レガシー WordPerfect ファイルを最新フォーマットへ変換する実践ガイド

WordPerfect はかつて、企業・法律事務所・学術機関における主力ワードプロセッサでした。現在もプログラム自体は存続していますが、ほとんどの組織は Microsoft Word、Google Docs、あるいはオープンソーススイートへ移行済みです。しかし、共有ドライブやアーカイブ箱、バックアップテープ上には、契約書・訴訟資料・研究論文など、法的・歴史的に重要なコンテンツを含む膨大な .wpd ファイルが残っています。これらの書類を書式・埋め込みオブジェクト・メタデータを失うことなく変換するのは簡単ではありません。本ガイドでは、ソースコレクションの評価から最終出力の検証までを網羅したワークフローを示し、忠実性の保持と長期的なアクセシビリティの確保に焦点を当てます。

1. WordPerfect 変換の課題を理解する

WordPerfect は独自のバイナリレイアウトを採用しており、DOCX が使用する Office Open XML 構造や PDF 仕様とは大きく異なります。主な障壁は次の通りです。

• フォント置換 – WordPerfect はフォントファイル自体ではなくフォントメトリックを埋め込みます。変換先の環境に元のフォントが無い場合、エンジンは既定フォントに置き換え、改行やページ割りが変わります。
• 複雑なレイアウト機能 – ヘッダー/フッター領域、複数列セクション、脚注、条件付きテキスト規則などは、素朴なコンバータでは誤って解釈され、コンテンツがずれることがあります。
• 埋め込みオブジェクト – OLE オブジェクト（例：Excel グラフ、Visio 図）はバイナリブロブとして保存されています。一部の変換ツールはこれらを抽出・描画できず、情報が失われます。
• マクロとスクリプト – WordPerfect のマクロ言語（WPM）はネイティブ環境外でのサポートがほとんどありません。マクロ生成コンテンツに依存する文書を変換するには別途戦略が必要です。
• メタデータの欠損 – 旧バージョンの WordPerfect は作者・作成日・改訂履歴を独自フィールドに格納します。変換時に標準的な Dublin Core や Office Open XML プロパティへマッピングされないと、これらは破棄されます。

これらの落とし穴を早期に認識すれば、移行パイプライン後半での高コストな手直しを防げます。

2. 変換前のソースファイル準備

計画的な準備フェーズはリスクを低減し、以降の変換作業を再現可能にします。

2.1 インベントリ作成と分類

• .wpd ファイルごとにサイズ、最終更新日、利用シーン（例：法務契約書、マーケティングパンフレット）を記載したスプレッドシートを作成します。
• 優先度でタグ付けするとリソース配分が楽になります。リスクが高い法務文書は手動レビュー、ニュースレター等の大量文書はバッチ処理が適します。

2.2 フォントの統合

• 文書で使用されている元フォントファイルをすべて集めます。プロプライエタリなフォントの場合は、視覚的メトリックが合致する代替フォントをライセンス取得して使用します。
• これらのフォントを変換作業用ワークステーションにインストールしてください。多くのコンバータは最初に見つかった一致フォントを自動的に使用します。

2.3 変換前のバックアップ

• 元のアーカイブ上で直接作業しないでください。全コレクションを専用変換ディスクへコピーします。これにより予期せぬ破損時でも安全にロールバックできます。

2.4 冗長ファイルの整理

• 重複または不要な .wpd を削除します。インベントリに対して重複検出ツールを走らせるだけで、作業負荷を 10‑20 % 削減し、ストレージコストも最小化できます。

3. 出力フォーマットの選定

最適な出力形式は、変換後の利用シーンに依存します。

• DOCX – 今後 Office や Google Workspace で編集し続ける場合に最適。スタイル・表・コメントなど構造要素をほぼすべて保持し、変更履歴もサポート。
• PDF/A‑2 – アーカイブ用途に理想的。PDF/A は外部フォントへの依存を排除し、埋め込みフォントで読み取り専用の表現を保証します。
• ODT – LibreOffice などオープンソースエコシステムを採用している組織向け。
• HTML5 – ウェブサイトや社内イントラネットで公開する場合、クリーンで意味的な HTML に変換すれば見出し階層が保たれ、スタイリングが容易になります。

