Google Cloud IAM Helperの二層構造：Agent Skillsによる運用自動化と認可・承認・監査の境界

IAM Helperの登場：Agent SkillsとMCPが構成するAI権限管理の二層構造

Google Cloudは2026年10月26日付の公式記事において、「IAM Helper」をエージェント向けのIAMワークフロー群として発表しました[1]。同日よりAgent Skillsを活用して環境を構築できると案内されています[1]。

IAM Helperは、Agent Skillsが高位のIAMワークフローロジックを担い、Google Cloud IAM Helper MCP toolsがバックエンド接続を担う二層構造を採用しています[2, 6, 7]。対応クライアント環境として、Gemini CLI、Gemini Cloud Assist、ADK、Claude Code、Cursorが挙げられています[2]。

補足：Model Context Protocol（MCP）とは

AIモデルが外部ツールやデータソースと標準化された形式で通信するためのオープンプロトコルです。

下位に位置する個別のMCPサービスは段階的に提供が進められており、Policy Troubleshooter MCP serverは2026年8月6日、Policy Analyzer MCP serverは2026年9月1日に一般提供（GA）が開始されました[3]。これらはIAM Helperの発表前から個別に利用可能となっていたサービスです[4]。

Agent Skillsは、Googleの公開リポジトリである google/skills から npx skills add google/skills コマンドで選択して導入できます[5]。リポジトリ内のSkillsにはApache 2.0ライセンスが適用されており、コピー、改変、再配布が認められています[5]。

IAM Helperを構成するMCPツールは、Policy IntelligenceやIAM API（Policy Troubleshooter、Policy Analyzer、Policy Simulator、IAM v1およびv2 API）に接続する原子的な読み取り専用関数として位置付けられています[6, 7]。このMCPツール群の上位で、以下の4つの主要なAgent Skillsが公開されています[8, 11, 14, 17]。

1. iam-helper-for-policy-management: IAM v1のallow policyおよびIAM v2のdeny policyの作成、変更、管理を支援します[8, 9]。allUsersによる公開アクセスを許可しないよう指示されており[8, 9]、IAM v1 allow bindingの追加・削除・設定や、IAM v2 deny policyの作成・更新・削除を対象とします[10]。変更コマンドの実行前には、明示的な利用者の確認を要求します[10]。
2. iam-helper-for-troubleshooting: 開発者向けの「Requester Flow」において403などのアクセス拒否エラーを調査し、PAMによる一時アクセスの申請や管理者への引き継ぎを支援します[11, 12, 13]。管理者向けの「Resolver Flow」では、ポリシー分析と最小権限ロールの探索を支援します[11, 12, 13]。
3. iam-helper-for-policy-simulator: 提案されたIAM v1 allow policyの変更案を過去90日分のアクセスログでシミュレーションし、既存のアクセス試行への影響を分析してから適用する手順を案内します[14, 15, 16]。
4. iam-helper-for-privileged-access-management: Privileged Access Manager（PAM）におけるentitlementのCRUD操作、アクセス昇格の申請、grantの承認および拒否ワークフローの手順を扱います[17]。

なぜ今エージェント向けIAMなのか：機械速度の運用と最小権限の維持

自律エージェントの導入が進む開発現場では、クラウド資源のプロビジョニングやTerraformコードの生成、デプロイ処理が機械速度で実行されます[18]。処理速度が大幅に向上する環境下では、権限拒否に伴う手作業の調査や管理者への問い合わせがCI/CDパイプラインをより早い段階で停止させる運用上の摩擦となります[18, 19]。

迅速な作業再開を優先するあまり、エージェントに対して広範な権限を恒久的に付与すると、クラウドセキュリティの基本である最小権限の原則が損なわれるリスクが高まります[20]。

Google Cloudは、こうした自律エージェント時代の課題を見据え、既存のPolicy IntelligenceなどのIAM判定エンジンを補完するエージェント向けオーケストレーションおよびインタフェース層としてIAM Helperを発表しました[21, 22]。

通常のGoogle Cloud Consoleやgcloud CLIを用いた運用では、人間の担当者がIAMポリシーを直接確認し、編集して保存する手順を踏みます[23]。これに対しIAM Helperでは、Agent Skillsが複数段階の調査やシミュレーションの手順を自動で束ねます[23]。そのため、本機能の本質は認可判定エンジンの変更ではなく、作業の入口と複数ツールの連携手順を自動化する点にあると整理されています[22, 23]。

何が変わるか：読み取り診断の自動実行と過去ログ90日による変更シミュレーション

