Meta AI、組織の専門知を学習する「第二の脳」型AIエージェントを開発

私たちは、特定のドメインにおける専門家の「セカンド・ブレイン」として機能する AI エージェントを構築しました。これにより、組織内の誰もが深く専門的な知識にアクセスし、共有し、それを基に発展させることが可能になります。

これは一般的なドメイン特化型エージェントとは異なります。その革新性は、2 つのレイヤーを統合した点にあります。

1 つ目は、構造化され監査可能な知識アーキテクチャです。これにより、「エージェントが何を知っているか」と「どのように推論するか」を明確に分離します。

2 つ目は、自己改善ループです。専門家のフィードバックを取り込み、モデルの再学習を行わずに、検証済みで回帰テスト済みの更新として蓄積していきます。

この 2 つのレイヤーが組み合わさることで、単発的な専門家の修正が永続的かつ複利効果を生む組織の記憶へと変換されます。このパターンは、モデルの重みではなく、検索可能なテキストによって支配される他のドメインにも一般化できるように設計されています。

このシステムは、Meta におけるドメインの専門家（SME）にとって大幅な時間の節約につながっており、彼らが知識を最も活かせる業務に集中できる環境を提供しています。

多くの大規模組織が、専門知識の扱いにおいて同様の課題を抱えています。一部の知識はモデルやプレイブック、チェックリスト、フレームワークとして文書化されていますが、最も価値のある専門知識は人の頭脳の中にあり、永続的な形で記録されることはほとんどありません。例えばコンプライアンス分野では、数百もの製品レビューで同じような質問が発生し、専門家の評価には数日間の手動調査が必要となります。さらに、評価間の一貫性の欠如が組織に実害をもたらすリスクを生んでいます。

専門家が、その判断が最も重要な本質的に新規で曖昧な仕事よりも、ルーチン的な質問への対応に多くの時間を費やすことは珍しくありません。組織の専門家の推論プロセスを捉え、必要なすべての人がその知識を利用できるようにするシステムが必要です。そうすることで、専門知の共有、継承、保存が容易になります。

私たちはこの課題に対処するため、特定のコンプライアンス領域において、組織のインテリジェンスを AI エージェントとしてコード化することから始めました。このエージェントは、組織の「セカンド・ブレイン」として機能する知識システムと、ドメイン専門家が実際に思考する様子を模倣する推論層、そして専門家の努力を永続的に積み重ねる自動化された改善パイプラインを組み合わせています。これらのパターンは、金融、セキュリティ、エンジニアリングなど、深い専門知識を持つあらゆる企業領域に一般化して適用可能です。

アーキテクチャの概要

市販の LLM は強力な基盤を提供しますが、専門家領域で完全に効果を発揮するには、より深い組織文脈が必要です。この基礎となる文脈がなければ、汎用モデルは限られた価値しか持ちません。なぜなら、組織が「できること」（一般的な情報の要約）と、「考慮すべきこと」（過去の立場、会社の方向性、ビジネスの文脈などに基づく）を区別できないからです。リスクの高い領域では、このギャップを埋めるために、モデルに組織独自の知識と優先順位を提供し、その分析が組織が実際にどのように推論するかを反映させる必要があります。

私たちが設計したシステムは、それぞれが異なる課題を解決する 4 つのレイヤーで構成されています。

これらのレイヤーはお互いに依存し合っています。知識システムのファイル構造により、自動化された編集が可能になります。推論層の明示的な手順によって、失敗の原因特定が現実的なものとなります。評価フレームワークはすべての変更をゲートします。そして改善ループは、知識と推論の両方にフィードバックされます。どれか一つのレイヤーを欠けば、他の部分も機能しなくなります。

組織のセカンド・ブレイン（第二の脳）を構築する

大規模な組織では、専門家の業務に伴って文書が数千件蓄積されることが珍しくありません。これらの文書をそのまま「組織の知識」として扱うのは誘惑的ですが、真の知識は暗黙的なものです。つまり、専門家がどのように推論し、何を優先し、曖昧さをどう解決するかという点です。推論時に文書の一部を参照するエージェントでは、毎回生データからその推論プロセスを再構築する必要があり、これは遅く、エラーが発生しやすく、一貫性にも欠けます。

