20260414_Agentic_AIで加速するDevOpsフィードバックループ___サポートチケットをSLAリスクのシグナルに変える

DevOps Days Tokyo 2026の登壇資料です。
2026-04-14 17:00-17:30(JST)
https://confengine.com/conferences/devopsdays-tokyo-2026/proposal/49569/agentic-aidevops-sla

■アジェンダ
背景と狙い
Part1 イベント駆動の通知・レポート基盤
・Azure Boards
・Azure Boards WIQL
・アーキテクチャ
・実装詳細
・定期レポート
Part2 Agentic DevOps PoC
・Agentic DevOps PoC
・学びと評価
まとめ

Transcript

1. Agentic AIで加速するDevOpsフィードバック ループ — サポートチケットをSLAリスクのシグ ナルに変える 2026.04.14 Yutaka.Osada
2. Agenda • 背景と狙い • Part1 イベント駆動の通知・レポート基盤 • Azure Boards • Azure Boards WIQL • アーキテクチャ • 実装詳細 • 定期レポート • Part2 Agentic DevOps PoC • Agentic DevOps PoC • 学びと評価 • まとめ DO WHAT MATTERS 2
3. Yutaka Osada （長田 豊） • DevOps Engineer @Avanade Japan • 業務 • Azureコンポーネントを活用したサー ビス構築 • 技術検証、パフォーマンスチューニン グを得意とし、T-SQLが好き。 • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me DO WHAT MATTERS 3 https://github.com/yutaka-art
4. 背景と狙い DO WHAT MATTERS 4 なぜ今、Ops側のシグナルが重要なのか AI 開発側だけのAI適用で は不十分 コード生成・PR支援は急 速に進化。しかしOps側 のシグナルを観測しDev へフィードバックするル ープが抜け落ちている。 !! サポートとコードの分 断 チケットがリリース・コ ードと結びつかず、SLAリ スクの把握や優先度判断 が属人的になる。情報が 散在し対応が遅れる。 -> 目指す姿 チケットを「運用シグナ ル」として扱い、SLAリス ク検知 → 通知 → 次アク ション提案を一本化する 。
5. PART1 イベント駆動の通知・レポート基盤
6. Step 1 | Azure Boards DO WHAT MATTERS 6 チケットを「シグナル」にする — Azure Boards プロセス設計 カスタムプロセス設計 Basic (標準プロセス) 継承 (Inherited Process) Support Process (カスタム) Support Ticket WIT [+] State 設計 New Triage In Progress Waiting Resolved Closed 主要フィールド設計 Severity (Critical/High/Normal/Low) DueDate (SLA期限日) CustomerName / TenantId SupportCategory MsSupportTicketId POINT フィールド設計の質が、後段の検知・集計・AI提案の精度を左右する
7. Step 1 | Azure Boards WIQL DO WHAT MATTERS 7 WIQL でSLAリスク候補を定義・再利用する 仕組み 1 GUI でクエリを定義 例: State <> Closed AND DueDate < @Today 2 Azure Boards にクエリを保存 クエリIDが払い出される 3 アプリからクエリIDで REST API 呼び出し コードは薄い / 条件式は GUI で管理 4 結果をレポート / 通知 / AI提案の 入力データとして利用 SLAリスク候補クエリ例 期限超過 DueDate < @Today AND State <> Closed 期限間近 (3日以内) DueDate >= @Today AND DueDate <= @Today+3 長期滞留 (5日超) State = Waiting AND ChangedDate < @Today-5 未アサイン State = New AND AssignedTo = [Empty] * 条件変更はGUIで完結。アプリ側コードの変更は不要。
8. Part 1 | アーキテクチャ DO WHAT MATTERS 8 Azure DevOps 顧 客 社 内 お問い合わせ Azure Teams or Slack Azure Boards Support Ticket：”INC”+YYYYMMDDHHMMSS In Progress：一次対応 ナレッジを確認し回答できるか判断 Waiting：トリアージ/アサイン 問合せLVを確認しエンジニアをアサイン Resolved：調査・回答案 エンジニア調査・回答案記載 ナレッジベース 専用チーム 通知タイミング • Support Ticket起票された場合 • Support Ticketの担当者が変更された場合 • Support TicketがOverdueの場合 Logic Apps 常時起動（Support Ticket起票・変更を検知） 日次起動（Support TicketがOverdueの場合） Support チケット起票 Teamsによる受動通知 で対応漏れを検知 凡例： :E-mail :Phone :Azure DevOps :SharePoint :Teams :Logic Apps Service Bus Container Apps Queues Business Proc Service hooks 要実装 拡張性を留意しPaaSを 採用 ：帳票 ：分析 Closed：顧客回答 エンジニアの回答を受けて顧客へ最終回答 付属機能 New：チケット発行（CSP Support） チケットに顧客情報・問い合わせ内容を入力 イベント駆動の通知・レポート基盤 — 全体構成
9. Part 1 | 実装要点 DO WHAT MATTERS 9 実装の要点 — Service Hooks / Adaptive Cards / Logic Apps Service Hooks イベント取捨選択 workitem.created で新規チ ケット通知 workitem.updated は担当者 変更のみカード生成 (差分チ ェック) 不要イベントはアプリ側でフ ィルタリング → ノイズ制御 Adaptive Cards テンプレート生成 テンプレートJSONに値を差 し込むパターンで管理・再利 用 担当者メンション・状態別色 分けが自在に設定可能 TeamsとSlackで別フォーマ ットに対応 Logic Apps採用の 運用上の理由 Graph API直叩きはEntra ID 権限付与・セキュリティレビ ュー負荷が高い Logic Appsの標準コネクタで Teams/Slack連携を簡潔に実 現 権限・監査の責任範囲をアプ リ外で分離できる
10. Part 1 | 定期レポート DO WHAT MATTERS 10 定期レポート — 保存WIQL + Dapr Cron で自動集計・配信 処理フロー Dapr Cron トリガー 毎朝9時・毎週月曜に自動起動 v 保存WIQL を実行 SLAリスク候補チケットを抽出 v サマリ生成 件数 / 顧客別 / Severity別集計 v Logic Apps 経由で Teams/Slack へ配 信 + ストレージへレポート保存 ノイズ制御の設計 [x] 全チケット変更を 通知 > [ok] 担当者変更など 重要イベントのみに絞 る [x] 毎時レポートを配 信 > [ok] 日次/週次で 集計・まとめて配信 [x] 同一チケットの重 複通知 > [ok] 状態変化ベースで フィルタリング
11. PART2 AGENTIC DEVOPS POC 同じ基盤の上にエージェントを「後付け」する
12. Part 2 | Agentic DevOps PoC DO WHAT MATTERS 12 PoCの構成と現時点の成果 既存基盤への拡張ポイント 定期レポート (既存) WIQLで抽出した リスク候補一覧 > AI エージェント (Foundry/OpenAI) 分析・提案生成 優先度/文面/WI ドラフト > 提案 レビュー 人間が確認・承認 自動実行ではない > 次アクション 実行 エスカレーション WI ドラフト作成 現時点の成果 (定性的) フィールド設計 + 保存WIQL により「SLAリスク候補の抽出」基盤を整備できた 既存の通知・レポートに対し、エージェント提案を「後付け」できる接続点を用意できた 「提案 → 人間レビュー」を前提にすることで、権限・監査・誤作動リスクを抑えた導入モ デルが見えた
13. Part 2 | 学びと評価 DO WHAT MATTERS 13 PoCで得られた学びと次フェーズの評価指標 [!] 落とし穴 精度以前に 入力データ品質がボトルネック (フィールド記載粒度・運用ルールの徹底) 通知価値は「量」でなく 「ノイズ制御」で決まる (条件絞込と提案粒度の設計が重要) [KEY] 導入の基本方針 自動実行ではなく「提案 → 人間レビュー」を前提 に導入し、 権限・監査・誤作動リスクを最小化した段階的な展 開を推奨。 次フェーズ 評価指標 評価指標 定義・測り方 方向 検知リードタイム SLA超過の何日前にリスクとして提示できたか 長いほど良 トリアージ時間 New -> Triage / In Progress までの時間短縮率 短縮率 UP 提案採用率 優先度/文面/WIドラフト等の提案が採用された割合 採用率 UP 通知ノイズ率 不要と判断された通知の割合 低いほど良 変更への接続率 提案起点でWork Item作成やDev改善につながった割合 接続率 UP
14. まとめ DO WHAT MATTERS 14 01 チケットを「運用シグナル 」に Azure Boards のカスタムプロセス + WIQL でSLAリスク候補を構造化 。すべての起点はフィールド設計 にある。 02 イベント駆動で通知を自在 に Service Hooks -> Service Bus -> Dapr -> Logic Apps でフォーマッ ト・送信先をコードでコントロー ル。標準連携を超えた柔軟性。 03 Agentは「後付け」で安全 に 既存基盤の出力をAI入力とし「提 案 -> 人間レビュー」前提で導入。 自動実行より先に接続点の設計を 。 Work Tracking + Event Streaming + Containers + Agents = フィードバックループの加速
15. THANK YOU DO WHAT MATTERS Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art 15