入稿する広告データを、媒体ごとの規定に照らして入稿前に点検する

処理の起点を決める

共有フォルダの「入稿待ち」フォルダに、クリエイティブが保存されたときを起点にします。

Make のシナリオは既定で15分ごとに実行されるため、特別な設定をしなくても、素材が届いてから15分以内には点検が始まります。 出稿の波に合わせて一定間隔・毎日1回・平日のいずれかを選べますが、入稿の締め切りが平日に集中するなら平日（mon-fri）の設定で足ります。

シナリオを有効化しておくことを忘れないでください。 作っただけでは動きません。「点検が回っているつもりで、実は止まっていた」は、この種の仕組みでもっともよくある事故です。稼働が分かる通知を1日1回出しておくと気づけます。

1件ずつ処理してください。 素材はまとめて届きますが、1件の点検結果を1件の一覧として出すほうが、差し戻しの単位と合います。

再点検の入口を必ず用意してください。 差し戻して直ったものが届いたら、もう一度同じ点検を通します。「直したから通るはず」で入稿すると、直した箇所の隣が新たに規定を外していることがあります。 オンデマンドの実行も残しておくと、締め切り直前に届いた素材を待たずにかけられます。

入力データを集める

このうち、いちばん重いのが「媒体の規定表」です。 現状は各担当者のメモにしかありません。これを自社の表として持ち直すことが、この構成の最初の作業であり、いちばん時間のかかる作業です。

規定値を記事や資料から写してこないでください。 媒体の規定は随時変わるもので、どこかに書かれた数字は、書かれた時点ですでに古くなり始めています。 必ず媒体の管理画面やヘルプで確かめた値を入れてください。

過去の差し戻し記録は、規定表の穴を埋める材料になります。 「この媒体でこの理由で戻された」という記録が10件あれば、足りていない行が10行分わかります。 完璧な表を最初から作ろうとせず、戻された理由から埋めるほうが早く形になります。

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

媒体の規定表： 次の列で持ってください。この表がこの構成の質を決めます。

「確認日」の列が、この表でもっとも重要です。 規定は変わります。いつ時点の規定と突き合わせたかが記録に残らないと、差し戻されたときに原因が分かりません。 規定が変わったのか、点検が漏れたのか、制作が指示どおりに直さなかったのか。確認日があれば、最初の可能性をすぐに切り分けられます。

「確認した人」の列は、更新の責任を見えるようにします。 誰も自分の仕事だと思っていない表は更新されません。媒体ごとに担当を割り振ります。

「種類」の列で、機械が扱う行とAIが扱う行が分かれます。 文字数・寸法・容量・形式は機械の行、必須表記・禁止表現はAIの行です。この列があるおかげで、点検の処理が自動的に2つに振り分けられます。

文字数の数え方も、自社で定義して規定表に書いてください。 全角と半角をどう数えるか、記号や絵文字をどう扱うか、改行を含めるか。媒体によって考え方が違うため、「何文字か」の答えが1つに決まりません。 曖昧なまま数えると、機械は「収まっている」と言い、媒体は「超えている」と言うという食い違いが起きます。

画像と動画の属性： 寸法、ファイル形式、容量は、ファイルを開かなくても属性から読み取れます。ここにAIは要りません。

画像内のテキスト量： OCRで文字を取り出し、文字が占める面積の割合を算出します。占有率は測る話であって、判断する話ではありません。 取り出した文字列は、必須表記の点検にも使えます。

遷移先のページ： 広告に設定されているリンク先を開き、見出しと主要な文言を取得します。訴求と遷移先が合っているかの点検に使います。

AIへ渡す前に整形する

1. ファイルの種類の判別 … 画像／動画／テキストのどれかを判別します
2. 属性の取得 … 画像と動画の寸法、ファイル形式、容量、動画の尺を取得します
3. 文字数の計測 … 見出しと説明文の文字数を、規定表で定義した数え方で数えます
4. 画像内テキストの取り出し … OCRで文字を取り出し、占有率を算出します
5. 規定表の引き当て … 入稿先の媒体とフォーマットから、規定表の該当行をすべて引きます
6. 機械で判定できる項目の判定 … 測った値と規定を突き合わせ、合否を確定させます
7. 残りの整理 … 判断の要る項目だけを、AIへ渡す形にまとめます

6でほとんどの項目の合否が決まります。 文字数、寸法、容量、形式。規定表の行のうち、機械だけで判定できる行が半分以上を占めるはずです。 ここでAIを使わないことが、精度と費用の両方に効きます。

5の引き当てで、該当行が0件になる場合の扱いを決めておいてください。 新しいフォーマットへ出稿しようとしたときに起こります。「規定表に行がない」を「問題なし」として通してはいけません。

