広告に使っているタレント・モデルの写真と動画の使用期限を素材台帳から拾い、停止か延長交渉かを判定して広告主の担当へ知らせる

処理の起点を決める

平日の毎朝7時に1回動かします。 月初の1回にしないのは、第3章の（a）のとおり、月の途中で来る申し入れ期限を拾うためです。 毎朝動かしても、営業に届くのは前日から判定が変わったものと、決める期限が近づいたものだけにします。

「決める期限」は、次の2つのうち早いほうです。 契約条件メモにある延長の申し入れ期限と、使用期限から撤去日数を引いた日です。どちらも過ぎると、選べる道が減ります。 申し入れ期限を過ぎれば延長の交渉が難しくなり、撤去日数を割り込めば期限までに外しきれません。

土日と祝日は動かしません。 決める期限が週末に当たるものは、前の金曜日を期限として扱います。

入力データを集める

質を決めるのは、契約条件メモです。 メモが「延長可（要相談）」の1行しかなければ、AIにも延長の条件は読めません。その場合は needs_review にして、制作管理部が契約書の原本を見ます。 メモの書き方がそろうほど、needs_review は減ります。

撤去日数の表は、営業と媒体の担当で一度決めれば足ります。 たとえば SNS の広告とリスティングは1日、自社サイトのバナーは2日、店内のデジタルサイネージは5日、店頭のポスターと交通広告は14日、といった値です。この値が実態より短いと、決める期限が遅く出ます。

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

素材台帳は Get items で読みます。フィルター クエリは次のとおりです。

UsageEnd le '@{formatDateTime(addDays(utcNow(), 60), 'yyyy-MM-dd')}' and UsageEnd ge '@{formatDateTime(utcNow(), 'yyyy-MM-dd')}' and Decision eq null

使用期限を過ぎた行は、別のフィルターで取ります。 期限を過ぎてもまだ掲出の行が残っているものは、判定に回さず、そのまま制作管理部のチャネルに「期限切れで掲出中」として出します。 ここはAIが判定する段階ではありません。

担当の営業の列は、ユーザーの列にしておきます。 名前の文字列だと、異動や同姓で送り先を誤ります。ユーザーの列ならメールアドレスが取れ、それをそのまま Teams の受信者に使えます。

日付は日本時間でそろえます。 utcNow() は UTC を返すので、朝7時の実行では前日の日付になります。比べる前に日本時間に直してから日付だけを取り出します。 最初に数件で確かめます。

AIへ渡す前に整形する

1. 掲出の終了予定日との比較 … すべての掲出の終了予定日が使用期限より前なら、AIを呼ばずに no_action とします
2. 決める期限の計算 … 掲出の行ごとに「使用期限 − 撤去日数」を出し、いちばん早い日を素材の撤去の期限とします
3. 契約条件メモの長さの確認 … 空のときはAIを呼ばず needs_review にします
4. 出演者の個人情報の除去 … メモに事務所の担当者の電話番号やメールアドレスがあれば、渡す前に伏せます
5. 前回の判定との比較 … 契約条件メモと掲出の行が前回から変わっていなければ、AIを呼ばずに前回の判定を使います
6. 同じ撮影の素材のまとめ … 同じ出演者・同じ使用期限の素材は、営業へのメッセージで1つにまとめます

1番目を軽く見ないでください。 期限の近い素材の多くは、キャンペーンが先に終わっていて何もしなくてよいものです。ここでAIを呼ばずに落とすと、判定に回る件数が大きく減り、営業に届く件数も減ります。

5番目は、毎朝同じ判定を作り直さないためです。 判定が日によって揺れると、営業は前日の連絡と見比べて混乱します。入力が変わったときだけ判定し直します。

AIに処理させる

させるのは、契約条件メモと掲出の行を読み、4つのうちどれに当たるかを、根拠の文字列を付けて判定することだけです。

no_action はAIに選ばせません。 掲出が期限より前に終わるかどうかは日付の比較で決まるので、前処理でフローが付けます。AIが見るのは、掲出が期限より後まで続く素材だけです。

