はじめに：「社内ドキュメントを全部入れたのに、なぜ回答がおかしいのか」

エンタープライズAIエージェントの導入を進めると、必ずと言っていいほど直面する問いがあります。社内Wiki、Confluence、PDFを数千件ベクトルDBに投入し、「これで賢くなったはず」と期待したのに、実際に動かすと一般論しか返さないチャットボットが現れる——。

Metaのエンジニアリングチームも、まったく同じ問題に正面から向き合いました。特定ドメイン（例：コンプライアンス）の専門家が、定型的な質問への回答に追われ、本来注力すべき判断が必要なケースに時間を割けない状況です。そこで彼らは**「組織のセカンドブレイン（Second Brain）」**というコンセプトで、まったく異なるアプローチを試み、わずか6週間で実運用レベルまで到達しました。

本記事では、そのアーキテクチャを実務視点で分解し、なぜ純粋なRAGでは不十分なのか、そしてモデル再学習なしで専門家フィードバックを永続的に反映する方法までを整理します。

📎 根拠資料： Meta Engineering - Organizational Second Brain

AI agent chat interface representing organizational second brain knowledge system for enterprise expert reasoning Development Concept Image

コアアーキテクチャ：4つのレイヤーに分割する

Metaが公開したシステムは、4つのレイヤーで構成されています。各レイヤーは相互依存しており、1つでも欠けると全体が劣化する設計です。

1. Knowledge System（ナレッジレイヤー）— 組織のセカンドブレイン

最も重要な洞察はこれです。「ドキュメント = ナレッジ」ではない。 真のナレッジは、専門家の頭の中にある判断の仕方にあります。

そこでMetaは、200以上のファイルを**厳格な分類体系（taxonomy）**で再構成しました。

  • Position files：「この問いにはこう判断する」という組織の公式スタンス + 境界条件
  • Taxonomy / Vocabulary files：組織が使う用語の単一の真実の源（Single Source of Truth）
  • Routing indexes：入力特性 → どのファイルをロードするか決定（埋め込み類似度に依存しない！）
  • Gateway files：分析ドメインに入る前に通過すべき閾値テスト

すべてのファイルはYAML frontmatterに depends_on、referenced_by を宣言し、双方向依存グラフを形成します。これが重要な理由は、自己改善ループが自動編集を提案する際に、**「これを変更するとどこまで影響が及ぶか」**を追跡できるようになるからです。

2. ナレッジは「密度」と「使用頻度」で分割する

ここで実務的に極めて重要な意思決定が登場します。

区分Wiki（構造化）RAG（検索）
特徴高密度、常時参照低密度、状況依存参照
例Position、意思決定フレームワーク、境界事例個別製品仕様、過去の決定記録、外部資料
理由毎ターン参照するため最新性維持が必要毎回ロードするとコンテキスト浪費

核心は、**「コア推論は常に精錬された組織ナレッジにグラウンディングし、必要な時だけRAGで補助証拠を取得する」**という点です。

3. Recipe（レシピ）— ナレッジと推論を分離する

ここが最も感銘を受けた部分です。**Knowledge filesは宣言的（declarative）、Recipesは命令的（imperative）**です。

# recipe_example.yaml（概念例）
name: compliance_assessment
steps:
  - step: 1
    action: "入力分類"
    load_knowledge: ["taxonomy/entity_types.md"]
    checkpoint: true  # 専門家レビューポイント
  - step: 2
    action: "関連positionのロード"
    load_knowledge: ["positions/data_handling.md"]
    escalation_condition: "evidence_conflict"
  - step: 3
    action: "リスク加重評価"
    load_knowledge: ["frameworks/risk_weights.md"]

この分離がもたらす力：

  • 組織スタンス追加 = knowledge file追加 + routing index更新（レシピ変更なし）
  • 方法論修正 = レシピのみ修正（knowledge file変更なし）
  • 失敗原因 = どのレイヤーの問題かクリーンに帰属

4. トークン80%削減の秘密

初期バージョンは単一のフラットファイルに全ソースをセマンティック検索でロードしていました。毎ターン、関連性の低いファイルがコンテキストを圧迫していたのです。Recipeベースの段階分離後、各クエリは小さくターゲティングされたサブセットのみをタッチ → ターンあたりのトークン消費が約80%減少。コンテキストウィンドウは有限であり、アテンションはボリュームに応じて劣化するため、これは単なるコスト削減ではなく推論品質の向上です。

Server infrastructure diagram visualizing structured knowledge files and dependency graph for AI agent compilation pipeline Developer Related Image

自己改善フライホイール：モデル再学習なしで専門家フィードバックを永続反映する方法

このシステムの最も独特な部分はSelf-Improvement Flywheelです。専門家フィードバックを4段階のコンパイルパイプラインで処理します。

