Company Brain とは何か：企業コンテキストの四層インフラ

Company Brainの第一の目的は、企業知識を正確に保つこと

Company Brainは、その定義が急速に変化している段階にあります。Sliteが回答者にその理解を尋ねたところ、53%が「継続的に更新される知識ベース」、18%が「チームの活動によって自動的に維持されるWiki」、13%が「ツール横断的なAI検索」、12%が「エージェントの記憶層」、そして4%が「分からない」と回答しました。

出典元画像 · Slite Company Brain Survey 2026対象：149名の回答者。公開ページに調査手法の記載なし

Sliteは最初の二つの回答を合わせて、「71%のチームがまず知識の正確さを期待している」としています。この統合には編集上の判断が含まれていますが、この資料の核心を的確に捉えています。Company Brainの第一の役割は、組織の知識を信頼できるものにすることであり、エージェントはその要求を、よりリスクの高い実行環境へと押し上げる存在にすぎません。 もし、あるシステムが複数の場所から回答を検索できたとしても、その回答の出典、更新日時、誰が修正できるのかを説明できなければ、それは依然として単なる検索レイヤーに過ぎません。

この書籍では、いくつかの類似概念についても遡って解説しています。個人の「セカンド・ブレイン」、エンティティとリレーションシップで業務コンテキストを整理するContext Graph、モデルによって生成・更新されるWiki、オープンソースのGBrain、そしてY Combinatorが起業の方向性として提唱するCompany Brainなどです。特にYCの公開している定義は明確で、それは生の企業データと信頼できるAI自動化の間に位置し、知識の抽出、整理、更新を行い、エージェントがこのコンテキストを利用できるようにするものとされています。

これらの説明を整理すると、ベンダーに依存しない、実用的な定義を導き出すことができます。

Company Brainとは、組織レベルのコンテキストを扱う基盤です。それは、仕事に関するシグナルを継続的に取り込み、それを遡って検証可能な共有記憶へと整理し、陳腐化、競合、権限を処理した上で、人またはエージェントに対して、回答と実行可能なコンテキストを提供します。

この定義は、「単なるAI知識ベース」と比較して、メンテナンスのループとマシンによる呼び出しという二つの重要な条件を追加しています。また、「Agent Memory」よりも広い概念です。なぜなら、それは特定のエージェントの会話履歴ではなく、組織としての事実を保持するものだからです。

知識の分散はなくならない。エージェントは古いドキュメントのコストを増幅させる

従来の知識管理は「単一の情報源」を約束することが多いですが、現実には、垂直型SaaSが増えれば増えるほど、知識は分散します。Sliteのサンプルでは、83%が専用の知識ベースを、79%が二つ以上のシステムを併用し、64%が共有ドライブを、56%がSlackやTeamsに依存し、30%が今でもメールに依存しています。これらの割合は複数回答を許容している可能性がありますが、書籍には設問の原文が掲載されていません。

出典元画像 · Slite Company Brain Survey 2026対象：149名の回答者。公開ページに調査手法の記載なし

分散自体は必ずしも失敗を意味しません。CRMは顧客の状態を保存するのに適していますし、チケットシステムは問題の処理状況に、チャットは迅速な調整に、デザインツールは創造的なプロセスを保存するのに適しています。真の問題は、同じ事実が、更新頻度、権限、ライフサイクルが異なる複数のシステムに分散して存在しているのに、組織はそれらの関係を継続的に処理する仕組みを通常持っていない、という点にあります。

ドキュメントは、よく知られたサイクルをたどります。誰かがルールを書き、チームが使い始めます。しかし、現実が変化しても、ページは更新されません。読者は次第に信頼を失い、チャットや新しいドキュメントで改めて説明し直すことになります。こうして知識ベースはどんどん蓄積されていく一方で、信頼できる知識はますます見分けにくくなっていきます。

