AWSタスク特化AI Vol1｜Textract・Comprehend・Rekognition・Transcribe

1. タスク特化AIの本番課題と4サービスの全体像

生成AI（Bedrock）が広く注目される一方、本番現場の日常業務を見渡すと、むしろ「定型かつ高頻度なタスク」が圧倒的なボリュームを占めています。請求書・契約書から特定項目を抜き出す、問い合わせメールを担当部門別に振り分ける、製品の外観検査画像で不良を判定する、コールセンターの通話内容を文字起こしして記録する——これらは毎日何千何万件も繰り返される定型処理であり、精度・コスト・速度の要件が厳しく求められます。

このような定型タスクに対して、基盤モデル（生成AI）を都度適用するのは必ずしも最適解ではありません。生成AIはプロンプト次第で答えが変わるため、「帳票の金額フィールドを必ず正確に抽出する」といった確定的な要求には向いていません。また、トークン課金の生成AIは大量呼出でコストが増大し、レイテンシも数百ミリ秒〜数秒かかるため、リアルタイム処理や大量バッチ処理には不利なケースが生じます。

そこで実力を発揮するのが、特定タスクに特化した学習済みAI APIです。AWSが提供するAmazon Textract・Amazon Comprehend・Amazon Rekognition・Amazon Transcribeの4サービスは、それぞれの専門領域で膨大なデータにより事前学習されており、追加のモデル学習なしに即時利用できます。高精度・低コスト・低レイテンシの三拍子が揃い、本番環境への導入障壁も低いのが特長です。

2023〜2024年の生成AIブームを経て、多くの企業が「生成AIで全部解決しよう」という試みから、「定型タスクはタスク特化AIに任せ、生成AIは創造的作業に集中させる」という実践的なアーキテクチャに舵を切っています。これは生成AIを否定するものではなく、両者の強みを適切に使い分けることで、精度・コスト・速度を最大化するアプローチです。タスク特化AIは「既に解けている問題を確実に高速・低コストで解く」ための武器、生成AIは「新しい文章や判断を生み出す」ための武器という棲み分けです。

タスク特化AI vs 生成AI — 使い分けの軸

タスク特化AIと生成AIの使い分けは、「入力と出力が決まっているか否か」が一番シンプルな判断軸です。

帳票から金額を抽出したい、メールを5分類に振り分けたい、画像内に不審物があるか判定したい——このような要件はタスク特化AIに軍配が上がります。一方、「顧客の問い合わせ内容に共感的な返信文を生成する」「複数ドキュメントを統合して要約レポートを作る」といった創造的・非定型な処理には生成AIの柔軟性が活きます。

使い分けの判断フローは次の通りです。

1. タスクを特定する — 抽出・分類・認識・文字起こしのいずれかに当てはまるか確認します
2. 精度要件を確認する — 毎回同じ形式の構造化出力が必要か確認します
3. スループットとコストを確認する — 大量処理・低コスト要件があるか確認します
4. 専用サービスで賄えるか確認する — 4サービスのAPIで対応できる範囲か確認します

以上が全てYESならタスク特化AIを選択します。NOが含まれる場合、あるいはタスクが複合的な場合は生成AIとのハイブリッド設計を検討します。

ハイブリッド設計でベストオブブリーズを実現

実際の本番システムでは、タスク特化AIと生成AIを組み合わせた「ハイブリッドアーキテクチャ」が定石になっています。タスク特化AIで定型処理を高精度・低コストに済ませ、生成AIで付加価値を乗せるというパターンです。

パターン1: 請求書処理パイプライン

Textract（帳票から金額・品目・日付などの構造データを抽出）→ Bedrock（抽出データをもとに発注確認レポートを自然言語で生成）

TextractのQUERIES機能で「合計金額は？」「発注日は？」を直接指定して高精度に抽出し、Bedrockで担当者向けの自然言語サマリを生成します。Textractがなければ帳票全体をBedrockに送る必要があり、OCR精度とコストの両面で不利です。専用サービスの組み合わせにより、精度と経済性を両立できます。

パターン2: コンタクトセンター分析

Transcribe（通話音声を文字起こし・話者分離）→ Comprehend（感情スコア・エンティティ・問題カテゴリを抽出）→ Bedrock（顧客ニーズのサマリと次のアクション提案を生成）

定型の文字起こしと感情分析はタスク特化AIに任せ、オペレーターへの提案生成には生成AIを使います。Transcribeの話者分離（Diarization）により、顧客側とオペレーター側の発言を分離して分析できます。Call Analyticsを活用すれば通話要約まで自動化可能です。

パターン3: メディアコンテンツ審査

Rekognition（画像・動画内の不適切コンテンツを自動検出・信頼度スコア付け）→ 閾値を下回るものだけ人手レビュー（Amazon A2I）→ 境界ケースをBedrock（コンテキストを踏まえた最終判断支援）

全件を人手レビューするコストを大幅に削減しつつ、自動化による誤審査のリスクも人手ゲートで抑えられます。Rekognitionの3階層タクソノミー（L1-L3）で不適切コンテンツを詳細分類でき、審査基準の標準化にも役立ちます。

4サービスの守備範囲

本記事が扱う4サービスの守備範囲を整理しておきます。

Amazon Textract は、PDFや画像形式の文書からテキスト・表・フォーム・指定項目を構造的に抽出するサービスです。単なるOCRを超え、表の構造やフォームのキーバリュー関係まで認識します。TABLES・FORMS・QUERIES・LAYOUTの4つのFeatureTypesを使い分けることで、様々な帳票・文書形式に対応できます。インテリジェントドキュメントプロセッシング（IDP）の中核として使われます（§2で詳解）。

Amazon Comprehend は、テキストを言語学的に分析するサービスです。プリトレーンドAPIとしてエンティティ認識（人名・地名・組織名等）、感情分析（ポジティブ/ネガティブ/ニュートラル/混在）、PII（個人識別情報）の検出・マスクを提供します。Custom ClassificationとCustom Entity Recognitionにより、独自の分類モデルもML不要で構築できます（§3で詳解）。

Amazon Rekognition は、画像・動画を対象にラベル検出・顔分析・コンテンツモデレーションを行うサービスです。事前学習済みAPIによる即時利用に加え、Custom Labelsで独自の物体・シーン・ロゴ・製品検出に対応します。顔認識機能はプライバシーと法規制への十分な配慮が必要です（§4で詳解）。

Amazon Transcribe は、音声をテキストに変換するサービスです。リアルタイムストリーミング（HTTP/2・WebSocket）と非同期バッチ処理の2経路を提供します。カスタム語彙・カスタム言語モデル・Call Analyticsなど本番向けの機能が充実しており、コンタクトセンター分析との相性が特に高いサービスです（§5で詳解）。

本記事の前提と既存記事との棲み分け

本記事はAWSタスク特化AI4サービスのAPI設計・本番運用パターンに焦点を当てています。以下の内容は既存記事を参照ください。

• S3・Lambda・IAM・EventBridgeの基本操作 ：本記事ではタスク特化AIとの連携設計を扱います。S3バケット設定やLambda関数のデプロイ手順は前提知識として扱います。
• Step Functionsの基本操作 ：タスク特化AIジョブのオーケストレーションパターンを扱いますが、Step Functions自体の操作手順は既存記事を参照ください。
• 生成AI（Bedrock）の基盤モデル操作 ：ハイブリッド設計でBedrockとの連携に触れますが、Bedrock自体の操作手順は以下の既存記事を参照ください。
• Amazon Connectの基本設定 ：Transcribe Call Analyticsとの連携に触れますが、Connect自体の設定手順は既存記事を参照ください。

想定読者はAWSの基本的なサービスを理解した上で、タスク特化AIを本番システムに組み込みたいエンジニア・アーキテクトです。

タスク特化AIが特に有効なシナリオ

以下のようなシナリオでは、タスク特化AIが生成AIより優先的に有効です。

• 大量定型文書処理 ：毎日数千件の請求書・領収書・申込書を処理する場合、Textractで構造抽出してRDBに格納するパイプラインがコスト効率に優れます。
• リアルタイム音声処理 ：コールセンターでの通話を即時文字起こしする場合、Transcribeのストリーミング接続により低遅延で処理できます。
• コンテンツ自動審査 ：UGC（ユーザー生成コンテンツ）の画像・動画を大量審査する場合、Rekognitionで9割以上を自動処理し境界ケースのみ人手レビューに回すコスト配分が有効です。
• 顧客フィードバック分類 ：問い合わせメールを自動分類してルーティングする場合、Comprehendのカスタム分類で専用モデルを構築し精度と速度を両立できます。

本記事を読み進める前に、自社のユースケースが「定型処理の大量化」「精度の安定性重視」「低レイテンシ要件」のいずれかに該当するか確認することをお勧めします。該当する場合、タスク特化AIは高い投資対効果を発揮します。生成AIを適用する前に「タスク特化AIで解けないか」を問う習慣が、アーキテクチャの品質向上につながります。

また、タスク特化AIはコンプライアンス要件への対応にも強みを持ちます。PII（個人識別情報）の自動検出・マスク（Comprehend）や不適切コンテンツの自動フィルタリング（Rekognition）は、GDPR対応や利用規約の遵守を自動化する上で有効です。生成AIにはない「決定論的なルール適用」としてのAI利用が、規制産業（金融・医療・法務）での採用を後押ししています。

4サービスはいずれも、同期APIと非同期APIの2モードを提供しています。小規模・即時応答が必要な処理は同期APIで、大量処理・バッチ処理は非同期APIでジョブ管理するパターンが基本です（§6で詳解）。このアーキテクチャの共通性により、4サービスを組み合わせた複合パイプラインも設計しやすくなっています。

AWSの責任共有モデルの観点でも、タスク特化AIはAWS側がモデルのセキュリティとコンプライアンスを管理するため、ユーザーはデータの取り扱いと入出力のセキュリティに集中できます。

生成AI(基盤モデル)はこちら（Amazon Bedrock本番運用 Vol1）

生成AIアプリ本番運用 LLMOps統合編 Vol1 — 評価・可観測性・コスト統制

AWS Bedrock AgentCore本番運用 Vol1 — AIエージェント基盤の設計

2. Amazon Textract — ドキュメント/帳票からの構造抽出

2.1 Textractの概要と2つの処理経路

Amazon Textractは、スキャンした文書やPDF・画像ファイルからテキスト・表・フォーム・指定項目を自動抽出するマネージドサービスです。OCR技術に加えて文書の構造(テーブル・キーバリュー・レイアウト)を理解する機能を備えており、請求書・発注書・医療フォーム・保険申請書など業務で頻繁に登場する帳票の処理に特に適しています。サーバーのプロビジョニングやモデルの学習は不要で、APIを呼び出すだけで即座に利用できます。

Textractの処理経路は同期と非同期の2種類があります。

