2026年3月31日、公開報道により、Claude Codeのnpmリリースにソースマップが誤って含まれ、大量の内部TypeScriptソースが露出したことが明らかになった。Ars Technica、Zscalerなどのメディアは、約1,900のTypeScriptファイルにわたり、およそ51万2,000〜51万3,000行が該当したと報じている。Anthropicは、この露出はリリースパッケージングの問題であり、機密性の高い顧客データや認証情報は関与していないと説明している。
初期の報道の多くは、最も目を引く発見——メモリシステム、隠しモード、未リリースの機能、内部コード名——に焦点を当てていた。しかし、より本質的な教訓は静かなところにある。公開された流出コードの分析からは、本番運用レベルのコーディングエージェントがモデルの周囲にどれほど多くのエンジニアリングを必要とするかが見えてくる。権限管理、テレメトリ、アナリティクス、セッショントレーシング、ツール実行、IDE連携、MCP連携、バックグラウンドタスク、マルチエージェントオーケストレーションなどだ。
これは新たに台頭しつつある分野を指し示している。すなわち**Agent Behavior Analysis（ABA、エージェント行動分析）**だ。その目的は、あらゆるやり取り、モデル呼び出し、ツール呼び出し、承認待ち、ブロック状態、セッション間の関係、ガバナンスイベントを、クエリ可能で相関分析可能、レビュー可能なテレメトリへと変換することにある。
本番運用エージェントは単なるモデルラッパーではない
Claude Codeは多くの場合、CLI形式のコーディングアシスタントとして体験される。しかし流出ソースに関する公開分析は、その裏にはるかに大規模なランタイムが存在することを示していた。権限レイヤー、メモリレイヤー、バックグラウンド処理、IDEブリッジ、MCPパス、そしてモデルを取り巻くマルチエージェントオーケストレーションだ。
正確な行数の内訳は、公式なアーキテクチャドキュメントではなく、ソースから導かれた分析として扱うべきだ。とはいえ、方向性は明確である。本番運用エージェントのうち、モデルを直接呼び出す部分はごく一部に過ぎない。残りはすべてランタイムエンジニアリングなのだ。
エンタープライズチームにとってこれが重要な理由は、運用上のリスクがモデルの応答だけに留まらず、その周囲のシステム全体に存在するからだ。
- エージェントはどのツールを呼び出したか?
- どの権限境界が適用されたか?
- 人間がそのアクションを承認したか?
- エージェントはユーザー入力待ちでブロックされていたか?
- サブエージェントは正しいコンテキストを引き継いだか?
- このアクションはどのセッション、あるいはどの親セッションに属していたか?
- トレースにはどのデータが入り、何がマスクされたか?
これらはオブザーバビリティの問いだが、通常のAPMの問いとは異なる。
エージェントオブザーバビリティの3つのレイヤーとは何か?
流出ソースに基づく公開分析では、Claude Codeにおける3つの独立したオブザーバビリティレイヤーが説明されていた。この区分は、ゼロから自前のエージェントランタイムを構築するチームにとっても有効だ。
| レイヤー | 答える問い | 例 |
|---|---|---|
| プロダクトアナリティクスイベント | ユーザー向けにどんな挙動が発生したか? | OAuthフローの開始、プラグインのインストール、セッションの再開 |
| 標準テレメトリ | インフラはどう機能しているか? | リクエスト数、レイテンシ、エラー率、エクスポーター状態(OTel、Prometheus、OTLP) |
| セッションレベルのエージェントトレーシング | 1回のユーザーとのやり取りはランタイム内でどう展開したか? | インタラクション、LLMリクエスト、ツール呼び出し、承認待ちでブロックされたツール、ツール実行、フック実行 |
プロダクトアナリティクスはランタイムトレースと混同すべきではない。プロダクトイベントとモデル実行のスパンは同一セッション内で発生し得るが、それぞれが答える問いは異なる。
セッションレベルのトレーシングは、エージェント特有の調査のために構築されたレイヤーだ。基本単位は単なるHTTPリクエストではなく、ユーザーとの1回のインタラクションである。1つのターンには、プロンプト処理、複数回のモデル呼び出し、複数回のツール呼び出し、承認待ち、フック、再開ロジックが含まれ得る。インタラクションレベルのルートスパンがなければ、調査はバラバラなイベントの寄せ集めになってしまう。
なぜ相関キーはログの量より重要なのか
エージェントシステムの調査が難しいのは、同じアクションが多様な形で現れるからだ。エージェントは次のいずれにもなり得る。
- ローカルのサブエージェント
- スウォーム内のチームメイト
- 独立したプロセス
- フレームワークが管理するワーカー
- IDE内のコーディングアシスタント
- MCP経由で呼び出されるワークフロー参加者
これを理解するには、安定した相関キーが必要だ。
user.idsession.idorganization.idagentIdparentSessionIdagentTypeteamName
これらの識別子により、バックエンドは最小限の関係グラフを構築できる——どのセッションがアクティブか、どのエージェントがそのアクションを実行したか、どの親セッションがそれを所有しているか、どのチームやワークスペースに属するか。ここがAgent Behavior Analysisの出発点となる。すべてのイベントがフラットなログ行として届くのであれば、チームはマルチエージェントのデッドロック、コストの急増、ツールの誤用インシデントを調査することはできない。
セマンティックスパンは関数レベルのタイミング計測に勝る
従来のトレーシングは関数、リクエスト、データベース呼び出しを起点にする。エージェントトレーシングには、より上位のタクソノミーが必要だ。
agent.interactionagent.llm_requestagent.toolagent.tool.blocked_on_useragent.tool.executionagent.hook
特に注目すべきはblocked_on_userスパンだ。エージェントシステムにおいて、時間は機械的な処理時間だけを指すのではない。承認待ち、手動確認、中断されたターン、人間の判断もランタイムの経路の一部である。
この時間を切り分けることで、チームはより鋭い問いに答えられるようになる。
- モデルの処理が遅かったからターンが遅くなったのか?
- ツール実行が遅かったのか?
- エージェントはユーザーの承認待ちだったのか?
- リスクの高いツールが頻繁に拒否されていなかったか?
- サブエージェントは権限不足で処理が止まっていなかったか?
これこそがAgent Behavior Analysisの核心的な価値だ。どのAPIが呼び出されたかを示すだけでなく、エージェントの挙動がどう展開し、どこで止まり、どの境界が次に起きたことを形づくったかを示す。
タクソノミーはガバナンスである
エージェントオブザーバビリティは、高次元で半構造化された、高カーディナリティのデータを生み出す。あらゆるプロンプト、ツール名、サーバー名、ファイルパス、ユーザーメッセージ、内部変数を無規律に保存すれば、プラットフォームは高コストでノイズが多く、リスクの高いものになってしまう。
優れたタクソノミーはガバナンスの仕組みそのものだ。Claude Codeに関する公開のソース由来分析は、エンタープライズシステムにとって重要なパターンを浮き彫りにした。
- メタデータは型によって制約されるべきである
- 機密性の高い文字列は明示的な取り扱いを要求すべきである
- 外部への配信前に、プライベートなペイロードフィールドは除去すべきである
- ユーザー定義のMCPサーバー名やツール名は正規化が必要な場合がある
- プロンプトテキスト、ツールの内容、ツールパラメータは明示的なスイッチで制御すべきである
- 高カーディナリティの識別子は意図的に管理すべきである
これは単なるデータモデリングの問題ではない。プライバシー、コスト、バックエンドの安定性、インシデントレビューがすべて同時に関わってくる。
TrueWatchがこのパターンから学んだこと
上記の設計の方向性は、TrueWatchがAIエージェントオブザーバビリティに取り組むアプローチと一致している。
柔軟なデータ、固定されないエージェントの形。 エージェントのアイデンティティは固定されていない——あるチームはOpenClaw、Claude Code、Codex、内製エージェント、MCP連携アシスタント、あるいはプロダクト固有のワークフローを運用し、それぞれ異なるフィールドを出力する。TrueWatchは、こうした異種混在のオブザーバビリティデータを受け取り、クエリ可能にするよう構築されている。初日からすべてのチームを同じ硬直したスキーマに押し込めることはしない。なぜなら、次に必要になるフィールドはsessionId、parentSessionId、skillName、teamName、approvalState、あるいはまだ誰も必要としていない何かかもしれないからだ。
収集と処理を分離する。 DataKitが対象環境でテレメトリを収集し、パイプライン処理がプラットフォームに到達する前にデータの解析、フィルタリング、エンリッチメント、マスキングを行う。これは、Claude Codeの分析から得られる教訓を映し出している——ガバナンスは、データがあらゆるシンクにすでに拡散した後ではなく、収集に近い場所から始めるべきだということだ。
DQLはオペレーターに単一のクエリプレーンを提供する。 エージェントの挙動はデータタイプをまたぐ——1件の調査で、トレーススパン、トークンメトリクス、ログ、イベント、承認記録、サービスデータが必要になることがある。DQLは、ツール呼び出し、トレースID、トークンの急増、エラーログ、サービス依存関係をつなぎ合わせ、誰もが無関係なシステム間を行き来する必要がないようにする。
高カーディナリティには相応の配慮が必要だ。 セッションID、トレースID、エージェントID、ツール名、モデルバージョン、プロンプトのバリエーション、ワークスペース識別子は急速に爆発的に増加し得る。TrueWatchはカーディナリティを注釈的な扱いではなく、アーキテクチャ上の課題として扱う。そのため、チームはオブザーバビリティのバックエンド自体を次のインシデントにすることなく、有用な詳細情報を保持できる。
Agent Behavior Analysisの4つのエンタープライズシナリオ
1. トークンコストの帰属分析
カスタマーサービスエージェントが本番稼働を開始する。月末になると、モデルAPIの支出が想定をはるかに超えていた。アプリケーションログは総使用量を示すが、本当に知りたい問い——どのスキル、どのプロンプトバージョン、どのモデル、どのセッションパターンがその増加を引き起こしたのか——には答えられない。
Agent Behavior Analysisを使えば、チームはトークン使用量をアプリケーション、モデル、スキル、セッション、ツール、あるいはプロンプトバージョン別に集計できる。犯人はしばしば些細なものだ——1ターンあたりのコンテキストを過剰に含む新しい注文履歴スキル、といったように。修正自体はたいてい簡単だ。難しいのは可視化する部分である。
2. リスクの高いツール使用と緊急停止
運用エージェントがデータベースのメンテナンスタスクを実行する権限を持っている。ある境界条件が誤っていたため、エージェントは危険な種類のSQL操作を試み始める。
CPUやメモリのグラフは正常に見えるかもしれない。しかしエージェントのスパンは実際の挙動を示している——リスクの高いツールへの繰り返しの呼び出し、対象データベース、コマンドの種類、セッション、権限コンテキストだ。適切なアラートポリシーがあれば、プラットフォームはオーナーに通知し、インシデントを起票し、あるいはガバナンスされたワークフローを通じて認証情報を失効させることができる。そして事後レビューでは、散在するログから物語を再構築するのではなく、トレースをたどればよい。
3. マルチエージェントのデッドロック
あるチームが、要件定義エージェント、コーディングエージェント、テストエージェントからなるスウォームを運用している。ワークフローが停止する——要件定義エージェントは作業がすでに引き渡されたと考えているが、テストエージェントは決して届かないコード出力を待ち続けている。
parentSessionIdやagentIdといった相関キーにより、プラットフォームはこれらのアクションをつなぎ合わせてトポロジーを構築できる。チームは、コーディングエージェントがgit_commitツール呼び出し中にユーザー承認待ちでブロックされ、その状態を上流に報告できなかったことを発見するかもしれない。行動分析がなければ、これは単なる沈黙に見える。セッショントレーシングがあれば、デッドロックには特定できる場所がある。
4. コンプライアンス監査と過剰権限の検出
ある金融サービス企業のチームが、マスキング済みのデータセットにのみアクセスできるはずのレポーティングエージェントを導入する。監査担当者は、そのエージェントが生の顧客データに一度もクエリを発行していないことの証拠を必要としている。
Agent Behavior Analysisは、各ステップでどのMCPサーバー、ツール、データセット、権限スコープが使用されたかを記録できる。未承認のサーバーや生データソースへの呼び出しの試みは、記録され、ブロックされ、レビューされる——単なる監視ではなく、コンプライアンス統制の一部として機能する。
よくある質問
Q: Agent Behavior Analysisとは何ですか? A: Agent Behavior Analysis(ABA)とは、モデル呼び出し、ツール呼び出し、承認待ち、ブロック状態、セッション間の関係といったあらゆるエージェントのやり取りを、フラットなログとして扱うのではなく、クエリ可能で相関分析可能、レビュー可能なテレメトリへと変換する実践のことです。
Q: Claude Codeのソース流出では実際に何が露出したのですか? A: 公開報道によれば、Claude Codeのnpmリリースにおけるパッケージングの問題により、約1,900のTypeScriptファイルにわたる約51万2,000〜51万3,000行を含むソースマップが露出しました。Anthropicは、機密性の高い顧客データや認証情報は露出していないとしています。
Q: なぜ標準的なAPMではAIエージェントに不十分なのですか? A: 標準的なAPMはリクエスト、レイテンシ、インフラの健全性を追跡します。エージェントシステムには、単なるHTTPリクエストではなく1回のユーザーとのやり取りを起点として、ツール呼び出し、承認待ち、フック実行といったビジネスセマンティクスをモデル化する、セッションレベルのレイヤーが必要です。
Q: エージェントオブザーバビリティにおける相関キーとは何ですか? A: 相関キーとは、sessionId、agentId、parentSessionId、teamNameといった安定した識別子のことで、オブザーバビリティプラットフォームがどのエージェントが、どのセッション内で、何を行ったか、そしてどの親セッションやチームに属するかを再構築できるようにします。
Q: TrueWatchは高カーディナリティのエージェントデータをどう扱いますか? A: TrueWatchはカーディナリティを後回しの課題ではなくアーキテクチャ上の関心事として扱います。そのため、チームはバックエンドを不安定にすることなく、調査に必要な粒度でセッションID、トレースID、エージェントID、プロンプトのバリエーションを保持できます。
すべての本番運用エージェントには行動分析が必要だ
Anthropicの公式声明によれば、Claude Codeのソースマップ流出はパッケージングのミスであり、顧客データの侵害ではなかった。しかしより広い教訓は、エージェントのランタイムエンジニアリングに関するものだ。
本番運用レベルのエージェントには、設計段階からオブザーバビリティを組み込む必要がある。プロダクトアナリティクス、標準テレメトリ、セッションレベルのトレーシング、セマンティックスパン、相関キー、プライバシー制御、高カーディナリティ管理、失敗時のクリーンアップ——これらは仕上げの装飾ではなく、インフラそのものである。
Claude Codeは主に自身のランタイムを観測している。エンタープライズのオブザーバビリティはより難しい課題を抱えている——ホワイトボックスエージェント、フレームワークエージェント、クローズドな内製エージェント、MCP連携ツールなど、多種多様なエージェントを観測しながら、データをクエリ可能で相関分析可能、かつガバナンスされた状態に保たなければならない。
それがToby AI Agentsのオブザーバビリティが目指す方向だ——あらゆるやり取り、ツール呼び出し、モデル呼び出し、承認待ち、ブロック状態、セッション間の関係を、チームがデバッグし、監査し、運用できるだけの可視性を持って提示すること。