Claude Codeのaws-coreプラグインでIaC・CDK・IAMのskillsを使う

aws-coreは、AWSが公開する「Agent Toolkit for AWS」の中心にあるプラグインです。/plugin installの1回で、AWS MCPサーバーの設定、25個のskill、Secrets Managerの値を直接読ませないフックがClaude Codeに入ります。この記事では、IaC(CDKとCloudFormation)とIAMに関わるskillが何を守らせてくれるのか、入れる前に知っておく食い違い、デプロイを人の承認に残す設定を順に扱います。

aws-coreに入るのは、MCPサーバー・skill・フックの3種類

プラグインの構成は、リポジトリのplugins/aws-coreで見られます。Claude Code向けに効くのは次の3つです。

README上の位置づけは「Start here」、つまりツールキットの入口です。ほかにAI基盤向けのaws-agents、データ分析向けのaws-data-analyticsなどがありますが、IaCとIAMはaws-coreが担当します。

導入手順

Claude Codeには公式マーケットプレイスclaude-plugins-officialが最初から登録されているため、マーケットプレイスの追加は要りません。

/plugin install aws-core@claude-plugins-official
/reload-plugins

Plugin not foundと出るときは、ローカルのマーケットプレイス索引が古い状態です。先に索引を更新します。

/plugin marketplace update claude-plugins-official

動かすのに手元で要るものは、次のとおりです。

• uv: MCPサーバーがuvxで起動します
• python3: フックがpython3、python、py -3の順に試して実行します
• AWSの認証情報: call_awsでAPIを叩くときに要ります。ドキュメント検索とskillの取得は認証なしで使えます

uv --version
python3 --version
aws sts get-caller-identity

3行目が通らなくても、skillを読ませてテンプレートを書かせるところまでは進みます。AWSの環境に書き込む段階で初めて認証が必要になります。

skillの数は、見る場所で食い違う

「何個のskillが入るのか」は、READMEと実体で揃っていません。入れる前に、読み込まれるものを手元で確かめるほうが確実です。

READMEの表に載らず、ディレクトリにだけ存在するものに、aws-iamとlaunch-with-awsがあります。この記事が主題にするIAMの手順書は、READMEだけを見ると入っていないように読めます。名前も食い違っているので、/aws-cdkのように名前を指定して呼ぶ運用は、手元の一覧で実名を確認してからにします。

CDKのskillは、事故になりやすい操作を先に警告する

aws-cdkは、CDKのTypeScriptとPythonでの構築・デプロイ・トラブル対応を扱います。対象外は、素のCloudFormation、SAM、Terraform、Pulumiです。

中心にあるのは「Critical Warnings」です。実際の運用で事故につながる5つの落とし穴が、冒頭に置かれています。

デプロイの定型は、cdk synth --strict、cdk diff、cdk deployの順です。skillは本番へのデプロイ前に必ずdiffを挟むよう書いています。

この方針をClaude Code側の設定でも固定しておくと、skillの文面頼みにならずに済みます。次は、デプロイを承認制に残し、破壊的な操作を止める設定の一例です(AWSの配布物ではなく、この記事での例示です)。

{
  "permissions": {
    "ask": [
      "Bash(cdk deploy *)",
      "Bash(aws cloudformation create-stack *)",
      "Bash(aws cloudformation update-stack *)"
    ],
    "deny": [
      "Bash(cdk destroy *)"
    ]
  }
}

コマンド文字列の一致で止める方式は、書き方を変えた呼び出しをすり抜けます。CDKのskillも、本番での禁止はIAMと監視で強制する内容を別の参照資料に置いています。権限の最後の砦はAWS側のIAMに置き、Claude Codeの設定は手前の確認として使う分担が現実的です。CDKの実装フロー自体はClaude CodeでAWS CDKスタックを書くが詳しく、CloudFormationの検証をMCPで行う道はaws-iac-mcp-serverの使い方にあります。

CloudFormationのskillは、検証の順序とテンプレートの書き方を決める

aws-cloudformationは、テンプレートの作成、デプロイ前の検証、失敗したスタックの原因調査までを扱います。CDKではなくYAML・JSONのテンプレートを直接書く場面の担当です。skill内の使い分け表も、既存のテンプレートがYAML・JSONでリソース数が50未満のシンプルな構成ならCloudFormation、再利用できる抽象化が効くならCDKを勧めています。

