広告会社がバナーのサイズ展開の画像を Gemini で点検し、文字の切れ・ロゴの欠け・表記の違いを入稿前に拾う
承認済みの基準のバナーから作った10〜20サイズの展開の画像を、基準の画像と原稿表と並べて点検します。文字の切れ、ロゴの欠け、注釈の抜け、価格や期間の表記の違いの候補を枠付きで拾い、直しの依頼の下書きにします。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- EC/不動産/小売/広告
- 対象部門
- マーケティング
- 対象業務
- 内容確認・チェック/比較検討
- 主な課題
- 人手が足りない/属人化している/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- デザイナーが、承認済みの基準の画像から各サイズに展開し、共有フォルダの案件のフォルダに書き出す
- 進行担当が、原稿表の行と基準の画像を開いて、横に並べる
- サイズ展開の画像を1枚ずつ開き、文字の切れ、ロゴの欠け、要素の重なりを探す
- 見出し・価格・期間・注釈・ボタンの文言を、原稿表と1つずつ見比べる
- 画像のピクセルの寸法と容量が、入稿先の規定に合っているかを確かめる
- 気になる点を、サイズと場所を添えてデザイナーへのメモに書く
- デザイナーが直し、進行担当がもう一度見る。そろったら入稿する
- 人デザイナーが、サイズを入れたファイル名で、案件のフォルダにサイズ展開の画像を書き出し、「展開完了」の印を付ける
- 自動プログラムが印を見て動き、原稿表の行と基準の画像を引く
- 自動プログラムが、ファイル名のサイズと実際のピクセルの寸法、容量、形式を入稿先の規定と照らす
- 自動サイズごとに、基準の画像と展開の画像を Gemini API に渡し、文字の書き写しと位置、ロゴの位置、切れ・欠け・重なりの候補を受け取る
- 自動プログラムが、書き写した文字を原稿表と文字列で突き合わせ、違う箇所を拾う
- 自動プログラムが、注釈と価格の文字の高さの比と距離を枠から計算し、候補に印を付ける
- 自動候補を枠付きの画像と一覧にし、デザイナーへの直しの依頼の下書きを作る
- 人進行担当が、候補のあるサイズだけを開いて確かめ、依頼を直してデザイナーに送る
- 人直しの後の画像はもう一度2番目から流し、候補が消えたら入稿する
各工程の詳しい説明を読む
- デザイナーが、承認済みの基準の画像から各サイズに展開し、共有フォルダの案件のフォルダに書き出す
- 進行担当が、原稿表の行と基準の画像を開いて、横に並べる
- サイズ展開の画像を1枚ずつ開き、文字の切れ、ロゴの欠け、要素の重なりを探す
- 見出し・価格・期間・注釈・ボタンの文言を、原稿表と1つずつ見比べる
- 画像のピクセルの寸法と容量が、入稿先の規定に合っているかを確かめる
- 気になる点を、サイズと場所を添えてデザイナーへのメモに書く
- デザイナーが直し、進行担当がもう一度見る。そろったら入稿する
(a)小さいサイズほど見落とす。 320×50や300×50のモバイルのバナーは、画面の上で拡大しないと注釈の文字が読めません。拡大して見る手間を省いた日に、「※税込」が消えたまま入稿されます。
(b)見比べの丁寧さが人によって違う。 ある進行担当は価格の桁まで見て、別の担当は見出しだけを見ます。同じ広告主の案件でも、担当が変わると差し戻しの件数が変わります。 点検の手順が担当の頭の中にあり、新しく入った人には伝わっていません。
(c)1文字の違いが目に入らない。 「10/31まで」と「10/30まで」、「1,980円」と「1,890円」は、基準の画像を見慣れているほど同じに見えます。展開の途中で古い原稿表の値が混ざると、その違いは見た目では分かりません。
(d)差し戻しが入稿の後に来る。 媒体の審査や広告主の確認で見つかり、直す間は配信が止まります。
- 【人】 デザイナーが、サイズを入れたファイル名で、案件のフォルダにサイズ展開の画像を書き出し、「展開完了」の印を付ける
- 【自動】 プログラムが印を見て動き、原稿表の行と基準の画像を引く
- 【自動】 プログラムが、ファイル名のサイズと実際のピクセルの寸法、容量、形式を入稿先の規定と照らす
- 【自動】 サイズごとに、基準の画像と展開の画像を Gemini API に渡し、文字の書き写しと位置、ロゴの位置、切れ・欠け・重なりの候補を受け取る
- 【自動】 プログラムが、書き写した文字を原稿表と文字列で突き合わせ、違う箇所を拾う
- 【自動】 プログラムが、注釈と価格の文字の高さの比と距離を枠から計算し、候補に印を付ける
- 【自動】 候補を枠付きの画像と一覧にし、デザイナーへの直しの依頼の下書きを作る
- 【人】 進行担当が、候補のあるサイズだけを開いて確かめ、依頼を直してデザイナーに送る
- 【人】 直しの後の画像はもう一度2番目から流し、候補が消えたら入稿する
8番目が、この設計の分かれ目です。進行担当は全部のサイズを開き直しません。 候補の無いサイズは、一覧でサイズと書き写した文字を流し見るだけにします。候補のあるサイズと、書き写しが原稿表と合わなかったサイズに時間を使います。
5番目と6番目をプログラムに置くのは意図してのことです。 文字の一致も高さの比も、書き写しと枠があれば計算で出せます。
02今回想定するシステム構成
デザイナーがサイズ展開を書き出す(ファイル名にサイズ) ▼【トリガー】案件のフォルダに「展開完了」の印 Python のプログラム(社内のサーバー) ├── 原稿表の行と基準の画像を引く ├── 寸法・容量・形式を入稿先の規定と照らす(AIを使わない) ├── GIF のコマを PNG に書き出す ▼ Gemini API(画像の理解・構造化出力)── サイズごとに基準と展開の2枚 │ 文字の書き写し(役割・枠)、ロゴの位置 │ 切れ・欠け・重なり・背景との区別がつきにくい箇所の候補 ▼ Python ── 原稿表との文字列の突き合わせ、注釈と価格の高さの比と距離 ▼ 候補の一覧と、枠を描いた画像と、直しの依頼の下書き ▼ 【人】進行担当が確かめる → デザイナーが直す → 入稿
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Gemini API(基準と展開の画像を比べ、文字の書き写しと候補を返す) | Claude API、OpenAI API |
| 連携 | Python(印の検知、寸法と容量の照合、原稿表との突き合わせ、枠の描画) | Google Apps Script |
| 原稿表 | 表計算のファイル(案件ごとの見出し・価格・期間・注釈・ロゴの種類) | - |
| 保管 | 制作物の共有フォルダ | - |
新しく足すのは、Python のプログラムと Gemini API の契約、ファイル名にサイズを入れる書き出し方です。 入稿するのは、これまでどおり人です。
画像を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、1つのリクエストに複数の画像を入れられます。 基準と展開の2枚を組にして渡します。画像を直接入れる場合は、指示の文と画像を合わせたリクエスト全体が20MBまでです。
ここで一つ合わない点があります。 Google 広告のアップロード型ディスプレイ広告の仕様では、形式は GIF、JPG、PNG で、容量は150KBまでです。GIF は Gemini API の対応形式に入っていません。 動くバナーは、プログラムでコマを PNG に書き出してから渡します。
位置は枠で返させます。 枠は [ymin, xmin, ymax, xmax] の順で、画像の大きさに対して0〜1000に正規化されます。細長い画像でも縦横それぞれを0〜1000で返すので、ピクセルに戻すときは縦と横の倍率を別に掛けます。
出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。enum で値を決まった文字列に絞れ、minItems と maxItems で配列の長さも縛れます。公式の案内は、値はアプリ側で検証するよう書いています。
03どうやって実装するのか
処理の起点を決める
デザイナーが案件のフォルダに「展開完了」の印を付けたときに動きます。 印は、空のファイルを1つ置くか、案件の管理表の欄を「展開完了」にするかのどちらかに決めます。画像の書き出しのたびには動かしません。 書き出しの途中で動かすと、まだ無いサイズが「足りない」として一覧に並び、進行担当が混乱します。
直しの後は、直したサイズだけを流し直します。 デザイナーが直したファイルを上書きすると、プログラムはファイルの更新の日時を見て、前回の点検の後に変わったサイズだけを呼び直します。 変わっていないサイズは前回の結果を使います。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 展開の画像 | サイズごとの画像。ファイル名にサイズと版 | 案件のフォルダ |
| 基準の画像 | 広告主の承認を取った基準のサイズの画像 | 案件のフォルダの「承認済み」 |
| 原稿表の行 | 見出し、価格、期間、注釈の文、ボタンの文言、ロゴの種類、案件の番号 | 原稿表 |
| 入稿先の規定 | 媒体ごとのサイズの一覧、形式、容量の上限 | プログラムに持たせる一覧 |
| ロゴの見本 | 使うロゴの画像(横組み・縦組み・アイコンだけ など) | 広告主から預かったロゴのフォルダ |
| 点検の項目の一覧 | 文字の切れ、ロゴの欠け、要素の重なり、注釈の抜け、背景との区別 | プログラムに持たせる |
質を決めるのは、原稿表の行が最新であることです。原稿表の行に版と更新の日を持たせ、点検の結果にその版を残します。
ロゴの見本は、欠けの見分けに効きます。 ロゴは広告主ごとに横組み・縦組み・アイコンだけの型があり、小さいサイズではアイコンだけにするのが決まりの広告主もあります。 見本を一緒に渡しておくと、決まりどおりのアイコンを「文字が欠けたロゴ」と言いにくくなります。
データの取得方法を決める
展開の画像は、ファイル名からサイズを読みます。 「案件番号_300x250_v2.png」のように、案件の番号・サイズ・版を入れる書き方に決めます。ファイル名のサイズと、画像の実際のピクセルの寸法が違えば、AIを呼ぶ前に止めます。 書き出しの設定の間違いで、600×500の画像に300×250の名前が付いていることがあります。
寸法・容量・形式の照合は、AIを使わずにプログラムで行います。 Google 広告のアップロード型ディスプレイ広告なら、仕様のサイズの一覧、GIF・JPG・PNG の形式、150KBの上限と照らします。媒体ごとに規定を一覧で持ち、案件の管理表の「配信する媒体」の欄で切り替えます。
Gemini API へは、サイズごとに1回、基準と展開の2枚を組にして渡します。 1件で10〜20回の呼び出しを並べて行います。サイズごとに分けると、どの組で比べたかがはっきりし、直しのときにそのサイズだけを呼び直せます。
有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定ですべてのやり取りを保存し(有料の枠で55日)、保存しないときは store=false を付けると案内されています。発表前のセールの価格や新商品の画像を扱うので、保存しない設定にします。
AIへ渡す前に整形する
- 形式の変換 … GIF は Gemini API の対応形式に無いので、プログラムでコマごとに PNG に書き出します。同じ絵のコマはまとめ、違う絵のコマだけを渡します
- 寸法の照合 … ファイル名のサイズと実際の寸法が違うものは、ここで止めてデザイナーに戻します
- 小さい画像の拡大 … 320×50のような細い画像は、注釈の文字が数ピクセルの高さしかありません。整数倍に拡大して渡し、拡大した倍率を記録します。拡大するかは、最小構成で拡大の有無を比べて決めます
- 基準の画像の縮小 … 基準の画像が大きいときは、長い辺を1,200ピクセル程度に縮めます。基準は「何が書いてあるか」の見本なので、細部までは要りません
- 原稿表の正規化 … 全角と半角、改行、空白をそろえた文字列を作っておきます。突き合わせはこの正規化した文字列どうしで行います
- 大きさの確認 … 2枚と指示の文を合わせて20MBを超えないかを見ます。バナーは小さいので、超えることはまずありません
3番目を軽く見ないでください。 公式の案内では、両辺が384ピクセル以下の画像は258トークンで扱われます。画像として小さいことと、AIが文字を読み取れることは別の話です。 拡大で読み取りが変わるかを、自社のバナーで先に確かめます。
AIに処理させる
させるのは、展開の画像の文字を役割ごとに書き写し、位置を枠で返し、切れ・欠け・重なり・背景との区別がつきにくい箇所の候補を返すことだけです。 基準の画像は、どの文字がどの役割かを教える見本として渡します。
| 返すもの | 中身 | 判断できないときの扱い |
|---|---|---|
| 文字の書き写し | 役割(見出し・価格・期間・注釈・ボタン・その他)ごとの文字と枠 | 読めない文字は ? にして、読めた部分だけを返す |
| ロゴ | ロゴの枠と、見本のどの型に近いか | どの型か分からなければ unknown |
| 切れ・欠け | 画像の端にかかって切れている文字、欠けているロゴの枠 | 切れているか、デザインの意図か分からなければ unclear |
| 重なり | 文字やロゴが写真や他の要素と重なっている箇所の枠 | 重なりが意図か分からなければ unclear |
| 背景との区別 | 文字の色と背景の色や模様が近く、読みにくい箇所の枠 | 判断がつかなければ unclear |
| 基準との違い | 基準にあって展開に無い要素の役割 | 見本と同じ役割の要素が見つからなければ not_found |
右端の列の考え方は、迷ったら進行担当に見せる側に倒すことです。 デザインの意図で端にかけた文字か、展開で切れた文字かは、AIには分かりません。分からないものは候補に入れて人に見せ、候補から外すのは人がします。
| させないこと | 理由 |
|---|---|
| 原稿表と合っているかの判定 | 1文字の違いを丸める。プログラムが文字列で突き合わせる |
| 注釈の大きさや距離が適切かの判断 | 表示の適否は人が決める。AIは枠を返し、比はプログラムが出す |
| 景品表示法や媒体の審査に合うかの判断 | 法令と審査の基準の判断は広告主と担当者が行う |
| デザインの良し悪しの評価 | 点検の目的ではない |
| 文言の修正案 | 文言は広告主と取り交わしたもの。AIが書き換えない |
| 写っている人物についての記述 | 点検に要らない |
1行目がいちばん起きやすい失敗です。 原稿表を渡して「合っていますか」と聞くと、価格の2桁が入れ替わった画像でも「合っています」と返ることがあります。書き写しと照合を分ければ、照合の側は決まった答えしか返しません。
指示内容を固定する
あなたは広告会社の制作部で、バナーのサイズ展開を点検する係です。
2枚の画像があります。1枚目は広告主の承認を取った基準の画像、
2枚目は同じ原稿から作った {幅}×{高さ} のサイズ展開の画像です。
2枚目の画像は {倍率} 倍に拡大してあります。
【やること】
1. 2枚目の画像に書かれている文字を、すべて書き写す。
1枚目を見本にして、役割を headline(見出し)/price(価格)/
period(期間)/disclaimer(注釈)/cta(ボタン)/other から選ぶ。
2. 文字ごとに、2枚目の画像の上の枠を [ymin, xmin, ymax, xmax] の順で、
0〜1000 に正規化して返す。
3. ロゴの枠を返し、見本のロゴのどの型(横組み・縦組み・アイコン)に近いかを付ける。
4. 次の候補を探し、枠と種類を返す。
画像の端にかかって切れている文字、欠けているロゴ、
文字やロゴが写真や他の要素と重なっている箇所、
文字の色と背景の色や模様が近く読みにくい箇所。
5. 1枚目にあって2枚目に見つからない役割を返す。
【厳守事項】
- 文字は見えたとおりに書き写してください。原稿表や1枚目の画像に
合わせて直さないでください。読めない文字は ? にしてください。
- 2枚目の文字が1枚目と同じかどうかを判定しないでください。
書き写すだけにしてください。
- 注釈の大きさや位置が適切かどうか、法令や媒体の審査に合うかどうかを
書かないでください。
- デザインの良し悪し、文言の修正案を書かないでください。
- 端にかけた文字が意図か切れか分からないときは、kind を unclear にして
候補に入れてください。
- 写っている人物については何も書かないでください。
「1枚目に合わせて直さない」を書かないと、書き写しが見本に寄ります。 2枚目の価格が「1,890円」でも、1枚目に「1,980円」とあれば、AIはそちらに引っぱられて書き写すことがあります。書き写しが見本に寄ると、照合の側で違いが見つかりません。 見本は役割を教えるためだけに渡していることを、指示の文で縛ります。
出力形式を固定する
サイズごとに、次の形の JSON で受け取ります。 role、kind、logo_type は enum で決まった文字列に絞ります。
{
"size": "320x50",
"scale": 3,
"texts": [
{ "role": "headline | price | period | disclaimer | cta | other",
"text": "秋のまとめ買いセール", "box_2d": [120, 30, 520, 610] }
],
"logo": { "box_2d": [100, 860, 900, 990], "logo_type": "horizontal | vertical | icon | unknown" },
"issues": [
{ "kind": "text_cut | logo_cut | overlap | low_contrast | unclear",
"box_2d": [0, 940, 300, 1000], "description": "右上の文字が画像の端で途切れている" }
],
"missing_roles": ["disclaimer"]
}
1つ目の理由は、texts をそのまま原稿表と突き合わせられることです。 プログラムは role ごとに原稿表の欄を引き、正規化した文字列で比べます。違いは「原稿表:10/31まで/画像:10/30まで」のように並べて一覧に出し、どちらが正しいかは進行担当が決めます。
2つ目は、box_2d から注釈と価格の関係を計算できることです。 プログラムは price と disclaimer の枠の高さをピクセルに戻して比を出し、枠の間の距離も出します。比と距離の一覧を案件をまたいで並べると、どのサイズの型で注釈が小さくなりやすいかが分かります。
3つ目は、missing_roles で消えた要素がすぐ分かることです。 小さいサイズで注釈を落としたとき、書き写しに disclaimer が無いだけでは見落とします。基準にあった役割が無いことを、別の欄で返させます。
response_format の schema には、次のように値を絞った形を入れます(抜粋)。
{
"type": "object",
"properties": {
"size": { "type": "string" },
"texts": { "type": "array", "items": { "type": "object",
"properties": {
"role": { "type": "string", "enum": ["headline", "price", "period", "disclaimer", "cta", "other"] },
"text": { "type": "string" },
"box_2d": { "type": "array", "items": { "type": "integer" }, "minItems": 4, "maxItems": 4 }
},
"required": ["role", "text", "box_2d"] } },
"issues": { "type": "array", "items": { "type": "object",
"properties": {
"kind": { "type": "string", "enum": ["text_cut", "logo_cut", "overlap", "low_contrast", "unclear"] },
"box_2d": { "type": "array", "items": { "type": "integer" }, "minItems": 4, "maxItems": 4 }
},
"required": ["kind", "box_2d"] } },
"missing_roles": { "type": "array", "items": { "type": "string" } }
},
"required": ["size", "texts", "issues", "missing_roles"]
} システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 案件のフォルダ | ファイルの読み取り | 展開の画像、基準の画像、「展開完了」の印 |
| 原稿表 | ファイルの読み取り | 案件の番号で行を引く。版と更新の日も読む |
| Gemini API | API呼び出し(/v1beta/interactions、store=false) | 文字の書き写し、ロゴ、候補、見つからない役割 |
| 点検の結果 | ファイルの作成 | 枠を描いた画像、候補と照合の違いの一覧、直しの依頼の下書き |
| 案件の管理表 | 欄の書き込み | 点検の状態(候補あり/候補なし/寸法の不一致) |
入稿の画面へは、この構成から何も送りません。 点検を通ったものを自動で入稿する経路を作ると、進行担当が見る前の画像が配信されます。原稿表にも書き込みません。 照合で違いが出ても、正しいのが画像か原稿表かは人が確かめます。
直しの依頼の下書きは、サイズごとの候補を1通にまとめます。 「300×250:右上の『期間限定』が端で切れている」「320×50:注釈が見つからない」のように、サイズと場所と何が起きているかを並べ、どう直すかは書きません。 直し方はデザイナーが決めます。
人が確認する
- 寸法の不一致を先に見る … AIを呼ぶ前に止まったサイズです。書き出しの設定の間違いなので、デザイナーに戻すだけで済みます
- 照合の違いを見る … 原稿表と書き写しが違った箇所を、画像で確かめます。書き写しの読み違いか、画像の誤りかを見分けます
- 候補を見る … 切れ・欠け・重なり・背景との区別、見つからない役割、注釈と価格の高さの比と距離です。残すか外すかを決めます
- 依頼を直して送る … 下書きを直してデザイナーに送ります
- 外した候補を記録する … 意図した端の文字を切れと言った、アイコンのロゴを欠けと言った、などの理由を残します
2番目で読み違いを見分けるのは、照合の違いの一部はAIの書き写しの誤りだからです。 小さい注釈の「※」が「*」になる、全角のカンマが抜ける、といったことが起きます。正規化で吸収できるものは正規化の規則に足し、毎週の違いの一覧から読み違いを減らします。
目標は、120件をならして1件10分です。 候補の無いサイズは一覧で流し見て、候補のあるサイズと照合の違いに時間を使います。外す候補が1件で半分を超えるなら、ロゴの見本が足りないか、意図して端にかける表現が広告主の型として登録されていません。
例外に対処する
| 起きること | 対応 |
|---|---|
| ファイル名のサイズと実際の寸法が違う | AIを呼ばずに止め、デザイナーに戻す |
| 容量が入稿先の上限を超える | AIを呼ぶ前に一覧に載せる。容量の圧縮はデザイナーが行う |
| GIF の動くバナー | コマを PNG に書き出し、違う絵のコマごとに呼ぶ。注釈が最後のコマにだけあるなら、そのコマを必ず渡す |
| 原稿表に案件の行が無い | 照合をせず、書き写しと候補だけを出す。進行担当に原稿表の整備を頼む |
| 原稿表が点検の後に変わった | 全サイズを流し直す |
書き写しに ? が多い | 拡大の倍率を上げて呼び直す。それでも多いサイズは人が見る |
JSON の値が enum に無い | そのサイズの結果を一覧に載せず、進行担当に回す |
| 写真に人物が大きく写る | 指示の文で人物を書かせない。点検の結果に人物の記述があれば消す |
上から3行目までが大半を占めます。 どれもAIの精度の問題ではなく、書き出しの設定と、入稿の形式の問題です。 書き出しの設定を案件の型として決めておくほうが、指示の文をいじるより効きます。
記録を残す
- 案件の番号とサイズごとの、展開の画像と基準の画像と、Gemini API が返した JSON の全文
- そのとき照合に使った原稿表の行と版
- 照合の違い、注釈と価格の高さの比と距離の計算の結果
- 進行担当が外した候補と、その理由
- 直しの依頼を送った日時と、直しの後の点検の結果
2つ目で原稿表の版を残すのは、広告主の変更が後から入るためです。 入稿の後に「期間が違う」と言われたとき、点検の時点の原稿表と画像が合っていたのか、原稿表そのものが古かったのかを、この記録で見分けます。
4つ目が、指示の文と正規化の規則を直す材料です。 外した理由で「意図した端の文字」が多ければ、広告主ごとの表現の型を指示に足します。
04実装レベルの3段階
最小構成では件数がさばけません。 1件で10〜20組あるので、月120件には使えません。確かめるための段階です。 半自動化で、1件30分が18分程度になります。 書き写しと照合は自動になりますが、候補の場所を画像で探す作業と、直しの依頼を書く作業が残ります。本格構成で10分になり、この段階が本記事の想定です。 枠を描いた画像と依頼の下書きが、そのまま確認の画面になるからです。 段階を飛ばさないでください。 半自動化の一覧を1か月見ると、読み違いの多い文字と意図した端の表現を使う広告主が分かり、そこを直してから進むほうが外す候補が減ります。
05工数削減シミュレーション
導入後 120件 × 10分 ÷ 60 = 20 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 小売・EC・不動産などの広告主から、セールや募集のバナーを毎月まとめて受注し、1つの原稿を10〜20のサイズに展開して入稿している広告会社・インハウスの制作部門。サイズ展開の点検を進行担当やデザイナー本人の目視に頼っていて、小さいサイズで注釈が消える、価格や期間が原稿表と違う、ロゴが端で欠けるといった差し戻しが入稿の後に見つかる場合。原稿表を表計算のファイルで持っていて、サイズ展開のファイル名にサイズが入っている場合。
- 1つの原稿を2〜3サイズにしか展開しない場合。広告の配信の仕組みが素材を自動で組み合わせるレスポンシブの形式が中心で、固定のサイズの画像をほとんど作らない場合。動画広告が中心の場合。なお、表示が景品表示法などの法令や媒体の審査の基準に合うかの判断、表現やデザインの良し悪しの評価、広告主の承認は、この構成では代替できません。
07最小構成で試す方法
- 先月入稿した案件から5件を選ぶ(うち2件は、入稿の後に注釈の抜けや表記の違いで差し戻されたと分かっているもの)
- その5件の基準の画像とサイズ展開の画像を、サイズごとに組にする
- Gemini API の有料の利用枠で、組ごとに2枚を渡す
- 「2枚目の画像の文字を役割ごとに書き写し、枠を返してください。端で切れている文字、欠けているロゴ、重なり、読みにくい箇所を候補として返してください。1枚目と同じかどうかは判定しないでください」と指示する
- 書き写しを原稿表と手で見比べ、差し戻しの原因になった箇所が出てくるかを見る
5件は必ずやってください。 プログラムを組む前に、「自社のバナーの小さいサイズの文字を、書き写せるのか」を確かめます。 小さいサイズは、拡大して渡した場合と、そのまま渡した場合の両方を試します。
| 出てきた内容 | 判断 |
|---|---|
| 差し戻しの原因になった箇所が、書き写しの違いか候補として出た | 寸法の照合と原稿表との突き合わせのプログラムに進む |
| 書き写しが1枚目の文字に寄っている | 指示の書き方で直る。構成は有効 |
小さいサイズの注釈がほとんど ? になる | 拡大の倍率と書き出しの解像度が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 人が拡大しないと読めなかったのと同じ理由です。書き出しの解像度をデザイナーと相談します。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 書き写しが基準の画像の文字に寄る | 指示で直さないよう縛る。 原稿表はAIに見せない |
| AIに「原稿表と合っているか」を聞く | 照合はプログラムの文字列の比較にする |
| GIF をそのまま送ってエラーになる | 対応形式は PNG、JPEG、WEBP、HEIC、HEIF。コマを PNG に書き出す |
| 動くバナーの最後のコマの注釈を見落とす | 違う絵のコマをすべて渡す |
| 小さいサイズの注釈が読めない | 拡大して渡す。倍率は最小構成で決める |
| 枠をピクセルに戻すときに縦横を取り違える | 0〜1000の正規化を縦と横で別に戻す |
| 意図した端の文字を「切れ」と言う | unclear で候補に入れ、広告主ごとの表現の型を指示に足す |
| 注釈が適切かをAIが判断する | 枠と比までにする。適否は人が決める |
| 発表前の価格や画像がAI側に保存される | 有料の利用枠で store=false にする |
| 点検を通ったものが自動で入稿される | 入稿は人。 この構成から送らない |
上の2行が、この構成の失敗のほとんどです。 どちらも書き写しと照合を一つにする失敗で、分けるかどうかで1文字の違いを拾えるかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 発表前のセールの価格と期間、新商品の画像、広告主のロゴ、物件の写真です。画像にはモデルの人物が写っていることがあります。
- 発表前の情報を保存させない … 有料の利用枠で使い、Interactions API の
storeをfalseにします。規約では、有料のサービスでもプロンプトと応答が禁止された使い方の検知などのために限られた期間記録されることが書かれています。広告主との秘密保持の取り決めで外部のサービスに渡してよいかを、先に確かめます - 人物を書かせない … 指示の文で、写っている人物について書かせません。点検に人物の情報は要りません
- 表示の適否を AI に寄せない … 打消し表示が適切かは複数の要素から総合的に判断されます。この構成が出すのは枠と比と候補までです
- 文言を書き換えさせない … 原稿表の文言は広告主と取り交わしたものです。AIの書き写しを原稿表に書き戻さず、修正案も出させません
- 入稿の責任の所在を変えない … 入稿は、これまでどおり進行担当が確かめて行います。点検の結果に候補が無いことを理由に、目視の流し見を省かないでください
誤りが起きた場合のリスクは、注釈の抜けや表記の違いを見落として配信することと、意図した表現まで直させてデザイナーの手を止めることの2つです。 どちらも、書き写し・照合・判断の3つを分けておく設計で防げます。
10まず何から始めるか
1週目:ファイル名と原稿表の決まりを作る
ファイル名に案件の番号・サイズ・版を入れる書き出し方を決めます。原稿表は、見出し・価格・期間・注釈・ボタン・ロゴの種類の欄に分け、版と更新の日を持たせます。 案件の多い広告主の3社から始めます。
2週目:5件で試す
先月の案件から5件を選び、基準と展開の画像を組にして Gemini API に渡します。差し戻しの原因になった箇所が、書き写しの違いか候補として出るかを最優先で見ます。 小さいサイズは拡大の有無を比べます。
3週目:照合のプログラムを作る
寸法・容量・形式の照合と、書き写しと原稿表の文字列の突き合わせを作ります。正規化の規則(全角と半角、改行、空白、記号)を、2週目の結果を見て決めます。
4週目:案件のフォルダから一覧までをつなぐ
「展開完了」の印で動き、サイズごとに呼び出し、照合の違いと候補の一覧を書き出すところまで作ります。この時点では直しの依頼の下書きを作らず、一覧だけを進行担当が見ます。
2か月目: 枠を描いた画像、注釈と価格の高さの比と距離、直しの依頼の下書きを足します。進行担当が外した候補の理由を毎週数えます。3か月目以降: 対象の広告主を広げ、1件30分が何分になったかを実測します。外した候補の理由が指示の文と正規化の規則に反映され、入稿の後の差し戻しの件数が下がった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
対応する画像の形式が PNG、JPEG、WEBP、HEIC、HEIF であること。画像を直接入れる場合にリクエスト全体が20MBまでであること。1つのリクエストに複数の画像を入れられること。枠が [ymin, xmin, ymax, xmax] の順で0〜1000に正規化され、元の画像の大きさに戻す必要があること。画像のトークンの換算(両辺が384ピクセル以下は258トークン、それより大きいものは768×768の区画ごとに258トークン)。例が /v1beta/interactions を使っていること | Gemini API: Image understanding | 2026-10-15 |
構造化出力が /v1beta/interactions に response_format で mime_type を application/json にし、schema にスキーマを入れて送る形であること。enum、minItems、maxItems が使えること。値はアプリ側で検証するよう書かれていること | Gemini API: Structured output | 2026-10-15 |
Interactions API が既定ですべてのやり取りを保存し(store=true)、有料の枠で55日、無料の枠で1日保持すること。store=false で保存しないようにできること | Gemini API: Interactions | 2026-10-15 |
| 有料のサービスではプロンプトと応答が製品の改善に使われないこと。禁止された使い方の検知などのために限られた期間記録されること。18歳以上であることが利用の条件であること | Gemini API Additional Terms of Service | 2026-10-15 |
| アップロード型ディスプレイ広告のイメージ広告のサイズの一覧(200×200から980×120までの20サイズ。320×50、300×50 などのモバイルバナーを含む)。形式が GIF、JPG、PNG であること。容量の上限が150KBであること | Google 広告 ヘルプ: アップロード型ディスプレイ広告の仕様 | 2026-10-15 |
| 打消し表示が適切に表示されているかは、文字の大きさ、強調表示の文字との大きさのバランス、配置箇所、背景との区別などの要素から総合的に判断されること。打消し表示の文字が強調表示に比べて著しく小さい場合、一般消費者が気付くことができないときがあると考えられること。文字の色と背景の色が対照的でない場合に気付かないおそれがあること | 消費者庁: 打消し表示に関する表示方法及び表示内容に関する留意点(実態調査報告書のまとめ) | 2026-10-15 |
表示が景品表示法や媒体の審査の基準に合うかは、広告主と担当者が、最新の法令・ガイドライン・媒体の規定に沿って判断してください。 本記事は公開の資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1686)についてのご相談はこちらから。
