AIエージェントが「このファイルを削除すべきだ」と判断したとき、実際に削除できるかどうかを誰が決めるのか。文章の誤りなら生成後に検査できるが、削除、公開、送信、権限変更は、実行後に取り消せない場合がある。エージェントが環境を操作するなら、安全性も操作の直前で確かめる必要がある。

モデルにルールを教える技術は、そのためにも有用だ。安全な回答例を学習させ、禁止事項をプロンプトに記述し、望ましくない行動にはペナルティを与える。OpenAIのDeliberative Alignment ↗も、安全仕様をモデルへ教え、回答時にその仕様を参照して推論させる手法である。状況に応じてルールを解釈できれば、不適切な提案を減らせる。

ただし、モデルがルールを理解していることと、違反する操作を実行できないことは別だ。前者はモデルの性質であり、後者は実行基盤の性質である。エージェントを運用する側には、次の問いが残る。

AIが考えたことのうち、何を実行できるのか。

この境界をモデルの自己判断だけに委ねず、外部のシステムで管理したい。

推論の裁量と実行権限

高性能なエージェントには、未知の状況を解釈し、仮説を立て、計画を変える能力を期待する。すべての手順を人間があらかじめ決めてしまえば、その柔軟さを使える場面は減る。仕事を進めるワーカーAIには、探索と推論の裁量が必要だ。

しかし、「外部へ情報を送れば仕事が進む」と考えられることは、その情報を送信する権限があることを意味しない。計画の提案と実行の許可を分ければ、考え方を狭めずに操作範囲を限定できる。

AIには自由に考えさせる。 ただし、自由には実行させない。

ワーカーは計画や操作を提案する。外部の統制システムは、実行条件を満たすか判定し、許可または拒否する。拒否されたワーカーは理由を受け取り、別の方法を考える。この構造なら、ルールを守ろうとしたかどうかにかかわらず、統制の対象になっている未許可の操作を止められる。

例えば、読み取りと提案は自律的に行わせ、書き込みには検証を要求する。サンドボックス内では試行を許し、本番環境への反映には承認を求める。不可逆な操作は人間へ委譲する。自律性を一律に下げるより、操作ごとに権限を分ける方が、問題解決の能力と失敗時の影響範囲を別々に扱える。

コントロールプレーンが管理するもの

ワーカーの外側で、能力、権限、状態、予算、操作対象を管理する仕組みをコントロールプレーンと呼ぶ。ワーカーが情報を集め、計画を立ててツールの使用を要求するのに対し、コントロールプレーンは、その呼び出しを実行前に捕捉する。

判定には、誰が、何に、何をしようとしているかだけでなく、操作時点の条件も必要になる。

  • 要求元のエージェントと操作対象のリソース
  • 読み取り、更新、削除、送信などの操作種別
  • 業務の進行状態と承認状態
  • 機密情報や個人情報の有無
  • 予算、回数、時間、件数の上限
  • 操作の可逆性と、必要な承認者
  • 直前までの行動系列との整合性

判定結果も、許可と拒否の二択とは限らない。パラメータを安全な範囲へ縮小する、機密項目を除外する、読み取り専用にする、サンドボックス内で実行する、人間の承認へ回す、といった処理が考えられる。

ただし、ワーカーが別の方法で同じ操作を実行できれば、統制は成立しない。セキュリティ分野の「リファレンスモニター」は、重要なアクセスを必ず仲介する仕組みであり、すべての対象アクセスで呼び出されること、改変から保護されること、検証できる程度に小さく単純であることを求める。エージェントの統制層にも、この考え方が当てはまる。

プロンプトにルールを書くだけでは、監督されるモデル自身がルールを解釈し、実行可否まで決めてしまう。外部で強制するには、ツール、API、ファイルシステム、ネットワーク、データベースへの操作を統制層に通す必要がある。

形式化できる条件の判定

明確な条件を毎回同じように適用する処理は、コードやポリシーエンジンに任せられる。例えば、次のような制約だ。

  • 指定ディレクトリ以外への書き込みを禁止する
  • 外部通信を許可リスト内のドメインに限定する
  • 一定額を超える送金に承認を要求する
  • 顧客識別子を含むデータの外部送信を禁止する
  • 本番変更の前にテスト成功を要求する
  • 削除を論理削除に限定する
  • 一定回数の失敗で処理を停止する
  • 読み取り専用のエージェントによる更新を禁止する

これらを型、スキーマ、アクセス制御、状態機械、Policy as Codeとして実装すれば、条件が満たされたかをモデルの都度の解釈に委ねずに済む。

