業務オントロジー入門 第6回｜Palantir、Fabric IQ、SAPはどう違う？ 〜製品の選び方と費用〜
オントロジーは、1社の製品名ではない
「オントロジーは、Palantirの製品の話だ」
多くの方が、そう考えていると思います。
でも、同じ発想の製品や仕組みはいくつもあると私たちは考えています。違いは、「操作をどこに置くか」にあります。
前回までは、製品の名前をほとんど出さずに、型の中身を説明してきました。今回は視野を広げ、「オントロジー」と呼ばれるものを並べて比べます。選ぶ前に知っておくべき費用とリスクも、ここで扱います。
この記事は、業務オントロジー入門シリーズ（全7回）の第6回です。シリーズの一覧はこちら。
製品の機能や提供状況は頻繁に変わります。この記事の製品に関する記述は2026年11月時点の各社の公式ドキュメントと発表に基づくもので、採用の判断の前には最新の公式ドキュメントで確認してください。また、優劣を判定するものではありません。
まずは、比べる軸から考えます。
比べる軸は、「名詞」と「動詞の置き場所」
このシリーズの軸は、名詞（もの・関係・状態）と動詞（業務操作）です。どの製品も名詞は持っています。違いが出るのは、動詞をどこに置くかです。
系統 | 名詞の定義 | 動詞の置き場所 | 中心にあるもの |
|---|---|---|---|
Palantir | Object Type、Link Type | 型の中（Action Type） | システムをまたぐ業務の運用 |
Microsoft Fabric IQ | Entity type、Relationship | 型の外（エージェント、Power Automateのフロー） | Microsoftのデータ基盤とBI |
SAP | Knowledge Graph、RAPのビジネスオブジェクト | SAPのアプリ側 | ERPの業務プロセス |
デジタルツイン（DTDL、AAS） | 資産の型、標準辞書への参照 | 機器への操作（CommandやOperation） | 設備・機器と、その計測値 |
セマンティックレイヤー | エンティティ、ディメンション | 無し（読む専用） | 指標の定義 |
記述・推論系（OWLなど。第1回の「記述する型」） | クラス、プロパティ、公理 | 無し（推論はするが操作はしない） | 厳密な意味の記述 |
このシリーズで説明してきた「業務操作まで型に含める」考え方を、最も徹底して製品にしているのがPalantirです。
ただし、それが唯一の正解という意味ではありません。1つずつ見ていきます。
Palantir：操作を型の中に持つ
Palantir Foundryのオントロジーは、名詞と動詞を1つの型の中で定義します。このシリーズの言葉との対応は、次のとおりです。
Palantirの言葉 | このシリーズの言葉 |
|---|---|
Object Type | もの |
Property | 項目 |
Link Type | 関係 |
Action Type | 業務操作 |
Submission criteria | 前提条件（と権限） |
Function | 計算ルール |
特徴は、ものの定義の下に、実際の業務データが常に結びついていることです。「受注」は概念であると同時に、基幹システムから流れ込む現在の受注データそのものでもあります。操作を実行すると、型の上のデータが更新され、必要に応じて元のシステムにも書き戻されます。
AIとの接続も、型の上で閉じています。AIに渡す道具は、ものの検索、計算ルール、操作の3つ。外部のAIエージェントから操作を呼ぶための仕組みも提供されており、呼び出しは利用者本人の権限で実行されます。
第1回から第5回までで説明した設計は、Palantirに限らず通用する考え方ですが、Palantirの構成を下敷きにしています。第3回の「受注を確定する」は、Palantirでは受注というObject Typeに対するAction Typeとして、前提条件と一緒に定義することになります。
Microsoft Fabric IQ：名詞は型、動詞はその外側
Fabric IQは、Microsoftがデータ基盤Fabricの上に置いた、業務の意味を扱う一連の機能です。2025年11月のMicrosoftの年次イベントIgniteで発表され、オントロジーはその中の1つの部品です。ほかに、Power BIのセマンティックモデル、グラフ、データエージェント、オペレーションエージェント、計画（Planning）が含まれます。
名詞の側は、Palantirと似た構成です。業務の概念（Entity type）、項目（Property）、関係（Relationship）を定義し、データに結びつけます。
特徴が2つあります。
1つは、データを動かさないこと。型は、既にあるデータの上に置かれる仮想的な層で、データは元の場所に残ります。
もう1つは、既存のBI資産から作れること。Power BIのセマンティックモデルから、テーブルを概念、列を項目、リレーションシップを関係、DAX（Power BIの計算式）で定義した指標も取り込めます。ただし、業務の言葉として通用する名前と定義にするには、人の見直しが要ります。
違いは、動詞の置き場所です。
私たちが確認した2026年11月時点の公式ドキュメントでは、オントロジーの構成要素は概念・項目・関係・指標・自然言語で書く業務ルールなどで、Palantirの操作にあたる「型の上のものを書き換える操作の定義」は見当たりません。業務を動かす役割は、オペレーションエージェントが担います。エージェントがデータを監視し、条件を満たすとTeamsで担当者に推奨を送り、担当者が承認するとFabricの処理やPower Automateのフローを実行します。
このシリーズの言葉で言えば、Fabric IQは名詞の層を強く持ち、動詞の層を外側に委ねています。第3回の「受注を確定する」を実現するなら、前提条件と効果をオペレーションエージェントやPower Automateのフロー、基幹のAPIのどこに置くかを、別に設計する必要があります。
なお、Fabric IQ自体は2026年6月の開発者イベントBuildで一般提供が発表されましたが、オントロジーの機能は2026年10月時点のMicrosoft Learnではプレビューと記載されています。提供状況は特に変わりやすいので、確認してください。
SAP：ERPの中の業務知識をAIへ。動詞はSAPのアプリ側
SAP Knowledge Graphは、SAPが2024年10月の技術イベントTechEdで発表した、自社の業務データの意味をAIに渡すためのグラフです。AIをSAP固有の業務の意味に結びつける仕組みとして、SAP DatasphereとAIアシスタントのJouleから使えるようにすると発表されました。
SAPのERPには、数十年分の業務プロセスの知識が組み込まれています。Knowledge Graphの強みは、その知識をそのままAIに渡せる点です。逆に言えば、主な対象はSAPのデータです。
では、SAPの動詞はどこにあるか。
Knowledge Graphではなく、SAPのアプリケーション開発の仕組み（RAP）のビジネスオブジェクトです。操作（Action）、保存してよいかの検証（Validation）、条件に応じて値を自動で決める仕組み（Determination）を、ものと一体で定義します。
名詞と動詞を一体で定義する点では、SAPのビジネスオブジェクトは業務の型と同じ発想です。第3回の「受注を確定する」は、SAPの受注がSAPの中で完結するなら、このビジネスオブジェクトのActionとして定義するのが自然です。違いは、それがSAPの中のアプリを作るための仕組みであるのに対し、Palantirは複数のシステムの上に共通の層を作る点です。
両者は競合というより、役割を分けつつあると私たちは見ています。2026年5月のSAPの年次イベントSapphireで、SAPはPalantirとの提携強化を発表しました。SAPのクラウドERPへの移行で、Palantir AIPをデータ移行の支援ツールとして使う取り組みです。
SAPが基幹業務の大半を占める会社では、SAPの中の業務はSAPの仕組みで、SAPとそれ以外をまたぐ判断は業務の型で、という分担が考えられます。
セマンティックレイヤーは、「読む専用」
BIや分析の分野で広がったセマンティックレイヤーは、業務の型と最も混同されやすいものです。
セマンティックレイヤーとは、データの上に、指標（売上、解約率）と分析の切り口（地域、月）と表の間の関係を定義し、「売上」を誰が計算しても同じ数字になるようにする層です。dbt、Power BI、Snowflake、Databricksが、それぞれの形で提供しています。
いずれも、指標を定義して問い合わせるためのものです。データを書き換えたり、業務の操作を実行したりする概念は定義されていません。
セマンティックレイヤー | 業務の型 | |
|---|---|---|
中心にあるもの | 指標（売上、件数、率） | 個々の業務のもの（この受注、この設備） |
典型的な問い | 先月の地域別の売上はいくらか | この受注を確定してよいか。確定するには何をすればよいか |
書き込み | 定義しない | 業務操作として定義する |
主な利用者 | 分析者、BIツール、分析を行うAI | 現場の担当者、業務アプリ、業務を代行するAI |
役割が違うので、片方でもう片方を置き換える必要はありません。
集計値の定義はセマンティックレイヤーに置く。個別の判断と操作は業務の型に置く。そして、両方で「顧客」「受注」の定義が食い違わないよう、第2回の社内共通語を共有する。
Palantirの公式ドキュメントも、オントロジーはセマンティックレイヤーではないと明記しています。
デジタルツインは、「モノ」の型
設備や機器などの物理的な資産を、デジタル上の写しとして記述する型もあります。Microsoftが仕様を公開するDTDLと、ドイツのインダストリー4.0の取り組みから生まれ、業界団体IDTAが仕様を公開するAAS（管理シェル）が代表です。
業務全体ではなく「モノ」に焦点を当てる点で、業務の型とは守備範囲が違います。
デジタルツイン | 業務の型 | |
|---|---|---|
中心にあるもの | 物理的な資産と、その計測値 | 業務の対象と、業務の操作 |
標準性 | 公開された仕様や国際規格。企業をまたいで交換できる | 製品固有の定義 |
動詞 | 機器への操作 | 業務の操作。権限と記録を伴う |
製造業では、両者は競合するより補い合います。設備の仕様と計測値はデジタルツインで標準的に記述し、その設備を使った保全計画や生産指示は業務の型で扱う、という組み合わせです。
ここまでで、系統の違いが見えました。では、どう選ぶか。
選び方の目安
選択の基準は製品の優劣ではなく、何を中心に業務を動かしたいかです。
やりたいこと | 向いている型 |
|---|---|
複数システムにまたがる判断と操作を、AIも含めて1か所で行いたい | 業務操作をオントロジーの中に持つ方式（操作内包型） |
Power BIなど既存のMicrosoft資産の上で、AIに業務データを理解させたい | Fabric IQ |
SAPの中の業務をAIで支援したい | SAP Knowledge GraphとRAP |
設備や機器の仕様・状態を、企業をまたいで標準的に交換したい | AAS、DTDL |
全社で数字の定義をそろえたい | セマンティックレイヤー |
業界をまたいで用語の意味を厳密に共有したい | 記述・推論系（金融業界の用語標準FIBOなど。第1回の「記述する型」） |
1つのシステムの中で完結する業務を改善したい | どれも使わない。既存システムの改修で足りることが多い |
最後の行が、いちばん見落とされます。
表の右側は「向いている型」であって、「導入すべき型」ではありません。どの型も、導入には費用と運用の負担がかかります。
導入の費用とリスク
ここまで、型で何ができるかを中心に見てきました。しかし、効果が負担を上回らなければ、導入する意味はありません。事前に検討すべき項目を並べます。
項目 | 中身 | 確認する問い |
|---|---|---|
独自形式と乗り換えの難しさ | 業務操作まで持つ型には、広く採用された共通の標準がない。製品の上に作った定義、データの接続、画面、権限の設定は、その製品の中でしか動かない | その製品を長く使い続ける前提が成り立つか。やめるときに何を作り直すか |
お金の費用 | 製品の利用料と計算資源の料金に加え、データの接続、名寄せ、整形の構築費がかかる。構築費は利用料より大きくなることも多い | 最初の1領域で、どれだけの効果（時間の短縮、判断の改善）が見込めるか |
人と組織 | データをつなぐ技術者、業務を説明できる担当者、定義を管理し続ける担当者が要る。部署をまたいで言葉を合意する手間もかかる | 定義の管理を誰が続けるか。部署間で定義が食い違ったとき、誰が決めるか |
運用の負担 | 元のシステムの項目が変われば、接続と定義を直す。書き戻しをするなら、照合と例外処理の運用も続く | 元のシステムの変更を、誰がいつ知り、どこを直すか |
もう1つのシステムが増えること | 型が一部の業務でしか使われないと、元のシステムと型の両方にデータがある状態が続き、かえって食い違いの原因になる | その領域の変更を、型の操作に寄せられるか |
効果が出るまでの時間 | 名詞を定義しただけでは、見るためのダッシュボードと変わらない。効果が出るのは、操作が業務で使われ始めてから | 最初の領域で、どの操作をいつから使い始めるか |
これらは、型をやめるべき理由ではなく、小さく始めるべき理由だと私たちは考えています。
1つの領域から始め、効果と負担を実際に測ってから広げれば、大きな失敗は避けられます。その手順は次回で扱います。
乗り換えのリスクには、もう1つ備えがあります。
製品に依存しない成果物を残す
製品が違っても、設計の中身は第2回と第3回で扱った内容に行き着きます。
業務を、IDを持つ「もの」と、状態を変える「業務操作」に切り分ける。言葉を1語1義にそろえ、意味の範囲を明示する。状態遷移と前提条件を明らかにする。システム間のIDを名寄せし、項目ごとに正本を決める。
これができていれば、製品を乗り換えても、設計の考え方と定義表はそのまま使えます。逆に、設計ができていなければ、どの製品を使ってもうまくいきません。
だから、業務の設計を製品の外にも残しておきます。
定義表、状態遷移図、判断の表。この3つは、どの製品にも持っていけます。製品の中にしか設計が無い状態を避けることが、乗り換えへの最も現実的な備えです。
推進担当が押さえる要点
- 「オントロジー」と呼ばれるものは複数あり、違いは動詞（業務操作）をどこに置くか
- Palantirは操作を型の中に持つ。Fabric IQは名詞を型に持ち、動詞をエージェントとフローに委ねる。SAPは動詞をSAPのアプリ側に持つ
- セマンティックレイヤーは読む専用で、業務の型とは役割が違う。置き換えず、言葉を共有して組み合わせる
- 1システムで完結する業務なら、どれも使わないのが正解のことが多い
- 費用とリスクは6項目。独自形式、構築費、人、運用、もう1つのシステム、効果が出るまでの時間
- 定義表・状態遷移図・判断の表を製品の外に残す。それが乗り換えへの備えになる
選ぶ前に、設計を持つ
ここまで製品を比べてきましたが、選ぶべき製品は、設計を持ってから決まります。
もの・関係・状態・操作が定義表にあり、正本が項目ごとに決まっていれば、どの製品が自社に合うかは表を見れば分かります。逆に、定義表が無いまま製品を選ぶと、製品の都合で設計が決まります。
次回は最終回です。最初の1業務を型にする手順と、2枚の定義表、よくある失敗をまとめます。
シリーズの目次
- 業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか
- 業務オントロジー入門 第2回｜業務から「もの」を切り出す
- 業務オントロジー入門 第3回｜業務操作を定義する
- 業務オントロジー入門 第4回｜基幹システムは置き換えない
- 業務オントロジー入門 第5回｜型の上でAIはどう動くか
- 業務オントロジー入門 第6回｜Palantir、Fabric IQ、SAPはどう違う？（この記事）
- 業務オントロジー入門 第7回｜最初の1業務を型にする
関連記事
- AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：統制を置く場所の選択肢
- AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方：審査で聞かれることと、選び方の基準
参考資料
- Palantir「The Ontology system」（Architecture Center。「The Ontology is not a "semantic layer"」の記述 （2026年11月1日確認））、「Overview • Ontology」「Core concepts」
- Microsoft Fabric Blog「From Data Platform to Intelligence Platform: Introducing Microsoft Fabric IQ」（2025年11月）
- Microsoft Azure Blog「Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases」（2026年6月2日。Fabric IQ の一般提供）
- Microsoft Learn「What is Fabric IQ?」「What Is Ontology (Preview)?」「Generate Ontology (Preview) from Semantic Models」「Operations Agent Actions」（2026年10月版 （2026年11月1日確認））
- SAP News「SAP Supercharges Copilot Joule with Collaborative Capabilities to Ignite Enterprise AI Revolution」（2024年10月8日。SAP Knowledge Graph の発表）
- SAP News「SAP and Palantir Enhance Partnership with AI-Supported Data Migration Tooling to Accelerate Enterprise Cloud ERP Transformation for Autonomous Enterprises」（2026年5月12日）
- SAP Learning「Analyzing a Business Object」（RAP のビヘイビア定義）
- dbt「Semantic layer GA」（2023年10月）、Microsoft Learn「New name for Power BI datasets」（2023年11月）、Snowflake Release Notes（Semantic Views、2025年6月・8月）、Databricks Release Notes（Metric views、2025年5月）
- IDTA「AAS Specifications」、IEC 63278-1:2023（2023年12月）
- Microsoft「Digital Twins Definition Language (DTDL), Version 3」（GitHub）
Askhubについて
Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。
この記事の軸で言えば、Askhubは業務操作をオントロジーの中に持つ操作内包型にあたり、国産の基幹システムへの書き戻しまで含みます。AIエージェントの権限設計で並べた統制の層のうち、「業務の型を持つ基盤」です。本文の比較表に自社を入れていないのは、製品の優劣ではなく型の違いを伝えるための記事だからです。
※Askhubのサービスに関する記載は、2026年11月時点の情報です。
