公式スキル · AI 活用

ドメインオントロジーの草案

v1.0.0・2026年11月4日更新

ドメインオントロジーの草案を作る。コンピテンシー質問、わかりやすい定義つきのクラス、多重度つきのプロパティ、インスタンスの例、命名ルール。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• チームによって同じ言葉が別のものを指していて、共通の定義が必要なとき
• ナレッジグラフ、CRM の構造、RAG のシステムを作る前

AI に渡すもの

• 領域とその境界
• だれが、何のために使うか
• 文書やシステムの項目の例

できあがるもの

オントロジーが答えるべき問いにひもづけた、クラス、プロパティ、インスタンスの例の表。

手順

1. コンピテンシー質問を5〜10個書く オントロジーが答えるべき実際の問い。「今後90日で更新を迎えるアカウントはどれで、それぞれの担当はだれか？」。作業の範囲を決め、最後のテストにも使う。
2. 言葉を並べる 問いと資料に出てくる名詞と動詞を、まだ構造をつけずにすべて。
3. クラスを選び、それぞれを1文で定義する クラスは、インスタンスを持つものの種類。定義の形は「[クラス]は、[特徴]を持つ[親クラス]である」。同義語は1つのクラスにまとめ、同義語を記録する。ある状態に出たり入ったりするもの（「有効な顧客」）は、クラスではなくプロパティの値にする。
4. 階層を作る どのサブクラスも、親の「一種」でなければならない。サブクラスが1つしかないクラスは避け、直下のサブクラスがおよそ12個を超えるのも避ける。インスタンスを共有できないクラス同士には、互いに素（disjoint）と印をつける。
5. プロパティと関係を足す それを持ついちばん一般的なクラスにつける。それぞれに、名前、値の型（テキスト、数値、日付、ほかのクラス）、多重度（ちょうど1、0か1、1以上、0以上）。主な関係には逆の関係も足す（owns / owned_by）。
6. 中心となるクラスごとに、インスタンスの例を2〜3個作る 現実的だが架空のもの。例が当てはまらないなら、クラスかプロパティが間違っている。
7. コンピテンシー質問でテストする 問いごとに、どのクラスとプロパティで答えられるかを示す。答えられない問いがあれば何かが足りない。どの問いにも使われないクラスは、削る候補。 このスキルの既定の命名ルール: クラスは単数形の UpperCamelCase（SalesOpportunity）、プロパティは lower_snake_case で、動詞か「has」で始める（has_owner、renews_on）。略語を使わず、名前に「class」「type」のような語を入れない。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: ontology-draft
description: 1つの業務領域のドメインオントロジーの草案を作る。答えるべきコンピテンシー質問、わかりやすい定義つきの中心となるクラス、多重度つきのプロパティと関係、インスタンスの例、命名ルールを、Ontology Development 101 の方法にそって、エンジニアでない人もレビューできる表にまとめる。業務の中心となる概念を定義したい、データモデルをふつうの言葉で設計したい、オントロジー、タクソノミー、ナレッジグラフのスキーマを作りたい、「何を管理していて、それぞれがどうつながるのか」を整理したいと頼まれたときに使う。
---

# オントロジーの草案

オントロジーは、業務で話題にするもの（クラス）、それについて記録すること（プロパティ）、それらのつながりを、合意して並べたもの。2人が同じものを同じように分類できるくらい、定義を正確にする。Noy と McGuinness の Ontology Development 101 は、オントロジーが答えるべき問い、つまりコンピテンシー質問で領域と範囲を決めるところから始める。このスキルもそうする。問いに答えられないオントロジーには何かが足りず、だれも聞かない問いに答えるオントロジーは大きすぎるから。

## 使う場面

- 1つの領域について、ナレッジグラフ、CRM の構造、データウェアハウス、RAG のシステムを作る前。
- チームによって、同じ言葉が別のものを指しているとき（「顧客」「アカウント」「ユーザー」）。
- スプレッドシートの列が増えすぎて、だれも定義を言えないとき。
- 既存の文書から事実を抜き出す作業には使わない。クラスができたら knowledge-graph-extraction を使う。

## 用意するもの

- 領域と、その境界（「事業全体」ではなく「法人向けサブスクリプションの見積もりから更新まで」）。
- だれが、何のためにオントロジーを使うか。
- 文書、スプレッドシート、システムの項目の例。なければ領域の説明をもとに進め、クラスに「[提案]」と印をつける。
- チームがすでに使っている標準（業界のスキーマ、schema.org、CRM のオブジェクト）。合うところはその名前を使う。

## 手順

1. **コンピテンシー質問を5〜10個書く。** オントロジーが答えるべき実際の問い。「今後90日で更新を迎えるアカウントはどれで、それぞれの担当はだれか？」。作業の範囲を決め、最後のテストにも使う。
2. **言葉を並べる。** 問いと資料に出てくる名詞と動詞を、まだ構造をつけずにすべて。
3. **クラスを選び、それぞれを1文で定義する。** クラスは、インスタンスを持つものの種類。定義の形は「[クラス]は、[特徴]を持つ[親クラス]である」。同義語は1つのクラスにまとめ、同義語を記録する。ある状態に出たり入ったりするもの（「有効な顧客」）は、クラスではなくプロパティの値にする。
4. **階層を作る。** どのサブクラスも、親の「一種」でなければならない。サブクラスが1つしかないクラスは避け、直下のサブクラスがおよそ12個を超えるのも避ける。インスタンスを共有できないクラス同士には、互いに素（disjoint）と印をつける。
5. **プロパティと関係を足す。** それを持ついちばん一般的なクラスにつける。それぞれに、名前、値の型（テキスト、数値、日付、ほかのクラス）、多重度（ちょうど1、0か1、1以上、0以上）。主な関係には逆の関係も足す（owns / owned_by）。
6. **中心となるクラスごとに、インスタンスの例を2〜3個作る。** 現実的だが架空のもの。例が当てはまらないなら、クラスかプロパティが間違っている。
7. **コンピテンシー質問でテストする。** 問いごとに、どのクラスとプロパティで答えられるかを示す。答えられない問いがあれば何かが足りない。どの問いにも使われないクラスは、削る候補。

