「コーディングエージェントにAWSを触らせる」と聞くと、まず身構える人が多い。私もそうだった。ルート権限に近いキーを渡すのが怖い。ところが2026年5月6日、AWSが自社のMCPサーバーを正式版(GA)にした。設計を見て、その身構えが少しほどけた。鍵を渡すのではなく、IAMの枠の中で動かす発想だったからだ。
「ツールを増やす」のではなく「ツールを減らした」設計
面白いのは、提供されるツールの数が極端に少ないことだ。普通こういうサーバーは「EC2用」「S3用」と機能ごとにツールが増殖していく。AWS MCP Serverは逆を行った。中心にあるのは call_aws というたった一つのツール。これが15,000を超えるAWS APIオペレーションを、手元のIAM認証情報を使って実行する。
加えて search_documentation と read_documentation の二つ。クエリ時点で最新のAWSドキュメントを引いてくるので、エージェントが古い仕様を前提に動く事故が減る。ツールの少なさは、エージェントの「迷い」を減らすという意味でもある。選択肢が多いほど、LLMは間違った道具を掴む。これはVim時代に、プラグインを増やしすぎて起動が重くなった頃の教訓と構造が似ている。
なぜ「一本に集約」が効くのか。AWSのAPIは15,000以上ある。これを個別ツールとして並べたら、エージェントのコンテキストはツール定義だけで溢れる。トークンも食う。call_aws はオペレーション名と引数を受け取る薄い窓口に徹し、実際の意味付けはエージェント側の推論に委ねた。窓口は一つ、奥行きは無限。この割り切りが、私には妙に潔く見えた。
公式の発表によれば、これは2026年5月6日に正式版となった。プレビュー段階から触っていた人の評判は悪くなかったが、GAになって本番運用の俎上に乗せやすくなったのが大きい。
実際に試した結果:Claude Codeから既存スタックを棚卸し
手元のClaude Codeに繋いで、まず無害なところから試した。「このアカウントで動いているLambda関数を、メモリ設定とランタイム別に一覧化して」と頼んだだけ。
エージェントは call_aws 経由で ListFunctions を叩き、ページネーションを自分で処理し、表にまとめてきた。私が手でCLIを並べていたら、たぶん10分はかかる。実測で2分とちょっと。リージョンをまたいだ集計を追加で頼んでも、嫌な顔ひとつせず回してくれた。
正直なところ、最初の数回は「本当にread系で止まってくれるのか」が気になって、CloudTrailを別タブで睨んでいた。余計な書き込みは飛んでいなかった。権限の境界がIAM側にあるので、エージェントの暴走をこちらの設定で縛れる。この安心感は大きい。
もう一歩踏み込んで、search_documentation の挙動も試した。「Aurora Serverless v2 の最小ACU設定の推奨値は」と尋ねると、エージェントは記憶の中の古い数字ではなく、その場でドキュメントを引いて答えた。AWSは仕様の更新が速い。学習時点の知識を信じて回答するLLMの弱点を、ドキュメント直結で塞ぐ発想だ。地味だが、本番設計の相談相手としての信頼度がここで一段上がる。
サンドボックスでPythonを回す、という新機能
GAで追加された目玉が、サンドボックス内でのスクリプト実行だ。エージェントが複数ステップの操作をPythonで書き、それをAWSサービスに対して実行する。しかも、こちらのローカルファイルシステムやシェルには触れない。
これが効くのは「APIを3回叩いて結果を突き合わせる」みたいな、一発のAPIでは終わらない作業のとき。たとえば、あるS3バケット群のサイズを集計してコスト試算まで出す、といった処理。従来はエージェントに長いツールチェーンを組ませる必要があった。今は「スクリプトを書いて回す」という人間に近い手順で片付く。
Agent Toolkitの一部、という位置づけ
このMCPサーバーは単体ではなく、AWSが同時に出した「Agent Toolkit for AWS」の中核として置かれている。IaC、ストレージ、分析、サーバーレス、コンテナ、AIサービスにまたがって40以上のスキルが用意された。
個人的には、スキルの数より「公式が責任を持って配る」点に意味があると思っている。野良のMCPサーバーをcloneして使うのは、認証情報を扱う以上どうしても怖い。提供元がAWS本体なら、少なくとも信頼の出発点が変わる。CursorでもKiroでもCodexでも、MCP対応のエージェントなら同じ口から繋げるのも地味に大きい。
スキルというのは、特定領域の作業手順をエージェントに渡す仕組みだ。たとえば「IaCでVPCを切る」一連の流れを、いちいち指示しなくても呼び出せる。40という数は今後さらに増えるだろう。ただ、私は最初から全部使う気はない。自分の業務で頻出する数個だけ拾えば十分だと思っている。道具は多ければいいわけではない、というのは冒頭の話と同じだ。
結論:権限設計を「エージェント前提」で見直す合図
このGAで一番変わるのは、ツールそのものより私たちの権限設計の発想だと思う。これまでは人間が使う前提でIAMを切っていた。これからは「エージェントがこの範囲で動く」という前提で、最小権限のロールを一つ余分に用意しておく。読み取り専用ロールを一本作って、まずそこにエージェントを閉じ込める。慣れたら書き込みを足す。
派手な新モデルの発表ではない。けれど、運用の現場をじわじわ変えるタイプの更新だ。次に触るなら、本番ではなくサンドボックスアカウントから。これだけは強く勧めておく。
最後に一点。便利さに引きずられて、いきなり広い権限を与えないこと。エージェントは指示を素直に実行するが、その素直さが裏目に出る場面もある。読み取りで十分な調査なら読み取りロールで。書き込みが要る作業に進むときだけ、明示的に権限を足す。手間に見えて、これが一番安全で、結局は速い。新しい道具を信じすぎないことも、新しい道具を使いこなす一部だと思う。
