GitHubのREADMEをPDFに変換する方法（無料・ログイン不要）

READMEはブラウザ向けに書かれています。スクロールし、外部へリンクし、読者がリポジトリ内をクリックして回れることを前提としています。しかし、ドキュメントをクライアントに送る、課題に添付する、リリースを保管する、リポジトリをクローンしない人に渡す——そうした瞬間に必要なのは、持ち運びやすいPDFという形式です。

GitHubのページをそのまま印刷すると、たいていひどい結果になります。サイトのナビゲーション、サイドバー、フッターまで一緒に印刷されます。幅の広いコードブロックは切れ、相対画像はブラウザがリポジトリのルートを読まなくなるため表示が崩れ、長い表はページをまたいで不自然に分割されます。md2pdfは、アカウント作成もソースファイルのサーバーへのアップロードも求めることなく、こうした問題を解決するために作られました。

このガイドでは、リポジトリのURLを貼り付けるところから、書き出したPDFを確認するところまで、一連の流れを説明し、各ステップでツールが何をしているのかを解説します。

ブラウザの印刷ボタンだけでは不十分な理由

GitHubのWebインターフェースはWebアプリであり、印刷用スタイルシートではありません。リポジトリのページでCtrl+Pを押すと、ブラウザはページ全体を印刷しようとします。ヘッダー、ファイルツリー、「About」サイドバー、フィードバック用ウィジェットなど、レイアウトにあるものすべてです。一部は独自の印刷用スタイルシートで隠せますが、GitHubのマークアップを外から変更することはできません。

他にもよくある問題が3つあります。

• 相対画像パス。 ![diagram](docs/architecture.png)と書かれたREADMEは、画像がリポジトリを基準に解決されるためGitHub上では正しく表示されます。しかし印刷されたブラウザページにはリポジトリのコンテキストがなく、画像が消えてしまうことがあります。
• 幅の広いコードと表。 コードブロックや比較表は印刷ページより幅が広くなります。印刷専用のルールがないと、読めないほど縮小されるか、切り取られてしまいます。
• ページ分割。 見出し、コードブロック、表の行は、不自然な改ページを避ける必要があります。ブラウザのそのままの印刷では、これをうまく処理できることはほとんどありません。

md2pdfは、READMEの生のMarkdownを取得し、リポジトリからの相対URLを解決し、GitHub Flavored Markdownとしてレンダリングし、結果をサニタイズして、ブラウザの印刷ダイアログが開く前に印刷用スタイルシートを適用します。出力は引き続きブラウザ標準の「PDFとして保存」エンジンで生成されますが、そのエンジンが受け取る文書はすでに整えられています。

md2pdfが変えるもの

変換パイプラインはすべてブラウザ内で実行されます。具体的には次のとおりです。

1. 公開GitHubリポジトリのURL、ローカルのMarkdownファイル、または貼り付けたMarkdownを用意します。
2. リポジトリの場合は、既定ブランチを検出し、.github/内のファイルを含む一般的なREADMEファイル名を順に試します。
3. 相対画像パスはraw.githubusercontent.comに、文書リンクはGitHubのblobビューに書き換えられます。
4. MarkdownはGFM対応でレンダリングされます。表、タスクリスト、取り消し線、フェンス付きコード、自動リンクに対応します。
5. HTMLはプレビューに渡る前にDOMPurifyでサニタイズされます。
6. 文書に見出しが3つ以上ある場合、目次が生成されます。
7. 選択したテーマの印刷用スタイルシートが適用され、ブラウザが印刷ダイアログを開きます。

ファイルはアップロードされません。外部へのリクエストは、指定した公開リポジトリのREADMEと画像を匿名で読み取るもの、および既定ブランチを検出するためのGitHub API呼び出しだけです。このバージョンでは非公開リポジトリには対応していません。

始める前に

必要なもの：

• 公開GitHubリポジトリ、またはローカルのMarkdownファイル、または貼り付け可能なMarkdown。
• モダンなブラウザ。Chrome、Edge、Firefox、Safariはいずれも印刷ダイアログで「PDFとして保存」に対応しています。
• 短い文書なら約2分。PDFを1ページずつ確認する場合はもう少し時間がかかります。

リポジトリが非公開の場合、取得は失敗します。手動のフォールバックは引き続き使えます。READMEのテキストをコピーしてエディターに貼り付け、絶対画像URLを使用してください。

ステップ1：ツールにリポジトリを渡す

コンバーターを開き、GitHubリポジトリのURLフィールドにリポジトリのURLを貼り付けます。md2pdfは正式なURL以外も受け付けます。

https://github.com/owner/repo
https://github.com/owner/repo.git
github.com/owner/repo
owner/repo
https://github.com/owner/repo/tree/main/docs
https://github.com/owner/repo/blob/main/README.md

