Claude Codeセッションと、言うことを聞かないその他すべてのエージェントの記録方法：実践フィールドガイド

はい、今日のClaude Codeセッションを録画できます。得られるのは、全体（すべてのモデルターン、すべてのツール呼び出し、エージェントが触れたすべてのファイル）を再生可能な形で記録したものです。これは簡潔な説明であり、今日現在も事実です。より詳細な説明は、録画可能性はハーネスごとに決まり、2つの質問によって決まります。ハーネスをプロキシにポイントできるかどうか、そして、トラフィックが到着したときにそのワイヤーフォーマットが理解されるかどうかです。Claude Codeはその両方を満たします。APIキーでサインインしたCodex CLIも同様です。プロバイダーURLがソースコードにハードコードされているエージェント、コンテナまたはVPS上で実行されているエージェント、およびサブスクリプションでサインインしたハーネスは、それぞれ異なる経路をたどります。そして、そのうちの1つは、今日現在、到着しません。

変わったのは、これらのエージェントがデモではなくなったことだ。彼らはあなたのリポジトリの中にシェルアクセス権とともに居座り、ファイルを編集し、テストスイートを実行し、プルリクエストを開く。そのうちの一つがあなたの想定外のことをしたとき、それが誤ったファイルの削除であれ、同じ失敗テストでのループであれ、午後いっぱいの計算リソースの浪費であれ、ターミナルのスクロールバックは証拠にはならない。それはレンダリングであり、しかも不完全なものなのだ。

必要なのはワイヤーです。つまり、実際にモデルへ送られた内容、実際に返ってきた内容、そしてターンとターンの間にエージェントが何を行ったかという記録です。その記録は、評価スイートの始まりにもなります。キャプチャしたセッションは、次のモデルや次のプロンプトに対して再生できる回帰テストだからです。厄介なのは、あらゆるハーネスが自分はプロバイダーと直接通信していると想定しており、その変更を容易にしているものがほとんどないことです。

ハーネスを記録できるかどうかは、何で決まるのですか？

「録画してもらえますか」という質問は、どれも同じ二つの質問に帰着する。

最初の点:ハーネスをプロキシに向けることはできますか?利便性の高い順に、4つの方法があります。

• ベースURL変数。このために構築されたルート: ハーネスはベースURL環境変数を読み取り、それを設定します。

• 自分でハーネスを起動する。子プロセスは親プロセスの環境を継承するので、コーディングエージェントを起動するゲートウェイも、エージェントの協力なしに捕捉されます。

• TLS傍受。設定を一切読み込まないハーネスでは、レコーダーがエージェントを起動し、傍受にオプトインします。

• アタッチ。 エージェントがレコーダーを起動できない場所で実行される場合、残されるのはアタッチのみです。

それらのいずれも該当しない場合、トラフィックはレコーダーに到達せず、議論すべきことは何もありません。

第2に、トラフィックが届いたとき、そのワイヤーフォーマットを理解できるかどうかだ。バイト列をキャプチャすることは製品ではない。レコーダーは、自分が立ち会っている会話を認識できなければならない。ツールコールの形状、ストリーミングのフレーム、リトライも含めてだ。それらを認識できなければ、その記録はリプレイではなく、単なるpcapにすぎない。レコーダーが理解できるフォーマットならリプレイ可能なセッションが生まれるが、独自の方言によるキャプチャは、ただ眺めることしかできない。

答えはハーネスごとに異なり、しかも間違えやすい細部の点でも異なります。これは、DeepSeekハーネスがClaude Codeとどのように異なるかを比べて得られたのと同じ教訓です。本記事の残りの部分では、実際にハーネスを実行したときに、この2つの問いがどのように見えるかを説明します。

Claude Code、Codex CLI、およびAgents SDK

Claude Code は、他のすべての評価基準となるケースである。なぜなら、ANTHROPIC_BASE_URLを読み取るからだ。この変数がレコーダーを指すように設定し、エージェントを起動すると、セッションはターンごとに届く。届くのは、プロンプト、ツール呼び出し、ファイル編集、そしてそれらの合間に交わされるモデルの応答である。私たちはこれを、実際のバグ修正（実際のリポジトリ、実際の欠陥、最初のプロンプトから動作する修正に至るセッション）を使ってエンドツーエンドで検証した。すると、その最初の実際のエージェントは、どのフィクスチャも生み出さなかった4つの問題を引き起こした。この4つはすべてその後修正された。これは、合成トラフィックでは、実際のエージェントがコードベースだけを相手に放置されたときに何をするかに備えることはできない、ということを率直に示している。

