【AI Agentに 『第二の脳』を持たせるSkill】｜Obsidian挫折から、リポ単位の外部メモリー構築へ

こんにちは、この記事に訪問頂きありがとう御座います。

早速ですが、

皆さん、ClaudecodeやCodexなどのAI Agentは
ご利用していますでしょうか？

日々、進化の速いAI Agentとの開発は楽しいですね――。

でも、開発を続けるほど「AIが忘れる」
この問題に度々ぶつかりませんか？

この記事は、

Claude CodeやCodexで複数セッションの開発を続け、

前回の決定や注意点を何度も説明している方へ。

リポジトリ単位（開発案件単位）で、

【AI Agentが使える外部メモリーSkill】を提供します。

モデルは、1回の作業を強くする。

外部メモリーは、作業をつなげる。

では、Agentが戻ってこられる記憶を、
どうすれば簡単に持たせられるのか。

私の出発点は、Obsidianで第二の脳を作ろうとして、
うまく続けられなかったことでした。

このnoteでは、メモ習慣のない私が、
リポジトリ単位でAI Agentが使える

外部メモリーSkillを作った経緯と、
使い始めるための考え方をまとめます。

AI Agentとの開発で、最初に感じた違和感

AI Agentとの開発は、本当に快適でした。

仕様を相談しながらコードを書き、修正案を出してもらい、
エラーを一緒に見て、次の設計を考える。

まさに、優秀な開発パートナーが隣にいるようでした。

でも、開発を続けるほど、
だんだん大きな違和感が出てきました。

『AIが忘れる。』

しかも忘れるのは、私が伝えた内容だけではありません。

• AI自身が決めた設計方針。

• 一度合意したルール。

• 前回直したはずの注意点。

• なぜその実装にしたのかという判断の理由。

セッションを重ねるうちに、それらが少しずつ抜け落ちていく。

そのたびに、また説明する。

「前にこう決めたよね」
「その方針は違う」
「このファイルは触らない約束だった」

こういうやり取りが増えていくと、開発スピードよりも先に、
こちらの気持ちが疲れていきます。

AIは賢い。

でも、毎回忘れたところから始まる。

この状態のままAgent Teamや複数セッションで開発を進めるのは、
かなり危ういと感じました。

外部メモリーが必要だと思った

そこで、外部メモリーが必要だと考えました。

AI AgentやAgent Teamで本格的に開発するなら、
会話の中だけに記憶を置いてはいけない。

• プロジェクトの状態

• 決定事項

• 設計方針

• 次にやること

• 失敗したこと

そういう情報を、AIがセッションをまたいでも
読める場所に置く必要がある。

最初に思いついたのは、

『Obsidian』や『NotebookLM』のようなツールでした。

特に、Obsidian・NotebookLMはUIから素晴らしいツールです。

ノート或いはブックが自分の手元にあり、
リンクできて、Graphでつながりも見える。

Second Brainという言葉とも相性がいい。

ただ、私には大きな問題がありました。

メモを書き、整理し、タグを付け、リンクを張り、知識を育てる。

それが好きな人には、Obsidianはとても強い道具だと思います。
もちろん、NotebookLMも。

でも、私が欲しかったのは
「自分が美しく整理するノート」ではありませんでした。

欲しかったのは、AI Agentが開発中に迷わず使える記憶です。

ここが、少し違ったのだと思います。

GitHubを探しても、非エンジニアには判断が難しかった

もっと簡単な方法はないのか？　メモ習慣のない私は、

そう思って、GitHubでAI Agent向けの外部メモリーをかなり調べました。

勿論、本格的なものはたくさんあります。

RAG、Vector DB、MCP、長期記憶、knowledge graph。
どれも強そうに見える。

でも、非エンジニア寄りの私には、途中でこうなりました。

「これ、本当に自分の開発レベルに必要なの？」

• まず仕様が解らない。

• 設定が難しい。

• 導入までが長い。

• 何をどこに保存すればいいのか分からない。

外部メモリーを使えるようにする前に、
外部メモリーの設計で止まってしまう。

これは本末転倒でした。

私が欲しかったのは、
すごい記憶システムを構築することではありません。

案件の開発を始める前に、
AI Agentへ最低限の記憶の置き場を渡すことでした。

だから、Skillとして作った

そこで考え方を変えました。

外部メモリーを構築する小難しい巨大なツールではなく、

AI Agentがすぐ使える外部メモリーを作るSkill

を作ればいい。

Skillを実行すると、

開発中のリポジトリに agent-memory/ という
外部メモリー用のフォルダを作る。

AI Agentは、そこに現在状態や次の作業、
決定事項、資料、改善候補を書き込む。

次のセッションでは、まずそこを読む。

人間が毎回すべて説明し直すのではなく、
Agentが自分で文脈復帰できるようにする。

「第二の脳」を作り込むことより、

AIが自由に使える「外部メモリー」の設置が重用で、

目指したのは、「構築すること」ではなく
今日から、「すぐ使えること」でした。

AIは今でも忘れる。でも怖くなくなった

もちろん、このSkillを使っても、
「AIが忘れる」現象はゼロにはなりません。

AIにはコンテキスト量の制限があります。

長い開発、複数セッション、複数Agentになれば、
忘れること自体は避けられません。

でも、ひとつ大きく変わったことがあります。

セッションを切り替えることが怖くなくなりました。

以前は、新しいセッションを始めるたびに、

「また全部説明し直しか」

と思っていました。

今は違います。

「新しいセッションで始めよう」

と自然に思えるようになりました。

AIが忘れることよりも、忘れたときに戻れる場所がないことが
ストレスだったのだと思います。

