[](https://devin.ai/ja) [](https://devin.ai/ja/blog) # Devin Oncallのご紹介 Jake Rachleff, Anhang Zhu, Jeff Yan, and Yun Park2026年10月15日15分で読めます 本日、お客様がソフトウェアの「自動運転」化へと歩みを進められるよう、Devin Oncallをリリースします。Devinはアラートやバグレポートを自動で調査し、チームによる本番インシデントの診断と解決を支援します。 Devin Oncallは、本番環境の障害の診断と緩和において最も優れたハーネスです。SREGymでの評価では最高スコアを記録し、**エンドツーエンドの成功率100%**でベンチマークを飽和させると同時に、緩和までの時間も最速でした。 #### SREGym-Liteスピードvsパフォーマンス Devin OncallCodexClaude CodeCloudThinker このベンチマークは、稼働中のシステムで発生する代表的な障害に対してエージェントをテストするもので、同じ実行の中で根本原因を_特定_し、かつ問題を_緩和_することの両方が求められます。各テストは、実際のシステムで起きた本番インシデントに基づいています。 Devin Oncallはすでに、Cognitionのお客様のオンコール対応やインシデント調査のあり方を変えつつあります。呼び出し（ページ）の削減から、エンジニアをプロダクト開発に専念させることまで、その効果はさまざまです。 - **[Reducto](https://devin.ai/customers/reducto)では、** Devinが複数のアラートにまたがる懸念すべき傾向に気づき、問題の内容に関するコンテキストを添えて、自らインシデントを起票しました。Reductoの本番アラートが発火したのは、失敗したリクエストが増え始めたずっと後のことでした。Devinが早期に問題を指摘していたため、インシデントの影響は大幅に抑えられました。現在ではエンジニアリング関連のアラートの大半にDevinが最初に対応し、中程度の重大度の問題であれば自ら修復したり、PRを作成してテストしたうえでエンジニアにレビューを依頼したりすることも少なくありません。 - **RivianとVolkswagenの合弁会社である[RV Tech](https://devin.ai/customers/rvtech)では、** Devinが顧客からのレポートから車両識別子とタイムスタンプを自動で抽出し、ログを取得し、解析スクリプトを実行して、問題のトリアージを行っています。エンジニアは初期調査を手作業で行う代わりに、その分析結果をレビューするだけで済みます。これにより、あるチームでは複数のエンジニアをプロダクト開発に戻すことができました。 - **[AngelList](https://devin.ai/customers/angellist-oncall)では、** Devinが根本原因を正しく特定する件数が、同社の社内調査ハーネスであるSkyの3.5倍に達しており、エンジニアは確信と信頼を持って、すぐに修復作業に取りかかれるようになりました。さらに、インシデントの50%についてはDevinが単独でエンドツーエンドに対応しました。AngelListはSkyを廃止し、Devin Oncallに切り替えています。 Devin Oncallを提供するお客様が増えるにつれ、導入は急速に拡大してきました。現在では、世界有数の大企業において、毎日数千件の実際の本番アラートに対応しています。 #### Devin Oncall 1日あたりの対応アラート数 このたび、Devin Oncallの一般提供を開始できることを大変うれしく思います。本記事では、Devin Oncallをどのように構築したかをご紹介します。本番環境の問題を調査・修復し、根本原因が解決されるまで作業を続けられるエージェントの背後にある、エンジニアリング上の判断を詳しく解説します。 ## （今や）エージェントさえあればいい エージェントは、これまで常に本番環境のデバッグが得意だったわけではありません。調査の質は、コーディング能力に比べて後れを取っていました。昨年までは、そうした限界がはっきりと見て取れました。エージェントは答えを見つけたと早々に結論づけがちで、十分に幅広く探索せず、ロールバックやスケールアップといったシンプルな緩和策をとる代わりに、大規模なコード変更を加えようとしていたのです。 AI SRE専門の企業（[TierZero](https://cognition.com/blog/welcoming-tierzero)時代の私たち自身も含みます）は、これを補うためにさまざまな手法を用いていました。 - エッセイ並みに長く、過学習気味で、FDEが調整したプロンプトやランブック - データをより細かく制御するために、お客様のネットワーク内にデプロイするオブザーバビリティ用のコレクター - エラーシグナルに対するカスタムのグラフアーキテクチャや、高度な古典的機械学習の手法 - SREタスクに特化したモデルのポストトレーニング いずれも、それぞれに脚光を浴びた時期がありました。 しかし、こうした手法はモデルが賢くなるにつれてスケールしなくなります。モデルの能力が向上すると、今ではかえってモデルの足を引っ張るようになったプロンプトを削ったり、システムの一部を作り直したりする羽目になります。より賢いエージェントからより良い調査結果を得る代わりに、以前の限界を前提に組み込んだ仮定を元に戻すことに時間を費やすことになるのです。「Bitter Lesson（苦い教訓）」が示すとおり、最良のコアアーキテクチャとは、非常に賢いエージェントです。 つまりオンコール対応に必要なのは、適切なコンテキスト、ツール、ワークフローを備えた、非常に優れたコーディングエージェントだけです。その有能なエージェントは、クラウド上で動作し、重要なシステムにアクセスでき、チーム間でコンテキストを共有できる必要もあります。私たちにとって、そのエージェントこそが**Devin**です。Devinはモデルに依存しないアーキテクチャを採用しているため、あらゆるオンコールタスクに最適なモデルを選択でき、より強力なモデルが登場すればすぐに採用できます。 この数か月間、私たちはこの基盤の上にDevin Oncallを構築・テストしてきました。本番環境の調査を遂行するために必要なコンテキストと作業パターンを、Devinに与えてきたのです。 [![Reductoのロゴ](https://devin.ai/images/blog/introducing-devin-oncall/logos/reducto.svg)](https://devin.ai/customers/reducto) > [今では、エンジニアが呼び出されることはほとんどありません。オンコール当番について不満を言うエンジニアもいなくなりました。](https://devin.ai/customers/reducto) [Raunak Chowdhuri共同創業者兼CTO](https://devin.ai/customers/reducto) [![AngelListのロゴ](https://devin.ai/images/blog/introducing-devin-oncall/logos/angellist.svg)](https://devin.ai/customers/angellist-oncall) > [仮説を立てて検証するという点で、Devin Oncallは本当に際立っています。](https://devin.ai/customers/angellist-oncall) [Thibaut LaBarreエンジニアリングリード](https://devin.ai/customers/angellist-oncall) [![Modalのロゴ](https://devin.ai/images/blog/introducing-devin-oncall/logos/modal.svg)](https://devin.ai/customers/modal) > [Datadog MCP、コードのトレース、ユーザーによる誘導の組み合わせは、何が起きたのか、本来何が起きるべきだったのか、そして問題があるのかどうかを把握するうえで非常に効果的です。毎日、コンテキスト収集にかかる時間を何時間も節約できています。](https://devin.ai/customers/modal) [Matthew Sweeneyサポートエンジニアリング責任者](https://devin.ai/customers/modal) 私たちは、Devin Oncallを支えるエンジニアリングを、**コアインテリジェンス、企業のコンテキスト、エージェントの振る舞い**という3つのレイヤーに整理しています。これらはおおむね、優秀なオンコールエンジニアの条件に対応しています。すなわち、システムについて推論する能力、その企業固有の環境に関する知識、そして実戦で鍛えられた信頼性のためのワークフローです。 ## コアインテリジェンス：もっともらしい説明の先へ 最も基本的なレベルでは、モデルとそのコアとなるハーネスが、制御された環境で問題をデバッグする方法を理解している必要があります。私たちは、すべてのプロバイダーのフロンティアモデルをデバッグのベンチマークで定期的に評価し、SREタスクごとに最も効果的なモデルを選択しています。代表的なベンチマークのひとつであるSREGymでは、より厳選された構成のベンチマークにおいて、前世代のモデルが50〜60%のスコアだったのに対し、ミドルクラスのモデルがすでに満点に達しています。 #### SREGym-Lite モデルのリリース時期別ベストスコア エンドツーエンドの成功：エージェントが正しい根本原因を特定し、かつ稼働中のシステムを修正できたことを示します。 100%75%50%25%0% Claude Sonnet 545.1%, Claude Code GPT-5.6 Sol76.5%, Codex Claude Opus 576.5%, CloudThinker Claude Fable 5.185.3%, Devin Oncall GPT-6 Astra100.0%, Devin Oncall Claude Opus 5.5100.0%, Devin Oncall GPT-6.1 Sol94.1%, Devin Oncall 7月8月9月10月 Devin Oncallその他のエージェントその時点でのベストスコア SREGym-Lite（17件の障害）において各モデルについて公表されているエンドツーエンドのベストスコアを、そのモデルがDevinで利用可能になった日付の位置に示しています。Devin Oncallの結果は当社独自の評価によるもので、その他の結果は2026年10月15日時点の公開SREGymリーダーボードによるものです。同リーダーボードでは、CloudThinkerもGPT-6 Astraで100%に到達しています。 これらの結果は、閉じたシステムであれば、モデルがバグを見つけるための正しい判断を下せることを示しています。しかし本番環境の調査では、複雑怪奇なレガシーシステムを相手にし、膨大な量のテレメトリデータを横断して探索する必要があります。エージェントはいまだに最初に見つけたもっともらしい根本原因で止まってしまい、エンジニアが「もっと深く掘り下げて」「根底にある原因を見つけて」と指示しなければならないことがあります。 私たちは、調査を促すプロンプトと、Devinと並行して非同期で動作する2つ目の「レビュー」エージェントによって、こうした早計な結論に対処しています。レビューエージェントは、直近の推論、ツール呼び出し、結果を精査し、相関を因果と取り違える、矛盾するテレメトリを無視する、トリガーと根本的な問題を混同する、といった誤りを洗い出します。たとえば、最近のデプロイは調査すべき手がかりではあっても、因果関係の説明ではありません。 これにより、調査する作業と、その結論が証拠から導かれるかを確認する作業が切り分けられます。どのように調査するかを決めるのは引き続きメインのエージェントであり、レビュアーは、本来であればエンジニアが投げかけなければならなかった的を絞った疑問を提示します。 ## 企業のコンテキスト：自社システムの調査方法を知る 有能なエンジニアリングエージェントであっても、企業の中でどう働くかを知る必要があります。関連するコードがどこにあるのか、テレメトリをどうクエリするのか、各サービスがどのように組み合わさっているのか、といったことです。一般的なデバッグ能力だけでは、エージェントはそうしたコンテキストも、それを見つけられるシステムへのアクセスも得られません。 ローカルで動かすエージェントのワークフローでは、ユーザーとエージェントは共生関係にあります。ユーザーは必要に応じてコンテキストを提供し、エージェントはユーザーの認証情報を使ってサードパーティのシステムにアクセスします。一方、クラウドエージェントはそれ単体で完結している必要があります。アクセス権と初期コンテキストを、あらかじめ設定しておかなければなりません。 その分セットアップの手間は増えますが、その作業の恩恵を受ける人も変わります。レガシーシステムに関する暗黙知など、クラウドエージェントが獲得したコンテキストは、個々のエンジニアが何度も提供し直すのではなく、チームや組織全体で共有できるのです。 十分な時間さえあれば、有能なエージェントは理論上、実行のたびに環境の大部分を把握できるかもしれません。しかし本番環境の調査には、スピードとコスト効率が求められます。お客様の中には、こうした知識を実質的にキャッシュする、入念に整備されたスキルを用意している方もおり、それによってDevinは有利なスタートを切ることができます。しかし、多くのお客様はそうではありません。そこで私たちは、そうしたお客様がすぐに使い始め、Devinが調査を重ねるにつれて知識を蓄積できるよう、3つのレイヤーのコンテキストを構築しました。 - **レスポンダーごとのメモリ：** 各Oncallエージェントは、それぞれ独自のメモリを持っています。どのチームメンバーをタグ付けすべきかを記憶でき、今後の調査で振る舞いを変えるよう指示することもできます。これにより、各レスポンダーは担当する作業に特化したコンテキストを持てます。 - **組織ごとのスキル：** Devin Oncallは定期的にお客様の環境をインデックス化し、連携サービスにおける一般的なデバッグタスク向けのスキルを生成します。たとえば、問題が影響する顧客の範囲（ブラスト半径）の算出や、プラットフォームの依存先からのデータのクエリなどです。これらのスキルにより、エージェントは調査のたびに手順を一から考え直すことなく、すぐに使える手順を利用できます。 - **組織ごとのメモリ：** すべての調査は事後処理され、有用な情報が保存されて、エージェントが今後の調査で動的に検索できるようになります。Devin Oncallは、これを組織の知見の低精度なキャッシュ、つまり本来なら自ら発見しなければならないシステムに関する情報として扱うよう調整されています。 これらのレイヤーが組み合わさることで、Devin Oncallは導入初日から機能し、チームが使うほど賢くなっていきます。私たちのモニタリングでは、誤った診断は時間とともに減少していくことが示されています。 ## エージェントの振る舞い：プラットフォームエンジニアのように動く 次々と届くアラートへの対応と、進行中のインシデントへの対応とでは、求められる作業パターンが異なります。Devin Oncallの2つのコアプロダクトであるレスポンダー（Responders）とインシデント（Incidents）は、それぞれのワークフローに合わせてDevinの作業を組み立てるもので、調査を効果的かつコスト効率の高いものにすることを目指しています。 ### レスポンダー レスポンダーは、[Auto-Triage](https://docs.devin.ai/product-guides/auto-triage)の次世代版です。アラートやバグレポートのストリームを監視し、問題を自動で診断するとともに、根本的な問題を記憶しておくことで、同じ調査を繰り返さないようにします。 私たちは、親子型のエージェントアーキテクチャを中心にレスポンダーを構築しました。表には出ない親のDevinがチャンネルに届く新しいアラートを監視し、そのアラートが調査に値する新しい問題を示しているかどうかを判断します。そうであれば、親は子の調査を起動します。 これにより、アラートストリーム全体の把握と、個々の問題の調査に必要なコンテキストとが切り分けられます。親は進行中のリクエストや既知の問題を把握し、一方で各調査は新しいコンテキストから始まります。 既知の問題を記憶しておくことで、不要な作業も減らせます。レスポンダーは、過去の作業を参照したり関連するアラートをグループ化したりすることで、調査のおよそ60%をスキップしており、通常の自動化と比べてお客様のコストを半分以上削減しています。 #### Devin Oncallのレスポンダー 既知の問題をスキップすることで、アラート対応のコストを半分以上削減します。 Devin Oncallには、**アラートレスポンダー（Alert Responders）** と **サポート＋バグレスポンダー（Support + Bug Responders）** の2種類のレスポンダーが用意されています。よくあるお客様のユースケースに合わせてデフォルトの振る舞いを調整しているため、複雑なランブックがなくても機能します。もちろん、ワークフロー上必要であれば、振る舞いをカスタマイズすることも可能です。 ### インシデント Devinはお客様のインシデント対応プロセスに加わり、緊急の問題の診断と修正を支援します。インシデントごとにメッセージングチャンネルを作成するという一般的なプラクティスの中で動作し、エンジニアと並行して能動的に調査を進めるとともに、関係者が状況をすぐに把握できるライブのインシデントドキュメントを更新し続けます。 ここでの課題は、会話に素早く反応しつつ、調査を前に進め続けることです。Devinには、集中力を失うことなく、こうした継続的なやり取りに対応することが求められます。 私たちは、インシデントのアーキテクチャの中で、これらの役割を分離しています。 無関係な議論に気を取られないよう、メッセージはDevinに届く前に事前フィルタリングされます。親のDevinはバックグラウンドで継続的に調査を進めながら、直接の質問を調べるために子のDevinを起動し、コンテキストを共有します。 これにより、親のDevinはオーケストレーションとバックグラウンドでの調査に集中でき、子のDevinは個別のリクエストに素早く応答できます。エンジニアは、インシデントの進展に合わせて質問を投げかけても、その質問が親のDevinの調査全体を占めてしまうことはありません。 ## 今後に向けて ソフトウェアをリリースするなら、それを動かし続ける力も備えているべきです。変更を本番環境まで追いかけ、問題を解決まで導き、変化するシステムを健全に保つことをDevinに任せてください。Devin Oncallによって、エンジニアはすべてのステップを自ら開始・調整することなく、方向性を定め、意思決定を行うことに専念できます。 それこそが、ソフトウェアを「自動運転」にするということです。チームは、自ら生み出すすべてのものを手動で運用する役割を負うことなく、より野心的なソフトウェアに取り組めるようになります。 Devin Oncallは、[devin.ai/oncall](https://devin.ai/oncall)から今すぐお試しいただけます。 目次 [（今や）エージェントさえあればいい](#今やエージェントさえあればいい)[コアインテリジェンス：もっともらしい説明の先へ](#コアインテリジェンスもっともらしい説明の先へ)[企業のコンテキスト：自社システムの調査方法を知る](#企業のコンテキスト自社システムの調査方法を知る)[エージェントの振る舞い：プラットフォームエンジニアのように動く](#エージェントの振る舞いプラットフォームエンジニアのように動く)[レスポンダー](#レスポンダー)[インシデント](#インシデント)[今後に向けて](#今後に向けて)