FDX株式会社
Strategy

Company Brain​（カンパニーブレイン）とは？​企業の​AI知識基盤

Company Brain（カンパニーブレイン）とは、社内に散在する知識を構造化し、人間とAIエージェントが同じ事実の源として参照できる企業AI知識基盤。導入の要点と主要3製品の違いを解説します。

··FDX株式会社 編集部·監修: 佐藤 拓哉（生成AI協会 理事）
Company Brain のレイヤー構造図。下から「散在する社内データ（Slack・ドキュメント・チケット・DB・人の頭の中）」→「コネクタ層」→「構造化・ナレッジグラフ層（権限境界つき）」→「Company Brain（事実の源）」→「人間とAIエージェントが同じ知識を参照」の5層を縦に積み上げて示す。

要点（100字）：Company Brain​（カンパニーブレイン）とは、​社内に​散在する​知識を​吸い上げ・構造化し・常に​最新化し、​人間と​AIエージェントが​同じ​「事実の​源」と​して​参照できる​企業AI知識基盤です。​AI自動化を​阻む​最大の​ボトルネックが​モデル品質ではなく​ドメイン知識に​なった​今、​その​欠けた​レイヤーを​埋める​基盤と​して​注目されています。

この​​記事の​​対象読者

Company Brainとは​​（要点3行）

  1. Company Brainは「企業の脳」にあたる知識基盤である。​社内に​散らばった​知識​（人の​頭の​中・Slack・チケット・ドキュメント・DB）を​吸い​上げ、​構造化し、​常に​最新の​状態に​保つ。​単なる​検索でも​チャットボットでもない。
  2. 目的は人間とAIエージェントが同じ「事実の源」を共有することに​ある。​ドキュメントを​"保管"する​ナレッジベースと​違い、​Company Brainは​実態との​ズレ​（ドリフト）を​検知して​能動的に​"維持"する。
  3. 2026年にY Combinatorが「AI自動化に欠けた基本部品（primitive）」と名指しした​ことで​概念が​主流化した。​AI実装の​最大の​ボトルネックが​「モデル品質」から​「ドメイン知識」へ​移った​ことの​裏返しである。

な​​ぜいま​「企業の​​脳」なのか — ボトルネックの​​移動

生成AIの​導入が​一巡し、​多くの​企業が​同じ壁に​ぶつかっている。​モデルは​十分賢いのに、​自社の​業務では​期待ほど​使えない。​原因は​モデルの​性能ではなく、​AIが​「その​会社の​ことを​何も​知らない」ことに​ある。

返金処理の​判断基準、​価格例外を​誰が​どう​決めるか、​インシデント時に​エンジニアが​どう​動くか。​こうした​業務の​リアルな​知識は、​ドキュメントに​整然と​書かれてはいない。​人の​頭の​中、​古い​メールスレッド、​Slackの​会話、​サポートチケット、​データベースに​断片と​して​散らばっている。​熟練者は​これを​暗黙の​うちに​繋いで​判断できるが、​AIエージェントは​この​状態のままでは​動けない。

この​構造を、​Y Combinatorは​2026年の​Requests for Startups​（著者Tom Blomfield）で​明確に​言語化した。

「すべての企業をAI自動化で動かしたいなら、新しい基本部品（primitive）が必要だ。それがCompany Brainである」

「企業内の​AI自動化を​阻む​最大の​ボトルネックは、もは​やモデル品質ではなくドメイン知識だ」

つまり​Company Brainとは、raw company data（生の社内データ）とreliable AI automation（信頼できるAI自動化）の間に欠けていたレイヤーを​指す。​AIを​賢く​するのではなく、​AIに​「自社の​ことを​正しく​知らせる」​ための​基盤である。​これは​PoCが​本番化で​止まる​「死の​谷」の​正体​その​ものでもある​（参考：AI PoCが​失敗する​5つの​構造的理由）。

ナレッジベースとの​​決定的な​​違い​​ — ​「保管」ではなく​​「維持」

