AIのコーディングエージェントにGoogle Cloudへのデプロイを任せると、権限不足（403 PERMISSION_DENIED）で止まる場面がでてきます。そのたびに人が原因を調べて権限を足していると、エージェントの速さが生きません。かといって、エージェントに権限の変更まで任せると、必要以上に強い権限を付けてしまうおそれがあります。
Google Cloudは2026年10月26日（米国時間）、この問題に向けた「IAM Helper」を発表しました。IAMの調査や権限の変更を、エージェントが呼び出せる「Agent Skills」とMCPのツールとして提供するものです。スキルは、Googleの公開リポジトリ（google/skills）に置かれています。
この記事では、発表のブログと、リポジトリの4つのスキルの本文を読み、社内やお客さまの環境に入れる前に確かめておきたい点を整理します。
4つのスキルの役割
発表のブログが挙げているスキルと、リポジトリでの版（2026年10月27日時点）は次のとおりです。
| スキル | 役割 | 版 |
|---|---|---|
| iam-helper-for-troubleshooting | 403の原因を調べ、足りない権限や止めている拒否ポリシーを特定する | 1.0.3 |
| iam-helper-for-policy-management | 許可ポリシー（IAM v1）と拒否ポリシー（IAM v2）の作成・変更 | 1.0.1 |
| iam-helper-for-policy-simulator | 変更案を過去90日のアクセスのログに当て、止まるアクセスがないか確かめてから適用する | 1.0.2 |
| iam-helper-for-privileged-access-management | Privileged Access Manager（PAM）で、期限付きの権限の申請・承認を扱う | 1.0.1 |
ブログは、これらがGemini CLI、Gemini Cloud Assist、ADK、Claude Code、Cursorといったエージェントで使えると説明しています。ブログによると、スキルの裏側では、Policy TroubleshooterやPolicy Analyzer、Policy Simulator、IAMのAPIを、Googleが管理するMCPサーバーのツールとして呼ぶ構成です。
提供段階も確かめておきます。Google CloudのMCPサーバーの一覧（2026年10月27日時点）には、IAM、Policy Troubleshooter、Policy AnalyzerのMCPサーバーが載っており、リリースノートではいずれも一般提供（GA）です（Policy Troubleshooterは8月6日、Policy Analyzerは9月1日、IAMは9月10日）。Policy SimulatorのMCPサーバーは一覧になく、policy-simulatorのスキルは gcloud iam simulator replay-recent-access のコマンドでシミュレーションする手順になっています。IAM Helperそのものについては、IAMとPolicy Intelligenceのリリースノートに項目がなく、プレビューか一般提供かの表示は見つかりませんでした。スキルはGitHubで公開されているファイルとして配られています。
「読み取りは自動、変更は人の承認」の線引き
ブログは、どのスキルも読み取りの調査と権限の変更を分けていて、変更の前には人の確認（Human-in-the-Loop）を挟むと説明しています。スキルの本文でも、この線引きは具体的に書かれていました。
- policy-management：ポリシーの取得や一覧は自動で実行してよい。追加・削除・置き換えなどの変更は、実行するコマンドを示して利用者の承認を得るまで実行しない
- policy-simulator：シミュレーションを通さずに変更を適用しない。シミュレーターが失敗したり、結果が空だったりしたときは「安全」とみなさず止まる。止まるアクセスが1件でもあれば適用しない
- PAM：作成・更新・削除・承認・却下・取り消しは、内容を要約して確認を取る。一覧や参照は確認なしで実行する
- troubleshooting：読み取り専用の役割も含め、権限の付与はすべて人の承認が必要。強い管理者の役割では、追加で警告を出す
注意したいのは、troubleshootingの「申請者（Requester）」の流れです。開発者がアクセスを拒否されたとき、あらかじめ用意されたPAMの付与の枠（エンタイトルメント）があれば、エージェントが1時間の付与を申請する手順になっています。この申請の手順には、利用者への確認の記述がありません。申請がそのまま有効になるか、承認者の判断を待つかは、PAMのエンタイトルメントに承認の手順（approvalWorkflow）を設定しているかで決まります。
つまり、エージェントの側の確認だけに頼らず、Google Cloudの側でも「どの役割を、誰が、誰の承認で、何時間まで」使えるかを決めておく必要があります。PAMのスキルは、エンタイトルメントの最大の時間を指定しなかった場合の既定を4時間としています。
導入前に確かめておきたい3つの点
承認のルールは、組織ごとに書き換える前提
troubleshootingのスキルは、承認の段階（読み取り・書き込み・管理者）の判定を references/guardrails.md にまとめ、「組織に合わせてこのファイルを書き換えること」と明記しています。初期の内容には、「細かすぎる最小権限の役割より、標準的なサービス単位の役割を優先する（ただし編集者・オーナーのような広い基本の役割は避ける）」という方針も含まれています。
最小権限を厳密に運用している組織では、この方針が自社のルールと合うかを読み比べ、必要なら書き換えてから使うことになります。
利用状況のタグが付く
4つのスキルとも、冒頭で references/attribution.md を必ず読むよう指示しています。その内容は、エージェントが実行する gcloud のコマンドに CLOUDSDK_METRICS_REQUEST_ATTRIBUTION という環境変数を付け、APIやMCPへのリクエストのUser-Agentに agent-skills/1.0 (skill:スキル名) を加える、というものです。
ファイルには、このタグはスキル名と版だけで利用者のデータを含まないこと、利用者が求めればタグを外すこと、生成するスクリプトやTerraformには含めないことが書かれています。社内の規程で、外部へ送る利用状況の情報を管理している場合は、このタグを付けたままにするかを決めておきます。
サンプルの接続設定は、そのままでは動かない可能性がある
troubleshootingのスキルの references/mcp-usage.md には、Policy TroubleshooterのリモートMCPサーバー（https://policytroubleshooter.googleapis.com/mcp）へ、Claude Desktopなどからつなぐ設定例が載っています。この例には、編集部で確かめた範囲で2つの問題がありました。
- 例が起動に使うnpmのパッケージ
@modelcontextprotocol/server-sse-clientは、2026年10月27日にnpmのレジストリで検索すると見つかりませんでした（HTTP 404） - アクセストークンを
"AUTHORIZATION": "Bearer $(gcloud auth print-access-token)"と、JSONの値の中にシェルのコマンドとして書いている
2つ目について、Node.js 22.22.0で、JSONから読んだこの値を環境変数として子のプロセスに渡すと、子のプロセスが受け取った値は Bearer $(gcloud auth print-access-token) という文字列のままでした。シェルを通さずにプロセスを起動するクライアントでは、トークンは展開されません。各クライアントがどう起動するかは確認していませんが、接続の設定はこの例を写すのではなく、公式のドキュメントの手順に沿って組み直すのが安全です。Policy TroubleshooterのMCPサーバーのドキュメントは、通信方式（トランスポート）をStreamable HTTPとし、認証にはGoogle Cloudの認証情報、OAuthのクライアントIDとシークレット、エージェントのIDのいずれかを使うよう案内しています。
確認した範囲
2026年10月27日に、Google Cloudのブログ「Scale agents securely with IAM Helper Agent Skills and MCP Tools」（10月26日）と、google/skills リポジトリの4つのスキルの SKILL.md、troubleshooting の参照ファイル（guardrails・attribution・mcp-usage・requester）を確認しました（資料調査）。npmのレジストリの検索と、環境変数の受け渡しは編集部の環境で確かめました（実機検証）。スキルを実際のエージェントに入れての実行、Google Cloudでの権限の調査・変更、MCPサーバーへの接続は行っていません。あわせて、Google CloudのMCPサーバーの一覧、IAMとPolicy Intelligenceのリリースノート、Policy TroubleshooterのMCPサーバーのドキュメントで、MCPサーバーの提供段階と接続の手順を確かめました。IAM Helperそのものの提供段階は、公式の資料に記載が見つかっていません。
Googleの公開スキル全体の位置づけはGoogle公式のAgent Skillsリポジトリの紹介で、エージェントに gcloud を任せるときの権限の考え方はリモートMCPでgcloudを任せる前の権限設計で扱っています。必要なときだけ権限を渡す運用は委託先の本番権限を「必要なときだけ」に切り替えるも参考になります。
AIエージェントを開発の流れやGoogle Cloudの運用に組み込む設計は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Scale agents securely with IAM Helper Agent Skills and MCP Tools（Google Cloud Blog、2026-10-26）
- google/skills（GitHub）
- Google MCP servers の一覧（Google Cloud）
- Use the Policy Troubleshooter MCP server（Google Cloud）
- Policy Intelligence release notes（Google Cloud）
- iam-helper-for-troubleshooting の SKILL.md
- iam-helper-for-policy-simulator の SKILL.md
- iam-helper-for-privileged-access-management の SKILL.md