人間はこのような混乱に直面すると、暗黙の判断で穴を埋めることがよくあります。私たちは日付を確認し、作成者を特定し、トーンがおかしいと気づいたり、直接同僚に尋ねたりします。エージェントには、このような組織に関する暗黙の常識が備わっていません。エージェントは、検索で上位に表示された古いページを権威があるものと誤認し、地域、顧客ランク、有効日などの情報が欠落したルールを使って、見積もりを生成したり、顧客に返信したり、バックエンドの操作を実行したりする可能性があります。

出典元画像 · Slite Company Brain Survey 2026対象：149名の回答者。公開ページに調査手法の記載なし

同じ質の低い知識であっても、人間にとっての結果は「確認にあと十分かかる」程度かもしれませんが、自動実行システムにとっては「同時に数百人の顧客に対して誤った対応をする」という結果になりえます。したがって、Company Brainには、自動化システムのリスクを管理する役割が求められます。つまり、出典、時間、権限、信頼性の限界は、回答と一緒に実行チェーンに組み込まれなければなりません。

人間がまずコンテキストを組み立てる負担を減らし、それからエージェントを安全にバックグラウンドへ

Sliteの調査では、企業がエージェントにのみサービスを提供したいと考えているわけではないことが示されています。回答者の4%は自分のためだけに回答を得たいと考えており、34%は自分とチームのために、54%は人とエージェントの両方のために、そしてわずか7%だけがエージェントのためだけにサービスを提供したいと考えています。書籍ではこれらの最初のいくつかのカテゴリを合計し、約九割のニーズが依然として人間による利用シーンを含んでいると強調しています。

出典元画像 · Slite Company Brain Survey 2026対象：149名の回答者。公開ページに調査手法の記載なし

人間にとって、Company Brainが削減するのは、各タスクの開始時にかかる「コンテキスト収集のための負担」です。新人は五つのツールを行き来してプロジェクトの履歴を再構築する必要がなくなります。営業担当者は製品ルールを尋ねて回る必要がなくなります。エンジニアは、特定のアーキテクチャ決定の根拠を見つけることができます。部門をまたいだコラボレーションは、「誰が覚えているか」に依存することが少なくなります。このようなメリットは派手ではありませんが、あらゆるエージェント自動化の基盤となるものです。

エージェントにとって、リスクは自律性が高まるにつれて増大します。チャットアシスタントが間違えた場合、人はまだループの中にいます。しかし、コーディング、カスタマーサポート、営業、コンテンツを作成するエージェントは、成果物を作り始めます。運用、人事、知識メンテナンスを行うエージェントは、システムの状態を変更します。バックグラウンド環境で動作するエージェントは、無人で継続的に行動するため、完全なコンテキスト、権限の境界、異常時のエスカレーションメカニズムに対する要求が最も高くなります。

すべてのエージェントが必要とする「会社の資料」が同じであるとは限りません。コーディングエージェントは、アーキテクチャの決定、障害記録、内部の取り決め、そしてなぜそのようなアプローチを取ったのかという背景を必要とします。それがなければ、技術的には正しくても、チームの暗黙のルールをすべて破るようなコードを書く可能性があります。カスタマーサポートエージェントは、既知の問題、ポリシーの境界、トーンに関するガイドラインを必要とします。そうでなければ、誤った回答が大規模に顧客に送信される可能性があります。営業エージェントは、価格設定ルール、過去の取引、現在のポジショニングを必要とします。そうでなければ、無断で値引きをしたり、二四半期前の情報を使って話をする可能性があります。コンテンツエージェントは、すでにリリースされた機能とロードマップを区別できなければなりません。知識メンテナンスエージェントは、どの事実が古くなりつつあるかを認識する必要があります。

バックグラウンドエージェントには、これらの要件がすべて重なり、しかもその場に異常を検知する人間がいません。したがって、Company Brainは、単に「関連するテキスト」を返すだけでなく、タスクに応じた正しい知識のスライスを提供し、出典、権限、時間、競合状態を保持する必要があります。