同期APIはAnalyzeDocumentとDetectDocumentTextで、1ページ文書や小規模処理に適しています。APIを呼び出すと即座にレスポンスが返り、抽出結果をそのまま受け取れます。入力はS3のオブジェクトまたはBase64エンコードしたバイトデータで渡し、1リクエストで処理できるのは1ページのみです。

非同期APIはStartDocumentAnalysisでジョブを開始し、完了後にGetDocumentAnalysisResultで結果を取得します。マルチページPDFや大規模バッチ処理に対応しており、S3バケットに格納した文書を入力として指定します。完了通知はAmazon SNSトピックに送られ、SQSキューと組み合わせてイベント駆動型で受け取るパターンが定番です。

# 非同期処理の基本パターン
StartDocumentAnalysis(S3入力 + SNS通知設定)
 ↓ ジョブIDを受け取る
SNS→SQSに完了通知が届く
 ↓
GetDocumentAnalysisResult(JobId)で結果取得
 ↓ NextTokenを使ったページネーションで全結果を収集

2.2 FeatureTypesの使い分け — TABLES/FORMS/QUERIES/LAYOUT

AnalyzeDocumentの呼び出し時にFeatureTypesパラメータで取得する構造情報を指定します。指定した機能の分だけ処理コストと時間が増えるため、用途に応じて必要なものだけを指定するのが基本原則です。

TABLESは文書内の表をセル単位で抽出します。TABLE・CELL・MERGED_CELLブロックタイプで返却され、セルのRow/ColumnIndex・RowSpan/ColumnSpanから表の構造を再構築できます。財務諸表・明細書・在庫一覧など行列構造の情報を扱う場合に使います。

FORMSはキーと値のペアを抽出します。「顧客名: 山田太郎」「生年月日: 1985-04-01」のような帳票フィールドをKEY_VALUE_SETブロックとして返します。ただしFORMSはラベルの文字列を文書から読み取るため、帳票の種類によってラベル名が異なると抽出結果のキー名もばらつきます。

QUERIESは自然言語の質問を投げて特定項目を狙い撃ち抽出する機能です。FORMSのラベル依存の問題を解消する核心機能であり、帳票の種類やレイアウトが変わってもクエリを同じにすることで安定した抽出が可能です。最大15個のクエリを同時に指定できます。

LAYOUTは文書の構造要素(段落・タイトル・ヘッダ・フッタ・セクションヘッダ・箇条書きなど)を自動グルーピングします。最大10種類のLAYOUT_*ブロックタイプ(LAYOUT_TEXT・LAYOUT_TITLE・LAYOUT_TABLE・LAYOUT_FIGURE・LAYOUT_SECTION_HEADER・LAYOUT_KEY_VALUE・LAYOUT_LIST・LAYOUT_HEADER・LAYOUT_FOOTER・LAYOUT_PAGE_NUMBER)で返され、文書の読み順や階層構造の再現に活用します。契約書・技術仕様書・規程類など構造化された長文ドキュメントの処理で特に有効です。

2.3 Queries API — 帳票ラベルのゆらぎを解消する核心機能

業務帳票の処理でよく起きる問題が、帳票の種類・発行元・バージョンによってフィールドのラベル名が異なる点です。例えばある請求書は「請求金額」、別の請求書は「ご請求額」「合計金額」「Amount Due」と記載されています。FORMSでキーを取得する方法ではラベル名のゆらぎを後処理で吸収する必要があり、帳票フォーマットが増えるたびにメンテナンスコストが増大します。

Queries APIはこの問題を根本から解消します。意図に基づく質問を送ることで、ラベルの文字列に依存せず文書の文脈から対応する値を抽出します。異なるフォーマットの帳票群に同じクエリセットを適用でき、前処理・後処理の複雑さを大きく削減できます。

response = client.analyze_document(
 Document={'S3Object': {'Bucket': 'my-bucket', 'Name': 'invoice.pdf'}},
 FeatureTypes=['QUERIES'],
 QueriesConfig={
  'Queries': [
{'Text': 'What is the invoice number?', 'Alias': 'INVOICE_NUMBER'},
{'Text': 'What is the total amount?', 'Alias': 'TOTAL_AMOUNT'},
{'Text': 'What is the invoice date?', 'Alias': 'INVOICE_DATE'},
  ]
 }
)

返却されるQUERY_RESULTブロックにはText(抽出値)とConfidence(信頼度スコア)が含まれます。信頼度スコアを閾値判定に使い、低スコアのものを人手レビューに回す設計が本番では必須です。

Queries APIを使う際の設計ポイントは次のとおりです。

• 具体的なクエリ文を使うほど抽出精度が上がります。内容を明確に指定するほど精度が向上します。
• 最大15クエリの制限を超える場合は複数回のAPI呼び出しに分割します。
• QUERIESとFORMS/TABLESは同時指定可能です。用途が混在する場合は組み合わせて使います。
• 本番運用では信頼度70〜85%を人手レビュー領域として設定するケースが多いです。

2.4 Layoutブロックタイプと構造化文書処理

LAYOUTを使うと、文書を単純なテキスト行の集合としてではなく「意味のある構造」として扱えます。例えば契約書のPDFを処理する際、LAYOUT_SECTION_HEADERで条項のタイトルを識別し、その配下のLAYOUT_TEXTブロックを条項の本文として再構築する処理が可能になります。

LAYOUTの主なユースケースは以下のとおりです。

• 文書の読み順再現: 複数カラムレイアウトや段組みで、人が読む順序通りにテキストを再構築します。
• セクション境界の検出: LAYOUT_SECTION_HEADERを起点にセクション単位で内容を分割し、後段のNLP処理に渡します。
• ヘッダ・フッタの除外: LAYOUT_HEADER/LAYOUT_FOOTERを識別してページ番号や会社名などの繰り返し要素を本文から切り離します。
• 図表の位置管理: LAYOUT_FIGUREで図の位置を把握し、キャプションテキストと関連付けます。

LAYOUTはFeatureTypesにLAYOUTを追加するだけで有効になります。TABLES/QUERIESと同時指定も可能です。

2.5 同期・非同期の選択基準

Lambdaからリアルタイムに単ページ帳票を処理するケースでは同期APIが適しています。一方、夜間バッチで月次の請求書束(数百〜数千ページ)を処理するケースでは非同期APIと専用のジョブ管理キューを組み合わせます。

大規模バッチ処理のオーケストレーションはこちら（Step Functions 実践 Vol1）

2.6 信頼度スコアとAmazon A2Iによる精度設計

Textractが返すすべてのブロックにはConfidence(0〜100の浮動小数)が付与されます。このスコアを利用した3段階の精度設計が本番では標準的です。

• 高信頼度(閾値以上): 自動処理を続行します。目安は90〜95%以上で要件に合わせて調整します。
• 中信頼度(要確認ゾーン): Amazon Augmented AI(A2I)の人手レビューフローに送ります。A2IはTextractと統合されており、専用のhumanレビューループを設定することで低スコアの抽出結果を人間のレビュアーに回す仕組みをマネージドで構築できます。
• 低信頼度(閾値以下): 抽出失敗として扱い、再スキャンまたは手動入力の案内を返します。

A2Iを使うにはAnalyzeDocumentの呼び出し時にHumanLoopConfigを指定します。条件を満たしたブロックが自動でA2Iの審査キューに入り、レビュー完了後にアプリケーションへコールバックされます。高精度が求められる公共手続き・医療文書・金融審査などでは、このA2Iとの組み合わせが実質必須です。

閾値の設定は本番データのサンプルを使って統計的にキャリブレーションします。「Confidence < 70: 差し戻し」「70 ≤ Confidence < 90: A2Iレビュー」「90 ≤ Confidence: 自動承認」という3段階を出発点とし、実際の誤抽出率を測定しながら調整します。

# A2I連携: 信頼度スコアによる自動/人手振り分け
def process_textract_results(blocks):
 auto_approved, human_review, rejected = [], [], []
 for block in blocks:
  if block['BlockType'] == 'QUERY_RESULT':
confidence = block.get('Confidence', 0)
if confidence >= 90:
 auto_approved.append(block)
elif confidence >= 70:
 human_review.append(block)
else:
 rejected.append(block)
 return auto_approved, human_review, rejected

2.7 2025年更新と最新対応状況

Textractは2025年の更新で以下の機能改善が行われています。

上付き・下付きテキスト対応: 数式・化学式・注釈番号など上付き/下付きで記載された文字を正確に識別できるようになりました。これにより科学技術文書・医薬品添付文書の処理精度が向上しています。

回転テキスト対応: 文書内で回転した文字列(スタンプ・透かし・縦書き注記など)を検出・抽出できます。横書き前提だった従来の処理では拾えなかった情報が取得可能になりました。

低解像度(FAX品質)精度改善: 100〜150DPI程度のFAX由来スキャン文書でも抽出精度が改善されています。レガシーFAXワークフローを自動化する際の信頼性が高まりました。

これらの更新はいずれも既存のAPIパラメータを変更せず利用できます。ただし本番デプロイ前に最新のAWSドキュメントで対応ファイル形式・言語・DPI要件を確認することを推奨します。

2.8 Textractのコスト構造と最適化

TextractのAPIコストは処理方式と機能ごとに課金されます。主なコスト構造を理解しておくことで、費用対効果の高い設計が可能になります。

DetectDocumentText(テキストのみ抽出): 1ページあたり$0.0015(〜1,000ページ)。基本的なOCRのみが必要な場合に使います。

AnalyzeDocument(TABLES/FORMS): 1ページあたり$0.015。構造化情報の抽出が必要な場合です。テキスト検出の10倍のコストになるため、必要な機能のみを指定することが重要です。

Queries API: AnalyzeDocumentと組み合わせて使います。1ページあたり$0.035(最初の1Mページ)の追加コスト。ただし後処理のロジックコストを削減できるため、総コストでは有利になるケースが多いです。

コスト最適化のポイントは次のとおりです。

• 必要なFeatureTypesのみを指定します。TABLESもFORMSも不要な場合はDetectDocumentTextを選びます。
• 非同期APIを使うバッチ処理では夜間のオフピーク時間帯に処理を集中させることでコストメリットが出ます。
• 低信頼度で再処理が必要なドキュメントを減らすため、スキャン品質の改善(解像度・照明・傾き補正)への投資が長期的なコスト削減につながります。

3. Amazon Comprehend — テキストの言語分析

Amazon Comprehendは、AWSが提供するNLP(自然言語処理)マネージドサービスです。テキストを入力するだけで、エンティティ認識・感情分析・PII検出・キーフレーズ抽出・言語検出をAPIコール一本で実行できます。機械学習の専門知識がなくても学習済みモデルをそのまま本番投入できる点が最大の特徴です。

プリトレーンドAPI — エンティティ認識・感情分析・PII検出

