業務オントロジー入門 第7回｜最初の1業務を型にする 〜領域の選び方・7つの手順・よくある失敗〜
全社の型ができるのを待たない
「全社の業務を型にしてから、AIを入れる」
多くの方が、そう考えていると思います。
でも、それではいつまでも始まらないと私たちは考えています。
最初は1つの領域。ものと操作が、それぞれ5〜10個に収まる大きさです。
このシリーズの最終回は、ここまでの内容を、自分の業務を業務オントロジー（業務の型）にする手順にまとめます。成果物は、2枚の定義表です。
この記事は、業務オントロジー入門シリーズ（全7回）の第7回です。シリーズの一覧はこちら。
まずは、最初の領域の選び方から考えます。
最初の領域は、4つの問いで選ぶ
領域を選ぶ基準は、4つです。
基準 | 確認する問い |
|---|---|
判断がある | 担当者が複数のシステムを見比べて判断している作業があるか |
操作がある | 判断の結果、何かのデータや状態を変えているか |
データがある | 必要なデータがシステムに存在し、IDで結びつけられるか |
担当者がいる | 業務を説明でき、型をレビューしてくれる人がいるか |
AIに任せる業務の選び方として、AIエージェントの権限設計で3つの条件を挙げました。同じ作業が月に何度も繰り返される。判断の基準を言葉にできる。取り消し方がはっきりしていて、誤ったときの影響を金額や件数で測れる。
4つの問いのうち「判断がある」「操作がある」を、この3つの条件で具体的に確かめます。両方を満たす業務が、最初の題材です。
経理の入金消込（入金と請求書を突き合わせる作業）、営業の受注変更、このシリーズで通し例にした受注の確定。いずれも当てはまりやすい業務です。
「判断がある」を外さないでください。判断の無い業務を型にしても、見るだけのダッシュボードになります。
領域が決まったら、順番に進めます。
7つの手順
手順 | 作業 | 読む回 |
|---|---|---|
1. 出来事を洗い出す | 担当者と付箋を並べ、業務の流れを出来事の連鎖として描く | 第2回 |
2. 言葉をそろえる | 出てきた名詞と動詞を用語集にし、揺れと多義を潰す。部門で意味が違うなら範囲を分ける | 第2回 |
3. 名詞を定義する | もの・項目・関係を定義表にする。IDとデータの出所を決める | 第2回、第4回 |
4. 状態遷移を描く | 状態を持つものごとに、状態と矢印を描く | 第3回 |
5. 動詞を定義する | 矢印を業務操作の定義表にする。権限、前提条件、承認、効果、取り消しを書く | 第3回 |
6. 正本を決める | 項目ごとに、基幹と型のどちらが正かを決める。書き戻す項目は4つの問いに答える | 第4回 |
7. 権限とAIの範囲を決める | 誰が何を見て何を変えられるか。AIにどの操作をどの方式で任せるか | 第5回 |
手順1と2を飛ばさないでください。
設計書から始めると、手順3で「保存の都合」が型に入り込みます。言葉をそろえずに始めると、手順5で「受注」が部門ごとに別のものを指していることに気づきます。
手順6は、重く見えます。最初は「読むだけ」でよいと決めれば、書き戻す項目は0でも構いません。
7つの手順の成果物が、2枚の定義表です。
業務オントロジーの成果物は、2枚の定義表
もの定義表
項目 | 記入する内容 |
|---|---|
名前 | 社内共通語の名前 |
定義 | 1文で。「〜とは、〜である」の形にする |
1件が表すもの | 何が1つ増えると1件増えるか |
ID | 何をIDにするか。同じ入力から必ず同じ値になるか |
データの出所 | どのシステムのどのデータか。無ければ「操作で作成」 |
項目 | 名前、データの種類（日付・金額・選択など）、正本、閲覧制限の有無 |
状態 | 取りうる値と、状態遷移図への参照 |
受注の記入例です（説明のための例です）。
項目 | 受注 |
|---|---|
名前 | 受注 |
定義 | 受注とは、顧客からの注文を当社が受け付けた時点の取引である |
1件が表すもの | 注文書が1通届くと1件増える |
ID | 基幹システムの受注番号 |
データの出所 | 基幹システムの受注ヘッダ |
項目 | 受注日（日付、正本は基幹）、状態（選択、正本は基幹）、合計金額（金額、正本は基幹、閲覧は営業と経理）、営業メモ（文章、正本は型） |
状態 | 受付済、与信確認中、確定、保留、出荷済、請求済、キャンセル。図は第3回 |
業務操作定義表
項目 | 記入する内容 |
|---|---|
名前 | 「〜を〜する」の形 |
対象 | 変更するもの。原則として、一緒に整合を保つ1つのまとまり |
権限 | 人の役割、システム、AI |
入力 | 入力する項目と、その範囲 |
前提条件 | 状態の条件と、実行者の条件 |
承認 | 効果を確定する前に、誰の許可が要るか |
効果 | 作成・変更・削除するもの |
書き戻し | 正本へ書き戻すか。失敗したときに操作も失敗させるか |
取り消し | どの操作で戻すか。戻せない場合はそう書く |
AIの扱い | 自動実行、確認してから実行、提案として保留、AIには許可しない |
記録 | 操作の記録で足りるか。記録用のものが要るか |
「受注を確定する」の記入例です。
項目 | 受注を確定する |
|---|---|
名前 | 受注を確定する |
対象 | 受注（と、その明細） |
権限 | 営業担当 |
入力 | 受注番号 |
前提条件 | 状態が「与信確認中」。与信残高が0以上、または承認記録がある。実行者がその受注の担当者 |
承認 | この操作には置かない。与信残高が0未満の受注は、先に上長が「保留を承認する」ことで承認記録を作る |
効果 | 状態を「確定」にする |
書き戻し | 基幹の受注確定の業務機能を呼ぶ。基幹が拒否したら、操作も失敗 |
取り消し | 「受注を取り消す」で「キャンセル」へ。出荷済なら取り消せない |
AIの扱い | 提案として保留。承認の記録がたまったら、与信残高が0以上の分を自動承認ルールに移す |
記録 | 操作の記録で足りる。承認のコメントは承認記録（もの）に残す |
この2枚があれば、製品が何であっても、設計は持ち運べます（第6回）。
表は、1人では埋まりません。
4つの立場で定義する
定義には、4つの立場が関わります。
立場 | 持ち寄るもの |
|---|---|
その業務の担当者 | 前提条件と例外。「こういうときは確定しない」 |
承認者 | 承認の基準。「この金額を超えたら私が見る」 |
情シス | 権限と書き戻し先。「基幹のこの機能を呼べる」「この項目は直接編集を止められる」 |
内部統制の担当者 | 職務権限規程との整合。「起票者は承認しない」 |
最初の会議で4人がそろう必要はありません。担当者と手順1〜5を進め、手順6で情シス、手順7で承認者と内部統制の担当者に入ってもらう順番で足ります。
表が埋まったら、レビューです。
声に出して読むレビュー
定義表のレビューで、私たちがいちばん効くと考えている方法は、業務担当者に定義表を読み上げてもらうことです。
「受注とは、顧客からの注文を当社が受け付けた時点の取引である」
「受注を確定するのは営業担当で、条件は、状態が与信確認中で、与信残高が0以上か承認記録があること」
声に出したときに違和感が出る箇所が、型の直すべき箇所です。
「受け付けた時点って、注文書が届いた時点？ 登録した時点？」「与信残高が0ちょうどのときは？」
こうした問いは、画面に向かって表を眺めているときには出てきません。読み上げると出てきます。
レビューで見つかる問題は、だいたい決まっています。
よくある失敗7つ
失敗 | 症状 | 対策 | 読む回 |
|---|---|---|---|
分析用の表をものにする | 1件が何を表すか説明できない | 業務上の1単位まで分解する | 第2回 |
IDが不安定 | 取り込みのたびに編集が消える、別のものに付く | 同じ入力から同じ値になるIDにする | 第4回 |
名詞だけ作って終わる | 見るだけのダッシュボードになり、業務が変わらない | 状態遷移図から業務操作を作る | 第3回 |
巨大な操作 | 失敗したときにどこまで戻すか分からない | 1操作が変えるのは1つのまとまりまで | 第3回 |
閲覧権限で書き込みも守れると思う | 見えない範囲のデータを変更できてしまう | 変えてよい範囲を前提条件に明示する | 第5回 |
正本が決まっていない | 基幹と型で値が食い違う | 項目ごとに正本を決める | 第4回 |
全社一枚岩のモデル | 定義の合意が取れず、いつまでも完成しない | 領域を絞り、意味の範囲を明示する | 第2回 |
7つのうち、最初の1領域で特に起きやすいのは「名詞だけ作って終わる」です。
もの定義表ができると、達成感があります。でも、効果が出るのは操作が業務で使われ始めてからです（第6回）。手順5まで進めてから、使い始めます。
使い始めたあとの進め方も、決まっています。
型は、使いながら育てる
AIエージェントの権限設計で説明した3段階を、ここでも使います。
段階1は、列も値も自由な表やメモ。AIに任せるのは、読んで要約し、下書きを作るところまで。
段階2は、名前と項目が決まり、ほかのデータと関係でつながった状態。もの定義表ができた状態です。AIは正しく探して照合し、候補を出します。書き込みはまだしません。
段階3は、状態と業務操作が定義された状態。業務操作定義表ができた状態です。AIは操作を提案・実行し、承認を通った結果を正本へ書き戻します。
受注なら、最初は「与信確認中の受注のうち、与信残高が0以上のものを一覧にする」ところまでをAIに任せます（段階2）。
人がその一覧を見て確定するうちに、基準がはっきりしてきます。そこで初めて「受注を確定する」を業務操作として使い、提案として保留する方式で任せます（段階3）。
段階3へ上げるときも、いきなり直接の書き込みを止める必要はありません。操作を通らない書き込みを、止めずに記録だけする期間を置きます（第4回）。
型が無い段階ではAIに書き込みを許さないので、最初がいちばん安全側で、型ができた分だけ任せる範囲を広げる形になります。しかも、実際に繰り返された作業から型を作るので、例外の扱いも含めて現場に合った定義になります。
推進担当が押さえる要点
- 最初の領域は、判断がある・操作がある・データがある・担当者がいる、の4つで選ぶ。ものと操作が5〜10個に収まる大きさ
- 手順は7つ。出来事を洗い出し、言葉をそろえてから、名詞、状態、動詞、正本、権限とAIの範囲の順に決める
- 業務オントロジー（業務の型）の成果物は、もの定義表と業務操作定義表の2枚。製品が変わっても持ち運べる
- 担当者・承認者・情シス・内部統制の4つの立場で定義し、読み上げてレビューする
- 最初の1領域で起きやすいのは「名詞だけ作って終わる」。操作が使われて初めて効果が出る
- 読む、照合して候補を出す、書き込む、の3段階で育てる。記録だけの期間を置いてから書き込みを絞る
最初の1業務から、AIに任せる範囲を広げる
このシリーズで伝えたかったことは、1つです。
AIに業務を任せるとは、AIの出力がそのまま会社の記録になるということ。そのとき問われるのは「AIは賢いか」ではなく「AIに何をさせてよいか」。その答えを置く場所が、業務の型です。
型は、もの・関係・状態・業務操作の4つでできています（第1回）。ものは業務の言葉から切り出し（第2回）、動詞は状態遷移図から作ります（第3回）。データは今の場所のまま、同じものと正しい値を決めます（第4回）。型の上でAIは、探す・計算する・動かすの3つの道具だけで動きます（第5回）。製品は設計を持ってから選びます（第6回）。
まずは、毎月繰り返している業務を1つ選び、担当者と付箋を並べるところから始めてみてください。
型が育てば、AIに任せる範囲は確実に広げていけると、私たちは確信しています。
シリーズの目次
- 業務オントロジー入門 第1回｜なぜ今、業務に「型」が要るのか
- 業務オントロジー入門 第2回｜業務から「もの」を切り出す
- 業務オントロジー入門 第3回｜業務操作を定義する
- 業務オントロジー入門 第4回｜基幹システムは置き換えない
- 業務オントロジー入門 第5回｜型の上でAIはどう動くか
- 業務オントロジー入門 第6回｜Palantir、Fabric IQ、SAPはどう違う？
- 業務オントロジー入門 第7回｜最初の1業務を型にする（この記事）
関連記事
- AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める：最初の1業務の3条件と、型を育てる3段階
- AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：判断ログから自動承認ルールへ移す手順
- AIエージェントの導入審査をスムーズに通すには？推進担当の準備と選び方：審査に出す前の準備
- AIエージェントの責任は誰が負う？システムと運用の責任分界：システムが持つ部分と、運用に残る部分
参考資料
- Alberto Brandolini「Introducing Event Storming」（2013年11月18日。手順1の付箋のワークショップ）
- Eric Evans, "Domain-Driven Design: Tackling Complexity in the Heart of Software," Addison-Wesley, 2003（ユビキタス言語、集約、境界づけられたコンテキスト）
- Palantir「Overview • Ontology」「Core concepts」（定義表の項目の下敷き （2026年11月1日確認））
Askhubについて
Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。
この記事の7つの手順と2枚の定義表は、Askhubの導入でコンサルタントが伴走する作業そのものです。定義表の項目は、この記事の表をそのまま写して使えます。
※Askhubのサービスに関する記載は、2026年11月時点の情報です。
