MLS-2.2特徴エンジニアリングの実施。

ヒントボタン

2,000TPS を 50ms 未満でさばくには推論負荷が軽いアルゴリズムが望ましく、Amazon SageMaker Linear Learner なら AUC を目的関数にできて L1 正則化を簡単に有効化でき、高次元でも疎な重みでモデルが小さくなるため ml.m5.large 一台でも低レイテンシと過学習抑制を両立しやすく、さらに Managed Spot Training で学習費用を抑えられます。

特徴量を 100 以下に減らしつつ理由を説明するには PCA や Gain 重要度では元の項目に戻れないため、Amazon SageMaker Clarify が計算する SHAP 値で寄与度上位の変数を選び直して再学習する方法が有効です。SHAP は線形モデルとも相性が良く、QuickSight などに可視化すれば不正検知の根拠を事業部へ示しやすく、L1 正則化との組み合わせで精度と解釈性の両立が期待できます。

学習段階で Managed Spot Training を用いてコスト圧縮し、本番は単一の Amazon SageMaker Endpoint で 2,000TPS を裁く前提を守るには、推論が重い k-NN や複数インスタンスを要する構成を避け、軽量で線形なモデルと SHAP 可視化を組み合わせる設計が有利です。レイテンシ、コスト、解釈性、過学習対策という複数要件を俯瞰して総合判断を行ってください。

ヒントボタン

Amazon Forecast で DeepAR+ を用いる際、日ごとに変わる要素は Related time series に渡すと学習効率が高まります。隔週月曜休業は店舗ごとに需要がゼロになる動的パターンなので Target のみでは外れ値と誤認されがちです。休業フラグを動的特徴量に含めれば RMSE を抑えつつ 300 店舗×複数カテゴリでも並列学習が効き、フルマネージドのまま 2 時間以内で完了できるため運用コストも膨らみません。

年末年始や GW 前の急増はカレンダー要因です。FeaturizationConfig の CountryHoliday で JP を指定すると Amazon Forecast が日本の祝祭日を自動でエンコードし、DeepAR+ がイベント効果を適切に捉えます。手動で休日列を作成・保守しなくてよいので再学習ジョブもシンプルになり、追加コストなしで高精度を維持できます。週次・年次の複数季節性は内部推定されるためパラメータ調整も不要です。

Amazon Forecast で日次粒度の需要を扱う場合は、1) オペレーションに合わせて頻度「D」を維持し、2) 系列数が多くても DeepAR+ の高速分散学習で 2 時間 SLA を守り、3) Related time series と Holiday カレンダーで休業日と季節イベントを動的に取り込み精度 5％以内を狙う──これら複数要件を総合的に満たす設定を選ぶ視点が最終判断のポイントになります。

ヒントボタン

Amazon SageMaker Data Wrangler では Studio の GUI で計算列ステップを追加して関数リストから log1p を選択するだけで自然対数変換を施した特徴量を作れ、そのフローを保存後に Create processing job を押すと変換内容やメタデータを含む SageMaker Processing 用 Python スクリプトが自動生成されるためほぼコードレスで前処理を共有できます。
SageMaker Pipelines に Data Wrangler 由来の ProcessingStep を組み込むことで S3 上の Parquet を読み込み同一フローで変換後データを出力する再現性の高いワークフローを自動化でき、さらにパラメータ化した入力 URI と共に推論用ジョブやモデルモニタリングの前段にも流用すれば将来のバッチ処理でも常に同じ log1p 変換が保証され Lambda など外部制御が不要になります。
SageMaker Processing では managed spot capacity を有効化すると ml.m5.xlarge などの汎用インスタンスを最大 90% 引きのスポット料金で利用できジョブ再実行も自動化されるため常時稼働を前提とする Amazon EMR や都度クエリを書く Amazon Athena より運用とコストを抑制でき Data Wrangler のエクスポートスクリプトに spot_instance_count と max_wait を設定するだけで要件を満たします。
GUI 主体の操作で前処理を設計し Pipeline と Spot による自動実行と再現性を確立し学習とバッチ推論に同一処理を適用しながらコストを抑えるという複数要件を総合的に満たす解決策は Data Wrangler と SageMaker Processing/Pipelines の連携構成だと読み解けます。