外部メモリーがあると、忘れても戻れる。

これは開発効率以上に大きな変化でした。

Obsidianの前に、Agentが読める記憶を作る

ここで誤解してほしくないのですが、
Obsidianを否定したいわけではありません。

むしろ、Obsidianは育った知識を見える形にするにはとても強い道具です。

このskillも、Obsidianの構想に合わせて作っています。

ただ、最初から完璧な第二の脳を作ろうとすると、
時間もかかるし　止まりやすい。

• フォルダ構造はどうするか。

• タグはどうするか。

• MOCをどう作るか。

• Graphをどう育てるか。

こうした設計は楽しい一方で、開発に入る前の負荷にもなります。

特に、メモ習慣がない人や、

非エンジニアだけどAI Agentで開発したい人にとっては、
ここで挫折しやすい。

だから私は、順番を変えた方がいいと思っています。

最初から、人間向けの大きな第二の脳を作らない。

まず、開発リポジトリの中に、
Agentが読める小さな外部メモリーを置く。

開発しながら必要な知識が溜まります。

それを、あとからObsidianへ接続すればいい。

そもそも、作ろうとしていた、

Obsidianの「第二の脳」だって

何のために構築しているのでしょうか？？

まさに、ここが求めている「第二の脳」の手がかりでしょう。

このSkillが最初に作るもの

このSkillでは、最初に小さな 「agent-memory/」 を作ります。

初期構成はシンプルです。

agent-memory/
  00_SESSION/CURRENT_STATE.md
  00_SESSION/NEXT_ACTIONS.md
  00_INDEX/MEMORY_MAP.md
  00_INDEX/LOOP_LIGHTWEIGHT_RULES.md
  01_DECISIONS/DECISION_LOG.md
  09_IDEAS/IDEA_INBOX.md
  14_SESSION_COORDINATION/MERGE_QUEUE.md
  17_SOURCE_MATERIALS/SOURCE_INDEX.md

大事なのは、ファイル数そのものではありません。

情報の置き方を分けることです。

• 現在状態は  CURRENT_STATE.md。

• 次にやることは  NEXT_ACTIONS.md。

• 記憶の地図は  MEMORY_MAP.md。

• 承認済みの決定は  DECISION_LOG.md。

• まだ確定していない改善候補は  MERGE_QUEUE.md。

• 資料は  SOURCE_INDEX.md に登録する。

これだけで、AI Agentがかなり迷いにくくなります。

特に重要なのは、

Source Materialsを「証拠」として扱うことです。

ユーザーが渡した資料やメモを、いきなり正本にしない。

Agentが作った要約も、いきなり決定事項にしない。

正本に入れる前に、いったん候補として止める。

この止める場所があるだけで、AIが勝手に決めたことが

プロジェクトの前提になる事故を減らせます。

実際に、このnote執筆でも使っている

私は今回、AI Agentとnote記事を書くための、
Agentチームを作っています。


そのチームにも agent-memory/ を置きました。

この記事が、実は1っ発目の執筆・・・。

外部メモリーに入れた情報として、

noteアカウントのコンセプト資料や、
上位事業のブランディングを行った資料があります。

これらは大事な資料です。

でも、記事制作の正本としてそのまま固定してしまうと、

逆に成長を止める可能性があります。

そこで、これらはSource Materialsとして登録し、

「方向性の参照」として扱いました。

さらに、この記事テーマ・主題に関しての「思考のメモ」も、

Source Materialとして登録しています。

つまり、この本文は「AIがなんとなく作った記事」ではありません。

• ユーザーの生の体験メモ。

• 周辺ツールの調査。

• Skillの実際の構成。

• noteで重視される一次情報・体験・気づき。

それらを分けて扱い、記事にしています。

これは、AIを使っていても、
人間の一次性を失わないための運用でもあります。

リポジトリ単位だから、ノイズが混ざりにくい

第二の脳を作ろうとすると、つい全部をひとつに集めたくなります。

でも、すべての知識をひとつに集め過ぎると、ノイズが入ります。

• 案件Aの判断。

• 案件Bの失敗。

• 案件Cの設計方針。

• 個人的なメモ。

• 記事制作のアイデア。

これらが最初から混ざると、AI Agentも人間も迷います。

その案件に必要な情報だけを、Agentが扱える。

この粒度が、思っていた以上に使いやすいです。

そして、ここには次の可能性もあります。

案件ごとに同じ型のMemoryが育っていけば、
あとから統合できる。

全文を雑に混ぜるのではなく、

案件ごとの決定、資料、失敗、改善ログを分けたまま束ねる。

そうすれば、AI Agentが横断的に引き出せる、

開発者のためのSecond Brainに近づけるはずです。

この統合Memoryについては、
別の記事で扱う予定です。

まずこの記事では、

1つの開発案件に外部メモリーを持たせるところまでを扱います。

この記事でいちばん伝えたいこと

AI Agentに必要なのは、AIを完璧にすることではありません。

人間が安心してAIに仕事を任せられる環境を作ることです。

AIは忘れます。
でも、忘れても戻れる場所があればいい。

AIは間違えます。
でも、決定と資料と仮説を分けておけば、
間違いに気づきやすくなる。

AIは勝手に進みすぎることがあります。
でも、正本に入れる前に MERGE_QUEUE.md で止めれば、
人間が確認できます。

外部メモリーは、
AIのためだけのものではありません。

開発者のストレスを減らすためのものです。

「また全部説明し直しか」と思わなくていい。

「新しいセッションで始めよう」と思える。

その安心感のために、私はこのSkillを作りました。

ここまで、読んで頂きありがとう御座いました。

このskillは、note記事特典として配布しております。