現在の言語: 日本語JA EnglishEN
お問い合わせ

MarkdownをWordに変換する方法|コピペ・DOCX・Pandoc

2026.09.05 公開 2026.10.01 更新 使い方ガイド 約15分で読めます

MarkdownをWordへ変換する方法を、通常貼り付け・リッチテキスト・DOCX・Pandocで比較。生Markdownと表示済み文章の違い、Wordテンプレート適用まで整理します。

目次(10)

MarkdownをWordへ移す方法は、原稿がすでに画面上で整形済みか、生のMarkdown(.md)かで変わります。表示済みの短い文章ならWordへ直接貼り付け、生のMarkdownを文書構造として変換したいならDOCX出力、繰り返し変換やWordテンプレート適用まで必要ならPandocという順で考えると分かりやすくなります。

一方、画像・数式・複雑なページレイアウトまで自動で完成するわけではありません。Wordへ移したあとに、余白、改ページ、画像位置などを確認する前提で使い分けます。

結論:表示済み文章はコピペ、生MarkdownはDOCX、自動化はPandoc

Microsoftの現行サポートでは、他アプリからWordへ貼る場合に「元の書式を保持」「書式を結合」「テキストのみ保持」を選べます。通常の貼り付けは元の書式を保持する設定が既定です。見た目を残したいのか、Word側のスタイルへ寄せたいのか、文字だけ欲しいのかで最初の方法を変えます。

先に選び方をまとめると、次のようになります。

方法 向いている場面 強み 注意点
ChatGPTの表示をそのままコピー 数段落、一度きり 最短で試せる 「元の書式を保持」「書式を結合」で結果が変わる
Yomuからリッチテキストをコピー Wordで編集を続ける短文〜中程度の原稿 見出し・太字・箇条書きを書式付きで渡しやすい Word固有のスタイルやページ設定は別途調整
YomuからDOCXを保存 見出し・表・長文の構造を残したい Word文書として編集しやすい 画像・数式・複雑なレイアウトは追加調整が必要

最初に直接貼り付けを試し、問題がなければそれが最短です。崩れた場合にだけ、リッチテキストかDOCXへ切り替えます。

Markdown→Wordの最短ルート

元原稿・目的 最初に試す方法
ChatGPT等で表示済みの短文をWordへ移す Wordへ通常貼り付け
生Markdownを数ページのWordへ変換したい Yomu等でDOCXへ変換
Wordで編集を続けたいがファイル生成は不要 リッチテキストで貼り付け
大量の.mdを継続的にDOCX化したい Pandoc
社内テンプレートの余白・見出し等を毎回揃えたい Pandoc + --reference-doc

Microsoft Wordの現行サポートでは、他アプリから貼り付ける際に「元の書式を保持」「書式を結合」「テキストのみ保持」を選べます。既定では元の書式を保持します。

一方、PandocはMarkdownとWord docx の相互変換を公式にサポートし、--reference-docでWordのスタイル、余白、ページサイズ、ヘッダー・フッター等を参照できます。

一度きりの短文にPandocを導入する必要はなく、反復変換やテンプレート適用が必要になった段階で使うのが合理的です。

表示済み文章と生Markdownで貼り付け結果が違う理由

ChatGPTやClaudeの回答画面では、Markdownの##や**がそのまま見えているとは限りません。画面上ではすでに見出し・太字・リストとして描画されている場合があります。

その表示済みの文章をコピーすると、クリップボードにはプレーンテキストだけでなくHTMLなどの書式情報が含まれることがあります。Wordは貼り付け時に、その情報と貼り付け先のスタイルを組み合わせます。

一方、コードブロックや.mdファイルから生のMarkdownをコピーすると、##や**が文字として残ることがあります。

「AI画面に表示された文章をコピーする」のか、「Markdownソースをコピーする」のかで結果が違うことを先に切り分けると、無駄な修正を減らせます。

コピー時にHTML・Markdown・プレーンテキストがどう扱われるかは、ChatGPTの文章をコピペすると書式が崩れるのはなぜ?で詳しく整理しています。

Wordへ移す3つの方法

方法1:まずChatGPTの表示をそのままWordへコピーする

数段落程度なら、最初にChatGPTやClaudeの表示済みの回答をそのままWordへ貼ります。

確認するのは、次の5点です。

  1. 見出しが本文と区別されているか
  2. 太字が残っているか
  3. 箇条書き・番号付きリストが崩れていないか
  4. 表が読める形で移っているか
  5. 不要なフォントや行間が持ち込まれていないか

