SNS投稿の二次利用の許諾依頼に投稿者から届いた返信を判定し、許諾・条件付き・拒否を利用条件とあわせて台帳に記録する

処理の起点を決める

起点は3つあります。 タグ付けされた投稿の取り込み、返信の登録、担当者の確定です。

1つ目は、公式アカウントがタグ付けされた投稿です。 New Tagged Media は、ビジネスアカウントが写真や動画にタグ付けされたときに動きます。キャプションでの言及（@の付いた文字）では動かないので、候補はタグ付けされた投稿に限られます。候補のテーブルに投稿のURL・投稿者・キャプション・時刻を足すだけで、AIは呼びません。 候補の数は多く、どれを使うかは人が選ぶからです。

2つ目は、返信のテーブルに新しいレコードが入ったときです。 担当者が「返信の登録」フォームを送ると、つないだテーブルにレコードが入り、それを起点に判定の Zap が動きます。

3つ目は、許諾台帳の「確定」のボタンです。 Zapier Tables のボタンの欄は、Zap を起こしたり、続けたりできるとされています。押されたら、確定の日時と押した人を記録し、状態を「確定」にします。

DMの返信を自動で拾わないのは、拾う手段が無いからです。 返信をメールで受け取る運用に変える方法もありますが、投稿者にとって手間が増え、返信率が下がります。 返信はDMのまま受け、貼る手間だけを担当者が負います。

入力データを集める

質を決めるのは、依頼した範囲です。 「EC・店頭・公式SNSで1年間」と依頼したのに「SNSならいいですよ」と返ってきたら、それは許諾ではなく条件付きです。 依頼の範囲を渡さないと、AIは「いいですよ」だけを見て許諾と判定します。

依頼文の版を台帳に残しておきます。 依頼文を途中で直すと、同じ「OKです」でも何に対するOKかが変わります。返信は、その人に送った版の依頼文に対する答えとして読みます。

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

検索は依頼番号の1つだけで行います。 Zapier Tables の検索は、指定したすべての条件に合うレコードだけを見つけるとされています。投稿者のアカウント名を条件に足すと、投稿者が名前を変えたときに見つからなくなります。

見つからなければ、判定せずに担当者に返します。 検索の設定には「見つからなければレコードを作る」という選択肢がありますが、使いません。 番号の写し間違いで新しい依頼が作られ、どの依頼にも紐づかない許諾が台帳に残るからです。

AIへ渡す前に整形する

1. 依頼番号の形の確認 … 「R-」と年月と4桁の形かを確かめます。全角の英数字は半角にします
2. 原文の保存 … 返信の原文は、手を加える前の形で台帳に写します。判定に使う文字列とは別に残します
3. 定型の部分の除去 … DMの画面から写すと付いてくる「既読」や時刻の文字を除きます
4. 同じ依頼への2通目の確認 … 同じ依頼番号の返信がすでにあれば、前の返信と判定もあわせてAIに渡します
5. 依頼してからの日数 … 依頼の日から返信の日までを数えます。依頼の期限を過ぎた返信は、担当者に回します

4番目は、条件が後から足される返信のためです。 1通目で「いいですよ」、2通目で「あ、名前は出さないでください」と来ることがあります。2通目だけを読むと「条件の追加」が分からず、1通目だけで確定すると条件が抜けます。 同じ依頼の返信は、まとめて判定し直します。

2番目を軽く見ないでください。 許諾の根拠は、返信の原文そのものです。整えた後の文字列しか残っていないと、後で確かめるときに「本当にそう書かれていたか」が言えなくなります。

AIに処理させる

させるのは、返信を5つのどれかに判定し、条件と手がかりを書き出すことだけです。

unclear を広く取るのが、この構成でいちばん大事な決まりです。 前向きに見える返信でも、使ってよいという言葉が無ければ unclear です。 担当者がもう一度確かめる手間は増えますが、許諾の無い投稿を使うよりずっと軽く済みます。

条件は種類ごとに書き出します。 媒体の限定、期間、クレジットの表記（アカウント名・本名・表記不要）、加工の可否、謝礼の求め、その他の6種類です。

権利者かどうかの手がかりは、返信の文面に出てくるものだけを書き出します。 「友だちが撮ってくれた写真です」「娘の写真なので」「元は別の人の投稿です」のような一文です。手がかりが1つでもあれば、判定が granted でも担当者に回します。

指示内容を固定する

あなたは小売チェーンのマーケティング部で、お客様のSNS投稿を販促に使う許諾の返信を読む担当です。
【依頼した範囲】に対する【返信】が、許諾か、条件付きか、拒否か、質問か、不明かを判定してください。
返信に書かれていることだけで判定してください。書かれていないことを推測しないでください。

【判定の選び方】
- granted ....... 依頼した範囲のまま使ってよいと、言葉で明言している
- conditional ... 使ってよいと言っているが、範囲を狭めるか、条件を付けている
- declined ...... 使わないでほしいと言っている
- question ...... 判断の前に質問をしている（許諾の言葉があっても質問があれば question）
- unclear ....... 上のどれとも言い切れない
迷ったときは unclear を選んでください。granted を選ばないでください。

