3行まとめ
毎回守るチームルール。
繰り返す好みや軽い文脈。
外部データへつながる権限。
便利さより先に、どの情報をどこへ置くかを決めます。
- Codex Memoriesは、毎回説明している作業好みやプロジェクトの軽い癖を次のスレッドへ持ち越すための補助記憶です。
- 必ず守らせたいテスト手順、禁止操作、人間承認、秘密情報の扱いは、Memoriesではなく
AGENTS.mdやリポジトリ内ドキュメントに置きます。 - MCPや外部コンテキストを読んだ作業を将来の記憶に使うなら、保存対象、除外条件、レビュー担当、削除手順を先に決めてから有効化します。
この記事でわかること
覚えてよい情報を決める。
AGENTS.mdへ残す条件を決める。
Claude Code memoryとの違いを見る。
MCPやドキュメントの扱いを確認する。
30日だけ小さく試す。
Memoriesは機能比較だけでなく、チーム運用の境界として見ます。
- Codex Memoriesに任せてよい情報と、任せてはいけない情報の分け方
AGENTS.mdとMemoriesを混ぜると、チームルールが曖昧になる理由- Claude Codeの
CLAUDE.mdやauto memoryと比較するときの見方 - MCP tool call、外部ドキュメント、ユーザーデータを含むスレッドを記憶対象にする前の確認項目
- チームで30日だけ試すときの最小運用ルール
前提知識
2026年6月10日時点の情報を前提にし、導入時には公式Docsと設定画面を再確認します。
Codex Memoriesは、OpenAIのCodexが過去スレッドから有用な文脈をローカルのmemoryファイルへ残し、将来の作業で再利用できるようにする機能です。2026年6月10日に公式Docsを確認した範囲では、Memoriesは初期状態でオフです。Codex appの設定、または~/.codex/config.tomlの[features]で有効化します。
[features]
memories = true公式Docsでは、Memoriesは欧州経済領域、英国、スイスでは提供開始時点で利用できないと説明されています。提供地域、UI名、設定名は変わりやすいので、導入前には自分のアカウント、組織、利用地域の設定画面と公式Docsを見直してください。
Memoriesはチームルールの置き場ではない
Codex Memoriesは便利ですが、チーム全員に必ず守らせたいルールを置く場所ではありません。公式Docsでも、必要なチームガイダンスはAGENTS.mdやチェックイン済みドキュメントに置き、Memoriesはローカルの想起用の補助層として扱うよう促されています。
この線引きが一番大事です。たとえば「本番DBに接続しない」「依存関係を追加する前に人間へ確認する」「PR前にnpm testを通す」は、うっかり忘れると事故につながります。こうしたルールはリポジトリ側に置き、レビューで変更できるようにします。
一方で「このリポジトリでは毎回pnpmを使うと説明している」「テスト失敗時に最初に見るログが決まっている」「このプロジェクトではfeature flag名をよく間違える」といった軽い作業知識は、Memoriesの候補になります。なくても破綻しないが、再利用されると助かる情報です。
MCPは記憶ではなく権限付きの接続
MCPは、AIエージェントが外部ツールやデータソースへ接続するための仕組みです。GitHub、社内API、ドキュメント検索、DB、Issue trackerなどをMCP経由で読むと、agentのcontextには外部データが入ります。
その作業からmemoryが作られる場合、単に「便利な文脈が残る」だけでは済みません。ユーザーデータ、秘密情報、未公開の設計、顧客ログ、認証情報に近い断片が混ざる可能性があります。MCPを使うチームほど、Memoriesを有効にする前に保存対象と除外条件を決めるべきです。
結果：ルール、補助記憶、外部権限を分ける
禁止操作、承認、テスト条件。
安定した好みや繰り返す進め方。
MCPや社内データへの接続範囲。
「覚えたか」ではなく、「ルールか、記憶か、権限か」で話せる状態にします。
最初の判断は単純です。Codex Memoriesをオンにするかどうかではなく、どの情報をどの層に置くかを先に決めます。
| 層 | 置くもの | 置かないもの |
|---|---|---|
AGENTS.md | 必須ルール、テスト手順、禁止操作、人間承認、レビュー基準 | 個人の癖、毎回変わる作業メモ |
| Codex Memories | 安定した好み、繰り返す作業手順、技術スタック、軽い落とし穴 | APIキー、顧客データ、監査対象ログ、法務上の必須ルール |
| MCP設定と認可 | 外部API、DB、GitHub、社内ツールへの接続権限 | 「AIが覚えておけばよい」程度の曖昧な権限説明 |
| 人間レビュー | memoryファイルの共有前確認、外部context混入時の判断 | 自動redactionへの丸投げ |
この分け方にすると、チーム内で会話がしやすくなります。「Codexが覚えたかどうか」ではなく、「その情報はルールなのか、補助記憶なのか、外部権限なのか」と問えるからです。
Codex Memoriesは何を覚える機能か
レビューや作業の進め方。
繰り返し使う手順。
よく使う技術構成。
軽い命名や運用の癖。
毎回避けたい落とし穴。
短命の会話や進行中の作業は、すぐにmemory化されるとは限りません。
OpenAIの公式Docsでは、Memoriesは過去スレッドから安定した好み、繰り返すworkflow、tech stack、project convention、known pitfallsを持ち越すための機能として説明されています。短命の会話や進行中の作業は、すぐにmemory化されるとは限りません。Codexはmemory更新をバックグラウンドで行い、rate limit残量がしきい値を下回る場合は生成をスキップすることもあります。
覚える価値がある情報
判断基準
Memoriesに向いているのは、次の条件を満たす情報です。
- 何度も説明している
- 内容が安定している
- 秘密情報ではない
- チームの必須ルールではない
- 古くなっても致命的な事故になりにくい
- ローカルの補助記憶として扱える
例を挙げると、使うpackage manager、よく見るテストログ、作業ブランチ名の慣習、レビュー時に必ず確認する軽い観点、ローカル検証でつまずきやすい既知の癖などです。
すぐ覚えさせない方がよい情報
注意点
反対に、次の情報はMemoriesへ入れる前に止めます。
- APIキー、OAuth token、GitHub token、DB credential
- 顧客名、メールアドレス、個人情報、問い合わせ本文
- 非公開リポジトリの具体的な脆弱性情報
- 本番障害ログの生データ
- 法務、監査、セキュリティ上の必須ルール
- 人間承認なしに実行してはいけない操作
Codexは生成されたmemory fieldからsecretをredactすると説明されています。ただし、これは保存してよい理由ではありません。redactionは追加の防御であって、秘密情報をmemory化する前提を正当化するものではない、と見た方が安全です。
確認するコマンド
AGENTS.mdが読まれているか、Memoriesが生成されているかは、操作を分けて確認します。
codex --ask-for-approval never "Summarize the current instructions."
ls ~/.codex/memories1つ目はinstruction chainの確認です。2つ目はローカルmemoryの存在確認です。どちらも秘密情報を出さない環境で実行してください。チーム用のスクリーンショットやログへ貼る前には、~/.codex配下に社内情報が混ざっていないかを確認します。
AGENTS.mdに残すべきチームルール
- 1Global
Codex home配下の共通指示。
- 2Project
リポジトリ全体の作業契約。
- 3Nested
現在位置に近い追加指示。
- 4Limit
上限に達すると追加を止める。
毎回守られないとレビューや運用が壊れるものは、MemoriesではなくAGENTS.mdへ置きます。
AGENTS.mdは、AIコーディングエージェント向けの作業契約を置く場所です。Codexは起動時に、Codex home配下のグローバル指示、プロジェクトルートから現在ディレクトリまでのAGENTS.mdやAGENTS.override.mdを読み、指示の連なりを作ります。
公式Docsでは、Codexはグローバル、プロジェクト、ネストされたディレクトリの順にガイダンスを連結し、現在位置に近いファイルほど後ろに入るため、より具体的な指示として効きやすいと説明されています。デフォルトでは、combined sizeがproject_doc_max_bytesの上限に達すると追加を止めます。2026年6月10日時点のDocsでは、この上限は32 KiBです。
毎回守らせたいことを書く
評価基準
AGENTS.mdに置くべきなのは、毎回守られないとレビューや運用が壊れるルールです。
# AGENTS.md
Repository expectations
- JavaScript/TypeScriptを変更したら、PR前に`npm test`を実行する。
- 本番DB、本番storage、本番APIへ直接書き込む操作は行わない。
- 新しいproduction dependencyを追加する前に人間へ確認する。
- `.env`、token、credential、顧客ログを本文、commit、issue、promptへ貼らない。
- MCP toolを追加するときは、read-onlyから始め、ownerとscopeを明記する。これはmemoryではなく契約です。PRレビューで差分を見られ、チームが同じルールを共有でき、問題が起きたときに変更履歴を追えます。
Memoriesへ逃がさないもの
次のような情報は、便利だからといってMemoriesへ逃がさない方がよいです。
- 破壊的操作の禁止
- テストを通す条件
- dependency追加の承認
- secretの扱い
- MCP serverのowner
- 本番環境へ触る権限
- 社内ポリシーや監査要件
「Codexが覚えているはず」は、チーム運用の根拠になりません。誰が変更し、どのレビューを通し、どの作業に適用されるのかが見える場所へ置きます。
読み込み順を確認する
ネストされたディレクトリで別チームのルールを置く場合は、読み込み順を確認します。
codex --cd services/payments --ask-for-approval never "Show which instruction files are active."支払い、認証、顧客データ、管理者機能のようにリスクが高い領域では、ルートのAGENTS.mdだけでは足りないことがあります。services/payments/AGENTS.override.mdのように近い場所へ追加ルールを置くと、作業対象に応じたルールを読み込ませやすくなります。
Codex Memoriesに任せてよいもの、任せてはいけないもの
セキュリティや法務に関わる情報は単純な勝敗ではなく、保存後の説明責任で判断します。
Memoriesの評価は、「覚えてくれると便利か」ではなく、「再利用されても困らないか」で見ます。
Memoriesでよいもの
次のような情報は、Memoriesの候補になります。
| 種類 | 例 | 条件 |
|---|---|---|
| 個人の作業好み | 変更前にrgで影響範囲を見る | チーム必須ルールではない |
| 繰り返す手順 | テスト失敗時に先に見るログ | 秘密情報を含まない |
| 技術スタック | このrepoはpnpmとVitestを使う | AGENTS.mdにも最低限の手順がある |
| 軽い落とし穴 | 特定packageのimport pathを間違えやすい | 古くなっても危険操作につながらない |
| レビュー観点 | UI変更時はPlaywright確認を優先する | 公式ルールは別に残す |
このあたりは、毎回promptに書くと手間です。Memoriesに入ることで、Codexが作業の出だしで文脈を拾いやすくなります。
AGENTS.mdへ置くもの
同じ「覚えてほしい」でも、必ず守らせたいならAGENTS.mdです。
たとえば「新しい外部APIを追加するときは、timeout、retry、rate limit、secret保管場所をレビューする」は、チームの品質基準です。Memoriesに残っていなくても必ず効いてほしいので、リポジトリ内のルールへ置きます。
「MCP serverはread-onlyから始める」も同じです。便利な作業知識ではなく、権限設計の初期値です。
保存しない、またはレビュー後に判断するもの
顧客ログ、障害調査、認証まわりの調査、セキュリティincident、非公開の事業判断は、再利用価値があってもmemory化を急がない方がよいです。
特にMCPやweb search、tool searchを使ったスレッドは、外部由来の情報が混ざります。Codexにはmemories.disable_on_external_contextという設定があります。2026年6月10日時点の公式Docsでは、この設定をtrueにすると、MCP tool call、web search、tool searchなど外部コンテキストを使ったスレッドをmemory生成から外すものとして説明されています。
[features]
memories = true
[memories]
disable_on_external_context = true外部コンテキストを使うチームでは、最初はこの方向に倒すのが扱いやすいです。必要になったら、どのMCP server、どのデータ、どの作業をmemory生成へ含めるかを個別にレビューします。
Claude Code memoryとの差分
片方の運用をそのまま移すのではなく、責務の近い部分だけを対応づけます。
Codex Memoriesを考えるとき、Claude Codeのmemoryと混同しやすくなります。どちらも「前の作業を次に活かす」方向の機能ですが、ファイル名、読み込み方、設定、権限との関係が違います。
AGENTS.mdとCLAUDE.mdは似ているが同じではない
Claude Codeでは、CLAUDE.mdやrulesがpersistent contextの中心になります。公式Docsでは、CLAUDE.mdはユーザーが書くinstruction、auto memoryはClaudeが corrections や preferences をもとに書くnotesとして説明されています。
Codex側で対応する概念をざっくり置くなら、AGENTS.mdがチームやプロジェクトの作業契約、MemoriesがCodexの補助記憶です。ただし、片方の運用をそのままもう片方へ移植するとずれます。Claude Codeには.claude/rules/やpath-scoped rules、/memoryなど、独自の管理方法があります。
context windowに入るものを見る
Claude Codeのcontext window公式Docsでは、最初のprompt前にCLAUDE.md、auto memory、MCP tool names、skill descriptionsなどがcontextへ入ると説明されています。作業中にファイルを読むと、その内容もcontextへ入ります。
これはCodex Memoriesにも通じる注意点です。memoryは「長期記憶」という言葉で語られがちですが、実務ではcontext windowに何が入るか、どの情報が後から再利用されるか、どの設定が強制力を持つかを分けて見ます。
権限境界はmemoryでは作れない
Claude CodeのDocsでも、CLAUDE.mdやauto memoryはcontextであって、強制的な制御層ではないと説明されています。行動を止めるなら、permissions、hooks、managed settingsのような別の仕組みを使います。
Codexでも同じ考え方が必要です。Memoriesに「本番DBへ触らない」と残っていても、それは権限設定ではありません。MCP server側のscope、認証情報、read-only token、承認フロー、実行環境の制約で止めます。
MCPや外部コンテキストをメモリ化する前の権限レビュー
- 1MCPを呼ぶ
接続先とscopeを確認する。
- 2contextに入る
ユーザーデータや未公開情報の有無を見る。
- 3memory候補
将来再利用してよい情報か判断する。
- 4レビュー
担当者、除外条件、削除手順を決める。
- 5除外
説明しにくい情報は保存しない側へ倒す。
ユーザーデータ、管理操作、秘密情報、監査要件が絡む場合は、便利さより権限境界を優先します。
MCPを使うほど、AIエージェントが読める情報は増えます。Issue、PR、社内Wiki、顧客問い合わせ、DB、billing、CRM、storage。どれも開発には役立ちますが、memory化してよいとは限りません。
MCPは便利な読み取り口ではなく権限付きの接続
根拠
MCP Authorizationの公式Docsでは、MCP serverがユーザー固有データ、監査対象の操作、同意が必要なAPI、enterprise access control、userごとのrate limitingやusage trackingを扱う場合、authorizationが強く推奨されると説明されています。
memory運用でも同じ観点を使います。
| 確認項目 | 見ること |
|---|---|
| user data | メール、ドキュメント、顧客ログ、問い合わせ内容が混ざるか |
| admin action | 作成、更新、削除、送信、課金変更に触れるか |
| consent | 誰の同意で、どのscopeを使っているか |
| audit | 誰のagentが、どのtoolを、どの入力で使ったか追えるか |
| token | 短命か、scopeが狭いか、保存場所が安全か |
| memory | そのスレッドを将来の記憶生成に使ってよいか |
MCP tool名だけでは判断できません。search_docsという名前でも、社内の未公開仕様を読むかもしれません。create_issueという名前でも、社外公開repoに書き込むかもしれません。tool名ではなく、業務動詞とデータ範囲で棚卸しします。
tokenとsecretはmemoryの前で止める
API tokenやOAuth tokenは、Memory側でどう扱うか以前に、prompt、ログ、ファイル、MCP tool resultへ出さない設計が必要です。
実務では、次のように分けます。
- secretは環境変数やsecret managerに置く
- MCP serverへ渡すtokenはread-onlyから始める
- local STDIO serverとremote HTTP serverで認可の扱いを分ける
- tool resultにtokenや個人情報を含めない
- agentの出力ログを共有前に確認する
- 外部コンテキストを含む作業はmemory生成から除外する初期設定にする
Codex Memoriesのredactionに期待するより、手前で混入させない設計にします。
外部コンテキストを使った作業は除外側から始める
GitHubのprivate issueを読ませる、顧客問い合わせを要約させる、社内Wikiから設計判断を拾わせる。こうした作業は便利ですが、memory化とは別です。
判断基準は次の通りです。
- 再利用価値より漏えい時の損失が大きい
- 出典や利用条件を説明しにくい
- 顧客、ユーザー、社員に紐づく
- 未公開の脆弱性や障害情報を含む
- MCP serverのscopeが広い
- 監査で「なぜ記憶されたか」を説明しにくい
1つでも当てはまるなら、最初は除外に倒します。あとから必要な情報だけを、人間が要約してAGENTS.mdや安全な運用メモに移す方が、レビューしやすくなります。
チーム導入の最小運用
賢くなったかだけでなく、古いルールや不要な文脈が残っていないかを見ます。
Codex Memoriesをチームで使うなら、最初から全員に広げない方がよいです。少人数で30日だけ試し、何がmemory化されるかを見るところから始めます。
30日パイロットで決めること
確認項目
| 決めること | 担当 | 確認頻度 | 戻し方 |
|---|---|---|---|
| Memoriesを有効にする人 | Tech lead | 開始時 | feature flagを戻す |
| 外部contextをmemory生成に使うか | Security owner | 開始時と週次 | disable_on_external_contextをtrueにする |
| memoryファイルのレビュー | Pilot参加者 | 週1回 | 該当memoryを削除する |
AGENTS.mdとの差分 | Repo owner | PRごと | ルールはPRで修正する |
| MCP serverのscope | Tool owner | tool追加時 | token失効、server無効化 |
| 共有前の確認 | 各参加者 | 共有前 | ~/.codex配下を共有しない |
見るべきなのは、「どれだけ賢くなったか」だけではありません。不要な文脈が残っていないか、古いルールが効いていないか、外部データが混ざっていないかを見ます。
AGENTS.mdレビューとmemoryレビューを分ける
AGENTS.mdはリポジトリのルールなので、PRレビューで見ます。変更理由、影響範囲、対象ディレクトリ、テスト手順を確認できます。
Memoriesはローカル状態なので、PRレビューだけでは管理できません。トラブル時、共有前、チームルール変更後、外部コンテキストを使った作業後に見る対象です。この2つを同じ承認フローへ押し込むと、逆にどちらも曖昧になります。
失敗時の戻し方を決める
Memories導入でよくある失敗は、古い文脈が残ることです。たとえば、以前はnpmを使っていたrepoがpnpmへ移行したのに、memoryが古い手順を思い出す。あるいは、一時的な調査メモを安定したルールのように扱う。
戻し方はシンプルにしておきます。
- 該当memoryを確認する
- 古いmemoryを削除する
- 正しいルールは
AGENTS.mdへ書く - Codexにactive instructionsを要約させる
- 同じ作業を小さなタスクで再試行する
この流れを決めておくと、Memoriesを過信せずに使えます。
失敗点：導入時に起きやすい事故
禁止操作やテスト条件までMemoriesへ寄せてしまう。
MCPや社内Wikiを読んだスレッドの扱いを確認しない。
自動redactionを安全保証として扱う。
説明しにくい情報は、最初からmemory生成の外に置く判断が必要です。
Memoriesをルール台帳にしてしまう
一番多い失敗は、「覚えてくれるなら、ルールも覚えさせればよい」と考えることです。Memoriesは便利な補助記憶ですが、レビュー可能なチーム契約ではありません。禁止操作やテスト条件はAGENTS.mdへ置きます。
外部コンテキストの混入を見ない
MCP、web search、tool search、private issue、社内Wikiを読ませたあと、そのスレッドが将来のmemory生成に使われるかを見ないまま進めると、後で説明しにくくなります。最初は外部コンテキストをmemory生成から外す設定を検討してください。
redactionを安全保証として扱う
redactionはありがたい防御ですが、秘密情報を保存してよい理由にはなりません。APIキーやtokenは、そもそもpromptやtool resultに出さない設計にします。
Claude Codeのmemory運用をそのまま持ち込む
Claude CodeにはCLAUDE.md、auto memory、path-scoped rules、/memoryなどの流儀があります。CodexにはAGENTS.mdとCodex Memoriesの流儀があります。似ている部分だけを見て、設定や読み込み順を混同すると事故ります。
共有前に~/.codexを確認しない
Codex homeには設定やstateが入ります。公式DocsではmemoryはCodex home配下、デフォルトでは~/.codex/memories/に置かれると説明されています。トラブルシュートのためにディレクトリを共有するときは、memoryや設定に秘密情報が混ざっていないかを必ず確認します。
実務で使うなら：4段階で広げる
- Phase 1
AGENTS.mdを短く整える。
- Phase 2
個人ローカルでMemoriesを試す。
- Phase 3
MCP serverごとにscopeを棚卸しする。
- Phase 4
チーム標準にする条件を決める。
最初から全員へ広げず、保存内容と削除手順を見てから標準化します。
Phase 1はAGENTS.mdを先に整える
Memoriesを有効化する前に、AGENTS.mdを短く整えます。テスト、禁止操作、secret、MCP、承認の初期ルールだけで十分です。まずチーム契約を見える場所へ置きます。
Phase 2は個人ローカルでMemoriesを試す
少人数でMemoriesを有効化し、1週間から30日ほど使います。memoryに入る内容、古い情報の残り方、外部コンテキストの扱いを見ます。この時点では、チーム標準にしない方が判断しやすいです。
Phase 3はMCP serverごとに棚卸しする
MCP serverを使っている場合は、server単位でowner、scope、secret、transport、write権限、audit、memory除外の方針を記録します。read-onlyから始め、作成、更新、削除、送信を分けます。
Phase 4で運用ルールに入れる
問題が少なく、レビューの流れも見えたら、チームの開発環境ルールに入れます。ただし、Memoriesを必須にするかどうかは別問題です。個人ローカルの補助として使う方が合うチームもあります。
Codex、Claude Code、MCPの設定変更を継続的に追いたい場合は、更新通知用の<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">ニュースレター</a>も用意しています。仕様変更や運用チェックリストの更新を、記事公開後の追跡に使うための導線です。
セキュリティ・コスト注意
誰がMemoriesをオンにしたか確認する。
地域、組織設定、UI名を再確認する。
memory生成に使う作業と使わない作業を分ける。
残量によってmemory生成がスキップされる場合を見る。
Memoriesは作業説明を減らす補助であり、秘密情報管理や権限設計の代わりにはなりません。
Codex Memoriesは、作業の説明コストを下げる可能性があります。ただし、tokenやrate limitを完全に消す機能ではありません。公式Docsでも、memory生成はバックグラウンドで行われ、rate limit残量が設定しきい値を下回ると生成をスキップする場合があると説明されています。
チームで見るべき注意点は次の通りです。
- Memoriesは初期状態でオフなので、誰が有効化したかを確認する
- 提供地域や組織設定は公開直前に再確認する
- memory生成に使うスレッドと使わないスレッドを分ける
~/.codex/memories/を共有前に確認する- secret、token、顧客データ、未公開障害情報をmemory化しない
- MCP serverはread-only、狭いscope、短命tokenから始める
AGENTS.md、permission、MCP認可、人間承認を混ぜない- memoryが古くなったときの削除と再生成の流れを決める
法人導入では、AIコーディングエージェントの設定だけでなく、社内API、GitHub権限、MCP server、ログ、承認フローまでつながります。権限設計やAGENTS.md整備を一度レビューしたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/contact/">お問い合わせ</a>から相談できます。
次に読むなら
参照した主な情報源
- https://developers.openai.com/codex/memories
- https://developers.openai.com/codex/guides/agents-md
- https://code.claude.com/docs/en/memory
- https://code.claude.com/docs/en/context-window
- https://modelcontextprotocol.io/docs/tutorials/security/authorization
更新履歴
- 2026年6月10日
OpenAI Codex Memories、Codex AGENTS.md guide、Claude Code memory、Claude Code context window、MCP Authorizationの公式Docsを確認しました。
仕様や設定名は変わりやすいため、検証日と確認範囲を残します。
- 2026-06-10: OpenAI Codex Memories、Codex AGENTS.md guide、Claude Code memory、Claude Code context window、MCP Authorizationの公式Docsを確認。X上の反応は需要シグナルとしてのみ扱い、本文の根拠には使っていません。スポンサー、アフィリエイト、検証環境提供はありません。