はじめに

こんにちは。株式会社シーイーシーのAWSコミュニティチームです。
今回は、IAMポリシーの設計やAccessDeniedの調査に役立つツール「IAM Policy Autopilot」の実践的な使い方をご紹介します。
IAMポリシーの設計やAccessDeniedの調査に、何時間も費やした経験はありませんか。

どのActionが足りないのか分からない
ResourceのARNを毎回調べている
結局AdministratorAccessを付けてしまう

IAM Policy Autopilotは、コードやエラー、AIを起点に、IAMポリシーを考える作業から解放してくれるツールです。「提案ツール」であり、生成されたポリシーをそのまま本番環境に適用するのではなく、内容を理解した上で必要な権限のみを採用することが推奨されています。
本記事では、IAM Policy Autopilotの使い方を3つに整理します。

この記事で扱うこと

IAM Policy Autopilotの3つの使い方
それぞれ「何ができるのか」
どんな場面で使うべきか
実務での注意点

この記事を読む前に

IAM Policy Autopilotを使う前に、以下の点を確認してください。

対象読者

AWSのIAMポリシーの基本（Action/Resource/Effect）を理解している方
boto3またはAWS SDKを使ったコードを書いたことがある方
Lambda・ECSなどのサービスにIAMロールを付与した経験がある方

IAM Policy Autopilotはあくまで「提案ツール」です。

本ツールが生成するポリシーは、静的解析をもとにした提案であり、そのまま本番環境へ適用することは推奨しません。
生成されたポリシーの内容を理解した上で、必要な権限のみを採用してください。

本番環境への適用には必ずIAM Access Analyzerなどでのレビューをはさんでください。

IAM Policy Autopilotの3つの使い方

① コードからIAMポリシーを生成する

目的

実装前や実装直後に「このコードに必要な最小権限のIAMポリシー」を作成するため。

使うコマンド

test_app.pyは実際のパスを指定してください。

iam-policy-autopilot generate-policies test_app.py \
  --region ap-northeast-1 \
  --account 123456789012 \
  --pretty

各オプションの意味

オプション	説明
`--region ap-northeast-1`	IAMポリシー内のARNに含まれるリージョンを指定
`--account 123456789012`	IAMポリシーに埋め込まれるAWSアカウントID。本番環境では実際のアカウントIDを指定すること（123456789012はダミー値）
`--pretty`	JSONを人が読みやすい形に整形する。権限内容自体は変わらない（表示のみ）
`--service-hints <SERVICES>`	分析対象を指定サービスに限定する。不要な権限を削減できる
`--upload-policies <PREFIX>`	生成されたポリシーを指定プレフィックスでAWS IAMにアップロードする。自動適用前に必ず内容を確認すること

できること

boto3・AWS SDKの呼び出しを静的解析する
使用しているAWS APIからActionを抽出する
最小権限のIAMポリシーを生成する

ポイント

AWSへは一切アクセスしない（静的解析のみ）
CI/CDパイプラインでも安全に実行可能
生成結果はあくまで「出発点」であり、そのまま本番環境へ適用しないこと

② AccessDeniedエラーをもとにIAMポリシーを修正する（運用フェーズ）

目的

実行時に発生したAccessDeniedの原因を解明して迅速に修正し、手作業でのエラーメッセージの解析を不要にするため。

使うコマンド

iam-policy-autopilot fix-access-denied \
"User: arn:aws:iam::123456789012:role/test-role is not authorized to perform: s3:GetObject on resource: arn:aws:s3:::example-bucket/input/data.json because no identity-based policy allows the s3:GetObject action"

出力例

