AI工学特論: MLOps・継続的評価

トップエスイー AI 工学特論の講義資料です。MLOps を巡る歴史、生成 AI を活用する技術・AI セーフティ・AI ガバナンス、MLOps の技術・プロセス・文化、AI エージェントの今後を扱っています。

参考資料
- 生成 AI 実践ガイドと企業事例集: https://citadel-ai.com/ja/news/2026/04/03/gen-ai-practical-guide/
- 事例でわかる MLOps: https://www.kspub.co.jp/book/detail/5369562.html

Transcript

1. AI工学特論: MLOps・継続的評価 Asei Sugiyama
2. 自己紹介 杉山 阿聖 (@K_Ryuichirou) Research Lead @ Citadel AI Google Developer Expert @ Cloud AI MLSE 主査 機械学習図鑑, 事例でわかる MLOps 共著
3. TOC MLOps を巡る歴史 <GenAIOps の技術・プロセス・文化 MLOps の技術・プロセス・文化 AI エージェント
4. MLOps を巡る歴史 MLOps の登場 MLOps に至るまで TPS DevOps MLOps GenAIOps
5. MLOps の登場 (1/2) Google の開催したイベン ト Cloud Next 2018 で有名 になった概念 MLOps は "DevOps for ML" として導入されている
6. MLOps の登場 (2/2) 機械学習パイプラインに よる自動化はトピックの ひとつ 品質や組織論などを含 む、広範な概念
7. MLOps に至るまで MLOps は DevOps (SRE) に源流がある DevOps はリーンやアジャ イルに源流がある それらの源流は TPS (トヨ タ生産方式) アジャイルとDevOpsの品質保証と信頼性 - Test Automation 図2, 図3 https://kokotatata.hatenablog.com/entry/2020/06/01/163652
8. TPS (トヨタ生産方式) TPS とは TPS の目的 理想のチーム カイゼン 問題解決
9. TPS とは ムダの徹底的排除の思想 と、つくり方の合理性を 追い求め、生産全般をそ の思想で貫き、システム 化した生産方式 自働化 ジャスト・イン・タイム トヨタ生産方式 | 経営理念 | 企業情報 | トヨタ自動車株式会社 公式企業サイ ト https://global.toyota/jp/company/vision-and-philosophy/productionsystem/
10. TPS の目的 TPS は効率化と捉えられがち 「誰かの仕事を楽にしたい」 トヨタ春交渉2021 #3 「トヨタ生産方式」「カーボンニュートラル」「SDGs」一人ひとりに 何ができるか｜トヨタイムズ - YouTube https://youtu.be/ze0hUCMS-aI
11. 理想のチーム トヨタ鞍ヶ池記念館 ラジオラマ(4)『G1 型トラ ックの故障修理活動』 昭和１１年(１９３６)４月 春爛漫の昼下がり 職務を超えて全員でお客 様のためにできることを やっている図 FAIRLADY Z fan : トヨタ鞍ヶ池記念館に行きました。 http://blog.livedoor.jp/fairlady3233/archives/1934986.html
12. カイゼン 「もっといいクルマをつ くろうよ」 「1 にユーザー、2 にディ ーラー、3 にメーカー」 売れる車と言わなかった トヨタ企業サイト｜トヨタ自動車75年史｜第3部 第5章 第2節｜第1項 激動す https://www.toyota.co.jp/jpn/company/history/75years/text/leaping_forward_a
13. 問題解決 PDCA サイクルを回すため のフレームワーク データの収集と KPI の設 定を行い、対策前後での 比較で効果測定を行う データサイエンスのフレ ームワークに等価 第5回:新作研修「問題解決研修 基礎編 ～8ステップと考え方～」は「風土 改革」・「人財育成」に直結する！ | 社員・企業研修のトヨタエンタプライズ https://kensyu.toyota-ep.co.jp/column/4880/
14. リーン・スタートアップ 極めて不確実な状況における新規 事業開発を扱う 問題解決手法を代表とした TPS を 新規事業開発に応用 トヨタ流製品開発の外部からのリ バースエンジニアリング エリック・リース 著 井口 耕二 訳 福島 良典 解説 「リーン・スタートアップ 新装版 ムダ のない起業プロセスでイノベーションを生みだす」 日経BP 2026年 https://bookplus.nikkei.com/atcl/catalog/26/05/21/02621/
15. 主査に関する10条 (長谷川龍雄氏) 第一条 主査は、常に広い智識、見識を学べ。 第二条 主査は、自分自身の方策を持つべし。 第三条 主査は、大きく、かつ良い調査の網を張 れ。 第四条 主査は、良い結果を得るためには全知全 能を傾注せよ。 第五条 主査は、物事を繰り返すことを面倒がっ てはならぬ。 北川 尚人 著 「トヨタ チーフエンジニアの仕事」 講談社 2020年 https://www.kodansha.co.jp/book/products/0000327438
16. 主査に関する10条 (長谷川龍雄氏) 第六条 主査は、自分に対して自信（信念）を持 つべし。 第七条 主査は、物事の責任を他人のせいにして はならぬ。 第八条 主査と主査付き（補佐役）は、同一人格 であらねばならぬ。 第九条 主査は、要領よく立ち回ってはならな い。 第一〇条 主査に必要な特性 ( 省略 ) 北川 尚人 著 「トヨタ チーフエンジニアの仕事」 講談社 2020年 https://www.kodansha.co.jp/book/products/0000327438
17. DevOps Dev vs Ops (2000 年代) Dev Ops 自動化 継続的改善
18. 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
19. 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
20. 自動化: IaC (Infrastructure as Code) インフラをコードで管理 アプリケーションだけで はなく、インフラもコー ドと設定ファイルでバー ジョン管理される 自動化が進む結果、ほぼ すべてがコードと設定フ ァイルに Using Recommendations for Infrastructure as Code https://cloud.google.com/recommender/docs/tutorial-iac
21. 自動化: CI/CD CI (Continuous Integration) コードをリポジトリに頻 繁にコミットする手法 CD (Continuous Deployment) 自動化によりサービスを 更新しデプロイする手法 GitHub Actions を使った継続的デプロイについて - GitHub Docs https://docs.github.com/ja/actions/about-github-actions/about-continuousdeployment-with-github-actions Google Cloud 上での DevOps と CI / CD について | Google Cloud 公式ブロ グ https://cloud.google.com/blog/ja/topics/developers-practitioners/devopsand-cicd-google-cloud-explained?hl=ja
22. 継続的な改善 フィードバッ クサイクルに よる改善 単一のチーム で開発と運用 を行う Explore Continuous Improvement - Training | Microsoft Learn https://learn.microsoft.com/enus/training/modules/characterize-devopscontinous-collaboration-improvement/3-explorecontinuous-improvement
23. MLOps 機械学習システムの開発における課題 MLOps CT (継続的学習)
24. 機械学習システムの開 発における課題 前処理が難しい モデルの更新などの運用 が煩雑 機械学習チームの悲劇 西田 佳史, 遠藤 侑介, 有賀 康顕 著 「n 月刊ラムダノート Vol.1, No.1(2019)」 ラムダノート株式会社 2019年 https://eiyo21.com/book/9784789554596/
25. 機械学習チームの悲劇 機械学習専門のチームが誕生 機械学習モデルを作成し、PoC で成果を確認 モデルをプロダクトに組み込むためのタスクが作成される モデルをプロダクトに組み込む作業の見積もりが大きくなる 典型的な機能開発のほうが小さな見積もりになり、優先度が上がる プロダクトに組み込まれないため機械学習専門のチームの成果が出 ない 投資対象を見直すことになりチーム解散
26. MLOps 機械学習の成果をスケールさせる ためのさまざまな取り組み そもそも AI は育てるもの (という お題目で PoC を乗り切った方々も 多いはず) AI を育てる活動 (Waymo など)
27. CT (継続的な 訓練) MLOps にお ける継続的な 改善の実装 モデルを継続 的に訓練して 改善 MLOps: Continuous delivery and automation pipelines in machine learning | Cloud Architecture Center | Google Cloud https://cloud.google.com/architecture/mlopscontinuous-delivery-and-automation-pipelines-inmachine-learning
28. GenAIOps 生成 AI の衝撃 Demo hell AI セーフティ AI ガバナンス 生成 AI 実践ガイド GenAIOps
30. AI ネイティブカンパニー DeNAが挑む「AIネイティブカンパニー」への全社的取り組み。人をエンパワーし、イノベーションを創出する─南場智子 | フルスイング by DeNA https://fullswing.dena.com/archives/100169/ メルカリが本気で始めた「AI-Native」化。100名規模のタスクフォースが立ち上がるまで | mercan (メルカン) https://careers.mercari.com/mercan/articles/53708/
31. AI Agent がビジネスに Algomatic: アポドリ、リクルタAI などエージェントを利用したサー ビスを次々展開 LayerX: バクラクシリーズに加え、 生成AIプラットフォーム Ai Workforce を展開 複数 AI エージェント同時立ち上げで「打席数」を重視——DMM が用意した20億円でスター トアップスタジオ展開する Algomatic #取材会 - BRIDGE（ブリッジ） https://thebridge.jp/2025/06/algomatic-launches-startup-studio-with-¥2-billioninvestment-from-dmm LayerX、総額150億円の資金を調達。エンジニアを中心とした人材採用強化やさらなる事業 拡大へ https://aismiley.co.jp/ai_news/layerx-ai-saas-fintech/
32. Demo hell デモまでは行き着くもの の、本番化が著しく困難 品質を評価し、担保する ことが極めて困難 Escaping AI Demo Hell: Why Eval-Driven Development Is Your Path To Production https://www.forbes.com/councils/forbestechcouncil/2025/04/04/escapingai-demo-hell-why-eval-driven-development-is-your-path-to-production/
33. AI セーフティ AI 事業者ガイドラインで は「安全性」を定義 AISI UK の Research Agenda では 6 種類のリス クを定義 AISI JAI-Trust で議論が進 行中 Research Agenda https://www.aisi.gov.uk/research-agenda
34. AI ガバナンス リスク管理 + 提供価値の最大化 アジャイルガバナンス: 組織として 学習し続けることを求める リスクマネジメントに関するISO 標準 (ISO 31000:2018) でもアジャ イルの考え方を取り入れている AI事業者ガイドライン（METI/経済産業省） https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
35. AI 事業者ガイドライン AI の利活用によって生じるリスクをステークホルダーにとって受 容可能な水準で管理しつつ、そこからもたらされる正のインパク ト（便益）を最大化することを目的とする、ステークホルダーに よる技術的、組織的、及び社会的システムの設計並びに運用。 AI事業者ガイドライン（METI/経済産業省）https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20240419_report.html
36. 生成 AI 実践ガイドと 企業事例集 DevOps の継続的改善をベ ースとするアプローチ DevOps と AI セーフテ ィ・AI ガバナンスを統合 良い使い方を追求するこ とがセーフティやガバナン スの達成につながる NEDO事業「AIの安全性確保に関する研究開発・検証等の推進事業／AIセー フティ強化に関する研究開発」の成果報告について - Citadel AI https://citadel-ai.com/ja/news/2026/04/03/nedo-citadel-ai-2025/
37. GenAIOps DevOps を生成 AI 向けに 拡張 AI セーフティ、AI ガバナ ンスを包含 アジャイルにそのサービ スの提供する価値、対応 すべきリスクに向き合う ことがすべて 生成 AI 実践ガイドと企業事例集 - Citadel AI https://citadelai.com/ja/news/2026/04/03/gen-ai-practical-guide/
38. 継続的な評価による継続的な改善
39. 初手は生成 AI がオススメ MLOps は機械学習タスクを自動化するので、先に機械学習タスク を明確にする必要がある AI を使いたいケースでは目的や提供価値が明確でないことが大半 初期の探索的なフェーズでは高性能な生成 AI で提供価値や実現可 能性を検証するのがオススメ 取り組みたいタスクが明らかになり、一般的な知識ではなく、自組 織の事情に合わせた高精度な結果を求めたくなった場合に MLOps 例: 需要予測や在庫の最適化などのタスクになったら MLOps
40. How Google does machine learning 各フェーズを掘り下げる (How Google Does Machine Learning 日本語版) - Coursera https://coursera.org/share/faf9215a37a5a12c0e3653225f7020d6
41. 機械学習までの ステップ 1. 小さく始める 2. 標準化 3. システム化 4. データ分析 5. 機械学習 機械学習とビジネス プロセス (How Google Does Machine Learning 日本語版) - Coursera https://www.coursera.org/learn/google-machine-learningjp/lecture/G8qKf/ji-jie-xue-xi-tobizinesu-purosesu
42. 組織における活用: Amazon Flywheel Amazon の成長を支える経 営戦略 サービスにおけるリコメ ンドの重要性も同時に示 している 5 Lakh Amazon sellers... and counting | Seller Blog https://sell.amazon.in/mr/seller-blog/5-lakh-amazon-sellers-and-counting? mons_sel_locale=mr_IN
43. Amazon も最初からうまくはいかなかった Ron Kohavi, Diane Tang, Ya Xu 著 大杉 直也 訳 「A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは」 KADOKAWA 2021年 https://www.kspub.co.jp/book/detail/5369562.html
44. まとめ MLOps は ML の成果をスケールさせるためのさまざまな取り組み TPS は仕事を楽にすることが重要であり、データに基づいて PDCA サイクルを回すことでカイゼンを実施している DevOps はすばやい開発とフィードバックによる継続的な改善が重 要であり、そのために CI/CD パイプラインを構築し自動化している MLOps はフィードバックループを継続的な訓練により実現してお り、そのために機械学習パイプラインを構築し自動化している GenAIOps は継続的な評価によりフィードバックループを実現して おり、チームとして業務の専門知識を身に着けている
45. TOC MLOps を巡る歴史 GenAIOps の技術・プロセス・文化 <MLOps の技術・プロセス・文化 AI エージェント
46. GenAIOps の技術・プロセス・文化 生成 AI 実践ガイド AI を活用するための技術 AI セーフティ AI ガバナンス
47. 生成 AI 実践ガイド 生成 AI を活用する企業 20 社 にヒアリング 開発手法はアジャイルに基づ く継続的改善 AI セーフティもアジャイルに 基づく学習と改善 AI ガバナンスは「AI を活用し ないリスク」への対応 生成 AI 実践ガイドと企業事例集 - Citadel AI https://citadelai.com/ja/news/2026/04/03/gen-ai-practical-guide/
48. AI を活用するための技術 AI エージェントのアーキテクチャ概要 AI エージェントを開発するうえでの注意点 AI エージェントの開発プロセス AI エージェントのテスト AI オブザーバビリティ 継続的な評価による継続的な改善
49. AI エージェントのアーキテ クチャ概要 LLM のオーケストレーシ ョンのためのライブラリ 状態の監理 エラーハンドリング オブザーバビリティ CI/CD GoogleCloudPlatform/agent-starter-pack: Ship AI Agents to Google Cloud in minutes, not months. Production-ready templates with built-in CI/CD, evaluation, and observability. https://github.com/GoogleCloudPlatform/agent-starter-pack
50. 事例: 株式会社タップル OpenAI と Google の複数 モデルを併用する構成を 採用 生成された SQL を別の LLM（LLM-as-a-Judge） で評価し、構文エラーや スキーマ名のミスを減点 方式で判定 SQL Agentによるタップルのデータ利活用促進 / CA DATA NIGHT #6 〜活用 から実務へ──生成AI・LLMの“業務の入り口”を探る〜 | CyberAgent Developers Blog https://developers.cyberagent.co.jp/blog/archives/56772/
51. AI エージェントを開発するうえでの注意点 セキュリティ 個人情報や機密情報 (プライバシー) レイテンシー モデル選定 コスト管理 信頼性とフォールバック
52. 事例: PharmaX (Yojo) 大きな LLM の出力を人手で修正し て小さな LLM を訓練 コストとレイテンシーを低減 LLM の出力を他の LLM の訓練に 用いられるかどうか、利用規約に は注意 OpenAIの蒸留機能(Model Distillation)を使って運用中のLLMのコストを削減する取り組み https://zenn.dev/pharmax/articles/f4ae12a91cca45
53. AI エージェントの開発プロセス ハッカソン：AIエージェントを用いて解決したい課題の特定と技術 的な実現性を検証する。 開発：コアな機能に絞って開発を行う。 テスト：開発したアプリケーションの品質を検証する。 デプロイ：開発したアプリケーションを公開し、運用する。 継続的なモニタリング：アプリケーションの利用状況を監視し、必 要に応じて改善を行う。
54. 事例: 日本生命 デジタルハッカソンは、生成AI以前 から行われている取り組み 事務サポートシステムの開発を伴う ハッカソン 「約款やマニュアルに基づく事務関 連の照会に対する回答精度は、今回 の取り組みで試した範囲では90％ 以上」 DX戦略 | サステナビリティ | 日本生命保険相互会社 https://www.nissay.co.jp/sustainability/contents/dx/
55. AI エージェントのテスト ルールベースでの判定が困難な要求に対するテストが必要 専門家を巻き込んで徐々にテストケースを拡充 用いられたテスト手法 シナリオテスト・マニュアルテスト Red Teaming (レッドチーミング) 自動評価・回帰テスト
56. 事例: すかいらーくグループ すかいらーくグループが生成 AI で新たな顧客体験を提供、Azure OpenAI Service を活用することで来店客とのていねいな会話を実現 | Microsoft Customer Stories https://www.microsoft.com/ja-jp/customers/story/22991-skylark-group-azure
57. 課題 ブランド毀損や安全に関わる致命的なリスクの排除が大きな課題 対策 品質管理、営業、総務などあらゆる部門の協力を得て、起こり得る リスクを網羅的に洗い出し、特に重大な影響を及ぼす質問群を高リ スクなテストデータとして特定 開発サイクルの中で、これらのデータを用いたシナリオテストを繰 り返し実施し、期待通りの挙動（安全な回答や回答の回避）をする か検証 テスト自体も開発を通じて徐々に増強
58. AI オブザーバビリティ トレーシング 回答を生成するまでに辿った思考のプロセス 呼び出したツール / エージェント メトリクス トークン消費量 レイテンシー エラー率 対話の破綻率
59. 事例: PharmaX (Yojo) Agent では検索や LLM を組み合わ せて使うため、望ましくない結果 が得られたときにその原因追及が 困難 最終結果を生成するまでの途中で 何が起きているのかを記録し、分 析できるようにする LangSmith や Langfuse は Trace の ための機能を実装している LangSmithによるLLMアプリケーションのトレーシング入門 https://zenn.dev/pharmax/articles/61edc477e4de17
60. 継続的な評価による継続的な改善
61. 事例: Algomatic 専門家によるレビューや 議論の結果をプロンプト に反映 専門家もいきなりは自分 のノウハウを言語化でき ないので、イテレーショ ンを回して徐々に言語化 AIエージェントの地上戦 〜開発計画と運用実践 / 2025/04/08 Findy ランチ セッション #19 - Speaker Deck https://speakerdeck.com/smiyawaki0820/08-findy-w-and-bmitoatupunumber-19
62. AI セーフティ リスクマネジメント ガードレール Human-in-the-loop 迅速なフィードバックループ、モニタリング
63. リスクマネジメント 既存のリスクマネジメントが AI セーフティにおいても重要 1. AI エージェントのユースケースを列挙 2. ユースケースごとにリスクアセスメント (特定、分析、評価) 3. リスクへの対応方法 (回避、低減、移転、受容) を決定 4. 安全だと判断できるユースケースに限ってサービスを提供 5. サービスの利用状況をモニタリング
64. リスク回避の例: Ubie 業務効率化を支援する生 成AIサービスを病院向け に提供 インフォームド・コンセ ント記録の作成や退院サ マリ等の作成を支援する 機能があるが、診療目的 での利用は禁止 Ubie株式会社_会社紹介資料 - Speaker Deck https://speakerdeck.com/ubie/ubie-hui-she-an-nei-202211
65. リスク低減の例: すかいらーく グループ アレルギーに関する質問への 誤答、存在しないメニューを 回答というリスクを特定 アレルギーに関する質問には 絶対に回答しないように事前 に徹底的に検証を行うことで 対策 すかいらーくグループが生成 AI で新たな顧客体験を提供、Azure OpenAI Service を 活用することで来店客とのていねいな会話を実現 | Microsoft Customer Stories https://www.microsoft.com/ja-jp/customers/story/22991-skylark-group-azure
66. リスク移転の例: LINE ヤフー 技術的対策の実装に加え、サ ービス利用に関する免責事項 を明示 利用者との責任範囲を透明化 し、適切なリスク分担を図っ ている 責任あるAIへの取り組み｜LINEヤフー株式会社 https://www.lycorp.co.jp/ja/sustainability/esg/social/responsible-ai/
67. リスク受容の例: KDDI 「AI を活用しないことによる 機会損失」自体を重大なリス クと認識 関連する公的なガイドライン 等を参考に一定のリスクを受 容 モニタリングなど対策も合わ せて実施 KDDI 新卒採用の一部コース（パーソナル事業本部）にVARIETASの「AI面接官」を 導入 | 株式会社VARIETASのプレスリリース https://prtimes.jp/main/html/rd/p/000000031.000079152.html
68. リスクマネジメントに関する原則 次の原則を導入し、リスクマネジメントとアジャイルを両立させる ユースケースを事前に特定し、ワークフローを細分化することで、 リスクの低いユースケースに限定してAIエージェントを導入する 初期はリスクの低いユースケースに限定し、徐々にAIエージェント の対応可能な範囲を広げていく 顧客との積極的なコミュニケーションを通じて、リスクの発見やユ ーザーリテラシーの向上を図る
69. ガードレール サービスで提供されるものだけではなく、次のような多層防御を構築 軽量な処理によるフィルタリング システムプロンプトによる指示 手動での介入 モデルのファインチューニング
70. 事例: SpiralAI 課題 キャラクター性と安全性はトレー ドオフ 一度の定義で完璧なガードレール を作ることは困難 対策 NG ワードのリスト、プロンプ ト、学習データを継続的に改善 SpiralAI、『SaGaラジオ！vol.15』で「AIジョー」の会話AIと音声合成を開発 | SpiralAI株式会 社のプレスリリース https://prtimes.jp/main/html/rd/p/000000086.000120221.html
71. Human-in-the-loop 専門家による品質の担保 AI エージェントの出力をそのままエンドユーザーに届けるのではなく、 専門家などがゲートキーパーとして介在し、出力の品質を保証 専門家へのフォールバック 基本的には AI エージェントが一次対応、AI の能力を超える事象が発生 した場合にのみ、シームレスに人間（専門家やオペレーター）へ交代
72. 事例: PharmaX (YOJO) ユーザーが OTC 薬を購入 できるオンライン薬局 問い合わせをルールと LLM で分類 エージェントで対応不可 能な場合、薬剤師にフォ ールバック AIエージェントの継続的改善のためオブザーバビリティ https://speakerdeck.com/pharma_x_tech/aiezientonoji-sok-de-gai-shannotameobuzababiritei
73. 迅速なフィードバックループ、モニタリング 課題: リリース前の検証の限界 専門家の協力のもとでも、本番環境でのユーザーの振る舞いを、開 発段階で完全に予測し網羅することは困難 対策: ビジネス指標のモニタリングと段階的リリース 多層的なモニタリング指標の設計: タスク完了率、成約率、ユーザ ーの離脱ポイントなど リスクを局所化する段階的リリース: 対象を限定して段階的にリリ ース、A/B テスト
74. 事例: PharmaX (Yojo) どうしても「やってみな いとわからない」 限定的にリリースして想 定外の事象が発生しない か確認する モニタリングでリスクと 効果を確認 AIエージェントの継続的改善のためオブザーバビリティ https://speakerdeck.com/pharma_x_tech/aiezientonoji-sok-de-gai-shannotameobuzababiritei
75. AI ガバナンス 組織体制 トップのコミット ガイドラインの整備 統合的な AI 相談窓口 AI の業務適用の支援 AI 利用スキルのトレーニング AI マネジメントシステムの認証
76. 組織体制: LINE ヤフー 責任あるAIへの取組み｜LINEヤフー株式会社 https://www.lycorp.co.jp/ja/sustainability/esg/social/responsible-ai/
77. トップのコミット: メルカリ CHRO, CAIO, CTO を兼任 2段階で進める AI-Native HR 構 想 1. 日常業務・日々のオペレーシ ョンに AI を徹底的に組み込ん で時間を生み出す 2. HR から AI-Native な組織の Vision を示しそれを実行して いく リスペクトと変革の両立——新CHRO @kimuras が描く、AI-Nativeな組織づくり | mercan (メルカン) https://careers.mercari.com/mercan/articles/60398/
78. 規定・ガイドライン体系の整 備: PFN 階層的なドキュメントを用 意し、段階的に個々のプロ ジェクトにあわせて具体化 最終的には「プロジェクト 開発方針」を個々のプロジ ェクトで策定 Preferred Networksにおける大規模言語モデル開発と活用での AI安全性の考え 方 https://www.digiarc.aist.go.jp/event/4th_grand_canvas/pdf/20250304-4thgrand-canvas-03-ohno.pdf
79. 統合的なAI相談窓口: セガ CEDEC 2025 講演資料よ り引用 (pp.17, p.19) AI ガバナンス担当チーム は、組織の中でもっとも 活用事例に詳しいチーム どんな問い合わせにも答 えることで信頼を勝ち取 る 安心安全に生成AIを使おう！社内で運用中の生成AIのガバナンスをご紹介 https://cedil.cesa.or.jp/cedil_sessions/view/3147
80. AI の業務適用の支援 AI ガバナンス担当の持つ 専門知識は、組織内の別 チームは持っていない チームトポロジーの「イ ネイブリングチーム」 短期間の密なコラボレー ションで組織内のチーム が AI 活用できるよう支援 マシュー・スケルトン, マニュエル・パイス 著 原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳「チームトポロジー」日本能率協会マネジメントセンター 2021年
81. AI 利用スキルのトレーニング: LINEヤフー 生成AIの利用に伴うリスクを把握するため、全従業員に研修を実施 社内のAIアシスタントを使うためには必ず受講しなければならない
82. AI マネジメントシステ ムの認証 KDDI アイレットの事例 どの部門がどのような業 務で AI を使うのかを定義 すべての業務を認証範囲 に含めることを避け、段 階的に拡大 既存の ISMS の枠組みを アイレット、AIAI マネジメントシステムの国際規格「 ISO/IEC 42001」を取得 | に拡大 AI とクラウド活用のシステム・アプリ開発なら KDDIアイレット株式会社 （iret） https://www.iret.co.jp/news/20251022.html
83. まとめ 生成 AI の活用のためにはアジャイルの原則に基づく「小規模な実 験」「継続的な改善」「専門家の直接的な関与」といった不確実性の 高い領域で品質を向上させるための手法が有効 AI セーフティはユースケースを確定させ、リスクを早期に発見し、 段階的に安全性を高めるアプローチが有効 AI ガバナンスは社内に活用方法と AI セーフティを浸透させるため の取り組みであり、イネーブリングチームとしての取り組みが有効 これらは相反するものではなく、アジャイルなアプローチで両立で きる
84. TOC MLOps を巡る歴史 GenAIOps の技術・プロセス・文化 MLOps の技術・プロセス・文化 <AI エージェント
85. MLOps の技術・プロセス・文化 Your system is your system 事例でわかる MLOps 技術 プロセス 文化 まとめ
86. Your System is Your System 機械学習の活用や生じる課題の背景はさまざまに異なる 具体的なベストプラクティスはそのまま自組織には適用できない Google のシニアエンジニア曰く「ベストプラクティスを俺に聞く な、お前のシステムのことはお前のほうがよく知っている」 一般的な原則 + 理解するための事例が重要
87. 事例でわかる MLOps 技術・プロセス・文化 活用フェーズごとに整理 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
88. 技術 機械学習パイプライン 推論システム 技術選定 実行環境とアクセラレーター モニタリング データの品質管理 コードの品質管理
89. 機械学習パイプライン Akshay Naresh Modi and Chiu Yuen Koo and Chuan Yu Foo and Clemens Mewald and Denis M. Baylor and Eric Breck and Heng-Tze Cheng and Jarek Wilkiewicz and Levent Koc and Lukasz Lew and Martin A. Zinkevich and Martin Wicke and Mustafa Ispir and Neoklis Polyzotis and Noah Fiedel and Salem Elie Haykal and Steven Whang and Sudip Roy and Sukriti Ramesh and Vihan Jain and Xin Zhang and Zakaria Haque TFX: A TensorFlow-Based ProductionScale Machine Learning Platform, KDD 2017 (2017) https://research.google/pubs/tfx-a-tensorflow-based-production-scale-machine-learning-platform/
90. 推論システム 訓練済みの機械学習モデ ルを用いて推論する 訓練時とは異なり、一般 的に高い可用性が必要 バッチ推論が第一選択 リアルタイム推論は技術 的な難易度が高くなる 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
91. 事例. DeNA バッチ推論 (図 4.3) リアルタイム推論 (図 4.5) 技術的には上のほうが実 現しやすい リアルタイム推論のほう が実現できる価値が高い ことがわかった場合に実 装を選択 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
92. 事例. CAM マネージド・ サービスで機 械学習基盤を 構築した例 メンバー 2 名 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわか るMLOps 機械学習の成果をスケールさせる処方 箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
93. 技術選定 アーキテクチャの選択は 重大な決断 さまざまな観点で検討 GPU などのハードウェア 利用する技術に対する経 験の深さ (組織内・外) 実現すべき価値 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
94. 実行環境とアクセラレーター 機械学習モデルによっては 訓練・推論時に GPU などの アクセラレーターが必要 利用すると、スループットや レイテンシーを大きく改善 できる可能性がある 利用のために追加で必要に なるプロセスには注意 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果をス ケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
95. 事例. チャットボット 大規模な訓練・推論環境 低いレイテンシーの実現 短期間での開発 推論に Inferentia を採用 し、規模と低いレイテン シーを実現 それ以外は慣れた技術を 用いて短期間で開発 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
96. モニタリング エラーが発生しないまま 振る舞いが異常になるケ ースがある 連絡ミスのような単純な 原因がほとんど 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html Daniel Papasian and Todd Underwood, How ML Breaks: A Decade of Outages for One Large ML Pipeline, USENIX Association 2020 https://www.usenix.org/conference/opml20/presentation/papasian
97. データの品質管理 バイアスはデータの収集 過程においても生じる 与信審査では融資した人 だけを対象としてはダメ アノテーションは高度に 専門的な作業で労力がか かる 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html Too Good to Be True: Bots and Bad Data From Mechanical Turk - Margaret A. Webb, June P. Tangney, 2022 https://journals.sagepub.com/doi/10.1177/17456916221120027
98. 事例. GO 株式会社 DRIVE CHART におけるデータ の品質管理の取り組み エッジデバイスで生じる大量 のデータから、レアなイベン トのデータをピックアップ クラウドへの通信量を抑える 取り組みも 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果をスケ ールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
99. コードの品質管理 異なるロールのメンバー が単一のコードベースで 協業するのは困難 ノートブックの利用、環 境構築の再現性、暗黙的 なノウハウで課題が発生 ロールごと別環境もアリ 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html たった3人で運用するド コモを支える機械学習基盤の作り方 ー Kubernates × Airflow × DataRobot を使ったMLOpsパイプライン ー - ENGINEERING BLOG ドコモ開発者ブログ https://nttdocomo-developers.jp/entry/202212191200_2
100. プロセス 導入フローと PoC 素早い実験を繰り返す 多様な利害関係者との協業 ビジネスの意思決定に役立つモニタリング
101. 導入フローと PoC 機械学習プロジェクトは 不確実性への対応が重要 目標を明確にし、小規模 な取り組みから慎重に規 模を大きくしていく 求められる品質が徐々に 上がることにも注意 Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
102. 事例. AWS ML Enablement Workshop データサイエンスの活用 機会を創出するためのワ ークショップ 短期間で成果を確認する ための方法論 GitHub で公開されている GitHub - aws-samples/aws-ml-enablement-workshop: 組織横断的にチーム を組成し、機械学習による成長サイクルを実現する計画を立てるワークショ ップ https://github.com/aws-samples/aws-ml-enablement-workshop
103. 素早い実験を繰り返す 市場や顧客のニーズは変 わり続ける 常に実験を行い成果の確 認が必要 実験をデザインし、正し く効果測定を行う 実験しやすい環境を整備 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
104. 多様な利害関係者との協業 機械学習システムの利害関係 者は多岐にわたる チーム内だけではなく、経営 層や PdM、法務・知財関係者 などと適切なコミュニケーシ ョンが必要 期待値コントロールの失敗な ど、落とし穴もある 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果をスケ ールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
105. ビジネスの意思決定に役立 つモニタリング 一般に、入力されるデー タや期待される出力が時 間とともに変わる モデルの精度の推移の監 視が必要 精度向上が KPI を向上さ せるかの確認も必要 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
106. 事例. コネヒト株式会社 ML Test Score を用いて機 械学習システムのアセス メントを行った例 実験環境を整備しダッシ ュボードを作成 2 回評価を行い、改善箇所 の検討と改善効果の可視 化を行っている 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
107. 文化 成果を出しやすい組織と 出しにくい組織がある 成果を出しやすくなる要 因は不明 規模や設立からの期間、 業種は支配的ではない イノベーションへの投 資、学習する文化は重要 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
108. 事例. 日本経済新聞社 日経イノベーションラボとい う研究開発部署 作業負荷の軽減や新たな顧客 体験の創出のため 将来的な課題を見据えて、新 技術に関する課題を整理し、 先んじて検証 組織的な LLM 活用を後押し 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果をスケ ールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
109. 事例. サントリー 生成 AI を社内で活用して いる事例 実践により活用のための 知見を得ていった 従来型の機械学習プロジ ェクトも数多く推進 データの品質向上が精度 向上につながった 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果 をスケールさせる処方箋」 講談社 2024年 https://www.kspub.co.jp/book/detail/5369562.html
110. 事例でわかる MLOps: はじめに もしあなたが自分の経験に自信がないにもか かわらず機械学習システムに関わらなければ いけなくなったのなら、たとえばシステム開 発に詳しくないのに開発に携わらなければい けないデータサイエンティストであったり、 機械学習に詳しくないソフトウェアエンジニ アであったりするのなら、あなたは本書が想 定する読者の一人です。 杉山 阿聖, 太田 満久, 久井 裕貴 編著 「事例でわかるMLOps 機械学習の成果をスケールさせる処方箋」 講談社 2024 年 https://www.kspub.co.jp/book/detail/5369562.html
111. まとめ 機械学習システムの置かれた状況は組織ごとに大きく異なり、 MLOps のそれぞれの原則を理解して適用する必要がある MLOps の取り組みを技術・プロセス・文化で整理した 技術面はある程度パターンが見えてきたものの、レイテンシーなど の要件で技術的な複雑さが大きく変わる点に注意が必要 プロセスにおいては複雑性に対する取り組みが重要、小さく始めて 徐々に進めること、幅広い利害関係者との協業が必要なことに注意 文化面は無視できないものの、企業の規模や業種は無関係、学習す る文化は大事
112. TOC MLOps を巡る歴史 GenAIOps の技術・プロセス・文化 MLOps の技術・プロセス・文化 AI エージェント <-
113. AI エージェント 飛び杼 (破壊的イノベーションの例) AI エージェントの業務浸透 生産性のパラドックス 発生している課題 Stevey's Google Platforms Rant Bezos Mandate Gemini Enterprise Agent Platform リーン・スタートアップの忘却 今後の研究
114. 飛び杼 機織り機に革命をもたらした発明 杼 (ひ) をキャッチする助手を不要に 生産性は2−3倍に (文献により異なる) Shuttle with bobin horizontal.jpg https://ja.wikipedia.org/wiki/ファイル:Shuttle_with_bobin_horizontal.jpg CC BY-SA 3.0
115. AI エージェントの業務浸透 約3,000名の現業部門でAI効率化 を推進、半分の人員で現業を維持 → 残り人員を新規事業へ 開発エンジニア生産性 最大20倍 法務チェック工数 90%削減 しかし「タスク工数が減ると余っ た時間で新たな仕事を追加してし まう」 DeNA南場智子「先に動かし、事業を広げる」 スピーチ全文書き起こし | フルスイング by DeNA https://fullswing.dena.com/archives/100189/
116. 生産性のパラドックス 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)
117. 発生している課題 1つの PR のサイズが増大し、レビューしきれなくなり品質低下 チーム開発している場合、個々のタスクの消化は高速に終わるが、 他のチームも同様なので、レビュー依頼が殺到して処理しきれない リーガルチェックのように、バックオフィスとして社内に提供して いるサービスへの依頼件数が文字通り倍増、待ち行列が長大に
118. Stevey's Google Platforms Rant Amazon が Microservice Architecture へと移行する前の状態 システムがモノリシックな構造である場合、互いの変更がどう影響 するかわからないため、機能開発チーム間での綿密な調整が必要 再現のない調整会議 綿密な統合テスト 共通のデプロイ計画 これらがとてつもないコミュニケーションコストを生み出し、シス テム開発が硬直化
119. Bezos Mandate (1/2) 今後、すべてのチームはデータと機能をサービスインターフェイス を通じて公開すること。 チーム間のコミュニケーションは、これらのインターフェイスを通 じて行わなければならない。 他のいかなるプロセス間通信も許可されない。ダイレクトリンキン グ、他のチームのデータストアへの直接読み取り、共有メモリモデ ル、バックドアなど、いかなるものであっても一切禁止する。許可 される唯一の通信方法は、ネットワーク越しのサービスインターフ ェイス呼び出しのみである。
120. Bezos Mandate (2/2) 使用する技術は問わない。HTTP、Corba、Pub/sub、カスタムプロ トコルなど、何でもよい。ベゾスは気にしない。 すべてのサービスインターフェイスは、例外なく、当初から外部に 公開可能なように設計されなければならない。すなわち、チームは 外部の開発者にインターフェイスを公開できることを前提に計画・ 設計しなければならない。例外は認められない。 これを実行しない者は解雇される。
121. 結果: 新たな複雑な問題が発生 エスカレーションが困難、1つの不具合が発生したとき、どの API が原因なのか突き止めることが困難で、担当チームを突き止めるの が難しい 互いのチームが DoS 攻撃者となりかねないため、スロットリング とクォータの導入が必須 デプロイ前のQAによる担保が不可能、モニタリングの強化が必須 どんなサービスがあるのか知るのが難しい、サービスリポジトリが 必要 他の人のコードをデバッグするのはほぼ無理
122. ということは…？
123. AI エージェントで複雑な問題が発生 エスカレーションが困難、1つの不具合が発生したとき、どのエー ジェントが原因なのか突き止めることが困難で、担当チームを突き 止めるのが難しい 互いのエージェントが DoS 攻撃者となりかねないため、スロット リングとクォータの導入が必須 デプロイ前のQAによる担保が不可能、モニタリングの強化が必須 どんなエージェントがあるのか知るのが難しい、エージェントリポ ジトリが必要 他のチームのエージェントをデバッグするのはほぼ無理
124. Gemini Enterprise Agent Platform IAM やログ、ロードバラン サーが Cloud の基礎とな ったように AI エージェン トの基礎が必要 AI エージェントの基礎と なるサービスが提供され 始めた Agent Platform overview | Gemini Enterprise Agent Platform | Google Cloud Documentation https://docs.cloud.google.com/gemini-enterpriseagent-platform/overview
125. 半分の人材で現在の業務を回す準備は開始
126. もう半分の人材で新規事業開発ができる？
127. リーン・スタートアップの忘却 IVS 2026 のレポート 「エンジニアを採用しなくても生成AIでプ ロダクトを作れる」という起業家のその後 数百万円分のトークンを燃やした後にPoC レベルで失敗 リーン・スタートアップの「作るのではな く検証せよ」という教えが忘却されている 「上場」が消え、EXITがM&A前提になった夏 ― IVSで見たスタートアップの現在地｜久松剛 https://comemo.nikkei.com/n/nadbc7cff8628?sub_rt=share_pw
128. 今後の研究 リーン・スタートアップ型の仮説検証サイクルを AI で支援 AI が提案するのではなく、AI で組織の学習装置を作成 初期の取り組みを公開済み 8th Grand Canvas : AI品質の未来を共に描く https://qai.pj.aist.go.jp/event/8th_grand_canvas/
129. まとめ MLOps は ML の成果をスケールさせるためのさまざまな取り組み TPS は仕事を楽にすることが重要であり、データに基づいて PDCA サイクルを回すことでカイゼンを実施している DevOps はすばやい開発とフィードバックによる継続的な改善が重 要であり、そのために CI/CD パイプラインを構築し自動化している MLOps はフィードバックループを継続的な訓練により実現してお り、そのために機械学習パイプラインを構築し自動化している GenAIOps は継続的な評価によりフィードバックループを実現して おり、チームとして業務の専門知識を身に着けている