AWSのAIツール ― Claude Code拡張機能 × IAM Policy Autopilot × Agent Pluginsを試してみた

はじめに

エブリーでデリッシュキッチンの開発をしている本丸です。
日頃の業務でClaude Codeを活用しているのですが、AWSからリリースされたAIツール群（IAM Policy Autopilot、Agent Plugins for AWS）がClaude Codeと連携できることを知り、社内勉強会を機に実際に試してみました。
本記事では、これらのツールの概要と、素のLLMに指示した場合と専用ツールを使った場合でどのような違いが出るのかを4つのシナリオで比較した結果をまとめます。

IAM Policy Autopilot

概要

IAM Policy Autopilotは、AWS re:Invent 2025で発表されたオープンソース（Apache 2.0）のツールです。ソースコードを静的解析し、最小権限のIAMポリシーを自動生成します。

対応言語はPython / TypeScript / Goで、CLI / MCPサーバーの両方で利用できます。

仕組み

特筆すべきはLLMを使用しない決定論的な静的解析である点です。Rust製のAST解析エンジン（ast-grep）がSDK呼び出しを検出し、IAMアクションにマッピングします。同じコードからは常に同じポリシーが生成されるため、再現性があります。

ソースコード
  ↓ AST解析（ast-grep）
SDK呼び出しを検出
  ↓ IAMアクションにマッピング
IAMポリシーJSON生成

主要機能

コマンド	用途
generate-policies	ソースコード解析からIAMポリシー生成
fix-access-denied	AccessDeniedエラーメッセージから修正ポリシー生成

Agent Plugins for AWS

概要

Agent Plugins for AWSは、2026年2月にAWS Labsからリリースされたプラグイン群です。AIエージェントにAWSの設計・構築・運用スキルを付与します。

利用可能なプラグイン

プラグイン	用途
aws-serverless	Lambda / API Gateway / EventBridge
deploy-on-aws	アーキテクチャ推奨 / コスト見積もり / IaC生成
databases-on-aws	Aurora DSQL含むDB設計ガイダンス
aws-amplify	Amplify Gen 2 フルスタックアプリ構築
amazon-location-service	マップ / ジオコーディング / ルーティング
migration-to-aws	GCPからAWSへの移行支援

deploy-on-aws の5段階ワークフロー

deploy-on-awsプラグインは、以下の5段階のワークフローでプロジェクトのデプロイを支援します。

1. Analyze → 2. Recommend → 3. Estimate → 4. Generate → 5. Deploy
（解析）     （推奨）       （試算）       （生成）      （デプロイ）

各フェーズでは、ワークフローを主導するSkillと、外部データを参照するMCPサーバー（awsknowledge, awspricing, aws-iac-mcp）、さらにIaC検証を自動実行するHooksが組み合わさって動作します。これにより、最新のAWSドキュメント・料金情報・IaCベストプラクティスを参照しながら一貫したプロセスで進行します。

素のLLMに指示する場合の課題

これらのツールを使わず、素のLLMに直接指示した場合には以下のような課題があります。

• 学習データの鮮度: 知識カットオフ以降のAPI変更・新サービスに非対応
• ハルシネーション: 存在しないAPIパラメータやサービス名を生成するリスク
• 一貫性の欠如: 毎回異なるアプローチ・構成を提案する可能性
• 検証手段がない: 生成されたポリシーやIaCの正しさを確認できない

一方、ツールを利用すると以下の改善が得られます。

• 最新情報の参照: MCPサーバー経由でリアルタイムにAWSドキュメント・料金を参照
• 構造化プロセス: 明確なワークフローにより一貫した品質を実現
• 最小権限の原則: 自動的に最小権限を適用、ベストプラクティスに基づく設計

比較シナリオ

ツールを使うと実際どれくらい差分が出るのかが気になったので、AWS開発でよく遭遇しそうな場面をAIに挙げてもらい、以下の4つのシナリオを用意して比較しました。各シナリオで素のLLMと専用ツール付きに対して同じプロンプトを渡し、出力を見比べています。

• シナリオ1: Lambda関数のIAMポリシー作成（IAM Policy Autopilot）
• シナリオ2: サーバーレスREST APIの構築（aws-serverless Plugin）
• シナリオ3: AccessDeniedエラーの解決（IAM Policy Autopilot）
• シナリオ4: AWSへのデプロイ設計（deploy-on-aws Plugin）

シナリオ1：Lambda関数のIAMポリシー作成

