【ITニュース解説】Guardrails in the Prompt Aren't Guardrails: An Authority Gate for Claude Code

システムエンジニアを目指す皆さんへ、AIが生成するコードの安全性を確保する上で非常に重要な考え方を紹介する。AIエージェント、特にコード生成能力を持つものは、私たちの開発作業を大きく助ける可能性がある。しかし、AIが勝手にコードを変更したり、意図しない振る舞いをしたりしないよう、その行動を確実に制御する方法が必要だ。

これまで、多くのAIエージェントの「ガードレール」は、システムに与える指示文、つまりプロンプトの中に「メインブランチに直接プッシュするな」といった形で記述されていた。AIはこの指示を読み、たいていはそれに従う。しかし、「たいてい」ではシステム開発において十分な制御とは言えない。本当に重要な変更の場合、AIが指示に従わない可能性が少しでもあれば、それは大きなリスクとなる。プロンプト内のテキストは、AIが解釈し、場合によっては無視することもできてしまうため、確実な制御手段とはならないのだ。

この問題に対処するため、「GODMODE V3」という仕組みが提案されている。これは、AIモデルの外部で意思決定を行い、AIエージェントがコード変更のような何かを変えようとする直前で、AIが偽装できない情報に基づいて判断を下す「権限ゲート」を提供する。簡単に言えば、AIが何かを変更する前に、必ずこのゲートを通過し、承認を得なければならないというルールだ。

GODMODE V3は二つの主要な層で構成されている。一つは「GODMODE V3」自体で、これが権限を管理する層だ。もう一つは「RuntimeV2」で、これが実際のコード実行を担当する層である。この二つの層は対等ではなく、GODMODE V3がRuntimeV2に対して命令を出し、その行動を厳しく制限する。

GODMODE V3（権限層）は、まず、エンジニアリングにおける具体的なルールを定めた「カード」と呼ばれるものを選び出す。そして、どのリポジトリの、どの範囲のファイルに対して、どのコミットからの変更なのかを特定し、最終的に「何を、どのように実行して良いか」という正確な実行内容（ペイロード）を生成する。この権限層が、実行して良い具体的な内容を完全に決定するのだ。

一方、RuntimeV2（実行層）は、実際にコードを実行し、その結果の証拠を生成するエンジンだ。しかし、このRuntimeV2は、それ自体で勝手にコード変更の機会（ミューテーションウィンドウ）を作り出すことはできない。つまり、RuntimeV2が何かを実行しようとする場合、必ずGODMODE V3の承認が必要となる。

この「カード」は、ただの文章ではなく、構造化されたデータでエンジニアリングルールを定義している。例えば、暗号化に関するカード「H04」では、パスワードや暗号化が必要な場合に適用され、「独自の暗号プリミティブを実装しない」といった厳格なルール、「認証なしの暗号化をしない」といったアンチパターン、そして最も重要な「最低限の証拠」として「暗号ライブラリの使用レビューと乱数ソースの検証」が必要だと明記されている。この「最低限の証拠」は非常に重要で、単に作業がどう行われるべきかだけでなく、その作業が完了したと主張するために何が必要かを具体的に示している。

具体的な制御は、「PreToolUseフック」と呼ばれる仕組みを使って実装される。Claude Codeは、外部ツールを呼び出す前にこのフックを実行できる。GODMODE V3は、このフックを通じて、すべてのツール呼び出しを「読み取り専用」「範囲を指定した変更（ファイル編集やシェルコマンド実行）」「最終的な確定（コミットとプッシュ）」のいずれかに分類する。

AIエージェントが変更を伴うアクションを実行しようとすると、そのアクションは必ずGODMODE V3による「生きた承認（live authorization）」と一致しなければならない。AIモデルは、自分で「これは許可された」と判断することはできない。承認はosagm_authorizeという専用の関数から提供され、これには使用するカード、ポリシー、正確な40文字のGitコミットSHA、リポジトリ、許可されたファイルスコープ、タスクの内容、そして実行されるべきペイロードの正確な内容とそのダイジェストが含まれる。もし実行しようとするペイロードが、承認されたペイロードとたった1バイトでも異なれば、その呼び出しは即座に拒否される。これにより、AIが承認された内容から逸脱してコードを変更するのを防ぐ。

さらに、「P0インバリアント（不変条件）」と呼ばれる厳格なルールが設定されている。これは、GODMODE V3のコードがリポジトリ内にあるにもかかわらず、ホストが別の経路を通じて変更を行ってしまうような特定の失敗を防ぐためのものだ。例えば、V3認証なしでRuntimeV2が直接実行されることは拒否される。RuntimeV2の状態だけでリポジトリの変更を承認することもできない。V3認証は常に正確なペイロードに紐付けられ、ペイロードが変更された場合は拒否される。リポジトリやファイルスコープも固定されており、RuntimeV2が勝手にそれらを広げることもできない。新しいV3認証は、以前開かれた下流のアクションを無効化する。ソースコミットSHAは常に正確な40文字のGit SHAである必要があり、不明な場合は失敗となる。これらのルールは機械的にチェックされ、厳格な安全性が保たれる。

AIエージェントが「テストが通りました」と主張しても、それは証拠にはならない。このシステムでは「証拠の段階」が定義されており、最も信頼できるのは「機械的に検証された」または「独立して検証された」という段階だ。AI自身の主張だけでは不十分で、客観的な検証がなければ「完了した」とは認められない。

もちろん、このGODMODE V3は万能ではない。現状では本番環境向けではなく、カードのマッチングも厳密なルールベースであり、高度な意味解釈はしない。また、バックエンドやセキュリティゲートなど、システム全体の他の重要な安全対策を置き換えるものでもない。そして、Claude Codeのツール層を通らないプロセスは、このシステムの制御範囲外となる。これはOSのサンドボックスのような広範な制御ではない。

しかし、この仕組みは非常に重要だ。AIエージェントは確かにコードを書くことができる。しかし、その変更が誰によって、どのルールに基づいて、どのコミットに対して承認されたのか、そしてそれがどう証明されたのか、という根本的な問いに答える必要がある。GODMODE V3は、AIモデルが勝手に制御を乗っ取れないような制御パスと、すべてのコード変更に対して厳格な証明要件を設けることで、AIが関与するソフトウェア開発の信頼性と安全性を高めるための答えの一つを示しているのだ。皆さんのAIエージェントの設定において、権限の決定がプロンプト内にあるのか、それともモデルの外部にあるのか、改めて考えてみる良い機会となるだろう。