これらのURLはすべて同じowner/repoの組み合わせに解決されます。プロトコルなしのURLやowner/repoの短縮形は、ターミナルやチャットメッセージからコピーするときに便利です。余分なパスセグメントは便宜上受け付けられますが無視されます。アプリはURLに表示されたネストしたファイルではなく、既定ブランチのリポジトリ直下のREADMEを読み取ります。ネストしたファイルが必要な場合は、そのMarkdownを直接貼り付けてください。

取得を押すか、Enterを押します。フィールドが空の場合、アプリは何もせず黙っているのではなく、期待する入力を伝えます。

ステップ2：READMEを取得して解決させる

アプリはまずGitHub APIにリポジトリの既定ブランチを問い合わせます。次に、そのブランチに対してREADMEのファイル名リストを試します。一般的な大文字・小文字のバリエーションや.github/README.mdの場所も含まれます。APIがレート制限中でもraw取得は続行できるため、一時的なAPI障害が必ずしもワークフロー全体を止めるわけではありません。

Markdownが届くとプレビューが更新されます。ここで確認すべき点は3つです。

• 画像。 リポジトリからの相対画像が表示されるはずです。表示されない場合、非公開アセット、存在しないパス、ホットリンクをブロックする絶対URLのいずれかが原因かもしれません。
• コードブロック。 言語タグ付きのフェンスはコードとしてレンダリングされます。非常に長い行はプレビュー内でスクロールしますが、印刷時の確認は別途必要です。
• リンク。 文書内リンクはPDFでも意味が通るよう、GitHubのblobビューに書き換えられます。外部リンクはプレビューで新しいタブで開きます。

画像の読み込みに失敗しても、md2pdfはそれを壊れた画像として示し、処理を続けます。バッジが1つ利用できないだけでエクスポートが失敗することはありません。これは意図的な設計です。欠けたバッジは、通常、文書の他の部分より重要ではないからです。

ステップ3：文書に合うテーマを選ぶ

印刷テーマは4つあります。

• クリーンは既定のテーマです。ニュートラルなサンセリフ書体を使用し、仕様書、技術README、コードの多い文書に最も安全な選択です。
• ビジネスはセリフ書体と暗いコードブロックを使用します。レポート、提案書、クライアント向けの引き継ぎ資料に適しています。
• アカデミックは両端揃えのセリフページと軽いコード表現を使用します。長文の文章、コース資料、論文風の提出物向けに作られています。
• ダークは画面優先のテーマです。プレビューは快適に読めるよう暗くなり、印刷用スタイルシートが明るいインクと明るいコード背景を強制するため、PDFも判読できます。

より詳しい比較はクリーン vs ビジネス vs アカデミック vs ダークをご覧ください。初めてのエクスポートではクリーンから始め、文書に明確な読者層の期待がある場合にのみ切り替えるのがおすすめです。

ステップ4：目次が役立つか判断する

自動目次は既定で有効になっており、文書に見出しが3つ以上ある場合に生成されます。安定した一意の見出しスラッグを使用するため、各項目はプレビューの正しいセクションにリンクします。

次の場合は有効にしてください。

• 文書が数ページより長い。
• 読者が特定のセクションへ移動する必要がある。
• PDFの一部だけを印刷する可能性のある人に渡す。

次の場合は無効にしてください。

• READMEが短く、目次ブロックがナビゲーションよりもノイズになる。
• 文書にすでに手書きの目次がある。
• 1ページの配布資料を作成している。

この切り替えはプレビューと印刷出力の両方に反映されます。PDF専用の個別設定はありません。

ステップ5：適切な設定でPDFに印刷する

ライブプレビューパネルのPDFをダウンロード／印刷をクリックします。アプリがブラウザの印刷ダイアログを呼び出します。ダイアログでは次のように設定します。

1. 送信先をPDFに保存（またはブラウザでの同等の項目）に設定します。
2. 受け取る人の地域に合わせてA4またはレターを選択します。
3. 社内規定のスタイルがない限り、余白は既定のままにします。印刷用スタイルシートがすでにページ余白を設定しています。
4. 最初の試行では倍率を100%に保ちます。幅の広い表やコードブロックが切れる場合は、ソースのフォントを小さくするのではなく、倍率を少し下げてください。
5. ブラウザに項目があれば背景のグラフィックを有効にします。テーマのアクセント、コードブロックの背景、表ヘッダーの塗りは背景色に依存します。無効でもPDFは読めますが、ビジネスとダークは視覚的な構造の一部を失います。
6. 特にURLとページ番号が必要でない限り、ブラウザのヘッダーとフッターはオフにします。これらは文書デザインの一部ではありません。
7. わかりやすい名前を付けて保存します。例：owner-repo-readme-2026-10.pdf。

正確なラベルはブラウザによって異なります。ChromeとEdgeでは、背景のグラフィックは「その他の設定」にあります。Firefoxでは「背景を印刷」を探してください。Safariは表示される設定が少ないため、保存前にプレビューを確認してください。

ステップ6：送る前にPDFを確認する

保存したPDFを開き、印刷で露見しやすい問題を確認します。

