AI エージェントを組織構造に乗せる – PLAY が AWS DevOps Agent で築いた全社共通のインシデント対応基盤

本ブログは株式会社 PLAY プラットフォーム本部 技術基盤部 技術推進グループ テックリード 市川 賢 様の監修のもと、アマゾン ウェブ サービス ジャパン合同会社 金目 健二が執筆いたしました。

AI エージェントの運用における課題

生成 AI の普及により、インシデント対応に AI エージェントを利用する取り組みが各社で進められております。一方で、検証環境では有用性が確認できても、実際に本番運用へ組み込む段階になると、エージェントの分析精度とは別のところで検討が止まるケースが見られます。「どこまでをエージェントに任せてよいのか」が組織内で合意されていないこと、複数のプロダクトを持つ組織において「誰がエージェントの動作を定義するのか」が決まっていないことがその要因です。この 2 点が定まらないまま精度の議論を進めても、組織としての運用には結びつきません。

本記事では、株式会社 PLAY（以下、PLAY）が AWS DevOps Agent（以下、DevOps Agent）を全社共通のインシデント対応基盤として利用するにあたり、決めた 2 つの設計（委譲範囲、組織）をご紹介します。実装の詳細は PLAY の技術ブログ「AWS DevOps Agent を活用したインシデント自動分析基盤」にて公開されておりますので、本記事ではそこで語られていない「なぜその設計を選んだのか」と、公開後に進んだ展開を中心にお伝えします。

PLAY が取り組んだこと

PLAY は、動画配信プラットフォームをはじめとする動画ソリューションを提供する企業です。「見たい人」と「見せたい人」がつながる世界をつくるためには、配信基盤に加え、コミュニケーションやインタラクション、認証や課金、視聴スタイルの変化に合わせた機能が必要となります。それぞれのコンテンツに適した仕組みを作り続けることをミッションとする PLAY では、性質の異なる複数のプロダクトが並行して稼働しており、その安定運用が事業の前提となっております。

本記事で取り上げる基盤は、プラットフォーム本部 技術基盤部 技術推進グループが中心となって構築しました。導入は 1 プロダクトから始まり、2026 年 9 月現在は 4 プロダクトと 1 つのソリューション案件で稼働しております。さらに 2 プロダクトで導入準備が進められております。

DevOps Agent は、AWS・マルチクラウド・オンプレミスを横断する運用支援エージェントです。インシデントの根本原因分析、予防的な対応、オンデマンドの SRE タスクを担います。マネージドサービスとして提供されているため、エージェント本体の実行環境やモデルを自前で構築する必要がなく、運用タスクに閉じた用途であれば短期間で利用を開始することができます。

PLAY においても、まず動かしてみるところから取り組みが始まりました。技術推進グループ テックリードの市川 様は「AWS DevOps Agent 自体は高い精度でインシデントを分析してくれる優秀なサービス」と述べています。分析精度は当初から十分な水準にありましたが、既存の運用フローにそのまま組み込めたわけではありませんでした。何が課題でどう解決していったのかを、次節から記します。

手作業で行われていた一次対応

本番環境でエラーが発生すると Slack にアラートが通知されます。エンジニアがログを確認し、コードを調査し、GitHub に Issue を起票し、修正を行う、という一連の作業を PLAY では毎回手動で行っておりました。一次調査だけで 1 件あたり 15 分から 1 時間を要しており、エラーの発生頻度が高い環境では、同様のエラーが発生するたびに同じコストが掛かる状況でした。

これらの作業をインシデント対応基盤に任せることを検討するにあたり、PLAY は 2 つの課題に直面しました。

①に対する答えが設計 1、②に対する答えが設計 2 となります。

これらの設計を反映した基盤の概要構成を以下に記します。

図 1: インシデント対応基盤 概要構成図

当基盤は、共通基盤チームが構築・運用する部分（図中「共通基盤」）と、各プロダクトチームが自身の AWS アカウントで運用する部分（図中「各プロダクトチームの AWS アカウント」）に分かれており、アラートの発生から人の判断までは次の流れで処理されます。

