PDFサムネが真っ黒になる原因と2つの解決策

WordPressでPDFのサムネイルが真っ黒になる原因は「RGBにしていないから」ではなく、「PDF/X形式で保存しているから」です。Illustratorの保存設定を変えるだけで即解決できますが、プラグイン側でCMYK→sRGBの自動変換を実装すればユーザー側の操作は不要になります。

この記事の結論

PDFサムネイルが真っ黒になる根本原因はPDF/X形式の保存設定です。対処法は2つあります。

即効の解決策：Illustratorの「準拠する規格」を「なし」に変更してPDFを保存し直す

根本的な解決策：プラグイン側でCMYK→sRGB変換をflatten前に実行する（Rapls PDF Image Creator v1.0.9以降は自動対応済み）

自作プラグイン「Rapls PDF Image Creator」でイベントチラシのPDFをWordPressにアップロードしたところ、自動生成されたサムネイルが完全な真っ黒。ファイルサイズはあるので画像自体は生成されているけど、中身が真っ黒。一方、別のPDF（cairoライブラリで出力したもの）は正常に変換できている。サーバー環境やプラグインではなく、PDF自体に原因があると考えて調査を始めました。

PDF/X-1形式で保存したPDF（左）と、「準拠する規格：なし」で保存し直したPDF（右）

最初に疑ったCMYKは犯人ではなかった

RGBに変換して保存し直しても真っ黒のまま。「カラーモードが原因」という思い込みが原因究明を遅らせました。真犯人はカラーモードではなく、PDFの保存形式そのものです。

PDFの画像変換で真っ黒になる原因として真っ先に思い浮かぶのがCMYKカラーモードです。ImageMagickはデフォルトでRGBを想定しているので、CMYKデータをそのまま処理すると色がおかしくなったり真っ黒になったりする。これは事実です。

そこでIllustratorの「ファイル」→「ドキュメントのカラーモード」→「RGBカラー」に変更してPDFを保存し直しました。

結果は同じ。相変わらず真っ黒。RGBに変えたのに直らないのはなぜか――ここからPDFの内部構造を直接調べることにしました。

pdfinfoで見つけた真犯人：PDF/X-1:2001

pdfinfoコマンドでPDFのメタデータを確認したところ、「PDF subtype: PDF/X-1:2001」という記述が見つかりました。これが真犯人です。

pdfinfoの実行結果。「PDF subtype: PDF/X-1:2001」が原因の決め手

正常に変換できたPDFと、真っ黒になるPDFのpdfinfo結果を比較しました。

正常なPDF：

Producer:        cairo 1.17.6
PDF version:     1.7

1 2	Producer: cairo 1.17.6 PDF version: 1.7

真っ黒になるPDF：

Creator:         Adobe Illustrator 28.6 (Windows)
Producer:        Adobe PDF library 17.00
PDF version:     1.3
PDF subtype:     PDF/X-1:2001

Creator: Adobe Illustrator 28.6 (Windows)

Producer: Adobe PDF library 17.00

PDF version: 1.3

PDF subtype: PDF/X-1:2001

決定的な違いは「PDF subtype: PDF/X-1:2001」です。

PDF/X-1:2001は印刷業界の国際規格（ISO 15930-1）で、印刷入稿用PDFが必要な要件を満たしていることを保証するためのものです。この規格には「CMYKまたはグレースケール、特色のみ使用可能（RGBは使用不可）」という制約があります。

つまり、Illustrator上でドキュメントをRGBモードに変更しても、PDF/X-1形式で保存すると規格の要件を満たすために内部的にCMYKが使われます。さらにDeviceN（特色）やIndexed Colorなど複雑なカラースペースが混在し、ImageMagickが正しく処理できない状態になっていたのです。

実際にPDFの内部カラースペースを確認すると、CMYKとRGBが混在していました。

[/Indexed/DeviceCMYK 122 34 0 R]
[/DeviceN[/Magenta/Yellow]/DeviceCMYK 38 0 R 39 0 R]
[/Indexed/DeviceRGB 199 120 0 R]

