PDF vs DOCX：長期保存にはどちらを使うべきか？
この問題は見た目以上に複雑です
ドキュメントの長期保存（アーカイバル）は、単純なことに思えます。フォーマットを選んで、ファイルを保存して、はい終わり、と。しかし、本当の長期保存は単にバイトを保存することではありません。それは、10年後、20年後、あるいは50年後に、人や機械がそのドキュメントを開き、読み、理解できることを保証することなのです。PDFとDOCXはどこにでもあり、広くサポートされていますが、長期保存という点では、どちらも人々がめったに議論しないような深刻な欠陥を抱えています。どちらを選ぶかは、結局のところ、あなたが何を保存しようとしているのか、という点に行き着きます。つまり、ドキュメントの最終的で固定された「見た目」なのか、それとも編集可能な「内容と構造」なのか、です。これらは根本的に異なる目標です。これらを混同することが、ほとんどの長期保存の失敗の根源なのです。法的契約書、公開されたレポート、スキャンされた請求書、そして執筆中の原稿では、それぞれ必要なものが異なります。ソフトウェアのデフォルト形式でただ保存する前に、それぞれのフォーマットが実際に何を保持し、何を捨て去り、そして専門家が何を推奨しているのかを理解する必要があります。
PDFが実際に保存するもの（そして、しないもの）
1993年、AdobeはPDFをある一つの問題を解決するために設計しました。それは、ドキュメントを送信した際に、誰の画面でも全く同じように見えることを保証する、という問題です。PDFはその問題を見事に解決しました。PDFはフォントを埋め込み、ページのジオメトリを固定し、デバイスに依存しない方法で色を指定します。言うことを聞かないプリンターや、エクスポートに失敗したPowerPointと格闘したことがある人なら誰でも、その価値がわかるでしょう。1999年に作られた質の良いPDFを2025年のブラウザで開いても、見た目は同じはずです。この視覚的な忠実さこそ、裁判所や政府、出版社がPDFを採用した理由です。しかし、ここに落とし穴があります。すべてのPDFが同じように作られているわけではないのです。WordからさっとエクスポートしたPDFと、長期保存用に作成されたPDF/A-1bファイルとでは、全くの別物です。PDF/Aファミリー（ISO標準19005）は、PDFのより厳格なサブセットです。埋め込みJavaScript、暗号化、外部フォントへのリンク、複雑な透明効果など、長期的な依存関係を生み出す機能を禁止しています。もしAdobe Acrobat Proをお持ちなら、派手なマーケティング用のPDFをPDF/Aとして保存してみてください。検証プロセスで、おそらく何十ものエラーが検出されるでしょう。根本的なトレードオフはこれです。PDFは「見た目」を保存しますが、「意味」は保存しません。PDF内の表は、多くの場合、グリッド上に配置されたテキスト断片の集まりにすぎません。スクリーンリーダーやデータスクレイピングツールにとっては、それは行と列ではなく、意味不明なデータの羅列に見えます。アクセシビリティやデータ抽出の観点から見ると、通常のPDFは行き止まりなのです。後のPDF/A-2aやPDF/A-3aといった規格では、タグ付き構造を追加することでこの問題を修正しようとしていますが、適切にタグ付けされたアクセシブルなPDFを作成するには、真剣で意図的な努力が必要です。偶然に出来上がることは決してありません。
DOCXが実際に保存するもの（そして、しないもの）
DOCXはXMLベースのフォーマットで、ECMA-376およびISO/IEC 29500として標準化されており、ドキュメントの内容を構造化されたマークアップとしてZIPコンテナ内に保存します。理論上は、これは長期保存に完璧に聞こえます。オープンスタンダード、プレーンなXML、秘密のバイナリコードなし、と。しかし現実には、めちゃくちゃです。DOCXは、PDFが消し去ってしまうセマンティックな（意味的な）構造を保存するのに優れています。「見出し2」のスタイルと、単に大きくて太いテキストとの違いを理解しています。表の構造、変更履歴、コメント、メタデータを保持します。この構造的な情報は、アクセシビリティやデータ処理にとって非常に価値があります。問題はその複雑さです。ECMA-376の仕様書は6,000ページ以上もあります。6,000ページの仕様書は、もはや明確な標準ではありません。さまざまな解釈を招く招待状のようなものです。その結果、全く同じように実装しているアプリケーションは二つとありません。Word 2019で作成したDOCXファイルは、LibreOffice 7.6やGoogleドキュメント、さらにはWord 2013でさえ、表示が崩れることがあります。SmartArtや一部の数式、カスタムXMLバインディングのような複雑な機能は、Microsoftのエコシステムを離れると、しばしば壊れたり消えたりします。それに、フォントの問題もあります。もしあなたのDOCXがCalibriのようなフォントを使っていて、2077年にそれを開くマシンにそのフォントがなければ、ドキュメント全体のレイアウトが崩れてしまいます。改行位置がずれ、ページ数が変わり、テキストに固定された画像は流れていってしまうでしょう。DOCXには、PDFのようにフォントを埋め込む信頼できるメカニズムがありません。では、結論は？ 編集可能な内容と構造を保存するには素晴らしいフォーマットです。しかし、視覚的なレイアウトを保存するには、賭けになります。
実際のアーカイブ標準が推奨すること
迷ったときは、プロがどうしているかを見てみましょう。いくつかの主要なアーカイブ機関が、この件に関する明確なガイダンスを公表しています。米国議会図書館のデジタルフォーマット持続可能性プログラムは、PDF/A-1に高い持続可能性評価を与え、そのISO標準化と自己完結性を賞賛しています。一方、DOCXには「中程度」の評価を与え、特にフォントへの依存と仕様の複雑さをリスクとして挙げています。英国国立公文書館はさらに直接的です。確定した記録にはPDF/Aを使い、編集可能である必要がある記録にはDOCXを受け入れる、としています。米国政府独自の記録管理規則（36 CFR Part 1236）もまた、恒久的な電子記録にはPDF/Aを指定しています。専門家のコンセンサスは明確です。署名済みの契約書、公開されたレポート、記入済みのフォームのような最終版のドキュメントをアーカイブする場合、専門的に見て唯一正当化できる選択肢はPDF/Aです。ポリシーのテンプレートや改訂中の原稿のような作業中のドキュメントをアーカイブする場合は、DOCXの方が理にかなっていますが、バックアップとしてプレーンテキストやHTMLでのエクスポートとセットにしておくのが賢明です。機関によっては、公式記録としてPDF/Aを、作業用コピーとしてDOCXを、両方アーカイブするところもあります。これは冗長ではなく、2つの異なる、しかし同等に重要な目的を果たすための良い習慣なのです。絶対にやってはいけない最悪のこと、そしてそれは小規模な組織でよく見られることですが、それは標準PDF（PDF/Aではない）や文書化されていないDOCXファイルをアーカイブして、ただうまくいくことを願うことです。PDF/A標準の厳格さがなければ、長期保存は保証ではなく、単なる推測になってしまいます。
フォーマット間の変換：CocoConvertの役割
では、このアーカイブのワークフローにCocoConvertはどう関わるのでしょうか？ 私たちはDOCXからPDFへ、そしてPDFからDOCXへの両方の変換を扱っていますが、私たちのツールが何をするのかを具体的に説明することが重要です。私たちのプラットフォームでDOCXをPDFに変換すると、標準的なPDFが生成されます。視覚的なレイアウトは美しく保持されます。フォント、スペース、表、画像はすべてそのまま変換されます。しかし、出力ファイルは自動的にPDF/A準拠のファイルになるわけではありません。この点は明確にしておきましょう。私たちは現在、変換の一部としてPDF/A認証を提供するサービスは行っていません。正式なアーカイブのために認証済みのPDF/A-1bやPDF/A-2aファイルが必要な場合は、追加のステップを踏む必要があります。Adobe Acrobat Pro（ファイル > 別名で保存 > その他の形式 > アーカイブ用PDF）や、オープンソースのVeraPDFバリデーターのようなツールを使って、出力を検証し、変換する必要があります。クライアントとレポートを共有するなど、多くの日常的なタスクでは、標準のPDFで全く問題ありません。しかし、規制対象のアーカイブでは、その追加の準拠ステップは譲れません。逆方向の、PDFからDOCXへの変換は、事態が少し厄介になります。CocoConvertは高度な光学文字認識（OCR）とレイアウト解析を用いて、構造化されたドキュメントを再構築します。その結果は、完全に元のファイルに依存します。Wordから作成されたクリーンなテキストベースのPDFは、見出し、段落、表が保たれたまま、かなりうまくDOCXに変換されます。しかし、スキャンされたドキュメントや、複雑な段組みを持つPDF、インタラクティブフォームを含むPDFからは、大幅な手作業での修正が必要なDOCXが生成されるでしょう。これはCocoConvertの問題ではありません。PDF自体の問題なのです。これは、ドキュメントがPDFにフラット化される際に起こる、根本的な情報損失を反映しているのです。PDFフォーマット自身が捨て去ることを選んだ構造を、魔法のように再構築できるコンバーターは存在しません。
実践的な判断フレームワーク：状況別のフォーマット選び
理論はさておき、ここでは適切な仕事に適切なフォーマットを選ぶための実践的なフレームワークを紹介します。法的文書やコンプライアンス関連文書（契約書、規制当局への提出書類、裁判所への提出物など）には、PDF/A-1bまたはPDF/A-2bを使用してください。これは譲れません。これらの文書は、不変であり、視覚的に固定されている必要があります。Wordでは、「ファイル > エクスポート > PDF/XPS ドキュメントの作成」を選択し、オプションで「ISO 19005-1に準拠 (PDF/A)」のチェックボックスをオンにします。そして、保管する前にVeraPDFのようなツールで出力を検証してください。内部の作業用文書（ポリシーの草案、手順書、テンプレートなど）は、DOCXを主要なアーカイブ形式として保持しつつ、メジャーバージョンごとにPDFのスナップショットをエクスポートして両方を保存します。ファイル名にはISO 8601形式の日付（例：`policy-draft-2026-05-17.docx`）を使いましょう。これにより、バージョン履歴が明確になり、壊れやすいファイルシステムのメタデータに依存しなくなります。スキャンした紙の記録（請求書、歴史的な手紙、記入済みの紙のフォームなど）には、OCRテキストレイヤーが埋め込まれたPDF/Aが正しい選択です。画像は正確に保存され、OCRレイヤーによって視覚的な記録を変更することなく内容を検索可能になります。研究データや構造化されたコンテンツ（スプレッドシート、データベース、データセットなど）には、PDFもDOCXも主要なフォーマットとして適切ではありません。これはよくある罠です。必要なのは、フィールドを説明するデータ辞書と共に、CSV、XML、またはJSONです。PDFやDOCXは人間が読める要約にはなりますが、唯一のアーカイブコピーであってはなりません。最後に、ファイルサイズについて一言。多くの画像を埋め込んだDOCXは、簡単に50～100MBに達することがあります。同じドキュメントのPDFなら、圧縮を使えばわずか8～15MBになるかもしれません。大量のアーカイブでは、その差はすぐに大きなものになります。PDF/Aは圧縮を許可しており、PDF/A-2標準ではJPEG 2000も利用できます。
率直な結論
これが率直な結論です。最終版ドキュメントのアーカイブに関しては、PDF/Aの勝ちです。これはPDFが完璧なフォーマットだからではなく、PDF/A標準が長期保存の問題を解決するためにゼロから構築されたからです。30年にわたる制度的な実績があります。裁判所はそれを受け入れ、国立公文書館はそれを義務付け、ISO標準は準拠すべき明確で曖昧さのない目標を提供しています。DOCXが正しい選択となるのは、編集可能性と意味構造が必要で、かつ、時間やアプリケーションによって視覚的な表示が変化する可能性を受け入れられる場合です。最悪の結末は、長期保存を後回しにすることです。単にPDF/Aに準拠していない標準PDFを保存したり、どのソフトウェアで作成したかを記録せずにDOCXを保存したりして、2046年にも読めるだろうと高を括るのは、失敗への近道です。フォーマットは古くなり、ソフトウェアは消えていきます。アーカイブで最も重要なのは、ファイルそのものではなく、それに付随して記録するメタデータかもしれません。作成日、ソフトウェアのバージョン、作成者、改訂履歴などです。どのフォーマットを選んだとしても、簡単なREADMEファイルを一緒に保存しましょう。そのファイルが何であるか、いつ作成したか、どのツールを使ったかを文書化するのです。今日のその5分の作業が、あなた自身、あるいは未来のアーキビストを、何日にもわたる頭痛から救うことになるかもしれません。CocoConvertの目標は、ファイル変換のステップを迅速かつ確実に処理することです。しかし、準拠性の検証やメタデータの文書化といった、決定的に重要な最終ステップは、ユーザーの皆様の役割です。変換ツール単体で達成できることを過大に宣伝するよりも、その点を明確にする方が良いと私たちは考えています。