FDX株式会社
Strategy

Company Brain​（カンパニーブレイン）とは？​AIエージェント時代に​「企業の​脳」が​必要に​なる​理由

Company Brain（カンパニーブレイン）とは、社内に散在する知識を吸い上げ・構造化し・常に最新化して、人間とAIエージェントが同じ「事実の源」として参照できるようにする企業AI知識基盤です。Y Combinator が2026年に「AI自動化に欠けた基本部品（primitive）」と名指しした概念の起源、Glean / Microsoft 365 Copilot / Palantir AIP の違い、アーキテクチャ5要素、ROI と失敗リスク、日本企業での権限・閉域要件までを経営層・AX推進責任者向けに解説します。

·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 自動化に​欠けた​基本部品」と​呼んだのは、​この​依存関係を​指している​（参考：マルチエージェント実装ガイド）。

関連記事

出典・参考文献

関連記事

Tech Note

ローカル LLM / オープンウェイトモデル比較 2026｜Llama 4 / Qwen 3 / DeepSeek / Mistral / Gemma の選び方

Tech Note

LLM トークン節約 5 パターン｜本番運用でコストを 70% 削るハーネス設計

Tech Note

ループエンジニアリング入門｜自律エージェントを動かし続けるハーネス設計の体系

Next Steps

次に読むべき

ノウハウ記事

他のノウハウ記事を読む

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

読む

事例

実装事例集

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

読む

ホワイトペーパー

AX 診断と研修設計

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

読む

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

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

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