見えないエージェント：見えないものはガバナンスできない

AnthropicはClaude DesktopにCoworkという機能をリリースしました。この機能は、すべてのmacOSインストール環境に10GBの仮想マシンバンドルを作成します。Coworkを有効にしていないユーザーにもVMが配置されました。削除しても再生成されました。あるユーザーはバンドルが21GBまで膨張したと報告しています。Anthropicが問題を認めるまでに、GitHubのイシューはHacker Newsで345ポイントと175件のコメントを集めました。¹

ディスク容量が不足するまで、誰も気づきませんでした。

TL;DR

エージェントツールは現在、オペレーターの可視性なしにコンピューティングリソース（ディスク、メモリ、CPU、ネットワーク）を割り当てています。AnthropicのCowork VMは目に見える事例ですが、すべてのMCPツールコール、すべてのサブエージェントの生成、すべてのWebフェッチは目に見えない事例です。エージェントをガバナンスするには、3層の可観測性が必要です。リソース計測（何を消費したか？）、ポリシー適用（何が許可されていたか？）、ランタイム監査（実際に何をしたか？）です。ポリシー層と監査層に対応する2つのオープンソースプロジェクト（mcp-firewallとLogira）がありますが、3層すべてをカバーするプロダクションツールは存在しません。以下では、可視性の問題、3層スタック、各層が検出するもの、そして今日から実装できる最小限の監視フックについて解説します。

可視性の問題

従来のソフトウェアは、オペレーターが引くことを選んだ可観測性のラインの下で動作します。Webサーバーがアクセスログを書き込むのは、エンジニアがロギングを設定したからです。データベースがスロークエリを追跡するのは、誰かがlog_min_duration_statementを設定したからです。粒度を決めるのはオペレーターです。

エージェントシステムはこの関係を逆転させます。実行時に何を実行するかを決めるのはエージェントです。「ログインエンドポイントを修正して」と指示を受けたコーディングエージェントは、47個のファイルを読み、12個に書き込み、3つのサブエージェントを生成し、2つのWebページをフェッチし、15個のbashコマンドを実行するかもしれません。各アクションはリソースを消費します。しかし、その消費は従来の監視には一切表示されません。

Coworkインシデントは、インフラストラクチャレベルでこの逆転を露呈させました。Claude Desktopは10GBのディスク容量を割り当て、アイドル時にCPUを24〜55%消費し、8GBマシンではスワップ使用量を20Kから24K以上のスワップインに押し上げました。¹ ユーザーがリソース消費を発見したのは、Anthropicのテレメトリではなく、macOSのストレージ警告によってでした。アプリケーションはVM割り当てに対するダッシュボードも、メーターも、オプトイン開示も提供していませんでした。

このパターンをエージェントセッションに拡大してみましょう。私のフックオーケストレーションシステムは、すべてのツールコールにわたって15種類のイベントをインターセプトします。¹¹ 60以上のセッションで、システムは各アクションにつき84個のフックが発火するのを記録し、デフォルトのエージェントインストールでは得られないテレメトリを生成しました。² その計装なしには、12件のドリフトインシデント、ファントム検証の失敗、NISTへのパブリックコメントで文書化した再帰的スポーニングループを検出できなかったでしょう。³

DORA 2024 Accelerate State of DevOps Reportは、強力な可観測性プラクティスを持つチームがより頻繁にデプロイし、障害からより早く回復することを明らかにしました。2025年版はこのフレームワークをAI支援開発に拡張し、可観測性と「AIによるコーディングやテストの支援が品質、リードタイム、全体的な信頼性にどう影響するか」を結び付けています。⁴ エージェントの可観測性はあれば良いものではありません。エージェントの振る舞いを計測することは、それをガバナンスするための前提条件です。

エージェント可視性の3層

エージェントの可観測性には、3つの独立した層が必要です。各層は異なる問いに答えます。1つの層の障害が他の層を損なうことはありません。

これらの層は段階的な構造に対応しています。計測していないリソースにポリシーを適用することはできず、定義していないポリシーへの準拠を監査することもできません。各層はその下の層の上に構築されています。

第1層：リソース計測

リソース計測は次の問いに答えます。エージェントはどれだけ消費し、どこで消費したのか？

Coworkインシデントはリソース計測の失敗です。VMバンドルは10GBのディスク容量を消費しました。レンダラープロセスはアイドル時にCPUを24%消費しました。セッション中、スワップアクティビティは着実に上昇しました。これらの指標はすべてmacOSのアクティビティモニタに存在していました。Claude Desktopのインターフェースには一切表示されていませんでした。¹

