Metaの組織的なセカンドブレイン：AIエージェントの記憶はモデルの重みにではなく、ファイルに保存すべき理由

MetaのOrganizational Second Brainは、変化の速い組織の知識を、あらゆる修正、方針、専門家の判断をモデルの重みに組み込もうとするのではなく、明示的なファイルに保存することの有効性を強く示しています。Metaは専門家の知識を、人間とエージェントの双方が読み取れる構造化ファイルシステムに整理し、依存関係でリンクし、変更後にテストし、バージョン管理、レビュー、改善を行えるようにしています。基盤モデルが知性を提供し、ナレッジレイヤーが組織の学習内容を保持します。

これは、AIのメモリのあらゆる形態をMarkdownに保存すべきだという意味でも、RAGが時代遅れになったという意味でもありません。モデルの重みは一般知識を提供し、検索は断片的な参照資料に引き続き有用であり、進行中のタスク状態はデータベースやエージェントのランタイムに保存するのが適している場合があります。Metaが解決しようとしているのは、より限定的でありながら重要性を増している問題、つまり時間とともに変化し、出典情報を必要とし、どのモデルが利用しても維持されなければならない組織の知識を、いかに保存するかという問題です。

MetaのOrganizational Second Brainとは？

MetaのOrganizational Second Brainは、文書に分散したり専門家の頭の中に閉じ込められたりして、本来なら失われてしまう専門知識を取り込むために設計された社内AIエージェントアーキテクチャです。Metaはこのシステムを、汎用チャットボットではなく、特定分野の二次的な専門家として説明しています。

Metaの公式Organizational Second Brainアーキテクチャによると、このシステムは相互に依存する4つのレイヤーを組み合わせています。

重要なのは、専門家がエージェントを修正するたびにMetaがモデルを再トレーニングするわけではないという点です。修正は、外部のナレッジファイルや推論手順の変更として反映できます。

これにより、専門家との一度きりのやり取りによる一時的なチャット修正が、組織の恒久的な資産になり得ます。

なぜ何千もの文書はエージェントメモリと同じではないのか

文書でいっぱいのフォルダーはアーカイブです。システムが重要な点、情報源同士の関係、特定のルールや解釈を適用するタイミングを理解して初めて、エージェントの有用なメモリになります。

大規模な組織は、すでに膨大な量の文書資料を保有しています。ポリシー、仕様書、過去の判断、チェックリスト、報告書、プロジェクトメモ、標準、社内文書などです。問題は、最も価値のある知識が、こうした文書の間に存在していることが多い点です。

専門家は次のことを把握している可能性があります。

• 2つのルールが矛盾する場合、どのポリシーが優先されるか
• どの例外が特定の条件下でのみ適用されるか
• どの過去の判断が現在も有効か
• 組織が内部で使用している用語
• ケースがエスカレーションを必要とするほど曖昧な場合
• そして、一見似ている2つの状況をなぜ異なるものとして扱うべきなのか。

従来の検索システムなら原典の文書を見つけられますが、モデルはその解釈を毎回ゼロから再構築しなければならない場合があります。

Metaは、これを生の文書そのものを組織知として扱うことの弱点の一つだと説明しています。推論時にチャンクを繰り返し取得するエージェントは、その断片から組織の判断根拠を推測しなければならず、処理が遅くなったり、一貫性を欠いたりする可能性があります。

Metaは2026年初頭、すでに同様の問題に直面していました。以前に行った、部族的知識をエージェントのコンテキストファイルにまとめる取り組みでは、50を超える専門エージェントが4つのリポジトリにまたがる4,100以上のファイルを分析し、簡潔なコンテキストファイルを59個作成しました。Metaは、初期テストでタスクあたりのエージェントによるツール呼び出しが約40%減少したと報告しています。

教訓は似ています。生の情報を増やすだけでは、エージェントの挙動が自動的に向上するわけではありません。多くの場合、不足しているのは蒸留された構造です。

