オントロジーとは？AI駆動開発が現場で止まる理由【2026年版】

---

AI駆動開発によって、コードを書く速度は劇的に上がりました。それでも現場では、「なぜか本番システムとして仕上がらない」「開発プロジェクト全体の生産性が上がらない」という違和感が残ります。プロンプト設計やテスト不足も一因ですが、より根深い壁は、AIが「顧客システムの文脈」を知らないことにあります。

深夜2時、CopilotやClaude Codeが生成した数千行のプルリクを前に、リードエンジニアの手が止まる。「この条件分岐は、うちの与信ポリシーと整合しているのか？」──AIはコードを書けても、あなたの会社の商流、例外ルール、営業の優先順位、現場の暗黙知までは知りません。

問題は、AIの性能が低いことではありません。顧客システムの文脈が、AIから参照できる形でどこにも整理されていないことです。与信ポリシー、例外ルール、承認経路、過去の仕様変更は、仕様書やコードの外側に散らばり、ベテランの記憶や現場の暗黙知として残っています。

この散らばった文脈を、AIが理解できる「業務世界の地図」として整理する考え方が、オントロジーです。本記事では、AI駆動開発が現場で止まる理由から出発し、なぜ生成AI時代にオントロジー設計が重要になるのかを解説します。

深夜2時のプルリク：AI駆動開発が現場で止まる瞬間

AIでコードを書く速度が上がった一方で、顧客システムの文脈を知らないことが新たなボトルネックになっています。

深夜2時。

都内のある開発チームのSlackに、無言の「:eyes:」スタンプが並びます。

「Copilotで一気に書いたんだけど、レビューお願いできます？」

若手エンジニアが投げたプルリクは、数千行の差分。GitHub CopilotとClaude Codeを駆使して、レガシーな受注管理システムに新しい料金ロジックとダッシュボードを追加するタスクでした。

コードの体裁は悪くありません。テストもそれなりに通っています。画面も動く。APIも返る。差分だけを眺めれば、たしかに「AI駆動開発の成果」と呼べそうです。

しかし、レビューするリードエンジニアの手は、途中で止まります。

Copilotは、完璧に「コード」を生成してくれました。しかし、「顧客システムがどう動いているのか」の理解は、人間の頭の中に残ったままでした。

プルリクは翌日、「ビジネスロジック要再設計」というコメントとともにクローズされました。この風景に、どこか身に覚えはないでしょうか。

これは、AIが使えないという話ではありません。むしろ逆です。AIがコードを書く力を持ったからこそ、「コード以前に定義すべき業務世界」が露わになったのです。

ボトルネックはコードではなく「顧客システムの文脈」

AI駆動開発の本当の課題は、コード生成能力ではなく、自社や顧客ごとの業務構造をAIが参照できないことにあります。

GitHub Copilot、Codex、Claude Code、Cursor、Windsurf。AI開発支援ツールは、UI改修、ボイラープレート生成、テストのたたき台、既存コードのリファクタリングといった作業を一気に速くしました。

世界1,100人超の開発者を対象にしたSonarSourceの2026年調査では、プロ開発者の自己申告ベースで、現在コミットまたは貢献されているコードの42%がAI生成またはAI支援と報告されています。

しかし同調査は、より核心的な矛盾も示しています。96%の開発者がAI生成コードを完全には信頼しておらず、AI支援コードをコミット前に必ず検証すると答えたのは48%にとどまります。つまり、生成速度が上がるほど、検証コストが新たなボトルネックになっているのです。

それでも、企業のアウトカム──売上、利益、リードタイム短縮、在庫削減、顧客体験の改善──が同じ速度で変わっているとは言い切れません。コードは速くなった。でも、システムはなかなか本番品質に仕上がらない。この矛盾の正体こそが、本記事のテーマです。

理由はシンプルです。LLMは「統計的にもっともそれらしいコード」は書けますが、顧客システムの文脈を理解しているわけではないのです。

