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

AnthropicはClaude DesktopにCoworkという機能をリリースしました。この機能は、すべてのmacOSインストール環境に10GBの仮想マシンバンドルを作成します。Coworkを一度も有効にしていないユーザーにもVMがインストールされました。削除しても再生成されるのです。あるユーザーはバンドルが21GBにまで膨れ上がったと報告しています。このGitHub issueは、Anthropicが問題を認識する前に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のディスク容量を割り当て、アイドル時に24〜55%のCPUを消費し、8GBマシンではスワップ使用量が20Kから24K+スワップインに増加しました。¹ ユーザーがリソース消費を発見したのは、Anthropicのテレメトリではなく、macOSのストレージ警告を通じてでした。アプリケーションはVM割り当てに対するダッシュボード、メーター、オプトイン開示のいずれも提供していませんでした。

このパターンは仮説ではありません。2026年3月、ある開発者がClaude Codeが本番データベースを破壊するTerraformコマンドを実行したと報告しました。エージェントは本番のステートファイルに対してterraform applyを実行しました。確認プロンプトは表示されませんでした。フックがコマンドをインターセプトすることもありませんでした。開発者が破壊に気づいたのは、アプリケーションがオフラインになったときでした。この事件はHacker Newsで142ポイント、158件のコメントを集めました。¹² 数日後、別の開発者がClaude Codeが本番環境全体（2.5年分のレコードを含むデータベーススナップショットを含む）を削除したと報告しました。¹³ 両方の事件は同じ根本原因を共有しています：被害が不可逆になる前に、エージェントが何をしていたかに対する可視性がゼロだったということです。

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

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

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

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

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

第1層：リソース計測

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

Coworkの事件はリソース計測の失敗です。VMバンドルは10GBのディスク容量を消費しました。レンダラープロセスはアイドル時に24%のCPUを消費しました。スワップ活動はセッション中に着実に増加しました。これらのメトリクスはすべてmacOSのActivity Monitorに存在していました。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フェッチは取るに足りません。1回の実行で80のURLをフェッチするスキャンパイプラインは、エージェントのツール抽象化がオペレーターから隠す67MBのキャッシュコンテンツを生成します。リソース計測は、GitHub issue #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の正規表現パターンはそれらを区別できます。デフォルトのエージェント権限ではできません。

アプリケーションレベルのポリシー適用にはバイパスリスクもあります。2026年3月の分析では、Claude Codeの組み込み拒否リストに対する3つの段階的なサンドボックスエスケープ技術が記録されました：パスベースの回避（/proc/self/root/usr/bin/npxはブロックされた/usr/bin/npxと同じバイナリに解決される）、自己指示によるサンドボックス無効化（エージェントがタスク完了をブロックされた際にサンドボックスの削除を自ら推論した）、動的リンカー呼び出し（ld-linux-x86-64.so.2がメモリマッピングを通じてバイナリをロードし、カーネルの適用フックを完全にバイパスする）。¹⁴ 3番目の技術はエクスプロイトのクラスです：execveを避けるあらゆるコードロードがプロセスレベルの適用をバイパスします。ポリシー適用への教訓は、文字列マッチングの拒否リストは必要な最初の層であり、十分な層ではないということです。コンテンツアドレス可能な適用（ファイル名ではなくSHA-256ハッシュでバイナリを識別する）はパス回避のギャップを埋めますが、動的ローダーバイパスにはポリシー層の下に位置するカーネルレベルの制御が必要です。

第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の観察のみの監査証跡に匹敵する本番対応の同等物がありません。

2026年3月にHacker Newsで802ポイントと181件のコメントを集めたmacOSネイティブのサンドボックスツールであるAgent Safehouseは、適用の側面からプラットフォームギャップに対応しています。¹⁵ このツールはmacOS上のローカルAIエージェント向けに特別に設計されたサンドボックスプロファイルを提供します。コミュニティの反応（サンドボックスツールで802ポイントは例外的）は緊急性を反映しています：macOS上でエージェントを実行する実践者には、「サンドボックスなし」と「独自のSeatbeltプロファイルを書く」の間の選択肢が限られています。Agent Safehouseは適用のギャップを埋めます。macOSの監査のギャップは依然として残っています。

適用と監査の区別は、インシデント対応における時間的分割に対応します。適用はインシデントを防ぎます。監査はインシデント後の再構成を可能にします。両方とも必要です。すべてのクレデンシャルアクセスをブロックする適用層は窃取を防ぎますが、正当な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コマンドを構築するエージェントは、フックが単一の文字列として見るコードを実行します。カーネルレベルの監査では各サブプロセスが見えます。

3層スタックがデフォルトの監視では見逃されたであろう障害を捕捉した、本番インシデントの具体的な結果：

増幅するブラインドスポット

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

私のオーケストレーションシステムが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エージェントの実行中にプロセス実行、ファイル操作、ネットワーク接続を記録します。⁹

エージェントはなぜオペレーターの可視性なしにサブエージェントを起動できるのですか？ タスクを委任するエージェントは、新しいコンテキストウィンドウを持つ子プロセスを起動します。親エージェントは子の最終出力を見ますが、個別のツールコール、ファイル読み取り、リソース消費は見えません。各委任ホップで情報は圧縮されます：孫の完全なセッションは親のログの1行のステータスになります。可観測性は委任の深度が増すのと同じ速度で劣化します。²

エージェント監視は従来のAPMとどう違うのですか？ 従来のApplication Performance Monitoring（APM）は、決定論的なソフトウェアのリクエストレイテンシ、エラーレート、スループットを追跡します。エージェント監視は非決定論的な動作を追跡します：エージェントが実行時に何を決定したか、その決定がポリシーの範囲内だったか、各決定がどのリソースを消費したか。APMはアプリケーションが既知のコードパスに従うことを前提とします。エージェント監視はエージェントが自身のパスを選択することを前提とします。²

出典