APIキーでサインインしたCodex CLIも、OPENAI_BASE_URL経由の場合も同じ話です。レコーダーに向ければセッションが得られ、ハーネスの使い方について他に変わることは何もありません。

プログラム的エージェントは、すべての経路の中で最も容易な経路を継承します。子プロセスは親環境を継承するため、コーディングエージェントを起動するゲートウェイも、エージェントの協力を得ることなく捕捉されます。起動を行うプロセスでベースURL変数を一度設定するだけで、そこで起動されるすべてのエージェントが独自にレコーダーに到達します。CI、オーケストレーター、またはAgents SDKからエージェントを実行している場合、これはすでにあなたが辿っている経路です。

これらすべてのケースにおけるレコーダーはOrcaReplayです。インストールはnpm i -g orcareplayで行います。Node 20以降が必要で、ネイティブ依存関係はありません。コンパイルするものも、ビルドするものもありません。同じエージェントトラフィックをキャプチャします。それはOrcaRouterがOrcaRouterのモデルカタログ全体でルーティングするもの。

ベースURL変数を一切読み取らないエージェント

一部のハーネスは、プロバイダURLを自身のソースコードにハードコードしている。環境変数も設定ファイルもフラグもない。設定しても何も起こらないのはANTHROPIC_BASE_URLである。なぜなら、それを読み取るものが何もないからだ。レコーダーがエージェントを起動できれば、依然として経路は存在する。そして、それは人々が最も懸念する経路、すなわちTLS傍受である。

オプトインは、まさにその言葉通りオプトインです。デフォルトではオフになっています。ある実行のためにこれを有効にすると、レコーダーはその実行に固有の認証局を生成します。この認証局を信頼するのは、レコーダーが起動するエージェントだけです。つまり、認証局はその単一のプロセスに渡されるものであり、システムのキーチェーンにインストールされることも、次の実行まで残されることもありません。実行が終了すると、認証局は削除されます。エージェントはこれまでとまったく同じように、ハードコードされたホストに接続します。レコーダーがそれに応答し、セッションは、あたかもURLが最初から設定可能だったかのように確立されます。

ルートが意図的に拒否することは、ルートが実際に行うことと同じくらい重要です。ルートは許可リストに載っているホストだけを読み、それ以外は一切読みません。許可リスト外のホストは、中身を読まれずにトンネリングされ、アドレスとバイト数のみが記録されます。つまり、エージェントが何かに接触したことは証明されますが、交わされた内容は1バイトも記録されません。この境界線は設計上の決定であり、未対応の制限ではありません。同じ原則はOrcaRouterのエージェントファイアウォールにも通底しており、そこでは許可リストは記録の副産物ではなく、製品そのものです。

落とし穴は最初の質問と同じものです。傍受が機能するのは、レコーダーがエージェントを起動したときです。コンテナ内で既に実行中のエージェントはその実行の認証局を受け取ったことがないため、レコーダーの回答を信頼しません。

このマシン上にないエージェント

コンテナには独自の環境があります。シェルで設定したベースURL変数はその内部には届かず、ホスト上のレコーダーは、すでに他の場所、つまりVPS上、CI内、あるいはハーネスがあなたに尋ねずに構築したサンドボックス内に存在するプロセスを起動することはできません。ここで起動ベースのキャプチャが失敗するのは、エージェントが難しいからではなく、レコーダーがそのプロセスに触れることが決してないからです。

まさにこのケースにはorca attachがあります。これは、レコーダーでは起動できないエージェント（コンテナ内やVPS上にあるものなど）を記録します。方向が逆転します。レコーダーがエージェントを起動して環境を渡す代わりに、すでに実行中のエージェントにアタッチして記録するのです。

