【入門】MarkItDownで始めるAI資料活用術 ― PDFもExcel・WordもMarkdownに変換してLLMに渡す

Last updated at 2026-05-11Posted at 2026-05-11

株式会社パレットリンクの @BaspisKawaE です。

今回は便利ツールの導入手順・活用方法を紹介いたします。
よろしくお願いします！

はじめに

本稿は、Microsoft製のPythonツール MarkItDown を用いて、PDF・Excel・Word等の多様な資料をMarkdown形式へ変換し、LLM(大規模言語モデル)への入力資料として活用するまでの手順を記述するものである。

対象読者はPythonの知識を持たない入門者を想定している。
環境構築からワンコマンド運用までを一貫して解説するが、途中で仮想環境の作成やPowerShellプロファイルの編集といった操作が含まれる点はあらかじめ断っておく。

ただしいずれも、本稿の手順をそのまま追えば完了する内容である。

なお、未記載のエラーへの遭遇時や、各コマンドや操作の意味を深く理解したい場合は、本稿の該当部分をそのままLLMに貼り付けて解説を求めればよい。
本稿はLLM活用の入り口となる記事であり、解説の依頼先として同じくLLMを使うのは自然な選択である。

その際は、本記事のURL末尾に.mdを付けるとMarkdown版が表示されるので、Ctrl+A(スマホの場合は全選択機能)からコピーしてLLMに貼り付けるとよい。

1. MarkItDownとは

MarkItDownはMicrosoftが公開しているOSSのPythonツールであり、以下のフォーマットをMarkdownへ変換する機能を持つ。

PDF
Word(.docx)
Excel(.xlsx)
PowerPoint(.pptx)
画像(EXIF・OCR)
音声(文字起こし)
HTML(WebページURL / ローカルHTMLファイル両対応)
CSV / JSON / XML
ZIPファイル(内部を再帰的に処理)
YouTubeのURL(メタデータ・概要欄等の外部情報を取得)
EPub

MarkItDownはあくまで機械的な変換ツールである。
出力されたMarkdownはそのままLLMへ渡すことも可能であるが、フォーマットによっては不要な情報が大量に混入する場合がある。

実運用では、まずLLMに整形を依頼して出力を読み取りやすい形に整え、必要に応じて別工程で要約や分析を行うという二段構えが安定する。
整形と要約は目的が異なるため、同一のプロンプトで同時に依頼せず、それぞれ分けて行うことが品質を保つ鍵となる(詳細はセクション6で解説する)。

1.1 なぜ変換が必要なのか

コンピュータが扱うデータは大きく「テキスト」と「バイナリ」の2種類に分類される。

テキストは人間が読める文字の羅列であり、.txt や .md がこれにあたる。
一方、バイナリは文字情報以外のデータ(フォント・レイアウト・画像・メタデータ等)を0と1で直接エンコードした形式であり、PDFや画像・動画がこれに該当する。

PDFが同じ文章量の .txt より大幅にファイルサイズが大きくなるのはこのためである。
LLMにバイナリファイルをそのまま渡すことは技術的に不可能ではないが、ファイルサイズが大きいほど処理コストが上昇し、変換・抽出処理が失敗するリスクも増す。

MarkItDownはこの問題に対して2つの価値を提供する。

データ量の削減： バイナリ形式に含まれる装飾・レイアウト情報を除去し、テキスト情報のみを抽出することでファイルサイズを大幅に圧縮する
受け渡しの安定： プレーンなMarkdownテキストに統一することで、LLMへの入力が安定し、解釈ミスや読み取り失敗が起きにくくなる

なお、変換・抽出処理はドキュメントの構造や品質によって失敗することがある。
特にスキャンPDFや複雑なレイアウトを持つファイルでは出力が不完全になる場合があることを留意されたい。

2. 事前準備：Pythonのインストール

2.1 Pythonが存在するか確認する

PowerShellを開く。開き方は以下のいずれかである。

スタートボタンを右クリック → 「ターミナル」(Windows 11) / 「Windows PowerShell」(Windows 10)
Win + X キー → 「ターミナル」を選択
スタートメニューで「PowerShell」または「ターミナル」を検索して起動

開いたら以下を実行する。

python --version

Python 3.13.x もしくはそれ以降のバージョンが表示された場合はすでに有効なPythonが存在する。

Python 3.13系 が表示された場合 → セクション3へ進む
Python 3.14系 が表示された場合 → セクション3へ進んでよいが、2.2末尾の補足(3.13系推奨の理由)を一読されたい
それ以前(3.12系以下) → 可能であれば3.13系への更新を推奨

