『外部脳🧠』を受動的から能動的な記憶装置に作り変えた話

要約

• 『外部脳』をAIが「自分から記憶を取りに行く」仕組みに大改革。受動から能動へ、記憶復元装置への大転換。
• 「お願い形式では動かない、仕様形式で書く」、AIへの指示文そのものの書き方も見直した。
• プロンプトは短く、わかりやすく、シンプルに。これ、プログラミングの基本。

今まで、ClaudeCodeとNotionで『外部脳』を構築した話を書いてきました。
https://zenn.dev/kajungbang/articles/5c00f3bf7d7416
https://zenn.dev/kajungbang/articles/fb31e447bcf14d
第3弾「公式機能と比較した話」](https://zenn.dev/kajungbang/articles/337e3219aece8a)
第4弾「Notionで外部脳を続けるぞ！という話」](https://zenn.dev/kajungbang/articles/89e3f06f76c23d)

今回は、『外部脳』を”受動型”から”能動型”へ、そもそものマインドセットを再構築し直した話です。

【きっかけ】 知識は増えているはずなのに、反応が悪い・・・

『外部脳』を活用し始めて約一ヶ月。ほぼ毎日の様に「これ、Notionに保存して」とClaudeAppにお願いしていたので、Notionに構築した『外部脳』に蓄積する情報は増えていきました。
しかし、それなのに・・・何か違和感がありました。
「ClaudeCodeやClaudeAPPは外部脳を活用（つまりOUTPUT）しているのかな？」と。

• 「あれ？これに関する論文あったよね？なぜ、そのことを言及しないんだろう？」
• 「あれ？これ前に終わった作業なのに、なぜ残作業として提示されるんだろう？」
• 「あれ？あれ？あれ？」

『外部脳』運用開始して約一ヶ月、「着実に動いているのか？活用されているのか？仕組みやプロセスに問題はないのか？」ーつまり”システム”を見直す良い時期でした。

【前提】　旧設計の構造と発見した弱点

『外部脳』の旧設計は、4層のアーキテクチャと4つのサイクルでした。

4つのレイヤー

• Raw : 原典・AIは勝手に書き換えない（静的記憶領域）
• Wiki : AI生成のサマリー・概念記事や統合知の保管先（静的記憶領域）
• Schema : AIの読み書きルールを定義（静的記憶領域）
• SessionLOG : AIの作業状況を記録（動的記憶領域）

4つのサイクル

• INGEST：新しい情報を取り込む
• COMPILE：取り込んだ情報をWiki化する
• QUERY：必要な情報を探して回答に使う
• LINT：KBの健全性をチェックする

一見まともです。しかし、決定的な弱点が4つ”も”ありました。

弱点1：QUERYが「受動的」だった

ClaudeCode（もしくはClaudeAPP）さんが動くのは「ユーザーが”質問”したとき」だけ。
たとえば、資料保存が途中で止まっていた時、「前回の続きをやって」と言えば作業は再開され『外部脳』対して検索クエリは処理されるので、重複保存は防げます。
しかし、それだけです。
それまでに実行したさまざまな”やりとり”、現在の『外部脳』に何が保存されていて、何が知見となっているのか？など、縦横無尽な「文脈としての記憶」を自動的に復元する仕組みにはなっていませんでした。
また”質問”の意味（定義）が不明瞭で、結局のところ、約一ヶ月”依頼”は走ったが”質問”は存在しなかった状態でした。

弱点2：INGESTとCOMPILEが重複していた

「INGEST」と「COMPILE」に、似たような作業が含まれており、どちらで何をやるのか、棲み分けが曖昧でした。「INGESTで取り込んで、COMPILEでWiki化」と言いつつ、実際には2つのサイクルが半分くらい重なっていたために、運用のたびに「どっちでやるんだっけ？」という”三遊間”が発生していました。
人間でしたら「前回INGESTがやってくれたから、今回はCOMPILEでやるよ」的な調整が現場で走りますが、AIではそうはいきません。

弱点3：LINTのトリガーが「気が向いたとき」だった

大事な”健全性チェック”。定期的に実行と決めていましたが”定期”の定義が決まっていませんでした。。つまり「なんとなく定期的に」のまま、これは実質的に機能していないに等しい状態です。

弱点4：使用用語がよくわからなかった

旧設計では、ソースが1件だけの概念を「スタブ」としてWikiDBに仮登録していました。実は私はこの「スタブ」という言葉を使ったことがなく「なんじゃらほい？？」と思いつつ、「まあ悪さをしている気配もないから」と放ったらかしにしていました。が、これが良くなかった、Wiki DBの内部構造が適正か否かを確認仕切れていなかったのです。つまり、自分の『外部脳』なのにその中身をちゃんと理解していなかった、というわけです。

用語うんぬんの瑣末なことも積み重なり 『外部脳』はあれど、それはあるだけ 状態に陥っていました。

【大改革】　新設計 ＜5レイヤーと3サイクル＞

まずは、改めて方針＝思想を定めました。
『外部脳』は使ってなんぼ、ClaudeCodeもClaudeAPPも、言われて使うのではなく、自ら自律的に使うべし

「受動から能動」へ：根本思想の転換

旧思想： 『外部脳』は情報を蓄積する場所。ClaudeCodeはユーザーに聞かれたら参照する。
新思想： 『外部脳』はClaudeCodeの記憶そのもの。セッション開始時に自動的に記憶を復元する装置。

人間に例えるなら、「聞かれたら思い出す人」から、「聞かれなくてもいろいろ思い出しちゃう人」への変身です。
思考が色々なところにすっ飛んでいってもいい、とにかく幅の広い思考力の実現を目指しました。

4サイクル → 3サイクルに再編成

”COMPILE”を廃止して”INGEST”に機能を統合、以下の新3サイクルに整理しました。

• 新INGEST：内部を5ステップ化（概念抽出と自動昇格を内包）
• 新QUERY：能動的記憶復元化（セッション開始時に自動発動）
• 新LINT：トリガー明確化（情報集約DBが10件増えたら自動発動）

今回最もテコ入れしたのは新INGESTの内部5ステップ化です。

【新INGEST】
Step 1: 情報集約DBの新規エントリを読む
Step 2: Wiki DBに”ソース要約ページ”を作成する
        ＋ 最重要概念を1つ抽出し”概念メモ”とする
        ＋ 同名の”概念メモ”が存在しない場合は新規作成する

Step 3: 同時にWiki DBの”概念メモ”一覧を検索し、
        既存の”概念メモ”に2件以上の”ソース要約”が紐づいた場合”概念メモ”は”概念記事”に自動昇格させる

Step 4: 昇格し新規作成した”概念記事”と関連ソース要約の間にリンクを追加する

Step 5: マスターインデックスを更新する

「同じ概念が2件以上のソースで言及されたら、自動的に概念記事に昇格させる」というルールにしました。
旧設計では「概念記事を作るかどうか」を毎回手動で判断していたものを、処理に変えたことで運用負荷が一気に下がりました。

この”概念メモ”は旧設計では「スタブ」と呼んでいたものです。
改名し

• 1ソースのみの概念は"概念メモ"（この段階では、まだ1つの文献（ソース）しか支持していない仮説的なもの）とし
• 2ソース以上集まったら"概念記事”に昇格させる（複数の文献が裏付ける確立した概念と判断）

ことにより、自分の言葉で語れる『外部脳』となりました。
まあ、ここの概念化に関しては、２件が妥当なのか３件が妥当なのか？は論点ですが、現時点では「２件以上ルール」です。

4レイヤー　→ 5レイヤー

旧レイヤーに「実装ログ（アーカイブ）」を追加しました。
セッションログが長くなると、コンテキスト（トークン）消費が大きくなりすぎるので、直近１０セッション以外はアーカイブ化しました。

• Raw : 原典・AIは勝手に書き換えない（静的記憶領域）
• Wiki : AI生成のサマリー・概念記事や統合知の保管先（静的記憶領域）
• Schema : AIの読み書きルールを定義（静的記憶領域）
• SessionLOG : AIの作業状況を記録（動的記憶領域）
• SessionLOG(Archive) :　トークン消費を節約するために作業完了したLOGは別保存、問題が発生した場合のルートコーズ分析用に削除ではなく保存する

AI内部の命令方法の改善　：「お願い」　→ 「仕様形式」

動的記憶を担う”セッションログ”には、「次回のセッション開始時に何をするのか？」がわかるように引き継ぎメッセージを毎回最後に書いています。
ここを「お願い形式」から「仕様書形式（命令）」に変えました。

旧）「次回セッション開始時は、KBスキーマ定義をfetchしてから開始してください」
新）修正後の指示文（一部抜粋）

🚨【読後即時アクション — 返答前に必ず順番に実行すること】

このページを読んだ直後に、以下を順番に**実行すること**。
実行前に返答を開始することを**禁止する**：

Step 1: KBスキーマ定義を fetch する
Step 2: マスターインデックスを fetch する
Step 3: 上記2件の内容を踏まえて回答する

※ セッションログだけを読んで回答することを**禁止する**。

「〜してください」という「お願い形式」では、ClaudeAPPさんは「参考にする」ものの「即座に実行する」べきとは受け取らないことが、テストシミュレーション実施で発覚しました。まあ、ここでもClaudeさんのサボり癖が出たわけです。

「お願い形式」から「仕様書形式（命令・禁止形式）」へ。
「〜してください」を「〜すること、〜することを禁止する」に書き換え。たったこれだけでしたが効果は絶大でした。

【まとめ】 プロンプトエンジニアリング的学び

今回の大改革は「仕組みと運用」の両面を見直しましたが、一番の学びは指示文の書き方そのものです。

• スキーマ定義（CLAUDE.mdに相当）に「セッション開始時にKBスキーマを読むこと」と書いていた
• セッションログにも「必ずスキーマ定義をfetchしてから開始してください」と書いていた

当方は二重に仕込みを入れている！これで大丈夫と思っていたのですが、実は期待通りには動いていませんでした。
書いてあることと、実際に行動として実行されることは別物。
ClaudeAPPさんは指示文を読んで「参考情報として（一部を）取り込む」ことはしても「即座にツールを呼び出し完遂する」までは行きつかなかった、それはお願いされたことなので「これぐらいでいいか」とAI自身の行動の適正化をAI自身の判断に委ねてしまうことになるからだと、私は理解しました。

全部読んで欲しい、完遂して欲しい、ここは絶対外してほしくない、などのMUST要件については
「人間からの命令、もしくは反転命令（禁止事項）」でなくてはならない、特に、システムなどの自動化スキームでは、特にこの視点が運用の肝となります。

AIからAIへの指示文で「お願い」は無用、「仕様書」として書く。
ClaudeCodeさんやClaudeAPPさんがあまりにも人間チックなので、こちらが使う言葉も丁寧になり過ぎていました。
そうです、すっかり忘れていましたが、相手はAI.機械です。

過剰な思い入れや忖度は不要。プロンプトは短く、わかりやすく、シンプルに。
プログラミングの基本です。
初心を忘れておりました。反省しきりです。