認可をレビューする
コンパイルが成功しても、その手形がプロダクトの意図した認可要件を正しく表しているとは限りません。分かるのは、Ninka がその手形を機械的に受理し、コンパイルできたということです。
要件どおりの認可仕様になっているかを判断するのは、人間のレビューです。
手形を書いたのが人でも AI エージェントでも、この責任は変わりません。
1. 要件と手形を突き合わせる
まず、変更のきっかけになった要件と手形を比較します。
生成された Rego がそれらしく見えるかどうかから始めないでください。人間がレビューする認可仕様は手形です。
少なくとも、次を確認します。
- 誰を許可し、誰を拒否するのか
- どの action が対象なのか
- どの resource type が対象なのか
- どの属性や関係によって判定範囲を絞るのか
- 例外の適用範囲が、意図した広さになっているか
要件そのものに複数の解釈があるなら、認可変更を受け入れる前に解釈を確定します。
2. ルールを「最終的に何を許すか」で読む
各ルールについて、次の組み合わせを確認します。
effect（allow / deny）- subject の role
- action
- resource type
- conditions
- relationships
各フィールドが構文上正しいかだけでは不十分です。それらを組み合わせた結果、誰のどの操作が許可または拒否されるのかを読みます。
正確なフィールド定義と評価規則が必要な場合は 手形スキーマ を参照してください。
3. audit.ambiguities を確認する
audit.ambiguities がある場合は、補足情報として読み飛ばさず、レビュー対象に含めます。
ここには、要件を手形へ落とす過程で書き手が明示した解釈の選択が入ります。その解釈でよいかを確認し、意図と違うなら要件を明確にするか、その判断を表す canonical なルールを修正します。
audit ブロック自体は認可判定を変えず、tegata_hash にも含まれません。
4. ポリシー全体を確認する
npx ninka-authz docs
Authorization Reference は、現在の認可仕様と生成済みの状態を読み取り専用で確認するためのものです。diff に出た行だけではなく、ポリシー全体を確認するために使います。
検証済みの WASM bundle がある場合は、Try it で具体的な入力に対する判定も確認できます。生成された validation の例や対話的な確認は有用な証拠ですが、仕様そのもののレビューを置き換えるものではありません。
5. 関所は機械的な検査として扱う
関所 (Sekisho) は、スキーマ、意味上の制約、ポリシー集合の整合性など、Ninka が機械的に判定できる規則を検査します。
関所を通過したからといって、次が保証されるわけではありません。
- 業務要件そのものが正しい
- プロダクトの意図どおりの範囲を許可している
- 重要な実利用シナリオをすべてテストした
- 人間が変更を承認した
Ninka のローカル toolchain は、人間の承認状態を保持したり強制したりしません。
6. 証拠の層を混同しない
verify が green でも、それは業務上の承認ではありません。手形が正しくても、アプリケーションが session や resource のデータを正しく入力へ対応づけている証拠にはなりません。逆に、アプリケーションのテストが通っても、元の業務要件が正しいとは限りません。
各検証が何を示し、何を示さないかは 認可をテストする を参照してください。
レビューを終える条件
認可変更を受け入れる前に、次の二つへ別々に答えられる状態にします。
- この手形は、プロダクトが意図した認可を表しているか。
- 受け入れた仕様が、これから出荷するシステムで正しく変換・統合・適用されることを示す証拠が十分にあるか。
1 つ目は人間のレビューが責任を持ちます。2 つ目のうち、コンパイラ・成果物・ランタイムに属する機械的な部分については Ninka が再現可能な証拠を提供します。一方、入力の組み立て、check() を呼ぶ場所、返された判定の適用はアプリケーション側の責任です。