出典元画像 · Slite Company Brain Survey 2026対象：149名の回答者。公開ページに調査手法の記載なし

ここでサンプルの偏りに注意する必要があります。Sliteの回答者の中で、57%が自社のエージェントまたはスキルファイルをすでに導入しており、そのうち25%が自分たちを「エージェントネイティブ」と表現しています。また、23%は主にAIをチャットツールとして使用しています。このようなサンプルは、一般的な企業よりもはるかにエージェントの最前線に近く、マシンが呼び出し可能な知識に対する需要を誇張することになります。これは、初期導入者が何を懸念しているかを示すものですが、すべての企業が同じ段階に達していることを証明するものではありません。

四層アーキテクチャ：シグナル、記憶、整理、呼び出し

この書籍で最も有用な部分は、様々な製品名を排除した後に、四つのシステム上の問題が浮かび上がってくる点です。どのようなCompany Brainであっても、それがMarkdown、知識ベース、ベクターデータベース、ナレッジグラフのいずれを使用していても、この道筋から逃れることはできません。

第一層は、シグナルの取得です。 情報は、業務システムから定期的に取得することも、イベント発生時にプッシュすることも、エージェントが作業のサマリーを書き込むことも、クエリ時にリアルタイムで読み取ることもできます。定期的な同期はカバレッジは安定していますが、遅延が生じます。イベントキャプチャは新鮮ですが、ノイズが発生しやすくなります。クエリ時の読み取りは最もタイムリーですが、外部インターフェースの速度、権限、レート制限の影響を受けます。

第二層は、記憶の形成です。 プレーンファイルは透過的でバージョン管理が可能です。ドキュメント知識ベースは人間にとって使いやすく、ベクターインデックスは意味的な類似性に優れ、ナレッジグラフはエンティティ間の関係と時間の変化に優れています。どのストレージも、それ自体が「会社の真実」とイコールになるわけではありません。選択肢によって、システムがどのような質問に答えられるかが決まり、権限の継承、移行、メンテナンスの難易度も決まります。

第三層は、整理とメンテナンスです。 これは、「RAGを接続すれば完了」とするほとんどのアプローチに欠けている層です。一般的なメカニズムとしては、定期的な統合、時間減衰、ドリフト検出、競合フラグ、手動レビューのキューなどがあります。この層は、何がまだ有効で、何が置き換えられ、何が責任者の確認を必要とするのかを継続的に判断します。

第四層は、呼び出しです。 人間はチャット、検索、引用、読みやすい説明を必要とします。エージェントは安定したAPI、MCP、専用ツールを必要とし、権限が不足している場合、出典が競合している場合、または信頼性が不十分な場合には停止する機能も必要とします。答えが見つかることと、それを実行しても良いということは別問題です。

四つの層の間には、「一度完了したら終わり」という矢印はありません。呼び出しの結果は知識のギャップを明らかにし、そのギャップは取得とメンテナンスのキューに戻されるべきです。メンテナンスは、次の呼び出しの質を決定します。Company Brainを閉ループとして捉えることで、真のコストセンターが見えてきます。

{{related:related-context-engineering}}

十の実装例が示すもの：唯一の技術的な道筋など存在しない

電子書籍に記載されている実装例は、オープンソースプロジェクト、メモリSDK、垂直製品、社内システム、極めてシンプルなDIYまで多岐にわたります。それらの共通点は非常に少なく、Company Brainが特定のデータベースやインターフェースによって独占されるものではないことを証明しています。

GBrainはMarkdown/Gitを記録層として使用し、PGLiteまたはPostgres/pgvectorでインデックスを構築し、夜間の「dream cycle」で関係性と参照をメンテナンスします。mem0は、アプリケーションから送信される会話から保存する価値のある事実を抽出し、ベクターとエンティティシグナルの両方を検索に使用します。Lettaは、エージェントがコンテキスト内メモリ、外部アーカイブ、完全なメッセージ履歴を管理できるようにし、バックエンドエージェントが共有メモリを整理します。Zep/Graphitiは、時間を考慮した知識グラフを重視します。新しい事実が古い関係を陳腐化させ、単に削除するのではありません。

