広告の制作担当から出る媒体ごとの入稿規定の質問に、掲載日に効く版の該当箇所を引用して答える
制作担当やデザイナーから出る「この枠は何ピクセルか」「タイトルは何文字までか」「入稿の締切はいつか」の質問に、媒体の入稿規定から該当箇所を探し、掲載日に効く版を示して引用付きで答えます。規定で決まらないものは媒体担当へ回します。
- 生成AI
- Gemini
- AIサービス
- Azure AI/Google Vertex AI/OpenSearch
- 連携・自動化
- Python
- 対象業界
- EC/小売/広告
- 対象部門
- マーケティング
- 対象業務
- 問い合わせ対応/情報検索
- 主な課題
- 問い合わせが多い/情報が見つからない/確認ミスが多い
- AIで行う処理
- 検索(RAG)
- 主な効果
- 品質標準化/対応スピード向上/検索時間短縮
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- RAG・個別開発(大)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 制作担当が、作り始める前や作っている途中に、媒体担当へチャットで質問する
- 媒体担当が共有フォルダを開き、その媒体の入稿規定のPDFかWebページの保存を探す
- 枠の種類と色・形式の条件から、該当するページと表を探して読む
- 改定のお知らせのメールを探し、掲載の時期に新しい版が効いていないかを確かめる
- 規定に書かれていないことは、手元のメモを探すか、媒体社に問い合わせる
- 該当箇所をチャットに書き写して返す
- 人制作担当が、質問フォームで媒体、枠、掲載開始日、質問の種類と質問の文を入れて送る
- 自動中継プログラムが、媒体・枠・掲載開始日から絞り込みの条件を作る
- 自動Agent Search(Vertex AI Search)の answer メソッドが、その媒体の入稿規定と社内の確認記録から該当箇所を探し、引用付きの回答案を返す
- 自動原稿の文が添えられていれば、中継プログラムが媒体の数え方で文字数を数え、規定の上限と並べる
- 自動中継プログラムが、回答案を `answer`(規定の原文で答えられる)/`refer`(媒体担当の確認が要る)に分ける
- 自動`answer` は制作担当へ返す。`refer` は媒体担当の待ち行列に入れる
- 人媒体担当が `refer` の質問を読み、規定を確かめるか媒体社に問い合わせて答える
- 人媒体担当が、媒体社に確かめた答えを確認記録に登録する(翌晩に取り込まれる)
各工程の詳しい説明を読む
- 制作担当が、作り始める前や作っている途中に、媒体担当へチャットで質問する
- 媒体担当が共有フォルダを開き、その媒体の入稿規定のPDFかWebページの保存を探す
- 枠の種類と色・形式の条件から、該当するページと表を探して読む
- 改定のお知らせのメールを探し、掲載の時期に新しい版が効いていないかを確かめる
- 規定に書かれていないことは、手元のメモを探すか、媒体社に問い合わせる
- 該当箇所をチャットに書き写して返す
(a)媒体と枠ごとに規定が分かれ、探すのに時間がかかる。 同じ新聞社でも、紙面の広告とデジタル版の広告で規定が別の文書です。交通広告は、鉄道会社ごと、さらに車両と駅で分かれます。「どの文書の何ページか」にたどり着くまでが、1件の時間の大半を占めます。
(b)答えられる媒体担当が限られる。 「この新聞の記事下は、モノクロでも網点の濃度に上限がある」「この鉄道会社は、医療機関の広告は事前に審査用の原稿が要る」。こうしたことは規定のどこかに書かれていますが、どこに書かれているかを覚えているのは長く担当している人だけです。 その人が休むと、質問への答えが半日止まります。
(c)旧い版の規定で作ってしまう。 媒体の改定は、お知らせのメールで届いたり、Webページの更新日が変わるだけだったりします。共有フォルダに新旧の版が並び、ファイル名に日付が無いものもあります。 4月から規定が変わる媒体に、5月掲載のデータを3月に作り始めたとき、どちらの版で作るべきかが分かりません。
(d)答えがチャットに流れて残らない。 媒体社に確かめた答えも、チャットで返して終わりです。同じ質問が翌月に別の案件から来ると、もう一度探します。
- 【人】 制作担当が、質問フォームで媒体、枠、掲載開始日、質問の種類と質問の文を入れて送る
- 【自動】 中継プログラムが、媒体・枠・掲載開始日から絞り込みの条件を作る
- 【自動】 Agent Search(Vertex AI Search)の answer メソッドが、その媒体の入稿規定と社内の確認記録から該当箇所を探し、引用付きの回答案を返す
- 【自動】 原稿の文が添えられていれば、中継プログラムが媒体の数え方で文字数を数え、規定の上限と並べる
- 【自動】 中継プログラムが、回答案を
answer(規定の原文で答えられる)/refer(媒体担当の確認が要る)に分ける - 【自動】
answerは制作担当へ返す。referは媒体担当の待ち行列に入れる - 【人】 媒体担当が
referの質問を読み、規定を確かめるか媒体社に問い合わせて答える - 【人】 媒体担当が、媒体社に確かめた答えを確認記録に登録する(翌晩に取り込まれる)
5番目の振り分けを、規則で決めるのがこの設計の要です。 表現が審査を通るかを問う質問、掲載開始日に効く版が登録されていない質問、引用が社内の確認記録だけで規定の原文に無い質問は、必ず refer にします。 審査の可否は媒体社が決めることで、この構成では答えません。
8番目を省くと、この構成は育ちません。 媒体社に確かめた答えが記録に残らなければ、次に同じ質問が来たときも refer になり、媒体担当の手が減りません。
02今回想定するシステム構成
入稿規定(PDF・Webページの保存) 改定のお知らせ 社内の確認記録 │ 媒体・枠・版・効力の始まる日を付ける │ 媒体・枠・確かめた日 ▼ ▼ Cloud Storage ── メタデータ(JSON Lines) ▼ Agent Search(Vertex AI Search)── データストア(レイアウト パーサー、表の注釈) │ media_id/placement/doc_kind/effective_from/effective_to ▼ 質問フォーム ──【トリガー】制作担当の送信 ▼ 中継プログラム(Python、Cloud Run) ├──▶ 媒体・枠・掲載開始日から絞り込み ├──▶ answer メソッド:該当箇所の引用と回答案 ├──▶ 原稿の文字数を媒体の数え方で数える └──▶ answer / refer の振り分け ▼ 制作担当へ返信 / 媒体担当の待ち行列
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 検索基盤 | Vertex AI Search(Agent Search)の answer メソッド | Azure AI Search、Amazon OpenSearch Service |
| 生成AI | Gemini(answer メソッドの回答の生成に使うモデル) | ─ |
| 連携 | 中継プログラム(Python。Cloud Run で動かし、フォーム・検索・待ち行列をつなぐ) | Node.js で同じものを書く |
| 集計 | 中継プログラムの文字数の計数(媒体ごとの数え方の表から) | ─ |
| 保管 | Cloud Storage(入稿規定の版ごとの写しとメタデータ、質問の記録) | ─ |
案件管理の表と共有フォルダは、今あるものをそのまま使います。 共有フォルダの入稿規定を版ごとに Cloud Storage へ写すだけで、案件管理の表には書き込みません。 入稿そのものは、これまでどおり媒体担当と制作進行が媒体社へ行います。
検索の土台は、Agent Search(Vertex AI Search から改称中)の answer メソッドです。 公式のドキュメントでは、検索の結果から回答を作る方法で、引用を付ける設定(includeCitations、既定は無効)、回答を求めていない書き込みや敵対的な問いに答えない設定、関係の薄い内容で答えない設定(ignoreLowRelevantContent)、回答の作り方を自然文で指示する preamble があります。
入稿規定の取り込みには、レイアウト パーサーを使います。 公式では、段落・表・リスト・見出しを検出し、チャンクに上位の見出しを付ける設定(includeAncestorHeadings)があり、チャンクの大きさは100〜500トークンです。表の注釈(table annotation)を有効にすると、表とその説明が1つのチャンクに入ります。 入稿規定は「枠ごとのサイズと形式の表」が中心なので、この設定が効きます。
03どうやって実装するのか
処理の起点を決める
起点は、制作担当が質問フォームを送信したことです。 チャットで受けていた質問をフォームに寄せます。媒体、枠、掲載開始日が欠けた質問は、どの文書のどの版で答えるかが決まりません。 フォームで必須にしておけば、後段で聞き返す件数が減ります。
| フォームの項目 | 書き方 | 使い道 |
|---|---|---|
| 媒体 | 一覧から選ぶ | 絞り込み |
| 枠 | 媒体ごとの一覧から選ぶ(全5段、中吊り、画像など) | 絞り込み |
| 掲載開始日 | 日付 | 版の絞り込み |
| 質問の種類 | サイズ・解像度/文字数・表記/形式・容量/締切・日程/審査・表現/その他 | 振り分けの規則 |
| 質問の文 | 自由記述 | 検索の質問文 |
| 原稿の文 | 任意。タイトルや説明文の案 | 文字数の計数 |
もう一つのトリガーは、入稿規定の改定です。 媒体からお知らせのメールが届いたら、媒体担当が新しい版を置き、メタデータに効力の始まる日を書きます。Webページで公開されている規定は、毎月1回、ページの更新日を見て、変わっていれば写しを保存します。 更新日だけが変わって履歴が無いページは、自社で写しを残さない限り、前の版が手元から消えます。取り込みは毎晩まとめて行います。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 質問の内容 | フォームの6項目と、質問した担当者・案件番号 | 質問フォーム |
| 入稿規定 | 媒体・枠ごとのサイズ、解像度、色、形式、容量、文字数、表記の決まり、締切、審査の手順 | 媒体から受け取ったPDF、Webページの保存 |
| 改定のお知らせ | 改定の内容と、効力の始まる日 | 媒体からのメール |
| 社内の確認記録 | 質問の要旨、媒体社の答え、確かめた日、確かめた相手の部署 | 媒体担当のメモから作る |
| 文字数の数え方の表 | 媒体ごとに、半角と全角の数え方、改行・記号の扱い | 入稿規定から起こしたもの |
質を決めるのは、すべての文書に付ける「媒体」「枠」「効力の始まる日」です。 枠を付けずに取り込むと、同じ媒体の別の枠のサイズで答えます。効力の始まる日を付けずに取り込むと、新旧の版が同じ重さで並び、どちらが引かれるかは検索の結果しだいになります。
改定のお知らせは、規定の本文とは別の文書として取り込みます。 お知らせは規定の一部だけを書き換えるもので、本文の新しい版が届くまでは、お知らせのほうが効力のある記述です。
社内の確認記録は、1件1文書にします。 質問の要旨、媒体社の答え、確かめた日、媒体と枠を見出しで分けます。確かめた相手と日付が書かれていない古いメモは取り込みません。
データの取得方法を決める
入稿規定・お知らせ・確認記録は、1件ごとにファイルにして Cloud Storage に置きます。公式では、非構造化データは TXT・JSON・Markdown・PDF・HTML・DOCX・PPTX・XLSX・XLSM に対応し、1ファイルの上限は200MBです。メタデータは JSON Lines で、1行ごとに id、structData、content(mimeType と uri)を書きます。
{"id":"spec-lineads-20260630","structData":{"doc_kind":"spec",
"media_id":"M-LINEADS","media_type":"digital",
"placement":["image","video","carousel"],
"effective_from":"2026-06-30T00:00:00Z",
"effective_to":"9999-12-31T00:00:00Z",
"source_url":"https://www.lycbiz.com/jp/manual/line-ads/policy_009",
"captured_at":"2026-07-01"},
"content":{"mimeType":"text/html","uri":"gs://media-specs/spec-lineads-20260630.html"}}
| 項目 | 中身 | 使い道 |
|---|---|---|
doc_kind | 規定/お知らせ/確認記録 | 振り分けの規則、表示 |
media_id | 媒体の番号 | 絞り込み |
placement | その文書が対象にする枠(複数) | 絞り込み |
effective_from/effective_to | 効力の始まる日と、次の版の前日 | 掲載開始日で版を選ぶ |
source_url/captured_at | 元のページと、写しを取った日 | 回答に版の出どころを示す |
質問のたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、日時の項目は ISO 8601 の文字列と比べられます。
media_id: ANY("M-LINEADS") AND placement: ANY("image")
AND effective_from <= "2026-11-20T00:00:00Z"
AND effective_to >= "2026-11-20T00:00:00Z"
日付は「質問した日」ではなく「掲載開始日」で入れます。 1月掲載から規定が変わる媒体に、11月に1月掲載分の質問が来たら、まだ効いていない新しい版で答えます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。
AIへ渡す前に整形する
- 規定を枠ごとに印を付ける … 1つのPDFが複数の枠を定めている場合、
placementに全部の枠を並べます - 版と効力の始まる日を付ける … お知らせのメールと規定の表紙から、版ごとの効力の始まる日を書き、前の版に
effective_toを書きます - Webページの規定は写しを取る … ページの更新日が変わったら、その日のページをHTMLで保存し、
captured_atを付けます - 確認記録を整える … 媒体担当のメモから、質問と媒体社の答えを拾い、確かめた日と相手の部署を付けて1件ずつ文書にします。広告主の名前は外します
- 文字数の数え方の表を作る … 媒体ごとに、半角と全角を同じに数えるか、改行や記号をどう数えるかを、規定の原文から起こします
- 質問の文から広告主の名前を外す … 掲載前のキャンペーンの名前や商品名が入っていたら、検索の質問文から外します
2番目の作業がいちばん大事です。 新しい版を置くときに前の版の effective_to を書き忘れると、新旧の両方が同じ掲載日で引かれます。 置くときの手順に「前の版を閉じる」を入れておきます。
5番目の表は、AIに文字数を数えさせないために作ります。 「半角全角問わず」かどうかで同じ原稿の数え方が変わるので、数え方は値として持ち、プログラムが数えます。
AIに処理させる
させるのは、その媒体・その枠の入稿規定と確認記録から該当箇所を探し、版の情報を付けて引用し、回答案を書くことです。
| させること | 中身 |
|---|---|
| 該当箇所を探す | 質問の種類に関係する記述(サイズの表、文字数、形式・容量、締切、審査の手順) |
| 原文を引用する | 数値と単位を、規定に書かれたとおりに写す |
| 版を示す | 引いた文書の効力の始まる日と、写しを取った日 |
| 足りない条件を挙げる | 規定を当てはめるために、制作担当が決めるべきこと(カラーかモノクロか、静止画か動画か) |
| させないこと | 理由 |
|---|---|
| 審査を通るかの判断 | 媒体社が決める。規定の該当箇所を示すまでにとどめる |
| 数値の換算や言い換え | 「pixel」を「ピクセル程度」、「半角全角問わず」を「全角」にしない |
| 文字数を数えること | 媒体ごとの数え方の表でプログラムが数える |
| 別の媒体・別の枠の規定で補う | 媒体と枠で数値が違う |
| 一般的な広告の慣行で補う | 「一般にバナーは」と書くと、根拠の無い回答になる |
4つ目の「足りない条件を挙げる」が、制作の現場にいちばん効きます。 新聞の全5段の入稿形式は、カラーとモノクロで別の表です。何を決めれば答えが1つになるかが分かれば、同じ質問を2度回さずに済みます。
answer メソッドの設定は次のようにします。
| 設定 | 値 | 理由 |
|---|---|---|
includeCitations | 有効 | 規定と確認記録に出典を付ける(既定は無効) |
ignoreLowRelevantContent | 有効 | 関係の薄い記述で答えない |
ignoreNonAnswerSeekingQuery | 有効 | 質問でない書き込みに答えない |
filter | 媒体、枠、掲載開始日 | その媒体・その枠の効力のある版だけを引く |
includeGroundingSupports | 有効 | 文ごとの根拠のスコアを受け取る |
answerLanguageCode | ja | 日本語で答えさせる |
preamble | 下の指示 | 答え方の規則を与える |
指示内容を固定する
answer メソッドの preamble に、次の指示を入れます。
あなたは広告会社の媒体担当として、制作担当やデザイナーからの
入稿規定の質問に、媒体の入稿規定と社内の確認記録を根拠に
回答案を作る立場です。読むのは制作の現場の担当者です。
【前提】
検索の文の最初に、媒体、枠、掲載開始日、質問の種類が並んでいます。
検索の対象は、その媒体・その枠の、掲載開始日に効力のある
入稿規定・改定のお知らせと、社内の確認記録だけです。
【答え方】
1. 質問に関係する記述を、文書の名前と見出しを付けて、
本文のまま引用してください。数値と単位は書き換えないでください。
2. 引用した文書の効力の始まる日を書いてください。
3. 改定のお知らせと規定の本文で記述が違うときは、両方を引用し、
お知らせの効力の始まる日を書いてください。
4. 規定を当てはめるために、制作担当が決めるべきこと
(カラーかモノクロか、静止画か動画かなど)があれば挙げてください。
5. 最後に、引用から読める範囲で回答案を2〜3文で書いてください。
【厳守事項】
- 検索結果に無い記述、別の媒体・別の枠の記述で答えないでください。
- 数値を換算・丸め・言い換えしないでください。
「半角全角問わず」「pixel」「以内」などの語も原文のまま書いてください。
- 原稿の文字数を数えないでください。
- 表現が審査を通るか、掲載できるかを判断しないでください。
審査の手順と提出の時期が書かれていれば、それだけを引用してください。
- 社内の確認記録だけが根拠のときは、そのことと確かめた日を書いてください。
- 一般的な広告の慣行や他の媒体の例で補わないでください。
- 該当する記述が見つからないときは、
「該当する記述は見つかりませんでした。媒体担当が確認します」
とだけ書いてください。
- 広告主の名前や商品名を書かないでください。
「数値と単位を書き換えない」を2か所に書くのは、言い換えが善意で起きるからです。 AIは読み手に分かりやすくしようとして、「1200×628pixel」を「横1200・縦628ピクセル」と書き直します。それ自体は誤りではなくても、「以内」が「まで」に、「半角全角問わず」が「全角」に変わった瞬間に誤りになります。 原文のまま写すことを、例外なく求めます。
「審査の手順と提出の時期だけを引用する」は、審査の質問を捨てないためです。 いつまでに誰へ何を出せば審査を受けられるかは、規定に書かれた事実として答えられます。 可否は refer にして媒体担当へ回します。
出力形式を固定する
answer メソッドの返り値と文字数の計数を、中継プログラムが次の形にまとめます。
{
"question_id": "",
"media_id": "",
"placement": "",
"run_date": "",
"question_type": "size | text | format | schedule | review | other",
"citations": [
{ "doc_kind": "spec | notice | internal", "title": "", "heading": "",
"quote": "", "effective_from": "", "captured_at": "", "uri": "" }
],
"conditions_to_decide": [],
"text_count": { "rule": "", "fields": [ { "field": "", "count": 0, "limit": 0 } ] },
"answer_text": "",
"route": "answer | refer",
"refer_reason": []
}
citations は、answer メソッドの references から取ります。公式では、citations の sources が referenceId で references を指し、references の chunkInfo に本文の断片と文書のメタデータが入ります。引用の位置(startIndex/endIndex)は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。
text_count はAIの返り値を使わず、中継プログラムが数え方の表から作ります。limit も数え方の表に起こした値を使い、AIの回答に書かれた数値とは突き合わせて、違えば refer にします。
route は次の規則で決めます。
refer_reason | 立てる条件 |
|---|---|
review | 質問の種類が審査・表現 |
no_version | 掲載開始日に効く版が無い、または answerSkippedReasons が返った |
internal_only | citations に規定・お知らせが無く、確認記録だけ |
notice_conflict | お知らせと規定の本文の両方が引かれ、記述が違う |
number_mismatch | 回答の数値と数え方の表の値が違う |
weak_support | 根拠のスコアが低い文がある |
どれにも当たらないものだけが answer です。 JSONにする理由は、この振り分けを規則で行うためです。answer_text の文章だけでは、確認記録だけが根拠か、お知らせと本文が食い違っているかを機械で判断できません。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 質問フォーム | フォームの送信を中継プログラムが受ける | 6項目を受け取る |
| Agent Search | answer メソッド | 該当箇所の引用と回答案 |
| 数え方の表 | 中継プログラムの設定として持つ | 原稿の文字数を数える |
| 社内チャット | 質問した担当者への返信 | answer の回答を返す |
| 媒体担当の待ち行列 | 共有の一覧に1行足す | refer の質問を回す |
| 社内の確認記録 | 媒体担当が答えを登録 | 翌晩に取り込む |
待ち行列の1行には、質問の内容、引用された箇所、refer_reason、文字数の計数を付けます。 媒体担当は、探すところからではなく、確かめるところから始められます。
案件管理の表と媒体社の入稿の窓口には、何も送りません。 この構成が出すのは規定の該当箇所と回答案までで、入稿は人が行います。
人が確認する
人が確認するのは refer の質問です。 answer の回答は制作担当へ直接返しますが、運用を始めてから1か月は、全件を媒体担当が見てから返します。
refer_reasonを見る … 審査の質問か、版が無いのか、確認記録だけが根拠かを確かめます- 版が無いものは、版の登録漏れを先に疑う … 共有フォルダとお知らせのメールを見て、取り込まれていない版を置きます
- 審査の質問は、規定の手順を確かめて媒体社に出す … 可否はこちらで決めず、媒体社の答えを待ちます
- 確認記録に登録する … 媒体社の答えを、確かめた日と相手の部署を付けて登録します
1か月の全件確認で見るのは、answer で返したものの中に、媒体担当が見れば refer にしたものが無いかです。 あれば、振り分けの規則が足りていません。1割を超えるなら、answer の直接の返信を始めません。
例外に対処する
| 起きること | 対応 |
|---|---|
| フォームの必須項目が欠けている | 送信できないようにする |
| 掲載開始日に効く版が無い | 絞り込みを外さず no_version で媒体担当へ。版の登録漏れを疑う |
| 改定のお知らせが届いたが本文の新版がまだ | お知らせを効力の始まる日付きで取り込み、notice_conflict で両方を示す |
| 枠の一覧に無い枠の質問 | 媒体担当へ回し、枠の一覧に足すかを決める |
| 回答の数値と数え方の表が違う | number_mismatch で媒体担当へ。どちらが正しいかを原文で確かめる |
| 質問に広告主の名前・商品名がある | 検索の質問文から外す |
| 掲載期間が改定日をまたぐ | 掲載開始日と終了日の両方で呼び、結果を並べる |
| 検索の呼び出しが失敗した | 制作担当に「受け付けました。媒体担当から返します」と返し、待ち行列へ |
記録を残す
- 質問の内容(6項目)、質問した担当者と案件番号、日時
- answer メソッドへの要求(絞り込みの条件、
preambleの版)と返り値の全文 - 引用した文書の版(効力の始まる日、写しを取った日)
- 文字数の計数に使った数え方の表の版と、数えた結果
routeとrefer_reason、媒体担当の確認の結果と、媒体社の答え- 制作担当へ返した回答と、返した日時
引用した版を残すのは、入稿で戻されたときに、改定の通知の遅れか旧い版での制作かを切り分けるためです。
04実装レベルの3段階
最小構成では件数がさばけません。 数十媒体の規定を毎回貼ることはできないので、確かめるための段階です。 半自動化で、15分が8分程度になります。 探す時間と版を確かめる時間は減りますが、媒体担当が全件を読んで返す作業が残ります。本格構成で4分になり、この段階が本記事の想定です。 差が大きいのは、answer の質問に媒体担当の手がかからなくなることです。
05工数削減シミュレーション
導入後 240件 × 4分 ÷ 60 = 16 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 新聞・雑誌・交通広告・Web広告など数十の媒体に出稿し、媒体ごと・枠ごとの入稿規定をPDFやWebページで受け取っている広告会社や、広告を内製している小売・EC事業者。制作担当やデザイナーから媒体担当への「このサイズは」「何文字まで」「締切はいつ」の質問が毎月百件を超え、答えられる人が限られている場合。媒体の規定が年に何度も改定され、どの版で作ったかが後から分からなくなっている場合。
- 出稿する媒体が数媒体に限られ、規定を担当者が覚えていられる場合。表現が媒体の審査を通るかどうかの判断をAIに任せたい場合(審査の可否を決めるのは媒体社で、この構成は規定の該当箇所を示すところまでです)。媒体から受け取った規定の写しを社内で保管・検索に使うことを媒体社が認めていない場合。
07最小構成で試す方法
- 質問の多い媒体を3つ選び、その入稿規定のいまの版と前の版を共有フォルダから集める
- 過去2か月のチャットから、その3媒体への質問と媒体担当の答えを20件拾う(改定の前後をまたぐ質問、審査の質問を数件入れる)
- 手元のAIサービスに規定を貼り、質問を1件ずつ、媒体・枠・掲載開始日を添えて入れる
- 第7章の指示を貼り、「原文のまま引用し、数値を言い換えず、審査の可否を書かない」と指示する
- 出てきた回答案を、当時の媒体担当の答えと突き合わせる
| 出てきた内容 | 判断 |
|---|---|
| 当時の答えと同じ箇所を、同じ版から引用した | 検索基盤への取り込みに進む |
| 数値を言い換えた、別の版から引用した | 指示で直るか試す。直らなければ数値の突き合わせと版の絞り込みを最初から作る |
| 規定に無いことを一般論で答えた | 確認記録を貼り足す。媒体社に確かめた答えが残っていないなら、残すのが先 |
3行目が出ることは珍しくありません。 失敗ではなく、媒体担当が答えている内容のうち、どれが規定に無く担当の記憶にだけあるかが分かったということです。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 旧い版の規定で答える | 掲載開始日で効力のある版を選ぶ。前の版の effective_to を必ず書く |
| 数値が言い換えられる | 原文のまま写すよう指示し、数え方の表の値と突き合わせる |
| 別の枠のサイズで答える | placement で絞り込む |
| Webページの規定の前の版が消える | 更新日を毎月見て、変わったら写しを取る |
| お知らせが本文より後に効く | お知らせを別の文書として取り込み、両方を示す |
| 審査の可否を答えてしまう | 審査の質問は refer。手順と時期だけを引用させる |
| 確認記録だけで答えて古い答えが返る | 確認記録だけが根拠のものは refer |
| 項目で絞り込めない | スキーマで項目を索引可能にする |
| 引用の位置がずれる | 位置は UTF-8 のバイト数。文字数で切らない |
上の2行が、この構成の失敗のほとんどです。 どちらも、入稿で戻されるデータを作らせる誤りです。版の選び方と数値の突き合わせを、AIの外の規則で守ります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 媒体の入稿規定(公開のものと、取引先にだけ渡されるもの)、媒体社への確認の記録、制作の現場からの質問(掲載前のキャンペーンの名前や原稿を含みうる)です。
- 媒体から受け取った規定を、社内の検索に使ってよいかを確かめる … 公開されていない規定や媒体資料は、取引先に限って渡されていることがあります。写しを保管して検索に使うことを、媒体社との取り決めに照らして確かめてから取り込みます
- 掲載前の情報を検索に入れない … 原稿の文とキャンペーンの名前は、掲載まで広告主の秘密です。原稿は文字数の計数にだけ使い、検索の質問文と確認記録からは外します
- 審査の可否を答えない … 表現が掲載できるかを決めるのは媒体社です。AIの回答を審査の見込みとして広告主に伝えないよう、制作担当に周知します
- 確認記録から広告主の名前を外す … 別の広告主の案件の質問に、他社の名前が出ないようにします
- データの置き場所を確かめる … 質問の記録を外部のクラウドに置くことになります。データストアを作るリージョンと、広告主との秘密保持の取り決めを合わせて確かめてください
誤りが起きた場合のリスクは、旧い版や別の枠の規定で作ったデータが入稿で戻ることと、審査の見込みを誤って伝えることです。 前者は版と枠の絞り込みで、後者は審査の質問を必ず人に回す規則で防ぎます。
10まず何から始めるか
1週目:質問の多い媒体を決め、規定に版を付ける
過去2か月の質問を数え、質問の多い媒体を3つ選びます。その媒体の入稿規定のいまの版と前の版を集め、版ごとの効力の始まる日を付けます。
2週目:20件の質問で試す
手元のAIサービスに規定を貼り、過去の質問20件を入れます。数値を言い換えていないか、別の版から引用していないかを最優先で見ます。
3週目:確認記録と数え方の表を作る
媒体担当のメモから、媒体社に確かめた答えを20件ほど文書にします。3媒体の文字数の数え方を、規定の原文から表に起こします。
4週目:データストアを作り、媒体担当が使う
規定・お知らせ・確認記録を取り込み、媒体担当が検索画面で質問を入れて回答案を見る運用を始めます。
2か月目: 質問フォーム、文字数の計数、振り分けの規則を作り、全件を媒体担当が見てから返します。3か月目以降: answer の中に媒体担当が refer にしたものが1割未満になったら、answer の直接の返信を始め、媒体を広げます。全媒体の規定に版が付き、改定のたびに前の版を閉じる作業が手順になった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Vertex AI Search が Agent Search へ改称中であること。answer メソッドが検索の結果から回答を作ること。includeCitations の既定が false であること。ignoreAdversarialQuery・ignoreNonAnswerSeekingQuery・ignoreLowRelevantContent、preamble、answerLanguageCode、検索の指定の filter。includeGroundingSupports で文ごとに 0〜1 の根拠のスコアが返ること。answerSkippedReasons。引用の startIndex/endIndex が UTF-8 のバイト単位であること。references の chunkInfo | Google Cloud: Get answers and follow-ups | 2026-10-14 |
絞り込みの ANY() が列挙した値との完全一致を見ること、AND/OR、日時の項目を ISO 8601 の文字列と比べられること、項目を索引可能にする必要があること | Google Cloud: Filter custom search for structured or unstructured data | 2026-10-14 |
非構造化データの対応形式と、1ファイル200MBの上限。メタデータを JSON Lines で id・structData・content(mimeType・uri)として書くこと | Google Cloud: Prepare data for ingesting | 2026-10-14 |
レイアウト パーサーが段落・表・リスト・見出しを検出すること。チャンクの大きさが100〜500トークンで、includeAncestorHeadings で見出しを付けられること。表の注釈(table annotation)を有効にすると表と説明がチャンクに入ること | Google Cloud: Parse and chunk documents | 2026-10-14 |
| LINE広告の入稿規程のページが「2026.06.30 更新」と更新日を表示し、ページ上に変更の履歴が無いこと。タイトルが「20文字以内(半角全角問わず)」、画像が「1200×628pixel」などと定められていること | LINEヤフー for Business: LINE広告の入稿規程 | 2026-10-14 |
入稿規定の内容と審査の可否は、各媒体社の規定と判断に従ってください。 本記事は Google Cloud の公式ドキュメントと媒体社の公開ページで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1442)についてのご相談はこちらから。