Company Brainを​「社内Wikiの​AI版」と​捉えると​本質を​見誤る。​両者の​違いは​一文で​言い​切れる。

ナレッジベースは文書を保管する。Company Brainは文書を能動的に維持する。

Wikiや​ドキュメントDBは、​PRが​マージされた​瞬間、​規程が​改定された​瞬間、​組織が​再編された​瞬間に​陳腐化する。​そして​「誰も​対応する​ドキュメントを​更新しない」。​これが​社内ナレッジが​死蔵される​普遍的な​理由だ。

Company Brainは​次の​4つの​性質で​これを​解く。

  1. 自動で最新化する — GitHub / Slack / Linear / Notionなどと​同期し、​「今この​瞬間に​何が​事実か」を​反映し続ける。
  2. 実態にグラウンディングする — 古い​手順書ではなく、​現状の​システム・コードベース・​運用に​根拠を​置いて​回答する。
  3. 組織の記憶を保全する — 退職・異動・組織再編・記憶の​風化を​超えて、​institutional knowledge​（組織知）を​残す。
  4. 人間とAIの共通の源になる — 人間も​AIエージェントも、​同じ​ナレッジグラフ・​同じ​定義を​参照する。

差は​「図書館」と​「司書」の​差だ。​図書館は​本を​並べておくだけだが、​司書は​中身を​最新に​保ち、​問いに​対して​正しい​棚へ​案内する。

Company Brainを​​支える​​アーキテクチャ5要素

Company Brainのレイヤー構造

技術的には、​Company Brainは​ エンタープライズRAG（検索拡張生成） を​土台に、​企業利用に​必要な​層を​積み上げた​ものと​して​実装される。​エンタープライズRAGとは​「基本RAG + コネクタ + 権限 + 評価 + 可​観測性 + ガバナンス」だ​（RAG/エージェント実装の​基礎は​ AIエージェント完全ガイド を参照）。

1. データコネクタ — 散在する​​知識を​​集める

100以上の​SaaS / オンプレソース​（Slack, Google Drive, Confluence, Jira, GitHub, Salesforce, ServiceNow, Notionなど）と​接続し、​差分同期で​最新化する。​コネクタの​網羅性が、​そのまま​Company Brainに​「見える​知識」の​範囲を​決める。

2. ベクトル検索 — 意図を​​汲む

キーワード一致を​超え、​意味で​検索する。​従来の​社内検索が​「暗黙知」や​「意図」を​汲み取れなかった​壁を​越える​層だ。

3. ナレッジグラフ / GraphRAG — 知識を​​つなぐ

人・文書・概念の​関係性を​捉える。​複数の​文書を​またぐ​問い​（​「この​顧客の​契約条件と​過去の​インシデントと​現在の​請求状況」）に​強い。​Microsoftの​GraphRAGが​先行実装し、​Palantirは​これを​後述の​「オントロジー」と​して​徹底している。

4. 権限境界​（permissions-aware）​​— 最重要

検索の​段階で、​アクセス権の​ない​情報を​構造的に​除外する。​Company Brainの​成否を​分ける​核心であり、​日本企業では​特に​重い​要件に​なる​（後述）。

5. エージェント化 — 検索から​​実行へ

ここが​Company Brainと​単なる​「社内検索」を​分ける​最前線だ。​知識基盤の​上に、​適応的な​プランニングと​並列サブエージェントを​載せ、検索 → 回答 → 根拠付け → 業務の自動実行へと​射程を​伸ばす。​Y Combinatorの​定義が​「知識を​AIが​実行可能な​skills fileに​変換する」と​述べたのは、​まさに​この​段階を​指している。

検索から実行へ

参考：エンタープライズRAG市場は​2025年の​約19.4億ドルから​2030年に​約98.6億ドル​（年平均成長率38.4%）​へ​拡大すると​予測されている。​Company Brainは​この​市場の​"出口"に​あたる​上位概念だ。

