microsoft/markitdown

AIに資料を読ませようとすると、最初に詰まるのはファイル形式のばらつきだ。手元にあるのは Word・Excel・PowerPoint・PDF・画像・音声で、そのままでは文字として渡せない。MarkItDown は、こうしたファイルを Markdown という一種類の文字の形に変換する Python の道具。README が挙げている対応元は、PDF、PowerPoint、Word、Excel、画像（付帯情報と、写っている文字の読み取り）、音声（付帯情報と書き起こし）、HTML、CSV・JSON・XML、ZIP（中身をたどる）、YouTube のURL、EPub など。

狙いは見た目の再現ではなく、構造を残すことにある。README は、見出し・箇条書き・表・リンクといった文書の骨格を Markdown として保つことを重視していると書いており、同時に、出力はそこそこ体裁が整っていて人にも読みやすいことが多いとしたうえで、渡す先として想定しているのはテキスト解析のツールで、人が読むための忠実さが要る変換には向かないかもしれない、とも書いている。ここを取り違えると期待が外れる。なぜ Markdown なのかの説明も添えられていて、ほぼ素の文字に近いのに構造を表せること、主要なLLMが Markdown を自然に扱うこと、トークンの効率がよいことが理由として挙がっている。

呼び出し方は2通り。コマンドで markitdown にファイルを渡す形と、Python から MarkItDown を呼ぶ形で、コマンドのほうは標準入力からも受け取れる。Docker で動かす手順も添えられている。第三者が作るプラグインの仕組みもあり、こちらは既定で無効になっていて、使うときに明示して有効にする。

手元の資料をまとめてAIに読ませたいとき

提案書がPowerPoint、見積がExcel、契約書がPDF、という状態のまま渡す方法はない。全部を同じ形にしてから渡せば、あとの処理は文字を扱うだけになる。入口を一本にするための道具だと考えると分かりやすい。

検索や分類の下ごしらえをしたいとき

社内の書類を検索できるようにする、分類する、要約する。どれも最初に「文字にする」工程が要る。表や見出しが残っていれば、そのあとで章ごとに切る・表だけ抜く、といった扱いもしやすくなる。

信用できない入力をそのまま渡さない。 README は冒頭と末尾の両方で警告していて、MarkItDown は実行しているプロセスの権限でファイルやネットワークにアクセスする、と書かれている。convert() は手元のファイルもURLもバイト列も受け取れる広い入口なので、外から来た値を扱うときは、用途に合った狭い関数（手元のファイルだけなら convert_local() など）を選ぶよう勧めている。サーバー側で動かす場合ほど効いてくる。

高い忠実さが要る変換には向かないかもしれない、と README 自身が断っている。 出力はテキスト解析のツールに渡すためのもの、というのが README の位置づけ。人が読む配布物を作り直す用途で当てにすると、期待とずれる。

形式ごとに部品が分かれている。 [all] で全部入れるか、[pdf, docx, pptx] のように選んで入れるかを決める必要がある。音声の書き起こしやYouTubeの字幕取得も、そのための追加指定がある。Azure につなぐ経路は2つあり（Document Intelligence と Content Understanding）、README の比較表はどちらも Azure の API 呼び出しとして課金されるとしている。とくに Content Understanding のほうは、そこに回す設定にした形式を変換するたびに API 呼び出し1回ぶん課金されると釘を刺している（回す形式は絞れる）。

この置き場所の役割は限定されている。 README は、Webサーバー・API・画面つきアプリの追加は受け付けない（別のプロジェクトとして作ってほしい）と明言している。ライブラリとコマンドとして使うものであって、そのまま社内サービスになるものではない。ライセンスは MIT。ただし Microsoft の商標の扱いには別途ガイドラインがある。