私たちは、こうした暗黙的な知識を事前に明示化します。長時間実行されるオフラインのプロセスがソースドキュメントを分析・推論し、構造化された知識ファイルへと凝縮します。これにより、組織がその専門領域をどのように解釈しているかを示す厳選された記述が作成され、制約や境界条件、ルーティングの指針などが機械可読な形式で定義されます。

最も重要なのは、この知識がフィードバックループの基盤となり、エージェントが人間の専門家のフィードバックから学習し、それを実装できるようになる点です。これにより、背後にあるモデルを再トレーニングする必要がなくなります。

業界全体も同様の考え方に収束しています。アンドレイ・カルパティ氏の「LLM Wiki」では、エージェントの知識をファイルで構成されたナビゲート可能なグラフとして構造化しており、Google の「Open Knowledge Format」標準はこの仕組みをクロスエージェンシー間の相互運用性のために標準化しました。共通する洞察は、知識は各クエリごとに再計算されるのではなく、事前に抽出され、明示的に構造化され、段階的に開示されるべきだという点です。私たちはこれらの原則をさらに発展させ、引用の忠実性と組織的な一貫性を絶対条件としたシステムを構築しました。200 件以上のファイルを厳格な分類体系に整理しています。

「ポジションファイル」は、組織が特定のドメインの問いに対してどのように解釈し、決定を下したかという権威ある立場を記録します。また、その適用範囲や境界条件、そして推論層がいつこのルールを適用すべきかを機械的に判断できるルーティング情報も含まれます。

「タクソノミーと語彙ファイル」は、組織がドメインを記述する際に使用する用語の権威ある辞書として機能します。エンティティタイプ、アクティビティカテゴリ、分類階層などが対象です。これらはすべて「唯一の真実源」として管理されており、エージェントと組織が言語を一貫して使用できるようにしています。

ルーティングインデックスは、入力の特徴を関連する位置と手順にマッピングし、埋め込みの類似性だけに頼らずに適用されるファイルを決定します。これにより、検索が確定的かつ監査可能になります。

ゲートウェイファイルは、エージェントが分析ドメインに入る前に通過しなければならない閾値テストを定義しており、専門知識が必要な場所以外で誤って適用されないように防止しています。

すべてのファイルは、YAML のフロントマターに依存関係（depends_on）と消費者（referenced_by）を宣言し、双方向の依存グラフを形成します。あるファイルが変更された場合、自己改善ループが自動編集を提案した際にも影響を受ける他の要素を正確に追跡できます。

image知識システムの概要図：ファイルはナビゲート可能なファイルシステム（左）として整理され、各ファイルの YAML フロントマター（右）では、適用されるタイミング（トリガーとなるシナリオ）、依存関係、消費者を宣言し、エージェントが容易にたどって管理できる双方向の依存グラフを形成します。

知識を密度と利用頻度に基づいて整理する

重要なアーキテクチャ上の判断は、キュレーションされたウィキと補完的な検索（RAG）の間で知識をどのように分割するかです。私たちは情報の密度と予想される利用頻度を基準に分割を行います。

高密度で頻繁に参照される情報は、ウィキペディア形式の知識基盤に格納されます。ここでは、組織がどのように推論を行うかを要約したファイル（ポジション、意思決定フレームワーク、境界事例、戦略的解釈など）を保存し、エージェントはほぼすべての処理段階でこれらを参照します。これらの情報は組織の思考プロセスの進化を反映しているため常に最新の状態を保つ必要があり、ウィキ構造によってその更新、バージョン管理、検証が容易に行われます。

一方、状況に応じて必要な情報源は、セマンティック検索や語彙ベースの検索（RAG）を通じて提供されます。詳細な参照資料、個別製品の仕様書、過去の意思決定記録、ニッチな外部知識など、特定の局面では極めて重要ですが、通常の処理では詳細まで必要とされない情報がこれに該当します。これら全てをウィキに読み込むとシステムが肥大化し、重要な情報への注力が散漫になるためです。

その結果、エージェントの核心的な推論は常に最も洗練され、最新の組織知識に基づいて行われますが、特定のシナリオで裏付けが必要となる場合は、関連する証拠資料にも柔軟にアクセスできます。この組み合わせにより、単なる情報の所在を示すだけでなく、組織が情報をどのように解釈し適用するかを内包した「組織のセカンド・ブレイン」が構築されます。

専門家の推論：コンポーザブルなレシピを通じて

