Codexチャットをフォークする方法
/fork で現在のチャットをフォークする
Codex CLIで /fork と入力してEnterキーを押します。スラッシュコマンドのドキュメントには、次の手順が記載されています。「Codexがチェックアウトの選択肢を提示した場合は、現在のディレクトリまたは新しいworktreeを選択します。」その結果、ドキュメントの言葉を借りれば、「Codexは現在のチャットを新しいIDを持つ新しいチャットにクローンし、元のトランスクリプトはそのまま残すため、並行して別のアプローチを探索できます。」
この「新しいID」は後で重要になります。元のチャットとフォークされたチャットは、この時点からそれぞれ独自の履歴を持つ2つの独立した保存済みチャットになります。
ターミナルから codex fork で保存済みのチャットをフォークする
現在開いていないチャットをフォークするには、ターミナルから codex fork を実行します。コマンドラインリファレンスには、「デフォルトでは、codex fork はセッションピッカーを開きます。代わりに --last を追加すると、最新のセッションをフォークします」と記載されています。セッションIDを直接渡すことも可能です。
チャットが保存されたディレクトリとは異なるディレクトリにいる場合、Codexはどこで作業するかを尋ねます。リファレンスには、「現在と保存されたセッションのディレクトリが異なる場合、codex fork は codex resume と同じ作業ディレクトリのプロンプトおよび tui.resume_cwd 設定を使用します」とあります。
過去のメッセージからフォークする
分岐点が「現在」ではないこともあります。Codexが回避したい方向に進む前の、3つ前のメッセージである場合などです。CLIリファレンスには、ショートカットが記載されています。「コンポーザーが空の状態でEscapeキーを2回押すと、前のユーザーメッセージを編集し、その時点からチャットをフォークできます。」
Codexの「新機能（What's new）」ページによると、2月にアプリにフォーク機能が追加され（「アプリにチャットのフォーク機能も追加されました」）、3月のエントリーには「過去のメッセージからチャットをフォークできるようになり、元のルートを失うことなく新しいアプローチを簡単に試せるようになりました」と記録されています。
/side でサイドの質問をする
すべての寄り道に完全なフォークが必要なわけではありません。スラッシュコマンドのドキュメントでは、/side を「メインチャットから切り替えることなく、現在のチャットから一時的な（ephemeral）フォークを開始する」方法として説明しています。サイドチャットのトランスクリプトは「親チャットとは別」であり、サイドチャットにいる間もTUIは親チャットのステータスを表示し続けます。
計画に関する簡単な質問、リスクの確認、メインの会話を散らかしたくない説明の要求などに使用します。ドキュメントには、「/side は別のサイドチャット内およびレビューモード中は利用できません」と注記されています。
インタラクティブセッションを開始せずにフォークする
スクリプト用として、codex exec fork は保存されたセッションを新しいセッションにコピーします。リファレンスには、「プロンプトがない場合、Codexはターンを開始せずにフォークを作成します」とあります。プロンプトを追加すると、フォークはすぐにその作業を開始します。
フォークに引き継がれるもの、残されるもの
会話履歴は引き継がれる
フォークは、フォークした時点までの完全なトランスクリプトから始まります。タスク、関連するファイル、またはすでに決定された事項を再説明する必要はありません。これが、新しいチャットを始めるのではなく、フォークを使用する主な理由です。
ファイルは選択したチェックアウトに依存する
ここが事前に計画しておくべき部分です。フォークは会話をコピーしますが、作業ディレクトリはコピーしません。現在のディレクトリにフォークした場合、元のチャットとフォークされたチャットは同じファイルを操作することになります。フォーク側が変更した内容は元のチャットのディスク上にも反映され、その逆も同様です。
コードを編集する実験を行う場合は、worktreeにフォークしてください。CLIでは、codex fork <SESSION_ID> --worktree で実行できます。リファレンスには、これには「明示的なセッションIDとローカルでの実行が必要であり、--last やセッションピッカーはサポートしていません」と記載されています。/fork を使用する場合は、Codexがチェックアウトの選択肢を提示したときに新しいworktreeを選択します。
worktreeのドキュメントでは、得られるものについて次のように説明されています。「各worktreeにはリポジトリ内のすべてのファイルの独自のコピーがありますが、コミットやブランチなどに関する同じメタデータ（.git フォルダ）をすべて共有します。」デスクトップアプリが管理するworktreeの場合、「開始コミットは、チャットを開始したときに選択されたブランチの HEAD コミット」であり、「ローカルの変更があるブランチを選択した場合、Codexは未コミットの変更もworktreeに適用します。」
Gitが無視（ignore）するファイルは扱いが異なります。ドキュメントには、「Codexは .worktreeinclude に一致する無視されたファイルのみをコピーし、Gitが追跡していない他のローカルファイルはコピーしません」とあります。プロジェクトの実行に .env ファイルが必要な場合は、それを .worktreeinclude にリストしておかないと、実験が元のチャットと同じように開始できない可能性があります。ただし、1つの例外は自動的に処理されます。「Codexは無視された AGENTS.override.md をローカルの管理対象worktreeに自動的にコピーします。」ドキュメントは、この挙動が「ローカルのChatGPTデスクトップアプリが管理するworktreeに適用され、リモートのworktreeやコマンドラインから自分で作成したGitのworktreeには適用されません」と付け加えています。
指示はチャットではなくリポジトリから取得される
AGENTS.md は会話の一部ではありません。リポジトリ内のファイルであるため、フォークされたチャットは元のチャットと同じ追跡対象の AGENTS.md を読み込みます。worktreeにフォークしてそこで AGENTS.md を編集した場合、元のチャットが独自のチェックアウトに達するまで、その変更は元のチャットには表示されません。CodexがAGENTS.mdのルールをスキップする理由に関するガイドでは、Codexがこれらのファイルをどのように見つけて結合するかを解説しています。
メモリはマシンごと、チャットごとのスイッチ付き
Codexのローカルメモリは、デフォルトで ~/.codex/memories/ の下にあるCodexのホームディレクトリに保存されます。これらはそのマシン上のすべてのチャットで共有されるため、フォークされたチャットも元のチャットと同じストアを利用します。チャットごとに設定できるのは、そのチャットがメモリを使用し、メモリに貢献するかどうかです。メモリのドキュメントには、「現在のチャットのメモリの挙動を制御するには /memories を使用します」および「チャットレベルの選択は、グローバルなメモリ設定を変更しません」と記載されています。
ドキュメントには、フォークが元のチャットの /memories の選択を引き継ぐかどうかは明記されていないため、重要である場合はフォーク先で確認してください。あえて良くないアイデアを試すためにフォークする場合、そのチャットが将来のメモリに反映されるのを避けたいかもしれません。Codexローカルメモリに関するガイドでは、メモリがどのように生成され、リセットされるかを解説しています。
フォークでの発見はフォーク内に留まる
フォークのドキュメントでは、チャットを新しいチャットにコピーすることについて説明しています。フォークした会話を元のチャットにマージして戻す方法については説明されていません。フォークで発見されたことは、すべてフォークのトランスクリプト内に留まります。実験がうまくいったとしても、あなたが伝えない限り、元のチャットはそのことを知りません。
共有されたスナップショットはフォークできない
誰かが共有したCodexチャットを送ってきた場合、それを読むことはできますが、相手が中断したところから再開することはできません。ドキュメントには次のように記載されています。「共有されたスナップショットから元のスレッドをフォークすることはできません。スナップショットを添付ファイルとしてインポートし、新しいスレッドで参照することは可能です。」また、共有されたスナップショットには多くの情報が欠落しています。「元のスレッドのツール呼び出し、シェルコマンド、ツールの入力や出力は含まれません。」
フォークが失敗する原因となる思い込み
フォークが独自のファイルを持っていると思い込むこと。 フォークが持っているのは独自の会話履歴です。ファイルは、選択したチェックアウトに依存します。現在のディレクトリにいる場合、両方のチャットが同じコードを編集します。
フォークでの発見を元のチャットが自動的に学習すると思い込むこと。 2つのトランスクリプトは、フォークした時点から完全に分離されています。
worktreeにプロジェクトに必要なものがすべて揃っていると思い込むこと。 追跡対象のファイルは揃っていますが、無視されたファイルは .worktreeinclude に一致するもののみです。
単に質問したいだけなのにフォークしてしまうこと。 単発の確認のために完全なフォークを行うと、管理すべき不要な保存済みチャットが増えてしまいます。そのような場合は /side を使用するように設計されています。
作業が実際には分岐していないのにフォークしてしまうこと。 Codexのベストプラクティスは明確です。「一貫した作業単位ごとに1つのチャットを維持してください。作業が依然として同じ問題の一部である場合は、推論のプロセスが保存されるため、同じチャットに留まる方が良い場合が多いです。作業が本当に分岐する場合にのみフォークしてください。」
解決策：作業が分岐するかどうかを判断し、適切なチェックアウトにフォークし、結果を持ち帰る
ステップ1：フォーク、サイドチャット、またはそのどちらも不要かを判断する
これから行おうとしている作業について考えてみてください。現在の作業に関する簡単な質問であれば、/side を使用します。異なるコードを生成する、本質的に異なるアプローチであれば、フォークします。同じ問題の次のステップであれば、現在のチャットに留まります。
分岐点が過去にある場合は、CLIでEscapeショートカットを使用し、取り消したいターンの前からフォークを開始します。
ステップ2：両方のチャットがファイルを操作する場合はworktreeにフォークする
実験でコードを編集し、元のチャットのファイルをそのまま残したい場合は、worktreeにフォークします。実際に使用する前に、プロジェクトの実行に必要なものがworktreeに揃っているか確認してください。無視されたセットアップファイルを .worktreeinclude に一度追加しておけば、すべての管理対象worktreeにそれらが適用されます。
何も編集せずに計画を比較するためにフォークするだけであれば、現在のディレクトリにフォークしても問題ありません。
次に、区別できるように両方のチャットに名前を付けます。ドキュメントによると、/rename コマンドは「トランスクリプトを変更せずに、保存されたチャット名を更新します」。元のチャットには採用しているアプローチの名前を、フォークには代替案の名前を付けます。デスクトップアプリでは、継続する方をピン留めしておきます。
ステップ3：フォークで決定した内容を記録し、持ち帰る
実験が終了したら、どちらのチャットを継続するかを決定します。フォークのアプローチが採用された場合は、そのままフォークで作業を続けるか、変更内容、それが機能した理由、および除外した選択肢などの結果を自分で元のチャットに持ち帰ります。
その決定を将来のチャットにも適用する必要がある場合は、AGENTS.md またはプロジェクトのドキュメントに記載してください。Codexのメモリに関するドキュメントには、その理由が記載されています。「必要なチームのガイダンスは AGENTS.md またはチェックインされたドキュメントに保管してください。メモリは、常に適用されるべきルールの唯一の情報源としてではなく、役立つ想起レイヤーとして扱ってください。」
結果を誰かと共有したい場合、共有されたスナップショットは閲覧や添付はできますが、フォークはできないことを覚えておいてください。リンクと一緒に結論を伝えてあげましょう。
MemoryLakeでの設定方法
フォークを行うと会話が増えていきます。いくつかの実験を行うと、決定の背後にある推論が、元のチャット、2つのフォーク、そしてサイドチャットに分散してしまい、それぞれが他のチャットの存在を知らない状態になります。
MemoryLakeは、結論を1つのリストにまとめて維持するためのメモリレイヤーです。これにより、どのチャットから得られた結論であっても、接続しているCodexや、ChatGPT、Claude Codeなどの他のアシスタントから利用できるようになります。
エントリーは、あなた自身の言葉で自分で作成します。Codexのチャット、worktree、~/.codex ディレクトリやそのメモリ、AGENTS.md ファイル、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。機密情報や認証情報は除外し、プロジェクトの詳細については組織のポリシーに従ってください。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーはMemoryLakeのワークスペースに属しており、ChatGPTのアカウントとは異なります。
ステップ2：最初のメモリをアップロードする
直近のいくつかのフォークから始めましょう。それぞれについて、どのアプローチが採用されたか、その理由、そして不採用となったアプローチから何を学んだかを記述します。1つのエントリーにつき1つの決定事項とし、日付と適用対象のリポジトリを記載します。
ステップ3：AIとエージェントを接続する
Codexや、使用している他のアシスタントを接続します。フォークされたチャットであれ、新しいチャットであれ、次のチャットはすでに決定された事項を踏まえて開始できます。
実践においてこれがもたらす変化
最初の違いは、実験によって元のチャットがリスクにさらされなくなることです。worktreeを使用することで、フォークは独自のファイルを持ち、元のコードはそのまま維持されます。
2つ目は、チャットを区別できるようになることです。チャットに名前を付け、いつフォークし、いつ /side を使用するかという明確なルールを設けることで、セッションリストの視認性が保たれます。
3つ目は、結果がフォーク内に取り残されないことです。結論を元のチャット、AGENTS.md、または自分で管理しているリストに書き込んでおくことで、次のチャットでもその発見を把握できます。後で古いチャットやフォークを見つける必要がある場合は、Codexがそれらをどこに保管しているかをカバーした見つからないCodexチャット履歴を探すためのガイドをご覧ください。新しいチャットがプロジェクトを記憶していない理由については、Codexがプロジェクトのコンテキストを忘れてしまう理由に関するガイドを参照してください。
Codexチャットをフォークする際のベストプラクティス
作業が分岐する場合にのみフォークする。 同じ問題の次のステップであれば、同じチャットに留まります。
質問には /side を使用する。 完全なフォークを作成することなく、メインのトランスクリプトから寄り道を排除できます。
コードを変更する場合はworktreeにフォークする。 そうしないと、両方のチャットが同じファイルを編集することになります。
.worktreeinclude を一度設定しておく。 設定しておかないと、.env などのプロジェクトに必要な無視されたファイルが新しいworktreeに含まれません。
両方のチャットに名前を付ける。 /rename を使用して、ピッカーでどのアプローチであるかがわかるようにします。
フォーク先で /memories を確認する。 実験内容を将来のメモリに反映させるべきかどうかを判断します。
結果を持ち帰る。 継続するチャット、または永続化させる必要がある場合は AGENTS.md に決定事項を書き込みます。
結論
Codexチャットをフォークすると、会話が新しいIDを持つ新しいチャットにコピーされ、元のチャットはそのまま残ります。現在のチャットを /fork でフォークしたり、保存されたチャットを codex fork でフォークしたり、過去の時点からEscapeショートカットでフォークしたり、/side でサイドの質問をしたりできます。ただし、worktreeを選択しない限り独自のファイルは作成されず、発見した内容が自動的にマージされることもなく、共有されたスナップショットからフォークすることもできません。
作業が本当に分岐するかどうかを判断し、両方のチャットがコードを編集する場合はworktreeにフォークし、両方のチャットに名前を付け、完了したら結果を持ち帰りましょう。そうすることで、実験は元のチャットを置き換えるのではなく、それを補完するものになります。