問題がなければ、そのままWord側で仕上げるのが最短です。既存のWordテンプレートへ合わせたい場合は、「書式を結合」を試すとコピー元の強調をある程度残しつつ貼り付け先の段落スタイルへ寄せられます。

逆に、##や**が残る、リスト階層が崩れる、表の修正量が多い場合は、次の方法へ進みます。

方法2:Wordで編集を続けるならYomuからリッチテキストをコピーする

ブラウザMarkdownエディタYomuでは、Markdownをプレビューしながら編集したあと、リッチテキストとしてクリップボードへコピーできます。

Yomuのリッチテキスト出力は、クリップボードへtext/htmlとtext/plainを用意する方式です。WordやGoogleドキュメント、メールなど、HTML書式を受け取れる貼り付け先へ持っていく用途に向いています。

手順

  1. Yomuを開く
  2. ChatGPT・Claudeの原稿を貼り付ける
  3. 見出し・箇条書き・表をプレビューで確認する
  4. 必要な言い回しや見出し階層を修正する
  5. エクスポートからリッチテキストをコピーする
  6. Wordへ貼り付け、見出し・太字・リストを確認する

この方法の利点は、DOCXファイルを一度保存して開く工程を挟まず、Wordへ書式付きで渡してそのまま編集を続けやすいことです。

一方、Word側の「見出し1」「見出し2」といった組織固有のスタイルまで完全に合わせる用途では、貼り付け後のスタイル調整が必要です。

方法3:見出し・表・長文の構造を残すならDOCXへ保存する

長文や表を含む原稿では、クリップボード経由よりDOCXとして書き出した方が扱いやすい場合があります。

Yomuでは、Markdownを編集・確認したあと、Word(.docx)として保存できます。

手順

  1. YomuへMarkdown原稿を貼り付ける
  2. 見出し階層、リスト、表、リンクを確認する
  3. エクスポートからWord(DOCX)を選ぶ
  4. 保存したファイルをWordで開く
  5. 見出し、リスト、表が文書として扱いやすい状態か確認する
  6. Word固有の余白・改ページ・フォントを最後に調整する

DOCXを使う目的は、Markdownの見た目を完全に複製することではありません。見出し・段落・リスト・表といった文章構造を、Wordで再編集しやすい形へ運ぶことです。

Wordへ移した後は「見た目」と「編集できる構造」を別に確認する

Wordで同じように見えていても、太字の段落がWordの「見出し2」スタイルとして扱われているとは限りません。納品・再編集する文書なら、次の二段階で確認します。

何を確認するか 具体的な操作 失敗の例
見た目 印刷レイアウトで見出し・表・改行を読む 表が用紙幅を超える
文書構造 ナビゲーションで見出しを確認 太字に見えるだけで見出しスタイルではない
内容 表のセル、URL、箇条書き番号を照合 行・リンクの欠落
配布形式 .docx保存後に閉じて再度開く 貼り付け直後にだけ正しく見えていた
共同編集 指定テンプレート・コメント等を確認 独自書式が社内テンプレートと競合

原稿が数行ならWord標準の貼り付けで十分な場合があります。大量のMarkdownを繰り返しDOCX化する場合は、Pandoc等の変換手順を揃える意味がありますが、変換後のWord実ファイルの検査は省略できません。

Word側で確認すること

何が残り、何はWord側で直す必要があるか

MarkdownとWordは扱える情報量が違います。目安として次のように考えます。

要素 直接コピペ リッチテキスト DOCX 最終確認
見出し 環境依存 比較的残しやすい 構造として残しやすい Wordの見出しスタイルを確認
太字・リンク 比較的残りやすい 残しやすい 残しやすい URL・装飾を確認
箇条書き 階層が崩れる場合あり 書式として渡しやすい 構造として残しやすい 親子関係を確認
表 コピー元次第 Word側で調整が必要な場合あり 表として扱いやすい 列幅・改ページを確認
画像 コピー方法に依存 自動埋め込み前提ではない Yomuでは自動埋め込みしない Word側で挿入
数式・複雑なレイアウト 不安定 不安定 完全再現はしない Word側で仕上げる

特に画像は、Markdown内のURLやローカルパスを見ただけで自動的にDOCXへ埋め込む設計ではありません。必要な画像はWord側で挿入してください。

表は「データが移ったか」と「読みやすいか」を分ける

