3行まとめ
長期知識だけを残し、secretは保存しません。
AGENTS.md、標準memory、外部メモリを分けます。
古い記憶や誤保存が出たら導入を止めます。
記憶を増やす前に、消せる運用を作ります。
- Agentmemoryのような永続メモリは、CodexやClaude Codeのセッション切れで失われる文脈を補えますが、保存対象を決めないまま入れると古い判断や秘密情報まで残ります。
- 導入前に分けるべきなのは、
AGENTS.mdに書く作業契約、Claude CodeやCodexの標準機能、追加メモリに保存する長期知識、保存してはいけない情報です。 - 最初はread-only評価で、codebase理解、継続リファクタ、レビュー報告の3タスクだけを試し、効果より先に削除手順と停止条件を確認します。
本文の事実確認には、AgentmemoryのGitHub、AnthropicのClaude Code memory関連ドキュメント、OpenAI CodexのAGENTS.mdとpermissions関連ドキュメントを使っています。Xで伸びていた投稿は需要シグナルとして扱い、本文の根拠にはしていません。
この記事でわかること
残す情報と残さない情報を分けられます。
read-only評価から始める条件を決められます。
3本の実務タスクで効果を見られます。
導入を止める条件を明文化できます。
導入判断を感想ではなく、評価表で残します。
- Codex/Claude Codeに永続メモリを足す前に決めること
- AgentmemoryのようなOSSを評価する時の確認観点
- 保存してよい情報と保存してはいけない情報の分け方
AGENTS.md、Claude Code memory、外部メモリの役割分担- read-only評価から始める1週間パイロット
- 導入を止めるべき失敗条件
前提知識
- 1Session
その会話だけで使う情報です。
- 2Project
AGENTS.mdなどrepoに紐づく作業契約です。
- 3Memory
セッションをまたいで残す長期知識です。
- 4Review
保存、更新、削除を人間が確認します。
長く残すほど、レビューと削除が必要になります。
AIコーディングエージェントを使い続けると、「前に決めた方針を毎回説明するのが面倒」「repo固有のテスト手順を毎回伝えている」「過去の調査ログがセッションをまたぐと消える」という悩みが出ます。永続メモリは、この面倒を減らす可能性があります。
ただし、記憶を増やせば自動的に安全になるわけではありません。むしろ、古い前提、間違った設計判断、secretに近い情報、非公開の障害ログが残ると、次のセッションで誤った判断を強めることがあります。
3種類の文脈を分ける
まず、セッション文脈、プロジェクト文脈、永続メモリを分けます。セッション文脈は、その会話の中だけで使う情報です。プロジェクト文脈は、repoの作業契約、テスト手順、禁止事項です。永続メモリは、セッションをまたいで残す価値がある知識です。
確認項目
毎回渡すべき情報なのか、repo内のAGENTS.mdに置くべき情報なのか、外部メモリに残すべき情報なのかを判断します。この判断を飛ばすと、何でも保存する運用になりがちです。
注意点
記憶があるほど便利に見えますが、記憶はレビュー対象でもあります。保存した情報を誰が見直し、いつ消し、どのrepoに効かせるのかを決めておく必要があります。
Agentmemoryで何を解決したいのか
| 項目 | 内容 | 見方 |
|---|---|---|
| 繰り返し説明 | AGENTS.mdへ置く候補です。 | |
| 過去判断 | 永続メモリ候補ですが確認日を付けます。 | |
| 長期タスク | 作業ログとメモリを分けます。 | |
| 一時情報 | 保存せずセッション内で扱います。 |
課題を分けると、保存しすぎを防げます。
Agentmemoryのような永続メモリを入れる前に、解決したい課題を言語化します。単に「セッションが切れるから不便」だけでは、保存対象が広がりすぎます。
課題は3つに分ける
よくある課題は、繰り返し説明、過去判断の忘却、長期タスクの再開です。
| 課題 | 例 | まず見る場所 |
|---|---|---|
| 繰り返し説明 | テストコマンド、禁止操作、レビュー形式 | AGENTS.md |
| 過去判断の忘却 | 採用しない設計、避ける依存、命名方針 | 永続メモリ候補 |
| 長期タスクの再開 | 複数日にまたがる調査、分割PR、未解決論点 | 作業ログとメモリ |
根拠
CodexにはAGENTS.mdでrepo固有の指示を渡す仕組みがあります。Claude Codeにもmemoryや設定の考え方があります。追加メモリを検討する前に、標準の文脈管理で足りる部分を切り分けます。
評価基準
「毎回説明している情報」のうち、repo全員に必要なものはAGENTS.mdへ、個人の作業継続に必要なものは作業ログへ、複数セッションで再利用する価値が高いものだけを永続メモリ候補にします。
入れる理由より入れない理由を先に決める
永続メモリは便利なほど、過剰に保存したくなります。だからこそ、導入前に「保存しない情報」を決めます。
保存しない条件
APIキー、.env、credentials、顧客名、障害時の非公開ログ、未公開ロードマップ、契約条件、個人情報、本番DBの値は保存しません。判断に迷う情報は、保存しない側へ倒します。
停止条件
メモリが古い前提を持ち出した、別プロジェクトの方針を混ぜた、secretに近い情報を保存しようとした、削除方法が確認できない。この場合は導入を止めます。
保存してよい情報と保存しない情報
| 項目 | 内容 | 見方 |
|---|---|---|
| 保存可 | 作業方針、設計判断、テスト手順、レビュー観点。 | |
| 保存不可 | APIキー、顧客データ、本番ログ、契約情報。 | |
| 要抽象化 | 具体値を消して作業観点だけ残します。 | |
| 期限付き | 暫定判断は見直し条件を付けます。 |
迷った情報は、保存しない側へ倒します。
永続メモリの設計は、何を覚えるかより、何を覚えないかで決まります。チームで使うなら、保存分類を明文化します。
保存してよい情報
保存候補になるのは、長く使う作業知識です。
| 分類 | 保存してよい例 |
|---|---|
| 作業方針 | PRは小さく分ける、未検証を必ず報告する |
| 設計判断 | このrepoではXではなくYを使う |
| テスト手順 | 変更後に走らせる標準コマンド |
| 用語 | 社内用語とコード上の対応 |
| レビュー観点 | UI変更時に見るアクセシビリティ項目 |
確認項目
保存してよい情報は、次回以降も有効で、secretではなく、チームメンバーに共有しても問題がなく、間違っていた時に修正できるものです。
注意点
「一時的な回避策」は保存候補に見えますが、期限がないと負債になります。保存するなら、確認日、対象範囲、見直し条件を一緒に残します。
保存しない情報
保存しない情報は、最初に明文化します。
| 分類 | 保存しない例 |
|---|---|
| 秘密情報 | APIキー、token、password、.env |
| 個人情報 | 顧客名、メール、住所、ログ内の識別子 |
| 本番情報 | DB値、障害ログ、アクセスログ |
| 契約情報 | 未公開の価格、契約条件、社外秘資料 |
| 古い暫定判断 | 期限切れの回避策、撤回済み方針 |
評価基準
メモリ候補を作る時は、「保存してよい理由」ではなく「保存してはいけない理由がないか」を先に見ます。1つでも迷う理由があるなら保存しません。
改善方法
保存したい内容にsecretや顧客情報が混じる場合は、抽象化します。具体値を残さず、「認証系の変更ではセッション期限とrefresh tokenの扱いをレビューする」のような作業観点に変換します。
Codex/Claude Code標準機能との分担
| 項目 | 内容 | 見方 |
|---|---|---|
| AGENTS.md | repo全員が使う作業契約を置きます。 | |
| Claude memory | 標準機能のスコープを確認して使います。 | |
| External memory | 再利用する長期知識だけを置きます。 | |
| Permissions | 実行境界は別設定で制御します。 |
同じ情報を複数箇所に重複保存しないことが大事です。
永続メモリは、CodexやClaude Codeの標準機能を置き換えるものではありません。むしろ、標準機能で扱うべき情報と、外部メモリに残す情報を分けるほど安全になります。
CodexではAGENTS.mdを先に整える
Codexでは、repoの作業契約をAGENTS.mdに置けます。テストコマンド、禁止操作、レビュー形式、承認が必要な操作は、まずAGENTS.mdへ置く候補です。
根拠
AGENTS.mdは、repoやディレクトリ単位で作業前提を伝えられるため、チームで共有する情報に向いています。永続メモリへ個人ごとに散らすより、repoに近い場所へ置いたほうがレビューしやすい情報があります。
注意点
AGENTS.mdは自然言語の作業契約であり、実行権限そのものではありません。保存場所を整えることと、permission profileやapprovalで実行境界を作ることは分けます。
Claude Codeではmemoryのスコープを確認する
Claude Codeを使う場合は、memory関連の標準機能や設定のスコープを確認します。プロジェクトに残す情報、ユーザー側に残る情報、外部ツールに残す情報を混ぜないようにします。
確認項目
どこに保存されるか、誰が読めるか、repo外へ持ち出されるか、削除できるか、同期されるか、チームメンバーと共有されるかを確認します。
評価基準
同じ情報をAGENTS.md、Claude Code memory、外部メモリに重複保存しないことです。重複すると、どれが正しいか分からなくなります。
read-only評価から始める
- 1日目
保存ルールと除外条件を決めます。
- 2日目
read-onlyで保存候補を出します。
- 3日目
人間が保存可否をレビューします。
- 削除確認
誤保存を消せるか確認します。
保存できることより、消せることを先に確認します。
Agentmemoryのような永続メモリを試す時、最初から書き込み作業に使わないほうが安全です。まずはread-onlyのcodebase理解と作業ログ整理で評価します。
最初の評価手順
1日目は、保存対象のルールを決めます。2日目は、既存repoを読ませて、設計判断やテスト手順の候補だけを出させます。3日目は、その候補を人間がレビューし、保存してよいものだけを残します。
条件
対象repoは低リスクなものにします。secretや顧客ログを含むrepoでは始めません。外部通信、MCP write tool、本番環境への接続は使いません。
注意点
read-only評価でも、ログやファイル名に機密情報が含まれる可能性があります。メモリ候補を保存する前に、具体値を抽象化する工程を入れます。
削除手順を先に確認する
保存より先に削除を確認します。どのファイルやDBに保存されるのか、手動で消せるのか、プロジェクト単位で消せるのか、誤保存した時にどこまで戻せるのかを見ます。
評価基準
削除手順を説明できないメモリは、チーム導入しません。保存できることより、消せることのほうが運用では重要です。
停止条件
保存場所が分からない、削除できない、プロジェクト境界を切れない、secret除外を設定できない。この場合は、便利そうでも導入を止めます。
評価タスクは3本で見る
| 項目 | 内容 | 見方 |
|---|---|---|
| Codebase理解 | 長期知識と一時情報を分けます。 | |
| 継続リファクタ | 前日の判断を正しく参照できるか見ます。 | |
| レビュー報告 | 次回使う観点へ抽象化できるか見ます。 | |
| スコアカード | 保存、境界、更新、削除を評価します。 |
過去ログを丸ごと持ち越すだけなら合格にしません。
永続メモリの効果は、派手なデモより日常タスクで見ます。最初は、codebase理解、継続リファクタ、レビュー報告の3本で十分です。
1本目はcodebase理解
未知のrepoを読ませ、構成、主要モジュール、テスト手順、よくある変更点を整理させます。そのうえで、保存してよい長期知識と、その場限りの調査結果を分けさせます。
成功条件
保存候補が短く、根拠ファイルがあり、secretや一時ログを含まず、次回も使える情報になっていることです。
失敗条件
存在しない設計を前提にする、ファイル名だけで判断する、非公開ログを保存候補にする、抽象化せずに具体値を残す場合は不合格です。
2本目は継続リファクタ
複数日に分けて小さなリファクタを試します。1日目に方針を決め、2日目に前日の判断を参照して再開できるかを見ます。
成功条件
前日の方針を正しく参照し、変更範囲を広げず、未完了項目と次の確認点を報告できることです。古い方針を更新する必要がある場合は、その理由を示します。
注意点
永続メモリがあると、前の判断を強く引きずることがあります。前提が変わった場合に、古い記憶を修正できるかも評価対象です。
3本目はレビュー報告
PRレビュー後の指摘、修正方針、未検証項目を整理させます。保存するのは、個別PRの詳細ではなく、次回以降も使うレビュー観点だけにします。
成功条件
「このrepoではUI変更時にキーボード操作を確認する」のような再利用可能な観点に抽象化できることです。PR固有の議論や担当者名を残さないことも見ます。
評価基準
メモリが次回の品質を上げるか、単に過去ログを丸ごと持ち越しているだけかを分けます。丸ごと保存は検索には便利でも、判断材料としては重くなります。
セキュリティ・コスト注意
envやcredentialsを保存しない設計にします。
保存場所、同期、バックアップを確認します。
保存候補を人間が確認します。
古い記憶を定期的に消します。
記憶は増えるほど棚卸しが必要になります。
永続メモリは、コスト削減やトークン節約の文脈で語られがちです。ただし、チーム導入ではセキュリティ、レビュー、削除、監査のコストも見ます。
secretと顧客データを除外する
メモリ候補にsecretや顧客データが入らないようにします。.env、credentials、障害ログ、アクセスログ、顧客名、メール、契約条件は保存対象外です。
確認項目
除外パターン、保存前レビュー、保存後の一覧確認、削除手順、ログの扱いを確認します。自動保存がある場合は、初回導入では無効または限定します。
注意点
「ローカル保存だから安全」とは限りません。端末バックアップ、同期、共有フォルダ、MCP tool、CI artifact、画面共有などで漏れる経路があります。
古い記憶のコストを見る
メモリは増えるほど、不要な情報も増えます。古い判断が残ると、CodexやClaude Codeが誤った前提で提案することがあります。
評価基準
確認日、対象repo、対象ディレクトリ、見直し条件がない記憶は、長期保存に向きません。期限や見直し条件を持てない情報は、作業ログに留めます。
改善方法
月1回、メモリ棚卸しをします。使われていない記憶、矛盾している記憶、期限切れの回避策、プロジェクト境界をまたいだ記憶を削除します。
失敗点とハマりどころ
ログや会話を丸ごと残してしまう。
別repoの方針を持ち込む。
撤回済み方針を参照し続ける。
誤保存を消せない。
便利さより、止まれる状態を重視します。
永続メモリ導入の失敗は、メモリが動かないことより、動きすぎることから起きます。覚えすぎ、信じすぎ、消せなさすぎが問題になります。
何でも保存する
保存対象を決めないまま使うと、作業ログ、会話、失敗、個別判断が混ざります。次のセッションで便利に見えても、正しい前提かどうか分からなくなります。
プロジェクト境界が混ざる
別repoのテスト手順や設計方針を持ち込むと、正しそうで危険な提案になります。repoごとのメモリ分離ができない場合は、チーム導入を止めます。
古い記憶を修正しない
一度保存した方針が古くなっても、そのまま残ることがあります。永続メモリには、保存だけでなく更新と削除の運用が必要です。
実務で使うなら
- ルール
保存可否と除外条件を決めます。
- 調査
read-onlyで候補を出します。
- 継続
翌日に再開できるか見ます。
- 判断
削除テスト後に継続可否を決めます。
効果測定と撤退条件を同時に扱います。
実務で試すなら、まず1週間の小さなパイロットにします。目的は、永続メモリが便利かを見ることではなく、保存、参照、更新、削除、監査が回るかを見ることです。
1週間パイロット
1日目に保存ルールを作り、2日目にread-only調査、3日目に保存候補レビュー、4日目に継続タスク、5日目に削除テストとスコアカード確認をします。
スコアカード
| 評価軸 | 合格ライン |
|---|---|
| 保存対象 | secretや個人情報を含まない |
| 根拠 | 保存候補に根拠ファイルや判断理由がある |
| 境界 | repoやプロジェクトごとに分離できる |
| 更新 | 古い記憶を修正できる |
| 削除 | 誤保存を消せる |
| 効果 | 次回タスクの説明量とレビュー負荷が下がる |
関連導線
チーム導入の土台は、先にCodex 101をチーム導入へ落とす記事で整理できます。評価タスクを作る時は、AI Coding Benchmark Kitの記事と合わせて見ると判断しやすくなります。
FAQ
必ず下がるとは断定できません。
共有作業契約はrepo側へ置きます。
個人でもsecret除外は必要です。
日常タスクで比較します。
迷ったら、保存しない理由から確認します。
Agentmemoryを入れればトークン消費は必ず下がりますか？
必ず下がるとは言えません。保存した情報が短く、正しく、次回タスクで再利用される場合は説明量を減らせます。一方で、不要な記憶が増えると、参照や確認のコストが増えます。
AGENTS.mdと永続メモリはどちらを優先しますか？
repo全員に共有したい作業契約はAGENTS.mdを優先します。永続メモリは、セッションをまたいで使う長期知識や作業継続の補助に限定します。
個人利用なら細かいルールは不要ですか？
個人利用でも、secret、顧客データ、本番ログを保存しないルールは必要です。個人の端末でも、バックアップや同期で意図せず広がることがあります。
既存記事の評価タスクは使えますか？
使えます。導入評価のタスク設計は、AI Coding Benchmark Kitの記事を参考にすると、比較条件を揃えやすくなります。
更新履歴
- 2026年5月31日
Agentmemory、Claude Code memory、Codex AGENTS.md、permissionsを確認して初版を作成しました。
導入前には最新のREADMEと公式ドキュメントを確認してください。
2026年5月31日 JSTに、AgentmemoryのGitHub、Claude Code memory関連ドキュメント、CodexのAGENTS.md guide、Codex permissionsを確認して初版を作成しました。OSSや公式機能は更新されやすいため、導入前には最新のREADMEと公式ドキュメントを確認してください。