エンティティ認識は、テキスト内の固有表現を自動検出します。検出カテゴリは PERSON(人名)・ORGANIZATION(組織)・LOCATION(場所)・DATE(日時)・QUANTITY(数量)・EVENT(イベント)・TITLE(作品名)など多岐にわたり、各エンティティには BeginOffset・EndOffset・Score(信頼度0〜1)が付与されます。

import boto3

comprehend = boto3.client('comprehend', region_name='us-east-1')

response = comprehend.detect_entities(
 Text='Amazon Web Services will hold re:Invent in Las Vegas in December 2024.',
 LanguageCode='en'
)

for entity in response['Entities']:
 print(f"{entity['Type']}: {entity['Text']} (Score: {entity['Score']:.2f})")
# ORGANIZATION: Amazon Web Services (0.99)
# EVENT: re:Invent (0.87)
# LOCATION: Las Vegas (0.99)
# DATE: December 2024 (0.98)

大量テキストを処理する場合は BatchDetectEntities でまとめて送信するとAPIコール数を削減できます。1リクエストあたり最大25件のテキストをバッチ処理できます。

感情分析では、テキスト全体の感情を POSITIVE・NEGATIVE・NEUTRAL・MIXED の4値で分類し、各ラベルに確率スコアを付与します。コンタクトセンターの問い合わせメール・SNS投稿の傾向把握・製品レビューの自動仕分けなどに活用されます。

response = comprehend.detect_sentiment(
 Text='このサービスは本当に使いやすくて助かっています。',
 LanguageCode='ja'
)
print(response['Sentiment'])  # POSITIVE
print(response['SentimentScore'])
# {'Positive': 0.97, 'Negative': 0.01, 'Neutral': 0.01, 'Mixed': 0.01}

MIXED は「良い点もあるが悪い点もある」という複合感情を示します。NPS調査やカスタマーフィードバック分析でよく現れるパターンです。

PII(個人情報)検出は、テキスト内のメールアドレス・電話番号・住所・クレジットカード番号・社会保障番号などを自動検出し、マスク処理や編集に活用します。主要なAPIは以下の2種類です。

• DetectPiiEntities — テキスト内のPIIエンティティとその位置(offset)を返す。後処理でマスク/編集が可能
• ContainsPiiEntities — テキストにPIIが含まれるかをブール値で高速判定。フィルタリング用途に最適

# PIIエンティティの検出とマスク処理例
response = comprehend.detect_pii_entities(
 Text='My email is john.doe@example.com and phone is 555-0123.',
 LanguageCode='en'
)

text = 'My email is john.doe@example.com and phone is 555-0123.'
masked = text
for entity in sorted(response['Entities'], key=lambda x: x['BeginOffset'], reverse=True):
 masked = masked[:entity['BeginOffset']] + '[REDACTED]' + masked[entity['EndOffset']:]

print(masked)
# My email is [REDACTED] and phone is [REDACTED].

リアルタイムPII APIを使うと、ストリーミングデータをリアルタイムで処理しながらPIIを検出・編集できます。コンタクトセンターのライブチャットやログ収集パイプラインでの活用が典型例です。

重要な言語制約: PII検出の完全なサポート対象は英語とスペイン語に限定されます。日本語を含む他言語はエンティティ認識・感情分析などコア機能のみ部分的にサポートしています。日本語のPII処理が必要な場合は、Bedrockのプロンプトベース抽出やカスタムエンティティ認識との組み合わせを検討してください。

カスタム分類(Custom Classifier) — AutoMLで独自ラベルを学習

Custom Classificationを使うと、ユーザー独自のラベルでテキストを分類するMLモデルをML知識なしで構築できます。問い合わせカテゴリの自動分類・社内文書の振り分け・サポートチケットの優先度判定などが典型的なユースケースです。

学習から推論までのステップ:

1. 学習データの準備 — テキストとラベルのペアをCSV形式で用意する。ラベルごとに最低100件、推奨500件以上
2. 分類器の作成 — CreateDocumentClassifier でS3の学習データパスを指定してAutoML学習を開始
3. 精度評価 — TrainingMetrics(正確度/F1スコア/混同行列)を確認し、閾値設計に活用
4. エンドポイントの起動 — CreateEndpoint でリアルタイム推論エンドポイントを作成
5. 推論の実行 — ClassifyDocument でテキストを分類(ラベルと信頼度スコアを返却)

# カスタム分類器によるリアルタイム推論
endpoint_arn = 'arn:aws:comprehend:us-east-1:123456789012:document-classifier-endpoint/support-ticket-classifier'

response = comprehend.classify_document(
 Text='返品手続きの方法を教えてください。商品到着後7日が経過しましたが可能でしょうか。',
 EndpointArn=endpoint_arn
)

for cls in response['Classes']:
 print(f"{cls['Name']}: {cls['Score']:.3f}")
# RETURN_REQUEST: 0.952
# PRODUCT_INQUIRY: 0.031
# SHIPPING_ISSUE: 0.017

カスタム分類器は PDF・Word・プレーンテキストを直接入力として受け付けるため、前処理コストを削減できます。また、Multi-label分類モード(1テキストに複数ラベルを同時付与)も選択可能です。例えば「返品依頼かつ緊急対応」のように複数属性を持つ問い合わせの分類に適しています。

大量の文書を定期バッチで処理する場合は、StartDocumentClassificationJob を使った非同期バッチジョブが経済的です。S3入力・S3出力・SNS完了通知のパターンで大規模処理に対応できます。

カスタムエンティティ認識 — 専門用語・固有名詞の自動検出

Custom Entity Recognitionは、標準APIでは検出できない業界固有の用語(製品コード・社内部門名・薬品名など)を独自エンティティとして認識させるAutoML機能です。

学習データの提供方法は2種類あります:

• 注釈付きデータ方式 — テキスト内のエンティティ位置をオフセットで明示したアノテーションCSVとテキストファイルを提供する方式。精度が高く、複雑なエンティティに向く
• エンティティリスト方式 — 認識させたい用語リストのCSVのみを提供する方式。準備が簡単だが精度はやや落ちる。固定的な製品コードや部品番号の検出に適している

# カスタムエンティティ認識の推論(推論エンドポイント経由)
recognizer_endpoint_arn = 'arn:aws:comprehend:us-east-1:123456789012:entity-recognizer-endpoint/pharma-recognizer'

response = comprehend.detect_entities(
 Text='患者AにメトホルミンXL500mgを投与。次回はグリメピリド2mgへ変更予定。',
 EndpointArn=recognizer_endpoint_arn
)

for entity in response['Entities']:
 print(f"Type: {entity['Type']}, Text: {entity['Text']}, Score: {entity['Score']:.2f}")
# Type: DRUG_NAME, Text: メトホルミンXL500mg, Score: 0.91
# Type: DRUG_NAME, Text: グリメピリド2mg, Score: 0.89

PDF・Word形式のドキュメントも直接入力として受け付けられるため、医療記録・法律文書・技術仕様書などの大量処理パイプラインに組み込めます。

IDP(インテリジェント文書処理) — 分類と抽出の一気通貫

IDP(Intelligent Document Processing)では、ComprehendとTextractを連携させることで、文書の分類から情報抽出までを自動化できます。

IDPの代表的なフロー:

1. 大量の帳票・契約書・申請書がS3バケットに到着
2. Textractがレイアウトとテキスト・表・フォームフィールドを抽出
3. Comprehendのカスタム分類器が文書種別(請求書/注文書/契約書など)を自動判定
4. 判定カテゴリに応じた専用カスタムエンティティ認識モデルが対象フィールドを抽出
5. 抽出結果をDynamoDBや業務システムへ自動登録し、低信頼度分は人手レビュー(Amazon A2I)へ転送

このフローをStep Functionsでオーケストレーションすることで、文書種別が混在する大量バッチ処理を完全自動化できます。ルールベースのパーサーと異なり、レイアウト変更に強い柔軟性があります。

Step Functionsによるパイプライン設計はこちら（AWS Step Functions 実践 Vol1）

★ 重要: 新規顧客への提供停止機能(2026年4月30日以降)

以下の3機能は2026年4月30日以降、新規顧客への提供が停止されています。新規システム設計ではこれらの機能の採用を避けてください。

既存利用者は引き続き使用できますが、新規採用・拡張時には代替設計への移行を計画してください。コアの感情分析・PII検出・カスタム分類・カスタムエンティティ認識はGA(一般提供)を継続しており、新規設計でも問題なく使用できます。

対応言語と本番適用時の注意点

Comprehendの言語サポートは機能によって異なります。本番投入前に必ず確認してください。

日本語の感情分析とエンティティ認識は利用できますが、英語・スペイン語と比較して精度面で劣るケースがあります。日本語コンテンツへの本番適用前には必ずパイロットテストで精度を検証してください。PII検出は日本語非対応のため、日本語の個人情報(氏名・住所・電話番号など)の検出にはカスタムエンティティ認識またはBedrockプロンプトとの組み合わせが必要です。

4. Amazon Rekognition — 画像/動画の認識

Amazon Rekognition は、画像と動画を対象とした AWS のマネージド画像認識サービスです。学習済みの深層学習モデルを API 経由で呼び出すだけで、ラベル検出・顔分析・コンテンツモデレーションといった高精度な認識処理を行えます。独自のユースケースには Custom Labels によるカスタムモデル学習も利用できます。

ラベル検出 — DetectLabels と信頼度スコア

ラベル検出は、画像や動画のフレームに含まれる物体・シーン・アクティビティを自動で識別する機能です。AWS が事前学習したモデルを使うため、追加の機械学習作業なしで幅広いカテゴリに対応しています。

DetectLabels API は画像を対象とした同期 API で、S3 の画像オブジェクトまたは画像のバイト列を入力として受け付けます。レスポンスには検出されたラベルの一覧と各ラベルの信頼度スコア(0〜100 のパーセント値)が含まれます。

import boto3

client = boto3.client('rekognition', region_name='ap-northeast-1')

response = client.detect_labels(
 Image={'S3Object': {'Bucket': 'my-images', 'Name': 'photo.jpg'}},
 MaxLabels=10,
 MinConfidence=75.0
)

for label in response['Labels']:
 print(f"{label['Name']}: {label['Confidence']:.1f}%")

MaxLabels で返却ラベル数の上限を、MinConfidence で信頼度の最低閾値を設定できます。本番環境では MinConfidence を適切に設定し、誤検知率と検知漏れのトレードオフを調整します。一般的には 70〜80% を目安として運用し、用途に応じてチューニングします。

ラベルには親カテゴリの情報も含まれます。たとえば「Cat」が検出された場合、親ラベルとして「Pet」「Animal」が付随します。この階層構造を活用することで、粒度の異なるフィルタリングが可能になります。

検出可能なカテゴリは多岐にわたります。屋外シーン(森林・海岸・山岳)、室内環境(キッチン・オフィス・スポーツ施設)、乗り物(自動車・飛行機・自転車)、動物、食べ物、人物の動作(スポーツ・作業)など、数千種類のラベルが利用可能です。

