AIエージェントのオブザーバビリティ：見えないものをどう監視するか

Anthropicは Claude Desktop に Cowork という機能を出荷しました。この機能は、macOS にインストールされるたびに10GBの仮想マシンバンドルを作成していました。Cowork を一度も有効にしていないユーザーにもVMが作られ、削除したユーザーはそれが再生成されるのを見ることになりました。あるユーザーは、バンドルが21GBまで膨れ上がったと報告しています。GitHub の issue は、Anthropic が問題を認めるまでに Hacker News で345ポイントと175件のコメントを集めました。¹

ディスク容量が尽きるまで、誰も気づかなかったのです。

AIエージェントのオブザーバビリティとは何でしょうか。 エージェントのオブザーバビリティとは、自律型エージェントが実行時に何を消費し、何を実行したかを監視する取り組みを指します。これには3つの層が必要です。リソース計測（セッションごとのディスク、メモリ、CPU、ネットワーク）、ポリシー適用（各ツール呼び出しにおける許可/拒否ルール）、そしてランタイム監査（実際の振る舞いをカーネルレベルで記録すること）です。この3つがそろわなければ、運用者はドリフトを検知することも、スコープを強制することも、インシデントを再構成することもできません。

要点

エージェントツールは今や、運用者から見えないままコンピュートリソース（ディスク、メモリ、CPU、ネットワーク）を確保します。Anthropic の Cowork VM は目に見える例ですが、あらゆる MCP ツール呼び出し、あらゆるサブエージェントの生成、あらゆるWebフェッチは目に見えない例です。エージェントを統治するには、3層のオブザーバビリティが要ります。リソース計測（何を消費したのか）、ポリシー適用（何を許されていたのか）、ランタイム監査（実際に何をしたのか）です。ポリシー層と監査層に取り組むオープンソースプロジェクトは2つあります（mcp-firewall と Logira）が、3つすべてをカバーする実運用ツールは存在しません。以下では、可視性の問題、3層スタック、各層が捉えるもの、そして今日から実装できる最小限の監視フックを取り上げます。

可視性の問題

従来のソフトウェアは、運用者が自ら引くと決めたオブザーバビリティの線の下で動きます。Webサーバーがアクセスログを書くのは、エンジニアがロギングを設定したからです。データベースがスロークエリを追跡するのは、誰かが log_min_duration_statement を設定したからです。粒度を決めるのは運用者でした。

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

Cowork のインシデントは、この逆転をインフラ層で露呈させました。Claude Desktop は10GBのディスク容量を確保し、アイドル時に24〜55%のCPUを消費し、8GBのマシンではスワップインを2万回から2万4千回以上へと押し上げました。¹ ユーザーがこのリソース消費に気づいたのは macOS のストレージ警告からであって、Anthropic のテレメトリからではありません。アプリケーションは、VMの確保についてダッシュボードもメーターもオプトインの開示も提供していなかったのです。

このパターンは仮定の話ではありません。2026年3月、ある開発者が、Claude Code が実行した Terraform コマンドによって本番データベースが破壊されたと報告しました。エージェントは本番のstateファイルに対して terraform apply を実行しました。確認プロンプトは出ず、コマンドを差し止めるフックもありませんでした。開発者が破壊に気づいたのは、アプリケーションがオフラインになったときでした。このインシデントは Hacker News で142ポイントと158件のコメントを集めています。¹² その数日後には、別の開発者が、2年半分のレコードにあたるデータベーススナップショットを含む本番環境一式を Claude Code が削除したと報告しました。¹³ どちらのインシデントも根本原因は同じです。被害が取り返しのつかなくなる前に、エージェントが何をしていたのかがまったく見えていなかったことです。

このパターンをエージェントセッションのスケールに広げてみましょう。私のフックオーケストレーションシステムは、Claude Code のフック基盤の上に構築されており、あらゆるツール呼び出しにまたがる15種類のイベントを捕捉します。¹¹ 60セッションにわたり、このシステムは各アクションで84個のフックが発火したことを記録し、標準のエージェントインストールでは決して得られないテレメトリを生み出しました。² その計装がなければ、NIST への公開コメントに記録した12件のドリフト、幻の検証失敗、再帰的な生成ループを、私は検知できなかったでしょう。³

