WindowsでWordをMarkdownに
ローカル変換する方法

DOCXをMarkdownへ変換して生成AIやRAGへ渡すなら、変換できたことだけでなく、見出し、表、画像、出典、警告を人間が確認できる状態にすることが重要です。

ローカル変換を選ぶべきケース

社内規程、提案書、設計書などを扱う場合、変換のためだけに第三者サービスへ文書をアップロードしたくないことがあります。その場合は、処理する端末と出力先を自分で管理できるローカル変換が候補になります。

ただし「ローカル」は安全性認証を意味しません。端末、OS、保存先、バックアップ、利用する変換ツールの依存関係は、利用者側でも確認が必要です。

Word文書にはコメント、変更履歴、文書プロパティ、hidden textなどが含まれる場合があります。Microsoftも、共有前に原本のコピーでDocument Inspectorを使う手順を案内しています。

WindowsでDOCXをMarkdownへ変換する2つの方法

1. PandocのCLIで変換する

PandocはDOCXを入力形式として扱える汎用コンバーターです。インストール後、たとえば次のようにGitHub Flavored Markdownへ変換できます。

pandoc input.docx --from=docx --to=gfm --output=output.md

Pandocの公式ガイドも、変換元の表現力がMarkdownより高い場合、複雑な表や書式などの変換はlossyになり得ると説明しています。CLIで再現しやすい一方、変換後の警告整理やレビュー記録は別途設計します。

2. MDDのGUI / CLIで変換・監査する

MDDはWindows向けのローカル変換、ルールベースの品質確認、構造化レビューを一つの工程にまとめるEarly Access準備中のツールです。DOCXは現在の製品方針でStable扱いですが、複雑な表や画像配置は確認対象です。

MDD Score、警告、変換レポート、source hashを出力し、人間のコメントや改善案を元Markdownとは別のJSONLへ保存します。MDD Scoreは内容の正確性を保証する指標ではありません。

生成AIへ渡す前の確認7項目

1. 見出し階層WordのスタイルがMarkdownの見出しへ正しく対応し、章の親子関係が崩れていないか確認します。
2. 箇条書きと番号番号の継続、入れ子、チェック項目が単なる段落へ変わっていないか確認します。
3. 表の意味列見出し、結合セル、注記が平坦化されても意味を読み取れるか確認します。複雑な表は原文を併記します。
4. 画像・caption・埋め込みobject画像の参照、caption、図中の重要情報が欠けていないか確認します。OCR済みと推測しません。
5. リンク・脚注・hidden informationリンク先、脚注、コメント、変更履歴、metadata、hidden textを共有範囲に含めてよいか確認します。
6. 警告とMDD Score警告をゼロにすることを目的にせず、表や画像など人間が確認すべき箇所を特定します。
7. source hashとreview JSONLどの原本から生成したかをhashで追跡し、人間の判断は元Markdownを直接変更せず別の記録として残します。

Markdown本文を変えずに、レビューをJSONLへ分けて残す手順も参照してください。

DOCXの表・画像にwarningが出た後、原本と照合する場所も確認できます。

AI / RAGへ渡す前のhandoff手順

1. 原本を変更せず、作業用コピーを用意する。
2. 必要に応じてWordのDocument Inspectorでhidden informationを確認する。
3. ローカル変換を実行し、出力Markdownと変換レポートを分けて保存する。
4. 上の7項目を確認し、未確認箇所を警告またはレビューとして残す。
5. 利用するAI / RAG側の保存、学習利用、アクセス制御を別途確認する。
6. 原本、変換物、AIへ渡した版の対応関係をhashまたはmanifestで残す。

よくある質問