Codexに“第２の脳”を追加して、話が切れても文脈を残せるようにする仕組みを知ってますか？その名もAgentmemory。それの導入手順、設定方法、ハマりどころまで全部まとめました。毎回同じ説明をするのが面倒な人、トークンを無駄にしたくない人は必見です。
毎朝Claude Codeを立ち上げて「昨日の続きから」と入力すると、返ってくるのは「前回のセッションの内容を教えてください」。なんなら毎日起きてる現象なんですよ。
セッションが切れた瞬間、プロジェクトの文脈はリセットされる。CLAUDE.md に書いてあることは読まれるけど、3日前にバグった原因の議論とか先週決めた設計方針の理由とか、そういう「文脈の重み」は丸ごと消える。
ある開発者がこう書いてました。
only 30 days of your Claude Code session history is saved on your computer by default, you have to set that longer if you want to have memory over all of them.
セッション履歴のデフォルト保持期限は30日。しかも保存されてるのは「文字列としての記録」であって、文脈として呼び出される仕組みじゃない。
Codex側でも基本同じです。GPT-5.5 のコンテキストは API で 1M token、Codex CLI では 400K。物理的なサイズは十分に見えるんですが、実運用では200K前後で精度が落ち始めます。
そこに、4,000Star突破で速報が走ったAgentmemory が降ってきた。ガチで使い倒して 1 週間。結論から書きます。
Codex/Claude Code に「無限メモリ」を後付けするという表現は、半分は誇大広告で、半分は本当です。
本当の方を最大化する設定の仕方、誇大広告の方を引き当てた時の回避策を、この記事で全部書きます。
1. なぜ Codex/Claude Code は「記憶喪失」するのか
Agentmemory の前に、「なぜ既存ツールでは無理なのか」を整理させてください。ここを抜かすと「便利なメモリツールを足しました」で終わって、本質を取り違えます。
コンテキストウィンドウが大きくても、実運用では使い切れない
2026年5月時点で、主要モデルのコンテキストウィンドウはこう。
● Claude Opus 4.7: 1M token（200K から拡張）
● GPT-5.5: 1M token（API）/ Codex CLI では 400K 制限
● Gemini 3.1 Pro: 1M token
日本語換算で約141万字。本一冊どころかシリーズもの全巻入る容量です。数字だけ見ると「全部入るやん」と思える。
ただ、Anthropic 自身が公式エンジニアリングブログでこう書いてます。
コンテキストウィンドウ内のトークン数が増えるにつれて、モデルがそのコンテキストから情報を正確に想起する能力は低下する。
物理的に入る ≠ 精度を保てる、なんですよね。経験的には200K〜400K あたりから「Claude さっき言ったこと忘れてない？」が始まる。これが俗に言う context rot（コンテキスト腐敗） です。
Claude Code 本家でも起きた「思考の崩壊」
実例を出しておきます。2026年4月23日、Anthropic が公式にpostmortem を出しました。
3月26日にロールアウトされたバグで、「1時間アイドル後の古い思考をクリアする機能」が、セッション再開後も毎ターン発火する状態になっていた。
結果、median の visible thinking 長さがこう変化した。
● 1月: 2,200字
● 3月: 600字
73% collapse。Claude Code 公式が自分の文脈を勝手に削っていた期間が約1ヶ月続いたわけです。
これが何で大事かというと、context rot は「使う側のミス」じゃなくて、サービス側の都合でも起きる、という話。CLAUDE.md をどれだけ綺麗に書いても、ツール側のチューニングひとつで「先週の文脈」は紙くずになる。
既存の対処（CLAUDE.md / auto-memory）の限界
Anthropic も対策は打ってます。Claude Code の auto-memory 機能は、セッション間で学んだことを記憶して再開時に呼び出してくれる仕組み。Claude Code チームが5月にアナウンスしてました。
ただ、これは compaction とセットで動く構造になってます。「コンテキストを圧縮する → 重要な情報だけメモリに退避する」というフローを内部でやってて、圧縮のたびに「何を残すか」を AI 側が判断するわけですが、ここの判断ロジックはユーザーが触れない。
しかも auto-memory は Claude Code 専用です。Codex / Cursor / Cline / Hermes など他のエージェントから読みに行く API はない。複数エージェント使ってる人ほど「同じ前提を3回説明する」が常態化していくわけです。
2. Agentmemory は何が違うのか
ここから本題。Agentmemory（公式リポは rohitg00/agentmemory）は、2026年5月15日時点で 8.8k Star に達したオープンソースのメモリエンジンです。@Codestudiopjbk の速報時点では「4,000+ Star」でしたが、その後2倍以上に伸びてる。ライセンスは Apache 2.0、TypeScript ベース、最新リリースは v0.9.12（5月13日）。完全 self-hosted で、外部 SaaS への送信ゼロ。
開発者の思想
リード開発者 Rohit Ghumare 氏（@ghumare64）が、Agentmemory の本質を一言でまとめてます。
Built this 6 months ago with agentmemory: persistent memory for AI coding agents. Same core idea: stop re-deriving, start compiling.
「再導出をやめて、コンパイルし始める」。ここが既存ツールとの哲学的な差なんですよ。
CLAUDE.md は「毎回再導出するためのインプット」でした。プロジェクト構造、規約、過去の決定。それを毎セッション AI が読み直して、再解釈して、また忘れる。Agentmemory が変えるのは、この「再導出ループ」を「コンパイル済みの記憶層」に置き換えるという発想です。
3層アーキテクチャ（README から要約）
公式 README に書いてある内部構造は、3 段に分かれてます。
1 つ目が Capture（取り込み）。12 個の Claude Code ライフサイクル hooks で自動キャプチャしてくれるので、手動で memory_save する必要はない。
2 つ目が Pipeline（処理）。重複排除 → privacy filter（API キー・PII 自動除去）→ AI ベースの圧縮、というフローで観測を整理する。
3 つ目が Retrieval（検索）。3 系統のハイブリッド検索（BM25 / vector / graph）を RRF k=60 で融合してます。BM25 が語幹化キーワード+類義語拡張、vector が密埋め込みの cosine 類似度、graph がナレッジグラフの traversal。Reciprocal Rank Fusion で融合するので、片方の手法で取りこぼしてももう片方が拾う。結果はセッション分散（max 3 per session）で返すので、同じセッションの結果ばかり並ぶ問題も解消されてます。
4-tier memory（Ebbinghaus 着想）
もうひとつ面白いのが、メモリを 4 階層に分けて時間と共に「育てる」設計です。
最下層が Working で、ツール実行の生観測・エラーログ・コマンド履歴のような短期記憶。Episodic に上がると「何が起きたか」のセッション要約になる。Semantic に上がると「自分が知っていること」、抽出された知識やパターンに変わる。最上位が Procedural で、「どう進めるか」のワークフロー化された手順。
頻繁にアクセスされた記憶は強化され、参照されない記憶は Ebbinghaus 忘却曲線で減衰する。人間の記憶構造に似せた仕組みです。これが「再導出をやめてコンパイル」の正体。
競合との位置づけ
ここは正直に書きます。GitHub Star だけ見ると、Agentmemory は競合に対してまだ小さい。
● Mem0: 55.7k Star、汎用メモリレイヤー、API/Cloud first
● Letta（旧 MemGPT）: 22.7k Star、エージェント OS、virtual context management
● Agentmemory: 8.8k Star、coding agent 特化、ローカル SQLite
数で勝負しに行くと負けます。ただ Agentmemory が刺さるのは coding agent 特化と decoupled 設計です。Rohit 氏自身がこう書いてる。
If you want actual extended memory architecture, cross-agent, portable, not locked to a particular agent, check out agentmemory. It's designed as a decoupled memory layer that works across harnesses.
Cursor、Cline、Claude Code、Codex、Hermes、どれにも同じメモリで接続できる。これが Mem0 や Letta との差別化軸です。Mem0 は汎用すぎて coding 文脈の自動キャプチャ機構が弱く、Letta はエージェント OS なのでメモリ層だけ取り出しにくい。
「コードエージェントを複数併用してる開発者」というニッチに、Agentmemory はど真ん中で刺してます。
3. 3分で始める ― インストールと初期設定
ここから手を動かしていきます。Mac / Linux / Windows どれでも基本フローは同じ、Node.js 環境さえあれば走ります。
ステップ 1: メモリサーバーを起動
ターミナルを 1 枚開いてこれを叩くだけ。
メモリサーバー起動（常駐させる）
初回は依存パッケージのダウンロードで 1〜2 分。起動成功すると http://localhost:3111 で REST API が立ち上がります。ヘルスチェックはこれ。
curl http://localhost:3111/agentmemory/health
→ {"status":"ok","version":"0.9.12"}
ビューアもセットで起動するので、ブラウザで http://localhost:3113 を開けばメモリの中身が可視化されてます。
ステップ 2: デモデータを入れてみる
中身がカラだとイメージしにくいので、サンプルデータを入れます。
別ターミナルでデモ投入
npx @agentmemory/agentmemory demo
これでダミーのセッション履歴が SQLite に書き込まれて、ビューアで観測できる状態になる。
ステップ 3: Claude Code に組み込む
Claude Code 側からはプラグインマーケットプレイス経由で入れるのが最短。
Claude Code 内で実行
/plugin marketplace add rohitg00/agentmemory
/plugin install agentmemory
これだけで以下が自動登録されます。
● 12 個の hooks（SessionStart / PostToolUse / Stop など全ライフサイクル）
● 4 個の skills（recall / consolidate / export / governance）
● 51 個の MCP tools（AGENTMEMORY_TOOLS=all で全部、デフォルトはコア 15 個）
ステップ 4: Codex CLI に組み込む
Codex 側もほぼ同じ流儀。
codex plugin marketplace add rohitg00/agentmemory
codex plugin install agentmemory
Codex の場合 AGENTMEMORY_URL=http://localhost:3111 が環境変数として自動セットされる。注意点として、Codex は MCP の同期性がClaude Code より厳しいので、サーバーが落ちてると即座にエラーになります。常駐起動を忘れずに。
ステップ 5: Cursor / Cline などに繋ぐ
Cursor 経由で使う場合は ~/.cursor/mcp.json に追記する形。
{
"mcpServers": {
"agentmemory": {
"command": "npx",
"args": \"-y", "[@agentmemory/mcp"],
"env": { "AGENTMEMORY_URL": "http://localhost:3111" }
}
}
}
Cline、Hermes、その他 MCP 対応エディタも同じパターンで繋がります。Cursor の MCP 設定は「閉じて開き直す」だけだと反映されない罠があって、これは後の「ハマりどころ 5 選」で詳しく書きます。
ステップ 6: ヘルスチェックの儀式
セットアップ完了後、必ずやっておくチェックリストはこれ。
1. メモリサーバー疎通
curl http://localhost:3111/agentmemory/health
2. iii-engine バージョン確認（v0.11.2 必須）
iii --version
3. ビューアでメモリ確認
3 番目のビューアで「観測が記録されてる」状態が見えれば、セットアップ成功。Node.js が入ってる前提なら 3 分かかりません。
4. 基本の 3 アクション ― 保存・検索・自動圧縮
Agentmemory の使い方は、大きく 3 つのアクションに整理できます。
アクション 1: 保存（自動キャプチャが基本）
Mem0 や Letta だと memory_add(...) のような手動コマンドで保存するのが普通。Agentmemory は思想が違って、12 個の hooks で全部自動キャプチャします。
たとえばこんな観測が、何もしなくても記録される。
● Bash ツール実行時のコマンドと出力（PostToolUse hook）
● ファイル編集の前後 diff（PreToolUse / PostToolUse hook）
● セッション開始時の関連メモリ自動注入（SessionStart hook）
● セッション終了時の要約圧縮（Stop hook）
「何を保存するかをユーザーが判断する負荷」がゼロになるのが最大の体感価値。CLAUDE.md だと「ここは大事だから書いておこう」「ここは消そう」を毎回考えてたわけですが、その判断ロジック自体を AI 側に任せる発想です。
手動保存もできます。MCP tool 経由で memory_save を呼べば「これは大事」と明示打刻できるので、重要な設計判断は自動キャプチャに任せず明示保存するのが安全。
アクション 2: 検索（3 系統ハイブリッド + RRF）
検索は MCP tool 経由か REST API 直叩きの 2 通り。代表的な MCP tool はこのあたり。
● memory_recall ― 自然言語で関連メモリを取得
● memory_smart_search ― ハイブリッド検索のフル機能版
● memory_sessions ― セッション単位でリスト
● memory_timeline ― 時系列で並び替え
● memory_relations ― 関連エンティティのグラフ traversal
REST API 直叩きならこう。
「Supabase の auth まわりで前にやった修正」を探す
curl -X POST http://localhost:3111/agentmemory/search \
-H "Content-Type: application/json" \
-d '{"query": "supabase auth fix", "limit": 5}'
返ってくるのは BM25 / vector / graph の3 系統が RRF k=60 で融合された結果。レイテンシは P50 で 20ms 未満（ローカルSQLite なので速い）。
公式ベンチマーク（LongMemEval-S、500 問、ICLR 2025）での精度はこれ。
● R@5: 95.2%（Top 5 候補に正解が入る確率）
● R@10: 98.6%
● MRR: 88.2%
注意点として、これは「検索精度」で「end-to-end のQA 精度」ではないです。「正解が候補のどこかに入ってる確率」なので、Claude がそれを使ってちゃんと答えるかは別の問題。ここを混同すると過信します。
アクション 3: 自動圧縮（4 階層を時間と共に育てる）
Stop hook が動くたびに、3 段の圧縮が順に走ります。
まず Working → Episodic で生のツール実行ログをセッション要約に畳む。次に Episodic → Semantic で複数セッションの出来事から「パターン」「知識」を抽出。最後に Semantic → Procedural で、よく繰り返される手順を「ワークフロー」として固める、という流れ。
これで「全部保存し続けて検索のノイズになる」問題が自動的に解消されます。セッション開始時に注入されるトークンバジェットは、デフォルト 2,000 tokens。これだけで「前回までの文脈」が必要十分な形で復元される設計です。
5. Codex / Claude Code 二刀流のワークフロー
ここからは実運用の話。Codex も Claude Code もガチで併用してる人向けに、3 つのワークフローパターンを書きます。
パターン 1: 個人開発の 1 日フロー
agentmemory サーバーを常駐させておくと、Claude Code 起動時に SessionStart hook が発火して前日の Episodic memory が自動注入されます。「昨日の続きから」と言わなくても「Supabase の RLS まわりで詰まってた話の続きやろう」と Claude 側が把握した状態で会話が始まる。
コーディング中は PostToolUse hook がコマンド・出力・差分を SQLite に書き続け、セッションを閉じると Stop hook が Working を Episodic に圧縮する。翌朝それが自動で読み込まれて、ループ完成です。
パターン 2: 複数プロジェクトの使い分け
Agentmemory はメモリを 3 スコープに分けられます。user スコープは個人全体に紐づく層で、コーディング規約の好みや命名の癖など「自分の癖」が入る場所。project スコープはプロジェクトごとに別管理で、SQLite ファイルも別。local スコープはそのマシンだけに残って、チーム共有モードでも外に出ない。
プロジェクト切り替え時に AGENTMEMORY_PROJECT=foo-app と環境変数を変えれば別の SQLite ファイルが参照される。複数プロジェクトを並行してる人にはここがガチで効きます。A プロジェクトの設計判断が B プロジェクトの議論に混ざってくる現象が、CLAUDE.md 運用だとよく起きてた。Agentmemory なら物理的に分離されるので混線しない。
パターン 3: チーム共有・上場企業との共同開発
うちは現在、上場企業の方々と AI エージェントを共同開発してるんですが、ここで地味に効くのが MCP server 共有モード。collab=true のフラグを立てると、複数の Codex / Claude Code インスタンスが同じメモリサーバーを参照できる。
サーバー側
AGENTMEMORY_COLLAB=true npx @agentmemory/agentmemory --bind 0.0.0.0
チーム内 VPN 経由で参照すれば、複数人が「同じプロジェクトの記憶」を共有しながら作業できる。ただし privacy filter は強めに効かせる必要があります。API キーや個人情報が混入したらチーム全員に共有されるので、.agentmemoryignore での除外設定は必須。これも後の「ハマりどころ」で触れます。
二刀流ならではの落とし穴
Codex と Claude Code を同じプロジェクトで切り替えながら使う場合、メモリは共有されますがプロンプト構文は別物です。Claude Code の /plugin コマンドは Codex では効かない、Codex の codex plugin install は Claude Code では効かない。「両方使えるツール」と言っても設定は別個に必要。ここを勘違いして初週ハマる人が多いです。
6. ベンチマークの読み方 ― 数字を「体感」に翻訳する
公式に書いてある数字を、実運用の感覚に翻訳します。
「92% トークン削減」の正体
速報や Medium 記事で踊ってる「92% 削減」は per-session ベースの話です。
● 従来の CLAUDE.md 手動運用: 1 セッション約 22,000 tokens 消費
● Agentmemory 経由: 1 セッション約 1,900 tokens 消費
● 削減率: 約 91-92%
セッション開始時の文脈注入トークンがガッツリ減るわけです。年間ベースだと数字が変わって、README の Token Savings table にはこう書いてある。
● LLM-summarized 運用: 約 650K tokens / yr（約 $500 / yr）
● Agentmemory: 約 170K tokens / yr（約 $10 / yr）
トークン数だと約 74% 減ですが、コスト換算では98% 削減。$500 が $10 になる計算です。差が出る理由は、Agentmemory がローカル SQLite + ローカル埋め込みで動くから。LLM ベースの圧縮を毎回走らせる Mem0 や Letta と違って、運用コストが極小になる構造です。
「LongMemEval-S R@5 95.2%」の意味
LongMemEval-S は ICLR 2025 で出された長期メモリのベンチマーク（500 問、各問題で約 48 セッション、約 115K tokens の文脈）。主要ツールで並べるとこう。
ツール | R@5 |
|---|
Agentmemory | 95.2% |
|---|
Mem0（2026年4月の新アルゴリズム） | 94.8% |
|---|
Letta | 83.2% |
|---|
Cognee | 72.5% |
|---|
Zep | 71.0% |
|---|
Mem0（旧アルゴリズム） | 68.5% |
|---|
Mem0 は新アルゴリズムで肉薄してきてるので、数字単独で「圧勝」と書くと公平じゃない。ただ Agentmemory は coding agent 特化の自動キャプチャ機構と組み合わせての 95.2% なので、「精度 × 運用負荷ゼロ」のトレードオフがいい位置にいる、というのが現時点の評価です。
繰り返しますが R@5 は検索精度で、Claude や Codex が最終的に正しい答えを出す確率ではない。ここを混同すると過大評価につながります。
Codex 400K vs Opus 4.7 1M の「物理 vs 実用」
ベンチマーク数字を眺めてて、もうひとつ大事な気づきがありました。
Claude Opus 4.7 は context 1M token に拡張された。GPT-5.5 も API では 1M token。これだけ見ると「もうメモリツール要らないんじゃ？」と思える。
ただ Codex CLI は実際には 400K に制限されてる。物理上限と実運用上限はズレてるんですよね。しかも Anthropic 自身が「コンテキストが増えると想起精度が下がる」と書いてる通り、200K〜400K で context rot が始まる。
つまり物理サイズが増えても、メモリエンジンの必要性は減らない。むしろ「広い context window をどう効率的に使うか」が新しい技術課題になってる、という現状です。
7. ハマりどころ 5 選― 実際にやって踏んだ地雷
ここからは正直に書きます。公式 README やインフルエンサーの紹介ツイートには出てこない、実際に入れて運用したら踏んだ地雷を 5 個。GitHub Issues を辿って再現性のあるものだけ拾いました。
ハマり 1: iii-engine v0.11.2 バージョン不一致
セットアップ直後、こんなエラーが出る人が一定数います。
iii: command not found
あるいは
Version mismatch: expected v0.11.2, got v0.11.0
Agentmemory は内部で iii-engine というバイナリに依存していて、バージョンが v0.11.2 にピン留めされてる。別バージョンが既に入ってると起動段階でこける。回避策は OS 別に release から固定バージョンを取ってくる方法。
macOS arm64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-aarch64-apple-darwin.tar.gz \
chmod +x ~/.local/bin/iii
Linux x64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-x86_64-unknown-linux-gnu.tar.gz \
確認
iii --version # v0.11.2 が出ればOK
ここをスキップするとあとから全部が動かなくなるので、最初に通しておきます。
ハマり 2: Issue #181 ― 無限ループでゴーストセッション量産
これがガチでヤバいやつ。v0.9.1 で報告された致命的バグで、API キー未設定の状態で Stop hook が /summarize を呼ぶと、子セッションが無限生成される。
Stop hook → /summarize → 子セッション生成
↓
子セッションの Stop hook も発火 → /summarize → さらに子セッション
↓
(無限ループ)
数分で約 579 個のゴーストセッションが生成された、という報告が GitHub Issue #181 に残ってます。回避策は 3 つ。
案1: agent-sdk モードを無効化（推奨）
export AGENTMEMORY_ALLOW_AGENT_SDK=false
案2: フェイク API キーで強制エラー
export AGENTMEMORY_ANTHROPIC_API_KEY="fake-key"
案3: 実 API キーを設定
export AGENTMEMORY_ANTHROPIC_API_KEY="sk-ant-..."
本番運用するなら案 1 か案 3 が安全。案 2 は「とりあえず動かしたい」初日だけ。
ハマり 3: Issue #159 ― MCP と REST API が別 KV で動いてる
これも知らないと首を傾げる現象。MCP tool（memory_search 等）を呼ぶと毎回空結果が返ってくるのに、REST API（POST /agentmemory/search）には同じデータでヒットがある。
REST API: GET /agentmemory/sessions → 69 observations
MCP tool: memory_sessions → [] (empty)
原因は @agentmemory/mcp パッケージと Agentmemory サーバーが完全に別の KV store を持ってる設計になってること（Issue #159）。MCP は「ローカル KV」、サーバーは「別の KV」で、相互通信のコードパスがない。2026年5月時点で Issue は open のまま。回避策はこう。
● 案 1: REST API を直接使う（MCP tool 経由じゃなくて curl や fetch で）
● 案 2: /mcp hook を一旦 disable して、サーバー専用運用にする
将来的に直る予定はあるみたいですが、当面はこの仕様前提で組むしかないです。
ハマり 4: Cursor / VSCode 系で MCP が反映されない
~/.cursor/mcp.json を編集してCursor を再起動したのに、/mcp list に Agentmemory が出てこない。Cursor だけじゃなく Windows ストアアプリ全般で起きる現象です。
GUI の「×」ボタンで閉じても、WindowsApps のバックグラウンドプロセスが残るのが default 挙動。古いプロセスが古い設定をメモリ保持したまま走り続ける。完全終了の儀式が必要。
macOS
pkill -9 Cursor
open /Applications/Cursor.app
Windows (PowerShell)
→ 再起動
設定ファイル側を疑う前にまず「プロセス残留チェック」を default にすると、ここでハマる時間が消えます。
ハマり 5: privacy filter で観測が勝手にdrop される
「サーバー動いてるのに、ビューアに観測が出てこない」現象も初週によく起きます。ログを見るとこんなwarning が並んでる。
[warn] observation dropped: private_tag detected
[warn] observation dropped: private_email detected
これ、バグじゃなくて仕様です。Agentmemory の privacy filter は API キー・パスワード・メールアドレス・PII を自動検出して、そういう観測を記録せずに捨てる。セキュリティ上は嬉しい挙動ですが、知らないと「動いてない」と勘違いする。共存策はこう。
.agentmemoryignore でファイル単位の除外
echo ".env" >> .agentmemoryignore
echo ".env.local" >> .agentmemoryignore
echo "\\/*.key" >> .agentmemoryignore
echo "\\/\password\" >> .agentmemoryignore
特に API キーを観測に含む実験コードを動かす時は、事前にこのファイルを置いておく運用が安全です。
8. まとめ ― 「無限メモリ」は context window の拡張じゃない
Agentmemory を 1 週間ガチで使ってみて、いちばん腹落ちした感覚はこれ。「無限メモリ」って表現はcontext window の物理的拡張のことじゃない。
1M token に増えたって、200K で精度が落ちるなら結局意味がない。物理サイズ競争はもう勝負がついてる気がします。そうじゃなくて、Agentmemory が手に入れさせてくれるのは意味的な外部脳です。
セッションの中ではなくセッションの外に、構造化された記憶を置いておく。必要な時に必要な分だけ呼び出して、終わったら閉じる。覚えとくべきものは時間と共に育って、忘れていいものは静かに減衰していく。人間の記憶の使い方と同じ構造なんですよね。
開発者の頭の中で起きる変化を一言で書くと、「セッション切れたら終了」から「セッション間で記憶が育つ」への遷移です。
業界全体もこの方向に動いてます。DeepLearning.AI のエージェントメモリコース、Mem0 の「stateless agents を stateful にする」メッセージ、MemGPT 論文の「LLMs as Operating Systems」──結局はどれも外部メモリの話で、Agentmemory はその coding agent 文脈での 1 個の解です。
Mem0 でも Letta でもいいし、自分で実装してもいい。ただガチで Codex / Claude Code を使ってる人にとって、現時点で最短で「無限メモリの感覚」を試せるツールではあると思います。率直に言って、入れる価値はあります。
9. このアカウントについて
ここまで読んでいただいた方へ。このアカウント @Codestudiopjbk は Codex ガチ勢 3 人で運営してます。
● 大学院生・ポスドク対象の開発プログラム参加
● 賞金 30 万円獲得
● 現在、上場企業様と AI エージェントを共同開発中
普段の発信内容はこんな感じ。
● GPT-5.5 / OpenAI Codex を使った実装事例
● Codex 活用・CLI 自動化・開発トレンド
● 海外の GPT-5.5 / Codex 最新情報の翻訳と検証
● Claude Code との実用比較（数百時間使い込みベース）
● 上場企業との共同開発で得た学び
開発思想から設計・実装・改善まで、動くプロダクトを世に出すまでの全工程を毎日発信してます。ご関心のある方はぜひフォローしてチェックしてみてください。有益だと思います。
開発系のご相談はDMまで。 Codex 導入・自動化設計・AI エージェント実装のご相談、お気軽にどうぞ。
参考・引用
● [Rohit Ghumare (rohitg00/agentmemory)] (2026-05-13) \Agentmemory v0.9.12 — Memory Engine for Coding Agents\) — 公式リポ、Apache-2.0、8.8k Stars、TypeScript
● [Rohit Ghumare] (2026-04) \"Built this 6 months ago with agentmemory: persistent memory for AI coding agents"\) — 開発者思想
● [GitHub Issue #181] \Stop-hook → /summarize → agent-sdk infinite recursion\) — ハマり2 一次ソース
● [GitHub Issue #159] \Standalone MCP tools don't proxy to running agentmemory server\) — ハマり3 一次ソース
● [Anthropic Engineering] \Effective Context Engineering for AI Agents\) — context engineering の公式ガイダンス
● [Anthropic] (2026-04-23) \April 23 Postmortem\) — Claude Code thinking length collapse 事件の社会証明
● [Mem0] \Introducing Mem0\) — Mem0 思想と Taranjeet Singh 引用
● [Letta] \Benchmarking AI Agent Memory\) — Letta ベンチマーク数字の出典
● [Charles Packer et al.] (2023-10) \MemGPT: Towards LLMs as Operating Systems\) — virtual context management 論文、Agentmemory の理論先行研究
● \[DeepLearning.AI] \Agent Memory: Building Memory-Aware Agents\) — Andrew Ng / Oracle コース
