社外に出す文章の誤字と表記ゆれを社内ルールで一括チェックする

処理の起点を決める

人が「チェックする」と決めたときが起点です。自動で走らせません。

理由は、原稿は書きかけの状態で何度も保存されるためです。保存のたびにチェックが走ると、書いている途中の文章に大量の指摘が出て、邪魔になります。

半自動化する場合は、Google ドキュメントのメニューに項目を足し、担当者が選んだときに実行します。Google Apps Script はドキュメントにメニューを追加できます。CMSで運用している場合は、下書き保存時ではなく「公開申請」のボタンを押したときに走らせます。

入力データを集める

表記ルール一覧が、この構成の本体です。 作り方は次のとおりです。

1. まず既存の公開資料を下敷きにします。日本翻訳連盟の「JTF日本語標準スタイルガイド（翻訳用）」は、文体、句読点、漢字とカタカナの表記、数字とアルファベット、記号類のルールをまとめた公開文書です。官公庁向けの文書を書く機会があれば、文化審議会の建議「公用文作成の考え方」（令和4年1月7日）も参照できます
2. そこから自社で実際に迷う項目だけを抜き出します。 全部入れないでください
3. 過去1年の校正コメントを見返し、繰り返し指摘している項目を足します
4. 自社サービス名・機能名・主要な他社名の正式表記を足します
5. 合計100〜150項目に収めます

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

原稿： Google ドキュメントから本文を取り出します。Google Apps Script では DocumentApp からドキュメントの本文を取得できます。2024年にタブ機能が追加されて以降、本文の取り方が変わっている点に注意してください。古い記事のコードをそのまま使うと本文が取れないことがあります。

表記ルール・用語集： スプレッドシートから読み込みます。編集はマーケティング担当が行うため、スプレッドシートが最も運用しやすい置き場です。

外部APIの呼び出し： Google Apps Script から生成AIのAPIを呼ぶには UrlFetchApp を使います。外部リクエスト用の権限（スコープ）の承認が必要です。初回実行時に承認画面が出ます。

AIへ渡す前に整形する

1. 機械的に判定できる項目を先に処理する … 全角の英数字、半角カタカナ、三点リーダやダッシュの種類、括弧の全角半角、数字の桁区切り、連続する空白。これらは正規表現で検出します。AIに任せると、見落とすうえに費用がかかります
2. 固有名詞を突き合わせる … 用語集にある表記と1文字でも違えば指摘します。ここも機械処理です。「弊社サービス名の表記ゆれを見つけて」とAIに頼む必要はありません
3. 原稿を分割する … 長い原稿は見出し単位に分けます。ただし分割すると文書全体の一貫性が見えなくなります。 ですます調とである調の混在、同じ用語が前半と後半で違う表記になっている、といった指摘は分割すると出せません。全体を通した文体の判定だけは、本文を要約せずに1回まとめて渡します
4. コード・引用・数式を除外する … 技術記事では、コード部分を校正対象から外します。除外しないと、コード内の英数字が全部指摘されます
5. 既知の例外を除外する … 他社の正式名称に半角カナが含まれる、引用文が旧かなづかい、といった例外を先に登録しておきます

AIに処理させる

正規表現でできることはAIにさせません。 AIに回すのは、文脈を読まないと判定できない項目だけです。

やらせないこと：

• 文章の書き換え。 「読みやすく直して」と頼むと、書き手の意図した表現まで平板にされます。修正案は「その箇所をどう直すか」に限定させます
• 事実の確認。 数値や社名が事実として正しいかは、この構成の対象外です。AIは知識で判断してしまうため、誤った指摘が混ざります
• 内容の評価。 「この記事は分かりやすいか」を聞かない。校正と編集は別の作業です

指示内容を固定する

あなたは社外向け文書の校正者です。
原稿を読み、下の【表記ルール】に反する箇所と、日本語として
誤っている箇所を指摘してください。

【厳守事項】
- 文章を書き換えないでください。指摘と修正案だけを返してください。
- すべての指摘に、根拠となるルール番号を必ず付けてください。
  ルールに該当しない日本語の誤り（誤字・係り受け・二重表現・敬語）は
  rule_id を "GEN" とし、category にどの種類かを書いてください。
- 表記ルールに書かれていない好みの問題を指摘しないでください。
  「もっと簡潔にできます」「この語のほうが自然です」は不要です。
