Authorization Compiler
認可は、仕様として管理する。
Ninkaは、宣言的な認可仕様「Tegata」を、 決定論的にRegoへコンパイルし、OPA WASMとして実行可能にする。
npm install ninka-authznpm ↗認可要件（自然言語）
AIエージェントが作成するTegata（手形）
コンパイルされた Rego（毎回同じ出力）
アプリからは check() を呼ぶだけ
Problem
認可は、実装ではなく仕様だ。
AIがコードを書く時代。 認可ロジックは実装のあちこちに分散し、 人間が追いきれない速度で増えていく。
if (user.role === "admin") { ... }
if (invoice.ownerId === user.id) { ... }
if (user.department === invoice.department) { ... }認可を実装の中に直接定義することは、もはや現実的ではない。Ninkaは認可コンパイラであり、Policy Engineでも、Policy Languageでも、Authorization Platformでもない。
How It Works
AIが仕様を書く。 人がレビューする。 Ninkaがコンパイルする。
AIが生成するのは Tegata だけ。 人は認可仕様をレビューし、 Ninkaが決定論的にRegoを生成する。OPAがWASMをビルドし、Ninka RuntimeがそのWASMをin-processで評価する。
ライブデモ
Features
コンパイラだからできること
レビューするのは、認可仕様だけ
AIが書くのは Tegata だけ。 人は認可仕様の差分をレビューし、実装はコンパイラが生成する。
手形：江戸時代、関所を通るための通行証。
認可仕様を検査し、検証も生成する
スキーマ違反、参照不整合、矛盾、到達不能な例外など、Ninkaが機械的に判定できる問題をコンパイル時に検査する。 Tegataからvalidation vectorsも導出し、生成されたポリシーを機械的に検証する。
関所：手形を確認し、通行の可否を決める場所。
同じ仕様から、同じ実装を再現する
同じcanonical Tegataからは、バイト同一のRegoを生成する。 RegoからWASMへのビルドには、Ninkaが固定したOPA toolchainを使う。
版木：江戸時代、同じ文書を何度でも同じ内容で刷るための木版。
書かれていない意味を、追加しない
認可仕様に書かれていない判断は、実行ポリシーへ持ち込まない。 AIの推測や暗黙知ではなく、承認された認可仕様から生成されたポリシーを実行する。
不文律：書かれていない慣習や暗黙のルール。
Authorization Reference
認可を、コードではなく仕様としてレビューする。
仕様、そこからコンパイルされたルール、検証結果、そして実際のWASMが下す判定。そのすべてを、一つの画面で。
認可の全体像を読む
Policies、Resources、Roles、Actionsから、個々のルールと条件まで。認可の構造を、実装コードを追わずに確認できます。
実際の判定を確かめる
入力をその場で変更し、コンパイルされたWASMを評価。仕様として読んだ認可が、実際にどう判定するかまで確認できます。
いま何を見ているかが分かる
LIVE は現在のコンパイル済み状態。仕様が更新されれば STALE として明示。SNAPSHOT では、検証済みの認可状態を固定して共有できます。
$npx ninka docs
FAQ
FAQ
Q. Ninkaは何で、何ではないのか？
A. NinkaはAuthorization Compilerだ。Policy Engineでも、Policy Languageでも、Authorization Platformでもない。レビュー可能なTegataを決定論的にRegoへ変換し、OPA WASMとして実行可能な形へつなぐ。
Q. AIに認可を書かせて問題ないのか？
A. AIが作成するのはTegata（JSON）までで、実行コードには直接関与しない。人が認可仕様としてTegataをレビューし、SekishoがNinkaの定義した機械判定可能な問題を検査する。
Q. OPA や Rego の知識は必要か？
A. なくても使える。Regoは Tegataから自動生成されるため、手書きすることはない。知識があるに越したことはなく、生成された Rego はいつでも読んで確認できる。
Q. OPA と競合するものか？
A. 競合しない。NinkaはPolicy Engineではない。TegataをRegoへコンパイルし、OPAがWASMをビルドする。実行時はそのOPA WASMをNinka Runtimeがin-processで評価する。
Q. 生成されたコードを、どう検証するのか？
A. コンパイラがTegataからvalidation vectorsを導出し、built WASMで検証する。ninka verifyはcommitted validation tableを再導出し、committed WASMへ再実行して、成果物のhashとlineageも検証する。
Q. Authorization Referenceは認可サーバや管理画面か？
A. 違う。Referenceはコンパイル済み認可状態のread-only projectionで、プロジェクトへ書き込まず、コンパイルもしない。LIVEはloopback上で現在の状態を読み、SNAPSHOTは任意の静的ホストへ配置できる。アプリの認可判定がReferenceを経由することはない。
Q. 無料で使える範囲は？
A. ローカルのツールはすべて無料。ライセンスは BUSL-1.1 で、ソースの閲覧・改変が可能だ（制限は競合サービスとしての提供のみ。2030年に Apache-2.0 へ移行する）。
はじめる
ローカルで試す
CLIをインストールし、 最初の認可仕様を作成します。