Codex 永続メモリ｜セッション横断のコンテキスト

Codex の永続メモリは、セッションをまたいで作業内容やプロジェクト固有の文脈を AI が覚えていてくれる新機能です。ChatGPT 上の Codex でも CLI でも、一度教えた情報を毎回伝え直す必要がなくなり、「昨日の続きから話せる AI 同僚」に近い使い方ができます。本記事では、株式会社Fyve がクライアントの中小企業に AI を導入する立場から、全体像、Claude Code の CLAUDE.md・Memory との比較、業務継続性を高める使い方、プライバシー設計を実務目線で整理します。

Codex 永続メモリとは何か

Codex 永続メモリ（Memories）は、過去のセッションから「再利用価値のある知識」を Codex が自動抽出し、次回以降のセッション開始時に注入する仕組みです。2026 年 4 月以降、Enterprise / Edu プランから順次提供が始まり、Plus / Pro にも展開されています。Codex CLI では v0.128 系以降で標準機能として搭載され、設定ファイルでオン・オフを切り替えられます。

従来の Codex は「単発のセッション」で完結する道具でした。あるセッションでプロジェクト構造や用語、ビルド手順を伝えても、次のセッションを開けばゼロから説明し直す必要がありました。永続メモリは、完了したセッションから決定事項・学び・前提条件を要約として保存し、次のセッションの冒頭に静かに差し込みます。

「覚えていてくれる」とは具体的にどういうことか

たとえば前日に「契約書 PDF は documents/ に入れ、ファイル名を contract-YYYY-MM-DD.pdf に揃える」とやり取りしたとします。永続メモリが有効な状態だと、翌日に同じ Codex プロジェクトを開いた時点で、このルールが自動的に文脈として読み込まれます。改めて説明しなくても、最初の応答からそのルールに沿った提案が返ってきます。

具体的に覚えていてくれる対象は、おおむね次のような情報です。

ディレクトリ構造や命名規則など、プロジェクト固有のお作法
採用したライブラリ・バージョン・代替検討の結論
「この処理はやらない」「この書き方は避ける」といった除外ルール
ユーザーが繰り返し指摘した好み（コメント量、ログ出力、レスポンス形式など）
過去に失敗した方針と、代わりに採用した方針

逆に、機密情報や一時的なトークン、特定の人名のような再利用すべきでない情報は、抽出時に伏字化（redaction）する設計です。完璧ではないため、メモリの内容を定期レビューする運用を勧めています。

仕組みの概略：Codex はどこに何を保存しているのか

Codex CLI の場合、永続メモリの実体はローカルファイルとして ~/.codex/memories/ 配下に保存されます。クラウドに勝手にアップロードされる類のものではなく、利用者の手元に置かれる点が大事です。

主なファイルは次の三つに整理できます。

memory_summary.md：直近のセッションから抽出された要約が書かれた、セッション開始時にまず読み込まれる「短いブリーフ」
MEMORY.md：より詳細な決定事項・経緯のログ。本文が必要なときに Codex が grep して参照する
raw_memory（セッション別）：個別セッションから抽出された生メモ。後述する抽出ジョブが書き出す

Codex 永続メモリの保存先と構成（memory_summary.md / MEMORY.md / raw_memory）

抽出処理はセッション終了の瞬間ではなく、バックグラウンドで動きます。最大 8 並列で停滞セッションを処理し、軽量モデル（gpt-5.4-mini）で会話ログを要約・蒸留します。ユーザーは処理を待つ必要がなく、次に Codex を開いたときに要約が用意されていれば良い、という非同期設計です。

セッション開始時の挙動

新しいセッションを開くと、Codex はまず memory_summary.md を全体読みします。コンテキスト予算を超えそうな場合はトークン数で切り詰め、本体に「詳細が必要になったら MEMORY.md を grep してね」と指示します。要約だけ常時持たせ、深掘りは検索で取りに行かせる設計です。記憶が増えるほど起動が重くなる、という懸念への自然な答えになっています。

Claude Code の CLAUDE.md / Memory との比較

「AI に文脈を持たせる仕組み」は Claude Code 側にも複数あります。実際に私たち株式会社Fyve は Claude Code と Codex を併用しており、それぞれの記憶系の役割が異なることを日々感じています。混同して使うと逆に作業が遅くなるので、ここで整理しておきます。

CLAUDE.md（Claude Code の手動ルールファイル）

CLAUDE.md は、人が書く静的なルールファイルです。「このリポジトリではこういう書き方をする」「このディレクトリではこういう責務を持つ」といったプロジェクト規約を、人間がコミットして共有します。Claude Code はセッション開始時に自動で読み込みます。永続メモリのように勝手に成長することはなく、「変えないでほしい固いルール」を置く場所として最適です。

AGENTS.md（Codex 側の共有ルールファイル）

Codex でこれに対応するのが AGENTS.md です。チームで共有する規約・コーディングスタイル・ツール選定理由などを書き、リポジトリにコミットします。Codex は永続メモリと AGENTS.md の両方を読みますが、両者の役割は分担されています。「契約のように守らせたい規約は AGENTS.md」「セッション間で覚えてほしい運用上の文脈は永続メモリ」という分け方が公式の推奨です。

Claude Code の Auto Memory