IAM Helperの運用において、読み取り診断やシミュレーションは自動的に実行されます[24, 25, 26]。一方で、アクセス方針の変更を伴う操作については、設定可能なリスク段階に応じた明示的な人間の確認（Human-in-the-Loop: HITL）を挟む設計となっています[24, 25, 26]。iam-helper-for-policy-management Skillにおいても、変更コマンドを実行する前に利用者へ明示的な確認を求めます[24]。

Policy Simulator Skillでは、IAM v1 allow policyの変更案を作成した際、過去90日分のアクセスログを再生してシミュレーションを実施します[15, 25, 28]。これにより、変更適用によって既存の正常なアクセスが遮断されるなどの悪影響が生じないかを事前に検証し、安全性が確認された段階で利用者に適用を確認します[15, 25]。

既存のIAM分析・推奨機能との位置付けも明確に区別されます。Policy Analyzerは既存のallow policyを解析して「誰がどのリソースにアクセスできるか」を可視化し、Policy Simulatorはポリシー変更の影響を適用前に評価する既存機能です[27]。また、IAM Recommenderは過去最大90日間の権限使用データを分析し、過剰なロールの削除や適切な代替ロールへの置換を提案します[29, 30]。IAM Recommenderには、Googleグループに付与された過剰な権限を恒久的なロールバインディングからPAMの一時的なオンデマンドentitlementへ移行する是正機能（Preview）も用意されています[31]。

なお、IAMロールの提案を行う「Policy Assist remote MCP server」がPreviewとして別途公開されていますが、IAM Helperの発表資料に記載された基礎MCPツール群には含まれておらず、IAM Helper内部でPolicy Assistを呼び出しているかは公開資料上確認できないと整理されています[32, 33]。

allow policyの変更を実際に適用するには、対象スコープに応じた getIamPolicy および setIamPolicy 権限（Project IAM Admin、Folder Admin、Organization Adminなど）が必要です[35]。deny policyの作成・更新・削除にはDeny Admin権限が求められます[35]。別途GAされているIAM remote MCP serverでは、custom roleやdeny policyの設定変更機能も提供されています[34]。

何が変わるか：Privileged Access Manager（PAM）連携による一時アクセスと自動失効

iam-helper-for-troubleshooting Skillでは、開発者が403アクセス拒否に遭遇した際、恒久的なロール追加を回避し、Privileged Access Manager（PAM）を用いたジャストインタイムの一時アクセス昇格へ誘導します[11]。

PAM entitlementには、申請可能なprincipal、付与するロール、有効期間、および承認ワークフローの要否を設定します[37]。承認ワークフローの設定はentitlementごとに任意（オプショナル）であり、承認ワークフローが未設定の場合、PAM上の承認手続きは不要です[36, 44]。アクセス申請を行える対象は、entitlementにあらかじめ追加されているprincipalに限定されます[44]。

entitlementに設定可能なgrant期間の上限は7日間（168時間）です[36, 38, 39, 40, 41]。grant期間が終了すると、付与されていたロールはPAMによって自動的に取り消されます[36, 38, 39, 41]。また、管理者は必要に応じて RevokeGrant 操作を実行し、有効期間中であってもアクセスを直ちに取り消すことが可能です[41]。

PAMにおける一時ロールの付与および撤回に伴うIAMポリシー変更は、Google-managed service agent（Google管理サービスアカウント）がバックグラウンドで実行します[42, 43]。これにより、アクセスを申請・承認するprincipal自身が強いIAM変更権限を持つ必要がなくなり、実行主体が明確に分離されます[42, 43]。

entitlementの作成、更新、削除を行う管理者には、PAM Admin（roles/privilegedaccessmanager.admin）およびリソース階層に応じたIAM管理権限（Project IAM Adminなど）が必要です[45]。これに対し、grantの申請者および承認者にはPAM固有のIAM権限は不要であり、entitlement側で指定されていれば手続きを実行できます[45]。

複数段階や複数人による承認機能はPreviewとして提供されており、利用にはSecurity Command Center（SCC）PremiumまたはEnterprise tierが必要です[46, 47, 48]。

Agent Skill内で対話的に行われる利用者確認と、PAMのgrant承認は独立した別のゲートです[49]。Skill側で確認を完了してもPAMの承認要件を満たしたことにはならず、PAM側で指定された承認者による厳密な審査プロセスが適用されます[49]。

誰に影響するか：開発者・管理者・DevOps担当者の実務フローと使い分け

IAM Helperの導入により、開発者、クラウド管理者、DevOps担当者のそれぞれにおいて実務フローが明確に分かれます。

開発者やオンコール担当者は「Requester Flow」を利用します[50]。デプロイ処理で権限不足が発生した際、エラーの自己診断を行い、事前に定義されたPAM entitlementが存在すれば一時アクセスを申請します[50]。自己解決が困難な複雑な権限エラーの場合は、管理者向けの構造化された問い合わせチケットを作成して引き継ぎます[50]。