主要プレイヤー3社の​​違い​​ — 同じ​​「企業の​​脳」でも​​思想が​​違う

「Company Brainを​作る」と​言っても、​出発点の​違いで​製品の​思想は​まったく​異なる。​代表的な​3系譜を​押さえておけば、​ベンダー選定の​軸が​ぶれない。

観点GleanMicrosoft 365 CopilotPalantir AIP / Foundry
思想フェデレーテッド型​（知識は​多数システムに​分散している​前提）スイート​埋め込み型​（M365内で​完結）オントロジー型​（現実の​デジタルツインを​作る）
中核権限対応ナレッジグラフ + 100+ コネクタMicrosoft GraphOntology​（意味論レイヤー）
得意全社​横断で​「見つける​・理解する」M365内で​「作る​・処理する」「意思決定と​アクション実行」
範囲ベンダー非依存Microsoftエコシステム内データ統合 + 運用実行
位置づけ知識発見の​代名詞生産性レイヤー実行基盤の極北

Glean — カテゴリの​​代名詞

「組織の​知識は​1つの​スイートではなく​多数の​システムに​分散している」と​いう​前提に​立つ。権限対応のナレッジグラフを​中核に、​60以上の​シグナルを​マッピングし、​引用付きで​回答する。​市場の​検証も​急で、​ARRは​2025年1月期の​約1億ドルから​2025年12月に​約2億ドルへ​9ヶ月で​倍増、​2025年6月には​評価額72億ドルで​Series F​（1.5億ドル）を​調達した。​Company Brainと​いう​言葉を​市場に​広めた​立役者でもある。

Microsoft 365 Copilot — スイート内の​​生産性レイヤー

M365に​埋め込まれ、​Microsoft Graphで​動く。​Gleanが​「全社から​情報を​見つける」のに​対し、​Copilotは​「Microsoftアプリ内で​情報を​作る」。​性質が​違う。​ただし採用には​壁が​あり、​ある​分析では​ Copilotパイロットのうち大規模展開に進んだのは6% にとどまると​いう。​理由は​シンプルで、​「Copilotが​組織の​知識の​大半​（M365の​外）を​見られないから」だ。​Company Brainの​本質が​「エコシステムを​越えて​全社の​知を​束ねる​こと」に​あると​示す、​逆説的な​事例と​いえる。

Palantir AIP / Foundry — オントロジー型の​​極北

中核は Ontology（オントロジー）。​組織の​データ宇宙を​「Employee」​「Purchase Order」​「Aircraft」と​いった実世界の概念（名詞）+ それを操作するアクション（動詞）+ 関係性 + ビジネスロジック + 粒度の細かいセキュリティと​して​表現する。​Palantirは​これを​「企業の​現実の​デジタルツイン」と​呼ぶ。​データが​入ると​ontologyオブジェクトに​整形され、​それが​AIの​推論コンテキストに​なる。​Gleanが​「知識の​発見」なら、​Palantirは​「知識に​基づく​意思決定と​実行」。​Company Brainの​"実行可能"側の​到達点だ​（Palantirの​組織モデルは​ Palantir / OpenAI / Scale AIに​見る​FDEモデルの​実態 でも詳説）。

Company Brainが​​もたらす価値

用途は​広い。​HR / 規程アシスタント、​ITヘルプ（チケット・runbook・ポストモーテム横断）、​法務 / 財務コパイロット​（条項・統制の​正確な​引用）、​現場運用​（マニュアル・保全ログ・安全速報）。​正しい​社内知識に​基づく​回答が​価値を​生む業務なら、​ほぼ​すべてが​対象に​なる。

失敗パターンと​​リスク — ​「データ基盤」を​​甘く​​見た​​企業から​​落ちる

Company Brainは​万能ではない。​むしろAIプロジェクト全般の​失敗確率は​高い。​Gartnerは、​2027年末までに​エージェンティックAIプロジェクトの​ 40%超が中止されると​予測する。​理由は​ ①コスト膨張 ②不明瞭な​ビジネス価値​（ハイプ駆動の​PoC）​③不十分なリスク統制、の​3つだ。