S3からファイルを読み取り、DynamoDBに書き込むLambda関数に必要な最小権限ポリシーを作成するシナリオです。

対象コード

import boto3

s3 = boto3.client('s3')
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('my-data-table')

def handler(event, context):
    bucket = event['bucket']
    key = event['key']

    response = s3.get_object(Bucket=bucket, Key=key)
    data = response['Body'].read().decode('utf-8')

    table.put_item(Item={
        'id': key,
        'content': data,
        'source_bucket': bucket
    })

    return {'statusCode': 200, 'body': 'Success'}

ツール利用時は「IAM Policy Autopilotのgenerate_application_policiesツールを使って」と追加で指示しました。

結果比較

項目	素のLLM	IAM Policy Autopilot
S3アクション	GetObjectのみ	GetObject + LegalHold + Retention + Tagging + Version + ObjectLambda
DynamoDBアクション	PutItemのみ	PutItem + WriteDataForReplication
KMS暗号化	なし	S3・DynamoDB向け kms:Decrypt（条件付き）
CloudWatch Logs	含む（推測で追加）	含まない（サービスロールに委任）

IAM Policy Autopilotは暗号化・バージョニング・Access Point等、本番運用で必要になる権限を網羅的にカバーしています。素のLLMが推測ベースで生成したのに対し、IAM Policy AutopilotはAST解析によりget_object()とput_item()の呼び出しを検出し、関連する権限を自動的に追加しました。
一方で、IAM Policy Autopilotの出力はKMS暗号化やAccess Pointなど実際に使っていない権限まで含まれるため、過剰な権限にならないよう利用するリソースに合わせてレビューすることは必要そうです。

シナリオ2：サーバーレスREST APIの構築

ユーザー情報のCRUD APIをLambda + API Gateway + DynamoDBで構築するシナリオです。
ツール利用時はaws-serverlessプラグインのMCPサーバーを利用しました。

結果比較（template.yaml）

項目	素のLLM	aws-serverless Plugin
Lambda関数数	1（ルーターパターン）	5（操作ごとに分離）
IAMポリシー	全操作にDynamoDBCrudPolicy	Read → ReadPolicy / Write → CrudPolicy（粒度分離）
CPUアーキテクチャ	x86_64（デフォルト）	arm64（コスト最適化）
トレーシング	なし	Tracing: Active（X-Ray）

ツール利用時は5回のMCP呼び出しが行われました。最初のget_serverless_templatesでは条件が具体的すぎて失敗しましたが、エージェントが自動で条件を緩めて再試行する適応的な動作が見られました。最後にvalidate_cloudformation_templateでテンプレートの妥当性検証も実施されています。
興味深かったのは、aws-serverless Pluginが単一のLambda関数ではなく、CRUD操作ごとに5つに分割した関数を生成した点です。これは最小権限の原則を徹底するためで、Read系の関数にはDynamoDBReadPolicy、Write系の関数にはDynamoDBCrudPolicyと、操作ごとに必要最低限のIAMポリシーだけを付与できるようにするための構成だと考えられます。単一関数にするとどうしてもCRUD全ての権限を付けざるを得ないため、関数を分割することで権限分離をしっかり行うベストプラクティスが反映されているようでした。

シナリオ3：AccessDeniedエラーの解決

Policies: []でDynamoDB権限を付け忘れたLambdaのAccessDeniedエラーを解決するシナリオです。
ツール利用時はIAM Policy Autopilotのgenerate_policy_for_access_deniedツールを利用しました。

注：実際にAWS上へリソースを作成して再現したわけではなく、あらかじめ用意したエラーメッセージ（JSON）とLambdaコード・SAMテンプレートを入力として渡し、修正ポリシーがどのように生成されるかを確認しています。

エラーメッセージ

{
  "statusCode": 500,
  "body": "{\"error\": \"AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/scenario3-data-writer-role/scenario3-data-writer is not authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:ap-northeast-1:123456789012:table/scenario3-data-table\"}"
}

結果比較

項目	素のLLM	IAM Policy Autopilot
原因特定	正しく特定	正しく特定
ポリシーJSON	一般的な記述（アカウントIDなし）	完全修飾ARN（リージョン+アカウントID）
検証手順	なし	sam build → sam deploy → テストの手順を提示

どちらも根本原因（Policies: []）は正しく特定できました。差が出たのはポリシーの精度で、IAM Policy AutopilotはエラーメッセージからアクションとリソースARNをパースし、ピンポイントの修正ポリシーを生成しました。

シナリオ4：AWSへのデプロイ設計

