業務文書の校正にAIを使うなら、比べるべきは「誤字をどれだけ見つけるか」ではありません。自社の表記ルールと社内用語を外から渡せるか、そしてその文書をどこへ送ることになるか——この3点で実用性がほぼ決まります。誤字脱字の検出は多くのツールで一定水準に達しており、差がつくのはむしろ、社名・製品名・略語といった「そのツールが知らない言葉」をどう扱うかの部分です。
本記事では、AIを使った文章校正を業務システムに組み込む立場から、方式ごとの違い、表記統一の実装方法、機密文書を扱うときの確認点、そして実装で詰まりやすい箇所を整理します。
AI校正ツールは何を比べればいい？
校正の仕組みは大きく3通りに分かれます。それぞれ得意な領域が違うため、「どちらが優秀か」ではなく「どの工程に置くか」で考えます。
| 方式 | 仕組み | 得意なこと | 苦手なこと |
|---|---|---|---|
| ルールベース校正 | 辞書と文法規則で機械的に照合する | 表記ゆれ、送り仮名、禁止語の検出。結果が毎回同じ | 文脈依存の誤り、不自然な言い回し |
| LLM（大規模言語モデル。大量の文章を学習した言語生成AI） | 文全体を読んで書き換え案を出す | 読みにくい文の整理、敬語、論理の飛び | 結果が毎回ぶれる。指示しない箇所まで直す |
| 併用 | ルールで機械判定し、残りをLLMに回す | 統一は確実に、表現は柔らかく | 構成が複雑になり、保守の手間が増える |
重要なのは再現性です。表記統一は「昨日は直されたのに今日は直されない」が起きると信頼を失います。社内規程や契約書のように一字一句を揃えたい文書ほど、ルールベースの比重を上げる設計が向いています。逆に、顧客向けの提案文や社内報のように読みやすさが主目的なら、LLMの提案力が効きます。
表記の統一はどう持ち込む？
「弊社の表記ルールに合わせてほしい」という要望は、実装としてはルールを文章ではなく、機械が読める形で持つことに尽きます。プロンプト（AIへの指示文）に「表記ルールは以下の通り」と数十行書き足す方法は、項目が増えるほど守られなくなります。
実務では次の順で整理します。
- 機械判定できるルール（「御社→貴社」「ユーザー（長音あり）」「お客様の『様』は漢字」など、置換で片づくもの）は辞書に入れ、ルールベースで処理する
- 判断が要るルール（一文の長さ、受け身の多用、二重敬語など）をLLMに任せる
- 例外（引用部分、法令の条文、外部から受け取った原文）は校正対象から除外する範囲を先に決める
ゼロから表記基準を作る必要はありません。日本翻訳連盟が公開している「JTF日本語標準スタイルガイド」や、文化審議会の建議「公用文作成の考え方」は、送り仮名・記号・数字の扱いなどが整理されており、自社ルールの土台として参照できます。これらをベースに、自社固有の差分だけを追加する形にすると、辞書の保守量が現実的な規模に収まります。
なお、プロンプトに書いたルールは時間とともに肥大化し、誰がいつ何を足したのか分からなくなりがちです。校正ルールもコードと同じく変更履歴を残す対象として扱うべきで、この考え方はプロンプトは設定ではなく資産 — 「壊れたら戻せる」AI業務システムの作り方で詳しく触れています。
社内用語はなぜ直されてしまう？
校正AIを入れた直後によく起きるのが、正しい社内用語を「誤り」と判定されてしまう現象です。原因ははっきりしていて、そのツールが自社の固有名詞を知らないからです。たとえば次のような場面です。
- 自社製品名「ロジクセル受発注」の「受発注」を「発注受付」に書き換えられる
- 社内略語「PJ台帳」を「プロジェクト台帳」に展開され、システム上の正式名称と食い違う
- 取引先の社名表記「㈱」「(株)」「株式会社」の揺れを、契約書の正式表記まで統一してしまう
対策は三つあります。第一にユーザー辞書——固有名詞を登録し、校正対象から外す、または指定表記に固定する機能があるかを確認します。第二に用語集の外部管理——用語をツール内の画面でしか編集できないと、部署ごとの更新が滞ります。表計算ファイルやテキストで持ち込め、まとめて取り込める形が望ましいです。第三に禁止語リスト——「絶対」「必ず」「完全」のように、広告表示や品質保証の観点で使わないと決めた語を検出させる用途です。
用語の統一をAIに守らせる設計は、翻訳の分野で先に議論が進んできた領域でもあります。考え方の共通部分は翻訳AIは用語統一で選ぶ — 翻訳サービスとLLMの違いが参考になります。
機密文書を校正に通してよいか、どう確認する？
校正にかける文書は、契約書、見積書、人事評価、顧客への謝罪文など、機微な内容が多くなります。ここは導入可否を左右する部分なので、確認項目を先に固めておきます。
| 確認項目 | 見るべき点 |
|---|---|
| 送信先 | 自社内で処理するか、国内のクラウドか、海外のサーバーか |
| 学習への利用 | 入力した文章がモデルの再学習に使われるか。使わない設定（オプトアウト）が既定か、申請制か |
| 保存期間 | 入力文と出力文がどれだけ保持されるか。不正利用監視のために一定期間残る場合がある |
| 再委託 | 提供事業者がさらに別の基盤事業者を使う場合、その範囲が契約書に書かれているか |
| 利用者単位の分離 | 部署や案件ごとにアクセス範囲を分けられるか。全文書が全社員から見える状態になっていないか |
個人情報を含む文書を外部サービスに渡す場合は、個人情報保護法上の委託や第三者提供の整理が必要になります。また、経済産業省と総務省が取りまとめた「AI事業者ガイドライン」では、AIを利用する事業者に対してデータの取り扱いや透明性の確保が求められており、社内規程を作る際の参照先になります。詳細な該当条文や要件は、自社の契約形態によって結論が変わるため、顧問の専門家に確認する前提で進めるのが安全です。
運用面では、「そもそも渡さない」仕組みを先に置くと話が早くなります。校正画面に機密区分の選択を必須にし、最高区分の文書は社内処理に回す、あるいは送信前に検知して止める、といった設計です。この入口側の作り込みについてはAIに渡せない入力を止める手順 — 判定・遮断・案内の設計で整理しています。
実装で詰まりやすいのはどこ？
受注開発の現場で手が止まりやすいのは、校正エンジンそのものより周辺です。
1. 差分の見せ方
LLMは修正後の全文を返してくることが多く、どこが変わったのかが分かりません。元文と出力を差分表示する処理を自前で用意し、1箇所ずつ採用・却下できる画面にしないと、担当者は結局全文を読み直すことになり、工数が減りません。
2. 書式の消失
Word文書やPDFから本文だけを抜き出して校正にかけると、太字・表・見出しの情報が落ちます。戻すときに書式が崩れると、校正より復旧に時間がかかります。対象を「プレーンテキストで扱う文書」に絞るか、書式を保持したまま本文だけ差し替える処理を設計段階で見込んでおきます。
3. 指示していない箇所まで直される
「誤字だけ直して」と頼んでも、LLMは文体や語順まで整えてしまうことがあります。修正種別（誤字・表記ゆれ・敬語・読みやすさ）を分けて出力させ、採用する種別を利用者が選べるようにするのが現実的です。
4. 改善したかどうかが分からない
プロンプトや辞書を調整したあと、「前より良くなった気がする」で終わってしまうケースが少なくありません。自社の文書から数十件を抜き出し、正解の修正結果を人手で作った検証用のデータを持っておくと、調整のたびに同じ基準で比較できます。考え方はAI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用にまとめています。
5. 最終責任の所在
AIが通した文書でも、外部に出る以上は人の確認が要ります。「AIが指摘しなかったから問題なし」とする運用にすると、見落としの責任が宙に浮きます。校正は人の確認を省く道具ではなく、確認の精度を上げる道具として位置づけ、承認フローは残しておく方が無難です。
まとめ
AI校正を業務文書に使うときの判断軸を整理します。
- 表記の統一は、機械判定できるルールを辞書として外に出し、判断の要る部分だけをLLMに回す。既存のスタイルガイドを土台にし、自社の差分だけ足す
- 社内用語は、ユーザー辞書への登録と、用語集を外部ファイルで保守できるかを確認する。固有名詞を「誤り」と判定されると現場の信頼を一気に失う
- 機密の扱いは、送信先・学習利用・保存期間・再委託・アクセス分離の5点を契約書で確認し、そもそも渡さない入口設計を併せて用意する
- 実装では、差分の見せ方、書式の保持、修正種別の切り分け、効果測定の仕組み、承認フローの維持が落とし穴になりやすい
校正AIは、導入しやすく効果も見えやすい領域です。だからこそ「とりあえず試す」から始めても構いませんが、本番の業務に乗せる段階では、ルールと用語をどこに置くか、文書をどこへ送るかを先に決めておくと、後からの作り直しを避けられます。