7では、AIに渡す情報を絞ってください。 画像そのもの、テキスト全文、必須表記のルール、禁止表現の一覧、遷移先のページの内容。機械で確定した合否は渡しません。 渡すと、AIがそれを再判定して違う答えを返すことがあります。

AIに処理させる

点検する項目を、誰が見るかで分けます。

AIに数えさせないでください。 文字数も、寸法も、容量も、占有率も、すべて機械の仕事です。AIは数えられないわけではありませんが、確率的に間違えます。 しかも間違え方が毎回違うので、テストで潰せません。「規定に収まっているか」に、確率的な答えを返す仕組みを混ぜてはいけません。

AIにさせるのは、次の3つです。

（1）必須表記が、意味のある形で入っているか

必須の文言が文字列として含まれているかは、機械で当てられます。ただし、文字列があっても点検が終わったことにはなりません。 極端に小さく置かれている、他の文字に重なっている、直後に打ち消す文言が続いている。「書いてあるが、書いていないのと同じ状態」を見るのがAIの仕事です。

（2）禁止表現に当たるかどうか

禁止表現の一覧は、文字列の一致では拾いきれません。言い換えられていることがほとんどだからです。一覧にある語は使わず、同じ意味の別の言い方をしている場合を見ます。迷うものは無理に決めさせず、人に回してください。

（3）訴求と遷移先の一致

広告で言っていることが、クリックした先のページに書かれているか。広告では触れているのに、遷移先に該当する記述がないという食い違いを見ます。 文字列の照合では判定できません。

AIに規定値そのものを覚えさせないでください。 「この媒体の見出しは何文字までか」を答えさせると、もっともらしい数字を返します。 規定は必ず規定表から引いた結果を渡します。

指示内容を固定する

あなたは広告の運用担当者として、入稿前のクリエイティブを点検する者です。
下に示す媒体の規定に照らして、判断の要る項目だけを点検してください。

【厳守事項】
- 文字数、画像の寸法、ファイル容量、画像内テキストの占有率を、
  あなたが数えたり測ったりしないでください。
  これらは別の処理で測定済みです。測定結果が渡されていない項目については
  「測定なし」としてください。推測した数値を書かないでください。
- 規定の値を、あなたの知識から補わないでください。
  下の【媒体の規定】に書かれている条件だけを使ってください。
  規定に該当する行がない項目は「規定の記載なし」としてください。
  「一般的にはこの程度まで」と書かないでください。
- 表現の良し悪しを評価しないでください。「訴求が弱い」と書かないでください。
  見るのは規定に収まっているかどうかだけです。
- 法令に関する判断をしないでください。景品表示法や薬機法に触れるかどうかは
  別の仕組みで点検します。「法的に問題がある可能性がある」と書かないでください。
- 判断に迷う場合は、どちらかに決めずに verdict を needs_human としてください。
  迷った理由を必ず書いてください。
- 指摘は、入稿できないもの（blocking）と、
  直したほうがよいが入稿はできるもの（advisory）に分けてください。
  規定に明確に反しているものだけを blocking にしてください。
- すべての指摘に、根拠となる規定の行を示してください。
  規定の行を示せない指摘は書かないでください。
- how_to_fix には、具体的な直し方を書いてください。
  「修正が必要」ではなく「必須の表記が画像の下端で他の文字に重なっているため、
  重ならない位置へ移す」と書いてください。

【媒体とフォーマット】
{media_and_format}

【媒体の規定（項目／種類／値または条件／確認日）】
{spec_rules}

【測定済みの値（文字数・寸法・形式・容量・画像内テキストの占有率）】
{measured_values}

【クリエイティブのテキスト（見出し・説明文）】
{creative_text}

【画像から取り出した文字列】
{ocr_text}

【必須表記のルール（商材ごと）】
{required_notations}

【禁止表現の一覧】
{prohibited_expressions}

【遷移先ページの見出しと主要な文言】
{landing_page}

「あなたが数えたり測ったりしないでください」の指示が、この構成の要です。 これを書かないと、AIは測定済みの値を無視して自分で数え直します。そして、機械が出した値と違う数字を返します。 どちらが正しいかを人が確かめる作業が増え、点検の意味がなくなります。

「規定の値を知識から補わない」も外せません。 媒体名を見ただけで、AIはそれらしい規定値を答えてしまいます。それが古い値でも、もっともらしく見えるので気づけません。 禁止表現の言い換えのように微妙なものもあるため、needs_human で人に回す道を作っておけば、判定の精度を無理に追わずに済みます。

出力形式を固定する

{
  "creative_id": "",
  "media": "",
  "format": "",
  "spec_checked_at": "",
  "findings": [
    {
      "item": "",
      "rule": "",
      "actual": "",
      "verdict": "pass | fail | needs_human",
      "how_to_fix": "",
      "checked_by": "machine | ai"
    }
  ],
  "blocking": [],
  "advisory": [],
  "needs_human": { "flag": false, "reason": "" }
}

