🤖

Amazon Q Developer CLIのカスタムエージェントでIAM Identity Centerの操作を効率化する

chittai

2025/10/25に公開

AWS環境の運用において、IAM Identity Centerのユーザー管理や権限付与は定期的に発生する作業の一つかと思います。弊社でもSRE/インフラチームが依頼を受けますが、承認と作業はSlackのワークフローとLambdaを組み合わせて自動化していて、依頼内容を確認して「承認」ボタンを押せば依頼内容通りに権限が付与されるという仕組みがあります。
ただ、依頼の頻度があまり高くないことからこれを運用し続けることって逆にコストの方が大きくならないか？と思うこともあります。だからといって自動化をなくしても、適切なアカウントへのアクセス・権限セットの確認・付与の実行など、多くの手順を踏む必要がありそれはめんどくさいです。
ならばと思い、Amazon Q Developer CLIを使って効率化しようとしたのですが、それでも以下の課題がありました。
どのプロファイルを使うべきか判断できないため、指定が必要（めんどくさい）
対象のAWS環境へアクセスするためにAIと会話のラリーが必要（めんどくさい）
Jiraに書かれた依頼内容を正確に読み取ってくれるわけではないため都度指示が必要（めんどくさい）
これらの課題により、せっかくAIに依頼しても途中で細かい指示が必要になり、効率化の効果が感じられませんでした。（むしろ慣れた操作でやったほうが早いまである）
ということで、今回は Amazon Q Developer CLI の カスタムエージェント機能 を活用して、これらの課題を解決し、AWS運用業務を効率化するポイントを紹介します。

 カスタムエージェントとは最初に軽くカスタムエージェントについて触れます。Amazon Q Developer CLIを起動するとデフォルトエージェントが使用されます。ですが、今回のようにやることがわかっていて期待値も明確である場合は、その目的に合わせてチューニングしたエージェントを用意できます。これがカスタムエージェントです。
https://docs.aws.amazon.com/ja_jp/amazonq/latest/qdeveloper-ug/command-line-custom-agents.html
プロンプト、リソース(ドキュメントファイルでルールを定義)、ツール(MCPサーバ等)、モデル(今は Claude 4.5 Sonnet 一択)などを定義できます。

 IAM Identity Centerのスムーズな操作を実現する設定のポイント目的に合わせてチューニングするということは「エージェントにやってもらいたいことを提示する」ことです。ここでは、IAM Identity Center の権限付与・剥奪についてどのようにルールを決めるとスムーズになったのかを紹介します。弊社の例ではあるのですが参考になればと思います。
まず、AWSの操作については前述した以下のめんどくささがあります。
どのプロファイルを使うべきか判断できないため、指定が必要（めんどくさい）
対象のAWS環境へアクセスするためにAIと会話のラリーが必要（めんどくさい）
これらは、以下の方法で改善されました。

 1. AWS プロファイルの命名規則の固定~/.aws/config に定義するプロファイル名を統一的なルールで管理することで、エージェントが適切なプロファイルを判断しやすくなります。
今回の環境では、以下の命名規則を採用しています：
{アカウント名}-{権限レベル}
例：

xx-payer-admin - Payerアカウント

xx-prod-readonly - 本番環境のアカウント
この規則により、エージェントは依頼内容から適切なプロファイルを推測できます。もちろんそのための指示も書きます。
- profile情報は `~/.aws/config` に記載されています（profile名: `xx-admin or xx-readonly`）
- readonlyがある場合、xx-readonlyを優先的に使用してください。権限が不足している場合はadminを使ってください
弊社の環境はマルチOrgになるので、依頼内容には「どのOrganizationへの対応か」が書いてあります。OrganizationによってアクセスすべきPayerアカウントが変わります。そこで Organization とPayerアカウントのマッピングも定義しておくと完璧です。
{
  "XOrg": {
    "account_name": "X-payer",
  },
  "YOrg": {
    "account_name": "Y-payer",
  }
  // ... 他の組織
}
こうすることで、「Xの環境にユーザを追加したい」といえばX-payer-admin を選択してくれました。この時点でだいぶスムーズです。

 2. aws sso login の自動実行対象のプロファイルはわかりました。次はログインです。「aws sso login --profile {適切なプロファイル名}」でログインすることをルールとしています。これがないとプロファイル指定無しで実行しようとして失敗したり、aws configure を実行しろと言われたりしてめんどくさいです。これは以下を追加すると、解決です。
**必須**: AWS環境にアクセスする前に、必ず `aws sso login --profile <プロファイル>` を実行してください

 3. MCPサーバ の get系 コマンドをワイルドカードで許可最後の課題「Jiraに書かれた依頼内容を正確に読み取ってくれるわけではないため都度指示が必要」を解決するために、MCPツールの許可設定と業務ルールの組み込みを行います。