Express.js（PostgreSQL / Redis / WebSocket / 画像アップロード）アプリケーションのAWS構成設計とコスト見積もりを行うシナリオです。
ツール利用時はdeploy-on-awsプラグインのMCPサーバー（awsiac + awspricing）を利用しました。

アーキテクチャ比較

項目	素のLLM	deploy-on-aws Plugin
NAT Gateway	あり（$36/月）	なし（Public Subnet + Public IP）
RDS構成	Multi-AZ（高可用性）	Single-AZ（コスト重視）
Fargate	512 CPU / 1024 MB × 2タスク	256 CPU / 512 MB × 1タスク（ARM64）
セキュリティ	標準的	enforceSSL, allowAllOutbound: false
設計方針	可用性・冗長性重視	コスト効率重視（必要十分）

コスト比較

サービス	素のLLM	deploy-on-aws Plugin	差
ECS Fargate	$29.55	$8.99	-70%
ALB	$22.40	$20.66	-8%
RDS PostgreSQL	$27.36	$20.55	-25%
ElastiCache Redis	$11.68	$18.25	+56%
NAT Gateway	$36.14	$0	-100%
合計	≈$134/月	≈$71/月	-47%

ElastiCache Redisのようにdeploy-on-aws側の方が高くなる項目もありますが、NAT Gatewayの削除やARM64採用などのコスト最適化により全体では約半額に収まっています。

ツール利用時は14回のMCP呼び出しが行われましたが、その中で試行錯誤も発生しました。たとえばECS Fargateの料金取得でフィルタが不正だったり、ALBのサービスコード名がAPI正式名称（AWSELB）と異なるためにエラーになったりと、エージェントがget_pricing_service_codesで正しいコードを探索する過程が見られました。

/deploy Skill による実行

シナリオ4を/deployスラッシュコマンドでも実行してみました。Skillが5段階のワークフローを主導し、各フェーズで選定理由をテーブルで明示するなど、よりプロセスの透明性が高い出力が得られました。

注：/deployは最後にAWSへ実際にデプロイするステップまで含むワークフローですが、今回はAnalyze → Recommend → Estimate → GenerateまでのIaCコード生成フェーズで停止させ、実際のデプロイは行っていません。

3方比較

観点	素のLLM	MCP直接	/deploy Skill
正確性	一般知識に基づく推測	静的解析・API参照で裏付けあり	同左 + 構造化ワークフローで漏れを防止
コスト	冗長性重視で高コスト（≈$134/月）	リアルタイム料金でコスト最適化（≈$71/月）	コスト最適化 + 代替案の差額も提示（≈$87/月）
プロセス	Read/Writeのみ	MCP呼び出し多数	Skill + MCP + cdk synth検証ループ

まとめ

今回はIAM Policy AutopilotとAgent Plugins for AWSを実際に使い、素のLLMとの出力の違いを4つのシナリオで比較してみました。

全体を通して感じた共通する価値は以下の点です。

• 最新のAWS情報に基づいた提案: MCPサーバー経由でリアルタイムにドキュメント・料金を参照するため、知識カットオフの影響を受けない
• 実コード解析による根拠ベースの出力: 推測ではなく、AST解析やAPI参照に基づくため信頼性が高い(IAM Policy Autopilotの特徴)
• 構造化ワークフローによる一貫した品質: 毎回同じプロセスで進行するため、出力のばらつきが少ない
• 最小権限・ベストプラクティスの自動適用: ARM64、関数分離、権限の粒度分離などが自動で適用される

一方、ツールがあればすべて完璧というわけではなく、料金取得の試行錯誤やテンプレート検索の条件調整など、エージェントが適応的に動作する場面も多く見られました。また、静的解析ベースのIAMポリシー生成では実際に使わないリソースへの権限まで含まれる場合があるため、生成されたコード・ポリシーは必ず人間がレビューしてからデプロイすることが重要です。

今回のように素のLLMとの出力差分を実際に確認してみると、ツールがどのような前提・ベストプラクティスに基づいて出力を生成しているかを把握することの重要性も感じました。便利だからと漫然と使うのではなく、ツールを導入することで何が変わるのか・どこまで任せられるのかをきちんと理解した上で、日々の開発に取り入れていきたいと思います。

参考文献

• IAM Policy Autopilot - GitHub
• Simplify IAM policy creation with IAM Policy Autopilot, a new open source MCP server for builders | AWS News Blog
• Agent Plugins for AWS - GitHub
• Introducing Agent Plugins for AWS | AWS Developer Tools Blog