取扱説明書を改訂したときに、旧版との差分と表記のゆれを出荷前に点検する

処理の起点を決める

改訂版が所定のフォルダに置かれたときを起点にします。

最小構成では、担当者が2つのファイルを生成AIの画面に投げる運用で足ります。月24件なら、トリガーを自動化する価値は小さく、点検の中身を作り込むほうが効果が大きいからです。

入力データを集める

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

テキストの取り出し： Wordファイルからは python-docx で段落と表を取り出せます。このライブラリは .docx を対象とし、段落・書式・表・セルを扱えます。見出し・段落・表のどこに書かれていたかを保持したまま取り出してください。 ただの文字列にすると、指摘に「何ページの何行目か」を付けられません。

変更履歴が残っている場合： Wordの変更履歴は、挿入された部分が w:ins（Inserted Run Content）、削除された部分が w:del（Deleted Run Content）として文書のXMLに記録され、w:author と w:date の属性で誰がいつ変えたかも分かります。変更履歴が残っているなら、差分を計算するより正確です。 ただし残っていないことが多いので、差分計算も必ず用意します。

表記ルールと用語集： 文書として持っているものをそのまま渡します。ルールが文書になっていない場合は、まずそれを作ってください。 この仕組みの精度は、ルールがどれだけ具体的に書かれているかで決まります。

AIへ渡す前に整形する

1. 段落の対応づけ … 旧版と新版の段落を、見出しの構造を手がかりに対応づけます。章が増減すると単純な行の突き合わせは崩れます
2. 表の扱い … 表はセル単位で比べます。行が増えただけで表全体が「変更」になると、指摘が読めなくなります
3. 変更のない箇所の除外 … 全文を生成AIに渡さず、変更箇所とその前後の段落だけを渡します。ただし「変更された用語の全文検索」は、機械で全文に対して行います
4. 図版の扱い … 図の中の文字は取り出せません。図の差し替えがあったかどうかだけを検出し、中身の点検は人に回します

AIに処理させる

差分計算と生成AIで役割を分けます。

差分計算（Python）にさせること： どこが変わったかの特定と、変更された用語・数値が他の箇所に残っていないかの検索。ここは生成AIにさせません。 「この語が文書内にあと3か所ある」は検索で確実に分かります。生成AIに探させると見落とします。

生成AIにさせること：

指示内容を固定する

あなたは技術文書の校正を担当する校閲者です。
改訂前後の差分を見て、社内の表記ルールと用語集に照らした指摘を作ってください。

【厳守事項】
- 指摘は必ず、該当する文をそのまま引用して示してください。
  引用のない指摘は出さないでください。
- どのルールに違反しているかを、ルール名または用語集の項目名で示してください。
  「読みにくいから」といった理由での指摘はしないでください。
- 技術的な内容の正誤を判断しないでください。
  数値や仕様が正しいかは技術部が判断します。
  「旧版と値が違う」という事実だけを書いてください。
- 文章を書き直した全文を返さないでください。
  指摘と、直し方の案（1行）だけを返してください。
- 変更されていない箇所について、新たな指摘を出さないでください。
  旧版から残っている表記ゆれの指摘は、別の欄に分けてください。

【表記ルール】
{style_rules}

【用語集】
{glossary}

【変更箇所の差分】
{diff_blocks}

【変更された用語が残っている他の箇所】
{residual_hits}

「変更されていない箇所に新たな指摘を出さない」の1行が重要です。 これを入れないと、120ページの文書全体について何百件もの指摘が返ります。今回の改訂で見るべきなのは、変更箇所と、変更の影響を受ける箇所だけです。

出力形式を固定する

Claude API の structured outputs でJSONスキーマを指定します。

{
  "document_id": "",
  "revision": "",
  "findings": [
    {
      "location": "",
      "quote": "",
      "type": "表記ルール | 用語 | 旧仕様の残り | 数値の不一致 | 訳抜け | 図の差し替え",
      "rule_name": "",
      "suggestion": "",
      "severity": "high | medium | low"
    }
  ],
  "pre_existing_issues": [],
  "unchanged_in_english": [],
  "figures_changed": [],
  "needs_human_check": []
}

pre_existing_issues（もともとあった問題）を分けているのが要点です。 今回の改訂で入った誤りと、前からあった表記ゆれを混ぜると、技術部に戻す指摘が膨らんで、いちばん重要な「旧仕様の残り」が埋もれます。

システムへ連携する

出力先は3通りあります。

まずは1つめで十分です。 コメント挿入は便利ですが、位置の特定を誤ると別の箇所にコメントが付き、かえって混乱します。

本文の自動修正はしません。 技術文書の文言を機械が書き換えると、承認の記録が誰のものか分からなくなります。

人が確認する

指摘は全件、人が確かめてから技術部に戻します。

理由は、表記ルールには例外があるためです。「原則として単位はSI単位系を使う」と書かれていても、顧客の指定で慣用単位を併記している箇所があります。ルールだけで判定すると、こうした意図的な例外まで指摘されます。

確認を速くするための設計が重要です。

• 一覧で、該当文の引用とルール名を必ず横に並べる
• type: 旧仕様の残り を先頭に置く。これがいちばん重い誤りです
• pre_existing_issues は折りたたんで、別の機会に回せるようにする
• 同じルールに対する指摘をまとめて表示する（1つ判断すれば全部片づく）

例外に対処する

記録を残す

• 点検の実行日時と対象の版
• 指摘の一覧（採用したもの・しなかったものの両方）
• 技術部が直した箇所と、直さなかった箇所
• 人が「これは指摘しなくてよい」と判断した理由

最後の項目を残すと、表記ルールの例外リストが育ちます。同じ指摘を毎回消す作業がなくなります。

技術文書には未公開の製品情報が含まれます。発売前の製品の説明書を扱う場合は、保管場所とアクセス権限を厳しく設定してください。