テンプレートに入れさせる既定値

skillが「特別な理由がなければ適用する」とする既定値は、次のとおりです。

• S3バケット: パブリックアクセスブロック(4項目すべて有効)、暗号化、バージョニング、aws:SecureTransportによる非HTTPSの拒否
• ステートフルなリソース: DeletionPolicyとUpdateReplacePolicyにRetain
• 物理名の固定は避け、!Sub "${AWS::StackName}-..."で一意にする
• シークレットを平文のStringパラメータに置かず、Secrets ManagerかSSM SecureStringの動的参照を使う

Metadataに書かれる意図と識別マーカー

見落としやすい挙動が2つあります。skillは、リソースを追加・変更するたびに、設計の意図(why)と守るべき制約(must)を各リソースのMetadataのcom.aws.cloudformation.Contextキーに残すよう求めます。さらに、作成・変更したテンプレートの先頭にAWSToolsMetrics.AWSAgentToolkitのマーカーを入れます。

Metadata:
  AWSToolsMetrics:
    AWSAgentToolkit: aws-cloudformation@3

値の3はskillのバージョンで、例にあるaws-cloudformation@3はskill自身の記述に出てくる形です。既存のAWSToolsMetrics配下のキーは残す決まりです。このプラグインでテンプレートを編集させると、差分にこの行が加わります。コードレビューで見かけても混乱しないよう、チームには先に伝えておく項目です。

Metadataは暗号化されず、CloudFormationのAPIから読めます。skillも、シークレットや個人情報を書かないよう明記しています。

検証と高速デプロイ

デプロイ前の検証は、ローカルでのcfn-lintかcloudformation-validate、推奨既定としてcfn-guardのセキュリティ・コンプライアンス検査、アカウントを参照するCloudFormationサービス側の事前検証の3段です。どれをどの順で使うかは、validation-tool-selectionという参照資料が選ぶ基準を持っています。

開発中の反復を速くするExpressモードは、create-stack、update-stack、delete-stackに--deployment-config '{"mode": "EXPRESS"}'を付けて有効にします。CDKではcdk deploy --expressです。skillは、CDKのhotswapとは別物だと明記しています。Expressは完全なインフラを引き続きCloudFormation経由でデプロイするためドリフトを生まず、hotswapはサービスAPIを直接叩いてドリフトを作ります。aws cloudformation deployはExpressに対応しないため、create-stackかupdate-stackを使います。

IAMのskillは、手順書ではなく「AIが間違えやすい点の訂正集」

aws-iamの冒頭には、これは包括的なIAMガイドではなく、AIエージェントがよく間違える点を検証済みの形で直すためのものだ、と書かれています。IAMの一般論ではなく、次のような限られた落とし穴が並びます。

• ForAllValuesは、キーが存在しないと真になる。同じキーにNull条件を足して存在を要求する
• ロールの連鎖(role chaining)では、セッションは最長1時間
• iam:PassRoleのResourceを*にし、コンピュートサービスの作成・更新権限と組み合わせると、アカウント内のあらゆるロールへの権限昇格になる
• ポリシー自体を書き換える8つのアクション(PutRolePolicy、AttachRolePolicyなど)は権限昇格の経路になる

ポリシー生成は、手書きではなくautopilotに回される

もう一つの特徴は、ポリシーを生成させる流れです。アプリケーションのソースコードか、terraform show -jsonで出したTerraformプランのJSONがあるときは、iam-policy-autopilotを使うようskillが強制しています。エージェントが自分でポリシーを組み立てることは禁じられており、成果物は生成コマンドそのものです。決定論的な静的解析で、再現できる結果を得るためと説明されています。

uvx iam-policy-autopilot@latest generate-policies \
  /path/to/project/src/handler.py \
  --region us-east-1 \
  --account 123456789012 \
  --service-hints s3 dynamodb \
  --pretty

引数のソースファイルは絶対パスで渡します。アカウントIDとリージョンは、分かるときだけ指定します。環境変数、STS、cdk.jsonなどから見つけられなければ、フラグを省いてARNをワイルドカードで出す扱いです。推測で埋めてはいけないと決められています。

