商品資料をAIへ渡して広告台本を作る時、良さそうな一文ほど、資料のどこへ戻れるのかが不安になります。仕様、利用場面、注意書きが同じ資料に混ざったまま文章生成へ進めると、根拠のある主張と補った表現が見分けにくくなります。
商品理解AIは一発で広告文を作らせるものではなく、商品資料から事実、訴求候補、避ける表現を先に分ける小さな作業として使うと扱いやすくなります。手元の資料1点で試せる範囲と、業務に組み込む時に確認すべき範囲を分けて判断できます。
商品理解AIが読む材料を分ける
商品理解AIは、商品資料の原文を読み、広告制作に使う前の材料へ分けるためのAI活用です。AIに商品情報を理解される前提では、資料を多く渡すよりも、台本へ進める材料を小さく見分けられる状態にすることが先になります。
資料を三つに分ける理由
商品資料には、仕様のようにそのまま確かめられる情報と、広告文へ変換できそうな意味と、先に止めたい表現が同居しています。事実は資料に書かれた属性や仕様、訴求候補は広告で伝えられる意味、避ける表現は根拠にない効能、比較、断定の候補です。
AIへ渡す文脈は有限の情報として扱い、高い信号になる情報を選ぶ考え方が重要です。（Effective context （公式））商品資料も同じで、原文を丸ごと台本へ流すより、事実、訴求候補、避ける表現に分けてから渡す方が、人が確認しやすい材料になります。
たとえば撥水ナイロン、カード8枚、鍵、水中での使用不可という原文が同じ紙面に並ぶと、AIは便利そうな言い回しへ寄せたくなります。最初に三つの欄へ分けると、素材や収納量は事実の欄、持ち歩きやすさは訴求候補の欄、水中でも安心という飛躍は避ける表現の欄に置けます。
横にスクロールして比較できます
| 資料行 | 原文 | 事実 | 訴求候補 | 避ける表現 |
|---|---|---|---|---|
| 素材 | 撥水ナイロンを使用 | 素材は撥水ナイロン | 雨の日も扱いやすい | 完全防水と言い切る |
| 容量 | カード8枚と鍵を収納 | カード8枚と鍵が入る | 小物をまとめやすい | 何でも入ると広げる |
| 注意 | 水中での使用不可 | 水中使用は不可 | 日常の持ち歩き向け | 水中でも安心と書く |
事実と訴求候補の違い
事実は、資料の原文へ戻って確認できる属性、仕様、注意事項です。たとえば素材、容量、対応範囲、対象外の条件は、広告文の前に独立した項目として置くと扱いやすくなります。
訴求候補は、事実を広告文へ変換しうる意味です。撥水ナイロンという事実から雨の日の持ち歩きやすさを考えることはできますが、完全防水という表現は原文の範囲を超えます。
SynClipの公開プロンプト草案では、商品資料から事実、訴求候補、禁止表現を書き出す使い方を想定しています。記入例は、顧客資料ではなく架空資料で添える前提です。
同じ原文から採用文と見送り文を分けると、AIの出力をそのまま採用する判断になりません。事実に戻れる候補だけを採用側へ寄せ、根拠が足りない文は見送り側へ置くと、台本化の前に迷いを減らせます。
カード8枚と鍵を収納できるという原文なら、小物をまとめやすいという訴求候補は資料に戻れます。何でも入る、収納力が圧倒的といった文は、収納点数や比較対象が資料にないため見送り側に置きます。
避ける表現を先に出す
避ける表現は、広告として悪い言葉を機械的に決める欄ではありません。資料にない効能、比較、断定が混ざりそうな候補を先に出し、人が台本化の前に確認するための欄です。
AIシステムの評価では、入力、出力、採点の考え方を分けて見る説明があります。（Demystifying evals（公式））商品資料でも、うまい言い回しを先に作るより、根拠外の候補を分けて止める形にすると、後から各文を確認しやすくなります。
この分け方は、法令審査を置き換えるものではありません。根拠にない効能、競合より優れているという比較、すべての人に当てはまる断定を、台本に入れる前の確認候補として外に出すための整理です。
撥水と書かれた資料から完全防水へ広げる、使用不可の条件を消して安心だけを残す、比較資料がないのに他商品より優れると書く、といった文は先に止める候補です。避ける表現の欄を先に作ると、広告訴求を弱めるためではなく、根拠のある言い換えだけを残すための確認ができます。
商品資料の構造化は小さく進める
まず資料を一つに絞る
商品資料の構造化は、最初から複数の資料をまとめて読ませるより、商品資料を一つに絞るほうが進めやすくなります。商品名、資料の版、広告で扱う対象範囲を先に書くと、AIが見る材料と見ない材料の境界を人が確認できます。商品理解AIを使う場面でも、商品名だけを渡して説明文を作らせるのではなく、原文の範囲を小さく決めてから抽出へ進めます。
コンテキスト設計では、望む出力に近づくために、限られた文脈へ何を入れるかを選ぶ考え方が重視されています。（Effective context （公式））Anthropicのコンテキスト設計の説明では、モデルに入れる情報は有限の資源として扱い、高信号の情報を選ぶ考え方が示されています。商品資料でいえば、全カタログを渡すより、今回の広告で使う商品名、版、対象ページ、原文だけを先にそろえる設計にすると、あとで人が台本化の根拠を追う位置を決めやすくなります。資料の一部だけを使う場合は、見出しやページ名も残し、あとで人が原文へ戻れる形にします。
原文を表へ移す
入力文は短くて構いません。たとえば「この商品資料一つだけを使い、原文、事実、訴求候補、根拠外を分けて表にしてください。資料にない効能、比較、法令適合、顧客実績は補わないでください」と置くと、文章生成の前に材料整理として使えます。公開プロンプト草案は、制作時に架空資料の記入例を添える前提で、商品資料から事実、訴求候補、禁止表現を書き出す用途に寄せています。
表へ移す時は、原文を短く切り、事実と訴求候補を同じ列に混ぜないことが大切です。事実は資料にある属性や条件で、訴求候補は広告文へ変える前の意味です。根拠外は、資料にない効能や比較を足してしまいそうな表現を止める欄として使います。Claudeのプロンプト資料では、プロンプト改善の前に成功条件、経験的に試す方法、改善したい初稿を用意する前提が示されています。（Prompt engineering（公式））商品資料の構造化でも、成功条件はきれいな文章ではなく、原文、事実、訴求候補、根拠外が分かれていることに置くと、表の各行を人が確認しやすくなります。
横にスクロールして比較できます
| 段階 | 入力 | 出力 | 進む条件 |
|---|---|---|---|
| 資料確認 | 商品名と版と範囲 | 使う原文の範囲 | 対象が一つに絞れている |
| 抽出 | 資料内の短い原文 | 事実と訴求候補 | 根拠外が分かれている |
| 採用可否 | 抽出表の各行 | 採用可と要確認 | 人が原文へ戻れる |
| 台本化 | 採用可の事実 | 根拠ID付き台本 | 各文の根拠が残る |
短い流れにすると、スマホでも確認しやすくなります。資料名を見て、版を見て、原文を表に移し、採用可否を分け、台本の一文から原文へ戻る順です。この順番なら、良さそうな広告文を先に選ぶのではなく、使ってよい材料だけを次の工程へ渡せます。
- 資料名と商品名を合わせる
- 資料の版と対象範囲を見る
- 原文を短く表へ移す
- 採用可と要確認を分ける
- 台本の文から原文へ戻す
台本へ渡す条件
台本へ渡すのは、表の中で事実IDが付いた項目だけにします。採用可は、資料内の原文へ戻れて、広告文に変える候補として人が使ってよいと見られる状態です。要確認は、原文には近いものの、表現の強さ、対象範囲、媒体上の見せ方を人がまだ見る状態です。根拠外は、資料にない効能、比較、断定が混じるため、台本へ渡さない状態です。
架空の旅行用ポーチを使った実行では、商品事実を渡した台本初稿の各カットに根拠の事実IDが付き、資料にない表現は含まれませんでした。この結果は一回の試行であり、音読時間や人の承認は検証していません。台本化の条件として使えるのは、AIがきれいな文を出したことではなく、各文がどの事実へ戻るかを人が追えることです。別の実行では、防水を求める条件でも根拠内の三カットを返し、ナレーションに防水語を含めず、見送り理由を返しました。資料なしの条件では状態が確認待ちになり、カット数はゼロでした。採用可に進める判断は、書けた量ではなく、事実ID、見送り理由、停止状態が確認できるかで分けます。
AI評価の考え方では、入力を与え、出力を見て、期待に合うかを採点する構造が示されています。（Demystifying evals（公式））商品資料の構造化でも、出力された表をそのまま完成物にせず、採用可、要確認、根拠外の三つに分けてから次へ進めます。要確認が残る行は台本に入れず、商品担当者や表現を確認する担当者が原文を見てから採用を決めます。
詳しい手順は三条件で台本初稿と修正案を作った実行例をご覧ください。
指示文の骨を本文に置く
入力文の最小形
手元の資料で試す時は、商品資料を広く渡すより、資料名、対象商品、補完してはいけない範囲、出力形式を先に固定します。プロンプト作成は言い回しの工夫だけでなく、成功条件、試し方、最初の草案を用意してから改善する作業として扱うと、広告訴求の根拠を残しやすくなります。（Prompt engineering（公式））
版日は2026-10-04として、資料にない効能、比較、法令適合、顧客実績を補わない条件を入力文に含めます。出力は自由な文章ではなく、事実、訴求候補、根拠外理由、台本への採用状態を分ける形にします。
入力する資料は1点に絞り、商品名や版が分かる名前を先に置きます。対象範囲を資料内の原文だけにすると、後から台本の一文を確認する時に、どの情報を採用したのかを戻しやすくなります。
版日: 2026-10-04
目的: 商品資料1点から、広告台本に使う前の材料を構造化する
入力する資料名: {資料名}
対象商品: {商品名}
対象範囲: この資料に書かれている内容だけ
禁止する補完:
- 資料にない効能を足さない
- 資料にない他社比較を足さない
- 法令適合を確定しない
- 顧客実績や売上を作らない
出力形式:
1. 事実
2. 訴求候補
3. 根拠外として止める表現
4. 台本へ進める時の採用状態
各項目には、資料内のどの原文に戻るかを示す根拠IDを付ける。根拠がない項目は採用可にしない。出力テンプレの骨
出力テンプレは、後で台本の一文から資料へ戻るための骨組みです。架空の旅行用ポーチを使った試行では、3カットの台本初稿に根拠の事実IDが付き、資料にない表現は含まれませんでした。
根拠IDは正しさを保証する印ではなく、人が原文へ戻るためのラベルです。出力テンプレでは、事実ID、原文、訴求候補、根拠外理由、台本への採用状態を同じ単位で持たせ、採用可と要確認と根拠外を混ぜないようにします。
架空ポーチの台本初稿では、カットごとに使った事実が残っていたため、広告文の読みやすさを見る前に資料との対応を確認できました。資料にない表現が混じっていないかを見る時も、完成文だけを読むより、事実IDと原文を並べて確認するほうが判断しやすくなります。
{
"facts": [
{
"fact_id": "F001",
"source_text": "資料内の原文を短く写す",
"fact": "資料に書かれた事実",
"appeal_candidate": "広告文に変換しうる意味",
"out_of_scope_reason": "根拠外の場合の理由",
"script_status": "adoptable | needs_review | out_of_scope"
}
],
"script_handoff": [
{
"line_purpose": "台本で使う目的",
"allowed_fact_ids": ["F001"],
"human_check": "採用前に人が見る点"
}
]
}
変更してよい所
商品カテゴリ、資料名、語調、使用媒体は、自社の商品と広告面に合わせて変えてかまいません。変更する時の設計案として、根拠外を補わないこと、根拠IDを消さないこと、人が採用状態を見られる形にすることは残します。
スマホで確認する時は、変更してよい項目を短く分けると、入力前の見落としを減らせます。入力文の見た目を整えるより、資料の範囲と採用状態が読み取れることを優先します。
語調を変える場合も、元資料にない効能や比較を足す変更は避けます。使用媒体を台本からLPや営業資料へ変える時も、根拠IDと採用状態を残しておけば、人が公開前に原文へ戻って確認できます。
- 商品カテゴリは自社の商品分類へ置き換える
- 資料名は版や日付が分かる名前にする
- 語調は媒体に合わせて変える
- 使用媒体は台本やLPなどに合わせる
公開前に人が見る項目
資料に戻れるか
台本の各文は、よく見える言い回しより先に、元の資料へ戻れる状態にしてから採用します。架空ポーチの試行では、正常条件で参照ID付きの三カットが返り、防水要求では防水語をナレーションに含めず見送り理由を返しました。公開前の確認では、文末の整い方ではなく、その一文がどの原文から来たかを追えるかを見ます。
根拠IDがない文は、採用する文ではなく採用しない候補へ戻します。資料に書かれた事実から離れた文をそのまま残すと、後から修正した時に元資料との対応が切れます。スマホで確認する時も、台本の一文、根拠ID、原文の順で短くたどれる形にすると、制作前の見直しがしやすくなります。
- 台本の各文に根拠IDが付いている
- 根拠IDから原文へ戻れる
- 原文にない効能や比較が混ざっていない
- 商品IDが対象商品と一致している
- 版が承認済み資料と一致している
- 承認者が見直す項目として残っている
言い過ぎが戻ってないか
修正後の台本では、最初に外した言い過ぎが戻っていないかを見ます。架空ポーチの防水要求では、資料内の訴求に戻した三カットを返し、ナレーションに防水語を含めず見送り理由を返しました。根拠外として止めた語が別の言い換えで復活していないかを、人が制作前に確認します。
禁止表現候補や比較表現の確認は、法令判断を完了させる作業ではありません。AIの評価や実行では、出力の誤りが後続の状態へ伝わり、複雑な処理ほど影響が重なることがあります。（Demystifying evals（公式））広告の公開前には、根拠外、要確認、採用可の扱いが修正後も保たれているかを見て、根拠のない効能、最上級表現、競合比較に近い文を採用候補から外します。
版と商品が合っているか
商品IDと版が違うと、文の表現が自然でも広告の根拠として使いにくくなります。旧版と別商品が混在した試行では、全資料五件と選択後一件のどちらでも現行承認資料を参照しました。対象商品が同じでも、旧版、未承認版、別商品の資料が混ざると、公開前の確認では合格にできません。
新版へ更新した試行では、全資料六件と選択後一件のどちらでも現行承認資料を参照しました。ただし、選択後の初稿に仕様外の「日常使いしやすく」が混入し、文章全体の合格ではありませんでした。根拠IDが付いていても、文全体の採否は別に見ます。
資料がない時に止まれることも、公開前の確認項目です。対象商品が見つからない試行では、全資料二件と選択後ゼロ件の両方で確認待ちになり、商品事実を返しませんでした。旧版と未承認版しかない試行でも、全資料三件と選択後ゼロ件の両方で確認待ちになり、商品事実を返しませんでした。資料がない状態で整った文だけを作らないことが、広告訴求の根拠を残すための最低条件になります。
商品理解AIへのよくある問い
- AIに入れない情報
- 社外秘、個人情報、未承認の顧客情報は、商品理解AIへそのまま入れない扱いにします。NISTのAIリスク管理の考え方では、AIシステムの目的、使われる場面、利用者、影響、制約を把握し文書化することが重視されています。商品資料を扱う時も、便利そうだから全文を渡すのではなく、公開済み資料、社内確認中の資料、個人や顧客を特定しうる情報を分けてから判断します。 迷う資料は、匿名化した架空資料に置き換えて試すほうが扱いやすくなります。たとえば商品名、顧客名、担当者名、注文内容を伏せ、仕様や表現の型だけを残せば、商品資料の構造化や広告訴求の根拠づけを小さく確認できます。入力可否の判断では、そのまま使える情報、加工後に使う情報、避ける情報を分け、人が公開可否を見てから次へ進めます。
- 商品の説明を頼む方法
- 商品の説明を頼む時は、商品説明を丸ごと作らせるより、資料一つから事実と訴求候補を分けて出す指示にします。SynClipの公開プロンプト草案は、商品資料から事実、訴求候補、禁止表現を書き出すためのものです。最初の入力文には、資料名、対象商品、資料にない補完をしない条件、出力形式を入れると、説明文へ進む前の材料が分かれます。 台本へ渡す時は、各文に元の事実へ戻れる根拠IDを残します。架空の旅行用ポーチを使った実行では、商品事実三件から三カットの台本初稿が作られ、各カットに根拠の事実IDが付きました。資料にない表現は含まれず、音読時間や人の承認は別の確認として残るため、AI出力だけで公開判断を終えない使い方になります。
- AIにできないこと
- 商品理解AIに任せないことは、資料にない事実の補完、法令適合の確定、人の採用判断の代替です。評価の考え方では、AIへ入力を与え、出力を見て、成功基準に照らす検査が置かれます。商品説明で同じ考え方を使う場合も、検査で見られるのは出力が条件に沿っているかであり、広告として公開してよいかまで一括で決まるわけではありません。 商品資料を扱う場面では、AIは原文から事実や訴求候補を取り出す補助として使います。資料外の効能を足す、未承認の顧客実績を作る、担当者の採用可否を肩代わりする、といった使い方には向きません。根拠にない効能、比較、断定は、台本で使える表現ではなく、人が止める候補として分けます。公開前には、根拠IDが原文に戻れるか、言い過ぎが戻っていないか、商品と版が合っているかを人が見ます。
自社の業務で試す
ここで示した商品資料を訴求の根拠へ結ぶ方法は、インパクトトライアル（最短1ヶ月のスピード検証）として提供しています。自社の商品資料で試す場合は、インパクトトライアルのページをご覧ください。
