docx から Obsidian へ：画像パスを正しく設定する
テキストは Word と Markdown の間でクリーンに変換できます。移行が崩れるのは画像です。変換したファイルを vault に入れた瞬間、すべてのスクリーンショットは、Obsidian がそのノートの場所から解決できるパスにある、ディスク上の実ファイルでなければなりません。まず画像パイプラインを固めてしまえば、あとはすべて定型作業です。
このガイドでは、Pandoc が docx ファイルからメディアを取り出す仕組み、ディスク上に何が出力されるか、そして動作する Obsidian ノートで終わる再現性のあるワークフローを説明します。あわせて、文書間で画像名が衝突する問題と、Obsidian が表示できない Windows ベクター形式という 2 つの典型的な落とし穴も取り上げます。
画像が難しい理由
docx ファイルは ZIP アーカイブです。段落は XML に格納されていますが、スクリーンショット、グラフ、図はすべてアーカイブ内のメディアフォルダにあり、ファイルシステムのパスではなく内部リレーションシップで参照されています。Word で見えているものは、変換後に Markdown ファイルが必要とするものとは一致しないため、コンバーターはテキストの書き換えとバイナリの解凍を同時に行う必要があります。
解凍の半分を省くと、どこにもつながらないリンクだらけのノートができあがります。Obsidian は壊れたプレースホルダーを文句も言わずにレンダリングし、被害はたいてい数週間後、別のデバイスでノートを開いたり、同僚と vault を共有したりしたときに表面化します。変換前に画像パイプラインを計画することが、クリーンな移行と修復作業を分ける境界線です。
Pandoc がメディアを抽出する仕組み
このサイトのコンバーターの背後にあるエンジン Pandoc は、docx リーダーの内部で抽出を処理します。メディア抽出を有効にすると、埋め込まれた画像はすべてパッケージ内で持っていた名前、image1.png、image2.jpeg などで書き出され、変換されたドキュメントの隣にある media フォルダにまとめられます。
Markdown の出力はまさにそれらのパスを参照するため、ノートとメディアフォルダはセットで持ち運べます。結果を ZIP としてダウンロードすれば、.md ファイルとそこで言及されているすべての画像を一度に受け取れます。アーカイブをどこに解凍してもリンクはすでに正しい状態です。参照がノートからの相対パスだからです。
知っておくべき詳細が 2 つあります。名前はキャプションではなく docx パッケージから来るため、Survey Site B とラベル付けされた写真が image7.png として保存されることがあります。そして番号付けは文書ごとにやり直されます。すべての Word ファイルが再び image1 から始まるため、複数の変換済み文書が 1 つのフォルダを共有した瞬間に衝突問題になります。
base64 インラインか、独立したフォルダか
base64 モードは逆のアプローチを取ります。画像はディスクに書き出されるのではなく、data URI として Markdown に直接埋め込まれます。結果は、失くすメディアフォルダのない自己完結型の 1 ファイルになり、ノートを単一の添付ファイルとして送ったり、ツール間で貼り付けたりする必要がある場合に便利です。
vault にとっては、通常は実ファイルのほうが勝ります。data URI はサイズを約 3 分の 1 膨らませ、数枚のスクリーンショットでノートが数メガバイトの base64 テキストになり、エディターの動作が重くなり、diff やバージョン管理が役に立たなくなります。実ファイルなら一度圧縮・リネームするだけで、それを参照するすべてのノートを修正できますが、ノート内に凍結された画像データを一箇所で更新することはできません。
Obsidian の添付ファイルの規約
Obsidian ではレイアウトを選べますが、ここで重要な設定が 2 つあります。Files and links（ファイルとリンク）にある Default location for new attachments（新しい添付ファイルの既定の保存場所）が、ドラッグした画像の行き先を決めます。vault のルート、現在のフォルダ、または指定したフォルダです。ほとんどの vault は最終的に vault 全体で 1 つの専用添付フォルダに落ち着きます。
変換された Markdown には media/image1.png のような相対参照が付いており、Obsidian はノート自身の場所を基準にこれを解決するため、最初の配置は簡単です。media フォルダをノートの隣に置いておけばよいのです。New link format（新しいリンク形式）は今後 Obsidian が書き込む内容を制御し、相対パスが最も安全な選択です。vault がマシン間や同期ツール間を移動してもノートが動き続けるからです。
初回からうまくいくワークフロー
まず、docx をこのサイトのコンバーターにドロップし、画像モードを ZIP のままにします。変換はすべてブラウザー内で実行されるため、未公開の下書きがマシンから出ることはなく、ダウンロードには .md ファイルとそのメディアフォルダが含まれ、すでに相対パスで結ばれています。
次に、ZIP をノートを置くべき vault のフォルダに解凍し、.md と media フォルダを並べて配置します。vault を開けば、最初の試行で画像がレンダリングされます。すべての参照が、実際に 1 つ隣に存在するファイルを指しているからです。
3 つ目に、ファイルマネージャーではなく Obsidian の中から整理します。画像を選択して添付フォルダにドラッグすると、Obsidian は同じ操作でファイルを移動し、参照を書き換えます。アプリの外でファイルを移動すると古いリンクが残ります。背後で変更されたパスを再スキャンするものが何もないからです。
文書同士が衝突するとき
すべての Word 文書は画像を 1 から採番するため、10 本の論文を変換すれば 10 個の異なる image1.png ファイルができます。それらをすべて共有の添付フォルダにコピーすれば、気づかないうちに 9 枚を上書きしたことになります。これは、移行が完了したように見えて数週間後に図が失われる、最もありがちなパターンです。どのファイルがどこから来たか、誰も覚えていない頃に。
一括変換は、ZIP 内でソース文書ごとに専用のサブディレクトリを与えることでこれを回避します。あるノートとそのメディアフォルダ、次のノートとそのメディアフォルダ、という具合に、間に共有の名前空間がありません。vault 全体で 1 つの添付フォルダにしたい場合は、意図的に統合してください。各文書の画像に意味のあるプレフィックスを付けてリネームし、Markdown 内の古いパスを検索・置換します。
Obsidian がレンダリングできない形式
docx の中身がすべて PNG や JPEG とは限りません。Office の図表、Visio からの貼り付け、一部のコピー操作は EMF や WMF を生成します。これらはブラウザーがデコードできない Windows ベクター形式です。Obsidian はブラウザー技術の上に構築されているため、パスがどれほど正しくてもこれらの画像は見えないままで、ノートに図形の穴が残ることがよくあります。
解凍後、media フォルダをファイルタイプで並べ替え、.emf や .wmf で終わるものを取り出します。最も手軽な修正は、ソース文書に戻り、図を右クリックして Save as picture（画像として保存）を選び、変換前に PNG をエクスポートすることです。その後、エクスポートしたファイルを参照に合わせてリネームするか、参照をファイルに合わせて編集します。