オントロジー入門

AIへ社内データを渡しても、商品名、顧客名、契約条件の意味が部署ごとにずれると、どの情報を判断に使うべきかが曖昧になります。オントロジー入門では、業務に出てくる概念、属性、関係をそろえ、DBやRAGに渡す前の意味を設計する視点が重要です。最初に見るべき違いが分かると、用語集で足りる範囲と、業務オントロジーとして設計すべき範囲を分けられます。

ポーチの例で概念と属性と関係を分ける

次の表は用語を理解するための編集部の架空例です。概念は何を扱うか、属性はその対象が持つ値、関係は別の対象とのつながりを表します。

「台本カットは資料を根拠にする」という関係の型を決めることと、「カット1は仕様書Aを参照する」という個別の記録を入れることを分けると、オントロジーと実データの役割を追いやすくなります。

オントロジー入門は業務語彙から始まる

概念と関係をそろえる意味

オントロジーは、業務で使う名詞を並べるだけではなく、その名詞がどの対象を指し、別の対象とどう結びつくかを記述する設計です。OWL 2の説明では、オントロジーは対象領域についての精密な記述の集合であり、人の誤解を防ぎ、ソフトウェアの振る舞いを一定に近づける目的を持つとされています。（OWL 2 Web Ontology（公式））業務で読むなら、顧客、契約、商品、問い合わせのような概念を、判断に使える関係として扱うための土台になります。

Palantirの資料では、オントロジーは統合されたデジタル資産の上に位置し、データセットやモデルを工場、設備、製品、注文、金融取引などの概念へ接続すると説明されています。（オントロジーの構築 • Palant（公式））さらに、既存のデータソースをオブジェクト、プロパティ、リンクへマッピングすることで組織の意味論を定義するとされています。企業で考える場合も、顧客テーブルがあるかどうかだけでなく、その顧客が契約、商品、問い合わせ、承認とどの関係に置かれるかを先に見ます。

NoyとMcGuinnessの入門では、オントロジーは領域内の用語と関係について機械が解釈できる定義を含むものとして説明されています。（What is an ontology ）顧客という言葉が営業では商談先、経理では請求先、サポートでは問い合わせ元を指す場合、同じ文字列を同じ意味として扱うと判断が粗くなります。この例の整理案として、同じ名詞を無理に一つへ丸めず、顧客、契約、請求先、利用者、問い合わせ元の関係を分けて扱うことを提案します。

業務で最初に定める部品

業務で最初に定める部品は、クラス、属性、関係です。OWL 2では、対象を個体、カテゴリをクラス、関係をプロパティとして扱い、プロパティには対象同士を結ぶものと、対象へデータ値を与えるものがあると説明されています。（OWL 2 Web Ontology（公式））業務では、問い合わせをクラスとして置き、問い合わせ種別や受付日を属性として見て、問い合わせが顧客や契約に関係するというつながりを関係として定めます。

クラスは、人が考える概念に含まれる対象のまとまりとして使えます。OWL 2の説明では、あるクラスが別のクラスより一般的である場合、その関係はサブクラスとして表せるとされています。（OWL 2 Web Ontology（公式））著者の業務語彙の例では、問い合わせの下に解約問い合わせ、請求問い合わせ、障害問い合わせを置くようなis-aの関係がこれに近い見方になります。

part-ofは、部品と全体の関係を表すときに使う考え方です。W3Cの資料では、part-wholeの関係はオントロジー開発でよく出る問題であり、OWLにはpart-whole関係を表す専用の組み込み要素はないものの、多くの一般的な場合を表現できる力がある（すべての場合ではない）と説明されています。業務の設計例なら、製品と構成部品の関係を考えられます。ただし「関連する」というだけの関係までpart-ofにせず、何を全体と部分とみなすのかを先に定義することを提案します。（Simple part-whole （公式））

最初から形式名を決めるより、部門間で意味がずれやすい名詞を選び、概念、属性、関係に分けるほうが実務の検討に入りやすくなります。商品名、契約種別、問い合わせ分類、承認者のような言葉を候補にし、それぞれが何を指し、どの対象とつながり、どの条件で変わるかを確認します。ここでの整理は効果を保証するものではなく、AIや検索に渡す前の業務語彙を比較できる形にするための設計です。

業務オントロジーは関係を地図にする

設計の整理案として、業務オントロジーをAI導入に使うときは、単語を登録する作業ではなく、AIに渡す文脈を設計する作業として見ると判断しやすくなります。顧客、契約、商品、問い合わせが別々の表や文書に分かれていても、業務上は互いに関係しながら判断に使われます。その関係をどの粒度で渡すかを決めることで、既存DBやRAGと競合させずに接続位置を考えられます。

関係がAIの文脈になる

AIに渡す情報は、多いほどよい断片の集まりではなく、望む動作に近づく文脈として選ぶ必要があります。Anthropicは、LLMに入る文脈を有限の資源として扱い、望む結果の可能性を高める高信号の情報を小さく選ぶ考え方を示しています。（Effective context （公式））この原則を踏まえた著者の設計案は、商品名だけでなく契約条件、問い合わせ分類、承認条件との関係も入力候補にし、実際の回答で必要性を検証することです。オントロジーの導入効果を同資料が実証しているわけではありません。

