AIエージェントは型の上でどう動くか 〜業務オントロジー入門 第5回〜

賢いAIでも、業務の意味は自分で埋められない

新人に設計書だけを渡して、「あとは自分で理解して」と仕事を任せる会社はありません。ところがAIには、それと同じことをしている場面が多くあります。

AIは推測で補います。推測は、たいてい正しく、ときどき外れます。外れたときに記録が変わるのが、AIに業務を任せるということです。

業務オントロジー（業務の型）は、AIにとっての地図と操作盤です。前回までに決めた型の上で、AIエージェントがどう動くかを扱います。

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

まずは、AIに何を渡すのかから考えます。

AIに渡すのは、3種類の道具だけ

AIエージェントは、「道具」を呼び出しながら仕事をします。道具とは、AIが呼び出せる機能のことです。

業務の型の上では、道具は3種類に限られます。

渡さないものも、はっきりしています。基幹システムのAPIそのもの、データベースへの接続、鍵。

AIがどんな指示を受けても、一覧にない操作は呼び出せません。一覧にある操作も、前提条件・権限・承認を満たさなければ、効果は確定しません。

道具を3種類に限ると、AIの仕事はどう変わるのでしょうか。

テーブルを推測しなくてよくなる

型が無い場合を考えます。

「顧客Aの受注で、確定済みなのにまだ出荷されていないものは？」と聞かれたAIは、テーブルの一覧を眺め、受注テーブルと出荷テーブルの関係を推測し、問い合わせの文（SQL）を組み立てます。

「shipped_at」が空なら未出荷だろう。キャンセル済みの行は……列名からは分からない。推測で補います。

型がある場合。AIには、「受注」に「状態」という項目があり、取りうる値は「受付済・与信確認中・確定・出荷済・請求済・保留・キャンセル」である、と渡されています。

AIは「顧客Aの受注のうち、状態が確定のもの」を探すだけです。推測の余地が、ほとんどありません。

名前と説明が付いた業務のものと、許された操作だけが渡される。これが、型がAIの地図になるということです。

地図があっても、AIは誤ります。だから、操作盤の側に関門があります。

AIの変更も、人と同じ関門を通る

第3回で、記録を変えるのは操作だけで、計算ルールもAIも操作を通る、と説明しました。

AIが「受注を確定しよう」と決めても、実行されるのは「受注を確定する」という操作です。前提条件は、人が実行するときと同じ条件で、同じ場所で判定されます。

だから、AIの操作は、人と同じ権限・条件・記録の管理下に置かれます。

AIのために別の統制を作る必要はありません。人のために作った統制が、そのまま効きます。

「この操作はしないで」とAIへの指示に書くだけでは、乗っ取られたときや誤解したときに破られます。判定するのは、AIの外にある書き込みの関門です（AIエージェントの権限設計）。

ただ、ここで1つ、見落としやすいことがあります。

見る権限と変える権限は、別もの

型の上では、「誰が何を見られるか」を、ものの単位と項目の単位で決められます。東日本の担当者には東日本の受注だけを見せる。原価の項目は、経理にだけ見せる。

この閲覧の制限は、書き込みを守りません。

東日本の受注しか見られない担当者でも、「受注を確定する」操作の前提条件に地域の制限が無ければ、受注番号を直接指定して西日本の受注を変更できてしまう可能性があります。画面に出ていなくても、操作は呼べるからです。

誰が何を変えてよいかは、閲覧権限とは別に、操作の前提条件に明示的に書きます。

AIについても同じです。閲覧の制限は、AIが読んだ内容から生成した出力や、AIが組み立てた変更内容までは制御しません。

AIに渡すデータの範囲は、閲覧の制限で絞る。AIにどの変更を許すかは、前提条件で絞る。2つは別の仕組みで、両方が要ります。

職務分掌（1人に権限を集中させない決まり）も、ここで書きます。「起票した担当者自身は、その承認をしない」は、承認の操作の前提条件です。

関門がそろったところで、どこまでAIに任せるかを決めます。

任せ方は、3段階

AIに任せる範囲は、操作の影響の大きさと、取り消しやすさで決めます。

影響が大きい操作や判断が曖昧な操作は、提案として保留する方式から始めます。Palantirも2026年4月28日のブログで、例に挙げた構成では既定でAIは操作を下書きするだけにし、人が最終確認してから確定すると説明しています。

任せ方は、操作ごとに決めます。第7回の業務操作の定義表に「AIの扱い」という欄を設けるのは、このためです。

提案と承認の記録がたまったら、人の判断が安定している範囲から自動承認ルールに移します。その進め方はAIエージェントの承認はどの粒度で？で整理しています。

任せる範囲を決めたら、もう1つ決めておくことがあります。型そのものの変え方です。

型の定義そのものも、変更管理する

型の定義を変えることは、業務の言葉と操作を変えることです。

「受注を確定する」の前提条件を緩めれば、AIが確定できる受注が増えます。「出荷」の定義を変えれば、全部門の画面とAIの振る舞いが変わります。

だから、定義の変更も承認の対象にします。

やり方は、ソフトウェア開発の変更管理に似ています。本番の定義とは別の下書きで直し、変更した内容を関係者がレビューし、承認してから本番に反映する。

Palantirはこの仕組みを、オントロジーのブランチ（本番とは別の下書き）として提供し、変更はプロポーザル（変更の提案）としてレビューされます。製品が何であれ、必要なのは次の3つです。

