制作チームから届く「このロゴの使い方・色・表記は広告主の規定に合うか」の質問に、広告主ごとのブランドガイドラインと過去の修正指示を根拠に答える

処理の起点を決める

起点は、制作チームの誰かが質問画面から質問を送ったことです。 広告主は一覧から選ばせ、その人が担当グループに入っている広告主だけを一覧に出します。 質問の本文は自由文ですが、「ロゴ」「色」「書体」「商品名・表記」「コピーの言い回し」「その他」から種類を1つ選ばせます。種類は検索の文の先頭に入れ、出典の節の当たりをよくします。

質問は1件ずつ、送られたその場で処理します。 デザイナーは手を止めて待っているので、まとめて処理する理由がありません。

修正指示が記録表に足されたときも、別の起点として動かします。 窓口の担当が新しい指示を1行足したら、その指示を文書にして取り込み、同じ広告主・同じ種類の質問に過去30日に返した回答を拾って、窓口の担当に一覧で知らせます。 指示より前の回答で、まだ制作中のものがあるかを確かめるためです。

入力データを集める

質を決めるのは、修正指示の「恒久／その案件限り」の列です。 これが空だと、中継プログラムは指示を規定と並べてよいかを決められません。判断がつかない指示は「その案件限り」にしておきます。 決まりとして返さない側に倒すためです。

制作物の画像は、検索にも判定にも使いません。 窓口の担当に回したときに、状況をつかむための添付として受けるだけです。

データの取得方法を決める

ガイドラインは節ごと、修正指示は指示ごとに1つの文書にして、Cloud Storage に置いて取り込みます。 メタデータに、広告主、文書の種類、質問の種類、版、状態、恒久／その案件限り、日付を持たせ、閲覧制御の情報として広告主の担当グループも書きます。

修正指示1件分のメタデータは、例えば次のような形です。

{
  "id": "ADV-017-INS-0142",
  "jsonData": "{\"advertiser_id\":\"ADV-017\",\"doc_type\":\"instruction\",\"category\":\"notation\",\"scope\":\"permanent\",\"issued_on\":\"2026-04-10\",\"status\":\"current\"}",
  "content": { "mimeType": "text/html", "uri": "gs://brand-qa/ADV-017/instructions/INS-0142.html" },
  "acl_info": { "readers": [ { "principals": [ { "group_id": "[email protected]" } ] } ] }
}

指示の本文は、記録表の1行を短いHTMLにして置きます。 原文のメールや校正紙の写真は所在だけを残し、検索には入れません。

閲覧制御は、データストアを作るときに有効にします。 プレビューの提供で、Cloud Storage のデータで使え、社内の ID の仕組みで質問した人を見分け、その人が閲覧できる文書だけを結果に返すとされています。作成後には有効にも無効にもできず、1文書の閲覧者（グループか個人）は3,000までとされています。広告主ごとの担当グループを閲覧者にすれば、1文書あたりの数はわずかです。

そのうえで、絞り込みでも広告主を固定します。 式は advertiser_id: ANY("ADV-017") AND status: ANY("current") のように書けます。閲覧制御だけでは、2社を担当するデザイナーの質問に両社の文書が当たります。 選んだ広告主に限るのは絞り込みの役目です。

AIへ渡す前に整形する

1. ガイドラインを節ごとに分ける … 「ロゴ」「色」「書体」「表記」などの見出しで分け、節ごとの文書にします
2. 版をそろえる … 現行版だけに status: current を付け、旧版には retired を付けます
3. 修正指示を書き出す … メールと校正紙から、指示1件を1行にし、原文の所在を残します
4. 恒久かその案件限りかを決める … 広告主の言葉に「今後は」「以後」があるか、案件名が付いているかで窓口の担当が決めます
5. ガイドラインに反映済みの指示を外す … 改訂で取り込まれた指示は status: retired にします
6. 図の注釈を有効にする … データストアを作るときに、レイアウトパーサーの画像の注釈と表の注釈を有効にします
7. 文書の分割を設定する … データストアを作るときに分割を有効にし、見出しを各断片に付けます

6番目と7番目は、データストアを作る前に決めます。 画像の注釈も表の注釈も作成時の設定で、分割の設定は作成後に変えられないとされています。断片の大きさは100〜500トークンで指定でき、見出しを断片に含める設定（既定は無効）を有効にすると、「ロゴの節の、使ってはいけない例の図」であることが断片だけで分かります。

4番目は、広告主の言葉で決めます。 「今後は」「以降すべての制作物で」とあれば恒久、「今回の店頭販促では」のように案件が名指しされていれば案件限りです。どちらとも読めないものは案件限りにし、次の打ち合わせで広告主に確かめます。

5番目を軽く見ないでください。 ガイドラインの改訂に取り込まれた指示が残っていると、改訂で値が変わった色について、改訂前の指示が「恒久の指示」として並びます。

AIに処理させる

させるのは、質問に当たる規定と恒久の修正指示を見つけ、書かれている値と言葉をそのまま、出典を付けて短く返すことです。

根拠の列を混ぜないことが、この構成で最も大事な点です。 規定と恒久の指示は「この広告主の決まり」、案件限りの指示は「そのとき言われたこと」です。3つ目が1つ目と同じ文で返ると、制作チームは決まりとして守り続けます。

answer メソッドの設定は次のようにします。