IAM Policy Autopilot Plan
Principal: arn:aws:iam::123456789012:role/test-role
Action: s3:GetObject
Resource: arn:aws:s3:::example-bucket/*
Denial: ImplicitIdentity

Proposed permissions:
  - s3:GetObject

できること

AccessDeniedメッセージを構造化する
Action・Resource・Principalを抽出する
追加すべきIAM権限を提案する

補足：AccessDeniedの2種類について

ImplicitDeny（暗黙的な拒否）：許可ポリシーが存在しないために拒否される
ExplicitDeny（明示的な拒否）：SCP（Service Control Policy）やリソースベースポリシーで明示的にDenyされている

IAM Policy Autopilotの出力にある"Denial: ImplicitIdentity"はImplicitDenyに相当します。
ExplicitDenyの場合は、単に権限を追加しても解決しないため、SCP・バケットポリシー・権限境界（Permissions Boundary）も合わせて確認してください。

③ MCPサーバーでAI・IDEと連携する（AI利用時）

目的

AIによる誤った権限設計を減らしつつ、人による確認負担を軽減する運用を目指すため。

IAM Policy AutopilotはMCP（Model Context Protocol）に対応しています。
MCPサーバー連携とは、AI（特に生成AI）が外部のシステムやデータと安全・共通ルールでつながるための仕組みのことです。

AIがコード生成時にMCPサーバーへアクセスし、IAM Policy AutopilotをIAM専用の知識源として利用します。

これにより、以下の流れが可能になります。

AI（Claude・Copilot・Amazon Qなど）がコードを生成
必要なAWS権限を推測
IAM Policy Autopilotを内部的に呼び出し
正しいIAMポリシー案を自動生成

注意点

AIが生成したIAMポリシーも、そのまま適用せず必ずレビューすること
MCP連携時もAWSへの実際のアクセスは発生しない（静的解析）

AmazonQ Developerでの使用例

設定例
~/.aws/amazonq/mcp.json に以下を追記します

{
  "mcpServers": {
    "iam-policy-autopilot": {
      "command": "uvx",
      "args": ["iam-policy-autopilot", "mcp-server"]
    }
  }
}

設定後は、IDEのチャットで以下のように依頼するだけです。

このapp.pyに必要な最小IAMポリシーを生成してください

AmazonQ Developer は、MCPサーバー経由でIAM Policy Autopilotを呼び出し、コードを静的解析した上でポリシー案を返します。

実際に使ってみる：コードからIAMポリシー生成

前提条件

以下の前提で検証します。

AWS Lambda上で動作する
S3バケットからJSONファイルを取得する処理
S3バケットの暗号化設定はSSE-S3（AWSマネージドキー）

テストコード例

app.py

import boto3

def handler():
    s3 = boto3.client("s3")
    response = s3.get_object(
        Bucket="example-bucket",
        Key="input/data.json"
    )
    body = response["Body"].read()
    print(body)

if __name__ == "__main__":
    handler()

通常出力（service-hintsなし）

iam-policy-autopilot generate-policies app.py \
  --region ap-northeast-1 \
  --account 123456789012 \
  --pretty

出力例

{
  "Policies": [
    {
      "Policy": {
        "Id": "IamPolicyAutopilot",
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "kms:Decrypt"
            ],
            "Resource": [
              "arn:aws:kms:ap-northeast-1:123456789012:key/*"
            ],
            "Condition": {
              "StringEquals": {
                "kms:ViaService": [
                  "s3.ap-northeast-1.amazonaws.com"
                ]
              }
            }
          },
          {
            "Effect": "Allow",
            "Action": [
              "s3:GetObject",
              "s3:GetObjectLegalHold",
              "s3:GetObjectRetention",
              "s3:GetObjectTagging",
              "s3:GetObjectVersion"
            ],
            "Resource": [
              "arn:aws:s3:::*/*",
              "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/*/object/*"
            ]
          },
          {
            "Effect": "Allow",
            "Action": [
              "s3-object-lambda:GetObject"
            ],
            "Resource": [
              "arn:aws:s3:::*/*",
              "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/*/object/*"
            ]
          }
        ]
      },
      "PolicyType": "Identity"
    }
  ]
}

実際に生成して分かったこと

実際に生成されたポリシーは上記のとおりですが、やや包括的な内容になりやすいことが分かりました。
例えば、単純なs3:GetObjectのみを使うコードに対して、kms:Decryptやs3:GetObjectLegalHoldなど実際には不要な権限まで含まれていました。
また、Resourceの指定も"arn:aws:s3:::/"と広い範囲になりやすく、そのまま本番環境へ適用するのは適切ではありません。

各権限が含まれる理由と今回の前提での要否

kms:Decrypt：SSE-KMS暗号化の場合に必要。今回はSSE-S3のため「不要」
s3:GetObjectLegalHold/Retention/Tagging/Version：Object Lock・バージョニング・タグを使わない場合は「不要」
s3-object-lambda:GetObject：S3 Object Lambdaを使わない場合は「不要」

Resourceが"arn:aws:s3:::/"と広い理由

静的解析では実行時のバケット名を特定できないため、ワイルドカードになっています。
実際のバケット名が確定している場合は、以下のように絞り込むことを強く推奨します。

前提条件に合わせ、手動で調整したポリシーがこちらです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::example-bucket/input/data.json"
        }
    ]
}

このように、生成されたポリシーはあくまで叩き台であり、前提条件に合わせた手動精査と、実際に動かした際の対応を含めたフローで運用することが重要です。

実務での正しい使い方

IAM Policy Autopilotは以下のフローで活用することで、最小権限のIAMポリシーを効率的に作成できます。

①叩き台生成

generate-policiesでコードを静的解析し、ポリシーの叩き台を生成します。この時点では過剰な権限が含まれる場合があります。

②動かす前に手動精査

生成されたポリシーを手動で確認して不要なActionを削除し、Resourceを具体的なARNに絞り込みます。kms:DecryptやGetObjectLegalHoldなど前提条件に合わないものを削除し、バケット名が確定している場合はResourceもさらに絞り込みます。

③実際に動かす

実装したコードを実行します。正常に動作した場合は⑤へ、AccessDeniedが出た場合は④へ戻ります。

④エラー対応

fix-access-deniedでAccessDeniedのエラーメッセージを解析し、不足している権限を特定して追加します。追加後は③に戻って再実行します。

⑤最終精査

IAM Access Analyzer（未使用アクセス分析）で実際に使われなかった権限を検出し、不要な権限を手動で削除します。一定期間運用後に実施します。

まとめ

IAM Policy Autopilotは、IAMを自動化するツールではなく、IAMで無駄な時間を費やさないための出発点を作るツールです。

生成結果はそのまま採用しない。各権限の意味を理解した上で取捨選択する
Resourceは可能な限り具体的なARNに絞り込む
IAM Access Analyzerでポリシーを検証し、過剰な権限を削除する
AIと組み合わせることで、IAM設計の手間をさらに削減できる

IAMの設計に時間がかかっていると感じたら、まずAutopilotを試してみてください。

参考

IAM Policy Autopilot（GitHub）：
https://github.com/awslabs/iam-policy-autopilot/blob/main/README.md

※本記事は2026年5月時点の情報に基づいて執筆しています。