このスキルの既定の命名ルール: クラスは単数形の UpperCamelCase（SalesOpportunity）、プロパティは lower_snake_case で、動詞か「has」で始める（has_owner、renews_on）。略語を使わず、名前に「class」「type」のような語を入れない。

## 出力の形式

```markdown
# オントロジーの草案 — [領域]
**範囲:** [境界] · **使う人:** [だれが、何のために] · **状態:** 草案

## コンピテンシー質問
1. [問い]

## クラス
| クラス | 親 | 定義 | 同義語（使わない） |
|---|---|---|---|

## プロパティと関係
| プロパティ | クラス | 値の型 | 多重度 | 逆 | 定義 |
|---|---|---|---|---|---|

## インスタンスの例
| インスタンス | クラス | プロパティの値 |
|---|---|---|

## 問いのカバー状況
| 問い | 答えるもの |
|---|---|

## 命名ルール
- [ルール]

## 未決の判断
- [必要な判断と選択肢]
```

## 例

**入力:** 「領域: 当社の SaaS のサブスクリプション。法人に販売していて、1社が複数のワークスペースを持てる。ワークスペースごとにプランとシート数がある。社内では会社のことを『アカウント』とも『顧客』とも呼ぶ。だれがいつ更新するか、それぞれの更新の担当はだれか、どのワークスペースがシートの上限を超えているかを知りたい」

**出力:**

```markdown
# オントロジーの草案 — SaaS のサブスクリプション
**範囲:** 会社、ワークスペース、サブスクリプション、更新 · **使う人:** カスタマーサクセスと経理が更新の管理に · **状態:** 草案

## コンピテンシー質問
1. 今後90日で更新を迎えるサブスクリプションはどれで、それぞれの更新の担当はだれか？
2. プランの上限より多くのシートを使っているワークスペースはどれか？
3. 各社はいくつのワークスペースを持っているか？

## クラス
| クラス | 親 | 定義 | 同義語（使わない） |
|---|---|---|---|
| Company | — | 当社の製品を買う、または買う可能性のある法人 | アカウント、顧客、組織 |
| Workspace | — | 会社の利用者がログインする、当社の製品の中の独立した区画 | インスタンス、テナント |
| Subscription | — | 1つのワークスペースについて、1つのプランで一定期間結ぶ有料の契約 | 契約、ライセンス |
| Plan | — | 価格とシートの上限を持つ、名前のついたパッケージ | ティア |
| Person | — | 記録する個人 | 連絡先、ユーザー |

## プロパティと関係
| プロパティ | クラス | 値の型 | 多重度 | 逆 | 定義 |
|---|---|---|---|---|---|
| has_workspace | Company | Workspace | 1以上 | belongs_to | 会社が料金を払っているワークスペース |
| has_subscription | Workspace | Subscription | ちょうど1（現在のもの） | covers | 現在の有料の契約 |
| on_plan | Subscription | Plan | ちょうど1 | — | 買ったプラン |
| renews_on | Subscription | 日付 | ちょうど1 | — | 現在の期間が終わる日 |
| has_renewal_owner | Subscription | Person | 0か1 | owns_renewal | 更新に責任を持つ当社の担当者 |
| seat_limit | Plan | 数値 | ちょうど1 | — | プランのシートの上限 |
| seats_used | Workspace | 数値 | ちょうど1 | — | 今日使われているシート数 |

## インスタンスの例
| インスタンス | クラス | プロパティの値 |
|---|---|---|
| 株式会社ノースピーク | Company | has_workspace: Northpeak-JP, Northpeak-US |
| Northpeak-JP | Workspace | seats_used: 48; has_subscription: SUB-1042 |
| SUB-1042 | Subscription | on_plan: Team; renews_on: 2026-03-31; has_renewal_owner: 大野 玲奈 |
| Team | Plan | seat_limit: 40 |

## 問いのカバー状況
| 問い | 答えるもの |
|---|---|
| 1 | Subscription.renews_on、has_renewal_owner |
| 2 | Workspace.seats_used と Plan.seat_limit を Subscription.on_plan 経由で比べる |
| 3 | Company.has_workspace（の数） |

## 命名ルール
- クラス: 単数形の UpperCamelCase。プロパティ: lower_snake_case で、動詞か「has」で始める。略語を使わない。

## 未決の判断
- トライアルは価格0の Subscription か、別のクラスか？ 問い1に影響する。
```

## 送る前のチェック

- [ ] すべてのコンピテンシー質問が、名前のあるクラスとプロパティにひもづいている。
- [ ] すべてのクラスに、親とほかとの違いを示す1文の定義がある。
- [ ] 同義語は1つのクラスにまとめて記録してあり、別のクラスにしていない。
- [ ] すべてのプロパティに、値の型と多重度がある。
- [ ] それぞれの「〜の一種」の関係が、サブクラスのすべてのインスタンスについて成り立つ。

## よくある失敗

- 状態をクラスにする（「ChurnedCustomer」）。状態のプロパティを使う。ものは状態に出たり入ったりする。
- 業務でこれまでに出てきたものを全部モデルにする。コンピテンシー質問が必要とするところで止める。
- 定義がクラス名の言い換えのまま（「顧客とは顧客である」）。何がほかと違うのかを書く。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.