状態遷移図から業務操作を定義する 〜業務オントロジー入門 第3回〜

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

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

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

関連記事

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

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

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