Metaがエージェントの知識を構造化ファイルに保存する理由

Metaは、1つの巨大な指示文書を維持するのではなく、200を超えるファイルを厳密な分類体系に整理しています。これらのファイルは、組織知のさまざまな種類と、異なるルーティング上の責任を表しています。

Metaは、ファイル間の関係を宣言するためにYAMLフロントマターも使用しています。ファイルには、そのファイルが何を depends_on また、どの他のファイルがそれを参照しているかも示せます。 referenced_by.

簡略化した例は、次のようになります。

---
type: position
topic: customer-data-retention
依存先:
  - data-classification.md
参照元:
  - privacy-review-recipe.md
適用条件:
  - customer_pii = true
---

# 顧客データの保持

## 見解
現在の組織の見解をここで定義します。

## 境界
その見解が適用される範囲と、適用されない範囲を記録します。

## 例外
既知の例外を列挙します。

## エスカレーションの条件
専門家によるレビューが必要なケースを説明します。

これはMetaの内部ファイルをそのまま写したものではなく、説明用の例ですが、プレーンな構造化ファイルが魅力的である理由を示しています。

これらの特徴があります。

• 人間にも読みやすい
• 機械可読で、
• 差分を簡単に確認でき、
• 相互参照しやすく、
• リンターを簡単に適用でき、
• バージョン管理でき、
• 個別に元に戻すことができます。

エージェントが変更を提案するときは、依存関係グラフも重要です。1つのポリシーファイルが変更された場合、システムは、その編集が孤立して存在すると仮定するのではなく、どの手順、インデックス、下流のルールが影響を受ける可能性があるかを特定できます。

MetaのセカンドブレインはRAGに取って代わるのか？

いいえ。Metaは、キュレーションされた知識レイヤーと検索の両方を意図的に維持しています。この2つは異なる情報上の課題を解決します。

Metaは、情報を密度と想定利用頻度に応じて区分しています。

キュレーションされたレイヤーには、エージェントが繰り返し必要とする可能性が高く、組織による自分たちの領域の進化する解釈を表す情報が保存されます。具体的なケースで必要になった場合は、疎な資料もセマンティック検索や字句検索によって利用できます。

これは、元祖のRetrieval-Augmented Generation研究で示された、より広範な区別とも一致します。この研究では、モデル内にパラメトリックに保存された知識と、必要に応じて取得できる明示的な外部の非パラメトリックメモリを区別しています。

Metaは実質的に、この両極の間にもう1つのレイヤーを加えています。

モデルの重み
汎用知能
        |
        v
整理済みの知識
ポジション
ルール
解釈
意思決定フレームワーク
        |
        v
RAG／検索
詳細な証拠
履歴記録
まれな参照情報
        |
        v
元データ

この区分を説明するなら、次のようになります。

RAGはエージェントがエビデンスを見つけるのに役立ちます。精選されたナレッジレイヤーにより、エージェントは組織の解釈を毎回ゼロから再発見せずに済みます。

AIエージェントは、知っていることと推論方法をなぜ分けるべきなのでしょうか？

Metaの最も重要な設計判断の一つは、宣言的ナレッジと手続き的推論を分離することです。

ナレッジファイルは、組織が知っている、または信じていることを説明します。Metaの「レシピ」は、エージェントが問題に取り組む方法を説明します。

この分離により、失敗の診断が容易になります。

エージェントが誤った結論に達した場合、メンテナは次の点を確認できます。

• 正しいナレッジは存在していたのでしょうか？
• 正しいファイルが読み込まれたのでしょうか？
• 組織上のポジション自体が間違っていた、または古くなっていたのでしょうか？
• それとも、推論手順が、本来は正しいナレッジを誤って利用したのでしょうか？

Metaによると、新たな組織上のポジションを追加する場合、推論レシピを変更せずに、ナレッジファイルを追加してルーティングインデックスを更新するだけで済むことがあります。逆に、基盤となるドメインの事実を書き換えずに、レシピを変更することで方法論上の問題を修正できます。