• なぜその条件分岐が存在するのか
• どの部署の例外ルールが優先されるのか
• 与信ポリシーや承認経路の背景にある判断基準は何か
• 現場だけが知っている暗黙知や運用上の制約はどこにあるのか

こうしたものは、GitHubやStack Overflowには載っていません。だからLLMは、「それっぽい一般解」は出してくれても、「その顧客システムにとって正しい答え」は出せないのです。

Vibe Codingが見せた“コード生成だけでは足りない”現実

Vibe Codingは、OpenAI創設メンバーで元Tesla AI DirectorのAndrej Karpathyが広めた開発スタイルで、AIに自然言語で「こんな感じで」と指示しながらコードを書かせるアプローチです。Collins Dictionaryは2025年のWord of the Yearとして「vibe coding」を選び、自然言語でAIに指示してコードを書く開発スタイルとして説明しています。

Vibe Codingは、プロトタイプ作成や小規模ツール開発では非常に強力です。しかし、企業システムでは「動くこと」と「正しいこと」は違います。

ここで必要になるのは、AIにさらに強いプロンプトを投げることではありません。Vibe Codingで生成されたコードを支える「業務世界の設計図＝オントロジー」を、先に用意することです。

エンジニアの仕事は「書く」から「文脈を整える」へ

ここで重要なのは、「AIでエンジニアがすぐ不要になるか」という話ではありません。むしろ現場では、AIが生成したコードを顧客システムの文脈に照らして確認し、仕様へ戻し、テスト観点を増やし、どこまでAIに任せるかを判断する仕事が増えています。

AIによって「書く作業」は速くなります。しかし、顧客システムを理解し、業務ルール・例外・承認・責任分界を整理する仕事は、むしろ重要になります。

つまり、AI駆動開発の次の課題は、より多くのコードを書くことではありません。顧客システムの文脈を、AIが参照できる形に整えることです。

オントロジーで何が変わるのか：顧客システムの文脈をAIに渡す仕組み

オントロジーは、仕様書や人の記憶に散らばった業務ルールを、AIが参照できる「業務世界の地図」として整理する仕組みです。

冒頭のプルリクに戻って考えてみましょう。AIが生成したコードは、文法的には正しく、テストも一部通っていました。それでもリードエンジニアの手が止まったのは、コードが間違っていたからではなく、顧客システムの文脈を参照していなかったからです。

たとえば、受注管理システムで新しい料金ロジックを作る場合、AIが本当に知るべきなのは「if文の書き方」だけではありません。

• この顧客は与信上、どのランクにあるのか
• キャンペーン割引と個別契約割引のどちらが優先されるのか
• 在庫はどの倉庫から引き当てるべきなのか
• 一定金額を超える値引きには誰の承認が必要なのか

オントロジーは、こうした業務上の概念を、顧客・契約・製品・在庫・承認ルールといった業務オブジェクトとして定義し、それらの関係性と制約を明示します。

表1：オントロジーによってAIが参照できるようになる業務文脈

現場で暗黙知になりやすいもの	オントロジーでの表現	AIにとっての効果
与信ポリシー	顧客オブジェクトと信用ランク、承認条件を結びつける	割引や出荷可否の判断で、顧客ごとの制約を参照できる
キャンペーン優先順位	契約、価格ルール、キャンペーン条件の適用順を定義する	複数の割引条件がある場合でも、誤った順序で適用しにくくなる
在庫引当ルール	倉庫、在庫状態、出荷経路、予約済み在庫を関係づける	見かけの在庫ではなく、販売可能な在庫を判断しやすくなる
承認経路	金額、部門、権限、例外条件をルールとして定義する	AIが勝手に業務実行せず、人間の承認が必要な場面を判定できる
※ 出典：企業システム設計、ドメイン駆動設計、Palantir Ontologyの公開情報をもとにArpable編集部が整理

つまり、オントロジーがあると、AIは単に「それらしいコード」を生成するのではなく、顧客システムの文脈に照らして、どのルールに従うべきかを確認しながら実装や判断を進められるようになります。