「attachが2つ目の質問に答えてくれるわけではありません。attachが解決するのは、トラフィックをレコーダーまで届けるところまでです。そのトラフィックがリプレイ可能なセッションになるかどうかは、依然としてワイヤフォーマットが解釈されるかどうかにかかっています。レコーダーが解釈できるフォーマットを話すエージェントをアタッチすれば、リプレイ可能なセッションが得られます。そうでないエージェントをアタッチした場合は壁に突き当たります。この壁は、インシデントの最中に見つけるよりも、意図的に見つけておくほうが安上がりです。」

サブスクリプションのログインでは何が変わりますか？

同じバイナリでも、サインインの方法によって記録可能になったり不可能になったりします。APIキーでサインインしたCodex CLIは、OPENAI_BASE_URLをリコーダーに向ければ、キャプチャされます。それで完了です。同じCLIをChatGPTサブスクリプションでサインインすると、そのエンドポイントとの通信は完全に止まり、代わりにあなたとして認証された独自のバックエンドと通信するため、書き換えるべきオリジンは存在しません。base-URL変数は残っていますが、それをどこに向けても、ハーネスが実際に使用しているサービスになるわけではありません。

これは最初の質問ではなく、2番目の質問が失敗しています。バイトを移動させることはできます。レコーダーはそれらを見ることすらできます。しかし、その会話はレコーダーが代わりを務められないバックエンドに向けられており、その流れはレコーダーが話すAPIではありません。レコーダーが成り得る起点がないため、生成すべきリプレイもありません。

サブスクリプションでサインインするハーネスについての正直な答えは、今日のところ記録できない、というものです。そして有益な教訓は、サインイン方法が記録可能性の判断に含まれるということです。評価や監査証跡のために記録が必要なら、記録対象のセッションはAPIキーで実行し、サブスクリプションはインタラクティブ作業用に維持してください — 記録済みセッションを回帰評価に変える方法がそのループをエンドツーエンドで説明します。また、どのハーネスを標準化するにしても、まずその2つの質問をそれに投げかけてください。私たちはハーネスごとにまさに同じことを行っており、直近でそれを行ったのは Prime Agentハーネス。

要点

1つのコマンドと1つの環境変数で、今日からClaude Codeセッションを記録できます。

• npm i -g orcareplay

• ANTHROPIC_BASE_URL をレコーダーに向けてください

• エージェントを実行する

APIキーを使ったCodex CLIも同じくらい遠くにあります。ハードコードされたURLは、許可リストのみを読み取り（これはOrcaRouterのエージェントファイアウォールが強制するのと同じ原則です）、実行終了時には自身の証明書を忘れるTLSインターセプトへのオプトインが必要です。コンテナまたはVPSには、orca attachを実行するコストがかかります。サブスクリプションログインの場合、記録そのものが失われます。つまり、そのハーネスは記録されず、今日は設定変更もありません。

決定の全体像をひと目で：

• Claude Code — サインイン API キー vs レコーダーへのルート ANTHROPIC_BASE_URL vs 本日の記録可否: はい

• Codex CLI — サインインAPIキー vs レコーダーへのルート OPENAI_BASE_URL vs 本日記録可能 Yes

• プロバイダーURLがハードコードされたハーネス — 任意のサインイン vs レコーダーへのルーティング — レコーダーが開始するオプトインTLS傍受 vs 現時点で記録可能 — はい

• コンテナまたはVPS上のエージェント — 任意のサインイン vs レコーダーへのルーティング orca attach vs 現時点で記録可能か：はい（ワイヤーフォーマットが判明している場合）

• Codex CLI — サインイン: ChatGPTサブスクリプション vs レコーダーへのルート: なし vs 今日記録可能: いいえ

最後の行は、レコーダーへの経路がまったくない唯一の組み合わせです。

ハーネスを導入する前に、最初のインシデントの後ではなく、2つの質問をしてください。答えを得るのは簡単で、その答えによって、いつか必死に必要になるセッションがそもそも存在するかどうかが決まります。

情報源の注記: この記事で述べるすべての挙動と数値（`ANTHROPIC_BASE_URL` と `OPENAI_BASE_URL` のキャプチャパス、フィクスチャ適用後に発生した4つの不具合とその修正、TLS証明書のライフサイクル、許可リストとトンネルの動作、`orca attach`、インストール要件）は、2026-09-04 時点で、名前を挙げた各ハーネスに対して実施した当社自身の検証実行に基づいています。第三者によるベンチマークは実施しておらず、したがって引用もありません。