ヒントボタン

Amazon SageMaker Data Wrangler には「対数(1+x)」変換オペレーションがあり、中央値付近の値はほぼ維持しつつ 5 万のような極端な customer_lifetime_value を強く圧縮できます。この単調写像は順位を崩さず外れ値の影響だけを和らげるため、ツリーの分割基準が偏らず XGBoost の学習が安定します。フローに追加しておけば SageMaker Pipelines や EventBridge で回す日次バッチでも同じ前処理を確実に再現できます。

S3 から取り込んだ購買履歴を整形する際、Min-Max スケーリングは最大値に引きずられ大半が 0 付近に密集し、Z スコア除去は正規分布前提で高 CLV 顧客まで捨てる恐れがあり、分位数ビニング＋ワンホットは連続的な大小関係が失われます。Data Wrangler の「対数(1+x)」変換なら非線形に値域を縮めることで尖度を下げつつ連続性を保てるため、XGBoost のスプリットが細かな違いを拾いやすくなる点をプレビュー統計で確認してみてください。

要件を俯瞰すると「外れ値を切り捨てずに影響だけ緩和する」「連続値の順序情報を残す」「コードを書かずにパイプラインで再現できる」という三つを同時に満たすことが鍵です。Amazon SageMaker Data Wrangler で標準提供される対数系の非線形変換がこれらを最もバランス良く満たす選択であると総合判断できます。

ヒントボタン

インタラクティブに1,000万行の日本語テキストを数分でサンプリングし、グラフやワードクラウドを確認できるサービスはブラウザだけで操作できる SageMaker Data Wrangler です。Athena や Glue のクエリを手書きせず UI で列選択やフィルタが行え、背後では分散処理が自動スケールするため 5 分以内という可視化要件をクリアしやすくなります。さらにサンプルはメモリに収まりやすいサイズへ自動抽出されるのでノートブックを立ち上げる待ち時間もありません。

全文書統計を必要とする TF-IDF はバッチ処理向けで、Spark Processing を用いる SageMaker Pipelines を毎日 02:00 にトリガーすればデータ量が増えても自動的に分散実行されます。OutputConfig で Parquet を指定し S3 バージョニングを有効にすると日次の成果物が世代管理され、Lake Formation や Athena からもすぐ参照可能です。ジョブは Data Wrangler の Export でコード生成されるため、Glue のフルスクラッチ開発と比べても運用作業を大きく削減できます。

Data Wrangler が出力する Python スクリプトは CodeCommit や GitHub にプッシュし CodeBuild／CodePipeline でテストを走らせることで CI/CD に自然に組み込めます。この流れなら Pull Request でレビューした内容がそのまま本番パイプラインに再利用でき、手動実行のノートブックや単独 Lambda より再現性が高くコストも予測しやすいです。時間制約・バージョン管理・運用工数という複数要件を総合的に満たす構成かどうかを軸に判断しましょう。

ヒントボタン

クリックストリームの入力 S3 URI、scikit-learn のハイパーパラメータ、生成した特徴量や評価指標をあとから SDK で横断検索したい場合、SageMaker Experiments が Trial と TrialComponent にメタデータを自動登録してくれるため、boto3 や sagemaker-sdk で即座にクエリでき、独自の Athena テーブルやタグ設計を新規に用意する手間を省けます。
前処理スクリプトだけを変更して最大 10 件を並列実行するなら、SageMaker Processing を含む SageMaker Pipelines でパラメータをリスト化し ParallelismConfiguration を設定すると、各ジョブがオンデマンドでコンテナを立ち上げて完了後に自動解放されるため、ノード管理なしでスケールアウトを実現できます。
常時稼働の EMR や ETL 向け Glue も候補に見えますが、クラスター保守やカタログ運用が伴い運用負荷の要件に触れがちです。モデル実験の体系的追跡、並列実行、ノードレス運用という複数条件を俯瞰すると、Pipelines と Experiments をネイティブ統合した SageMaker のマネージドアーキテクチャが最も自然な選択と言えます。

