Graph Engineeringで作るSRE Agent ~ ⼿動対応者からAIの監督者へ ~

Devincon 2026 登壇資料

1. Graph Engineeringで作るSRE Agent ~ ⼿動対応者からAIの監督者へ ~ 株式会社サイバーエージェント 杉⼭雄⼤ © 2026 WinTicket Inc. 1
2. 00 ⾃⼰紹介 メディア統括本部 Data Science Center 機械学習エンジニア 杉⼭ 雄⼤ YUDAI SUGIYAMA 2026.04 WinTicketのPlatformチーム でSRE領域を担当 2025.04 サイバーエージェント新卒⼊社 WINTICKETの競輪予想モデル“AI予想”などの 機械学習システムの運⽤‧保守に従事 2
3. 00 アジェンダ 01 WinTicketとDevin活⽤ 02 Agent設計技術の変遷 03 SRE Agentの導⼊ 04 AIと⼈間の役割 05 今後の展望 3
4. 01 WinTicketとDevin活⽤ 4
5. 01 WinTicketとDevin活⽤ WINTICKETについて 2021 業界No.1サービスへ成⻑ 新しいUI/UX体験やコロナ禍での特需もあり インターネット投票におけるシェアの およそ半分を担うまでに成⻑ 2019 WINTICKETリリース 競輪‧オートレースの投票サービスとしてリリース 5
6. 01 WinTicketとDevin活⽤ Devin活⽤事例 仕様書作成の⾃動化 分析エージェント 現在、9割以上の仕様書をDevin と協働で作成 Slackから⾃然⾔語でDevin に分析を依頼できる環境 6
7. 01 WinTicketとDevin活⽤ 数字で⾒るDevin使⽤量 17,000+ 1,800+ 1,100+ Sessions PRs created PRs merged 集計期間 2025.02~2026.07 7
8. 02 Agent設計技術の変遷 8
9. 02 Agent設計技術の変遷 これまで設計してきたもの Prompt Engineering Context Engineering Harness Engineering 単⼀のモデル呼び 出しで与える指⽰ の設計 扱える情報として 何を与えるか の設計 エージェントの 実⾏環境の設計 9
10. 02 Agent設計技術の変遷 Loop Engineering Peter Steinberger（OpenClaw開発者） Boris Cherny（Claude Code開発者） “エージェントに直接プロンプトすべきではない エージェントに指⽰するループを設計すべきだ” “もうClaudeにプロンプトしない Loopを⾛らせ、それがClaudeに指⽰する 私の仕事はLoopを書くこと” 引⽤元 https://x.com/steipete/status/2063697162748260627 引⽤元 https://www.youtube.com/watch?v=RkQQ7WEor7w 10
11. 02 Agent設計技術の変遷 Loopを構成する6要素 要素 説明 Automations スケジュールまたはイベントをトリガーに⾃動起動する仕組み Worktrees 複数のエージェントが互いに⼲渉しないよう、それぞれ独⽴した作業 ディレクトリを持たせる隔離の仕組み Skills プロジェクト固有の知識‧慣⾏を説明し直さずに済むようにする再利 ⽤可能なナレッジ Plugins / connectors MCP などを介して、既存の外部ツール群にエージェントを接続する 仕組み Sub-agents 詳細調査やコードレビューを専任のサブエージェントに任せる構造 State 単⼀の会話セッションの外側に存在し続ける記録媒体 引⽤元 https://addyosmani.com/blog/loop-engineering/ 11
12. 02 Agent設計技術の変遷 Graph Engineering Josh C. Simmonsの記事 Peter Steinberger（OpenClaw開発者） AI Agent設計はLoopから明⽰的なGraphへ移⾏す ると論じる記事 “まだループの話をしてるんですか？ それとも、もうグラフの話に移ったんですか？” 引⽤元 https://www.drjoshcsimmons.com/writing/weare-entering-the-graph-engineering-phase 引⽤元 https://x.com/steipete/status/2078277297791189132 12
13. 02 Agent設計技術の変遷 Graphを構成する3要素 要素 説明 Node 能⼒の単位。思考‧⾏動‧観察サイクルを実⾏するモデル、単純な決 定論的関数、検索ステップ、あるいは⼈間。１つの処理だけを実⾏ し、単独でテスト可能であり、他の部分に影響を与えることなく交換 可能なもの Edge 決定事項。あるNodeから次のNodeへ状態を伝達する型付き遷移。 決定論的なものとモデルによって決定されるものがある。重要なの は、どちらがどちらであるかを把握し、可能な限り決定論的な処理を デフォルトにすること State 状態。スキーマを持つオブジェクトであり、境界を越えるたびに チェックポイントが作成される。「たまたまコンテキストウィンドウ に表⽰されているもの」ではない 引⽤元 https://www.drjoshcsimmons.com/writing/we-are-entering-the-graph-engineering-phase 13
14. 02 Agent設計技術の変遷 これから設計するもの Prompt Engineering Context Engineering Harness Engineering 単⼀のモデル呼び 出しで与える指⽰ の設計 扱える情報として 何を与えるか の設計 エージェントの 実⾏環境の設計 Loop Engineering Graph Engineering エージェントが継 続的に⾃律実⾏し 続けられる仕組み の設計 Loop内の明⽰的な 状態遷移グラフ の設計 14
15. 03 SRE Agentの導⼊ 15
16. 03 SRE Agentの導⼊ SRE Agentとは テレメトリ‧アラート‧インシデント履歴などのコンテキストを継続的に観測‧推論し、⼈間が定 義したガードレール下で障害の調査‧復旧を担うAI Agent Gartner® Report: Predicts 2026 — AI Agents Will Transform IT Infrastructure and Operations 2029年までに企業の70%が、ITインフラストラクチャを同時に運⽤するためにAI Agentを導⼊する⾒込み であり、これは2025年の5%未満と⽐較して⼤幅な増加となる 引⽤元 https://www.pagerduty.com/resources/itops/analyst-report/gartner-predicts-report-2026-ai-a gents-transform-it-infrastructure-operations/ 16
17. 03 SRE Agentの導⼊ 通知の種別 クリティカル通知 ワーニング通知 ‧SLI/SLO ‧Error tracking ‧5xx増加 ‧Crashloop Backoff ‧票数報告や情報取得の失敗 ‧リソース枯渇系(CPU/RAM/Disk) ‧外部決済サーバーの障害 ‧パケットロス ‧Cron Jobの失敗 ‧Cloud Armor ワーニング通知対応の課題 SLOを事前定義可能なアラートは、OnCallで元々キャッチできていたが、ワーニング通知は⼈間の即時対 応が必須でないものも多く、対応が漏れることもある（特に休⽇） 17
18. 03 SRE Agentの導⼊ Devin Auto-Triage WinTicketでは既にDevinを仕様書作成やデータ分析等で活⽤していたことに加え、Slackとの連携の容易性、Loopの 6要素に対応した機能を標準で提供していることから、Devin Auto-Triageを採⽤ 引⽤元 https://devin.ai/auto-triage 18
19. 03 SRE Agentの導⼊ Devin Auto-Triageの特徴 24/7対応可能 障害のたびに賢くなる トリアージ‧原因調査は、継続的に更新されるメモ 常に待機しており、新しいバグやアラートが通知さ リを使⽤して動作する。チームがバグをどのように れると、即座に調査を開始できる 処理するかを学習し、適切な担当者を割り当て、過 去の調査を参照できる 重複排除 繰り返される通知を認識し、関連するSlackスレッ ドとリンクさせ、既に調査済みの事項を追跡するこ とでノイズを減らせる セキュリティ DevinとSub-Devinは安全なネットワークサンド ボックス環境で実⾏される 19
20. 03 SRE Agentの導⼊ アラート監視体制 After Before Datadog Slack Datadog Slack AI AI ⼈間 ⼈間 20
21. 03 SRE Agentの導⼊ トリアージ基準 優先度 基準 P1 主要導線が利⽤できない。業界や取引先、多くのユーザーに影響が ある P2 機能は⼀部利⽤できるが、限定ユーザーに失敗、遅延、不整合が発 ⽣している可能性がある P3 ユーザー影響は限定的、または確認できないが、再発⾒込みや運⽤ 影響がある P4 対応不要。単発、⾃然復旧済み、仕様通り、誤検知、または既に対 応中 21
22. 03 SRE Agentの導⼊ SRE Agentの意思決定Graph 22
23. 03 SRE Agentの導⼊ 実際のトリアージ例１ ⼈間レビュー、マージ PR作成、メンション してレビュー依頼 メモリ使⽤量増加 Resource Limitの 設定漏れでP3と判定 23
24. 03 SRE Agentの導⼊ 実際のトリアージ例２ SLO超えのバーンレート のためP2と判定 リリース前にリバート⼿ 順をナレッジに追加 リリース起因の Fast Burn Rate Alertが発⽣ ナレッジのリバート ⼿順を元にPR作成 →最終的にマージ 24
25. 03 SRE Agentの導⼊ SRE Agentを運⽤してみての所感 トリアージ ‧アラート対応のカバレッジが広がった ‧⼈間が全てのアラートを⾒る必要がなくなった ‧不要なメンションが多い ‧⼈間から「本当に影響がないか」の追加質問が多い コード品質 原因調査におけるコンテキスト ‧Devinの権限をDatadogのみに絞っている ‧そのため、本番DBへのクエリやkubectlの実⾏な どが必要になる調査が実⾏できない 責任の所在 ‧ログレベル変更などの軽微な修正は対応可 ‧Devinのセルフマージを許可すると、その変更に対 ‧AI単体では設計判断を要する修正は難しい する責任の所在を説明できなくなる ‧過去のレビューをナレッジ化する仕組みがないと ‧そのため、AuthorがDevinのPRに対して⼈間をア 同じ間違いを繰り返してしまう サインする仕組みが必要 25
26. 04 AIと⼈間の役割 26
27. 04 AIと⼈間の役割 責任の所在の明確化 責任の所在 ‧Devinのセルフマージを許可すると、その変更に対 する責任の所在を説明できなくなる ‧そのため、AuthorがDevinのPRに対して⼈間をア サインする仕組みが必要 対応 ‧Devin Auto-Triage経由でPRを作る際には特定の ラベルを貼るよう指⽰ ‧そのラベルが貼られたPR作成をトリガーに 対象のGitHub Teamからランダムにアサインする ワークフローを作成 ⼈間レビューの必要性 ⾃動化が進むほど「⼈間が何もしなくてよい」と錯覚しがちであり、AI駆動開発では これをプロセスの萎縮（Process Atrophy）と呼び、最⼤のリスクのひとつと位置づけている 27
28. 04 AIと⼈間の役割 ⼈間レビューのフィードバックループ コード品質 ‧ログレベル変更などの軽微な修正は対応可 ‧AI単体では設計判断を要する修正は難しい ‧過去のレビューをナレッジ化する仕組みがない と同じ間違いを繰り返してしまう 対応 ‧過去のPRレビューでの同じ指摘を検出し、ルール 化を提案するワークフローを作成 ‧ルールの肥⼤化を防ぐために⾃動化する部分は、 収集‧分析‧提案まで Context Advantage ⼈間はAIよりもコンテキスト⾯で優位性がある。⼈間はシステムがどのように動かなければならないかの コンテキストについてAIよりも多くを知っている。これは、コンテキスト注⼊ステップを⾃動化できない 理由にも繋がる。⼈間がAIが知らない何かを知っている限り、⼈間は関与する必要がある。 28
29. 04 AIと⼈間の役割 SREにおけるAIの⾃律性レベル 現在のSRE Agentの⾃律性レベル: L1 - Assisted Monitor 異常や兆候を検知‧観測すること Investigate データを分析し原因を診断すること Mitigate (Approval) 対応⽅針を承認すること Actuate 承認された変更を本番に適⽤すること Self Direct ⼀連の対応を⾃律的に考案‧実⾏すること 引⽤元 https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ 29
30. 05 今後の展望 30
31. 05 今後の展望 1 低リスクな修復の⾃律実⾏ 2 SLI/SLOの継続調整 3 エージェント⾃⾝へのSREの適⽤ 31
32. ご清聴ありがとうございました 32