さらに​本質的なのは​データ側の​問題である。

要するに、​**Company Brainの​勝負どころは​「モデル」ではなく​「データ・権限・ガバナンスの​基盤づくり」​**に​ある。​ここを​外注任せに​して​PoCだけ走らせると、​Gartnerの​言う​40%側に​落ちる。

日本企業特有の​​論点

日本企業で​Company Brainを​検討するなら、​海外プレイヤーの​事例を​そのまま​当てはめる​前に、​3つの​論点を​踏まえる​必要が​ある。

1. 権限・セキュリティは​​「最初の​​設計」で​​決まる

「一般​社員が​役員直轄の​機密や​他部署の​人事評価を​参照できては​大問題」。​日本企業では、​Active Directory​（AD）​権限を​継承し、​アクセス可能な​文書から​のみ​回答を​生成する​**動的な​権限フィルタ​（RBAC連携）​**が​事実上の​必須要件に​なる。​これは​後付けが​難しい。​Company Brainの​選定時点で​「既存の​権限体系を​どこまで​忠実に​継承できるか」を​最優先で​評価すべきだ。

2. 属人化・暗黙知と​​いう​​日本企業の​​主戦場

従来の​社内検索は​「暗黙知」や​「意図」を​汲めなかった。​ベテランの​経験則、​根回しの​履歴、​過去案件の​判断理由。​日本企業に​厚く​堆積した​こうした​知こそ、​Company Brainが​最も​価値を​出す領域だ。

3. ​「読みやすい​​文章」から​​「構造化データ」へ

発想の​転換も​要る。​これまでの​社内文書作成は​「人間が​読みやすい​文章を​書く」ことが​目的だった。​Company Brain時代は、​構造化データ​（Markdown / JSON）と​メタデータを​整える​ことに​重心が​移る。​AIが​正しく​参照できる​形に​データを​置く​こと​自体が、​新しい​業務に​なると​いう​ことだ。

4. 閉域・オンプレ要件

データ越境制約や​稟議文化から、​SaaS型​（Gleanなど）の​採用が​難しい​ケースも​ある。​その​場合は、​ローカルLLM / オンプレ構成や、​機微情報を​オンプレに​留める​ハイブリッド設計が​選択肢に​なる​（オンプレLLMの​選び方は​ ローカルLLM / オープンウェイトモデル比較2026 を参照）。

FDXの​​考える​​「Company Brainの​​作り方」

Company Brainは、​ツールを​買えば​手に​入る​ものではない。​自社の​業務知識を、​AIが​安全に​使える​形に​整える​実装プロジェクトだ。​FDX株式会社は、​ここを​Forward Deployed Engineer​（FDE）と​Deployment Strategist​（DS）の​ペアで​伴走する。

「生成AIは​入れたが​社内データを​使いこなせていない」​「Gleanか​Copilotか​Palantirか、​自社に​どれが​合うのか​判断できない」。​その壁は、​ツール選定ではなく​ データ・権限・業務知識の構造化 の​問題である​ことが​多い。​FDXは​そこから​一緒に​設計する。

Company Brain構築の​無料相談を​申し込む →

FAQ

Q1. Company Brainと​​社内検索​（エンタープライズサーチ）の​​違いは？

社内検索は​「文書を​探す」​ところで​止まる。​Company Brainは、​探した​知識を​構造化し、​最新に​保ち、​引用付きで​回答し、​最終的に​AIエージェントが​業務を​実行する​根拠まで​提供する。​Y Combinatorの​定義でも​「これは​社内検索でも​チャットボットでもない」と​明確に​区別されている。​検索は​Company Brainの​入口の​一機能に​すぎない。

Q2. Company Brainと​​RAGは​​同じ​​もの？

