広告会社が運用する広告主のSNSアカウントの予約投稿を、投稿の前に表記ルール・NGワード・ハッシュタグの規定で校正する

処理の起点を決める

15分おきの定時実行で、「校正待ち」の行を探します。 行が追加されたときに動く Watch New Rows は使いません。原稿は行を足して書くのではなく、既にある行のステータスを書き換えて校正に回すためです。

セルの変更で動く Watch Changes も使いません。このモジュールはGoogle Sheets の画面で人が行った変更だけを見て、スクリプトの実行や API による変更では動きません。 管理表の一部を他のツールから書き込んでいると、そこから回ってきた原稿が拾われません。

Search Rows でステータスの列が「校正待ち」の行を探し、 見つかった行を1件ずつ処理します。処理を始めたら、まずステータスを「校正中」に書き換えます。次の15分後の実行で、同じ行を二度拾わないためです。

広告主ごとに管理表が分かれているので、広告主の一覧の表を最初に読み、管理表のIDを順に回します。 広告主が増えたら、一覧に1行足すだけで校正の対象になります。

入力データを集める

質を決めるのは、規定の表の書き方です。 「商品名は正しく書く」では照らしようがありません。「誤：フレッシュジュース／正：フレッシュ・ジュース」のように、正誤の組で書きます。 正誤の組になっていれば、AIは本文の中から誤りの側を探せばよく、迷う余地が減ります。

規定の表は、例えば次のような形にします。

種類の列で、機械が見る行とAIが見る行を分けます。 NGワードとハッシュタグの行は前処理で機械が使い、表記ルールの行とNGワードの行の理由はAIに渡します。NGワードの理由を渡すのは、言い換えを見分ける手がかりになるからです。 「比較の根拠を示せない」と分かれば、「どこよりも安い」が同じ問題を持つと判断できます。

ルールに番号を振っておきます。 指摘のたびにルールの番号が返るので、担当者は「なぜ直すのか」を規定の表で確かめられます。 番号の無い指摘は、AIが一般的な正しさで出したものとして区別できます。

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

規定の表は、Get Range Values で範囲ごと読みます。 表記ルール、NGワード、ハッシュタグの規定を別々の範囲に置き、それぞれを読み込みます。行ごとに Search Rows で引くより、1回でまとめて読むほうが操作の回数が少なく済みます。

書き戻しは Update a Row で、行の番号を指定して行います。 値の入れ方は「Raw」を選びます。「User entered」だと、手で入力したときと同じように解釈され、 指摘の文の先頭が「=」や「+」のときに数式として扱われるおそれがあります。

AIへ渡す前に整形する

1. ステータスを「校正中」にする … 二重に拾わないため、処理を始めた時点で書き換えます
2. 本文とハッシュタグを分ける … 本文の中に書かれたハッシュタグも取り出し、ハッシュタグの列と合わせます
3. NGワードの完全一致を確かめる … 規定の表のNGワードを1語ずつ、本文に含まれるかを Make の文字列の関数で確かめます
4. ハッシュタグを確かめる … 数が上限を超えていないか、必須のタグがあるか、禁止のタグが無いかを確かめます
5. 文字数を確かめる … SNSの種類ごとに、自社で決めた上限を超えていないかを確かめます
6. URLを伏せる … 本文のURLは「［URL］」に置き換えてからAIへ渡します。URLの文字列を表記の誤りとして指摘させないためです

3番目から5番目の結果は、AIの結果とは別の列に書きます。 機械が拾ったものは必ず直すもの、AIが拾ったものは担当者が判断するものです。同じ列に混ぜると、確実な指摘と迷いのある指摘の区別がつかなくなります。

AIに処理させる

させるのは、本文を表記ルールと照らして、合わない箇所を探し、ルールの番号と直し案を付けることだけです。

