AIエージェントの監視には実行時介入が必要です

2026年5月15日、Parand A. Alamdari、Toryn Q. Klassen、Sheila A. McIlraithは、AIガバナンスにはオフライン監査、オンラインの実行時監視、そして予測された違反が実際に起きる前に介入できる監視機構が必要だと主張する論文を発表しました。¹

最後の「介入できる」という点が重要です。

失敗を記録するだけの監視は、事後検証には役立ちます。しかし、エージェントを一時停止し、ブロックし、封じ込め、あるいは別の方向へ導ける監視は、結果がまだ確定していないうちに実行そのものを変えます。

AIエージェントの監視には、実行時介入が必要です。 ログ、トレース、ダッシュボード、承認記録は、チームに証拠を与えます。実行時介入は、その証拠を、エージェントがまだ危険な行動を避けられる段階での判断へ変えるのです。

要約

AIエージェントの監視は、事後鑑識のように振る舞うと失敗します。本格的なエージェント実行基盤なら、進行中の軌跡を監視し、ポリシー違反や決定的な誤りを検知し、範囲を限定した介入を選べるべきです。続行、警告、一時停止、ブロック、封じ込め、復旧、エスカレーションといった判断です。

最近の研究も、複数の角度から同じ方向を示しています。形式手法の研究は、時相論理を実行時監視と介入型の監視機構に適用しています。¹ AgentForesightは、軌跡が終わる前のオンライン監査として失敗検知を位置づけています。² AgentTrustは、危険なツール呼び出しを実行前に捕捉し、構造化された判定を返します。³ AIRは、インシデント対応をエージェントのループ内に置き、システムが検知、封じ込め、復旧を行い、将来のガードレールを合成できるようにします。⁴

実務上の教訓は明確です。可観測性で止めてはいけません。観測結果に基づいて行動できる実行基盤を作る必要があります。

重要なポイント

エージェントプラットフォームチーム向け: - 監視をダッシュボードではなく、制御ループとして扱いましょう。 - エージェントが高リスクなツールに触れる前に、介入アクションを定義してください。

セキュリティチーム向け: - 事後レビューから、コミットポイントでのオンライン検知へ移行しましょう。 - すべての介入について、ルール、証拠、判断、結果を記録してください。

プロダクトチーム向け: - 介入イベントは、構造化されたレビュー対象として表示しましょう。 - なぜ実行が止まったのか、どの証拠が停止を引き起こしたのか、どの安全な選択肢が残っているのかをユーザーに見せてください。

運用担当者向け: - 後から被害を説明するだけのトレースより、挙動を変えられるトレースを信頼しましょう。 - 監視機構に問うべきなのは、前の失敗を再構成できるかだけではありません。次の悪い一手を止められるかです。

なぜAIエージェントの監視は遅すぎるのでしょうか？

多くの監視は、エージェントがすでに行動した後に始まります。

ログを見れば、エージェントがシェルコマンドを実行したことは分かります。トレースを見れば、Webページを取得した、MCPサーバーを呼び出した、ファイルを書いた、承認を求めた、といったことも分かります。ダッシュボードは、ネットワークポリシーがドメインをブロックしたことを示せます。これらの記録は重要です。しかし、それだけでは次の行動は自動的には変わりません。

OpenAIのCodex安全性記事は、適切な証拠基盤を説明しています。境界づけられた実行、管理された設定、ネットワークポリシー、承認、エージェントに直接対応したテレメトリです。Codexは、ユーザープロンプト、ツール承認判断、ツール実行結果、MCPサーバー利用、ネットワークプロキシの許可・拒否イベントをOpenTelemetryイベントとしてエクスポートできます。⁵ OpenAIはまた、Codexログをセキュリティトリアージ用エージェントと組み合わせ、疑わしいエンドポイントのアラート周辺にある元の依頼、ツール活動、承認、ツール結果、ネットワークポリシー判断をレビュー担当者が確認できるようにする方法も説明しています。⁵

この可視性は重要です。問題は、可視性に行動を変える仕組みがないときに生じます。