• 改ページ。 見出しがページ末尾に単独で残ってはいけません。コードブロック、表、画像は途中で分割されないようにします。
• 幅の広いコンテンツ。 長いコード行と表は、あふれの最も一般的な原因です。切れている場合は、ソースの行を短くするか印刷倍率を下げてください。
• リンク。 PDF内のリンクをいくつかクリックします。GitHubのblobリンクは正しいファイルビューを開くはずです。
• 画像。 図やバッジが残っていることを確認します。欠けた非公開アセットはPDF内で自然に直ることはありません。
• メタデータ。 文書のタイトルと作成者は、専用のPDFメタデータフォームではなく、READMEとブラウザの印刷メタデータ設定に由来します。ファイル名はわかりやすく付けてください。
• 読みやすさ。 ページを100%で印刷し、本文が快適に読めるか確認します。アカデミックの両端揃えやビジネスのセリフ書体は、画面と紙で印象が変わることがあります。

取得に失敗したとき

アプリは取得の失敗を、実行可能なメッセージに変換します。よくあるケースは次のとおりです。

表示される内容	通常の意味	対処方法
リポジトリが見つからないか非公開	URLが間違っているか、リポジトリに認証が必要	URLを確認する。非公開リポジトリならMarkdownを手動で貼り付ける
READMEが見つからない	既定ブランチ、main、masterのいずれにもREADMEがない	ファイルをアップロードするか、Markdownを貼り付ける
GitHubのレート制限に達した	未認証のAPIリクエストが多すぎる	約1分待って再試行する。raw取得はまだ機能する場合がある
取得に失敗した、またはタイムアウトした	ネットワークの問題、または15秒のタイムアウトを超過	再試行する。手動貼り付けの経路は引き続き使える

取得に失敗しても、エディターはすでに入力した内容を保持します。ページを失うことなく、貼り付けまたはアップロードのモードに切り替えられます。

貼り付けまたはアップロードを使う

GitHubからの取得は便利ですが、唯一の入力方法ではありません。コンバーターは次の方法にも対応しています。

• .md、.markdown、.txtファイルを最大2 MBまでアップロードする。
• Markdownをエディターに直接貼り付ける。入力すると短いデバウンスの後にプレビューが再レンダリングされます。
• サンプルを読み込むと、表、タスクリスト、コードブロックがどのように扱われるかを確認できます。

1つ注意点があります。相対画像パスは、先にリポジトリを取得した場合にのみ解決されます。アップロードまたは貼り付けしたMarkdownにはリポジトリの基準がないため、そのモードでは絶対画像URLを使用してください。それ以外（見出し、表、コード、タスクリスト）は同じように動作します。

すべてのエクスポートを改善する5つのソース側の修正

PDFの品質は、元になるMarkdownの品質を超えません。次の変更はすぐに効果を発揮します。

1. 正しい見出し階層を使う。 セクションは##から始め、サブセクションには###を使い、レベルの飛ばしは避けます。目次と印刷用スタイルシートはどちらも構造に依存します。
2. 画像に役立つ代替テキストを付ける。 アクセシビリティに良いだけでなく、画像を読み込めないときにPDFで読めるフォールバックになります。
3. コードに言語を指定してフェンスで囲む。 言語タグ付きのブロックは、特に長い行がある場合、インデントされたコードより予測どおりにレンダリングされます。
4. 表を細く保つ。 8列の表は縮小しない限りA4に収まりません。詳細は本文に移すか、表を分割してください。
5. リポジトリのアセットには相対パスを使う。 md2pdfが正しく書き換えます。ローカルマシンや非公開バケットへの絶対リンクは、そのままでは生き残れません。

プライバシー：ブラウザから出るもの

md2pdfはMarkdownをアップロードしません。レンダリング、サニタイズ、目次の生成、PDFのエクスポートはすべてローカルで行われます。リポジトリを取得する場合、外部へのリクエストは公開READMEとその画像をGitHubから匿名で読み取るものだけです。アカウント、Cookie、変換に紐づくアナリティクスはありません。

これは、文書に社内メモ、顧客名、未公開の計画が含まれる場合に重要です。機密性の高いMarkdownを貼り付けて、第三者製の変換サービスにテキストを送ることなくエクスポートできます。ローカルファイルも同様です。ファイルはブラウザが読み取るのであって、アップロードされるのではありません。

まとめ

公開リポジトリのURLを貼り付け、取得を押し、プレビューを確認し、テーマを選び、長い文書では目次を有効にし、背景のグラフィックを有効にしてPDFに印刷します。送信前に改ページと幅の広いコードブロックを確認してください。取得に失敗した場合は、Markdownを貼り付けるかアップロードして続行します。

ワークフロー全体は、あえて退屈に設計されています。アカウントなし、待ち行列なし、アップロードなし、サーバーサイドレンダラーなし。あるのはREADME、印刷用スタイルシート、そして人に渡せるPDFだけです。