なぜ今、業務に「型」が要るのか 〜業務オントロジー入門 第1回〜

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

社内のデータを整備して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. AIエージェントは型の上でどう動くか 〜業務オントロジー入門 第5回〜
6. Palantir、Fabric IQ、SAPはどう違う？ 〜業務オントロジー入門 第6回〜
7. 最初の1業務を型にする 〜業務オントロジー入門 第7回〜

関連記事

• 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月時点の情報です。

関連するページ：製品の全体像、AIエージェント

自社の業務をどう型（オントロジー）にするか相談したい方は、お問い合わせからご連絡ください。業務の洗い出しから定義表づくりまで、伴走支援のコンサルタントが一緒に進めます。