地域の情報誌に載せる店舗の原稿を、Apps Script から生成AIに渡して表記のゆれと営業時間・電話の食い違いを校正する

処理の起点を決める

起点は、15分ごとの時間主導型のトリガーです。 Apps Script が原稿の管理シートを見て、状態が「校正依頼」の行を拾います。

ドキュメントの保存やシートの編集をきっかけにしない理由は2つあります。書き手は書きながら何度も保存するので、保存のたびに校正が走ると、書きかけの原稿に指摘が出ます。 状態を「校正依頼」にするという書き手の操作を合図にすれば、書き終えた原稿だけが対象になります。もう1つは、締め切り前に依頼が重なっても、15分ごとに一定の本数ずつ処理すれば、実行時間の上限に当たりにくいことです。

公式の割り当ての表では、1回の実行は6分までとされています。1回の実行で処理する原稿は5本までにし、残りは次の回に回します。 処理を始めた行は状態を「校正中」に変え、次の回で二重に拾わないようにします。終わったら「校正結果あり」にします。

6分を超えて止まった行は「校正中」のまま残ります。 30分以上「校正中」のままの行は、次の回で「校正依頼」に戻して拾い直します。

入力データを集める

質を決めるのは、店舗の番号です。 原稿と台帳を店名で結びつけると、「カフェ ○○」と「○○カフェ」、本店と支店で引けない店舗が出ます。管理シートに店舗の番号の列を足し、書き手が原稿を登録するときに番号を選ぶ形にします。 新しい店舗は、営業が先に台帳に行を作ります。

台帳の「確認した日」も渡します。 半年以上前に確認した値と食い違ったときは、原稿のほうが新しい可能性が高いと分かります。どちらを疑うかの手がかりを、一覧に一緒に出します。

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

本文は DocumentApp でドキュメントを開き、getBody() から取り出します。公式のページでは、Body の getText() は要素の内容を文字列として返すとされています。AI に渡すのはこの文字列です。 画像や表の装飾は渡しません。

置き換えの表での検索は、本文の文字列に対して JavaScript の正規表現で行います。 公式のページでは、Body の findText() は正規表現で探せるものの、キャプチャグループやモード修飾子など一部の機能は十分に対応していないとされ、要素の中の文字のかたまりごとに照らすとされています。複雑な表現は getText() の文字列のほうで探し、findText() は使いません。

台帳は店舗の番号で1行だけを引き、AI には渡しません。 比べるのは Apps Script です。台帳を AI に渡すと、AI が台帳の値で原稿を「直した」指摘を返し、原稿に何が書かれていたかが一覧から消えます。

AIへ渡す前に整形する

1. 状態の確認 … 状態が「校正依頼」で、店舗の番号が入っている行だけを拾います。番号が空の行は「店舗の番号なし」として書き手に戻します
2. 本文の取り出し … getText() で文字列にし、前後の空白を落とします
3. 長さの確認 … 3,000字を超える原稿は、特集の記事などの別の扱いとして AI に渡さず、編集者に回します
4. 置き換えの表での検索 … 種類が「置き換え」の決まりを順に当て、見つかった箇所を「決まりの番号・直す前・直した後・位置」として先に一覧に載せます
5. 全角・半角のそろえ … 照らし合わせ用に、本文の写しの数字とハイフンを半角にそろえた文字列も作ります。AI に渡すのは元の本文のほうです。 全角の数字そのものが表記の決まりの対象だからです
6. 台帳の値のそろえ … 電話番号は数字だけにし、営業時間は「HH:MM-HH:MM」の形、定休日は曜日の集合にそろえておきます

4番目で見つかったものは、AI に重ねて探させません。 指示文に「次の指摘はすでに見つかっている」と渡し、同じ箇所を二重に指摘しないようにします。 編集者が同じ指摘を2回見ると、一覧そのものを信用しなくなります。

AIに処理させる

させるのは2つです。表記の決まり（判断）に照らした表記のゆれ・誤字の指摘と、店舗の情報を書かれたとおりに抜き出すことです。