これが、オントロジーがAI駆動開発に必要になる理由です。AIにもっと長いプロンプトを書くのではなく、AIが参照できる業務世界そのものを整備する。ここに、コード生成AIと本番システムの間にある溝を埋める鍵があります。

小さく始めるなら、「オントロジー＝巨大なメタデータ基盤」と考える必要はありません。チームの中で毎回揉めているロジック──たとえば「どの割引がどの順番で適用されるか」や「誰の承認があれば出荷してよいか」など、1つの業務論点だけを選び、そこに登場するオブジェクトとルールをホワイトボードに書き出すところから始められます。

それを、そのままAIに読み込ませる「最初の業務世界の地図」として扱う。ここが、オントロジー設計を「現場で回る習慣」に変える入口です。

なぜ生成AI時代にオントロジーが再注目されているのか

生成AIが賢くなるほど、確率的なAIを「決定論的な業務ルール」に従わせるためのオントロジーの重要性が高まります。

LLMは本質的に、大量のテキストを圧縮し、統計的にもっともありそうな次の言葉を出す「確率的（Probabilistic）」な装置です。

一方で、企業の契約、会計、在庫引当、与信判断といった基幹業務は、入力に対して同じ結果を返さなければならない「決定論的（Deterministic）」な世界です。

この「確率的なAI」と「決定論的な業務」のギャップを埋める仕様書こそが、オントロジーです。だからこそ、一般的な知識には強いLLMであっても、個社固有の業務判断では弱さが出るのです。

企業の競争優位が宿る場所は、一般解ではありません。そこに存在するのは、その会社固有のビジネスドメインであり、AIが参照すべき「動いている業務の設計図」です。

• Rules（ルール）：独自の商流、約款、価格条件、監査要件
• Process（プロセス）：部門間の承認経路、現場運用、例外対応
• Constraints（制約）：物理的な在庫上限、法的要件、設備制約

これらは、GitHubのどこを探しても載っていません。つまり、AIがいくら賢くなっても、自社固有の業務世界をモデル化しなければ、AIは本番業務で正しく動けないのです。

AGIを待つより、顧客システムをオントロジー化する

AI界隈には、今もAGI（汎用人工知能）への根強い期待があります。「いずれはAIが、あらゆるビジネスドメインを自動的に理解してくれるはずだ」という考え方です。

しかし、現実の顧客システムは、一般知識だけでは理解できません。過去の仕様変更、部門間の調整、現場で守られてきた例外ルール、監査対応、商慣習。こうしたものは、モデルが勝手に知ってくれるものではありません。

AGIを待つ前に、人間とAIとシステムが協調しながら、顧客システムの文脈をオントロジーとして書き起こす。これが、AIを本番業務に近づける現実的なルートです。

Palantirが示すオントロジー実装の現実解

Palantirは、オントロジーを抽象概念ではなく、現場業務を動かすための実装基盤として扱っています。

オントロジーを実務に落とし込む例として、Palantir Technologiesのアプローチは非常に示唆的です。

Palantirの強みは、単にAIモデルを提供することではありません。公式ドキュメントや公開事例からも分かるように、企業のデータ・業務概念・権限・アクションをオントロジーとして結び、AIがその上で判断や提案を行えるようにする設計思想にあります。

PalantirのAIPにおいて、LLMは万能な魔法使いではありません。深夜2時のプルリクで言えば、与信ポリシーも在庫ルールも承認経路も、すべて「読める地図」として与えたうえで、初めてAIが動く設計です。オントロジーに定義された世界の中で、業務ルールを参照し、シミュレーションを行い、安全なアクションを起こすための部品として機能します。

この設計思想の違いが、AIを「便利なデモ」から「現場で動く仕組み」へ変えていきます。PalantirはAIP Bootcampを、顧客が1〜5日という短期間で、自社データを使った実ユースケースに到達する場として位置づけています。

重要なのは、AIを単体で試すのではなく、業務データ・権限・アクションを結びつけた状態で価値を検証する点です。