【厳守事項】
- 感謝や喜びの言葉だけで、使ってよいという言葉が無い返信は unclear です。
- 絵文字やスタンプだけの返信は unclear です。絵文字の意味を解釈しないでください。
- 返信が依頼した範囲の一部だけを認めている場合（例：SNSだけ）は conditional です。
- 条件は【条件の種類】ごとに分けて、返信の言葉をそのまま conditions に写してください。
- 撮影者が別の人である、写っている人が別の人である、別の人の投稿の転載である、
  という手がかりが返信にあれば、その文を rights_clues に写してください。
- 権利者かどうかの結論は書かないでください。
- 質問への回答や返信の文案は書かないでください。
- evidence には、判定の根拠にした返信の言葉をそのまま写してください。

【条件の種類】media（媒体）/ period（期間）/ credit（クレジット）/ edit（加工）/ reward（謝礼）/ other
【依頼した範囲】{request_scope}
【これまでの返信と判定】{previous_replies}
【返信】{reply_text}

「感謝の言葉だけは unclear」を明記しないと、ほとんどの前向きな返信が granted になります。 依頼への返信として届いた「ありがとうございます！」は、文脈上は承諾に見えるからです。禁じるのは、文脈で許諾を補うことそのものです。

「迷ったら granted を選ばない」を書くのは、間違え方に重さの差があるからです。 unclear を granted と取り違えると許諾の無い投稿が使われ、granted を unclear と取り違えると担当者の確認が1件増えるだけです。

出力形式を固定する

AI by Zapier の出力の項目として、次の形で受け取ります。

{
  "verdict": "granted | conditional | declined | question | unclear",
  "evidence": "",
  "conditions": [
    { "type": "media | period | credit | edit | reward | other", "text": "" }
  ],
  "rights_clues": [""],
  "questions_asked": [""],
  "changed_from_previous": true
}

1つ目の理由は、verdict で Paths を機械的に分けられることです。 5つの値のどれかしか返らないので、分岐の条件がそのまま書けます。Paths は1つのグループに最大10本の分岐を置けるので、5つの判定と、どれにも当たらないときのフォールバックを1本置きます。

2つ目は、conditions を台帳の欄に分けて入れられることです。 媒体・期間・クレジット・加工のそれぞれを別の欄にすると、ECの担当者は「クレジット」の欄を見るだけで、表記が要るかが分かります。

3つ目は、evidence と rights_clues で確認が速くなることです。 担当者は返信の全文を読む前に、どの言葉で判定したかを見られます。

システムへ連携する

ECと店舗の担当者には、許諾台帳の「使ってよい投稿」の表示だけを見せます。 Zapier Tables の表示（ビュー）は、絞り込みの条件に合うレコードだけを並べます。状態が「確定」で、判定が許諾か条件付きのものだけを出し、条件の欄を横に並べます。

ECのシステムには書き込みません。 画像を商品ページに載せるのは、今までどおりECの担当者です。この構成が持つのは、使ってよいかの記録までです。

人が確認する

判定はすべて、担当者が確かめてから確定します。 目標は、1件あたり2分です。

1. Slack で知らされたものを先に見る … 条件付き、質問、不明、要確認
2. 条件付きは、条件を受け入れるかを決める … 受け入れるなら確定、受け入れないなら使わない
3. 質問と不明は、担当者が返信を書いて送る … 新しい返信が来たら、またフォームに貼ります
4. 許諾（未確定）は一覧で evidence を読み、確定のボタンを押す
5. 要確認は、投稿の画像を見て、撮影者や写っている人を確かめる

5番目を省かないでください。 子どもが写っている投稿や、友人が撮った写真は、投稿者の許諾だけでは足りないことがあります。 どこまで確かめるかは、社内の基準で決めておきます。

確定のボタンを押せる人を決めておきます。 押した人は台帳に残るので、後で問い合わせがあったときに、誰がどの返信を見て確定したかが言えます。

確かめる時間を1日1回に決めます。 返信が届くたびに見ると、担当者の手がそのたびに止まります。午前中に前日分の Slack の知らせと未確定の一覧をまとめて見る運用にすると、2分の目標に収まります。ECの掲載の締切が迫っているものだけは、その場で見ます。

例外に対処する

AI by Zapier は、使うたびに前の判定を覚えていません。 公式の説明でも、前の実行から学ぶことはないとされています。2通目を判定するときに前の返信を渡すのは、そのためです。 渡さなければ、2通目は単独の返信として読まれます。

3行目がいちばん重い例外です。 取り下げの依頼は、許諾の返信と同じ経路（DM）で届きます。フォームに貼って判定すれば、表示から外れるところまでは自動です。 店頭のポップのように印刷したものは、担当者が回収します。

記録を残す

• 返信の原文（手を加える前）と、フォームに貼った人と日時
• 依頼した範囲と依頼文の版
• AIの出力（verdict、evidence、conditions、rights_clues）
• 確定した人と日時、確定の前に判定を変えた記録
• 取り下げの依頼と、表示から外した日時
• 使ってよい投稿を、どの媒体にいつ使ったかの記録（ECと店舗の担当者が足す）

4つ目で「判定を変えた記録」を残すのは、指示を直す材料にするためです。 unclear を担当者が granted に変えることが多い言い回しがあれば、それは基準の側に「許諾とみなす言葉」として足すかを検討します。 AIの判定を後から緩めるのは、人が決めてからにします。