【ITニュース解説】My DOCX converter learned that 'bold' is a negotiation, not a fact

Word文書（DOCX）形式のデータをプログラムで処理したり、別の形式に変換したりする作業は、見た目以上に非常に複雑で困難を伴う。多くの人が、PDF文書よりWord文書の方が構造が単純だと考えがちだが、実際はその逆で、Word文書は見た目の情報と内部の構造が大きく異なることがあるため、開発者は多くの「落とし穴」に遭遇する。

例えば、文書内で文字を「太字」にするという、ごく基本的な書式設定一つをとっても、Wordの内部では複数の設定箇所が存在し、これらが複雑に絡み合っている。プログラムがWord文書を解析する際、単純に「この部分は太字か？」と問い合わせても、期待する結果が得られない場合があるのだ。最初の段階では、python-docxのようなライブラリを使って、直接「太字」と設定されているかどうか（run.boldプロパティ）を確認していたが、ある法律事務所が作成した契約書を変換しようとしたところ、文書全体がプレーンテキストとして出力されてしまった。その原因は、その文書が「Strong」や「Emphasis」といった「文字スタイル」を使っていたためだった。これらのスタイルは視覚的には太字や斜体に見えるが、プログラムが直接の太字設定を問い合わせても「設定されていない」と返答してしまう。つまり、Wordには書式設定に関する「唯一の真実」があるわけではなく、少なくとも四つの異なる情報源（直接のプロパティ、文字スタイル、段落スタイル、文書のデフォルトスタイル）が互いに影響し合い、時には競合しているのだ。

このような複雑さに対応するためには、書式設定の確認方法を多段階にする必要がある。まず直接の文字プロパティを確認し、次に文字スタイル、その次に段落スタイル、最後に文書全体のデフォルトスタイルを見るという「フォールバックチェーン」（優先順位の低い設定を段階的に確認していく仕組み）を導入するのだ。さらに、通常の太字設定（w:b）と、アラビア語などの複雑なスクリプト言語向けの太字設定（w:bCs）が別々に存在する点も考慮しなければならない。また、テンプレートによっては、親のスタイルから継承されるはずの斜体設定を、明示的に「斜体にしない」（w:iをfalseに設定）と上書きしているケースもあり、これら全てを正確に処理する必要がある。

書式設定のもう一つの大きな課題は「見出し」の判別だ。Word文書では通常、「見出し1」「見出し2」といったスタイル名で見出しが表現される。しかし、デザイナーによっては、これらの見出しスタイルをカスタマイズして、見た目をまるで本文のように見せる場合がある。この場合、スタイル名だけを信用して見出しを判断すると、誤った構造で文書が変換されてしまう。そこで、プログラムはスタイル名ではなく、Wordの内部で段落ごとに設定されている「アウトラインレベル」（w:outlineLvl）という情報を確認する必要がある。このアウトラインレベルが「0」に設定されていれば、たとえフォントサイズが本文と同じであっても、それは間違いなく見出しとして扱うべきなのだ。

文書の構造の中でも、特に複雑なのが「テーブル」だ。Wordのテーブルは、テーブルの中にさらにテーブルが入れ子になっていたり、複数のセルが縦方向や横方向に結合（マージ）されていたり、テキストが全く含まれずに空の段落だけが入っているセルがあったりと、非常に多様な構造を持つ。python-docxのようなライブラリを使っても、視覚的に人間が見ているようなテーブルの構造、特に結合されたセルの情報を正確に把握できない場合がある。例えば、ライブラリのcell.textプロパティが結合領域について誤った情報を示すことがあるため、開発者はWord文書の元となるXMLデータ（w:vMergeやw:hMergeといったタグ）を直接解析し、どのセルがどのように結合されているかを突き止める必要に迫られる。

これらの経験から得られる教訓は、Word文書（DOCX）は、内部の構造がどうであれ、ユーザーに見せる「見た目」を最優先する「プレゼンテーション形式」であるということだ。もしDOCXファイルを例えば大規模言語モデル（LLM）が理解しやすい形式に変換しようとするならば、スタイル名のような表面的な情報は信用してはならない。代わりに、文書の論理的な構造を示す「アウトラインレベル」、直接設定された書式、そして文書の基盤となる「生のXML階層」といった、より根源的な情報を信頼し、深く解析する必要がある。なぜなら、Wordのユーザーは、標準的な「本文」スタイルを使っているにもかかわらず、手動でフォントサイズを28ポイントにして太字にし、それをタイトルとして使うような、プログラムが想定しない自由な使い方を平気でするからだ。変換ツールは、このようなユーザーの多様な使い方にも耐えうる頑丈さを持っていなければならない。

このような多くの課題を克服し、Word文書（DOCX）のURLやバイナリデータを受け取り、見出し、リスト、テーブルといった構造を正しく保持したクリーンなMarkdown形式に変換するAPIが開発された。これは、DOCX形式の複雑さと格闘した結果生まれた、実用的なソリューションだと言える。