はじめに
セッション概要
IAMポリシー作成の課題
【デモ】マルチテナントの顧客オンボーディング
AIコーディングアシスタントによるポリシー作成の危険性
IAM Policy Autopilotの概要
IAM Policy Autopilotの仕組み
IAM Policy Autopilotにおける注意点
【デモ】IAM Policy AutopilotとKiroによるポリシー作成
実際に使ってみて考えるユースケース
終わりに
参考

はじめに

こんにちは、藤本です。
re:Inventから2カ月経ちましたが、今一度当時の様子を思い出しながら、現地で聴講したセッション「From Code to Policies: Accelerate Development w/ IAM Policy Autopilot (SEC351-R)」の内容をまとめてみました。

セッション概要

タイトル

「[NEW LAUNCH] From Code to Policies: Accelerate Development w/ IAM Policy Autopilot (SEC351-R)」
（和名：コードからポリシーへ IAM Policy Autopilotで開発を加速する）

セッション形式

コードトーク
コードトークは、開発コードを題材にしたディスカッション形式のセッションです。ライブコーディングやコード例を交えながら、具体的な実装パターンや技術の使いどころを、デモ中心に紹介します。登壇者は参加者とコミュニケーションを取りつつ進行するため、一方的に聞くだけではなく、能動的に学べるのが特徴です。

レベル

300レベル

概要

本セッションでは、2025年11月30日に発表されたIAM Policy Autopilotが取り上げられ、IAMポリシー作成における現状の課題を整理しながら、その解決アプローチが紹介されました。デモでは実際にコードを動かしつつIAM Policy Autopilotの使い方を解説し、権限エラーなど開発で起こりがちな状況も再現されていました。具体的なユースケースを通して、ツールの有用性がイメージしやすい内容になっていました。

IAMポリシー作成の課題

IAMポリシーは熟練者でも詰まりやすい領域であり、プロトタイピングから初期開発で速度を落とす要因になっています。この詰まりを回避するために現場でありがちなパターンとして次の3つが挙げられていました。

最大権限AdministratorAccessを付ける
AWSマネージドポリシーを付ける
最小権限を手動で設定する

「最大権限AdministratorAccessを付ける」や「AWSマネージドポリシーを付ける」方法の場合は、AWS Well-Architected フレームワーク SEC03-BP02 最小限の権限アクセスを許可するの考え方にはそぐわないアプローチになります。また、「最小権限を手動で設定する」方法は理想的ではありますが、必要なアクションや条件の検証などに時間がかかります。さらに、機能追加のたびに権限を更新する必要があり、開発のテンポが落ちやすくなります。

最近では、上記3点の他にAIコーディングアシストでIAMポリシーを作成する方法も考えられますが、完璧なIAMポリシーが生成されるとは限りません。
会場では実際にAIコーディングアシストによって作成されたIAMポリシーの注意点について、デモで紹介されました。

【デモ】マルチテナントの顧客オンボーディング

セッションのデモでは、マルチテナントの顧客オンボーディングを題材に、顧客ごとに専用の暗号鍵とストレージを自動作成するシンプルなマイクロサービスが例に出されました。
具体的には、Lambda 関数が顧客ID（customerId）と顧客名（customerName）を受け取り、

顧客専用の KMS キー作成（タグ付け・キーポリシー設定・エイリアス作成）
顧客専用 S3 バケット作成
作成した KMS キーを指定して、バケット暗号化（SSE-KMS）を有効化

という順に処理しています。

AIコーディングアシスタントによるポリシー作成の危険性

前述のアーキテクチャを題材に、デモでは実際にAIコーディングアシスタントを用いてIAMポリシーを作成していました。生成されたポリシーは一見正しい権限に見えましたが、AWS マネジメントコンソールのポリシー検証ではエラーとなり、弾かれていました。こうした不整合が起きた原因として3点挙げられていました。

SDKメソッド名とIAMのアクション名は一致しない

AWS SDK（デモの例ではBoto3）のメソッド名は、IAMのアクション名と1対1で対応しないことがあります。
例えば、S3バケットの存在確認に使うhead_bucket()メソッドがありますが、s3:HeadBucketというIAMアクションは存在しません。実際に必要になるのは、バケット内のオブジェクト一覧を確認するための権限s3:ListBucketです。
同様に、put_bucket_encryption()メソッドに対して、必要になるIAM アクションはs3:PutEncryptionConfigurationであり、メソッド名をそのままアクション名に変換するだけでは正しいポリシーになりません。

隠れた依存関係で追加権限が必要になる

IAMでは、1つのAPI呼び出しであっても、内部的な処理まで含めた権限が必要になることがあります。
例えば、KMSのCreateKeyでは、作成時にKey Policyを指定できますが、そのポリシーに将来の管理権限、つまりキーポリシー更新(kms:PutKeyPolicy)を許可する権限を入れておかないと、キーの更新や復旧ができなくなります。 LLMはメソッド名からの推測は得意ですが、キー作成後に管理可能であることを担保するといった運用・文脈依存の要件は取りこぼしやすいです。