知識だけでは不十分です。ドメインの専門家は単に事実を思い出すのではなく、構造化された手法に従います。例えば財務アナリストはバリュエーションモデルを段階的に処理し、セキュリティエンジニアは脅威モデリングの手順に従います。課題は、LLM が確実に実行できる形式でこれらの手法を捉えることです。

私たちは「レシピ」と呼ぶ合成可能な手順によってこの課題を解決します。知識ファイルが宣言的であるのに対し、レシピは命令的です。各レシピは多段階の分析ワークフローを規定し、まず何を調査すべきか、各ステップでどの知識を読み込むべきか、どのような意思決定手順に従うべきか、そして何が完全な分析とみなされるかを具体的に指定します。

重要な設計上の選択は、エージェントが「何を知っているか」と「どのように推論するか」を分離することです。レシピは知識ファイルを参照しますがドメインの事実を含みません。一方、知識ファイルは立場を示すものの手順を規定しません。これにより以下のようなメリットが生まれます。

組織内の新しい立場を追加するには、知識ファイルを追加してルーティングインデックスを更新するだけでよく、レシピの変更は不要です。

エージェントの手法に欠陥がある場合は、レシピを編集すればよく、知識ファイルを変更する必要はありません。

失敗の原因も明確に層ごとに特定できます。それは知識が間違っていたのか、それとも手順に問題があったのか、どちらか一方に帰属します。

レシピはパイプラインを構成します。これは、夕食のサービスにおけるマスターシェフが、ソースやタンパク質、飾り付けといった各コンポーネントのためのサブレシピに委任するが、それらの詳細自体には含まないマスターレシピのようなものです。上位レベルのルーティングレシピは入力 examined し、どの下流レシピを呼び出すかを選択します。それぞれが分析フェーズの一つを担当します。

これは段階的な開示（プログレッシブ・ディスクロージャー）も可能にします。あらゆる可能なシナリオを網羅する単一の巨大な指示セットを最初から提示するのではなく、各レシピステップにはそのフェーズに関連する指示と知識のみが含まれます。初期バージョンでは、単一の平坦な指示ファイルを使用し、セマンティック検索を通じてすべてのソースを読み込み、実行のたびに文脈ウィンドウに大量の関連性の異なるファイルを呼び出していました。レシピ駆動型のステージへと再構成した後、各クエリは小さくターゲットを絞ったサブセットのみを対象とするようになり、1 トークンあたりの消費トークンは約 80% 削減されました。コンテキストウィンドウには限界があり、量が増えると注意散漫（アテンション）が低下するため、適切なタイミングで正しい指示を提供することは、推論の質を直接向上させます。

人間の制御維持

このシステム全体を通じて、人間のエキスパートがコントロールし続けます。エージェントは彼らの作業を加速・構造化しますが、判断力や結果に対する権限を代替するものではありません。

これを以下の 2 つのメカニズムで実現しています。

• チェックポイント：分析中の定義された地点において、エージェントは進行前に中間推論を提示し、エキスパートがレビューします。その後、エキスパートは確認、修正、または方向転換を行うことができます。

エージェントが、入力情報の不備や複数の正当な解釈を支持する証拠などにより、真の曖昧さに直面した際にエスカレーションが発生します。無理に解決を図るのではなく、質問は専門家へ引き継がれ、その選択によって分析の方向性が決定されます。

チェックポイントとエスカレーションには、同時に三つの目的があります。

品質と方向性の制御：専門家が誤りを下流で拡大する前に検出し、分析を最も関連性が高いと考える道筋に維持します。

学習シグナル：修正やエスカレーションのすべてが、自己改善ループへの入力となります。

信頼の調整：専門家は最終出力だけでなく、エージェントの推論プロセスを観察し、不確実性を隠すのではなく明確に示す様子を見ることで、段階的に信頼を構築します。

意思決定の重大度が高くなるほど、この仕組みは重要になります。そのため、コンプライアンス、金融リスク評価、セキュリティレビュー、エンジニアリング安全性といった分野では、デフォルトで人間をループに参加させることを推奨しています。

自己改善のフライングホイール