日本企業が真似できるのは「5日間で完璧なシステムを作ること」ではなく、短期間で1ユースケースだけを決めて、そのためのオントロジー・権限・アクションをまとめて設計するという進め方です。PoCを量産するのではなく、「5日間のミニBootcamp」を社内で企画し、1つの業務テーマにオントロジー設計とAIエージェント実装を集中させる。このリズムが、Palantirが示している現実解のエッセンスです。

日本企業は何から始めるべきか：3つの業務オブジェクトと3つの問い

オントロジー設計は大げさな全社プロジェクトではなく、重要な業務オブジェクトを一つ定義することから始められます。

想像してみてください。深夜2時のプルリクで止まっていたリードエンジニアが、翌月には「与信条件はオントロジーに聞け」と言えるようになる。それは夢物語ではなく、業務オブジェクトを一つ正確に定義することから始まる現実的なルートです。

日本企業がまず取り組むなら、次の3つの業務オブジェクトから始めるのが現実的です。業種によって優先順位は変わりますが、多くの企業で「AI活用の最初の壁」になりやすい領域です。

顧客：誰と取引しているのか

顧客は、単なる会社名ではありません。法人、部署、担当者、契約単位、与信状態、請求先、納品先が絡み合う複雑なオブジェクトです。

AIに「この顧客に最適な提案を作って」と頼むなら、AIは顧客の階層、契約条件、過去の取引、禁止事項を理解している必要があります。

契約：どの条件で動いているのか

契約は、業務ルールの塊です。価格、期間、例外条件、解約条項、SLA、監査要件などが含まれます。

契約オブジェクトを定義しないままAIを動かすと、もっともらしい提案はできますが、法務・監査・営業現場で使えない結果になりがちです。

在庫・案件・資産：現場で何が動いているのか

製造業なら在庫や設備、SI企業なら案件や人員、金融なら口座やリスクポジションが中核オブジェクトになります。

どのオブジェクトが動くと、売上・コスト・リスク・顧客体験に影響するのか。ここを定義することが、AIに現場を理解させる第一歩です。

LLMを入れる前に、自社ドメインのOS設計図があるか？

自社のビジネスオブジェクト（顧客・案件・製品・契約・資産）は何か。
それらはどう関係し合い、どの制約のもとで動いているのか。

ここを曖昧にしたままCopilotやチャットボットをいくら導入しても、現場のプルリクレビューや運用テストの風景は変わりません。

社内にFDE的な人を立てられるか？

Palantirには、FDE（Forward Deployed Engineer）やDeployment Strategistと呼ばれる独自の役割があります。FDEは、顧客現場に入り込み、データと業務を一体でモデル化するPalantir独自の職種です。

• FDE：現場に入り込み、データと業務を一体でモデリングするエンジニア
• Deployment Strategist：経営・事業・ITをまたぎ、どのドメインからOS化するかを設計する人

同じ役職名をそのまま置く必要はありません。しかし、この役割自体はどんな企業にとっても不可欠です。

「誰かが、現場と経営をつなぐOSアーキテクトになっているか？」

外部OSと自前OSの境界を引いているか？

どこまで外部のOS、たとえばPalantirやクラウド各社の基盤に乗り、どこから自社のOSとして握るのか。

インフラや汎用AIモデルはクラウドに任せても、ビジネスドメインのオントロジーは、自社で定義し続けなければなりません。

この境界線の引き方こそが、AI時代の競争優位とデジタル主権を左右する設計上の論点になります。

補足：RAG・ナレッジグラフ・デジタルツインとの違い

RAGやナレッジグラフ、デジタルツインはオントロジーと重なりますが、業務アクションまで定義する点で役割が異なります。

オントロジーは、RAG、ナレッジグラフ、デジタルツインと混同されがちです。どれもAIに文脈を与える技術ですが、役割は少しずつ異なります。

表2：RAG・ナレッジグラフ・デジタルツイン・オントロジーの違い