1つの操作が複数アクションに展開される

AWSのAPIは1メソッドにつき1権限ではありません。
例えば、S3のコピーの処理は、コピーの権限だけでなく、実際には読み取り（Get）と書き込み（Put）の権限が必要になります。 LLMはこうした複合操作に必要な権限を網羅しきれず、一部の権限が抜けた不完全なポリシーを生成してしまうことがあります。

これらが起きる背景には、LLMがドキュメントやコード例などの公開情報からパターンを学習し、それらしい推測で補完する性質があることが挙げられます。しかしIAMポリシーでは、上記で挙げたようにアクション名の厳密さや依存関係の存在により、推測ベースの生成は外れやすく、デバッグに時間がかかってしまいます。

セッションでは、その解決策としてIAM Policy Autopilotを利用するアプローチが紹介されました。

IAM Policy Autopilotの概要

IAM Policy Autopilotは、アプリケーションコードを静的に解析してコードが実際に行っている操作に基づき、必要なIAMポリシーの生成を行うオープンソースのツールです。コマンドラインツール（CLI）として利用できるだけでなく、MCP（Model Context Protocol）サーバーとしても提供されており、IDEやコーディング支援ツールから呼び出して利用することができます。 GitHubで公開されているため、ローカル環境に導入し、無料で利用できます。

github.com

IAM Policy Autopilotの仕組み

IAM Policy Autopilotは、大きく3ステップでポリシーを生成します。

静的解析でコードからSDK操作を抽出する
ローカル環境でコードを静的解析し、head_bucket、create_key、create_aliasなどのSDK操作を抽出します。
抽出した操作をIAMアクションにマッピングする
AWSが公開している IAMサービスリファレンス（アクション・条件の一覧）を参照し、さらに最新の情報が更新されたマッピング情報を使って、抽出したSDK操作に必要なIAMアクションに対応付けします。
例えば、Boto3の create_key()メソッドは、単にkms:CreateKeyだけでは完結しないケースがあります。作成時の指定内容によってはkms:PutKeyPolicyやkms:TagResourceなども必要になります。 IAM Policy Autopilotはこうした関連アクションを、推測ではなくサービスデータに基づいて導出します。
決定論的にポリシー生成する
抽出した操作とマッピング結果を組み合わせて、必要なアクションを網羅したポリシーを決定論的（Deterministic）に生成します。ここでいう決定論的（Deterministic）とは、同じ入力を与えれば、毎回全く同じIAMポリシーが生成されるという性質を指します。

このアプローチのメリットは、LLMの推測に起因する不確実性を抑えつつ、実運用に耐える形でポリシー生成を進められる点にあります。
具体的には、同じコードから毎回同じ結果が得られる決定性により差分管理や監査がしやすくなり、公開されているサービス参照データを利用することで最新性も担保できます。さらに、存在しないIAMアクションのような誤りが混ざりにくい点で信頼性が高く、推測ベースの生成で起こりがちなミスや手戻りを減らすことができます。

IAM Policy Autopilotにおける注意点

対象はアイデンティティベースのIAMポリシーのみ

IAM Policy Autopilotによって生成できるのは、ロールやユーザーに付与する IAMポリシーに限られます。 RCP（Resource Control Policy）や SCP（Service Control Policy）、Permission Boundary（アクセス許可の境界）などのポリシーには対応していません。

最小権限を保証するものではない

生成されるポリシーは必ず最小権限になるのではなく、まず動かすためのベースラインとして提供されます。そのため、出力結果は都度レビューし、リソースの絞り込みや不要権限の削除などを行いながら改善していく前提になります。

静的解析だけではリソース名を自動識別できない

現時点の静的解析では、S3バケット名などのリソース名を自動的に特定してポリシーに反映することはできません。結果として、リソースを特定できず、全てのリソース（Resource: *）を選択するケースがあります。

クロスサービスの依存関係は読み取れない場合がある

SDK操作とIAMアクションのマッピングにより、多くのケースはカバーできますが、設定やデータの状態に依存するような複雑なクロスサービス連携では例外もあります。例えば、S3のオブジェクトがSSE-KMSで暗号化されている場合、読み取り処理でS3の権限に加えてKMSの権限が必要になりますが、こうした依存関係は静的解析だけでは判断しづらく、ポリシー生成時に取りこぼされる可能性があります。

【デモ】IAM Policy AutopilotとKiroによるポリシー作成

デモでは、先ほどのマルチテナントの顧客オンボーディングをIAM Policy AutopilotとKiroによるポリシー作成で解決する方法が紹介されました。

1. インストール

ローカル環境にIAM Policy Autopilotをインストールします。

pip install iam-policy-autopilot

2. MCPサーバとしてセットアップ

今回はKiroを使用するため、IDEの画面からゴーストのアイコンをクリックして、MCPサーバーの設定画面（mcp.json）に以下を設定します。

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

3. ポリシー作成

