ひとことで言うと
推論の結果を条件で選り分けて、人間のレビュー（ヒューマンループ）に流し込む配管です。レビュワーの管理・タスクUI・結果の回収（S3）までを引き受け、アプリ側は「どういう条件で人間に回すか」だけを決めます。
要するに、工場の抜き取り検査ラインです。全数を人が見るのではなく、機械が「自信がない」と言ったものと、無作為に抜いたロットだけを検査台に載せる。A2I が用意するのは検査台・作業指示書・検査記録の保管場所で、何を検査台に載せるかの基準（確信度の範囲・抜き取り率）は自分で書きます。
なぜ生まれたか
「低い確信度の推論は人間が見る」という要件は、ほぼすべての実運用 ML アプリに付いて回ります。ところがそれを自前で作ると、ワークフローの実装・タスク管理ソフトの自作・大量のレビュワーの管理という、モデルとは無関係な作業が丸ごと発生しました。公式が挙げる例が具体的で、スキャン品質や手書きが悪い住宅ローン申請書からの情報抽出です。
A2I はここを既製の部品にしました。Textract と Rekognition については、条件付きで人間ループを起動する統合まで済んでいます。
試験勉強より先に知っておくべき現況: 公式ドキュメントの冒頭に、「Amazon SageMaker A2I は新規のお客様には提供されていない。既存のお客様は通常どおり利用を継続できる。AWS はセキュリティと可用性の改善は続けるが、新機能の追加は予定していない」と明記されています（同じ注記が SageMaker Ground Truth にも付いています）。試験範囲には残っているので概念は問われますが、これから新規に組む HITL は Step Functions などで自前に組む、という現実との差を意識して読みます。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 画像モデレーションの人間レビュー | 組み込みタスクタイプ AWS/Rekognition/DetectModerationLabels/Image/V3 | D3 |
| 帳票抽出の人間レビュー | 組み込みタスクタイプ AWS/Textract/AnalyzeDocument/Forms/V1（キーバリューの欠落・低確信度で起動） | D3 |
| 任意のモデルの推論レビュー | カスタムタスクタイプ。アプリ側で条件判定し StartHumanLoop を呼ぶ | D2・D5 |
| リアルタイム推論の監査 | SageMaker AI エンドポイントの低確信度推論をレビューし、その出力データで追加学習する | D5 |
| 生成・変換系の品質確認 | Comprehend の推論、Transcribe の書き起こし、Translate の低確信度翻訳のレビュー | D5 |
| 継続的な抜き取り監査 | Sampling 条件で一定割合をランダムに人間へ | D3 |
| レビュワーの調達 | プライベート（自社の従業員）／ベンダー（AWS Marketplace）／Mechanical Turk から選ぶ | D2 |
試験でどう問われるか
A2I は D2 の「人間の専門性で FM を補強する」論点と、D3 の責任あるAI、D5 の人間評価の3方向から出ます。 一番出やすいのは Ground Truth との取り違えで、次が組み込みタスクタイプとカスタムタスクタイプで挙動が違うことです。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 人間を挟む要件 | 対象が**推論結果（本番の出力）**で、確信度で選り分けたい → A2I | SageMaker Ground Truth（あれは学習データのラベリング。時間軸が学習前で逆） |
| 学習データを作りたい | 対象がまだラベルの無いデータセットで、成果物が訓練用のラベル → Ground Truth（自動データラベリングで一部を機械化） | A2I（推論後の仕組みなので、そもそも入力が無い） |
| 人間レビューの起動条件をどこに書くか | 組み込みタスクタイプならフロー定義の HumanLoopActivationConditions。呼び出し側は HumanLoopConfig にフロー定義 ARN を渡すだけ | 呼び出し元サービスのパラメータで閾値を指定する案 |
| 自前モデルの推論を人間に回したい | カスタムタスクタイプ。条件はアプリ側のコードに書き、A2I ランタイムの StartHumanLoop を呼ぶ | カスタムタスクタイプで HumanLoopActivationConditions を設定する案（カスタムでは使えない） |
| コストを抑えつつ網羅性を確保 | 機械で絞って一部だけ人間に回す（Rekognition のモデレーションなら全体の1〜5%程度が公式の想定） | 全件を人間レビューに回す案／閾値を上げるだけで人間を置かない案 |
| レビュー結果をどう使うか | S3 の出力パスに集約され、完了は CloudWatch Events で通知。出力データを追加学習に回す | 呼び出し元の API レスポンスに人間の判定が同期で返る、と読む選択肢 |
| レビュワーの選定 | 機密データ → プライベートワークフォース。大量・非機密 → Mechanical Turk／ベンダー | 機密文書を Mechanical Turk に流す案（DataAttributes の申告が必要な時点で疑う） |
最も引っかかるのは既定の挙動です。組み込みタスクタイプで HumanLoopActivationConfig に条件を指定しなかった場合、そのサービスは「すべてのタスク」を人間レビューに送ります。「条件を書かなかったので人間レビューは起きない」は逆で、コストが跳ねる方向に倒れます。
カスタムタスクタイプはさらに単純で、条件そのものが設定できず、StartHumanLoop を呼んだ回数だけ必ず人間レビューが発生します。絞り込みはアプリ側の責任です。
実務でどう使うか
- フロー定義の名前はリージョン内で一意・小文字・最大63文字（a-z、0-9、ハイフン）です。
HumanLoopNameも同様に小文字で、リージョン内一意。バッチ投入で大文字が混ざって落ちるのが定番です - A2I のリソースと呼び出し元サービスのリソースは同一リージョンに揃えます。 出力先の S3 バケットもワークフローと同じリージョンである必要があります
HumanLoopConfigにはタスクの運用パラメータが並びます。TaskCount（1件を何人に見せるか）、TaskTimeLimitInSeconds（1タスクの制限時間）、TaskAvailabilityLifetimeInSeconds（タスクが取られずに失効するまで）。ここを既定のまま本番に出すと、誰も取らないタスクが静かに失効します- Mechanical Turk を使うときだけ
PublicWorkforceTaskPriceを含めます。 プライベート・ベンダーのワークフォースで指定すると余計です - 結果は同期では返りません。
StartHumanLoop（またはHumanLoopConfig付きの呼び出し）はHumanLoopArnを返すだけで、判定は S3 に落ちます。状態はDescribeHumanLoop、完了検知は CloudWatch Events。API レスポンスを待つ設計にはできません - 出力の KMS 暗号化は
OutputConfigのKmsKeyIdで指定します。 人間が見た判定結果は元データより機微であることが多く、ここを空にしたまま運用すると監査で必ず指摘されます - カスタムタスクタイプではワーカータスクテンプレートを自作します。 HTML のクラウドコンポーネントで書き、
RenderUiTemplateでプレビューできます
止まるのはタスクではなく人です。TaskAvailabilityLifetimeInSeconds を過ぎたタスクは、誰も取らないまま失効します。ヒューマンループはレビュワーが実際にログインして捌いている間だけ機能する仕組みで、S3 に結果が増えないことは「レビュー対象が無かった」とも「誰も見ていない」とも読めます。滞留は CloudWatch Events 側で見張ります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| SageMaker Ground Truth | Ground Truth は学習前にデータセットへラベルを付ける（成果物は訓練データ）。A2I は推論後に出力をレビューする（成果物は判定と監査記録）。時間軸が逆 |
| Step Functions の HITL | Step Functions はワークフローの中で承認待ちを作る汎用の手段。A2I はレビュワー管理とタスクUIまで込みの既製品。新規構築では前者が現実的（A2I は新規受付を終了） |
| Bedrock Guardrails | Guardrails は機械が自動で止める。A2I は人間に判断させる。「自動で拒否」なら Guardrails、「人が最終判断」なら A2I |
| Bedrock Model Evaluations の人間評価 | あちらはモデルを選ぶ・比較するための評価（オフライン）。A2I は本番の1件1件を捌く（オンライン） |
| SageMaker Model Monitor | Model Monitor は統計的なドリフトや品質劣化を検知する。A2I は個々の推論を人が見る。集計と個票の違い |
| Amazon Mechanical Turk 単体 | MTurk は労働力そのもの。A2I はその上に条件分岐・タスクUI・結果回収を載せた層。A2I からワークフォースの1選択肢として使える |
想起チェック
Q1. A2I と Ground Truth を1文で分けてください。
A2I は推論結果の人間レビュー、Ground Truth は学習データのラベリングです。A2I は本番の出力に対して事後に働き、Ground Truth は学習の前に訓練データを作ります。
Q2. Textract の組み込みタスクタイプでフロー定義を作り、起動条件を書き忘れました。何が起きますか。
すべてのドキュメントが人間レビューに送られます。 条件未指定は「人間レビューなし」ではなく「全件レビュー」です。コストと処理時間が想定外に跳ねます。
Q3. 自前の SageMaker エンドポイントの推論を、確信度 0.8 未満のときだけ人間に回したい。条件はどこに書きますか。
アプリケーションのコードです。カスタムタスクタイプでは HumanLoopActivationConditions が使えず、StartHumanLoop を呼べば必ず人間レビューが発生します。閾値判定は呼ぶ前に自分でやります。
Q4. 人間の判定結果はどこで受け取りますか。
フロー定義の OutputConfig で指定した S3 のパスです。呼び出しは HumanLoopArn を返すだけの非同期で、完了は CloudWatch Events で検知し、状態は DescribeHumanLoop で確認します。