本番化するAIエージェント、誰がどう監視するのか——“観測”と“制御”を両立する設計へ

今日の深掘りポイント

• 監視の主体は“職能”で決めない。ユーザー→エージェント、エージェント→ツール、エージェント→外部コンテンツという3つの境界で監督権限を分割し、制御面を設計することが肝要です。
• 規制・標準の要請は「記録できること」から「リスクに応じた行動を変えられること」へ移行しています。AI監査ログは証跡ではなく“制御面”の一部として設計します。
• 現場で先行すべきは、(1) 最小権限のツール実行とJITシークレット、(2) プロンプト/ツール呼び出しの構造化ログ、(3) ポリシー・アズ・コードのガードレール、(4) レッドチーミングの継続運用です。
• MITRE ATLAS/ATT&CKの視点を併用し、プロンプトインジェクションを“初期アクセス”とみなす思考整理が有効です。検知・抑止ポイントはツール権限、出力ハンドリング、外部接続に集中します。
• 導入の勢いは十分で、確からしさも高い一方、運用に落とし込む設計は未成熟です。監督を一部署に集約するより、アプリ運用・セキュリティ・法務の“三線”でリスク受容を明確化するのが現実的です。

はじめに

生成AIの“エージェント化”は、チャットから自律的なマルチステップ実行へと軸足を移しつつあります。AutoGenやCrewAIのようなフレームワークを使えば、プランニング、ツール呼び出し、検証、再試行を繰り返す「合議的」なエージェントが短期間で立ち上がります。この潮流は運用の重心を「モデル精度」から「エージェントの行動安全性」と「監督可能性」へとずらします。

社内の温度感としては、“使えば効率は上がるが、暴走と漏えいが怖い”に収れんしています。いま必要なのは、倫理やガバナンスの大枠を語ることではなく、観測と制御を繋ぐ具体的な設計です。本稿では、規制・標準・ナレッジベースという“足場”に寄りかかりながら、監視の主体と技術スタックをどう切り分けるかを掘り下げます。

参考になる俯瞰記事として、The New Stackは「誰がAIエージェントを監視するのか」を問い直し、エージェント時代の監視要件を整理しています。事例偏重ではなく、監視設計の論点が素直にまとまっているのがよい視点です。The New Stack: Who Monitors AI Agents? です。

深掘り詳細

事実：規制・標準・実装の現在地

• EU AI法は高リスクAIに対して運用時のイベント記録（ログ）やトレーサビリティ、リスクマネジメントを求め、一般目的AI（GPAI）にも一定規模ではリスク低減策や透明性の義務付けを進めています。制度は最終採択・告示へ進み、適用フェーズに入る見通しです。一次情報はEUの公式発表を参照すると良いです。Council of the EU – Artificial Intelligence Act（公式リリース）
• NISTはAI Risk Management Framework（AI RMF 1.0）で、Govern/Map/Measure/Manageの4機能を提示し、ログ、評価、運用制御を“リスクに応じて調整する”設計原則を示しています。これは“監視＝観測”だけでは不十分で“観測→制御”の閉ループを求める指針です。NIST AI RMF 1.0（公式）
• 攻撃ナレッジとしては、MITRE ATLASがAI/ML特有の攻撃（プロンプトインジェクション、データ汚染、モデル悪用など）を集約し、エンタープライズATT&CKと補完関係にあります。AIエージェントの実運用は、この両者を“併読”するのが適切です。MITRE ATLAS
• アプリ開発の実務寄りには、OWASP Top 10 for LLM Applicationsが、LLM01: Prompt Injection、LLM04: Insecure Output Handling、LLM06: Sensitive Information Disclosureといった失敗パターンを体系化しています。エージェントはほぼ必ず“ツール呼び出し”を伴うため、OWASPの失敗パターンはそのまま運用上の監視ポイントに写経できます。OWASP Top 10 for LLM Applications（公式）
• 実装基盤としてのAutoGenやCrewAIは、マルチエージェントのコラボレーション、ツール実行、メッセージルーティングを抽象化します。これは“観測点”を標準化するには好都合です。Microsoft AutoGen（GitHub）, CrewAI（GitHub）

インサイト：監視の主体は“境界”で決める