部署ごとに同じ言葉の意味がずれる場合は、AIへの入力にも区別に必要な情報が含まれているかを確認することを提案します。たとえば、問い合わせが契約に関係する、契約が商品条件を含む、回答案が承認条件を参照する、といった関係を文脈へ含める設計案が考えられます。これらは業務に当てはめて検討する例です。

RAGは、事前学習済みモデルの内部知識と、検索で参照する外部の記憶を組み合わせて生成する方法として説明されています。（[2005.11401] Retriev）つまり、RAGは根拠候補を取りに行く仕組みとして役立ちますが、検索された資料の中でどの顧客、契約、商品、問い合わせを同じ判断単位として扱うかは別に設計する必要があります。著者の接続案では、検索結果をAIに渡す前に関係の意味と更新責任を整理します。この配置の有効性は対象業務で検証する必要があります。

AI導入で効く業務オントロジーの場面

AI導入で業務オントロジーを考える場面は、技術の新しさよりも、業務の言葉と関係が判断を左右するかで見ます。顧客、契約、商品、問い合わせのような対象が複数部署で使われ、意味や関係がずれるほど、AIに渡す文脈も崩れやすくなります。単純な検索や一回限りのFAQで足りる場面では検索対象や回答文の整備を先に検討することを提案します。関係の設計を加える負担に見合う用途があるかを判断するためです。

採用に向く業務

採用を検討しやすいのは、業務で使う語彙が部門ごとに違い、同じ顧客や契約を別の意味で扱っている場面です。業務側では、この考え方を用語集だけで終えず、問い合わせが契約に関係する、契約が商品を含む、承認条件が商品や顧客種別に依存する、という関係まで整理する判断に使います。

Semantic Layerは、売上などの重要なビジネス指標をモデリング層で定義し、下流のデータツールやアプリケーションで一貫して使うための層です。（dbt Semantic Layer（公式））指標の定義をそろえる問題ならSemantic Layerが先に検討候補になります。一方で、問い合わせ、契約、商品、承認条件の関係までAI利用面に渡したい場合は、業務オントロジーとして対象と関係を整理する余地が出ます。

比較のための提案として、採用に向く場面と見送れる場面を同じ表で分けます。向く選択は一般的な判断候補であり、表の内容だけで導入効果を約束するものではありません。SynClipは広告・制作業務を起点に企業固有のカスタム開発と共創へつなぐ事業方針を採るため、業務語彙と関係の設計が必要な場合は、個社の業務に合わせた検討対象になります。

見送れる場面も、オントロジーが不要という意味ではなく、最初の投資対象として重い場合があります。NoyとMcGuinnessは、実装に埋め込まれた領域前提を明示すると、知識が変わったときに前提を変更しやすくなると説明しています。（What is an ontology ）著者の検討案として、変更される前提が少なく、関係よりも文書検索や指標定義の整理が中心なら、検索整備やSemantic Layerから始めるほうが扱いやすい場合があります。

小さなドメインのサンプル

問い合わせ対応を小さなドメインにすると、最初の出力は完成システムではなく、用語集、クラス階層、関係定義、実装前チェックに分けられます。用語集では、問い合わせ、顧客、契約、商品、回答案、承認者の意味を短くそろえます。クラス階層では、問い合わせの下に解約問い合わせ、請求問い合わせ、障害問い合わせを置くように、判断に使う粒度だけを持ちます。

著者が関係を確認しやすいと考える定義の例は、問い合わせを「顧客または利用者から届き、契約、商品、請求、障害のいずれかに関係する対応単位」と置き、契約や商品との関係を別に定める形です。対照となる曖昧な定義の例は、問い合わせを「対応が必要なもの」とだけ置き、どの対象に紐づくか、誰が更新するか、どの条件で承認が必要かを残さない形です。NoyとMcGuinnessは、オントロジーをドメインの概念、各概念の特徴を記述する属性、属性に対する制約の形式的で明示的な記述として説明しています。（What is an ontology ）

• 用語集の例: 問い合わせ、顧客、契約、商品、回答案、承認者を定義する
• クラス階層の例: 問い合わせの下に解約問い合わせ、請求問い合わせ、障害問い合わせを置く
• 関係定義の例: 問い合わせは顧客から発生し、契約または商品に関係する
• 実装前チェックの例: どの関係をAIに渡し、どの判断を人が承認するかを分ける

実装前チェックでは、問い合わせがどの契約に関係するか、回答案がどの商品条件を参照するか、承認者がどの条件で差し戻すかを見ます。これは効果を断言するための手順ではなく、曖昧な名詞を関係へ分解するための紙面上のサンプルです。SynClipの事業方針は広告・制作業務を起点に企業固有のカスタム開発と共創へつなぐことにあり、このサンプルも個社の業務に合わせて検討する題材として扱います。

