業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか 〜AIに業務を任せる会社の前提〜

「データを整えて渡せば、AIに任せられる」とは限らない

「社内のデータを整備してAIに渡せば、業務は任せられる」

多くの方が、そう考えていると思います。

でも、それだけでは足りないと私たちは考えています。

テーブル名と列名だけを渡されたAIは、業務の意味の多くを推測で補うからです。

業務オントロジーとは、業務に出てくるもの・関係・状態・許される操作を、人とシステムが同じ意味で扱えるように、会社として明示的に定めたものです。

このシリーズでは、これを「業務の型」と呼びます。オントロジーという言葉は硬いので、「どの画面からでもAIからでも、業務を同じ形で扱うための枠」という意味で、型と呼ぶことにします。

この記事は、業務オントロジー入門シリーズ（全7回）の第1回です。シリーズの一覧はこちら。

まずは、なぜ今この話が要るのかから考えます。

同じ「顧客」が、システムごとに別物

企業のデータは、システムごとの都合で作られています。

同じ「顧客」でも、CRM（顧客管理システム）では商談の相手、基幹システムでは請求先、物流システムでは届け先を指します。IDも項目名も違います。

テーブルの設計は「どう保存するか」を優先して決まります。業務の担当者が使う言葉とは、一致しません。

受注業務で考えてみます。

営業がCRMで商談を進め、基幹システムに受注を登録する。倉庫が物流システムで出荷し、経理が基幹システムで請求を起こす。

「あの受注、もう出荷された？」という問いに答えるには、3つの画面を見比べる必要があります。

CRMの商談番号と基幹の受注番号の対応を知っているのは、担当者だけ。「出荷」が倉庫を出た時点なのか、顧客に届いた時点なのかも、部門によって違います。

この読み替えを、人が毎回、頭の中でしています。

問題は昔からありました。それでも、業務は回っていました。

では、何が変わったのでしょうか。

放置できなくなった2つの変化

1つは、システムをまたぐ判断が増えたことです。

需給の調整、与信の判断、設備の保全計画。こうした判断は、複数のシステムのデータを同時に見ないとできません。システムごとの定義の違いを、判断のたびに人が読み替えています。

もう1つは、AIエージェントの登場です。質問に答えるだけでなく、指示を受けて自分でシステムを操作し、仕事を進めるAIのことです。

社員に配る生成AIの多くは、質問に答え、下書きを作るところまでを担ってきました。間違えても、人が読んで直せば済みます。

ところが、業務の工数を本当に減らそうとすると、AIに記録の更新まで任せたくなります。

このとき、AIに渡すのがテーブル名と列名だけだと、どうなるか。

「shipped_at」という列を見て、AIは「出荷日」だと推測します。それが倉庫を出た日なのか、届いた日なのかは、列名からは分かりません。「受注」のテーブルに、キャンセル済みの行も混ざっていることも、列名からは分かりません。

人の担当者なら、業務の知識で補います。AIには、その「書かれていない知識」がありません。

そこで、システムの上に「業務の意味を一元的に定義する層」を置く考え方が広がりました。

米国のデータ基盤企業Palantir（パランティア）や、Microsoftのデータ基盤Fabric（Fabric IQ）は、この層を「オントロジー」と呼んでいます。

では、業務の型とは、具体的に何を決めるものなのでしょうか。

業務オントロジーとは、もの・関係・状態・操作を会社として定めたもの

「オントロジー」は、もともと哲学や情報科学の言葉です。

情報科学では、トム・グルーバーが1993年に示した「概念化の明示的な仕様」という定義がよく引かれます。平たく言えば、「何が存在し、どう関係するかを、はっきり書いたもの」です。

このシリーズでは学術的な議論には立ち入らず、この定義に「許される操作」を足したものを、実務上の定義として使います。

型は、4つの要素でできています。

もの・関係・状態までは、データの設計をしたことがある方なら、見覚えがあると思います。