このシステムで最も特徴的な部分は、自己改善のフライングホイール（flywheel）です。構造化された知識システムと組み合わせ可能なレシピは、人間やエージェントが可読性を持ち、テスト可能でモジュール化されたシステムを構築しますが、相互依存するファイルの数が増えると、手動でのメンテナンスはスケーリング不可能になります。ドメインの専門家がエージェントにフィードバックを提供する場合、そのフィードバックは正確なファイル編集に変換されなければなりません。このプロセスには数週間かかることがあり、完全な依存関係グラフの理解、他の部分が壊れていないことの検証、そして修正が実際に機能していることの確認が必要だからです。

エージェントが知識をどのように保存し、取得し、更新するかという課題に取り組むための研究は多数あります。RAG（Retrieval-Augmented Generation）メモリシステムからモデル重みを用いた知識編集まで多岐にわたります。しかし、文書ベースの組織的ナレッジベースが成長し、専門家の見解が進化する中で、その正確性を維持することについては、あまり注目が集まっていません。エージェントが自動的に修正をドラフトするケースは増えています。ただし、モデルの再学習なしで構造化されたナレッジベースに対して、このレベルの検証厳密性が適用されている例はまだ見たことがありません。

私たちはこのメンテナンスをコンパイル問題として捉え、自動化します。専門家の修正は以下の 4 つのフェーズを経ます：

1. 専門家のフィードバックを診断し、根本原因を含む実行可能な課題に落とし込む。
2. 課題を最小限の検証済み編集に変換する（コンパイル）。
3. 回帰（regression）なく修正が機能していることを検証する。
4. ドメインの専門家がそれらを検証する。

ループが完了すると、直前に修正された不具合が回帰テストスイートに追加され、今後の更新でもその挙動が維持されるようになります。

image自己改善ループ。専門家の修正は根本原因に特定され、検証済みの最小限の編集としてまとめられ、再生テストと回帰テストで評価された後にレビューと採用が行われます。各修正はその後回帰スイートに取り込まれるため、その成果は永続的なものとなります。

診断：各修正を根本原因に割り当てる

生の専門家のフィードバックは、ドメインの専門家（SME）がエージェントと対話し、修正を加えた会話ログから得られます。この診断フェーズでは、これらの会話から構造化されたシグナルを抽出します。

最初の手法では、フィードバックを会話の形式に基づいて分類しました。専門家が情報を提供した場合は知識不足、エージェントの方向転換を促した場合は手順の問題だと判断するものです。しかしこのヒューリスティックは失敗しました。会話の形式は根本原因の代用として不適切だからです。専門家が結論に対して修正を加える場合でも、それは知識不足、レシピの不備、あるいは真の曖昧さを指摘している可能性があり、一概に断定できません。

このアプローチでは、情報の抽出と分類を分離して行います。まず、エージェントが読み込んだすべてのファイル（いつ、どのように使用されたかを含む完全な知識マニフェスト）とともに、専門家のあらゆる実質的なシグナルを抽出します。次に、実際の知識ファイルを参照し、単一の帰属テストを実行します。「エージェントは、入手可能な資料から正しい結論に到達できたか？」

もし資料に正解が含まれていたにもかかわらずエージェントが誤った場合：それはレシピの問題です。

もし資料に正解が含まれていなかった場合：それは知識のギャップです。

もし専門家同士で正解について意見が分かれる場合：それは曖昧さであり、人間の議論のためにフラグを立てます。

コンパイル：外科的なマルチエージェント編集

このコンパイラーは、診断された各課題を最小限のファイル編集に変換します。サブエージェントは並列して影響を分析し、相互参照、既存の立場との競合、トークン予算への影響、テストカバレッジ、重複リスクを検査します。

信頼性を高めるために採用した2 つの設計上の選択があります。

独立した敵対的レビュー：改善の根拠について何も知らない新しいコンテキストで動作する別のエージェントが、知識ベースに対する提案された差分のみを受け取ります。その役割は、導入された矛盾、壊れたエッジケース、または弱められた立場といった問題を見つけることです。提案側エージェントとは文脈を共有しないため、彼らの盲点を継承することはありません。

構造的検証は決定論的に行われます。リンターがプログラム的に問題を検出し、未解決のクロス参照やファイルサイズ制限の違反、識別子の衝突、依存関係の循環などを捕捉します。この層は確率的なものではなく、パスするか失敗するかの二択です。

評価：修正の有効性の証明

提案された変更には、2段階の検証プロセスが適用されます。