- 書かれている内容が事実として正しいかは判定しないでください。
  数値・社名・製品仕様の正誤は対象外です。
- 原文は必ず本文からそのまま引用してください。要約や言い換えをしないでください。
- コードブロックと引用ブロックの中は対象外です。

【文書種別】
{doc_type}（Web記事 / 広告文 / プレスリリース / 営業資料）

【表記ルール】
{style_rules}

【用語集】
{glossary}

【原稿】
{draft}

「原文は本文からそのまま引用する」の1行が実務上いちばん効きます。 引用が本文と一致しない指摘は、AIが作り出した箇所である可能性が高いためです。後段のプログラムで「原文が本文に見つからない指摘」を機械的に捨てられます。

「好みの問題を指摘しない」も必ず入れます。 これがないと、1本の記事に50件の指摘が出ます。指摘が多すぎる仕組みは、2週間で使われなくなります。

表記ルールと用語集は毎回同じ内容を送ることになります。Claude API には同じ内容の再送を安く済ませるキャッシュの機能があり、1,024トークン以上のまとまりが対象、5分間有効（読み出しがあるたびに延長）、キャッシュからの読み出しは通常の入力料金の10％という条件が公開されています。ルール一覧が長くなるほど効きます。

出力形式を固定する

{
  "doc_type": "",
  "findings": [
    {
      "rule_id": "R001 | GEN",
      "category": "表記統一 | 用語 | 文体 | 記号 | 誤字 | 係り受け | 二重表現 | 敬語 | 長文",
      "original": "",
      "suggestion": "",
      "location_hint": "",
      "severity": "must | should | info"
    }
  ],
  "document_level": {
    "style": "ですます調 | である調 | 混在",
    "mixed_examples": []
  },
  "notes": ""
}

構造化した形にする理由は3つあります。

第一に、rule_id で機械的にふるいにかけられます。ルール一覧に存在しない番号の指摘は捨てます。 これで根拠のない指摘がほぼ消えます。

第二に、original が本文に含まれるかを照合できます。含まれなければ捨てます。

第三に、severity で並べ替えられます。must（表記ルール違反・誤字）を上に、info（一文が長い）を下に出せば、担当者は上から順に見るだけで済みます。

document_level を分けているのは、文体の判定が「箇所」ではなく「文書全体」の話だからです。

システムへ連携する

指摘の戻し方には3つの選択肢があります。

2番目について補足します。Google ドキュメントに本文の特定箇所を指すコメントを付けることは Drive API の機能として可能ですが、コメントの位置指定は文書の版に紐づくため、文書が編集されると位置がずれます。 公開文書にも「位置が変わらない文書での利用を推奨する」と書かれています。校正対象は編集される前提の原稿なので、この方式は最初に選ぶべきではありません。

1番目のスプレッドシート出力から始めてください。 見た目は素朴ですが、指摘が消えず、後から集計もできます。

人が確認する

全件、人が判断します。指摘を自動で反映しません。

理由は2つあります。第一に、表記ルールには意図的に外す場合があるためです。他社の正式名称、引用文、キャンペーンの表記など、ルールに反するが直してはいけない箇所があります。第二に、AIの指摘には誤りが混ざるためです。

判断を速くするための設計が重要です。

• severity の順に並べる。must から見る
• 同じ rule_id の指摘をまとめて表示する（同じ直し方を連続で処理できる）
• 「無視する」を選んだ指摘を記録し、次回から同じ箇所を指摘しない
• 1本あたりの指摘件数を表示する。20件を超えたら、ルールの書き方を疑う

最後の項目が運用の目安になります。指摘が多すぎるのはAIの精度の問題ではなく、ルール一覧に「好みの問題」が混ざっているサインです。

例外に対処する

記録を残す

• 原稿の版（チェックした時点の本文）
• AIが返した指摘の全件（捨てたものを含む）
• 担当者が「直した」「無視した」のどちらを選んだか
• 1本あたりの指摘件数と、書いた人

最後の2つが、この構成のいちばんの副産物です。 「無視された指摘」が多い項目は、ルールとして機能していません。「書いた人ごとの指摘傾向」が分かれば、ライターへのフィードバックが「前回も言った」から「この3項目が多い」に変わります。

個人の評価に使わないでください。指摘件数を人事評価に結びつけると、書き手はチェックを通さなくなります。