このシリーズの立場で大事なのは、4つ目の業務操作まで型に含めることです。

「受注の状態を『確定』にできるのは誰で、どんな条件のときか」を、データの定義と同じ場所に書きます。

受注の状態の欄を、直接「確定」に書き換える道は作りません。確定になるのは、「受注を確定する」という操作が、条件を通ったときだけです。

ただ、「オントロジー」の周りには、似た目的を持つ言葉がたくさんあります。

似た言葉は「答える問い」で見分ける

用語集、データモデル、ナレッジグラフ、セマンティックレイヤー。どれも「業務の意味をそろえる」ための道具に見えます。

違いは、「何に答えるためのものか」で見分けるとよいと私たちは考えています。

関係を整理すると、こうなります。

用語集は、型の出発点です。言葉の定義が文章で書かれています。型は、その定義をシステムが読める形にしたものです。

データモデルは、保存の都合で決まります。型は、業務の単位で決まります。両者は一致しないことが多く、だからこそ型が要ります。

ナレッジグラフは、型に従う実際のデータです。設計図と建物の関係に近い。

セマンティックレイヤーは、「売上」のような数字の計算方法をそろえる層です。業務の型とよく混同されるので、第6回で比べます。

もう1つ、資料を読むときに混乱しやすい区別があります。

「記述する型」と「動かす型」がある

「オントロジー」という言葉は、出自の違う2つの流れで使われています。

1つは、記述する型です。1980年代のAI研究から、Web上で意味を共有する技術（セマンティックウェブ）へと続く流れで、金融や医療の業界標準にも使われています。

目的は、世界を正確に記述し、そこから新しい事実を導くこと。書かれていないことは「不明」として扱います。

もう1つは、動かす型です。データベースの設計図（ER図）から、業務の言葉でソフトウェアを設計する考え方（ドメイン駆動設計）を経て、PalantirやFabric IQに続く流れです。

目的は、業務を動かすこと。判断し、データを書き換えます。登録されていないものは「存在しない」として扱います。

違いが出る例を1つ挙げます。

「顧客Aに未払いの請求はあるか」と聞かれたとき。動かす型は、データに無ければ「無い」と答えます。記述する型は、「無いとは言い切れない」と答えます。

業務システムは、登録されていないものは存在しない前提で動いています。だからこのシリーズは、動かす型を扱います。

業界をまたいで用語の意味を厳密に共有したい場合は、記述する型が向いています。その使い分けは第6回で触れます。

では、動かす型があると、業務は何が変わるのでしょうか。

型があると、業務はこう変わる

営業用の画面、倉庫用の画面、AIエージェント。この3つが、同じ「受注」のデータを使うとします。

型が無い場合、3つはそれぞれ、「どの表とどの表をつなぐか」「誰にどの行を見せるか」「どんなときに書き換えてよいか」を、自分のプログラムの中に持ちます。

3か所に同じルールが書かれます。1か所だけ直し忘れると、画面によって答えが変わります。

型がある場合、これらは「受注」という1つの定義の側に持たせます。

受注とは何か。顧客とどうつながるか。誰が見られるか。誰が、どんな条件で、何を変えてよいか。

画面もAIも、その定義を読みに行きます。誰がどこから触っても、同じルールが効きます。

データの表現力そのものは、型がデータベースより優れているわけではありません。型の中身も、結局は表と列に保存されます。

違いは、1つの定義に、つながり・権限・操作がまとめてぶら下がり、それがすべての利用先で強制されることにあります。

推進担当者の目線で言い直すと、変わるのは3つです。

1つ目。読み替えが消えます。「出荷」がどの時点を指すかを、人に聞いて回らなくてよくなります。型に書いてあるからです。

2つ目。ルールが1か所になります。新しい画面やAIを足すとき、ルールを書き直しません。定義を読ませるだけです。

