AIエージェント（Claude Code）にObsidian Vaultを使った「第二の脳」を持たせて運用を始めてから、約1週間が経ちました。指示書の肥大化や棚卸し忘れなど、いくつかのつまずきを乗り越えてきましたが、今回見つかったのは、セッション開始時に約26万字・3,662行を読み込む状態になっていたことです。原因は、索引だけを確認するはずの処理が、個別の記憶ファイルまで毎回全文展開していたことでした。本記事では、原因の特定方法と、再発しにくい形への直し方を実例で紹介します。
「太っているのは指示書だろう」という思い込みが外れた
「グローバルの設定が太りすぎていないか確認してほしい」という依頼を受けて調査を始めた際、最初に疑ったのは日々増え続けているプロジェクトの指示書やスキル一覧でした。運用期間が長くなるほど、こうしたファイルは自然と増えていくためです。
しかし実際にセッション開始時の注入内容を実測してみると、そこが本命ではありませんでした。
実測して初めて分かったこと
本命だったのは、セッション開始のたびに走る「記憶をロードする起動スクリプト」（SessionStart hook）でした。
もともとの設計は、索引ファイルだけを読み、必要な記憶は個別に開いて参照する、というシンプルなものだったはずです。ところが実装を確認すると、記憶ファイル82本を毎回すべて全文展開してしまっていました。
実測した数字と、直した後の構造
実測結果は次のとおりです。
- 修正前：注入量 263,333字／3,662行
- 修正後：注入量 104,934字／903行（約60%減）
さらに重要なのは、単に一度削減できたという話ではなく、修正前は「記憶ファイルが1本増えるたびに、次のセッションの読み込み量も線形に増えていく」という構造だった点です。この修正により、記憶ファイルが増えても、その全文が毎回の注入に自動的に追加される構造ではなくなりました。
なぜこの構造が問題だったか
記憶を貯める仕組み自体は正しく機能していても、それを読み込む側が「増えるほど重くなる」構造のままだと、運用を続けるほどコストが際限なく膨らんでいきます。今回のケースは、貯める仕組みを直したはずなのに、読む仕組みの方に同じ問題が残っていた、という点が見落としやすいポイントでした。
今回の対処から得られた教訓
1つ目は、「どこが太っているか」を印象や思い込みで決めないことです。今回も「たぶん指示書だろう」という予想は外れていました。実際に文字数・行数を測って初めて、本当のボトルネックが見えてきました。
2つ目は、その場しのぎの対処で終わらせないことです。単純に記憶ファイルの数を減らすといった対症療法ではなく、「今後も同じ理由で太らない構造」にまで直して、ようやく再発しない対策になります。
よくある質問（FAQ）
Q. 記憶ファイルが増えること自体が問題なのでしょうか？
A. いいえ、記憶が増えること自体は「第二の脳」として正しい成長です。問題なのは、その記憶を読み込む仕組みが、増えた分だけ線形にコストが増える構造になっていたことです。
Q. どうやって「太っている場所」を特定すればよいですか？
A. 印象で犯人を決めず、実際にセッション開始時の注入内容を文字数・行数で実測することが有効です。今回も最有力候補だった指示書ではなく、別の場所が本命でした。
まとめ
AIエージェントに「第二の脳」を持たせる運用では、記憶を「貯める仕組み」だけでなく「読む仕組み」も肥大化しうるという実例を紹介しました。太っている場所は思い込みではなく実測で特定し、対処は一時的な削減ではなく「記憶ファイルが増えても、その全文が自動的に読み込みへ追加される構造ではなくす」ところまで直すことが、長く運用を続けるうえで重要だと感じています。