• Slack のエラー通知（各種監視サービスからアラートが Slack へ飛ぶ）、または Amazon CloudWatch Alarm を共通基盤の AWS Lambda が受信し、正規化する（①）
• Amazon DynamoDB 上の過去アラートと SimHash を基に照合し、類似アラートかどうかを判定する（②）
• 類似アラートと判定された場合は、関連する Issue を元の Slack スレッドに返信し、DevOps Agent は起動しない（③）
• 類似アラートでない場合は、AWS Systems Manager Parameter Store のルーティング設定を参照し（④）、該当サービスの AWS アカウントで動作する DevOps Agent へ Webhook で調査を依頼する（⑤）
• DevOps Agent はプロダクトチームが記述した調査スキルに従い、CloudWatch Logs、GitHub、New Relic を調査する（⑥）
• 調査の過程で、MCP 基盤を経由して Issue 番号の記録や過去インシデントの参照を行う（⑦）
• 調査の進捗と結果は、元の Slack スレッドへ 3 段階（開始 → 原因候補 → 完了）で報告される（⑧）
• 担当エンジニアが結果を確認し、修正に着手するかを判断する（⑨）

この構成のうち、⑥〜⑨で「DevOps Agent がどこまでを担い、人がどこから引き継ぐか」を決めたのが設計 1（委譲範囲）、共通基盤と各プロダクトの AWS アカウントの境目で「誰が何を作るか」を決めたのが設計 2（組織）です。

設計 1: 委譲範囲の決め方

本節は、インシデント対応の自動化範囲についてチーム内の合意が取れていない方に向けた内容となります。

一次トリアージへの限定

PLAY が最終的に目指しているのは、DevOps Agent を起点に原因調査を行い、必要であればコード修正と Pull Request の作成まで自動で行い、承認を経てマージ、デプロイまでつなげることです。しかし、最初からそこまでを対象とはしませんでした。市川 様は次のように述べています。

「最初からそこまでを対象にすると、調査の精度が固まっていない段階で修正やデプロイまで自動化することになり、運用に乗せるのは難しいと考えました。そこで、まずは一次トリアージ（原因の調査と Issue 起票）に範囲を絞り、その精度を高めることに注力する判断をしました。」

全工程を渡すのでも、人が全工程を行うのでもなく、一次トリアージという範囲を切り出して任せる、という判断です。当初の線引きは「原因の調査と Issue 起票まで」でした。運用を重ねる中で、調査結果が Slack スレッドに返ってきた時点で対応が完結するケースが多いことが分かり、Issue は「起票されたが確認して閉じるだけ」になりがちでした。そのため、Issue が必要な場合のみ起票するよう DevOps Agent のスキルで調整しました。プロダクトによっては 7〜8 割のアラートが Slack 上の返信で完結しているとのことです。

現在の役割分担は以下の通りです。

エージェントが担うのは調査と報告までであり、修正に進むかどうかの判断は原則として人が行います。人が Issue に @play fix とコメントすることで、PLAY が自前で用意したコードレビュー・修正の仕組みが Pull Request を作成し、そのレビューとマージは人が行う流れとなっております。なお、調査結果の確度が高い一部のケースでは、この @play fix コメントを DevOps Agent 自身が行う運用も始まっております。詳細は「今後の展望」にて記します。

この線引きにより、エージェントの分析が的を外した場合でも業務に影響が及びません。Slack スレッドの報告を読んだ人が気づくことができます。一方、最も時間を要していた「どこを見るべきか探す」工程は人の手を離れることとなります。

スキルファイルによる範囲の明文化

DevOps Agent の動作は、マークダウン形式のスキルファイルで定義します。PLAY はこのスキルファイルに、エージェントに任せる範囲をそのまま記述しております。調査から起票・通知までを 9 つのステップに分け、それぞれで呼び出すツールを明示したものです。

ステップに分けておくことで、エージェントが何をどの順で行うかがドキュメントとして残ります。任せる範囲が曖昧なまま動かした場合、想定外の動作が起きた際に原因を追うことが困難となります。ステップ単位で定義することは、動作を安定させることに加え、何が起きたかを後から説明できる状態を作ることにもつながります。前述の「不要な Issue を作らない」という調整も、Step 6 の条件をスキルに書き足すことで実現しております。

スキルの具体性と調査の質

スキルファイルの書き方について、PLAY が運用を通じて得た知見があります。技術ブログには次のように記されています。