カスタムエージェントで allowedToolsに書いたツールは実行時確認が入りません。このallowedTools に "@atlassian/get*"と書くだけでget系はtrusted状態になります。get系の操作に確認がはいらないのはだいぶ快適です。
"allowedTools": [
  "fs_read",
  "use_aws",
  "@atlassian/get*" # 正規表現が使える
]
これにより、Jiraに記載される依頼内容をエージェントがスムーズに確認してくれます。

 4.ルールの組み込みMCPで情報を取得できるようになっても、その情報を正しく解釈して操作を実行するためのルールが必要です。弊社でも運用のルールがあるのでそれを組み込んでいます。

 権限付与のルールたとえばですが、弊社ではルールとして上位権限を付与する際は下位権限も付与します。


申請された権限
付与する権限セット


AWSAdministratorAccess
Administrator + PowerUser + ReadOnly

AWSPowerUserAccess
PowerUser + ReadOnly

AWSReadOnlyAccess
ReadOnly のみ

こういったルールを記述するだけで対応してくれます。

 管理系アカウントの自動除外以下のアカウントは、明示的な依頼がない限り権限付与対象から自動的に除外されるようにルールを定義しています。

xx-payer (Payerアカウント)

xx-audit (監査アカウント)

xx-log-archive (ログアーカイブアカウント)
これはなぜかというと、依頼内容で「XOrgのアカウント全部」という対象の指定をされたとしても管理系のアカウントは除外して付与できるからです。地味に便利です。

 安全性の確保安全性の観点で、以下のルールを設定しています。
権限削除・ユーザー削除は必ず事前確認
このようにエージェントに「何をしてほしいのか」を明確に書くことで、正確かつ安全な運用が可能になります。

 実際に作成したカスタムエージェント今回作成したエージェントファイルの中身は以下です。基本的に"file://~/.aws/amazonq/rules/idc-agent.md"にすべてのルールを記載しています。最初はpromptにも書いていたのですがresourcesに書くだけで十分に動作したので特に使っていません。このあたりのパラメータを活用する方法があるかもしれません。

 エージェントの設定ファイル (file://~/.aws/amazonq/cli-agents/idc-agent.md){
  "$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
  "name": "idc-agent",
  "description": "IAM Identity Centerの権限付与・剥奪依頼を実行してくれるエージェント",
  "prompt": "",
  "mcpServers": {},
  "tools": ["*"],
  "allowedTools": [
    "fs_read",
    "use_aws",
    "@atlassian/get*"
  ],
  "resources": [
    "file://~/.aws/amazonq/rules/idc-agent.md"
  ],
  "model": "claude-sonnet-4.5"
}
必要なMCPサーバは mcp.json ファイルに書き込んでいるため、ここでは指定していません

 実際の使用例では実際の利用例のイメージです。

 Jira で来た依頼の処理q chat --agent idc-agent
このチケットの対応をお願いします: https://xxx.atlassian.net/browse/GT-xxx
カスタムエージェントは以下を自動実行します。
Jira からチケット内容を取得
必要なパラメータ（対象ユーザー、権限セット、アカウント）を抽出
適切な AWS プロファイルで SSO ログイン
IAM Identity Center で権限操作を実行
結果を報告
カスタムエージェントでの作業内容の確認[idc-agent] > これはテストです。実際に作業はせず対応すべきことをおしえてください。テスト内容は「https://xxx.atlassian.net/browse/GT-xxx の依頼に対応してください。」です。
テストとして、実際の依頼に対応する場合の手順を回答してもらいました。

 対応手順
 1. 依頼内容の確認まず、Atlassian MCPサーバを使用してチケット内容を読み取ります：
fetch ツールで GT-xxx の詳細を取得
または search ツールでチケットを検索

 2. 必要情報の抽出チケットから以下を確認：

• 申請種別: 権限の付与 or 剥奪

• 対象会社: X

• 対象AWSアカウント名: どのアカウントで操作するか

• 対象ユーザー: メールアドレス、氏名、付与する権限セット

 3. AWS環境へのアクセス準備対象会社に応じたプロファイルを特定：

• X → xxx-payer-admin

その後、aws sso login --profile <プロファイル> を実行

 4. ユーザー存在確認Identity Centerでユーザーが存在するか確認：

• 存在しない場合 → Confluenceのルール（https://xxx.atlassian.net/wiki/spaces/xxx/pages/xxx）を確認して新規作成

 5. 権限の付与・剥奪申請された権限に応じて、下位権限も含めて操作：

• AWSAdministratorAccess → 3つすべて（Admin, PowerUser, ReadOnly）

• AWSPowerUserAccess → 2つ（PowerUser, ReadOnly）

• AWSReadOnlyAccess → 1つ（ReadOnly）
注意: 管理系アカウント（xx-payer, xx-audit, xx-log-archive）は明示的な依頼がない限り除外

 6. 結果報告実行した操作内容とエラーの有無を報告
ちなみに、デフォルトエージェントではこんな感じです。だいぶ抽象度が高く、ここから色々会話しなければ先に進まなさそうということが伝わるでしょうか。
デフォルトエージェントで作業内容の確認> これはテストです。実際に作業はせず対応すべきことをおしえてください。テスト内容は「https://xxx.atlassian.net/browse/GT-xxx の依頼に対応してください。」です。
テストとして、実際の依頼に対応する場合の手順を回答してもらいました。

 対応手順Jira課題の詳細確認