ナレッジベースが拡大するほど、このモジュール性の価値は高まります。

段階的開示によってMetaのトークン使用量が約80%削減された仕組みとは？

大規模なコンテキストウィンドウがあっても、情報アーキテクチャの必要性がなくなるわけではありません。モデルは技術的には数十万、あるいは数百万のトークンを受け入れられますが、すべてのポリシー、リファレンス、指示をあらゆるタスクで読み込むべきだという意味ではありません。

Metaの初期実装では、比較的フラットな指示構造とセマンティック検索が使われており、関連性が混在した大量の情報をコンテキストウィンドウに取り込む可能性がありました。

レシピシステムはパターンを段階的開示へと変えました。

旧来のアプローチ

タスク
  |
  v
大規模な指示セット
+ 多数の取得ソース
+ 幅広いドメインコンテキスト
  |
  v
モデル


段階的開示

タスク
  |
  v
ステップ1
ステップ1の指示とナレッジのみを読み込む
  |
  v
ステップ2
ステップ2の指示とナレッジのみを読み込む
  |
  v
ステップ3
必要な場合にのみエビデンスを取得

レシピ主導のステージに移行した後、Metaは、各クエリがナレッジシステムの小さく対象を絞ったサブセットにのみアクセスし、1ターンあたりの消費トークン数が約 80%.

これは、セカンドブレインによってAIの総コストが80%削減されたという意味ではありません。この結果が示しているのは、コンテキスト読み込み戦略を再構成した後の、ターンごとのトークン消費量についてです。

より一般的な教訓が重要です。

より良い問いは「モデルはどれだけ多くのコンテキストを保持できるか」ではなく、「このステップが問題を正しく解決するために必要とするコンテキストはどれだけ少ないか」です。

Metaは専門家のフィードバックをどのように永続的なエージェントメモリに変えるのか？

自己改善ループは、Metaのアーキテクチャでおそらく最も重要な部分です。知識を保存することは、時間が経っても正確さを維持することに比べれば簡単だからです。

Metaは、メンテナンスをコンパイルの問題として扱います。専門家による修正は、4つの段階を経ます。

1. 診断 フィードバックを分析し、根本原因を特定します。
2. コンパイル 問題を、検証済みの最小限の編集にまとめます。
3. 検証 変更によって問題が解決し、回帰が発生していないことを確認します。
4. レビュー 提案された変更を分野の専門家と確認します。

診断段階では、エラーが知識不足、誤った推論手順、または本当の曖昧さのいずれに起因するのかを特定します。

正しい答えがすでに元の資料に含まれていたにもかかわらずエージェントが失敗した場合、Metaはそれを方法論上の問題として扱います。必要な情報が欠けていた場合は、知識のギャップです。専門家同士の意見が一致しない場合は、システムに誤った確実性を埋め込むことを避け、上位にエスカレーションできます。

次に、コンパイル段階で最小限の編集が提案されます。Metaによると、別々のエージェントが、相互参照への影響、既存の見解との衝突、重複、トークン予算への影響、テストカバレッジなどの問題を調べます。

新たな敵対的レビュアーが、元の改善理由を知らない状態で提案された変更を受け取り、矛盾やエッジケースを見つけようとします。続いて決定論的な構造検証により、参照切れ、依存関係の循環、識別子の衝突、ファイルサイズの制約違反などの問題を確認します。

このプロセスは次のように要約できます。

専門家による修正
        |
        v
根本原因を診断
        |
        v
最小限の編集を提案
        |
        v
敵対的レビュー
        |
        v
構造検証
        |
        v
再実行＋回帰テスト
        |
        v
人によるレビュー
        |
        v
変更を反映
        |
        v
失敗をテストスイートに追加

修正が反映されると、最初に失敗したシナリオが回帰テストスイートの一部になります。そのため、今後の変更では、新たに修正された動作を維持する必要があります。

