業務オントロジー入門 第3回｜業務操作を定義する 〜状態遷移図から「やっていい変更」を書き出す〜

名詞だけでは、ダッシュボードと変わらない

「ものと関係を定義すれば、AIは正しく業務を扱える」

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

でも、それでは業務は変わらないと私たちは考えています。

名詞だけの型は、見るためのダッシュボードと変わらないからです。業務を動かすのは、操作です。

前回、受注業務のもの7つと関係6本を決めました。今回はその上に、業務オントロジー（業務の型）の動詞の側、つまり業務操作を定義します。

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

まずは、操作がどこから見えてくるのかから考えます。

業務が変わるのは、状態が変わるとき

受注は、受け付けてから請求まで、状態が変わり続けます。

状態の移り変わりを図にしたものを、状態遷移図と呼びます。受注なら、こうなります（説明のための例です）。

• 受付済 →（与信確認を依頼する）→ 与信確認中
• 与信確認中 →（受注を確定する）→ 確定
• 与信確認中 →（保留にする）→ 保留
• 保留 →（保留を承認する）→ 与信確認中
• 確定 →（出荷を完了する）→ 出荷済
• 出荷済 →（請求を発行する）→ 請求済
• 受付済 →（受注を取り消す）→ キャンセル
• 確定 →（受注を取り消す）→ キャンセル
• 保留 →（受注を取り消す）→ キャンセル

箱が状態、矢印が状態を変える操作です。

この図は、型の設計で最も役に立つ図の1つだと私たちは考えています。読み取れることが3つあるからです。

矢印1本が業務操作1つ、矢印が無い操作は禁止

1つ目。矢印1本が、業務操作1つの候補になります。上の図からは「与信確認を依頼する」「受注を確定する」など、7種類の操作が読み取れます（「受注を取り消す」は3本の矢印で1つの操作です）。

2つ目。矢印が出ていない操作は、禁止です。「出荷済」から「キャンセル」への矢印が無いので、出荷後の取り消しはできません。これが、操作を実行してよい条件になります。

3つ目。状態は、ものの項目になります。受注に「状態」という項目を持たせ、取りうる値を図の状態に限定します。

ここで大事なのは、状態の欄を直接書き換える道を作らないことです。

受注が「確定」になるのは、「受注を確定する」という操作が条件を通ったときだけ。画面からでもAIからでも、操作を通らずに「確定」と書き込むことはできない。

この性質があるから、図に無い状態は、業務の中に現れません。

では、矢印1本を、どう定義に落とすのでしょうか。

業務操作は、5つの項目で定める

AIエージェントの権限設計で、業務操作は5つの項目で定めると説明しました。状態遷移図の要素は、この5つにそのまま対応します。

前提条件は、「与信確認中である」のような状態の条件です。

承認は、人の許可です。前提条件が機械で判定できる条件なのに対し、承認は人（または人が確定した自動承認ルール）が判定します。

取り消しが逆向きの矢印だ、という見方は便利です。図に戻る矢印が無ければ、その操作は取り消せない。それは、操作を定義する前に分かっておくべきことです。

受注業務の操作を、まとめて表にします。図の矢印に出ない操作が2つあります。受注を新しく作る「受注を登録する」と、受注の状態は変えずに別のもの（出荷指示）を作る「出荷を指示する」です。この2つは表で足します。

この表の中で、AIに任せるときにいちばん効いてくるのが「前提条件」の列です。

判断はAIが、判定は機械が

AIエージェントに業務を任せる場面を考えます。

AIの出力は確率的です。同じ質問をしても、毎回少し違う答えが返ることがあります。もっともらしい誤りもします。

AIへの指示に「与信確認が済んでいない受注は確定しないこと」と書いても、それが必ず守られる保証はありません。取り違えることも、メールや文書に仕込まれた指示にAIが従ってしまう攻撃（プロンプトインジェクション）に乗っ取られることもあります（プロンプトインジェクションとは？）。

業務操作を使うと、役割を分けられます。

駅の自動改札にたとえると分かりやすい。どの改札を通るかは人が決めます。でも、通ってよいかは改札機が切符やICカードを見て判定します。人がどれだけ急いでいても、有効な切符が無ければ扉は開きません。

AIは、改札を選ぶ人です。「この受注を確定しよう」と決めるのはAIでかまいません。

前提条件は、改札機です。「状態が与信確認中で、与信残高が0以上か承認記録がある」という条件を、同じ入力なら必ず同じ結果になる形で判定します。

AIが判断を誤っても、条件を満たさない操作は通りません。人の担当者が誤った場合も同じです。

安全性を、AIの賢さに頼らない。型と条件という、毎回同じ答えを出す仕組みに置く。

これが、わざわざ操作を型として定義する理由です。

だから、操作を設計するときの順番も決まってきます。

「してはいけない変更」から書く

操作を設計するとき、「何ができるようにするか」から考えたくなります。

私たちは、逆の順番を勧めています。先に、「どの状態で、誰が、何をしてはいけないか」を書き出す。

業務操作が守っているものを並べると、6つになります。

「してはいけないこと」を6つの枠に落とすと、残った範囲が「してよい変更」になります。

操作の定義から入力画面を作れる、同じ操作を複数の画面やAIから呼べる。そうした便利さは、副産物です。業務操作は、業務アプリを速く作るための機能である前に、起きてはいけない変更を起こさないための、守りの仕組みです。