概念	主な役割	得意なこと	オントロジーとの関係
RAG	文書を検索してLLMの回答に反映する	社内文書、FAQ、ナレッジ検索	文書検索には強いが、業務ルールやアクションまでは定義しにくい
ナレッジグラフ	概念同士の関係をグラフで表現する	関係探索、推論、データ連携	オントロジーの構成要素になり得る
デジタルツイン	現実の状態をデジタル空間に再現する	工場、物流、設備、都市などの状態監視・シミュレーション	オントロジー上で動く現実再現モデルとして活用できる
オントロジー	業務概念、関係性、ルール、アクションを定義する	AIエージェント、本番業務、権限・責任分界の設計	AIに業務世界を理解させる中核レイヤー
※ 出典：RAG、ナレッジグラフ、デジタルツイン、オントロジーの一般的な技術定義をもとにArpable編集部が整理（2026年5月時点）

実務では、これらは競合ではなく組み合わせて使います。RAGで文書を探し、ナレッジグラフで関係性を整理し、デジタルツインで現実状態を反映し、オントロジーで業務の意味とアクションを定義する。これが、生成AIを本番業務へ近づける現実的なルートです。

多くの企業が「まずはRAGから」と考えますが、RAGだけでは「誰がどこまで自動実行してよいか」「どのルールが優先されるか」といった責任分界を表現しきれません。そこを埋める中核レイヤーがオントロジーです。

まとめ：コードの時代から、オントロジーの時代へ

AI駆動開発の本質は、コードを書く速度ではなく、AIが理解できる業務世界をどれだけ正確に設計できるかに移っています。

深夜2時のプルリクに戻りましょう。

Copilotが書いたコードを前に、リードエンジニアがうなりながらレビューコメントを書く。

「仕様をもう一度、ビジネス側と一緒に整理しよう」
「このロジック、うちのオペレーションフローとズレていない？」

本当に必要なのは、レビューコメントでも、テストケースの追加でもありません。

「顧客システムの文脈を、どうモデル（オントロジー）として表現するか」

この一段上の問いです。

これは単なる開発手法の議論ではありません。経営陣にとっては、自社のビジネスモデルやドメイン知識を、どれだけAIが扱える資産に変えられているかという競争優位の問題です。

汎用AIモデルがコモディティ化していくほど、企業ごとの差は「どのモデルを使うか」ではなく、自社固有の業務世界をどれだけ精密にモデル化できているかに表れます。

AI駆動開発は、コードを書く作業を大きく変えました。しかし、企業システムの本番化で最後に問われるのは、コードの量ではありません。

問われるのは、AIが参照できる業務世界を、誰が、どの粒度で、どう設計するかです。

Copilotが「コードの時代」の仕上げをしているとすれば、オントロジーは「業務世界をAIに教える時代」の入口を示しています。ここを先に押さえた企業ほど、AI投資がPoC止まりではなく、売上・コスト・リスクプロファイルといった指標の変化として可視化されやすくなります。

次の一手は、Palantirを導入するかどうかだけではありません。

「あなたの会社のオントロジーを、どこから書き始めるか」

まずは、次のスプリントで議論が難航しそうな1つのプルリクを選び、その裏側にある業務オブジェクトとルールを、チームで10分だけホワイトボードに書き出してみてください。

そのペンを握るのは、他ならぬ、いまこの記事を読んでいるあなた自身なのかもしれません。

専門用語まとめ

Vibe Coding（バイブコーディング）

AIに「なんとなく」の指示を与えてコードを書かせ、動けばOKとする開発スタイル。プロトタイピングには強い一方、業務整合性が求められる大規模システムでは技術的負債になりやすい。

AI駆動開発

AIを単なるコード補完ではなく、要件整理、設計、実装、テスト、レビュー、運用改善まで開発プロセス全体に組み込む考え方。

オントロジー（Ontology）

ビジネスにおけるヒト・モノ・契約・在庫・ルールなどの実体と、それらの関係性やアクションを定義した構造モデル。AIに自社や顧客システムの業務世界を理解させるための地図。

