# 第 10 章：実世界のナレッジ Harness を作る

> **一文で：** ある一人の開発者が、4 エージェント体制、progressive disclosure ルーティング、自動コンテンツパイプラインを備えた完全な AI ナレッジシステムを構築した。
>
> **なぜ重要か：** これは、適切なアーキテクチャがあれば、かつてチームが必要だった規模を一人で構築できることの証明である。本書のコンセプトは机上のものではない。

本章では、数か月にわたる反復開発の末に完全なナレッジ harness を構築した、ある単独開発者 ——ここでは「ビルダー」と呼ぶ —— の匿名化されたケーススタディを示す。ここで述べるシステムは実在し、現在も日常的に本番運用されている。これは、context engineering、progressive disclosure、skill systems、エージェント編成といった前章までのコンセプトが、実践でどう組み合わさるかを示す。

## 出発点

ビルダーは単純な問題から始めた：知識が多すぎて、構造が足りない。個人のナレッジ vault は、進行中のプロジェクト、技術リファレンス、会議ログ、断片的アイデアにわたり 300 を超えるノートに膨らんでいた。標準的アプローチ ——必要なときに検索する —— は、vault が拡大するにつれて破綻した。ノートは忘れられ、洞察は取り出されるのではなく再発見され、作業セッションをまたぐと文脈が失われた。

最初の解は控えめだった：vault にアクセスできる LLM アシスタントを使う。しかし 300 以上のノートへの素のアクセスは context window を溢れさせた。本当のエンジニアリング課題は「LLM が私のノートを読めるか」ではなく「適切なノートを適切なタイミングでどう LLM に渡すか」だった。

## ナレッジ層：暗黙的なナレッジグラフとしての vault

このシステムの土台は、意図的に設計されたフォルダ階層を持つ Obsidian vault である：

- **Inbox** ：取り込み用（新しいノートはまずここに着地する）
- **Active** ：日常使用のノート（5–10 件に保つ）
- **Projects** ：締切のある時間制約付き作業
- **Areas** ：締切のない継続責任
- **Notes** ：原子的知識（1 ノート 1 アイデア、タイトルは断定文）
- **Daily** ：日誌とレビュー報告
- **Archive** ：完了済み・陳腐化した素材

すべてのノートは wikilink で関連ノートに繋がり、形式的なグラフ DB なしに暗黙的なナレッジグラフを形成する。リンク規約は単純だが厳格である：ノート A がノート B が詳述するコンセプトに言及するなら、A は B にリンクしなければならない。これにより時間の経過とともに、どの入口からでも関連 context にたどり着ける、ナビゲート可能な知識の網が形成される。

vault はレビューサイクルで保守される：日次レビューは inbox を処理し新しいノートを分類する。週次レビューは知識蓄積の傾向を分析し、価値ある古いノートを浮上させる。月次レビューは矛盾を検出し、重複ノートを統合し、完了プロジェクトをアーカイブする。この保守は任意ではない。なしでは、ノートが古び・冗長化・孤立化し、ナレッジ層は数週間で劣化する。

## Context Engineering：インデックスとしてのシステム prompt

ビルダーの context engineering アプローチは、システム prompt を一枚岩の指示集ではなく、より深いリソースへのインデックスとして扱う。中央構成ファイル（AI のための README に相当）には次が含まれる：

- **環境詳細**：OS、shell、避けるべき既知のクセ
- **言語設定**：ビルダーの作業言語と書式規約
- **ルーティングテーブル**：トリガーキーワードとルーティングファイルへのポインタを持つ、スキル分類の優先順位付きリスト

この構成ファイルは常時ロードされる。ペイロードではなくポインタを保持するので、コンパクトに保たれる ——2,000 トークン未満。LLM はユーザー要求を受け取ると、ルーティングテーブルと突き合わせて該当のルーティングファイルだけをロードし、そのファイルから必要な特定のスキルへと辿る。

別のメモリシステムがセッション横断の永続化を担う。次を保存する：

- アクティブなプロジェクトの場所と構造
- フィードバックから学習したユーザー設定
- 各プロジェクト固有の技術パターンと規約
- 複雑なトピック向けの詳細サブファイルへの参照

メモリファイルは有機的に成長する。ビルダーがアシスタントの振る舞いを修正すると、その修正は設定として記録される。プロジェクトの構造が確立されると、一度文書化され以降は参照される。これにより、ステートレスな LLM とのやり取りに付きまとう「自分のプロジェクトをまた説明する」反復問題が解消される。

## Harness Engineering：エージェントチーム

このシステムは 4 エージェント体制を採用し、それぞれに役割が定義されている：

1. **Data Collector**：外部ソース（ウェブ検索、API 呼び出し、ドキュメント解析）から情報を収集する。広い権限で動作するが、公開能力は持たない。
2. **Pipeline Orchestrator**：ワークフローを調整し、どのエージェントを呼び出すかを決め、シーケンスを管理する。「sprint contract」 ——各タスクの期待出力基準を定める文書 —— を書く。
3. **Content Writer**：出力（レポート、SNS 投稿、技術文書）を生成する。ブランドボイスと書式基準を強制する content guard の下で動作する。
4. **QA Evaluator**：すべての出力を sprint contract に照らしてレビューしてから公開させる。事実の正確性、書式準拠、ブランド整合性をチェックする。

