販売店・加盟店が作る販促物を毎月点検して、ロゴと商標表示の逸脱を見つける
販売店や加盟店が作った販促物を毎月まとめて取り込み、ロゴの見え方と商標表示の使い方を点検して、ガイドラインから外れている疑いを条項つきで挙げます。担当者の作業は、120点を順番に開いて見ることから、挙がった疑いに是正を求めるかどうかを決めることに変わります。
- 利用ツール
- ChatGPT/Claude/Gemini/Google Apps Script/Make/n8n/Python/Zapier
- 対象業界
- EC/宿泊/小売/広告/飲食
- 対象部門
- マーケティング/知財
- 対象業務
- 内容確認・チェック/情報検索
- 主な課題
- 人手が足りない/属人化している/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 品質標準化/工数削減/機会損失防止
- 導入難易度
- ★★★☆☆
- 実装レベル
- 半自動化
- 費用感
- API連携(中)
- 人間の確認
- 必須
01導入前 / 導入後の業務フロー
- 提出フォルダを開き、前回の点検以降に増えた掲載物を確認する
- チラシのPDF、POPの写真、SNS投稿、Webページを1点ずつ開く
- 正規ロゴの見本を別の画面に並べ、見比べる
- ロゴの版、縦横比、色、周囲の余白、重なり、書体を目で確認する
- 文面を読み、商品名の書き方と登録商標の表示を確認する
- キャンペーン表現が承認済みの一覧にあるかを確認する
- 逸脱がありそうなら、ガイドラインのPDFを開いて該当する条項を探す
- 条項番号と指摘内容をスプレッドシートに記録する
- 許諾済みの使い方かを過去のやり取りで確かめ、是正を求めるかどうかを決める
- 自動毎月1日の定期実行と、提出フォルダへの追加時に処理が始まる
- 自動増えた掲載物を集め、形式と向きと解像度をそろえる
- 自動掲載物から画像とテキストを分ける(チラシのPDFはページごとに画像化する)
- 自動例外リストを当て、許諾済みの使い方・共同販促・経過措置を先に外す
- 自動画像の判定を行う(ロゴの版、縦横比、色、余白、重なり、書体、改変)
- 自動テキストの判定を行う(商標の使い方、表示の有無、承認外のキャンペーン表現)
- 自動疑いごとに、条項番号と掲載物のどの箇所かを返させる
- 自動画像の疑いには枠を描き、テキストの疑いは該当箇所を抜き出して並べる
- 自動点検台帳に「疑い」として記録し、店舗別・区分別に集計する
- 人担当者が疑いの一覧を見て、当たっているかを確かめる
- 人担当者が是正を求めるかどうかを決め、結果と理由が記録される
各工程の詳しい説明を読む
- 提出フォルダを開き、前回の点検以降に増えた掲載物を確認する
- チラシのPDF、POPの写真、SNS投稿、Webページを1点ずつ開く
- 正規ロゴの見本を別の画面に並べ、見比べる
- ロゴの版、縦横比、色、周囲の余白、重なり、書体を目で確認する
- 文面を読み、商品名の書き方と登録商標の表示を確認する
- キャンペーン表現が承認済みの一覧にあるかを確認する
- 逸脱がありそうなら、ガイドラインのPDFを開いて該当する条項を探す
- 条項番号と指摘内容をスプレッドシートに記録する
- 許諾済みの使い方かを過去のやり取りで確かめ、是正を求めるかどうかを決める
問題は4つあります。
(a)1点ずつ開く時間が積み上がる。 1件12分で月120点、2名で分けても月24.0時間です。点検そのものより、開く・並べる・探すの往復に時間が消えています。
(b)見る人によって指摘が変わる。 知財部が見た月とマーケティング部が見た月で挙がる指摘が違い、加盟店からすると「前回は何も言われなかった」ことになります。
(c)根拠を示すのに時間がかかる。 条項を探す作業が1件2分かかり、急ぐとそこを省いて「ロゴの使い方を直してください」とだけ送ることになり、(b)を悪化させます。
(d)許諾済みの使い方を、毎回指摘しそうになる。 共同販促でロゴを並べる約束をした店、旧ロゴの在庫を使い切るまで猶予を与えた店があり、この情報は担当者の記憶かメールの中にしかありません。
- 【自動】 毎月1日の定期実行と、提出フォルダへの追加時に処理が始まる
- 【自動】 増えた掲載物を集め、形式と向きと解像度をそろえる
- 【自動】 掲載物から画像とテキストを分ける(チラシのPDFはページごとに画像化する)
- 【自動】 例外リストを当て、許諾済みの使い方・共同販促・経過措置を先に外す
- 【自動】 画像の判定を行う(ロゴの版、縦横比、色、余白、重なり、書体、改変)
- 【自動】 テキストの判定を行う(商標の使い方、表示の有無、承認外のキャンペーン表現)
- 【自動】 疑いごとに、条項番号と掲載物のどの箇所かを返させる
- 【自動】 画像の疑いには枠を描き、テキストの疑いは該当箇所を抜き出して並べる
- 【自動】 点検台帳に「疑い」として記録し、店舗別・区分別に集計する
- 【人】 担当者が疑いの一覧を見て、当たっているかを確かめる
- 【人】 担当者が是正を求めるかどうかを決め、結果と理由が記録される
最後の2つを自動化しないことが、この設計の中心です。 是正の依頼は取引先との関係に直接ひびきます。同じ逸脱でも、新しい契約を結ぶ直前の店と、今回だけ急いで作った長年の店では、伝え方も伝えるかどうかも変わります。
4番目が(d)の問題を解きます。 例外リストを判定の前に当てるので、許諾済みの使い方が毎月疑いとして挙がりません。逆だと担当者は毎月同じ誤検知を消すことになります。
02今回想定するシステム構成
加盟店の提出フォルダ(チラシPDF・POP写真・SNS投稿・自店Webページ) │ ▼【トリガー】毎月1日の定期実行 + 提出フォルダへの追加時 Make(シナリオ) │ ├──▶ Python ── 形式の統一/向きの補正/解像度の調整/画像とテキストの分離 │ ├──▶ 例外リストの突き合わせ(許諾済みの使い方・共同販促・経過措置) │ ├──▶ Gemini API【画像】── ロゴの見え方の疑い + 疑いの箇所の座標 │ ├──▶ Gemini API【テキスト】── 商標の使い方と表示の疑い + 該当箇所 │ └──▶ Python ── 座標を元のサイズに戻して枠を描く/店舗別・区分別に集計 │ ▼ 点検台帳に「疑い」として記録 │ ▼ 【担当者が確かめ、是正を求めるかどうかを決める】 ├──▶ 求める ──▶ 連絡文の下書き ──▶ 差し替えの記録 └──▶ 求めない ──▶ 理由を残し、例外リストに反映
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 連携 | Make | Zapier、n8n |
| 処理 | Gemini API | Claude API、OpenAI API |
| 集計 | Python | Google Apps Script |
足すのは、連携と処理と集計の3つだけです。 提出フォルダ、点検台帳、連絡手段はいまのままです。
入力の仕様を先に押さえておきます。対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、1リクエストに渡せる画像は最大3,600枚です。HEIC と HEIF がそのまま入るのは、店頭POPがスマートフォンで撮られるこの題材では効きます。 渡し方は3通りあり、インライン(Base64)は総リクエスト20MBまで、大きいファイルや繰り返し使うファイルには File API が推奨され、公開URLの参照もできます。正規ロゴの見本は繰り返し使う側です。
トークンの数え方は設計に直結します。縦横どちらも384ピクセル以下の画像は258トークンで、それより大きい画像は768×768ピクセルのタイルに分割され、タイル1枚あたり258トークンになります(公式の例では960×540の画像は切り出しの単位が360で、各辺を360で割って 3 かける 2 の6タイル)。解像度をむやみに上げてはいけない一方、下げすぎるとロゴの細部が読めないので、二段構えで解決します(第7章の前処理)。
もう一つの土台が、疑いの箇所を座標で返させられることです。バウンディングボックスの座標は[0, 1000] に正規化され、[ymin, xmin, ymax, xmax] の順で返ります(元のサイズに戻すのは利用する側)。これがあるから、疑いの箇所に枠を描いて担当者に見せられます。
03どうやって実装するのか
処理の起点を決める
起点は2つです。毎月1日の定期実行と、提出フォルダへの追加時です。 定期実行はSNS投稿と自店Webページ用で、これらは「提出」という行為がないため月に一度まとめて巡回します。 追加時の起動はチラシとPOP用で、印刷前のチラシにはその日のうちに指摘を返せます。
Make のシナリオはこの2つに1本ずつ作ります。1本に両方の分岐を詰めないでください。 定期実行は大量を一度に、追加時は1点を速く処理します。処理済みの印も掲載物ごとに持ってください。 フォルダ監視では、ファイル名の変更や再アップロードで同じものが2回流れます。
定期実行が動かなかった月を検知する処理も、別に入れてください。疑いの件数が0件だった月と、処理した掲載物が0点だった月は、意味がまったく違います。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 掲載物の画像とテキスト | チラシのページ画像とPOPの写真、SNS投稿とWebページの表示と文章 | 提出フォルダ、URLの一覧 |
| 正規ロゴの見本 | 現行版、旧版、モノクロ版、横組み、縦組み | ブランド資産の管理フォルダ |
| ガイドラインの条項 | 条項番号と本文(ロゴの扱い、商標の表記、表示の方法) | 条項単位に分けたもの |
| 正しい表記・承認済み表現の一覧 | 商品名の正しい書き方、表示の要否、使ってよい表現 | 知財部・マーケティング部の台帳 |
| 例外リスト | 許諾済みの使い方、共同販促、旧ロゴの経過措置と期限 | 知財部(新しく作る) |
| 加盟店の台帳 | 店舗コード、契約区分、過去の指摘の履歴 | 既存の加盟店管理 |
質を決めるのは「ガイドラインの条項」です。 PDFのまま渡してもAIは「第3章のあたり」としか返せません。「L-02 ロゴの縦横比を変更しない」「T-01 商品名を動詞として使用しない」の粒度に分けたものが要ります。
例外リストは、ほとんどの会社にまだありません。ここを先に作ることが、いちばん重い準備です。 記録されていないと毎月同じ誤検知が出ます。店舗コードと条項番号と期限を必ず持たせてください。「あの店は特別」というメモでは機械が当てられません。
データの取得方法を決める
提出フォルダ: Make がクラウドストレージを監視し、追加されたファイルを取り込みます。PDF、画像、まれに文書ファイルが混ざるので、取り込んだ時点で種類を判定して分岐します。
SNS投稿: 加盟店自身に投稿の一覧を月1回出してもらいます。各サービスを自動で巡回する設計にはしません。 取得の可否は規約と仕様に依存し、作り込むと変更のたびに止まるためです。
自店Webページ: URLの一覧を読み、表示を画像として取り込み、文章も取り出します。ページ全体を1枚の長い画像にせず、画面の高さで区切ります。 見本と条項は繰り返し使うファイルとして扱い、例外リストと表記の一覧はスプレッドシートに置いて担当者が直せるようにします。
AIへ渡す前に整形する
Python でまとめて行います。AIに渡す前に形をそろえる工程が、判定の精度を決めます。
- 形式の統一と向きの補正 … 対応形式はそのまま渡し、それ以外は変換します。PDFはページごとに画像化し、元のファイルとページ番号を持たせます。スマートフォンの写真は向きの情報がファイルの中にだけ残り、そのまま渡すと横倒しで届くことがあるので、画素の並びそのものを回します
- 鮮明さの確認 … ぼけの度合いを機械で測り、一定以下は判定に回さず「撮り直しの依頼」に出します。ぼけた画像を渡すと疑いなしが返り、それが「問題なし」として記録されます
- 解像度の二段構え … 1回目は中くらいの大きさで全体を渡してロゴの位置だけを挙げさせ、返ってきた座標でその部分を切り出して2回目に大きく渡します。 タイルの枚数を抑えながら細部が見られます
- 例外リストの突き合わせと再提出の判定 … 店舗コードと条項番号と期限で除外します。期限切れの例外は自動で外れる形にしてください。 同じ掲載物の再提出なら、前回の指摘が直っているかを最初に見ます
AIに処理させる
画像の判定とテキストの判定を、必ず分けて行います。 観点が違い、根拠の形が違い(画像は座標、テキストは原文の抜き出し)、直し方も違う(画像は前処理と解像度、テキストは表記の一覧の整備)ためです。混ぜると、どちらを直せばよいか分からなくなります。
AIにさせないことが2つあります。
- 色や余白の数値化 … 「指定色と違う」「余白が0.3倍しかない」と数値で答えさせません。色は座標の領域から画素の値を機械で取り、余白は座標から機械で計算します。 それでも撮影した写真では照明で変わるため、測った値も「疑い」の材料までです
- 合否の断定と法令上の評価 … 「違反しています」と書かせず、商標法をはじめとする法令の解釈にも触れさせません。この構成が見るのは、自社のブランドガイドラインへの適合だけです
指示内容を固定する
画像の判定に使う指示:
あなたは、ブランドガイドラインへの適合を点検する担当者を支援する立場です。
渡す画像は、当社の商品を扱う販売店・加盟店が自分で作成した販促物です。
ガイドラインから外れている「疑い」を挙げてください。
見るのは当社のロゴ、シンボル、商品名のロゴタイプだけです。
販売店自身のロゴ、他社のロゴ、商品写真そのものは対象外です。
【見る観点】
1. ロゴの位置(当社のロゴが写っている箇所をすべて挙げる)
2. ロゴの版(現行版に見えるか、旧版に見えるか)
3. 縦横比(見本と比べて縦または横に伸びて見えるか)
4. 色(見本と違う色に見えるか)
5. 周囲の余白(ロゴのすぐそばに文字・写真・罫線が寄っているか)
6. 重なり(ロゴの上に文字・図形・写真が重なっているか)
7. 書体(商品名のロゴタイプが見本と違う書体に見えるか)
8. 改変(影、縁取り、回転、部分の切り取りが加えられているか)
【厳守事項】
- 違反かどうかの断定と、是正を求めるべきかどうかの判断を書かないでください。
法令(商標法など)の解釈に触れず、「違反」「侵害」「法令」という語を
出力に使わないでください。
- 色・余白・縦横比について数値(色コード、ミリ、パーセント、倍率)を
出力しないでください。見えたことだけを書き、
needs_measurement を true にしてください。
- 疑いごとに、ガイドラインの条項番号を1つ挙げてください。条項番号は
渡した一覧にあるものだけを使い、当てはまる条項が無い疑いは挙げないでください。
- 疑いを挙げた箇所は box_2d に [ymin, xmin, ymax, xmax] の順で、
0から1000に正規化した座標で返してください。
- 画像が不鮮明で判断できない場合は、疑いを挙げずに unreadable.flag を
true にし、reason に理由を書いてください。推測で埋めないでください。
- 確信の度合いを confidence に high / medium / low で入れ、迷った場合は
low にしてください。「該当なし」に寄せないでください。
【ガイドラインの条項】{guideline_clauses}
【正規ロゴの見本】{reference_logos}
【点検対象の掲載物】{image}
テキストの判定は、同じ型のまま中身を差し替えます。 観点は「商品名が動詞として使われている」「略称・短縮形で書かれている」「複数形や所有格のような形に変えられている」「商品の種類そのものを指す言葉として使われている」「登録商標であることの表示が無い、または位置が指定と違う」「旧ブランド名・旧商品名が使われている」「承認済みの一覧に無いキャンペーン表現や効果の言い切りが足されている」「表記のゆれが正しい表記と違う」の8つです。
厳守事項には、「渡した正しい表記の一覧・承認済みの表現の一覧に無いものを、正しい、または承認済みとして扱わないでください」「疑いを挙げた箇所は text_span に原文をそのまま抜き出し、言い換え、要約、修正後の文を入れないでください。直し方の案は suggested_fix に分けます」の2つを足し、渡す資料に {trademark_table} と {approved_claims} を加えます。
「当てはまる条項が無い疑いは挙げない」が、いちばん効く制約です。 これを書かないと、AIは「なんとなく整っていない」という指摘を返します。条項に紐づかない指摘は、「どこに書いてあるのか」と聞かれて答えられないので、加盟店に伝えられません。
「low にしてよい、該当なしに寄せない」も必要です。 目的は疑いを拾うことなので、拾いすぎる側に倒すほうが安全です。 担当者が10件から3件を選ぶのは短時間で済みますが、拾われなかった1件は誰も見つけません。
出力形式を固定する
構造化出力の設定は、response_format に type("text")、mime_type("application/json")、schema を入れる形です。
{ "type": "object", "required": ["item_id", "check_type", "findings", "unreadable"],
"properties": {
"item_id": { "type": "string" },
"check_type": { "type": "string", "enum": ["image", "text"] },
"findings": { "type": "array", "maxItems": 20, "items": {
"type": "object",
"required": ["clause_id", "category", "observed", "confidence"],
"properties": {
"clause_id": { "type": "string" },
"category": { "type": "string", "enum": [
"logo_version", "logo_ratio", "logo_color", "logo_clearspace",
"logo_overlay", "logo_typeface", "logo_modified", "tm_verb",
"tm_abbreviation", "tm_generic", "tm_notice", "old_name",
"unapproved_claim", "spelling"] },
"observed": { "type": "string" },
"box_2d": { "type": "array", "minItems": 4, "maxItems": 4,
"items": { "type": "integer" } },
"text_span": { "type": "string" },
"suggested_fix": { "type": "string" },
"confidence": { "type": "string", "enum": ["high", "medium", "low"] },
"needs_measurement": { "type": "boolean" } } } },
"no_finding_reason": { "type": "string" },
"unreadable": { "type": "object", "required": ["flag"], "properties": {
"flag": { "type": "boolean" }, "reason": { "type": "string" } } } } }
スキーマは Python では Pydantic のモデルから model_json_schema() で、JavaScript では Zod から z.fromJSONSchema() でも作れます。
category を自由文にしないでください。 自由文にすると「ロゴの比率」「縦横比の崩れ」「アスペクト比」が月ごとに混ざり、店舗別・区分別の集計ができなくなります。 公式のドキュメントにはすべての JSON Schema の機能が使えるわけではなく、非常に大きい、または深くネストしたスキーマは拒否されることがあると書かれているので、入れ子は2段までにとどめ、条項の一覧や見本はプロンプト側に置いています。
返る値は {"clause_id": "L-03", "category": "logo_color", "observed": "見本より青みが薄く見えます", "box_2d": [118, 638, 210, 935], "confidence": "low", "needs_measurement": true} のような形です。needs_measurement が true の疑いは、AIが見えたことしか言えなかったものです。 その先は座標の領域から画素の値を機械で測りますが、撮影物では照明で変わるので、最終的には担当者が元のデータを見て決めます。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 提出フォルダ(クラウドストレージ) | Make の監視とファイル取得 | 掲載物の取り込み |
| 前処理と集計 | Python | 形式・向き・解像度の調整、枠の描画、集計 |
| 生成AIサービス | API(画像とテキストで別々に呼ぶ) | 疑いの洗い出しと条項の紐づけ |
| 例外リスト・表記の一覧・点検台帳 | スプレッドシートの読み書き | 除外と照合、疑いと判断の記録、集計 |
| 加盟店への連絡 | 電子メールの下書き | 是正を求めると決めた場合のみ |
最後の行は下書きまでにします。送信は担当者が行います。 機械が送った文面が、会社の意思表示として扱われるためです。
人が確認する
全件、人が確認します。疑いをそのまま加盟店へ送る設計にしません。 第1段階は「当たっているか」で、画像の疑いは枠が描かれているので開いた瞬間に分かり、テキストの疑いは原文の抜き出しを前後ごと読んで判断します。第2段階は「是正を求めるか」の判断で、これは機械にさせません。
| 判断 | 当てはまる場面 |
|---|---|
| すぐ差し替えを依頼する | 配布前のチラシ、掲載中のWebページで、ロゴの改変や旧ロゴがある |
| 次回から直してもらう | すでに配布済みで差し替えができず、影響が限定的 |
| 今回は何も言わない | 誤検知、例外リストに入れるべき使い方、直しても意味が薄い違い |
3つ目を選べることが重要です。 すべての疑いを指摘すると、加盟店は販促物を作ること自体をやめます。
確認の順番は、①confidence が high で配布前・掲載中のもの、②ロゴの改変・旧ロゴ・承認外の表現、③同じ加盟店で前月にも同じ区分が出ているもの、④それ以外、です。③で同じ指摘が3か月続く店が見つかれば、1点ずつ直すより説明に行くほうが早いと判断できます。
疑いが0件だった掲載物も、月に10点は抜き取りで目視してください。 確認の時間の目標は1件3分(確かめる2分+決める1分)です。
例外に対処する
| 起きること | 対応 |
|---|---|
| 画像がぼけている・暗い | 判定に回さず「撮り直しの依頼」に出す。疑いなしとして記録しない |
| 定期実行が動かなかった | 処理した掲載物が0点の月を検知する。疑い0件と処理0点を分けて扱う |
| 同じ掲載物が2回流れた | 中身から作った値を台帳に持ち、点検済みを飛ばす |
| 許諾済みの使い方が疑いになる | 例外リストに追加し、店舗コード・条項番号・期限を必ず入れる |
| 経過措置の期限が切れた | 期限で自動的に例外から外れる形にする。手で消す運用にしない |
| 条項の一覧に無い番号が返る | 機械で突き合わせて外す。作られた条項番号を加盟店に送らない |
| 応答が JSON として読めない | 再実行し、読めなければ未処理として残す。壊れた出力を台帳に入れない |
| 疑いが1点で数十件出る | maxItems で上限を決め、confidence の高い順に残す |
| SNS投稿の一覧が出てこない | 巡回の対象外だと台帳に残す。「疑いなし」として扱わない |
点検していない掲載物と、点検して問題がなかった掲載物はまったく違います。 条項番号の突き合わせも仕組みで持ってください。プロンプトの制約は必ずすり抜けます。
記録を残す
- 取り込んだ掲載物の原本(提出日、提出者、店舗コード、チャネルの区分)
- 前処理の結果と、AIに渡した画像とテキスト、使った条項の一覧の版
- AIが返した疑い(条項番号、区分、
observed、座標、confidence) - 担当者が「当たっている/誤検知」と判断した結果と、その理由
- 是正を求めるかどうかの判断と理由、送った連絡文、差し替えの結果
- 月ごとの集計(点検した点数、疑いの件数、区分別、店舗別)
4つ目を残すと、この構成の弱点が見えます。 誤検知を区分ごとに数えれば、どの観点が使いものになっていないかが分かります。 「ガイドラインの版」も必要です。改訂前の掲載物を改訂後の条項で指摘すると、加盟店には理不尽に映るためです。
04実装レベルの3段階
最小構成だけでも、12分が9分程度になります。 ただし掲載物を開いて渡す作業が残ります。 半自動化で9分から4分程度になります。 収集と前処理が消え、疑いの箇所に枠が描かれた状態から始められるためです。本記事が想定するのもここです。 本格構成では工数はそれほど変わりませんが、(b)の「見る人によって指摘が変わる」が解けます。 進む判断は半自動化を3か月回してからで間に合います。
05工数削減シミュレーション
導入後 120件 × 4分 ÷ 60 = 8 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 自社のロゴと商品名を使う販売店・加盟店・代理店が数十社以上あり、その販促物を月に100点前後まとめて点検している企業。ブランドガイドラインがすでに条項の形で文書になっていて、正規のロゴデータと商標の正しい表記の一覧が社内に整理されている場合。点検の担当が知財とマーケティングに分かれていて、是正を求めるかどうかを取引先との関係を見ながら決めている場合。
- 販促物をすべて本部が作っていて、販売店や加盟店が自分で作ることがない場合。ガイドラインが「ロゴを正しく使うこと」程度の一文しかなく、何が逸脱にあたるかを条項として書けていない場合。この場合はガイドラインを条項に分ける作業が先で、本記事の構成はその後の話になります。点検したい相手が正規の取引先ではなく第三者の場合は、設計そのものが変わります。
07最小構成で試す方法
- 先月点検した掲載物から10点を選ぶ(チラシ3点、POP3点、SNS投稿3点、Webページ1点)
- そのうち3点は実際に指摘した掲載物、1点は許諾済みの特別な使い方を入れる
- ガイドラインからロゴと商標の条項を10項目だけ抜き出し、番号と本文を並べる
- AIの画面に条項の一覧と正規ロゴの見本を貼り、掲載物を1点ずつ渡して「渡した条項に当てはまる可能性がある箇所を挙げてください。当てはまる条項が無いものは挙げないでください。違反かどうかの断定と、法令の解釈はしないでください」と指示する
- 画像とテキストを別々に渡した場合と、まとめて渡した場合を比べる
2番目の条件を必ず守ってください。 指摘した3点が拾われるかで拾えるかどうかが分かり、許諾済みの1点が挙がるかで例外リストが必要になる量が分かります。
| 疑いの出方 | 判断 |
|---|---|
| 指摘した3点が拾われ、条項の当て方も合っている | 自動化する価値が大きい。前処理と枠の描画まで作る |
| 拾われるが、条項の当て方がずれる | 条項の分け方が粗い。 1条項1観点になるまで分ける |
| 疑いが大量に出る | 例外リストと承認済み表現の一覧が足りない。AIの問題ではない |
3行目は失敗ではありません。 何を準備すればよいかが分かったということです。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| ガイドラインが条項に分かれていない | 1条項1観点になるまで分け、番号を振る。PDFのままでは条項は返らない |
| 例外リストが無く、同じ誤検知が毎月出る | 店舗コード・条項番号・期限を持つ表を先に作る |
| 存在しない条項番号が返る | 一覧と機械で突き合わせて外す。作られた番号を加盟店に送らない |
| POPの写真が横倒しで届く | 向きの情報だけを直さず、画素の並びそのものを回してから渡す |
| ぼけた写真で「疑いなし」が返る | ぼけの度合いを機械で測り、一定以下は撮り直しを依頼する |
| ロゴが小さすぎて判定できない | 1回目で位置を挙げさせ、2回目にその部分だけを大きく渡す |
| 縦長のWebページで判定が甘くなる | 1枚の長い画像にせず、画面の高さで区切って複数枚にする |
| 総リクエストのサイズを超える | インラインは20MBまで。枚数で区切るか File API に切り替える |
| 区分が自由文になり集計できない | enum で固定する。言い方が混ざると店舗別の集計が崩れる |
| スキーマが拒否される | 入れ子を浅くする。条項の一覧や見本はプロンプト側に置く |
| 点検していない掲載物が「疑いなし」に見える | 台帳で「未点検」「点検して疑いなし」を別の値にする |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 加盟店が作った販促物(配布前のものを含む)、店舗名・住所・電話番号・店長名、取引の区分、自社の正規ロゴデータとガイドライン。取引先の未公開の販促計画と、自社のブランド資産の両方が含まれます。
- サービスの利用条件を先に確認する … 公式の利用規約では、有料のサービスではプロンプトや応答を製品の改善に使わず、モデルの学習にも使わないことが示されています。一方、無料のサービスでは、送信した内容と生成された応答が製品の提供・改善・開発に使われ、人間のレビュアーが読み、注釈を付け、処理することがあると書かれ、機密情報・個人情報を送らないよう明記されています。配布前のチラシと店舗の連絡先を扱うこの構成は、有料のサービスを前提に組んでください
- ログの保持を学習と混同しない … 有料のサービスでも、ポリシー違反の検知と防止、および法令遵守のために、限られた期間プロンプトと応答が記録されるとされています
- 預かったものを点検以外に使わない … 提出されるチラシには、まだ公表していない価格、キャンペーンの開始日、新商品の情報が含まれます。店頭POPには店員や来店客も写り込みますが、二段構えの切り出しなら2回目に渡すのはロゴの周辺だけで済みます
- 法的な評価をAIにさせない … この構成が見るのは自社のブランドガイドラインへの適合だけです。 法令の解釈には触れさせず、「違反」「侵害」という語を出力に使わせません。権利に関わる判断は、知財部門と、必要に応じて外部の専門家が行います
- 是正を求めるかどうかを人が決める … これは情報の話ではなく取引の話です。送った文面が会社の意思表示として扱われ、誤検知をそのまま送ると指摘そのものが信用されなくなります
- ガイドラインと点検記録の扱いを決める … 改訂中の版や未発表の新ロゴを判定に混ぜないでください。加盟店に伝えるのは、担当者が是正を求めると決めたものだけです
誤りが起きた場合のリスクは、正しい使い方をしている加盟店に、誤った指摘を送ってしまうことです。 これは精度の問題であると同時に、疑いを人が確かめてから送る手順を運用に組み込めているかの問題です。
10まず何から始めるか
1週目:ガイドラインを条項に分ける
ロゴと商標に関する条項を抜き出し、1条項1観点になるまで分けて番号を振ります。「ロゴを正しく使用すること」は、縦横比、色、余白、重なり、書体に分けます。AIはまだ使いません。
2週目:例外リストを作る
過去1年の点検記録とメールから、許諾済みの特別な使い方、共同販促、旧ロゴの経過措置を拾い出し、店舗コード、条項番号、期限の3つを持つ表にします。ここが誤検知の量を決めます。
3週目:10点で試す
先月の掲載物から10点(うち指摘した3点、許諾済み1点)を選び、条項の一覧と見本を添えて渡します。見るのは「指摘した3点が拾われるか」「条項の当て方が合っているか」です。
4週目:前処理と二段構えを作る
向きの補正、ぼけの判定、解像度の調整を Python で組み、ロゴの位置を挙げさせてからその部分を大きく渡す形を試します。1回目と2回目で拾える観点がどう変わるかを記録します。
2か月目: 提出フォルダの監視と枠の描画まで作ります。最初の月はチラシとPOPだけにします。
3か月目: SNS投稿とWebページを足し、120点を全部通します。12分が何分になるかを実測し、誤検知として消した疑いを区分ごとに数えてください。 使いものにならない観点は、人が見る形に戻します。
4か月目以降: 店舗別・区分別の集計を出します。指摘を速くするより、逸脱が起きにくい形に説明資料を直すほうが効きます。 「今月の120点のうち何点を点検し、何件に是正を求めたか」が台帳で見えた時点で完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
画像の入力が image/png、image/jpeg、image/webp、image/heic、image/heif に対応し、1リクエストあたり最大3,600枚まで渡せること。縦横どちらも384ピクセル以下は258トークン、それより大きい画像は768×768ピクセルのタイルに分割されタイル1枚あたり258トークンになること(960×540の画像は切り出しの単位が360で、各辺を360で割って3かける2の6タイル)。渡し方がインライン(Base64)、File API、公開URLの参照の3通りで、インラインはテキストとプロンプトと画像のバイト列を合わせて総リクエスト20MBまで、大きいファイルや繰り返し使うファイルには File API が推奨されること。バウンディングボックスの座標が [0, 1000] に正規化され [ymin, xmin, ymax, xmax] の順で返り、元の画像サイズに戻す処理が必要であること。ベストプラクティスとして、画像の向きが正しいこと、鮮明な画像であることが挙げられていること | Gemini API: Image understanding | 2026-09-22 |
構造化出力の設定が response_format に type("text")、mime_type("application/json")、schema を入れる形であること。JSON Schema を直接渡せるほか、Python では Pydantic の BaseModel から model_json_schema() で、JavaScript では Zod から z.fromJSONSchema() で作れること。型として string、number、integer、boolean、object、array、null が、オブジェクトで properties、required、additionalProperties、文字列で enum と format、数値で minimum、maximum、配列で items、minItems、maxItems、加えて description が使えること。すべての JSON Schema の機能が使えるわけではなく、非常に大きい、または深くネストしたスキーマは拒否されることがあること | Gemini API: Structured output | 2026-09-22 |
| 有料のサービスではプロンプトや応答を製品の改善に使わず、モデルの学習や改善にも使わないこと。ポリシー違反の検知と防止、および法令遵守のためだけに、限られた期間プロンプトと応答が記録されること。無料のサービスでは、送信した内容と生成された応答が Google 製品の提供・改善・開発に使われ、人間のレビュアーが入力と出力を読み、注釈を付け、処理することがあり、機密情報・個人情報を送信しないよう明記されていること | Gemini API 追加利用規約 | 2026-09-22 |
画像の形式、枚数、トークンの数え方、サイズの上限は変更されうる値です。実装の前に最新の案内を確認してください。 また本記事は自社のブランドガイドラインへの適合だけを扱っており、法令上の評価は知財部門と外部の専門家が判断する範囲です。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0163)についてのご相談はこちらから。
