Amazon Bedrock Knowledge Bases の MULTIMODAL 解析で利用可能なモデルを東京リージョンで全網羅検証してみた

---

はじめに

Amazon Bedrock Knowledge Bases（以下KB）の「Advanced Parsing（解析設定）」を MULTIMODAL モードで運用しようとすると、設定画面に並ぶ基盤モデルのどれが実際に動くのか、AWS公式ドキュメントだけでは判断しきれません。公式は「Claude vision models / Nova vision models / Llama 4 vision models」とファミリー単位の記述で止まっており、個別のモデルIDは明示されていないためです。

筆者はアジアパシフィック（東京）リージョン（ap-northeast-1、下記東京リージョンと略）で運用中のKBに対し、Claude/Nova/Llama計17モデルで「①データソース設定（DS作成）→②Ingestionジョブ Sync 成功→③RAGクエリで関連結果が返るか」の3観点をAWS APIで検証しました。本稿はその結果と、運用上ハマりやすい落とし穴をまとめた実装者向けレポートです。

結論サマリー

東京リージョン×MULTIMODALで実用可能なのは10モデル。残り7モデルはリージョン未提供、KB Parser未対応、Vision非対応、Legacy扱い等で利用不可です。とくに以下4点は事前に押さえてください。

• Inference Profile ARNが事実上必須。東京リージョンはモデルカード上 in-region inference が「不可」となっているため、jp.*/apac.*/global.* のいずれかを使う必要がある。
• claude-sonnet-4-6 は Vision モデルだがKB Parserとして拒否される（"Invalid Bedrock Foundation Model Parser Provided"）。
• global.* Inference Profile はAWS Marketplace承認 + IAM権限（aws-marketplace:Subscribe）の両方が必要。Anthropic系は初回ユースケース申請も。
• Sync=COMPLETE だけでは成功判定不可。statistics.numberOfNewDocumentsIndexed >= 1 かつ numberOfDocumentsFailed == 0 を確認すべし（Nova Microが典型例）。
• Amazon OpenSearch Serverless（下記、AOSSと略）ベクター書き込み伝播に最大2分のラグあり。Sync完了直後のretrieveが空でも慌てず60〜120秒待ってリトライ。
• 公式ドキュメントの記載と実機挙動には乖離があり、本記事は実機検証結果を事実として扱う。

---

検証環境

項目	内容
リージョン	ap-northeast-1（東京）
KB タイプ	OpenSearch Serverless ベース（VECTOR）
Embeddings	amazon.titan-embed-text-v2:0
補助ストレージ	S3バケット（supplementalDataStorageConfiguration）
解析対象	PowerPoint由来のPDF（9ページ・2.5MB・図表複数）
検証日	2026-05-18

MULTIMODAL 設定で KB を作成するには、Vector構成内に supplementalDataStorageConfiguration で S3 ロケーションを指定する必要があります（KB作成時のみ設定可・後からの追加は不可）。また、データソースのS3バケットと補助ストレージのS3バケットが同一の場合、データソース側に inclusionPrefixes を指定して再取り込みを防ぐ必要があります。

---

検証手順（簡易）

各モデルについて以下を順次実行しました。

# 1) データソース作成（MULTIMODAL 解析設定）
aws bedrock-agent create-data-source \
  --knowledge-base-id "$KB_ID" --name "$DS_NAME" \
  --data-source-configuration '{"type":"S3","s3Configuration":{"bucketArn":"...","inclusionPrefixes":["docs/"]}}' \
  --vector-ingestion-configuration '{
    "parsingConfiguration": {
      "parsingStrategy": "BEDROCK_FOUNDATION_MODEL",
      "bedrockFoundationModelConfiguration": {
        "modelArn": "arn:aws:bedrock:ap-northeast-1:<account>:inference-profile/jp.anthropic.claude-sonnet-4-5-20250929-v1:0",
        "parsingModality": "MULTIMODAL"
      }
    }
  }'