DORA の2024年版 Accelerate State of DevOps Report は、強いオブザーバビリティ実践を持つチームほどデプロイ頻度が高く、障害からの復旧も速いことを示しました。2025年版はこのフレームワークをAI支援開発へと拡張し、オブザーバビリティを「AI支援によるコーディングやテストが品質、リードタイム、全体的な信頼性にどう影響するか」と結びつけています。⁴ エージェントのオブザーバビリティは「あれば便利」なものではありません。エージェントの振る舞いを測ることは、それを統治するための前提条件なのです。

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

エージェントのオブザーバビリティには、独立した3つの層が必要です。各層はそれぞれ別の問いに答えます。ひとつの層が破られても、他の層は損なわれません。

これらの層は、ひとつの段階的な流れに対応します。測っていないリソースにポリシーを課すことはできませんし、定義したことのないポリシーへの準拠を監査することもできません。各層は、その下の層の上に成り立っているのです。

第1層：リソース計測

リソース計測が答えるのは、エージェントがどれだけを、どこで消費したのかという問いです。

Cowork のインシデントは、リソース計測の失敗でした。VMバンドルは10GBのディスク容量を消費し、レンダラープロセスはアイドル時に24%のCPUを消費し、セッション中にスワップ活動が着実に増えていきました。これらの指標はすべて macOS のアクティビティモニタには存在していました。しかし、そのどれひとつとして Claude Desktop のインターフェースには現れなかったのです。¹

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

ディスク。 すべてのファイル書き込み、すべてのキャッシュエントリ、すべてのログファイルです。私のセッションはセッションあたり200〜400KBの状態ファイル（jiro.state.json、jiro.progress.json、フックログ）を生成します。60セッションでは12〜24MBの状態データが積み上がり、明示的に掃除しないかぎりセッションをまたいで残り続けます。²

メモリ。 ターンごとのコンテキストウィンドウ消費です。20万トークンのコンテキストウィンドウは、現在の Opus の価格でフルに埋めるとおよそ3ドルかかります。私のコストトラッカーは、設定可能な上限の80%、90%、95%に予算しきい値を置きつつ、セッションごとの累積トークン使用量を記録します。⁵

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

ネットワーク。 Webフェッチ、API呼び出し、MCPツールの起動です。外向きのリクエストはどれも潜在的なデータチャネルであり、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エージェント向けにポリシー層を担います。⁷ このツールはエージェントとすべてのツール使用リクエストの間に立ち、実行前に各リクエストを正規表現ベースのポリシーに照らして評価します。ポリシーは JSONNet の設定ファイルで記述し、フォルダ、gitリポジトリ、ユーザー単位でスコープを切れます。ファイアウォールは PreToolUse フック連携を通じて Claude Code と GitHub Copilot CLI をサポートします。

このアーキテクチャは、ひとつの重要な洞察を反映しています。どのエージェントも、許可/拒否のロジックについて自前の中途半端な解を実装している、ということです。Claude Code は glob パターンを使い、Codex CLI は前方一致のみを使います。それぞれのやり方は、ポリシー空間の一部しかカバーしません。mcp-firewall は、エージェントをまたいで動くひとつのエンジンへとルールを集約します。

集約された適用がない場合のポリシーの穴を考えてみましょう。私のフックシステムには、認証情報のパターン、危険なgit操作、機微なパスへのアクセス、デプロイコマンドをチェックする PreToolUse:Bash ハンドラーが12個あります。² 各ハンドラーは、それぞれ独自の正規表現を持つ別々のシェルスクリプトです。新しい拒否ルールを追加したければ、新しいスクリプトを書きます。どのルールが存在するかを監査したければ、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 ハッシュでバイナリを識別する方式）はパス回避の穴を塞ぎますが、動的ローダによる迂回には、ポリシー層より下に位置するカーネルレベルの制御が要ります。