[/Indexed/DeviceCMYK 122 34 0 R]

[/DeviceN[/Magenta/Yellow]/DeviceCMYK 38 0 R 39 0 R]

[/Indexed/DeviceRGB 199 120 0 R]

なぜImageMagickはCMYKで真っ黒になるのか

RGBは「光の強さ」で値が大きいほど明るく、CMYKは「インクの量」で値が大きいほど暗くなります。ImageMagickがCMYKの数値をRGBとして解釈するため、色が反転して真っ黒に見えるのです。

ImageMagick（Imagick PHP拡張）はデフォルトでRGBカラースペースを想定しています。CMYKのデータを渡すと、インク量の数値をそのまま光の強さとして解釈してしまいます。

RGBは「光の三原色」で、値が大きいほど明るくなります（R:255, G:255, B:255 = 白）。一方CMYKは「インクの量」で、値が大きいほど暗くなります（C:100, M:100, Y:100, K:100 = 真っ黒）。CMYKで「インクが少ない＝明るい」はずの領域を、RGBとして「光が弱い＝暗い」と解釈するため、画像全体が極端に暗く――ほぼ真っ黒に見えるわけです。

PDF/X-1:2001やPDF/X-4:2008などの印刷入稿規格はCMYKを強制するので、Illustratorで「RGBモード」で作成していてもPDF/X形式で保存した瞬間に内部はCMYKになります。これが真っ黒の正体です。

【解決策①】Illustratorの保存設定を変更する（即効）

Illustratorの「別名で保存」→「Adobe PDFを保存」ダイアログで、「準拠する規格」を「なし」に変更するだけです。Web用なら「最小ファイルサイズ」プリセットを選べば自動的に「なし」になります。

「準拠する規格」を「なし」に変更する。Web用途ならこれだけで解決

手順

Illustratorでファイルを開く
「ファイル」→「別名で保存」→ ファイル形式「Adobe PDF (pdf)」で保存
「Adobe PDFを保存」ダイアログで以下を確認：
- Adobe PDFプリセット：「最小ファイルサイズ」または「高品質印刷」
- 準拠する規格：「なし」（これが最重要）
「PDFを保存」をクリック

「準拠する規格」で「PDF/X-1a:2001」「PDF/X-3:2002」「PDF/X-4:2008」のいずれかが選ばれていると印刷用の制約が適用されます。Web用途やWordPressで使うPDFなら「なし」で問題ありません。

Web用なら「最小ファイルサイズ」プリセットを選ぶのが手軽です。このプリセットは自動的に「準拠する規格：なし」になり、RGBカラーで出力されます。

他の回避策

直接画像として書き出す：サムネイル用の画像が欲しいだけなら、PDFを経由せずIllustratorから直接PNGやJPGで書き出せば、カラーモードの問題を完全に回避できます。「ファイル」→「書き出し」→「Web用に保存（従来）」。

pdftoppm（Poppler）を使う（開発者向け）：サーバー側で対処する場合、pdftoppm -png -r 150 input.pdf outputでCMYKからRGBへの変換を自動で行えます。PDF/X-1形式でも正しく変換できますが、サーバーにPopplerのインストールが必要です。なお、WordPressプラグインからpdftoppmを呼ぶにはexec()を使うことになりますが、プラグイン審査ではexec()の使用がセキュリティ上の問題として指摘されます。この問題への対処法は「WordPressプラグイン審査に通るまでの実体験」で詳しくまとめています。

【解決策②】プラグイン側でCMYKを自動検出・変換する（根本対応）

PDFを読み込んだ直後にカラースペースをチェックし、CMYKならsRGBに変換。この変換をflattenの前に実行することが最も重要です。flatten後に変換しても、すでに色が壊れているため手遅れです。

解決策①はユーザーにPDF保存設定の変更を求める「回避策」です。しかし、印刷用PDFをPDF/X形式で保存するのは正しい選択です。それをWeb用に変換するときに問題が起きるなら、変換する側――つまりプラグインが対応すべきです。