セキュリティ管理者やCloud IAM管理者は「Resolver Flow」を活用します[51]。組織、フォルダ、プロジェクトの各階層におけるallow policyおよびdeny policyの継承関係を調査し、過不足のない最小権限ロールを特定してトラブルを解消します[51]。

TerraformなどのIaCを用いてアクセス要件をJSONやYAML、HCLに定義するDevOps担当者は、iam-helper-for-policy-management Skillを使用します[52]。IAM v1 allow bindingの追加・削除やIAM v2 deny policyの記述・検証をSkillに支援させ、安全な構文でのポリシー変更を進めます[52]。この際、変更コマンドの実行前には必ず利用者の明示的な承認が求められます[53]。

担当者ロール	使用する主なSkill	主な実務シナリオ	実行されるIAM関連操作	承認・確認の手続き
開発者 / オンコール	iam-helper-for-troubleshooting（Requester Flow）	403拒否エラーの自己診断、一時アクセスの取得、管理者への調査依頼	PAM grantの申請、エラーログの分析、構造化チケットの作成	Skill内での確認、およびPAM entitlement設定に基づく承認審査 [11, 50]
セキュリティ / IAM管理者	iam-helper-for-troubleshooting（Resolver Flow）	組織・階層をまたぐポリシー継承の分析、最小権限ロールの探索	Policy Analyzer / Troubleshooterを用いたアクセス権限の調査	調査・診断は自動実行、管理者自身による権限評価 [11, 51]
DevOps / プラットフォーム担当者	iam-helper-for-policy-management / iam-helper-for-policy-simulator	IaC用ポリシー定義の作成・検証、変更適用前の影響シミュレーション	allow binding / deny policyの変更、過去90日ログでのシミュレーション	リスク段階に応じたSkill上の明示的確認、set-iam-policy実行前の承認 [10, 52, 53]

Policy Simulator Skillを運用環境で実行するには、実行環境に対して roles/policysimulator.admin、roles/cloudasset.viewer、および対象リソースに対する適切なIAM管理者ロール（Project IAM Admin等）が付与されている必要があります[54]。

監査および運用管理の観点では、PAMの各種イベント（entitlement作成、grant申請、承認、拒否、取消）はCloud Audit Logsに記録されます[55, 56]。PAMのGrantリソース自体は、拒否や取消、終了などの状態となってから30日後に自動削除されます[56]。grantの監査ログは _REQUIRED バケットのログ保持期間に従って保存されます[56]。一方、allow policyの変更履歴はSetIamPolicyを含む監査ログやCloud Asset Inventoryから確認でき、過去の成功したSetIamPolicyの内容を取り出して再適用することで以前の状態へ復旧する手順が案内されています[57]。

承認・実行・監査の境界：認証主体の分離とログ収集の実態

AIエージェントによるIAM操作を安全に運用するためには、認証主体、認可制御、監査ログの各境界を正しく把握する必要があります。

Google Cloud MCPサーバへの接続は、MCPクライアントに設定されたprincipalを用いて認証されます[58, 61, 63]。運用者が自身の個人identityを使用した場合、AIアプリケーションによる操作はその個人に帰属し、個人と同じ権限で実行されます[58, 59, 60, 61, 63]。そのため、Google Cloudは本番環境において、権限を厳格に絞り込み追跡性を確保できる専用のagent identityまたはworkload identityの利用を推奨しています[58, 59, 60, 61, 62, 63]。

MCPの利用制御では、プロジェクト上の mcp.tools.call 権限（MCP Tool Userロールなど）に加えて、呼び出し先の個別クラウドサービスに対する正規のIAMロールが必須となります[64, 65, 66, 67]。Google Cloud IAMのallow policyおよびdeny policyを用いることで、principal、service名、tool名、読み取り専用属性（tool.isReadOnly）、OAuth client IDに基づいてMCPツールの呼び出しを制限できます[68, 69]。ただし、OAuth client IDを条件とした制御はIAM deny policyでのみ利用可能です[69]。

会話上の確認と実際の認可実行は明確に独立しています。Skillの会話プロンプト上で行われる人間確認はワークフローを停止させるゲートであり、Google CloudのIAM認可やPAM承認の代行ではありません[71]。さらに、Skillが提示したgcloudコマンドを実行する場合、Google Cloud CLI側でアクティブとして選択されているアカウントが実行主体となるため、MCPクライアントの認証主体と同一のアカウントであるとは限らない点に留意する必要があります[70, 72]。

