「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'}}

厄介なのは、ページ数もファイルサイズも上限内で、暗号化もされていないPDFで起きた報告がある点です。メッセージは原因を名指ししないので、手元のファイルから順に疑っていく必要があります。結論は、まず暗号化と中身の破損を確かめ、それでも出るなら重さを疑う、という順です。

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

invalid_request_errorは、リクエストの形式・内容に不備があるときの汎用400エラーです。公式のエラー一覧は400を「形式または内容の問題」とだけ説明し、Files APIのエラー一覧に並ぶ「Invalid file type」「Exceeds context window size」「Invalid filename」にもCould not process PDFは入っていません。

SDKのGitHubリポジトリに2025年3月に立ったissueでは、base64のdocumentブロックで渡したPDFのうち99%以上は正常に処理され、一部だけがこのエラーで止まると書かれています。Message Batches APIでも同じエラーが出て、報告者はmsgbatch_で始まるバッチメッセージIDを共有しています。

直接APIを呼ばなくても遭遇します。Claude CodeでPDFを読ませたときにも、同じ文言のAPI Error: 400がrequest_id付きで報告されています。

上限内でも起きた報告と、疑う順序

SDKのissueで報告者が潰していた項目は次の4点です。

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

上限系の要因をすべて除いても再現したため、issueでは「典型的には、PDFが壊れているか、不正な内容を含む場合に起きる」と返信されています。同じ報告者は、同じPDFの再送が通ることもあれば同じエラーで弾かれることもあると書いています。

