Slide 1

Slide 1 text

© Ubie,Inc. SRE へのサポートケースを AIに管理させる方法 SRE NEXT 2025 #srenext_b 2025 / 07 / 11 Ubie 株式会社 飯國 隆志

Slide 2

Slide 2 text

2 自己紹介 飯國 隆志 (Takashi Iiguni) ● SRE ● Ubie (2024~), NTT Com(2022~) @guni1192

Slide 3

Slide 3 text

3 Ubie について 月間1200万人以上の生活者が利用 メガファーマの約9割が活用 15,000件以上の医療機関と連携 生活者向け 医療機関向け 製薬企業向け

Slide 4

Slide 4 text

4 Ubie における SRE への問い合わせの課題

Slide 5

Slide 5 text

327件

Slide 6

Slide 6 text

327件 2025年 4月-6月の間 Ubie の SRE, DE に寄せられた問い合わせの件数

Slide 7

Slide 7 text

7 Ubie における他のチームからインフラチームへの相談内容 ● terraform 等の PR のレビュー依頼 ● Google Cloud / GitHub への権限付与 ● デプロイ失敗時のトラブルシュート ● データ分析の相談 ● 新規サービスのインフラ構築の相談 1m-5m 数週間 1営業日

Slide 8

Slide 8 text

8 Slack で問い合わせを受け付けてチケット化 ● スレッド単位で問い合わせをチ ケット化して対応 ● チケットのステータスは SRE の daily standup で共有する

Slide 9

Slide 9 text

9 課題1: 問い合わせ対応に取られる工数が肥大化 ● 月間100件以上の問い合わせを3人で回していた ● もっとインフラの根本的な改善に工数を割り当てたい ○ コスト最適化, 開発者体験の向上, 諸々のマイグレーション ● 問い合わせ対応に1日の稼働の50%以上使うこともある 月100件 エンジニア 70人 SRE 2人 + Data Engineer 1人

Slide 10

Slide 10 text

10 SRE への問い合わせを Toilととらえる > Our SRE organization has an advertised goal of keeping operational work (i.e., toil) below 50% of each SRE’s time. At least 50% of each SRE’s time should be spent on engineering project work that will either reduce future toil or add service features. Feature development typically focuses on improving reliability, performance, or utilization, which often reduces toil as a second-order effect. Chapter 5 - Eliminating Toil, https://sre.google/sre-book/eliminating-toil/ ● 問い合わせの多くはマニュアル的な作業 ● 問い合わせの多くは、反復的に発生する ● 問い合わせは、サービスや組織の成長によって増える O(n)

Slide 11

Slide 11 text

11 課題2: SREのメンバー内で対応できるかボラがある ● SRE内でも一貫性がない回答になることがある ● SRE内でもベスプラが浸透してないこともある SRE エンジニア 「これどうすればいい?」 「@sre これ誰か知ってる?」

Slide 12

Slide 12 text

12 問い合わせの Toil を削減し 50%の稼働を確保するために ● 定型の問い合わせを SRE が介在することなく解決できる ● チケット管理のオーバーヘッドを限りなく減らす

Slide 13

Slide 13 text

13 あとはAIに任せる

Slide 14

Slide 14 text

14 Slackのスレッドをチケット化するサービスを内製 (otter) ● Slack Bot + Webアプリとして動作 ● AI によるチケットの一次回答 ● AI がチケットの優先度、アサインを判定する

Slide 15

Slide 15 text

15 infra-help-otter のアーキテクチャ

Slide 16

Slide 16 text

16 自チーム向けに欲しい機能を内製 ● 優先度に応じてSlackでリマインド ● 統計情報 (チケット数と解決にかかった時間) ● AIによるチケットのタグ付け ● 稼働時間の計算

Slide 17

Slide 17 text

17 Ubie の インフラに関するドメイン知識が不足している ● Ubie のインフラのアーキテクチャ ● Ubie のアプリケーションのデリバリーの仕組み ● Ubie では非推奨な機能、サービス 「知らんがな」 「AI君は入ってきたばかりだから知らないかもしれないけど」

Slide 18

Slide 18 text

18 AI君のオンボをしよう ● 開発者ドキュメントを量産 ○ フォーマット決めて cursor に書かせた ○ GitHub Pages + Hugo で社内に公開 ● Vertex AI Search のデータソースを作る ○ チケットが作られたら初手ドキュメント検 索してリンクを提示

Slide 19

Slide 19 text

19 otter に問い合わせるとき 1. スレッドを立てる 2. チケットを作成 3. AI による一時回答 4. 作業待ち / Review 5. Close Engineer 新しくリリースしたService A から Service B に疎通でき ない

Slide 20

Slide 20 text