回答が返ったら、中継プログラムが出典を doc_type と scope で分けます。 本文の出典に scope: one_off が入っていたら、その文を本文から外して参考の枠に移します。次に、規定と恒久の指示が同じ項目について違う値を書いていないかを確かめ、違えば窓口へ回します。

1行目が最も起きやすい失敗です。 「Webで使う色の値は」と聞かれると、モデルは印刷用のCMYKの値からRGBを計算して答えます。ガイドラインがWeb用の値を別に定めていれば、計算した値とは違います。 書かれた値だけを返させ、書かれていなければ窓口へ回します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは広告会社の窓口の担当として、制作チームからの質問に、
選ばれた広告主のブランドガイドラインと修正指示の該当箇所を示して答えます。
読むのはデザイナーとコピーライターで、あなたの回答を見て出典の箇所を開きます。

【答え方】
1. 「ガイドライン」として、該当する節の名前と、規定の内容を書いてください。
   値（余白の比率、最小の大きさ、色の値、書体名）は書かれているとおりに書いてください。
2. 「修正指示」として、恒久の修正指示があれば、日付と内容を書いてください。
3. どちらにも該当が無ければ、その旨だけを書いてください。

【厳守事項】
- 選ばれた広告主の文書だけを根拠にしてください。
- 色の値を換算しないでください。媒体ごとの値が書かれていなければ、
  「この媒体の色の値は記載がありません。窓口の担当が確認します」と書いてください。
- 規定に書かれていない使い方について、可否を書かないでください。
  「規定に記載がありません。窓口の担当が広告主に確認します」と書いてください。
- ガイドラインと修正指示が同じ項目で違う内容のときは、どちらが正しいかを書かず、
  「ガイドラインと修正指示の内容が異なります。窓口の担当が確認します」と書いてください。
- 特定の案件だけの指示を、今後の決まりとして書かないでください。
- 図で示された決まりは、図の説明の言葉で書き、図にない内容を足さないでください。
- 表記のルールは、全角・半角、記号（®、™など）、送り仮名を含めて書かれているとおりに書いてください。

「値を書かれているとおりに」と「換算しない」を別々に書くのが要です。 前者だけでは、モデルは「書かれている値」をもとに計算した値を親切に足します。計算そのものを禁じ、書かれていないことを窓口へ回す合図にします。

検索の文は、中継プログラムが画面の入力から組み立てます。 例えば「質問の種類：ロゴ、制作物：ECモールの商品ページ、質問：ロゴを白い背景の上に置くとき、周りの余白はどれだけ空けるか」のように、種類と制作物を先に並べ、質問の本文を最後に置きます。

出力形式を固定する

answer メソッドの応答と裏付けの検査の結果を、中継プログラムが次の形に整えます。

{
  "question_id": "",
  "advertiser_id": "",
  "category": "logo | color | typeface | notation | copy | other",
  "media": "",
  "status": "answered | routed | skipped",
  "route_reason": "not_in_guideline | conflict | color_not_specified | low_support | none",
  "guideline": [ { "section": "", "version": "", "text": "", "uri": "" } ],
  "permanent_instructions": [ { "date": "", "text": "", "source": "" } ],
  "reference_one_off": [ { "date": "", "campaign": "", "text": "" } ],
  "support_score": 0,
  "answer_text": ""
}

1つ目の理由は、規定・恒久の指示・案件限りの指示を別々の配列で持てることです。 質問画面では、reference_one_off を灰色の「参考」の枠に出し、「この案件だけの指示です」と表示します。

2つ目は、version を残せることです。 ガイドラインが改訂されたとき、旧版を出典にした回答を拾えます。

3つ目は、route_reason の件数を広告主ごとに数えられることです。 not_in_guideline が多い広告主は、ガイドラインに載せてほしい項目を広告主に提案する材料になります。

システムへ連携する

ガイドラインの原本と記録表には書き込みません。 広告主への問い合わせで決まったことは、窓口の担当が記録表に1行足します。この構成が自動で決まりを足すと、広告主の確認を経ない決まりが増えます。

人が確認する

質問画面へ直接返った回答も、制作チームが出典の箇所を開いて確かめます。

1. 広告主を確かめる … 出典の文書が、選んだ広告主のものかを見ます
2. 出典を原文で読む … 値と言葉は、回答の文ではなくガイドラインの節で確かめます
3. 参考の枠を決まりとして扱わない … 案件限りの指示は、今の案件に当てはまるかを窓口の担当に聞きます

窓口の担当は、待ち行列に回ってきたものだけを見ます。 規定に無いものは広告主に問い合わせ、決まったら記録表に恒久の指示として足します。次に同じ質問が来たときには、直接返るようになります。

目標は、600件をならして1件3分です。 回る割合が3割前後という想定で、広告主への問い合わせの往復は含めていません。

例外に対処する

3行目は、記録表を正す材料になります。 食い違いの多くは、改訂で取り込まれた指示を retired にし忘れたものです。

記録を残す

• 質問の全文（広告主、種類、本文、制作物の種類）と日時、質問した人
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• check grounding API の結果
• 振り分けの結果と、窓口の担当が最終的に答えた内容
• そのとき参照したガイドラインの版と、修正指示の記録表の内容

最後の行を残すのは、校正で修正を受けたときに経緯を説明するためです。 回答の時点で指示が記録されていなかったのか、記録されていたのに見落としたのかを、当時の記録表で区別できます。