エンタープライズAIの勝負どころは、「その企業ならではの文脈（コンテキスト）を誰が押さえるか」へ移りつつあります。なかでも、企業そのものを写し取る「業務世界モデル」を作ろうとしたPalantirの発想は、AIエージェントを実務で効かせるうえで学びが多い。この記事は、なぜデータとAIを揃えるだけでは業務が回らないのか、文脈をどう組み立てればAIが効くのかを、Palantirの設計から読み解きます。
💡 この記事の要点（30秒で）
① 勝負どころが移った ＝ エンタープライズAIは「企業固有の文脈を誰が押さえるか」へ
② データ＋AIでは回らない ＝ 意味を失ったデータにAIを載せても、業務は動かない
③ 間に一層が要る ＝ 業務の文脈をたもつ層＝業務世界モデル（オペレーショナルレイヤー）
④ 名詞・動詞・動的化 ＝ 何があり（名詞）、何ができ（動詞）、どう変わり誰が動かすか（動的化）
⑤ 本記事のゴール ＝ AIを業務で効かせる勘所と、真似されにくい優位の作り方がつかめる
🏢 CRIEN視点 ── CRIENは企業の業務自動化基盤を数多く手がけ、自社の業務も複数のAIエージェントで回しています。現場で痛感するのは、AIの精度を磨く前に「自社の業務世界をどれだけ正確に写せているか」で成果が決まる点です。私たちが日々の実装で向き合うテーマそのものです。
データとAIを揃えても、業務は回らない
「土台となるデータを整え、その上にLLMを置けば仕事は回る」——そう見込む企業は少なくありません。ところが現実は、それだけでは足りない。データは「意味」をはぎ取られたまま散らばっているからです。
ある金額の列が何を表すのか。その取引がどの工程や顧客につながるのか。誰に開示してよいのか。こうした文脈は、表のどこにも書かれていません。文脈が抜けたままLLMを載せると、制約を無視した答えや、実行できない提案が返ってくる。要るのは、データとAIの間に、業務の文脈をたもつ層を一枚はさむことです。それを構造化したものが、企業の「業務世界モデル」です。手前の段として、社内データをAIが扱える形に整えることも欠かせません（ AI導入のためのデータ準備5ステップ ）。
必要なのは、意味と実行をつなぐ中間の層
この中間層は、単なる意味づけ（セマンティックレイヤー）ではありません。Palantirはこれを「オペレーショナルレイヤー」と呼び、貯めただけのデータを「現実を動かす道具」に変える層です。
前提として、最初の一枚は誰かが顧客の現場で組み上げねばなりません。「自社にとっての"航空機"とは何か」という写像は企業ごとに違い、製品を渡すだけでは埋まらないからです。この役回りを担うのが、Forward Deployed Engineer（FDE）です。詳しくは パランティアモデルとFDE完全ガイド で解説しています。
業務世界モデルを支える3要素
この業務世界モデル（Palantirの言葉ではオントロジー）は、3つの要素で捉えられます。
| 要素 | 問い | 中身 |
|---|---|---|
| 名詞（意味層） | 世界に何があるか | 顧客・製品・契約などの対象、その関係、属性を定める |
| 動詞（実行層） | 何ができるか | 承認・担当変更・整備予約など、業務の行為を組み込む |
| 動的化 | どう変わり、誰が動かすか | 状態遷移・権限・記録を織り込み、現実と同期して動く |
名詞は、散らばった呼び名（「user」「client」など）を「顧客」という一つの実体にまとめる層で、従来のBIも担ってきました。差がつくのは動詞から。承認・発注・優先度変更といった行為を重ねて初めて「見る」から「動かす」へ届きます。
核心は動的化です。「見込み客→契約中→更新→解約」という移り変わりを持たせ、各状態で許す操作と実行できる相手（権限）を定めた瞬間、モデルは"生きて"動き出す。しかも現実のシステムへ書き戻せ、判断は「いつ・誰が・何を決めたか」まで記録に残る。それが次の判断の材料になり、使うほど精度が上がります。
Airbusの公表事例が教えること
よく引かれるのがAirbusです。Palantir・Airbusの公表資料によれば、A350は約500万個の部品からなり、数百のチーム・複数の国と工場をまたいで作られていました。従来は部品の遅れや品質のデータが散在し、「完成するまで全体像を誰もつかめない」状態だったとされます。
散らばったデータを「航空機・部品・工程」という現実の骨組みで統合し、依存関係を明示的に結んだことで、詰まりが見え、判断が速くなった。公表資料では、これがA350の納入を約33%早めた主要因とされます（公表時点の数値）。押さえたいのは因果です。AIが魔法をかけたのではなく、現実の構造で束ね、依存を結び、詰まりを見えるようにし、判断を速くした連鎖の結果。判断に要る現実の構造を写し取ったから効いたのです。
自社実装に効く、4つの設計原則
この考え方は、自社にAIエージェントを組み込むときそのまま使えます。
1. 「データ統合」でなく「意思決定」から始める ── 「何を分析したいか」ではなく「誰が、何を、どんな制約で決めているか」から。Airbusの改善も「どの部品の詰まりを先に潰すか」から逆算されました。
2. 名詞だけでなく動詞も設計に入れる ── 動かすには、読める（名詞）だけでなく実行できる（動詞）が要る。両者がそろって初めて「意思決定」になります。
3. 「読むだけ」で止めず、実行と記録までつなぐ ── 提案止まりで実行を人手に委ねると、成果の多くを取りこぼす。書き戻しと記録の循環が精度を押し上げます。
4. AIにも人と同じ権限・統制を継がせる ── 開示してよい相手、実行を許す操作の線引きを、人と同じ物差しでAIにも当てられなければ本番には出せません。整え方は 中小企業のAIデータガバナンス5ステップ にまとめています。
実装の具体は 自律型AIエージェントで業務自動化する手法 も参考になります。
まとめ：勝負どころは「賢いモデル」より「深い文脈」
AI時代の優位は、もはやモデルの賢さだけでは決まりにくい。効くのは「自社の業務世界を、どれだけ忠実に、動的に、現実と同期して写せるか」です。その文脈の深さは使うほど積み上がり、真似されにくい強みになります。問うべきは「どれだけ賢いモデルを使うか」ではなく「自社の業務世界をどれだけ深く知っているか」です。
自社の業務をAIに理解させ、実行まで任せる基盤を作りたい方は、 まるごとAI顧問 へ。業務世界の写し取りから実装まで、CRIENが現場で伴走します。
FAQ（よくある質問）
データ基盤にLLMを載せれば、AIで業務は回りますか？
それだけでは回りにくいのが実情です。データは意味をはぎ取られて散らばり、列名が何を指すのか、誰が見てよいのかが分かりません。文脈が抜けたままAIを載せると、制約を無視した答えや実行できない提案が返る。間に、業務の文脈をたもつ層が要ります。
「業務世界モデル（オントロジー）」とは何ですか？
企業に「何があり（名詞）」「何ができ（動詞）」「どう変わり誰が動かすか（動的化）」を構造化した、業務の文脈そのものです。散らばったデータを現実の実体に対応づけ、行為や状態遷移・権限・記録まで含めて表し、AIエージェントはこれを文脈として推論・実行します。
名詞と動詞を分けて設計する意味は何ですか？
「読める」ことと「実行できる」ことは別だからです。名詞（指標の定義）だけでは、結果を見るBIで止まります。承認・発注・優先度変更といった動詞を重ねて初めて業務遂行まで表せる。AIの価値も、読めるかより実行できるかで決まります。
Airbusの「33%」は、AIが賢かったからですか？
いいえ。公表資料では約33%の納入加速とされますが、要因はモデルの賢さではありません。散在データを現実の構造で束ね、依存関係を結び、詰まりを見えるようにし、判断を速くした連鎖の結果です（公表時点の数値）。
中小企業でも、この発想は活かせますか？
活かせます。全社を一気に写す必要はありません。「どの判断を、誰が、どんな制約で下すか」から対象を絞り、一つの業務の文脈を組み立ててAIに実行まで任せ、得た記録を次に活かす小さな循環から始められます。
出典・参考
• パランティアモデルとFDE完全ガイド｜生成AI各社が採用する「現場で作るAI導入」
• AI導入のためのデータ準備5ステップ｜AI-Readyスコア
• 中小企業のAIデータガバナンス5ステップ実践ガイド
• 自律型AIエージェントで業務自動化する手法
• Palantir 公式サイト：https://www.palantir.com/