他のいくつかのアプローチは、人間による承認をより重視しています。Sylphは、GitツリーをそのままBrainとして扱い、エージェントによる変更はまずドラフトとして作成され、レビュー後にマージされます。Claude Code + Gitを用いたDIYアプローチは、CLAUDE.md、ルール、スキルファイル、runbookで知識層を構成し、圧縮と更新はエンジニアとPRを通じて行われます。Carraraは、Postgres内の共有メモリをローカルアプリケーションに複製し、各メモリは人によって承認されます。

垂直システムは、「会社」を特定の作業領域に縮小します。Pletorはブランドルール、クリエイティブなリファレンス、効果データを整理します。Gorgias Cortexは、多数の型付きMarkdownノードを接続してカスタマーサポート知識を構築し、会話のトラジェクトリからギャップを発見します。Slite Agentは既存のドキュメントを基盤とし、責任者、検証ラベル、有効期限ウィンドウ、引用付き回答、MCPを追加します。最後の項目はベンダーによる自己申告であり、今回の調査ではこれらの製品の現在の動作を独立にテストしたわけではありません。

十のサンプルを比較する際には、まず次の四つの点を確認する必要があります。何を取り込むことができるのか、何を記憶とみなすのか、更新を誰が承認するのか、回答がどのように作業に組み込まれるのか。技術的な違いは最終的には責任の所在に収束し、技術用語自体はむしろ二次的なものになります。

Build or buyの本当の分かれ目は、誰がこのコンテキスト層を永続的にメンテナンスするか

Sliteによれば、サンプルの中で「実際に機能する」Company Brainをすでに保有しているのはわずか17%でした。回答者の主な懸念事項は、回答の正確性77%、権限とプライバシー63%、メンテナンスの負担58%、日常的な取り込みとメンテナンスのコスト58%、セットアップ作業33%となっています。これらの数字は、このサンプル内での優先順位を比較するのには適していますが、市場規模や一般的な発生率を計算するのには適していません。

すでに構築を試みている人々の中で、Sliteによれば、約半数がClaudeまたはCodexを使用して知識ベースに接続するカスタムソリューションを採用し、約五分の一がGBrainを使用しています。電子書籍には、このグループの比率の正確な母数と調査方法が記載されていません。これは、回答した初期導入者が自分たちで制御できる技術的な道筋を好むことを示すものですが、自社構築のソリューションが市場で主流であることを証明するものではありません。

書籍では、市場を二つの軸で描いています。一つは、Company Brainが業務アプリケーションとは独立した層なのか、それとも特定の製品の付随機能なのかという軸です。もう一つは、それを企業自身がメンテナンスするのか、ベンダーに任せるのかという軸です。これにより、四つのカテゴリが形成されます。自社ホスト型の独立層、ベンダー管理の専門製品、企業がメンテナンスするメモリSDK、そして大規模スイートに組み込まれベンダーがメンテナンスする機能です。

出典元画像 · Slite Company Brain Survey 2026ベンダーによる市場分類であり、独立したベンチマークではありません

この四象限には明らかにSliteの立場が反映されていますが、非常に本質的な問いを投げかけています。あなたはソフトウェアを購入しているのか、それとも組織のコンテキストのメンテナンス権を永久に外部委託しているのか。 自社構築は「ベクターデータベースを立ち上げる」こと以上の意味を持ちます。それは、コネクタ、権限マッピング、検索評価、競合処理、手動レビュー、コスト最適化に長期的に関与することを意味します。しかし、製品を購入してもこれらの作業がなくなるわけではなく、誰がそれを行うのか、企業がプロセスをどの程度可視化できるのか、そして離れるときに何を持ち出せるのかが変わるだけです。