エージェントのコーディングセッションでは、リソース計測は4つの次元を追跡します。

ディスク。 すべてのファイル書き込み、すべてのキャッシュエントリ、すべてのログファイルです。私のセッションでは、セッションごとに200〜400KBの状態ファイル（jiro.state.json、jiro.progress.json、フックログ）が生成されます。60セッションにわたると、明示的にクリーンアップしない限り、セッション間で永続する12〜24MBの状態データが蓄積されます。²

メモリ。 ターンごとのコンテキストウィンドウ消費量です。200,000トークンのコンテキストウィンドウは、現在のOpus価格でフル使用すると約3ドルのコストがかかります。私のコストトラッカーは、設定可能な上限の80%、90%、95%のしきい値で、セッションごとの累計トークン使用量を記録します。⁵

CPU。 フック実行時間です。私の9フックプロンプトディスパッチャーは、プロンプトごとに200msを追加します。このオーバーヘッドはユーザーには見えません（人間のタイピングがボトルネックです）が、自動化パイプラインでは累積します。ralphの自律ループは、ストーリーごとにディスパッチャーを50〜100回発火し、ストーリーあたり10〜20秒のフックオーバーヘッドを追加します。²

ネットワーク。 Webフェッチ、APIコール、MCPツール呼び出しです。すべてのアウトバウンドリクエストは潜在的なデータチャネルです。私のWeb抽出ライブラリは、フェッチURLとレスポンスサイズを記録します。ネットワーク計測なしでは、50MBのレスポンスを返すWebフェッチと5KBを返すものの区別がつきません。⁶

商用エージェントツールで、セッションごとのリソースダッシュボードを提供するものはありません。クラウドプロバイダーはコンピューティングを課金のために計測しますが、オペレーターの可視性のためではありません。エージェントが消費するものとオペレーターが見えるものの間のギャップが、リソース計測の欠損です。

この不在は数字が蓄積するまで見えません。400KBの状態ファイルを書き込む1つのセッションは何でもありません。400KBずつ書き込む60セッションが、クリーンアップなしに放置されると、24MBの孤立した状態データが残ります。847KBを返す1つのWebフェッチは無視できます。実行ごとに80のURLをフェッチするスキャニングパイプラインは、エージェントのツール抽象化がオペレーターから隠す67MBのキャッシュコンテンツを生成します。リソース計測は、蓄積がGitHubのイシュー#22543を誰かに起票させる危機になる前に、累積を可視化します。¹

第2層：ポリシー適用

ポリシー適用は次の問いに答えます。エージェントを制約するルールは何か、そしてそれらのルールは一貫して適用されているか？

mcp-firewallは、CLIエージェントのポリシー層に対応します。⁷ このツールはエージェントとすべてのツール使用リクエストの間に位置し、実行前に各リクエストを正規表現ベースのポリシーに照合して評価します。ポリシーは、フォルダー、gitリポジトリ、またはユーザーごとにスコープされたJSONNet設定ファイルを使用します。ファイアウォールは、PreToolUseフック統合を通じてClaude CodeとGitHub Copilot CLIをサポートします。

このアーキテクチャは重要な洞察を反映しています。すべてのエージェントが、許可/拒否ロジックの独自の中途半端なソリューションを実装しているということです。Claude Codeはglobパターンを使用します。Codex CLIはプレフィックスのみのマッチングを使用します。各アプローチはポリシー空間のサブセットをカバーします。mcp-firewallは、エージェント間で機能する1つのエンジンにルールを集約します。

集中的な適用なしのポリシーギャップを考えてみましょう。私のフックシステムには、資格情報パターン、危険なgit操作、機密パスアクセス、デプロイメントコマンドをチェックする12個のPreToolUse:Bashハンドラーが含まれています。² 各ハンドラーは独自の正規表現パターンを持つ個別のシェルスクリプトです。新しい拒否ルールを追加する必要がある場合、新しいスクリプトを作成します。どのルールが存在するかを監査する必要がある場合、12個のファイルにわたってgrepします。mcp-firewallは、明示的な許可配列を持つ単一の設定ファイルにこれを統合します。

OWASP Top 10 for Agentic Applications（2025）は、Agent Goal Hijacking（ASI01）とExcessive Agency（LLM06:2025）をトップリスクとして特定しています。⁸ どちらのリスクもツールコールレベルでのポリシー適用が必要です。ゴールをハイジャックするエージェントも依然としてツールコールを行います。過剰な権限を持つエージェントも依然として権限を要求します。ポリシー適用は、エージェントの意図がシステムのツールと出会う境界で両方をインターセプトします。