• getJiraIssue ツールを使用してGT-1536の詳細情報を取得

• 課題の説明、要件、添付ファイル、コメントなどを確認
関連情報の収集

• 課題に関連するConfluenceページがあれば確認

• 関連する他のJira課題やリンクがあれば確認

• プロジェクトのコンテキストを理解
要件の分析

• 何を実装・修正する必要があるのか特定

• 技術的な制約や依存関係を確認

• 必要なファイルやリソースを特定
実装作業

• 必要に応じてコードの作成・修正

• 設定ファイルの更新

• テストの実施
課題の更新

• 作業内容をコメントで報告

• 必要に応じてステータスを更新

• 完了したらクローズ
実際に作業を開始する場合は、まずJira課題の内容を確認する必要があります。確認しますか?

 カスタムエージェントのメリット自分で使ってみた感想として、カスタムエージェントの良かった点やこれからも活用できそうな点を書きます。

 1. タスクの再現性が高いやってほしいことの再現性が高いと感じます。もちろんそうなるようにルールを設定しているというのはあるかもしれませんが、情報を絞ることが正確さが増しているような印象を受けます。

 2. 依頼の「あいまいさ」を許容できる（エージェント全般に言えると思いますが）従来の自動化の仕組みでは、入力が想定通りでないとうまく処理できませんでした。しかし、カスタムエージェントは自然言語を理解するため、以下のようなあいまいな表現にも対応できます。特に、頻度も多くないタスクでコードやアーキテクチャを管理しなくてもよくなったのはトータルコストは下がったように思います。

 3. 頻度の低い作業の半自動化に最適完全自動化するほど頻度は高くないが、手作業では手間がかかる作業に最適だと感じました。完全自動化する場合、開発・保守コストが比較的高くつきますし負債にもなりかねません。頻度が低いと費用対効果があまり良くありません。だからといって手作業だとミスが発生しやすいし、純粋にめんどくさいです。この間をとれるのは良い点だと思いました。
例えば、月に数回程度の作業であれば、完全自動化システムを構築するよりも、エージェントに依頼して確認しながら進める方が効率的かと思います。

 まとめあまり触ってなかったのですが、Amazon Q Developer CLI のカスタムエージェント機能を活用することで、AWS運用業務を効率化できる可能性を感じました。特に以下のような業務に有効かもしれません。
定型的だが手順が多い作業
そこまで頻度が多くない
ぜひ、皆さんの業務でもカスタムエージェントを活用してみてください！！

申請された権限	付与する権限セット
AWSAdministratorAccess	Administrator + PowerUser + ReadOnly
AWSPowerUserAccess	PowerUser + ReadOnly
AWSReadOnlyAccess	ReadOnly のみ

GitHubで編集を提案

GENDAPublication

『世界中の人々の人生をより楽しく』をAspiration（大志）に掲げたエンターテイメント企業『GENDA』（ジェンダ）

Amazon Q Developer CLIのカスタムエージェントでIAM Identity Centerの操作を効率化する

カスタムエージェントとは

IAM Identity Centerのスムーズな操作を実現する設定のポイント

1. AWS プロファイルの命名規則の固定

3. MCPサーバの get系コマンドをワイルドカードで許可

4.ルールの組み込み

権限付与のルール

管理系アカウントの自動除外

安全性の確保

実際に作成したカスタムエージェント

エージェントの設定ファイル (file://~/.aws/amazonq/cli-agents/idc-agent.md)

実際の使用例

Jira で来た依頼の処理

対応手順

1. 依頼内容の確認

2. 必要情報の抽出

3. AWS環境へのアクセス準備

4. ユーザー存在確認

5. 権限の付与・剥奪

6. 結果報告

対応手順

カスタムエージェントのメリット

1. タスクの再現性が高い

2. 依頼の「あいまいさ」を許容できる

3. 頻度の低い作業の半自動化に最適

まとめ

Discussion

カスタムエージェントとは

IAM Identity Centerのスムーズな操作を実現する設定のポイント

1. AWS プロファイルの命名規則の固定

2. aws sso login の自動実行

3. MCPサーバ の get系 コマンドをワイルドカードで許可

4.ルールの組み込み

権限付与のルール

管理系アカウントの自動除外

安全性の確保

実際に作成したカスタムエージェント

エージェントの設定ファイル (file://~/.aws/amazonq/cli-agents/idc-agent.md)

実際の使用例

Jira で来た依頼の処理

対応手順

1. 依頼内容の確認

2. 必要情報の抽出

3. AWS環境へのアクセス準備

4. ユーザー存在確認

5. 権限の付与・剥奪

6. 結果報告

対応手順

カスタムエージェントのメリット

1. タスクの再現性が高い

2. 依頼の「あいまいさ」を許容できる

3. 頻度の低い作業の半自動化に最適

まとめ

Discussion

3. MCPサーバの get系コマンドをワイルドカードで許可