店舗の情報は、情報の欄と本文の両方から抜き出させます。 第3章の（c）のとおり、本文に「火曜日はお休み」と書かれていれば、それも定休日として出させます。同じ項目が2か所に出てくれば両方を返させ、食い違いはコードが見つけます。

価格は、税込の表示があるかを文字から読ませるだけです。 国税庁のページでは、事業者が消費者にあらかじめ価格を表示するときは、税込の価格を表示することが義務付けられ、チラシの広告や新聞の広告など媒体を問わないとされています。認められる表示の例として「11,000円」「11,000円（税込）」「11,000円（税抜価格10,000円）」などが挙げられています。AI には「（税込）」「税抜」などの文字があるかを抜き出させ、税込として足りるかの判断は表記の決まりと編集者に置きます。

4行目は、これから特に効いてきます。 同じ国税庁のページでは、令和9年4月1日から令和11年3月31日までの2年間、飲食料品の譲渡について消費税率が引き下げられ、飲食料品の総額表示の特例が設けられるとされています。飲食店の紹介の原稿では、その時期の前後で価格の書き方が変わりえます。AI が税込の価格を計算して書き直すと、どの税率で計算したかが分からない値が誌面に載ります。

指示内容を固定する

あなたは地域の情報誌の校正の担当です。店舗の紹介の原稿を読み、
表記の決まりに照らした指摘と、店舗の情報の抜き出しを行います。

【指摘の決まり】
- 【表記の決まり】に反する箇所を指摘し、rule_no に番号を入れてください。
- 誤字・脱字、送り仮名の誤り、同じ原稿の中での表記の不統一も指摘してください。
  決まりに無いものは category を other にし、rule_no を空にしてください。
- original には、原稿の本文から直す前の文字列をそのまま写してください。
  1文字も変えないでください。1つの段落の中の、前後を含めて10〜30字ほどにしてください。
- suggestion には直した後の文字列を、original と同じ範囲で書いてください。
- 【すでに見つかった指摘】と同じ箇所は指摘しないでください。
- 文の言い回し、店舗の魅力の書き方、文体は直さないでください。

【抜き出しの決まり】
- 営業時間、定休日、電話番号、住所、価格を、原稿に書かれたとおりに抜き出してください。
  数字や記号を直さないでください。全角・半角もそのままにしてください。
- 情報の欄だけでなく、本文に書かれたものも抜き出し、where に field か body を入れてください。
- 同じ項目が2か所以上にあれば、すべて出してください。
- 書かれていない項目は出さないでください。推測で埋めないでください。
- 価格には、「税込」「税抜」「消費税」などの文字が付いているかを tax_label に入れてください。
  税込の価格を計算しないでください。

【すでに見つかった指摘】{rule_hits}
【表記の決まり】{rules}
【原稿の本文】{body}

「1文字も変えないで写す」を明記するのは、照合のためです。 写した文字列が本文に無ければ、その指摘はコードで外します。指摘の正しさを AI の言い分ではなく、本文の文字に置きます。

「数字や記号を直さない」は、抜き出しの命です。 AI は「03-1234-5678」と「03ー1234ー5678」を同じものとして、そろえた形で返したくなります。原稿に長音の「ー」が入っていること自体が表記の誤りなので、そろえられると見つけたかった誤りが消えます。

出力形式を固定する

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

{
  "corrections": [
    {
      "category": "notation | typo | inconsistency | other",
      "rule_no": "R-012",
      "original": "",
      "suggestion": "",
      "reason": ""
    }
  ],
  "store_facts": [
    {
      "item": "hours | closed_days | phone | address | price",
      "where": "field | body",
      "text": "",
      "tax_label": "tax_included | tax_excluded | none | not_price"
    }
  ]
}

指摘と抜き出しを分けて持つのは、行き先が違うからです。 corrections は編集者が原稿に入れるかを決める一覧へ、store_facts は Apps Script が台帳と比べる材料へ回ります。抜き出しは AI の判断を含まない値なので、比べ方を変えても AI を呼び直さずに済みます。

受け取ったあと、Apps Script が次の照合をします。