ヒントボタン

Amazon SageMaker Data Wrangler で 5 万以上ある merchant_id をそのまま扱うと One-Hot では列数が爆発し、Feature Store への登録やエンドポイントのペイロードが肥大化して P95 10 ms を超えやすくなります。ツリーベースの XGBoost は連続値のしきい値分割で学習するため、カテゴリを 1 列の数値に圧縮すればメモリもレイテンシーも大幅に抑えられます。

ターゲットの不正率に基づく手法は SageMaker Pipelines で時間分割を徹底しないとデータリークを招きやすく、Label Encoding は整数に序列を与えてしまうため高カードinalityでは木が深くなり推論メモリを消費します。出現頻度をそのまま数値化する方式なら統計量のみで安全に学習でき、推論時も軽量です。

AWS Glue で get_dummies して列爆発を起こす案を避けつつ、ターゲット情報に依存しない統計量ベースの変換を Data Wrangler で完結させれば、Feature Store のスキーマ、ネットワーク帯域、SageMaker エンドポイントのメモリを同時に最小化でき、リアルタイム要件と運用コストの両面で最もバランスが取れる選択となります。

ヒントボタン

Amazon SageMaker の Script モードでは、training や validation とは別に自由な input_channel を追加でき、埋め込みファイルを S3 から自動で /opt/ml/input/data/embeddings に配置後、TensorFlow 2.12 の学習スクリプトで os.environ[‘SM_CHANNEL_embeddings’] を通じて np.loadtxt で読み込み tf.keras.layers.Embedding(weights=[…], trainable=False) と設定すれば一度のロードで固定重みを適用できます。
Glue Data Catalog や Feature Store を使って単語ベクトルを API で逐次取得する方法はネットワーク I/O とサービス利用料金が学習ステップ毎に積み重なる一方、BlazingText supervised に切り替えるとアルゴリズム自体が FastText ベースに変わり TensorFlow Bi-LSTM のコードや評価指標を全面的に再設計する必要があり、運用コストと互換性の観点で不利になります。
要件は既存の TensorFlow 2.12 Bi-LSTM アーキテクチャを保ちつつ 550MB の word2vec 埋め込みを S3 から高速かつ一括で読み込み、推論時に更新しない形で再利用し追加課金を抑えることなので、SageMaker の追加 input_channel 機構を用いて学習ジョブ内で固定レイヤとして初期化するアプローチが最もシンプルかつ費用効率の高い総合解になります。

ヒントボタン

8列のカテゴリ列にユニーク値が最大200ある場合ワンホット後に1600特徴となり5000万行を密行列で扱うと膨大なメモリを要するため、Amazon SageMaker Processing で scikit-learn の OneHotEncoder を sparse=True で実行し疎行列を生成して LibSVM 形式で S3 に格納すれば組み込み XGBoost が直接読み込みつつメモリ消費を大幅に抑えられます。
Amazon SageMaker Pipelines では前処理を Processing ステップ、学習を Training ステップに分離するとキャッシュとリトライが効きコードをコンテナとして再利用できるため Notebook や Studio を常時起動する必要がなく、Data Wrangler の手動操作や AWS Glue での中間 Parquet 生成よりも自動再学習パターンに適合します。
S3 に日次追加される視聴履歴をメモリ効率良くワンホット化しNotebook を常駐させず再利用可能なジョブとして自動連鎖させるという複数要件を俯瞰すると、Processing で疎行列ファイルを作り XGBoost Training に受け渡すシンプルな二段構成が運用性と性能のバランスが取れた選択です。

