Claude CodeやCursor、GitHub Copilotなどのコーディングエージェントを使っていると、同じ設計判断を何度も説明し直す場面に遭遇します。「なぜGraphQLを選んだのか」「あのバグ修正の理由は何だったか」といった背景情報は、セッションが終わると消えてしまいます。この問題を解決する「エージェントメモリ（AIエージェントが過去の決定や文脈を記憶し、必要なときに呼び出す仕組み）」をどう構築するかで悩んでいるエンジニアに向けて、実装方式の選び方を整理します。
エージェントメモリをどこまで自前で持つか、クラウドサービスに任せるかは、チーム構成やセキュリティ要件によって最適解が変わります。この記事では4つの選択肢を比較し、プロジェクトの状況に応じた選び方を示します。
エージェントメモリに求められる3つの機能
判断軸に入る前に、何が「メモリ」として機能するかを整理しておきます。単なるメモ置き場との違いはここにあります。
1つ目は「決定とその理由を保存する」機能です。「APIレイヤーにGraphQLを使う」という事実だけでなく、「モバイル画面でREST呼び出しが10回以上必要だったから」という理由まで残せるかが重要です。理由がなければ、次のエージェントが同じ議論を蒸し返してしまいます。
2つ目は「意味で検索できる」機能です。キーワード一致ではなく、payments/webhook.tsを編集するエージェントが、二重課金バグの注意書きを自動的に受け取れるかどうかがポイントです。これには埋め込みベクトル（文章の意味を数値の配列に変換する技術）を使った検索が必要になります。
3つ目は「鮮度の劣化を検知する」機能です。ファイル名が変更されたのに古いメモだけが残っていると、それを読むすべてのエージェントが古い地図で作業することになります。静的なファイルも同じ問題を抱えますが、気づくのがさらに遅れがちです。
判断軸1: チーム規模と共有範囲
1人で複数のリポジトリを行き来するのか、チーム全体で記憶を共有したいのかで、必要な構成が大きく変わります。個人利用なら、ローカルで完結する構成で十分なことがほとんどです。
チームで共有するなら、複数人・複数マシンからアクセスできる永続ストレージが必須になります。ここで初めて「サービスとして運用する」という選択が現実味を帯びてきます。
判断軸2: インフラ運用に割ける時間
Postgresとpgvector（PostgreSQLでベクトル検索を可能にする拡張機能）を自前で立てる構成は、技術的には難しくありません。しかし稼働後は、認証・バックアップ・マイグレーション、そして埋め込みモデルが更新されたときに全ベクトルを再計算する作業まで、すべて自分の仕事になります。
これらは本来プロダクト開発に使いたい時間を奪います。インフラ運用の工数を割けるかどうかは、自前構築か外部サービス利用かを分ける大きな分岐点です。
判断軸3: データの機外持ち出しに対する制約
金融・医療系など、設計判断やコードの文脈を外部のデータベースに置けない制約があるプロジェクトもあります。この場合、ホスティング型サービスは選択肢から外れます。
一方で、埋め込みモデルをOllama（ローカルでLLMを動かすランタイム）で動かし、ネットワーク外に一切データを出さない構成を取れば、自前運用でもこの制約をクリアできます。
判断軸4: 検索精度と鮮度管理の必要度
小規模なプロジェクトで、決定事項が数十件程度なら、意味検索や鮮度管理がなくても実害は少ないかもしれません。逆に、リポジトリが大きくファイルの移動・リネームが頻繁なら、鮮度検知がない仕組みはすぐに形骸化します。
4つの選択肢を比較する
| 方式 | 意味検索 | 鮮度検知 | 運用コスト |
|---|---|---|---|
| CLAUDE.md等のファイル | なし | なし | ほぼゼロ |
| ローカルMCPメモリサーバー | 実装次第で可 | 基本なし | 低い（1人1台前提） |
| 自前Postgres+pgvector | あり | git連携で実装可 | 高い（インフラ全般を保有） |
| ホスティング型サービス | あり | あり（ファイル・コミット連携） | 運用はサービス側が負担 |
1つ目の「ファイルに書く」方式は、CLAUDE.mdや.cursorrules、docs/decisions/フォルダにテキストで残す最も単純な形です。インフラゼロでコードと一緒にバージョン管理でき、誰でも読めます。弱点は、エージェントがコンテキストに収まる範囲しか読まないため意味検索が効かず、鮮度管理も人手任せになる点です。
2つ目の「ローカルMCPメモリサーバー」は、MCP（Model Context Protocol。AIツールが外部システムとやり取りするための標準プロトコル）を使って小さなプロセスを立て、Claude CodeやCursor、Copilotが同じストアを読み書きする方式です。MCPプロジェクトが提供する参照実装は、ナレッジグラフをディスク上のJSONファイルとして保持します。Mem0やGraphitiといったオープンソースプロジェクトも、自前のベクトルストアを使って完全ローカルで動かせます。1人1台の範囲では十分ですが、2台目のマシンやチームメイトとの共有、バックアップは範囲外です。
3つ目の「自前Postgres+pgvector」は、埋め込みモデルをOllamaでローカル実行し、MCPサーバーを前段に置き、gitの変更を監視してファイルに紐づくメモの鮮度を検知する、という本格構成です。複数人・複数マシンで動く「サービス」になりますが、その分の運用コストはすべて自分持ちになります。
4つ目の「ホスティング型サービス」は、MCPサーバーをインストールしてアカウントに接続するだけで、ストレージ・検索・鮮度チェック・チームアクセスの管理を任せられる方式です。トレードオフは明快で、設計判断のデータが自分の管理下にないデータベースに置かれることです。
ケース別の推奨
個人開発でリポジトリが1〜2個なら、ファイルベースのメモ（CLAUDE.md等）で始めるのが妥当です。意味検索や鮮度管理の必要性を感じてから次のステップを検討しても遅くありません。
1人で複数マシン・複数リポジトリを行き来するなら、ローカルMCPメモリサーバーが候補になります。アカウント登録不要で、手元の環境だけで完結します。
チームで共有し、かつデータを外部に出せない制約があるなら、Postgres+pgvector+Ollamaの自前構成一択です。運用工数を見積もったうえで、専任できる担当がいるかを確認してください。
チームで共有したいが、インフラ運用に時間を割けないなら、ホスティング型サービスが現実的な選択肢です。無料枠があるサービスなら、まず試してから判断できます。
あえて見送るべき条件
決定事項の数が少なく、プロジェクトのライフサイクルが短いなら、どの方式も過剰投資になりがちです。ファイルベースのメモで十分なケースにわざわざベクトル検索基盤を用意する必要はありません。
また、社内のコンプライアンス上、AIツールが生成したテキストであってもデータベース外部への保存自体が許可されていない組織では、ホスティング型サービスはもちろん、クラウド上のPostgresを使う自前構成も対象外になります。この場合はオンプレミスでの自前構成か、ファイルベースでの運用に絞られます。
まとめ
エージェントメモリの選定は、チーム規模・運用工数・データ機外持ち出し制約・検索精度の必要度という4つの軸で整理すると判断しやすくなります。
まず着手するなら、CLAUDE.mdやdocs/decisions/フォルダへの記録から始め、意味検索や複数人共有が必要になった段階でMCPメモリサーバーや自前Postgres構成、ホスティング型サービスへの移行を検討する流れが現実的です。
導入前には、利用予定のMCPサーバーがオープンソースかどうか、データの保存先がどこにあるかを公式リポジトリやドキュメントで確認しておくと、後から構成を見直す手間を減らせます。