ObsidianからWordへのエクスポート完全ガイド【2026年版】

普段からObsidianで作業している方なら、きっと一度は経験しているはずです。3ヶ月かけてObsidian独自の構文を駆使したリサーチノートを丁寧に育ててきた。たとえばこんなふうに:

[[Project Plan]]        → 別ノートへのリンク
![[diagram.png]]        → 埋め込み画像
> [!note] Key insight   → コールアウトブロック

そこへ同僚から「Word版がほしい」と一言。いざエクスポートしてみると、独自構文のすべてが見事に崩れている。

私が初めてこの問題に遭遇したのは、Obsidianには一切触らないステークホルダーに 40 ページの技術調査レポートを引き渡した時でした。Vault 内では整った見た目だったものが、Wordでは角括弧のリテラル文字列と、行方不明になった画像プレースホルダの山に変わり果てていたのです。その後も何度か同じ変換作業を繰り返すうちに、確実に通用するワークフローに辿り着きました。本記事では、そのやり方を余さず紹介します。多くの人が飛ばしがちな前処理のステップ、実際に問題を引き起こす Obsidian 独自の 3 つの癖、そして画像やコールアウトが言うことを聞かない時の対処法まで含めて解説していきます。

ObsidianのMarkdownが「そのままでは持ち運べない」理由

Obsidian はノートをプレーンな .md ファイルとして保存します。だから Word へのエクスポートも簡単だろう、と思ってしまうのも無理はありません。しかし、実際にはそうはいきません。Obsidian は標準的な Markdown に、どの汎用コンバーターも理解しない独自の拡張機能を追加しているからです。

エクスポート失敗のほぼすべての原因になる、4 つの拡張機能を整理しておきましょう。

標準的な Markdown コンバーター、たとえば Pandoc や大半のオンラインツールは、[[...]] を単なるリテラル文字列として扱い、![[...]] は未知のトークンとして処理します。アプリ上で見ている美しい Obsidian の表示は、あくまで プレビュー であって、ソースそのものではありません。この区別こそが、「なんでエクスポートが壊れるの?」というフラストレーションの根本原因です。

もう 1 つ、見落としやすい問題があります。添付ファイルのパスです。Obsidian は ![[image.png]] を解決する時、フォルダを問わず Vault 全体から一致するファイルを探し出します。一方、標準的な Markdown では明示的な相対パスが必要です。Vault 内で添付ファイルを 99 Attachments/ に置いていて、対象のノートが 10 Projects/ にあるような構成では、どのコンバーターを使うにしても事前にリンクの書き換えが欠かせません。

エクスポート前の前処理で勝負は決まる

私のワークフローで最も大きな信頼性向上につながったのは、コンバーターを走らせる 前 に 5 分の前処理パスを挟むことでした。これを省くと、Wordファイルをあとから 30 分かけて掃除する羽目になります。

ステップ1: 添付ファイル設定を確認する

Settings → Files and links を開き、2 つの値をチェックします。

• Default location for new attachments — 新しく追加される画像や PDF の保存先
• New link format — Obsidian がパスをどう書き出すか(Shortest path when possible、Relative path to file、Absolute path in vault のいずれか)

ここが Obsidian のデフォルトである Shortest path when possible になっていると、添付ファイルが別フォルダにあるノートは軒並みエクスポートで崩れます。エクスポート前に Relative path to file に切り替えましょう。ただし、この設定は今後作成されるリンクにのみ適用されます。既存のリンクは書き換えるまで古い形式のままです。その書き換えはステップ 2 で扱います。

ステップ2: wikilinksを標準Markdownリンクに変換する

Obsidian には専用のトグルがあります。Settings → Files and links → Use [[Wikilinks]] → OFF にすると、新規リンクは [Note Name](Note-Name.md) 形式で書き出されるようになります。とはいえ、これもあくまで 新規 リンクにしか効きません。

既存の [[wikilinks]] を変換するには、選択肢が 2 つあります。