同じ教訓は、ポリシーがまったく見通せない一段上の層にも当てはまります。2026年9月に Air Security が公表した Plugin4Shell は、主要な4つのコーディングエージェントに共通する、マーケットプレイスのサプライチェーンの欠陥です。マーケットプレイスはプラグインについて審査済みのコミットをピン留めしますが、エージェントはそのコミットが本当にそこに入ったのかを確かめないままチェックアウトします。そのためプラグインのリポジトリを握った攻撃者は、ピン留めされたコミットと同じ名前のブランチを作り、それをデフォルトブランチにできます。マーケットプレイス側でのありふれたピンの貼り直しが、続いて各エージェントのバックグラウンド自動更新を起動し、チェックアウトはそのブランチへ解決される一方、ピン留めは守られているように見えたままです。私の読みでは、このスタックのどの PreToolUse フックも、拒否リストも、ファイアウォールも、プラグインのすり替えを見ていません。すり替えはエージェントがツールを呼び出す前に起きるからです。Air の時系列によれば、Anthropic は Claude Code 2.1.179 で修正を確認し、OpenAI は Codex 0.146.0 で修正を出荷し、GitHub Copilot には修正がなく、非推奨となった Gemini CLI には修正の予定もありません。ただし Claude Code の公開チェンジログの 2.1.179 の項目はこの修正に触れておらず、バージョンは研究者たちの説明に依拠しています。ここで効く対策は、バージョンを最新に保つ衛生管理と、マーケットプレイスが実際に何を解決したのかの棚卸しであり、それは計測の問題であって、ポリシーの問題ではありません。¹⁷

第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 の観測専用の監査証跡に相当する実運用可能なものが存在しないのです。

macOS ネイティブのサンドボックス化ツールである Agent Safehouse は、2026年3月に Hacker News で802ポイントと181件のコメントを集め、このプラットフォームの空白に適用の側から取り組んでいます。¹⁵ このツールは、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 フレームワークは、連鎖的な失敗や不正なエージェントを扱っていますが、マルチエージェントの委譲チェーンに対するオブザーバビリティ要件までは定めていません。⁸ OpenGuard による2026年3月のエージェントのプロンプトインジェクション分析は、同じ空白をセキュリティの側から浮かび上がらせています。異なる権限を持つエージェント間を汚染された文脈が流れることで、明確なデータフローポリシーも合成レベルの認可もないまま、引き継ぎを通じて「静かに権限を昇格させる道」ができてしまうのです。¹⁶ この空白は構造的なものです。チェーン上の各エージェントが、それぞれ独立に設定され独立に報告される、自前のリソース計測、ポリシー適用、ランタイム監査を必要とすることになります。オーバーヘッドは掛け算です。チェーン上の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 です。一致したらブロックします。実装に必要なのは、標準入力（ツール呼び出しのJSON）を読み、commandフィールドを取り出し、パターンファイルと grep する1本のシェルスクリプトです。私の認証情報チェック用フックは、これを31行で行っています。²

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

settings.json における拒否リストフックの実例です。

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

フックスクリプトは標準入力からツール呼び出しを読み、コマンド文字列を取り出し、パターンと照合します。ブロックされたコマンドには {"decision": "block", "reason": "Sensitive path access denied"} というJSONオブジェクトを返し、許可されたコマンドには {"decision": "approve"} を返します。Claude Code はどちらの応答も、それ以上の確認なしに尊重します。このフック全体は、許可されたコマンドにレイテンシをまったく加えず（正規表現の照合は5ms未満で終わります）、ブロックされたコマンドには即座にフィードバックを返します。

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

押さえておきたい要点

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

セキュリティチームへ。 ツール呼び出しの境界でのポリシー適用は、エージェントセキュリティにおける実行可能な最小限の姿勢です。mcp-firewall の集約的なアプローチは、エージェントごとの許可/拒否ロジックを、監査可能なひとつの設定へとまとめます。自分たちのエージェントの組み込み権限が、脅威モデルの求めるポリシー空間をカバーしているかどうかを評価してください。