3つ目。AIに渡すものが変わります。「受注テーブルを更新してよい」ではなく、「受注を確定する」という操作を渡します。AIがどんな指示を受けても、定義にない操作は呼び出せません。

3つ目は、AIに書き込みを任せるときの統制の土台になります。考え方はAIエージェントの権限設計で整理しています。

ただ、型は万能ではありません。

型が要らない場面もある

業務の型を作るには、部門をまたいで言葉の定義を合意し、データをつなぎ、定義を管理し続ける人が要ります。

その手間に見合わない場面もあります。

1つのシステムの中で完結する業務。既存システムの改修で足りることが多い。

AIに読み取りだけをさせる場面。要約や下書きなら、記録は変わりません。

書き込んでも影響が小さく、すぐ戻せる業務。メモの追記やタグ付けなら、型を作るより運用ルールで足ります。

逆に、型の価値が大きくなるのは、次の条件が重なるときです。

データの出所が多い。使う人・画面・AIが多い。そして、見る権限と変える権限を、すべての利用先でそろえたい。

受注業務は、営業・経理・倉庫の3部門と、CRM・基幹・物流の3システムにまたがります。このシリーズが通し例に受注を選んだのは、そのためです。

導入の費用とリスクは第6回で、小さく始める手順は第7回で扱います。

推進担当が押さえる要点

• 業務の型とは、もの・関係・状態・業務操作を、会社として明示的に定めたもの。4つ目の操作まで含めるのが、このシリーズの立場
• 問題の根は、システムごとに違う「顧客」「出荷」の読み替えを、人が毎回していること。AIには、その読み替えの知識が無い
• 用語集・データモデル・ナレッジグラフ・セマンティックレイヤーとは、「答える問い」が違う。型が答えるのは「何があり、誰が何をしてよいか」
• 型の価値は、新しい表現力ではなく、1つの定義に権限と操作がぶら下がり、画面からでもAIからでも同じルールが効くこと
• 1システムで完結する業務や、読むだけの用途なら、型は要らない

型を決めることから、任せる範囲は広がる

AIに業務を任せるとは、AIの出力がそのまま会社の記録になるということです。

そのとき問われるのは「AIは賢いか」ではなく、「AIに何をさせてよいか」。その答えを置く場所が、業務の型です。

次回は、型の名詞の側を扱います。業務から「もの」を切り出し、1件が何を表すかを決める方法です。

シリーズの目次

1. 業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか（この記事）
2. 業務オントロジー入門 第2回｜業務から「もの」を切り出す
3. 業務オントロジー入門 第3回｜業務操作を定義する
4. 業務オントロジー入門 第4回｜基幹システムは置き換えない
5. 業務オントロジー入門 第5回｜型の上でAIはどう動くか
6. 業務オントロジー入門 第6回｜Palantir、Fabric IQ、SAPはどう違う？
7. 業務オントロジー入門 第7回｜最初の1業務を型にする

関連記事

• AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：業務操作の5つの項目と、統制を置く場所の選び方
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：判断ログを根拠に、任せる範囲を広げる
• AIエージェントのセキュリティ全体像：AIに書き込みを任せるときの統制の全体像

参考資料

• Thomas R. Gruber, "A Translation Approach to Portable Ontology Specifications," Knowledge Acquisition 5(2), 1993（https://tomgruber.org/writing/ontolingua-kaj-1993/ （2026年11月1日確認））
• Palantir「Overview • Ontology」（https://www.palantir.com/docs/foundry/ontology/overview/ （2026年11月1日確認））
• Microsoft Fabric Blog「From Data Platform to Intelligence Platform: Introducing Microsoft Fabric IQ」（2025年11月、https://blog.fabric.microsoft.com/en-US/blog/from-data-platform-to-intelligence-platform-introducing-microsoft-fabric-iq/ （2026年11月1日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは「動かす型」を持つ基盤にあたります。型を決めたデータへの書き込みは、画面からでもAIからでも、サーバー側の1か所で同じ判定を通ります。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。