
【アップデート】AWS DevOps Agent の Slack連携に双方向コミュニケーション機能が追加されました
タイトルのとおり、DevOps Agent の Slack連携に 双方向コミュニケーション 機能が追加されました。
September 1, 2026: Chat with AWS DevOps Agent in Slack
You can now start and continue conversations with AWS DevOps Agent directly from a private Slack channel. Enable bidirectional communication when you associate a channel, then run a one-time setup command and chat using app mentions.
今までは 片方向(one-way)、つまり 「DevOps Agent から Slackチャンネルへメッセージを飛ばすだけ」でしたが、 本アップデートで こちらから DevOps Agent へ @メンション することで、 DevOps Agent が必要な調査を行い、その結果をチャットで返してくれるようになりました 。 Slack 上でリソースの状況を対話的に確認できます。
早速 この機能を使ってみました。
セットアップ1: Slackプロバイダーを追加する
すでにエージェントスペースは作成してある前提で進めます。 本ブログでは Slack 機能プロバイダーの追加から紹介します。 この部分がセットアップ済みであれば読み飛ばしていただいてOKです。
[AWS DevOps エージェント > 機能プロバイダー] ページにて Slack 機能の [Register] を選択します。

機能プロバイダー一覧の Slack を Register
デフォルト設定のまま [次へ] を選択します。

Slack を DevOps エージェントに登録する画面
Slack の許可画面に切り替わります。 「AWS DevOps Agent - AP (Tokyo)」アプリに対するアクセス許可を求められるので、 接続先のワークスペースを選んで [許可する] を選択します。

Slack アプリへのアクセス許可画面
セットアップ2: エージェントスペースへの関連付け
次はエージェントスペース側の作業です。途中で Slack チャンネルでの操作も挟みます。 注意点として、双方向コミュニケーション機能は プライベートチャンネルのみ対応 しています。 連携先のプライベートチャンネルを事前に用意しておきましょう。
設定したいエージェントスペースのページに移動します。
[機能 > コミュニケーション] より [統合を追加] を選択します。

エージェントスペースのコミュニケーション設定
先ほど登録した Slack プロバイダーが「登録済み」として並んでいるので、 [追加] を選択します。

登録済みの Slack プロバイダーを追加する
「このエージェントスペースを Slack チャネルに関連付ける」画面に移ります。 連携先チャンネルの [チャネルID] と [双方向通信] の設定を記入します。
双方向通信の設定では、利用するIAMロールを指定します。 今回は新規作成として、 [次へ] を選択します。

チャネルIDと双方向通信を設定する
次のステップでは、DevOps エージェントを Slack チャンネルへ招待するよう案内されます。 Slackチャンネル上で /invite @AWS DevOps Agent - AP (Tokyo) を実行しておきます。

DevOps エージェントをチャンネルへ招待する案内
[追加] を選択して関連付けは完了です。 コミュニケーション一覧に Slack 統合が追加されました。

双方向が「有効」で統合が追加された
チャットしてみる
最初にセットアップ
チャットを始める前に、チャンネル側で一度だけセットアップが必要です。 スレッド内ではなくチャンネルへの新規メッセージとして、 DevOps Agent へメンションして setup と送信します。
Channel bound to agent space が返ってくれば準備完了です。

setup 送信で Channel bound to agent space が返る
その1: Hello World
まずはシンプルにチャットしてみます。 メンションすると、こんな感じでスレッドに返信してくれました。

できることを一覧で返してくれた
その2: リソース調査
AWSリソースの調査を依頼してみます。 GuardDuty の 検出結果ARN を渡して、詳細を聞いてみました。
検出結果を取得したうえで調査し、レポートにまとめてくれました。 Webアプリ上でのチャットや調査機能と変わらず、 ちゃんとツール・スキルを使ってくれています。

GuardDuty Finding をスキルで調査しレポート化
同じスレッドに続けてメンションすると、 それまでのやりとりを踏まえた回答が返ってきます。

直前の Finding を踏まえて CloudTrail 証跡を回答
その3: ほかいろいろ
スレッドの途中からメンションした場合、 それ以前のメッセージ(メンションしていないところ) は拾ってくれないようです。

スレッド冒頭の内容は拾わず、対象を聞き返してくる
ただし、「DevOps Agent が通知として投稿した調査レポートのスレッド」 上で続けてメンションすると、その調査を把握したうえで回答してくれます。

DevOps Agent 調査スレ上で続けてやりとりできる
また、参照できるのはメンションされたスレッドの内容だけのようです。 チャンネル上の他のメッセージは取得できません。

チャンネルのメッセージ履歴は読めないとの回答
補足: CloudTrail イベントには何が残る?
Slack からチャットを開始すると、 CreateChat イベントが記録されます。 イベントソースは aidevops.amazonaws.com です。

CreateChat イベントがユーザー名付きで記録される
イベントの中身は以下のようなものです。
{
"userIdentity": {
"type": "AssumedRole",
"arn": "arn:aws:sts::999999999999:assumed-role/DevOpsAgentChannel-c6p7241t/DevOpsAgentChannel-c6p7241t-U09K654PA5A",
"sessionContext": {
"sessionIssuer": {
# 省略
"userName": "DevOpsAgentChannel-c6p7241t-U09K654PA5A"
}
},
"invokedBy": "aidevops.amazonaws.com"
},
"eventSource": "aidevops.amazonaws.com",
"eventName": "CreateChat",
"awsRegion": "ap-northeast-1",
"requestParameters": null,
"responseElements": {
"createdAt": 1788495194.265,
"executionId": "8ad6d51f-68d8-4c49-8c4e-36552b23bf09"
},
"resources": [
{
"type": "AWS::AIDevOps::AgentSpace",
"ARN": "arn:aws:aidevops:ap-northeast-1:999999999999:agentspace/0bce185d-a465-4c2e-a184-531c57855dc7"
}
]
}
セッション名やユーザー名は DevOpsAgentChannel-c6p7241t-U09K654PA5A のようになっています。 {双方向ロール名}-{SlackのユーザーID} の形式になっており、 誰がチャットを開始したかを (いちおう) 追えるようになっています。
おわりに
DevOps Agent の Slack双方向コミュニケーション機能を試してみました。
Webアプリをわざわざ開かなくても、 プライベートチャンネルに参加している方なら誰でも使えるのが良いですね。 普段の会話の延長でリソースの状況を聞けるので、利用のハードルはかなり下がりそうです。
一方で、管理者としてはコストトラッキングが大変そうだと感じました。 誰が実行したかは CloudTrail の証跡から追えるので、 実際にかかったコスト情報と突き合わせながら推算するのが良さそうです。
以上、参考になれば幸いです。