顔分析 — 属性推定とプライバシー設計

顔分析機能は、画像や動画フレームに含まれる顔を検出し、その顔が持つ属性情報を推定します。重要な前提として、この「顔分析」は属性推定であり、個人を特定する「顔認識(Face Recognition)」とは異なります。

DetectFaces API が返す顔属性には以下が含まれます。

• 年齢層推定: Low と High で幅を持たせた推定値(例: 20〜30歳)
• 感情推定: HAPPY / SAD / ANGRY / CONFUSED / DISGUSTED / SURPRISED / CALM / FEAR の 8 種別と信頼度
• マスク着用: FaceOccluded で顔の遮蔽状態を推定
• サングラス・目の開閉・笑顔の有無: 各属性に真偽値と信頼度
• 顔の向き: Pose(Yaw / Pitch / Roll)で頭部の傾きを角度で返却
• 顔の品質: Brightness(明度)と Sharpness(鮮明度)でスコア化

これらは 統計的推定値 であり、絶対的な正確性を持つものではありません。特に感情推定・年齢層推定は、照明条件・撮影角度・文化的背景によって精度が変動します。

プライバシー配慮と法規制への対応

顔分析・顔認識技術の利用においては、プライバシーへの配慮と関連法規制の確認が不可欠です。

個人を特定する顔認識機能(Face Collection を使った照合)は、特に米国の複数の州で厳格な規制が設けられています。代表的なものとして BIPA(Biometric Information Privacy Act) があります。イリノイ州の BIPA は、生体情報(顔認識データを含む)を収集・使用・開示する事業者に対し、本人の書面による同意の取得・プライバシーポリシーの公表・適切な保持期間の設定などを義務付けています。違反した場合は 1 件あたり 1,000〜5,000 ドルの罰則が適用されます。

EU の GDPR でも生体データは「特別カテゴリの個人データ」として厳格な取り扱いが求められます。日本の 個人情報保護法 においても、顔認識データは個人識別符号に該当します。

DetectFaces による属性推定は、個人を特定するデータを生成するものではありません。 しかし、実装の目的・用途・データの扱い方によっては規制の対象となる可能性があります。顔認識機能(CompareFaces / SearchFacesByImage / Face Collection)を利用する場合は、適用される法規制を事前に法務担当者と確認し、必要な同意プロセスを整備してください。

AWS は顔認識機能の責任ある利用についてガイドラインを公表しており、利用規約によって有害な目的への利用を禁止しています。設計段階から「この機能が本当に必要か」「属性推定で代替できないか」を検討することが重要です。

コンテンツモデレーション — 3 階層タクソノミーとスコアリング

コンテンツモデレーション機能は、画像・動画に含まれる不適切なコンテンツを自動検出します。UGC(ユーザー投稿コンテンツ)を扱うプラットフォームや、メディア配信サービスの審査業務で広く活用されています。

DetectModerationLabels API が返すラベルは、3 階層のタクソノミーで構造化されています。

• L1(大分類): Explicit Nudity / Violence / Hate Symbols / Drugs & Tobacco / Alcohol / Gambling / Rude Gestures / Visually Disturbing
• L2(中分類): L1 の下位カテゴリ(例: Graphic Violence / Weapon Violence)
• L3(小分類): より細粒度の分類(例: Nazi Party / Supremacist)

response = client.detect_moderation_labels(
 Image={'S3Object': {'Bucket': 'media-bucket', 'Name': 'image.jpg'}},
 MinConfidence=50.0
)

for label in response['ModerationLabels']:
 print(f"{label['Name']} (Parent: {label['ParentName']}): {label['Confidence']:.1f}%")

信頼度の閾値設定は運用上の重要な設計ポイントです。本番の審査フローでよく使われるアプローチは、信頼度スコアに応じた 3 段階判定 です。

• 高信頼度(例: 90% 以上): 自動ブロック
• 中間帯(例: 50〜90%): 人手レビューキューへ転送
• 低信頼度(50% 未満): 通過

この中間帯の人手レビューを効率化するには Amazon A2I(Augmented AI) との組み合わせが定番です。Rekognition がモデレーションラベルを検出すると A2I ワークフローが起動し、レビュータスクを自動生成します。レビュアーはポータル上でコンテンツを確認・判定し、結果が S3 に出力されます。

カスタムモデレーションアダプタ を使うと、プリトレーンドのモデレーションモデルを特定ドメインに特化させることもできます。自社基準の不適切コンテンツ(業界固有の表現・ブランドルール違反等)を少量のラベル付き画像から差分学習し、判定精度を向上させます。

Custom Labels — 独自の物体・シーン認識

プリトレーンドのラベル検出では対応できない独自カテゴリ(自社製品の型番・ロゴ・製造ラインの部品・医療画像など)には、Custom Labels を利用します。

Custom Labels は AutoML ベースのカスタムモデル学習機能です。独自の画像データとラベルを用意するだけで、機械学習の専門知識なしにカスタムモデルを構築できます。

学習の流れ:

1. S3 バケットにラベル付き画像をアップロード
2. Rekognition コンソールまたは API でデータセットを作成し、バウンディングボックスまたは画像レベルのラベルを付与
3. トレーニングジョブを開始(最低 10 枚/クラス、推奨 50 枚以上/クラス)
4. 評価指標(適合率・再現率・F1スコア)でモデルを評価
5. 推論ユニット(Inference Unit)数を指定してモデルを起動し、本番利用開始

コスト面の重要ポイント: Custom Labels の学習は 月あたり 2 時間まで無料枠 が設けられています(2025年時点)。推論時は起動中の推論ユニット単位で時間課金が発生するため、使用しない時間帯はモデルを停止する運用が必須です。

# モデルの起動
client.start_project_version(
 ProjectVersionArn='arn:aws:rekognition:ap-northeast-1:123456789:project/my-project/version/v1/1234',
 MinInferenceUnits=1
)

# カスタムラベル検出
response = client.detect_custom_labels(
 ProjectVersionArn='arn:aws:rekognition:ap-northeast-1:123456789:project/my-project/version/v1/1234',
 Image={'S3Object': {'Bucket': 'my-bucket', 'Name': 'product.jpg'}},
 MinConfidence=70.0
)

# 推論コスト削減のため未使用時は必ず停止
client.stop_project_version(
 ProjectVersionArn='arn:aws:rekognition:ap-northeast-1:123456789:project/my-project/version/v1/1234'
)

動画分析 — 非同期 Video API

Rekognition の動画分析は画像の同期 API と異なり、非同期の Video API を使います。動画ファイルを S3 にアップロードし、解析ジョブを投入して SNS 経由で完了通知を受け取るパターンです。

動画向け主要 API 一覧:

非同期ジョブの処理フローは「投入 → SNS 通知受信 → 結果取得」の 3 ステップです。

# Step 1: ジョブ投入
response = client.start_label_detection(
 Video={'S3Object': {'Bucket': 'video-bucket', 'Name': 'footage.mp4'}},
 NotificationChannel={
  'SNSTopicArn': 'arn:aws:sns:ap-northeast-1:123456789:rekognition-complete',
  'RoleArn': 'arn:aws:iam::123456789:role/RekognitionSNSRole'
 },
 MinConfidence=70.0
)
job_id = response['JobId']

# Step 2: SNS 通知を受信した Lambda 関数内で結果取得
result = client.get_label_detection(
 JobId=job_id,
 SortBy='TIMESTAMP'
)
for item in result['Labels']:
 print(f"{item['Timestamp']}ms: {item['Label']['Name']}")

動画分析の結果にはフレームのタイムスタンプ(ミリ秒)が付与されます。「動画の何秒地点で何が映っているか」を特定でき、シーン検索やハイライト生成などの応用が可能です。

長い動画では結果が複数ページに分割されます。NextToken が返却される限りループして全件取得する実装が必要です。

all_labels = []
response = client.get_label_detection(JobId=job_id)
while True:
 all_labels.extend(response['Labels'])
 if 'NextToken' not in response:
  break
 response = client.get_label_detection(
  JobId=job_id,
  NextToken=response['NextToken']
 )

画像(同期)と動画(非同期)の使い分け

Rekognition の API 選択は、入力メディアの種類と処理要件によって明確に分かれます。

リアルタイム性が求められる用途(EC サイトの商品画像審査・ライブ配信の静止フレーム判定など)では同期 API を選択します。録画映像の分析・動画アーカイブの一括処理・長尺動画のシーン検索では非同期 Video API を選択します。

なお、ライブストリーミング映像のリアルタイム解析には Rekognition Streaming Video Events という別製品があります。Kinesis Video Streams と連携して、ライブ映像からの継続的な検出に対応しています。

Rekognition を本番システムに組み込む際は、ラベル検出・顔分析・モデレーション・カスタムラベル・動画分析のうち必要な機能を選定し、同期 API と非同期 API を組み合わせたパイプライン構成を設計することが重要です。統合設計の詳細は §6 で扱います。

5. Amazon Transcribe — 音声からテキストへの変換

Amazon Transcribeは、音声データを自動的にテキストへ変換するAWSのマネージドASR（自動音声認識）サービスです。事前学習済みの深層学習モデルを活用し、個別にモデルを学習させることなくAPIコールだけで高精度な音声認識を実現します。コンタクトセンターの通話録音・会議の議事録自動生成・医療記録の口述入力など、大量の音声データを扱う業務に広く採用されています。

転写方式はリアルタイムストリーミングと非同期バッチの2種類があり、ユースケースに応じて使い分けます。精度向上のためにカスタム語彙・カスタム言語モデル・語彙フィルタを組み合わせ、業界固有の専門用語や固有名詞の認識精度を高めることができます。コンタクトセンター向けにはCall Analyticsが提供されており、感情分析・話者分離・通話要約などの高度な分析機能を備えています。

5.1 リアルタイムストリーミング転写

リアルタイムストリーミングは、ライブ音声やマイク入力をリアルタイムでテキストに変換する方式です。低レイテンシが求められるライブ字幕システム・音声操作UI・コールセンターのリアルタイムモニタリングに適しています。

HTTP/2ストリーミングはイベントストリームを使用した双方向プロトコルです。StartStreamTranscription APIで接続を確立し、音声チャンクをイベントとして送信しながら部分的な転写結果（Partial results）と確定転写結果（Final results）をリアルタイムに受信します。Partial resultsはUIへの即時表示に活用し、Final resultsを後続処理に渡します。

WebSocketストリーミングはブラウザアプリケーションや既存のWebSocket基盤との親和性が高い選択肢です。署名付きURLでWebSocket接続を確立し、バイナリメッセージとして音声データを送信します。ブラウザベースのコールセンターアプリケーションや会議システムでよく採用されるパターンです。