エンジニアリングマネージャーへ。 長期的な答えはエージェントの自己統治です。監視を外部からの制約としてだけでなく、行動規範として内面化したエージェントということです。それが成熟するまでは、自分たちのエージェントツールについて3つの問いを立ててください。セッションごとのリソース消費は見えますか。ツール呼び出しのポリシーを定義し、監査できますか。エージェントが何をしたのかを事後に再構成できますか。ひとつでも「いいえ」があるなら、そこには可視性の空白があり、それはワークフローにエージェントが1つ増えるたびに広がっていきます。

よくある質問

エージェントのオブザーバビリティとは何ですか。

エージェントのオブザーバビリティとは、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 のようなツールは、AIエージェントの実行中にプロセス実行、ファイル操作、ネットワーク接続を記録するために eBPF プローブを使います。⁹

エージェントは、どうして運用者に見えないままサブエージェントを生成できるのですか。

タスクを委譲するエージェントは、新品のコンテキストウィンドウを持つ子プロセスを生成します。親エージェントには子の最終出力が見えますが、その個々のツール呼び出しやファイル読み取り、リソース消費は見えません。委譲のホップごとに情報は圧縮され、孫のセッション全体が、親のログでは1行のステータスになってしまいます。オブザーバビリティは、委譲の深さが増すのと同じ速さで劣化します。²

エージェントの監視は、従来のAPMとどう違うのですか。

従来のアプリケーションパフォーマンス監視（APM）は、決定的に動くソフトウェアのリクエストレイテンシ、エラー率、スループットを追跡します。エージェントの監視が追跡するのは非決定的な振る舞いです。エージェントが実行時に何をすると決めたのか、その判断はポリシーの内側だったのか、そして各判断がどれだけのリソースを消費したのか、というものです。APM はアプリケーションが既知のコードパスをたどることを前提にします。エージェントの監視は、エージェントが自らの道を選ぶことを前提にします。²

Claude Code のフックでエージェントのオブザーバビリティは実現できますか。

できます。Claude Code のフックシステムは、ライフサイクルイベント（PreToolUse、PostToolUse、Notification）でスクリプトを発火させ、リソースの計測、ポリシーの適用、アクションの記録を行えます。トークン予算トラッカー、PreToolUse 拒否リスト、PostToolUse セッションロガーという3つのフック構成なら、100行未満のbashで3つの可視性層すべてをカバーできます。すでに Claude Code を使っているチームにとって、フックは最も入りやすい入口です。

エージェントが自分のサンドボックスを迂回すると何が起きますか。

サンドボックスの迂回とは、適用層が黙って破られることを意味します。エージェントは意図されたスコープの外側で実行を続け、ランタイム監査がなければ、その突破の記録はどこにも残りません。2026年3月に記録されたサンドボックス脱出手法には、パスによる回避、エージェント自身によるサンドボックス無効化、動的リンカの呼び出しが含まれます。いずれもアプリケーション層の監視からは見えません。

MCP ツールのオブザーバビリティはなぜ重要なのですか。

MCP ツールの呼び出しは、どれも潜在的なデータチャネルです。ファイルを読み、ネットワークリクエストを行い、コードを実行できます。MCPサーバーは攻撃面を広げます。サーバーが1つ増えるたびに、エージェントが実行時に呼び出せる新しい能力が加わるからです。呼び出しごとのロギングとポリシー適用がなければ、MCP ツールの起動は運用者から見えません。

マルチエージェントの委譲チェーンはどう監視すればよいですか。

委譲チェーン上の各エージェントには、それぞれ自前のリソース計測、ポリシー適用、ランタイム監査が必要です。ralph 自律ループはこの問題をよく示しています。親が子エージェントを生成し、その子はそれぞれ新品のコンテキストウィンドウを受け取ります。親に見えるのは最終出力であって、個々のツール呼び出しではありません。オブザーバビリティは委譲の深さが増すのと同じ速さで劣化するため、すべてのホップで独立した監視が必要になります。

出典