【業務効率化】wordの構造を理解し、複数のdocxファイルの表記ゆれやバラバラな体裁を一気に修正する

久しぶりの投稿となります。また、少しずつ投稿再開していきますので、よろしくお願いいたします。

今回は、章ごとに担当者が分かれた設計書を1つのWord文書にマージしたとき、体裁がバラバラになってしまう問題を、docxファイルの内部構造から解きほぐしていきます。

構築案件で設計フェーズの際、基本設計書や手順書を章単位で分担して作成し、最後に1つの文書へまとめる場面がよくあります。ところが、いざ結合してみると、見出しのフォントや番号の振り方、表の罫線、「サーバ」と「サーバー」といった表記が章ごとに違っていて、直すだけで半日つぶれてしまった、という経験を持つ方も多いのではないでしょうか。

実は、この「バラバラ」はWordの内部では起こるべくして起きている現象です。docxファイルはZIP形式で圧縮されたファイルで、展開するとXMLファイルが並んでいます。どのファイルが何を担っているかを知っておくと、「なぜ崩れるのか」と「どこを揃えれば一括で直るのか」が見えてきます。

この記事では、インフラエンジニアの方に向けて、次の3点を整理します。

• docxを展開したときのファイル構成と、主要ファイルの役割
• マージ時に体裁や表記がバラバラになる仕組み
• 表記ゆれの修正と、スタイル定義の考え方を使った作成ポリシーの統一

docxの正体はZIPファイル：展開して中身を見てみよう

拡張子が.docxのファイルは、Office Open XMLという形式で作られたZIPアーカイブです。確認する方法は簡単で、元ファイルをコピーして拡張子を.zipに変えて展開するか、7-Zipなどの圧縮ソフトで直接開きます。Linuxであればunzipコマンドでも展開できます。元のファイルは壊さないよう、必ずコピーに対して操作してください。

展開すると、おおむね次のような構成になります。ヘッダーや画像、コメントなどは、文書内で使っている場合にだけ現れます。

sample.docx（展開後）
├─ [Content_Types].xml
├─ _rels/
│   └─ .rels
├─ docProps/
│   ├─ core.xml
│   └─ app.xml
└─ word/
    ├─ document.xml
    ├─ styles.xml
    ├─ numbering.xml
    ├─ settings.xml
    ├─ fontTable.xml
    ├─ theme/
    │   └─ theme1.xml
    ├─ header1.xml / footer1.xml
    ├─ media/（画像）
    └─ _rels/
        └─ document.xml.rels

見た目はWordで開いたときの1つの文書でも、内部では「本文」「スタイル定義」「番号定義」「設定」が別々のファイルに分かれて管理されている、という点がポイントです。

主要ファイルの役割：体裁を決めているのは3つのファイル

展開したファイルのうち、設計書の体裁統一に関わるものを役割ごとにまとめます。

本文の見た目を決める要素は、実質的に document.xml、styles.xml、numbering.xml の3つです。次の章では、この3つがマージ時にどう食い違うのかを見ていきます。

なぜ章ごとに体裁がバラバラになるのか

原因は大きく3つに整理できます。

1. スタイルと直接書式が混在している document.xmlの中では、段落が「見出し1」のようなスタイル名を参照しているだけの場合と、段落や文字に直接フォント・サイズ・色を指定している場合があります。画面上では同じ見た目でも、中身は別物です。担当者が見出しを「太字＋大きい文字」で自作していると、目次に出てこず、あとからスタイル定義を変えても追従しません。
2. スタイル定義が文書ごとに違う docxは1ファイルごとに自分専用のstyles.xmlを持っています。同じ「見出し1」という名前でも、フォントや余白、行間の定義は担当者のファイルごとに違うことがあります。結合するときの方法によって、結合先の定義に揃うこともあれば、元の見た目を保つために直接書式へ置き換わったり、名前の似たスタイルが増えたりします。
3. 番号の定義も文書ごとに独立している 章番号や箇条書きの番号は、各ファイルのnumbering.xmlで管理されています。結合すると、章ごとに番号がリセットされたり、別の番号体系のまま引き継がれたりして、「3章の次が1章から始まる」といった状態になりがちです。

つまり、手作業で見た目を1つずつ直すより、「どのスタイルが使われているか」を揃えるほうが近道です。スタイルに任せる状態にしておけば、定義を変えるだけで全章に反映されます。