リアルタイム転写では部分結果と確定結果の2段階で転写が返ってきます。部分結果は随時更新されますが確定ではありません。確定結果（IsPartial: false）を受信した時点で後続処理（Comprehend分析・DBへの書き込みなど）を実行します。

チャンクサイズと送信頻度のバランスも重要です。一般的に100〜200msのチャンクサイズで安定した低レイテンシ転写を実現できます。ネットワーク障害に備えて指数バックオフ付きの再接続ロジックを実装することが本番運用の前提です。

5.2 非同期バッチ転写

録音済みの大量音声ファイルや長時間録音を処理する場合は非同期バッチ転写を使用します。同期APIのようなTPS（1秒あたりトランザクション数）制限の影響を受けにくく、大量処理に適しています。

StartTranscriptionJobで転写ジョブを開始します。入力音声ファイルはS3に配置し、ジョブ設定でS3 URIを指定します。出力先もS3バケットとして設定します。対応フォーマットはMP3・MP4・WAV・FLAC・OGGなど主要な音声・動画形式です。

import boto3

client = boto3.client('transcribe', region_name='ap-northeast-1')

response = client.start_transcription_job(
 TranscriptionJobName='call-recording-20250601',
 Media={'MediaFileUri': 's3://my-audio-bucket/recordings/call-001.mp3'},
 MediaFormat='mp3',
 LanguageCode='ja-JP',
 OutputBucketName='my-transcript-bucket',
 OutputKey='results/call-001.json',
 Settings={
  'ShowSpeakerLabels': True,
  'MaxSpeakerLabels': 2,
  'VocabularyName': 'my-custom-vocab'
 }
)

ジョブの状態確認はGetTranscriptionJobで行います。TranscriptionJobStatusがCOMPLETEDになると転写結果がS3に保存されます。FAILEDの場合はFailureReasonフィールドで原因を確認します。

def poll_job(client, job_name):
 import time
 for _ in range(60):
  resp = client.get_transcription_job(TranscriptionJobName=job_name)
  status = resp['TranscriptionJob']['TranscriptionJobStatus']
  if status in ('COMPLETED', 'FAILED'):
return resp['TranscriptionJob']
  time.sleep(15)
 raise TimeoutError('Transcription job timed out')

大量処理では「S3に音声ファイル配置 → S3イベントがLambdaをトリガー → LambdaがStartTranscriptionJobを呼び出し → EventBridgeで完了通知 → 後続LambdaがGetTranscriptionJobで結果取得 → 結果をS3/DynamoDBに保存」という自動パイプラインが定番設計です。

5.3 カスタム語彙（Custom Vocabulary）

業界固有の専門用語・固有名詞・製品名などをTranscribeに事前登録し、認識精度を向上させる機能です。デフォルトの言語モデルが学習していない語彙の誤認識を大幅に削減できます。

CSV形式またはプレーンテキストで語彙リストを作成し、CreateVocabulary APIで登録します。主要なフィールドは以下の通りです。

• Phrase — 認識させたい単語・フレーズ（必須）
• SoundsLike — 発音のヒント（英語向け。カタカナ英語の発音指定に活用）
• IPA — 国際音声記号による精密な発音指定
• DisplayAs — 転写テキストへの出力形式（例: 「えーびーしー」→「ABC」）

「Amazon SageMaker」「虚血性心疾患」「クロスオリジンリソース共有」のような固有名詞・専門用語・略語を登録することで誤認識を大幅に削減できます。語彙は複数作成でき、ジョブ実行時にVocabularyNameで指定します。更新はUpdateVocabularyで既存語彙を上書きします。リアルタイムストリーミングでも同様に語彙を指定できます。

5.4 語彙フィルタ（Vocabulary Filter）

転写テキスト内の不適切な語句を除去・マスクする機能です。コンタクトセンターの通話録音における不適切発言フィルタリングや、個人情報の一次マスク処理に活用されます。

フィルタには3つの動作モードがあります。

• REMOVE — 対象語句を転写テキストから完全に削除します
• MASK — 対象語句を***でマスクします（削除箇所の存在を示しつつ内容を隠す）
• TAG — 語句をそのまま残しつつvocabularyFilterMatch: trueフラグを付与します。後続処理で判定させたい場合に適しています

client.create_vocabulary_filter(
 VocabularyFilterName='profanity-ja',
 LanguageCode='ja-JP',
 Words=['不適切語1', '不適切語2']
)

ジョブまたはストリーミングセッションでVocabularyFilterNameとVocabularyFilterMethod（REMOVE/MASK/TAG）を指定して適用します。語彙フィルタはカスタム語彙と同時使用可能です。

5.5 カスタム言語モデル（Custom Language Model）

ドメイン特化の言語確率モデルを学習させ、専門領域の音声認識精度を向上させる機能です。カスタム語彙が個々の単語・フレーズを追加するのに対し、カスタム言語モデルはドメイン全体の言語的文脈と語彙分布を学習します。

学習にはドメインのプレーンテキストデータ（最大2GB・UTF-8形式）が必要です。医療記録・法律文書・技術マニュアルなど対象ドメインのテキストを用意し、CreateLanguageModel APIで学習を開始します。学習時間はデータ量に応じて数時間かかります。完了後はDescribeLanguageModelで状態（IN_PROGRESS/COMPLETED/FAILED）を確認します。

カスタム語彙との使い分けとして、カスタム語彙は数十〜数百件の固有名詞や専門用語の追加に適しており、カスタム言語モデルは大量のドメインテキストから言語パターン全体を学習させる大規模な精度向上に向いています。最大の精度改善が必要な場合は両方を組み合わせます。

5.6 Call Analytics — コンタクトセンター向け特化機能

Call Analyticsは、コンタクトセンターの通話分析に特化した機能セットです。通常の転写に加えて、コンタクトセンター運用に必要な多様な分析データを一括取得できます。

動作モードは2種類あります。リアルタイムモードではライブ通話をストリーミング転写しながら感情スコアなどの分析結果をリアルタイムで取得します。オペレーターのダッシュボードに顧客感情状態を表示し、エスカレーション判断や品質管理に活用します。StartCallAnalyticsStreamTranscription APIを使用します。

ポストコール（非同期）モードでは録音済み通話ファイルをStartCallAnalyticsJobで処理し、通話全体を詳細に分析します。分析結果のJSONは指定のS3バケットに保存されます。

主要な分析機能は以下の通りです。

感情スコア（Sentiment）はAGENT・CUSTOMER双方の発話セグメントごとにPOSITIVE/NEGATIVE/NEUTRAL/MIXEDを数値スコアで算出します。通話全体の感情推移をトレンドグラフ化することで顧客満足度の定量評価が可能です。

発話速度（Talk Speed）は話者ごとの1分あたり単語数を計測します。対応が急ぎすぎ・ゆっくりすぎのオペレーターへのフィードバック指標として活用されます。

話者分離（Speaker Diarization）はAGENTとCUSTOMERの2チャネルを識別し、それぞれの発話を別々に転写します。ステレオ録音（各チャネルに話者を割り当て）と組み合わせることで確実な話者分離が実現できます。

通話要約（Call Summarization）は通話の重要事項・アクションアイテムを自動生成します。後処理での通話記録作成を大幅に効率化します。

沈黙検出（Non-Talk Time）は保留時間や応答待ちパターンの分析に活用されます。割り込み検出（Interruptions）は顧客とオペレーターのやり取りの質を評価する指標となります。

Amazon Connectとの統合ではContact Lens機能経由でCall Analyticsを利用するケースが多く、Contact Flowやリアルタイムダッシュボードとの統合が設定不要で実現できます。Connect連携の詳細設定手順は以下の記事を参照してください。

5.7 Amazon Transcribe Medical

医療分野に特化した音声認識モデルです。一般モデルとは異なる医療用語特化の言語モデルが搭載されており、診療録・処方箋・患者報告など臨床現場の音声を高精度でテキスト化します。電子カルテ（EHR）への口述入力自動化を主な用途として設計されています。

主な特徴として、薬品名・診断名・解剖学的用語などの医療専門用語を高精度で認識します。Specialtyパラメータで診療科（PRIMARYCARE/CARDIOLOGY/NEUROLOGY/ONCOLOGY/RADIOLOGY/UROLOGY）を指定でき、会話形式（CONVERSATION）と口述形式（DICTATION）の2タイプをサポートします。一般TranscribeとはAPIエンドポイントが別（StartMedicalTranscriptionJob / StartMedicalStreamTranscription）です。

response = client.start_medical_transcription_job(
 MedicalTranscriptionJobName='ehr-dictation-001',
 Media={'MediaFileUri': 's3://medical-audio/dictation.mp3'},
 MediaFormat='mp3',
 LanguageCode='en-US',
 OutputBucketName='medical-transcripts',
 Specialty='CARDIOLOGY',
 Type='DICTATION'
)

医療環境での使用ではHIPAA対応のためS3バケットの暗号化・VPCエンドポイント経由のAPI呼び出し・CloudTrail監査ログの有効化が求められます。現時点（2025年）では英語（en-US）のみのサポートです。

5.8 話者分離とチャネル識別

話者分離（Speaker Diarization）は複数話者が参加する会議・対話音声で誰がいつ発言したかを識別する機能です。ShowSpeakerLabels: trueとMaxSpeakerLabels（最大10）を設定すると、転写結果にspk_0・spk_1などの話者ラベルが付与されます。

チャネル識別（Channel Identification）はステレオ音声の左右チャネルを個別の話者として転写します。コンタクトセンターではオペレーターとカスタマーを専用チャネルに録音しChannelIdentification: trueを設定することで確実な話者分離が実現できます。

話者分離とチャネル識別は同時使用不可です。コンタクトセンターではCall Analytics（チャネルベース）を、会議転写などその他の用途では話者分離を使う設計が基本です。

5.9 対応言語とリージョン可用性

日本語（ja-JP）はGenerally Available（GA）対応であり、リアルタイムストリーミングと非同期バッチの両方で利用できます。主な対応言語は英語（各国バリエーション）・日本語・中国語・スペイン語・フランス語・ドイツ語・ポルトガル語・イタリア語・韓国語など30言語以上です。各言語のStreaming/Batch対応状況はAWSドキュメントの公式リストを確認してください。リリースサイクルは速いため、最新状況の変動にご注意ください。

リージョン可用性の注意点として、Call AnalyticsとTranscribe Medicalは対応リージョンが限定されています。ap-northeast-1（東京）ではコアのStreaming・Batchはサポートされていますが、特殊機能については最新のリージョン別サービス提供状況ページを確認してください。

5.10 ComprehendとのハイブリッドPipeline

TranscribeとAmazon Comprehendを組み合わせることで、音声データから高度なインサイトを抽出するパイプラインを構築できます。これは§7で詳述するコンタクトセンター統合パターンの中核となる組み合わせです。

基本的なパイプライン設計は以下の通りです。

