はじめに こんにちは。BASE Departmentでバックエンドエンジニアをしている白数（ かじゅ ）です。 私たちのチームでは今年の夏、カートの表示速度を改善するプロジェクトに取り組みました。 ここでいう「速度」は、サーバーの処理時間だけを指すものではなく、購入者がボタンを押してから次の画面が表示されるまで、実際に待っている時間を指します。 計測を始めた時点で特に表示に時間がかかっていたのは、PAY IDアプリで「購入手続きに進む」を押してから購入確認画面が表示されるまでの経路でした。 一度に大きく作り替えず、小さく変えては数字を見る、を繰り返しフロントエンドとバックエンド合わせてマージ（リリース）したプルリクエストは約140件にもなりました。 その積み重ねの結果、最も効果が大きかったWebでカートを開く操作では、ボタンを押してからカートが表示されるまでの待ち時間がプロジェクト開始前の半分以下になりました。 この記事では、表示速度を改善するまでの過程と実施した対応の一部をご紹介します。 「ボタンを押してから画面が出るまで」を一つの指標にした BASEのカートでは、商品ページの「カートに入れる」や、アプリの「購入手続きに進む」を押すと、次の画面に遷移する前に中継用のページに入ります。 このページの役割は、カートの状態を確認し、カート編集画面と購入確認画面のどちらへ進むかを決めることです。購入者に見えるのはローディング表示だけなので、以下では「振り分けページ」と呼びます。 購入者は振り分けページの読み込み、APIの処理、次画面の読み込みが終わるまで待つことになります。 複数のページをまたぐためAPIの応答時間だけを見ても、この待ち時間は分かりません。 これまでAPIのレイテンシは日々計測している状況でしたが、画面表示までの時間は計測できていませんでした。 まずは振り分けページのナビゲーション開始から、次画面の表示が完了するまでを一つのカスタムイベントにまとめ、ブラウザからNew Relicへ送るようにしました。 この値をプロジェクトの主要指標としたうえで関連データを含む形でダッシュボード化しp50（中央値）とp90を中心に日々の推移を手軽に確認できるようにしました。 詳細はお見せできませんが作成したダッシュボード 内訳を見るとページ全体を2回読み込んでいた 処理の内訳は振り分けページ、バックエンド、購入確認画面の3区間に分かれます。 処理の内訳 区間ごとに計測すると、p50ではバックエンドのAPIが全体に占める割合は非常に小さく、待ち時間の大半は振り分けページと購入確認画面という、2回のページ全体の読み込みでした。 不要なJavaScriptを読まないようにした 改修前の振り分けページは、ローディングを表示するだけにもかかわらず、13本のJavaScriptファイルを読み込んでいました。 中身はReactや状態管理ライブラリ（XState）などで、振り分けの処理はこれらの読み込みと初期化が終わるまで始められませんでした。 そこで、振り分けの処理を始めるまでに読み込むJavaScriptを減らすことを方針にしました。 先に、改修前後を図に示します。 改修前後 まずはフロントエンドの軽量化を行いました。主な対応は以下です。 サポートブラウザの見直しにより不要になった古いpolyfillを削除 OpenAPI定義から自動生成していたAPIクライアントを最小実装へ見直し 実際には使用していない処理まで含まれており、ファイルサイズが大きくなっていたため自動生成された型定義のみを利用し必要最小限の実装へ変更 次に「カートに入れる」などのアクションをサーバー側でも実行できる構成へ変更しました。 これまでXStateやReact hooksに依存していた処理を、Reactに依存しない素の関数へ置き換えたうえで、BFF（Backend for Frontend）であるNext.jsのAPIルートへ移しています。 これらの対応により、 ブラウザからバックエンドAPIを順番に呼び出す必要がなくなった BFFへの1回のリクエストで処理が完結 ブラウザ側に残る処理は、警告表示・計測・画面遷移のみ という構成になりました。 Reactに依存する処理がなくなったため、Next.jsのページとしてリクエストを受けつつもJSXを使用せずに、ローディング表示と振り分け用のインラインスクリプトのみの必要最小限なHTMLを文字列で組み立てて直接レスポンスすることで、振り分けページのみはReactを使用しない構成に変更しました。 その結果、約353KB（gzip圧縮後）のJavaScriptが全て不要となり、このページで実行するJavaScriptファイルは0本となっています。 ここまでの対応に要したプルリクエストは、polyfillの削除が7件、APIクライアントの見直しが25件、素の関数への置き換えが37件、BFFへの移設が13件、Reactの削除が6件です。 最も件数が多かった素の関数への置き換えは、単体ではプロジェクト開始前の表示時間（p50）の約4%にあたる短縮にとどまりましたが、BFFへの移設とReactの削除を可能にする下準備となりました。 最終的には、プロジェクト開始前の表示時間（p50）に対して「カートに入れる」経路では合わせて約19%、カートを開く経路では約13%にあたる時間を短縮できています。 次の画面で使う情報を先に取得して渡すようにした 購入確認画面で使うカート・購入手続き・決済情報は、振り分けページのSSRで取得しても使われなかったり、購入確認画面のSSRでバックエンドから取り直されたりと、無駄な待ち時間の原因になっていました。 これらの情報はBFFで振り分けの処理を実行する際に並行して取得し、短い有効期限でRedisへ保存する形とすることでバックエンドからの取り直しを不要にしました。 この対応でPAY IDアプリの経路では、プロジェクト開始前の表示時間（p50）の約14%にあたる時間を短縮できています。 また、振り分けページでローディングを表示している間に、次画面で使うJavaScriptを先読みしておくことで遷移後の読み込み時間の短縮にもつながっています。 バックエンドはp90を中心に改善した 上述したとおり、p50では全体に占めるバックエンド処理の割合が小さかったものの、p90ではバックエンド処理の占める割合が大きかったため改善を行いました。 バックエンドの対応に要したプルリクエストは14件です。 1リクエストの中で外部APIを複数回実行しており処理時間の大半は、この外部APIからの応答を待つ時間です。 そこで不要な外部APIの呼び出しを経路から外しました。 次画面では参照せず、表示後に別のAPIで取り直す値を計算していた。同じ処理を別画面向けのAPIと共有し、そちらでは値を使っていたため、不要な経路でだけ計算をスキップした ある判定のために2種類の外部APIを呼んでいたが、判定に必要な情報は片方のAPIのレスポンスにも含まれていたため、1回の呼び出しにまとめた また、ループの中にN+1問題がありました。 バックエンドはレイヤーを分けたモジュラーモノリスの構成で実装されています。 DBアクセスや他機能への問い合わせがループの中に隠れていてコード上では気付きにくく、N+1の逐次問い合わせが発生していたため、事前に一括取得するようにリファクタリングを行いました。 AIを使って調査と改善のサイクルを速めた ここまでに紹介したボトルネックの調査や改善内容の検討にはAIを活用しています。 たとえば、New Relicのログや計測結果を調べる際には、確認したい内容をもとにクエリのたたき台を作らせたり、複数の計測結果から次に確認すべき箇所を整理させたりしました。また、コードを調査する際には、処理の呼び出し関係を追い、不要なAPI呼び出しやループ内の問い合わせが発生している可能性がある箇所を洗い出すために利用しました。 AIの出力をそのまま採用するのではなく、実際のログやコード、計測結果と照らし合わせて確認し、修正後はダッシュボードで数値が改善していることを検証しました。 このように、仮説を立て、コードを調査し、小さく修正して計測するサイクルを繰り返すことで、多数の改善を継続的にリリースできました。 表示時間が階段状に下がった 上記以外の対応も含め、プロジェクト開始前の1週間と全施策完了後の1週間を比べたときの表示時間の変化は次のとおりです。 経路 p50（中央値） p90 PAY IDアプリ: 購入手続きに進む → 次画面 -35% -40% Web: カートに入れる → 次画面 -42% -46% Web: カートを開く → 次画面 -53% -51% p50では最大53%、p90では最大51%の短縮です。 速度改善期間中のPAY IDアプリにおける購入手続きに進む→次画面のp50 約140件のプルリクエストを施策別に見ると、不要なJavaScriptを読まないようにする対応が88件、次の画面で使う情報の先取りが20件、バックエンドの改善が14件、計測の仕組みづくりや本記事で紹介していない改善が20件です。 フロントエンド、バックエンドともに効果が大きかったのはAPIの呼び出し回数を減らす施策でした。 改善の効果をチームで喜んだ ダッシュボードの数字だけでなく、実際に画面を操作して体感でも確かめていました。 速度が改善するたびに盛り上がり、良い雰囲気の中でプロジェクトを進めることができました。 改善の効果があったときの会話 おわりに 過去にも速度改善の対応経験はありましたが、AIの利用によりボトルネックの分析や特定が非常に楽になりました。 断片的に散らばったログを自力でかき集め、分析や対応内容を検討していたとすると、これだけの数のプルリクエストをリリースするのは難しかったと思います。 また、今回はプロジェクトとして対応しましたが、AIによって分析のハードルが大きく下がるので、日常的に分析させることで、処理を効率化できる箇所に早く気付けそうだと感じました。 BASEでは様々な職種で一緒にプロダクトを作り上げていくメンバーを募集しています。興味のある方は、ぜひお気軽に採用情報をご確認ください！ binc.jp