Markdown表からWordへ内容を移せても、列幅やページ内の収まりまで自動で最適になるとは限りません。

列数が多い表では、次を確認します。

  • セル内容が欠けていないか
  • 列幅が極端になっていないか
  • ページをまたいだときに読みにくくないか
  • スマートフォンではなく、提出・印刷時のWord表示で問題ないか

技術的に変換できることと、提出物として読みやすいことは別です。

リッチテキストとDOCX、どちらを選ぶか

判断基準は「Wordでこのあとどの程度編集するか」と「原稿の構造がどれだけ複雑か」です。

リッチテキストは、数ページ未満の文章をWordへ持っていき、そのまま人間が編集を続ける用途に向きます。ファイル生成を挟まず、コピー&ペーストで作業をつなげられます。

DOCXは、見出し・表・長文の構造をまとめて移したい場合に向きます。提出・共有用のWordファイルとして残したい場合にも分かりやすい方法です。

どちらも、Word固有のテンプレートや高度なレイアウトまで完全再現するためのものではありません。

何度も同じ形式へ変換するならPandocも選択肢

毎回同じスタイルで大量のMarkdownをDOCXへ変換する場合は、PandocのようなCLIツールが向いています。Yomuはブラウザで単発〜反復の変換を簡単に行う用途、Pandocはスクリプト化・大量変換・Wordテンプレート適用を含む自動化に向きます。

terminal
pandoc input.md -o output.docx

Pandocでは--reference-docを使い、Word側のスタイルや文書プロパティを継続的に揃える運用もできます。

ただし、一度きりのChatGPT原稿をWordへ持っていく用途では環境構築が増えるため、最初の3択には含めません。自動化や大量変換が必要になった時点で検討すれば十分です。

複数媒体へ使うならMarkdownを原本として残す

同じ原稿をWordだけでなくnote、WordPress、はてなブログへ展開する場合は、媒体ごとに別原稿を作るよりMarkdownを原本として残す方が管理しやすくなります。

noteへ持っていく場合は、ChatGPT・Claudeをnoteにコピペすると崩れる?で、直接貼り付けとnote向け変換を比較しています。

WordPressへ持っていく場合は、ChatGPTのMarkdownをWordPressに貼ると崩れる?でGutenbergブロックへの変換手順を整理しています。

公開前・業務原稿では処理場所も確認する

未公開記事や業務文書を扱う場合は、変換精度だけでなく、本文をどこへ送るかも確認します。

YomuではMarkdownの編集、リッチテキスト生成、DOCX生成をブラウザ内で行い、変換のために本文を外部の変換サーバーへ送らない構成です。

オンラインMarkdownエディタの確認ポイントは、オンラインMarkdownエディタは安全?で整理しています。

よくある質問

ChatGPTの回答をWordに貼ったら`##`や`**`が残るのはなぜ?

コードブロックや.mdファイルから生のMarkdownをコピーすると、記号が文字として残ることがあります。AI画面に表示済みの文章をコピーしているか、Markdownソースをコピーしているかを先に切り分けます。

リッチテキストとDOCX、どちらを使えばいい?

数ページ未満の文章をWordへ持っていき、そのまま編集を続けるならリッチテキストです。見出し・表・長文の構造をまとめて移したい、提出・共有用のWordファイルとして残したいならDOCXです。

DOCXにしたら画像が入っていないのは?

YomuはMarkdown内のURLやローカルパスを見て自動的にDOCXへ画像を埋め込む設計ではありません。必要な画像はWord側で挿入してください。

Wordの「見出し1」「見出し2」のスタイルまで自動で合う?

組織固有のスタイルまで完全に合わせる用途では、貼り付け後にWord側でスタイル調整が必要です。毎回同じスタイルで大量に変換するなら、--reference-docを使えるPandocも選択肢です。

まとめ

ChatGPTの回答をWordへ移すときは、最初から複雑な方法を選ぶ必要はありません。

  • 数段落なら、まず直接コピー
  • Wordで編集を続けるなら、Yomuからリッチテキストをコピー
  • 見出し・表・長文の構造を残したいなら、YomuからDOCXを保存

画像、数式、複雑なページレイアウトはWord側の追加調整が必要です。逆に、文章構造を移すことが目的なら、用途に応じて3つを使い分けるだけで手直しをかなり減らせます。

YomuでMarkdownをWord向けに整える

参考

← ブログ一覧へ