Terraformは、.tfファイルそのものは直接の入力になりません。先にterraform planを出力し、terraform show -jsonでJSONにします。対応言語はPython(boto3)、Go、TypeScript/JavaScript(SDK v3)、Javaで、RustやC#などはサービス認可リファレンスを引く別の経路にフォールバックします。

Well-Architectedレビューと、AWSへの移行

IaCとIAMのほかに、aws-coreには作業単位が大きいskillが2つあります。

aws-well-architected-reviewは、コードとIaCを読んでWell-Architectedフレームワークの6本柱に沿ったレビューを作ります。フルレビュー、クイックレビュー、柱を絞ったレビュー、スコアだけ出すモードがあります。要件が決まっていれば確認を挟まず最後まで進む非対話型で、レポートはファイルではなく会話に直接出します。成熟したワークロードに無理にCriticalを付けないよう、校正の指針も書かれています。

launch-with-awsは、Lovable、Bolt.new、Replitなどで作ったWebアプリをAWSへ移す手順です。Pythonスクリプトを順に実行し、最初にauth-startでサインインします。移行の範囲は元のプラットフォームで分かれます。

Replitは、データとアカウントを手動で移す作業が残ります。サインインは最長90日で切れ、以降は再度ブラウザーでのサインインが要ります。

フックが止めるもの

aws-coreのフックは、PreToolUseの2か所に設定されています。1つはBashコマンド、もう1つはuse_awsやmcp__aws*、mcp__plugin_*aws-mcp*に一致するAWS関連のMCPツール呼び出しです。どちらも、AWS CLIのsecretsmanager get-secret-value、SDKのGetSecretValue、ローカルのSecrets Managerエージェントへの取得リクエストのような、シークレットの値を直接引く呼び出しを拒否します。

拒否メッセージは、{{resolve:secretsmanager:...}}の動的参照をasm-execと組み合わせて使うよう案内します。CloudFormationのskillがテンプレートに動的参照を使わせる設計と、一続きの考え方です。フックのタイムアウトは5秒です。

grep、cat、gitのような読み取り系のコマンドは、文字列にAPI名が出てくるだけでは止めない作りです。

隣接するAWS系プラグインとの使い分け

AWS関連のプラグインは複数あり、役割が重なって見えます。

リポジトリのREADMEは、2025年にAWS Labsとして公開されたMCPサーバー・skill・プラグインの後継がAgent Toolkitだと書き、推奨する理由として次を挙げています。

• エージェントの操作と人間の操作を区別するIAM条件キー。読み取り専用のポリシーをエージェントにだけ当てられる
• すべてのリクエストに対するCloudWatchメトリクスとCloudTrailの監査ログ
• 一貫したエンドツーエンドの評価を経たskill

エージェントに限って書き込みを禁じるポリシーが書けることは、前節の承認制の設定と組み合わせると効きます。Claude Code側で確認を挟み、AWS側ではエージェントの操作だけを絞る二重の構えになります。請求の読み取りに絞るなら、AWS Billing MCPサーバーの記事が対応します。

最初にどのskillから使うか

最初の依頼は、状況に合わせて入口を変えます。

• 既存のCDKスタックを直す: cdk diffの結果を貼り、置き換えが起きるリソースがないか確認させる
• 素のCloudFormationテンプレートを新規に書く: 既定値とMetadataの書き方を指定したうえで、検証の3段を通させる
• IAMポリシーが必要: ソースコードのパスを渡し、autopilotのコマンドを出させる
• 設計全体の健康診断: Well-Architectedレビューをスコアモードで依頼する

CLAUDE.mdに書いておくと、毎回の指示が短くなります。

## AWSの作業ルール(aws-coreプラグイン使用)
 
- CDKのデプロイ前に`cdk synth --strict`と`cdk diff`を実行し、置き換えが出るリソースを報告する
- `--hotswap`と`--express`は開発用スタックでのみ使う
- IAMポリシーはソースコードから生成し、`iam:PassRole`の`Resource`に`*`を使わない
- シークレットはテンプレートに書かず、動的参照を使う

これらはskillが既に持つ方針ですが、プロジェクトの規約として明文化しておくと、skillが読み込まれなかった場面でも同じ判断が保たれます。