「スキルファイルの書き方そのものが調査の精度とスピードに直結する。Agent 自体は強力でも、スキルが曖昧だと毎回ゼロから調査範囲を探索することになり、結果として『分析に時間がかかる (= 課金が増える)』『見るべき場所を取りこぼす』といった問題が起きる。」

特に効果があったのは、「このアラートやエラーパターンが来たら、どこを最初に見に行くべきか」を具体的に記述することでした。

• CloudWatch ロググループ — 「xxx というエラーメッセージが来たら、まず /aws/foo-handler のログを ${時刻} – 5 分 の範囲で確認する」のように、エラー文字列とロググループの対応を列挙する
• GitHub リポジトリとパス — 「このアラートの対象はモノレポの services/foo 配下なので、コード調査は該当リポジトリの services/foo に絞る」のように、ディレクトリ単位まで明示する
• メトリクス — 該当時刻のメトリクスを確認する場合は、ダッシュボードの URL や関連クエリも併記する

この点は実装前の想定と最も異なっていた部分であったと、市川 様は次のように述べています。

「調査対象のモジュールに対して、どの CloudWatch のロググループや New Relic のエンティティが対応するかというマッピングをスキルに記載しておくと、エージェントが迷わず調査を進められます。エージェント自体の能力よりも、この対応関係をどれだけ具体的に渡せるかが結果を左右する、というのが実装前の想定と違った点でした。」

このマッピングは、PLAY のスキルでは「モジュールマップ」として次のような形で記述されております。以下はサービス名や識別子を架空のものに置き換え、内容を汎化した抜粋です。

表の各行には、リソースの対応関係だけでなく「ECS と Lambda の両方で動いており片方だけ見て再現しないと結論しない」、「APM が入っていないモジュールがある」、「Blue/Green のどちらが現用系かはタスク数と ALB の重みで判定する」といった、エージェントが単独では誤りやすい事実が注記として書き込まれております。命名規則から推測させると必ず間違える点を、稼働環境で確認した事実として先に潰しておく、というのがこのスキルの書き方です。

効果は調査時間に表れております。スキルをほとんど用意していなかった導入初期には 1 件の調査に 15〜20 分程度を要しておりましたが、スキルを具体化した現在は 5〜10 分程度で完了しております（初期の計測は数回分のため、参考値となります）。

Slack スレッドでの判断

エージェントに調査を任せると、人は「今どこを見ているのか」を把握しづらくなります。PLAY では、人が判断を行う場所を Slack のスレッドに置きました。

アラートが通知されたスレッドには、そのとき誰が何を話したかという文脈が残っております。調査結果が別の場所に投稿されると、その文脈から切り離されてしまいます。加えて、PLAY ではどのプロダクトにおいても、アラートが通知されたスレッドに担当者が調査の進捗を書き込んでいく運用が既に定着しておりました。エージェントの調査結果も同じスレッドに返すことで、担当者は普段と同じ場所を見るだけでよく、新しいツールや手順を覚えることなくエージェントを既存の運用に取り込むことができます。問題が起きた元のスレッドに結果が返ることは、文脈の維持と既存運用との接続の両面で重要でした。

調査の進捗は 3 段階で元のスレッドに返されます。

1. 調査開始時 — 対象のエラーとリポジトリを提示
2. 原因候補の特定時 — 対象ファイルと行番号、原因候補の説明
3. 調査完了時 — 根本原因、影響のあるコード、関連コミット、修正の方針、Issue を作成した場合はその URL

段階を分けている理由は、人が途中で介入できるようにするためです。原因候補の時点で見当違いだと分かれば、完了を待たずに人が動くことができます。前述の通り、多くのアラートはこの 3 段階目の報告を読んだ時点で対応が完結しております。

原因を特定できなかった場合の出力
実運用において分かれ目となったのは、エージェントが答えを出せなかった際の出力を事前に決めておくことでした。

AI エージェントの導入検討では「どれくらい正しく答えられるか」に議論が集まりがちです。PLAY の運用では、プロダクトによっては 7〜8 割のケースで根本原因の特定に至っております。一方、運用に乗せた後は、残りの正解を出せなかったケースの扱いが品質を左右します。何も返ってこなかったり、自信のない推測だけが返ってきたりすると、人はエージェントの出力を信用しなくなります。