“誰が監視するのか”という問いは、組織図の議論に見えて、実は“どの境界で強制力を持てるか”の設計に帰着します。エージェント運用では、少なくとも次の3境界で監督権限とメトリクス、拒否権（ブロック権）を定義します。

1. ユーザー↔エージェント

• 監督者: アプリ運用＋セキュリティ（共同）
• メトリクス: 入力機密度、プロンプト分解（意図・約束・制約）、高感度タスクのHITL挿入率
• 控え所: 役割ベースのポリシー（例: 財務操作はHITL必須）、入力マスキング、セッション上限

2. エージェント↔ツール（OS/DB/SaaS/API/コード実行）

• 監督者: セキュリティ（最小権限とシークレット管理の責任主体）
• メトリクス: ツール呼び出し種類・頻度・引数逸脱率、試行→失敗→再試行のループ検知、データ境界越境率
• 控え所: JIT・スコープ限定トークン、機能ホワイトリスト、出力ハンドリングのサニタイザ、ネットワーク・エグレス制御

3. エージェント↔外部コンテンツ（Web/メール/ファイル/ユーザー生成）

• 監督者: セキュリティ（検閲器・DLP）＋アプリ運用（許可ドメイン管理）
• メトリクス: 外部コンテンツ由来の命令注入検知率、ドメイン信頼度、レスポンスの自己照合/交差検証率
• 控え所: ドメイン許可リスト、サンドボックス取得→要約→検証の多段化、モデル間クロスチェック

人の役割で“全部見ます”は現実的ではありません。境界ごとに“誰が・何を・どこまで止められるか”を合意し、メトリクスを“停止判断の根拠”に昇格させることが、運用の地平をひらきます。

ログは“証跡”ではなく“制御面”：設計の勘所

• 収集対象を“行動単位”で定義します。最低限、(a) システム/ユーザー/ツール各メッセージのハッシュと要約、(b) ポリシーバージョン、(c) ツール呼び出し（名前・引数スキーマ・スコープ・結果要約）、(d) リスク評価とガードレール判定理由、(e) セッションIDと担当者（HITL）の可逆なトレイル、を1レコードとして束ねます。
• 収集タイミングを“事後”だけにしない。ポリシー判定を非同期にせず、同期的ゲートとして設置し、判定ロジックとログを同一の“制御面”で運用します。
• プライバシー・セキュリティの基本は“見せないログ”。PII/機微は保存前に不可逆要約とトークン化、原文の短期メモリと長期保存先を分離し、WORM相当の改ざん耐性を持たせます。
• メトリクスは“安定運用”の敵にも味方にもなります。成功率だけでなく、ブロック率、再試行深度、外部コンテンツ依存度など“逸脱の前兆”をSLOに組み込みます。

脅威シナリオと影響

以下は仮説ベースのシナリオです。AI特有のパターンはMITRE ATLASの語彙で、エンタープライズ環境への落とし込みはMITRE ATT&CKの戦術・テクニックに“準拠的に”対応づけています（厳密な1対1ではありません）。

1. 間接プロンプトインジェクションでエージェント行動を乗っ取り

• 事象: エージェントが参照するWebページやドキュメントに埋め込まれた隠し命令により、機密データ要約や外部送信を実行。
• ATLAS: Prompt Injection / Model Abuse（AI特有）
• ATT&CK（例示）:
  • Command and Scripting Interpreter（T1059）—コード実行系ツールが呼ばれた場合
  • Exfiltration Over Web Service（T1567）—HTTP経由の外部送信
• 影響: 機密の要約漏えい、業務フローの無許可実行、改ざんされた意思決定

2. ツール権限の過剰付与とシークレット露出

• 事象: エージェントの環境変数やプロンプトにAPIキーが埋め込まれ、ツール呼び出しが広すぎるスコープで実行。流出したキーで継続的な不正利用。
• ATT&CK（例示）:
  • Unsecured Credentials（T1552）
  • Valid Accounts（T1078）
• 影響: 持続的アクセス、請求リスク、データ平文取得

3. プラグイン/パッケージのサプライチェーン汚染