あわせて、掲出の行ごとに「メモの範囲に入っているか」を in_scope ／ out_of_scope ／ unclear で返させます。 期限より前でも、契約に無い媒体に出ていれば問題です。範囲から外れた掲出が1つでもあれば、判定は needs_review に寄せます。

5行目がいちばん起きやすい失敗です。 「延長可」としか書かれていないメモを渡すと、「一般に申し入れは満了の1か月前まで」と補って negotiate にします。メモに無い条件で見立てを出すと、営業はその期限を信じて動きます。

指示内容を固定する

あなたは広告会社の制作管理部で、タレント・モデルを起用した広告素材の
使用期限が近づいたときに、停止の手配か延長の交渉かの見立てを作る補助です。
最終的に決めるのは広告主と営業です。あなたは見立てだけを出します。

【入力】
- 素材：{asset}（素材ID、出演者、種別、使用開始日、使用期限）
- 契約条件メモ：{contract_note}
- 掲出の行：{placements}（媒体、地域、開始日、終了予定日）

【してほしいこと】
1. 契約条件メモから、次の4点を書かれているとおりに写してください。
   延長の可否／申し入れの期限の文言／使える媒体／使える地域
   書かれていなければ「記載なし」としてください。
2. 掲出の行ごとに、媒体と地域がメモの範囲に入っているかを
   in_scope／out_of_scope／unclear で答えてください。
3. 次の基準で verdict を1つ選んでください。
   - negotiate：メモに延長できる旨がある
   - stop：メモに延長できない旨がある
   - needs_review：延長の可否が「記載なし」か「要相談」など
     どちらとも読める、または out_of_scope／unclear の掲出がある
4. 判定の根拠にしたメモの文字列を evidence にそのまま写してください。

【厳守事項】
- メモに書かれていない条件を、業界の慣行や一般論で補わないでください。
- 「要相談」「応相談」は、延長できる旨として扱わないでください。
- 日付の計算をしないでください。申し入れの期限は文言のまま写してください。
- 延長料の金額を計算しないでください。
- 迷ったときは needs_review を選んでください。
- 回答に JSON マークダウンを含めないでください。

「要相談を延長できる旨として扱わない」を明記しないと negotiate になります。 「延長可（要相談）」には「可」の字があり、何も言わなければそれを根拠に選びます。第3章の（b）で人によって読み方が分かれていたのは、まさにこの書き方です。 迷う書き方は人に回す、と決めておくことで、担当者による揺れをなくします。

日付の計算を禁じているのは、フローの側で計算するためです。 AIには「満了の1か月前まで」という文言を写させ、フローがその文言の型（「満了のN日前」「満了のNか月前」）を見て日付にします。 型に合わない文言は needs_review に回します。

最後の1行は、公式ドキュメントの FAQ にある対処です。 モデルが JSON をマークダウンで囲むと形式の検証が通らないことがあり、この一文を足すよう案内されています。

出力形式を固定する

プロンプトの出力を JSON にし、次の形の例を渡して形式を「カスタム」で保存します。

{
  "asset_id": "",
  "contract_terms": {
    "extension": "",
    "notice_deadline_text": "",
    "allowed_media": "",
    "allowed_region": ""
  },
  "placements": [
    { "placement_id": "", "media": "", "region": "", "scope": "in_scope | out_of_scope | unclear" }
  ],
  "verdict": "negotiate | stop | needs_review",
  "evidence": [ { "quote": "" } ],
  "open_points": [ { "point": "" } ]
}

1つ目の理由は、根拠と判定を分けて見られることです。 営業へのメッセージには verdict と evidence を並べて出し、なぜその見立てかを1行で読めるようにします。 判定だけが届くと、営業はメモを開き直します。

2つ目は、形式が固定されることです。 公式ドキュメントでは、プロンプトを保存すると最新の自動検出の形式または定義したカスタムの形式がロックされ、フローで使うときは保存された形式が使われるとされています。毎朝同じ形で返ってくるので、台帳への書き込みとメッセージの組み立てが壊れません。