監視機構が、エージェントが信頼できないコンテンツを読んだ後、新しい外部ドメインへデータを送ろうとしていることを検知したなら、その一連の流れを記録するだけでは不十分です。実行を一時停止するか、リクエストをブロックすべきです。コーディングエージェントが失敗したマイグレーションを3回リトライし、その後さらに広範で破壊的なコマンドを提案したなら、実行基盤は最終レビューまで待つべきではありません。進行中の軌跡を中断すべきです。

AIエージェントの監視は、2つの問いに同時に答える必要があります。

2つ目の問いが、監視を介入へ変えます。

新しい実行時研究は何を加えたのでしょうか？

新しい研究群は、この分野により明確な語彙を与えています。

形式手法の論文は、時間的に拡張された行動制約に焦点を当てています。孤立したイベントだけでなく、順序、距離、並びに意味があるルールです。著者らは、LLMを含むブラックボックスAIシステムのオフライン監査とオンライン監視のために、形式手法と機械学習を組み合わせています。¹ さらに、実行時に予測された違反を先回りして防ぐ、または軽減する、予測型および介入型の監視機構も導入しています。¹

AgentForesightは、エージェントの文脈で失敗パターンに名前を与えています。この論文によると、長期視野のマルチエージェントシステムでは、1つの決定的な誤りを受け入れた後、軌跡全体の失敗へ連鎖することがあります。² AgentForesightは、軌跡が終わった後に責任のあるステップを診断するのではなく、オンライン監査担当に現在の接頭辞だけを確認させ、続行するか、最初の決定的な誤りで警報を出すかを判断させます。²

AgentTrustは、ツール呼び出しの境界で動作します。エージェントのツール呼び出しを実行前に捕捉し、allow、warn、block、reviewという構造化された判定を返します。³ この形が重要なのは、ファイル操作、シェルコマンド、HTTPリクエスト、データベースクエリが現実の副作用を生むからです。³

AIRは、インシデント対応の層を追加します。この論文は、エージェント安全性の取り組みが、事前に失敗を防ぐことへ偏りがちで、インシデント発生後に対応、封じ込め、復旧する能力が限られていると指摘しています。⁴ AIRは、インシデント対応をエージェント実行ループに組み込みます。インシデントを検知し、封じ込めと復旧の行動を導き、将来の実行に向けたガードレールルールを合成します。⁴

まとめると、これらの論文は重心を次のように移しています。

この変化は、現実のエージェント作業に合っています。副作用は最終回答ではなく、実行中に起きるからです。

実行時介入とは何でしょうか？

実行時介入とは、ライブ証拠がポリシー、安全性、品質、リスクのしきい値を超えたために、システムが行う範囲限定の行動です。

介入は、パニックより狭く、ログ記録より強いものであるべきです。

良い介入は、モデルを叱りません。実行状態を変えます。

介入は、構造化された記録を生むべきです。

別のレビュー担当者がイベントを確認し、なぜ実行基盤が進路を変えたのかを理解できるとき、監視機構は信頼を得ます。

なぜ時間的制約が重要なのでしょうか？

多くのエージェント失敗は、順序に依存します。

「テストなしで公開してはいけない」は、1つのコマンドの性質ではありません。公開アクションと、その前に存在する証拠との関係です。「信頼できないコンテンツを読んだ後に外部ネットワーク通信を送ってはいけない」は、順序に依存します。「失敗したマイグレーションの後に本番へ書き込んではいけない」は、前の失敗状態に依存します。「ソース検証が失敗した後にデプロイを承認してはいけない」は、承認イベントと検証イベントの両方に依存します。

Linear Temporal Logicは、before、after、until、eventually、neverといった時間上の制約を表現する手段を研究者に与えます。5月15日の形式手法論文は、LTLベースの監査・監視技術が、時間的に拡張された行動制約の違反検知において、LLMのベースライン手法を上回ったと報告しています。¹ 著者らはまた、この手法では小規模モデルのラベラーでさえ最先端のLLMジャッジと同等またはそれ以上の結果を示し、イベント間の距離、制約数、命題数が増えるにつれてLLMの時間的推論が劣化したとも報告しています。¹