PLAY のスキルファイルには、根本原因を特定できなかった場合の専用フォーマットが用意されております。返す内容は以下の 3 点です。

• 調査内容 — 確認したファイル、参照したログ、確認したメトリクス
• 判明した事項 — 根本原因が不明であっても、分かった事実は記載する
• 修正の方針 — 次のステップ、追加で調査すべき領域

「分かりませんでした」で終わらせず、人が続きを引き継げる状態で返す設計です。特定に至らなかったケースでも調査済みの範囲が記録されているため、人による再調査を初手から始める必要がありません。任せる範囲を決めるということは、うまくいったときの範囲だけでなく、うまくいかなかったときの振る舞いまで決めることであったと言えます。

設計 2: 組織での分担

本節は、複数のプロダクトを抱える SRE / プラットフォームチームや CCoE の方に向けた内容となります。

難所となったサービス固有の調査手順

基盤を作る過程で分かったことは、DevOps Agent の活用において本当に難しいのは各サービス固有の調査スキルを書く部分である、という点でした。

どのリポジトリを見るのか、どの CloudWatch ロググループを参照するのか、どの New Relic エンティティが対応するのか、どの GitHub Organization に Issue を起票するのか。いずれもサービスの中身を最もよく知っている担当者にしか書けません。共通基盤を作るチームが全プロダクトのドメイン知識を持つことは現実的ではありません。

一方で、それ以外の部分は横展開が可能です。Slack イベントの受信、ルーティング、重複したアラートの排除、MCP によるツール提供、Slack スレッドへの戻し制御は、プロダクトが変わっても同じ仕組みで対応できます。

「基盤の仕組み」と「ドメイン知識」を分けることが、PLAY の組織設計の起点となりました。

共通基盤チームとプロダクトチームの線引き

この分担により、プロダクトチームは自分たちが詳しい部分の記述に集中でき、共通基盤側のインフラ運用を意識する必要がありません。共通基盤チームも、プロダクト内部のドメイン知識を持たずに運用を成り立たせることができます。どちらのチームも自分が知っていることだけを担当すれば動く、という状態を作ったことが、複数プロダクトへの展開を可能にしました。

設計 1 で述べたスキルファイルを書くのはプロダクトチームであり、それに沿ってエージェントが動く土台を用意するのが共通基盤チームという関係になります。

スキルを記述したプロダクトチームは次のように述べています。

「これまでチーム内で統一してきた調査方法や報告フォーマットに、各システムの技術スタックや AWS のインフラ構成を加えてスキルに書き起こしたもので、いずれも普段から自分たちが持っている情報だったため自前で書き切れました。調査対象のシステムさえずれていなければ調査内容は基本的に信頼しており、報告される【確度】を見て、必要な部分だけ人が追加で事実確認を行っています。」

ここで述べられている確度は、調査結果の根本原因に付与される【確定 / 有力 / 推定】のラベルです。権限や経路の制約（参照する MCP がないなど）により取得できない情報がある場合は確度が下がるようにスキルで定義されており、人はこのラベルを見て事実確認の要否を判断しております。

アカウント分離による責任範囲の明確化

各プロダクトチームの DevOps Agent は、その AWS アカウントで動作します。

権限とリソースが分離されることに加え、責任の範囲がアカウント単位で定まります。どのサービスがどれだけエージェントを利用したかがアカウントごとに分かれるため、「誰の責任範囲か」を運用の都度議論する必要がありません。組織で共有する基盤ほど、この境目を仕組みで決めておくことの価値は高まります。

新規プロダクトの追加手順

新しいプロダクトを基盤に載せる手順は以下の 3 点です。

1. プロダクトチームが自アカウントに Agent Space を作成する
2. プロダクトチームがサービス固有の調査スキルを記述する
3. 共通基盤チームがルーティング設定に Webhook URL を 1 行追加する

ルーティング設定は AWS Systems Manager Parameter Store の SecureString で管理されており、Lambda の再デプロイなしで変更することができます。Slack のチャンネル単位、CloudWatch のアラーム単位で、呼び出す DevOps Agent を切り替えることが可能です。