ヒントボタン

Amazon SageMaker の組込み Image Classification アルゴリズムには、学習中にメモリ上で画像をランダムに変換できる機能があります。ハイパーパラメータ augmentation_type に crop, flip, rotation, scale などを指定するとミニバッチごとに回転や左右反転が適用され、S3 のオブジェクト数を増やさずに特徴量を拡張し過学習を抑制できます。設定はジョブ起動時に値を渡すだけなので前処理ジョブも追加ストレージも不要です。

torchvision.transforms を呼び出す PyTorch スクリプトや ECR へ独自コンテナを登録する方法でも同様のオーグメンテーションは実現できますが、イメージのビルドやCI/CD、バージョン管理といった運用負荷が増えがちです。SageMaker の組込みアルゴリズムなら転移学習用の事前学習モデルとオンザフライ変換が標準で使えるため、スタートアップの限られた開発リソースや時間を効率的に活用できます。

SageMaker Processing と AWS Glue DynamicFrame で画像を複製すると S3 ストレージコストが増え、Amazon Rekognition Custom Labels 経由ではワークフローが複雑化します。これらの選択肢と比較して、組込み Image Classification アルゴリズムの augmentation_type は学習バッチ内だけで変換を行うため余分な保存領域が不要です。コスト、運用工数、要件すべてを俯瞰すると、ハイパーパラメータでのオンザフライ拡張が最も合理的な判断となります。

ヒントボタン

大量画像を毎回ローカルにコピーすると転送待ちやディスク容量がボトルネックになるため、Amazon SageMaker の Pipe モードで S3 からストリーミング読み込みを行えば 1 TB 規模でもスタートアップが求める最小コストを維持でき、インスタンス起動直後からバッチ読み込みが走ることで GPU 使用率 90% 以上というパフォーマンス要件を継続的に満たしやすくなり、キャッシュが残らないので再学習時のストレージ課金も抑えられ、さらに File モードと比べてジョブ開始待機時間が短縮されるため実行料金の削減にもつながります。
画像を事前に全て変換して保存すると S3 コストが二重になり拡張パターンも固定されますが、PyTorch DataLoader で Albumentations を使い CPU 並列で 224×224 正規化やランダム回転・左右反転をオンザフライで行えば Amazon SageMaker Training の GPU パイプラインは常に新しいミニバッチを受け取れるため使用率低下を防げ、WeightedRandomSampler により 500 枚しかないクラスも 5,000 枚クラスと同等の頻度で学習されることで精度と汎化性能を両立でき、さらにエポックごとに変化するデータが過学習を抑制し Git 管理下で拡張ロジックの改善も簡単に反映できます。
月 2 回の再学習を手離れ良く回すには、GitHub や CodeCommit へのプッシュをトリガに AWS CodePipeline が Dockerfile 付きのリポジトリをビルドし Amazon ECR にプッシュ、そのイメージタグを指定して SageMaker Training ジョブを起動する CI/CD 流れを組むことで、ライブラリバージョンの差異や手動ビルドのミスを排除しながらビリングは学習時間分だけに限定でき、Pipe モード入力とオンザフライ前処理を組み合わせる構成がストレージ・運用・性能の複数要件をバランス良く満たす最適解になります。

ヒントボタン

ヒント 1
Amazon SageMaker の ProcessingStep で scikit-learn StandardScaler を学習して直ちに S3 へ保存し、そのまま公式 SKLearn コンテナと XGBoost コンテナを組み合わせた PipelineModel を生成すれば、学習・検証・バッチ・オンライン推論で完全に同じ平均と分散を再利用できます。マルチコンテナエンドポイントに載せることで前処理と推論を 1 ホップで連続実行でき、training-serving skew を防ぎつつコードはパイプライン定義だけに集約されます。さらに公式イメージを使うため独自 Docker の保守も不要で、1 TB を超えるデータでも分散前処理ジョブが自動スケールし運用負荷を大幅に削減できます。

