Word から Markdown への移行：完全ガイド
Word から Markdown への文書移行は、そのほとんどが機械的な作業です。しかし失敗には決まったパターンがあり、防ぐコストは小さく済みます。そのすべてが、変換を一発で決まる魔法の一手としてではなく、いくつかの判断を含む小さなパイプラインとして扱わなかったことに由来します。
このガイドでは、それらの判断を順番にたどります。実際にどのくらいの量を移行するのか、何が変換を生き残り何が生き残らないのか、脚注・表・数式がどう移るのか、そして静的サイトや wiki が一度で受け入れるファイルに仕上げるにはどうすればよいのかを見ていきます。
変換前に範囲を決める
現行の1文書と10年分のアーカイブでは、別のプロジェクトです。1文書なら、午後に手作業で磨き上げられる忠実な変換が目標です。アーカイブなら、目標は再現性に移ります。同じオプション群を一貫して適用し、人間は全ファイルではなくサンプルを確認する形です。
どちらの場合も、サンプルから始めます。表がひどく、図が多い、代表的な文書を2〜3本変換し、出力を注意深く点検します。サンプルから、どのオプションが重要で、残りの山にどれだけのクリーンアップが必要かが、本番実行に踏み切る前に分かります。
きれいに変換できるもの、できないもの
Word の正規の見出しスタイルは Markdown の見出しに、単純な表は表に、脚注は脚注になり、埋め込み画像は実ファイルとして取り出されます。通常の文書フローの中にあるコンテンツは問題なく移行でき、典型的な文書の実体はその大部分が占めています。
例外は周縁に集まります。太字の行で見出しを装うような直接書式は構造にならないため、先に Word で正規の見出しスタイルを適用してください。変更履歴（トラック変更）はすべての変更が承認されたものとして変換されるので、削除されたテキストが重要なら変換前に変更履歴を解消します。コメント、テキストボックス、フローティング図形は確実には引き継がれないため、その中身は本文のフローに移すか、別途保存しておく必要があります。
脚注は一緒に移る
Word の脚注はうれしい誤算の一つです。Pandoc が読み取り、Markdown 出力では本物の脚注記法が使われます。文中の各マーカーは番号の前にキャレットを付けた角括弧の参照になり、すべての定義は文書末尾に集められ、マーカーへ相互にリンクされます。
それでも確認すべき点が2つあります。相互に参照し合う脚注や、表や画像を含む脚注は、元と異なる順序や形で出力されることがあります。また、文末脚注は脚注と同じように変換されますが、Markdown ではたいていそれが望む形です。
表とその限界
出力先が GitHub、Obsidian、ほとんどの wiki なら GFM オプションを有効にします。単純な表はパイプテーブルに変換されます。ヘッダー行1行、区切り行1行、データは1行につき1行です。この形式はどこでもレンダリングされ、プレーンテキストのままでも読みやすさを保ちます。
限界は構造的なものです。結合セル、複数段落を含むセル、入れ子の表にはパイプテーブルでの表現方法がなく、pandoc はそれらのプラットフォームが無視する Markdown 方言にフォールバックします。誠実な解決策は上流にあります。Word 側で複雑な表の結合を解いて平坦化するか、少数の表は移行後の手直しが必要だと受け入れるかです。
数式は LaTeX になる
Word の数式エディターで入力された数式は構造化された数学として保存されており、pandoc は捨てずに変換します。Markdown 出力はインライン数式をドル記号のデリミタで囲み、ディスプレイ数式を独立した行に置きます。LaTeX 出力形式は、それを期待するレンダリングパイプライン向けにネイティブの数式環境を出力します。
変換後は2つの弱点をスキャンします。Word が曖昧に表示していたインライン数式と、何年も前に画像として Word に貼り付けられたものです。後者は今や数式ではなく画像です。これらは再入力が必要で、移行開始前にそれを知っていれば、スケジュールを正直に保てます。
予測可能な画像戦略をひとつ
埋め込み画像はすべて、変換されたファイルの隣の media フォルダに、docx パッケージが割り当てた名前で取り出されます。image1.png とその仲間たちです。Markdown はこれらの相対パスを参照し、ZIP ダウンロードは両者をまとめて届けるため、変換された各文書は自己完結したペアになります。
実行前に決めておきます。各文書が独自の media フォルダを持つか、共有の assets フォルダに統合するかを。分けておくのは安全で自動です。統合する場合は意味のある接頭辞で名前を付け直し、参照も合わせて更新する必要があります。避けたいのは、複数の image1.png が互いを上書きし終えてから衝突に気づくことです。
静的サイト向けの front matter
Hugo や Jekyll のような静的サイトジェネレーターは、各ファイルの先頭に YAML の front matter（title、author、date）を期待します。変換ツールは docx 内に保存された文書プロパティからそのブロックを生成できるため、ファイルはメタデータを備えた状態で届き、後から入力し直す必要がありません。
それが成り立つのは、プロパティが本物の場合だけです。古い形式から一括変換された Word ファイルは、Title フィールドが空で、作成者が退職した社員のアカウントのままということがよくあります。実行前に Word で10分かけて各文書のファイル情報を埋めることが、使える front matter と単なるプレースホルダーの分かれ目です。
一括移行の実行
オプションがサンプルで調整済みなら、大量実行は無風です。docx ファイルのフォルダをこのサイトの変換ツールに追加し、キューが各ファイルを個別のステータス付きで処理するのを待ち、ZIP をダウンロードします。一括出力は各文書に独立したサブディレクトリを与えるため、ある論文の画像が別の論文の画像を覆い隠すことはありえません。
移行が承認されるまで、元の docx ファイルは保持してください。それらは変換がならしたり落としたりした箇所の唯一の正本であり、調整済みオプションでの再実行は、失われた細部を記憶から再構築するより常に安くつきます。
移行完了のチェックリスト
各文書で6項目を確認します。見出し階層が飛躍なく降りていること、すべての画像参照が実在するファイルに解決されること、表が対象プラットフォームでレンダリングされること、脚注が本物の脚注として現れること、数式がレンダリングされるべき場所でレンダリングされること、front matter のフィールドが空ではなく埋まっていることです。
最後に、1本の文書を実際の出力先で端から端まで通します。静的サイトをビルドし、wiki ページをプレビューし、Obsidian でノートを開きます。移行が完了したと言えるのは、変換ツールが成功を報告したときではなく、対象システムがファイルをレンダリングしたときです。この最終確認は数分で済み、ファイル単位のチェックが見逃したすべてを捕らえます。