ひとことで言うと
紙・画像・PDF の中身を、テキストだけでなく「関係」ごと取り出す API です。フォームはキーバリューのペアとして、表はセルとして、署名はバウンディングボックスとして返り、LAYOUT を指定すると読み順に並んだ段落・見出し・リストとして返ります。手書き文字も対象です（英語のみ）。
要するに、書類を「読む」のではなく「解体して部品名を付ける」機械です。マルチモーダル FM に画像を渡すのは、書類を見せて「何が書いてある？」と人に聞くのに近い——答えは自然文で返り、毎回少しずつ違います。Textract が返すのは座標と信頼度が付いた部品のリストで、同じ書類なら同じ形が返る。下流でスキーマに突っ込めるかどうかが分かれ目です。
なぜ生まれたか
古典的な OCR は「文字を読む」ところで止まります。返るのは平坦なテキストで、「Name:」と「Jane Doe」が対応していることも、そのセルが表の何行目かも落ちてしまう。フォームや請求書を処理したい側は、OCR の後段に自前のルールベース（座標のテンプレート、正規表現）を積むしかなく、書式が1つ変わるたびに壊れました。
Textract は、抽出の単位を文字ではなく関係に置き直しました。公式は解析結果を「テキスト・フォーム・表・クエリ応答・署名の5カテゴリ」と説明しています。さらに QUERIES で「顧客の社会保障番号は？」のように質問で欲しい値を指定でき、LAYOUT で推定される読み順（上から下、左から右）に並べ直せます。この最後の1つが、そのまま LLM への入力整形として効きます。
| 何が不便だったか | Textract の答え |
|---|---|
| OCR がテキストを平坦化してしまう | FORMS（キーバリュー）／TABLES（セル）で関係ごと返す |
| 書式ごとに座標テンプレートを書く羽目になる | QUERIES（欲しい値を質問で指定）／Custom Queries（自社文書でアダプタを学習） |
| 段組みの文書を読ませると文の順序が壊れる | LAYOUT（段落・見出し・図表を、推定される読み順で返す） |
| 大量ページの文書が同期処理に載らない | 非同期オペレーション（S3 の文書を Start* → SNS 通知 → Get*） |
| 免許証・請求書ごとに解析器を作っていた | AnalyzeID / AnalyzeExpense / Analyze Lending（用途特化の専用オペレーション） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 文字だけ取りたい | DetectDocumentText（同期）／StartDocumentTextDetection（非同期） | D1 |
| フォームを構造化 | AnalyzeDocument に FORMS（キーバリューのペア。チェックボックスも含む） | D1 |
| 表を取り出す | AnalyzeDocument に TABLES（セル・表題・脚注・表の種別） | D1 |
| 欲しい値を質問で取る | AnalyzeDocument に QUERIES。他の FeatureType と併用可 | D1 |
| 署名の有無と位置 | AnalyzeDocument に SIGNATURES（単独指定だと通常のテキスト検出結果も返る） | D1 |
| LLM に渡すための読み順整形 | AnalyzeDocument に LAYOUT（段落・見出し・リスト・図・表・ページ番号を読み順で） | D1 / D2 |
| 請求書・領収書 | AnalyzeExpense（ページごとに1件の請求書として扱い、ページ間の文脈は保持しない） | D2 |
| 米国の身分証 | AnalyzeID（US パスポートと US 運転免許証のみ） | D2 |
| ローン書類の分類＋振り分け | Analyze Lending（ページを分類して適切な解析オペレーションに自動ルーティング） | D2 |
| 自社文書向けの精度改善 | Custom Queries でアダプタを学習し、AdapterId を付けて呼ぶ | D1 |
試験でどう問われるか
AIP-C01 での Textract は、「非構造データを FM に食わせる前段をどう作るか」の分岐で出ます。競合する選択肢は昔ながらの OCR ではなく、Bedrock Data Automation（BDA）とマルチモーダル FM に直接読ませる案です。この三択の分け方が本体になります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Textract か BDA か | 欲しいのが決まった要素の抽出（キーバリュー・表セル・署名の位置・座標・信頼度）で、下流が厳密なスキーマを期待する → Textract | 「複数モダリティ（動画・音声込み）を1本の API で」と書いてあるのに Textract を選ぶ。BDA は文書・画像・動画・音声を扱う |
| Textract かマルチモーダル FM か | 同じ入力に同じ出力が要る／座標や信頼度が要る／監査で根拠を示す → Textract | 「FM に画像を渡して JSON で返させればいい」。プロンプト依存で形が揺れ、位置情報も付かない |
| Knowledge Bases に PDF を取り込む | 図・グラフ・表を含む PDF → KB のパーサとして BDA か FM を選ぶ（既定パーサはテキストしか出さない） | ここで Textract を選ばせる選択肢。KB のパーサ選択肢に Textract は並ばない |
| 1,000ページの PDF を処理 | 非同期オペレーション（S3 の文書を Start* → SNS → Get*） | 「AnalyzeDocument をページごとにループ」。同期は PDF/TIFF が1ページまでなので、そもそも通らない |
| 表と署名を同時に取りたい | FeatureTypes に複数指定（TABLES と SIGNATURES を併記）。1回の呼び出しで済む | 「機能ごとに API を分けて2回呼ぶ」 |
| 免許証・パスポートの読み取り | AnalyzeID（ただし US 発行のもの） | AnalyzeDocument に FORMS（動くが、身分証の項目名を自分で組み立てる羽目になる）／US 以外の身分証に AnalyzeID を当てる案 |
| 請求書の総額を取りたい | AnalyzeExpense | QUERIES で「合計金額は？」を投げる案（できるが、請求書用の正規化は AnalyzeExpense の仕事） |
| 段組みの資料を RAG に入れたら回答が支離滅裂 | 読み順が壊れている → LAYOUT で読み順に整形してからチャンキング | チャンクサイズを変える／埋め込みモデルを替える（原因は埋め込みではなく入力の順序） |
1問拾える境目: Textract の対応言語は英語・フランス語・ドイツ語・イタリア語・ポルトガル語・スペイン語で、Queries の検出は英語のみ、手書き認識も英語のみ。さらに公式は「日本語や中国語のような縦書きテキストはサポートしない」と明記しています。「日本語の申込書を Textract で処理する」というシナリオは、選択肢として置かれていても正解になりません。ここはマルチモーダル FM や BDA を検討する側に倒れます。
実務でどう使うか
- 同期と非同期は「速さ」ではなく「入るかどうか」で決まります。 同期は JPEG/PNG/PDF/TIFF がメモリ 10 MB まで、かつ PDF と TIFF は1ページまで。非同期は PDF/TIFF が 500 MB・3,000ページまで。複数ページの PDF を同期に投げる設計は、負荷とは無関係に落ちます
- 非同期の入力は S3 のオブジェクトです。
Start*がJobIdを返し、完了は SNS トピックに publish されます。公式は「Getを繰り返し呼んで完了を確認するのは推奨しない（スロットリングされる）」と明記しており、SQS か Lambda で受けるのが前提の設計です - 非同期の結果は 7 日で消えます。 既定では Textract 側のバケットに暗号化して保管され、
Getはジョブ開始から 7 日以内しか取得できません。残したいならOutputConfigで自分の S3 バケットを指定します ClientRequestTokenの寿命も 7 日です。同じトークンで同じStartを呼ぶと同じJobIdが返りジョブは再実行されません。パラメータをわずかに変えて再送するとidempotentparametermismatchexceptionになります。リトライ処理を書くときにここで詰まります- Queries には1ページあたりの上限があります（同期は 15、非同期は 30）。「全項目を Queries で取る」設計は、書式が大きいと上限に当たります
AnalyzeExpenseは複数ページの文脈を保持しません。 各ページを独立した請求書として扱うので、明細が2ページにまたがる請求書は下流で結合する必要があります- XFA ベースの PDF は非対応、パスワード付き PDF も不可。 現物の PDF がどちらかであるケースは実務では普通にあります
- 文字の最小高は 15 ピクセル（150 DPI で 8 pt 相当）。スキャン解像度を落としたバッチが丸ごと精度不足になる原因はたいていこれです
「Textract に通したから構造化データになった」とは限りません。返るのは Block オブジェクトの配列で、キーバリューや表を業務項目に写像するのは自分の仕事です。ここを省きたいなら BDA（ブループリントで業務スキーマを定義する）を選ぶ、というのが設計上の分岐で、試験の選択肢もその形で並びます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock Data Automation | BDA は文書・画像・動画・音声を生成AIで処理して構造化出力にする統合サービス。Textract は文書に特化して、座標・信頼度付きの要素を返す。「複数モダリティを1つの API で」と書いてあれば BDA |
| マルチモーダル FM に直接読ませる | FM は自然文で答え、出力の形が揺れる。決定性・座標・信頼度が要件に出たら Textract |
| Bedrock Knowledge Bases のパーサ | KB のパーサ選択肢は「既定パーサ／BDA／基盤モデル」の3つ。Textract はここに出てこない。KB の外で前処理として使うか、KB のパーサを選ぶかは別の話 |
| Amazon Comprehend | Textract は取り出す（画像・PDF → テキストと構造）。Comprehend は解析する（テキスト → 実体・感情・PII）。ふつうは Textract → Comprehend の順に並ぶ |
| Amazon Rekognition | Rekognition は画像・動画の物体・顔・シーン。文字も読めるが、文書の構造は Textract の担当 |
| Custom Queries と Comprehend Custom | どちらも「自社データで既製モデルを寄せる」だが、Textract のアダプタは文書からの抽出、Comprehend Custom はテキストの分類・実体認識。入力段が違う |
想起チェック
Q1. 「PDF の請求書から、FM に渡すための構造化データを作りたい」。Textract と Bedrock Data Automation を分ける基準は何ですか。
欲しい出力の形です。座標・信頼度付きの要素（キーバリュー、表セル、署名位置）を厳密なスキーマに流し込むなら Textract。文書に加えて画像・動画・音声も同じ API で扱い、業務スキーマの出力まで任せたいなら BDA です。
Q2. 300ページの PDF を `AnalyzeDocument`（同期）で処理する設計はなぜ通りませんか。
同期オペレーションは PDF と TIFF を1ページしか受け付けないからです（加えてメモリ 10 MB の上限）。複数ページは非同期の StartDocumentAnalysis を使い、S3 の文書を指定して SNS で完了を受けます。
Q3. 段組みのレポートを RAG に取り込んだら、回答の文が前後で繋がりません。Textract 側で打てる手は？
FeatureTypes に LAYOUT を加えることです。段落・見出し・リスト・図表を、推定される読み順（上から下、左から右）で返すので、チャンキング前に文の順序が直ります。
Q4. 非同期ジョブを投げた後、結果はいつまで取得できますか。
ジョブ開始から 7 日です。既定では Textract 所有のバケットに暗号化保管され、Get* でしか取れません。それ以上残すなら OutputConfig で自分の S3 バケットを指定します。