元のページにある選択ツールは、判断を三つの変数に単純化しています。チームの規模、最も懸念する点（誤った回答／権限／メンテナンス／コストのいずれか）、そして内部の担当者が技術的な能力を持っているかどうかです。このフレームワークは製品リストよりも有用です。エンジニアリング能力を持つ小規模チームで、主にコストに制約されている場合は、自社ホストがより実現可能です。規模が拡大し、権限が複雑になり、メンテナンスを担当する人がいない場合は、専門製品の方が現実的な利点があります。Memory SDKは、特定の製品やエージェントに記憶を追加するのに適していますが、それが自動的に全社的な共有コンテキストになるわけではありません。ページはまた、これらの回答に基づいてマッチングのパーセンテージを計算しますが、検証方法は公開されていないため、これらの数字はSliteが作成した選択のためのヒューリスティックであり、効果の確率を示すものではありません。

Sliteは、後者の一連の問いを「コンテキスト主権」と呼んでいます。Company Brainが真に複数の業務システムにまたがる場合、それはどの単一のSaaSよりも完全な会社の全体像を徐々に形成していきます。企業は少なくとも三つのデューデリジェンスを実施すべきです。

1. 元の記憶を完全にエクスポートできるか？ 回答だけでなく、出典、バージョン、関係性、権限に関するメタデータもエクスポートできる必要があります。
2. モデルと呼び出し層を交換できるか？ 知識構造が特定のモデルやスイートにのみ対応している場合、切り替えコストは増大し続けます。
3. 上位プラットフォームがAPIを制限した場合、どうなるか？ Slackは2025年、一部の非Marketplaceアプリに対して、履歴メッセージAPIを毎分一回、最大15件に制限し、外部インデックスのための無制限なバルク抽出に反対する姿勢を明確にしました。クエリ時の取得に依存するアプローチは、このようなプラットフォームの境界に直面する必要があります。

独立層には戦略的な魅力がありますが、唯一の正解として位置づけることはできません。小規模なチームであれば、スイートに組み込まれた機能の方が適しているかもしれません。規制対応や高度なカスタマイズが必要な場面では、自社構築が必須となるでしょう。専門ベンダーは、運用や権限管理の面でより成熟している可能性があります。この電子書籍には、正確性、総所有コスト、ROI、クロスベンダーのベンチマークが含まれておらず、どのカテゴリが普遍的に優れているかを証明することはできません。

ビルダー間で四つの合意はあるが、四つの疑問は未解決のまま

Sliteがまとめた最近の合意事項は、かなり慎重な内容です。カンパニーブレインは恒久的なメンテナンスが必要だということ。現時点では、AIが人間のレビューなしに企業知識を恣意的に書き換えるべきではないということ。知識のキャプチャは、仕事のプロセスの副次的な結果であるべきだということ。そして、エージェントが生成するクエリ数は人間よりもはるかに多くなるため、権限、コスト、可観測性はすべて、マシンのスケールに合わせて設計する必要があるということです。

「恒久的なメンテナンス」という前提は、技術的なアプローチがいまだに急速に変化していることに由来します。本書で調査されたシステムは、五種類のリランカーと三つの検索アプローチを採用していますが、共有されたベンチマークはありません。ナレッジグラフの必要性についても、コンセンサスは得られていません。Zepは時間グラフを中核に据え、Gorgiasは約12,000の型付きノードを構築しましたが、SliteとLettaはグラフを採用していません。Gorgiasのアーキテクチャに関する記事は、公開されてから本書のインタビューを受けるまでの間に、すでに時代遅れになっていました。そのため、自社構築チームが担うのは、継続的なプロダクト開発業務です。収集、検索、権限管理、評価、デバッグ、ガバナンスに、長期的に責任を持つ担当者が必要です。

