複数人で書いた文書の表記ゆれをAIで統一する:用語辞書を作ってから直す流れ
AIを使いこなす執筆にClaudeを使用しています。

複数人で書いた文書の表記ゆれは、AIに「統一して」と頼む前に、表記の辞書を作り、その辞書どおりに直させるほうが安全です。「サーバー」と「サーバ」のどちらを採るかは会社や文書ごとの決めごとです。AIに任せると、全体は揃っても自社のルールとは違う結果になりかねません。 進め方は次の3段階です。 1. AIに表記ゆれの候補を一覧にさせるだけにする(直させない) 2. 人が一覧を見て採用する表記を決め、辞書にする 3. 辞書をAIに渡し、辞書にある変更だけを適用させ、変更ログを出させる 辞書のひな形と、手順1・3の依頼文を載せます。サンプルの語や文章はすべて説明用の例です。依頼文は、この記事のために実際に動かして確かめたものではありません。ご自身の文書で少量から試し、結果を確認してから広げてください。
先に辞書を作る理由と、AIに任せる範囲
AIは、長い文書から「同じ意味で書き方が違う語」を拾う作業や、決まった規則を当てはめる作業に向いています。一方、どちらを正とするかは読者・業界・社内慣習で決まるため、人が決めます。
- 表記ゆれ候補の洗い出し、担当:AI(見落としはある前提で、人も目を通す)
- 採用表記の決定、担当:人
- 例外条件の記入、担当:人(AIが案を出してもよい)
- 辞書の適用と変更ログ作成、担当:AI(辞書にない変更はさせない)
- 変更内容の最終確認、担当:人
社内に基準がなければ、公的文書の指針がたたき台になります。文化審議会は2022年1月7日に、昭和26年の「公用文作成の要領」に代わる手引として「公用文作成の考え方」を建議しました。横書きの読点は「、」を原則とする、といった考え方が示されています(文化庁「文化審議会建議『公用文作成の考え方』について」)。ただし公用文向けの指針であり、民間の社内文書に適用する義務はありません。
ステップ1:表記ゆれの候補を洗い出す
最初の依頼では原稿を直さないことを明記します。修正版を出させると、人が決める前に変更が入ってしまうからです。
用意するのは、複数の担当者の文章をつなげた原稿と、あれば社内の表記ルールの抜粋です。社名・人名・金額などの機密情報は、架空の語に置き換えます。AIに渡してよい情報かどうかは、自社の情報管理ルールに従って判断してください。
ファイルで渡す場合、Claudeのヘルプでは、チャットにPDF、DOCX、CSV、TXTなどをアップロードでき、プロジェクトに置くファイルは内容がコンテキストウィンドウに収まる必要があるとされています(Upload files to Claude)。対応形式や上限は変わることがあるため、最新のヘルプで確認してください。長い文書は章ごとに分け、辞書は全章で同じものを使います。
依頼文(説明用の例)
あなたは日本語の校正担当です。以下の【原稿】にある表記ゆれの「候補」を一覧にしてください。
この段階では原稿を修正しないでください。
# 拾ってほしいもの
- 同じ意味で書き方が違う語(例:サーバー/サーバ)
- 送り仮名・ひらがな/漢字の揺れ(例:問い合わせ/問合せ)
- 数字・単位・記号の揺れ(例:全角/半角、2桁/二桁)
- 同じ対象を指す呼び方の揺れ(例:お客様/顧客/ユーザー)
# 出力形式(表)
| 語のグループ | 見つかった表記 | 出現回数(概算で可) | 出現箇所の例(前後10字程度) | 意味が違う可能性 |
# 守ること
- 固有名詞、引用、コード、URLは候補に入れず、別枠で「除外した箇所」として挙げる
- 意味が違う可能性がある語は、統一してよいか分からないと明記する
- 推測で「正しい表記」を決めない。推奨案を出す場合は「案」と書き、理由を添える
【原稿】
(ここに原稿を貼る)出現回数は「概算で可」としています。AIの数え上げは正確とは限らないため、優先順位をつける目安として見ます。
ステップ2:辞書を決める
候補の表が返ってきたら、人が1行ずつ採否を決めます。迷ったときは、次の順で判断します。
- 自社・取引先の既存ルールや、製品の公式表記があるか(製品名は公式表記を最優先)
- 読者が検索・照合する語か(画面上のボタン名と本文を揃える)
- 文書の種類(契約・社外向け・社内メモ)で基準が違うか(契約条文は原文を変えない)
- 上のどれでも決まらなければ、出現が多いほうを採用する
4番は、修正箇所を減らすための編集上の割り切りです。1〜3番に当てはまる語は、多数派かどうかで決めないでください。
表記ゆれ辞書のひな形
スプレッドシートに貼れる形です。行の内容はすべて説明用の例で、実在の社内ルールではありません。
- T001、区分:外来語、採用表記:サーバー、直す対象(ゆれ):サーバ、適用条件・例外:製品名・引用中は変更しない、決めた理由:長音ありに統一、決定者:(氏名)
- T002、区分:用語、採用表記:問い合わせ、直す対象(ゆれ):問合せ、問い合せ、適用条件・例外:ボタン名「お問合せフォーム」は画面表記に合わせ変更しない、決めた理由:名詞は送り仮名を付ける方針、決定者:(氏名)
- T003、区分:用語、採用表記:利用者、直す対象(ゆれ):お客様、顧客、適用条件・例外:「契約者」を指す文は変更しない、決めた理由:契約前後を区別するため、決定者:(氏名)
- T004、区分:表記、採用表記:ください、直す対象(ゆれ):下さい、適用条件・例外:「物をくれる」意味の「下さい」は変更しない、決めた理由:補助的な用法はひらがなに統一、決定者:(氏名)
- T005、区分:記号、採用表記:、、直す対象(ゆれ):,、適用条件・例外:英数字の桁区切りは変更しない、決めた理由:横書きでも読点は「、」にする方針、決定者:(氏名)
「適用条件・例外」列が一番重要です。T003のように、一見同じ意味でも別の対象を指す場合があります。この列を空欄にしたまま適用すると、機械的な置換で意味が変わります。「決定者」列は、あとで判断が割れたときに誰に戻すかを残すためのものです。
ステップ3:辞書を適用させる
辞書ができたら、原稿と一緒に渡します。同じ辞書を繰り返し使うなら、プロジェクトに辞書ファイルを置く方法もあります。ヘルプには、プロジェクトにアップロードした資料はキャッシュされ、再び参照するときにキャッシュされている間は、新しい内容より使用量への影響が小さい、という趣旨の説明があります(Usage limit best practices)。ただ、毎回チャットに貼る方法でも作業はできます。
依頼文(説明用の例)
以下の【辞書】に従って、【原稿】の表記を統一してください。
# ルール
- 辞書の「直す対象」にある表記だけを、「採用表記」に直す
- 「適用条件・例外」に当てはまる箇所は変更しない
- 辞書にない変更(言い回し、文体、事実、数値の変更)は一切しない
- 迷った箇所は直さず、「要確認」として別に挙げる
- 辞書にない表記ゆれは直さず、「辞書に追加する候補」として挙げる
# 出力(この順で)
1. 修正後の本文
2. 変更ログ(表):| 辞書ID | 変更前(前後10字程度) | 変更後 |
3. 要確認の箇所
4. 辞書に追加する候補
【辞書】
(ステップ2の表を貼る)
【原稿】
(ここに原稿を貼る)出力の3・4がポイントです。辞書にないが気になる箇所を、直さずに別枠で出させると、辞書を育てる材料になります。
人が確認することと、うまくいかないとき
AIが返した本文は、そのまま確定せず、次の順で確認します。
- 差分を機械的に比べる:原稿と修正後の本文を、Wordの文書比較機能やテキスト比較ツールで突き合わせ、変更ログとずれがないかを見ます。AIが自己申告した修正件数は、検証には使いません。
- 変更ログを抜き取りで確認する:辞書ID別に数件ずつ、文脈で意味が変わっていないかを見ます。T003のように例外条件のある行は重点的に見ます。
- 除外したはずの箇所を確認する:固有名詞、引用、URL、条文などが変わっていないか、検索で確かめます。
- 「要確認」と「追加候補」を人が決め、辞書に反映する。
うまくいかないときは、症状から見直す箇所を探します。
- 意味が変わってしまった語がある、見直す箇所:辞書の「適用条件・例外」を追記して再実行
- 辞書にない箇所まで直される、見直す箇所:「辞書にない変更は一切しない」を依頼文の冒頭近くに移し、変更ログを必須にする
- 後半で適用が甘くなる、内容が欠ける、見直す箇所:章ごとに分け、同じ辞書で繰り返す
- 担当者ごとに辞書の解釈が割れる、見直す箇所:「決定者」と理由を確認し、決めた人に戻す
辞書を最初から完璧にしようとすると進みません。まず10〜20行の小さな辞書で数ページを直し、変更ログと「追加候補」から育てていくほうが続きます。