共通基盤側の作業がエントリ 1 件の追加で済むため、展開のボトルネックはプロダクトチーム側のスキル記述のみとなります。1 プロダクトから始まった導入は、現在 4 プロダクトと 1 つのソリューション案件に広がり、2 プロダクトで導入準備が進められております。

2 つの設計を支える作り込み（PLAY 技術ブログ公開時点）

2 つの設計を実運用に乗せるために、PLAY が自前で用意した部分をご紹介します。本節は技術ブログ公開時点（2026 年 6 月）の構成であり、その後の変化は「その後の発展」にて記します。

注記: 本節の内容は、執筆時点の DevOps Agent の機能を前提とした補い方です。DevOps Agent 側の機能追加により、将来的には自前で用意する必要がなくなる部分もあります。設計 1・設計 2 が経路や機能の変化に依存しないのに対し、本節は時点依存の内容としてお読みください。

MCP サーバーによる外部連携

DevOps Agent はセキュリティ上の理由から、スキルから直接 HTTP リクエストを発行したり Lambda を呼び出したりすることができません。この制約は実装して初めて分かったことの 1 つであったと、市川 様は次のように述べています。

「GA 直後で情報が少ない中、試行錯誤しながら触っていたため、当初はスキルの中で DevOps Agent から Slack に直接投稿するよう記述していましたが、これが動作せずしばらく詰まりました。その後、セキュリティ上の理由でスキルから直接 HTTP リクエストを発行できない仕様だと分かり、MCP サーバー経由であれば連携できると気づき、自前の MCP サーバーを作成して動作を確認しました。」

設計 1 を実現するには外部連携が必要となります。Slack スレッドへの進捗投稿、Issue 番号の記録、社内ナレッジベースの検索、Backlog への課題起票はいずれもエージェントの外側にあり、この連携を担うのが MCP (Model Context Protocol) サーバーです。技術ブログ公開時点では、PLAY は AWS Lambda の Function URL として MCP サーバーをデプロイし、DevOps Agent のコンソールでエンドポイントを登録しておりました。

自前の MCP サーバーに加え、GitHub 公式と New Relic 公式の MCP サーバーも登録しておりました。棲み分けとしては、サービス横断で必要なツールは公式の MCP サーバーをそのまま利用し、Slack スレッド返信・Backlog 起票・社内ナレッジ参照といった組織固有の要件は自前の MCP サーバーで提供する、という形です。

MCP サーバーを介した間接的な構成はセキュリティ上の制約に由来するものですが、副次的なメリットもありました。エージェントが呼び出せる操作の範囲が、MCP サーバーに登録したツールの集合として明示されることです。これは設計 1 で決めた任せる範囲を、技術的に境界づける仕組みとしても機能しております。

SimHash による重複アラートの排除

同一原因のエラーが連続して発生する環境では、同じ調査が繰り返されることとなります。人が読む報告が重複することに加え、エージェントの実行も無駄になります。

課題は、エラーメッセージの類似性をどのように判定するかでした。エラーメッセージには発生のたびに変わる要素（タイムスタンプ、PID、リクエスト ID など）が含まれるため、SHA-256 のような暗号学的ハッシュで完全一致を見ても、同じ原因のエラーを同一と判定することができません。

そこで PLAY は、類似したテキストに近いハッシュ値を生成する SimHash（Locality-Sensitive Hashing の一種）を採用しました。正規化したテキストから SimHash を計算し、ハミング距離が閾値以下のものを類似と判定します。DynamoDB 上で効率的に近傍検索を行うため、64 bit の SimHash を 4 つの 16 bit ブロックに分割し、各ブロックをグローバルセカンダリインデックス (GSI) のパーティションキーとしております。

類似と判定され、かつ過去の Issue が紐づいている場合は、Slack スレッドに「関連 Issue: #XX」を返信し、エージェントは起動しません。2 回目以降の同じエラーは、人にもエージェントにも渡さない設計です。

類似判定の手段としては、他に 2 つの選択肢がありました。1 つ目は、過去のインシデントを蓄積している Amazon Bedrock Knowledge Bases で検索する方法です。ただしこの場合、通知のたびに RetrieveAndGenerate を実行することになり、生成の部分にコストがかかるため、大量に通知が来た場合にコストが増大します。DynamoDB 上の SimHash 判定にて十分な精度が出たため、こちらを採用しております。2 つ目は、DevOps Agent 自身が持つインシデントのトリアージ機能です。この機能はルックバックウィンドウ（通常 20 分）の中で同時に起きた関連インシデントを 1 つの調査に統合したり抑制したりするもので、数か月前の過去障害との類似性を判定して抑制する用途には適していないため、採用を見送りました。