表記ゆれを一括で直すための考え方

設計書でよく見かける表記ゆれには、次のようなものがあります。

• 長音の有無：サーバ／サーバー、ユーザ／ユーザー、ブラウザ／ブラウザー
• 全角と半角：英数字、括弧、スペース、半角カナ
• 漢字とひらがな：出来る／できる、下さい／ください
• 製品名や略称の大文字小文字：Linux／linux、Windows Server／WindowsServer

最初にやるべきなのは、置換する前に自社やプロジェクトの表記ルール（用語統一表）を決めておくことです。どちらが正しいかではなく、どちらに揃えるかを先に決めておけば、あとは置換リストとして機械的に処理できます。

XMLを直接検索すると見つからない理由

document.xmlを開いてテキストエディタで「サーバ」を検索しても、ヒットしないことがあります。見た目は一続きの文字でも、書式の違いや校正記号、編集履歴の識別子の違いによって、内部では複数の文字列のかたまり（run）に分割されていることがあるためです。「サ」「ーバ」のように分かれていると、単純な文字列検索やsedでは拾えません。

そのため、本文の表記ゆれは、runの分割を意識せずに検索できるWordの置換機能で行うのが安全です。XMLの構造を知っておくと、「検索したのに残っている」ときの原因が分かり、確認作業にも役立ちます。

置換で事故を起こさないための注意点

• 二重置換に注意する：「サーバ」を「サーバー」に置換すると、すでに「サーバー」となっている箇所が「サーバーー」になります。Wordのワイルドカード検索で「サーバ([!ー])」を「サーバー\1」に置換するなど、直後が長音でないものだけを対象にします。
• インフラ設計書では置換してはいけない箇所がある：コマンド、パラメータ名、ホスト名、設定ファイルの記載、ログの引用文などは、表記ゆれに見えても原文のまま残す必要があります。
• 「すべて置換」の前に件数を確認する：想定より件数が多いときは、置換対象に意図しない語が含まれていないかを見直します。
• 作業前に元ファイルをバックアップする：結合済みの文書を直接編集せず、必ずコピーで作業します。

XMLを直接置換するメリットと使いどころ

本文テキストの置換だけなら、Wordの置換機能のほうが安全です。それでも、XMLを直接扱うメリットが出る場面があります。

• 大量のファイルを一括処理できる：章ごとに分かれた数十のdocxに同じ置換リストを適用するとき、スクリプトで自動化できます。1ファイルずつWordで開く必要がありません。
• Wordが入っていない環境でも実行できる：Linuxサーバーや定期実行のジョブ上で、展開、置換、再圧縮までを回せます。
• 置換の再現性と記録が残る：置換リストとスクリプトをバージョン管理すれば、何をどう直したかを後から追えます。
• Wordの置換では届かない箇所を触れる：styles.xmlのフォント指定、numbering.xmlの番号定義、docPropsの作成者情報などは、Wordの検索と置換の対象外です。
• 差分で確認しやすい：展開前後のXMLをdiffで比べれば、変更箇所を機械的に確認できます。

一方で、runが分割されていると単純な置換では拾えないこと、XMLや再圧縮の手順を誤るとWordで開けなくなることがデメリットです。目的に応じて、次のように使い分けます。

スタイル定義の考え方で作成ポリシーを統一する

styles.xmlは、いわばスタイルの辞書です。「見出し1」「標準」「表のスタイル」などがそれぞれ定義されていて、document.xmlの各段落は、そのスタイルのIDを参照して見た目を決めています。さらに、文書全体の既定のフォントやサイズも、同じファイルの既定値として持っています。

フォントの指定は、日本語用と英数字用が別々の属性になっています。「日本語は○○、英数字は△△」というポリシーを決めている場合、スタイル側でこの2つを揃えて定義していないと、章ごとに英数字だけフォントが違って見える、という現象が起きます。

作成ポリシーを統一する進め方は、次のとおりです。

1. 基準になるスタイル定義を1つ決める：マージ先のファイル、またはテンプレートを「正」とし、見出し1〜3、本文、表、箇条書きの定義を確定させます。
2. 各章の直接書式を外す：結合した文書で書式のクリアを行い、すべての段落に正しいスタイルを適用し直します。
3. 見た目の調整はスタイル側で行う：フォント、サイズ、行間、余白を変えたいときは、段落を1つずつ直さず、スタイルの定義を修正します。
4. 章番号は見出しスタイルと紐付けた多段リストで一元管理する：番号定義を1つに集約すれば、章ごとのリセットや連番ずれを防げます。

