メールマガジンを配信する前に、本文の誤字・表記ゆれ・リンク先・配信停止の表示・価格の表記を点検し、直す箇所を担当に返す

処理の起点を決める

「点検待ち」のフォルダに原稿が入ったこと、または原稿が更新されたことを起点にします。 Make の Google Docs の Watch Documents を、このフォルダに向けて置きます。

フォルダを分けるのは、書きかけの原稿を点検させないためです。 原稿の担当は、書き終えた時点でドキュメントを「点検待ち」へ移します。書いている途中のドキュメントを見張ると、1文字直すたびに点検が走り、指摘の一覧が何通も届いて誰も読まなくなります。

配信の直前にもう一度だけ点検します。 キャンペーンのページは公開の直前まで準備中のことが多く、原稿の点検の時点では開けなかったリンクが配信の時点で開けるかは、配信予定表の配信日時の少し前に、リンクの確認だけを再実行して確かめます。

入力データを集める

質を決めるのは、広告主ごとのルール表です。 「お客さま」と書く広告主の原稿に「お客様」と書いてあることを、AIはルール表がなければ誤りと判断できません。 どちらも正しい日本語だからです。ルール表は、表記の誤りを「その広告主の決まりと違う」という形で判断させるための材料です。

配信の情報を渡すのは、日付と期間の食い違いを見るためです。 「本日20時まで」と書いた原稿が翌日の朝に配信される予定なら、本文だけを読んでも気づけません。 配信日時とキャンペーンの期間を一緒に渡して、本文の日付・曜日・期限と照らします。

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

本文は Get Content of a Document で取り出します。リンクは、本文の文字列からではなく、ドキュメントのリンクの情報から取ります。 「こちら」のようにURLが表に出ていないリンクは、本文の文字列だけを見ても見つかりません。

リンクの一覧は、Iterator で1本ずつのまとまりに分けます。 Iterator は配列を1要素ずつのまとまりに変えるモジュールで、リンクの数だけ Make a request が動きます。 結果は Array aggregator で1つの配列に戻し、AIに渡す形にします。

ページのタイトルを取るのが、この構成のひと工夫です。 応答のコードが200でも、行き先が「お探しのページは見つかりません」という独自のエラーページであることがあります。タイトルを取っておけば、AIが「冬のコート特集」という文言に対して「秋の新作」というタイトルのページに着いていることを読めます。

AIへ渡す前に整形する

