AWS構築をコーディングエージェントで自動化する「Agent Plugins for AWS」——deploy-on-awsが変える開発現場
コーディングエージェントにAWSの設計・デプロイ・運用スキルを与えるオープンソースのプラグイン集「Agent Plugins for AWS」が、2026年2月にAWSから発表された。その最初の汎用プラグイン「deploy-on-aws」の仕組みと実力をNTTデータのエンジニアが検証した記事が公開されている。
出典: AWS構築をコーディングエージェントから自動化!? Agent Plugins for AWS「deploy-on-aws」の仕組みと実力を検証
要点 (事実のみ)
- Agent Plugins for AWSは2026年2月17日に発表されたオープンソースのエージェントプラグイン集。skills / MCP servers / hooks / references を束ねて構成される
- 最初に公開されたプラグイン「deploy-on-aws」は、Analyze→Recommend→Estimate→Generate→Deployの5段階ワークフローで既存アプリケーションをAWSにデプロイする流れを支援する
- 主要なMCPサーバーとして awsknowledge・awspricing・aws-iac-mcp の3つが挙げられており、最新の公式データを踏まえた推論を可能にする
- Amazon QやKiroなど既存AIサービスとの違いとして「設計判断の基準を構造化された構築フローとして標準化・バージョン管理できる点」が挙げられている
- 発表記事での位置づけは「構築を加速するためのアクセラレータ」であり、生成されたIaCのレビューと手直しを前提とした利用が推奨されている
徐 聖博の見解
私が注目したのは「単発プロンプト＋モデル知識に依存した推論」との決別を明示している点だ。Amazon QやKiroでもAWSのインフラ自動化は既にできる。しかしdeploy-on-awsのアプローチは、設計判断の根拠をreferencesとして外部ファイルに切り出し、ワークフロー単位でバージョン管理できる構造になっている。これは「AIが何を根拠に判断したか」を後から追跡・改訂できるという点で、プロダクション運用の文脈では本質的に違う。
私たちのチームはAWSを主力クラウドとして受託開発案件に使っている。IaCの生成自体はすでにAIが補助しているが、「なぜそのサービスを選んだか」「コストの見積もりはどの前提に基づくか」がブラックボックスのまま納品物に入ってくることへの不安は常にある。deploy-on-awsのreferencesの仕組みは、その判断プロセスを人間がレビュー可能な形式に落とし込もうという試みとして理にかなっている。
一方で、記事が「レビューと手直しを前提」と明言している通り、IaCをそのまま本番に流す用途には今すぐ適さない。特に権限設計とセキュリティチェックは、MCPサーバーが最新ドキュメントを引いてくるとしても、ターゲット環境の要件と突き合わせる人間の目が依然として必要だ。受託案件でこのプラグインを使うとすれば、「調査・推奨・見積もり」の上流3ステップの品質底上げに使い、GenerateとDeployはエンジニアが引き継ぐ分担が現実的だと私は判断する。
もう一点、オープンソースとして公開されている点も重要だ。社内独自のベストプラクティスをreferencesに書き足せば、プラグインを組織のナレッジ基盤として育てられる。これは採用・育成の観点でも効く——インフラ経験が浅いメンバーが「なぜこの設計か」を学ぶ足場として機能しうるからだ。
(編集レンズ: 実装・運用視点 / 発注側・中小企業・開発実務への含意)
