Authorization for the AI Coding Era
AIはコードを書く。Ninkaは認可を守る。
AIがアプリを書くと、認可は if 文としてコードへ分散し、設計として維持できなくなります。 NinkaはAIに意図（手形）だけを書かせ、検査と変換はコンパイラが行います。本番に届くのは、承認済みのルールだけです。
認可要件（自然言語）
AIエージェントが作成する手形（Tegata）
コンパイルされた Rego（毎回同じ出力）
アプリからは check() を呼ぶだけ
Problem
AIは、その場では正しい認可コードを書く。
だが、認可という設計を維持する責任者がいない。
AIに任せると、認可はこうなります。 if (user.role === "admin") … if (invoice.ownerId === user.id) … if (user.department === invoice.department) … これが数百箇所に散らばります。1つ1つは正しくても、認可はコードへ分散し、設計として存在しなくなる。問題はAIの精度ではなく、これです。 認可の不具合の多くは、ここから始まります。
Features
コンパイラだから、できること
AIは好きにコードを書いていい。認可だけは、構造的に散らばれない。AIが書くのは意図（手形）だけで、if 文は書きません。認可は常に authz/ の1か所に集約され、検査（関所）と変換（金座）はすべてコンパイル時に行われます。
同じ入力からは、常に同じコードを生成
コンパイラは乱数や時刻を参照しない純粋関数として実装されています。同じ手形からは、いつ・誰が・何回コンパイルしても同一の Rego / WASM が生成されます。承認したルールと本番で動くコードが、常に1対1で対応します。
- 100回コンパイルのバイト比較で同一性をテスト
- 生成コードにタイムスタンプや環境情報を含めない
- CI の ninka verify がビルド漏れや手動改変を検出
- Rego の手書きは不要
All Features
How It Works
使い方
インストールして init
npm i ninka-authz と npx ninka init を実行すると、authz/ フォルダ、check() の呼び出し口、エージェント用の規約が作成されます。アカウント登録は不要です。
AIエージェントに依頼
「請求書の削除APIを追加。削除できるのは admin のみ」のように普段どおり依頼するだけで、エージェントが手形の作成、コンパイル、エラー修正まで行います。人は diff をレビューして承認します。
アプリから check() を呼び出し
アプリ側に認可の if 文は不要になります。CI に npx ninka verify を追加すると、手形とビルド成果物の不一致も検出できます。
Use Cases
主なユースケース
AIエージェント中心の開発チーム
認可コードが散らばる前に、ルールの置き場所を手形に統一します。検査がエージェントのループ内で行われるため、モデルの精度に認可の品質が左右されません。コードは多少荒れても、認可だけは荒れません。
Supabase RLS に限界を感じ始めたチーム
DB の外での判定、approve / export など CRUD 以外の操作、監査対応。RLS では難しくなった認可を、同じルールでどこからでも判定できます。
Pricing
料金
ローカルで動くツール（CLI・コンパイラ・ランタイム）はすべて無料です。有料プランは、チームでの承認フローと本番向けの署名機能として提供予定です。
Free
個人開発に必要な機能がすべて含まれます。
- • CLI 一式（init / compile / build / verify / explain）
- • コンパイル・検査は回数無制限
- • アプリ内 WASM ランタイム（check()）
- • TypeScript 型の自動生成
Ninka Cloud（準備中）
手形の変更を PR 上で検出し、承認記録を残す GitHub App です。
- • 手形単位の承認フロー
- • AIの解釈メモをレビューコメントに展開
- • 承認記録の保存
- • 本番向けの署名
Enterprise（準備中）
SSO や監査対応が必要な組織向けのプランです。
- • SSO 連携
- • 監査エクスポート
- • 決定ログ分析
- • 導入支援
FAQ
FAQ
Q. AIに認可を書かせて問題ないのですか？
A. AIが作成するのは手形（JSON）までで、実行コードには直接関与しません。手形はコンパイル時に検査され、問題があれば通りません。影響が及ぶのは「不正な JSON が PR に現れる」までで、本番には届きません。
Q. OPA や Rego の知識は必要ですか？
A. 不要です。Rego は手形から自動生成されるため、手書きすることはありません。必要に応じて、生成された Rego を確認することもできます。
Q. OPA と競合するものですか？
A. 競合しません。実行エンジンには OPA をそのまま使用しています。Ninka が提供するのは、その手前にある検査と承認管理の層です。
Q. Supabase RLS で十分ではないですか？
A. 単一の Postgres で CRUD 中心の構成であれば、RLS で十分です。DB の外で判定が必要になったときや、承認・エクスポートのような操作が増えたときに、Ninka が選択肢になります。
Q. 無料で使える範囲は？
A. ローカルのツールはすべて無料です。ライセンスは BUSL-1.1 で、ソースの閲覧・改変が可能です（制限は競合サービスとしての提供のみ。2030年に Apache-2.0 へ移行します）。
Next Step
まずは手元で試してみてください
npx ninka init から check() まで、5分で動かせます。
Contact Us
認可を、
承認できるかたちに。
現在、npm 公開とアーリーアクセスの準備を進めています。 ご興味のある方は、フォームからお気軽にご連絡ください。
- ✓アカウント登録不要・ローカルで完結
- ✓ソースコードは BUSL-1.1 で公開
- ✓認可設計のご相談も歓迎します