Claude Code や Cursor を業務に入れた瞬間、多くのチームが同じ壁にぶつかります。
「何かやってくれているのはわかるが、何をやったのかが追えない」という状態です。
Uber が本番運用で採用した OSS フレームワーク ADR（Agentic Detection and Response） は、その不安に対する現時点で最も実践的な答えのひとつです。
3 つの構成要素が何をするものかを実務レベルで整理しつつ、最小構成でセットアップしてログを読めるところまで辿ります。
エージェントの「野放し運用」が詰む理由
エージェントが起こす問題の多くは、ログがないから追えないのではありません。
ログはある。でも 繋がらない という形で詰むのが実態です。
従来のアプリケーションログは、リクエスト→レスポンスというシンプルな因果関係を前提に設計されています。
ところがエージェントのツール呼び出しは、非同期・多段階で連鎖します。
「あるプロンプトへの応答として、どのツールが、どの順番で、何を引数に呼ばれたか」という因果の連鎖を、既存のログから再構成するのは現実的ではありません。
EDR（エンドポイント検知・対応）や SIEM（セキュリティ情報・イベント管理）を使っているチームも、同じ壁に当たります。
システムコールレベルのファイル書き込みやネットワーク通信は見えます。
でも「なぜエージェントがそれをしたのか」というプロンプトから行動への文脈が欠落しています。
MLSys 2026 に採択された Uber の論文（arxiv.org/abs/2605.17380）はこれを Observability ギャップ として明示しています。
EDR はファイル書き込みとネットワーク呼び出しを見られるが、エージェントの推論・プロンプト・ツール実行を繋ぐ因果連鎖は見えない、という指摘です。
たとえばこんなシナリオを考えてみてください。
ある日、本番リポジトリから設定ファイルが消えました。
システムログには「ファイル削除」のイベントが残っています。
でも、それが Claude Code のどのセッションで、どのプロンプトに応答して実行されたのかは、ログを追っても分かりません。
原因調査が「ログがない」ではなく「ログはあるが繋がらない」という形で行き詰まる——これが野放し運用の本質的な問題です。
ADRの3要素——Uberが1日20万セッションで直面したギャップから生まれた設計
ADR は Uber が社内で開発し、本番運用した後に OSS として公開したフレームワークです。
GitHub リポジトリは uber/ADR で公開されており、論文は MLSys 2026 に採択されています。
Uber が直面した課題は、前節で述べた 3 つのギャップそのものでした。
Observability（エージェントの意図と行動を繋ぐトレースがない）、Evaluation（MCP ネイティブで企業ポリシーを考慮した評価基準がない）、そして Detection at scale（1 日 20 万セッション超に LLM ベースの推論を全件かけるとコストとレイテンシが破綻する）です。
特に 3 つ目の制約が設計の核心になっています。
「全セッションを LLM で推論すれば精度は上がるが、スケールすると現実的ではない」という問題を、どう解くか。
この問いへの答えとして、3 つの役割に分割した構成が生まれました。
- ADR Sensor: MCP レイヤーでエージェントのアクションをインターセプトし、ツール呼び出し・入出力・セッション情報をトレースとして収集する。いわば「記録係」。
- ADR-Bench: 収集したトレースを既知の脅威パターン（プロンプトインジェクション・クレデンシャル漏洩・意図しない外部通信など）と照合する評価フェーズ。デプロイ前のチューニングに使う「採点係」。
- ADR Detector: ランタイムで異常シグナルを検知し、アラートを出す「見張り係」。コスト・精度・レイテンシのバランスを取るために、軽量なシグナルで絞り込む設計になっている。
GitHub リポジトリのトピックタグには claude-code・cursor・mcp・prompt-injection・threat-detection などが並んでおり、特定のエージェント実装に閉じない汎用フレームワークとして設計されています。
リポジトリの README には Detection ディレクトリに「フェイクのクレデンシャル・エミュレート環境・プロンプトインジェクションシナリオを含む合成ベンチマークフィクスチャ」が収録されていることも明記されており、防御的セキュリティ研究用途であることが示されています。
最小構成でADRを動かす——Sensorだけでもログはとれる
リポジトリは Sensor・Detection・Benchmark の 3 ディレクトリに分かれています。
最初から全部動かそうとすると設定が複雑になるので、まずは Sensor だけ 入れてトレースを貯めることを目標にします。
Detector と Bench は、ログが溜まってからチューニングする方が現実的です。
前提環境は Python と、MCP に対応したエージェント（Claude Code または Cursor）です。
リポジトリのクローンとインストールは次のコマンドで始められます。
git clone https://github.com/uber/ADR.git
cd ADR
pip install -e ./Sensor
ただし、ここから先の設定ファイルのフィールド名・環境変数名・起動コマンドの詳細については、公式リポジトリの README を直接参照してください。
本記事執筆時点では、YAML 設定のキー名や Sensor の起動オプションが公開ドキュメントから確認できる範囲に限りがあるため、特定のフィールド名を断定的に示すことを避けます。
実際に動かす際は uber/ADR の README が一次情報になります。
ひとつ確認できているのは、Claude Code 自体が OpenTelemetry（OTel）のメトリクスとイベントログ出力に対応しているという点です。
AWS ブログやクラスメソッドの記事でも実証されているように、Claude Code は OTLP エンドポイントを環境変数で指定するだけでトレースを外部に流せます。
ADR Sensor が OTLP と直接互換があるかどうかは公式ドキュメントで要確認ですが、Claude Code 側の OTel 対応を活用してトレースを収集するパイプラインを組む方向性は現実的です。
動作確認の感覚としては、Sensor を起動した状態で Claude Code に「ファイルを読んで書き換える」程度のタスクを走らせ、Sensor 側のコンソールにイベントが流れてくるかを見るのが手っ取り早いです。
ファイル読み書きやシェル実行を伴うタスクを実行したとき、どのツールが呼ばれたかが記録されていれば、Sensor は機能しています。
取れたログの読み方——「これが出たら要注意」なシグナル
ADR Sensor が収集するトレースの具体的なフィールド名は、公式リポジトリのサンプルを参照するのが確実です。
ただ、概念レベルで「何が記録されるか」を理解しておくと、ログを見る際の判断軸が立ちます。
収集されるトレースには大きく分けて、セッションを識別する情報・ツール呼び出しの詳細（ツール名・入力引数・出力結果）・タイムスタンプ・エージェント識別子が含まれます。
これらが揃うことで、「あのセッションで、いつ、何のツールが、何を引数に呼ばれたか」という因果の連鎖が初めて追えるようになります。
ログを読む際の実務的な起点は 2 つあります。
ひとつは セッション単位で追う やり方で、インシデントが発生したときに「あのセッションで何が起きたか」を時系列で再構成するのに向いています。
もうひとつは ツール名でフィルタする やり方で、bash・curl・python のような汎用ツールの呼び出しだけを抽出して眺めると、意図しない副作用が浮かびやすくなります。
ADR-Bench が照合する脅威パターンのカテゴリは、GitHub リポジトリの Detection ディレクトリに収録された合成ベンチマークフィクスチャから読み取れます。
プロンプトインジェクション・クレデンシャルへのアクセス・意図しない外部通信・権限昇格を試みるコマンドといったカテゴリが含まれています。
実際の検知シグナル名や閾値の詳細は公式リポジトリの Detection ディレクトリを参照してください。
概念として押さえておきたい「要注意パターン」を挙げると、次のようなものになります。
- 外部ドメインへの予期しない HTTP リクエスト（特にクレデンシャルファイルへのアクセスと組み合わさっているケース）
- 環境変数・設定ファイル・シークレットストアへのアクセスを含むツール呼び出し
- 外部ソース（Web ページ・ファイル内容）を読み込んだ直後にエージェントの行動が変化しているパターン（プロンプトインジェクションの典型的な兆候）
単体のシグナルより、セッション内での 組み合わせと順序 で判断する方が誤検知を減らせます。
クレデンシャルへのアクセスの直後に外部通信が続いているセッションは、それぞれ単独で立つより優先度を上げて確認する——そういった判断軸を持つと実務で使いやすくなります。
本番に持ち込む前に知っておくべきこと
正直なところ、ADR を入れれば即座に安全になるわけではありません。
本番投入前に知っておかないと後で痛い目を見る点が、いくつかあります。
まずパフォーマンスオーバーヘッドの話です。
Uber の論文が設計課題として明示しているのが「コスト・精度・レイテンシのバランス」です。
全セッションに LLM ベースの推論をかけると、1 日 20 万セッション規模ではコストとレイテンシが破綻します。
ADR Detector はこの問題を軽量なシグナルで絞り込む設計で対処していますが、チューニングなしで本番に持ち込むと Detector の推論コストがエージェント本体のコストに匹敵するケースも出てきます。
ステージングで実際のセッション量を流してオーバーヘッドを計測してから本番に持ち込む必要があります。
ログ保管コストも見落としがちです。
Sensor が収集するトレースは、セッション数が増えるにつれてデータ量が急増します。
全件保管するのか、異常フラグが立ったセッションだけ長期保管するのか。
保管期間とサンプリング戦略は Sensor を入れる前に決めておくべきで、ここを曖昧にしたまま運用を始めるとストレージコストが予想外に膨らみます。
アラートチューニングの難しさも現実的な壁です。
初期状態では誤検知が多く出ます。
bash ツールを使う正常なタスクが意図せず脅威パターンに引っかかるケースなど、実運用データがないと閾値を適切に設定できません。
Bench と Detector はステージングで実際のワークロードを流しながらチューニングし、誤検知率が許容範囲に入ってから本番に持ち込むのが現実解です。
これらを踏まえると、段階的な導入順序が自然に見えてきます。
まず Sensor だけ先行投入してトレースを貯める。
貯まったログを見ながら、どのパターンが自分たちのワークロードで意味を持つかを把握する。
その上で Bench でチューニングし、Detector を段階的に有効化して本番へ持ち込む。
この順序を守れば、「入れたら誤検知だらけで運用が回らない」という状態を避けられます。
Sensor だけでも入れる価値は十分あります。
トレースが溜まるだけで、インシデント時の原因調査が「ログが繋がらない」状態から「ログを辿れる」状態に変わります。
そこから始めるのが、野放し運用を終わらせる現実的な第一歩です。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
Claude Code や Cursor の業務導入支援から、ADR のようなエージェント監視の実装支援まで対応しています。
導入の相談は お問い合わせページ からどうぞ。