守る範囲を決めるとき、もう1つ決めることがあります。1つの操作が、どこまで変えてよいかです。

1つの操作が変えるのは、1つのまとまりまで

受注と受注明細は、「受注の合計金額は明細の合計と一致する」というルールで結ばれています。

このルールを守るには、明細だけを勝手に書き換えさせず、必ず受注を通して変更させる必要があります。

常に一緒に整合性を保たなければならないものの集まりを、ソフトウェア設計では集約と呼びます。このシリーズでは「一緒に整合を保つまとまり」と呼びます。

原則は、1つの操作が書き換えてよい範囲を、1つのまとまりに収めることです。

「受注を確定する」操作が、ついでに在庫や請求まで書き換えるようにすると、失敗したときにどこまで戻すかが分からなくなります。

受注と出荷指示は、別のまとまりです。だから、さきほどの表では「受注を確定する」と「出荷を指示する」を別の操作にしています。まとまりをまたぐ処理は、操作を分けてつなぎます。

ここまでで、操作の形は決まりました。残るのは、前提条件の中身です。

判断のルールは表にして、業務担当者と合意する

「与信枠に収まるか」のような判断は、言葉で書くと曖昧になりがちです。

私たちは、判断を表にして、業務担当者と合意することを勧めています（数字は説明のための例です）。

与信残高は、与信枠から、既存の未収金とこの受注の金額を引いた値とします。

表にすると、2つのことが見えます。

1つは、漏れです。どの行にも当てはまらない入力があれば、判定が定まらない。「与信枠が未設定で、与信残高が計算できないとき」は、この表では決まりません。

もう1つは、合意のしやすさです。判断のルールを表として業務担当者と確認しておけば、システムの正しさを業務の言葉で確かめられます。

この表の書き方には、DMNという標準の記法があります（参考資料）。ただ、最初は普通の表で十分です。

表の中に出てくる「与信残高」は、計算です。計算は、操作から分けておきます。

計算は、操作から分けておく

与信残高の計算は、「受注を確定する」操作の前提条件でも、「保留にする」操作の前提条件でも使います。

こうした計算は、操作の中に書かず、「計算ルール」として独立させます。

計算ルールは、同じ入力なら同じ答えを返し、それ自体は記録を変えません。だから、テストしやすく、何度呼んでも安全です。

記録を変えるのは、操作だけです。計算ルールは記録を変えず、AIも記録を変えるには操作を通ります。

この性質が、次回以降の権限と記録、AIの安全設計の土台になります。

最後に、操作のたびに残るものを確かめておきます。

記録は、操作のたびに残る

操作を実行するたびに、誰が、いつ、どの操作で、何を変えたかの記録が残ります。

AIエージェントの承認はどの粒度で？で説明した判断ログは、この記録に、AIの提案の根拠と人の承認・却下の理由を加えたものです。

ここで、前回の「承認記録」を思い出してください。

誰がいつ承認したかを残すだけなら、操作の記録で足りる場合があります。

承認のコメントや承認の条件のように、業務上の意味を持つ情報を扱うなら、独立したものにします。

判断の基準は前回と同じです。「後から、その出来事について問い合わせるか」。

推進担当が押さえる要点

• 業務オントロジー（業務の型）の動詞にあたる業務操作は、状態遷移図から読み取る。矢印1本が操作1つ、矢印が無い操作は禁止、状態は項目になる
• 状態の欄を直接書き換える道は作らない。状態が変わるのは、操作が条件を通ったときだけ
• 操作は前提条件・権限・承認・効果・取り消しの5項目で定める。取り消しは逆向きの矢印で、無ければ取り消せない
• AIは操作を選ぶ人、前提条件は改札機。安全性をAIの賢さではなく、毎回同じ答えを出す判定に置く
• 設計は「してはいけない変更」から。1つの操作が変えるのは、一緒に整合を保つ1つのまとまりまで
• 判断のルールは表にして業務担当者と合意し、計算は操作から分ける

操作を定義して初めて、オントロジーは業務を動かす

もの・関係・状態・業務操作。4つの要素がそろうと、型は「見るもの」から「動かすもの」に変わります。

AIに渡すのは、この操作の一覧です。システムのAPIではなく、「受注を確定する」という業務の言葉で、条件付きの操作を渡します。

ただ、ここまでの話は、型の中で閉じています。実際の会社には、基幹システムやCRMが既にあり、そこに記録があります。

次回は、既存システムとの両立を扱います。同じ会社を同じと決める名寄せ、項目ごとの正本、そして書き戻しの原則です。

シリーズの目次

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

関連記事

• AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：業務操作の5つの項目と、統制を置く場所の選び方
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：判断ログと、自動承認ルールへの移し方
• プロンプトインジェクションとは？防げない前提の対策と確認8項目：書き込みを業務操作で縛る理由

参考資料

• OMG「DMN — Decision Model and Notation」（現行版 1.6、2026年9月、https://www.omg.org/spec/DMN （2026年11月1日確認））
• Palantir「Action types • Overview」「Action types • Submission criteria」（https://www.palantir.com/docs/foundry/action-types/ （2026年11月1日確認））
• Eric Evans, "Domain-Driven Design: Tackling Complexity in the Heart of Software," Addison-Wesley, 2003（集約）

Askhubについて

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

この記事で説明した「操作を通らない書き込みを止める」仕組みは、Askhubではサーバー側の1か所でまとめて判定します。画面から直接直しても、AIが書いても、同じ判定を通ります。

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