1. 音声入力 — コンタクトセンター通話録音・会議音声・顧客インタビューなど
2. Transcribeで転写 — リアルタイムまたは非同期によるテキスト化（Call Analytics経由で感情/要約も同時取得）
3. テキストをComprehendへ渡す — 転写テキストをComprehend APIの入力として利用
4. Comprehendで分析 — エンティティ認識・感情分析・PII検出・カスタム分類を適用

import json
import boto3

def analyze_transcript_result(bucket, key):
 s3 = boto3.client('s3')
 comprehend = boto3.client('comprehend', region_name='ap-northeast-1')

 obj = s3.get_object(Bucket=bucket, Key=key)
 data = json.loads(obj['Body'].read().decode('utf-8'))
 text = data['results']['transcripts'][0]['transcript']

 entities = comprehend.detect_entities(Text=text[:5000], LanguageCode='ja')
 sentiment = comprehend.detect_sentiment(Text=text[:5000], LanguageCode='ja')

 return {
  'entities': entities['Entities'],
  'sentiment': sentiment['Sentiment'],
  'scores': sentiment['SentimentScore']
 }

Call Analyticsの音声ベース感情スコアとComprehendのテキストベース感情分析を照合することで、声のトーン（音声的感情）と言語内容（テキスト的感情）の乖離を検出する高度な分析も実装できます。このパターンにより音声単体やテキスト単体では得られない複合的なカスタマーインサイトを取得できます。

6. 統合・運用・コスト設計

4サービスを個別に利用するだけでなく、本番システムとして動かすには統合・運用・コスト設計が鍵になります。大量処理をどのジョブ管理パターンで捌くか、精度をどう担保するか、コストをどう最小化するか——これらを設計段階から組み込んでおくことで、本番稼働後の問題を大幅に減らせます。

非同期ジョブ管理パターン

Textract・Rekognition・Transcribeの大量処理は、すべて同一の非同期パターンで管理できます。処理のスタート（StartXxx）、完了通知受信（SNS/SQS）、結果取得（GetXxx）の3ステップです。

StartXxx — 非同期ジョブの開始

各サービスの非同期APIは次の命名規則で統一されています。

• Textract: StartDocumentAnalysis / StartDocumentTextDetection
• Rekognition: StartLabelDetection / StartFaceDetection / StartContentModeration
• Transcribe: StartTranscriptionJob

各APIはS3上のファイルパスを受け取り、JobId（またはTranscriptionJobName）を返します。同期APIと異なり、処理完了を待たずにすぐ返却されます。

SNS/SQSによる完了通知

非同期ジョブが完了すると、指定したSNSトピックにコールバック通知が届きます。SNSトピックにSQSキューをサブスクライブしておけば、Lambdaが確実に結果を受信できます。

完了通知にはJobIdとステータス（SUCCEEDED/FAILED）が含まれます。FAILEDの場合はStatusMessageにエラー詳細が入ります。

GetXxx — 結果の取得

完了通知受信後、JobIdを使って結果を取得します。

• Textract: GetDocumentAnalysis(JobId=...) — NextTokenでページネーション
• Rekognition: GetLabelDetection(JobId=...) — NextTokenでページネーション
• Transcribe: GetTranscriptionJob(TranscriptionJobName=...) — 結果はS3 URIで受け取る

ページネーションが必要な場合、NextTokenが返らなくなるまでループします。

同期 vs 非同期の使い分け

S3 → Lambda → AI API の定番パイプライン

タスク特化AIを組み込む最も一般的なアーキテクチャは、S3イベントトリガーでLambdaを起動し、AI APIを呼び出して結果を保存するパターンです。

基本フロー

1. 入力ファイルをS3バケットにアップロード
2. S3イベント通知（ObjectCreated）がLambdaをトリガー
3. LambdaがAI API（StartXxx または同期API）を呼び出し
4. 非同期の場合はSNS/SQS経由でコールバックLambdaを起動
5. 結果をS3（JSONファイル）またはDynamoDB（構造化データ）に保存

IAMロールの最小権限設計

LambdaのIAMロールに必要な権限は最小限にします。

• 入力S3バケットへの s3:GetObject
• 出力S3バケットへの s3:PutObject
• Textractなら textract:StartDocumentAnalysis・textract:GetDocumentAnalysis
• SNSトピックへの sns:Publish（非同期時）

大規模オーケストレーション

複数のAIステップを組み合わせる場合、Step Functionsでワークフローをオーケストレーションします。例えば「Textract抽出 → Comprehend分類 → 結果保存」の3ステップをStep Functionsのステートマシンとして定義することで、エラーハンドリングと再実行を宣言的に管理できます。Step Functions自体の操作詳細は既存記事を参照ください。

Step Functions本番運用ガイドを読む（§6参照先）

精度向上: 信頼度スコア閾値 + Amazon A2I

タスク特化AIの4サービスは、すべての検出結果に信頼度スコア（Confidence）を付与します。このスコアを活用して、精度と自動化率のバランスを設計します。

信頼度スコアの設計パターン

本番では通常、2つの閾値（上位閾値・下位閾値）を設定した3ゾーン設計が有効です。

閾値の最適値は業務の許容エラー率によって異なります。金融・医療などの高精度領域では上位閾値を95%以上に設定するケースも多いです。

Amazon A2I（Augmented AI）による人手レビュー

中間ゾーンの結果はAmazon A2Iのヒューマンレビューワークフローに送付します。A2IはTextract・Rekognitionとのネイティブ統合があり、レビュー結果をモデルの再学習データとして活用できます。

A2I統合の設計ポイントは次の通りです。

• HumanLoopConfigでレビュー条件（閾値）を定義
• HumanTaskUiTemplateArnでレビューUIテンプレートを指定
• レビュー結果はS3に保存され、次のバッチ学習に活用可能

サンプリング検証

本番稼働後も、定期的なサンプリング検証を運用に組み込みます。自動承認した結果の一定割合（例：1%）を人手でチェックし、精度が基準を下回った場合はアラートを発報します。このフィードバックループにより、モデル劣化やデータドリフトを早期に検知できます。

コスト構造と最適化

タスク特化AIの課金はサービスごとに異なります。主要な課金モデルを把握した上で最適化を図ります。

各サービスの課金モデル

カスタムモデルの課金に注意

Rekognition Custom Labels、Comprehend Custom ClassifierやCustom Entity Recognizerはモデルの学習（Training）と推論（Inference Endpoint稼働）の両方で費用が発生します。

• 学習費用：Rekognitionは学習時間、Comprehendはデータ量ベース
• 推論費用：カスタムモデルはエンドポイントを起動している間、インスタンス時間で課金

利用頻度が低い場合は推論エンドポイントを都度起動・停止することでコストを抑えられます。プリトレーンドAPIはエンドポイント管理不要でAPIコール単位の課金のため、利用頻度が低い場面に適しています。

コスト最適化の主要施策

• 同期/非同期の適切な使い分け ：少量・即時はAPIコールを抑制した同期、大量はバッチ集約して非同期
• 不要なFeatureTypesの省略 ：TextractでTABLES/FORMSが不要なページはDETECT_DOCUMENT_TEXTのみに留める
• Transcribeのチャンキング ：長時間の音声は必要箇所のみを切り出して処理
• リザーブドキャパシティ ：Transcribeは大量継続利用でリザーブドキャパシティによるコスト削減が可能

スロットリング対策: 指数バックオフ + DLQ

各タスク特化AIサービスにはTPS（Transactions Per Second）上限があります。上限を超えるとThrottlingException（Textract/Rekognition）またはLimitExceededException（Transcribe/Comprehend）が返ります。

指数バックオフ with ジッター

スロットリングに対するベストプラクティスは、指数バックオフ（Exponential Backoff）にジッター（ランダム揺らぎ）を加えたリトライです。複数のLambdaが同時にリトライすると「Thundering Herd問題」が発生するため、ジッターにより同期を崩します。

import time
import random
import boto3
from botocore.exceptions import ClientError

def call_with_retry(func, max_retries=5, base_delay=1.0):
 for attempt in range(max_retries):
  try:
return func()
  except ClientError as e:
code = e.response['Error']['Code']
if code in ('ThrottlingException', 'LimitExceededException'):
 if attempt == max_retries - 1:
  raise
 delay = base_delay * (2 ** attempt) + random.uniform(0, 1)
 time.sleep(delay)
else:
 raise

Dead Letter Queue（DLQ）による失敗保護

Lambda + SQSのパターンでは、リトライ上限に達した失敗メッセージをDLQ（Dead Letter Queue）に転送します。DLQで保留されたメッセージはアラームで検知し、原因調査後に再処理キューへ移動させます。

DLQ設計のポイントは次の通りです。

• SQSキューのmaxReceiveCountで最大リトライ回数を設定（通常3〜5回）
• DLQのメッセージ保持期間を長め（14日）に設定して分析時間を確保
• CloudWatch AlarmでApproximateNumberOfMessagesVisible > 0を監視

Service Quotaの引き上げ申請

スロットリングが頻発する場合は、AWS Service QuotasコンソールからデフォルトのTPS上限引き上げを申請します。本番環境では事前申請が推奨です。テキスト量・画像数・音声時間の見積もりを元に、ピーク時のTPS要件を算出して申請します。

運用監視の設定

• CloudWatch Metric: ThrottledCount（Textract/Rekognition）・ThrottledRequests（Transcribe）を監視
• エラー率アラーム: ErrorCount / RequestCount > 0.01（1%）を超えたらアラーム
• コスト監視: AWS Budgetsでサービス別の月次予算を設定し、予算の80%到達でアラーム

7. 実戦統合パターン — 複数AIの組合せと生成AIとのハイブリッド

タスク特化AI4サービスの真の価値は、単体利用ではなく「組み合わせ」と「生成AIとのハイブリッド」によって最大化されます。本節では本番現場で実績のある3つの統合パターンを詳解し、サービス選定フローを整理します。

パターン①: 請求書・帳票処理の自動化

構成: Textract → Comprehend → Bedrock

請求書・発注書・納品書などの帳票処理は、タスク特化AI統合の最も典型的な用途です。

[S3: 帳票到着]
 ↓ S3イベント通知
[Lambda: ジョブ起動]
 ↓ StartDocumentAnalysis(FORMS + QUERIES)
[Textract: 非同期抽出]
 ↓ SNS完了通知 → Lambda
[Lambda: Comprehend呼び出し]
 ↓ ClassifyDocument(文書種別判定)
 ↓ DetectEntities / CustomEntityRecognizer(金額・取引先・品目抽出)
[Bedrock Claude: 例外判断・要約生成]
 ↓
[DynamoDB / 業務システムへ登録]
 ↓ 低信頼度の場合のみ
[Amazon A2I: 人手レビュー]

各ステップの設計ポイント:

1. Textract(帳票抽出) — FeatureTypes: ['FORMS', 'QUERIES'] を指定。QUERIESに「請求金額を教えてください」「振込先口座番号を抽出してください」を入力すると、レイアウトに依存しない狙い撃ち抽出が可能。信頼度スコアが低いフィールドはフラグを立てる

2. Comprehend(分類・エンティティ抽出) — カスタム分類器で「請求書/発注書/納品書/契約書」を判定後、判定カテゴリごとに専用カスタムエンティティ認識モデルを起動。汎用エンティティ認識ではPERSONがサプライヤ名に誤判定されるため、業務固有のエンティティ定義が精度を決定する

3. Bedrock(例外判断・要約) — 金額の閾値超過・取引先未登録・フォームフィールドの欠損を検出した場合、Bedrock Claudeへ例外ケースの判断を依頼。「この請求書の内容を要約し、通常と異なる点を箇条書きで挙げてください」といったプロンプトで構造化された判断支援を生成できる

4. Amazon A2I(人手レビュー) — Textract信頼度 < 0.8 または Comprehend信頼度 < 0.85 の帳票を自動的にA2Iレビューキューへ転送。人手修正結果をフィードバックループで学習データに組み込むことで継続改善が可能

処理量の目安: 中規模企業の月間5万件の帳票処理で、人手作業比90%削減・処理時間を数日から数分に短縮した実績があります。

パターン②: コンタクトセンターの音声→テキスト→インサイト分析

構成: Transcribe Call Analytics → Comprehend → Bedrock

コンタクトセンターの通話録音を自動分析し、顧客体験改善と品質管理を効率化するパターンです。

[S3: 通話録音(WAV/MP3)]
 ↓
[Transcribe Call Analytics: 非同期ジョブ]
 ↓ 出力(JSON)
 - 話者分離済みトランスクリプト
 - 感情スコア(エージェント/顧客別)
 - インタラプト回数・無音時間
 - 通話サマリー(オプション)
 ↓
[Lambda: 分析データ抽出]
 ↓
[Comprehend: カスタム分類]
 - 問い合わせカテゴリ(返品/技術/請求/解約など)を判定
 - PII検出・マスク処理(通話ログの個人情報除去)
 ↓
[Bedrock Claude: 応答改善提案・QA評価]
 - 「エージェントの対応改善点を3点挙げてください」
 - 「この通話を解約意向スコアで評価してください(1-10)」
 ↓
[DynamoDB / OpenSearch: インサイト蓄積]
[Amazon Connect / BI ダッシュボード: 可視化]

リアルタイム活用のオプション:

TranscribeのリアルタイムストリーミングとAmazon Connectを組み合わせると、通話中にリアルタイムで文字起こし・感情検知・サジェストを提供できます。エージェントが次に言うべきトーク例や、エスカレーション推奨のアラートをリアルタイムで表示するアシスト機能に発展します。

# Transcribe Call Analyticsのジョブ起動例
response = transcribe.start_call_analytics_job(
 CallAnalyticsJobName='contact-center-analysis-20240601-001',
 Media={'MediaFileUri': 's3://my-call-recordings/call_001.wav'},
 OutputLocation='s3://my-analysis-results/',
 DataAccessRoleArn='arn:aws:iam::123456789012:role/TranscribeRole',
 Settings={
  'VocabularyName': 'contact-center-terms',
  'LanguageOptions': ['ja-JP'],
 },
 ChannelDefinitions=[
  {'ChannelId': 0, 'ParticipantRole': 'AGENT'},
  {'ChannelId': 1, 'ParticipantRole': 'CUSTOMER'}
 ]
)

Call Analyticsの出力には話者別の感情スコア推移・インタラプト回数・保留時間が含まれており、品質管理スコアリングを自動化できます。手動でのコール聴取サンプリングを全件自動評価に切り替えた事例では、品質問題の検出率が大幅に向上しています。

Amazon Connect本番運用はこちら（AWS Connect 実践 Vol1）

パターン③: メディアコンテンツ審査の半自動化

構成: Rekognition → A2I → Comprehend

SNS・UGC(ユーザー投稿コンテンツ)・eコマースの商品画像を自動審査するパターンです。完全自動化でなく人間をループに組み込む「Moderation-in-the-Loop」設計が重要です。

[S3: ユーザー投稿画像/動画]
 ↓
[Rekognition: コンテンツモデレーション]
 - 不適切コンテンツを3階層タクソノミー(L1-L3)で分類
 - 信頼度スコアを付与
 ↓ スコア評価
 [高信頼度 SAFE(>0.95)]  → 自動承認
 [高信頼度 UNSAFE(>0.95)]→ 自動拒否
 [中間(0.70-0.95)] → Amazon A2I(人手審査)
 ↓ A2I審査完了
[Comprehend: キャプション/テキスト分析]
 - 投稿テキスト・キャプションのPII検出
 - カスタム分類でスパム/ハラスメント/違反コンテンツ判定
 ↓
[DynamoDB: 審査ログ蓄積]
[Rekognition Custom Labels: フィードバックで再学習]

Rekognitionコンテンツモデレーションのタクソノミー活用:

response = rekognition.detect_moderation_labels(
 Image={'S3Object': {'Bucket': 'ugc-images', 'Name': 'upload_001.jpg'}},
 MinConfidence=50.0
)

for label in response['ModerationLabels']:
 print(f"L1: {label.get('ParentName', 'ROOT')} > {label['Name']}: {label['Confidence']:.1f}%")
 # L1: Explicit Nudity > Nudity: 97.3%
 # L1: Violence > Graphic Violence: 23.1%

信頼度スコアの閾値設計は事業リスクに応じて調整します。子ども向けプラットフォームは閾値を低め(誤検知を許容してでも安全側)に設定し、一般向けUGCでは高め(不必要な人手レビューを削減)に設定します。

画像に埋め込まれたテキストはRekognitionのText Detectionで抽出し、Comprehendのカスタム分類で違反テキストを検出するハイブリッドが有効です。画像単体では安全でも、埋め込みテキストに問題がある事例に対応できます。

AIサービス選定フロー — 入力種別 × 処理目的

適切なサービスを最短で選ぶための選定フローです。

Step 1: 入力種別の確認

Step 2: 処理目的の確認

Step 3: 生成AI分岐の判断基準

タスク特化AIで処理できない場合、またはタスク特化AIの出力を入力として生成AIに渡す場合は以下の基準で判断します:

• タスク特化AIを選ぶべき場合: 入出力が定型/構造化・学習済みモデルによる精度が十分・大量処理でコストを抑えたい・低レイテンシが必要
• Bedrockを選ぶべき場合: 自由記述の生成が必要・例外ケースの柔軟な判断が必要・複雑な推論や多段階の思考が必要・タスク特化AIの出力を人間向けに説明・要約したい

ハイブリッド設計の原則

タスク特化AIと生成AIを組み合わせる際の設計原則を整理します。

原則1: タスク特化AIを前段に置く

Bedrockに生の帳票画像や長大な生テキストを直接渡すのは非効率です。Textract/Transcribeで構造化・クリーニングした後のデータをBedrockに渡すことで、トークン消費を削減しつつ精度を向上できます。

# 非効率な例
Bedrock → 「この画像から請求金額を抽出してください」 (画像をBedrockに直接渡す)

# 効率的なハイブリッド
Textract → 「請求金額: ¥125,000 / 振込期限: 2024-12-31」(構造化済みテキスト)
  → Bedrock → 「この請求書を3行で要約し、通常と異なる点を挙げてください」

原則2: 信頼度スコアで分岐する

タスク特化AIの信頼度スコアが高い場合は自動処理、低い場合はBedrockの追加判断またはA2I人手レビューへ分岐する設計が堅牢です。

原則3: 既存AI記事との連携

本シリーズの4サービスは、以下の既存シリーズと連携して完全なAIシステムを構成します:

• タスク特化AIによる構造化済みデータを → BedrockでLLM推論に渡す(本シリーズVol1との連携)
• 独自モデル精度が不十分な場合 → SageMakerでファインチューニング
• 複雑なマルチステップ処理 → Step Functionsでオーケストレーション
• エージェント型自律処理 → Bedrock Agents / AgentCore

生成AI(Bedrock)との連携設計はこちら（Amazon Bedrock本番運用 Vol1）

独自MLモデル開発・ファインチューニングはこちら（SageMaker Unified Studio Vol1）

生成AI×RAG/エージェントはこちら（ML/AI本番運用 Vol2）

独自MLモデル開発はこちら（SageMaker Unified Studio Vol1）

8. つまずきポイント・アンチパターン・まとめ

8.1 つまずきポイント — 本番で頻発する8つの落とし穴

つまずきポイント1: 同期APIで大量文書を処理してスロットリング

請求書が1日1000枚以上届くシステムでAnalyzeDocument同期APIを直接呼び出し続けると、TextractのスロットリングTPS上限に達してThrottlingExceptionが発生します。同期APIはリアルタイム処理向けであり、大量バッチには設計されていません。

解決策: 非同期API(StartDocumentAnalysis)に切り替え、S3バッチ入力→SNS/SQS通知パターンを採用します。SQSでジョブをキューイングすることで自然な流量制御が実現します。さらにサービスクォータの引き上げ申請を検討します。

つまずきポイント2: SNS/SQS未設定のままGetXxxを頻繁ポーリング

非同期APIを使い始めた際に、完了確認をループでのポーリングで実装するケースがあります。1秒ごとにGetDocumentAnalysisResultを呼び続けると、処理が完了していない間も無駄なAPIコールが発生してコストが積み上がり、さらにスロットリングのリスクも高まります。

解決策: SNSトピックに完了通知を設定し、SQSキューで受け取るイベント駆動型の設計に切り替えます。これにより完了するまでポーリングを行わずコストとレイテンシの両方を最適化できます。

つまずきポイント3: 信頼度スコアを無視して誤抽出を本番に流す

TextractはすべてのブロックにConfidenceスコアを付与しますが、このスコアを無視して全件を後段システムに渡すと、低品質な抽出結果が会計システムや顧客DBに混入します。特に低解像度スキャンや手書き帳票では、信頼度の低い項目が高確率で発生します。

解決策: Confidenceの閾値を設計します(例: 90%以上=自動承認、70〜90%=A2I人手レビュー、70%未満=差し戻し)。閾値は本番データサンプルでキャリブレーションします。A2Iとの統合は§2.6を参照してください。

つまずきポイント4: ComprehendのTopic Modeling等の新規制限機能を新規設計に採用

2026年4月30日以降、Amazon ComprehendのTopic Modeling・Event Detection・Prompt Safety Classificationは新規顧客への提供が停止されています。既存ユーザは継続利用可能ですが、新規システム設計でこれらの機能を前提にしてはいけません。このことを知らないままシステムへ組み込んでしまうと、設計段階で機能の利用不可が発覚します。

