2026年11月18日から20日にかけて幕張メッセで開催されるInter BEE 2026の出展者セミナーに、New Relicが登壇します。「TVer」や「Hulu」などの国内トップクラスの動画配信サービスの開発・運営を手掛ける株式会社PLAYをゲストに迎え、AWS DevOps AgentとNew Relic MCPを連携させた障害対応の事例をお話しします。
マイクロサービス化や外部サービスとの連携が進むと、障害が起きたときに見るべき場所が増え、原因の当たりをつけられる人が少数の熟練者に限られていきます。夜間に通知が届いても、その人が読むまで調査が始まらないという場合があります。 本記事では、PLAYがこの課題をどう解いたのかの骨格と、セッションで聞ける内容をご紹介します。聴講予約はすでに始まっていますので、動画配信に限らず障害対応の属人化に悩むチームの方は、ぜひお申し込みください。
Inter BEE 2026への入場は無料ですが、来場事前登録が必要です。登録後にログインすると、カンファレンスの聴講予約ができるようになります。
本セッションの詳細と聴講予約は、Inter BEE 2026のセッションページからお進みください。会場の席数には限りがありますので、お早めのお申し込みをおすすめします。
セッションの概要
セッションの名称は「AWS DevOps AgentとNew Relic MCPの連携による次世代の障害対応体制の構築」です。2026年11月18日（水）の12時から13時30分まで、幕張メッセ国際会議場1階の103会議室で開催します。登壇者は、株式会社PLAYの市川賢氏（プラットフォーム本部・技術基盤部・技術推進グループ、テックリード）と、New Relic株式会社の志茂秀真（ソリューションコンサルタント）です。
PLAYは、VOD・ライブ配信のプラットフォームから番組編成、素材管理、収益化までのシステムを自社で開発・運用しています。2024年秋にNew Relicを導入し、APMでシステム全体の可視化を進めたあと、次の課題として障害対応の属人化に取り組みました。その経緯は、2026年6月のプレスリリースでも紹介しています。本セッションでは、この取り組みを実際に設計・運用したPLAYのエンジニアから、設計の判断とその結果を直接お聞きいただけます。
障害対応はどこで属人化するのか
障害対応が特定の人に寄るのは、その人だけが原因を見抜けるからではありません。通知が飛んでから当たりがつくまでに、何をどの順で見るかを、その人だけが知っているからです。エラー率の推移はNew Relicで見て、アプリケーションのログはCloudWatchで追い、そのときの構成はマネジメントコンソールで確かめます。置き場所が違うだけでなく、時間の窓の切り方や絞り込みの条件にも作法があり、見る順番が結果を分けます。
この順番は手順書に書き出しても効きにくく、読む人の練度で再現度が変わります。PLAYの環境では、一次調査に対応できるエンジニアが2〜3名の熟練者に限られていました。セッションでは、この属人化を「散らばった情報源のどこから何を引くか」という手数と、「引いたものをどの順で見て何と突き合わせるか」という筋道の2層に分けて捉え、それぞれを別の仕組みで解いた考え方を説明します。
AIエージェントを社内の情報源につなぐ
AIエージェントに調査を任せようとすると、最初にぶつかるのは賢さではなく経路の問題です。エージェントは自分がつながっている先しか見られないので、New Relicのテレメトリデータも社内のナレッジも、つないでいなければ存在しないのと同じです。この接続を標準化したオープンな仕様がMCP（Model Context Protocol）です。New RelicではNew Relic MCPサーバーを通じて、対応するAIエージェントからオブザーバビリティデータを照会・分析できるようにしています。
PLAYでは、Amazon Bedrock AgentCore Gatewayで全社共通のMCP基盤を用意し、エージェントの入口を1つにまとめました。認証と認可と監査を入口で一度だけ解き、その先に社内のナレッジ検索やプロダクトごとの業務データ、そしてNew Relic MCPをつないでいます。エージェントはゴールデンメトリクスの分析やデプロイの影響分析といったNew Relic MCPを呼び、エラー率の推移や直前のデプロイの影響を自分で取りに行きます。
アラートと同時に一次調査を始める
手元の調査が速くなっても、人が異変に気づくまでの時間は変わりません。そこでPLAYは、アラートが飛んだ時点で一次調査が始まる仕組みとして、AWS DevOps Agentを採用しました。Slackへのエラー通知を入口にLambdaがイベントの形をそろえ、DevOps AgentへWebhookで渡します。エージェントはログやコード、New Relicのデータを突き合わせて分析し、GitHubやBacklogに課題を起票します。
運用に載せるうえで工夫したのは、似たエラーで何度もエージェントを起動しないための重複判定と、調査結果を通知の元のスレッドに返す仕組みです。担当者がスレッドを開いた時点で、根本原因の候補と修正の提案が届いているので、最初に開くのはコンソールではなくSlackになります。DevOps Agentもエンジニアと同じMCP基盤の利用者として加わっています。そのため、人が手を動かす場合も自動で回る場合も、手に入る材料は変わりません。この点が設計の要です。
セッションで聞けること
セッションでは、ここまでの骨格に加えて、ブログでは書き切れない判断の過程を取り上げます。エージェントにどこまでを委ね、どこから人が判断するかという委譲範囲の決め方や、共通基盤を持つチームと各プロダクトのチームの役割分担がその中心です。
成果については、1件あたり約15分かかっていた一次調査が実質ゼロ（5〜10分程度）になったこと、一次調査に対応できるエンジニアが2〜3名から10名以上へと4倍以上に広がったことを、設計の判断と結びつけて説明します。
New Relic側からは、AIエージェントにテレメトリデータを渡すうえでMCPがどう位置づけられるのか、そしてNew Relic MCPがどのような調査のツールを提供しているのかをお話しします。動画配信の現場で実際に動いている事例と、それを支える製品側の仕組みの両方を、90分で持ち帰っていただける構成です。
聴講予約について
Inter BEE 2026への入場は無料ですが、来場事前登録が必要です。登録後にログインすると、カンファレンスの聴講予約ができるようになります。本セッションの詳細と聴講予約は、Inter BEE 2026のセッションページからお進みください。会場の席数には限りがありますので、お早めのお申し込みをおすすめします。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