2行目が、機械の確認と分けた理由です。 「最安」がNGワードなら、機械は「最安」を拾えますが、「どこよりも安い」は拾えません。 AIに読ませる意味があるのは、この種類の指摘です。

2行目を明記しないと、指摘の数が増えすぎます。 校正を頼まれたAIは、規定に無くても「より自然な言い方」を出しがちです。指摘が10件並び、そのうち規定に基づくものが2件という状態では、担当者は全部を読まなくなります。

指示内容を固定する

あなたは広告会社のSNS運用チームで、投稿の原稿を広告主の規定に照らして
校正する立場です。広告主の規定に書かれていることだけを根拠にしてください。

【やること】
次の投稿の本文を読み、広告主の規定に合わない箇所をすべて挙げてください。
挙げるのは次の4種類だけです。
1. rule ......... 表記ルールの「誤り」の側の表記が使われている
2. ng_paraphrase  NGワードと同じ意味の別の言い方が使われている
3. inconsistency  同じ投稿の中で、同じ語が2通りに書かれている
4. typo ......... 明らかな誤字・脱字（固有名詞・造語・ブランドの表記は除く）

【厳守事項】
- 本文を書き換えないでください。指摘と直し案だけを返してください。
- 直し案は、指摘した箇所だけを直したものにしてください。
  前後の文まで書き直さないでください。
- ng_paraphrase の suggestion は空にしてください。言い換えの案を作らないでください。
- 規定に無い好みや言い回しの改善は挙げないでください。
- rule と ng_paraphrase には、根拠にしたルールの番号を rule_id に入れてください。
  番号が無いものを rule として挙げないでください。
- NGワードと同じ語がそのまま使われている場合は挙げないでください。
  （別の手順で確認済みです）
- 法令に照らして問題があるかどうかは書かないでください。
- 意味が同じか、規定に当たるか迷うものは、certainty を uncertain にしてください。
  迷ったものを confirmed にしないでください。
- 指摘が無ければ issues を空の配列にしてください。

【広告主】{client_name}
【SNSの種類】{platform}
【表記ルール（番号・誤り・正しい表記・補足）】{style_rules}
【NGワード（語・理由）】{ng_words}
【本文（URLは［URL］に置換済み）】{post_body}

「NGワードと同じ語がそのまま使われている場合は挙げない」は、機械の確認との重複を避けるためです。 両方が同じ語を拾うと、管理表の行に同じ指摘が2回並び、 担当者はどちらを見ればよいか迷います。役割を分けたことを、指示の側でも守らせます。

「前後の文まで書き直さない」を書かないと、直し案が書き直しになります。 「CP」を「キャンペーン」に直すだけの指摘が、文全体を整えた別の文になって返ってきます。 担当者は何が直されたのかを見比べることになり、指摘の意味がなくなります。

出力形式を固定する

構造化出力の JSON Schema で、次の形に固定します。

{
  "issues": [
    {
      "type": "rule | ng_paraphrase | inconsistency | typo",
      "rule_id": "",
      "original": "",
      "suggestion": "",
      "certainty": "confirmed | uncertain",
      "note": ""
    }
  ]
}

「週末限定CP！どこよりも安い10％OFFでお待ちしています」という本文なら、返ってくるのは次のような値です。

{
  "issues": [
    { "type": "rule", "rule_id": "R-01", "original": "CP", "suggestion": "キャンペーン",
      "certainty": "confirmed", "note": "" },
    { "type": "rule", "rule_id": "R-03", "original": "10％OFF", "suggestion": "10％オフ",
      "certainty": "confirmed", "note": "" },
    { "type": "ng_paraphrase", "rule_id": "N-01", "original": "どこよりも安い",
      "suggestion": "", "certainty": "uncertain", "note": "最安と同じく比較の表現" }
  ]
}

3つ目の指摘で suggestion が空なのは、言い換えのNG表現には直し案を作らせないためです。 どう書き換えるかは表現の判断で、担当者が決めます。

