「レターサイズ（8.5×11インチ）のPDFなのに、Microsoft Edgeでは11.33×14.67インチと出てしまい、印刷すると小さくなる」──開発・運用現場で実際に起きがちなこのトラブルを、なぜ起きるのか・どう直すのか・どう再発させないかまで、技術的背景と検証手順、そして生成側の実装例を交えて体系的に解説します。今日から「Edgeだけ小さく印刷される」問題に終止符を打ちましょう。
現象の整理：EdgeのPDFビューワーでページサイズが誤表示・縮小印刷される
本記事が対象とするのは次のようなケースです。
- Webアプリで生成したレターサイズ（8.5×11インチ／約216×279mm）のPDFをMicrosoft Edgeで開くと、ドキュメントのプロパティに「11.33×14.67インチ」など過大なサイズが表示される。
- そのままEdgeの印刷ダイアログから印刷すると、「用紙に合わせて縮小」が働き、本文が小さく出力される。
- 同じPDFをAdobe Acrobat ReaderやGoogle Chromeで開くと正しいサイズで表示・印刷される。
なぜ起きるのか：72ポイントと96DPIの取り違え
PDFのページ寸法は基本単位ポイント（pt）で表され、1pt＝1/72インチです。レターサイズをptに換算すると次の通りです。
| 規格 | インチ | ポイント（72dpi） | ミリメートル換算 |
|---|---|---|---|
| Letter | 8.5 × 11 | 612 × 792 | 約 216 × 279 |
ところがWindows/ブラウザの世界ではCSSピクセルの論理密度として96DPIが使われます。もしビューアが何らかの要因で「96で作った数値を72で割る」ように誤換算すると、
8.5 × (96/72) = 11.33...
11 × (96/72) = 14.67...
という11.33 × 14.67インチが導かれます。ドキュメントプロパティにこの値が出る場合、Edge側でDPI/単位の取り扱いに起因する表示バグや、PDF生成側の記述とEdgeの解釈の相性問題が疑われます。ページそのものは612×792ptでも、「見かけ上の用紙が大きい」と誤認されるため、印刷時にEdgeが縮小して用紙に合わせる挙動を起こしやすくなります。
最短での回復策：まずEdgeを最新へ更新
ChromiumベースのEdgeの一部古いバージョンでは、PDF内部のDPIやユーザーユニットに絡む値を誤って換算し、インチ表記が拡大される事例が知られています。まずは以下で最新版に更新してください。
- アドレスバーに
edge://settings/helpと入力 → 更新の有無を確認 → 再起動 - 企業利用で更新が制限されている場合は、IT管理者に安定チャネルの最新ビルド適用を依頼
更新だけでドキュメントプロパティのインチ表記が正され、印刷縮小が消えるケースは多く見られます。
更新できない・直らないときの即効回避：印刷設定を手動調整
再現性高く効くのが次の2点です。
- 印刷ダイアログの「スケール」＝「実際のサイズ（100%）」を選択
- 「用紙に合わせて縮小」や「ページに合わせる」のチェックを外す
これでEdge側の自動縮小を止められます。加えて次も推奨です。
- 余白：必要に応じて「標準」またはプリンタ推奨値へ
- ヘッダーとフッター：不要ならオフ（印刷領域を侵食するとレイアウトが縮むことがあります）
- 「システムダイアログを使用して印刷」（詳細設定→システム）を選ぶと、プリンタードライバ側のスケールを直接100%に指定しやすい
管理者向けの暫定運用：PDFは既定で外部ビューアで開く
組織全体での被害回避には、EdgeのPDF内蔵ビューアを使わず、Acrobatなど外部アプリで開かせるポリシーが有効です。
- ユーザー設定：設定 > Cookie とサイトのアクセス許可 > PDF ドキュメント → 「常に外部でPDFを開く」をオン
- GPO/MDM：AlwaysOpenPdfExternally ポリシーを有効化（EdgeでPDFリンクを開いたら既定のPDFアプリを起動）
根本対策：PDF「生成側」で誤認されにくいファイルを作る
Edgeでの誤認を避けるための生成側ベストプラクティスをまとめます。ここを固めておくと、ビューア差によるトラブルは大きく減ります。
ページボックス（MediaBox/CropBox）を明示し、正しいpt値を埋め込む
- /MediaBox はページの基準矩形です。レターなら
[0 0 612 792]に。 - トリミングや塗り足しがないなら /CropBox も
[0 0 612 792]に合わせる（余計な/UserUnitや不整合は避ける）。 - pt（72dpi）の整数値で記述（浮動小数や奇数DPI換算値は避ける）。
画像のDPIメタデータに依存しない版下を作る
PDF内の画像（XObject /Image）に埋め込まれたDPIメタデータやXMPは、ページサイズ計算に関与しないのが本来ですが、ビューワーの実装バグや相性で誤解釈されることがあります。画像の実寸は配置行列（CTM）で決まり、ページサイズはページボックスで決まる──この原則に沿って、画像DPIではなくptベースのレイアウトで確定させましょう。
CSS→PDFの場合（Puppeteer/Playwright/Chromeヘッドレス等）
- @pageでサイズを明示：
@page { size: Letter; margin: 0.5in; } - APIでは
format: 'Letter'またはwidth: '8.5in', height: '11in'を指定 preferCSSPageSize: true（CSSの@pageサイズを優先）scale: 1固定（意図しない縮小・拡大を排除）
// 例: Puppeteer
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com/print', { waitUntil: 'networkidle0' });
await page.pdf({
format: 'Letter', // または width:'8.5in', height:'11in'
printBackground: true,
preferCSSPageSize: true,
scale: 1
});
await browser.close();
iText / pdf-lib / PDFKit / ReportLab 等でのポイント指定
| ライブラリ | レターサイズ指定例 |
|---|---|
| iText (Java) | Document doc = new Document(PageSize.LETTER); |
| pdf-lib (JS) | const { PDFDocument, StandardFonts } = require('pdf-lib'); const pdfDoc = await PDFDocument.create(); const page = pdfDoc.addPage([612, 792]); // 8.5x11in × 72pt |
| PDFKit (Node) | const doc = new PDFDocument({ size: 'LETTER', margin: 36 }); |
| ReportLab (Python) | from reportlab.lib.pagesizes import letter from reportlab.pdfgen import canvas c = canvas.Canvas("out.pdf", pagesize=letter) |
余計なDPI情報・ユーザーユニットを付与しない
- /UserUnit を不用意に設定しない（1pt＝1/72inからの逸脱はビューワー差を招く）。
- メタデータの
DPIやResolutionをページ寸法に転用しない。 - エクスポート時は72pt基準で整数に正規化（612×792など）。
検証：PDFが正しいか、Edgeだけおかしいかを切り分ける
1. PDFそのもののページボックスを確認
以下のいずれかの方法で、生成されたPDFのページボックス値を見ます（代表例）。
- 専門ツールのプロパティで 612 × 792 pt を確認
- コマンドラインツールでページ情報を表示（例：pdfinfo、mutool、qpdf 等）。期待値は Page size: 612 x 792 pts
ここで誤っていれば、ビューアではなく生成側の問題です。/MediaBoxと/CropBoxを修正します。
2. 他ビューアとの比較
| ビューア | 期待表示 | 印刷の既定 | 確認ポイント |
|---|---|---|---|
| Adobe Acrobat Reader | 8.5 × 11 in | 実際のサイズ／合わせる（選択可） | ページサイズ表示、ページ設定 |
| Google Chrome | 8.5 × 11 in | デフォルトで縮小しない傾向 | スケール100%、余白、ヘッダ/フッタ |
| Microsoft Edge | 11.33 × 14.67 in（誤表示し得る） | 用紙に合わせて縮小が働く場合あり | スケールを「実際のサイズ」に |
3. Edgeのビルドと設定
- edge://settings/help でバージョン確認→更新
- edge://policy でPDF関連ポリシー（AlwaysOpenPdfExternallyなど）を点検
- 設定 > PDF ドキュメント で「常に外部で開く」を試す
印刷が縮小されるロジックを理解する（再発防止の鍵）
印刷時の縮小は、「実寸のページサイズ」と「プリンタの給紙サイズ」がズレている時に発生します。Edgeの誤表示でページを大きく認識したままLetter用紙へ送ると、
- 「用紙に合わせて縮小」＝Fit to paperが自動で有効
- 結果として実寸より小さい印字になる
逆に、印刷側で「実際のサイズ（100%）」にすると、Edgeが誤認した大きいページをそのまま出そうとするため、プリンター側で印刷可能領域からはみ出るという警告が出る場合もあります。従って、
- Edgeのページサイズ誤認を解く（更新・設定）
- それでもダメなら印刷スケールを100%に固定
- 最終手段として外部ビューアを使う
という順に対処すると、ユーザー体験を損ねずに収束しやすくなります。
生成側チェックリスト（実務者向け）
| 項目 | 推奨値/設定 | 理由 |
|---|---|---|
| ページボックス | /MediaBox [0 0 612 792]、/CropBoxも同値 | レターサイズの正しいpt寸法を明示 |
| ユーザーユニット | 未設定（既定＝1） | 単位が複雑化すると解釈差の温床 |
| 画像DPI | 任意だがレイアウトはCTMで固定 | DPIメタデータに依存しない |
| CSS→PDF | @page { size: Letter; }＋preferCSSPageSize: true | レイアウトエンジンの自動推定を回避 |
| ラスタライズ | 必要最小限、テキストはテキストのまま | ビットマップ化は寸法解釈の混乱源 |
| メタデータ | ページサイズを重複表現しない | 矛盾する情報を避ける |
診断用サンプルPDFの作り方（異常切り分けの標準手順）
- 1ページ、背景無し、余白0.5in、四辺に枠線（0.5in内側）だけを描くPDFを生成
- ページ寸法は612×792ptを直接指定
- Edge、Chrome、Acrobatで開き、プロパティの用紙サイズと印刷時のスケールが一致するか確認
四辺の枠線を実寸（例：Avery等のラベル枠）に合わせると、縮小の有無がひと目で判断できます。Acrobat/Chromeで正しく、Edgeだけ縮小するなら、Edge側の問題と判断可能です。
Edgeの既知挙動とヒント
- 古いChromiumベースのEdgeで、PDF内部のDPI情報を誤換算してインチ表記が拡大される報告がある（更新で解消するケース多数）。
- Edgeの印刷UIは環境により既定で「用紙に合わせる」が選ばれている場合がある。常に「実際のサイズ」へ切替を習慣化。
- システム印刷ダイアログからドライバー側のスケール100%を指定すると回避しやすい。
よくある落とし穴
- PDFの見た目＝ページサイズが正しいとは限らない（高解像度画面で拡大表示されても、ページボックスが誤っていれば印刷で破綻）。
- 画像をベタ貼りしたPDFで、画像DPIに合わせた寸法をページサイズにしてしまうと、72pt基準と揺れて不整合になりやすい。
- レター指定のつもりでA4（595×842pt）を使ってしまい、双方のビューアで微妙な縮小が起きる。
実装メモ：単位換算の確実な式
| 変換 | 式 | 例 |
|---|---|---|
| インチ → pt | pt = inch × 72 | 8.5in → 612pt |
| mm → pt | pt = mm × 72 / 25.4 | 279mm → 792pt |
| 誤表示の推定 | inch_wrong = inch_true × (96/72) | 8.5in → 11.33in |
運用上のベストプラクティス
- 自動テスト：CIでpdfinfo等を用い、ページサイズが期待値（612×792pt）かを検証。
- 印刷手順ドキュメント：ユーザー向けに「Edgeの印刷はスケール100%」と明記。
- 監視・一次切り分け：障害報告では必ず「閲覧ブラウザ」「Edgeのバージョン」「プロパティの用紙値」を収集。
再発防止：仕様の決め方を固定する
「印刷物の正寸」を仕様としてプロダクトに組み込むと、環境差の揺れを吸収できます。
- 版下定義：@pageでサイズと余白を固定、マージン/枠/固定テキストはpt指定。
- 出力テスト：Edge/Chrome/Acrobatの三者で毎リリース確認。
- 回避策の用意：Edgeで不具合時は「外部で開く」または「スケール100%」の手順をUIに案内。
トラブルシューティング フローチャート（文字版）
Edgeでサイズが大きく表示→更新（edge://settings/help）→改善？→YES：完了／NO：印刷スケール100%に変更→改善？→YES：運用回避／NO：PDFのMediaBox/CropBoxを再生成（612×792pt）→他ビューアで正常か確認→YES：Edgeのみの問題→「外部で開く」or GPOで外部強制／NO：PDF生成側の欠陥→実装修正。
ユーザーサポート用テンプレ（社内FAQに流用可）
- Q：印刷したら小さく出ます。
A：印刷ダイアログで「スケール」を「実際のサイズ（100%）」にしてください。「用紙に合わせて縮小」をオフに。 - Q：PDFの用紙サイズが11.33×14.67inと表示されます。
A：Edgeの表示が誤っています。最新版に更新してください。更新できない場合はスケール100%で印刷、または外部ビューアで開いてください。 - Q：ChromeやAcrobatでは正常です。
A：PDF自体は正しい可能性が高いです。Edgeのみの一時的な問題が疑われます。
開発者向け：既存PDFを安全に正規化する
既発行PDFのボックスが不整合な場合、ツールで/MediaBoxと/CropBoxを正規化します。
# 例：qpdf でページサイズ確認（表示のみ）
qpdf --show-npages sample.pdf
qpdf --show-pages sample.pdf
# 例：pdfcpu 等で A4→Letter に調整（概念例）
pdfcpu trim -pages 1- -m "0 0 612 792" in.pdf out.pdf 実際のコマンドやオプションはツールにより異なります。テスト環境で十分に検証してから本番に適用してください。
印刷品質の補足：解像度とアンチエイリアス
- テキストや線はベクターのまま出力する（ラスタライズは最終手段）。
- ビットマップ画像は300dpi以上を推奨。ただしページサイズの計算はpt基準で行う。
- バーコード/QRコードは整数ptグリッドに合わせて配置（小数ptは細線化の原因）。
社内配布文面サンプル（ユーザー周知）
【重要】EdgeでPDF印刷が小さくなる場合の対処
1) Edgeを最新に更新してください（edge://settings/help）
2) 印刷時は「スケール＝実際のサイズ（100%）」にしてください
3) 直らない場合はPDFを右上メニューから「外部アプリで開く」を選択し、Acrobatで印刷してください
まとめ：技術と運用の両輪で解決する
本件は72ptと96DPIの取り違えという古典的な問題が、特定の実装やバージョンで表面化したものです。まずはEdgeを更新、ダメなら印刷スケール100%で回避。根本的には/MediaBox等をpt単位で正しく定義し、CSSやAPIでページサイズを明示して生成すれば、どのビューアでも正しく扱われます。ユーザー運用・GPOも併せて用意しておけば、現場の手戻りを最小化できます。
付録：A4との混同チェック（よくあるミス）
| 用紙 | インチ | pt（72dpi） | 主な用途 |
|---|---|---|---|
| Letter | 8.5 × 11 | 612 × 792 | 北米の標準 |
| A4 | 8.27 × 11.69 | 595 × 842 | 国際標準（日本含む） |
mm換算で近い値になるため、単位系の取り扱いを誤ると見た目は似ていても印刷でズレます。レター指定の要件がある場合は必ず612×792ptを使いましょう。
開発メモ：レイアウト確定のためのCSS断片
@page {
size: Letter;
margin: 0.5in;
}
html, body {
margin: 0;
padding: 0;
}
.header, .footer {
position: running(header-footer);
}
レターを明示し、余白・ヘッダ/フッタを固定することで、ビューワーやプリンタ側の自動調整を最小化できます。
フィードバックと改善サイクル
同様の不具合に直面している開発者は少なくありません。再現PDFと手順、Edgeのバージョン、印刷ダイアログの設定値をまとめてコミュニティやフォーラムに共有すると、修正優先度の向上につながります。組織内でもナレッジとして残し、次回以降の不具合対応を短縮しましょう。
チェックリスト（最終確認）
- PDFの
/MediaBox//CropBoxは[0 0 612 792]である - Edgeは最新ビルドに更新済み
- 印刷時は実際のサイズ（100%）を選び、用紙に合わせて縮小はオフ
- 必要に応じて外部ビューアで開く設定やポリシーを適用
- 自動テストでPDFのページサイズを検証している
開発・運用まとめ（要点再掲）
- 原因の本質：72ptと96DPIの取り違え/誤換算がトリガー
- 即効策：Edge更新 → スケール100% → 外部ビューア
- 恒久策：ページボックスをptで厳密に、CSSとAPIでサイズ明示、DPIメタデータに依存しない
- 運用策：GPOで外部オープン、印刷手順の標準化、CIでページサイズ検証
以上の手順を実践すれば、多くの現場で「Edgeだけレターが巨大に見える／小さく印刷される」問題は解消または的確に回避できます。
コメント