Claude Code には、セッション中に Claude 自身が短いメモを残せる Auto Memory の仕組みもあります。ユーザーの好み、フィードバック、プロジェクト文脈、参照ポインタの 4 カテゴリで保存され、次回以降のセッションに反映されます。Codex の永続メモリと近い役割ですが、Claude Code の場合は 4 層に分かれた階層構造を持ち、人がレビューしやすい単位で分割される点が特徴です。

三者を一行で対比すると

CLAUDE.md / AGENTS.md：人が書く・人が直す・チームで共有する「契約書」
Claude Code の Auto Memory：Claude がカテゴリ分けして書き溜める「秘書のメモ」
Codex 永続メモリ：Codex が会話ログから自動抽出して育てる「引き継ぎノート」

Codex 永続メモリ・Claude Code Auto Memory・CLAUDE.md/AGENTS.md の役割比較

私たちは、変えたくない規約は CLAUDE.md / AGENTS.md に書き、現場で発生した運用知見は自動メモリに任せる二段構えで運用しています。両方を「契約書」として使うと、メモリの揺らぎがそのまま規約のブレになるので避けるべきです。

Claude CodeMCPメモリサーバ徹底比較｜AIに記憶を持たせる3製品

中小企業の業務継続性を高める使い方

株式会社Fyve はクライアントの中小企業に AI 活用顧問サービスとして伴走していますが、永続メモリは「個人の生産性ツール」というより「組織の記憶インフラ」として効きます。理由は単純で、中小企業ほど業務知識が属人化しており、引き継ぎ資料が整っていないからです。Codex に「現場の手順」を覚えさせていけば、それ自体が引き継ぎ資料に近い役割を果たします。

シナリオ 1：請求書発行ワークフローの定着

毎月の請求書発行に「クライアント A は月末締め翌月末払い」「金額は税抜きで小数点以下切り捨て」「振込手数料は当社負担」のような細かいルールがあるとします。最初の数回のセッションで Codex に伝えながら作業すると、永続メモリが要点を拾います。3 ヶ月後、別のスタッフが同じプロジェクトを開いた時点で、過去の決定事項を踏まえた応答が最初から返ってきます。

このとき Codex への指示は、非エンジニアでも書ける次のような文章で十分です。

「請求書 PDF を documents/invoices/ に置いて。ファイル名は invoice-YYYY-MM.pdf 形式。クライアント A は月末締めです」
「金額は税抜きで小数点以下を切り捨てたあと、消費税 10% を加算してください」
「振込手数料は当社負担なので、請求書の文面には含めません」

こうした「業務上の前提」を会話の中で繰り返し参照していくと、永続メモリが業務ルール集を勝手に蓄積していきます。現場の運用から知識が立ち上がるイメージです。

シナリオ 2：プロジェクトをまたいだ「定型」の保存

受託開発では、案件ごとに似たような Next.js プロジェクトを立ち上げることがあります。「お問い合わせフォームは Resend で送信」「画像配信は Vercel の Image Optimization を使う」「環境変数は NEXT_PUBLIC_ プレフィックスで揃える」など、暗黙のお作法が積み重なります。永続メモリを使うと、こうした「会社の定型」が Codex のホームディレクトリに自然と蓄積されていきます。新しい案件で Codex を開いた瞬間に、過去案件で固めた定型が初手から提案に反映される状態を作れます。新人スタッフのオンボーディングを Codex が手伝ってくれる構造でもあります。

シナリオ 3：失敗の記憶を残す

永続メモリの便利な点は、成功例だけでなく「失敗してやめた選択肢」も覚えてくれることです。「ライブラリ X はライセンスの都合で却下」「方式 Y は性能要件を満たさず方式 Z に変えた」というやり取りは、後で同じ議論を蒸し返さないための防波堤になります。中小企業では同じ失敗を繰り返しがちなので、ここの効きが大きいと感じています。

導入時のプライバシー・セキュリティ設計

永続メモリは便利ですが、「AI に何を覚えさせるか」を設計せずに使うと、本来覚えさせるべきでない情報まで Codex のホームディレクトリに残ってしまいます。私たちはクライアントに導入する際、以下のチェックを必ず通しています。

1. メモリの保存先を理解する

Codex CLI の永続メモリは ~/.codex/memories/ 配下のローカルファイルです。クラウドに自動アップロードされる訳ではありませんが、その端末を共有していれば他の利用者からも読めてしまいます。共有 PC や VDI で使うときは、ユーザーごとにホームディレクトリが分離されているかを確認する必要があります。

2. 機密性の高い情報は会話に出さない

Codex はメモリ抽出時にシークレットを伏字化しますが、完全ではありません。API キー・トークン・住所・電話番号といった項目は、そもそも会話のテキストに直書きしない運用を取るべきです。CLI の場合は環境変数経由で渡し、画面に表示しないようにすればメモリにも残りません。

3. メモリの中身を定期的にレビューする

月に 1 度程度、~/.codex/memories/MEMORY.md と memory_summary.md を開いて、内容を人の目で確認することを推奨しています。誤って覚えた情報はテキストエディタで該当行を削除すれば消えます。「育てたメモリを信頼するために、定期的に剪定する」という発想です。

4. 設定でオン・オフを切り替える

Codex CLI の場合、~/.codex/config.toml の [features] セクションで memories = true を指定するとオン、外すか false にするとオフです。さらに memories.use_memories で「保存はするが次回セッションには注入しない」という分離もできます。機密寄りの案件ならメモリ自体をオフにする選択も普通にあります。