Metaは、リリースで説明されている6週間の開発期間中、改善サイクル全体で回帰がゼロだったと報告しています。また、以前は数日かかっていた個別評価が数分に短縮されました。これらはMeta社内での展開結果であり、独立したベンチマークではありません。

ファイルはなぜモデルの重みより更新しやすいのか？

変化の速い組織内知識では、ファイルによって変更内容が可視化されます。 これが見出しの根拠となる最も強い論拠です。

これは、モデル編集が不要または不可能だという意味ではありません。MEMITモデル編集研究などでは、Transformerモデル内部で事実の関連付けを直接変更する方法が探究されています。

Metaは、別のアーキテクチャ上の問いを投げかけています。

組織の知識が頻繁に変化し、人間が重要な更新をすべて確認する必要があるなら、そもそもなぜその知識をモデル内に入れるのでしょうか？

Metaによると、改善パイプラインの最終出力は、ドメインエキスパートがすばやくレビューできる差分です。より広い設計原則は、この複雑さを、バージョン管理でき、差分を確認でき、元に戻せるテキスト内にとどめることです。

そのため、知識の保守はモデルの再トレーニングよりも、ソフトウェア構成管理に近いものになります。

MarkdownとYAMLはAIエージェント向けのポータブルなメモリレイヤーになりつつあるのか？

Metaの設計は、人間とエージェントの双方が直接検査できる知識表現へ向かう、より広範な動きの一部です。

2026年4月、Andrej KarpathyはLLM Wikiパターンを公開しました。その発想は、クエリのたびに生のRAG結果から文書横断的な知識を再構築するのではなく、LLMに永続的な構造化Wikiを段階的に維持させるというものです。

重要なのは、蓄積されることです。

ソースA
   |
   v
構造化Wiki

ソースB
   |
   v
既存のページを更新する
関係を追加する
矛盾にフラグを付ける

ソースC
   |
   v
知識がより豊かになる
ゼロからやり直すことなく

GoogleのOpen Knowledge Format仕様は、相互運用性に向けて同じ考え方を推し進めています。OKF v0.2は、YAMLフロントマター付きのMarkdownファイルを格納したディレクトリを中心に構成された、意図的に最小限の形式を定義しており、中央のスキーマレジストリやプロプライエタリなランタイムを必要とせず、人間とエージェントの双方が読み取れます。

This suggests a potentially important direction:

これは、重要な方向性の可能性を示しています。

プレーンテキストのエージェント知識は、相互運用性のレイヤーになる可能性があります。

              組織にとって重要な知識が、あるプロバイダー独自のメモリシステム内に隠されるのではなく、明示的なファイルとして存在するなら、同じ知識レイヤーを理論上、異なるエージェントや異なるモデルで利用できます。
            KNOWLEDGE
                 |
       +---------+---------+
       |         |         |
       Markdown / YAML
    v         v         v
       |         |         |
       +---------+---------+
                 |
              Claude     Gemini     Qwen

AGENTS

モデルは交換可能になります。蓄積された知識まで交換可能にする必要はありません。

AIエージェントのメモリがファイルになったら、そのファイルはどこに保存すべきか？

エージェント知識が永続的なファイルの集合になると、新たなインフラ上の疑問が生じます。それらのファイルには、他の価値ある組織データと同じ保護が必要です。

• 本格的な知識レイヤーには、次のようなものが含まれる場合があります。
• 精選された見解、
• 専門家の判断、
• 分類体系、
• 推論レシピ、
• ルーティングロジック、
• 評価ケース、
• ソースドキュメント、
• 引用、
• エージェントが生成した改善、

その結果、LLMの規模とはほとんど関係のない要件が生じます。

これらの要件は、ワークステーション、プライベートサーバー、長期的なエージェント知識用のNAS、Gitリポジトリ、または管理されたクラウド環境で実装できます。Metaのアーキテクチャは、特定のストレージ製品を必要としません。

より大きなポイントは、エージェント知識が一時的なプロンプトコンテキストというより、長期的に維持されるデータ資産に近いものになり始めていることです。

