Claude Code→Codexの移行手順と設定・履歴の確認方法

Claude Code→Codexの移行手順と設定・履歴の確認方法

Claude CodeからCodexへ移るとき、設定や会話をすべて手作業で移す必要はありません。公式には取り込み機能があり、引き継ぐ項目を選べます。ただし、移せた設定がそのまま期待どおりに働くかは確認が必要です。10月14日にはCodexでGPT-5.5の提供範囲も変わりました。本記事では2026年10月17日時点の公式資料をもとに、設定と履歴の取り込みから最初の修正確認までを説明します。

結論powered by Claude

Claude Codeからの移行には、ChatGPTデスクトップアプリの取り込み画面とCodex CLIの/importを使えます。対象を選んで持ち込む方式で、移行元の設定は変更・削除されません。まず小さなプロジェクトで試すと、戻れる状態を保ちながら違いを確認できます。

CLIが取り込む会話は直近30日間の最大50件です。また、実行中のタスク、リモートのセッション、ローカルのapp-serverデーモンへの接続中には使えません。手順を始める前に、必要な会話が対象に入るか、現在の利用場所が条件を満たすかを確認します。

取り込み後に見るべきなのは、指示・権限・モデル・接続の状態です。ファイルが存在するだけでは移行完了と判断できません。読み取り中心の調査を依頼し、その後に小さな修正とテストを行うことで、想定した範囲で作業できるかを確かめます。

目次 (9)

Claude CodeからCodexへ移す前に決めること

「claude code to codex」で調べている人がまず決めたいのは、移行の成功条件です。過去の会話を参照したいのか、プロジェクトの規約を引き継ぎたいのか、普段の修正作業をCodexで続けたいのかで、確認する対象は変わります。本記事では、同じプロジェクトの作業をCodexで再開し、差分とテスト結果を人が判断できる状態を目標にします。

移行前のメモには、対象フォルダー、途中の作業、未解決の問題、普段使うテストの実行方法を残してください。会話全体を読み直さなくても再開できるように、「何を変えたか」「何をまだ試していないか」を短く分けて記録すると役立ちます。これは製品の必須操作ではなく、取り込み対象から漏れた情報を補うための実務上の提案です。

OpenAIの取り込み機能の公式説明では、元のエージェントの設定を変更したり削除したりしないと案内されています。ただし、既存プロジェクトと同じフォルダーを使う場合、その中のコードをCodexで変更すれば作業ファイルは変わります。設定の保持とコードの変更は区別し、着手前の差分を把握しておきましょう。

アプリとCLIで異なる取り込みの入口

公式資料では、ChatGPTデスクトップアプリとCodex CLIの両方からClaude Codeの情報を取り込めます。画面上で対象を見ながら選ぶならアプリ、ターミナルを中心に使うならCLIという選び方ができます。両方で一度に取り込むより、最初に使う入口を一つに絞ると、どの操作で何が追加されたかを追いやすくなります。

アプリの案内では、設定、指示、スキル、プラグイン、プロジェクト、最近の会話などが対象に挙げられています。すべての項目が同じ形で動くことを保証する説明ではありません。選択画面に現れる対応項目を確認し、移行元の機能名だけで互換性を判断しないことが大切です。接続先への再サインインなど、取り込み後の作業が残る場合もあります。

Step 1: アプリで対象を選んで取り込む

ChatGPTデスクトップアプリの設定で「Import」を開きます。設定項目に見当たらない場合は「General」内の「Import other agent setup」を確認します。取り込みを開始してClaude Codeを選び、次の画面で必要な対象を選択します。終了後は取り込まれたプロジェクトや会話を開き、目的の作業が見えるか確かめます。画面名や表示位置は利用中の版によって変わる可能性があるため、公式資料と実際の画面を照合してください。

Step 2: CLIではローカルの会話から取り込む

Codex CLIを対話的に使っている画面で /import を入力し、Claude Codeを選んで、対応する設定やプロジェクトのファイル、最近の会話を選択します。これは端末の一般的なコマンド入力欄に直接打つ命令ではなく、Codex CLI内の操作です。公式資料が示す利用条件を満たすローカルのセッションで行い、取り込み後の設定を確認してから開発作業を再開します。

会話履歴の範囲と再開メモを確認する

Codex CLIの取り込み対象となる会話は、公式資料では直近30日間の最大50件です。古い会話や、それを超える履歴まで移る前提で作業を組むと、必要な判断経緯が見つからなくなるおそれがあります。この数値はCLIについての説明であり、デスクトップアプリにも同じ上限が適用されるとは本記事では断定しません。使う入口の対象画面で、必要な会話を確認してください。

履歴が見えていても、最後の結論が現在のコードと合っているかは別に確かめます。途中で方針を変えた会話では、冒頭の設計案と最後の実装が異なる場合があります。Codexに渡す再開メモには、採用した方針、変更してよい範囲、完了条件を明記すると、過去の案を誤って採用する可能性を減らせます。

また、公式資料によると /import は実行中のタスク、リモートのセッション、ローカルのapp-serverデーモンに接続している状態では利用できません。項目が使えない場合は、まずその条件に当てはまっていないかを確認します。取り込みができない状況で、設定ファイル一式を見当で上書きするより、現在の作業を区切って適切な入口からやり直すほうが原因を追いやすくなります。

