Amazon Q Developer in chat applications

Amazon Q Developer in chat applications（旧AWS Chatbot）は、SlackやMicrosoft TeamsとAWSをつなぐChatOps機能です。通知の整形配信、生成AIを使った調査、対応するAWS CLI操作をチャネル内で行えます。2025年2月の改称後も既存のAPI、IAM名前空間、エンドポイント、設定は継続します。

解決する課題

• アラームや障害通知をメールやコンソールで個別に確認しており、チームの初動が遅れる → 普段使うチャットに集約して即座に気づきたい
• 通知を受けてからAWSコンソールにログインし直して調査するのが煩雑 → チャットからそのまま状況を確認・操作したい
• 通知が生のJSONで届いて内容が読み取りにくい → 重要度やリソース情報を整形して見やすく届けたい
• チャット経由の操作に過剰な権限が紐づくのが怖い → 実行できる操作の範囲を安全に絞り込みたい
• インシデント対応のやり取りや判断の経緯がチャットに残らない → 通知から対応までを同じ場所で記録したい

主要概念と用語

• 設定済みクライアント（Configured Client）: Amazon Q Developerと連携させたSlackワークスペースまたはMicrosoft Teamsのチーム。最初に一度だけ承認・登録する
• チャネル設定（Channel Configuration）: 通知を届ける個々のチャンネルと、そこで使うIAMロールや通知元をひも付けた設定単位
• IAMロール（チャネルロール）: チャットからコマンドを実行する際に引き受けるロール。この権限がチャット経由で実行できる操作の上限になる
• ガードレールポリシー（Guardrail Policy）: チャネルロールに重ねて適用する上限ポリシー。許可される操作の範囲を全体として制限する
• SNSトピック連携: 通知の入口。CloudWatchアラームやEventBridgeなどがSNSトピックに発行したメッセージを Chatbot が受け取りチャンネルへ転送する
• 通知（Notifications）: チャンネルへ届くアラームやイベントのメッセージ。重要度やリソース情報を整形したカード形式で表示される
• コマンド実行（Run Commands）: チャットにコマンドを入力してAWS操作を行う機能。読み取り系の確認から一部の変更操作まで対応する

仕様・制限・クォータ

• 連携先のチャットツールはSlackとMicrosoft Teamsに対応する。チャンネルごとに チャネル設定 を作成して通知元と権限をひも付ける
• 通知の入口は基本的に SNSトピック で、CloudWatchアラーム・EventBridgeルール・Budgetsなど多くのサービスがSNS経由で通知を送れる
• チャットから実行できるのは 読み取り中心のAWS CLIコマンドで、一部の操作はチャット経由では実行できないよう制限される。実行可能な範囲はチャネルロールとガードレールで決まる
• 1つのチャンネルに複数の通知元（複数のSNSトピック）をひも付けたり、複数チャンネルへ通知を出したりできる
• ワークスペース・チームやチャネル設定の数にはアカウント単位のクォータがあり、必要に応じて上限緩和を申請できる
• 近年はサービスのブランドが Amazon Q Developer in chat applications として案内される場面があるが、提供される連携機能の位置づけは同じである

内部の仕組み

横にスクロール

Amazon Q Developer in chat applicationsは、通知配信、対話調査、コマンド実行を担います。通知の流れでは、AWS User NotificationsやSNSトピックからメッセージを受け取り、重要度やリソース情報を整形してSlackまたはTeamsへ転送します。

コマンド実行の流れでは、利用者がチャンネルでコマンドを入力すると、Chatbot がそのチャンネルの チャネル設定 に紐づく IAMロール を引き受けて操作を実行します。実行できる操作はこのロールの権限の範囲に限られ、さらに ガードレールポリシー を重ねることで、ロールが広めでも全体として許可される操作を絞り込めます。

設計パターン / ベストプラクティス

• 通知の入口をSNSに統一する: アラームやイベントを一度SNSトピックに集約し、そこから Chatbot に渡す構成にすると通知元の追加・変更が容易になる
• チャンネルを用途で分ける: 本番アラート用、コスト通知用、開発向けなどチャンネルを分け、それぞれに適した通知元と権限をひも付ける
• 権限は最小限から始める: 最初は読み取り中心の権限に絞り、必要に応じて操作権限を足していく。ガードレールで全体の上限を固定しておく
• 重要度でフィルタする: すべてのイベントを流すとノイズになるため、EventBridgeやアラームのしきい値で重要な通知だけをチャンネルへ送る
• インシデント運用に組み込む: アラーム受信からチャットでの一次調査・連絡までを同じチャンネルで完結させ、対応の経緯を残す

運用・監視

• どのチャンネルにどの通知元・どのIAMロールがひも付いているかを定期的に棚卸しし、不要なチャネル設定を整理する
• チャット設定やコマンド実行に関する API 操作は CloudTrail、通知の配信状態は CloudWatch のログ・メトリクスや連携元で追跡する
• 通知が届かない場合は、SNSトピックの購読設定・チャネル設定・チャットツール側のアプリ承認のいずれかを順に確認する
• ノイズが多い場合は通知元のしきい値やイベントパターンを見直し、本当に必要な通知だけが流れる状態を保つ

コスト

通知配信、CLI操作、チャットアプリ内の生成AI機能は追加料金なしで利用できます。SNS、CloudWatch、EventBridgeなどの連携元や、コマンドが操作する各AWSサービスには通常の料金が発生します。

セキュリティ

• チャット経由で実行できる操作は チャネルロール の権限に限られる。本番リソースを変更しうる権限は付けず、読み取り中心に絞るのが基本
• ガードレールポリシー を全チャネルに適用し、たとえロールが広めでも実行可能な操作の上限を固定する
• 連携するSlackワークスペースやMicrosoft Teamsのチームは信頼できるものに限定し、誰がチャンネルで操作できるかをチャット側の参加管理でも制御する
• チャネル設定やチャットからのコマンド実行など、サービスの API 操作は CloudTrail に記録される。通知本文の配信そのものがすべて CloudTrail に残るわけではないため、配信状態は連携元や CloudWatch 側でも確認する
• 機密性の高い情報を含む通知をチャンネルへ流す場合は、チャンネルの公開範囲と参加メンバーを管理し、不要な共有を避ける

関連サービス・比較

Amazon SNSは汎用メッセージ配信基盤、Amazon Q Developer in chat applicationsはチャット向けの 整形表示・対話調査・操作 を担います。SNSを入口、Amazon Qをチャット連携層として組み合わせられます。

ハンズオン / CLI例

# 通知の入口となるSNSトピックを作成
aws sns create-topic --name ops-alerts

# CloudWatchアラームの通知先に上記SNSトピックを指定（ARNは前の出力を使う）
aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alerts

# 既存のSlack向けチャネル設定を一覧で確認
aws chatbot describe-slack-channel-configurations \
  --query "SlackChannelConfigurations[].{Name:ConfigurationName,Channel:SlackChannelName,Role:IamRoleArn}"