Authorization for the AI Coding Era
バイブコーディング時代の、AIが書き、コンパイラが保証する認可。
AIはあなたのアプリを書けるようになった。しかし認可は書けない──書けているように見えるだけだ。 Ninka は、AIに if 文ではなく「決まりそのもの」を書いた小さなJSON＝手形（Tegata）を書かせます。手形は関所（Sekisho）が検分し、危険な決まりはAI自身が直す。承認された手形からは、いつ誰がコンパイルしても1バイトも違わない Rego / WASM が鋳造される。アプリは check() を呼ぶだけ。
認可要件（自然言語）
AIエージェントが書く手形（Tegata）
金座が鋳造する Rego（バイト同一）
アプリは check() を呼ぶだけ
Problem
AIはアプリを書ける。認可は書けない。
書けているように見えるだけだ。
AIにアプリを書かせると、「adminだけ削除できる」という決まりは if (user.role === "admin") としてコード中に散らばります。しかもAIは頼むたびに微妙に違うコードを書く。結果、「いまどういう決まりで動いているか」を言い切れる人がいなくなる。 AIが最も得意なのは「動いて見えるが微妙に間違っているコード」であり、認可はその典型です。デモでは通る。本番で権限昇格が起きる。 敵はOPAでも競合でもない。AIが量産する if user.role == "admin" である。
Features
手形・関所・金座 — 決定性の壁
AIの揺れは手形より手前に閉じ込め、手形から先は「同じ入力なら同じ出力」の純粋な機械にする。AI generates, compiler guarantees.
承認できる形の認可 — 小さなJSONの証書
認可の決まりを「誰が・何に・何を・どんな条件で」だけを書いた小さなJSON＝手形として宣言します。書くのはAIでいい。しかし効力は人間の承認から生まれる。手形には内容から計算される指紋（tegata_hash）があり、AIの解釈メモ（ambiguities）も同乗します。
- エンジニアでなくても読める宣言形式（1ファイル＝1ポリシー＝1承認単位）
- 指紋 tegata_hash の承認＝実行されるコードの承認
- AIの解釈（「50万円以内は50万ちょうどを含む」等）が申告として残る
All Features
How It Works
5分で最初の認可が動く
npm i ninka-authz → npx ninka init
authz/（スキーマ・例ポリシー・語彙）と check() 境界、そして AGENTS.md のエージェント規約を配置し、例ポリシーを即コンパイルします。アカウント作成・APIキーは不要。関所＋Rego＋型生成まで完全オフラインで動きます。
エージェントに、普段どおり頼む
「請求書の削除APIを追加して。削除できるのは admin だけ」— エージェントが規約に従って手形を書き、npx ninka compile を実行し、関所のエラーを自分で直します。人間の仕事は手形の diff と解釈メモ（ambiguities）のレビューだけ。
アプリは check() を呼ぶだけ
決まりの中身はアプリのコードのどこにも書かれていません。判定はアプリ内 WASM で数十マイクロ秒。CI では npx ninka verify が「手形と成果物のバイト一致」を検査し、ビルド忘れや手書き改変を落とします。
Use Cases
こんなチームにフィットします
バイブコーディングで作っている新規プロダクト
エージェントに書かせたアプリの認可が if 文で散らばり始める前に、認可の砂場（手形）を最初から用意する。エージェントのループに関所が入るので、弱いAIが書いても品質の下限はコンパイラが保証します。
Supabase RLS を「卒業」する瞬間
判定がDBの外に出た（2つ目のサービス・ジョブ・外部API）、動詞がCRUDを超えた（承認・エクスポート・共有）、監査が来た — この瞬間から、同じ手形をどこでも check() できる Ninka の領分です。
Pricing
道具は配りきる。お金は「会社としての承認と記録」から。
コンパイラ・CLI・実行ライブラリは BUSL-1.1 で公開し、ひとりで作っている間の全部が無料です（コンパイル無制限・ローカル完結）。有償が始まるのは、2人目が現れたとき（承認フロー）と、本番に載せるとき（署名）から。
Free — ローカルの道具すべて
npm install だけで、認可のコンパイラ一式が手に入ります。アカウント不要・オフライン動作。
- • CLI ninka（init / compile / build / verify / explain）
- • 関所の検分・コンパイル無制限
- • WASM ビルドと in-process ランタイム（check()）
- • TypeScript 型生成・CI 用ドリフト検査
Ninka Cloud（準備中）
2人目が現れた瞬間から。GitHub App が手形の指紋差分を検出し、AIの解釈メモをレビュースレッドとして展開、「hash X を誰がいつ承認したか」を記録します。
- • 承認フロー（tegata_hash 単位）
- • 解釈メモ（ambiguities）→ レビュースレッド展開
- • 承認記録・監査チェーン
- • 署名サービス（組織の承認の公証・オフライン検証）
Enterprise（準備中）
監査に「はい」と答えられる状態を組織として維持するためのプランです。
- • SSO 連携
- • 監査エクスポート
- • 決定ログ分析
- • 導入支援・優先サポート
FAQ
FAQ
Q. AIの出力を認可に使って、本当に大丈夫なのですか？
A. AIの揺れ（非決定性）は手形を書くところまでにしか存在しません。手形は関所が機械的に検分し、矛盾や「絶対に発動しない例外」は名指しでエラーになります。最悪でも「変な手形が書かれた」で止まり、「変な認可が本番に出た」には決してなりません。そして承認された手形からは、バイト同一のコードしか生まれません。
Q. OPA や Rego を知らなくても使えますか？
A. はい。人間もAIエージェントも、Rego を一行も書きません。エージェントが書くのは読める証書（手形）で、Rego はそこから機械的に鋳造されます。深掘りしたい人だけ、手形 → Rego と降りていけます。
Q. OPA との関係は？ 競合ですか？
A. いいえ。OPA は実行エンジンとしてそのまま使います（再発明ゼロ）。OPA に8年間欠けていたのは「人間との契約層」— 何が要件で、誰が何を承認し、承認したものと動いているものが同じだと誰が保証するのか — であり、Ninka はその一層を上に置くだけです。既存の OPA 基盤にもそのまま相乗りできます。
Q. Supabase RLS で足りているのですが？
A. 単一 Postgres・CRUD 動詞・コンプラ圧力なしの間は RLS で十分です。判定が DB の外に出た瞬間（2つ目のサービス・ジョブ・外部API）、動詞が CRUD を超えた瞬間（承認・エクスポート・共有）、監査が来た瞬間 — そこからが Ninka の領分です。
Q. 本当に無料ですか？ ソースは見られますか？
A. 道具（コンパイラ・CLI・ランタイム）は BUSL-1.1 で公開します。ソースは読めて改造でき、競合マネージドサービスとしての提供だけが禁止です（2030年に Apache-2.0 へ自動移行）。課金は承認フロー・署名という「組織の仕事」が始まってからです。
Next Step
エージェントに頼めば、承認できる認可が出てくる。安全に。
バイブコーディングを否定しない。バイブコーディングのままで安全になる。 npx ninka init → エージェントに依頼 → compile → check() — 5分で最初の認可が動きます。
Contact Us
認可を、
承認できるかたちに。
Ninka は現在、npm 公開とアーリーアクセスの準備中です。 バイブコーディングで実際にプロダクトを作っているチームの声を探しています — 導入相談・フィードバック・壁打ち、歓迎です。
- ✓アカウント不要・完全ローカルで動く道具
- ✓BUSL-1.1 でソース公開（読める・改造できる）
- ✓導入・認可設計の相談歓迎