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

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

[[Project Plan]]        → link to another note
![[diagram.png]]        → embedded image
> [!note] Key insight   → callout block

そこへ同僚から「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分です。「あとでやる」と「今日送る」の、大きな違いです。