ポリシー適用はアクセス制御とは異なります。従来のアクセス制御は「このユーザーに権限があるか？」と問います。エージェントに対するポリシー適用は「このアクション、このコンテキスト、このタスクにおいて、承認されたスコープ内にあるか？」と問います。コンテキストの感度が課題です。フィーチャーブランチへのgit pushとmainへのgit push --forceは同じツール（Bash）ですが、影響範囲が異なります。mcp-firewallの正規表現パターンは両者を区別できます。デフォルトのエージェント権限では区別できません。

第3層：ランタイム監査

ランタイム監査は次の問いに答えます。エージェントはシステムコールレベルで実際に何をしたか？

Logiraは、カーネルレベルでシステムコールをインターセプトするeBPFプローブを使用して監査層に対応します。⁹ このツールは3つのイベントカテゴリを記録します。プロセス実行（execイベント）、ファイル操作（資格情報ファイルアクセスを含む）、ネットワーク接続（宛先追跡付き）です。各監査実行で3つのファイルが生成されます。タイムラインレビュー用のevents.jsonl、クエリ可能なフィルタリング用のindex.sqlite、実行メタデータ用のmeta.jsonです。

設計哲学は「観察のみ」です。Logiraは記録と検出を行いますが、適用やブロックは行いません。⁹ 適用層との分離は意図的です。ポリシー適用は既知の悪いアクションを防止します。ランタイム監査は事後に未知の悪いアクションを発見します。2つの層は異なる時間的機能を果たします。防止（事前）とフォレンジクス（事後）です。

LogiraのeBPFプローブはアプリケーション層より下で動作します。データを窃取するための新たなコマンドを構築するエージェントも、依然としてシステムコールを発行します。エージェントはカーネルレベルのトレーシングからファイル読み取り、ネットワーク接続、プロセス生成を隠すことができません。このアプローチは、アプリケーションレベルのフックが見逃すもの、つまりツールコール抽象化をバイパスする副作用を捕捉します。

組み込みの検出ルールは、AIエージェントのリスクを具体的に対象としています。資格情報ファイルアクセス、永続化メカニズムの変更（/etc、systemd、cron）、疑わしいコマンドチェーン（curl-pipe-shパターン）、破壊的操作（rm -rf）、異常なネットワークエグレスです。⁹ これらのルールは汎用的なシステム監査ではなく、エージェント脅威モデルのためのデフォルト設定です。

プラットフォームの制約は重要です。LogiraはLinux 5.8以上とcgroup v2を必要とします。macOSエージェント（Claude Desktop、Darwin上のClaude Code）はeBPFベースの監査を使用できません。私のOSサンドボックスは、最も近い代替手段としてmacOS Seatbeltプロファイルを使用しています。これは機密パスへの書き込みをブロックするカーネルレベルの拒否ルールです。³ Seatbeltは適用であり、監査ではありません。macOSにはLogiraの観察のみの監査証跡に相当するプロダクション対応のツールがありません。

適用と監査の区別は、インシデントレスポンスにおける時間的な分離に対応します。適用はインシデントを防止します。監査はインシデント後の再構築を可能にします。両方が必要です。すべての資格情報アクセスをブロックする適用層は窃取を防止しますが、正当なSSH操作も防止します。すべての資格情報アクセスをブロックせずに記録する監査層は、オペレーターがアクセスパターンをレビューし、証拠に基づいて適用ルールを調整できるようにします。監査データとポリシー改善のフィードバックループこそが、可視性スタックが時間とともに改善される仕組みです。監査がパターンを明らかにし、パターンがポリシーに反映され、ポリシーが監査でカバーすべき表面を縮小します。

Logiraのcgroup v2分離は、アプリケーションレベルの監査では再現できない機能を追加します。実行スコープの帰属です。システムはすべてのイベントを、システム全体ではなく、特定の監査実行に帰属させます。2つのエージェントセッションが同じマシン上で同時に実行されている場合、cgroup分離により、セッションAのファイルアクセスがセッションBの監査証跡に表示されないことが保証されます。アプリケーションレベルのフックは同じ保証を提供できません。なぜなら、フックはエージェントプロセス内で発火し、同時セッションを分離するカーネルレベルの境界を持たないからです。⁹

実際に運用しているもの

私のオーケストレーションシステムは、専用の監視ツールではなく、フックを通じて3層すべてをカバーしています。

