「Could not process PDF」400エラーの原因と対処法

Anthropic SDKでPDFをdocumentブロックとして渡すと、次の400エラーで処理が止まることがあります。

anthropic.BadRequestError: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'Could not process PDF'}}

厄介なのは、ページ数もファイルサイズも公式の上限内で、暗号化もされていないのに起きる点です。公式のエラーリファレンスにも載っていないため、原因の切り分けは自分で行う必要があります。

"Could not process PDF"はどんなときに出るエラーか

invalid_request_errorは、リクエストの形式・内容に不備があるときの汎用400エラーです。PDFの渡し方(Base64埋め込み・URL参照・Files APIのfile_id)や、Messages API・Message Batches APIのどちらを使っているかに関わらず発生します。SDKのGitHubリポジトリに報告された実例では、同じ実装で99%以上のPDFは正常に処理され、一部のPDFだけがこのエラーで止まると記録されています。

このメッセージは、公式のAPIエラーリファレンスにも、Files APIが明示するエラー一覧にも載っていません。Files APIが公開している400は「Invalid file type」「Exceeds context window size」「Invalid filename」などで、いずれもメッセージから原因が読み取れます。それに対しCould not process PDFは原因を名指ししない、切り分けが必要なタイプのエラーです。

直接APIを呼んでいなくても遭遇します。Claude CodeのPDFスキルはPDFを読む際に内部でMessages APIを呼び出すため、CLI利用者でもAPI Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Could not process PDF"}, "request_id": "..."}という同一文言のエラーが報告されています。

原因になりやすいのは暗号化と内容の破損

2025年に報告された事例では、報告者が次の4点を確認済みでした。

• トークン数: 12万トークン未満(当時のモデルの上限20万トークンより十分小さい)
• ページ数: 74ページ(当時の上限100ページより十分小さい)
• リクエストサイズ: 5.9MB(上限32MBより十分小さい)
• PDFにパスワード・暗号化は無い

つまり上限系の要因はすべて除外された上でこのエラーが再現していました。対応したAnthropicのエンジニアの回答はシンプルで、「典型的には、PDFが破損している(malformed)か、不正な内容を含んでいる場合に起きる」というものです。

公式のPDF処理の要件には「標準的なPDF(パスワード・暗号化なし)」という条件が明記されています。この条件に違反した場合の専用エラー名は公開されていないため、暗号化されたPDFを送るとこの汎用メッセージで弾かれる可能性が高いと考えられます。原因を絞り込むときは、まず暗号化の有無、次にファイル構造の健全性という順で確認するのが効率的です。

暗号化・パスワード保護になっていないか確認する

送信前にpdfinfoでPDFの暗号化状態を確認できます。

pdfinfo document.pdf | grep Encrypted

Encrypted: yesと出た場合は、qpdfでパスワードを解除するか、発行元のアプリケーションでパスワードなしとして再エクスポートしてから送信します。社内文書管理システム由来のPDFは、書き出し時に既定で保護がかかっていることがあるため、まずここを疑うのが早道です。

ファイル構造自体が壊れていないか確認する

暗号化されていないのにエラーが出る場合は、PDFの構造そのものに問題がある可能性があります。Adobe Acrobatやプレビューアプリで正常に開けても、パーサーによって許容する非準拠の度合いが違うため、Claude側の処理では引っかかることがあります。qpdf --checkで構造検証だけを先に行い、警告が出るファイルは一度PDFとして再書き出し(印刷してPDF保存するなど)してから渡すと解消することがあります。

元の報告では、プライバシーの都合で問題のファイルそのものは公開されず、構造上どこが不正だったかは特定されませんでした。実務上有効だった対処は、同じファイルをそのまま再送する手動リトライと、PDFを別の方法で再生成することの2つでした。

画像だけのスキャンPDFはこのエラーの原因になるか

原因ではありません。公式ドキュメントによると、Claudeは送られたPDFの各ページを、テキストレイヤーの有無に関わらず画像に変換してから処理します。スキャンして画像だけになったPDFも同じ変換が行われるため、それだけでCould not process PDFにはなりません。

ただし、抽出できるテキストを持たないスキャンPDFには別の制約があります。ClaudeのCitationsでスキャンPDFを引用できない理由にあるとおり、Citations機能はテキストが抽出できない文書を引用対象にできません。これはエラーにならず応答自体は返るため、Could not process PDFとは症状も原因もまったく別物です。エラーで止まっているのか、引用だけが付かないのかを先に見分ける必要があります。

似た文言の別エラーと混同しない

