商品資料、訴求、素材、台本、配信結果、修正理由が担当者ごとに別々の言葉で残ると、AIに渡すたびに根拠確認が戻ってきます。広告オントロジーは、用語を並べるだけではなく、広告運用の対象物と関係を固定して、AIと人の確認を同じ言葉でそろえる設計です。
広告業務をつなぐ六つの概念と関係
最小表は商品から始める
必須プロパティとは、AIや担当者が判断を進めるために空欄にしない項目です。広告オントロジーの最小表では、商品、訴求、素材、台本、配信結果、修正理由の6概念を並べ、各概念に最低限の項目、主な関係、人の確認を置きます。
商品から始める理由は、訴求と台本の根拠を商品事実へ戻しやすいからです。SynClipが作成した広告オントロジー定義表 v1は、概念の名前と説明と関係までを整理した知見であり、最初の表ではこの粒度に合わせて実データの細かな対応表へ踏み込みすぎない設計にします。
コーヒー広告の自主制作では、公開ページの台本から訴求と台本の対応表が作られています。この対応表は自主制作であり顧客成果ではなく、訴求と台本の対応を小さく確認するための材料として扱います。商品事実との接続は、対応表に商品事実の列があるものとして読ませず、別の根拠資料で商品事実を置いてから訴求と台本へ結ぶ設計にします。
最初の入力順は、1商品を選び、商品事実を短い文で分け、各事実から使える訴求候補を置き、1つの台本系列へ結びます。配信結果がまだない段階でも、修正理由の欄を先に用意しておくと、根拠外の訴求や素材条件の違反を次回の関係へ戻せます。
1商品1台本系列で始める時は、商品名、確認した事実、使える訴求、使わない訴求、台本のカット、根拠ID、修正理由を同じ行群で追えるようにします。商品欄に事実がなく、訴求欄だけに強い表現が残っている場合は、その表現を台本へ進めず、禁止表現や承認条件の候補へ戻します。
横にスクロールして比較できます
| 概念 | 必須項目 | 主な関係 | 人の確認 |
|---|---|---|---|
| 商品 | 商品名 事実 利用場面 | 訴求を支える | 根拠資料と一致するか |
| 訴求 | 主張 根拠 禁止線 | 台本へ反映する | 根拠外の主張がないか |
| 素材 | 種類 権利 使用条件 | カットで使う | 使用条件に合うか |
| 台本 | カット 文言 根拠ID | 訴求を表現する | 根拠IDが残るか |
| 配信結果 | 配信面 指標 比較対象 | 学習へ戻す | 比較条件が混ざらないか |
| 修正理由 | 理由 対象 戻し先 | 禁止表現や条件へ戻す | 次回に再利用できるか |
詳しい手順は商品資料から事実と訴求候補を分ける手順をご覧ください。
全体像は6領域で持つ
広告オントロジーの全体像は、商材と市場、戦略と計画、クリエイティブ、配信と運用、成果と学習、横断の6領域で持つと、制作だけに閉じない地図になります。SynClipの広告代理店の工程別AI適用表は、広告オントロジーの地図を工程に展開するための知見として扱えます。
商材と市場には、商品、価格帯、利用場面、競合、顧客課題を置きます。戦略と計画には、目的、訴求軸、配信先、対象顧客、検証したい仮説を置き、商材のどの事実がどの訴求を支えるかを結びます。
クリエイティブには、素材、構成、台本、カット、ナレーション、修正理由を置きます。動画制作のサブオントロジーは、本稿の設計案では、クリエイティブ領域の中で素材、カット、台本、編集指示、確認結果を扱う入れ子として置き、広告運用全体から切り離した制作表にはしません。
配信と運用には、配信面、入稿条件、配信設定、停止条件を置きます。成果と学習には、配信結果、比較対象、学び、次回へ戻す判断を置き、横断には承認条件、禁止表現、素材権利、ブランドルールを置くと、AIが動く前に人が確認する関係も同じ地図に残せます。
この段階で置くのは、領域名、概念名、関係名までです。たとえば商品が訴求を支え、訴求が台本に反映され、台本が配信結果と修正理由につながるという関係を先にそろえると、実データの対応表や実装定義へ進む前でも担当範囲のズレを見つけやすくなります。
AIが根拠を保つ業務言語
意味と関係を先に固定する
広告オントロジーでは、商品、訴求、素材、台本、配信結果、修正理由のような概念の名前と説明と関係までを決めます。SynClipの定義表では、研究記録から広告業務に必要な概念を取り出し、名前だけでなく関係まで扱う形にしています。用語集として単語を並べるだけでは、AIが台本の表現を商品事実へ戻して確認する道筋が残りません。
OWL 2の一次資料では、オントロジーを対象領域についての精密な記述の集合として扱い、クラス、プロパティ、個体、データ値を持つものとして説明しています。（OWL 2 Web Ontology（公式））広告業務に置き換えると、商品は概念、訴求や台本との結びつきは関係、商品名や容量などは値として整理できます。文法を覚えるより先に、どの対象を同じ種類として扱い、どの関係を成立させるかを決めることが実務では重要です。
同じ資料では、ラベルだけでは人間の背景知識にある関係をシステムが導けないため、関係を明示する必要があるという説明もあります。（OWL 2 Web Ontology（公式））広告で言えば、商品名と訴求文を同じ資料に置くだけでは、商品事実が訴求を支えるのか、禁止表現として除外されるのか、単なる参考語なのかが残りません。商品が訴求を支える、訴求が台本の一文へ反映される、修正理由が禁止表現へ戻るという関係を先に置くと、出力後の確認で根拠の線をたどる設計にできます。
RDFの一次資料では、主語、述語、目的語の三つで資源同士の関係を表し、同じ資源が複数の関係に現れることでつながりをたどれると説明されています。（RDF 1.1 Primer（公式））広告では、商品が訴求を支え、訴求が台本のカットへ反映され、配信結果や修正理由が次の判断へ戻る関係として考えられます。この関係を固定する目的は、AIが出した一文を単なる生成文ではなく、どの商品事実に支えられた表現かという単位で確認することです。
詳しい手順は概念と属性と関係の基礎をご覧ください。
似た概念との境目を持つ
RAGは、生成前に外部の情報を検索して使う方法です。研究資料では、事前学習済みモデルの知識を、検索された明示的な非パラメトリックメモリと組み合わせる生成モデルとして説明されています。（[2005.11401] Retriev）広告では、商品資料や過去台本を取りに行く手段として役立ちますが、検索で見つかった資料のどの部分が訴求を支え、どの表現を止めるかは別に定義する必要があります。
セマンティックレイヤーは、分析指標の定義を中央に置き、下流のデータツールやアプリケーションで同じ指標を使えるようにする層です。dbtの資料では、売上のような重要なビジネスメトリクスの定義をモデリング層で定義し、ツールをまたいで一貫性を持たせるものとして説明されています。（dbt Semantic Layer（公式））広告運用では、CPAや売上のような指標をそろえる役割に近く、商品、訴求、台本、修正理由の関係そのものを設計する広告オントロジーとは役割が異なります。
ナレッジグラフは、実世界の対象と関係をネットワークとして表すものです。IBMは、ナレッジグラフを実世界の対象とその関係を表すネットワークと説明し、オントロジーとの違いは排他的に分けられるものではないとしています。（What is a knowledg（公式））広告では、実際の商品、台本、配信結果がつながった状態をナレッジグラフとして扱い、その前提になる対象物と関係の型を広告オントロジーとして持つと整理しやすくなります。
境目を持つ理由は、導入する道具を増やすためではありません。検索の仕組みだけを入れると、AIは資料を見つけられても、根拠外の効能訴求を止める条件までは持ちません。指標定義だけをそろえると、配信結果の集計は安定しても、負けた台本のどの訴求を次回変えるべきかまでは残りません。実データのつながりだけを蓄積すると、後から見た時に型と例が混ざり、別の商品へ移す判断が難しくなります。
横にスクロールして比較できます
| 概念 | 主な役割 | 広告での扱い | 境目 |
|---|---|---|---|
| RAG | 外部情報を検索して生成に使う | 商品資料や過去台本を探す | 関係の型は別に要る |
| セマンティックレイヤー | 指標定義を一貫させる | 配信指標や集計名をそろえる | 制作対象の関係は扱いにくい |
| ナレッジグラフ | 対象と関係の実データを結ぶ | 商品や台本のつながりを蓄積する | 型と実データを分けて見る |
| 広告オントロジー | 業務対象と関係の型を決める | 根拠と表現の対応を固定する | 検索手段ではなく設計 |
行動と権限まで考える
広告オントロジーを業務で使うなら、対象物の名前だけでなく、誰が何を実行できるかまで考える必要があります。Palantirの資料では、オントロジーを組織のオペレーション層として扱い、オブジェクト、プロパティ、リンクに加えて、アクション、関数、動的セキュリティを含むものとして説明しています。（オントロジーの構築 • Palant（公式））広告では、生成できる表現、承認前に出せない表現、確認が要る素材、差し戻しになる条件を、業務の関係として持つ発想に置き換えられます。
同じ資料では、オントロジーがデータセットやモデルの上に位置し、顧客の注文や金融取引のような実務上の概念へ接続するものとして説明されています。（オントロジーの構築 • Palant（公式））広告業務に置き換えると、商品、素材、台本、配信結果は単なるファイル名や表の列ではなく、担当者が操作し、承認し、次の判断に使う対象です。AIが使ってよい素材、確認待ちの素材、公開前に止める表現を分けるには、対象の定義と操作の定義を近い場所に置く必要があります。
たとえば、商品事実にない効能を訴求へ入れない、権利確認前の素材を台本の必須カットにしない、担当者承認前のコピーを公開用の表現として扱わない、といった制約があります。これらはAIへの注意書きではなく、商品、素材、台本、承認状態の関係として表すほうが再利用しやすくなります。差し戻し理由も、単発のコメントではなく、禁止表現や確認条件へ戻すことで次の生成に使う判断として扱えます。
根拠IDを出力へ残す
商品事実から台本初稿を作る時は、各カットにどの根拠を使ったかを残すと、後から訴求の出どころを追いやすくなります。ネスカフェ エスプレッソベース 無糖の公式ページで確認した商品事実4件を入力した実行記録では、3カットの台本初稿に根拠IDが付き、味の評価や比較は含まれませんでした。
根拠IDは、台本の良し悪しを自動で保証する印ではありません。広告オントロジーでは、商品事実、訴求、台本カットを結ぶ関係を残すための目印として扱い、担当者はその目印を使って根拠外の表現や比較表現を確認します。
同じ初稿をAI編集者の指示で修正案にした実行記録では、利用場面を先に置きながら根拠IDが維持されています。人の承認ではないため、修正案は公開可否の判断ではなく、表現順を変えても根拠への参照を残す作業例として扱います。
設計する時は、根拠IDを台本末尾のメモに閉じず、各カットの項目として置く形が考えられます。実行記録で示されているのは、商品事実4件から3カットの台本初稿を作った時に、各カットへ根拠IDが付き、味の評価や比較を含めなかったという範囲です。
人の確認を関係に戻す
修正理由は、単なるコメントではなく、次回の生成や確認に戻す関係として扱います。修正理由とは、どの表現をなぜ止めたか、どの根拠や条件へ戻すかを示す業務上の判断です。
架空商品COFFEE-01のブラウザー自動操作デモでは、登録欄に深煎り、ブラジル産、200gが表示され、訴求として脂肪が燃えるを入力した時に根拠にありませんという差し戻しが確認されています。その後、深煎りへ修正し、画面上の確認OKと担当者承認表示まで確認されています。この確認はローカルの架空デモ上の表示であり、実在担当者による承認ではありません。商品IDと登録語の完全一致による確認であり、AI生成や法令審査でもありません。
この確認結果は、人の承認や法令適合を自動化した事実ではなく、根拠外の訴求を止める関係を作るための材料です。脂肪が燃えるのような根拠外訴求は、禁止表現や承認条件へ戻し、深煎りのように登録語と一致する訴求は、商品事実に基づく表現として次回の候補に残します。
詳しい手順は修正理由を次の制作へ残す記録例をご覧ください。
公開できる型と隠すべき中身
実績と検証を分ける
コーヒー広告と商品事実からの台本生成は、自主制作の実物と実行記録として扱います。ネスカフェ エスプレッソベース 無糖の公式ページで確認した商品事実から三カットの台本初稿を作った実行記録では、各カットに根拠IDが付き、味の評価や比較は含まれません。同じ初稿をAI編集者の指示で修正案にした記録では、利用場面を先に置きながら根拠IDを維持しています。
この種の検証は、顧客成果や人の承認と同じ意味ではありません。人の承認、法令審査、広告成果、社内の評価手順は別の判断材料であり、自主制作の検証から同じものとして読ませない方が、導入前の比較がしやすくなります。OWLの一次資料は、オントロジーを対象領域についての精密な記述の集合として扱い、精密な記述は人の誤解を防ぎ、ソフトウェアの振る舞いをそろえる目的を持つと説明しています。（OWL 2 Web Ontology（公式））広告の開示設計では、実績、検証、承認を別の概念として置くと、どの材料から何を判断できるかを分けやすくなります。
検索前に解きたい基本疑問
- オントロジーの正体は何か
- オントロジーは、対象になる世界を概念と関係で表す型です。OWLの一次資料では、オントロジーは関心領域についての精密な記述の集合として扱われ、クラス、プロパティ、個体、データ値を持つものと説明されています。RDFの一次資料では、主語、述語、目的語の三つで関係を表す考え方が示され、同じ対象が複数の関係に参加できるため、つながりを追える構造になります。 広告では、商品、訴求、素材、台本、配信結果、修正理由を別々のメモとして置くのではなく、どれがどれを支えているかまで決めます。SynClipの広告オントロジー定義表は、概念の名前と説明と関係までを整理する設計知見として使えます。たとえば商品事実が訴求を支え、訴求が台本に反映され、修正理由が次の生成条件へ戻る関係を決めると、担当者ごとの言い換えに引きずられにくくなります。
- LLMとの関係は何か
- LLMは文章を作る前に、どの情報を文脈として受け取るかで振る舞いが変わります。Anthropicの資料では、コンテキストエンジニアリングを、推論時に入る情報を選び維持する戦略として説明し、望む出力に近づく高信号の情報を選ぶ考え方を示しています。広告オントロジーは、その文脈に入れる商品事実、素材条件、禁止表現、承認条件の位置づけをそろえる役割を持ちます。 ネスカフェ エスプレッソベース 無糖の公式ページで確認した商品事実から作った台本初稿では、各カットに根拠IDが付き、味の評価や比較は含まれませんでした。同じ初稿を修正案にした実行記録でも、利用場面を先に置きながら根拠IDを維持しています。架空商品COFFEE-01のブラウザー自動操作デモでは、登録語にない訴求を入力した時に根拠にないことを返し、登録済みの深煎りへ修正して画面上の確認OKと担当者承認表示まで確認していますが、これは商品IDと登録語の完全一致による確認であり、AI生成、法令審査、実在担当者による承認ではありません。
- セマンティックとの違いは何か
- セマンティックレイヤーは、売上のような重要な業務指標の定義を集約し、下流のツールやアプリケーションで一貫して使えるようにする層です。dbtの資料では、指標定義をモデリング層へ移すことで、異なる部門が同じ定義から扱えるようにする考え方が示されています。広告で言えば、配信結果の指標名や集計条件をそろえる役割に近いです。 RAGは、生成モデルに外部の記憶を組み合わせ、知識集約型のタスクで根拠や更新の課題に向き合う手法として示されています。ナレッジグラフは、実世界の対象とその関係をネットワークとして表す考え方です。広告オントロジーは検索手段や指標定義だけではなく、商品が訴求を支え、素材が台本に使われ、配信結果と修正理由が次の判断へ戻るという広告業務の対象物と関係の型を決めます。
自社の業務で試す
ここで説明した商品事実から訴求、台本、修正理由までを結ぶ設計は、インパクトトライアル（最短1ヶ月のスピード検証）として提供しています。自社の資料で根拠が残る形を試す場合は、インパクトトライアルのページをご覧ください。