解決策: Topic Modeling代替にはBedrock(Claude等)でのテキスト分析を採用します。Event Detectionが必要な場合はBedrockの情報抽出プロンプトで代替します。コアの分類/感情分析/PII検出/カスタムモデルはGA継続のため、これらを中心に設計します。

つまずきポイント5: Rekognitionの顔認識でプライバシー規制を考慮しない

Rekognitionの顔認識・顔比較機能は強力ですが、個人識別目的での利用にはBIPA(生体情報プライバシー法、米イリノイ州他)・GDPR・日本の個人情報保護法など各国の法規制への対応が必要です。規制確認なしに顔認識を本番投入すると訴訟リスクを伴います。

解決策: 顔認識を使う場合は、利用目的の限定・本人同意の取得・データ保持期間の制限・プライバシーポリシーへの明示を徹底します。個人特定を伴わない顔分析(属性推定のみ)の場合は比較的リスクが低いですが、法務確認は必ず実施します。

つまずきポイント6: カスタムモデルの学習データ不足で精度が出ない

Comprehendのカスタム分類やRekognition Custom Labelsは独自のMLモデルを学習させる機能ですが、学習データが少ないと精度が低く実用にならないモデルが生成されます。「100件程度のラベル付きデータで学習させたが精度が30%台だった」といったケースが頻発します。

解決策: Comprehendカスタム分類は最低500〜1000件(クラスあたり50〜200件以上)のラベル付きテキストを推奨します。Rekognition Custom Labelsは物体1種類あたり最低20〜30枚(推奨100枚以上・多様な角度・照明条件)。学習前にデータ品質チェックリストを作成して確認します。

つまずきポイント7: 言語非対応の見落とし(Comprehend PIIは英語・スペイン語のみ)

Comprehendのリアルタイムエンティティ検出・感情分析は日本語を含む複数言語に対応していますが、PIIの検出は英語とスペイン語のみです。日本語テキストの個人情報検出を期待してシステムを設計すると、テスト段階で意図した動作が得られない点に気付きます。

同様に、Transcribeのカスタム語彙・カスタム言語モデルも対応言語に制限があります。利用予定の言語が機能の対応言語リストに含まれているかを設計段階で確認することが必須です。

解決策: 機能ごとの対応言語を公式ドキュメントで確認します。日本語PII検出が必要な場合はBedrockのClaudeで情報抽出プロンプトを使う代替策を検討します。

つまずきポイント8: カスタムモデル推論エンドポイントの時間課金を見落とす

Comprehendのカスタム分類・エンティティ認識、Rekognition Custom Labelsのカスタムモデルは、「推論エンドポイント(プロジェクトバージョン)の実行中」は処理の有無に関わらず時間単位で課金されます。学習後にエンドポイントを起動したまま放置すると、月末に想定外の高額請求が発生します。

解決策: バッチ処理では実行直前に起動し、完了後すぐ停止する制御を実装します。常時起動が必要なリアルタイム処理の場合でも、夜間・休日の低負荷時間帯にスケールダウンするスケジューリングを組みます。EventBridge SchedulerでLambdaを定期実行して自動停止するパターンが定番です。

8.2 アンチパターン → 正解対照表

8.3 まとめ — 4サービスの再掲要点

本記事で解説したAWSタスク特化AI4サービスの要点を再掲します。

Amazon Textract: ドキュメント/帳票からテキスト・表・フォーム・指定項目を抽出するサービスです。FeatureTypesの使い分けが核心で、Queries APIにより帳票フォーマットのゆらぎを吸収できます。本番ではConfidenceスコアによる3段階の精度設計とA2I人手レビューを組み合わせます。大量処理は非同期API(StartDocumentAnalysis + SNS/SQS)に切り替えます。2025年更新で上付き/下付きテキスト・回転テキスト・低解像度FAXの精度が改善されました。

Amazon Comprehend: テキストの言語分析(エンティティ/感情/PII)に加え、カスタム分類・カスタムエンティティ認識で独自ドメインにも対応します。2026年4月30日以降、Topic Modeling・Event Detection・Prompt Safety Classificationは新規顧客への提供が停止されているため、新規設計では使わず代替を選びます。コアのPII検出は英語・スペイン語のみである点に注意します。

Amazon Rekognition: 画像/動画のラベル検出・顔分析・コンテンツモデレーションを学習済みAPIで即座に利用可能です。Custom LabelsでB2Bドメイン固有の物体も認識できます。顔認識は利用目的の限定と法規制確認を必須とします。動画処理は非同期Video API(S3 + SNS/SQS)を使います。

Amazon Transcribe: リアルタイムストリーミング(HTTP/2・WebSocket)と非同期バッチの2経路で音声をテキスト化します。Call Analyticsでコンタクトセンターの感情分析・通話要約・リアルタイムアドバイスを実現できます。出力をComprehendに渡す「文字起こし→言語分析」のハイブリッドパイプラインが定番です。

4サービス共通の運用原則:

1. 大量処理は非同期API + ジョブ管理(SNS/SQS)で設計する
2. 信頼度スコア閾値 + Amazon A2I で精度を担保する
3. タスク特化AIは定型の抽出/分類/認識、生成AIは非定型生成という使い分けを徹底する
4. カスタムモデルは学習データ品質・量を事前確認し、推論エンドポイントのコストを管理する
5. 本番デプロイ前に各サービスのAPI仕様・対応言語・提供状況を公式ドキュメントで確認する

8.4 クロスリンク — 関連記事へのナビゲーション

本記事で登場した関連技術の詳細は以下の記事で解説しています。

生成AI(Bedrock)との連携設計はこちら（Amazon Bedrock本番運用 Vol1）

生成AI×RAG/エージェントはこちら（ML/AI本番運用 Vol2）

生成AI LLMOps本番運用 Vol1はこちら

独自MLモデル開発はこちら（SageMaker Unified Studio Vol1）

8.5 コスト設計の落とし穴と最適化パターン

4サービスのコスト構造を把握しないまま本番に投入すると、予算超過を招くポイントがいくつかあります。

Textractのコストはページ単位で発生します。月次100万ページのDetectDocumentTextは$1,500、同ページ数のAnalyzeDocument(TABLES/FORMS)は$15,000と10倍の差があります。機能を絞ることで大きくコストを削減できます。

Comprehendのコストは文字数(UTF-8バイト数)と処理タイプで決まります。感情分析は3バイト最小単位で課金されます。大量のショートテキストを個別に送るよりBatchDetectSentimentでまとめて送ることでAPIコール数を削減できます。カスタム推論エンドポイントは起動時間課金のため、使用していない時間帯の停止が最重要の最適化です。

Rekognitionのコストは画像1000枚あたり、または動画1分あたりで課金されます。Custom Labels推論は推論ユニット単位の時間課金です。動画の場合はフレームレートを下げた解析(全フレームではなく1秒に1フレーム等)でコストを削減できます。

Transcribeのコストは音声の秒数(最小15秒)で課金されます。無音期間の多い音声は前処理でカットするとコストを削減できます。リアルタイムAPIは非同期バッチより高コストのため、リアルタイム性が不要な用途では非同期を使います。

コスト監視には、CloudWatchのメトリクスに加えてAWS Cost Explorerのサービス別・APIオペレーション別コスト分析を活用します。予算アラートをSNSと組み合わせてしきい値を超えた際に通知する設計も推奨します。

8.6 本番運用で使えるデバッグパターン

本番稼働後に発生しやすいトラブルとその診断パターンを整理します。

Textractの抽出精度が突然低下した場合:

• スキャン機器の変更や設定変更でDPIや向きが変わっていないか確認します。
• 帳票フォーマットのマイナーバージョンアップで項目位置が変わった場合、Queries APIでは影響が小さいですが、FORMSベースの抽出では影響が出ます。
• CloudWatchのConfidence分布をモニタリングし、低信頼度件数が増えた時点でアラートを上げる仕組みを整備します。

Comprehendの分類精度が期待値を下回る場合:

• 学習データのラベルの一貫性を確認します。同じ意味のテキストに異なるラベルが付いていると精度を下げます。
• テスト用データが学習データと同一ドメインかを確認します。Out-of-Domainのテキストは精度が低くなります。
• 信頼度スコアの分布を可視化します。全体の信頼度が低い場合、学習データ量の追加またはモデルの再学習が必要です。

Rekognitionのモデレーション誤検知が多い場合:

• MinConfidenceの閾値を引き上げます。デフォルト値より高い値(例: 70→80)に設定することで誤検知を減らせます。
• カスタムモデレーションアダプタの利用を検討します。プリトレーンドモデルの誤検知パターンに対してドメイン特化の調整を行えます。
• A2Iで人手レビューした結果を蓄積し、誤検知パターンを分析してモデル再学習の素材に活用します。

Transcribeの文字起こし品質が低い場合:

• カスタム語彙(専門用語・固有名詞)の登録状況を確認します。未登録の専門用語は誤認識されやすいです。
• 録音環境の品質(マイクの品質・バックグラウンドノイズ・話速)を確認します。特に電話音声は周波数帯が狭いため誤認識しやすいです。
• ShowSpeakerLabelsとChannelIdentificationの設定を確認します。話者分離が不要な場合は無効化することで処理速度と精度が向上します。

これらのデバッグパターンをRunbookとして整備し、インシデント発生時に迅速に診断できる体制を作ることが本番運用品質の維持につながります。

8.7 本番移行チェックリスト

以下は本番移行前に確認すべき重要なチェックリストです。

設計・アーキテクチャ確認:

• [ ] 大量処理ユースケースで非同期APIを採用しているか
• [ ] SNS→SQSのイベント駆動型完了通知が設定されているか
• [ ] 信頼度スコアの3段階閾値(自動承認/A2Iレビュー/差し戻し)が設計されているか
• [ ] スロットリング対策として指数バックオフとDLQが実装されているか
• [ ] カスタムモデル推論エンドポイントの起動/停止管理が自動化されているか

セキュリティ・コンプライアンス確認:

• [ ] 顔認識機能を使用する場合、法規制確認と本人同意プロセスが整備されているか
• [ ] PII検出機能の対応言語(英語・スペイン語)が要件を満たしているか
• [ ] 処理した文書データのS3バケットに適切な暗号化とアクセス制御が設定されているか
• [ ] Comprehendの廃止機能(Topic modeling等)を新規設計に採用していないか

コスト管理確認:

• [ ] 使用するFeatureTypesを必要最低限に絞ったか
• [ ] カスタムモデルのエンドポイント時間課金をコスト試算したか
• [ ] AWS Budgetsでサービス別の予算アラートを設定したか

品質・テスト確認:

• [ ] 本番代表データでConfidence閾値のキャリブレーションを行ったか
• [ ] A2Iのヒューマンレビューループが正常に動作することを確認したか
• [ ] エラー率・レイテンシ・コストのCloudWatchダッシュボードを構築したか

このチェックリストを移行前レビューの際に確認することで、本番移行後の問題を事前に防止できます。