ClaudeのBedrock ConverseでPDFの画像が読めない原因と直し方
Bedrock Converse APIはCitationsを有効にしないとPDFの画像・グラフを見ずテキスト抽出だけに落ちます。2つの処理モードの違いと、Citations有効化とInvokeModel移行という2つの直し方をまとめます。
Amazon BedrockのConverse APIでClaudeにPDFを渡すと、グラフや図表を無視してテキストだけを読んだような返答が返ることがあります。原因はCitationsです。Files APIでPDFを処理する方法ではこの現象を「よくあるつまずき」の1つとして触れるにとどめており、原因の切り分けと2つの直し方は本記事が担当します。Citationsを有効にしないまま送ると、Converse APIは視覚解析ではなく基本的なテキスト抽出モードへ自動で切り替わります。直し方は2つあります。Converse APIでCitationsを明示的に有効にするか、Citationsを必須としないInvokeModel APIに切り替えるかです。
Converse APIがPDFの画像を無視する理由
公式ドキュメントは、Bedrock経由のPDF処理を2つのモードに分けています。1つは文字だけを抜き出す「Converse Document Chat」、もう1つはページを画像としても読み、グラフやレイアウトまで解析する「Claude PDF Chat」です。Claude PDF ChatにはCitationsの有効化が必須で、有効にしなければConverse Document Chatが自動的に使われます。
通常のClaude APIやClaude Platform on AWSでは、PDFを送るとページごとにテキスト抽出と画像化が両方行われ、Claudeは常にその両方を見て回答します。テキストだけ・画像だけという分岐はありません。Bedrock Converse APIだけが例外で、この標準の挙動を得るためにCitationsという別機能のオンオフを条件にしています。
この分岐が厄介なのは、エラーが出ないことです。リクエストは成功し、レスポンスも返ってきます。ただし中身がテキストだけを読んだ結果になっているだけなので、「グラフの数値を答えて」と聞いても表の見出しから推測したような曖昧な回答が返り、実際には数値もレイアウトも見ていません。この仕様はConverse API固有で、Claude API本体やClaude Platform on AWSでは起きません。
Converse Document ChatとClaude PDF Chatの違い
| 項目 | Converse Document Chat | Claude PDF Chat |
|---|---|---|
| 有効化条件 | Converse Document ChatCitations無効時に自動で使われる | Claude PDF ChatCitationsを有効にしたときのみ |
| 画像・グラフ・レイアウトの解析 | Converse Document Chat不可(テキスト抽出のみ) | Claude PDF Chat可(各ページを画像としても処理) |
| トークン消費(3ページPDFの目安) | Converse Document Chat約1,000トークン | Claude PDF Chat約7,000トークン |
差は7倍近いトークン消費です。Citationsを有効にすれば解析の質は上がりますが、コストも跳ね上がる点は踏まえておく必要があります。参考までに、Bedrockを介さない通常のClaude API・Claude Platform on AWSでのPDFコストは、ページあたりのテキスト抽出分が内容密度に応じて1,500〜3,000トークン、それに画像分の解析コストが加算される計算です。Converse APIの1,000・7,000トークンという数字は、あくまでBedrockのドキュメント処理モード固有の目安です。BedrockでのClaude料金体系そのものはAWS BedrockのClaude料金は直接APIとどう違うかで扱っています。グラフや手書き注記のない定型フォーマットのPDFなら、あえてテキスト抽出モードのままにしてコストを抑える判断もあり得ます。
デフォルトでテキスト抽出モードに落ちる
見落としやすいのは、この切り替えが「デフォルト」の挙動だという点です。Citationsはオプトインの機能なので、boto3で素朴にConverse APIを呼び出すだけのコードは、意識しない限りCitationsを有効にしません。つまり多くのチームは、最初の実装でテキスト抽出モードに気づかないまま運用を始め、あとから「グラフを含むPDFだけ結果がおかしい」という形で気づきます。
リクエストサイズの上限(32MB)とページ数(1Mトークン未満のコンテキストウィンドウでは実質100ページ、それ以外は600ページ)の上限は、この画像・テキストの切り替えとは別の制約です。ページが多いPDFで結果が欠けるときは、モード切り替えの問題なのかページ数上限に当たっているのかを切り分けます。
さらに厄介なのは、密度の高いPDF(小さいフォントのページが多い、複雑な表、図が多い)はページ数の上限に達する前にコンテキストウィンドウそのものを埋め尽くすことがある点です。Claude PDF Chatモードは各ページを画像としても処理するため、Citationsを有効にした直後にこの問題が表面化しやすくなります。ページ数を減らす、文書をセクションごとに分割する、埋め込み画像をダウンサンプリングするといった対処が必要になります。
Citationsを有効にして視覚解析を復元する
Citationsは本来、回答の根拠になった原文箇所を引用として返す機能です。BedrockのConverse APIでは、この機能を有効化することが視覚PDF解析のスイッチを兼ねています。Anthropic Messages APIではdocumentコンテンツブロックにcitations: {"enabled": true}を付けて送ります。有効にすると、レスポンスにも通常のテキストに加えて引用情報が付随するようになります。Converse API側でこのフィールドを具体的にどう指定するか(パラメータ名や配置箇所)は、確認できた公式ドキュメントの範囲には記載が見当たりませんでした。引用情報が不要なら、次のInvokeModelへの切り替えの方がシンプルです。
InvokeModel APIに切り替える
Citationsを使いたくない、あるいはConverse側の設定を確認する時間がないなら、InvokeModel APIに切り替える方法があります。InvokeModelはCitationsを強制しないため、通常のPDF視覚解析がそのまま使えます。
import boto3
import json
import base64
bedrock = boto3.client(service_name="bedrock-runtime")
with open("document.pdf", "rb") as f:
pdf_data = base64.standard_b64encode(f.read()).decode("utf-8")
body = json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"messages": [
{
"role": "user",
"content": [
{
"type": "document",
"source": {
"type": "base64",
"media_type": "application/pdf",
"data": pdf_data,
},
},
{"type": "text", "text": "このPDFのグラフの内容を説明してください"},
],
}
],
})
response = bedrock.invoke_model(
body=body, modelId="global.anthropic.claude-opus-4-6-v1"
)
response_body = json.loads(response.get("body").read())
print(response_body.get("content"))documentブロックにcitationsフィールドを付けなくても、InvokeModelはPDFを画像としても解析します。テキスト抽出だけへ落ちるフォールバックはInvokeModelには存在しません。
modelIdはARN形式のベースモデルIDをそのまま渡すとcross-region inference対象のモデルではHTTP 400になります。global.・us.・eu.・jp.・apac.のいずれかの推論プロファイル接頭辞を付けたIDを使ってください。
どのモデル・どの統合で起きるか
この制約が及ぶのは、anthropic.claude-opus-4-6-v1のようなARN形式のモデルIDを使うレガシー統合(InvokeModel・Converseの旧API)です。Claude Opus 5・Sonnet 5・Fable 5系・Opus 4.8・Opus 4.7はARN形式のモデルIDを持たず、InvokeModel経由で呼ぶと新しいMessages APIエンドポイント(Claude in Amazon Bedrock)と同じ基盤で処理されます。これらの新しいモデルをConverse API経由で呼んだときに同じCitations制約が適用されるかどうかは、公式ドキュメントに明記がありません。Converse APIを使い続けるなら、モデルを切り替えるたびに挙動を確認するのが安全です。
もう一つ確認しておきたいのが、モデルのライフサイクルです。Bedrock上のARN形式モデルには現役・非推奨・提供終了の3段階があり、Claude Sonnet 3.7とOpus 4は提供終了済み、Sonnet 4・Opus 4.1・Haiku 3.5は非推奨(動作はするが新規利用は推奨されない)に区分されています。PDF解析の結果がおかしいと思って調べたら、実はモデルID自体が提供終了していてリクエストが別の形で失敗していた、という切り分けミスも起こり得ます。
Converse APIのCitations必須化は何を意味するか
AWSのConverse APIは元々、複数のモデルプロバイダーを共通インターフェースで扱うための仕様です。Anthropic固有のdocumentブロックとCitations機能を、AWS側の抽象化レイヤーに完全には統合しきれていないことが、この分岐の背景と読めます。Anthropicは新しいMessages APIエンドポイントとClaude Platform on AWSという、Converseを経由しない選択肢をすでに用意しました。この制約が解消される保証はなく、今後のConverse APIアップデートを待つのは得策とは言えません。新規に構成を組むなら、最初からConverseを避ける設計の方が長期的なメンテナンスコストは低いはずです。
まとめ — Bedrock Converseでこの問題に当たったら
Bedrock Converse APIでPDFの画像やグラフが読み取られないなら、まずCitationsが有効かを確認します。有効化で解決しない、あるいはCitations自体が不要ならInvokeModel APIへの切り替えが最短です。新規構築なら、最初からConverseを避けてClaude Platform on AWSや新しいMessages APIエンドポイントを選ぶ方が、この種の仕様差異に振り回されずに済みます。BedrockでのClaude Code利用時に生じる別の制約はBedrock/Vertex/FoundryでClaude Codeが使えない機能一覧にまとめています。Files APIを使ったPDF管理の基本はFiles APIでPDFを処理する方法を参照してください。ただしBedrockではFiles API自体が使えず、PDFはBase64埋め込みでのみ渡せる点は変わりません。