2026年6月の「Autoformalization of Agent Instructions into Policy-as-Code」 ↗は、自然言語の指示やツールの説明を、Cedarというポリシー言語へ変換する手法を提案している。AIがポリシー案の作成を支援しても、実行時の判定は形式化したルールに基づく。2026年3月の「Before the Tool Call」 ↗も、ツール呼び出しを実行直前に捕捉し、宣言的なポリシーで権限を判定する構造を提案している。

ここでの原則は、次のとおりである。

決定論的に判定できることを、確率的なAIに判定させない。

曖昧な状況を整理し、拒否理由を理解し、代替手段を探す能力はワーカーに必要だ。一方、形式化できた権限の最終判定は、外部システムが担う。

監督AIと人間へ委ねる判断

形式化できない判断も残る。「ユーザーの本来の意図に反していないか」「業務上妥当か」「別の情報と組み合わせると危険にならないか」といった問いには、意味や文脈の理解が要る。この部分では、別のAIを監督役として使う価値がある。

OpenAIが2026年4月に公開したCodexのAuto-review ↗は、サンドボックスの境界を越える操作を別のエージェントが審査し、許可または拒否する構成を採っている。タスク完了を目指すメインエージェントと、境界を越える操作を評価する監督役を分けることで、審査の評価と改善を行いやすくする。拒否されたワーカーが、その理由から安全な代替手段を見つける場合もある。

ただし、OpenAI自身が説明するように、Auto-reviewは決定論的な安全保証ではない。監督AIには誤認や見逃しがあり得る。同社はこの方式を、決定性を犠牲にして表現力を得る仕組みと位置づけている。

そこで、判断を三つに分ける。形式化して禁止できる操作はシステムが止める。文脈によって許可の是非が変わる操作は監督AIが評価する。損害が大きい、根拠が足りない、ルールが衝突するといった場合は人間へ委譲する。監督AIは、形式的な統制で扱えない部分を補う役割を持つ。

ツールの内側で起きる操作

ツール呼び出しの直前にチェックを置いても、そのツールが起動する子プロセスや、そこから発生する通信まで管理できるとは限らない。シェルコマンド、ネットワークアクセス、ファイル操作に未監視の経路があれば、ワーカーは統制を迂回し得る。

2026年に発表されたActPlane ↗は、ツール呼び出しだけでは捕捉できない間接的な操作を問題とし、OSレベルでポリシーを強制する構成を提案している。エージェント側でタスクの意味を解釈し、OS側で実際の制約を強制する分離である。

実行権限を広げるほど、従来のセキュリティ技術も必要になる。OSのサンドボックス、ネットワーク制御、秘密情報管理、認可、監査ログ、トランザクション、ロールバックは、そのための手段だ。プロンプトの改善だけでは、これらの操作経路を管理できない。

事前認可とモニタリングの役割

操作を事前に認可しても、許可された操作の組み合わせから想定外の結果が生じることはある。個々の操作では正常に見えても、長期の行動系列では不自然になる場合もある。そのため、実行前の統制とは別に、履歴を継続的に分析する必要がある。

2026年3月19日のOpenAIの説明 ↗では、社内のコーディングエージェントについて、行動と推論を別のモデルで分析し、ユーザーの意図や社内ポリシーに反する可能性のある挙動を検出している。当時のレビューは完了後30分以内で、将来は操作前の評価へ近づける方向が示されていた。

事前認可は、定義した条件に反する操作を止める仕組みである。モニタリングは、事前認可で捉えきれなかった違反や、まだ定義していない問題のある行動を見つけ、ルールの改善につなげる。実行前、実行中、実行後で、異なる役割を担う。

AI Controlの研究 ↗でも、高性能だが完全には信頼できないモデルに、監視、編集、限定的な人間監査などを組み合わせる方法が検討されている。安全性を評価する単位は、モデル単体から、モデルと監督手段を組み合わせた運用プロトコルへ広がる。

削除の判断を、削除権限につなぐ前に

冒頭のファイル削除なら、ワーカーは削除を提案できる。その提案が、対象範囲、検証、承認といった条件を満たして初めて実行される。実行後の記録は、判定や結果が妥当だったかを確かめるために残す。目指したいのは、こうした手順が機能するシステムだ。

ルールから外れる可能性を持ちながらも、許可されていない行動を勝手には実行できないAIシステムである。

モデルの安全学習は、今後も必要である。通常時に不適切な操作を避けられれば、拒否や再試行の運用コストを減らせる。しかし、その学習を最終的な防壁にはできない。

推論には裁量を与え、実行には検証可能な条件を課す。AIエージェント開発は、モデルの振る舞いを改善するアラインメントに加えて、モデルの能力をどこで使い、どこで止めるかという実行ガバナンスを設計する必要がある。