GenAIOps: 生成AI時代の DevOps

GDG on Campus Japan Convention 2025 での登壇資料です https://gdsc-jp.connpass.com/event/361579/

Transcript

1. GenAIOps: 生成AI時代の DevOps Asei Sugiyama
2. 自己紹介 杉山 阿聖 (@K_Ryuichirou) Software Engineer @ Citadel AI Google Developer Expert @ Cloud AI MLSE GenAIOps WG 機械学習図鑑 共著 事例でわかる MLOps 共著
3. TOC 生成AIの衝撃 <- MLOps までの道のり GenAIOps 発展的な話題
4. 生成AIの衝撃 古典的機械学習 生成 AI 生成 AI の創発性 Vibe Coding Spec Driven Development 本当に早くなったのか 新しい問題なのか Software Engineering とは
5. 古典的機械学習 AI といえば機械学習アル ゴリズムだった 今も有用ではある 秋庭 伸也, 杉山 阿聖, 寺田 学 著, 加藤 公一 監修 「見て試してわかる機械学 習アルゴリズムの仕組み 機械学習図鑑」 翔泳社 2019年 https://www.shoeisha.co.jp/book/detail/9784798155654
6. 生成 AI
7. 生成 AI の創発性
8. Vibe Coding 自然言語で指示するだけ でコーディングを行わな いスタイル 非専門家がアプリケーシ ョン開発可能に プロトタイピングのため の試行錯誤が容易に Andrej Karpathy / X https://x.com/karpathy/status/1886192184808149383
9. Spec Driven Development AWS が開発した Kiro で導 入された開発手法 プロンプトからまずは要 件を記述 要件に基づきコード生成 (Plan first, then build.) GitHub からも Spec Kit が 発表された Kiro: The AI IDE for prototype to production https://kiro.dev/ github/spec-kit: Toolkit to help you get started with Spec-Driven Development https://github.com/github/spec-kit
10. 本当に早くなったのか AI の導入が 25% 増加すると 個人としては早くなり、 組織としては遅くなる コードレビューの速度は 3.1% 増加 承認の速度は 1.3% 増加 リリース速度は 1.5% 低下 安定性は 7.2% 低下 DORA | Impact of Generative AI in Software Development https://dora.dev/research/ai/gen-ai-report/ (fig.2, fig.3)
11. 新しい問題なのか 新たな時代の到来と主張 する人もいる (Software Engineering 3.0) 低品質なコードを記述す ることで開発速度が低下 することは既知の事実 対策するための技術も知 られている AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition - Speaker Deck https://speakerdeck.com/twada/agentic-software-engineering-findy-2025- 07-edition
12. Software Engineering とは ソフトウェアエンジニアリングとは時間で積 分したプログラミングである プログラミングとは、コードを生産する即時 的行動である。ソフトウェアエンジニアリン グとは、コードを利用しなければならない期 間中に有用に保つのに必要であり、またチー ムを横断した共同作業を可能とする、ポリシ ー、プラクティス、ツールのセットである。 Titus Winters、Tom Manshreck、Hyrum Wright　編、竹辺 靖昭　監訳、久富木 隆一　訳 「Googleのソフトウェア エンジニアリング― 持続可能なプログラミングを支える技術、文化、プロセス」 オライリージャパン 2021年 https://www.oreilly.co.jp/books/9784873119656/
13. 星のドラゴンクエスト 10 周年でサービス終了 サービスの複雑化がサービス の継続判断に影響 10 年間サービスを開発し続け ることは簡単ではない サービスが継続できなくなる インパクトを生むことがある プロデューサーレター | 星のドラゴンクエスト | SQUARE ENIX BRIDGE https://cache.sqex-bridge.jp/jp/ja/guest/information/96614? returnTo=https%3A%2F%2Fcache.sqex- bridge.jp%2Fguest%2Finformation%3Fgame_id%3D67%26list%3Dno%26page%3D
14. 星のドラゴンクエスト プロデューサーレターより引用 ゲームプログラムは膨大な機能の集合体です。 個々は問題なく動作していても、絡み合った際に思わぬ挙動を示 すことは多々あります。 運営・制作チーム、特に開発作業に携わる者達は常に効率化に尽 力し、時には発明することでこれらの課題を乗り越えて参りまし たが、いよいよプレイヤーのみなさまに影響を及ぼさずに運営を 続けることが難しい状況に至った次第でございます。 それならば10周年を節目として全ての物語を描き切ろう、運営・ 制作チームはそのように判断いたしました。 プロデューサーレター | 星のドラゴンクエスト | SQUARE ENIX BRIDGE https://cache.sqex-bridge.jp/jp/ja/guest/information/96614? returnTo=https%3A%2F%2Fcache.sqex-bridge.jp%2Fguest%2Finformation%3Fgame_id%3D67%26list%3Dno%26page%3D2
15. グランブルーファンタジー 10 年続くサービスを継続 するための取り組み 大規模なシステムの設計 を見直し再構築 継続を可能にするための 技術が存在する 注: 継続したほうが偉いと いう話ではない 【Developers Summit 2024フォローアップ】 『グランブルーファンタジー』 100万行を超える大規模なシステム再構築～10周年のその先へ～ | Cygames Engineers' Blog https://tech.cygames.co.jp/archives/3614/
16. まとめ 生成 AI により幅広い人が莫大な量のコードを記述できるようにな った Vibe Coding や Spec Driven Development という新しい技法が出現し ている 一方で、生成 AI の導入が組織の生産性に必ずしも良い影響を与え るとは限らない 低品質なコードを記述することで開発速度が低下することは既知の 事実 対策するための技術も Software Engineering の分野で知られている
17. TOC 生成AIの衝撃 MLOps までの道のり <- GenAIOps 発展的な話題
18. MLOps に至るまで Spec Driven Development (再掲) ウォーターフォール アジャイルソフトウェア開発宣言 MLOps に至るまで TPS (トヨタ生産方式) DevOps MLOps
19. Spec Driven Development AWS が開発した Kiro で導 入された開発手法 プロンプトからまずは要 件を記述 要件に基づきコード生成 (Plan first, then build.) GitHub からも Spec Kit が 発表された Kiro: The AI IDE for prototype to production https://kiro.dev/ github/spec-kit: Toolkit to help you get started with Spec-Driven Development https://github.com/github/spec-kit
20. ウォーターフォール Winston W. Royce による開発 プロセスの整理 オリジナルは反復とフィード バックを含む なぜか直線的なプロセスとし て世に理解されてしまった Managing the development of large software systems: concepts and techniques | Proceedings of the 9th international conference on Software Engineering https://dl.acm.org/doi/10.5555/41765.41801
22. MLOps に至るまで アジャイルの源流は TPS (トヨタ生産方式) DevOps はリーンやアジャ イルに源流がある MLOps は DevOps (SRE) に源流がある アジャイルとDevOpsの品質保証と信頼性 - Test Automation 図2, 図3 https://kokotatata.hatenablog.com/entry/2020/06/01/163652
23. TPS (トヨタ生産方式) TPS とは TPS の目的 理想のチーム カイゼン 問題解決
24. TPS とは ムダの徹底的排除の思想 と、つくり方の合理性を 追い求め、生産全般をそ の思想で貫き、システム 化した生産方式 自働化 ジャスト・イン・タイム トヨタ生産方式 | 経営理念 | 企業情報 | トヨタ自動車株式会社 公式企業サイ ト https://global.toyota/jp/company/vision-and-philosophy/production- system/
25. TPS の目的 TPS は効率化と捉えられがち 「誰かの仕事を楽にしたい」 トヨタ春交渉2021 #3　 「トヨタ生産方式」 「カーボンニュートラル」 「SDGs」一人ひとりに 何ができるか｜トヨタイムズ - YouTube https://youtu.be/ze0hUCMS-aI
26. 理想のチーム トヨタ鞍ヶ池記念館 ラジオラマ(4)『G1 型トラ ックの故障修理活動』 昭和１１年(１９３６)４月 春爛漫の昼下がり 職務を超えて全員でお客 様のためにできることを やっている図 FAIRLADY Z fan : トヨタ鞍ヶ池記念館に行きました。 http://blog.livedoor.jp/fairlady3233/archives/1934986.html
27. カイゼン 「もっといいクルマをつ くろうよ」 「1 にユーザー、2 にディ ーラー、3 にメーカー」 売れる車と言わなかった トヨタ企業サイト｜トヨタ自動車75年史｜第3部 第5章 第2節｜第1項 激動す https://www.toyota.co.jp/jpn/company/history/75years/text/leaping_forward_a
28. 問題解決 PDCA サイクルを回すため のフレームワーク データの収集と KPI の設 定を行い、対策前後での 比較で効果測定を行う データサイエンスのフレ ームワークに等価 第5回:新作研修「問題解決研修 基礎編 ～8ステップと考え方～」は「風土 改革」 ・ 「人財育成」に直結する！ | 社員・企業研修のトヨタエンタプライズ https://kensyu.toyota-ep.co.jp/column/4880/
29. DevOps Dev vs Ops (2000 年代) Dev Ops 自動化 継続的改善
30. Dev vs Ops (2000 年代) クラウドサービスが生まれ始めた 時代 (Amazon S3 は 2006 年) Dev: 顧客に新しい価値を早く提供 したい、多少不安定になるかもし れないが運用が頑張れば良い Ops: 顧客に安定的に価値を提供し たい、新機能の追加で不安定にな ることは受け入れられない 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr - Slideshare https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
31. Dev Ops Dev vs Ops から Dev & Ops に移行 しようという提案 (2008) 「顧客に価値をすばやく安定的に 提供しよう」という提案 この提案に基づくのが DevOps DevOps: Dev と Ops の協調 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr - Slideshare https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
32. 自動化: CI/CD CI (Continuous Integration) コードをリポジトリに頻 繁にコミットする手法 CD (Continuous Deployment) 自動化によりサービスを 更新しデプロイする手法 GitHub Actions を使った継続的デプロイについて - GitHub Docs https://docs.github.com/ja/actions/about-github-actions/about-continuous- deployment-with-github-actions Google Cloud 上での DevOps と CI / CD について | Google Cloud 公式ブロ グ https://cloud.google.com/blog/ja/topics/developers-practitioners/devops- and-cicd-google-cloud-explained?hl=ja
33. 継続的な改善 フィードバッ クサイクルに よる改善 単一のチーム で開発と運用 を行う Explore Continuous Improvement - Training | Microsoft Learn https://learn.microsoft.com/en- us/training/modules/characterize-devops- continous-collaboration-improvement/3-explore- continuous-improvement
34. MLOps MLOps とは CT (継続的学習)
35. MLOps Google の開催したイベント Cloud Next 2018 で有名になった概念 機械学習の成果をスケールさせる ためのさまざまな取り組み AI を育てる活動 (Waymo など)
36. CT (継続的な 訓練) MLOps にお ける継続的な 改善の実装 モデルを継続 的に訓練して 改善 MLOps: Continuous delivery and automation pipelines in machine learning | Cloud Architecture Center | Google Cloud https://cloud.google.com/architecture/mlops- continuous-delivery-and-automation-pipelines-in- machine-learning
37. まとめ MLOps は機械学習の成果をスケールさせるためのさまざまな取り 組み MLOps は DevOps を ML に拡張したものであり、源流は TPS TPS は仕事を楽にすることが重要であり、データに基づいて PDCA サイクルを回すことでカイゼンを実施している DevOps はすばやい開発とフィードバックによる継続的な改善が重 要であり、そのために CI/CD パイプラインを構築し自動化している MLOps はフィードバックループを継続的な訓練により実現してお り、そのために機械学習パイプラインを構築し自動化している
38. TOC 生成AIの衝撃 MLOps までの道のり GenAIOps <- 発展的な話題
39. GenAIOps ハッカソン Demo Hell Eval-Centric AI 評価は難しい Criteria Drift プロンプトエンジニアリング LLM-as-a-Judge 継続的な評価による継続的な改善 Agent
40. ハッカソン: デジタル庁 ハッカソンにより「5時間 という短い開発時間の中 で、38個のプロトタイプ」 ハッカソンの成果物を OSS として公開 第三弾： 「法令」×「デジタル」ハッカソンを開催しました｜デジタル庁 https://www.digital.go.jp/news/9fb5ef8e-c631-4974-96d9-0b145304c553 法令 Deep Research ツール Lawsy を OSS として公開しました｜Tatsuya Shirakawa https://note.com/tatsuyashirakawa/n/nbda706503902
41. Demo hell デモまでは行き着くもの の、本番化が著しく困難 品質を評価し、担保する ことが極めて困難 Escaping AI Demo Hell: Why Eval-Driven Development Is Your Path To Production https://www.forbes.com/councils/forbestechcouncil/2025/04/04/escaping- ai-demo-hell-why-eval-driven-development-is-your-path-to-production/
42. AI セーフティ強化に関する研究 開発プロジェクト Citadel AI で「企業向け実装解 説」としてベストプラクティ ス集・事例集の作成を担当 「デモは簡単にできるものの サービス化や本番化は難しい」 というテーマでヒアリング 似たような課題・対策を行っ ていることが見えてきた
43. 評価は難しい システムの正しい振る舞 いを、誰も明確に記述で きない 品質評価の観点を事前に 列挙することは困難で、 出力から事後的に得られ ることが大半 機械学習による言語パフォーマンスの評価 - Speaker Deck https://speakerdeck.com/langstat/ji-jie-xue-xi-niyoruyan-yu- pahuomansunoping-jia
44. Criteria Drift Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences LLM の出力に対する評価基準 が、評価を進めるにつれてユ ーザー自身によって変化また は洗練されていく [2404.12272] Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences https://arxiv.org/abs/2404.12272
45. 発想の逆転: 高速プロトタイ ピング 専門家も自分の行ってい ること・やりたいことを 明確にできない 評価を繰り返すことで専 門家の知識を明文化する 手戻りを恐れるのではな くイテレーションを回す AIエージェントの地上戦 〜開発計画と運用実践 / 2025/04/08 Findy ランチ セッション #19 https://speakerdeck.com/smiyawaki0820/08-findy-w-and- bmitoatupu-number-19
46. プロンプトエンジニアリング 入力文章を調整して、言語モ デルを効率的に使おうとする 手法群 指示文を人が見たときにわか りやすくなるよう、明確に記 述することが基本 Gemini の記事が参考になる Gemini から欲しい回答を引き出すプロンプト術｜Gemini - Google の AI https://note.com/google_gemini/n/n60a9c426694e
47. LLM-as-a-Judge プロンプトを用いて LLM に出力の良さを評価させ る手法 新たな評価観点が得られ た場合、その評価観点に 基づく評価方法の手順書 を書くと、その観点に基 づく評価が LLM で可能 LLMによるLLMの評価「LLM-as-a-Judge」入門〜基礎から運用まで徹底解 説 https://zenn.dev/pharmax/articles/2d07bf0498e212
48. 継続的な評価による継続的な改善
49. Agent チューニングにより「1つ のこと(ドメイン)をうまく やる」ものができる 各ドメインを協調させる 取り組みがエージェント Microservices Architecture の再発見 メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例 https://speakerdeck.com/na0/merukariniokerudetaanariteikusu-ai-eziento- socrates-to-adk-huo-yong-shi-li
50. まとめ 生成 AI の活用においては Eval-Centric (評価中心) な方法論が必要 Eval-Centric においては継続的な評価により継続的な改善を実装で きる 専門家も自分の知識を明文化できないという前提に立って、継続的 な評価を通じた高速プロトタイピングを継続的に行う
51. TOC 生成AIの衝撃 MLOps までの道のり GenAIOps 発展的な話題 <-
52. 発展的な話題 AI セーフティ AI ガバナンス ソフトウェアエンジニアリングの再発見 古典は厚いが役に立つ
53. AI セーフティ 定義自体の議論が進行中 AI 事業者ガイドラインで は「安全性」を定義 AISI UK の Research Agenda では 6 種類のリス クを定義 Research Agenda https://www.aisi.gov.uk/research-agenda
54. 実践 AI セーフティ リスクマネジメントの手法を応用 1. ユースケースを列挙 2. ユースケースごとにリスクを分析 3. ユースケースごとに対応 (回避・低減・移転・受容) を決定 4. 安全だと判断できるユースケースに限ってサービスを提供 5. サービスの利用状況をモニタリング AIセーフティは個々の開発チームの責務
55. AI セーフティ≒プロ ダクトマネジメント ユーザーは誰か どう使うのか 何に使うのか いつ使うのか Melissa Perri 著 吉羽 龍太郎 訳 「プロダクトマネジメント」 オライリー・ジャパン 2020年 https://www.oreilly.co.jp//books/9784873119250/ 及川 卓也, 曽根原 春樹, 小城 久美子 著 「プロダクトマネジ メントのすべて 事業戦略・IT開発・UXデザイン・マーケテ ィングからチーム・組織運営まで」 翔泳社 2021 年 https://www.shoeisha.co.jp/book/detail/9784798166520
56. AI ガバナンス リスク管理 + 提供価値の最大化 アジャイルガバナンス: 組織として 学習し続けることを求める A/Bテストを通じた提供価値の改 善を組織として行えるようにする ことは、AIガバナンスの一部 AI事業者ガイドライン（METI/経済産業省） https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
57. AI ガバナンスのミッション どんな使い方をしても大丈夫なAIを用意して展開しようとすると失 敗する (実現できない) AI セーフティについては組織内の各チームに任せる AI ガバナンスを専門で行うチームでのみ低減できるリスクは「AI を 活用しない機会損失リスク」 うまくいっている AI ガバナンスチームのミッションは「AI の組織 的な活用」
58. セガでの AI ガバナンス CEDEC 2025 講演資料よ り引用 (pp.11-12) もはや AI を使うのが当た り前で気がついたら誰も が使っているという前提 「AIを使わないことはあ りえない」 安心安全に生成AIを使おう！社内で運用中の生成AIのガバナンスをご紹介 https://cedil.cesa.or.jp/cedil_sessions/view/3147
59. ソフトウェアエンジニアリングの再発見 Agent 開発手法 ソフトウェア開発手法 小さくはじめて育てる リーンスタートアップ 高速プロトタイピング アジャイルソフトウェア開発宣言 独自データセット定義 テスト駆動開発 領域特化エージェント ドメイン駆動開発 本番環境でのテスト DevOps のカナリアリリース
60. 書籍は厚いが役に立 つ NotebookLM で伝統的 な手法と新技術をあわ せて音声解説を生成す ると良い Vlad Khononov 著, 増田 亨, 綿引 琢磨　訳「ドメイン駆動設 計をはじめよう― ソフトウェアの実装と事業戦略を結びつ ける実践技法」オライリー・ジャパン 2024 年 https://www.oreilly.co.jp/books/9784814400737/ AI エージェント実践ガイドブック https://cloud.google.com/resources/content/intl/ja- jp/aiagentgb
61. まとめ 生成 AI の出現により、非専門家であってもコードを書けるように なり、莫大な量のコードが書けるようになった ソフトウェアエンジニアリングは、コードを利用しなければならな い期間中、コードを有用なものに保つ取り組み MLOps は DevOps を ML に拡張したものであり、源流は TPS TPS は仕事を楽にすることが重要であり、データに基づいて PDCA サイクルを回すことでカイゼンを実施している Eval-Centric においては継続的な評価により継続的な改善を実装で き、提供したい価値を発見していく取り組み