1. 本文の整形 … 見出し・段落・箇条書きの区切りを残したまま文字列にします。段落ごとに番号を振り、指摘の場所を「何段落目」で返せるようにします
2. リンクの抜き出し … URLとリンクの文言の組を作ります。同じURLが何度も出るときは、確認は1回にまとめます
3. 計測用のパラメータの扱い … utm_ で始まるパラメータは、確認のときには外さずにそのまま呼びます。ルール表にある付け方と違うものは機械の確認で拾います
4. 差し込みの記号の確認 … {{ や %名前% のような、配信システムの差し込みの記号が本文に残っていないかを見ます。配信システムで使う記号は残してよいので、ルール表にある記号の一覧と照らします
5. 定型文の確認 … ルール表にある配信停止の案内の文言、送信者の名称、連絡先が末尾にあるかを文字列で確かめます
6. 個人の情報の除去 … 原稿にテスト用の実在の会員の名前やメールアドレスが入っていないかを見て、入っていればAIに渡す前に伏せます
7. 長さの確認 … 本文が長い号は段落の区切りで分けて渡します

5番目をAIに任せないでください。 配信停止の案内が「あるかどうか」は、ルール表の文言と照らせば決まります。AIに聞くと、似た文言があるだけで「ある」と返すことがあります。 法令で表示が求められる項目なので、決まった手順で確かめます。

AIに処理させる

させるのは、5つの観点で指摘を拾い、指摘ごとに場所と根拠と直し案を書くことだけです。 配信してよいかの判断はさせません。

価格の書き方を見るのは、消費者に向けた価格の表示には税込の価格の表示が求められているからです。 財務省の説明では、総額表示は表示の媒体を問わず、インターネットのホームページや電子メールの広告も含むとされ、たとえば税抜9,800円の商品なら税込の10,780円を表示することがポイントとされています。AIには、価格に税込の表示があるかと、ルール表の書き方に合っているかだけを見させます。

2行目がいちばん起きやすい失敗です。 「通常価格12,000円が20%OFFで9,800円」と書いてあると、AIは計算して「9,600円の誤り」と直し案を書きます。しかし実際の売価が9,800円で、割引率のほうが誤っていることもあります。 どちらが正しいかは原稿からは分からないので、食い違いを指摘するところまでにとどめます。

指示内容を固定する

あなたはメールマガジンの配信前の点検の担当です。
原稿と、機械で確かめた結果と、広告主のルール表だけを見て、
直すべき箇所を拾ってください。推測で埋めないでください。

【点検の観点】
1. typo ......... 誤字・脱字・変換の誤り
2. style ........ ルール表の表記と違う書き方
3. inconsistency  同じ原稿の中での書き方の揺れ
4. price ........ 価格の書き方（税込の表示、割引の前後と割引率）
5. date ......... 配信日時・キャンペーン期間と本文の日付・曜日・期限
6. link ......... リンクの文言と、着いたページのタイトル・URLの食い違い

【厳守事項】
- 指摘ごとに、段落番号と、原稿の該当箇所をそのまま写してください。
- 直し案は、該当箇所をどう書き換えるかを書いてください。
  原稿全体を書き直さないでください。
- ルール表に書かれていない表記を、誤りとして扱わないでください。
  同じ原稿の中で揺れている場合だけ inconsistency にしてください。
- 価格の計算が合わないときは、どちらが正しいかを決めないでください。
  食い違いを指摘し、正しい価格を推測して直し案に書かないでください。
- 税込の表示がない価格は price として指摘してください。
- リンクが開けるかどうかは判断しないでください。
  機械の確認の結果に書かれていることを、そのまま使ってください。
- リンクの文言と着いたページのタイトルが明らかに違う場合だけ
  link として指摘してください。タイトルが空なら needs_check です。
- 固有名詞・商品名・ブランド名は、ルール表にない限り誤字として
  指摘しないでください。迷ったら needs_check にしてください。
- 配信してよいか、法令に照らして問題があるかは書かないでください。
- 指摘がない場合は、findings を空の配列で返してください。

【配信の情報】{delivery_info}
【広告主のルール表】{rule_table}
【機械で確かめた結果】{machine_checks}
【リンクの確認結果】{link_results}
【原稿（段落番号付き）】{draft}

「ルール表に書かれていない表記を誤りとして扱わない」を明記しないと、指摘が増えすぎます。 AIは一般的な表記の好みで「〜できます」を「〜することができます」に、「お問合せ」を「お問い合わせ」に直そうとします。どちらも誤りではなく、広告主が決めていなければ直す理由がありません。 指摘が多すぎる一覧は、原稿の担当が読まなくなります。

「正しい価格を推測して書かない」を、厳守事項と観点の両方で縛っているのも同じ理由です。 直し案に価格が書いてあると、原稿の担当はそれをそのまま貼り付けます。 推測の価格が配信されるほうが、食い違いが残るより悪い結果になります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "draft_id": "",
  "advertiser": "",
  "findings": [
    {
      "category": "typo | style | inconsistency | price | date | link",
      "paragraph": 0,
      "quote": "",
      "suggestion": "",
      "reason": "",
      "level": "fix | needs_check"
    }
  ],
  "summary": ""
}

1つ目の理由は、機械の確認の結果と同じ一覧に並べられることです。 Make の側で、機械の確認の結果を同じ形に変えて findings に足します。リンクの切れは category を link、level を fix として加えます。原稿の担当は、どこから出た指摘かを気にせず、1つの一覧を上から直せます。

2つ目は、level で読む順番を決められることです。 fix は直せば済むもの、needs_check は人が判断するものです。読み合わせの担当が見るのは needs_check と、fix のうち採らなかったものだけです。

3つ目は、指摘が0件のときにシナリオが止まらないことです。 構造化出力は、スキーマに合ったJSONを返すようにする仕組みで、指摘が無いときは空の配列で返ります。 文章で返させると、「問題は見当たりません」という返事をJSONとして読めずに止まります。

Make の側では、機械の確認を次の表の決まりで findings に加えます。

配信停止の案内と送信者の表示を機械の確認に置いているのは、それが法令で求められる表示だからです。 特定電子メール法の第4条は、広告や宣伝のメールを送る送信者に、送信者の氏名または名称と、受信拒否の通知を受けるための電子メールアドレスまたはURLなどを正しく表示することを求めています。有無を文字列で確かめられることを、AIの読み取りに任せる理由はありません。

システムへ連携する

原稿のドキュメントには書き込みません。 指摘をドキュメントのコメントとして書き込むこともできますが、直す前の原稿が変わってしまうと、どの版を点検したかが分からなくなります。 指摘は別の表に書き、原稿は担当が自分で直します。

人が確認する

原稿の担当は、一覧の全部の行に「直した／採らない」を付けます。 採らない行には理由を一言書きます。採否の記録が、次に述べるルール表の手直しの材料になります。

1. fix の行を上から直す … 誤字、リンクの切れ、配信停止の案内の抜けなど。ここは迷わず直します
2. needs_check の行を判断する … 固有名詞、ルール表にない表記、価格の食い違い。価格は商品の台帳で正しい価格を確かめてから直します
3. 読み合わせの担当が見る … needs_check の行と、fix のうち採らなかった行、直した箇所だけを見ます
4. 配信直前の再確認を見る … 配信日時の前に再実行したリンクの確認で、切れが出ていないか

目標は、120本をならして1本10分です。 指摘の一覧を見て直す時間が中心で、頭から全部を読み直す時間は入っていません。 1本に何十件も指摘が出る号は、ルール表が古いか、前の号を複製したときの書き方が残っているかのどちらかです。

例外に対処する

上から3行は、毎号のように起きます。 どれもリンクが切れているわけではないのに、機械の確認では切れたように見えます。ルール表に「ログインが要るページ」と「公開予定のページ」の一覧を持たせ、配信直前の再確認と組み合わせて扱います。

記録を残す

• 点検した原稿の版（ドキュメントのIDと、点検した日時）
• リンクの確認の結果（URLごとの応答のコード、転送先、タイトル）と、配信直前の再確認の結果
• AIの出力のJSONの全文と、そのとき使ったルール表の版
• 指摘ごとの採否と、採らなかった理由
• 配信の後に訂正のメールを出した号と、その理由

4つ目の採否の記録が、ルール表を育てる材料になります。 同じ表記の指摘が毎回「採らない」になっていれば、ルール表のほうが実際の運用と合っていません。 月に1度、採らなかった指摘を観点ごとに数え、ルール表を直します。