多くのプロジェクトでは デュアル出力 が採用されます：将来的な編集用に DOCX、コンプライアンスと長期保存用に PDF/A を出力します。

4. 変換エンジンの選択

変換ツールは大きく 3 つのカテゴリに分けられます。

プライバシーに敏感な大規模アーカイブでは、ハイブリッド方式が有効です。最も複雑なファイルはローカルにインストールした WordPerfect（またはトライアル版）で処理し、単純な文書は convertise.app などのクラウドサービスに委ねます。Convertise は可能な限りブラウザ内で処理を完結させ、ソースがユーザーのマシンを離れないようにするため、機密性の高い契約書の取り扱いに適しています。

5. 詳細変換ワークフロー

以下はツール選定後にスクリプト化できる、再利用可能なステップバイステッププロセスです。

5.1 自動事前チェックスクリプト（PowerShell 例）

# .wpd ファイルをスキャンし CSV レポートを生成
Get-ChildItem -Path "E:\LegacyWPD" -Recurse -Filter *.wpd |
Select-Object FullName, Length, LastWriteTime |
Export-Csv -Path "E:\ConversionReport\wpd_inventory.csv" -NoTypeInformation

生成された CSV はバッチエンジンに渡し、サイズが 5 MB 超のファイルを手動レビュー対象としてフラグ付けできます。

5.2 Convertise CLI を使ったバッチ変換（仮想 CLI）

# convertise が CLI ラッパー cs-cli を提供している想定
cs-cli batch \
  --input "E:/LegacyWPD/**/*.wpd" \
  --output-format docx \
  --output-dir "E:/Converted/DOCX" \
  --log "E:/ConversionReport/batch_log.txt"

CLI は元のタイムスタンプを保持し、各出力ファイルの SHA‑256 チェックサムを書き出します。このハッシュは後の検証に利用します。

5.3 PDF/A 生成（LibreOffice ヘッドレスモード使用）