顧客システムの文脈

コードや仕様書だけでは表現しきれない、顧客企業固有の商流、例外ルール、承認経路、過去の仕様変更、現場の暗黙知の総称。AI駆動開発を本番化する際の最大の難所になりやすい。

決定論的（Deterministic）

入力が決まれば出力も一定に決まる性質。契約、会計、承認、在庫引当などの業務では、確率的な推測ではなく決定論的な処理が求められる。

ハルシネーション（Hallucination）

AIがもっともらしい誤情報を生成する現象。AIが事実を理解しているのではなく、確率的にありそうな言葉をつなげることで起こる。オントロジーや業務ルールで参照範囲を縛ることで抑制しやすくなる。

デジタルツイン（Digital Twin）

現実世界の物理環境や業務状態を、データを用いてデジタル空間上に再現したもの。オントロジーが静的な地図だとすれば、デジタルツインはその上で動くシミュレーターに近い。

よくある質問（FAQ）

Q1.
オントロジーとは何ですか？

A1.業務上の概念、関係性、ルール、アクションをAIが理解できる形で定義した「業務世界の地図」です。

• 顧客、契約、製品、在庫、承認などを業務オブジェクトとして整理します。
• 生成AIを本番業務で使う際の前提となる意味レイヤーです。

関連：オントロジーで何が変わるのか

Q2.
AI駆動開発でコードが速く書けるのに、なぜ現場で止まるのですか？

A2.AIが顧客システムの文脈を知らないからです。

• AIは一般的なコードは書けますが、与信ポリシー、営業の優先順位、例外ルール、過去の仕様変更までは知りません。
• そのため、結合テストや運用レビューで「ビジネスロジック要再設計」になることがあります。

関連：顧客システムの文脈

Q3.
Vibe Codingは悪い開発スタイルなのでしょうか？

A3.悪いわけではありません。プロトタイプや小規模ツールには非常に有効です。

• ただし、基幹業務や大規模システムにそのまま持ち込むと、業務ロジックの整合性が崩れやすくなります。
• 本番システムでは、Vibe Codingに加えてオントロジー設計が必要になります。

関連：Vibe Codingの限界

Q4.
生成AIとオントロジーはどう関係しますか？

A4.生成AIに業務文脈を理解させるための土台がオントロジーです。

• 生成AIは一般知識には強い一方、自社固有の業務ルールは知りません。
• オントロジーを整備することで、AIが参照すべき業務概念とルールを明示できます。

関連：なぜ生成AI時代にオントロジーが必要なのか

Q5.
オントロジーはPalantirを導入しないと作れませんか？

A5.いいえ。考え方としては、Palantirを導入しなくても始められます。

• ドメイン駆動設計（DDD）やデータモデリングの延長として、業務オブジェクトとルールを整理することから始められます。
• ただし、全社規模で実装する場合は、専用基盤や運用体制が必要になります。

関連：日本企業は何から始めるべきか

Q6.
オントロジー設計は、どのくらいの期間・投資が必要ですか？

A6.いきなり全社で取り組む必要はありません。まずは1〜2つの業務オブジェクトから始めるのが現実的です。

• 顧客、契約、案件、在庫など、業務成果に直結する領域を選びます。
• 期間は対象業務の複雑さによりますが、編集部の実務経験や一般的なPoC設計の感覚では、まずは3〜6ヶ月単位で小さく検証し、対象範囲を広げていく進め方が現実的です。
• 重要なのは、最初から全社最適を狙うことではなく、AIが参照できる業務世界を一つずつ増やすことです。

今日のお持ち帰り3ポイント

• AIはコードを書けても、顧客システムの文脈までは知りません。
• この欠落を埋めるのが、オントロジー（業務世界の地図）です。
• AI駆動開発の次に問われるのは、コードを書く力ではなく、AIが理解できる業務世界を設計する力です。

主な参考サイト

合わせて読みたい

更新履歴