AIエージェントを「信頼」で運用するのをやめよう — 権限モデルで設計する4つの境界
AIエージェントに「本番DBには触らないこと」と書いたプロンプトがある。それで安心しているなら、設計の出発点を間違えている。
結論を先に言う。プロンプトによる禁止は防御にならない。防御は実行層に置く。 これが今回紹介するZennの記事が主張する核心であり、Claude CodeやCodex CLIを実務で使い始めた人間が一度は正面から向き合うべき話だ。
AIエージェントに「触るな」と書いても確率は1.0にならない
なぜプロンプトの禁止が防御にならないのか。構造の問題だ。
LLMへの指示は、実行を制約するコードではなく、次のトークンの確率分布に影響を与える入力にすぎない。「本番DBには触らないこと」という一文は、その通りに振る舞う確率を上げる。しかし確率を1.0にすることはできない。モデルが賢くなれば従う確率は上がるが、「確率である」という性質自体は変わらない。
指示が破られる経路は3つある。
| 経路 | 内容 |
|---|---|
| 解釈の齟齬 | 「テスト環境で」という指示に対し、接続先の判別を誤る |
| 制約の見落とし・競合 | 長く複雑な文脈で、初期の制約が他の要求と競合・埋没する |
| 間接プロンプトインジェクション | 読み込んだファイル・Webページ・ツール出力に含まれる文字列を、指示として解釈する |
3つ目が実務で最も厄介だ。エージェントに外部データを読ませる構成では、入力データが指示として扱われる可能性が常にある。記事の著者は「命令階層の設計やデータと命令の分離は成功率を下げる有効な緩和策だが、実行権限の制限を代替する強制境界にはならない」と明確に述べている。
帰結はシンプルだ。「破られる前提で、破られたときに何が実行できるかを制限する」 これが設計原則になる。
なぜ今この話が重要か
Claude Code、Codex CLI、各種MCPクライアント。これらは「チャットで相談するAI」ではなく、「ファイルを読み書きし、コマンドを実行し、外部APIを叩くAI」だ。実作業を委譲できる分、被害の半径が一気に広がる。
去年まで「AIとの対話」だったものが、今年から「AIへの権限委譲」になっている。この変化に、安全設計の考え方が追いついていないケースが多い。現場で一番よく見るのは「賢いモデルを選べば事故は減る」という発想だが、これは本質的に正しくない。問題は「権限を渡す範囲を決める」設計の問題だ。
4つの権限境界と、それぞれの「成立条件」
記事では実装として引ける境界を4つ挙げている。重要なのは「どれも単体では境界にならない」という点で、成立条件とセットで考える必要がある。
① ファイルシステム
読み取り専用モードで起動できる実装であれば、それが第一選択だ。
# Codex CLI: 読み取り専用サンドボックスで起動する
codex exec -s read-only "<レビュー依頼>"
書き込みを伴う作業では作業ディレクトリを分けるが、ここに落とし穴がある。git worktreeで作業ツリーを分けただけではセキュリティ境界にならない。コンテナやVM、OSのユーザー権限、エージェント自身のサンドボックス機能を併用して、元の作業ツリーや共有認証情報に到達できない状態を作る必要がある。
エージェントが「触れない」状態を作ること。「触らないよう頼む」ことではない。
② ネットワーク
エージェントが外部と通信できる構成は、データの持ち出し経路になりうる。到達可能なドメインを許可制にする（コンテナ内で実行し、egressをプロキシ経由に限定するのが確実）のが基本だ。
MCPサーバーへの接続はこの面の判断になる。接続するとエージェントが使える権限の上限が広がる。実効権限はサーバーが提供する能力・渡したトークンのスコープ・クライアント側のツール許可と都度承認設定の組み合わせで決まる。接続前に確認すべきはツール一覧だけでなく、読み書きの範囲・外部送信の有無・認証スコープ・承認を省略する設定になっていないか、だ。
③ 認証情報
原則は「エージェントのプロセスに本番の認証情報を渡さない」こと。全環境変数を継承した状態で起動するのは避け、必要最小限のスコープのトークンを必要なときだけ渡す。
やむを得ず渡す場合も、スコープを絞る（read権限のみのトークンを別途発行）・有効期限を短くする・本番と開発でキーを分離する、の3点で影響を限定する。
ここで記事の著者が指摘している点が実務的に刺さる。「AIが漏らすかもしれない」という懸念以前に、エージェントが読むファイル（ログ・エラー出力・設定ファイル）に認証情報が載る経路のほうが現実的なリスクだ、と。AIの行動への警戒より先に、情報管理の基本が問われている。
④ 高影響操作（外部副作用）
送信・決済・公開・削除・force push。判断軸は「不可逆かどうか」だけではなく、公開範囲・金銭・復旧コストを含めた影響の大きさだ。これに該当する操作は自動実行から外す。
著者の運用は具体的で参考になる。「記事の下書き生成も画像生成もAIに任せているが、公開ボタンは人間が押す。理由はAIの精度ではなく、やり直せる操作とやり直せない操作でリスクの桁が違うから」。
ただし、人間の承認を置けば安全というわけでもない。操作名だけを見て押す承認は「承認疲れ」と「誤誘導」に弱い。対象・差分・宛先・金額・公開範囲が確認できる形で提示するところまでが設計だ。
pre-commit hookが「防御」にならない理由
著者が「自分が実際に間違えた」と認めているのがこの点だ。
# hookは回避できる
git commit --no-verify -m "..."
--no-verifyで回避できるうえ、権限設定によってはhookの設定や検査対象のファイル自体を書き換えることもできる。構造的な問題は「チェックする側の仕組みが、チェックされる側の権限内に置かれている」ことだ。
正しい位置づけはこうなる。
| 仕組み | 実行環境 | 役割 |
|---|---|---|
| pre-commit hook | ローカル（エージェントが権限を持つ） | 早期発見の網。回避可能 |
| CI（GitHub Actionsなど） | 信頼境界の外（サーバー側検証） | 条件を満たせばゲートになる |
ただしCIも、置くだけではゲートにならない。①保護ブランチの必須チェックとして指定されている、②エージェントがworkflowファイルや保護ルールを書き換えられない、③合否の報告経路をエージェントが操作できない、の3条件が揃って初めて機能する。
「ローカルは速度のため、CIは強制のため」という整理が明快だ。
監査役AIにも書き込みを渡してはいけない
複数のAIを相互監査させる構成（Claude Codeの実装をCodexにレビューさせる等）では、監査役の権限設計が別途必要になる。
# 監査役は読み取り専用で起動する
codex exec -s read-only "この差分を監査してください。観点: ..."
-s read-onlyを付ける理由は2つ。ひとつは責任所在の保全。レビュアーが直接コードを直し始めると、その変更が誰の判断によるものか追跡できなくなる。もうひとつは合意の擬似性の問題。2つのモデルが同じ誤りを共有することはある。AIどうしの「合意」は「正しさの証明」ではなく、「人間が読む優先度を下げてよいサイン」にとどめるべきだ。
出力は「提案」で止め、採否は人間が決めてから実装側に反映させる。この一方向の流れを設計に埋め込む。
これは「AIを疑う」設計ではなく、「信頼に依存しない」設計だ
ここからは見方の話をする。
この記事の主張をひと言で解釈するなら、「AIを信用するかどうかという問いを、設計の外に追い出す」ということだと思う。信頼できるか否かで運用を変えるのではなく、信頼の有無に関係なく安全が担保される構造を作る。著者自身が最後にこう書いている。「権限設計は『AIを信用しない』ための仕組みではなく、信用の有無に依存せずに済ませるための仕組みです」。
この視点は、今後のAIエージェント導入の議論でひとつの判断軸になる。「このエージェントは信頼できますか」という問いは、実はあまり意味がない。問うべきは「このエージェントが最悪の動きをしても、境界内で止まりますか」だ。
同種のニュースやツール紹介を見るときに使える軸がある。「これはプロンプトで制御する話か、権限で制御する話か」 を切り分けること。新しいAIエージェントツールが出たとき、その安全機能が「賢いプロンプト設計」に依存しているなら、防御にはならないと疑ってかかるべきだ。
実務的な示唆と、次に来る論点
エンジニアでない人への翻訳として、記事は3点に絞っている。
- 新しいことを任せるときは、読み取りから始める — 案を出させる・下書きを作らせる段階を経てから、実行を任せる
- 送信・支払い・公開のボタンは自分で押す — 押す前に宛先・金額・公開範囲を見る、までがセット
- パスワードやカード番号は会話に書かない — ちゃんとしたサービスは、認証を会話の外で完結させる
シンプルだが、これが守れていない現場は多い。
次に問題になるのは、MCPサーバー経由の権限拡大だと思う。個々のAIエージェントの権限は管理しても、MCPサーバーを接続するたびにその上限が広がっていく。しかも接続するサーバーの数が増えるほど、権限マップは複雑になる。「ツール一覧だけでなく、読み書きの範囲・外部送信の有無・認証スコープを確認する」という著者の指摘は正しいが、それを人間が毎回チェックし続けるのは現実的ではない。MCPサーバーの権限を一元管理・可視化する仕組みが次の実装課題になるはずだ。
境界が引けていれば、その内側は安心して任せられる。この言葉が実感できる設計になっているかどうか、今一度確認する価値がある。