# 2) Ingestion ジョブ開始
aws bedrock-agent start-ingestion-job --knowledge-base-id "$KB_ID" --data-source-id "$DS_ID"

# 3) RAG クエリ（AOSS伝播のため最大2分待機）
aws bedrock-agent-runtime retrieve \
  --knowledge-base-id "$KB_ID" \
  --retrieval-query '{"text":"Difyとは何ですか？"}' \
  --retrieval-configuration '{"vectorSearchConfiguration":{"numberOfResults":3}}'

KBあたりのデータソース上限は5、並列Ingestionジョブ上限は1 のため、検証スクリプトはモデル毎にDS作成→Sync→クエリ→DS削除を逐次で回しています。

---

検証結果

Anthropic Claude

モデル	LC	DS作成	Sync	RAG	総合
claude-3-haiku-20240307	LEGACY	✅	✅	✅(0.55)	✅
claude-3-sonnet-20240229	LEGACY	✅	❌	-	❌ ※30日未使用でアクセス停止
claude-3-5-sonnet-20240620	LEGACY	✅	✅	✅(0.55)	✅
claude-3-5-sonnet-20241022-v2	LEGACY	✅	✅	✅(0.60)	✅
claude-3-5-haiku-20241022	LEGACY	✅	❌	-	❌ ※東京未提供
claude-sonnet-4-20250514	LEGACY	✅	✅	✅(0.58)	✅
claude-sonnet-4-5-20250929	ACTIVE	✅	✅	✅(0.60)	✅
claude-sonnet-4-6	ACTIVE	❌	-	-	❌ ※KB Parser未対応
claude-haiku-4-5-20251001	ACTIVE	✅	✅	✅(0.58)	✅
claude-opus-4-5-20251101	ACTIVE	✅	✅	✅(0.55)	✅ ※Marketplace承認要
claude-opus-4-6-v1	ACTIVE	✅	✅	✅(0.55)	✅ ※Marketplace承認要
claude-opus-4-7	ACTIVE	✅	✅	✅(0.55)	✅

参考：Claude Opus 4, Opus 4.1, 3.7 Sonnet は東京リージョンに Inference Profile が無く対象外。

Amazon Nova / Meta Llama

モデル	DS作成	Sync	RAG	総合
amazon.nova-pro-v1:0	✅	✅	✅(0.57)	✅
amazon.nova-lite-v1:0	✅	✅	✅(0.60)	✅
amazon.nova-micro-v1:0	✅	△	❌	❌ ※Vision非対応
meta.llama4-maverick / scout	✅	❌	-	❌ ※東京未提供

---

運用ノウハウ：4つの落とし穴

1. Inference Profile ARN が事実上必須

bedrockFoundationModelConfiguration.modelArn には FM ARN も Inference Profile ARN も指定できますが、東京リージョンでは多くのモデルでInference Profile ARNが事実上必須となります。

理由はClaude Sonnet 4.5 のモデルカードにある通り、ap-northeast-1 の In-Region inference 列が ❌（=東京リージョンエンドポイントへの FM ARN 直接呼び出し不可）であるためです。同様にClaude Sonnet 4/4.5/Haiku 4.5/Opus 4.5/4.6/4.7 も東京の In-Region は ❌ で、いずれも Geo (jp.* 等) または Global (global.*) 経由でしか呼び出せません。

FM ARNを指定すると StartIngestionJob で以下のエラーになります。

Invocation of model ID ... with on-demand throughput isn't supported.
Retry your request with the ID or ARN of an inference profile that contains this model.

ベストプラクティス：解析モデルARNは必ず Inference Profile ARN を使う。東京リージョンでは原則 apac.* または jp.* の system Inference Profile を選び、両方がない場合のみ global.* を使います。

2. global.* Profile は Marketplace 承認とIAM権限の両方が必要

