「#197」 なぜAI利活用は「PoC」で止まるのか—Palantirオントロジーが変えるもの
皆さんも経験がありませんか、私もこの２年間でRAGを使えば使うほど、ある一定の水準で止まってしまう。
検索の結果の偏り。少し聞き方を変えると回答率が悪くなる。その度に、関係するナレッジベースのチャンク分割やインデックスの張り方を見直すのだが、根本は変わらない。
足りないのは、AIモデルの性能ではない。
足りないのは、もう一歩踏み込んでAIが業務を理解し、判断し、実行するための「業務の地図」ではないかと最近思うようになってきた。
業務の地図とは何か。それを考えるうえで、Palantirという会社が非常に参考になる。そして、この業務の地図の不在こそが、多くの生成AI導入がPoCで止まる本当の理由だと考えている。
RAGは「文書の検索」であって「業務の理解」ではない
RAGを導入した現場でよく聞く言葉がある。
「思ったより使われていない」
「回答は返ってくるが、業務の判断には使えない」
理由は単純だ。RAGがやっているのは、テキストを検索して、それらしい断片を拾ってくることだけだ。文書の中に書かれた「言葉」は理解できても、その言葉が業務の中で何を意味するのか、他の何と繋がっているのかは理解していない。
「在庫」という言葉を検索できても、それがどの工場の、どの部品の、どのくらいの日数分の在庫で、誰が発注の権限を持っているのかは知らない。AIにとって、それはただの文字列だ。
だから、RAGは「聞けば答えてくれるチャットボット」の域を出ない。読むことはできても、動くことはできない。
オントロジーとは「業務の意味を定義する地図」
Palantirという会社をご存知だろうか。防衛・製造・金融といった領域で、企業のAI導入を支援している米国企業だ。今この会社が注目されている理由は、AIモデルの性能ではなく「オントロジー」という仕組みにある。
オントロジーを一言で言えば、企業のデータ全体を「業務が分かる形」に変換した表現であり、生のデータを人間もAIも理解できる現実世界の概念に変えるものだ。テーブルや列の代わりに、「従業員」「機体」「発注」「取引先」といった、現実の業務にある名詞で扱う。
これを構成する要素は大きく3つある。
オブジェクト（名詞）。「工場」「部品」「輸送ルート」「在庫リスク」といった、業務上の実体だ。
リンク（関係）。「このエンジンは千葉工場で製造される」「この部品はこの倉庫にある」といった、オブジェクト同士の繋がりだ。
アクション（動詞）。「在庫を補充する」「発注を承認する」といった、実際に業務システムを動かす操作だ。アクションを実行すると、ERP（基幹業務システム）などを通じて現実世界の業務を実際に動かすことができる。
つまりオントロジーとは、バラバラなデータベースの中身を、「この会社では何が何を意味し、何と繋がり、誰が何をしてよいか」という業務の文脈ごと定義し直したものだ。SAPもMESもSCMも入っているのに、現場では結局Excelで管理されている、という状況の本当の原因は、データが存在しないことではなく、データが意味のある形で結ばれていないことにあると指摘されている。
これが、私の言う「業務の地図」だ。
PoCで止まる本当の理由
多くの企業が生成AIのPoCで止まる理由は、この地図がないままAIを業務に接続しようとしているからだと最近強く思い始めている。
議事録作成AIは、議事録という「文書」を作る。だが、その議事録に出てきた「発注してほしい」という一言を、実際の発注アクションに繋げる回路がない。
社内文書検索は、規程集から答えを引っ張ってくる。だが、その規程が「今この案件」の承認フローの中でどこに位置するのかを理解していない。
AIエージェントのPoCは、単発のタスクならこなせる。だが、複数の業務システムをまたいで「この状況なら、誰の承認を得て、何を動かすべきか」を判断する土台がない。
本当のボトルネックは、AIそのものの精度ではない。AIの提案が「スライドの中」にとどまり、業務の意味や責任分界と接続できないことにある。
PoCは「AIが賢いかどうか」を確かめる実験だ。だが本番運用に必要なのは、「AIが自社の業務をどう理解し、どこまで動いてよいか」を定義した地図の方だ。地図がないまま賢いAIを投入しても、その賢さを発揮する場所がない。
中小規模の現場に、Palantirはいらない
とはいえ、Palantirのような大規模な基盤を導入できる企業は限られる。大規模な基幹業務を一つの意味モデルに統合したい企業には最有力候補だが、コスト・導入工数は大きく、全社規模のコミットメントがある組織向けという性格の製品だからだ。
だが、オントロジーという「考え方」は、規模に関係なく使える。
大がかりな製品を入れる前に、まず紙とペンでもいい。自分たちの業務にある「名詞」を書き出す。顧客、案件、在庫、予約、承認。次に、それらが「何と繋がっているか」を書く。どの案件が、どの担当者に紐づき、どの承認を経て、何が動くのか。最後に、AIに任せてよい「動詞」と、人間が握るべき「動詞」を切り分ける。
これができて初めて、RAGは「検索」から「業務理解」に近づく。議事録作成AIは「記録」から「実行」に近づく。AIエージェントは「実験」から「運用」に近づく。
技術を入れる前に、地図を描く。順番を間違えないことが、PoCの先に進む唯一の道だと思っている。
師匠が、まさにこの「地図の描き方」を連載している
ここまで書いてきた話、実は私の師匠である小野哲氏が、note連載「AIエージェント時代のオントロジー」でより技術的な解像度で解いている。
連載第2回「RAGはどこで力尽きるか」では、RAGが抱える弱点を3つに整理している。関係を何段もたどるような問いに弱いこと。個別の断片は拾えても全体を見渡す問いには答えられないこと。根拠の粒度が粗く、どのデータの何時点の情報かまで遡れないこと。原因はどれも同じで、断片同士の「つながり」がどこにも記録されていないからだ、という指摘だ。
その解決策として紹介されているのがGraphRAG。文書からAIが関係性を抜き出し、点と線でできた相関図（ナレッジグラフ）に組み替える手法だ。ここで面白いのは、その先にもう一段の議論があること。AIが自己流で描いた相関図には表記ゆれや定義のブレが残る。だから、関係者が合意して定義し、ルールで検算され、出所まで記録された「設計された地図」を持てば、AIはその地図を検索する司書のような役割に徹し、事実をでっち上げる余地がなくなる、という流れだ。
これはまさに、私がこの記事で「業務の地図」と呼んできたものの、技術的な裏づけそのものだ。Palantirのオントロジーが大企業の全社基盤としてやっていることを、もっと軽量に、自分たちの手で設計し直す道筋がそこにある。
連載の次回は「LLMと90分でオントロジーを作る」というハンズオン企画だという。実際に手を動かして地図を作る具体的な方法は、ぜひそちらを読んでほしい。
私がこれまで現場の課題を見てきて確信しているのは、システムは技術の展示会ではなく、人の行動を変えるためにあるということだ。オントロジーという言葉は聞き慣れなくても、その本質は「自分たちの業務を、AIが読める形で言語化する」という、ずっとシンプルな作業に過ぎない。
RAGは「知識を残す」ことを助けてくれます。
必要なのは、その知識をきっかけに「次の仕事が自動的に動く仕組み」作りでは無いでしょうか。
そしてその作業は、Palantirを買わなくても、今日から始められる。