Sprint contract の仕組みは詳述に値する。Orchestrator がコンテンツタスクを開始するとき、単に「X についての投稿を書け」とは言わない。次を指定する契約を生成する：対象プラットフォーム、語数範囲、必須要素（例：統計を 1 つ含めること、CTA で締めること）、禁止要素（例：最上級表現禁止、未検証の主張禁止）、評価基準。Content writer はこの契約に対して生成する。QA evaluator はこの契約に対して採点する。出力が評価で落ちたら、契約基準を参照する具体的フィードバックと共に writer に返される。これは単発のリトライではない ——契約が満たされるか人間が介入するまでループは続く。

Content guard は 3 層で動作する：

- **Prompt レベルガード**：エージェントが何をしてよく何をしてはいけないかを定義する、システム prompt 埋め込みの指示
- **Auto-correction**：生成後の処理で、よくある問題を捕捉して修正する（例：望ましくない書式パターンの除去、用語統一の強制）
- **Regex strip**：出力に決して現れてはならない特定パターンを除去する最終パス（例：下流システムを壊す特定文字、モデルから漏れるメタデータトークン）

エージェント間通信はトリガーベースである。エージェントは互いをポーリングしない。Data collector が情報収集を終えると、定義された場所に出力を書き、orchestrator をトリガーする。Writer がコンテンツを生成すると、evaluator をトリガーする。このイベント駆動アーキテクチャは、不要な計算なしにシステムをレスポンシブに保つ。

## スキルシステムの進化

スキルシステムは、本番運用で見つかった実用上の限界に駆動されて、4 つの明確な進化段階を経た。

**段階 1：フラットなスキルファイル。** 各スキルは指示を含む独立した markdown ファイルだった。LLM はセッション開始時に全スキルファイルをロードした。スキル数 5–10 では機能したが、コレクションが拡大すると持続不能になった。Context window がスキル定義で埋まり、実作業の余地がほとんどなくなった。

**段階 2：リッチな YAML フロントマター。** スキルは構造化メタデータ ——トリガー条件、必要 context、依存関係、バージョン番号 —— を獲得した。これによりシステムは関連性でスキルをフィルタできたが、フィルタリング自体がトークンを消費し遅延を加えた。

**段階 3：スキル間 wikilink。** スキル同士がリンクし合い、スキルグラフを形成し始めた。「deploy」スキルは前提条件として「run tests」にリンクする。これによりシステムは単独スキルではなくスキル連鎖をロードできるようになったが、グラフのナビゲーション自体にグラフインデックスのロードが必要だった。

**段階 4：ルーティングファイルによる Progressive disclosure。** 最終アーキテクチャは、システム prompt 内のルーティングテーブルというコンパクトなインデックスを使い、それが 7 つのカテゴリ別ルーティングファイルを指す。各ルーティングファイルは、そのカテゴリのスキルをトリガー条件付きで列挙する。LLM はマッチしたカテゴリのルーティングファイルだけをロードし、続いて必要な特定スキルだけをロードする。任意の瞬間にシステムにロードされているのは：システム prompt インデックス（約 2K トークン）+ 1 つのルーティングファイル（約 500 トークン）+ 1 つのスキルファイル（約 1–2K トークン）。総オーバーヘッド：システムにスキルがいくつあろうと 4K トークン未満。

ビルダーはこのルーティングアーキテクチャを全カテゴリにまたがる 85 件のテストクエリで検証し、85/85 の正解 ——100% の精度 —— を達成した。エッジケース（複数カテゴリにマッチしうる曖昧なクエリ）はルーティングテーブル内の明示的な曖昧解消ルールで処理する。

## 結果

このアーキテクチャの測定可能な成果：

- **65% のトークン削減**（フラットファイル方式比、progressive disclosure による）。以前は 8–12K トークンのスキル context を消費していた同じタスクが、現在は 4K 未満で済む。
- **自動コンテンツパイプライン** ：複数プラットフォームに一定品質で日次出力し、一人で管理。
- **ナレッジ保守** ：自動 vault lint が矛盾、孤立ノート、陳腐化情報を検出する ——以前は手動レビューセッションが必要だった問題。
- **セッション横断の連続性** ：「コールドスタート」問題が解消される。メモリシステムにより、アシスタントは毎回前回の続きから始められる。

## 学んだこと

**簡単に始め、複雑さは段階的に重ねよ。** ビルダーは初日から 4 エージェント sprint-contract システムを設計したわけではない。最初は指示テキストファイル 1 つを持つ単一エージェントだった。複雑さの各層は、特定の失敗モードへの応答として加えられた：エージェントが幻覚した（QA evaluator を追加）、出力が一貫しなかった（content guard を追加）、context window が溢れた（progressive disclosure を追加）。早すぎるアーキテクチャは、想像上の問題に最適化されたシステムを生んでいただろう ——実際の問題ではなく。