そう考えて、自作プラグイン「Rapls PDF Image Creator」にCMYK自動変換機能を実装しました。

処理順序の罠：flattenの前に変換する

最初、私はflatten後にカラースペース変換を入れていました。しかしこれでは直りません。CMYKのままflattenすると、その時点で色が壊れるのです。

flatten（平坦化）とは、透過レイヤーを背景色と合成して1枚の画像にする処理です。この合成処理の中で各ピクセルの色値が計算されますが、その計算はRGBカラースペースを前提としています。CMYKデータをRGBのつもりで合成すると、色の反転や極端な暗転が起きて取り返しがつきません。その後にいくらsRGBに変換しても、壊れた色は元に戻せません。

正しい処理順序はこうです。

1. PDFを読み込む
2. カラースペースをチェック
3. CMYKならsRGBに変換 ← flattenの前にここで実行
4. 背景色を設定
5. flatten（平坦化）
6. リサイズ
7. 画像として保存

1. PDFを読み込む

2. カラースペースをチェック

3. CMYKならsRGBに変換 ← flattenの前にここで実行

4. 背景色を設定

5. flatten（平坦化）

6. リサイズ

7. 画像として保存

今回の実装で最も時間がかかったのは、この順序の問題に気づくまででした。

実際のコード（ImagickEngine.php）

// PDFを読み込む
$imagick = new \Imagick();
$imagick->setResolution($resolution, $resolution);
$imagick->readImage($pdfPath . '[0]');

// カラースペースをチェック（PDF/X-1:2001対応）
$colorspace = $imagick->getImageColorspace();
if ($colorspace === \Imagick::COLORSPACE_CMYK) {
    // CMYKからsRGBに変換（flatten前に実行することが重要）
    $imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);
}

// 背景色を設定して平坦化
$imagick->setImageBackgroundColor('white');
$imagick = $imagick->flattenImages();

// 以降、通常のサムネイル生成処理...

// PDFを読み込む

$imagick = new \Imagick();

$imagick->setResolution($resolution, $resolution);

$imagick->readImage($pdfPath . '[0]');

// カラースペースをチェック（PDF/X-1:2001対応）

$colorspace = $imagick->getImageColorspace();

if ($colorspace === \Imagick::COLORSPACE_CMYK) {

// CMYKからsRGBに変換（flatten前に実行することが重要）

$imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);

}

// 背景色を設定して平坦化

$imagick->setImageBackgroundColor('white');

$imagick = $imagick->flattenImages();

// 以降、通常のサムネイル生成処理...

getImageColorspace()でカラースペースを取得し、COLORSPACE_CMYKならtransformImageColorspace()でsRGBに変換。たった数行の追加ですが、これでPDF/X形式のPDFも正しい色でサムネイルが生成されます。

コマンドラインで同等の処理をする場合

convert input.pdf[0] -colorspace sRGB -background white -flatten output.png

1	convert input.pdf[0] -colorspace sRGB -background white -flatten output.png

-colorspace sRGBを-flattenよりも先に指定するのがポイントです。順序を逆にすると、PHP版と同じく色が壊れます。

テスト結果：全形式で正常変換を確認

PDF/X-1a、PDF/X-4、InDesign出力のCMYK PDFすべてで正常に変換され、従来正常だったRGB PDFにも影響はありませんでした。

PDF形式	作成ソフト	修正前	修正後
PDF/X-1a:2001	Illustrator	真っ黒	正常
PDF/X-4:2008	Illustrator	真っ黒	正常
PDF/X-1a:2001	InDesign	真っ黒	正常
通常PDF（RGB）	各種	正常	正常
Web用PDF	ブラウザ印刷	正常	正常

色の再現性について補足すると、CMYKとRGBは色域が異なるので完全に同じ色にはなりません。ただしサムネイル用途ならtransformImageColorspace()の自動変換で十分な品質です。処理時間への影響も実測では誤差の範囲でした。