サービス区分	主な提供機能	変更（書き込み）操作の可否	必要な主なIAMロール	Data Access監査ログの初期状態
IAM Helper 基礎MCPツール群	Policy Troubleshooter、Policy Analyzer、Policy Simulator、IAM APIへの接続	不可（原子的な読み取り専用関数として提供）	MCP Tool User、およびアクセス先リソースの閲覧権限	既定で無効（明示的な有効化が必要） [64, 73, 79]
IAM remote MCP server（GA）	custom roleの参照・作成・更新・削除、deny policyの構成管理	可能（ロールや拒否ポリシーの作成・変更に対応）	MCP Tool Userに加え、Role AdministratorまたはDeny Admin	既定で無効（明示的な有効化が必要） [34, 76, 82]

IAM Helperの発表資料では基礎MCPツールが読み取り専用と説明されていますが、別途一般提供されているIAM remote MCP serverにはcustom roleやdeny policyの変更機能が含まれています[73, 74, 75, 76, 77]。したがって、読み取り専用という制約はIAM Helperの基礎ツール群に固有の説明であり、Google CloudのIAM関連MCP全体に一般化することはできません[73, 74, 75]。

監査ログの収集状態にも実務上の注意点が存在します。PAMのentitlement作成やgrant申請・承認などのイベントはCloud Audit Logsに記録されます[78, 80]。しかし、Google Cloud MCPのData Access audit logsはログ量が膨大になり得るため既定で無効化されており、ツールの呼び出し履歴を監査するには明示的な有効化設定が必要です[78, 79, 80, 81, 82]。ログはアクセス対象データが存在するプロジェクトに記録されます[82]。

また、Skillによる実行時の帰属タグ、MCPのサービス別監査ログ、PAMのイベントログ、allow policyのSetIamPolicy履歴は個別に存在しますが、Skillの選択からMCP呼び出し、gcloud変更、PAM承認までを一連のトランザクションとして結ぶ共通の相関ID（Correlation ID）や実行トレース仕様は公開資料上確認されていません[83, 84, 85]。さらに、allow policyには過去のログから復旧する手順が示されているものの、deny policyについては同等の履歴復旧手順やIAM Helperによる自動ロールバック機能は公表資料上確認できないとされています[86]。

安全性の検証と実務上の限界：プロンプト注入対策と推奨精度の評価設計

AIエージェントによる権限管理を本番運用に導入するにあたっては、プロンプト注入耐性の限界や分析エンジンの制約を正しく認識し、客観的な検証手法を整える必要があります。

Agent Skillsの指示内容はモデルに渡されるテキストそのものであり、プロンプト注入の攻撃対象面（attack surface）となり得ます[87]。また、MCPの tool annotation はモデルに対するヒント情報に過ぎず、モデルの注入耐性を向上させたり、指示の実行を強制したりするセキュリティ境界としての機能は持ちません[87]。

基盤となる分析エンジンにも固有の制約が存在します。Policy Simulatorは過去90日間のアクセス試行を参照してシミュレーションを行いますが、IAM conditions（条件付きバインディング）には対応しておらず、未対応のリソース種別が存在する場合や評価情報が不足している場合にはシミュレーション結果に不確実性が生じます[88]。また、IAM Recommenderのロール推薦も最大90日分の権限使用データに基づいており、最小観察期間（既定90日）を短縮すると推薦精度に影響を及ぼす可能性があると説明されています[89]。

これらの制約を踏まえ、エージェントによる権限推奨の精度を評価する際は、最小権限を満たす正解セットを事前に策定しておく設計が妥当とされています[90]。リソース階層、principalの属性、グループ所属、条件付きバインディング、アクセスログの偏りを含めた複数ターンのツール実行環境を用意し、エージェントが生成した最終回答テキストではなく、ツール呼び出しによって生じる「実環境の状態変更」を採点対象として複数回の試行を重ねる評価手法が求められます[90]。

安全性の評価においては、Skillの指示テキストやMCPツールの出力データ内に敵対的指示を混入させるプロンプト注入試験、偽の読み取り専用属性の付与、権限外の操作要求などを含むレッドチーム試験を実施すべきとされています[91]。その際、ツールの呼び出し対象や引数、副作用の有無、承認プロセスの回避が試みられていないかを精査し、攻撃の成功率と正常な業務タスクの誤ブロック率を明確に分離して測定する設計が推奨されています[91]。

さらに、既定で無効化されているMCPのData Access監査ログを事前に有効化し、エージェントの実行記録、認証principal、MCPツール呼び出し、人間の承認記録、そして実際のIAMポリシー変更履歴を定期的に突合して監視する体制を確立することが不可欠とされています[92]。