ポイントは、見た目を直すのではなく、スタイルに任せられる状態に戻すことです。この状態にしておけば、次に表記ルールが変わったときも、スタイル定義の修正だけで全章に反映できます。

styles.xmlを直接編集するメリットと注意点

Wordの画面でスタイルを直す方法で足りる場面は多いですが、styles.xmlを直接扱うと有利になるケースもあります。

メリット

• 各章のスタイル定義を結合前に一斉に揃えられる：基準にするファイルのstyles.xmlを各章のdocxへ配れば、スタイル名が同じ段落はすべて基準の定義で表示されます。
• Wordの画面から見えない設定を確認・修正できる：文書全体の既定書式や、日本語用と英数字用で別々に持つフォント指定などを直接確認できます。
• 章ごとの違いを差分で洗い出せる：「見出し1のサイズが3章だけ違う」といった差を、目で探さずにdiffで機械的に見つけられます。
• 多数のファイルやWordのない環境でも処理できる：スクリプト化すれば、数十ファイルでも同じ手順で処理できます。

注意点

• 直接書式は消えない：バラバラの原因が、担当者が手で付けた太字やサイズ指定（document.xml側）なら、styles.xmlを揃えても直りません。本文側の書式クリアが別途必要です。
• 番号定義とセットで差し替える：見出しの章番号はnumbering.xmlと紐付いているため、styles.xmlだけ差し替えると番号が崩れることがあります。
• スタイルIDの一致を確認する：日本語版Wordでは、標準スタイルのIDが「a」になっているなど、英語版と異なる場合があります。異なる環境で作られたファイル同士では、事前にIDを確認します。
• 必ずバックアップを取り、Wordで開いて確認する：編集後は、すべての章をWordで開き直して、見出しと番号の表示を確かめます。

使い分けの目安は、数ファイルの結合ならWordでテンプレートを適用して書式をクリアする方法、数十ファイルの一括処理やWordのない環境、章ごとの定義の違いの調査なら直接編集、と考えると判断しやすくなります。

マージ後の確認チェックリスト（インフラ設計書向け）

結合と体裁統一が終わったら、納品や承認依頼の前に次の項目を確認します。

• 見出し：全章で同じスタイルが使われているか。ナビゲーションウィンドウに階層が正しく表示されるか
• 直接書式：太字や色、フォントサイズを手作業で指定した段落が残っていないか
• 番号：章番号、図表番号、箇条書きの番号が連番になっているか
• 表：表のスタイル、罫線、列幅、見出し行の書式が章ごとに違っていないか
• フォント：日本語と英数字のフォントが全体で統一されているか
• ヘッダー・フッター：ページ番号、文書名、版数が全ページで正しく出ているか
• 目次・相互参照：フィールドを更新して、ページ番号とリンクが最新になっているか
• 表記ゆれ：用語統一表に沿って置換し、コマンドやパラメータなど置換対象外の箇所が崩れていないか
• 変更履歴・コメント：不要な変更履歴やコメントが残っていないか
• 文書プロパティ：タイトルや作成者の情報が、提出先に出してよい内容になっているか

まとめ

章ごとに担当者が分かれた設計書の体裁がバラバラになるのは、担当者の丁寧さの問題ではなく、docxの内部で「スタイル定義」「番号定義」「直接書式」がファイルごとに独立しているために起こる構造的な現象です。

この記事のポイントを振り返ります。

• docxはZIPファイルで、本文はdocument.xml、スタイルはstyles.xml、番号はnumbering.xmlが担っている
• 体裁の崩れは、直接書式の混在、スタイル定義の差、番号定義の重複から生まれる
• 表記ゆれはWordの置換機能で直し、コマンドやパラメータなど置換してはいけない箇所に注意する
• 見た目を1つずつ直すのではなく、スタイルに任せられる状態に揃えると、一括で直せて再発もしにくい

まずは、手元の設計書をコピーして展開し、styles.xmlを開いて「見出し1」の定義を眺めてみてください。内部の仕組みが見えるだけでも、体裁統一の作業の見通しがぐっと良くなりますよ。