まず「ターゲットリプレイ」では、フィードバックをトリガーした元のシナリオに対してエージェントを実行します。テストされていることをエージェントは知りません。また、変更内容を知らない別の判定者が、新しい出力を元の専門家フィードバックと比較評価します。この意図的な盲検化（ブラインド）設計により、確認バイアスを防止しています。ターゲットリプレイで失敗した場合、コンパイルは再試行されます。

次に「回帰テスト」では、そのドメインに特化した複数のベンチマークが実行されます。これらは通常、Q&A ペアの構造化されたテストスイートです。分析ドメインのように正解が複数存在する可能性がある場合でも、独立した LLM 判定者が特定の基準に基づき、各テストケースに対して合格・不合格を判定します。エージェントはベンチマークの質問に対して並列かつ独立したセッションで実行され、パフォーマンスの低下（回帰）を検出します。回帰テストで失敗した場合、コンパイルは再試行されます。その際、エージェントがどこで性能を落としたかを記述した更新されたプロンプトと、元の課題および試みた修正内容も併せて提供されます。

導入と拡張：リターンの複利効果

このパイプラインの出力は、完全な監査証跡を伴うプルリクエスト（差分）です。人間のエキスパートは、生じた失敗のデバッグを行うのではなく、すでに実証済みの修正内容をレビューします。承認されマージされた後（知識ファイルやレシピが更新される）、元の失敗したシナリオとその検証済み正解は自動的に回帰テストスイートに追加されます。つまり、すべての修正が永続的に基準を引き上げることになり、将来の知識システムへの改変では、直近で修正された動作を維持する必要があります。

結果

6 週間にわたる 3 つの開発スプリントを経て、本システムは以下の成果を達成しました。

• ドメインの専門家がエージェントの出力を「ほぼ常に有用」と評価。初期バージョンでは大幅な再作業が必要だったケースが激減しました。
• 個別の評価に要する時間が日単位から分単位へと短縮されました。
• 自動化された自己改善により、以前はフルエンジニアリングスプリントを必要としていた知識編集を、検証済みの形で継続的に生成できるようになりました。
• 改善サイクル全体で回帰バグがゼロ。すべての修正が自動的に回帰スイートを強化しています。
• ドメインの専門家は一貫して、「分析作業の大半をエージェントが処理し、人間による判断が必要な本質的な曖昧なケースに集中できる」と報告しています。

このアーキテクチャの適用

今回構築した特定のドメインでは、数十のソース（内部見解と外部資料の両方）を統合し、リスク加重評価を作成する必要がありました。しかし、このアーキテクチャはドメインに依存しません。以下のような状況であればどこでも応用可能です：

専門家の頭脳に属する専門知識は、往々にして「部族の知恵」として閉じ込められています。

評価の一貫性は極めて重要です。

業務量は、利用可能な専門家のキャパシティを超えています。

市販の汎用大規模言語モデル（LLM）では、不十分な分析しか得られません。

このパターンが当てはまる具体的な領域としては、規制コンプライアンス、プロトコル遵守、金融リスク評価、セキュリティレビュー、エンジニアリング基準への適合性確認、調達評価などが挙げられます。共通するのは、組織が一般知識だけでなく、真の組織的専門性を備えた AI システムを必要としている点です。

このアーキテクチャを採用するための要件は以下の通りです。

• 明確なファイル境界、相互参照、依存関係グラフを持つ構造化された知識システム（そのドメインにおける「組織のセカンド・ブレイン」）
• ドメイン知識と分析手法（レシピ）を分離する手続き層
• 改善サイクルごとに成長していく自動化評価スイート
• ドメインのリスク許容度に調整された、人間が関与するチェックポイント

より深い原理はシンプルです。複雑さを、人間もエージェントも読み取れるテキストファイル内に保持することです。微調整されたモデルの重みの中に閉じ込めるのではなく、あらゆる改善はドメインの専門家が 30 秒でレビュー可能なテキスト編集として行われます。すべての変更はバージョン管理され、差分確認が可能で、かつ元に戻せます。コンパイル・パイプライン自体は高度ですが、その出力は常に透明性を持っています。

目指すべきは、専門家の知見が永続的に蓄積・増幅されるシステムです。専門家とのやり取りのたびにシステムの精度が向上し、修正内容は検証済みの改善として残ります。組織の集合知が個人に閉じ込められる状態から脱却し、共有へと移行するのです。