効果はチャンネルの性質により差があります。アラートのノイズが多いチャンネルでは、1 か月に 913 件のアラートのうち 719 件（78.7%）が類似判定によりスキップされました。ノイズの少ないチャンネルでは 18 件のうち 9 件（50%）でした。スキップされた分だけ、人が目を通す報告もエージェントの調査も削減されております。

調査に渡す文脈の拡充

重複と探索を削減する一方で、1 回の調査に渡すコンテキストは下記を用いることで厚くしております。

• GitHub 公式 MCP サーバー — 該当リポジトリのソースコード、変更履歴、関連 Pull Request を直接参照
• New Relic 公式 MCP サーバー — エラー発生時のメトリクス、トレース、Errors Inbox の情報を確認
• 社内ナレッジベース — Amazon Bedrock Knowledge Bases に蓄積した過去のインシデント報告を参照し、類似インシデントを踏まえて分析

SimHash の実装、GSI 設計、MCP ツールの定義コード、スキルファイル全文は PLAY の技術ブログに掲載されております。

成果

「Slack 上の報告で対応が完結する割合」と「根本原因を特定できた割合」はプロダクトごとに差があり、上表は PLAY 社内で報告されている水準を記載しております。

その後の発展

技術ブログの公開後、PLAY は DevOps Agent の呼び出し経路と、エージェントが参照できるデータの範囲を広げております。

2 系統となった呼び出し経路

図 2: DevOps Agent の 2 つの呼び出し経路

Slack からの呼び出しである②において工夫されているのは、ユーザーが明示的にメンションする以外の導線です。PLAY では各プロダクトに問い合わせ専用の Slack チャンネルがあり、Slack ワークフローが設定されております。このワークフローに Slack App のメンションを付与しておくことで、問い合わせがそのままトリガーとなります。内容に応じてナレッジベースから回答するか、障害や問題が起こっていそうな内容であれば DevOps Agent が調査を行い、一次調査結果を Slack のスレッドに返します。

②は Amazon Bedrock AgentCore（以下、AgentCore）Runtime 上で動作し、問い合わせ内容に応じてナレッジベースを呼ぶか DevOps Agent を呼ぶかをエージェンティックに振り分けております。②の経路では調査結果に対するフィードバックを Slack のボタンで収集しており、今後は①の自動一次トリアージにおいても同様に収集できるようにする予定です。

MCP 基盤による調査範囲の拡大

社内ツールへのアクセスを担う MCP の提供元は、全社共通の MCP 基盤へと発展しました。AgentCore Gateway を統一入口とし、DevOps Agent はここを経由してツールを呼び出します。

この基盤には、サービスのデータベース（Amazon RDS など）を参照する運用用途の MCP、プロダクトごとの業務データを参照する各プロダクト専用の MCP、外部 SaaS の情報を参照する MCP が含まれます。これらを DevOps Agent の呼び出し先としたことで、サービス内のデータを見なければ調査できない事象についても DevOps Agent で調査できるようになりました。ツールの認可は Cedar Policy で制御されており、プロダクトごとに参照できるツールの範囲を絞っております。

任せられる範囲は、エージェント自体ではなくその外側の整備によって広がっております。PLAY では、New Relic に新しいエンティティを追加した際や、セキュリティ SaaS の検知通知をこの仕組みで分析対象に加えた際に、調査対象を拡大しております。

変わらなかった 2 つの設計

経路と調査範囲が増えても、2 つの設計はそのまま機能しております。

• 設計 1（委譲範囲） — スキルファイルは共通のまま。Slack から呼び出した場合も、一次トリアージと同じスキルによってスレッドに調査状況が報告される
• 設計 2（組織） — 分担は変わらない。プロダクトチームがスキルを書き、共通基盤チームが受け口とツールを提供する

任せる範囲をスキルとして外に出し、組織の分担を仕組みで固定していたため、入口と参照先を増やすという変更を、設計を作り直すことなく吸収することができました。

