ひとことで言うと
文書・画像・動画・音声といった非構造コンテンツを、単一の API で構造化データに変換する Bedrock の機能です。公式の言い方では「複数の AI モデルとサービスを管理・オーケストレーションする必要をなくす、統一された API 駆動の体験」を提供します。
要するに、モデルではなく「出力の形」を発注する窓口です。普通の FM 呼び出しは「どのモデルに・どんなプロンプトで頼むか」を自分で決めますが、BDA に渡すのはファイルと、欲しいフィールドの一覧（ブループリント）だけ。どのモデルが動いたかは表に出てきません。裏側の可視化が消える代わりに、出力スキーマが契約になるのが交換条件です。
なぜ生まれたか
非構造データから業務用の JSON を作る作業は、長くサービスの数珠つなぎでした。PDF は Textract で OCR、そこから固有表現を Comprehend、音声は Transcribe、画像は Rekognition、最後に FM でプロンプトを書いて整形する。モダリティごとに別の API・別の出力形式・別のエラー処理が要り、ページ数や動画長のスケールはすべて自分で捌く必要がありました。
BDA はこれを 1つの非同期ジョブにまとめました。加えて、精度側の道具として信頼度スコアとvisual grounding（抽出元の位置の裏付け）が組み込まれています。
| 日付 | 何が起きたか |
|---|---|
| 2024-12-04 | プレビュー公開。 文書・画像・動画・音声の非構造マルチモーダルコンテンツからの洞察生成を自動化する Bedrock の新機能として発表（当初は米国西部オレゴンのみ） |
| 2025-03-03 | GA。 文書精度・動画要約精度の改善、35,000超の企業ロゴ検出、クロスリージョン推論への対応、KMS カスタマー管理キー・PrivateLink・タグ付けが入る。Knowledge Bases の RAG ワークフローにおけるパーサとしての位置づけもここで明示 |
| 2025-12-19 | ブループリントの instruction optimization。 正解ラベル付きのサンプル文書（最大10件）から、ブループリントの自然言語指示を自動で refine する |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| インテリジェント文書処理（IDP） | 分類・抽出・正規化・検証のオーケストレーションを書かずに、非構造文書を業務スキーマの JSON にする | D1・D2 |
| メディア解析 | 動画のシーン単位の要約、不適切コンテンツの検出、映像内テキストの抽出、広告・ブランドによる分類 | D2 |
| RAG の前処理 | Knowledge Bases のデータソースのパーサに BDA を指定し、図・チャート・表・画像を抽出して S3 に保存させる | D1 |
| 決まったフィールドの抽出 | カスタム出力＋ブループリント。フィールド名・型（string / number / boolean）・自然言語の説明（正規化と検証のルール）を定義する | D1・D2 |
| ジョブの結果通知 | InvokeDataAutomationAsync の notificationConfiguration で EventBridge に流し、後段を起動する | D2 |
| 動画の部分処理 | assetProcessingConfiguration で開始・終了ミリ秒を指定し、5分以上の区間を1本の動画として扱わせる | D2 |
試験でどう問われるか
BDA は D2.5「アプリ統合パターンと開発ツール」に名指しで載っているので、主役として出ます。問われ方は一貫していて、**「自分でパイプラインを組むか、BDA に任せるか」**の分岐です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 複数モダリティの非構造データを構造化したい | 「文書も画像も動画も音声もある」「オーケストレーションの手間を減らしたい」 → BDA | Textract・Transcribe・Rekognition・Comprehend を Step Functions で自前接続する案（動きはするが、公式が「その必要をなくす」と言っている構成） |
| PDF に図・チャート・表が含まれる Knowledge Base | 図表も引けるようにしたい → パーサに BDA（または FM パーサ）を選ぶ | Bedrock default parser（テキストしか出力しない）／チャンクサイズを変える案 |
| パーサの中で BDA と FM のどちらか | 追加のプロンプト不要・ページ数課金でよい → BDA。抽出用プロンプトを自分で書き換えたい → FM パーサ（トークン課金） | 「プロンプトをカスタマイズしたいので BDA」（BDA は追加プロンプトを与えない設計） |
| 抽出するフィールドを固定したい | 業務スキーマに合わせた JSON が要る → カスタム出力＋ブループリント | 標準出力のままアプリ側でパースする案／FM に JSON Schema をプロンプトで渡す案 |
| 同期で結果が欲しい | InvokeDataAutomation（同期）は画像のみ。それ以外は InvokeDataAutomationAsync ＋ GetDataAutomationStatus | 動画・音声を同期 API で処理する選択肢／Lambda の同期実行で 240 分の動画を処理する案 |
| ブループリントの抽出精度が出ない | 正解データ付きのサンプルがある → instruction optimization（InvokeBlueprintOptimizationAsync） | ファインチューニング／temperature の調整（BDA にモデルパラメータの露出はない） |
| 本番に出す前に検証したい | ブループリントの DEVELOPMENT ステージで試し、CopyBlueprintStage で LIVE へ | ブループリントを作り直して差し替える案（バージョン管理の意図が消える） |
Knowledge Bases のパーサ選択には、コストの片道切符があります。公式が明記しているとおり、パーサに BDA か FM を選ぶと、データソース内のすべての .pdf がその方法で解析されます。テキストだけの PDF も例外なくで、既定パーサには戻りません。「図表を含む PDF が数枚あるから BDA に切り替える」は、残り数千枚のテキスト PDF もページ課金の対象にする決定です。
実務でどう使うか
- 同期と非同期で制限が別物です。 非同期の文書は最大 500 MB、splitter 有効時で 3,000 ページ（コンソール経由は 200 MB・20 ページ）。同期は 50 MB・10 ページで splitter は使えません。設計時にここを取り違えると、PoC は通って本番で落ちます
- 日本語の文書は、標準の対応入力言語に入っていません。 文書の Supported Input Languages は 英語・ドイツ語・スペイン語・フランス語・イタリア語・ポルトガル語で、縦書きは非対応と明記されています。一方音声の対応入力言語には日本語・韓国語・中国語・広東語が含まれます。モダリティによって言語対応が違うのが、日本の案件で最初に踏む段差です
- プロジェクト内のブループリント数の上限は文書 40・画像 1・音声 1・動画 1。 文書が複数あるときは、BDA がレイアウトが最も一致するブループリントに自動で振り分けます。アカウント単位ではプロジェクト 100・ブループリント 1,000・ブループリントのリーフフィールド 100 が上限です
- 公式ページ間で、カスタム出力の対象モダリティの記述が揺れています。 How it works は「カスタム出力は文書・音声・画像のみ」と書き、Custom output and blueprints 側は「文書 40・画像 1・音声 1・動画 1」と書いています。動画のカスタム出力を前提に設計するなら、実機で確認してから決めます
dataAutomationProfileArnは呼び出しの引数に入っています。 GA 時にクロスリージョン推論対応が入った経路がここです。ジョブの入出力は S3、暗号化はencryptionConfiguration（KMS）で指定します- 標準出力は常に返ります。 カスタム出力を設定していても、公式は「BDA は常に標準出力の応答を返す」と明記しています。両方が返る前提でパースを書きます
DOCX はページ番号が当てになりません。DOCX は処理前に PDF へ変換されるため、公式が「DOCX ファイルではページ番号のマッピングが機能しない」と書いています。監査で「この値は何ページ目から取ったか」を出す要件があるなら、入力を PDF に寄せる必要があります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Textract | Textract は文書からテキスト・表・フォームを取り出すところまで。BDA は業務スキーマの JSON まで運び、動画・音声も同じ API で扱う |
| Amazon Transcribe / Rekognition | どちらも単一モダリティの専用 API。BDA は「それらを自分で束ねる必要をなくす」ために置かれている |
| Amazon Comprehend | Comprehend はテキストに対するエンティティ抽出・分類。入力が PDF や動画のままでは始まらない |
| Bedrock Knowledge Bases | Knowledge Bases は検索の仕組み。BDA はその入口のパーサとして選べる部品で、競合ではなく上流 |
| FM を直接呼ぶ（プロンプトで JSON 化） | プロンプトを自分で調整したい・トークン課金で回したいなら FM。追加のプロンプトなしでページ課金なら BDA |
| 標準出力とカスタム出力 | 標準出力はデータ型ごとの既定の情報（音声の文字起こし・動画のシーン要約・文書の要約）。カスタム出力は自分が定義したフィールドだけを取りに行く |
想起チェック
Q1. Knowledge Base のデータソースが「図とチャートを含む PDF」のとき、既定パーサではなぜ足りませんか。
Bedrock default parser はテキストファイル内のテキストしか解析しないためです。図・チャート・表・画像を抽出して S3 に保存させたいなら、BDA か FM をパーサに選びます。
Q2. パーサとして BDA と FM のどちらを選ぶかを分ける基準は何ですか。
抽出プロンプトを自分でカスタマイズしたいかどうかと、課金の単位です。BDA は追加のプロンプト不要でページ数課金、FM パーサは既定プロンプトを書き換えられて入出力トークン課金です。
Q3. 240 分の動画を BDA で処理します。同期 API は使えますか。
使えません。InvokeDataAutomation（同期）は画像のみです。動画は InvokeDataAutomationAsync で投げ、GetDataAutomationStatus で結果の S3 の場所を取ります。
Q4. カスタム出力の抽出精度が要件に届きません。BDA の枠内で最初に取る手は何ですか。
ブループリントの instruction optimization です。正解ラベル付きのサンプル文書（最大10件）を渡し、フィールドの自然言語指示を refine させます。BDA にモデルのファインチューニングや推論パラメータの露出はありません。