指示ファイルはAGENTS.mdの適用範囲を見る

公式の取り込み対応表では、指示ファイルの移行先として AGENTS.md、設定の移行先として config.toml が示されています。ただし、取り込まれた文章の存在と、次の作業でその文章が有効になることは同じではありません。プロジェクトのどの場所で作業を始めるかによって、読み込まれる指示の範囲や優先関係が変わるためです。

OpenAIのAGENTS.mdの公式資料では、全体の指示に加え、プロジェクトのルートから現在の作業ディレクトリまでの指示を組み合わせる仕組みが説明されています。より近い階層の指示が後に適用されるため、ルートだけを見て「規約が移った」と判断しないようにします。特定のサービスや画面を修正するなら、その場所に固有の指示も確認します。

取り込み後は、Codexに「この作業で参照する指示ファイルと、守るべきテスト方法を要約してください。まだ変更はしないでください」と依頼すると確認しやすくなります。これは本記事の確認用の文例です。期待する規約が回答に出ない場合は、配置場所、作業を始めたフォルダー、上書き用の指示の有無を調べます。無関係な過去の規約まで増やすより、対象作業に必要なルールを短く保つほうが見直しやすくなります。

権限と外部接続は取り込み後に確認する

Claude Codeで許可していた操作が、Codexでも同じ扱いになるとは限りません。公式の移行資料は、取り込んだスキルやエージェントの制限、外部接続、引数やファイルの位置に依存する指示などを確認するよう求めています。移行が完了した表示だけで、すべての接続や操作が使えると判断しないことが重要です。

Codexでは、操作できる範囲を制御するサンドボックスと、どの場面で承認を求めるかという方針を分けて考えます。承認とセキュリティの公式資料にも、この二つの役割が説明されています。承認の表示が出たときは、何を読んだり変更したりする操作なのかを確認し、単に以前のツールで通ったという理由で権限を広げないようにします。

取り込み後の確認は、次の順序で行うと作業範囲を判断しやすくなります。

  1. 対象プロジェクトと、変更を許すフォルダーが合っているか確認する。
  2. 調査だけを依頼し、変更しないという条件を守っているか確認する。
  3. 外部接続に追加の設定が必要と表示されたら、対象の接続だけを整える。
  4. 小さな編集を依頼し、変更したファイルと実行した確認内容を読む。

取り込み後のアプリに対応が必要な項目が表示された場合、公式の案内に沿って設定を完了します。接続情報やアカウントの中身を会話へ貼り付けて問題を解こうとする必要はありません。まず不足している項目の名前とエラーの内容を確認し、必要な操作を絞り込んでください。

10月の提供変更を踏まえてモデルを選ぶ

2026年10月17日時点で移行するなら、過去に作ったCodexの設定例に含まれるモデル名にも注意が必要です。OpenAIの10月14日の更新履歴では、ChatGPTでサインインして使うCodexでGPT-5.5の提供が終了したことが示されています。OpenAI APIと、APIキーで認証するCodexのセッションは、この変更の対象外とされています。

同じ更新履歴は、契約や利用するクライアントで使える場合にGPT-6.1 Solを使うよう案内しています。したがって、移行時に古い記事のモデル名をそのまま固定するのではなく、実際の選択画面と組織の利用設定を確認します。この変更はClaude Codeからの取り込み機能の公開日を示すものではなく、移行先のモデル設定を今見直す理由として捉えてください。

モデルを変えれば、同じ依頼でも調査の進め方や説明量が変わる場合があります。最初の比較では、プロジェクト、依頼内容、完了条件をそろえ、差分の正しさとテスト結果を見ると判断しやすくなります。回答速度だけで移行の成否を決めず、人が手直しした箇所や、追加で説明し直した条件も記録しておきましょう。

小さな修正を一件終えて移行を確かめる

移行直後の確認には、既知の不具合や短い文言修正など、期待する結果を具体的に説明できる課題が向きます。大きな機能追加では、移行設定の問題と実装方針の問題が重なってしまいます。最初の一件では対象ファイル、変えてはいけない挙動、必要なテストを伝え、結果を読み切れる規模に絞ります。

たとえば「指定の入力条件で出るエラーを直してください。公開されている関数の引数は変えず、関係するテストを実行し、未確認の点を報告してください」という依頼なら、変更範囲と完了条件を一緒に伝えられます。テストの実行方法が分からない場合には、まず既存の資料から確認するよう依頼し、推測した手順で成功したことにしないよう求めます。

  1. 最初の依頼ではコードの変更をせず、原因候補と確認方法を説明してもらう。
  2. 説明を確認した後に、合意した範囲の修正を依頼する。
  3. 差分を読み、意図しないファイルや設定が変わっていないか確認する。
  4. テスト結果と未確認の項目を確認し、次の依頼に進むか判断する。

この一件を終えたら、引き継いだ指示が働いたか、必要な接続が使えたか、モデルが利用できたかを振り返ります。問題があった項目だけを修正して再確認すれば、設定全体を入れ直す必要はありません。取り込み機能で情報を移し、実際の作業で使える状態まで確かめることが、Claude CodeからCodexへの移行の区切りになります。

参考になったら ♡
Codexer Navi 編集部
@codexer_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。