1つ目の理由は、管理表の列にそのまま書き戻せることです。 issues の要素1つが1つの指摘で、「原文 → 直し案（ルール番号）」の形に並べて指摘の列に書きます。自由な文章で返されると、どこが指摘でどこが説明かを人が読み分けることになります。

2つ目は、type と certainty を enum で固定できることです。 構造化出力は enum に対応しています。値が決まった選択肢から返るので、Make の側で「certainty が uncertain のものは別の列へ」という振り分けを条件で書けます。 なお、公式の説明では enum の値の大文字・小文字までは保証されないとされているので、比べるときは大文字・小文字を区別せずに比べます。

3つ目は、rule_id で指摘の根拠を確かめられることです。

機械の指摘を左端に置くのは、必ず直すものだからです。 担当者は左から順に見て、機械の指摘を直し、AIの確定の指摘を採るか決め、要判断のものを読むという順で進めます。

スキーマのすべての object に additionalProperties: false を付けます。 構造化出力では必須の指定で、付けないと要求そのものが通りません。

システムへ連携する

書き込むのは、原稿の管理表の指摘の列とステータスの列だけです。 本文の列には書き込みません。本文を自動で直す設定は、作れても作りません。 広告主の承認を受ける文が、誰も読んでいない直し案で変わってしまうからです。

社内チャットへは、件数だけを知らせます。 指摘の中身を流すと、チャンネルが指摘で埋まり、担当者は管理表を見なくなります。「広告主A：指摘あり3件、校正エラー1件」の形で、管理表へのリンクを付けて送ります。

人が確認する

人が見るのは、校正したすべての投稿の指摘の列です。 投稿は広告主の名前で世に出るので、指摘が無かった投稿も、担当者が本文を一度読んでから承認に回します。

1. 機械の指摘を直す … NGワード、ハッシュタグ、文字数は、規定どおりに直します
2. AIの確定の指摘を採るか決める … ルールの番号で規定の表を確かめ、採るものは本文を直します
3. AIの要判断の指摘を読む … 言い換えのNG表現か、広告主に確かめるべきかを決めます
4. 採らなかった指摘に理由を残す … 「固有名詞」「広告主の了承済み」など、一言で残します
5. 本文を一度通して読み、広告主の承認に回す

4番目が、規定の表を育てる記録です。 同じ指摘が「広告主の了承済み」で採られなかったことが続けば、その表記は規定の表に「例外」として足します。 規定の表が実際の運用に追いつくと、要判断の指摘が減っていきます。

目標は、1,200件をならして1件2分です。 指摘の無い投稿は通して読むだけ、指摘のある投稿は規定の表を確かめて直すので数分かかります。

例外に対処する

5行目は、Make の側で機械的に確かめます。 指摘の original の文字列が本文に含まれているかを文字列の関数で見ます。本文に無い文字列への指摘は、AIが本文を読み違えたか、言い換えて写したものです。 確定の列に置くと、担当者は本文の中で存在しない箇所を探すことになります。

3行目と4行目は、構造化出力でもスキーマどおりにならない場合として、公式に挙げられているものです。 応答の停止の理由を見て、該当すれば書き戻さずに止めます。

記録を残す

• 校正した時点の本文とハッシュタグ（管理表の別のシートに写しを残す）
• 機械の確認の結果と、AIの出力（issues の全体）
• そのとき使った規定の表の版
• 担当者が採らなかった指摘と、その理由
• 広告主からの差し戻しの有無と、その内容
• Make のシナリオの実行の履歴

1つ目で本文の写しを残すのは、校正の後に本文が変わるためです。 担当者が直した後の本文しか残っていないと、何を指摘されて、何を直したのかが追えません。

5つ目の差し戻しの記録は、この構成の効き目を見る材料になります。 広告主からの差し戻しのうち、規定の表にある決まりで防げたものがどれだけあったかを、月ごとに数えます。