9月2日、Meta Engineeringが「An Organizational Second Brain: Building an AI That Learns From Experts」と題した記事を公開した。この記事では、専門家の暗黙知をAIエージェントに蓄積し、モデルの再学習なしに自己改善させる組織的ナレッジ基盤のアーキテクチャについて詳しく紹介されている。汎用LLMを「組織固有の判断ができるエージェント」へと変えるための設計は、コンプライアンスにとどまらず幅広いエンタープライズ領域への応用を示唆する内容だ。
課題：専門知識は「人の頭の中」にある
コンプライアンス、金融リスク、セキュリティレビューなど、深い専門知識を要する領域では、どの組織も同じ問題を抱えている。マニュアルや手順書として文書化された知識は一部に過ぎず、最も価値のある判断基準や文脈は専門家（SME）の頭の中にしか存在しない。
結果として、専門家は本来注力すべき高度な判断ではなく、ルーティンな質問対応に時間を消費する。Metaも同じ課題に直面し、特定のコンプライアンスドメインを対象に「組織の第二の脳」として機能するAIエージェントを構築した。
4層アーキテクチャの概観
このシステムは4つの層で構成される。それぞれが独立した問題を解決しており、1つでも欠けると他の層が機能低下する設計だ。
元記事によれば、4層はそれぞれ次の役割を担う：
- 第1層（知識ベース）：組織固有のポジション・用語・依存関係を構造化したファイル群。汎用LLMが持ちえない「この組織としての判断軸」を供給する
- 第2層（レシピ）：「何を知るか」ではなく「どう推論するか」を記述した宣言的手続きファイル。知識と推論手順を明示的に分離する
- 第3層（自己改善ループ）：専門家のフィードバックを診断・コンパイル・バリデーション・承認の4フェーズで知識ベースへ反映する。モデルの再学習は不要
- 第4層（人間の制御機構）：チェックポイントとエスカレーションにより、最終判断の権限を常に人間が持つ
汎用LLMは強力な基盤だが、組織固有の文脈なしでは「一般論として何ができるか」しか答えられない。「この組織がどう判断すべきか」を答えるには、組織自身の知識と優先順位をモデルに供給する必要がある。
核心：知識ベースの構造設計
このシステムの最大の特徴は、暗黙知を事前に明示的な構造として書き出す点にある。推論時にドキュメントを検索して毎回再解釈するのではなく、オフラインのプロセスがソースドキュメントを処理し、「組織がそのドメインをどう解釈するか」を構造化されたファイル群に蒸留する。
ファイルは200以上あり、厳格な分類に従って管理される：
- ポジションファイル：組織が特定のドメイン問題についてどう判断するかの公式立場、制約、境界条件を記述
- タクソノミー/語彙ファイル：エンティティ種別や分類階層など、組織が使う用語の唯一の正典
- ルーティングインデックス：入力の特性から適用すべきファイルを決定論的に特定する。埋め込み類似度だけに頼らないため、監査可能
- ゲートウェイファイル：特定の分析領域に入る前に通過すべき閾値テストを定義し、不適切な知識適用を防ぐ
各ファイルはYAMLフロントマターでdepends_onとreferenced_byを宣言しており、双方向の依存グラフを形成する。1ファイルが変更されると、影響範囲を正確にトレースできる。
元記事はこの設計を「知識を毎回再導出するのではなく、事前に抽出・構造化し、段階的に開示する」思想に基づくものとして説明している。引用の正確性と組織内一貫性を必須要件として設計されている点が特徴だ。
※編集部の考察：Andrej KarpathyのLLM OS構想やGoogleのOpen Knowledge Formatも「知識を構造化して段階的に開示する」という同様の方向性を示しており、本システムの設計思想と共鳴する部分がある。
WikiとRAGの分担
知識の配置先は情報密度と参照頻度で分ける：
- 高密度・高頻度→ Wikiに格納：ポジションファイル、意思決定フレームワーク、境界条件の例など、ほぼ毎回参照されるもの
- 低密度・状況依存→ セマンティック検索（RAG）で提供：詳細な参照資料、個別の製品仕様、過去の決定記録など
「レシピ」による推論の分離
知識だけでは不十分だ。金融アナリストがバリュエーションモデルをステップ順に進めるように、専門家は構造化された手順に従って推論する。この手順を「レシピ」と呼ぶ宣言的な手続きファイルで表現した。
設計上の重要な決定は「何を知るか」と「どう推論するか」の分離：
- レシピは知識ファイルを参照するが、ドメイン事実は含まない
- 知識ファイルはポジションを述べるが、手順を規定しない
この分離により、障害の帰属が明確になる。「知識が間違っていたのか、手順が間違っていたのか」を切り分けられる。
また、レシピの段階的な構成によりコンテキストの逐次開示（Progressive Disclosure）が実現する。初期バージョンでは単一のフラットな指示ファイルと全ソースのセマンティック検索を使っていたが、レシピ駆動の段階的構造に変更したところ、1ターンあたりのトークン消費が約80%削減された。
自己改善フライホイール：最も独自性の高い部分
Metaがこのシステムで最も特徴的と位置づけるのが、モデルの再学習なしに専門家フィードバックを知識ベースへ反映する自己改善ループだ。
専門家の修正は以下の4フェーズで処理される：
- 診断：フィードバックを根本原因（知識の欠落なのか、手順の欠陥なのか）に帰属させる
- コンパイル：問題を最小限の検証済み編集に変換する
- バリデーション：修正がリグレッションを起こさないことを確認する
- エキスパートレビュー：ドメイン専門家がレビューし、承認する
ループが完了すると、修正されたケースがリグレッションテストスイートに追加される。1度修正した問題は永続的に保持される。
元記事によれば、RAGのメモリシステムやモデル重みへの知識編集については研究が進んでいるが、ドキュメントベースの組織知識ベースをモデル再学習なしに正確に維持するためのバリデーション手法はこれまであまり注目されてこなかった領域だ。Metaはこれを「コンパイル問題」として定式化し自動化した。
診断フェーズの難しさ
初期の診断アプローチは会話の形式で分類していた。「専門家が情報を提供した→知識の欠落」「専門家がリダイレクトした→手順の問題」という発見的手法だ。しかしこれは失敗した。会話の形式は根本原因の代理指標として不正確だったからだ。結論への修正は、知識の欠落でも、レシピの欠陥でも、その両方でも起こりうる。
人間の制御を維持する仕組み
エージェントは専門家の作業を加速・構造化するが、判断の権限は人間が持つ設計だ。2つの機構で担保する：
- チェックポイント：分析の途中で中間推論を専門家に提示し、確認・修正・方向転換を可能にする
- エスカレーション：入力が曖昧だったり証拠が複数の解釈を支持する場合、エージェントが強制解決せず専門家に委ねる
これらは品質管理、改善ループへの訓練シグナル、専門家の信頼構築という3つの目的を同時に果たす。
まとめ
元記事がこのシステムを通じて示すのは、LLMを組織の専門知識と接続する際の現実的な設計指針だ。知識と推論手順の分離、依存グラフによる監査可能性、コンパイルとしての知識更新という3つの原則は、コンプライアンス以外にも、金融、セキュリティ、エンジニアリングなど深い専門知識を持つ任意のエンタープライズドメインに適用できると記事は述べている。
詳細はAn Organizational Second Brain: Building an AI That Learns From Expertsを参照していただきたい。
