Problem
認可は、実装ではなく仕様だ。
AIがコードを書く時代。 認可ロジックは実装のあちこちに分散し、 人間が追いきれない速度で増えていく。
if (user.role === "admin") { ... }
if (invoice.ownerId === user.id) { ... }
if (user.department === invoice.department) { ... }認可を実装の中に直接定義することは、もはや現実的ではない。
How It Works
AIが仕様を書く。 人がレビューする。 Ninkaがコンパイルする。
AIが生成するのは Tegata だけ。 人は認可仕様をレビューし、 NinkaがRego/WASMと検証ベクタを生成する。
ライブデモ
Features
コンパイラだからできること
レビューするのは、認可仕様だけ
AIが書くのは Tegata だけ。 人は認可仕様の差分をレビューし、実装はコンパイラが生成する。
手形：江戸時代、関所を通るための通行証。
認可仕様から、検証も生成する
認可仕様から検証ベクタを自動で生成する。 境界値・型違反・欠落データまで検証し、曖昧な仕様はコンパイルしない。
関所：手形を確認し、通行の可否を決める場所。
いつでも同じ結果を再現できる
同じ認可仕様は、決定論的に同じ Rego/WASM へコンパイルされる。 いつ、どこで実行しても、同じ認可仕様からは常に同じ結果が生成される。
版木：江戸時代、同じ文書を何度でも同じ内容で刷るための木版。
書かれていない意味を、追加しない
認可仕様に書かれていない判断は、実行ポリシーへ持ち込まない。 AIの推測や暗黙知ではなく、認可仕様そのものを実行する。
不文律：書かれていない慣習や暗黙のルール。
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 へ移行する）。
はじめる
ローカルで試す
CLIをインストールし、 最初の認可仕様を作成します。