関所 (Sekisho)

関所 (Sekisho) は「チェックポイント」を意味します。Ninka のコンパイル時検査です。手形 (Tegata) がコンパイルされる前に、関所はその 意味 を検査します。JSON として整形式かどうかだけではありません。

手形は完全に妥当な JSON でありながら、危険なポリシーであり得ます。関所は、妥当だが間違っているポリシーのコンパイルを拒む門です。

何を、なぜ検査するのか

スキーマ検証は、ドキュメントが正しい 形 をしていることしか教えてくれません。関所は、このポリシーが安全な 意味 を持つかを問います。AI エージェントが（あるいは疲れた人間が）繰り返し作り出す、意味レベルの問題のカテゴリを捕まえます。

• 矛盾。 同じ条件が、同じアクションを allow にも deny にもしている。ポリシーは自己矛盾しており、意図された判定は決定不能です。
• 死んだ例外 (dead exception)。 より広い deny が既に優先しているため、決して発火し得ない allow ルール（deny は allow に優先）。アクセスを許可したつもりでも、どのリクエストもそこに到達できません。関所は、何もしないルールを表に出します。
• 語彙のドリフト (vocabulary drift)。 同じ概念の二つの綴り。admin と administrator、admin と Admin。文字列比較にとってこれらは別々のロールなので、管理者を対象にしたつもりのルールが、静かに半分を取りこぼします。

一部の指摘はコンパイルを止めるハードエラー、一部はレビューの参考になりつつコンパイルを続行させる警告です。いずれの場合も、メッセージは何を変えればよいかを正確に伝えます。

エラーは一行で、修正方法が分かる

関所のメッセージは短く、何を直せばよいかを伝えます。これは AI エージェントとのループを閉じます。エージェントが手形を書き、コンパイラを走らせ、関所が却下したら、その一行のエラーだけでドキュメントを修正して再試行できます。書く → 検査する → 直す のループを、人間が見る前にエージェント自身が回すのです。手形があなたの承認に届く頃には、既に関所を通り抜けています。

エージェントが手形を書く ─► ninka compile ─► 関所
        ▲                                    │
        └──────── 一行のエラー ◄─────────────┘   （通るまでループ）
                                             │
                                     通過した ▼
                                    人間が承認する

一度きり、ビルド時の検査

関所は 一度だけ、コンパイル時に、ポリシードキュメントそのものに対して走ります。ランタイム（コンパイル済み ポリシーを リクエストごとに 適用する OPA）と意図的に対になっています。チェックポイントは証書を一度検査し、番人はすべての通行を判定する。関所の仕事は、そもそも悪いポリシーが決してコンパイルされないようにすることです。