RAG​（検索拡張生成）は​技術手法、​Company Brainは​その​技術で​実現する​企業基盤の​概念だ。​Company Brainは​「エンタープライズRAG​（コネクタ + 権限 + ナレッジグラフ + ガバナンス）」を​土台に​しつつ、​組織知の​維持・​最新化・エージェント実行までを​含む上位概念と​して​捉えると​よい。

Q3. Gleanを​​入れれば​​Company Brainは​​完成する？

ツールは​強力な​土台に​なるが、​それだけでは​完成しない。​Gartnerが​指摘するとおり、​成功する​組織は​データ基盤に​最大4倍投資している。​コネクタを​繋いでも、​権限体系が​整理されていない​・社内文書が​構造化されていない​・暗黙知が​どこにも​ない、と​いう​状態では​Company Brainは​機能しない。​製品導入と​並行して、​データ・権限・業務知識の​整備が​要る。

Q4. 権限管理​（誰が​​何を​​見られるか）は​​どう​​担保する？

retrieval​（検索）の​段階で​アクセス権の​ない​情報を​構造的に​除外する​「permissions-aware」​設計が​前提だ。​日本企業では​Active Directory権限を​継承し、​ユーザーが​アクセス可能な​文書から​のみ​回答を​生成する​動的フィルタ​（RBAC連携）が​事実上の​必須要件に​なる。​ここは​Company Brain選定で​最優先に​検証すべき項目。

Q5. 中​小企業でも​​Company Brainは​​必要か？

Y Combinatorは​「世界中の​すべての​企業が​必要と​する」と​述べている。​ただし規模に​よって​出発点は​違う。​大企業は​権限・ガバナンスの​設計が​重く、​中小企業は​まず​「散在する​知識を​1箇所に​集めて​構造化する」​ところから​始めるのが​現実的。​規模に​関わらず、​AIエージェントを​業務に​使うなら、​その前提と​して​知識基盤は​避けて​通れない。

Q6. 導入は​​どれくらいの​​期間と​​投資が​​必要？

ツールの​ライセンスだけでなく、​実装・​データ整備・権限設計を​含めた​総保有コストで​考える​必要が​ある。​重要なのは​「PoCで​検索が​動いた」を​ゴールに​しない​こと。​Gartnerの​言う​40%の​失敗側に​落ちないためには、​最初から​ROI指標・権限設計・撤退/拡張の​判断基準を​握ったうえで​段階導入するのが​定石だ​（​参考：AIコンサルティングの​選び方）。

Q7. Company Brainと​​AIエージェントの​​関係は？

Company Brainは​AIエージェントの​「土台」だ。​エージェントは​自律的に​業務を​実行するが、​自社の​業務知識を​持たなければ、​社内事情を​知らない​新人に​重要判断を​任せるのと​同じに​なる。​Company Brainが​エージェントに​「正しい​根拠」を​与える​ことで、​安全か​つ​一貫した​自動化が​成立する。​Y Combinatorが​Company Brainを​「AI自動化に​欠けた​基本部品」と​呼んだのは、​この​依存関係を​指している​（参考：マルチエージェント実装ガイド）。

関連記事

まとめ

出典・参考文献

関連記事

Strategy

AIエージェント完全ガイド｜2026年版 定義・構築アプローチ・企業導入の成功条件

Strategy

AI内製化の進め方｜外注依存から脱却する5ステップと判断基準

Market Trend

AIロールアップとは｜AI×M&Aの新モデルを徹底解説

Next Steps

次に読むべき

ノウハウ記事

他のノウハウ記事を読む

FDE / AX 実装に関する他のインサイト記事。

読む

事例

実装事例集

記事で議論したパターンが動いている実例。

読む

ホワイトペーパー

AX 診断と研修設計

読んだ後の「次に何をするか」のたたき台。

読む

FDX流の​FDEモデルを​相談する

戦略立案・実装・現場定着・運用移管まで一気通貫で支援します。

無料相談を申し込む実装事例を見る