業務の知識をオントロジーにする5つの手順：多店舗運営を題材に【2026年版】
この記事の概要
本記事は全4回シリーズの最終回です。
第1回で概念、第2回で標準、第3回で実装と実測を扱いました。
今回は、自社の業務をどう書き起こすかという手順です。
読み終えたときに、自社の1枚を書き始められる状態にすることを目標にしています。
以下で扱う題材は架空の設定です。
実在する事業者や案件ではありません。
数値もすべて架空のものです。
なお本記事の手順は、かなうテック（屋号：Kanau Tech™）が実務で使っている進め方であり、公式に定義された方法論ではありません。
Part 1. 現場の知識はどこにあるか
業務の知識は、たいてい3か所に分かれて置かれています。
担当者の頭の中。
スプレッドシート。
口頭でのやりとり。
このうち文書になっているのはスプレッドシートだけで、それも多くは表です。
表は対象の一覧を持ちますが、対象どうしの関係は持ちません。
第1回で扱ったとおり、関係が書かれていない部分は、読む側が毎回推測して埋めます。
人間が読む場合は経験で埋まるので、問題として表面化しません。
問題になるのは、担当者が変わったときと、AIに渡したときです。
どちらも経験を持たない読み手が推測することになります。
Part 2. 題材
架空の設定を置きます。
3店舗を運営する飲食事業者を考えます。
各店舗はそれぞれメニューを持ち、一部のメニューは複数店舗で共通です。
メニューはレシピを持ち、レシピは食材を使います。
食材は仕入先から入り、仕入価格が変動します。
一部の食材にはアレルゲンが含まれます。
スタッフは複数店舗を兼務することがあり、一部の業務は特定の資格を持つ人しか担当できません。
この設定を選んだのは、間違えると実害が出る関係が自然に含まれるからです。
アレルゲンの取り違えは事故になります。
原価の計算違いは利益を削ります。
資格の要否を誤ると、担当できない人が担当することになります。
Part 3. 手順1 名詞を集める
最初にやることは、網羅ではありません。
自社で実際によく出る問いを1つ選びます。
ここでは次の問いを選びます。
「この食材の仕入先が止まったら、どの店舗のどのメニューが出せなくなるか」
第3回の測定で、この形の問い（複数の仕組みをまたいで順序と依存を答えるもの）が最も効くと分かっています。
問いを決めたら、その問いに答えるために登場する名詞を集めます。
店舗、メニュー、レシピ、食材、仕入先、アレルゲン、スタッフ、資格、シフト。
この段階では順序も分類も要りません。
出てきた順に並べるだけです。
網羅しようとすると終わりません。
選んだ問いに答えられる範囲で閉じます。
Part 4. 手順2 型に分ける
集めた名詞を、型（クラス）と、その具体例（個体）に切り分けます。
第1回で扱った5つの構成要素のうち、クラスと個体にあたる部分です。
- クラス：店舗、メニュー、レシピ、食材、仕入先、アレルゲン、スタッフ、資格
- 個体：千葉本店、日替わり定食、鶏の照り焼き、鶏もも肉、A商店、卵、佐藤（架空）、食品衛生責任者
切り分けの目安は、「これは何の一種か」と問えるかどうかです。
「鶏もも肉は食材の一種である」は成立します。
「食材は何の一種か」は答えにくく、ここが上限になります。
ここで手が止まる箇所が出ます。
たとえばシフトはクラスなのか、関係なのか。
答えは、それ自体が属性を持つかどうかで決まります。
シフトが日付と時間帯と店舗を持つなら、シフトはクラスです。
「誰がどの店舗で働くか」だけを表したいなら、関係で足ります。
Part 5. 手順3 関係に名前を付ける
ここが最も重要な手順です。
そして最も飛ばされやすい手順です。
まず禁止事項を1つ置きます。
「関連する」という関係を使わないことです。
「メニューと食材は関連する」と書いても、何も言っていません。
読む側は結局、どう関連するのかを推測します。
推測を減らすために関係を書くのに、推測が必要な関係を書いては意味がありません。
使う関係の型を、先に決めて一覧にします。
- offers：店舗はメニューを提供する
- based-on：メニューはレシピにもとづく
- uses：レシピは食材を使う
- supplies：仕入先は食材を供給する
- contains：食材はアレルゲンを含む
- works-at：スタッフは店舗で働く
- holds：スタッフは資格を持つ
- requires：業務は資格を要する
- substitutes：食材は別の食材で代替できる
9つです。
かなうテックでは10個前後を目安にしています。
型が多すぎると、書く人ごとに選び方がぶれます。
少なすぎると、別々の関係が同じ型に潰れます。
まず5個で始めて、足りない場面が3回出たら1つ足す進め方を勧めています。
第1回のPart 5で書いたとおり、型を有限にすることには、もっともらしい誤りを作りにくくする働きもあります。
自由記述を許すと、この効果は消えます。
書き起こした結果は、次のような形になります。
{"type":"entity","name":"千葉本店","entityType":"店舗","observations":["席数28","ランチ営業あり"]}
{"type":"entity","name":"日替わり定食","entityType":"メニュー","observations":["ランチ限定"]}
{"type":"entity","name":"鶏もも肉","entityType":"食材","observations":["仕入価格が変動する"]}
{"type":"relation","from":"千葉本店","to":"日替わり定食","relationType":"offers"}
{"type":"relation","from":"日替わり定食","to":"鶏の照り焼き","relationType":"based-on"}
{"type":"relation","from":"鶏の照り焼き","to":"鶏もも肉","relationType":"uses"}
{"type":"relation","from":"A商店","to":"鶏もも肉","relationType":"supplies"}
第3回で扱ったmemoryサーバが読む形式と同じです。
表計算ソフトの3列（元、関係、先）で書いても構いません。
形式より、関係に名前が付いていることのほうが重要です。
この時点で、Part 3で選んだ問いに答えられるか確かめます。
A商店が止まったら、supplies を逆にたどって鶏もも肉、uses を逆にたどって鶏の照り焼き、based-on を逆にたどって日替わり定食、offers を逆にたどって千葉本店。
4本たどれば答えが出ます。
どの表にも書かれていない答えです。
Part 6. 手順4 制約を書く
第1回で挙げた5つの構成要素の最後が制約です。
ここまでの手順で書いてきたのは、成り立っている事実です。
制約は、成り立っていなければならない条件を書きます。
この題材なら、次のようなものです。
- アレルゲンを含む食材を使うメニューは、アレルゲン表示を持たなければならない
- 資格を要する業務のシフトには、その資格を持つスタッフだけを割り当てられる
- 1つの食材の仕入先が1社しかない場合、そのメニューは代替食材を持たなければならない
制約を書く価値は、間違いを機械に見つけさせられる点にあります。
表を目で確認する作業が、条件に合わない組み合わせを探す作業に変わります。
ただし、ここで第2回のPart 4で扱った開放世界仮定が効いてきます。
書いていないことは、無いことではありません。
「アレルゲン表示を持たない」と「アレルゲン表示をまだ書いていない」は別です。
制約に引っかかった項目を見るときは、この2つを区別する必要があります。
そして第1回のPart 7で扱ったとおり、この制約に強制力はありません。
書いてあるだけでは、違反した状態が作られることを防げません。
止めたいなら、業務の流れの側で止めることになります。
Part 7. 手順5 語の揺れを潰す
書き起こすと、同じものを違う名前で呼んでいる箇所が必ず出ます。
「鶏もも」と「鶏もも肉」。
「千葉本店」と「本店」。
「アレルギー表示」と「アレルゲン表示」。
これは失敗ではなく、この作業の成果です。
第1回で挙げた「用語のずれが見える」は、この場面で起きます。
潰し方は2段階です。
まず、同じものを指す名前を1つに決めます。
次に、決めた名前と、現場で使われている別名の対応表を作ります。
別名を消してはいけません。
現場は今の呼び方を続けます。
対応表があれば、どちらの呼び方で来ても同じ対象に着地します。
第3回で紹介したCookbookの手順でも、この名寄せが独立した段階として置かれていました。
そこでの注意も同じで、まとめすぎると別の実体が1つに潰れます。
「本店」が2店舗ある事業者では、「本店」を1つに潰すと集計が混ざります。
Part 8. 書き起こしたあと何ができるか
3つあります。
変更の影響範囲が出せます。
仕入先が止まったとき、価格が上がったとき、メニューを廃止するとき。
いずれも関係をたどる問いで、第3回の測定で効果が出たのはこの型でした。
引き継ぎが軽くなります。
担当者の頭の中にあった「この食材はあの店だけ使う」という知識が、関係として残ります。
規程や手順の見直しが速くなります。
これは次のPart 9で扱います。
一方、期待してはいけないことも書いておきます。
書き起こしただけでは、業務が正しく回るようにはなりません。
第1回のPart 7で扱った参考情報と実行基盤の区別が、そのまま当てはまります。
そして第3回で見たとおり、更新されない記述は、現場と食い違ったまま参照されます。
書き起こす前に、誰がいつ更新するかを決めておくことになります。
Part 9. 同じ型が効く他の領域
規程や契約や法令の領域は、関係の塊です。
「この条項はどの法令にもとづくか」「この条項を変えたら、どの他の条項に波及するか」。
どちらも第1回のPart 6で見た、RAGが最も苦手でグラフが最も得意な形をしています。
条文と条項の関係を一度書き出せば、見直しのたびに全文を読み直す代わりに、該当する部分の周辺だけを見れば済みます。
介護の分野では、利用者、職員、保有資格、勤務区分、加算の要件が多対多で絡みます。
資格と要件の関係を書き出す構造は、この記事の題材とほぼ同じです。
シフト管理の自動化については介護のシフト管理を自動化するで扱っています。
士業の分野では、条文、改正、適用条件の関係が中心になります。
参照先を制約したうえで出典付きで答えさせる設計は士業向けAI×MCPリファレンス設計で扱っています。
いずれも、この記事の5つの手順をそのまま当てられます。
変わるのはクラスと関係の型の中身だけです。
Part 10. 最初の1枚をどこから書くか
全体像から始めないことです。
手順を振り返ります。
- 自社でよく出る問いを1つ選ぶ
- その問いに登場する名詞を集める
- 型と具体例に切り分ける
- 関係の型を5個決めて名前を付ける
- 成り立つべき条件を書く
- 同じものを指す別の呼び方を対応表にする
最初の1枚は、A4で1枚に収まる規模で構いません。
選んだ問いに答えられれば、その1枚は役に立っています。
答えられなければ、足りない関係が具体的に分かります。
分かった時点で足せばよく、最初から完全である必要はありません。
第3回で書いたとおり、効くかどうかは自分の環境で測れば分かります。
書き起こす作業も同じで、1つの問いで試してから広げるほうが確実です。
自社のどの問いから書き起こすべきか、関係の型をどう選ぶかの切り分けは、無料相談でも承っています。
シリーズ一覧
| 回 | 内容 |
|---|---|
| 第1回 | 概念。5つの構成要素、関係の型、RAGとの使い分け、参考情報と実行基盤の区別 |
| 第2回 | 標準。RDFのトリプル、OWL、推論、開放世界仮定、厳密さの止めどころ |
| 第3回 | 実装と実測。24回の測定、効いた問いと効かなかった問い、2つの失敗モード |
| 第4回（本記事） | 業務への適用。書き起こしの5つの手順 |
関連記事
注記：本記事に登場する3店舗の飲食事業者、店舗名、メニュー、仕入先、スタッフはすべて架空の設定であり、実在する事業者や案件とは関係ありません。数値も架空のものです。Part 3からPart 10で示した手順は、かなうテック（屋号：Kanau Tech™）が実務で用いている進め方であり、公式に定義された方法論ではありません。自社の業務に合うかどうかは個別にご判断ください。