Step 1. Diagnosis — 会話形式ではなく根本原因で分類

当初はヒューリスティックで試みて失敗したと述べられています。「情報を提供したならナレッジギャップ、方向転換したなら手続き問題」というアプローチは、会話形式 ≠ 根本原因であるため機能しませんでした。

機能する方式は抽出と分類の分離です：

  1. 専門家の実質的シグナル + エージェントの全ナレッジマニフェスト（どのファイルをいつどう使ったか）を抽出
  2. 実際のナレッジファイルを読み、単一の帰属テストを適用：
    • ソースに正解があったのに間違えた → Recipe問題
    • ソースに正解がなかった → Knowledge gap
    • 専門家間で見解が割れた → Ambiguity（人間の議論にフラグ）

Step 2. Compilation — 敵対的レビュー（Adversarial Review）

サブエージェントが並列で影響度を分析します。信頼性を生む2つの設計：

  • 独立的敵対レビュー：改善根拠を一切知らない別エージェントがdiffのみを受け取り、問題点（矛盾、エッジケース破壊、スタンス侵害）を発見。コンテキストを共有しないため、提案者のブラインドスポットを継承しない
  • 決定論的構造検証：Linterがdangling参照、ファイルサイズ予算違反、識別子衝突、依存性サイクルをプログラミング的に検出（確率的ではない、Pass/Fail）

Step 3. Evaluation — ブラインド二重検証

  • Targeted replay：フィードバックを誘発した元シナリオで再実行。エージェントはテストされていることを知らない。別のjudgeが何を変更したか知らないまま結果を評価 → 確証バイアスを遮断
  • Regression testing：ドメイン別Q&Aベンチマークを並列独立セッションで実行。回帰検出時は、元issue + 試行修正 + 回帰位置を含むプロンプトで再コンパイル

Step 4. Landing — 固定化された失敗シナリオが資産になる

承認されたPRがランディングされると、元の失敗シナリオ + 検証済み正解が自動的に回帰テストスイートに追加されます。つまり、すべての修正が永続的にバーを引き上げ、以降の変更は直前に修正した動作を必ず保存しなければなりません。

実務結果（6週間・3スプリント）

  • コンプライアンスドメインのSMEがエージェント出力をほぼ常に有用と評価
  • 個別評価所要時間 日（days）→ 分（minutes）
  • ゼロ回帰を達成、各修正が回帰スイートを強化

⚠️ このアーキテクチャの限界と注意事項

率直に言えば、このアーキテクチャはすべてのチームに適合するわけではありません。導入前に以下を必ずチェックしてください。

  1. 初期キュレーションコストが相当かかる：200+ファイルをtaxonomyで再構成する作業は、相当なドメイン専門家の時間を要します。ドキュメントが10件未満なら、単純なRAGの方が優れています。
  2. 「判断可能なテキスト」ドメインである必要がある：コンプライアンス、財務リスク、セキュリティレビューのように検索可能なテキストで判断が表現されるドメインにのみ適用可能です。創造的設計や新製品企画には不向きです。
  3. Human-in-the-loopがデフォルトであるべき：高リスク意思決定（コンプライアンス、金融）では、checkpoint/escalationをオフにしてはいけません。
  4. レシピの過剰エンジニアリングに注意：手続きが細分化されすぎると、メンテナンス地獄が訪れます。最初は3〜5個のレシピから始めてください。

📚 次のステップ学習方向

このアーキテクチャを直接試すなら：

  1. Andrej KarpathyのLLM Wiki概念から理解する（ナレッジをファイルグラフとして構造化）
  2. Google Open Knowledge Format 仕様を確認（cross-agent相互運用性）
  3. 小さなドメインを1つ選定 → 10ファイルでプロトタイプ → 回帰テスト1件から開始

Data analysis dashboard showing regression test results and self-improvement loop metrics for enterprise AI knowledge base Programming Illustration

まとめ：「複雑性をモデル重みではなく、テキストファイルに置け」

Metaエンジニアリングチームが残した最も重要な一文です：

「Keep the complexity in text files that are readable by both humans and agents, rather than fine-tuned model weights.」

ファインチューニングはブラックボックスであり、巻き戻しが難しく、監査が不可能です。一方、テキストファイルベースのナレッジシステムは：

  • すべての改善が30秒でドメイン専門家がレビュー可能なdiff
  • すべての変更がバージョン管理、diff、ロールバック可能
  • コンパイルパイプラインが精巧でも出力は常に透明

結局のところ、目標はこれです。専門家の努力が永続的に複利で積み上がるシステム。 すべての相互作用がシステムをより良くし、すべての修正が検証済みの改善として残る。

あなたの組織の集合知がまだ個人の頭の中に閉じ込められているなら、このアーキテクチャは真剣に検討する価値があります。

あわせて読みたい

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。