checked_by を残すことが、この設計の中心です。 機械が測った値とAIが判断したものが同じ一覧に並ぶため、区別が付かないと、差し戻しが起きたときにどちらの精度を直せばよいか分かりません。 機械の側が原因なら測り方や規定表を直し、AIの側が原因ならプロンプトを直す。直す場所が決まっていることが、運用を続けられるかどうかを分けます。

spec_checked_at には、引いた規定表の確認日を入れます。 点検した日ではなく、規定を最後に確かめた日です。差し戻されたとき、この日付が古ければ規定の更新漏れが疑われます。新しければ、点検か制作の側に原因があります。

blocking と advisory を分ける理由は、入稿を止めないためです。 全部を「直せ」にすると、制作会社は並んだ指摘を端から直そうとし、入稿が止まって掲載開始がずれます。 規定に明確に反していて入稿が通らないものだけを blocking に入れ、残りは次回以降に直せばよいという整理にしてください。

findings の item を規定表の行と対応させています。 規定表の1行が点検結果の1行になるため、点検できなかった項目が抜け落ちていることにも気づけます。

structured outputs では、enum（文字列・数値・真偽値・null のみ）、const、anyOf と allOf、default、required と additionalProperties、文字列フォーマット、配列の minItems（値 0 と 1 のみ）がサポートされます。verdict や checked_by のような決まった値の列は enum で縛れます。 ただし enum の値は大文字小文字を厳密に指定する必要があります。 また オブジェクトの additionalProperties は false に設定する必要があり、定義していない項目が紛れ込みません。

スキーマのキャッシュが、この構成では効きます。 初回は文法のコンパイルで追加の遅延が発生しますが、コンパイル済みの文法は最後の使用から24時間キャッシュされます。 月180件を毎日回すため、間隔が空きにくく、効いた状態が続きます。ただし、スキーマの構造やツールセットを変えるとキャッシュは無効化されます。name や description だけの変更では無効化されません。

構造化出力を使うと、出力形式を説明するシステムプロンプトが自動で付くため、入力トークンが増えます。 また、output_config.format を変えると、会話スレッドのプロンプトキャッシュが無効化されます。

システムへ連携する

出力は一覧として作るだけで、媒体の管理画面への入稿は行いません。

入稿を自動化しないでください。 点検を通った素材を自動で入稿する仕組みにすると、規定表が古かったときに、誤った内容がそのまま掲載されます。 掲載されてしまえば、差し戻しより損失が大きくなります。

制作会社への差し戻しも自動化しないでください。 誤った指摘まで送ってしまいます。制作会社は指示どおり直すので、誤った指摘は誤った修正になって戻ってきます。

通知は blocking があるときだけにしてください。 すべての点検で通知を出すと、そのうち読まれなくなります。 advisory は一覧の中で見れば足ります。

人が確認する

運用担当の確認は必ず残します。

1つ目が最重要です。 規定に反していないものを「入稿できない」として差し戻すと、制作会社は直す必要のないものを直します。 blocking の指摘は、規定表の該当行を開いて確かめてください。

確認を速くするための設計が効きます。

• blocking を一覧の上に並べ、advisory を下に置く
• 指摘ごとに、規定表の該当行と確認日を並べて表示する
• checked_by を一覧に出し、機械の判定とAIの判断を見分けられるようにする
• 測定した値と規定の条件を、左右に並べる
• 差し戻しの文面を、そのままコピーできる形で置く

3つ目が、確認の速さを大きく変えます。 機械が測った文字数や寸法は、基本的に疑う必要がありません。 目を向けるべきはAIが判断した行です。見分けが付けば、確認すべき行が最初から絞られます。

「規定表に行がなかった項目」の確認を飛ばさないでください。 見落とすと、点検していない項目を点検したつもりで入稿します。 新しいフォーマットへの初回の出稿で必ず起きます。

例外に対処する

「規定表に該当する行がない」を沈黙で通さないことが、いちばん大事な例外処理です。 点検の仕組みでもっとも危ないのは、点検していないものを点検したことにしてしまう状態です。

記録を残す

この記録が、規定表を育てる材料になります。

• 点検した素材、媒体、フォーマット、点検日
• 引いた規定表の行と、その確認日
• 機械が測った値と、AIが判断した内容（checked_by 付き）
• blocking と advisory の件数
• 担当者が指摘を採用したか、取り消したか
• 実際に差し戻した内容と、その結果
• 入稿が受け付けられたか、媒体側で差し戻されたか

最後の2つが、この仕組みの精度を測る唯一の物差しです。 点検を通したのに媒体側で差し戻されたなら、規定表か点検のどちらかに穴があります。

「担当者が取り消した指摘」も必ず残してください。 誤った指摘が繰り返し出ている場合、規定表の書き方かプロンプトに原因があります。 記録がなければ、それに気づけません。