messages.N.content.M.pdf.source.base64.data: The PDF specified was not valid.という、フィールドの位置を含む別のエラーも報告されています。Could not process PDFとの違いは、メッセージにbase64.dataというフィールドパスが含まれているかどうかです。フィールドパスが付くこちらのエラーは、base64データ自体が壊れている・PDFとして解釈できないケースを指しており、Could not process PDFより原因を特定しやすい部類に入ります。エラー文にフィールドパスが含まれているかどうかを最初に確認すれば、どちらの系統かを見分けられます。

ページ数・サイズの上限は原因になりにくい

現在のPDF処理の上限は次のとおりです。

上限を実際に超えた場合は、Files APIなら「Exceeds context window size」のように原因が読み取れる別の400エラーになります。リクエストサイズ超過による413エラーとの見分け方はClaude APIのリクエストサイズ上限と413エラーの見分け方で扱っています。Could not process PDFが出た時点で上限を疑って時間を使う前に、まず暗号化と構造の健全性を確認したほうが早く原因に近づけます。Files APIの基本的なアップロード手順や料金、ファイル一覧の取得方法はClaude Files APIでPDFを処理する方法にまとめています。

Claude Codeの3エラーとは別物

Claude CodeのReadツールが送信前にローカルで検知するPDF too large・PDF is password protected・The PDF file was not validは、この記事とは別系統のエラーです。それに対し、Claude CodeのPDFスキルが内部でMessages APIを呼んだ先でCould not process PDFを受け取ると、事前チェックを通過したあとでAPI側から拒否される形になります。報告されているユーザー体験では、一度このエラーが出た会話を続けても同じPDFへの参照が残り続け、リトライを重ねても直らなかったとされています。回避できたのは/clearで会話をリセットするか、セッション自体を再起動した場合だけでした。

リトライは効くことがあるが自動では行われない

SDK直接利用の報告者の観察では、「同じPDFに対するリトライは通ることもあれば、同じエラーで再度弾かれることもある」とされています。ここで注意したいのは、Python・Ruby・PHPの公式SDKは400番台のエラーを既定のリトライ対象から除外していることです。接続エラーや429・5xx系は自動でリトライされますが、BadRequestError(400)は最初の1回で終わります。SDKごとの例外クラスとリトライ対象の詳細はClaude APIのエラー形式とSDK例外クラスの言語別対応表にまとめています。

つまり、このエラーへの手動リトライはSDKの標準機能ではなく、アプリケーション側で自分で実装する必要があります。同じファイルで何度リトライしても毎回同じエラーになる場合は、一時的な問題ではなくファイル自体(暗号化・破損)が原因だと判断する材料になります。

直らないときの切り分け手順

1. レスポンスのrequest_idを控える(Message Batches APIならmsgbatch_...形式のバッチメッセージIDも)
2. pdfinfoでページ数・ファイルサイズ・暗号化の有無を確認する
3. 暗号化されていなければ、同じファイルを一度だけ手動でリトライする
4. 複数ページのPDFであれば分割し、どの範囲で再現するかを特定する
5. ファイル自体を再エクスポートしてから渡し直す
6. Claude Code経由なら/clearか再起動を試す(会話を続けたままのリトライでは直らない)
7. それでも再現する場合は、request_idを添えてAnthropicに報告する

このエラーを扱ったAnthropic SDKのissueは長期間動きが無いことを理由にクローズ済みですが、コメントで再オープンできる状態にはなっています。個人情報を含む文書の場合は、issueへの投稿ではなくサポート窓口経由での報告が安全です。

まとめ

Could not process PDFは、ページ数・サイズ・暗号化のいずれも上限内に見えるのに発生する、原因を名指ししないタイプの400エラーです。報告されている事例では上限系の要因はすべて除外され、Anthropicのエンジニアは「PDFの破損または不正な内容」を典型的な原因として挙げています。まずpdfinfoで暗号化の有無を確認し、次にファイル構造を検証し、それでも解決しなければ手動リトライとサポートへの報告に進むのが現実的な切り分け順です。Claude Code経由で発生した場合は、同じ会話内でのリトライではなく/clearかセッション再起動が必要な点も覚えておく価値があります。

よくある質問

TypeScriptなど他言語のSDKでも同じ文言が出ますか

出ます。APIが返すエラーのtypeとmessageはSDKの言語に関わらず共通で、各言語がそれぞれの例外クラスに包んで投げるだけです。表示されるメッセージ文字列自体は変わりません。

Message Batches APIでも起きますか

起きます。報告された事例では、同期のMessages APIだけでなく、msgbatch_で始まるバッチメッセージIDに対してもこのエラーが再現したことが報告されています。

サポートへの問い合わせにはどの情報が必要ですか

レスポンスJSONに含まれるrequest_idが最低限必要です。Message Batches API経由であれば、失敗したバッチメッセージのIDも合わせて伝えると調査が早くなります。ファイル自体は個人情報や機密情報を含むことが多いため、そのまま公開のissueに貼らず、サポート窓口を経由します。