なぜこの問題にハマりやすいのか

「RGBにすれば直る」という常識が通用しないのがPDF/X形式の落とし穴です。見た目では判別できず、pdfinfoで内部構造を見て初めて気づきます。

Illustratorは元々印刷物のデザインに特化したソフトウェアなので、PDF保存設定もデフォルトで印刷入稿を意識したものになりがちです。過去に印刷用データを作成したことがあると、その設定が「最後に使用した設定」として残っていることもあります。

カラーモード（RGB/CMYK）については多くの人が知っていますが、PDF/X規格の存在はあまり知られていません。さらに、PDF/X形式で保存されたPDFもAcrobatやプレビューでは普通に表示できるので、ImageMagickで変換するまで問題に気づきません。

手元のPDFを確認する方法

pdfinfoコマンドで「PDF subtype」にPDF/Xの表記があれば、それが原因です。コマンドライン、Adobe Acrobat、macOSプレビューの3つの方法で確認できます。

コマンドラインで確認（最も確実）

pdfinfo ファイル名.pdf | grep -i "subtype\|PDF version"

1	pdfinfo ファイル名.pdf \| grep -i "subtype\\|PDF version"

出力にPDF subtype: PDF/X-1:2001のような行があれば、PDF/X形式です。

Adobe Acrobatで確認

PDFを開いて「ファイル」→「プロパティ」→「概要」タブの「詳細情報」。「PDF/X」という表記があればPDF/X形式。

macOSのプレビューで確認

「ツール」→「インスペクタを表示」→「一般情報」パネル。ただしPDF/X規格の詳細が表示されないことがあるので、確実に知りたい場合はpdfinfoを使ってください。

注意点と制限事項

特殊なICCプロファイルを使用したPDFや、サーバーのImageMagickバージョンによっては自動変換が正しく動作しない可能性があります。その場合は解決策①（Illustrator設定変更）で対応してください。

すべてのCMYK PDFに対応できるわけではない：特殊なICCプロファイルや複雑なカラー定義を含むPDFでは、自動変換がうまくいかない可能性があります。その場合は解決策①のIllustrator保存設定の変更で対応してください。

サーバー環境による差異：ImageMagickのバージョンやコンパイルオプションによって挙動が異なる場合があります。Xserver、ConoHa WING、さくら、mixhostでは問題なく動作することを確認済みです。

Web用PDFのチェックリスト

今後同じ問題を防ぐための確認項目です。Illustratorユーザーは「準拠する規格：なし」、開発者は「flatten前にカラースペース変換」の2点だけ覚えておけば大丈夫です。

Illustratorの場合：

ドキュメントのカラーモードがRGBになっているか、PDF保存時の「準拠する規格」が「なし」になっているか、プリセットは「最小ファイルサイズ」または「高品質印刷」か――この3点を毎回確認してください。

その他のアプリの場合：

印刷用プリセット（PDF/X、Press Qualityなど）を避けているか、Web用または画面表示用のプリセットを選択しているか――この2点を確認してください。

開発者の場合：

PDFからサムネイルを生成する処理を書いている方は、入力PDFがCMYKかどうかを必ずチェックしてください。「RGBしか来ない」という前提は、印刷系ユーザーがいる環境では簡単に崩れます。カラースペース変換はflattenの前に実行する、この順序だけ守れば問題は起きません。

Rapls PDF Image Creatorでの対応状況

プラグインをv1.0.9以降に更新するだけで、PDF/X形式のPDFも自動的に正しく処理されます。ユーザー側で行うことは何もありません。

今回のCMYK自動変換は、Rapls PDF Image Creator v1.0.9としてWordPress.orgにリリース済みです。既存のPDFでサムネイルが真っ黒になっていた場合は、WordPress管理画面の「設定」→「Rapls PDF Image Creator」→「一括生成」から再生成してください。

SVNでのプラグイン更新手順は「WordPress.orgにプラグインをSVNで公開する手順」で詳しく解説しています