なぜバージョン管理だけではAIメモリに不十分なのか？

Gitのようなバージョン管理は、差分、履歴、レビュー、ブランチ、論理的なロールバックを提供するため、構造化されたエージェント知識に非常に役立ちます。しかし、完全なデータ保護戦略ではありません。

バージョン管理が主に答えるのは、次の問いです。

何が変更されたのか？

ファイルシステムのスナップショットによる迅速な復旧は、別の問いに答えます。

不正な変更が行われる前の完全な作業状態を、迅速に復元できますか？

バックアップは別の問いに答えます。

元のストレージシステム自体が失われたり破損したりした場合、復旧できますか？

エージェントが自らの知識レイヤーを更新できるようになると、この違いはさらに重要になります。

不正な編集はGitで簡単に元に戻せるかもしれません。しかし、破損したリポジトリ、失われた添付ファイルのコレクション、破損したベクトルインデックス、誤って削除された元データのアーカイブ、または故障したストレージデバイスは、別の種類の問題です。

ナレッジベースが組織の運用の一部になるなら、その知識の保護は、単なるプロンプトエンジニアリングではなく、データインフラとして扱うべきです。

持続性のあるローカルエージェント知識スタックは、どのような構成になるのか？

実用的なエージェントメモリのアーキテクチャでは、インテリジェンス、整理済みの知識、検索、ソースデータ、保護を1つのレイヤーに押し込めず、分離できます。

AIモデル
Claude／Gemini／Qwen／その他
        |
        v
エージェントランタイム
ツール／ルーティング／セッション
        |
        v
整理済みの知識
ポジション
分類体系
レシピ
ルール
        |
        v
RAG／検索
インデックス
埋め込み
語彙検索
        |
        v
元データ
PDF
ドキュメント
コード
履歴記録
        |
        v
データ保護
バージョン管理
スナップショット
バックアップ

このアーキテクチャの利点は、独立性です。

モデルは、ナレッジベースを書き換えずに変更できます。検索エンジンは、元のソースを削除せずに変更できます。エージェントフレームワークは、専門家の判断を失わずに置き換えられます。ストレージハードウェアは、知識そのものの論理構造を変えずにアップグレードできます。

これは、現在のチャットボットがたまたま記憶している「コンテキスト」とするよりも、はるかに持続性の高いAIメモリの定義です。

Metaの「セカンドブレイン」は、AIエージェントのメモリの進む方向を示しているのか？

Metaのアーキテクチャは、AIエージェントシステムにおける長期的な資産が、モデルではなく知識レイヤーになる可能性が高まっていることを示唆しています。

モデルは今後も急速に進化し続けるでしょう。組織は、独自開発の最先端モデル、ローカルのオープンウェイトモデル、専門エージェント、またはこれら3つの組み合わせの間を移行する可能性があります。

組織知識は、異なる時間軸で変化します。

企業は何年もかけて、次のことを発見することがあります。

• どの手順が実際に機能するのか、
• どの例外が重要なのか、
• どの用語なら曖昧さを避けられるのか、
• どの過去の意思決定が今も関連性を持つのか、
• また、どの専門家の修正を二度と発見し直す必要がないようにすべきか。

推論モデルが変わったからといって、その知識が使い捨てになってはなりません。

Metaの設計は、ファイルベースのメモリが他のあらゆるメモリ技術に取って代わるものではないことも明らかにしています。より堅牢なアーキテクチャは、階層化されています。

汎用知能のためのモデル重み、維持管理される組織知識のための構造化ファイル、量の少ない根拠のためのRAG、方法論のためのレシピ、進行中のタスクのための実行時状態、そして永続性のためのバージョン管理とバックアップです。

その結果、AIの「Second Brain」についての考え方が変わります。

単にコンテキストウィンドウを大きくしたものでもありません。

PDFを大量に集めたフォルダーでもありません。

それは、単なるベクトルデータベースではありません。