ヒント 2
p99 50 ms を守るためにはネットワーク往復を極小化する構成が不可欠です。Amazon Feature Store でスケール済み特徴を取得したり、AWS Glue や Athena のマテリアライズドビューを挟んだり、API Gateway＋Lambda で前処理してから呼び出す方式は、いずれも二段リクエストやコールドスタートが加わり遅延が増えやすくなります。SageMaker のマルチコンテナなら CPU キャッシュ内で前処理と推論が完了しオーバーヘッドが最小化されます。また平均・分散を環境変数や日次 ETL で別管理にすると、データ分布が変わった際に CI/CD が二系統に割れて整合性リスクが高まるため、単一パイプラインで一貫管理できる構成が望ましいです。

ヒント 3
求められているのは ①学習・評価・バッチ・リアルタイム推論すべてで同一スケーリングを保証し、②CodePipeline からワンボタンで SageMaker Blue/Green デプロイを実行し無停止でエンドポイントを置換し、③p99 レイテンシ 50 ms をクリアし、④独自コンテナ開発や二重管理を避けて運用とコード量を最小化することです。これら複数要件を総合的に満たす設計として、ProcessingStep でスケーラーを学習し PipelineModel に前処理と XGBoost を束ねてデプロイするワークフローがベストプラクティスと言えるでしょう。

ヒントボタン

毎日自動実行されるSageMaker PipelinesのステージとしてAthenaの1TBデータを取り込み、Pearson相関ヒートマップで共線性を自動判定して特徴量を落とし、その後ろでSageMaker ClarifyがSHAP値を算出しPNGやCSVをS3へ保存する一連の流れをノーコードで構築できるのはGUIベースのData Wranglerだけであり、Pipeline用Python生成機能により追加運用コードをほぼ書かずに済み、さらにSparkバックエンドの並列処理で30分以内という制約もクリアしやすいです。
Glue DataBrewやQuickSightはプロファイリングやダッシュボード用途には適していますがSHAPのようなモデル解釈指標を直接計算できず、EMRやSageMaker Processingで自前スクリプトを組む方法はLambdaやStep Functionsなどの接着コードが増えて運用工数と30分制限リスクが高まりますし、金融SaaSの日次バッチではガバナンス観点から手動ノートブック運用を避けたいので、Clarifyを裏側で呼び出しつつGUIで完結できるData Wrangler単独構成がシンプルかつ信頼性が高いと考えられます。
処理時間30分以内・追加運用コード最小・Athena直接接続・相関除外とSHAP可視化・S3レポート保存・Pipelines自動エクスポートという複数要件を俯瞰すると、単一GUIで実装可能でSageMakerサービス群とネイティブ連携できるData Wranglerが最も整合的であり、サービス選定は一貫性と運用効率のバランスから総合判断することが重要です。

ヒントボタン

機械学習モデルで前処理と推論を切り離すと学習時の変換を本番で再現できず精度が落ちやすいです。Amazon SageMaker の Inference Pipeline を使えば PCA コンテナと XGBoost コンテナを同一エンドポイント内で直列実行でき、入力を 500 列のまま送りつつ即座に 300 次元以下へ圧縮できるため P99 30ms と 600TPS を両立しやすく追加インフラも最小化できます。

巨大な 1 億行×500 列の履歴に対し PCA を都度計算するとコストが跳ね上がりますが、SageMaker Pipeline の Processing ステップで一括計算し PCA モデルアーティファクトを Model Registry と Feature Store に登録しておけば再学習や A/B テストでも同じ変換を再利用でき、インスタンスメモリ不足と長時間学習の課題を恒常的に解消できます。

