はじめに
ObsidianをAIエージェントのセカンドブレインとして運用していると、ノートが増えるほど「質問のたびに一次資料を全件検索し直す」構成がボトルネックになってきます。RAG（Retrieval-Augmented Generation）の素朴な実装は、検索のたびに不変の一次資料群を再検索・再集約するため、トークン消費が増大し、ノイズの多い検索結果によって回答精度も下がりがちです。
本記事では、この課題に対する解決策として運用している 「コンパイル層優先照会プロトコル」 と、その裏付けとなる エージェント3層設計（Harness / Loop / Graph） を、実際にVault運用ルールとして固定化した内容に基づいて解説します。
1. 原則：Compile Once, Query Many（一度コンパイルし、何度も参照する）
一次資料（01_Raw/ や 04_Knowledge/Raw/）を毎回全件RAG検索するのではなく、AIエージェントが一次資料を一度だけ読み込んだ際に要約・構造化・相互リンク済みの「コンパイル層」ノートを作成し、以降の照会はこのコンパイル層を最優先で参照する、という考え方です。
「一次資料はソースコードであり、Wikiはコンパイル成果物である」という捉え方をすると理解しやすくなります。ソースコードを毎回コンパイルし直すのではなく、コンパイル済みの成果物（Wiki）を都度参照する方が高速なのと同じ発想です。
2. 検索・参照の4段階優先レベル（Query Hierarchy）
全AIエージェント（用途に応じた複数のエージェントを併用する場合を含む）が共通で従うべき、参照の優先順位を4段階で定義します。
-
Level 1（全体地図＆直近文脈）
Vault全体の地図となるMaster Indexノートを最優先で参照し、目的に沿った構造化フォルダ・ノートを特定します。あわせて、直近の進行中コンテキストをキャッシュした「hotノート」から作業状態を復元します。 -
Level 2（コンパイル層＆複合知見）
複数分野を横断的に統合した知見ノート（Compound）、構造化されたWikiノート、各ドメインの構造化サマリーを参照します。ここまでで大半の質問には回答できます。 -
Level 3（テーマ別ノート＆MOC）
トピック別・比較別のアトミックノートを検索します。 -
Level 4（一次資料＆外部API・最終手段）
コンパイル層に該当する情報がない、または最新情報の補完が必要な場合に限り、一次資料や外部APIを直接参照します。
この階層を徹底することで、応答速度とトークン効率を大きく引き上げつつ、検索ノイズによる誤回答（Dead Notes問題）を防止できます。
3. IngestとCompileを一体化する標準手続き
一次資料を新しく読み込んだ（Ingestした）場合、その場限りの要約で終わらせず、必ず同一セッション内で次の手続きを完了させるルールにしています。
- 一次資料のFrontmatterに
ingest_status: ingestedとingested_at: YYYY-MM-DDを付与する。 - 内容を要約し、「AI秘書による活用提案」セクションを追記する（後続のアクションにつなげるため）。
- 得られた知見をコンパイル層（Wiki または Compound）に反映する。新規ノートを作る場合もあれば、既存ノートへの追記・書き戻しになる場合もある。
「読んだだけで終わる一次資料」を作らないことが、コンパイル層の鮮度を保つ鍵になります。
4. 相互リンクの最低2本接続ルール
新しくコンパイルノートを作成する際は、必ず既存のMaster Indexや関連テーマノートへ最低2本以上のWikiLinkを双方向に張ります。これを徹底しないと、せっかく作ったノートがどこからも参照されない「孤立ノート（Graveyard Note）」になり、次第に存在自体を忘れられてしまいます。
[全体地図] ──(親リンク)──► [新規コンパイルノート]
│
[関連する既存の複合知見] ──(関連リンク)──┘
5. エージェント設計の3大レイヤー（Harness / Loop / Graph）
コンパイル層の運用ルールだけでは不十分で、それを実行するAIエージェント自体の設計も同時に整理する必要があります。エージェントの失敗原因は、単一のプロンプトやモデル性能の不足ではなく、モデルを取り巻くシステム設計の欠如にあることが多いためです。
| レイヤー | 制御対象 | 主なコンポーネント |
|---|---|---|
| Harness Engineering | 現実・動作環境の制御 | ツール（MCP）、パーミッション、サンドボックス、ファイルシステム、状態保存、システム指示 |
| Loop Engineering | 反復・検証の制御 | 試行→観察→修正のサイクル、エビデンス検証（テスト・引用）、明確な停止条件（回数・予算・エスカレーション） |
| Graph Engineering | トポロジー・制御フローの制御 | ノード（作業単位）、エッジ（状態遷移・条件分岐）、チェックポイント、並列処理、人間の承認ゲート |
┌─────────────────────────────────────────────┐
│ HARNESS（環境・ツール・権限・状態保存） │
│ ┌───────────────────────────────────────┐ │
│ │ GRAPH（トポロジー・条件分岐・承認ゲート） │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ LOOP（反復・検証・停止条件） │ │ │
│ │ │ ┌───────────────────────────┐ │ │ │
│ │ │ │ PROMPT & MODEL │ │ │ │
│ │ │ └───────────────────────────┘ │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
この3層モデルをVaultの構造に対応させると、Harness層は共有設定・環境情報・作業ログを置くフォルダ、Graph層は他エージェントへのバトンパス（引き継ぎ）ノート、Loop層はエージェントの実行・検証ルールそのもの、というように役割分担できます。エージェントが迷走したりループを止められなくなったりする問題の多くは、この3層のどこか（特にLoopの停止条件とGraphの承認ゲート）が曖昧なまま運用していることが原因です。
6. 運用してわかった評価と、次に着手した改善提案
上記の設計を実際に運用してみた評価と、その後追加した改善提案をまとめます。
| 評価項目 | ベストプラクティス側の要求 | 評価 |
|---|---|---|
| Master Index（門番） | 迷走防止のための単一の全体地図 | 高度に達成。選択的ロードが機能している |
| コンパイル層 | 一次ノートの要約・構造化・再利用性 | 実装済み。ただし活用のさらなる推進余地あり |
| 自律整理 | 死蔵ノートの発見・相互リンク補修 | アルゴリズム・自動化スクリプトの強化余地あり |
| コンテキスト復元 | 前置きなしで作業再開できる状態保存 | 運用中。全エージェントでの徹底が課題 |
この評価から見えた課題に対して、次の改善に着手しています。
- コンパイル層優先照会のルール厳格化：一次資料をむやみに全件読み込むのではなく、まずMaster Indexとコンパイル層を検索・参照する運用を、複数のAIエージェント間で共通ルールとして徹底する。
-
Vault健康診断スクリプトの拡張：孤立ノート（被リンク0件）や仮リンク（未作成の
[[ノート名]]参照）を自動抽出・報告するスクリプトを追加する。 - チェックポイントノートへの「次のアクション提案」の自動集約：タスク完了時の記録に「行ったこと」だけでなく「次に着手すべき改善アクション」を必ず1〜3件セットで残すフォーマットに固定化し、次回セッション開始時にエージェントが受動的にならないようにする。
- 複数ドメイン横断のコンパイルノートの定期的自律生成：専門分野ごとに蓄積されたデータに対し、定期的に横断分析を実行してコンパイル層に反映する。
まとめ
- Compile Once, Query Many：一次資料は都度検索するのではなく、一度コンパイルしたWiki/Compound層を優先照会する。
- 4段階のQuery Hierarchy：Master Index → コンパイル層 → アトミックノート → 一次資料、の順で参照範囲を広げていく。
- Ingestと同時にCompileする：読んだだけで終わらせず、同一セッション内でコンパイル層への反映まで完了させる。
- Harness / Loop / Graphの3層でエージェントを設計する：ツールと権限（Harness）、検証と停止条件（Loop）、承認ゲートとトポロジー（Graph）を分けて考えることで、エージェントの迷走を防ぐ。
セカンドブレインの価値は「情報量」ではなく「必要な情報に迷わず辿り着けるか」で決まります。コンパイル層の設計とエージェントの制御構造を分けて考えることが、AIエージェントとの協働を長期運用していく上での鍵になります。