本番の定義を、誰も直接は変えられないこと。変更の内容と理由が残ること。その業務の言葉に責任を持つ人が承認すること。

定義のレビューは、「業務の言葉が変わることを、関係者が合意する場」として運用するとよいと私たちは考えています。第2回で決めた社内共通語を、ここで守り続けます。

定義が守られ、操作が記録されていると、もう1つできることがあります。

動かした記録から、実際の業務を見る

第2回と第3回で描いたのは、業務の「あるべき姿」です。

操作の記録がたまると、「実際の姿」が見えます。誰がいつどの操作で何を変えたかの記録を時系列に並べれば、実際の業務の流れが復元できます。この分析をプロセスマイニングと呼びます。

あるべき姿と実際の姿を比べると、ずれが見つかります。

「保留」から「与信確認中」に戻した受注のうち、半分が翌日もう一度「保留」になっている。保留の基準が、人によって違うのかもしれない。

「受注を取り消す」が、出荷指示の直後に集中している。出荷の前に、確認の操作が1つ足りないのかもしれない。

1つ注意があります。受注番号ごとに並べると、歪むことがあります。

1件の受注が分納で3回に分かれている場合、受注番号ごとに並べると、同じ出荷作業を3回繰り返したように見えます。本当は、3つの別の出荷指示が1回ずつ完了しただけです。

型があると、この歪みを避けられます。出荷の完了は出荷指示の出来事として記録され、受注との関係も残っているので、受注ごとに数えるか出荷指示ごとに数えるかを選べるからです。

実務では、この循環を回すことになります。

1. 出来事を洗い出し、あるべき業務を描いて、操作を定義する（第2回、第3回）
2. 操作を通して業務を行い、記録がたまる
3. 記録から実際の業務を描き、あるべき姿とのずれを見つける
4. ずれをもとに、操作の条件やAIに任せる範囲を見直す

型は、作って終わりではありません。動かした記録が、次の型を作ります。

ここまで、型がAIに何を保証するかを見てきました。最後に、保証しないことを確かめておきます。

それでも、人に残る仕事がある

AIエージェントの権限設計で挙げた3つは、型があっても残ります。

定義と見直し。前提条件や承認の基準が間違っていれば、システムは間違った基準を正確に守ります。

定義にない例外。型に合わない案件は、必ず出ます。AIには「できません」と止まらせ、人が引き取る道を用意します。

条件を満たした誤り。別の顧客の受注を確定するような誤判断は、前提条件だけでは防げません。承認と判断ログで扱います。

型は、AIを縛るためのものというより、安心して任せる範囲を広げるための道具です。人に残る仕事を減らすのではなく、人の仕事を「確認」から「定義と例外」に移します。

推進担当が押さえる要点

• 業務オントロジー（業務の型）がAIに渡すのは、探す・計算する・動かすの3種類の道具だけ。システムのAPI（システム同士が直接やり取りする窓口）や鍵は渡さない
• 型があると、AIはテーブルを推測しなくてよくなる。名前と説明が付いたものと、許された操作だけを使う
• AIの変更も、人と同じ操作を通り、同じ関門で判定される。AI専用の統制は要らない
• 見る権限と変える権限は別。変えてよい範囲は、閲覧権限ではなく操作の前提条件に書く
• 任せ方は、自動実行・確認してから・提案として保留の3段階。操作ごとに決め、影響の大きいものは保留から始める
• 型の定義の変更も承認の対象にする。操作の記録から実際の業務を見て、型を見直す

オントロジーがあるから、AIに任せられる

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

型は、AIが読む地図と、AIが触る操作盤を、会社が決めたとおりの形にします。地図に無いものは探せず、操作盤に無い操作はできない。

ここまでの4回で、型の中身と、既存システムとの両立、AIとの関係を見てきました。

次回は視野を広げます。Palantir、Microsoft Fabric IQ、SAP、セマンティックレイヤー。同じ「オントロジー」と呼ばれるものがどう違い、どう選ぶか、導入の費用とリスクは何かを扱います。

シリーズの目次

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

関連記事

• AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：書き込みの関門と、人に残る3つの仕事
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：判断ログから自動承認ルールへ
• AIエージェントは誰の権限で動くのか｜ID・代理実行・社内検索の落とし穴：AIの操作を人と区別して記録する方法
• AIエージェントの監視と停止：改ざんできない記録と、止める手段

参考資料

• Palantir「Connecting Agents to Decisions」（Palantir Blog、2026年4月28日、https://blog.palantir.com/connecting-agents-to-decisions-277dee8ddb40 （2026年11月1日確認））
• Palantir「Overview • Ontology」「Ontology MCP • Overview」（オブジェクト・リンク・アクションをAIの道具として提供する仕組み。Ontology MCP は 2026年6月に一般提供 （2026年11月1日確認））
• Palantir「Ontologies • Branching the ontology • Overview」「Review ontology proposals」（定義の変更管理。https://palantir.com/docs/foundry/ontologies/branching-ontology/ （2026年11月1日確認））
• Wil van der Aalst, "Object-Centric Process Mining: Dealing with Divergence and Convergence in Event Data," SEFM 2019, LNCS 11724, pp. 3–25（1つのケースに押し込むと起きる歪み）

Askhubについて

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

この記事で説明した「AIの変更も人と同じ関門を通る」設計は、Askhubの前提です。AIの提案と人の承認・却下は判断ログに残り、任せる範囲を広げるときの根拠になります。

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

関連するページ：AIエージェント、承認

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