長さの確認をコードで行うのは、スキーマに書いても効かないからです。 公式のページでは、minLength／maxLength は制約付きの生成で無視され、サーバーが外すとされています。エラーにならないので、書いて安心してしまうのがいちばん危ない形です。 一方で minItems／maxItems と、数値の minimum／maximum は効くとされています。

校正の一覧は、原稿ごとに次の形で管理シートのタブに書きます。

【原稿 2611-034 ○○食堂（取材枠）担当：編集A】
指摘（決まり）  R-012 「お問合せ」→「お問い合わせ」
指摘（AI）      R-031 「11時〜20時」→「11:00〜20:00」
指摘（AI）      other 「こだわりの自家製のタレ」→ 同じ原稿で「たれ」と混在
店舗の情報      電話　食い違い（原稿 0X-XXXX-1234／台帳 0X-XXXX-1243、台帳の確認 2026-04）
店舗の情報      定休日　field「火曜」／body「月曜はお休み」で食い違い
価格            「ランチ 900円」税込の表示なし
外した指摘      1件（本文に無い文字列）

システムへ連携する

原稿のドキュメントには書き込みません。 指摘は一覧に出し、編集者が提案のモードで入れます。Apps Script が原稿を直接書き換えると、誰がどこを直したかが原稿の履歴から追いにくくなります。 書き手は提案を見て、採るか戻すかを決められます。

店舗の台帳にも書き込みません。 食い違いが出ても、台帳を直すのは営業が店舗に確かめたあとです。

API の鍵は、スクリプトのプロパティに置きます。 URL Fetch の呼び出しは、公式の割り当ての表で Workspace のアカウントなら1日100,000回とされ、月240本では問題になりません。

人が確認する

編集者は、校正の一覧を見てから原稿を開きます。 一覧を見ずに原稿を頭から読むと、これまでと同じ時間がかかります。

1. 店舗の情報の食い違いを先に見る … 電話・営業時間・定休日の食い違いは、営業に確認を頼みます。台帳の確認した日が古ければ、原稿の側が正しい可能性も伝えます
2. 指摘を採るかを決める … 決まりの番号が付いた指摘は原則として採り、other の指摘は書き手の意図を考えて決めます
3. 文の流れを読む … AI が見ない部分です。店舗の魅力が伝わるか、取材の内容と合っているかを読みます
4. 価格の要確認を片付ける … 税込の表示が無い価格は、書き手か営業に確かめます

3番目は、この構成で編集者に残す本来の仕事です。 表記と数字の確認から手が空いた分を、ここに使います。

目標は、240本をならして1本4分です。 一覧の確認に1〜2分、文の流れを読むのに2〜3分という見込みです。食い違いの多い号は4分を超えますが、その分は営業の確認に回る時間です。

例外に対処する

7行目で「AI の指摘なし」と明記するのが大事です。 一覧が空に見えると、指摘が無いのか AI が動かなかったのかが分かりません。動かなかったときは、そう書きます。

6行目のように、台帳の形に収まらない書き方は、一致とも食い違いとも言いません。 「不定休」と「定休日なし」を同じとみなすかどうかは、店舗に聞くまで分かりません。

記録を残す

• 原稿ごとの校正の一覧（決まりの指摘、AI の指摘、店舗の情報の照らし合わせ、価格の要確認）
• AI に渡した本文と表記の決まりの版、返ってきた JSON の全文
• 照合で外した指摘 … 本文に無かった文字列と、長すぎて外したもの
• 編集者が採った指摘と採らなかった指摘
• 店舗の情報の食い違いと、営業が店舗に確かめた結果（どちらが正しかったか）
• 表記の決まりのシートの変更の履歴

4つ目は、表記の決まりを直す材料です。 other の指摘のうち毎号採られているものは、決まりに足すべきものです。逆に、決まりの番号付きなのに採られない指摘は、決まりの書き方が現場と合っていません。

5つ目は、台帳の当てになり方を測る材料です。 食い違いのうち台帳の側が古かった割合が高ければ、原稿より先に台帳の確認の仕方を直すほうが効きます。