Claude CodeとCodexの引き継ぎ設計：文脈を保つ3つの方法
この記事で学べること
- Claude CodeとCodexへ任せる工程を分ける判断基準
- 作業状況、完了事項、残タスク、注意点を引き継ぎ文書へ残す方法
- 共通ルールとセッション境界を使って、AI間の文脈切れを減らす仕組み
Claude CodeとCodexの引き継ぎは文脈を文書化する
Claude CodeからCodexへ同じ判断基準で仕事を渡すには、会話ではなく、現在状態、完了済み、残タスク、注意点を読める文書に残します。作業範囲や検証結果が曖昧なままでは、次のAIが別の前提で進めるためです。引き継ぎ文書と共通ルール、自然なセッション境界を組み合わせると、再説明を減らしながら人が確認できる状態を保てます。
この記事では、「次のAIが同じ判断基準で再開できるよう、何を文書へ残すか」という問いに焦点を当て、実行前の前提、作業手順、完了を確かめる方法を扱います。
最後まで読むと、「次のAIが同じ判断基準で再開できるよう、何を文書へ残すか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
引き継ぎ設計はツール選択・文脈切断・保存方法を扱う
このサイトでは、Claude CodeとCodexという2つのAIを同じリポジトリで併用しています。作業の種類によって使い分けており、途中でバトンタッチすることもあります。
この記事では、次の3点をまとめます。
- ClaudeとCodexのそれぞれが向く作業の種類と、使い分けの判断基準
- バトンタッチ時に文脈が切れるという問題の原因
- 文脈を引き継ぐための3つの対処方法
ClaudeとCodexの基本的な違い
Claude Code は、コードベースを読み、ファイルを編集し、コマンドを実行できるコーディングエージェントです。ターミナルだけでなく、IDE、デスクトップアプリ、ブラウザからも利用できます。[1] 私は主にIDE上で使っており、最初の計画、設計の議論、エラー原因の切り分けなど、創造的な判断が必要な場面で会話しながら進めています。
Codex（OpenAI）も、コードの作成、理解、レビュー、デバッグ、開発タスクの自動化に使えるコーディングエージェントです。[2] 現在のCodexには、ターミナルで対話しながら進めるCLI、IDE拡張、デスクトップアプリ、クラウドでバックグラウンド実行するWeb/Cloudの面があります。[3][4][5] 私はCodexも主にIDEから使い、必要に応じてまとまった差分の作成やレビューに寄せています。
この記事での使い分けは、Claude CodeとCodexの全機能比較ではありません。モデルのアップデートが激しいため、正直なところ、利用方法も更新されたモデルの性質を見極めながら都度調整しています。そのうえで、このサイトではClaude Codeを計画や設計の議論に、Codexをまとまった変更や反復可能なレビュー・実装に寄せています。
Claude Codeには計画・エラー調査・方向性整理を任せる
Claudeには、最初の計画、設計の議論など、創造的な作業を依頼することが多いです。
計画・設計の検討：「この機能はどう実装すべきか」「この構成で問題はないか」という確認をしながら進める場面では、Claude Codeとの対話が有効です。理由を確認しながら別案を比較できるため、判断を積み重ねながら進められます。
エラー調査：エラーが発生したとき、原因の特定には複数の仮説を立てて確認する作業が伴います。「このログの意味は何か」「次に確認すべきことは何か」という対話が必要な場面では、Claudeが向いています。
方向性の整理：記事や機能の目的、読者に伝える順番、どの判断を先に固めるかを相談する作業もClaudeに寄せています。実装前の曖昧な段階で、選択肢を出しながら整理しやすいためです。
Codexには一括変換と基準に沿った反復レビューを任せる
Codexには、パターンが決まっていて繰り返し実行できる作業や、まとまった差分を作ってから確認したい作業を任せています。私の運用では、Codexはプロンプト忠実度が高く、レビュードキュメントに沿った検知が得意だと感じています。Codex CLIは対話型でも使えますが、私はこのサイトでは「指示を渡し、変更内容を確認し、必要なら追加指示を出す」という進め方で使うことが多いです。[3]
同じパターンの一括変換：「このディレクトリのファイル全体に、同じfrontmatter（Markdown記事の先頭に置くtitle、description、dateなどの設定情報）フィールドを追加する」といった作業は、Codexに向いています。変更のパターンが明確で、途中の判断が少ない場合、まとまった差分として確認しやすくなります。
レビュードキュメントに基づく一括レビュー：対象ファイルのリストとレビュードキュメントを渡して、「各ファイルを同じ基準で確認する」という作業は、Codexに任せやすいです。判断基準が文書化されているほど、検知結果を後から確認しやすくなります。
Claude Codeで方針を決め、Codexへ反復作業を引き継ぐ
あるとき、ブログ記事の英語版を複数作成する作業がありました。
最初はClaude Codeで取り組みました。日本語版の内容を確認し、翻訳の方針を議論し、1本目を一緒に作りました。この段階では、「どう訳すか」「日本語の文脈をどう英語で表現するか」という判断が必要だったため、対話型のClaudeが適していました。
1本目が完成した時点で翻訳のパターンが明確になりました。残りの記事は同じパターンで変換するだけです。ここでCodexに引き継ぎ、残りの英語版を一括作成する指示を出しました。
Claudeで方針を固め、Codexで繰り返し部分を処理する、という流れです。
途中判断の多さと反復性でClaude CodeとCodexを選ぶ
どちらを使うかを決めるときの基準として、以下を確認しています。
| 確認項目 | この運用でClaude Codeが向く | この運用でCodexが向く |
|---|---|---|
| 途中で判断が必要か | はい | いいえ |
| リアルタイムで細かく確認したいか | はい | いいえ |
| 作業が繰り返しパターンか | いいえ | はい |
Codexにも対話型のCLIやIDE拡張があり、Claude CodeにもWebやデスクトップアプリなどの面があります。そのため、この表は製品の限界ではなく、このサイトでの使い分けの目安です。どちらか一方だけで完結する必要はなく、途中でバトンタッチすることも選択肢の一つです。
Git履歴からClaude CodeとCodexの作業分担を確認する
この使い分けは感覚だけで決めているわけではありません。2026年6月24日時点のローカルGit履歴を、Claude関連パス、Codex関連パス、共通ハーネス（AIに渡すルール、作業手順、検証方法をまとめた仕組み）関連パスに分けて集計すると、作業の性質に差が出ていました。
ここでの集計は、実際にどのモデルが各コミットを作成したかを証明するものではありません。CLAUDE.md、.claude/、Claude関連docs/blogをClaude側、AGENTS.md、.codex/、ChatGPT/Codex関連docs/blogをCodex側、shared/ と AGENT_HARNESS_DESIGN.md を共通ハーネス側として見た、リポジトリ内の変更傾向です。
| 集計対象 | コミット数 | 変更ファイル数 | 追加行 | 削除行 | 読み取れる傾向 |
|---|---|---|---|---|---|
| Claude関連パス | 65 | 150 | 31,982 | 9,809 | 初期の設計、Claude Code向けドキュメント、対話しながら固めたルールが多い |
| Codex関連パス | 20 | 126 | 11,394 | 2,513 | Codex docs、Codex harness、まとまった構造追加や反復的な整備が多い |
| 共通ハーネス関連パス | 41 | 68 | 9,218 | 1,231 | 両方のAIが参照するルール、検証、引き継ぎの整備が継続している |
この結果からは、Claude Codeは判断や設計を含む作業の起点になりやすく、Codexは方向性が固まった後の構造追加や一括整備に使いやすい、という運用が見て取れます。しかし、モデルのアップデートは激しく、正直なところ、実際の使い方も更新されたモデルの性質を見極めながら、その時点で最適な形に調整しています。一方で、shared/ の変更量も大きいため、最終的には「Claude用」「Codex用」と分けるだけでは足りません。両方が同じ前提を読める共通ハーネスを育てることが、引き継ぎの安定につながります。
バトンタッチで生じる問題：文脈が切れる
Claude CodeからCodexへ切り替えるとき、Claude Codeのセッション内容は自動では引き継がれません。Codex CLIには過去のCodexセッションを再開する機能がありますが、これはClaude Codeの会話履歴を取り込む仕組みではありません。[3] どのファイルを変更したか、何が完了して何が残っているか、どのような判断で現在の状態になったか。Claude Code側で決めたことは、Codexへ改めて説明する必要があります。
さらに、AIとの会話が長くなるほどトークン（AIが入力や出力を処理するときの文字の単位で、使用量や文脈の長さに関係するもの）消費が増え、古い会話は参照できなくなります。「文脈が切れる」問題と「Codexへの説明の繰り返し」という問題が重なると、作業が複雑なほど負担が大きくなります。
現在状態と残タスクを引き継ぎ文書へ記録する
agent-handoff（現在状態と残タスクを渡す引き継ぎ文書）は、Codexが作業を引き継いだときに最初に読むメモです。
人間のチームでも、担当者が変わるときに引き継ぎ文書を用意します。それと同じ考え方をClaude CodeからCodexへの文脈共有に適用したものです。文書の内容は以下の4項目を基本としています。
- 現在の作業状況：何に取り組んでいる最中か
- 完了済みのこと：前回のセッションで終わったこと
- 残タスク：次のセッションで対応が必要なこと
- 注意点：判断の経緯、制約、試したが機能しなかったこと
これらを簡潔にまとめたファイルを用意しておくことで、Codexへの引き継ぎ時に「このファイルを読んでから作業を再開してください」と伝えられます。
handoff文書は現在状態・完了済み・残タスク・注意点を記録する
以下はhandoff文書の構成例です。
## 現在の作業状況
サイトのブログ記事5本を新規作成する作業を進めています。
日本語版は3本完了、英語版はまだ着手していません。
## 完了済みのこと
- `claude-codex-handoff-workflow.md`（日本語版）の作成
- `japanese-ai-instruction-tips.md`（日本語版）の作成
- `feature-branch-conflict-retreat.md`（日本語版）の作成
## 残タスク
- 残り2本の日本語版を作成する
- 全5本の英語版を作成する
- `npm run review:content` で検証する
## 注意点
- 英語版の一人称は `I` のみ（`we` / `our` / `us` は禁止）
- `npm run build` はユーザーの明示承認なしに実行しないnpm run agent:handoff による生成
このプロジェクトでは、npm run agent:handoff というコマンドでhandoff文書の雛形を生成できる仕組みを用意しました。
手動でファイルを毎回ゼロから書くのは負担が大きいため、スクリプトがgitの変更履歴を参照しながら「変更されたファイルの一覧」と「直近のコミットメッセージ」を組み合わせたドラフトを出力します。生成されたファイルは .agent-handoff/current.md に保存され、作業者が内容を確認・補足してから使用します。
生成されたファイルはコミットしません。あくまでセッション間の引き継ぎに使う一時的なメモとして扱っています。
共通ルールをshared/配下に集約する
Claude CodeとCodexの両方が守るルールは、shared/ 配下に集約しています。Claude Codeは CLAUDE.md、Codexは AGENTS.md を起点として読み、どちらも同じ shared/rules/ を参照します。ツールごとの初期指示ファイルが異なっても、引き継ぐ方針を二重管理せずに済みます。
新しいルールを追加したとき、shared/rules/ の1ファイルを更新するだけで両方のAIに反映されます。バトンタッチのたびにルールの差分を説明する手間が省けます。
会話が長くなったらセッションを区切る
同じ作業を1つのセッションで長く続けると、会話履歴が積み重なってトークン消費が増えます。Claude Code側の作業に区切りが来たら、agent-handoff文書を更新し、Codexのセッションをその文書から始める流れにしました。
セッションを切り替えるたびに少し時間がかかりますが、長い会話を続けるよりコストを抑えられる場合が多いと感じています。区切りのタイミングは、「1つの機能が完成したとき」や「1本の記事が完成したとき」など、作業に自然な区切りが来た瞬間が適しています。
まとめ：引き継ぎは4項目の文書と共通ルールから始める
このサイトでのClaude CodeとCodexの使い分け
- Claude Codeは最初の計画、設計の議論、原因調査など、創造的な判断が必要な作業に向く
- Codexは繰り返しパターンの実装や、レビュードキュメントに基づく一括レビューなど、まとまった差分や検知結果として確認したい作業に向く
- 使い分けの基準は「途中で判断が必要かどうか」と「判断基準を文書として渡せるかどうか」
- これは製品全体の限界ではなく、私がこのサイトで使っている実行面に基づく判断
- Git履歴のpathベース集計でも、Claude関連パスは設計・判断寄り、Codex関連パスは構造追加・一括整備寄りの傾向が見える
- モデルの性質は更新ごとに変わるため、固定的な分担ではなく、その時点で最適な使い方に調整している
- 1つの作業をClaudeで始めてCodexに引き継ぐという流れも有効
文脈を引き継ぐ3つの方法
- agent-handoff文書：4項目（現在の状況・完了済み・残タスク・注意点）を記録し、Codexへの再説明を省く
shared/集約：共通ルールを1か所に置き、バトンタッチ時のルール差分をなくす- セッションの区切り：作業の自然な区切りでセッションを切り替え、トークン消費を抑える
最初の行動は、次の引き継ぎで現在状態、完了済み、残タスク、注意点の4項目だけを埋めることです。製品間で会話履歴そのものが移るわけではなく、モデルの性質も更新されるため、引き継ぎ文書は自動継続の保証ではなく、人が確認できる再開地点として使います。
参考文献
- Anthropic, Overview, Claude Code Docs
- OpenAI, ChatGPT and Codex documentation, ChatGPT Learn
- OpenAI, Codex CLI, ChatGPT Learn
- OpenAI, Features, ChatGPT Learn
- OpenAI, Codex cloud, ChatGPT Learn
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。