• 事象: サードパーティのツールやパッケージ更新に悪性コードが混入し、エージェント経由で実行。
• ATT&CK（例示）: Supply Chain Compromise（T1195）
• 影響: ビルド時/実行時の侵害、改ざんのサイレント持続

4. ログとトレースからの機密再構成

• 事象: 詳細ログ（入出力の原文、ツール引数）から機微が再構成され、外部の監視/分析基盤に転送。
• ATT&CK（例示）:
  • Exfiltration Over Unencrypted/Obfuscated Channel（T1041相当の外部送信）
  • Automated Collection（T1119）
• 影響: 二次漏えい、法令違反、規制調査時の不利

これらは“モデルの安全性”だけでは防げません。制御面（権限、ガードレール、ネットワーク、ログ設計）と、プロセス面（HITL、レッドチーミング、運用責任分担）の掛け算が必要です。

セキュリティ担当者のアクション

“90日で土台を作る”現実解を提案します。特定ベンダー依存を避け、標準・設計原理に立脚します。

• 0–30日：可視化と境界の確定

  • エージェントの資産台帳を作成（モデル、システムプロンプト、ツール一覧、権限スコープ、外部接続先、データ分類）。
  • 三つの境界（ユーザー↔エージェント／エージェント↔ツール／エージェント↔外部）ごとに“ブロック権”の所在とSLOを定義。
  • ログスキーマを“行動単位”で決定（上記勘所）。保存前マスキング方針と保持期間、WORM化を設計。
  • 参考枠組み: NIST AI RMFの“Map/Measure”アクティビティを最小限で適用します。NIST AI RMF

• 31–60日：制御面の実装

  • ツール実行の最小権限化（JIT・短命トークン、機能ホワイトリスト、引数バリデーション）。
  • ガードレールを“ポリシー・アズ・コード”で実装し、同期ゲートに配置（例: 高感度データが推定されたときはHITLを必須に）。ポリシー評価の結果と根拠を必ずログ化。
  • 外部コンテンツは“取得→要約→検証→実行”の多段パターンをデフォルトにし、許可ドメイン制御とネットワーク・エグレス制限を導入。
  • 参考: ポリシーフレームワークの設計原理としてOPA（Open Policy Agent）の考え方は流用可能です。Open Policy Agent

• 61–90日：レッドチーミングと運用訓練

  • MITRE ATLAS/OWASP LLM Top 10に基づくシナリオで継続的レッドチームを走らせ、検知率・ブロック率・再試行深度をKPI化。
  • インシデント対応手順を“エージェント特化”に更新（暴走停止、セッション破棄、トークン失効、影響範囲推定、ユーザー通知、再発防止のプロンプト/ポリシー更新）。
  • 監査観点の下支えとして、EU AI法で要請されうる“運用ログのトレーサビリティ”と“リスクマネ”の証跡を棚卸し。法務と“同じ棚”を見る運用にします。EU CouncilのAI Actページ

現場の勘所として、“ログは安全装置”“権限は最小限”“外部は疑って多段化”“人の介入はコストではなく最終防波堤”という4原則を徹底するだけで、リスク曲線は大きく変わります。導入の速度感は十分です。いまは、監視を“観測”で終わらせないための制御面を、組織に馴染む粒度で先に用意する段階です。

参考情報

• The New Stack: Who Monitors AI Agents? https://thenewstack.io/who-monitors-ai-agents/
• NIST AI Risk Management Framework (AI RMF 1.0) https://www.nist.gov/itl/ai-risk-management-framework
• Council of the EU – Artificial Intelligence Act（公式リリース）https://www.consilium.europa.eu/en/press/press-releases/2024/05/21/artificial-intelligence-act-council-gives-its-final-approval/
• MITRE ATLAS https://atlas.mitre.org/
• OWASP Top 10 for LLM Applications https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Microsoft AutoGen（GitHub）https://github.com/microsoft/autogen
• CrewAI（GitHub）https://github.com/crewAIInc/crewAI
• UK NCSC: Guidelines for Secure AI System Development https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development

読者のみなさんの現場での工夫や悩みも、ぜひ教えてください。次回は“レッドチーミングを継続運用に落とす最低限の台帳とスクリプト群”を取り上げる予定です。気持ちよく、でも確かに安全に、エージェントを走らせていきます。