そして、その知識が一つのモデルの中に永久に閉じ込められるものでもありません。

持続可能なSecond Brainとは、検査、修正、テスト、復旧が可能で、次のモデルに引き継げるよう維持された知識システムです。

モデルは来月には置き換えられるかもしれません。しかし、組織が何年もかけて築いた知識は、そのモデルとともに失われるべきではありません。

FAQ：Metaの組織向けSecond BrainとAIエージェントのメモリ

Metaの組織向けSecond Brainとは何ですか？

これは、専門的な組織知識を保持するためにMetaが構築した、社内向けのAIエージェントアーキテクチャです。構造化された知識ファイル、組み合わせ可能な推論レシピ、評価、そして基盤モデルを再訓練することなく、専門家の修正をテスト済みの更新へ変換する自己改善ループを組み合わせています。

MetaはAIエージェントのメモリをすべてMarkdownファイルに保存しているのですか？

いいえ。このシステムは、価値の高い組織知識のために構造化されたファイルベースの知識層を使用しつつ、量の少ない参考資料については意味検索と字句検索を維持します。モデル自体は引き続き汎用的な知能を提供し、その他の実行時状態は知識ファイルの外部に置かれる場合もあります。

MetaのSecond BrainはRAGに取って代わるのですか？

いいえ。Metaは、厳選した知識とRAGを意図的に組み合わせています。頻繁に使う立場、意思決定フレームワーク、解釈は構造化ファイルに集約し、詳細な仕様、過去の記録、めったに必要とされない根拠は検索で参照できるようにしています。

100万トークンのコンテキストウィンドウを使えばよいのでは？

コンテキストウィンドウが大きくても、無関係なコンテキストが無料で有用になるわけではありません。Metaは、段階的なプログレッシブ・ディスクロージャーにより、各推論ステップで必要な指示と知識だけを読み込めることを発見しました。これにより、以前のより広範な読み込み方式と比べて、1ターンあたりの消費トークンを約80%削減できました。

なぜ組織の知識をモデルの重みの外部に保持するのですか？

外部ファイルは、人間が確認、編集、引用、バージョン管理、差分確認、テスト、ロールバックを行いやすくなります。また、モデルプロバイダーを変更したり、基盤となるLLMをアップグレードしたりしても、組織は同じ知識を維持できます。

Metaの推論レシピとは何ですか？

レシピは、エージェントがタスクを分析する方法を定義する手順書です。知識ファイルとは意図的に分離されています。知識ファイルが組織の事実や見解を記述する一方、レシピはそれらを適用する際に用いる推論プロセスを記述します。

MetaのSecond Brainは専門家からどのように学習しますか？

専門家による修正は根本原因まで分析され、最小限の編集に変換されたうえで、敵対的検証と構造検証によって確認され、リプレイテストと回帰テストスイートでテストされます。その後、人間の専門家がレビューします。成功した修正は回帰テストスイートに追加され、今後の更新でも維持されるようにします。

ファイルベースのエージェントメモリは、ベクトルデータベースと同じものですか？

いいえ。ベクトルデータベースは主に検索の仕組みです。構造化された知識ファイルには、精選された解釈、ルール、依存関係、推論の境界、引用、人間がレビューした変更を保持できます。両者は併用できます。

同じ知識ファイルを異なるAIモデルで使用できますか？

可能性はあります。MarkdownやYAMLのようなモデルに依存しない形式は、周辺ツールがスキーマとルーティングルールを理解していれば、異なるエージェント実行環境で利用できます。ポータブルな知識形式が注目を集めている理由の一つです。

エージェントのメモリにはNASやホームサーバーが必要ですか？

必ずしもそうとは限りません。知識は、信頼性が高く、適切なアクセス権を設定できるストレージシステムであれば、どこにでも保存できます。共有可能で永続的なAI知識のためのローカルサーバーやNASは、ナレッジベースでスナップショット、大規模なソースアーカイブ、独立したバックアップも必要になる場合に役立ちます。