LINEヤフーにおけるAIOpsの現在地

「ENOG89 Meeting」での発表資料です。

Transcript

1. LINEヤフーにおけるAIOpsの現在地 取り組みと効果測定と課題と展望 @ 2026/03 Hiroki Shirokura Cloud Service CBU, LY Corporation ENOG89 2026-03-06
2. Self Introduction • Hiroki Shirokura (HN: slankdev) ◦ Principal Software Engineer @ LINEヤフー ▪ Cloud, VPC, Proxy, Security ▪ Architect, PjM, EngMgr, SWE • Past My Works ◦ Kamuee: SRv6対応の設計と実装に関して - ENOG55 ◦ SRv6 Dplane, Cplane Implementation ◦ High Functional Cloud NFV System Design and Implementation at LINE Cloud ‒ JANOG48 Meeting ◦ ⽇本最⼤級プライベートクラウドをゼロから設計。LINEヤフー 「Flava」が挑む世界基準 ◦ Flava SecureG: Highest Security Cloud Environment after LY Corporation Merger ◦ ENOG89 (LY, Infrastructure AIOps) ← Now we here 3
3. Agenda 1. Background & Motivation 2. AI Agent System Architecture 3. Demonstration 4. Outcome Evaluation 5. Lesson Learnt 6. Issues & Future Work AIでIT運⽤の効率化をするにはどうすればよいの? What we should do for IT operation enhancement with AI 経営者からの「AIで業務改善せよ」に応えるためはどうすればよいの? What we should do for “AIʼs Enhancement” from CEO Open Question 4
4. Background & Motivation AIを⽤いた⽣産性の劇的な向上にむけて > 今後3年間で業務⽣産性を2倍に⾼め、継続的なイノベーションの創出を⽬指す LINEヤフー、全従業員約11,000⼈を対象に業務における「⽣成AI活⽤の義務化」を前提とした新しい働き⽅を開始 • 情シス的取り組み: ChatGPT Enterprise, Codex, Claude code, etc.. • Private Cloud的取り組み: AI API service, MCP Hub, AI Platform Service, etc… • 実際に現場で効果を発揮する取り組み ◦ 開発 -> Claude Code, Codexをほぼ全員が使う空気感 ◦ 運⽤ -> 部分的な活⽤の余地, Codingほど⺠主化されているとは⾔えない空気感 > LINEヤフー、AIカンパニー構想を本格化 全サービスにパーソナルエージェント導⼊ LINEヤフー、AIカンパニー構想を本格化 全サービスにパーソナルエージェント導⼊ | Ledge.ai LINEヤフー決算説明会 <- 今発表 5
5. Background & Motivation AIを⽤いた⽣産性の劇的な向上にむけて i.e. Private Cloud operation Cloud Data plane Cloud Control plane Grafana Alert manager PromQL API (on TSDB) Slack PagerDuty OpenSearch DSL LogQL API Metrics PF Log PF OpenSearch Dashboard Me while on-call Cloud Data plane Check system metrics via Grafanaʼs visualization Login to check raw system status (like docker ps, df -h, etc..) Confirm dataplane status (like hypervisor down by hardware issue) Check entity relation (Virtual Router A3 is running on Hypervisor D14) Get a phone call when some error or critical issue is occurred and operatorʼs handling is needed Call PromQL raw query to investigate more detailed information related to the incident System status check api System status cache api Other ops PF Operation Run Books 6
6. i.e. Private Cloud operation (1) Hypervisor Down 7
7. $ openstack compute service list --host \ hv00000-xxxx.xxx-az2.xxxx.xxx \ -c Zone -c State -c "Updated At" +---------+-------+----------------------------+ | Zone | State | Updated At | +---------+-------+----------------------------+ | kks-az2 | down | 2026-02-13T20:00:00.000000 | +---------+-------+----------------------------+ $ ping hv00000-xxxx.xxx-az2.xxxx.xxx PING hv00000-xxxx.xxx-az2.xxxx.xxx (10.0.0.1): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 i.e. Private Cloud operation (1) Hypervisor Down 8
8. i.e. Private Cloud operation (1) Hypervisor Down 9
9. Background & Motivation AIを⽤いた⽣産性の劇的な向上にむけて i.e. Private Cloud operation • Operationにおける指標 ◦ Time To Detect (TTD) ◦ Time To Identify (TTI) ◦ Time To Recover (TTR) -> よくMTTRとかいうやつ. • 傾向: 我々はTTI関連でTOILがある. ◦ ⼈によって確認の解像度もちがったり, コーナーケースの閃きなどには差がある. • 傾向: 我々は優先度が⾼くない課題を放置してジリジリとボディーブローを受けている ◦ 優先度が低いアラートが対応されないまま散乱し重要な前兆に気づかない ◦ 爆弾が爆発するまでは安全だからとりあえず放置. -> 数ヶ⽉放置されて爆発. ということもある 10
10. Background & Motivation AIを⽤いた⽣産性の劇的な向上にむけて i.e. Private Cloud operation • どんな情報をみるのか ◦ 先ほどのシステムの情報を縦横無尽に確認して閃きにあわせてデバッグする ▪ 主に以下が多い ▪ Cloud Infrastructure System (Baremetal, VM, K8s, etc...) ▪ Prometheus Metrics (TSDB API), Alertmanager ▪ Slack, PagerDuty • ⾏う作業 ◦ 初動調査としての結論とその根拠 (Nova HV statusがdown, ping fail, etc..) ◦ Silence -> 無視するだけ ◦ Refresh -> 仮想ルータをサービスアウトしたり, Nodeを再起動したり ◦ etc… これはAIが得意な範囲かもしれない. 11
11. Introduction to EDITH Project Goal(1): Toil Elimination • 障害対応時などに15min程度の データ分析を行う部分をなくす • OnCall業務における初動確認という業務をなくす • 発展的に効率化の種は見つけて育てる Goal(2) Human-AI Symbiosis • AI運用で良かったねとメンバーが思う状態を目指す • 導入障壁を覚悟しつつ , 運用の基本Interfaceとして実験的に取り入れる . 12
12. Edith Chat • 今でいうClaude coworkに限りなく近い ⼀通り必要なツール(抜粋ずみ)をもつ. 必要なKnowledgeもPromptingずみ. 13 functions.o11ymcp.run_promql functions.o11ymcp.run_logql functions.o11ymcp.alertmanager_list_alerts functions.o11ymcp.alertmanager_list_silences functions.o11ymcp.alertmanager_create_silence functions.nfvcplanemcp.run_kubectl_get_json functions.openstackmcp.openstack_list_sli_monitors functions.toposmcp.topos_get_hypervisor_by_server_hostname functions.emsmcp.ems_list_failed_hypervisors functions.alertmanualmcp.list_alerts functions.alertmanualmcp.create_alert functions.alertmanualmcp.list_history functions.alertmanualmcp.create_history functions.alertmanualmcp.update_history functions.alertmanualmcp.delete_history functions.opsmanualmcp.ops_manual functions.githubmcp.* (github mcp) functions.coretool.bash functions.coretool.directory_create functions.coretool.execute_jq functions.coretool.ls functions.coretool.tree functions.coretool.file_glob functions.coretool.file_grep functions.coretool.text_file_grep functions.coretool.file_info_get functions.coretool.text_file_read functions.coretool.ping functions.coretool.todo_read functions.coretool.todo_write
13. Edith Inbox • 定期的な調査や整理結果をまとめる場所. InboxからChatを開 始できるようになっている. • 内部的には同様にChat Sessionと同様のコンテキスト管理がさ れていて, 結論のみ定期実⾏の結論のみメモとしてのこす. • Chat側のPromptには汎⽤的な情報しか書かれていないが, Inboxである程度の初動調査などを実⾏し, そこからChat Sessionを始められるようにしてある. • 「Private Cloud Region AでこのようなError Alertがでてい るがこれらの根拠によりおそらくサイレンスを⼊れておけばよい よ」 • 「サイレンスが切れそうになっているけども原因となる状態はま だ維持しているので延⻑しておくと良さそう」 • 後述 14 Inbox == AIがやっておいてくれた仕事のサマリーがまとまる場所
14. EDITH Architecture 15 Core Component • EDITH Chat: Chat Interface. 今でいうClaude coworkに限りなく近い • EDITH Inbox: 定期的な調査や整理結果 をまとめる場所. InboxからChatを開始で きるようになっている. Design Principle • Agent Harnessは取り替える可能性を前 提とする. (今は⾃前実装だが, Claude Code等をChat部分では使うかもしれな いし) • どのHarnessを使ったとしても必要になる 部分に⼤きく投資し, 取替可能部分はでき るだけ簡素的に実装管理
15. EDITH Architecture 16 • Workspace Base Context Management ◦ Claude codeが出た当初に即座に真似 • Data Analysis with Code, Query ◦ Firewall log: no-code:15⾏, code:1000⾏ 成功 ◦ SDN database entry: no-code:10個, code:1000個 成功 ◦ 前提の事実として, だいたい⼈がプログラムやクエリ⾔語をたたいたりするよりもLLMのほう がそういったのを⽣成するのは上⼿である. 覚えてるクエリを実⾏するのでなく, 0からクエリ を出せるので, 「JQが得意なこの⼈に少したすけてもらってから情報収集する」とか 「PromQLが得意なこの⼈に助けてもらいながら情報収集する」とかのDelayがない. ◦ ある瞬間のPrivate Cloud Alertデータの量は2M token • Code Mode / Code Execution with Tool ◦ 中⻑期に⼤規模に進める過程で停⽌しないようにするテクニック ◦ Claude code等のToDo管理などである程度価値が減少しているかもしれない
16. Demonstration 17 スクショなどは後⽇公開予定
18. 19 EDITH Inbox Item
23. 24 EDITH Chat
36. 37 所感... • Promptはどのくらいの量? ◦ agent_base_instruction: 2.5K token ◦ instructions_for_flava_alerts: 18K token ◦ inbox context: 2.3K token • ちいさなテクニック ◦ bash, pythonツールを制限すると⼤きく時間がかかる... ⼀⽅で安全性も⼼ 配である... データの読み込みだけしかできないような⾮常に隔離された sandboxを簡単に呼び出せるようにしておくのがよいだろう. ▪ ChatGPTは中でそうやってますよね.
37. Performance? • 今⽇時点では応答までの速度は遅い ◦ 集中した状態だと1,2分で確認できることがAIだと5,6分 ◦ いらないツールも実⾏しながら推論にも時間がかかる. ◦ しかし⼈間 の割り込みとそれを⾒に⾏くコストを考えると価値は⼗分 ▪ Googleではアラートがでてから5min以内にAckしないといけない ▪ LY Cloudでは明確なルールはなくも, ⼤体5~15min程度 ◦ とはいえいつでもすぐに, ⼈と⽐ てはるかにたくさん実⾏可能な利点を活かす⽅針 • Inbox Summary⾃体のContext内容を⼯夫する余地がかなりある. ◦ まだ⾛りながら調節中. ◦ 現在はRegion, Environmentごとにまとめて集計 ◦ 重要アラートのみまとめて集計とか, バリエーションが複数かんがえられるがまだやってない 38
38. Maturity & Milestone step1 2025.10.01 39 AI Work Human Work Incident start → Incident identified → Incident recovered → MTTI improvement MTTR improvement step2 2025.03.01 step3 2025.04.01 Only approve Including Human command execution MTTR improvement • Other Important Key Metrics ◦ Number of incidents (100 times x 10 min-TTR-improve == 16 h saved) ◦ Coverage & Works for AI Awareness ▪ ROI: “With AI with toooooo much AI-nize time” <<< “No AI”
39. 特に気をつけていること AIによる改善を測定可能に 40 • まだ⾒たことない改善された状態を⽬指す以上指標がほしい ◦ 新しい機能を作る, 機能を変える, ⽅向転換をする, の決断のために ◦ アーキテクチャ⾃体に影響がでうるため技術や⽅法に固有でないメトリクス ◦ (=~ 推測するな計測せよ) • 我々の具体例 ◦ Incident Reportから同様の事故を再現 (TTI, TTR, ⼈間補助回数) ◦ Chaos EngineeringのGame dayをAI中⼼に実施 (TTI, TTR, ⼈間補助回数) ◦ それぞれ「いまは⼈が良いか, AIの⽅が良いか」を量⼦化 ◦ ⾃動計測されていなくてもそのメトリクスを計算できることが⼤事 • 参考: Shownet 2025の事例 ◦ Shownetでは+1, -1でFBを記録できるように. ◦ AI利⽤者が何を求めているかは千差萬別である可能性から直接FBの価値が⼤きい ◦ ⼀⽅我々はある程度⽬的が明確なケースも多く, FBの負荷が削減可能かもしれないと考えてみる まだまだ 試⾏錯誤中 プロジェクト としての評価も ドライになる
40. 特に気をつけていること: AIを⽣かしやすい会社設計に移⾏ 41 • ⽬的を「運⽤負荷を軽減する」、⼿段を「AIを活⽤する」ともしするのであれば避けられない ◦ 第⼀原則で再設計し, 現状との差分を認知して, 効果的な状態移動を促すだけ. ◦ 場合によっては運⽤のルールを変える.(政治もあきらめない) • 我々の⾏っている具体例 ◦ Operation Policy, Operation Catalogなど, ⼈とAIが⾒る資料を共通化. 型づけと分類 ▪ 関連事故件数, 作業ごとのリスク, 確認項⽬, 懸念コメント, etc.. ▪ AIがその作業をする時は読んでヒントにできるようにしておく ▪ 運⽤向けAIアプリだけでなく, Codex, Claudecodeでも参照する⼈が増えてきた ◦ AIも⼈にもリスクの低い作業で⾊々できるようにしておく ▪ 「経路の迂回は⼀定の⾃由度で⾏える温度感」 ▪ 「プロセスの再起動はいつ起こってもよいことにする」 ◦ AIが⾃由にサーバにログインして何かするのは最終⼿段 ▪ 流⽯にコンプライアンスのリスクもある ▪ システム状態確認はツール型で制限 (docker ps, show bgp, traceroute, etc..) ▪ ツール系はReadは広く, Writeは狭く まだまだ 試⾏錯誤中
41. 特に気をつけていること: AIを⽣かしやすい会社設計に移⾏ 42 • アナロジー ◦ IPv6 Prefixのみでトラフィックを引き込めるようにして BGPだけでも成⽴するSRを実装しよう (SRv6) ◦ L3VPN Cplaneを全て実装するのでなく, BGP L3VPNを実装してUpstreamし, BGPの設定のみをSDN Planeで⾏おう (LINEのVPC Cplane実装) ◦ Dplane側で実装する きFailoverを ⼀部Cplane側で実装してしまった結果事故がおきる (LINEのVPC Cplaneでの事故例)
42. 43 • 経験的な基本⽅針(2026.02時点): ◦ 運⽤関連のツールはReadは広くWriteは狭く. ◦ 評価指標に合わせて, 具体と抽象を探索(いつもいっしょ), この営みをスケールさせることに注⼒ ◦ LLMは確率的な挙動をするものだという前提を崩さない • 「毎回, パラメータをかえながら何度も試⾏錯誤してやっと成功する」 ◦ 別に問題ないという判断も可能 ◦ Foundation Modelが改善するだけで⾃動的に解決するかも • 「このサイレンスツールは危険度が⾼いから必ず承認制にしよう」 ◦ ツール引数を静的にvalidationし, ⾃由実⾏をゆるそう ◦ サイレンスはドメイン知識系なので特に安定性が低いと考える • 「このサイレンスツールは毎回パラメータが安定しないな」 ◦ 「プロンプトを改善したらよいんじゃないか...?」 ◦ 「ツールをもう少し仕事に対して明確化したらよいんじゃないか...?」 ◦ ⼀般的にケースバイケース. どっちもやってます. 特に気をつけていること: AIにやらせること, やらせないことを管理する 結局は⼿段である集中と分散の トレンドのようにおすすめはエ コシステムの引⼒に影響を受け て重⼼がきまる エコシステムは我々は コントロールできない. 誰ならできるの? Claude codeの⼀例
43. 44 仕事のほとんどはただの⾃動化 「完全に型のきまった⾃動化 + ⾃動化を助けるAI」 特に気をつけていること: AIにやらせること, やらせないことを管理する 汎⽤的な知識をもとにAIが⾃律的に作業 「型付ツール + 汎⽤知識 + 特殊性のある質問」 • 「どれだけ確率的な動作を排除したいか」 • 「都度都度の微妙な前提の違い」で威⼒を発揮するんじゃないか • 「Disposableに分解と組み合わせをしたくなるほど汎⽤的に知識が ⾔語化されるか」次第でもかわるな... ⾊々まよう時期なのでいっぱいためして⾃分(⾃社)なりの答えをだそう!
44. どれもAIに限らず⼀般的なコツ 45 しかし当たり前にやり続けるのも結構難しい
45. 直⾯した課題と考え⽅ • 確率的な動きがゆえに品質改善時に認知負荷がたかく, 進まずに放置されてしまう件 ◦ 評価まわりのCriteriaを明確にしてできるだけ脳がストールしないように集中 • MCP認証まわりの成熟度の課題 ◦ 基本的に時間の問題だと楽観視 ◦ IDaaS, Application, MCP Client, それぞれの成熟度の課題 • AIを上⼿に使う⼈と使えてないひとで差分が開く ◦ 開発 -> いたしかたないと判断中 ◦ 運⽤ -> ⼈間の⼊⼒を最⼩限にすることで下⼿にできないように(inboxのコンセプト) • 作ったは良いけど本当の意味で活⽤はされなかった未来 ◦ ありえるので教訓で説明した「効果測定」を起点に1,2年は怪しんで監視予定 • すごいAI製品がでてきてす て⽔の泡になりうること ◦ 歓迎. しかしその製品が使えない場合もありえるので「なぜ」の理解は重要視 46
46. まとめと今後の展望 • 経営者からの「AIで業務改善せよ」に応えるためは? ◦ 業務性能を可視化して, あとはそれをメトリックにしながらエンジニアに投資しよう ◦ AIアプリに対して⼈の⼊⼒を最⼩限にするようにコンテキストを先んじて集める⼯夫をしよう • 今後の展望 ◦ Inboxの切り分け⽅は⽇々再考 ▪ どの粒度でインボックスをまとめる きか複数のバリエーションを考え中 ◦ 適⽤領域を増やしながら効果測定と改善を継続 ▪ 早くチームを縮⼩してリソースを重要事項に追加投資したい ▪ 複数のチームで導⼊実験など ◦ 品質向上のフローをよりスケールさせる ▪ Skill Mining: Miningされる対象の情報処理をPFレイヤーで回収. 作業記録や⼿順書など ▪ Auto Refinement: そんなこと本当にできるのかというレベルであるが... ▪ Dataset Scaling: 今はそもそも⼿作業が多い. お願い: 今回の発表のフィードバック(もっとこんなことを聞きたい)をヒントに定期的にJANOGやENOG で発表はし続けようとおもいますので気になったことはぜひ僕に届くようにコメントください！ 47
47. End of Presentation 49