推論方式の前提をそろえる
推論（Inference）は、学習済みモデルを使って「新しい入力から予測・分類・生成」を行う処理です。AIF-C01では、モデルの中身を作り込む話よりも、「どんな要件のときに、どの推論方式・どのAWS構成を選ぶか」を整理しているかが重要になりやすいです。
推論方式は大きく分けて次の2つで語られます。
- リアルタイム推論（オンライン推論）：ユーザー操作やAPI呼び出しに対して、その場で結果を返す
- バッチ推論（オフライン推論）：入力データをまとめて処理し、後から結果を使う
ただし現場やAWSサービスの機能を見ると、リアルタイムとバッチの間に「中間」があります。代表例が SageMakerの非同期推論 です。これはリクエストをキューに入れて非同期に処理し、結果を後から受け取る方式で、大きなペイロードや時間がかかる推論に向いています。最大ペイロードや処理時間などの特徴が明確に説明されています。
ここまでを一言でまとめると、推論方式は「速く返すか」「まとめて回すか」だけでなく、**返し方（同期/非同期）**まで含めて設計の選択肢がある、ということです。
AIF-C01対策で評価の高いUdemy講座をまとめて確認できます。👇
セール時は1,500円前後で購入できることもあります。
判断軸はレイテンシだけではない
「リアルタイム推論＝正義」と思いがちですが、実務でも試験でも、それだけで決めると設計が崩れます。判断軸を、最低限この5つで見ると迷いが減ります。
レイテンシ要件
- 例：画面の検索補助、チャット応答、本人確認の判定などは、待ち時間が長いとUXが崩れやすい
- 逆に、日次レポートのスコアリングや、メール配信のセグメント作成は「数分〜数時間でもOK」になりやすい
スループットと入力のまとまり
- 秒間リクエストが高く、入力が小さいならリアルタイムでさばきやすい
- 一方で「データが大量にあり、まとめて処理したい」ならバッチに寄せるのが自然
ペイロードの大きさと処理時間
大きな入力や長い処理時間は、同期のリアルタイムAPIに載せるほど失敗しやすいです。SageMaker非同期推論は、この領域を狙って「大きなペイロード」「長い処理」「ほぼリアルタイム」を想定した機能として説明されています。
コスト最適化
- 常時リクエストが来る：リアルタイムの常時稼働でも無駄が出にくい
- たまにしか来ない：アイドル時間が多い構成だとコストが膨らみやすい
- 非同期推論は「リクエストがないときにゼロ台までスケールできる」点がコスト面のメリットとして説明されています。
運用と障害時のふるまい
- リアルタイムは「落ちたら即影響」。冗長化・オートスケール・監視・デプロイ戦略が重要
- バッチは「遅れてもやり直せる」設計にしやすい（再実行、リトライ、部分成功など）
この5軸を一度言語化してからAWSサービスに当てはめると、暗記ではなく理解で整理できます。
リアルタイム推論の典型パターンとAWS構成例
リアルタイム推論は「ユーザーの操作に追随して、すぐ結果が必要」なときの選択肢です。AWSでの典型パターンは大きく2系統あります。
SageMakerでリアルタイム推論を出す
最も分かりやすいのは SageMakerのエンドポイント を使うパターンです。モデルをホスティングして、HTTPリクエストで推論を返します。
ここで押さえたいのは、SageMakerの推論オプションが「リアルタイム一択」ではなく整理されている点です。SageMakerのドキュメントでは、推論オプションとして Batch Transformが“永続エンドポイント不要のオフライン処理向き” であることが明確に書かれています。つまり、リアルタイムにする理由がないなら、リアルタイムを選ばないのが自然です。
よくある構成例
- Web/アプリ
- Amazon API Gateway
- AWS Lambda（前処理、認可、入出力の整形）
- SageMakerリアルタイムエンドポイント
- 結果をDBへ（DynamoDB/RDSなど）またはそのまま返却
使いどころ例
- レコメンド（閲覧中に提案）
- 不正検知（決済やログイン時に判定）
- 画像の簡易判定（アップロード直後に結果表示）
Bedrockでリアルタイム生成を出す
生成AI寄りのユースケースでは Amazon Bedrock Runtime を呼ぶリアルタイム推論が典型です。Bedrockの InvokeModel は「指定したモデルを呼び出して推論（テキスト/画像/埋め込み等）を生成する」APIとして説明されています。
さらに「待っている間に少しずつ表示したい」場合はストリーミングが選択肢になります。InvokeModelWithResponseStream はレスポンスがイベントストリーム形式になることが示されています。チャットUIの体験を作るときに、ここは理解しておくと腑に落ちます。
よくある構成例
- フロントエンド（Web/モバイル）
- API Gateway / ALB
- Lambda / コンテナ（入力整形、ガードレール、プロンプト管理）
- Bedrock Runtime（InvokeModel、必要ならストリーミング）
- 生成結果をS3やDBに保存（監査や再利用）
リアルタイム推論での注意点
- 「同期で返す」設計は、タイムアウト・再試行・スパイク耐性を考える必要がある
- モデルの推論時間が読めないなら、後述する非同期やバッチに逃がす方が事故が減る
- 監視はアプリ監視だけでなく、推論の失敗率・レイテンシ分布・入力サイズの偏りを見ると実務に近い
バッチ推論の典型パターンとAWS構成例
バッチ推論は「データが揃っていて、まとめて処理したい」「結果が即時でなくてもよい」場合に向きます。現場ではこちらの方が実は多いです。AIF-C01でも、設計上のメリットを説明できると強い領域です。
SageMaker Batch Transformでまとめて推論する
SageMakerの Batch Transform は、永続的なエンドポイントを持たずに、データセット全体に対して推論を実行する用途が想定されています。ドキュメントでも「永続エンドポイントが不要」「大きなデータセットに対する推論」などの目的が箇条書きで示されています。
よくある構成例
- 入力：S3（CSV/JSONLなど）
- 実行：SageMaker Batch Transformジョブ
- 出力：S3（推論結果をファイルとして保存）
- 後処理：AWS Glue / Athena / Redshift で集計、あるいはDBへロード
- 起動：EventBridgeのスケジュール、Step Functionsでワークフロー化
使いどころ例
- 全顧客に対する解約確率スコアを毎日更新
- 商品マスタを使った分類ラベル付けを週次で更新
- ログ全体を対象に異常検知スコアを夜間バッチで計算
Batch Transformは、処理開始時にインスタンスを起動して処理を分散し、終われば止まる、という世界観なので「アイドルコスト」を抑えやすいのが直感的です。
非同期推論という“バッチ寄りのリアルタイム”
「ユーザーが操作した結果を返したいけど、数秒〜数十秒では終わらない」「入力が大きい」というとき、リアルタイムAPIに無理やり載せるより 非同期推論 が現実的になります。
SageMakerの非同期推論は、リクエストをキューイングして非同期に処理し、大きいペイロード（最大1GB）や長い処理時間（最大1時間）、ただし“ほぼリアルタイム”要件に適すると説明されています。
よくある構成例
- クライアントが推論リクエスト送信（受付だけ返す）
- 結果はS3に出力、または通知（SNSなど）で完了を伝える
- クライアントはポーリング/通知で結果取得
この方式は「リアルタイムのUX」と「バッチの耐久性・スケール」を折衷できます。AIF-C01の文脈でも、リアルタイムかバッチかの二択で詰まったときに、第三の選択肢として整理できると強いです。
迷ったときの落とし穴と試験での読み替え
ここからは、問題文で迷いやすいポイントを、実務目線で読み替えるコツとして整理します（断定的な出題予告ではなく、混乱しやすい論点の整理です）。
「すぐ必要」＝リアルタイム、とは限らない
“すぐ”の定義が曖昧なケースが多いです。
- 数百ミリ秒：リアルタイム寄り
- 数秒〜数十秒：非同期でも成立することがある
- 数分〜：バッチで十分なことが多い
問題文の「ユーザーが待つのか」「業務処理の裏側か」を想像すると判断しやすいです。
「コスト最適化」があるなら、常時稼働を疑う
たまにしか動かないのに、常時エンドポイントを立てる設計はコスト的に不利になりやすいです。SageMaker非同期推論は、リクエストがないときにゼロ台までスケールできる点が明記されています。こうした“止められる仕組み”はコスト要件と相性が良いです。
「大量データを一括処理」ならBatch Transformがまず候補
SageMakerの推論オプションとして、Batch Transformが「永続エンドポイント不要のオフライン処理向き」と整理されていることは、そのまま判断材料になります。
さらに、Batch Transformの目的として「大きなデータセットの推論」「永続エンドポイントが不要」などが示されているため、問題文のキーワードとつなげやすいです。
生成AIの“リアルタイム”はストリーミングの有無も論点
チャットのような体験を想定するなら、最後にまとめて返すより「途中から表示」が求められることがあります。BedrockのストリーミングAPIでは、レスポンスがイベントストリームになる点が説明されています。これを押さえておくと、要件に「逐次表示」「ストリーム」といったニュアンスが出たときに慌てません。
学習としてのおすすめ（Udemyの活用）
推論方式の使い分けは、用語暗記よりも「要件→構成」を何周も当てはめる方が伸びます。体系的に学べる教材の一例として、SageMakerの推論（エンドポイント、Batch Transform、非同期推論）やBedrockの呼び出し（InvokeModel、ストリーミング）をハンズオンで触れるUdemy講座を1本挟むと、点が線になりやすいです。講座を選ぶときは「推論のデプロイと運用（監視・スケール・コスト）」まで扱うものを選ぶと、理解が実務寄りになります。
AIF-C01対策で評価の高いUdemy講座をまとめて確認できます。👇
セール時は1,500円前後で購入できることもあります。
まとめ
推論方式の選択は、リアルタイムかバッチかの二択で考えると、設計も試験問題も途端に難しく見えます。整理のコツは、まず要件を「レイテンシ」「スループット」「ペイロードと処理時間」「コスト」「運用」の5軸に分解することです。
リアルタイム推論は、ユーザー操作に対して即時に返す必要があるときに強く、SageMakerのエンドポイントやBedrock Runtimeの呼び出しが代表的です。Bedrockは InvokeModel で推論を実行でき、必要ならストリーミングで段階的に返す設計も考えられます。
一方、バッチ推論は、データがまとまっていて結果の即時性が高くないときに自然な選択肢です。SageMaker Batch Transformは「永続エンドポイントが不要」「大きなデータセットの推論」といった目的が明確で、要件に合うなら迷いにくいです。
そして、リアルタイムに見えて実は“非同期が合う”領域もあります。SageMaker非同期推論は、大きなペイロードや長い処理時間、ただしほぼリアルタイム要件に向くと説明されており、コスト面でもゼロスケールができるのが特徴です。
AIF-C01の学習では、サービス名を丸暗記するよりも、「この要件ならこの方式、その理由はこれ」という説明ができる状態を目指すのが近道です。要件文を見たら、まず5軸で分解して、リアルタイム・非同期・バッチのどこに落ちるかを決める。これを繰り返すと、迷いが確実に減っていきます。
