AIに、そのまま提出できるWordで作って、と頼むと、たいていそれらしいファイルが返ってきます。全部AIに任せたら全部できた、という報告は、どこで崩れても原因の場所が分からない、という報告とほぼ同じ意味です。文章を書く仕事と、形式を変換する仕事が、一つの箱の中で混ざっているからです。この記事では、文書の形式を相互に変換するPandoc（パンドック）の基本を押さえたうえで、AIには中間の形式までを書かせ、変換はPandocに任せる分け方が、なぜ誤りの場所を特定しやすくするのかを示します。
Pandocは、同じ入力に同じ結果を返す変換器です
Pandocは、さまざまなマークアップ言語や文書形式を相互に変換するコマンドラインの道具です。John MacFarlane氏を中心に開発が続けられ、GitHubでソースが公開されています。Windows、macOS、Linuxで使えます。主な対応形式は、Markdown、LaTeX、HTML、Word（DOCX）、LibreOfficeの形式（ODT）、EPUB、PDF、AsciiDoc、reStructuredText、EmacsのOrg modeなどです。
変換の幅に加えて、出力の見た目を決める雛形を差し替えるテンプレート、変換の途中で中身を加工するフィルタ（PythonやLuaで書け、Luaフィルタは本体との相性がよい）、BibTeXなどの文献データからAPAやChicagoの書式で参考文献の一覧を作る機能、LaTeXの数式をPDFで同じ品質に表示する機能があります。
そして、ここが要点です。Pandocは、同じ入力と同じ設定からは、毎回同じ出力を返します。確率で文章を選ぶAIとは、性質が正反対の道具です。
継ぎ目にMarkdownを置くと、誤りの場所が分かれます
AIの仕事を、見出しや箇条書きや表を含む原稿をMarkdownで書くところまでにし、WordやPDFへの変換をPandocに任せると、作業が二つの箱に分かれます。見出しの中身が違う、事実が誤っている、という問題は文章の箱で起きています。表の罫線が崩れる、フォントが化ける、という問題は変換の箱で起きています。どちらの箱かが分かれば、直す相手も分かります。
インストールは、macOSならHomebrew、WindowsならChocolateyやScoop、LinuxならaptやdnfといったパッケージマネージャーでPandocを入れるのが手軽です。公式のリリースページから入手する方法や、Dockerの公式イメージ（pandoc/core）を使う方法もあります。使い方の基本は次のとおりです。
pandoc 入力ファイル -o 出力ファイル
pandoc README.md -o README.docx
pandoc -f markdown -t docx 原稿.md -o 原稿.docx形式はファイルの拡張子から推定され、うまくいかないときは入力と出力の形式をオプションで明示します。Markdownの冒頭にYAML形式でタイトル、著者、日付を書けば、表紙やヘッダに反映されます。PandocのMarkdownは脚注、表のキャプション、引用文献などの拡張も使えます。既存のWord文書をMarkdownに変えてGitで版を管理する、複数のHTMLを一つのPDFにまとめる、EPUBの電子書籍を作る、Mermaid記法の図をフィルタでPDFやWordに含める、といった使い方もできます。
書式の崩れを毎回手で直している作業は、変換の仕組みに一度払えば済む費用を、担当者の残業で分割払いしている状態です。崩れの原因が直らないかぎり、支払いは文書の数だけ続きます。テンプレートを一度整えれば、同じ崩れは二度と起きません。
AIへの頼み方は、変換の前提を渡すことです
継ぎ目をうまく働かせるには、変換の箱が扱いやすい原稿を、文章の箱に書いてもらう必要があります。
社内向けの手順書の原稿を、Markdown で書いてください。
冒頭に YAML 形式で title と date を入れてください。
見出しは2段階まで、表は列が4列以内にしてください。
太字や絵文字は使わないでください。
Pandoc で Word に変換する前提です。変換の前提を伝えると、AIは崩れにくい書き方を選びます。変換の箱の制約が、そのまま文章の箱への制約になるわけです。ここで指定したことは、出てきた原稿をPandocに通す前に、自分の目で確かめられる項目でもあります。
PDFと日本語は、変換器の外の道具に左右されます
PDFへの出力には、Pandocの外に別の道具が要ります。基本はLaTeXのエンジン（pdflatex、xelatex、lualatexなど）を経由し、wkhtmltopdfやweasyprintでHTML経由にする方法もあります。Pandocだけを入れてPDFが出ないときは、まずここを疑います。日本語のPDFでは文字化けやフォントのエラーが起こりがちなので、日本語に対応したエンジンを選んで指定し、テンプレート側で日本語フォントを設定します。
pandoc 原稿.md -o 原稿.pdf --pdf-engine=lualatexほかにも、特殊なLaTeXのコマンドやWordの機能は変換されない場合があり、段組みのような複雑なレイアウトは完全には再現できないことがあります。画像を相対パスで指定すると、実行する場所によって読み込めないので、画像を探す場所をオプションで指定するか、絶対パスで書きます。定期的に変換するなら、Makefileやスクリプトにまとめます。
この分け方が割に合わない場面もあります。一度きりの短い文書で、体裁がほとんど問われないなら、AIに直接ファイルを作らせても困ることは少ないでしょう。段組みや複雑な表組みが必須の文書では、Pandocの変換のあとに手作業の仕上げが残ります。また、AIが直接ファイルを作る機能は変化が速く、いま書いた得手不得手がいつまで当てはまるかは分かりません。最新のAIならPDFも完璧に作れるはず、という期待は、毎回くじを引き直す運用を技術の進歩と呼んでいるだけかもしれません。同じ原稿から同じPDFが出ることを確かめる手段がないなら、完璧かどうかも確かめようがないからです。
あなたの職場で、AIが書いた文書の体裁を手で直している時間は、文書一本あたりどのくらいでしょうか。その崩れは、文章の箱と変換の箱の、どちらで起きているでしょうか。
この記事の背景にある考え方は、拙著『ChatGPT はじめてのプロンプトエンジニアリング』の2章「プロンプトエンジニアリングの基本」のうち、出力形式を扱う項に書きました。本書は「PDF形式での出力は、ChatGPTは苦手とします。」と書き、マークダウンで出力して外部で変換する道を示しています。この項を読むと、AIに最終の形まで作らせるのか、中間の形で受け取って別の道具に渡すのかを、自分の文書ごとに考えて選べるようになります。
AIの答えが物足りないとき、疑うべきはAIか、自分の言葉か。
『ChatGPT はじめてのプロンプトエンジニアリング』
AIは言葉でしか動かない。プロンプトを暗記するのをやめ、構成要素に分解して、自分の言葉で意図を込める力を鍛える本です。
読み終えたとき、手元に残るもの
- 必須、任意、形式の三つに分けたプロンプトの構造
- 回答の質を変える、意図を込めた生きたプロンプト
- 発注と検収は人が担う、AIとの役割分担
- 章末の演習プロンプト26題
4刷重版。全国の大学図書館65館が所蔵しています（2026年10月時点）。