Opus 4.5 / 4.6 のように jp.* プロファイルが用意されておらず global.* のみのモデルでは、初回呼び出し時に AWS Marketplace のサブスクライブが走ります。KBロール（または初回呼び出しユーザー）に以下が無いと失敗します。

{
  "Effect": "Allow",
  "Action": ["aws-marketplace:Subscribe", "aws-marketplace:ViewSubscriptions"],
  "Resource": "*"
}

加えて Anthropic モデルは初回利用時に Bedrockコンソール上でユースケース申請を提出する必要があります。bedrock get-foundation-model-availability --model-id <id> で agreementAvailability.status が AVAILABLE か事前確認できます。

3. Sync=COMPLETE は成功を保証しない

nova-micro は Vision非対応にもかかわらず DS作成・Ingestion開始・Sync=COMPLETE まで通過します。しかし統計は numberOfNewDocumentsIndexed: 0 / numberOfDocumentsFailed: 1、failureReasons に "internal error" が記録され、実体としては失敗しています。

運用チェック：必ず以下のフィールドで判定する。

aws bedrock-agent get-ingestion-job ... \
  --query 'ingestionJob.{status:status, indexed:statistics.numberOfNewDocumentsIndexed, failed:statistics.numberOfDocumentsFailed, reasons:failureReasons}'

status=COMPLETE かつ indexed >= 1 かつ failed == 0 を成功条件とすべきです。

4. AOSS インデックス伝播は最大2分

Sync=COMPLETE 直後に retrieve を叩くと結果が空配列で返るケースが頻発します。これはOpenSearch Serverless のベクトル書き込み伝播ラグで、60〜120秒の待機後にリトライすることで安定します。CI/CD やバッチ処理に組み込む場合はリトライポリシーを実装してください。

---

クリーンアップ

検証用KBは課金資源（AOSS最低稼働コスト・S3保管料）を持つため、削除を忘れずに。

aws bedrock-agent delete-data-source --knowledge-base-id "$KB_ID" --data-source-id "$DS_ID"
aws bedrock-agent delete-knowledge-base --knowledge-base-id "$KB_ID"
# AOSS コレクション・S3バケット・IAMロールは CloudFormation 経由なら stack delete で連動

なお、CloudFormationスタックを --deletion-mode FORCE_DELETE_STACK する場合でも、CloudFormationの実行ロールが必要です。AWS CDK が作成した cdk-hnb659fds-cfn-exec-role-* を先に削除してしまうと、その後のスタック削除が失敗するので注意してください。

---

今後の展望

claude-sonnet-4-6 の KB Parser 未登録のように、新モデルがリリースされても KB 側の allowlist 更新には数週間〜数ヶ月のラグとなる場合があります。本検証のように CreateDataSource API を空打ちして "Invalid Bedrock Foundation Model Parser Provided" エラーの有無で対応状況を逆引き確認する手法は、新モデル投入直後の運用設計に有効です。

Amazon Bedrock Data Automation（プレビュー・us-west-2のみ）が東京リージョンに来れば、解析モデルを意識せずマネージドにマルチモーダル取り込みできるようになる見込みです。それまでは本稿のような実機検証ベースのモデル選定が必要となります。

---

おわりに

東京リージョンでBedrock KBの解析設定を運用する方にとって、本検証結果が「どのモデルを選ぶべきか」「どの順序で動作確認すべきか」の判断材料になれば幸いです。AWS公式ドキュメントの記述よりも実機でのAPI挙動の方が信頼でき、特に新モデル投入直後やリージョン拡大直後は本記事のような検証を都度実施することをおすすめします。

※ 本記事の結果は検証日時点の情報です。AWS側のサービス更新により挙動が変わる可能性があります。

ロータッヘイ(執筆記事の一覧)

24卒入社の香港人です。
2025 Japan All AWS Certifications Engineers
リンゴちゃん（デボンレックス）にいつも癒されています。