リソース計測。 cost-gateフックは、設定可能な予算しきい値に対してセッションごとのトークン使用量を追跡します。⁵ システムパフォーマンスモニターは、設定可能な間隔でCPU、メモリ、ディスク、スワップをチェックし、リソース圧力がしきい値を超えると警告を注入します。¹⁰ セッションドリフト検出器は25回のツールコールごとに発火し、元のプロンプトのエンベディングと最近のアクションのスライディングウィンドウ間のコサイン類似度を計算します。²

ポリシー適用。 8つのPreToolUseディスパッチャーフックが、ツールタイプごとにハンドラーフックにルーティングします。PreToolUse:Bashだけで、資格情報パターン、破壊的なgit操作、機密パスアクセス、デプロイメントコマンドをカバーする12個のハンドラーを実行します。再帰ガードは最大深度2と、親エージェントあたり最大5つの子エージェントを適用します。²

ランタイム監査。 PostToolUseフックがすべてのツールコール結果を記録します。セキュリティスキャニングフックは、実行後にbash出力の資格情報リークをチェックします。セッション状態ファイル（jiro.state.json）は、すべてのストーリー完了、レビュアーの判定、証拠ゲートの結果を記録します。² システムはeBPFを使用しません（macOSの制約）が、フックパイプラインを通じてツールレベルのテレメトリを捕捉します。

このシステムが機能するのは、すべてのアクションがフックパイプラインを通過するからです。制限は深度です。フックレベルの監視は、エージェントが何をしようとしたかを捕捉しますが、OSが実際に何を実行したかは捕捉しません。埋め込みサブシェルを持つbashコマンドを構築するエージェントは、フックからは単一の文字列として見えるコードを実行します。カーネルレベルの監査であれば、各サブプロセスが見えるでしょう。

複合するブラインドスポット

エージェントがエージェントを生成すると、不透明性が倍増します。各委任ホップが情報の損失をもたらします。

私のオーケストレーションシステムがralphの自律ループを実行する際、親プロセスは各PRDストーリーのために新しいClaude Codeインスタンスを生成します。各子エージェントは焦点を絞ったタスクと新しいコンテキストウィンドウを受け取ります。親は完了状態を追跡します。親は子の個々のツールコール、ファイル読み取り、リソース消費を見ることはできません。²

深度1（親が子を生成）では、親は子の最終出力を見ます。深度2（子が孫を生成）では、親は孫の出力についての子のレポートを見ます。各ホップが情報を圧縮します。NISTコメントの委任チェーン分析では、3つの複合リスクを測定しました。意味的圧縮（コンテキストがプロンプト文字列に圧縮される）、権限増幅（子が感度を理解せずに権限を継承する）、説明責任の拡散（ルートエージェントが自ら検査しなかった結果に対して責任を負う）です。³

可観測性は同じ速度で劣化します。ルートエージェント上の3層可視性スタックは、各子が独立して自身の監視を実行しない限り、孫エージェントに対する可視性はゼロです。私の再帰ガードは深度制限を適用しますが、ガードはポリシー制御であり、可観測性制御ではありません。委任が深度2で停止したことを知っても、深度2で何が起きたかはわかりません。

私の本番システムからの具体例です。ralphループがデータベースマイグレーションストーリーを実装するために子エージェントを生成しました。子エージェントはマイグレーションに「検証ステップ」が必要だと判断し、統合テストを実行するために独自のサブエージェントを生成しました。孫エージェントはサイレントに失敗しました（テストデータベースが設定されていませんでした）。子エージェントは空のレスポンスを受け取り、沈黙を成功と解釈し、ストーリー完了を報告しました。親は「story 4: complete」と記録しました。壊れたマイグレーションを発見したのは3時間後、カラムの欠落でアプリケーションがクラッシュした時でした。ルートエージェントのテレメトリはクリーンな実行を示していました。障害は2ホップの深さに存在し、ルートにデプロイしたすべての監視層から見えませんでした。²

OWASP Agentic Applicationsフレームワークはカスケード障害とローグエージェントを扱っていますが、マルチエージェント委任チェーンの可観測性要件は規定していません。⁸ このギャップは構造的です。チェーン内の各エージェントが独自のリソース計測、ポリシー適用、ランタイム監査を、独立して設定し、独立して報告する必要があります。オーバーヘッドは乗算的です。チェーン内の3つのエージェントに対する3層の監視は9つの監視インスタンスとなり、それぞれが独自のテレメトリを生成し、それぞれが独自の設定を必要とします。その調整を管理する既存のツールはありません。

今日から実装できること

可視性スタックをカバーする3つの最小限の監視フックです。