とはいえ、本番運用上の教訓は、すべてのチームが明日から完全な形式手法スタックを出荷しなければならない、というものではありません。

より直接的な教訓はシンプルです。順序を理解するルールを書きましょう。

これらの制約は、次のステップを判断できるだけの履歴を実行基盤に記憶させます。状態を持たないプロンプトだけでは、これを安定して行うことはできません。

実行時監視はどこに置くべきでしょうか？

実行時監視は、コミットポイントに置くべきです。

コミットポイントとは、エージェントが可逆的な分析から外部への効果へ踏み出す瞬間です。ファイル変更、データベース書き込み、ネットワーク送信、デプロイ、メッセージ送信、権限変更、支払い、削除、公開リリースなどが該当します。

OpenAIのCodex cloudドキュメントは、具体的な境界を1つ示しています。Codexはデフォルトでエージェントフェーズ中のインターネットアクセスをブロックしますが、セットアップスクリプトは依存関係取得のためにインターネットアクセスを使えます。⁶ 同じドキュメントは、エージェントのインターネットアクセスを有効にすると、信頼できないWebコンテンツからのプロンプトインジェクション、コードや秘密情報の流出、マルウェアまたは脆弱な依存関係、ライセンス制限付きコンテンツなどのリスクが増えると警告しています。⁶ また、ドメインとHTTPメソッドの制限も推奨しており、GET、HEAD、OPTIONSにリクエストを限定すると追加の保護になるとしています。⁶

このポリシーの形は、ネットワークアクセス以外にも広げるべきです。

すべてのトークンを監視しても、注意力を浪費するだけです。コミットポイントを監視すれば、失敗がトランスクリプトの外へ出ていく箇所を守れます。

エージェントは介入をどう受け取るべきでしょうか？

エージェントには、曖昧な叱責ではなく、正確な状態更新を返すべきです。

弱い応答:

注意してください。安全でない可能性があります。

より良い応答:

ブロック: 信頼できないコンテンツを読んだ後の外部POSTです。次に許可される行動: リスクを要約する、対象ドメインとペイロード種別を含めてオペレーター承認を依頼する、またはネットワーク送信なしで続行する。

2つ目の応答は、エージェントに安全な計画空間を与えます。何が発火したのか、なぜその行動を実行できないのか、どの代替策が残っているのかを示しています。AgentTrustの判定形式も、この方向を示しています。リスクのあるコマンドに対して、allow、warn、block、reviewと、より安全な代替案を返す形です。³

実行時介入は、危険を残さず、主体性を残すべきです。

エージェントはまだタスクを修復できます。承認を依頼できます。ツールを変えられます。作業を読み取り専用の経路に分割できます。証拠パケットを作れます。実行基盤が取り除くのは、現在のポリシー状態に違反する行動だけです。

人間には何を見せるべきでしょうか？

人間には、謎の停止ではなく、介入カードを見せるべきです。

このカードは、承認キュー、トレースタイムライン、レビューパケットと同じプロダクトファミリーに属します。違いはタイミングです。承認は、計画された行動を進めてよいかを尋ねます。実行時介入は、監視機構がライブのパターンを見て、次に許可されるステップを変えたと伝えます。

良いインターフェースは、停止の理由を理解するためにユーザーへ全トランスクリプトの読解を強いるべきではありません。カードは、重要なトレース断片を指し示すべきです。

チームは最初に何を作るべきでしょうか？

価値の高いコミットポイントに、シンプルな監視ルールを置くところから始めましょう。