Lambda関数のPythonコードを対象に、Kiroに対して「このコードを実行するためのIAMポリシーを作成してください。」（Please create an IAM policy for this script.）と依頼します。ここでKiroはIAM Policy Autopilot（MCP）を呼び出し、コード内のAWS SDK呼び出しを解析し、必要なIAMポリシーを生成します。
生成されたポリシーはファイル名iam-policy.jsonとして出力され、保存することができます。

4. IaC（AWS CloudFormation）に組み込む

作成されたポリシーの検証を行うため、KiroにCloudFormationテンプレートの作成を依頼します。 Kiroに対して「このコードをデプロイするためにCloudFormationテンプレートを作成してください。」（Please create a CFN template to deploy this script.）のように指示し、このコードをデプロイできるテンプレートを生成してもらいます。作成するテンプレートには、Lambda関数本体、実行ロール、生成されたIAMポリシー（iam-policy.json）を含めます。
ここでIaC（CloudFormation）に組み込むことで、!GetAttや!Subといった参照・変数展開を使って、デプロイ時に確定するリソースARNをポリシーへ埋め込むことができます。これによりResource: "*"のままになる権限を、実際に作成したリソースへ絞り込みやすくなります。つまり、静的解析だけではリソース名を自動識別できないというIAM Policy Autopilotの弱点を、CloudFormation側の参照機能で補うことができます。

テンプレートをデプロイしたら、最後にデプロイ済みのLambda関数を実行し、期待どおりに動作することを確認します。
デモでは、デプロイしたLambda関数が正しく動くことを確認していました。

権限不足による`AccessDenied`の自動修復フロー

デモでは、SQS通知の機能追加によって実行ロールの権限が不足し、AccessDeniedが発生した場合の自動修復フローも紹介されました。具体的には、発生したAccessDeniedのエラーメッセージを元に、不足している権限を特定し、追加すべきIAMポリシーの変更案を提示するというものです。デモではAccessDeniedのエラー文をKiroに読み取らせ、原因となっているアクション（sqs:SendMessage）を特定したうえで、実行ロールに必要な権限を追加して再デプロイし、エラーが解消されるところまで確認していました。

権限不足の切り分けと修正は手作業だと地味に時間を取られるため、こうした自己修復がスムーズに実行できるのは便利だと思いました。

実際に使ってみて考えるユースケース

デモの内容を参考に、実際にIAM Policy Autopilotを触ってみて、運用目線では3つの開発フェーズに分けて使うのがよいと思いました。

①初期開発

初期開発は、とりあえず動かすフェーズです。ここで、AdministratorAccessや広いマネージドポリシーを付けずに、IAM Policy Autopilotによりベースラインを満たすIAMポリシーを素早く作成します。 IAM Policy Autopilotにより、開発スピードを落とさずに開発を進められ、初学者や別領域のエンジニアでもIAMで詰まりにくくなります。

手順

SDKを用いたコードを書いた後、CLIgenerate-policiesでベースライン生成
生成ポリシーを実行ロールに付与してデプロイ
動作確認して必要権限の方向性を固める

②反復開発

反復開発はサービス・機能を追加するフェーズです。コードの変更に追随してIAM Policy Autopilotでポリシーを再生成し、必要権限の不足を減らします。この時、IaC（CloudFormationなど）に組み込み、!GetAtt や !Subといった参照機能で ARN をテンプレートから埋め込むことで、ポリシーの対象リソースを具体化してスコープダウンします。

手順

コードに変更が入った場合、CLIgenerate-policiesを再実行
生成したポリシー（JSON）の差分をレビュー
IaC（CloudFormationなど）に組み込み、参照（!GetAtt や!Sub）でリソース名を絞る

③AIコーディングアシスタントでの開発

AIコーディングアシスタントを活用しながら開発を進めるフェーズです。権限不足によるAccessDeniedが発生した場合でも、IAM Policy Autopilotと連携したAIコーディングアシスタントがポリシーを自動で見直して自己修復します。これにより、人が都度ログを確認して対応する手間を減らせるため、監視・対応コストの低減につながります。

手順

コードに権限エラーAccessDeniedが発生した場合、IAM Policy Autopilot MCPサーバーを利用し、AIコーディングアシスタントに依頼（CLIにおいてはfix-access-deniedを実行）
修正内容を確認し、デプロイ

終わりに

IAM Policy AutopilotはMCPとCLIの両方で提供されており、比較的簡単に導入できる点が魅力的だと感じました。 IAM Policy Autopilotを利用することで、コードから必要な権限をベースラインとして素早く生成できるため、AdministratorAccessのような最大権限に頼らずに開発を進めやすく、一定のセキュリティ水準を保ちながら前に進められます。この開発スピードとセキュリティの両立を支援できる点が最大のポイントだと思いました。
ただし、生成されたポリシーはあくまで出発点であり、まず動くベースラインのポリシーを用意することを前提としているため、最小権限が保証されるわけではありません。実運用では、リソースの絞り込みや不要権限の削除などを継続的に行い、レビューを通じて最小権限に近づけていく必要があります。加えて、CI/CD に組み込んだり、IAM Access Analyzerを活用して未使用の権限を棚卸しする運用が必要になります。