ひとことで言うと
スクリプトとコンテナを渡すと、インスタンスを立てて・S3 のデータを流し込んで・処理して・結果を S3 に置いて・インスタンスを畳むまでをやる使い捨てジョブです。前処理・後処理・特徴量エンジニアリング・モデル評価が公式に挙げられた用途です。
要するに、S3 と S3 の間に一度だけ差し込む仮設のコンベアです。常設の設備（エンドポイント）ではないので、終われば消えて課金も止まります。運ぶ物（データ）と加工の仕方（スクリプト・コンテナ）はこちらが決め、コンベアを組み立てて解体する部分だけを SageMaker AI が持ちます。
なぜ生まれたか
学習とホスティングは SageMaker AI がマネージドで持っていたのに、その前後の「データをこねる」工程だけが自前の EC2 や EMR に残る状態が続いていました。同じデータに触るのに、IAM もネットワークも監査の経路も別立てになります。Processing は、この工程を学習ジョブと同じ形（ジョブ API・S3 入出力・CloudWatch）に揃えることで、SageMaker AI に組み込まれたセキュリティとコンプライアンスの中に前処理を戻しました。
| 決めること | 渡し方 |
|---|---|
| 何で処理するか | 組み込みのデータ処理コンテナ、または独自ロジックの持ち込みコンテナ（ECR に push） |
| どのデータを | 入力は S3 が基本。Amazon Athena・Amazon Redshift も入力ソースとして使える |
| どこで受け取るか | コンテナ内の /opt/ml/processing/input（コードは .../input/code） |
| どこへ出すか | コンテナ内の /opt/ml/processing/output/... に書くと、指定した S3 へアップロードされる |
| どれだけの規模で | instance_count / instance_type / volume_size_in_gb。完了時にリソースは解放される |
| どう起動するか | CreateProcessingJob API、AWS CLI、SageMaker Python SDK（ScriptProcessor など） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 学習前のデータ加工 | scikit-learn 等のスクリプトを渡して整形・クリーニングする | D1 |
| 大規模な分散処理 | PySparkProcessor / SparkJarProcessor で Spark を分散実行する | D1 |
| マルチモーダルデータの前処理 | 音声・画像・文書などを一括変換するバッチとして走らせる | D1 |
| 推論結果の後処理 | 出力の整形・集計を、エンドポイントとは別のバッチで行う | D1 |
| モデル評価 | 学習済みモデルの評価スクリプトを回して指標を S3 に出す | D5 |
| バイアス・説明可能性の分析 | SageMaker Clarify の分析は Clarify 専用コンテナを使う Processing ジョブとして実装されている | D3 |
| 独自依存関係での処理 | Dockerfile を書いて ECR に push し、その image URI を指定する | D1 |
試験でどう問われるか
主役では出ません。D1 の 1.3 で「マルチモーダルデータの処理」の手段として名指しされる位置です。分岐は規模と起動の形——1件ずつ来るのか、まとめて回すのか。Lambda との切り分けが本命です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| バッチ処理の実行基盤 | 大量データをまとめて変換する／実行時間が長い／GPU や大きなメモリが要る → Processing | Lambda（イベント単位・短時間の処理向き。長時間のバッチには向かない） |
| GUI か コードか | スクリプトとコンテナで再現性のある処理を書く → Processing | Data Wrangler（対話的な GUI。無人の定期実行そのものではない） |
| 実行時間の上限 | Spark 実行時、MaxRuntimeInSeconds は最大5日まで設定できる | 「長時間ジョブは Lambda のタイムアウト延長で対応する」 |
| モデル評価の置き場所 | 学習後に評価スクリプトを回して指標を出す → Processing ジョブ（学習ジョブでもエンドポイントでもない） | エンドポイントを立てて評価リクエストを流す案 |
| Clarify との関係 | バイアス・特徴量寄与の分析をどう実行するか → Clarify の Processing ジョブとして | 「Clarify は独立したエンドポイント型サービス」 |
| データソース | 入力は S3 が基本だが、Athena / Redshift も直接の入力ソースにできる | 「必ず事前に S3 へ吐き出しておく必要がある」 |
「マネージドだから速い」ではありません。公式が触れているのはインスタンス数と完了時間がほぼ線形（単純な Spark ワークロードの場合）という性質だけで、1インスタンスあたりの速さを上げる機能はありません。時間を半分にしたいなら台数を倍にする——そういう性格のサービスです。
実務でどう使うか
- 課金はジョブの実行時間だけです。 完了と同時にインスタンスが解放されるので、エンドポイントのような「立てっぱなしの出血」がありません。逆に、頻繁に短いジョブを打つと起動時間の割合が支配的になります
- 出力は S3 にアップロードされるまでローカルにしかありません。
s3_upload_modeをEndOfJobにしていると、ジョブが途中で落ちた場合そこまでの成果物は残りません。長時間ジョブでは分割するか、アップロードのタイミングを設計に入れます - 持ち込みコンテナは ECR 経由が前提です。 Dockerfile を書き、ECR リポジトリを作り、push した image URI を
app_specificationに渡す——他プラットフォーム（Kubernetes など）で使っている既存イメージをそのまま流用できるのは利点ですが、イメージの管理コストは自分持ちになります - 監視は CloudWatch で完結します。 CPU・GPU・メモリ・GPUメモリ・ディスクのメトリクスとイベントログが出るので、インスタンスサイズが足りているかは推測ではなく実測で決められます
- Spark のイメージは AWS が用意しています。 ソースと Dockerfile は公開されており、事前ビルド済みイメージは ECR にあります。SDK の
PySparkProcessorを使わない場合は自分で image URI を引くことになります
Processing を選ぶ理由は性能ではなく、権限と監査の経路です。同じ処理は EMR でも EC2 でも書けます。Processing の見返りは、SageMaker AI に組み込まれたセキュリティとコンプライアンスの枠組みの中で、学習・ホスティングと同じ形（ジョブ API・S3 入出力・CloudWatch）に揃うこと。シナリオに「既存の ML ワークフローと同じ統制下で」と書いてあれば、それが選定理由です。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| AWS Lambda | 1件か、まとめてか。 Lambda はイベント単位の短い処理、Processing は長時間・大規模なバッチ。同じ「サーバーレスな加工」でも粒度が違う |
| SageMaker Data Wrangler | Data Wrangler は人が画面で作る、Processing は無人で回す。フローを本番化すると Processing 側の世界に来る |
| AWS Glue | Glue はデータ基盤の ETL とカタログ。Processing はML のジョブとして学習・評価と同じ枠組みに乗る。IAM と監査の経路が SageMaker AI 側に揃うことが選ぶ理由になる |
| バッチ変換（Batch Transform） | バッチ変換はモデルに推論させるジョブ。Processing はモデルを使わない加工（または評価スクリプトの実行） |
| Amazon EMR | EMR はクラスタを持つ。Processing はジョブごとに立てて畳む。常設の分析基盤か、使い捨てかで分かれる |
| SageMaker Clarify | 別サービスに見えるが、実行形態は Processing ジョブ（専用コンテナ）。「Clarify をどう回すか」の答えが Processing になる |
想起チェック
Q1. Processing ジョブと Lambda を分ける基準を一言で。
処理の粒度と時間です。イベント単位で短時間なら Lambda、大量データをまとめて長時間かけるなら Processing。Spark 実行時の MaxRuntimeInSeconds は最大5日まで設定できます。
Q2. 学習済みモデルの評価指標を出したい。学習ジョブ・エンドポイント・Processing のどれですか。
Processing ジョブです。公式が挙げる用途に「モデル評価」が含まれます。評価のためだけにエンドポイントを立てる必要はありません。
Q3. 入力データは必ず S3 に置く必要がありますか。
S3 が基本ですが、Amazon Athena と Amazon Redshift も入力ソースとして使えます。「必ず事前に S3 へ書き出す」という制約ではありません。
Q4. SageMaker Clarify のバイアス分析は、どういう形で実行されますか。
Clarify 専用コンテナを使う Processing ジョブとして実行されます。入力データと分析設定を S3 から読み、結果を S3 に書き戻します。