知識の書き戻しについては、実行可能ないくつかの人間によるレビューパターンが確立されつつあります。Pletorは修正提案を修正受信箱に置きます。Gorgiasでは、グラフの修正はPRレビューを通過する必要があります。Sylphのエージェントはドラフトを提出することしかできず、正式な知識に昇格させることはできません。SliteはAgent Triageを使用して提案された更新を表示します。これらはすべて同じリスク、つまり、あるテキストが部分的な計画なのか、議論中のアイデアなのか、それともすでに発効した会社の決定なのかを、エージェントが判断するのが難しいというリスクに対処しています。誤った情報が共有メモリに直接入り込むと、その後の検索で繰り返し呼び出され、徐々に増幅される可能性があります。

キャプチャも、従業員が思い出してからドキュメントを書くことに依存することはできません。nao Labsは各エージェントスキルの最後にログステップを追加し、知識の蓄積をタスク完了の一部にしています。Gorgiasは毎晩会話の軌跡を分析して、ナレッジグラフに欠けているものを探します。Sliteは接続されたツール内のアクティビティを監視し、更新を提案します。これら三つのアプローチは、タスク後の記録、失敗した軌跡からのギャップの推測、作業イベントからのシグナルキャプチャに対応しており、いずれも進行中の作業に合わせてメンテナンスを調整することを目的としています。

呼び出し口も変わりつつあります。mem0、Guru、SliteはすでにMCPサービスを提供しており、Gorgiasも内部のBrainをコードファーストのチームに公開しています。エージェントは人間のようにナレッジベースを開いて検索する必要はありません。各タスクの開始前に自動的にコンテキストをクエリします。クエリが人間の偶発的な動作から機械の日常的なステップに変わると、キャッシュ、権限チェック、呼び出しコスト、失敗ログ、異常停止はすべて、より高い頻度で設計する必要があります。

難しい問題は、組織が知識をどのように定義するかに集中しており、モデルがさらに多くのテキストを検索できるかどうかではありません。従業員とClaudeやChatGPTとの会話には、最も凝縮された推論プロセスが保存されていることがよくありますが、公開したくない試行錯誤や議論、個人的な判断が含まれる可能性もあります。これらをすべて除外すると、組織は多数の意思決定コンテキストを失うことになります。デフォルトで共有Brainに取り込むと、プライバシーと承認の境界を越えてしまうことになります。

競合するバージョンを単純にマージすることもできません。マーケティングチームとセールスチームは、同じポジショニングについて、それぞれのシナリオでそれぞれが正しいと考えるかもしれません。モデルが自動的に、より声の大きい方や、ドキュメントの更新日が新しい方を保持する場合、実際には組織に代わって立場を選択していることになります。現在のソリューションは、最終的に信頼できる個人による裁定に依存することが多く、その個人がメンテナンスのボトルネックであり、単一障害点にもなります。カンパニーブレインは、「誰が、どの範囲で、それが有効であると考えるか」を表現する必要があり、単に確からしい答えを残すだけでは不十分です。

本書のビルダーの一人は、業務知識の約80%は依然として人の頭の中にあると判断しています。この数字には独立した研究方法がなく、インタビュー対象者の見解としてのみ扱うべきです。これは、カンパニーブレインの一つのハードな限界を指し示しています。システムは、自分が観察でき、承認でき、レビューできる知識のみを管理できるのです。

文書化されていない部分については、すでにある試みが現れています。Ontoraは、構造化されたAI主導のインタビューで従業員に掘り下げた質問をし、経験の背後にある理由をBrainに整理します。これにより、問題は「どのシステムを接続するか」から「これまでシステムに入ったことのない知識をどのように得るか」へと前進します。しかし、情報源は、この方法がまだスケーラビリティ、レビュー負担、従業員の受け入れを解決していないことも認めています。

したがって、カンパニーブレインの最も合理的な導入開始点は、エラーのコストが制御可能で、情報源の境界が明確な作業領域です。まず、四つの疑問に一つずつ答える必要があります。シグナルはどこから来るのか、誰が確認を担当するのか、権限はどのように継承されるのか、記憶は移行できるのか。システムがこれらの問いに答えられない場合、検索がどれほど賢くても、古い知識をより速く人間やエージェントに届けるだけです。