本ブログは株式会社 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 つの課題に直面しました。  課題  課題の実体 ① どこまで AI エージェントに任せてよいか分からない（委譲範囲の決定） 全工程を渡すことには不安がある。一方で人が全工程を行うと運用が回らない ② 複数のプロダクトにどのように展開するのか（組織間の分担範囲の決定） 調査手順はプロダクトの中身を知る担当者にしか書けない。一方で各チームに仕組みまで作らせると重複が生じる ①に対する答えが設計 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 上の返信で完結しているとのことです。 現在の役割分担は以下の通りです。  担当  範囲  共通基盤（共通 AWS アカウント） アラートの受信と正規化、過去の類似エラーとの照合、エージェントへの受け渡し  DevOps Agent（各プロダクト AWS アカウント） ログの確認、コードの調査、根本原因の分析、調査結果の Slack スレッドへの報告、必要な場合の Issue 起票  人 調査結果の確認、修正に着手するかの判断、Pull Request のレビューとマージ、対応の優先度判断  修正の自動化（PLAY 自前の仕組み） Issue 上で @play fix とコメントされると、自動でコードレビューとコード修正を行い Pull Request を作成 エージェントが担うのは調査と報告までであり、修正に進むかどうかの判断は原則として人が行います。人が Issue に @play fix とコメントすることで、PLAY が自前で用意したコードレビュー・修正の仕組みが Pull Request を作成し、そのレビューとマージは人が行う流れとなっております。なお、調査結果の確度が高い一部のケースでは、この @play fix コメントを DevOps Agent 自身が行う運用も始まっております。詳細は「今後の展望」にて記します。 この線引きにより、エージェントの分析が的を外した場合でも業務に影響が及びません。Slack スレッドの報告を読んだ人が気づくことができます。一方、最も時間を要していた「どこを見るべきか探す」工程は人の手を離れることとなります。 スキルファイルによる範囲の明文化 DevOps Agent の動作は、マークダウン形式のスキルファイルで定義します。PLAY はこのスキルファイルに、エージェントに任せる範囲をそのまま記述しております。調査から起票・通知までを 9 つのステップに分け、それぞれで呼び出すツールを明示したものです。  Step  内容  使用するツール  1  エラー情報のパース + 「調査開始」の Slack 通知  slack_post_thread  2  対象リポジトリの特定  –  3  ナレッジベース検索  knowledge_base_query  4  デプロイとの相関確認  –  5  コードの調査 + 「原因候補特定」の Slack 通知  slack_post_thread  6  GitHub Issue / Backlog 課題の作成（必要な場合）  add_issue 等  7 「調査完了」の Slack 通知  slack_post_thread  8  Issue 番号のコールバック（起票した場合）  issue_callback  9  結果の報告  – ステップに分けておくことで、エージェントが何をどの順で行うかがドキュメントとして残ります。任せる範囲が曖昧なまま動かした場合、想定外の動作が起きた際に原因を追うことが困難となります。ステップ単位で定義することは、動作を安定させることに加え、何が起きたかを後から説明できる状態を作ることにもつながります。前述の「不要な Issue を作らない」という調整も、Step 6 の条件をスキルに書き足すことで実現しております。 スキルの具体性と調査の質 スキルファイルの書き方について、PLAY が運用を通じて得た知見があります。技術ブログには次のように記されています。 「スキルファイルの書き方そのものが調査の精度とスピードに直結する。Agent 自体は強力でも、スキルが曖昧だと毎回ゼロから調査範囲を探索することになり、結果として『分析に時間がかかる (= 課金が増える)』『見るべき場所を取りこぼす』といった問題が起きる。」 特に効果があったのは、「このアラートやエラーパターンが来たら、どこを最初に見に行くべきか」を具体的に記述することでした。 CloudWatch ロググループ — 「xxx というエラーメッセージが来たら、まず /aws/foo-handler のログを ${時刻} – 5 分 の範囲で確認する」のように、エラー文字列とロググループの対応を列挙する GitHub リポジトリとパス — 「このアラートの対象はモノレポの services/foo 配下なので、コード調査は該当リポジトリの services/foo に絞る」のように、ディレクトリ単位まで明示する メトリクス — 該当時刻のメトリクスを確認する場合は、ダッシュボードの URL や関連クエリも併記する この点は実装前の想定と最も異なっていた部分であったと、市川 様は次のように述べています。 「調査対象のモジュールに対して、どの CloudWatch のロググループや New Relic のエンティティが対応するかというマッピングをスキルに記載しておくと、エージェントが迷わず調査を進められます。エージェント自体の能力よりも、この対応関係をどれだけ具体的に渡せるかが結果を左右する、というのが実装前の想定と違った点でした。」 このマッピングは、PLAY のスキルでは「モジュールマップ」として次のような形で記述されております。以下はサービス名や識別子を架空のものに置き換え、内容を汎化した抜粋です。 モジュール リポジトリ CloudWatch ロググループ（本番） New Relic APM delivery-api <git>/delivery-api /ecs/delivery-api-blue, /ecs/delivery-api-green（用途別に分かれた複数の ECS サービスがこの 2 つを共有する） prod-delivery-api manifest-service <git>/manifest-service /ecs/manifest-service-{blue,green} に加え、Lambda 側 /aws/lambda/prod-manifest-service-Function-<SUFFIX> も稼働中。両方を確認する prod-manifest-service（アラート条件なし） edge-handler <git>/edge-handler /aws/lambda/us-east-1.edge-handler（Lambda@Edge のためリージョンが us-east-1） なし（CloudWatch Logs が唯一のテレメトリ） 表の各行には、リソースの対応関係だけでなく「ECS と Lambda の両方で動いており片方だけ見て再現しないと結論しない」、「APM が入っていないモジュールがある」、「Blue/Green のどちらが現用系かはタスク数と ALB の重みで判定する」といった、エージェントが単独では誤りやすい事実が注記として書き込まれております。命名規則から推測させると必ず間違える点を、稼働環境で確認した事実として先に潰しておく、というのがこのスキルの書き方です。 効果は調査時間に表れております。スキルをほとんど用意していなかった導入初期には 1 件の調査に 15〜20 分程度を要しておりましたが、スキルを具体化した現在は 5〜10 分程度で完了しております（初期の計測は数回分のため、参考値となります）。 Slack スレッドでの判断 エージェントに調査を任せると、人は「今どこを見ているのか」を把握しづらくなります。PLAY では、人が判断を行う場所を Slack のスレッドに置きました。 アラートが通知されたスレッドには、そのとき誰が何を話したかという文脈が残っております。調査結果が別の場所に投稿されると、その文脈から切り離されてしまいます。加えて、PLAY ではどのプロダクトにおいても、アラートが通知されたスレッドに担当者が調査の進捗を書き込んでいく運用が既に定着しておりました。エージェントの調査結果も同じスレッドに返すことで、担当者は普段と同じ場所を見るだけでよく、新しいツールや手順を覚えることなくエージェントを既存の運用に取り込むことができます。問題が起きた元のスレッドに結果が返ることは、文脈の維持と既存運用との接続の両面で重要でした。 調査の進捗は 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 の組織設計の起点となりました。 共通基盤チームとプロダクトチームの線引き 担当 やること 共通基盤チーム Slack / CloudWatch の受信、ルーティング、重複アラート排除、MCP 基盤によるツール提供、Slack スレッドへの返信 各プロダクトチーム 自チームの AWS アカウントに DevOps Agent の Agent Space を作成、サービス固有の調査スキル（マークダウン）を記述、Webhook を共通基盤に向ける この分担により、プロダクトチームは自分たちが詳しい部分の記述に集中でき、共通基盤側のインフラ運用を意識する必要がありません。共通基盤チームも、プロダクト内部のドメイン知識を持たずに運用を成り立たせることができます。どちらのチームも自分が知っていることだけを担当すれば動く、という状態を作ったことが、複数プロダクトへの展開を可能にしました。 設計 1 で述べたスキルファイルを書くのはプロダクトチームであり、それに沿ってエージェントが動く土台を用意するのが共通基盤チームという関係になります。 スキルを記述したプロダクトチームは次のように述べています。 「これまでチーム内で統一してきた調査方法や報告フォーマットに、各システムの技術スタックや AWS のインフラ構成を加えてスキルに書き起こしたもので、いずれも普段から自分たちが持っている情報だったため自前で書き切れました。調査対象のシステムさえずれていなければ調査内容は基本的に信頼しており、報告される【確度】を見て、必要な部分だけ人が追加で事実確認を行っています。」 ここで述べられている確度は、調査結果の根本原因に付与される【確定 / 有力 / 推定】のラベルです。権限や経路の制約（参照する MCP がないなど）により取得できない情報がある場合は確度が下がるようにスキルで定義されており、人はこのラベルを見て事実確認の要否を判断しております。 アカウント分離による責任範囲の明確化 各プロダクトチームの DevOps Agent は、その AWS アカウントで動作します。 権限とリソースが分離されることに加え、責任の範囲がアカウント単位で定まります。どのサービスがどれだけエージェントを利用したかがアカウントごとに分かれるため、「誰の責任範囲か」を運用の都度議論する必要がありません。組織で共有する基盤ほど、この境目を仕組みで決めておくことの価値は高まります。 新規プロダクトの追加手順 新しいプロダクトを基盤に載せる手順は以下の 3 点です。 プロダクトチームが自アカウントに Agent Space を作成する プロダクトチームがサービス固有の調査スキルを記述する 共通基盤チームがルーティング設定に 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 のツール 接続先 対応する設計 slack_post_thread Slack API 設計 1（Slack スレッドでの判断） issue_callback Amazon DynamoDB 重複アラートの記録 knowledge_base_query Amazon Bedrock Knowledge Bases 過去インシデントの参照 Backlog 系（add_issue / update_issue / get_issues 等） Backlog REST API 設計 1（起票先の多様性） 自前の 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 の技術ブログに掲載されております。 成果 取り組み 指標 Before After 設計 1 委譲範囲 一次調査にかかる時間（1 件あたり） 人手で 15 分〜1 時間 エージェントで 5〜10 分 設計 1 委譲範囲 Slack 上の報告で対応が完結する割合 – 7〜8 割（プロダクトによる） 設計 1 委譲範囲 根本原因を特定できた割合 – 7〜8 割（プロダクトによる） 作り込み（SimHash） 類似判定によるスキップ率（1 か月） 毎回調査 78.7%（ノイズの多いチャンネル）/ 50%（ノイズの少ないチャンネル） 設計 2 組織 新規プロダクト追加時の基盤側作業 個別に作り込み ルーティング設定 1 行 「Slack 上の報告で対応が完結する割合」と「根本原因を特定できた割合」はプロダクトごとに差があり、上表は PLAY 社内で報告されている水準を記載しております。 その後の発展 技術ブログの公開後、PLAY は DevOps Agent の呼び出し経路と、エージェントが参照できるデータの範囲を広げております。 2 系統となった呼び出し経路 図 2: DevOps Agent の 2 つの呼び出し経路  経路  起点  ① 自動一次トリアージ  Slack のエラー通知、CloudWatch Alarm  ② Slack からの呼び出し  Slack App へのメンション 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 つの設計を決めました。 委譲範囲 — 一次トリアージという範囲を切り出し、スキルファイルに記述し、人が判断を行う場所を Slack スレッドに置き、原因を特定できなかった場合の出力まで決めた 組織 — 「基盤の仕組み」と「ドメイン知識」を分け、共通基盤チームとプロダクトチームがそれぞれ自分の知っている範囲だけを担当する構造とした 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 プラットフォーム本部 技術基盤部 技術推進グループ テックリード 市川 賢 様

New RelicのNerdGraph（GraphQL API）を使って、EC2インスタンスのメタ情報をCSVに出力するツールを作った際の記録です。AWSコンソールやOSへのログインを都度行わなくても、New Relicにすでに送られている監視データからEC2のインスタンスID・IPアドレス・リージョンなどの情報を一括取得する方法を紹介します。あわせて、User keyとLicense keyの使い分けや、クエリを変更すればEC2以外のリソースにも応用できる点についても触れています。