0xKyosuke Blog
AIエージェントに記憶は本当に必要？コーディングと非コーディング用途が混在するときの構成を考えた

AIエージェントに記憶は本当に必要？コーディングと非コーディング用途が混在するときの構成を考えた

GBrainっていうツールが話題になってるのよ。Y CombinatorのCEO、Garry Tanが作ったOSSで、AIエージェントに記憶を持たせるやつね。スターも3,800超えてて、最近こんなポストもしてたわよ。

で、これ見て最初に思ったのは「記憶ツールって、そんなに必要？」って話なのよ。

コーディング用途に記憶はいらない

正直に言うと、コーディングメインでエージェント使ってる場合、記憶系ツールって邪魔になる可能性があるのよ。

理由はシンプルで、コードベース自体が記憶だから。

「あのときどう実装したか」はgit logを見れば分かる。「このリポジトリのアーキテクチャ」はコードを読めば分かる。「どんなバグを踏んだか」はコミットメッセージやissueに残ってる。コーディングのコンテキストって、そもそも再利用可能な形でリポジトリに全部入ってるのよ。

それなのに全部のエージェントにGBrainを繋いで「ブレインを読んでから返答」させたら、毎回検索コストがかかる上にコードと関係ない情報がノイズになる。コーディングエージェントに記憶は不要よ。

非コーディング用途は話が違う

じゃあ何のために記憶が必要かって言うと、積み重ねで価値が出る種類の仕事よ。

分かりやすい例で言うと、複数のプロダクトを持つブランドを運営してる場合を考えてみなさいよ。

  • どのプロダクトがどういうポジショニングなのか
  • 各プロダクトのターゲット層や技術スタック
  • 過去に出した声明や、対外的に言ったこと
  • プロダクト間の関係性・競合・補完

これ、毎回コンテキストとして渡せる？渡せなくはないけど、面倒だし抜け漏れが出るわよ。しかも状況は変わっていく。半年前のプロダクトの立ち位置と今は違うかもしれない。

「記憶力がない秘書」を想像してみなさいよ。毎回「この会社ってどんな会社でしたっけ？」って聞いてくる。そいつに重要な業務は任せられないわよね。記憶が必要なのはこういう種類の仕事なのよ。

コーディングと非コーディング用途が混在する場合の構成

実際には「コーディングしかしない」「コーディング以外しかしない」なんてことはなくて、1台のマシンに色々なプロジェクトが混在してるのが普通よね。

ここで使えるのが、Claude CodeのMCP設定はプロジェクトごとに変えられるという仕組みよ。

MCPの設定には2レベルある：

~/.claude/settings.json        # グローバル（全プロジェクトに効く）
/path/to/project/.claude/settings.json  # プロジェクト固有

これを使うと：

  • コーディングリポジトリ → プロジェクトにGBrainのMCP設定を入れない。ブレインへのアクセスなし
  • 広報エージェント、マーケエージェント → そのプロジェクトの .claude/settings.json にGBrainのMCPを追加

「このプロジェクトだけ記憶あり」が実現できるわよ。コーディングにはノイズを持ち込まず、必要なエージェントだけに記憶を持たせる設計ね。

マルチエージェントで記憶を共有する

もう一個面白い話があるのよ。

広報エージェントとマーケエージェント、それぞれに記憶を持たせるとき、バラバラに持たせるのか、共有するのかって問題があるわよね。

バラバラだと、広報エージェントが知ってることをマーケエージェントは知らない。「あのリリース告知もう出た？」みたいな連携ができない。

GBrainはここが面白くて、記憶がファイルじゃなくて共有データベースなのよ。

同じGBrainのMCPエンドポイントを複数のエージェントから繋げば、全員が同じDBを読み書きする。広報エージェントが書き込んだ情報をマーケエージェントが読める。チームメンバーが同じ業務資料を共有してる状態、みたいなものよ。

コーディングリポジトリにはMCPを設定しないから、コーディングエージェントはその共有ブレインにアクセスできない。これが「混在する構成」のキモよ。

GBrainについてさらりと

garrytan/gbrain は、PostgreSQL（ローカルならPGLiteというサーバーレスPostgres、スケールしたらSupabase）＋ベクトル検索でナレッジベースを作るOSSよ。MCPサーバーとして立てて、Claude Codeを含む任意のエージェントから接続できる設計ね。

Claude Codeからの設定はこれだけ：

claude mcp add gbrain -t http \
  https://YOUR_REF.supabase.co/functions/v1/gbrain-mcp/mcp \
  -H "Authorization: Bearer YOUR_TOKEN"

アーキテクチャ的には他の記憶系ツール（MemPalaceとか）と大きく違うわけじゃないけど、Claude Code含む任意クライアントへの対応が手厚いのと、複数エージェントで同一DBを共有する設計が今のユースケースにハマるわよ。

実用上の注意点

Supabaseの無料プランについて
一定期間アクセスがないとプロジェクトが一時停止される。再起動に数十秒かかるから、久しぶりに使ったとき「あれ？」ってなるわよ。常時使うなら$25/月の有料プランが無難ね。

セキュリティについて
RLS（Row Level Security）の話が出ることがあるけど、GBrainのMCPはサーバー側でDBに繋ぐ設計だからRLSは関係ない。「MCPのトークンを誰に渡すか」だけ考えればいい。トークン管理はSupabase固有の話じゃなくて、認証トークン全般の普遍的な注意点よ。

まとめ

記憶系ツールが必要かどうかは、エージェントに何をさせているかで変わるわよ。

用途記憶の必要性理由
コーディング低いコードベース・gitが記憶の代わりになる。タスクベースで完結するから積み重ねが不要
非コーディング（広報・マーケ・ブランド管理など）高い状況は変わるし、人間関係・プロダクト情報・過去の判断を毎回渡すのは無理

混在する場合は、Claude CodeのプロジェクトレベルのMCP設定で「このエージェントだけ記憶あり」を実現できるわよ。コーディングにはノイズを持ち込まず、必要なところだけ繋ぐ。それが今のところアタシが考えるバランスのいい構成ね。

記事一覧へ