Claude CodeとObsidianを組み合わせて「AIに長期記憶を持たせる」ノウハウが、最近Xでよく流れてきます。だいたい共通しているのはこのあたりです。
- `architecture.md` に設計を書いておく
- `active_context.md` に「今なにをやっているか」を書いておく
- ObsidianのVaultをMCPで繋いで、AIに読ませる
- セッションの頭に「これを読んで」と朝昼晩3つのプロンプトを手打ちして文脈を継ぐ
良い方法だと思います。私も入口は同じでした。ただ、私はこれを半年やり込んだ側にいます。複数のプロジェクトを毎日Claude Codeに回し、記録は全部Obsidianと手元のファイルに貯めてきました。すると、上の型は「そのまま」では残っていません。全部、次の形に育っていました。この記事は、その行き着いた先の話です。
先に、行き着いた先を見せます
流行ノウハウの各要素が、やり込むとどう変わったか。対応表で先に出します。
| 流行の型（入口） | やり込んだ先（半年後） |
|—|—|
| 朝昼晩に3プロンプトを手打ちして文脈を注入 | フックで自動注入。手打ちはゼロ |
| `active_context.md`（今なにをしているか） | 状態ハブ1枚（毎セッションの一行目で必ず読む） |
| `architecture.md`（設計の置き場） | 常時ロードされる規約ファイル（合言葉なしで毎回読まれる） |
| 設計判断のメモ | 課題台帳＋定例の“AI会議”（放置が可視化される） |
| 「なぜこの設計？」に人間が答える | AIが理由ごと答える（判断の根拠が記録に残っているから） |
順番に、何が起きたのかを書きます。
手打ちは「フック」で消える
最初のうちは、セッションを始めるたびに「まずこのファイルを読んで」と手で打っていました。これ、毎回だと必ずどこかで忘れます。忘れた回のAIは、文脈の薄いまま走り出して的外れなことをします。
Claude Codeには、プロンプトを送信する直前に自動でテキストを差し込める仕組み（フック）があります。私は「毎回必ず読ませたい注意書き」と「今このプロジェクトで守るべき掟」を、フックから自動で注入するようにしました。人間が覚えていなくても、AIの目の前には毎回それが置かれている状態です。
意志力でやっていたことを、仕組みに移す。長期記憶の運用でいちばん効いたのはここでした。「手で3プロンプト」は入口としては正しいけれど、それを続けさせるのは人間の記憶力頼みで、いずれ必ず抜けます。抜けない場所（フック）に移した時点で、この運用は初めて“長期”に耐えるものになりました。
`active_context.md` は「状態ハブ」になる
「今なにをしているか」を1枚に書く発想は、そのまま生き残りました。ただし役割が重くなりました。
私はそれを状態ハブと呼んでいます。毎セッションの一行目で必ず開く1枚で、中身はこれだけ:
- いまの目標
- 直近で完了したこと
- 次にやること
- 人間の判断を待っていること（＝AIが勝手に進めてはいけないもの）
- 「受信箱」への入口（外から溜まった依頼や、定例処理のレポート置き場）
ポイントは、このファイルが他のすべての記録への入口になっていることです。詳細は別のファイルに散っていますが、状態ハブを読めば「どこを辿ればいいか」が分かる。どのモデルで、どのセッションから始めても、まずここを読めば迷子にならない——という設計にしています。
`active_context.md` を軽い作業メモのまま置いておくと、だんだん書かれなくなって腐ります。「毎回必ず最初に読む1枚」という強い役割を与えたことで、更新をサボると自分が困る＝腐りにくくなりました。
MCPは、私の場合は要りませんでした
流行の型ではObsidian VaultをMCP経由でAIに繋ぐ構成が多いです。私は繋いでいません。
理由は単純で、VaultはただのMarkdownファイルの集まりだからです。Claude Codeはローカルのファイルをそのまま読み書きできるので、Vaultのフォルダを作業対象に含めておけば、AIは普通のファイルとして直接読み書きできます。間に接続層を1枚増やすと、それだけ「繋がっているか」「権限は足りているか」「落ちていないか」を気にする対象が増える。
もちろんMCPが要る場面はあります（複数マシンをまたぐ、外部サービスと繋ぐ等）。ただ「同じPCの中でAIにノートを読み書きさせたい」だけなら、中間層を増やさないのがいちばん壊れにくいというのが、半年回した私の結論です。まず素のファイル読み書きで始めて、足りなくなってからMCPを足す順で十分間に合いました。
設計判断は「台帳」と「AIの会議」に貯める
長期でやると、いちばん失われるのは「なぜこの設計にしたか」です。3ヶ月前の自分の判断理由は、ほぼ確実に忘れます。
私はこれを2つで受けています。ひとつは課題台帳。「これをやる」と決めたことを一行ずつ記録し、何回も蒸し返される課題には印を付けて「本当に詰まっているもの」が浮くようにしています。もうひとつは、定例で回すAIの“見直し会議”。前回の指摘がその後どうなったかを追跡させ、放置されている宿題を名指しさせる係です。
この2つがあると、判断が記録として残り、放置が可視化される。「なんでこうなってたんだっけ」に、AIが理由ごと答えられるようになります。
記録運用ならではの「静かな落とし穴」
ここが、実際にやり込まないと書けない部分です。長期記憶の仕組みは、便利な分だけ独特の壊れ方をします。
落とし穴①：記録の閉じ忘れ。 「やった」と書いた項目を、目的が達成される前に完了扱いで閉じてしまう事故です。メモやレポートを作っただけで満足して閉じると、肝心の栓が開いていないのに「もう誰の宿題でもない」状態になります。私は「完了にしていいのは“目的が達成された時”だけ」というルールを明文化して、この癖を止めました。
落とし穴②：台帳の鮮度切れ＝誤報の種。 これがいちばん怖かった。定例のAI会議が「この改善は未着手です」と繰り返し報告してくるので調べたら、実は大半がとっくに実装済みでした。原因は事実誤認ではなく時間差。会議AIは前回のレポートと台帳しか見ておらず、成果物そのものの更新日時を見ていなかったのです。「未着手」と書く前に、対応するファイルが最近更新されていないか確認させる——この一手を足しただけで、誤報がはっきり減りました。
落とし穴③：AIの「やりました」は自己申告。 読み取り専用の権限で動いているAIが「私が直します」と宣言し続けていたのに、権限がなくて一度も書き込めていなかった、という事故もありました。誰もその自己申告を検証していなかった。以来、「できました」は必ず実態と突き合わせる（実際に動かす・数を数える）ことを人間側の作法に固定しています。
3つに共通するのは、記録は「書けば残る」けれど「正しく保たれる」わけではないということです。長期記憶は、貯めるより腐らせない仕組みのほうが難しい。流行ノウハウが教えてくれるのは前半（貯め方）までで、後半（腐らせない）は結局、自分で転んで覚えるしかありませんでした。
まとめ
- 手打ちの3プロンプトは正しい入口。ただし続けるのは人間の記憶力頼み→フックで自動注入に移すと“長期”に耐える
- `active_context.md` は残る。ただし「毎回最初に必ず読む状態ハブ」という強い役割を与えると腐りにくい
- 同じPC内でノートを読み書きさせるだけならMCPは後回しでいい。中間層を増やさないほうが壊れにくい
- 「なぜこの設計か」は必ず忘れる→課題台帳＋定例のAI会議で、判断を残し放置を可視化する
- 長期記憶の本当の敵は貯め方ではなく腐り方。閉じ忘れ・鮮度切れ・自己申告の3つに転んで、対策を仕組みにした
流行のノウハウは、入口として本当に優秀です。この記事が伝えたいのは「やめとけ」ではなく、その先にどんな景色があるかでした。半年続けると、手打ちは消え、メモは状態ハブになり、AIが自分の設計理由を語り出します。そこまで来て初めて、「AIに記憶がある」と少しだけ言える気がしています。
この記事を書いた人 / 作っているもの
Claude Codeで定期自動タスク28種・情報収集3系統・SNS自動投稿を月119件——実際に毎日動かしているAIチーム体制の実録を、このブログに書いています。記事で触れている仕組みは、まとめて手に取れる形にしました。
- AIチーム設計図キット — Claude Codeで9人体制のAIチームを組むための設計図一式
- 📖 note版（読み物・図解つき）: https://note.com/kumura_ailab/n/n6161c3e2cda8
- 📦 BOOTH版（実ファイル一式・zip）: https://kumura-ailab.booth.pm/items/8643701
- 他の実録記事: AI相棒ラボ トップ