今後の展望

PLAY では引き続き以下の取り組みが進められております。

対応プロダクトの拡大 — 現在 2 プロダクトで導入準備が進められております。プロダクトチーム側でスキルを準備できれば、共通基盤側はルーティング設定を 1 行追加するだけで連携が完了します。

委譲範囲の拡大 — 一次トリアージの精度が固まってきたことを受け、任せる範囲を段階的に広げております。1 つ目は自動 PR 作成です。New Relic のソースコードマップ連携でエラー箇所が行番号まで特定できる UI のバグなど、調査結果の確度が高いケースに限り、DevOps Agent が GitHub の MCP サーバー経由で Issue に @play fix とコメントし、Pull Request 作成まで人を介さずに進めております。2 つ目は、直近のデプロイが原因と判定された場合に Blue/Green デプロイメントを切り戻す自動対応です。いずれも、冒頭で述べた「コード修正から Pull Request 作成、承認を経たマージ・デプロイまで」という最終的な目標に向けた段階となります。

フィードバック収集の拡大 — 現在は Slack からの呼び出し経路で収集している調査結果へのフィードバックを、自動一次トリアージの経路においても収集できるようにする予定です。

PLAY からのコメント

株式会社 PLAY CTO 丸山 健一 様は次のように述べています。

「私が管掌する技術基盤部では、全社の業務効率化を目的として、社内ツールの開発および仕組みの整備を推進しております。今回構築したインシデント対応基盤もその一環であり、当初より複数チームへの展開を前提として設計いたしました。最初のチームへの導入後、その評価が社内に伝わり、他チームからも導入の要望が自発的に寄せられましたが、本設計により円滑な社内展開を実現できたものと考えております。今後は、お客様のプロダクト利用状況といったビジネスコンテキストを調査に加味しつつ、より多角的な観点からの分析を可能とすることを目指してまいります。」

終わりに

PLAY は DevOps Agent を全社共通のインシデント対応基盤として利用するにあたり、2 つの設計を決めました。

1. 委譲範囲 — 一次トリアージという範囲を切り出し、スキルファイルに記述し、人が判断を行う場所を Slack スレッドに置き、原因を特定できなかった場合の出力まで決めた
2. 組織 — 「基盤の仕組み」と「ドメイン知識」を分け、共通基盤チームとプロダクトチームがそれぞれ自分の知っている範囲だけを担当する構造とした

2 つの設計は、スキルファイルという成果物でつながっております。仕様を書くのは現場であり、仕様が動く土台を用意するのは基盤チームである、という関係です。

市川 様は技術ブログの締めくくりにおいて「AI エージェントを業務に組み込むときの最大の難しさは、エージェント単体の精度よりも、『既存の運用フローやチーム構造にどう乗せるか』の部分にあると感じています。」と述べています。調査結果を人が既に見ているアラートスレッドに返すという設計 1 の判断は、この「既存の運用フローに乗せる」ことを、人の作業手順を変えずに実現した例と言えます。

DevOps Agent の分析精度は、それ単体で十分に高い水準にあります。まず動かしてみるところまでの敷居は高くありません。その精度を組織の日常業務に定着させるために必要となるのは、何を委ね、誰が書くかを決めることでした。

AWS では、AI エージェントを運用へ組み込むにあたってのご相談や、類似事例の共有を行っております。同じように AI エージェントを運用に組み込もうとされている読者の方は、下記の参考リンクもご参照ください。本記事が、AI エージェントの運用設計を検討されているお客様の一助となれば幸いです。

参考リンク

• AWS DevOps Agent を活用したインシデント自動分析基盤（PLAY 技術ブログ） — SimHash の実装、GSI 設計、MCP ツール定義、スキルファイル全文
• AWS DevOps Agent による自律的インシデント対応 － その能力を引き出す設計のベストプラクティス －（AWS Summit Japan 2026 CNS319 登壇資料 PDF）

この記事は ソリューションアーキテクト 金目、スペシャリストソリューションアーキテクト 加藤、テクニカルアカウントマネージャー 馬場が担当しました。

監修: 株式会社 PLAY プラットフォーム本部 技術基盤部 技術推進グループ テックリード 市川 賢 様