認可要件（自然言語）
AIエージェントが作成するTegata（手形）
コンパイルされた Rego（毎回同じ出力）
アプリからは check() を呼ぶだけ
Problem
認可は、実装ではなく仕様です。
AIがコードを書く時代、認可は実装へと分散し、人間が追えない速度で増え続けます。
if (user.role === "admin") { ... }
if (invoice.ownerId === user.id) { ... }
if (user.department === invoice.department) { ... }認可を実装として定義することは、もはや現実的ではありません。
How It Works
使い方
AIが認可仕様を書く
AIが生成するのは、宣言的な認可仕様 Tegata だけです。 人間はその差分をレビューします。
{
"effect": "allow",
"subject": { "roles": ["manager"] },
"actions": ["approve"],
"resource": { "type": "invoice" }
}Ninka Compilerがコンパイルする
Tegata │ ▼ Ninka Compiler ├─ Static Validation └─ Deterministic Compilation │ ▼ Rego / WASM │ ▼ Self Verification
Ninka Compilerは、Tegataを静的解析し、決定論的にRego/WASMへコンパイルします。生成されたRego/WASMは、Tegataから自動導出した検証ベクタによって、境界値・型違反・欠損を含めて自己検証されます。
アプリは check() を呼ぶだけ
const ok = await check({
subject,
action,
resource,
});アプリケーションに認可ロジックを書く必要はありません。 実行はin-processのOPA/WASMが担います。
Features
コンパイラだから、できること
曖昧な認可を、実行前に止める
Tegataは、そのままポリシーにはなりません。関所が仕様を検分し、曖昧な解釈、不整合、危険な表現を通しません。
同じ型から、同じポリシーを鋳造する
検分を通ったTegataを、定義された意味論に従ってRego/WASMへ変換します。同じTegata hashとcompiler versionからは、同じポリシーが生成されます。
書かれていない意味を、追加しない
Ninkaは認可仕様の行間を読みません。自然言語から生まれた曖昧な解釈は ambiguities として残し、仕様に存在しない判断を実行ポリシーへ混入させません。
下した判定を、実行後も確認できる
生成されたポリシーはin-process WASMとして実行されます。判定ログは宣言された属性だけを記録し、それ以外の入力は自動的にマスクされます。
FAQ
FAQ
Q. AIに認可を書かせて問題ないのですか？
A. AIが作成するのはTegata（JSON）までで、実行コードには直接関与しません。Tegataはコンパイル時に検査され、問題があれば通りません。
Q. OPA や Rego の知識は必要ですか？
A. なくても使えます。Regoは Tegataから自動生成されるため、手書きすることはありません。知識があるに越したことはなく、生成された Rego はいつでも読んで確認できます。
Q. OPA と競合するものですか？
A. 競合しません。OPA は強力ですが、Rego を書くのは難しい — Ninka は Tegata という認可の抽象化レイヤーを与え、OPA へ決定論的にコンパイルします。実行時に動くのは OPA そのものです。
Q. 生成されたコードが正しいと、なぜ言えるのですか？
A. 検定があるからです。コンパイラがTegataから検証ベクタを自動導出し、境界値・型違い・データ欠損まで機械的に網羅します。独立実装の参照評価器と本番 WASM の両方に流して、全件一致した場合にだけビルドが通ります。テストを人が書く必要はありません。
Q. 無料で使える範囲は？
A. ローカルのツールはすべて無料です。ライセンスは BUSL-1.1 で、ソースの閲覧・改変が可能です（制限は競合サービスとしての提供のみ。2030年に Apache-2.0 へ移行します）。
Next Step
まずは手元で試してみてください
npx ninka init から check() まで、1分で動きます。