Claude Codeの側でも、6MBのPDFで「数時間前までは読めていた」という報告(#20290)があり、サイズの小ささは安全の保証になりません。疑う順序は、暗号化、ファイルの構造、PDFの重さ、会話に残ったPDFの4段です。

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

公式のPDF要件は「標準的なPDF(パスワード・暗号化なし)」です。この条件に外れたPDFがどのメッセージで弾かれるかは、公式ページに書かれていません。要件に外れたファイルを送らないことが先決なので、送信前にpdfinfoで状態を見ます。

pdfinfo plain.pdf | grep -E "Pages|Encrypted"
pdfinfo user-pass.pdf | grep Encrypted; echo "grep exit=$?"
pdfinfo owner-pass.pdf | grep Encrypted

plain.pdfは暗号化なし、user-pass.pdfは開くためのパスワードを設定、owner-pass.pdfは印刷・編集を制限するパスワードだけを設定したテスト用ファイルです。pdfinfo 26.08.0での出力は次のとおりでした。

Pages:           1
Encrypted:       no
Command Line Error: Incorrect password
grep exit=1
Encrypted:       yes (print:yes copy:yes change:yes addNotes:yes algorithm:RC4)

読み取れる点が2つあります。

• 開くためのパスワードが付いたPDFでは、pdfinfo自体が「Incorrect password」で止まり、grep Encryptedは何も出力しません。「Encryptedの行が出ない」を「暗号化なし」と読むと見落とします。終了コードか標準エラーも見ます。
• 編集制限だけのPDFはパスワードなしで開け、Encrypted: yesと出ます。公式の要件の文言に従えば、この種のPDFも対象外に当たります。

パスワードが分かっているなら、pdfinfo -upw <パスワード> user-pass.pdfで中身を読めます。PagesとEncrypted: yesが出れば、保護付きだと確定します。そのうえで発行元のアプリから保護なしで書き出し直し、直したファイルを渡します。

ファイルが壊れていないか

暗号化がなければ、ファイルの構造を疑います。AcrobatやプレビューアプリでPDFが開けても、パーサーごとに許容する非準拠の度合いは違います。

最初の関門はファイルの先頭5バイトです。

head -c 5 plain.pdf; echo
head -c 5 fake.pdf; echo
pdfinfo fake.pdf 2>&1 | tail -3

fake.pdfは、URLからダウンロードしたつもりがエラーページのHTMLを.pdfで保存したときを想定した、中身が<html>のファイルです。

%PDF-
<html
Syntax Error: Couldn't find trailer dictionary
Syntax Error: Couldn't find trailer dictionary
Syntax Error: Couldn't read xref table

正常なPDFは%PDF-で始まります。<htmlで始まっていれば、ダウンロードの失敗や認証ページが保存されただけで、PDFではありません。第三者のリポジトリに、Web取得したPDFをbase64で添付した際にmessages.1.content.2.pdf.source.base64.data: The PDF specified was not validの400が返った報告があります。報告者は、HTMLをPDFに偽装したものと途中で切れた本文が混ざりやすいと見て、添付前の先頭バイトとサイズの検証を提案しています。

途中で切れたPDFは、pdfinfoがCouldn't read xref tableなどを出して終了コード1になります。Ghostscript 9.20でgs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=fixed.pdf broken.pdfを実行すると、末尾のstartxrefが欠けた切れ端は「The file has been damaged」と報告され、出力が0バイトになりました。再書き出しで直るのは構造を読み取れるファイルだけです。読めない場合は、元のアプリからPDFを作り直します。

重いPDFは上限内でも失敗しうる

リクエストサイズとページ数の上限は、どちらもリクエスト全体の合計に対する値です。Files APIの上限は1ファイル単位です。

公式ドキュメントには、上限の表とは別に注意書きがあります。要点は2つです。

1つ目は、文字が小さいページが続くPDF・複雑な表・画像の多いPDFは、ページ数の上限に届く前にコンテキストウィンドウを埋めることがある点です。ページ数が上限内でも、トークン側で先に詰まります。

2つ目は、大きなPDFを含むリクエストは、Files APIを使ってもページ数の上限に届く前に失敗しうる点です。Files APIに載せれば通る、とは限りません。

対処は、文書をいくつかの区間に分割することです。大きなファイルでは、各ページが画像として処理されるので、埋め込み画像を縮小する手も挙がっています。

Claude Codeの報告(#15312)には、16.6MBのPDFで400になった例があります。一方で6MBでも出た報告があり、サイズの大小だけでは決まりません。上限を超えた場合は、Files APIなら別の400(「Exceeds context window size」など)や、サイズ超過の413が返ります。413との見分け方はClaude APIのリクエストサイズ上限と413エラーの見分け方にまとめています。アップロード手順と料金はClaude Files APIでPDFを処理する方法で扱っています。

画像だけのスキャンPDFが原因になるか

公式ドキュメントは、各ページを画像に変換し、抽出したテキストを画像と並べてClaudeに渡すと説明しています。画像だけのPDFを拒否する要件は挙げていないので、スキャンPDFであること自体は Could not process PDF の原因として挙がっていません。

ただし、テキストを持たないスキャンPDFには別の制約があります。ClaudeのCitationsでスキャンPDFを引用できない理由にあるとおり、Citationsはテキストを抽出できない文書を引用対象にできません。こちらは応答自体は返るので、Could not process PDFとは症状が別です。

「an image in the conversation could not be processed」と出たとき

Claude Codeでは、PDF以外にもAPI Error: an image in the conversation could not be processed and was removed.という文言が出ます。Claude Codeのエラー一覧は、この行を「APIが会話中の画像を受け付けなかった」ことを示すものと説明しています。サイズや寸法の上限を超えた画像が典型です。

PDFは各ページが画像としても処理されるため、画像の多いPDFを読ませた後に同じ症状を疑う場面があります。ただし、PDFが原因だと断定できる根拠は公式の一覧にありません。画像側の対処はClaude Codeの「Image was too large」エラーの対処にまとめています。

似た文言のエラーとの見分け方

Claude Codeが返すPDF too large・PDF is password protected・The PDF file was not validは、さらに別系統の文言です。PDF too largeはClaude Codeのエラー一覧で上限が最大100ページ・20MBと書かれており、API側の32MBとは数値も違います。一覧が示す対処は文言ごとに少し違います。大きすぎる場合は、Readツールでページ範囲を指定して読ませるか、pdftotextなどでテキストを抽出し、出力ファイルをパスで参照します。保護付きや無効なPDFは、パスワードを外すか元のアプリから書き出し直します。それぞれの意味はClaude CodeのPDFエラー3種の解説にあります。

Claude Codeでは、一度の失敗が会話に残る

Claude Codeでは、一度このエラーが出ると、同じ会話では直らなかった報告が複数あります。#15312では、16.6MBのPDFで400になったあと、画像・スラッシュコマンド・テキストだけの入力でも同じCould not process PDFが返り、セッションが使えなくなったとされています。6MBのPDFの報告(#20290)にも、無効なPDFを読んだあとはエラーが残り続け、/clearか再起動しか手がなかったというコメントがあります。

理由はissue上では推測にとどまりますが、症状としては「失敗したPDFが会話の履歴に残り、以後のリクエストで送られ続ける」形に見えます。直らないときは、会話を引き継がず/clearするか、新しいセッションで元のPDFを使わずに作業を再開します。

直らないときの順番

自動リトライとの関係にも注意が要ります。公式のエラー解説では、SDKの自動リトライは接続エラー・レート制限・5xxなど一時的な失敗が対象で、既定は2回です。400は挙がっていないので、この400を再送する処理は自分で書く必要があります。SDKごとの例外クラスと扱いはClaude APIのエラー形式とSDK例外クラスの言語別対応表にあります。

まとめ

先に調べるのは上限の数字ではなく、手元のPDFそのものです。Claude Codeで出たときは、元のPDFを直す前に/clearで会話を切り替えます。