1. コミットポイントを定義する。 ミスがローカルの作業回を離れて外へ出るツール呼び出しとリソースに名前を付けます。
2. 型付きイベントストリームを作る。 ツール、引数、対象、結果、関連する先行イベント、実行状態を記録します。
3. 順序を理解するルールを書く。 test-before-deploy、review-before-egress、approval-before-writeなど、繰り返し重要になる順序関係から始めます。
4. 狭い介入を追加する。 広範なシャットダウンより、一時停止、ブロック、封じ込めを優先します。
5. 構造化された判定を返す。 何が発火したのか、どの行動がまだ許可されているのかをエージェントに伝えます。
6. 介入カードを表示する。 人間にルール、証拠、リスク、次の選択肢を提示します。
7. 結果をレビューする。 真陽性を昇格し、偽陽性を調整し、ノイズの多いルールを廃止します。

最初のバージョンは地味で構いません。ツール境界に置いた少数の決定論的ルールは、あらゆる文を見張る広範なモデルジャッジより有効なことがよくあります。

より深いバージョンでは、予測型監視、LTL制約、学習済み監査担当、インシデント対応ループを追加できます。ただし、それらの層は、イベントストリームと介入セマンティクスが機能してから構築しましょう。

ふさわしい基準

すべての一時停止が深刻そうに見え、すべての警告が同じ重みを持つなら、実行時介入は形だけの儀式になってしまいます。

基準は狭く保つべきです。

• 次の行動が重要な場面でだけ介入する。
• 発火したルールに名前を付ける。
• 証拠を見せる。
• 安全な次の経路を残す。
• 結果を記録する。
• 損害を防がずノイズだけを生むルールは取り除く。

良い監視は、作業を守ります。悪い監視は、ベンダーの責任回避の物語だけを守ります。

エージェント実行基盤が最大化すべきなのは、動きの多さではありません。説明責任のある前進です。ときには、エージェントを止めずに続行させることが、説明責任のある前進になります。ときには、次のステップを拒むことがそうなります。

品質の基準は、その違いを見極められるかにあります。

簡単なまとめ

AIエージェントの失敗は最後だけでなく、軌跡の途中で起きます。だからこそ、AIエージェントの監視には実行時介入が必要です。ログとトレースは、何が起きたかを説明します。介入型の監視機構は、次に何が起きるかを変えられます。

現在の研究の方向性は明確です。形式的な時間制約、オンライン監査担当、ツール呼び出し判定、インシデント対応ループは、いずれも監視を能動的な制御へ向かわせています。チームは、型付きイベントストリーム、コミットポイントルール、構造化された判定、介入カード、結果レビューから始めるべきです。目的はアラートを増やすことではありません。取り返しのつかないミスを減らすことです。

FAQ

AIエージェントにおける実行時介入とは何ですか？

実行時介入とは、ライブ証拠がポリシー、リスク、安全性、品質のしきい値を超えたために、システムが進行中のエージェント実行を変えることです。介入には、続行、警告、一時停止、ブロック、封じ込め、復旧、エスカレーションがあります。

実行時介入は可観測性とどう違いますか？

可観測性は、何が起きたかを記録します。実行時介入は、実行がまだ進行中の間に行動します。1つのトレースが両方を支えることはできますが、介入にはポリシー判断と、次に許可される行動が必要です。

すべてのエージェント行動を監視機構に通すべきですか？

意味のあるツール行動はすべて、型付きイベントを生成すべきです。ただし、中断ルールが必要なのは価値の高いコミットポイントだけです。読み取り専用イベントは、通常は静かにログへ残せば十分です。副作用のあるイベントには、より厳格な監視が必要です。

始めるために形式手法は必要ですか？

いいえ。チームは決定論的な順序ルールから始められます。テスト前のデプロイ禁止、信頼できない取得後の外部書き込み禁止、修復失敗が続いた後の破壊的コマンド禁止、必須証拠なしの最終完了禁止などです。形式手法が役立つのは、ルールセットが増え、時間的な関係を手作業で確認するのが難しくなってからです。

信頼できる実行時介入とは何ですか？

信頼できる介入は、ルールに名前を付け、証拠を示し、次の行動を制限し、結果を記録し、権限を持つ人間にレビュー経路を与えます。曖昧な警告は、介入とは言えません。

参考文献