**Progressive disclosure はセットアップコストに見合う。** ルーティングテーブル、7 つのルーティングファイル、個別スキルファイルの構築と保守は継続的な労力を要する。しかし 65% のトークン削減は、対話 1 回ごとに自身の元を取る。さらに重要なのは、システムがスケールすることだ：新しいスキル追加は、prompt 全体の再構成ではなく、1 つのルーティングファイルへの 1 エントリ追加で済む。

**Less is more。** 圧縮された精密なスキル定義は、冗長なものより優れる。「クエリにマッチするノートを vault で検索し、ファイルパスと関連抜粋を返し、繋がりを提案する」と書かれたスキルファイルは、同じ指示を 500 語で詳述したものより、よく機能する。LLM は手取り足取り教えてもらう必要はなく ——明確な意図を必要とする。

**Harness こそが製品である。** ビルダーの競争優位は、特定の単一スキルやエージェントではない。それは harness ——ルーティング論理、sprint contract、content guard、レビューサイクル、メモリシステム —— である。個別の構成要素は素直なものだ。価値が宿るのは統合の中である。これはナレッジエンジニアリングのより広い真理を反映している：モデルはコモディティ化しているが、それを編成するシステムはコモディティ化していない。

## サイドバー：参照実装としての Claude Code

ビルダーのシステムが進化していた期間の大半、Anthropic 自身の社内ツールはブラックボックスだった。実践者は Claude Code の振る舞いから動作を推測できたが、Anthropic 外でソースを見た者はいなかった。それが変わったのは **2026 年 3 月 31 日**、Anthropic が npm パッケージ `@anthropic-ai/claude-code` v2.1.88 内に 59.8MB の source map を誤って同梱したときだった ——1,906 ファイルにまたがる約 513,000 行の難読化されていない TypeScript（全容は第 4 章を参照）。このリークは、フロンティアラボの本番 harness をコミュニティが初めて経験的に覗き見る機会を与えた。そしてそのパターンのいくつかは、ビルダーが独立して到達したものと近い韻を踏む：

- **Self-Healing Memory、1 つの大きなファイルではなく。** Claude Code の流出アーキテクチャは、層と層の間に明示的な修復ロジックを持つ 3 層「Self-Healing Memory」を中心に組まれている。ビルダーの vault + メモリファイル + sprint-contract ループは、同じ発想の貧者バージョンである：短期作業状態（現在のセッション）、中期圧縮状態（メモリファイル）、長期永続知識（vault）。両システムにおいて「memory」は場所ではない ——遷移を伴う層の集合である。
- **MEMORY.md はインデックスであって store ではない。** Claude Code 内部では、`MEMORY.md` は一枚岩の transcript ではなく、より詳しいノートへの軽量なポインタ式インデックスである。ビルダーの構成ファイルはまさに同じ役割を果たす：ルーティングテーブルとポインタを持ち、ペイロードは持たない。これがベースライン context を 2K トークン未満に保てる理由である。
- **`KAIROS` と自律デーモンモード。** Claude Code のソースは `KAIROS` フィーチャーフラグを 150 回以上参照する。これは自律デーモンモード ——対話的 REPL の遥か先を行く、無人で長時間動く実行ループ —— をゲートする。ビルダーのトリガーベース・イベント駆動のエージェント間通信は、同じ発想の手作り版である：イベントで起き、作業し、引き継ぐエージェント。各ステップで人間の介入を必要としない。

このサイドバーの趣旨は、ビルダーのシステムが密かに Claude Code であるということではない。両者はエンジニアリング工数で桁違いに離れており、ビルダー版は Anthropic が 50 万行の TypeScript で行うことを数百の markdown ファイルで行っている。趣旨は、**両システムが独立に同じ形に収束した** ——インデックスを伴う層化された memory、ペイロードよりルーティング、イベント駆動の編成 —— ことであり、これらのパターンが様式的選択ではないことを示唆する。実際のワークロードに耐えた本番 harness は、こういう姿に行き着くのである。

## 実践者への含意

このケーススタディは、単独の開発者が数か月にわたり反復作業することで、2 年前ならエンジニアチームが必要だった規模のナレッジ harness を構築できることを示している。鍵となる可能化要因は：複雑な多段指示に従えるだけの能力を持つ LLM、ツール統合のためのオープンプロトコル（MCP）、そしてこれらのシステムの設計パターンを提供する新興分野 context engineering である。

ビルダーのシステムはコピーするテンプレートではない。本書の原則 ——progressive disclosure、context engineering、スキルグラフ、エージェント編成 —— が本番で測定可能な成果を生むことの概念実証である。あなたの harness は違う形になる。アーキテクチャは同じであるべきだ。

---

*次の章: [第 11 章 — LLM ナレッジエンジニアリングの鍵となる瞬間](11-timeline.md)*