以下のいずれかに該当する場合はインストールが必要である。

コマンド自体が認識されない('python' は内部コマンドまたは外部コマンド... と表示される)
Microsoft Storeが自動で開く、または Python was not found; run without arguments to install from the Microsoft Store と表示される(Microsoft Storeのダミーが引っかかっている状態)
Python とだけ表示されてバージョン番号がない

2.2 Pythonをインストールする

【重要】Microsoft Storeからはインストールしないこと

Microsoft Store経由でインストールされたPythonは、通常と異なるディレクトリ配置(pythoncore-3.14-64 等)を取り、pipの依存解決が不安定になる事例が検証環境で確認されている。
本稿では python.org公式サイト からのインストールを推奨する。

python.orgのダウンロードページにアクセスし、Python 3.13系の最新版 をダウンロードする。

インストーラを起動したら、最初の画面で 以下の項目を必ずチェックすること。

☑ Add python.exe to PATH

この設定を省略すると、インストール後もコマンドが認識されない。

インストールが進行する。

「Setup was successful」と表示されれば完了である。

インストール完了後、PowerShellを新しく開き直し、再度バージョンを確認する。

python --version
# → Python 3.13.x が表示されればOK

pip --version
# → pipのバージョンとパスが表示される

なぜPython 3.14系ではなく3.13系を推奨するのか

Python 3.14系は2025年10月7日にリリースされた最新メジャーバージョンである。
一方、MarkItDownが依存する多数のパッケージ(pandas, lxml, onnxruntime等)の中には、3.14系への対応が追いついていないものが存在する可能性がある。

検証環境ではPython 3.14系でmarkitdownのインストールが依存解決に失敗し、古いバージョン(0.0.2)が選択される事象が再現した。
この挙動はGitHub Issue #1470にて報告されているPython 3.14サポートの未完了状態と整合する。
安定版である3.13系を用いることでこの問題を回避できる。

ただし、Python 3.14系がすでにインストールされており、かつ本稿の手順通りに markitdown[all] のインストールが問題なく完了する場合は、そのまま3.14系で運用を続けて差し支えない。
本稿が3.13系を推奨する理由は「入門者がトラブルに遭遇する確率を下げる」ことにあり、3.14系の使用自体を禁止するものではない。

3. MarkItDownのインストール

MarkItDownは 仮想環境(venv) を作成してその中にインストールする。

3.1 なぜ仮想環境を使うのか

Pythonパッケージをグローバル環境に直接インストールすると、他のツールとバージョンが衝突し、「昨日まで動いていたのに今日は動かない」という状態を引き起こすことがある。

仮想環境は、用途ごとに独立した箱を作り、その中だけでパッケージを管理する仕組みである。
MarkItDown専用の箱を用意することで、他の作業に影響を与えず、かつ壊れても作り直しが容易になる。

入門者こそこの習慣を身につけておくことを強く推奨する。

3.2 仮想環境を作成する

【雛形】

# 作業ディレクトリを作成
mkdir <インストール先ディレクトリ>
# 作業ディレクトリへ移動
cd <インストール先ディレクトリ>
# venv環境を作成
python -m venv venv

【例：Dドライブ直下に配置する場合】

mkdir D:\markitdown-env
cd D:\markitdown-env
python -m venv venv

venv という名前のフォルダが作成され、内部に独立したPython実行環境が構築される。

【重要】ここで決めたパスは、以後のセクション(3.3・3.4・4章のプロファイル設定)で繰り返し使用する

本稿では D:\markitdown-env を例として用いるが、Dドライブを持たない環境ではこのパスを適宜書き換える必要がある。
書き換える場合、後続のコマンドやプロファイル内のパス指定もすべて同じ場所に揃えること。 片方だけ書き換えると整合が取れなくなり、関数が動作しなくなる。

Dドライブがない環境で推奨される置き場所の例：
C:\Users\<ユーザー名>\markitdown-env
(ユーザーフォルダ配下であれば権限面のトラブルが起きにくい)

3.3 仮想環境を有効化する

.\venv\Scripts\Activate.ps1

プロンプトの先頭に (venv) と表示されれば成功である。

補足： 「このシステムではスクリプトの実行が無効になっているため...」というエラーが出る場合は、セクション5.2を参照されたい。

3.4 MarkItDownをインストールする

有効化された状態(プロンプト先頭に (venv) がある状態)で、以下を実行する。

python -m pip install "markitdown[all]"

