AIエージェントの安全性を考えるとき、一般には「AI自身にルールを理解させ、正しく振る舞うよう学習させる」という発想が採られる。安全な回答例を学習させ、禁止事項をプロンプトに記述し、望ましくない行動にはペナルティを与える。OpenAIのDeliberative Alignmentのように、安全仕様そのものをモデルへ教え、回答時にその仕様を参照して推論させる手法も、この方向に位置づけられる。モデルが状況に応じてルールを解釈できるようにする点で、これは重要な技術である。
しかし、AIエージェントの実運用を考えると、安全性をモデル自身の規範意識だけに依存させるべきではない。
AIが文章を生成するだけなら、不適切な回答を生成後に検査することもできる。ところが、AIエージェントはファイルを読み、コードを実行し、データベースを更新し、外部サービスへ情報を送信する。誤りは「回答」という成果物ではなく、環境に対する操作として発生する。削除、公開、送信、権限変更といった操作は、一度実行されれば取り消せない場合もある。
したがって、エージェントの安全性における中心的な問いは、AIが何を考えたかではない。
AIが考えたことのうち、何を実行できるのか。
この境界を、モデルの自己判断ではなく、外部のシステムによって管理する必要がある。
推論の自由と、実行の自由を分ける
高性能なAIエージェントの価値は、あらかじめ人間が想定した手順だけを再現することではない。状況を解釈し、仮説を立て、計画を変更し、複数の手段を比較しながら目的を達成することにある。
その能力を活かすには、ワーカーAIの推論を過度に縛るべきではない。すべての判断をルール化し、決められた手順から外れないようにすれば、AIを導入する意味そのものが薄れる。未知の状況への対応力や、柔軟な問題解決能力が失われるためである。
一方で、推論の自由をそのまま実行の自由へ接続してはならない。
AIが「このファイルを削除すべきだ」と判断することと、実際に削除できることは別の問題である。「この情報を外部へ送信すれば仕事が進む」と考えることと、その情報を送信する権限があることも別である。
必要なのは、次の分離である。
AIには自由に考えさせる。 ただし、自由には実行させない。
ワーカーAIは、目的達成のための計画や操作を提案する。外部の統制システムは、その操作を実行してよいか判定する。許可されれば実行し、条件を満たさなければ拒否する。AIは拒否理由を受け取り、別の方法を考える。
ここでは、ルール違反をAIの「人格」や「態度」の問題として扱わない。AIがルールを守ろうとしたかどうかにかかわらず、許可されていない操作は実行されない。安全性を、確率的なモデルの振る舞いから、実行基盤の構造へ移すのである。
ワーカーAIとコントロールプレーン
この構造は、ワーカーAIとコントロールプレーンの二層に分けて考えると分かりやすい。
ワーカーAIは、業務を遂行する主体である。情報を収集し、推論し、計画を立て、ツールの使用を要求する。ワーカーには、一定の裁量と探索の自由を与える。
コントロールプレーンは、ワーカーの能力、権限、状態、予算、操作対象を管理する。AIが発行したツール呼び出しを実行前に捕捉し、ポリシーに照らして処理する。
典型的には、次の情報から判定を行う。
- どのエージェントが操作を要求しているか
- どのリソースを対象としているか
- 読み取り、更新、削除、送信のどれに該当するか
- 現在の業務状態や承認状態はどうなっているか
- 操作対象に機密情報や個人情報が含まれるか
- 予算、回数、時間、件数などの上限を超えていないか
- 操作が可逆か、不可逆か
- 人間または別システムの承認が必要か
- 直前までの行動系列と矛盾していないか
判定結果は、許可と拒否の二択に限らない。安全な範囲へパラメータを縮小する、機密項目を除外する、読み取り専用へ変更する、サンドボックス内で実行する、人間の承認へ回すといった処理も考えられる。
重要なのは、ワーカーAIがコントロールプレーンを迂回できないことである。
セキュリティ分野には、すべての重要なアクセスを必ず仲介する「リファレンスモニター」という古典的な考え方がある。信頼できる統制機構には、すべてのアクセスで必ず呼び出されること、外部から改変されないこと、検証可能な程度に小さく単純であることが求められる。
AIエージェントにおいても同様である。ルールをプロンプトの一部として渡すだけでは、AI自身がそのルールを解釈し、AI自身が実行可否を決めることになる。統制機構が監督対象の内部に存在しているため、これは厳密な意味での統制ではない。
ツール、API、ファイルシステム、ネットワーク、データベースなど、外部環境へ影響を与えるすべての経路を統制層に通す必要がある。
判定できるものを、AIに判定させない
この設計では、AIと決定論的システムの役割分担が重要になる。
AIは、曖昧な文章や複雑な状況を解釈することに優れている。一方で、同じ入力に対して常に同じ判断を返すことや、例外なくルールを適用することは得意ではない。
したがって、明確に形式化できる条件はAIに判断させない方がよい。
例えば、次のような条件はコードやポリシーエンジンで判定できる。
- 指定されたディレクトリ以外には書き込めない
- 外部ドメインへの通信は許可リストに限定する
- 送金額が一定額を超える場合は承認を要求する
- 顧客識別子を含むデータは外部へ送信できない
- 本番環境への変更前にはテスト成功を必須とする
- 削除操作は論理削除に限定する
- 一定回数以上失敗した場合は処理を停止する
- 読み取り権限しか持たないエージェントは更新できない
これらを自然言語でAIへ指示するのではなく、型、スキーマ、アクセス制御、状態機械、Policy as Codeなどとして実装する。
最近の研究でも、自然言語の指示を形式的なポリシーへ変換し、実行時には外部の決定論的ポリシーエンジンで操作を許可・拒否する構成が提案されている。重要なのは、AIがポリシー案の作成を支援する場合であっても、実行時の判定自体は形式化されたルールに基づく点である。
2026年に公開された事前認可に関する研究も、ツール呼び出しを実行直前に捕捉し、宣言的なポリシーに基づいて権限を判定する構造を提案している。モデルの安全学習や事後監査とは異なり、個々の操作が実行される前に止められることが中核となっている。
原則は明快である。
決定論的に判定できることを、確率的なAIに判定させない。
AIが担うべきなのは、拒否された理由の理解、代替手段の探索、曖昧な状況の整理である。最終的な権限判定ではない。
AIによる監督は、統制層を補完する
すべてのルールを形式化できるわけではない。
「ユーザーの本来の意図に反していないか」「操作が業務上妥当か」「一見無害な処理が別の情報と組み合わさることで危険にならないか」といった判断には、意味や文脈の理解が必要になる。
この領域では、別のAIを監督役として利用する価値がある。ただし、監督AIを決定論的な統制層と同一視してはならない。
OpenAIが2026年4月に公開したCodexのAuto-reviewは、サンドボックスの境界を越える操作を別のエージェントが審査し、許可または拒否する構成を採っている。タスクを完了しようとするメインエージェントと、境界を越える操作だけを評価する監督役を分離することで、評価と改善を行いやすくしている。拒否されたワーカーが、理由を手がかりに安全な代替手段を見つける場合もある。
これは、ワーカーを自由に動かしながら、境界上で別の主体が介入するという点で重要な実践例である。
しかし、OpenAI自身も、Auto-reviewは決定論的な安全保証ではないと明記している。監督AIは文脈を柔軟に解釈できる一方、誤認や見逃しも起こり得る。OpenAIはこの方式を、決定性を犠牲にして表現力を得る仕組みと位置づけている。
したがって、AIによる監督は次のように配置すべきである。
決定論的に禁止できる操作は、システムが無条件に止める。文脈によって許可の是非が変わる操作は、監督AIが評価する。損害が大きい、判断根拠が不足している、複数のルールが衝突するといった場合は、人間へ委譲する。
AIによる監督は統制の基礎ではなく、形式的なルールでは扱えない領域を埋める補完層である。
ツール呼び出しだけを監視しても不十分である
統制層を実装する際には、どの境界で操作を捕捉するかも重要になる。
多くのエージェント基盤では、AIが発行するツール呼び出しの直前にポリシーチェックを行う。しかし、ツールを経由せずに実行されるシェルコマンド、子プロセス、ネットワークアクセス、ファイル操作などが存在すれば、統制を迂回される。
2026年に発表されたActPlaneは、ツール呼び出しのレベルだけでは捕捉できない間接的な操作を問題として挙げ、OSレベルでポリシーを強制する構成を提案している。タスクの意味はエージェント側で理解しつつ、実際の強制はOS側で行うという分離である。
これは、AIエージェントの安全性をプロンプト設計の延長として捉えるべきではないことを示している。
エージェントが強い実行権限を持つほど、必要になるのはAI固有の安全技術だけではない。OSのサンドボックス、ネットワーク制御、秘密情報管理、認可、監査ログ、トランザクション、ロールバックといった、従来のコンピュータセキュリティと分散システムの技術である。
AIの能力が新しくても、実行を安全に管理する原則まで新しくする必要はない。
モニタリングは、実行統制とは別に残る
事前に操作を認可しても、すべての問題を防げるわけではない。形式上は許可された操作を組み合わせることで、想定外の結果が生じる場合がある。個々の操作は正常でも、長期的な行動系列として見ると不自然な場合もある。
そのため、実行前の統制に加えて、行動履歴の継続的なモニタリングが必要になる。
OpenAIは、社内で利用するコーディングエージェントについて、行動と推論を別のモデルで分析し、ユーザーの意図や社内ポリシーに反する可能性のある挙動を検出する仕組みを運用している。現状では完了後30分以内のレビューだが、将来的には操作前の評価へ近づける方向が示されている。
ここでも、事前認可と事後監視の役割は異なる。
事前認可は、明確に禁止された操作を実行させないための仕組みである。モニタリングは、想定していなかった行動パターンを発見し、ルールや統制システムを改善するための仕組みである。
安全なエージェント基盤では、実行前、実行中、実行後の統制が連続している必要がある。
問題は、AIの自由ではなく権限の設計にある
AIエージェントの安全性を議論すると、AIをどこまで自律的に動かすべきかという問いになりやすい。しかし、自律性という一つの軸だけで考えると、能力と危険性を同時に抑えてしまう。
本来分けるべきなのは、思考上の自律性と、実行上の権限である。
ワーカーAIには、広い情報を与え、自由に仮説を立てさせてもよい。その一方で、アクセスできるリソース、実行できる操作、変更可能な範囲、使用可能な予算は限定できる。
例えば、読み取りと提案は自律的に行わせるが、書き込みには検証を要求する。サンドボックス内では自由に試行させるが、本番環境への反映には承認を要求する。可逆な操作は許可するが、不可逆な操作は人間へ委譲する。
この構造であれば、AIの問題解決能力を保持しながら、失敗時の影響範囲を制御できる。
AI Controlの研究でも、高性能だが完全には信頼できないモデルを利用しながら、監視、編集、限定的な人間監査などのプロトコルによって危険な結果を防ぐ方法が検討されている。ここで安全性の単位となるのはモデル単体ではなく、モデルと監督手段を組み合わせた運用プロトコルである。
AIを信頼できるか否かという二択から離れ、AIに何を任せ、どこで止め、どの操作を検証するかを設計する必要がある。
アラインメントから、実行ガバナンスへ
モデル自身にルールを教えることは、今後も必要である。通常時に適切に振る舞う確率を高め、危険な操作を自発的に避けるAIの方が、運用コストは低い。
しかし、モデル内部のアラインメントは安全性の基礎条件ではあっても、最終的な保証にはならない。
AIがルールを理解していることと、ルールに反する操作を実行できないことは異なる。前者はモデルの性質であり、後者はシステムの性質である。
AIエージェント開発では、次の順序で安全性を設計すべきである。
まず、ワーカーAIに目的達成のための十分な推論能力と裁量を与える。次に、外部環境へ影響を与えるすべての操作を、迂回不能な統制層へ通す。形式化できる条件は決定論的に判定し、曖昧な部分だけを監督AIへ委ねる。重大な例外は人間へ戻す。そして、全行動を記録し、未知の逸脱を基にルールそのものを更新する。
目指すべきなのは、ルールを絶対に破らないAIではない。
ルールから外れる可能性を持ちながらも、許可されていない行動を勝手には実行できないAIシステムである。
AIの安全性を、AI自身の従順さに依存させてはならない。
推論は自由に、実行は統制下に置く。 AIを教育するだけでなく、AIが活動する境界を設計する。
AIエージェント開発の中心は、モデルの振る舞いを矯正する「アラインメント」から、モデルの能力を活かしながら行動を制御する「実行ガバナンス」へ広がっていくべきである。