注意が1つあります。 公式ドキュメントの制限事項に、フィールドのキーの無い JSON（["abc", "def"] のような配列）はサポートされないとあります。evidence と open_points を文字列の配列にせず、キー付きの要素の配列にしているのはこのためです。

営業に届くメッセージは、フローの側で次の形に組み立てます。

【起用素材の使用期限のお知らせ】（決める期限の近い順）

■ ○○食品／出演：A さん／動画（15秒）
  使用期限：12月15日　決める期限：11月14日（延長の申し入れ期限）
  見立て：延長交渉（negotiate）
  根拠：「延長は満了の1か月前までに書面で申し入れ」
  掲出中：SNS 広告（全国）・店内サイネージ（関東）
  → 台帳の「決定」に、延長／停止を入れてください

見立ては契約条件メモから作ったものです。
延長の可否は契約書と事務所への確認で決まります。

最後の2行は毎回入れる定型文です。 見立てがAIの作ったものであることと、最終的な可否は契約書で決まることを、届くたびに思い出してもらいます。

システムへ連携する

素材台帳の「決定」の列には書き込みません。 この構成が書くのは見立てまでで、「決定」を入れるのは営業です。 判定から停止の依頼を自動で出す仕組みも作りません。止める作業は、各媒体の担当が管理画面と店舗への連絡で行います。

Teams への投稿には上限があります。 公式ドキュメントでは、メッセージの大きさは約28KBが上限で、フロー ボットの操作は接続あたり300秒で25回とされています。営業ごとに1通にまとめ、1通に入れる素材は10件までにします。 送る営業が25人を超える朝は、送信の間に待ちを入れます。

Teams の管理センターで、Workflows のアプリが許可されている必要があります。 公式ドキュメントでは、メッセージの投稿は Workflows（旧 Power Automate）のアプリが使えて、管理センターで「許可」になっていることが前提とされています。制作管理部のチャネルはプライベート チャネルにしません。 プライベート チャネルへの投稿は現在サポートされていないとされています。

人が確認する

判定のすべてを、営業か制作管理部のどちらかが確かめます。 この構成は見立てを早く、そろった形で届けるためのもので、判定を確定させる段はありません。

1. 営業が negotiate と stop を見る … 根拠の文字列を読み、広告主と延長するか止めるかを話して「決定」を入れます
2. 制作管理部が needs_review を見る … 契約書の原本を開き、延長の可否と申し入れの期限を確かめて、契約条件メモを書き直します
3. 制作管理部が延長の交渉を担う … 「決定」が延長になったものについて、事務所へ申し入れます
4. 媒体の担当が停止を確かめる … 「決定」が停止になったものについて、媒体ごとに止めた日を掲出計画に入れます

2番目で契約条件メモを書き直すのが、いちばん効く作業です。 次にその素材や同じ事務所の素材が出てきたとき、メモがそろっていれば needs_review になりません。

4番目を省かないでください。 店頭のポスターは、店舗に連絡しただけでは外れたか分かりません。止めた日が掲出計画に入らない掲出は、使用期限の翌日に「期限切れで掲出中」として制作管理部のチャネルに出ます。

例外に対処する

最後の行は、延長の交渉が終わった後の更新漏れを拾います。 延長が決まっても、台帳の使用期限を書き換えないと、期限の翌日に「期限切れで掲出中」の誤報が出ます。 逆に、交渉がまとまらなかった素材がそのまま掲出され続けることも防ぎます。

記録を残す

• 判定ごとの入力（契約条件メモ、掲出の行、撤去日数）と、AIが返した JSON の全文
• 営業に届けた日時と、決める期限
• 「決定」が入った日時と、決めた人
• 見立てと「決定」が食い違ったもの … negotiate だったが停止にした、などの記録
• 使用期限を過ぎて掲出が残った件数と、外れるまでの日数

4つ目は、判定の精度ではなく、メモの書き方を直す材料です。 食い違いの多くは、広告主の都合で延ばさなかっただけで、AIの誤りではありません。ただし、stop と出たのに延長できたものは、メモの書き方を疑います。

最後の行が、この構成の効き目を測る数字です。 期限切れの掲出が0件の月が続くことが、作業時間の削減より大事な目標です。