補足： シングルクォート(')はPowerShellで誤動作することがあるため、ダブルクォートを推奨する。

3.5 動作確認

markitdown --version

バージョン番号(例：markitdown 0.1.5)が表示されれば設定完了である。

補足： 実行時に Couldn't find ffmpeg or avconv という警告が表示されることがあるが、これは音声ファイル変換時のみに関係する警告であり、PDF/Word/Excel変換には影響しない。無視してよい。

確認が済んだら、仮想環境を抜ける。

deactivate

4. ワンコマンド保存の設定

毎回仮想環境を有効化し、オプションを指定して変換するのは手間である。そこでPowerShellのプロファイルに関数を登録し、venv内のMarkItDownを直接呼び出す形で運用する。

本セクションで設定する md-save コマンドは、PowerShellプロファイルに登録することで、どのディレクトリからPowerShellを起動しても利用できるようになる。

「デスクトップで開いたPowerShellでも」「エクスプローラの任意のフォルダで右クリックから開いたPowerShellでも」、常に同じ md-save コマンドが使える状態になる。

本セクションの運用方針について

本セクションでは、仮想環境の有効化を省略して、どのディレクトリからでも一発で変換できる運用方法を解説する。プロファイル関数からvenv内の実行ファイルをフルパスで呼び出すため、以下の特徴がある。

どのPowerShellセッションからでも md-save が使える
毎回 Activate.ps1 を実行する必要がない
一方で、D:\markitdown-env （あるいは任意で指定したパス）を移動・削除すると関数が動かなくなる

LLM資料変換という単一用途を想定し、利便性を優先した構成としている。

4.1 プロファイルファイルを作成する

プロファイルが存在しない場合は以下で作成する。

New-Item -Path $PROFILE -ItemType File -Force

4.2 プロファイルを編集する

notepad $PROFILE

以下の内容を記述する。

【雛形】

$OutputEncoding = [System.Text.Encoding]::UTF8
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

function md-save {
    param([string]$source)
    $venvExe = "<インストール先ディレクトリ>\venv\Scripts\markitdown.exe"
    $dir = "<保存先ディレクトリ>"
    $filename = "$(Get-Date -Format 'yyyyMMdd_HHmmss').md"
    & $venvExe $source -o "$dir\$filename"
    Write-Host "Save!: $dir\$filename"
}

【例：3.2でDドライブ直下を選んだ場合】

$OutputEncoding = [System.Text.Encoding]::UTF8
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

function md-save {
    param([string]$source)
    $venvExe = "D:\markitdown-env\venv\Scripts\markitdown.exe"
    $dir = "D:\markitdown"
    $filename = "$(Get-Date -Format 'yyyyMMdd_HHmmss').md"
    & $venvExe $source -o "$dir\$filename"
    Write-Host "Save!: $dir\$filename"
}

この関数は、venv内のMarkItDown実行ファイルをフルパスで直接呼び出す。そのため、毎回 Activate.ps1 を実行する必要がない。
$source はURLとローカルファイルパスの両方を受け付ける。

$venvExe は3.2で作成した仮想環境内の実行ファイルを指す。
$dir は4.3で作成する保存先ディレクトリを指す。
この2つのパスは必ず自分の環境に合わせて書き換えること。

【最重要】プロファイルは「UTF-8(BOM付き)」で保存すること

Microsoft公式ドキュメントによれば、Windows PowerShell 5.1 はBOM(バイトオーダーマーク)のないテキストファイルを ANSIコードページ(日本語環境ではShift-JIS / CP932) として解釈する。
そのため、UTF-8で書かれたプロファイルをBOMなしで保存すると、非ASCII文字を含む箇所で読み込み時に文字化けが発生する。
パス文字列やメッセージに日本語が含まれる場合、文字化けで構文そのものが崩れ、プロファイル全体が読み込めなくなるケースもある。

【メモ帳での保存方法(Windows 11)】

「名前を付けて保存」ダイアログ下部にあるエンコードの選択肢で UTF-8 (BOM 付き) を選ぶ。
Windows 10以前のメモ帳ではデフォルトで「UTF-8」が常にBOM付きだったが、Windows 11のメモ帳ではBOMなしUTF-8が既定となっているため、明示的な指定が必要である。

【PowerShellでBOM付きに変換する方法】

既にBOMなしで保存してしまった場合、以下のコマンドで強制的にBOM付きに変換できる。

$content = Get-Content $PROFILE -Raw -Encoding UTF8
$utf8Bom = New-Object System.Text.UTF8Encoding($true)
[System.IO.File]::WriteAllText($PROFILE, $content, $utf8Bom)

4.3 保存先ディレクトリを作成する

【雛形】

mkdir "<保存先ディレクトリ>"

【例：Dドライブ直下に保存する場合】

mkdir "D:\markitdown"

ここで作成したディレクトリが、4.2のプロファイル内 $dir と一致している必要がある。

4.4 動作確認

PowerShellを再起動し、以下を実行する。

md-save "D:\path\to\file.pdf"

指定ディレクトリにタイムスタンプ付きのMarkdownファイルが生成されれば成功である。

変換対象のパスを手早く取得する手法

Windows 11のエクスプローラでファイルを右クリックすると、「パスのコピー」という項目がある(ショートカット：Ctrl+Shift+C)。
これを使用すると、ファイルのフルパスがダブルクォート付きでクリップボードにコピーされる。
(例："D:\docs\report.pdf")
そのままPowerShellで md-save と入力した後にペーストすれば、引数が完成する。変換対象がローカルファイルの場合、この方法が最も速い。

5. 既知の注意事項

5.1 YouTubeは動画本文ではなく外部情報のみ取得される

YouTubeのURLを変換した場合、取得されるのはメタデータ(タイトル・キーワード・再生時間)と概要欄テキストのみである。
動画本文(話者の発言内容)は、字幕が有効な動画に限り取得できる。字幕が無効の動画では本文は得られない。

これを得る方法については、稿を改めて扱う。

5.2 スクリプト実行ポリシーの制限

仮想環境の有効化(Activate.ps1)実行時などに、以下のエラーが表示された場合、

このシステムではスクリプトの実行が無効になっているため...

以下のコマンドで解除する。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

5.3 PDF変換時のフォント警告

PDFを変換する際、以下のような警告が表示されることがある。

Could not get FontBBox from font descriptor because None cannot be parsed as 4 floats

これはpdfminer-sixがPDF内部のフォント記述を解析する際に、一部のフォントで境界ボックス情報が取得できなかったことを示す警告である。
変換自体には影響せず、出力されるMarkdownの品質も損なわれないため、無視してよい。

5.4 音声関連の警告

起動時に以下の警告が出ることがある。

Couldn't find ffmpeg or avconv - defaulting to ffmpeg, but may not work

これは音声ファイル変換機能が使用するffmpegが見つからないという警告である。
音声を扱わない限り無視してよい。
音声変換を行う場合は別途ffmpegをインストールする必要がある。

6. 活用例

# PDFを変換
md-save "D:\docs\report.pdf"

# Excelを変換
md-save "D:\docs\data.xlsx"

# Wordを変換
md-save "D:\docs\spec.docx"

# YouTubeを変換(概要欄・メタデータを取得)
md-save "https://www.youtube.com/watch?v=xxxxxxxxx"

# Webページを変換(ローカルHTMLファイルもURLもOK)
md-save "https://example.com/article"

生成されたMarkdownファイルはLLMへの入力として使用する。

6.1 整形と要約は別工程として分離する

実運用では、変換直後の出力をLLMに渡すにあたり、整形と要約・分析を別工程として分けることを推奨する。
この2つは目的がまったく異なるため、同一のプロンプトで同時に依頼すると、LLMがどちらを優先すべきか判断できず、結果の品質が不安定になる。

整形： 原文の意味を一切変えず、不要な情報を除去して読みやすい構造に整える(形式の変換)
要約・分析： 原文の内容を理解した上で、短く言い換えたり、ポイントを抽出したりする(意味の解釈)

特にExcelファイルの変換結果は、セルのメタデータや空白行・書式情報が大量に混入して著しく肥大化することが多く、整形工程の効果が顕著に現れる。
他のフォーマットについても、整形を一段挟むことで後続の対話の安定性が大きく向上する。

6.2 整形プロンプト(事実情報を保持する)

まず、LLMに整形のみを依頼するプロンプトを以下に示す。
意味内容の変更・要約・補足・解釈を禁止することが重要である。

このMarkdownは○○をMarkItDownで変換したものです。
以下のルールに従って整形してください。意味内容の変更・要約・補足・解釈は一切行わないこと。

【除去】
- 空白行・重複行を除去する
- 書式の残骸(記号・不要なタグ等)を除去する

【整形】
- 見出し(#)を用いて構造を明示する
- 重要語句には強調(**)を付与する
- 引用・注釈は引用記法(>)で区別する

【禁止】
- 文章そのものの書き換え(言い換え・意訳・表現の変更)
- 要約・補足・解釈の追加
- 意味内容の削除・統合・並び替え

【許可】
- Markdown記法による整形(見出し化・強調付与・引用記法への変換等)
- 上記【除去】に該当する範囲での空白行・重複・書式残骸の削除

このプロンプトを適用した場合、変換前後の出力は概ね以下のように変化する。

整形前(MarkItDown変換直後)

プロジェクト概要

担当︓ ⼭⽥ 太郎
更新⽇︓ 2026年4⽉1⽇

このプロジェクトはA社向けの基幹システム刷新案件です。フェーズ1として要件定義を
4⽉中に完了させる予定です。注意点として、既存システムとの互換性を必ず確認するこ
と。

整形後(LLMによる整形済み)

# プロジェクト概要

- 担当：**山田 太郎**
- 更新日：2026年4月1日

このプロジェクトはA社向けの**基幹システム刷新案件**です。フェーズ1として**要件定義を4月中に完了**させる予定です。

> 注意：既存システムとの互換性を必ず確認すること。

整形済みのMarkdownは、原文の情報をすべて保持したまま、構造だけが整った状態になる。
この状態で保存しておけば、後日「この資料を要約して」「ここの意味を教えて」といった対話を行うときも、LLMが原文を正確に参照できる。

なお、LLMがこのプロンプトの禁止事項をどこまで厳密に守れるかは、モデルや入力の性質により変動する。
整形結果は必ず確認し、意味内容が変質していないかを目視で検証することを推奨する。

6.3 要約・分析プロンプト(意味を解釈する)

整形済みMarkdownを用いて要約や分析を行う場合は、別プロンプトとして明示的に指示する。
例を以下に示す。

以下のMarkdownを読み、要点を3点にまとめてください。
元の情報は変更せず、解釈した結果を新たに記述する形で回答すること。

[整形済みMarkdownをここに貼り付け]

6.4 なぜ整形と要約を分離するのか

この二段構えが有効な理由は、情報保全と情報加工の責任を明確に分離できることにある。

整形工程の出力は「事実情報のアーカイブ」として再利用できる
要約・分析工程の出力は「目的に応じた使い捨ての解釈」として扱える
後から別の観点で要約したくなった場合、整形済みMarkdownから再び別プロンプトを当てるだけで済む

もし整形と要約を同一プロンプトで依頼すると、LLMは「どこまでが原文でどこからが解釈か」を示しにくくなり、読み手側も判別できない。
加えて、要約の観点を後から変更したくなったときに、整形済みの中間成果物が手元に残らないため、変換からやり直す必要が生じる。

整形と要約を分離することで、変換→整形→(必要に応じて)要約という直列パイプラインが成立し、各工程の成果物をそれぞれ再利用できるようになる。
これがMarkItDownを運用する上での基本ワークフローとなる。

おわりに

MarkItDownは軽量ながら対応フォーマットが広く、LLMとの連携を前提とした設計思想を持つ。
本稿で解説した設定を一度行えば、以後はコマンド一発で資料をMarkdownへ変換できる。

実用上の基本ワークフローは以下の3段階である。

MarkItDownで変換する ― バイナリをMarkdownテキストへ機械的に変換する
LLMで整形する ― 不要な情報を除去し、事実情報を保持したまま構造を整える
必要に応じてLLMで要約・分析する ― 整形済みMarkdownを元に、目的に応じた解釈を得る

この流れを通すことで、「データ量の削減」「受け渡しの安定」「情報保全と加工の分離」というMarkItDown活用の価値が最大限に発揮される。

本稿の検証過程で得られた副次的教訓として、PowerShellプロファイルはBOM付きUTF-8で保存する ことと、Microsoft Store版Pythonを避ける ことの2点を挙げておきたい。
これらは一見些細に見えるが、実環境では長時間のトラブルシューティングを要する罠になりうるため、留意されたい。

参考リンク

microsoft/markitdown (GitHub) ― MarkItDown公式リポジトリ
markitdown (PyPI) ― パッケージ配布元
Python 3.13.13 Release ― 本稿の検証環境で使用したPythonバージョン
about_Character_Encoding - PowerShell | Microsoft Learn ― PowerShellの文字エンコーディング仕様
GitHub Issue #1470: Python 3.14 support ― Python 3.14系でのmarkitdown依存解決問題
Python MarkItDown: Convert Documents Into LLM-Ready Markdown (Real Python) ― MarkItDownの詳細な使用例と解説

検証環境：Windows 11 / PowerShell 5.1 / Python 3.13.13 / markitdown 0.1.5

パレットリンクでは、日々のつながりや学びを大切にしながら、さまざまなお役立ち記事をお届けしています。よろしければ、ぜひ「Organization」のページもご覧ください。
また、私たちと一緒に未来をつくっていく仲間も募集中です。ご興味をお持ちの方は、ぜひお気軽にお問い合わせください。一緒に新しいご縁が生まれることを楽しみにしています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up