用語解説（本編に入る前に）
受肉（じゅにく）: 姿を持たない存在がアバター＝肉体を得ること。本記事では「テキストしか出力しない AWS のサービスに、キャラクターの姿と声を与えること」の意味で使います。
0. AWS DevOps Agent
こちらの素晴らしい記事をご参照ください
1. AWS DevOps Agentを受肉させた
AWS DevOps Agentは賢いです。自律調査を始め根本原因分析までやってくれます。
「障害の一次調査」は本当に機械に渡せる時代になったと感じました。
でもこの賢い頭脳には姿がありません。出力はテキストだけ。しかもその行き先は——Slack/メール/チケットです。つまり他の通知に混ざって既読スルーの海に沈んでいきます。
そこでこの賢い頭脳に声と肉体を与えてみました。
受肉したエージェントはこう口を開きます___
「ご主人さま、大変です。ECSサービスで異常を検知しました。調査を開始します。」
裏では魂であるDevOps Agentが自律的に原因を掘り下げています。そして数分後、彼女がもう一度口を開きます。
「ご主人さま、調査が完了しました。原因はタスクのメモリ不足とのことです。」
Slackを開く必要はありません。異常の検知も、その後の根本原因も、受肉したエージェントの声で、二段階で耳に割り込んでくる。この記事はDevOps Agentそのものの解説ではなく賢い頭脳に声と肉体を与えその出力を「キャラクターの声」として届けるまでの経路——受肉の話です。
2. AWSのSNSはプッシュ型ではなくプル型である（持論）
Slack・メール・通知はシステム的には“プッシュ型”のようでいて、人間視点で見るとプル型であると私は思っています。見に行かないと情報を得られないし見に行った先では他の通知に埋もれています。
音声は逆です。画面から目を離していても別ウィンドウで作業していても、耳には届く"プッシュ型"です。真のプッシュ通知を実現したかったので音声通知という手法を取り入れました。
そして、どうせ音声にするなら無機質な読み上げではなくキャラクターに喋らせたいっ！
音声にキャラクターの見た目が伴い、通知が「情報」から「報告してくれる相棒」になると障害対応の心理的なハードルが下がるのではないかと期待しています。
3. 構成の全体像
- AWS DevOps Agent ＝ 自律的に障害を調査する頭脳部分
- EventBridge + Lambda + IoT Core（イベント配信経路） ＝ 調査結果をローカルクライアントまで運ぶ（MQTTで配信）
- Aivis Cloud API（クラウド音声合成）
- ローカルクライアント（常駐画面） ＝ MP4モーション動画＋ブラウザ常駐のキャラクター画面
クラウド側で「調査→セリフ化→配信」、ローカル側で「受信→音声合成→再生」を行います。
経路は二段階です。① アラーム発火の瞬間、検知Lambdaが CreateBacklogTask APIをIAM認証で呼んでDevOps Agentの調査を起票しつつ、検知の第一報を即座に鳴らします。② 数分の自律調査が終わるとDevOps AgentがEventBridgeに完了イベントを出し、③ そのイベントを受けた続報Lambdaが ListJournalRecords でサマリ本文を取りに行き、④ Amazon Bedrock（Claude Haiku 4.5）にConverse APIで読ませてセリフを生成させたうえで、原因を続報として鳴らします。①と②で使う配信路は共通です。
| 構成要素 | 役割 |
|---|---|
| AWS DevOps Agent | 調査の頭脳。自律的にRCAを行い、完了をEventBridgeで通知する |
| Lambda（検知／続報） | セリフ編集係。第一報と、ListJournalRecordsで取得したサマリの続報を口調に変換 |
| Amazon Bedrock（Claude Haiku 4.5） | 続報Lambdaが呼び出し、調査サマリをメイド口調のセリフに生成する（失敗時は正規表現ベースの抽出にフォールバック） |
| AWS IoT Core | 配信路。MQTTでローカルへ届ける |
| ローカルブリッジ（Node.js） | 購読してブラウザへWebSocket中継 |
| ブラウザ（常駐キャラ画面） | 再生キュー管理・セリフのテロップ表示・MP4モーション再生 |
| Aivis Cloud API | クラウド音声合成。ローカルブリッジが /tts 経由でBearer認証で代理呼び出しし、MP3を返す |
4. 設計判断：口調はDevOps Agentに混ぜない
4.1 口調はDevOps Agentに混ぜない
最初に考えたくなるのは「SKILL.mdに『キャラの口調で報告して』と書けば一発では？」という案です。これは採用しませんでした。
- 演出指示が調査の推論に干渉する。「ご主人さまと呼べ」という指示は、RCAという本来の仕事のコンテキストを汚します
- エージェント出力はブレる。生成のたびに文体が揺れるので、キャラの口調を固定できません
そこで、DevOps Agentには機械可読な構造化サマリだけを出させ、セリフ化は後段のLambdaに任せる役割分離にしました。DevOps Agent（非決定的で賢い）と口（後段Lambda）を分ける、という整理です。Amazon Bedrockでサマリを口調に生成させています。
4.2 通知はポーリングではなくMQTTのプッシュ配信
クラウドからローカルへ結果を届ける方法として、DynamoDBに結果を保存してローカルからポーリングする方式も候補にありました。しかしポーリングは一定間隔での取得であり、2節の「音声はプッシュ型」という主張と矛盾します。即座に耳へ届けたいのに、ポーリング間隔の分だけ遅延するのでは本末転倒です。
そこで採用したのがAWS IoT CoreのMQTTです。ローカル常駐クライアントはトピックを購読しておくだけで、Lambdaがpublishした瞬間に通知を受け取れます。DynamoDBポーリングが「プル型」なのに対し、MQTT購読は「プッシュ型」——2節の議論をそのまま配信方式の選定にも適用した形です。
5. 実際にやってみた
テスト用に存在しない関数を参照するlambdaを用意しました。
CloudWatchアラームでエラーを検知します
いざ実行！エラーになりましたね。アラームも発動しています。
DepOpsAgentも見てみましょう。解析していますね。
キャラクターの動き（アラート報告→分析報告→解除報告）
アラートの発動とほぼ同時に喋り出します！
6. まとめ：あなたの推しサービスも受肉させてみては？
- テキスト出力はプル型で埋もれますが、声はプッシュ型で耳に割り込みます。詳細確認は字幕・ログに任せれば、両方のいいとこ取りができます
- 設計の核は魂と口の役割分離です。魂（DevOps Agent）には機械可読な構造化サマリだけを出させ、口の仕事＝セリフ化は後段Lambdaに任せる。境界はMQTTペイロード契約ひとつなので、魂の側は差し替え可能です
今回受肉させた相手はDevOps Agentでしたが、神経系（EventBridge＋Lambda＋IoT Core）とMQTT契約さえ守れば、いろんなサービスに受肉可能です。あなたの推しサービスも受肉させてみませんか？
参考リンク
- AWS DevOps Agentが一般提供[GA]になりました（DevelopersIO）
- Integrating DevOps Agent into event-driven applications using Amazon EventBridge
- AWS DevOps Agent API Reference（CreateBacklogTask・ListJournalRecords ほか）
- AWS DevOps Agent IAM Permissions
- aws-samples/sample-aws-devops-agent-cloudwatch（Webhook構成の公式サンプル）
- AWS DevOps Agent Pricing
- Announcing General Availability of AWS DevOps Agent（根本原因精度94%の出典）