Claude CodeとCodexをまたぐ引き継ぎで何が起きるのか
Claude Codeで設計し、Codexでレビューする開発フローで、なぜ前提や判断理由を説明し直すことになるのかを整理します。会話履歴だけでなく、調査履歴や作業履歴を渡す考え方です。
複数エージェントをまたぐと文脈が切れる
Claude Codeで設計した判断、Codexで見つけたレビュー観点、Cursorで直した差分は、それぞれのツールの中に分かれて残ります。次のAIエージェントへ渡したいのは会話ログそのものよりも、なぜその判断をしたのかという作業の流れです。
最近の開発では、Claude Codeで設計を相談し、Codexで差分や実装方針を検証し、Cursorで編集し、ターミナルではGitHub Copilotを使う、というように複数のAIエージェントを横断することが増えました。
便利な一方で、それぞれのエージェントは互いの会話を見ていません。Claude Codeで決めたことをCodexに説明し直し、Codexで見つけた懸念をCursorに説明し直す。人間が毎回ブリッジ役になります。
この説明コストは小さく見えますが、毎朝、毎セッション、毎レビューで積み重なります。特に、作業の途中で日をまたいだときに痛みが大きくなります。
会話履歴だけでは足りない
エージェント横断の記憶というと、まず会話履歴の共有を考えます。しかし、開発の意思決定はチャットに入る前にかなり進んでいます。
Stack Overflowを読む、GitHub Issueを追う、VS Codeで試しに実装して消す、ログを眺める、ブラウザでドキュメントを確認する。こうした前段の探索は、どのエージェントの会話履歴にも残りません。
つまり、チャットログをつなぐだけでは、エージェントは『何を言ったか』は見られても『なぜそう考えたか』までは追いにくいままです。
作業文脈をタイムラインとして持つ
Contextbergでは、エージェント会話履歴だけでなく、画面、ブラウザ履歴、アプリ利用、キーストロークをまとめて1本のタイムラインにします。
たとえば、月曜夜にEdgeでOAuthの仕様を読み、VS Codeで認証コードを触り、Codexに差分レビューを投げ、火曜朝にClaude Codeで続きを相談する。この流れ全体を、エージェントが参照できる文脈として残します。
重要なのは、どのエージェントが話したかではなく、ユーザーの作業がどの順序で進んだかです。エージェントをまたいでも、作業者は同じ人間なので、記憶は人間の作業単位で持つ方が自然です。
MCPを出口にする理由
記憶をアプリ内チャットだけに閉じると、また別のサイロが増えます。Claude CodeにもCodexにもCursorにも渡したいので、ContextbergではMCPを出口にしています。
MCP経由でget_activityやget_agent_history、read_ltmを呼べるようにすれば、各エージェントは自分の会話履歴だけでなく、ユーザーの作業履歴全体を必要な範囲で読めます。
これにより、人間が『昨日はここまでやって、途中でこのIssueを読んで、この方針にした』と毎回説明する回数を減らせます。
最初に狙う体験
最初に狙っている体験はシンプルです。月曜に作業を止め、火曜にClaude Codeを開いて『昨日の続き、どこからやる？』と聞いたら、エージェントが前日の作業文脈を読んで返せること。
その返答には、会話履歴だけでなく、読んでいたドキュメント、触っていたファイル、見ていた画面、Codexで確認した差分まで含まれていてほしい。
Contextbergは、そのためのローカルメモリ層です。エージェントを賢くするというより、エージェントが失っている人間側の文脈を渡すための土台です。
引き継ぎで渡すべき情報
レビュー引き継ぎで重要なのは、会話全文ではありません。次のエージェントが判断を再開するために必要な、短くて検証できる情報です。
| 文脈 | 渡す内容 | 渡さない方がよいもの |
|---|---|---|
| 目的 | 何を直したかったのか、なぜその変更が必要だったのか | 最初の曖昧な相談全文 |
| 制約 | 採用しなかった案、避けたい依存、既存パターン | 古い仮説や一度捨てた思いつき |
| 差分 | 触ったファイル、重要な関数、未確認の影響範囲 | 無関係なログや大きすぎるbuild output |
| 検証 | 通したテスト、失敗したテスト、再現手順 | 結果だけで原因が分からない一言メモ |
| 調査元 | 読んだIssue、公式doc、Stack Overflow、関連PR | 開いたが読んでいないページの羅列 |
実際に聞くプロンプト
Contextbergで作業文脈が読める状態なら、Codex側では最初からレビューに入るのではなく、まず前提を復元させます。
昨日Claude Codeで進めていた認証リファクタについて、
読んでいたIssue、触ったファイル、決めた方針、残っている不安を分けて要約して。
そのうえで、今回の差分レビューで最初に見るべき箇所を3つ挙げて。昨日の認証リファクタは、Claude CodeでAccessTokenStoreの責務分離を相談し、最終的にDPAPIでrefresh tokenを保護する方針に寄せています。
読んでいたもの:
- GitHub Issue: token refreshが並列実行された時のrace condition
- Microsoft docs: ProtectedData.Protect / CurrentUser scope
- Stack Overflow: DPAPI利用時の例外処理とユーザー切り替え時の注意
触っていたファイル:
- src/auth/AccessTokenStore.ts
- src/auth/refreshToken.ts
- tests/auth/token-refresh.test.ts
決めた方針:
- token保存処理はAccessTokenStoreに寄せる
- refresh処理は冪等にする
- logout時にPKCE stateとrefresh tokenを同時に消す
残っている不安:
- refresh失敗時に古いtokenが残らないか
- 並列refresh時に片方の結果で上書きされないか
- logout後にbackground taskが再保存しないか
今回の差分レビューで最初に見るべき箇所:
1. refreshToken.ts の排他制御
2. logout処理が保存済みtokenとPKCE stateを両方消しているか
3. token-refresh.test.ts に並列refreshとlogout直後のケースがあるかこの聞き方にすると、エージェントは単にdiffを見るだけでなく、なぜそのdiffが生まれたかを踏まえてレビューできます。レビュー品質を上げるというより、レビュー開始前の説明コストを減らす効果が大きいです。