AIに丸投げしないトイル削減 / Eliminating Toil Without Leaving It All to AI

[SRE AI活用事例] 減らせ！TOIL削減大作戦！
https://mixi.connpass.com/event/403987/

Transcript

1. AIに丸投げしないトイル削減 2026/09/09 【SRE AI活⽤事例】減らせ！TOIL削減⼤作戦！ #BIZREACH_MIXI @kohbis ©MIXI 1
2. ABOUT ME Kohei SUGIMOTO 株式会社MIXI • 2022/04 ~ 『家族アルバム みてね』SRE X/ ©MIXI @kohbis 2
3. 『家族アルバム みてね』について（1/2） 家族アルバム みてねはスマホで撮った⼦どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。 ©MIXI 3
4. 『家族アルバム みてね』について（2/2） 2015年にリリースから、7⾔語‧175の国と地域で3,000万⼈以上の⽅にご利⽤いただいています。 人数 国内 海外 30,000,000 25,000,000 20,000,000 15,000,000 10,000,000 5,000,000 0 20 15 20 1 6 20 1 7 20 18 20 19 20 20 20 21 20 22 20 23 20 24 20 25 20 26 年月 .5 ※ iOS‧Android™ アプリ登録者数、ブラウザ版登録者数の合計 ©MIXI 4
5. たまにやる、思い出したときにやる業務たち 「やる価値はある。でも急ぎじゃないしそこまで重要ではない。 でもやる価値はある。でも忘れがち。でも（ry …」系のタスク たとえば • 「インフラのリソース割り当てに過不⾜がないか」 • 「Dockerイメージサイズ、肥⼤化してないか」 • 「テスト（CI）をもっと早くできないか、遅くなってないか」 • 「前にレビューで指摘したことは、ドキュメントやテストに追加したか」 なんとなくやることや流れは決まっていそう しかし、⼿順化するタイミングも逃しやすい （なぜなら思い出したときにやるから） ©MIXI 5
6. “トイル” とは？なぜ減らす？ Google SRE - Chapter 5 - Eliminating Toil ※1 より • ⼿作業である（Manual） • 繰り返される（Repetitive） • ⾃動化できる（Automatable） • 戦術的である（Tactical） • ⻑期的な価値がない（No enduring value） • サービス成⻑に⽐例して増加する（O(n) with service growth） 少量なら薬（⼩さな成功や達成感）にもなるが、過剰になると毒（toxic）になる • 個⼈ キャリアの停滞、⼠気の低下 • 組織 進捗の鈍化、引き受ける前例をつくる、離職の促進 ※1 https://sre.google/sre-book/eliminating-toil/ ©MIXI 6
7. “誰にとっての” トイル？ 「これはトイル（嫌なこと）だ」は主観的に語られやすい ※1 • より正確に定義することが求められる • あるひとにとってトイルは、別のひとの権限で⾏われるべきかもしれない 今⽇のスコープ • • みてねのSREチームにとってのトイル 「改善業務」そのものはエンジニアリング • データ収集や抽出、（機械的な）判定、過去の事例‧実績を探す これらはトイルになりえる 業務を分解すれば、トイルだけを取り出せるはず ※1 『SREをはじめよう』https://www.oreilly.co.jp/books/9784814400904/ ©MIXI 7
8. AIに丸ごとまかせればいいのでは？ 「もちろんアリ」 しかし、現実にはAIあるあるな課題‧可能性と向き合う必要がある • 実⾏ごとの品質や、変更の再現性にブレがある • AIによる作業で完結するため、誤った⽅針でも突き進んでしまう（特にCI） • データ（メトリクスなど）は量によってはコンテキストに収まらない • LLMでデータ収集や集計まで⾏わせると、トークン消費が増加する • （⼈間が⾏うような）広い権限を与える必要があり、意図しない動作による事故 が発⽣する 「丸ごとまかせる」ことであらたに「AIのためのトイル」が発⽣する可能性がある （もちろんコンテキストやスキルによる調整やガードレールを効かせる余地はある） ©MIXI 8
9. 「ループに任せる」の潮流に逆らっていないか？ ループエンジニアリング ※1 Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. ただし • 作業者と検証者（Verifier）が分かれている • 検証可能な停⽌条件（ /goal ） などが必要となる それでも “Done” is a claim and not a proof. であり Verification is still on you. ※1 https://addyosmani.com/blog/loop-engineering/ ©MIXI 9
10. 今⽇お話しすること 誰にとってのトイルか • みてねのSREチームにとってのトイル（再掲） なにをやりたかったか • AIによってトイルを削減したい • AIによるDone（完了）を、 claim（主張）から proof（証明）に近づけたい そのためになにをやったか • 業務を分解してトイル部分だけを取り出し、そのステップだけをAIに任せる • ほかのステップは可能な限り、決定的なロジックに寄せる ©MIXI 10
11. 「業務のレイヤーを分解して、AIの仕事を局所化する」アプローチ 蓄積 抽出 具体的な実装で実現できる（⾃然⾔語にしない） • • • ©MIXI 判定 修正 レビュー AIはここだけ ⼈間 + CI 「蓄積」「抽出」「判定」までは、CIやクエリ、コードを書く 毎回「同じ⼊⼒から同じ出⼒」が期待できるため、再現性のある説明が可能 「蓄積」は新しい何かとは限らず、モニタリングなど既存データを使⽤できる 「どのように直すか？」という思考を伴う「修正」は、AIの仕事にする 「レビュー」は⼈間とCIが⾏い、AIよる修正にも⼈間が作ったPRと同じ検証を⾏ う（もちろんAIがレビューするケースは多い） 11
12. 実践① K8sリソース最適化（1/2）〜判定のルール化〜 K8sリソースの過剰な割り当てはコスト増につながるが、気づきベースでの調整 ※1 （ワークロードによっては使⽤量が時間経過に伴い変化） Prometheusに蓄積された実際の使⽤量と、resources設定（YAML）を突合する • • • 適正値（推奨値）をロジック化（例） • max(p50) * 1.25 • HPAが指定されている場合は、そのtargetを採⽤ • CPUは 50m 、Memoryは 128Mi 単位で切り上げる 要⾒直しも機械的に判定（例） • recommended < request （削減のみ） • 1 - recommended / request >= 40% （削減率） • (request - recommended) * pods >= 2core / 8Gi（削減総量） ⾒直し対象はリストファイルで管理、⽅針はMarkdownにドキュメント化 ※1 K8sのリソース管理を容易にするツールやサービスは存在する ©MIXI 12
13. 実践① K8sリソース最適化（2/2） 「判定をロジックに落としたら、この改善業務にはAIは不要だった」というオチ 当初は、最終的にAIによる分析、PRの⾃動起票なども⾒込んでいた （実装も⾏い、PR起票もいい感じに動いた） • しかし、推奨値はロジックで算出済み AIは推奨値から修正対象箇所を⾒つけてPR起票するだけ AIに任せる意味がほとんどない • そもそもが「思い出しベースで⾜りていた」温度感 • 将来的にはワークロードごとの重要性などのコンテキストを加味したうえで、PR 起票まで⾏う可能性はある 業務を分解したことで「AIを使わなくていい」ということがわかった （もちろん、このワークフロー構築にはAIが⼤活躍している） ©MIXI 13
14. 実践② スローテスト改善、コンテナイメージサイズ削減（1/2） スローテストの増加も、コンテナイメージサイズの肥⼤化も、気づきベースで対応 パイプラインにあてはめて、AIの作業を「修正」に局所化 レイヤー スローテスト改善 コンテナイメージ削減 蓄積 CloudWatchにテスト時間を記録 存在するECRイメージ 抽出 最遅specをn件だけ取得 dive ※1 で構成を分析 判定 ルール（遅い順） ルール（削減余地の有無） 修正 AIが⾼速化PRを⽣成 AIがDockerfile修正PRを⽣成 レビュー ⼈間 & CI ⼈間 & CI ※1 https://github.com/wagoodman/dive ©MIXI 14
15. 実践② スローテスト改善、コンテナイメージサイズ削減（2/2） AIによる修正を「局所化」するためのガードレールづくり、調整は必要 • • • 出⼒の制約 • PRテンプレート準拠の強制 • 修正を「やり込みすぎない」ように限定 （例）Dockerfileでパッケージに同梱されるdocをオプション以外で削除不可 作業相応のモデルの選択 発散の防⽌ • そもそも「局所化」したはずなので発散する余地は少ないはず • （例）サブエージェントやMCPの制限、CIの実⾏上限設定 • （参考）Claude Code ActionでAgent ModeとTag Modeの挙動差異を調査 した記録 at Zenn ※1 ※1 https://zenn.dev/mitene/articles/202607-claude-code-action-tag-vs-agent-mode ©MIXI 15
16. 実践③ AGENTS.mdの⾃動更新 〜AI時代のあらたなトイル〜 TerraformのPRでレビューで指摘した観点が、PRコメントかレビュワーの記憶にしか なく、全体に徹底されない レビューコメントからルールを抽出し、AGENTS.mdへ⾃動的に蓄積＆統廃合 マージ済み PRの レビューコメント • • • ルール抽出 ⼈間の作業は「PRをマージする」だけ （ googleapis/release-please ※1から着想） ルール抽出、統廃合の基準（プロンプト）⾃体を ⽂書化してレビュー対象にする AIが⽣成するコードおよびAIによるレビューの 品質をAGENTS.mdから両⽅向に改善し続ける AGENTS.md改善を蓄積した PRに追記（なければ起票） 肥大化を避けるために しきい値超えで統廃合 ※1 https://github.com/googleapis/release-please ©MIXI 16
17. 「業務の分解」「AI活⽤の局所化」の副作⽤ 「業務のレイヤーを分解して、AIの仕事を局所化する」アプローチによって いままでトイルと認識していたものの⾒え⽅が変わる（かもしれない） • • 完全に定型化できる作業だとわかった 機械的に⾃動化 or エージェントへの定型依頼として（あえて）丸投げ • （例）DevinのPlaybook + Automation • Rubocop TODO ※1 の継続的な削減、Terraformブロックお掃除 ⼈間がレビューで守っているだけのルールだとわかった ポリシーテストやフォーマッタによって機械的に作業⾃体をなくす AGENTS.mdに追記し、（あえて）AIのコーディングやレビューに丸投げ レイヤーを分解することで、各レイヤーにおける⼿法の置換も容易になる ※1 https://docs.rubocop.org/rubocop/latest/usage/auto_gen_config.html ©MIXI 17
18. まとめ • • • 判定はAIに委ねない（委ねすぎない） 判定をルール化することで、品質のブレやトークン消費を抑えられ AIが不要になる AIの仕事は局所化し、実⾏や出⼒それぞれにガードレールを設ける 可能な作業、権限の範囲を絞る 出⼒はテンプレートを強制し、CIで検証する ⼈間の介⼊ポイントをセットで設計する 「PRをマージするだけ」「分析結果を⾒るだけ」まで決めて⾃動化する 「業務のレイヤーを分解して、AIの仕事を局所化する」アプローチにあてはめれば トイル削減の仕組みは量産できる ©MIXI 18
19. ありがとうございました ©MIXI 19