/recapの機能
OpenAIのドキュメントにある手順は簡潔です。「Codexがアイドル状態のときに、/recapと入力する」。すると、Codexはこれまでの会話の短い要約を作成し、ターミナルに表示します。
ドキュメントにはさらに2つのポイントが記されています。手動のrecapは設定に関わらず動作します。「tui.auto_recap = falseであっても、Codexは会話の要約を生成する」。そして、本当の問題がスペースの不足である場合は別のコマンドを案内しています。「コンテキストスペースを解放したい場合は/compactを使用する」。
つまり、/recapは読者である「あなた」のためのものです。チャット内のスペースを空けるものではなく、ドキュメントではチャットのコンテキストをそのまま維持するオプションとして紹介されています。
recapが読み取る内容
Codexのオープンソースコードを見ると、recapに含まれる内容がわかります。それはセッション全体よりも限定的です。
最近の表示されているやり取りのみ。 コードは、会話の中で目に見えるメッセージ（あなたのリクエストとCodexの返信）から要約を構築します。ツールの出力、推論プロセス、他のスレッドの履歴は除外されます。
限定されたウィンドウ。 コードは最大8つの最近のやり取りを取得し、指示を含めて約8,192トークンの固定予算内に収めます。履歴がそれより長い場合、古いやり取りから先に削除され、長いメッセージは冒頭と末尾を残して中間がトリミングされます。
最新のリクエストはそのまま保持。 最新のメッセージにまだ回答がない場合、コードはそれを最新の返信と共に保持するため、要約にはあなたが今尋ねた内容が反映されます。
指示（Steers）は結合されたまま。 Codexが作業中にメッセージを送信した場合、コードは隣接するユーザーメッセージを1つのリクエストとして扱います。そのため、タスク途中の修正は、それが変更を加えた元のリクエストと一緒に読み取られます。
recapに求められる内容
Codexが履歴と共に送信する指示では、タスクに戻ってきた人向けの短い状況把握が求められます。具体的には、大まかな目標、意味のある進捗、および阻害要因（ブロッカー）です。また、インストールされていない修正や実行されていないテストなどの注意事項を未解決のまま残すこと、そして提案、キュー投入、実装、テスト、公開された作業を区別することもモデルに求められます。目標の長さはユーザーの言語で40〜60語、最大でも80語以内です。
recapには「次のアクション」も含まれることがありますが、それはあなたへの未回答の質問、合意された次のステップ、または阻害要因に対する明確な解決策がある場合に限られます。コードでは、要約を最大700文字、次のアクションを200文字に制限しています。
指示では、会話をデータとして扱うこと、そしてそれが不完全であったり抜粋であったりする可能性があることを念頭に置くようモデルに伝えています。これはユーザーにとっても同様の警告です。recapは最近のメッセージから構築された迅速なオリエンテーションであり、完全な記録ではありません。
recapが実行される場所
コードは、セッションで使用しているのと同じモデルを使用して、別の独立した一時的なリクエストを通じて要約を生成します。結果が届くとターミナルに表示されます。
この設計により、ドキュメントでは/recapを「圧縮せずに内容を把握する方法」と説明できるのです。作業は会話の傍らで行われます。要約を作成するためにチャットの履歴が要約されたり置き換えられたりすることはありません。
recapはターミナルの機能です。クラウド上の会話で/recapを試すと、会話の要約はクラウド会話では利用できない旨のメッセージが表示されます。すでに要約が生成中である場合や、まだ会話が存在しない場合、Codexは新しい要約を開始せずにその旨を通知します。
Codexが自動で要約を作成するタイミング
自動要約はデフォルトでオンになっています。OpenAIの設定リファレンスでは、この設定を「ターミナルがフォーカスされていない間に自動会話要約を生成する（デフォルト：true）」と説明しています。
オープンソースコードには、そのタイミングの詳細が記されています：
- ターミナルがフォーカス外であること。 ターミナルウィンドウから切り替えた時点でカウントダウンが始まります。要約が作成される前に戻ると、保留中の要約はキャンセルされます。
- 約30分。 ターミナルがフォーカスを失った時点と、最後のターンが終了した時点の、いずれか遅い方から30分待ちます。
- 十分な会話量。 最初の自動要約が行われるには、少なくとも3回の完了したターンが必要です。
- 前回からの更新。 要約が行われた後は、次の要約を作成するまでに少なくともさらに2回の完了したターンを待ちます。
したがって、短いセッションや、ターミナルをずっと見ている場合には自動要約は行われません。席を外した長いセッションでは行われます。
自動要約をオフにする方法
この設定はCodex 0.153.0で導入されました。リリースノートには「手動の/recapを利用可能にしたまま自動要約を無効にするには、tui.auto_recap = falseを設定してください」とあります。
Codexの設定ファイルの[tui]セクションの下で、auto_recapをfalseに設定します。設定リファレンスでも、「falseに設定すると自動要約が無効になりますが、/recapは引き続き利用可能です」と確認されています。
これをオフにすると、Codexは自動要約のスケジュールを停止しますが、リクエストしたときには引き続き/recapが機能します。
/recap vs /compact
どちらのコマンドも「要約」に関わるため、混同されがちです。しかし、これらはチャットに対して正反対のことを行います。
/recap は「あなた」のために要約を書き、会話はそのまま残します。Codexは同じ履歴を使って作業を続けます。
/compact は「Codex」のために要約を書き、それを以前のターンの代わりに使用します。これによりコンテキストウィンドウのスペースが解放されますが、以前の詳細な内容は要約に置き換わります。Codexはチャットが制限に近づくと自動的に圧縮も行います。GPT-6.1 SolのCodex 500kコンテキストに関するガイドで、その仕組みを説明しています。
長いセッションに戻った際の実践的な手順：まずrecapを読んで現在の状況を確認し、それからチャットの圧縮が必要かどうかを判断してください。
Claude Codeも使用している場合
Claude Codeにも同名で同様の目的の機能がありますが、詳細は異なります。両者を併用する場合は注意が必要です。
Anthropicは、Claude Code版を「これまでのセッションで何が起こったかの1行の要約」と説明しています。待ち時間はCodexよりもはるかに短く、要約は「最後のターンが完了してから少なくとも3分が経過し、ターミナルがフォーカスされていない場合にバックグラウンドで生成」されます。Codexと同様に、まず一定の履歴が必要であり、Anthropicは要約が「2回連続で表示されることはない」と付け加えています。
制限や切り替え方法も異なります。「Claude Codeは自動要約と/recapの出力の両方を400文字に制限しています」。自動要約のオフは設定ファイルではなく/configで行い、環境変数で強制的にオンまたはオフにすることも可能です。また、Anthropicはコストガイドの中で「セッションの要約とアイドル時の圧縮は、アイドル中にもトークンを消費する可能性がある」と注記しています。
つまり、同じコマンド名でも、Codexでは長い待ち時間の後に長い要約が得られ、Claude Codeでは数分後に1行の要約が得られるという違いがあります。
recapが代替しないもの
recapは最近のメッセージからオンデマンドで生成されるものです。これは読解の補助であり、記憶（memory）でも引き継ぎ文書でもありません。
作業を新しいチャットに移動する場合、recapの長さとウィンドウはすべてを運ぶには小さすぎます。引き継ぎプロンプトの書き方ガイドでは、新しいチャットに必要な要素を網羅しています。ローカルとworktree間、あるいは別のマシンにチャットを移動する場合は、Codex引き継ぎガイドで移動対象を説明しています。
Codexがすべてのセッションで知っておくべき事実については、Codex独自のmemory機能やプロジェクトのAGENTS.mdがあります。Codex memories v2ガイドで、それらの保存場所を解説しています。
また、チャットが要約を必要としているのではなく、消えてしまったように見える場合は、紛失したCodexチャット履歴の探し方ガイドで保存場所を確認してください。
よくある間違い
コンテキストを空けるために/recapを使う。 圧縮はされません。スペースが必要なときは/compactを使ってください。
セッション全体の要約を期待する。 固定予算内で最大8つの最近のやり取りを読み取り、ツールの出力は除外されます。
recapを記録として扱う。 戻ってきたときに表示されるだけのものです。残しておきたいものは、自分で管理できる場所に保存してください。
自動要約をオフにすると/recapも使えなくなると思う。 自動要約を無効にしても、手動コマンドは維持されます。
クラウドの会話で/recapを試す。 クラウドでは利用できません。
解決策：recapを状況把握に使い、記録は別に保管する
ステップ1：何かを決める前にrecapを読む
長いセッションに戻ったら、まずrecapを読んでください。テストが未実行である、変更がインストールされていないなど、注意事項が自分の記憶と一致するか確認します。要約が表示されていない場合は、Codexがアイドル状態のときに/recapと入力します。要約に「次のアクション」が記載されている場合、それはCodexがすでに受け入れた指示ではなく、確認すべき提案として扱ってください。
ステップ2：recapに頼るべきでないことを書き留める
なぜそのアプローチを選んだのか、何を除外したのか、何が禁止事項なのかといったことは、最近のメッセージの要約に依存すべきではありません。覚えているうちにそれらを書き留めておきましょう。
ステップ3：永続的な事実はすべてのセッションから見える場所に置く
プロジェクトの慣習はAGENTS.mdに移動し、決定事項は自分で管理するノートに記録してください。そうすれば、前回のrecapの内容に関わらず、新しいセッションはそれらの情報を持って開始されます。
MemoryLakeでのセットアップ
recapは、戻ってきたときに表示される最近のメッセージの短いビューです。作業の背後にある決定事項はそれよりも長く続くものであり、recapの小さなウィンドウでは古いやり取りから先に消えてしまいます。
MemoryLakeは、それらの決定事項を自分で管理する1つの場所に保管し、ChatGPT、Claude Code、Codexなど、接続したアシスタントから利用できるようにする記憶レイヤーです。
エントリーはあなた自身の言葉で書きます。Codexのセッション、そのrecap、AGENTS.mdファイル、Codexのmemory、あるいはベンダーのストレージから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。recapはOpenAIが説明している通りの動作を続けます。
ステップ1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーはMemoryLakeワークスペースに属し、ChatGPTやCodexのアカウントとは別個のものです。
ステップ2：最初の記憶をアップロードする
解決策のステップ2で作成したノート（決定事項、除外したアプローチ、境界条件）から始めましょう。1つのエントリーにつき1つのポイントを、日付と共に記入します。
ステップ3：AIとエージェントを接続する
Codexや、使用している他のアシスタントを接続します。セッションが開始されるたびに、同じエントリーが利用可能になります。
実践で何が変わるか
第一の違いは、復帰が早くなることです。recapが現在の状況を教えてくれ、それがチャットの内容を変更していないことがわかっているからです。
第二に、要約への依存度が下がります。作業の背後にある理由は書き留められているため、短いrecapがそれらを保持し続ける必要はありません。
第三に、新しいセッションがより安定します。直近の数メッセージの要約ではなく、あなたの決定事項に基づいてセッションが開始されるからです。
Codexにおけるrecapのベストプラクティス
状況把握には/recapを使う。 スペースを空けるには/compactを使う。
長いセッションでは自動要約をオンにしておく。 気が散る場合はtui.auto_recapでオフにする。
ウィンドウを意識する。 最近のやり取りは最大8つまで、ツールの出力は含まれない。
注意事項を確認する。 recapは未完了の作業にフラグを立てるよう求められているが、必ず自分で確認すること。
ターミナルを使用する。 クラウドの会話ではrecapは利用できない。
決定事項はその都度書き留める。 recapはそれらを保管する場所ではない。
結論
/recapは、最近の表示されているやり取りから構築された現在の会話の短い要約をCodexに要求します。これはチャットの傍らで生成されるため、チャットのコンテキストはそのまま維持されます。Codexは、ターンの終了後にターミナルが約30分間フォーカス外になり、十分な会話量がある場合に自動的に要約を作成します。これは手動コマンドを維持したままtui.auto_recap = falseでオフにできます。
recapを状況把握に使い、スペースが必要なときは/compactを使ってください。作業の背後にある決定事項は、すべてのセッションが読み取れる場所に保管しておきましょう。