MarkdownをPDFに変換する方法

Markdownは書くのに最適な形式です。シンプルな構文で読みやすく、どこでも動きます。しかし、Markdownを使わない人(ほとんどの人)と文書を共有する必要があるときは、PDFが普遍的なフォーマットになります。ブラウザベースのMarkdownからPDFへの変換ツールは、コンテンツをサーバーにアップロードせずに、変換作業全体をローカルで処理します。

MarkdownをPDFに変換する理由

• 文書の共有: PDFはどのデバイスでも同じ見た目になります。Markdownファイルにはレンダラーが必要です。
• 印刷: Markdownにはページサイズや余白の概念がありません。PDFは印刷レイアウトを適切に扱います。
• プロフェッショナルな見た目: 適切な見出しスタイル、余白、ページ区切りを持つPDFは、生のMarkdownファイルよりも洗練されて見えます。
• 提出物: 多くの職場、学校、クライアントはPDF形式を求めます。
• アーカイブ: PDF/AはISO標準の長期保存フォーマットです。Markdownはそうではありません。
• メールの添付: PDFはあらゆるメールクライアントで安定して表示されます。Markdownは多くのクライアントで生のテキストとして表示されます。
• 法的記録と監査証跡: 署名されたPDFはほとんどの法域で認められますが、Markdownファイルは認められません。

MarkdownをPDFに変換する手順

1. Markdownを貼り付ける: コンテンツをエディタに入力または貼り付けます。右側のパネルにライブプレビューが表示されます。
2. ページ設定をカスタマイズ: ページサイズ(A4、Letter、A3、A5)を選択し、必要に応じて余白を調整します。
3. 生成してダウンロード: 「PDF生成」をクリックして文書を作成し、すぐにダウンロードできます。

Markdownの簡単な歴史

Markdownは2004年にJohn Gruberによって作られ、Aaron Swartzから大きな貢献がありました。Gruberの目的は、執筆に向いた構文を作り、それがそのまま読めて、HTMLにレンダリングできる形にすることでした。ほとんどの人が直接書かなければならなかった煩雑なHTMLを置き換えるためです。元の仕様は意図的にシンプルで、見出し、太字、斜体、リンク、リスト、引用、コードだけでした。

このフォーマットは爆発的に広まりました。2010年までに、Stack Overflow、GitHub、Reddit、そしてほとんどの開発者向けサイトがMarkdownを採用しました。CommonMark(2014年)は、Gruberの元の仕様にあった曖昧さを修正するために構文を標準化しました。GitHub Flavored Markdown(GFM)は、元のMarkdownになかったテーブル、タスクリスト、取り消し線などの機能を追加しました。

今日、Markdownは技術的な文章のリンガフランカ(共通語)です。GitHubのREADMEファイル、ドキュメントサイト(Docusaurus、MkDocs、VuePress)、ブログ(Hugo、Jekyll、Eleventy、Astro)、ノートアプリ(Obsidian、Notion、Bear)、チャットツール(Discord、Slack、Element)などで使われています。人間が読めるソースと、HTMLおよびPDFへの安定したレンダリングという組み合わせが、Markdownが新しいフォーマットに取って代わられない理由です。

Markdown構文クイックリファレンス

作成できる文書の例

• 技術文書: APIリファレンス、社内Wikiページ、運用手順書、納品物として印刷するプロジェクトREADME
• レポートとケーススタディ: コードブロック、テーブル、図を埋め込んだ調査資料
• 履歴書とCV: テキスト中心のクリーンなフォーマットからプロフェッショナルなPDFへ書き出します
• 学術論文とノート: 講義ノート、学習ガイド、章の下書き
• ビジネス文書: 議事録、提案書、業務プロセス変更の記録
• 書籍と電子書籍: 多くの著者が長文をMarkdownで下書きし、レビュー用にPDFに書き出します
• レシピ集、学習ガイド、日記: 構造が必要だがワープロソフトと戦いたくないものすべて

Markdownのフレーバー

パーサーごとに、Markdownのルールが少しずつ異なります:

• CommonMark: 標準化されたコアです。見出し、太字、斜体、リンク、リスト、コードブロック、引用ブロック。
• GitHub Flavored Markdown(GFM): テーブル、タスクリスト、取り消し線、自動リンク、生のHTMLのサポートを追加します。最も広く普及しているフレーバーです。
• MultiMarkdown / Pandoc Markdown: 脚注、引用、数式(LaTeXスタイル)、定義リスト、メタデータブロックを追加します。学術や書籍の文脈で使われます。
• AsciiDoc: より多くの機能(注意書き、インクルード、条件付きコンテンツ)を持つ別のフォーマットです。構文が異なるため、Markdownではありませんがよく比較されます。
• MDX: MarkdownにJSX(Reactコンポーネント)を加えたもの。Web専用で、PDFには綺麗にレンダリングされません。

ほとんどのブラウザベースのMarkdownからPDFへの変換ツールはGFMかCommonMarkを使います。脚注や引用の構文を使う場合は、変換ツールが対応しているかを生成前に確認しましょう。

出力のスタイリング

Markdownはプレーンテキストです。PDFにはスタイリングの判断が必要になります:

• フォント選択: ほとんどの変換ツールは本文にサンセリフ(Helvetica、Arial)、コードに等幅(Courier、Menlo)をデフォルトにします。カスタムフォントを選べるものもあります。
• コードハイライト: コードブロックの構文ハイライト(Prism.jsやhighlight.jsなどのライブラリを使用)はコードを読みやすくします。コードの多い文書ではこれを有効にしましょう。
• テーブルのスタイル: デフォルトのテーブルはシンプルです。一部の変換ツールは、明確さのためにストライプ行や枠線を提供します。
• 見出しの階層: H1は文書のタイトル(1文書に1つ)に、H2は主要セクションに、H3からH6は下位セクションに使います。レベルを飛ばすこと(H1からH4へ)は、スクリーンリーダーや目次ジェネレーターを混乱させます。
• ページ余白: 文書には20から25mmの余白が標準です。ポスターや密度の高いレイアウトには15mm。10mm未満の余白は窮屈に見えます。

よくある落とし穴

• コードブロックがページからはみ出す: 非常に長い行は折り返されるか切れます。長い行を分割するか、コードのフォントサイズを小さくしましょう。
• 画像が表示されない: 外部画像はアクセス可能なURLにある必要があります。base64データURI(![alt](data:image/png;base64,iVBOR...))を使うか、変換ツールが対応している場合は相対パスを使いましょう。
• テーブルがページ区切りで分割される: 長いテーブルは行の途中で分割されることがあります。ほとんどの変換ツールは「ヘッダーの繰り返し」を自動的に挿入できません。回避策として、テーブルを小さなテーブルに手動で分割しましょう。
• ハードコードされた改行が保持されない: Markdownの単一改行は改行になりません。末尾にスペース2つを置くか、空行を挿入する必要があります。これは「段落が一緒くたになった」問題の頻出原因です。
• 見出しが番号付けされない: Markdownは見出しに自動で番号を振りません。「1.1.1」スタイルの番号付けが必要な文書では、手動で追加するか、カウンタに対応した変換ツールを使う必要があります。
• 数式がレンダリングされない: 標準のMarkdownには数式が含まれません。$E = mc^2$のように書いてLaTeX風のレンダリングを期待する場合、KaTeXまたはMathJaxに対応した変換ツールが必要です。
• URL内の特殊文字: 画像ファイル名のスペースはURLエンコード(my image.pngではなくmy%20image.png)しないと参照が壊れます。

検討に値する代替手段

• ブラウザの印刷からPDF: レンダリングされたMarkdownをブラウザで開き(任意のプレビューツール)、Ctrl/Cmd+PでPDFとして保存します。無料で即座に使えますが、スタイリングは限定的です。
• Pandoc: Markdown、PDF、DOCX、EPUB、LaTeX間の変換のためのコマンドライン定番ツール。機能が豊富(引用、テンプレート、数式)ですが、インストールが必要です。
• Typora: 高品質なPDF書き出しを備えた有料のデスクトップMarkdownエディタ。Markdownを毎日書く場合に最適です。
• Marp: プレゼンテーション用のMarkdown。スライドとしてPDFに書き出します。
• Eleventy / Hugo / Jekyll + PDFプラグイン: 記事のPDFバージョンを自動生成したい静的サイト作者向け。

一度きりの文書やほとんどの執筆作業には、ブラウザベースの変換ツールが最速です。執筆ワークフローで繰り返し使う場合は、PandocまたはTyporaのセットアップに価値があります。

使いこなしのヒント

• 生成前にプレビューする: ライブプレビューで見出し、リスト、コードブロックが正しく見えるか、PDF作成前に確認しましょう。
• 構造には見出しを使う: 見出しはPDF内の明確な文書階層を作ります。タイトルには#、セクションには##、サブセクションには###を使います。
• ページ区切りを追加する: 新しいページを強制したい場合は、インラインHTMLを使えます: <div style="page-break-after: always"></div>。
• コードブロックは短く保つ: 非常に長いコードブロックはPDFのページ幅をはみ出すことがあります。必要に応じて小さな塊に分割しましょう。
• A4とLetterの両方でテストする: 文書が異なる国で印刷される可能性がある場合、A4(国際標準)とUS Letter(北米標準)の両方で見栄えがいいか確認しましょう。
• Markdownリンターを使う: markdownlintなどのツールは、PDFで視覚的な不具合として現れる書式の不一致(末尾スペース、リスト記号の混在)を検出します。CLIツールやVS Codeの拡張機能として無料で利用できます。
• プラットフォームのフレーバーに合わせる: 読者がGitHubで読む場合、GFM機能(タスクリスト、テーブル)を使いましょう。Pandocで公開する場合は、脚注や引用が使えます。

プライバシーと機密文書

MarkdownからPDFへの変換ツールは完全にブラウザ内で動作します。貼り付けたMarkdownソース、生成されたHTMLプレビュー、最終的なPDFはすべてデバイス上に留まります。サーバーへのアップロード、ロギング、第三者との共有は一切ありません。

これはMarkdown文書がしばしば機密性の高い内容を含むからです。NDAの下にある技術仕様、社内ドキュメント、未発表の原稿の下書き、個人的な観察を含む調査ノート、技術形式の財務レポートなどです。クラウド型のMarkdownからPDFサービスは、設計上、コンテンツをサーバーに送信します。一部のサービスは「改善」や分析のために入力を保持します。機密性の高いMarkdownコンテンツには、ブラウザベースの変換ツールの方が安全です。

ブラウザベースの変換は、ページを一度読み込めばオフラインでも動作するため、出張中や飛行機の中で作業するときに便利です。