目次
はじめに
本記事は、2026 年 8 月 26 日に開催された DevinCon の「SRE/運用」トラックで発表された内容の書き起こしです。発表タイトルは「Graph Engineering で作る SRE Agent ~ 手動対応者から AI の監督者へ ~」で、登壇者が抜粋・修正しました。
当日の発表スライドはSpeaker Deckで公開しています。
DevinConとは
DevinConは、AI ソフトウェアエンジニア「Devin」の開発元である Cognition AI 社が主催する、AI 駆動開発のコミュニティキックオフイベントです。2026 年 8 月 26 日に浜松町コンベンションホールで開催され、登録 600 人・参加 300 人の規模で行われました。
Agent 型 AI を活用したソフトウェア開発は、基盤モデルや Harness Engineering の進化によってこの数年で大きな転換点を迎えています。一方で、AI 駆動開発の成否を決めるのはモデルやプロダクトの性能だけではありません。ユースケースの設計、開発プロセス、組織への定着、評価・運用といった実践知の共有が重要であり、その知見は企業の垣根を越えた議論によって磨かれていきます。DevinCon は、こうした実践知を持つエンジニアリーダーが集まり、日本における Devin コミュニティを立ち上げるためのキックオフイベントとして開催されました。
以下、杉山の発表を章立てに沿って紹介します。
自己紹介
サイバーエージェントのメディア統括本部データサイエンスセンターに所属する杉山（@yudaisugiyama）です。2025 年にサイバーエージェントへ新卒入社し、競輪・オートレースの投票アプリ WINTICKET を運営する株式会社 WinTicket で、競輪予想モデル”AI 予想”など機械学習システムの運用・保守を担当してきました。2026 年 4 月に WINTICKET のプラットフォームチームへ異動し、3 ヶ月間 SRE 領域を担当しました。本発表では、この SRE 領域で取り組んできたアラート対応の自動化事例を紹介します。
WINTICKETとDevin活用
WINTICKET は 2019 年にリリースされた、競輪・オートレースのインターネット投票サービスです。新しい UI/UX 体験の提供と、コロナ禍でインターネット投票を選ぶユーザーが増えた追い風もあり、2021 年時点で業界 No.1 サービスへと成長しました。現在はインターネット投票のシェアのおよそ半分を占めています。
WINTICKET では、開発の中で Devin をいくつかの場面で既に活用しています。
1 つは仕様書作成の自動化です。WINTICKET では要求仕様書と開発仕様書の 2 種類を作成しており、2025 年 12 月〜2026 年 1 月の 2 ヶ月間に作成された 36 件のうち 33 件（92%）が Devin との共同作成でした。仕様書を書く際はまず Slack 上でフォームに回答し、そこから立ち上がる Devin との Slack スレッドで対話的に仕上げていく運用となっています。
詳細: WINTICKETで仕様書作成にAIが定着するまでにやったこと
2 つ目は分析自動化です。Slack の Workflow Builder から分析内容と分析期間を入力すると Devin が SQL を生成して BigQuery で実行し、分析結果を Slack に返してくれるようにしています。これにより、データマネジメントチーム以外の事業部メンバーも Slack から気軽に分析を依頼できるようになりました。
詳細: WINTICKETにおけるAI-Readyなデータ分析基盤の構築
上記の例以外にも、様々な場面で Devin を活用しています。
WINTICKET では 2025 年 2 月から Devin を使い始めており、これまでに累計 1 万 7,000 件以上のセッションが実行されました。そのうち約 1 割にあたる 1,800 件ほどが PR を作成し、さらにその半数以上にあたる 1,100 件以上が実際にマージされています。
Agent設計技術の変遷
SRE Agent 導入の話をする前に、Agent 設計技術の変遷について整理します。
Agent 設計技術として最初に注目されたのは「Prompt Engineering」です。単一のモデル呼び出しに対する指示プロンプトの設計を扱う技術で、Few-shot Learning や Chain of Thought といった手法などが含まれます。その次が「Context Engineering」で、Agent に与える情報そのものをどう設計するかを扱います。その後に登場したのが「Harness Engineering」です。どのツールを使わせ、何を禁止するかといった Agent の実行環境を設計する技術です。モデルだけでは補えない部分を埋める仕組み（プロンプト、ツール、フック、Multi-Agent 構成など）を設計し、それらをモデルの進化に合わせて継続的に見直し続ける必要があります。
また、最近（本発表から見て直近の 2026 年 6 月頃）になって「Loop Engineering」という概念が広まっています。きっかけとなったのは、OpenClaw 開発者の Peter Steinberger 氏の投稿です。「Agent に直接プロンプトすべきではなく、Agent に指示する Loop を設計すべきだ」というものでした。もう 1 つのきっかけは、Claude Code 開発者の Boris Cherny 氏の「Claude にプロンプトするのではなく Loop を走らせる。自分の仕事は Loop を書くことだ」という投稿です。
Loop を構成する要素として、Addy Osmani氏のブログでは次の 6 つが定義されています。
- Automations
- Worktrees
- Skills
- Connectors
- Sub-agents
- State
それぞれの要素の説明についてはスライドの通りです。
さらに最近（2026 年 7 月頃）は「Graph Engineering」という言葉が広まりつつあります。AI Agent 設計はこれまで暗黙的な Loop として定義されてきたが、その Loop の中身を明示的な Graph として定義していくべきという考えです。Peter Steinberger 氏も「まだ Loop の話をしているのか、それともグラフの話に移ったのか」と投稿しており、この言葉の広がりがうかがえます。重要なのは、Loop と Graph のどちらも、技術自体は以前から存在していた点です。LangGraph のように Agent をグラフで設計する技術は 1 年以上前からありました。広く使われる言葉になったのが最近というだけです。
Graph を構成する要素として、Simmons氏の記事では次の 3 つが定義されています。
- Node
- Edge
- State
それぞれの要素の説明についてはスライドの通りです。
ここまでの流れをまとめます。注目の中心は Prompt Engineering、Context Engineering、Harness Engineering から Loop Engineering へ移り、現在は Graph Engineering に移っています。ただし、新しい概念が主流になったからといって、それ以前の要素が不要になったわけではありません。下流の概念は上流の要素を内包する形で成立しており、注目の重心が移動しているだけで、それぞれの要素は今も機能し続けていると考えています。
SRE Agentの導入
こうした Agent 設計技術の変遷を踏まえ、WINTICKET における SRE Agent の導入事例について紹介します。
本記事での SRE Agent とは、「テレメトリー・アラート・インシデント履歴などのコンテキストを継続的に観測・推論し、人間が定義したガードレール下で障害を調査・復旧する AI Agent」を指すこととします。AIOps や Agentic SRE と呼ばれることもありますが、本記事ではこれらを総称して SRE Agent と呼びます。Gartner 社のレポートによると、2029 年までに企業の 70%が IT インフラストラクチャーの運用にこうした AI Agent を導入する見込みとされています。2025 年時点では 5%未満だったとのことなので、今後この領域への導入が大きく増えていくと考えられます。
WINTICKET では、アラートやエラーに関する通知を Slack チャンネルに集約しています。
前提として、どのような通知があるかを説明します。大まかにクリティカル通知とワーニング通知の 2 種類があります。クリティカル通知は即時対応が必須のもので、SLO アラート、500 系エラーの一時的な増加、票数報告・レース情報取得の失敗、外部決済の障害などが該当します。一方ワーニング通知は、エラートラッキングやリソース使用率、一時的なパケットロスなど、即時対応が必要な場合とそうでない場合が混在する通知を指します。
クリティカル通知は SLO を事前定義できるため、従来からオンコールで対応できていました。一方ワーニング通知は人間の即時対応を必須としないケースが多く、経験則でのトリアージに頼っており特に休日は対応が漏れてしまうこともありました。
そこで導入したのが Devin Auto-Triage です。採用理由は以下の 4 点です。
- 既に仕様書作成や分析自動化で Devin を活用していたため
- Slack との連携が簡単なため
- Loop の 6 要素に対応する機能が標準で提供されているため
- 監視基盤である Datadog の Bits AI SRE よりも低コストに運用できそうだったため
Devin Auto-Triage は、指定した Slack チャンネルを常時監視し、そこでのアラート通知やメッセージをトリガーに Devin が起動しトリアージを行うことができます。毎回の起動セッションに対して共通の永続メモリを持っており、トリアージの際に過去のインシデントの知見を活用できます。
Devin Auto-Triage の特徴は次の 4 点です。
- 24/7対応可能
- 障害のたびに賢くなる
- 重複排除
- セキュリティ
それぞれの特徴の詳細についてはスライドの通りです。
導入前は、人間が Slack アラートチャンネルの通知を確認したうえで必要に応じて自分で調査するか、Agent に調査を手動で依頼する運用でした。
導入後は、通知イベントをトリガーに Devin が自動でトリアージを開始し、事前に定義したトリアージ手順に従って、緊急性の高い通知だけを人間にメンションしてくれます。これにより、人間はより重要な判断にのみ集中できるようになります。また、Devin が全ての通知に対して 24 時間 365 日トリアージを行うため、アラート対応のカバレッジも広がりました。
トリアージの基準は P1 から P4 まで定めています。それぞれの基準の概要はスライドの通りです。
このトリアージ基準は Playbook に定義しており、Devin は毎回この Playbook を参照してトリアージを行います。
SRE Agent に指示しているトリアージ手順は以下のような流れです。
- アラート通知が来たらまず事象を確認して優先度を判断する
- P1・P2 の場合は、人間にメンションして根本原因調査に入る
- P4 の場合は、永続メモリに記録して終了する
- P3 で改善不要と判断した場合は、永続メモリに記録して終了する
- P3 で改善可能と判断した場合は、修正 PR を作成する
PR 作成後、人間のレビューで問題なければマージします。改善を要する場合は AI または人間が修正し、承認されるまで繰り返す運用にしています。
MTTA / MTTR が改善された一例です。
事象: Datadog から Kubernetes の Pod メモリ使用量増加の通知。
対応: Devin が調査し「リソースリミットの設定漏れ」と判断して P3 と判定、修正 PR を作成。人間がレビューし、内容に問題がなかったためそのままマージしました。
人間の対応が比較的遅れがちな土曜日に発生したものでしたが、発生からわずか 3 分後に Devin が P3 と判定してチームにメンションを飛ばし、修正 PR まで提出してくれました。
2 つ目は少し特殊な事例です。あるリアーキテクチャプロジェクトでは、そのプロジェクト固有のエラーに気づいた場合のリバート手順をあらかじめ Playbook に追加し、エンジニアと Devin の双方に共有していました。
事象: リアーキテクチャプロジェクトのリリースに起因するアラート発生。Devin は SLO 超過を理由として即座に P2 と判定しました。
対応: Devin が事前に共有されていたリバート手順に沿って、人間の対応よりも早くリバート PR をドラフトで作成しました。Slack 上でのやり取りを経て最終的にマージしました。
リリースを担当したメンバーからは「リバート手順を事前に Devin へ共有しておいてよかった」という声が上がっています。
数ヶ月運用して良かった点は、アラート対応のカバレッジが大きく広がり、人間がすべてのアラートを見る必要がなくなったことです。一方で、いくつか課題も見えてきました。
1 つ目は、実際には対応不要なアラートまで緊急と誤判定してしまうケースが多いことです。不要なメンションが発生しやすく、トリアージの精度にはまだ改善の余地があります。
2 つ目は原因調査に使えるコンテキストの制約です。現状、Devin の権限は調査段階では GitHub、Datadog に絞っているため、本番 DB の確認や kubectl の実行が必要な調査・対応にはまだ対応できていません。
3 つ目はコード品質です。ログレベルの変更のような軽微な修正には対応できますが、設計判断を要する修正はまだ難しいのが実情です。これは AI の開発環境やモデルの性能よりも、Harness 整備が十分に成熟していないことが要因の 1 つだと考えています。ルール自体は Devin も参照していますが、定義が抽象的で判断に使えなかったり、参照されるべき場面から離れた場所に置かれていて拾われなかったりすることで、遵守されないケースが残っています。また、人間の中の暗黙知を参照可能なルールとして定義しきれていないことも実情としてあります。
4 つ目は、人間レビューをナレッジ化する Human in the Loop（HITL）の欠如です。原因調査から修正 PR 作成までのナレッジは永続メモリに保存し、次回以降の調査に活用できる Loop が Devin Auto-Triage の機能として既にあります。一方で、修正 PR に対する人間のレビュー内容をナレッジ化する仕組みはまだ存在していないため、同じ指摘を繰り返してしまいます。
5 つ目は責任の所在です。Devin が作成する PR の Author は Devin bot であり、人間の担当者がアサインされるわけではありません。そのためセルフマージを許可すると、仮にその変更に起因して障害が起きた際に、責任の所在を定義できなくなります。この問題を避けるため、現時点ではセルフマージを任せず人間が必ずレビューとマージを行う運用としています（マージ判断をするにはレビューが必要なので）。
AIと人間の役割
運用で見えた課題を踏まえ、現時点の WINTICKET における AI と人間の役割分担について説明します。
Devin Auto-Triage 経由で PR を作成する際に特定のラベルを付与するよう指示しており、そのラベルが貼られた PR に対して、対象領域の GitHub Team からランダムにメンバーをアサインするワークフローを運用しています。アサインされたメンバーが Devin の修正方針が妥当かどうかを判断し、問題なければチームメンバーにレビューを依頼します。
自動化が進むほど「人間は何もしなくていい」という錯覚に陥りがちですが、AI 駆動開発ではこれを「プロセスの萎縮（Process Atrophy）」と呼び、最大のリスクの 1 つと位置づけています。サイバーエージェントにおけるAI推進戦略と変革への取り組みでも、この錯覚が品質や意図の劣化につながるリスクとしています。
先述したコード品質の課題を踏まえ、過去の PR レビューから同じ指摘を検出し、ルール化を提案する Loop を試験導入しています。ルールの肥大化を防ぐため、現状は自動でナレッジに追加するのではなく、過去の PR レビューを収集・分析してルールの提案までを自動化し、実際に追加するかどうかは人間が判断する運用にしています。この運用がうまくいけば将来的な自動化も検討しますが、まずは実験的にどのような提案がされるのかを検証している段階です。
Google Brain と Coursera の共同創業者である Andrew Ng 氏が提唱している考え方で「Context Advantage」という言葉があります。人間は AI よりも「システムがどう動くべきか」というコンテキストを多く持っている、という主張です。裏を返せば、そのコンテキストを注入するステップをまだ自動化できていないということでもあります。これが、人間によるフィードバックレビューが今も必要な理由につながっています。人間が AI の知らない何かを知っている限り、人間の関与は必要であり続けると考えています。
本記事で扱ってきた SRE のアラート対応領域における、現在の WINTICKET の AI 自律性レベルは、GoogleのSREに関する記事で定義されているレベル 0〜4 のうち、レベル 1「Assisted」に位置すると考えています。この記事では、次の 5 つの判断軸それぞれについて、オートメーションか人間かで自律性のレベルを定義しています。
- Monitor
- Investigate
- Mitigate
- Actuate
- Self Direct
WINTICKET の現状を当てはめると、監視ツールからの通知が自動で Slack に流れてくるため、Monitor は自動化できています。Devin Auto-Triage の導入により、データを分析して原因を診断する Investigate もイベント駆動で自動化できるようになりました。一方で、修正 PR のレビューや承認（Mitigate、Actuate）はまだ人間が必要で一連の対応を AI が自律的に考案・実行するレベル（Self Direct）にはありません。
今後の展望
SRE における AI の自律性を高めていくことが、今後の SRE に求められるスキルの 1 つになると考えています。そのためには、責任の所在の定義や、Agent の修正品質を高めるための Harness 設計等をする必要があります。また、SLI/SLO はトラフィックの傾向やシステム構成の変化に応じて本来見直され続けるべきものですが、現状は人間が経験則で閾値を設定・調整しており、継続的な見直しまでは手が回っていません。この見直しが滞ると、閾値が実態と乖離してしまいます。将来的には、過去のインシデントやトラフィックの傾向を SRE Agent が継続的に分析し、SLI/SLO の閾値調整そのものを提案・実行できるようにしたいです。
また、SRE Agent 自身への SRE 適用の必要性も出てくると考えます。一例としてMicrosoftのAgent Governance Toolkitでは、Agent の「ポリシー遵守率」を SLO として設定する仕組みを取り入れています（ポリシー遵守率が 99%を下回るとエラーバジェットの消費が始まるなど）。ここで、エラーバジェットは単なる指標ではなく、Agent にどこまでの自律性を与えるかを自動で左右する仕組みとして機能します。例えば 30 日間安全に稼働し続けた Agent には、より広い自律性が与えられます。逆に、バジェットを使い切ってしまった場合はサーキットブレーカーによる自動強制停止といった対応が考えられます。今後は、こうした SLO やエラーバジェットに加えて、人間が任意のタイミングで Agent を緊急停止できる kill switch も必要になってきます。また、Agent の判断過程を後から追跡できる監査証跡など、Agent の暴走を未然に防ぐための運用整備も必要になってくると考えています。
登壇を終えて
同じパネルセッションに登壇した株式会社タイミーさんや AI inside 株式会社さんの事例を聞き、改めて Devin の良さを実感する一日にもなりました。サイバーエージェントでは現在 Devin を Team プランで契約しています。現在だと Enterprise プラン限定の機能であるロールベースアクセス制御（RBAC）によるユーザーレベルでの権限管理をまだ整備しきれていないと強く感じました。イベント終了後すぐに WINTICKET のメンバーと Enterprise プランへの契約変更について議論し、WINTICKET が担保したいセキュリティ品質を Enterprise プランで満たせるかを検証する方向で動き始めています。
DevinCon への参加を通じて登壇資料をまとめたり、他社のさまざまな Devin 活用事例を聞いたりする中で多くの学びを得られるとても価値のある機会でした。
おわりに
DevinCon は、AI 駆動開発の最前線に立つすべてのエンジニアが企業の垣根を越えて本質的な課題とベストプラクティスを議論する、日本初のコミュニティキックオフでした。今回紹介した Devin Auto-Triage の取り組みも、こうした場での議論を通じて次の改善につなげていきたいと考えています。今後も WINTICKET での AI 駆動開発の実践知を社内外に発信していきます。