# DOCX から PDF へ変換
libreoffice --headless --convert-to pdf:writer_pdf_Export --outdir "E:/Converted/PDF" "E:/Converted/DOCX/*.docx"
# Ghostscript で PDF/A‑2 に強制変換
for f in E:/Converted/PDF/*.pdf; do
  gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceRGB \
     -sDEVICE=pdfwrite -sOutputFile="${f%.pdf}_pdfa.pdf" "$f"
done

二段階のアプローチにより、生成された PDF がアーカイブ基準を満たすことが保証されます。

5.4 検証と品質保証

1. チェックサム比較 – 事前ハッシュと変換後に生成されたメタデータファイルのハッシュを比較し、ソースが変換中に改変されていないことを確認します。
2. 目視スポットチェック – 変換文書のうち 5 % をランダムに抽出し、Word/LibreOffice で開いてページ数、ヘッダー/フッターの整合性、表の配置を比較します。
3. メタデータ監査 – exiftool や pdfinfo を使用して、作者・作成日・キーワードが保持されているか確認します。欠落があれば、インベントリ CSV から取得した情報をスクリプトで注入できます。

6. 埋め込みオブジェクトとマクロの取扱い

6.1 OLE オブジェクトの抽出

WordPerfect の OLE オブジェクトはバイナリストリームとして保存されています。Ole2Extract などのツールで事前に抽出し、変換後に手動またはマクロで再埋め込みします。

6.2 WordPerfect マクロへの対処

WPM マクロは移植性が低いため、最安全な手段は WordPerfect 環境でマクロを実行し、結果を静的文書（例：PDF）としてエクスポートしたうえでその静的出力を変換することです。マクロがテキスト生成のみであれば、python‑wpd（存在すれば）などのライブラリで同等ロジックを Python スクリプトとして再実装し、元 .wpd を直接処理することも検討できます。

7. メタデータの保持とマッピング

変換後に残りやすい標準メタデータフィールドは以下の通りです。

• Title → dc:title（PDF）または coreProperties.title（DOCX）
• Author → dc:creator / coreProperties.author
• Subject/Keywords → dc:description / coreProperties.subject
• Creation/Modification Dates → dcterms:created / dcterms:modified

変換ツールがこれらを落とした場合は、ポストプロセスで再注入できます。以下は python‑docx を用いた例です。

from docx import Document
import csv, datetime
from pathlib import Path

metadata = {row['filename']: row for row in csv.DictReader(open('wpd_inventory.csv'))}
for file in Path('E:/Converted/DOCX').glob('*.docx'):
    doc = Document(str(file))
    meta = metadata.get(file.name, {})
    doc.core_properties.title = meta.get('title', '')
    doc.core_properties.author = meta.get('author', '')
    if meta.get('created'):
        doc.core_properties.created = datetime.datetime.fromisoformat(meta['created'])
    doc.save(str(file))

8. 大規模コレクション向けバッチ自動化

数万件に及ぶアーカイブの場合、RabbitMQ や AWS SQS などのキューベースシステムでワーカーを非同期に動かすと効果的です。各ワーカーは以下を実行します。

1. ファイルパスを含むメッセージをキューから取得
2. 変換パイプラインを実行
3. 結果を出力バケットへ保存
4. 成功／失敗イベントをキューに投稿

この設計のメリットは次の通りです。

• スケーラビリティ – キューが滞留したらワーカーを追加起動
• フォルトトレラント – 失敗ジョブは自動リトライ可能
• 監査性 – 各メッセージに一意 ID が付与され、ログは一元管理できるためコンプライアンス報告が容易

9. プライバシーとコンプライアンスの留意点

レガシー WordPerfect ファイルの多くは社内情報ですが、個人識別情報（PII）や保護された医療情報（PHI）を含む可能性もあります。クラウドサービスに送信する前に必ず確認してください。

1. データ所在地 – サービスが組織と同一法域で処理を行うか
2. エンドツーエンド暗号化 – 転送時は TLS、可能であれば処理中も暗号化されたままにする
3. 永続保存なし – 変換完了後にファイルがサーバに残らないことを保証する。例として Convertise.app は変換完了直後にファイルを破棄します。

上記条件を満たさないファイルは、オンプレミスで変換を完結させてください。

10. 変換資産のアーカイブ保管

変換が成功したら、組織の記録保持ポリシーに従って以下の階層構造で保存します。

ArchiveRoot/
├── Original_WPD/        # 読み取り専用・不変のバックアップ
├── DOCX_Editable/       # 将来の編集用
├── PDF_A_Archive/       # 長期保存用の読み取り専用
└── Metadata/            # CSV レポート、チェックサム、監査ログ

PDF/A 層は書き換え不可（WORM）ストレージに配置し、誤改変を防止します。重複除去（デデュプリケーション）を適用すれば、容量削減とチェックサム整合性の両立が可能です。

11. よくある落とし穴と対処法

12. 変換後コーパスの将来保証

DOCX、PDF/A、ODT といったオープンで文書化されたフォーマットに収めれば、将来的な陳腐化リスクは大幅に低減します。永続的に保護するための手順は次の通りです。

• 標準準拠の検証 – PDF/A バリデータ（例：veraPDF）や DOCX スキーマバリデータで合格を確認
• 定期的なメディア更新 – 5‑7 年ごとに新しいストレージ技術へ移行
• 変換レシピの保存 – 使用したコマンドライン引数、ツールバージョン、フォントパックをドキュメント化。これにより、下流システムのレンダラが更新された際にも同一変換結果を再現可能

---

レガシー WordPerfect 変換を、インベントリ作成・制御されたツール選定・自動検証・堅牢なアーカイブという 4 つの柱で構成したデータ移行プロジェクトとして扱えば、レイアウトの完全性やコンプライアンスを犠牲にせず、何十年も蓄積された貴重なコンテンツを解放できます。オンプレミス完全解決策でも、convertise.app のようなプライバシーに配慮したクラウドツールを併用しても、ここで示した原則に従えばプロセスは透明・再現可能・監査可能となります。