20 otter にチケットを作成する流れ 1. スレッドを立てる 2. チケットを作成 3. AI による一時回答 4. 作業待ち / Review 5. Close アサインと優先度判定も 合わせて行う

Slide 21

Slide 21 text

21 otter にチケットを作成する流れ 1. スレッドを立てる 2. チケットを作成 3. AI による一時回答 4. 作業待ち / Review 5. Close InfraHelpOtter Istio の Authorization Policy を確認してください Summary: サービス間通信の方法について、以下の情報を提供します。 <略> Links: *1 https://docs.example.com/how-to-setup-istio-authorization-policy *2 https://docs.example.com/about-istio

Slide 22

Slide 22 text

22 otter に問い合わせるとき 1. スレッドを立てる 2. チケットを作成 3. AI による一時回答 4. 作業待ち / Review 5. Close Engineer PR 作ったから見てほしい SRE @InfraHelpOtter ack InfraHelpOtter チケットを In-Progress にしました Engineer Authorization Policy 設定する PR 出す SRE Approve した @InfraHelpOtter hold InfraHelpOtter チケットを In-Review にしました

Slide 23

Slide 23 text

23 otter に問い合わせるとき 1. スレッドを立てる 2. チケットを作成 3. AI による一時回答 4. 作業待ち / Review 5. Close SRE @InfraHelpOtter close InfraHelpOtter チケットを close にしました Engineer Merge して動作確認できたー

Slide 24

Slide 24 text

24 otter の導入効果

Slide 25

Slide 25 text

25 社内のナレッジとの連携で Toil を削減 After ● bot が提示するドキュメントで事足りる場合はプロダクトチームが手を動かした方が早い ● そもそも問い合わせチケットを作ることなく自己解決する Before ● 説明するのが面倒で SRE が手を動かして PR 作っちゃう ● 毎回必要なリソースが定義されている GitHub のリンクを探して、手順を人間が書いてあげる

Slide 26

Slide 26 text

26 コミュニケーションパスの統一 After ● #help-xxx チャンネルに議論を集約できる ○ 他のチャンネルから #help-xxx チャンネルにスレッドを要約してチケットスレッドにする機能 Before ● 他のチームのチャンネルや times で相談されて、SREの稼働が把握しにくい ● 各チームで議論している最中に呼ばれて今北産業状態

Slide 27

Slide 27 text

27 人力チケット管理からの解放 After ● 優先度が高いチケットは毎朝botがリマインドする ● 対応する人のロールや稼働日に応じてAIがチケットのアサインを割り振る ● チケットのステータスが変わるごとに差分をAIで要約する Before ● 毎朝マネージャーがスレッドを遡って手動でリマインド ● ランダムでアサインされた人を手動で再割り当て ● 並列でやっていると「これどういう状態?」ってなりがち

Slide 28

Slide 28 text

28 全社に展開 ● Corp IT、経理、総務、社内生成AI、医療機関NWなどにも展開 ● 既存のSaaSを置き換えてでも使いたいと言ってくれるチームも! ● 社内生成AI サービスとの連携でアクセスできるナレッジも広がる

Slide 29

Slide 29 text

29 問い合わせにかかる工数は削減できたか ● 問い合わせの件数, 解決にかかる時間はむしろ増加傾向 ☔ ○ ドキュメントに書いてあるような問い合わせはかなり減った ○ 新しい課題に専念できるようになり、時間がかかるタスクが増えた ○ SRE の問い合わせにかけられる稼働が減った 本格稼働開 始

Slide 30

Slide 30 text

30 今後の機能追加 ● AI 機能の強化 (AI だけで50%以上のチケットの解決を目指す) ○ Agent化: 一次回答だけで終わらせない ■ Bulk で検索結果だけ渡しても目が滑る ■ ヒアリングしていくと how が変わることがある ○ MCP の実装: ■ server: daily stand up でチケットの情報を自動で取得する ■ client: 社内のナレッジを拾いやすくする

Slide 31

Slide 31 text

31 目指すは手を動かすことなく問い合わせが完了している世界

Slide 32

Slide 32 text

32 まとめ ● SRE への問い合わせ件数が増え、工数が爆発 (327件, 2025/4-6) ● SRE への問い合わせをAIで管理するサービスを内製開発 ○ AI による優先度判定、アサイン ○ 社内ドキュメントとの連携とAIによる一時回答 ● 全社に展開して、AI がシームレスにナレッジにアクセスしつつ全社の Toilを削減していく

Slide 33

Slide 33 text

© Ubie,Inc. 33 採用情報 Ubieでは積極的に採用を行っています。あ なたの応募をお待ちしています。 https://recruit.ubie.life/ We Are Hiring! https://x.com/UbieCorp_JP https://www.facebook.com/ubie.inc https://www.linkedin.com/company/ubie-inc Ubie公式 採用サイト