1. リソース：トークン予算トラッカー。 セッションごとの累計入出力トークンを記録します。ハードリミットを設定します。80%でアラートを出します。実装には、エージェントの使用統計の読み取り（Claude Codeは/costでセッションコストを公開）としきい値との比較が必要です。私のcost-gateフックは47行のbashでこれを実現しています。⁵

2. ポリシー：PreToolUse拒否リスト。 すべてのBashツールコールの前に発火するフックを作成します。コマンドをパターンリストと照合します。rm -rf /、git push --force、.sshや.envを含むパス、curl | shなどです。一致するものをブロックします。実装には、stdin（ツールコールJSON）を読み取り、コマンドフィールドを抽出し、パターンファイルに対してgrepする1つのシェルスクリプトが必要です。私の資格情報チェックフックは31行でこれを実現しています。²

3. 監査：PostToolUseセッションログ。 すべてのツールコールと結果をセッション固有のJSONLファイルに追記します。タイムスタンプ、ツール名、引数、終了コードを含めます。ログにより、セッション後の再構築が可能になります。エージェントが何をしたか、どの順序で、サイレントに失敗したものはあったか？ 私のセッションロガーは22行のbashでこれを実現しています。²

settings.jsonでの拒否リストフックの実装例です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

フックスクリプトはstdinからツールコールを読み取り、コマンド文字列を抽出し、パターンと照合します。ブロックされたコマンドは{"decision": "block", "reason": "Sensitive path access denied"}というJSONオブジェクトを返します。許可されたコマンドは{"decision": "approve"}を返します。Claude Codeはどちらのレスポンスも追加のプロンプトなしに尊重します。フック全体で、許可されたコマンドにはゼロレイテンシを追加し（正規表現チェックは5ms未満で実行）、ブロックされたコマンドには即座にフィードバックを提供します。

これら3つのフックの合計は100行未満です。専用の監視ツールを置き換えるものではありません。ゼロの可視性を最小限の可視性に置き換えるものです。最小限の可視性は、それに続くすべてのガバナンス判断の前提条件です。計測なしにリソース予算を設定することはできません。拒否リストなしにスコープポリシーを適用することはできません。監査ログなしにインシデントを調査することはできません。まずログから始めましょう。残りの2つはそこから続きます。

重要なポイント

プラットフォームエンジニアへ： エージェントは既存の監視が追跡しないリソースを消費します。エージェントセッションごとのディスク、メモリ、CPU、ネットワーク使用量は、コンテナメトリクスと同じダッシュボードに表示されるべきです。Coworkインシデントがその必要性を証明しています。10GBがオペレーターの可視性ゼロで割り当てられました。

セキュリティチームへ： ツールコール境界でのポリシー適用は、最小限のエージェントセキュリティ態勢です。mcp-firewallの集中的アプローチは、エージェントごとの許可/拒否ロジックを1つの監査可能な設定に統合します。エージェントの組み込み権限が、脅威モデルが要求するポリシー空間をカバーしているか評価してください。

エンジニアリングマネージャーへ： エージェントツールについて3つの質問をしてください。セッションごとのリソース消費を見ることができますか？ ツールコールポリシーを定義し監査できますか？ エージェントが事後に何をしたかを再構築できますか？ いずれかの答えが「いいえ」であれば、ワークフロー内のエージェントが増えるたびに拡大する可視性ギャップがあります。

FAQ

エージェントの可観測性とは何ですか？ エージェントの可観測性とは、AIエージェントが実行中に何をするかを監視し理解する能力です。どのリソースを消費するか、どのアクションを取るか、それらのアクションが定義されたポリシーに準拠しているかを含みます。

なぜAnthropicのCoworkは10GBのVMを作成したのですか？ Claude DesktopのCowork機能は、共同開発セッション用の仮想マシンをプロビジョニングします。Claude Desktopは、機能を有効にしていないユーザーも含め、すべてのmacOSインストール環境にVMバンドルを自動的に作成し、手動で削除するまで保持します。¹

mcp-firewallとは何ですか？ mcp-firewallは、CLIエージェント（Claude Code、GitHub Copilot CLI）からのツール使用リクエストをインターセプトし、実行前に正規表現ベースの許可/拒否ルールに対して評価するオープンソースのポリシー適用ツールです。⁷

eBPFランタイム監査とは何ですか？ eBPF（extended Berkeley Packet Filter）は、監査対象のプロセスを変更せずに、カーネルレベルでシステムコールをトレースすることを可能にします。LogiraのようなツールはeBPFプローブを使用して、AIエージェント実行中のプロセス実行、ファイル操作、ネットワーク接続を記録します。⁹

出典