研修やワークショップは、開発検討にすぐ進めない企業の補助的な入口としては使えます。ただし、問い合わせ対応の意味設計を本番のAI利用面へつなぐ判断では、研修を受けること自体を導入条件にしないほうが混同を避けられます。検討対象は、業務の対象、関係、更新される前提、承認する判断をどう扱うかです。

商品と訴求の関係を画面で確かめる

商品IDと根拠の語を結びつけて確認する最小例として、架空の商品を使った小さなローカルデモを作りました。商品ID「COFFEE-01」に「深煎り」「ブラジル産」「200g」という根拠の語を登録し、その商品の訴求が登録した語に一致するかを検査します。オントロジー全体を実装したものではなく、決めた関係に沿って値を照合する例です。撮影時はブラウザーを自動操作しました。OWLの推論処理やAIによる文章生成ではありません。

資料にない「脂肪が燃える」を入力すると、根拠にない訴求として差し戻されます。この画面で行っているのは登録語との完全一致の確認です。文章の意味を理解した判定でも、広告表現が法令に適合するかの判断でもありません。根拠のない表現を後工程へ進めないという確認点を示しています。

訴求を登録済みの「深煎り」に変えて再確認すると、担当者が承認する操作へ進めます。実際の業務へ広げる際は、同義語の扱い、資料の版、承認者の権限などを対象業務に合わせて設計します。この例の画面上の承認は手順の説明用で、本人認証を備えた業務承認機能ではありません。

導入前に見たい設計条件

導入前の確認は、資料を大量に集める作業ではなく、業務で使う言葉の意味と関係を見える形にする作業です。入力資料、関係者、既存システム、AI利用面、更新責任、見積もり項目を分けると、社内で何を決めればよいかを比較しやすくなります。

必要な入力資料

最初に見る資料は、商品やサービスの一覧、業務フロー、既存DBの項目、部門ごとの用語、承認ルール、AIに任せたい作業です。OWLの入門資料では、オントロジーは対象領域についての精密な記述の集合であり、人の誤解を防ぎ、ソフトウェアの振る舞いをそろえる助けになると説明されています。（OWL 2 Web Ontology（公式））業務側の資料も、量よりも言葉の意味と判断条件が読めるものを優先します。

商品一覧だけでは、商品が契約条件、問い合わせ、承認者とどう結びつくかまでは分かりません。業務フローや承認ルールを合わせて見ると、どの名詞が判断対象で、どの関係がAIへ渡す文脈になるかを検討できます。Anthropicは、LLMに入る文脈を有限の資源として扱い、望む行動につながる高信号の情報を小さく選ぶ考え方を示しています。（Effective context （公式））

• 入力資料: 商品一覧、業務フロー、既存DBの項目、部門ごとの用語、承認ルール、AIに任せたい作業を確認する
• 関係者: 業務責任者、現場承認者、データ担当、開発者の見方を比較する
• 既存システム: DB、BI、検索、RAGで保持している項目と対象を分ける
• AI利用面: 回答案、分類、確認補助など任せたい作業を候補として置く
• 更新責任: 用語、関係、承認ルールを誰が見直すかを候補化する
• 見積もり項目: 対象ドメイン、接続先、承認フロー、更新頻度、AI利用面、保守範囲を分ける

役割と更新責任

役割分担は、一般的な担当の例として、業務責任者、現場承認者、データ担当、開発者に分けて考えると整理しやすくなります。業務責任者は対象ドメインと判断基準を示し、現場承認者は回答案や分類の妥当性を確認する候補になります。データ担当は既存DBやBIの項目を説明し、開発者はそれらをAI利用面へ接続する設計を検討します。

更新責任は、導入後の効果を保証する項目ではなく、業務ルールが変わったときにどの定義を見直すかを決めるための検討項目です。NoyとMcGuinnessは、実装の背後にあるドメイン上の前提を明示すると、知識が変わった場合に前提を変更しやすくなると説明されています。（What is an ontology ）反対に、世界についての前提をプログラムコードへ固定すると、見つけにくく理解しにくく変えにくいとも説明されています。

用語の更新と関係の更新は、同じ担当に寄せる必要はありません。たとえば商品名や契約条件は業務側が判断し、DB項目との対応はデータ担当が確認し、AIに渡す文脈の粒度は開発者と一緒に詰めるという分け方ができます。この分け方は比較のための提案であり、各社の正式な体制や標準手順を示すものではありません。

広告制作から見えた業務語彙や承認条件を開発の検討材料にする場合は、制作物の表現だけでなく、どの判断が社内で承認されるのかまで切り分けます。SynClipの方針は、広告・制作業務を起点に企業固有のカスタム開発と共創へつなぐものです。この事実は、役割や費用内訳を約束するものではなく、検討範囲を業務理解から実装へ広げる前提として扱います。

詳しい手順はナレッジグラフとGraphRAGとの役割の違いをご覧ください。

詳しい手順は広告業務の六概念と関係を定める方法をご覧ください。

自社の業務で試す

ここで整理した業務の概念と関係の設計は、インパクトトライアル（最短1ヶ月のスピード検証）として提供しています。自社の商品資料や既存の台本で試す場合は、インパクトトライアルのページをご覧ください。

インパクトトライアルの進め方と費用を見る