9月19日、AWSが「Deploy Hugging Face models on Amazon SageMaker AI with coding agents」と題した記事を公開した。この記事では、KiroやClaude Codeといったコーディングエージェントに6つのオープンソーススキルを組み込み、Hugging FaceモデルをSageMaker AIへ本番品質でデプロイする手順について詳しく紹介されている。コーディングエージェントがモデルデプロイで失敗し続ける根本原因は「推論能力の欠如」ではなく「デプロイに必要な最新の事実知識がない」ことだ——AWSはその問題を、エージェントに外部の知識を注入する「スキル」という仕組みで解決した。

「エージェントに任せれば動く」が成立しない理由

コーディングエージェントにモデル名を伝えるだけでエンドポイントが立ち上がると想像しがちだが、実際はそうならない。AWSの検証では、KiroとClaude Codeの両エージェントに対して「Qwen/Qwen3-0.6BをSageMakerのリアルタイムエンドポイントにデプロイせよ」と指示したところ、両エージェントともに真っ先にTGI（Text Generation Inference）を選択した。

TGIは長年のデファクトだったため、学習データにTGIを使うチュートリアルが大量に含まれている。しかし当該リージョンで利用できたTGIのビルドはQwen3のアーキテクチャに対応しておらず、ヘルスチェックが失敗。エージェントはTGIのバージョンを上げて再デプロイ、また失敗、そしてvLLMへ切り替え、という流れをたどった。この間、起動しては落ちるたびにGPUの課金が発生している。

2つ目の検証はより静かに失敗した。テストの数週間前にリリースされたばかりのマルチモーダルMoE拡散モデルをデプロイするよう指示したところ、エージェントはモデルの存在を確認した上でTGIベースのスクリプトを書いた。TGIは離散拡散の画像テキストモデルに対応していないため、エンドポイントは起動を拒否するまで何も警告を出さない。

根本原因は推論能力の欠如ではなく、デプロイに必要な最新の事実知識がないことだ。「Qwen3にはvLLMが必要」「Python 3.13はMLスタックの多くでwheelが存在しない」「コンテナイメージはAWS DLC（Deep Learning Containers）カタログから取得すべき」——こうした知識はモデルの重みが更新されるよりも速く変化する。エージェントはモデルが存在することは知っていても、「そのモデルを今日動かすための正しい組み合わせ」を知らない。

6つのスキルで何が変わるか

Hugging Face Skills GitHubリポジトリから6つのスキルをインストールすることで、エージェントの動作が変わる。スキルはSKILL.mdファイルを含むフォルダという形式のオープン標準パッケージで、エージェントはタスクの内容に応じて必要なスキルをオンデマンドで読み込む。

hf-cloud-sagemaker-deployment-planner（全体を統括）
│
├── hf-cloud-aws-context-discovery（AWSコンテキストの検出）
├── hf-cloud-python-env-setup（Pythonの分離環境構築）
├── hf-cloud-sagemaker-iam-preflight（実行ロールの確認）
├── hf-cloud-serving-image-selection（コンテナ選定とイメージURIの解決）
└── hf-cloud-sagemaker-production-defaults（オートスケーリング・CloudWatchアラームの設定）

スキルなしとスキルありの比較を元記事のTable 1から引用する。

失敗→スキル導入→解決という流れで見ると、スキルの役割は「エージェントに正しい選択肢を与えること」と「本番運用に必要な設定を強制すること」の2点に集約される。

特に重要なスキル：コンテナ選定とIAMロール

hf-cloud-serving-image-selection は、エラーメッセージとして現れる「Failed to pass health check」を事前に防ぐためのスキルだ。SKILL.mdには「TGIをデフォルトにしてはならない」「コンテナURIをハードコードしてはならない」と明示されており、Hugging Face提供のvLLM / vLLM-Omni / TEI（Text Embeddings Inference） / HF Inference Toolkitを優先し、互換性がない場合のみAWS vLLMやDJL-LMI（Deep Java Library - Large Model Inference）といった汎用イメージを使うよう指示している。

実際のデプロイログでは、Qwen3-0.6Bに対して以下のイメージが解決された。

763104351884.dkr.ecr.us-east-1.amazonaws.com/huggingface-vllm:0.28.0-transformers5.15.0-gpu-py312-cu130-ubuntu24.04

このURIはAWS DLCカタログから動的に解決されており、ハードコードではない点が重要だ。カタログが更新されれば、スキルを通じてエージェントも最新イメージを参照できる。

hf-cloud-sagemaker-iam-preflight は、企業アカウント特有の問題（AWS IAM Identity Centerセッションにiam:CreateRole権限がない）への対処として設計されている。「まず既存ロールを探す、作成は最終手段」という順序で動作し、AmazonSageMaker-ExecutionRole-*や*SageMaker*Execution*といったパターンにマッチするロールを最終使用日順にランク付けして返す。なお、スキルがロールを新規作成する場合はAmazonSageMakerFullAccessが付与されるため、最小権限の原則に従い権限を絞ることが推奨されている。

セットアップ手順

前提条件は以下の通り。

• SageMaker AIを利用できるAWSアカウント
• AWS CLI v2（認証情報設定済み）
• Python 3.10〜3.12（3.13以降はMLスタックのwheelが未対応のため非サポート）
• スキルに対応したコーディングエージェント（記事ではKiro IDEを使用）
• Git

スキルのインストールは、Kiroのチャットに以下を貼り付けるだけだ（コミットSHAを固定している点に注意）。

Install six agent skills from the huggingface/skills repo, pinned to commit
f3186efbbc322121eb5d0f31e8a1d669ee961159, into this workspace.
Source: https://github.com/huggingface/skills.git

インストール後、チャットで/を入力するとスキルがスラッシュコマンドとして表示される。

デプロイ自体は自然言語で指示するだけでよい。エージェントはまずデプロイ計画をファイルに書き出してユーザーの承認を待つ。課金が発生するリソースの作成はその後だ。記事の例ではml.g5.xlargeインスタンス1台にQwen3-0.6BをUS East（N. Virginia）リージョンへデプロイしている。リアルタイムエンドポイントはトラフィックがなくても継続課金されるため、使用後はティアダウンが必要だ。

対応しているデプロイモードは、リアルタイム（デフォルト）のほか、スケールトゥゼロ対応リアルタイム、サーバーレス推論、非同期推論、バッチ変換、Amazon Bedrock Custom Model Importと幅広い。

詳細はDeploy Hugging Face models on Amazon SageMaker AI with coding agentsを参照していただきたい。