1. 小規模エクスポートなら手動で — ノート内で Cmd/Ctrl+F を使い、[[ を 1 つずつ検索して書き直します。5 ページ程度のノートならこれで十分です。
2. 大きなVaultならCommunity pluginを使う — Settings → Community plugins を開き、"link converter" や "markdown links" といったキーワードで検索してみてください。wikilinks や埋め込みの ![[...]] を標準 Markdown 構文に一括変換してくれるプラグインが、エコシステムにはいくつか存在します。現在のファイル単位でも、フォルダ単位でも動作します。最近更新されていて、利用者数の多いものを選ぶのが無難です。

書き換えが終わると、埋め込み添付ファイルは ![image.png](path/to/image.png) のような形になります。出力結果を必ず確認してください。添付フォルダ名にスペースが含まれている場合は URL エンコード(My%20Vault/attachment.png)しないと、コンバーターが黙って画像を落とすことがあります。

ステップ3: コールアウトをどう扱うか決める

Obsidian のコールアウト(> [!note]、> [!warning] など)は Vault 内では重宝しますが、Word には相当する機能がありません。対処の選択肢は、手間の少ない順に 3 つあります。

• 劣化を受け入れる — プレーンな引用ブロックとしてレンダリングされます。コールアウトの 種類(note/warning/tip)は失われますが、中身は残ります。ほとんどの引き渡しではこれで十分です。
• 重要なものだけ書き換える — > [!warning] Critical を > **⚠️ Critical:** のように置き換えてからエクスポートします。どちらの環境でも読みやすくなります。
• Word側で後処理する — 引用ブロックを Word の Quick Styles で装飾ボックスに変換します。完成度の高い成果物を作る時にだけ割に合います。

私は 20 ページ以下のノートには選択肢 2 を、それ以外には選択肢 1 を使っています。

ステップ4: Dataviewブロックを静的なコンテンツに変換する

ノートに Dataview クエリが含まれている場合、エクスポートされるのは クエリのコード であって、結果の表ではありません。エクスポート前に Obsidian 内でクエリを実行し、レンダリングされた出力をコピーして、コードブロックを静的な Markdown テーブルに置き換える必要があります。そう、これは手作業です。そして、きれいに回避する方法はありません。Dataview はクライアントサイドでレンダリングされるため、ソースファイル自体にはデータが含まれていないのです。

4ステップのエクスポートワークフロー

前処理が終われば、実際の変換作業は拍子抜けするほど素直です。

1. ノートをコピーする(その場でエクスポートしない)

対象のノートと添付ファイルを、Vault の外の一時フォルダに複製してください。前処理の編集(リンクの書き換え、コールアウトの置換)でメイン Vault を汚したくはないはずです。私はデスクトップに _export-staging/ というフォルダを用意して、そこを作業場にしています。

2. 添付ファイルのパスをフラットにする

参照されているすべての画像を .md ファイルと同じフォルダに移動し、リンクをシンプルなファイル名だけに書き換えます。![diagram](../../99 Attachments/diagram.png) ではなく ![diagram](diagram.png) にするイメージです。ほとんどのコンバーターは、上位フォルダを遡るパスを苦手とします。

3. コンバーターを実行する

前処理済みの .md ファイルを MarkFlow の Markdown から Word へのコンバーター にアップロードします。GitHub Flavored Markdown (GFM) に対応しており、表、タスクリスト、脚注など、前処理後の Obsidian が出力する標準機能はすべてカバーされます。画像はインラインで埋め込まれ、コードブロックはシンタックスハイライトを保ったまま、見出しは Word の Heading スタイルへマッピングされるので、出力された DOCX でナビゲーションウィンドウがきちんと機能します。

ノートに LaTeX 数式($E=mc^2$ や $$...$$)が含まれている場合は、選んだコンバーターが数式を Word の数式として保持できるか、プレーンテキストに潰してしまわないかを確認してください。数式が多いノート、たとえば研究ログや論文のドラフトでは、ここが決定的に重要なポイントになります。もし最終成果物が Word である必要がなく、共有できるファイルさえあればいいなら、Markdown から PDF への変換 を使うことで、Word の数式レンダリングの癖を丸ごと回避できます。

4. Wordで仕上げる

DOCX を開き、手持ちの Word テンプレートがあれば適用します。Markdown の見出しスタイルは Word 組み込みの Heading 1/2/3 にきれいにマッピングされるので、Design → Document Formatting から文書全体のスタイルをワンクリックで変更できます。送付する前に、以下の 3 点を必ずチェックしてください。

• 目次 — References → Table of Contents から挿入し、すべての見出しが正しく拾われているか確認する
• 画像サイズ — Obsidian は画像を自然なサイズで表示しますが、Word では肥大化することがあります。必要に応じて全選択して一括リサイズしてください
• ハイパーリンク — 外部リンクはすべて機能しているはず。内部の [[wikilinks]] は解決済みか削除済みになっているはずです

Obsidian特有のエッジケース

頻繁に遭遇する、いくつかの場面を個別に取り上げておきます。

デイリーノートとテンプレート

{{date}} やTemplater変数を使っているデイリーノートをエクスポートする場合、エクスポートは Obsidian が変数を置換した 後 に行われるため、出力される .md にはプレースホルダではなく実際の日付が含まれます。特別な対処は不要です。ただし例外として、ノートを Obsidian で開かずにファイルシステムから直接エクスポートした場合、未解決のテンプレートがそのまま出てきます。必ず一度ノートを Obsidian で開き、レンダリングさせてからエクスポートしてください。

Canvasファイル

Obsidian の Canvas(.canvas)ファイルは Markdown ではなく JSON で、どの Markdown コンバーターも扱えません。現実的な対処は、希望するズームレベルで Canvas のスクリーンショットを撮り、PNG として保存し、その画像をラッパーとなる Markdown ノートに埋め込んでエクスポートすることです。Community plugin によっては「Canvas を画像としてエクスポート」する機能を提供しているものもあります。頻繁に必要になるなら導入する価値はあります。

Mermaid図

mermaid でタグ付けされたフェンス付きコードブロックは、Obsidian 内部で図としてレンダリングされます。オンラインの Markdown から Word へのコンバーターの多くは、これを画像としてレンダリング(良い挙動)するか、あるいは生のコードのまま残す(悪い挙動)のどちらかです。MarkFlow は変換前に Mermaid をインライン SVG へレンダリングし、Word 側では編集可能な画像として表示できるようにします。もし利用するコンバーターが Mermaid に対応していない場合は、Obsidian の表示画面から図を PNG でエクスポートし、コードブロックを通常の画像埋め込みに置き換える、というフォールバックが使えます。

脚注

朗報です。Obsidian の脚注構文([^1] と定義 [^1]: text)は標準的な GFM なので、Word 組み込みの脚注機能にきれいに変換されます。前処理は不要です。

タグとfrontmatter

ノート冒頭の --- ブロックで囲まれた YAML frontmatter は、大抵のコンバーターで除去されます。frontmatter に読み手が必要とする情報(著者、日付、ステータスなど)が入っているなら、エクスポート前に本文中の通常の段落として書き直してください。#project/research のようなインラインタグは、プレーンテキストとして残ることが多く、ほとんどの場合は問題ありませんが、時に違和感を生みます。Word 文書を Obsidian ユーザー以外が読むなら、検索置換で削除するのが無難です。

手動変換が自動化に勝つ場面

正直に言いましょう。書式の少ない 2-3 ページ程度のノートを 1 件だけ変換するなら、最速のワークフローは Obsidian のリーディングビューからコピーして Word に貼り付ける ことです。Obsidian のリーディングモードは HTML でレンダリングしており、Word は HTML を意外な精度で書式付きコンテンツとして取り込んでくれます。表はそのまま、太字・斜体も残り、見出しは Word の見出しスタイルにマッピングされます。

ただし、このリーディングビューからのペーストは、次の 3 点で破綻します。

1. 画像 — Vault 内のファイルへのリンク参照として貼り付けられるので、ファイルがマシンから離れた瞬間に壊れます
2. コードブロック — シンタックスハイライトが失われ、等幅フォントも一貫しません
3. コールアウトとMermaid — 通常のエクスポートと同様に崩れます

つまり、コードも画像も含まない短いノートはペーストで。それ以上の長さや技術的な内容は、先述の 4 ステップのワークフローで、と使い分けてください。

トラブルシューティング:うまくいかない時の対処法

私が最もよく目にする失敗パターンをまとめます。より網羅的なリファレンスとしては、Markdown 変換トラブルシューティングガイド で一般的な 15 の変換問題を詳しく解説していますので、あわせて参照してください。

Wordファイルで画像が表示されない。 90% の確率でパスの問題です。.md のソースを確認してください。添付ファイルのパスがシンプルなファイル名(image.png)になっているか、それとも複雑なパス(../../99 Attachments/My Folder/image.png)のままか。フラット化しましょう。

表が1行に潰れて表示される。 ソースが Obsidian のレガシーな表記形式を使っているか、パイプ文字の数が揃っていない可能性があります。プレーンテキストエディタで .md を開き、すべての行でパイプ文字の数が同じであることを確認してください。ヘッダーセパレータも揃っている必要があります: | --- | --- |。

コードブロックの言語の色付けが失われる。 フェンスの開き(バッククォート 3 つ)の直後に言語タグ(python、js、bash など)が付いているか確認してください。コンバーターはそのタグを使ってシンタックスハイライトを適用します。タグがないとプレーンテキスト扱いになります。

エクスポート後もwikilinksが[[Note Name]]のまま。 前処理が走っていないか、そのファイルに適用されていません。Use [[Wikilinks]] が設定でオフになっていることを確認し、ステップ 2 で導入した変換プラグインを該当ファイルに対して再実行してください。多くのプラグインは Vault 全体ではなく単一ノートへのスコープ指定に対応しています。

数式が生のLaTeXのまま表示される。 そのコンバーターが数式レンダリングに対応していません。別のコンバーターに切り替えるか、Obsidian 上でレンダリングされた数式をスクリーンショットして画像として埋め込むしかありません。見栄えは良くありませんが確実です。

チームで回すための現実的なワークフロー

もしあなたがチームで唯一の Obsidian ユーザーで、かつ他のメンバーには Word ファイルを渡す必要があるなら、その場限りのエクスポートスクリプトではなく、繰り返し使えるプロセスを組み立てることをおすすめします。私が共同プロジェクトで採用しているバージョンはこんな感じです。

1. Vault 内に Word 行きのノート専用の Exports/ フォルダを用意する
2. そのフォルダでは wikilinks ではなく、最初から標準 Markdown リンク([text](note.md))を使う。前処理の手間が省ける
3. 変更されたノートに対して、週次でバッチ変換を実行する
4. DOCX の出力は Vault ではなく、共有ドライブに置く

ポイントは、思考のための空間(Obsidian 独自の機能を全開にしたメイン Vault)と、引き渡しのための空間(標準 Markdown で書かれた Exports/ フォルダ)を分離することです。この分離へのリファクタリングには、初回で 1 時間ほどかかりましたが、その後は毎月何時間も節約できています。

逆方向から来た方、つまり Markdown で書き始めたばかりで、基本を押さえたいという方には、Markdown の書き方ガイド がどんなエクスポートでもスムーズにしてくれる基礎を解説しています。変換パイプラインの出力側についてもっと深く知りたいなら、Markdown から Word への完全ガイド で、複雑な文書に効いてくるコンバーターの機能を一通り紹介しています。

おわりに

Obsidian の本当の強みは、その非標準的な機能、つまり wikilinks、コールアウト、Vault を生き物のように感じさせる動的クエリにあります。Word へのエクスポートはその大部分を諦めることを意味します。コツは抗うのをやめることです。Word 版はフラット化された表現になる、と受け入れ、それに合わせて前処理を行い、Word のスタイリングツールで必要な箇所だけ磨き直す。そう割り切ると、作業はぐっと楽になります。

前処理の習慣さえ身につけば、このパイプライン全体にかかる時間はノート 1 件あたり約 5 分です。「あとでやる」と「今日送る」の、大きな違いです。