Glue ETL や Batch Transform はオフライン処理向けでレイテンシ要件に届かず、ハイパーパラメータ調整のみでは高次元によるリソース枯渇を完全には防げません。SageMaker Processing→Pipeline→Feature Store→Inference Pipeline というリアルタイムな一気通貫構成が、低コスト・高速推論・特徴量整合性の複数要件を俯瞰した総合判断として最も妥当です。

ヒントボタン

学習は月に一度だけ、インスタンスは使う時だけ立ち上げたいという条件では、ジョブ終了後に自動でリソースが解放される Amazon SageMaker の組み込み PCA が適しています。randomized モードは 10,000 次元×数億レコードの計算を近似計算で高速化し、コストを大幅に抑制できます。データは Amazon S3 から直接読み書きでき、コピーや常時クラスター維持の費用も不要です。

推論が 1 日 1 回のバッチで足りる場合は、常時起動するリアルタイムエンドポイントより SageMaker Batch Transform の一括推論が好相性です。バッチ実行時だけインスタンスを確保し、終了後は課金が停止するためコスト最小化に寄与します。入力は S3、出力も S3 に 50 次元へ変換した結果を保存でき、IAM ロールで権限管理も一元化できます。

変換後データを Parquet 形式で Amazon S3 に置けば列指向圧縮でストレージ費も抑えられ、SageMaker Processing、Athena、AWS Glue など複数ジョブから直接再利用できます。月次学習・日次バッチ・エンドポイント不要・再利用可能フォーマットという要件を総合的に眺めると、オンデマンド学習の組み込み PCA と Batch Transform の組み合わせが最も整合します。

ヒントボタン

Amazon SageMaker Processing の組み込み PCA を利用して 5,000 列を 50 程度の主成分に線形圧縮し、変換行列をモデルアーティファクトに含めて推論時に逆変換用として読み込み SHAP が各元特徴の寄与を計算できるようにしておくと、ml.m5.2xlarge の 16 GiB 制約内での学習と既存エンドポイントの維持が同時に叶い、Processing はフルマネージドなので追加クラスター運用も不要です。
Data Wrangler で Z スコア正規化だけを行っても列数は 5,000 のままなのでデータサイズはほとんど減らず、メモリ不足を避けるには ml.m5.4xlarge などへスケールアップするしかなくなりますが、高スペックインスタンスを新たに導入しないという制約とコスト効率の観点からは、計算量を減らす次元削減の施策とフルマネージドな実行環境を組み合わせる案と比べて再考の余地があります。
総学習時間 30 分以内・メモリ 16 GiB 以内・既存 ml.m5.large の活用・SHAP による元特徴寄与の可視化・運用負荷最小化という複数条件を俯瞰すると、Amazon SageMaker Processing などネイティブサービスでの次元削減とアーティファクト一体化で推論時に復元まで自動化するアプローチが総合的に最も要件整合的に映ります。

ヒントボタン

Amazon S3 に置いた数 TB 規模の画像を毎秒 2,000 枚で学習ロジックへ流し込むには SageMaker Pipe mode でコンテナにストリーミングする方法が推奨であり、ジョブ開始時に全データをローカルへコピーする File mode や EC2+EBS 構成では I/O 帯域と起動待ち時間が増えて GPU が遊ぶ恐れがあります。
画像を水平方向反転やランダムクロップで増強する場合、SageMaker の組み込み Image Classification アルゴリズムは horizontal_flip や random_crop などのハイパーパラメータを指定するだけで GPU 上でオンザフライ変換でき、S3 に膨大な複製ファイルを保存せずにストレージコストと処理時間を抑えられます。
ハイパーパラメータ・入力チャネル・コンテナイメージが自動で Amazon S3 と CloudWatch Logs に記録される SageMaker マネージドトレーニングを採用すれば実験の再現性が確保でき、得られたモデルアーティファクトをそのまま SageMaker エンドポイントへ展開できるため、高スループット取り込み・低コスト増強・再現性・運用効率という複数要件を総合的に満たす構成となります。