目次
第1章 LLMOpsの世界へようこそ
1.1 なぜ今LLMOpsが必要なのか
- 1.1.1 生成AIアプリケーションの急速な普及
- 1.1.2 LLM導入の失敗から学ぶ教訓
- 1.1.3 従来の開発手法の限界
- 1.1.4 LLMOpsによる成功事例
- 1.1.5 LLMOpsの登場背景
- 1.1.6 規制動向とコンプライアンス要件
1.2 従来のMLOpsとLLMOpsの決定的な違い
- 1.2.1 アーキテクチャの根本的な違い
- 1.2.2 開発サイクルの劇的な変化
- 1.2.3 イテレーション速度の違い
- 1.2.4 実験の性質の変化
- 1.2.5 バージョン管理対象の変化
- 1.2.6 評価手法の根本的な違い
- 1.2.7 セキュリティとプライバシーの新パラダイム
- 1.2.8 運用面での違い
- 1.2.9 チーム構成と役割の変化
1.3 MLflowが解決するMLOps/LLMOpsの課題
- 1.3.1 従来のMLOpsにおける課題
- 1.3.2 LLM時代の新たな課題
- 1.3.3 MLflowのLLM対応機能の全体像
- 1.3.4 LLMOpsの課題とMLflowの4つのコアコンポーネント
1.4 本書の構成と読み方ガイド
- 1.4.1 本書の全体構成
- 1.4.2 読者層別の読み方ガイド
- 1.4.3 サンプルコードとリソース
- 1.4.4 効果的な学習のためのヒント
- 1.4.5 学習目標とマイルストーン
1.5 まとめ
- 1.5.1 本章の重要ポイント
- 1.5.2 次章への準備
- 1.5.3 最後に
第2章 MLflowとは
2.1 MLflowの進化を知る
2.2 MLflow以前の機械学習プロジェクトにおける課題（～2018年）
- 2.2.1 実験の散逸
- 2.2.2 チーム共有の障壁
- 2.2.3 本番環境でのギャップ
2.3 MLOpsプラットフォームとしてのMLflowの誕生・発展（2018～2022年）
- 2.3.1 実験管理
- 2.3.2 Model Registry
- 2.3.3 MLflowがもたらした変化
2.4 LLMのブレークスルーと課題の変化（2023～2024年）
- 2.4.1 ChatGPTによるLLMの爆発的な普及
- 2.4.2 モデル中心からシステム中心へ
2.5 MLflowの誕生（2025年）
2.6 まとめ
第3章 MLflowのインストールと初期設定
3.1 前提条件の確認
- 3.1.1 Python環境の準備
- 3.1.2 uvのインストール
3.2 サンプルプロジェクトのセットアップ
- 3.2.1 サンプルエージェントの概要
- 3.2.2 リポジトリのクローン
- 3.2.3 依存パッケージのインストール
- 3.2.4 MLflowのインストール
- 3.2.5 Tracking Serverの起動
3.3 サービスの設定とエージェントのテスト実行
- 3.3.1 APIキーの取得
- 3.3.2 環境変数の設定
- 3.3.3 ドキュメントデータの取り込み
- 3.3.4 エージェントの実行
3.4 応用（1）：OpenAI以外のLLMを使用する場合
- 3.4.1 Anthropic
- 3.4.2 Google Gemini
- 3.4.3 Azure OpenAI
- 3.4.4 Amazon Bedrock
3.5 応用（2）：より高度なTracking Serverの設定
3.6 応用（3）：マネージドMLflowの活用
- 3.6.1 Databricks
- 3.6.2 Amazon SageMaker
- 3.6.3 Nebius
- 3.6.4 Red Hat OpenShift AI
3.7 まとめ
第4章 可観測性の確保──トレーシングの導入
4.1 可観測性・トレーシングとは
- 4.1.1 LLMアプリケーションの複雑化
- 4.1.2 アプリケーションのブラックボックス化
- 4.1.3 可観測性とトレーシング
4.2 LLMアプリケーションにおけるトレーシング
- 4.2.1 プロンプトとレスポンスの内容
- 4.2.2 トークン使用量とコスト管理
- 4.2.3 モデルのパラメータとデフォルト値の可視化
- 4.2.4 ツール呼び出しの詳細
- 4.2.5 処理の階層構造と並列実行の可視化
- 4.2.6 データとしてのトレースの価値
4.3 トレーシングを有効にする
4.4 MLflow QAエージェントへのトレーシング導入
- 4.4.1 自動トレーシングの有効化
- COLUMN 実験（Experiment）とは
- 4.4.2 実行してトレースを確認
- 4.4.3 エラーのデバッグと修正
4.5 トレースに追加情報を付与する
- 4.5.1 タグの追加
- 4.5.2 タグを使ったトレースの検索
- 4.5.3 会話セッションの管理
4.6 トレーシングの仕組みと実装
- 4.6.1 自動トレーシング（Autolog）
- 4.6.2 手動トレーシング
- 4.6.3 自動トレーシングと手動トレーシングの組み合わせ
4.7 応用（1）：TypeScriptアプリケーションのトレーシング
- 4.7.1 MLflow TypeScript SDKでのトレーシング
- 4.7.2 Vercel AI SDKでのトレーシング
4.8 応用（2）：トレースの検索
4.9 応用（3）：OpenTelemetryとの連携
- 4.9.1 MLflowトレースのエクスポート
- 4.9.2 MLflowへのOTLPトレースの取り込み
- 4.9.3 OpenTelemetry Collectorの使用
4.10 応用（4）：並行実行とスレッド安全性
- 4.10.1 非同期処理（async/await）
- 4.10.2 マルチスレッド環境
4.11 まとめ
第5章 改善サイクルを加速する ──評価の仕組み
5.1 LLMアプリケーションの品質保証の難しさ
- 5.1.1 LLMエージェントの複雑性
- 5.1.2 評価をする＝開発が遅くなる？
5.2 評価の始め方：まずは実際に動かしてみる
- 5.2.1 テスト用の質問を用意
- 5.2.2 推論を実行し，人手で評価
5.3 ドメイン専門家によるレビュー
5.4 評価基準を決定する
- 5.4.1 自然言語の出力を評価することの難しさ
- 5.4.2 LLM-as-a-Judgeとは
- 5.4.3 LLMジャッジを利用する際の注意点
- 5.4.4 MLflowにおけるスコアラーの実装
- 5.4.5 組み込みスコアラー（ルールベース／LLMジャッジ）
- COLUMN MLflowの評価プロンプトを読む
- 5.4.6 カスタムスコアラーとGuidelinesスコアラー
- 5.4.7 スコアラーのバージョン管理
5.5 評価データセットの準備
5.6 自動評価の実行
- 5.6.1 評価の実行
- 5.6.2 評価結果の確認
- 5.6.3 評価ランの比較
- 5.6.4 分析の次のステップ
5.7 応用（1）：会話セッションのシミュレーションと評価
- 5.7.1 単発の評価 vs. 会話の評価
- 5.7.2 会話セッション向けの組み込みスコアラー
- 5.7.3 会話セッションのカスタムスコアラー
- 5.7.4 シミュレーターによる会話の生成と評価
- 5.7.5 ペルソナや目標を実際の会話ログから作成する
- 5.7.6 テストケースのデータセット管理
5.8 応用（2）：LLMジャッジのアライメント
- 5.8.1 アライメントのワークフロー
- 5.8.2 MemAlign：メモリによるアライメント
5.9 応用（3）：サードパーティ評価ライブラリとの連携
5.10 まとめ
第6章 プロンプトエンジニアリング──プロンプトの運用と管理
6.1 プロンプト管理の課題とPrompt Registryの価値
- 6.1.1 プロンプト管理の課題
- 6.1.2 Prompt Registryの価値
6.2 プロンプトのバージョニングとライフサイクル管理
- 6.2.1 プロンプトの登録
- 6.2.2 バージョン更新と不変性
- 6.2.3 エイリアス管理とライフサイクル
- 6.2.4 タグとメタデータ
- 6.2.5 プロンプトの性能分析
- 6.2.6 モデルパラメータの保存
- 6.2.7 構造化出力（Structured Output）の利用
6.3 プロンプトの運用・改善戦略
- 6.3.1 プロンプトのオフライン評価
- 6.3.2 プロンプトの段階的デプロイ
- 6.3.3 プロンプトのA/Bテスト
- 6.3.4 プロンプトの自動最適化
6.4 まとめ
第7章 本番環境で動かす──サービングとデプロイメント
7.1 LLMサービングの課題
- 7.1.1 従来のMLサービングとの違い
- 7.1.2 エージェントサービング固有の課題
- 7.1.3 MLflowのサービング機能
- 7.1.4 サービング方式の選択
7.2 エージェントのサービング準備
- 7.2.1 Agent Server用エージェント定義
- 7.2.2 Prompt Registryとの統合
- 7.2.3 Agent Serverの起動と動作確認
- COLUMN Models from CodeとModel Registry
7.3 バージョン管理とサービング評価
- 7.3.1 Gitベースのバージョントラッキング
- 7.3.2 サービング環境での評価
7.4 AI Gatewayによるプロバイダー管理
- 7.4.1 AI Gatewayの役割とアーキテクチャ
- 7.4.2 AI Gatewayのセットアップ
- 7.4.3 エージェントからAI Gatewayを利用する
- 7.4.4 A/Bテストとフォールバック
- 7.4.5 使用状況の追跡とコスト管理
7.5 本番デプロイメント
- 7.5.1 デプロイ前チェックリスト
- 7.5.2 Dockerコンテナとしてのデプロイ
- 7.5.3 Kubernetesへのデプロイ
- 7.5.4 Databricks Model Servingによるデプロイ
- 7.5.5 ロールバック戦略
7.6 応用（1）：ストリーミングとResponsesAgent
- 7.6.1 ストリーミングレスポンスの実装
- 7.6.2 ResponsesAgentによるカスタム実装
7.7 応用（2）：カスタムアプリケーション統合
- 7.7.1 FastAPIラッパー
- 7.7.2 Gradioによるデモインターフェース
7.8 まとめ
第8章 監視と運用──LLMアプリケーションの健全性管理
8.1 本番環境でのトレースベース監視
- 8.1.1 本番環境におけるトレーシングの重要性
- 8.1.2 効果的なトレース設計の指針
- 8.1.3 MLflow軽量トレーシングSDK
- 8.1.4 本番トレーシングの基本設定
- 8.1.5 トレースデータの保存先と戦略
- 8.1.6 トレースへのメタデータ追加
- 8.1.7 サンプリング戦略
8.2 トークン使用量とコストの可視化
- 8.2.1 トークン使用量追跡の重要性
- 8.2.2 Overviewダッシュボード
- 8.2.3 トークン使用量の自動追跡
- 8.2.4 コストの可視化と監視
- 8.2.5 コスト最適化戦略
8.3 品質メトリクスのリアルタイム追跡
- 8.3.1 LLMアプリケーションの品質課題
- 8.3.2 監視すべき品質メトリクス
- 8.3.3 ユーザーフィードバックの収集
- 8.3.4 LLMジャッジによる自動評価
- 8.3.5 継続的評価パイプラインの構築
8.4 アラート設定とインシデント対応
- 8.4.1 アラート戦略の設計
- 8.4.2 アラート閾値の設定
- 8.4.3 アラート通知システム
- 8.4.4 インシデント対応フロー
- 8.4.5 ロールバック戦略
8.5 OpenTelemetryとの統合
- 8.5.1 OpenTelemetryが必要になる場面
- 8.5.2 OpenTelemetryの概要
- 8.5.3 MLflow TracingのOTLP設定
- 8.5.4 OpenTelemetry Collectorの設定
- 8.5.5 主要な可観測性プラットフォームとの統合
- 8.5.6 GenAI Semantic Conventions
8.6 まとめ
- 8.6.1 監視・運用チェックリスト
- 8.6.2 次のステップ
- COLUMN LLMアプリケーション監視の成熟度モデル
第9章 実践ケーススタディ
9.1 非構造文書からの情報抽出アプリケーション
- 9.1.1 実際の活用事例
- 9.1.2 アプリケーションの処理の流れ
- 9.1.3 MLflowの使いどころ
- 9.1.4 実装例
- 9.1.5 サービングまでの手順
- COLUMN MLflow PyFuncとは
- 9.1.6 本番運用に向けた工夫
- 9.1.7 本節のまとめ
9.2 社内技術文書検索システム（エージェント型RAG）
- 9.2.1 実際の活用事例
- 9.2.2 アプリケーションの処理の流れ
- 9.2.3 MLflowの使いどころ
- 9.2.4 実装例
- 9.2.5 サービングまでの手順
- 9.2.6 本番運用に向けた工夫
- 9.2.7 本節のまとめ
9.3 技術レポート作成マルチエージェント
- 9.3.1 実際の活用事例
- 9.3.2 アプリケーションの処理の流れ
- 9.3.3 MLflowの使いどころ
- 9.3.4 実装例
- 9.3.5 サービングまでの手順
- 9.3.6 本番運用に向けた工夫
- 9.3.7 本節のまとめ
9.4 まとめ
第10章 エンタープライズ環境でのMLflow活用
10.1 エンタープライズ環境におけるLLMOpsの要件
- 10.1.1 エンタープライズLLMOpsの全体像
- 10.1.2 技術要件
- 10.1.3 ガバナンスとコンプライアンス
- 10.1.4 セキュリティとアクセス制御
- 10.1.5 コスト管理と最適化
10.2 Databricksプラットフォームの概要
- 10.2.1 Databricksとは
- 10.2.2 統合データレイクハウスアーキテクチャ
- 10.2.3 Unity Catalogによるデータガバナンス
- 10.2.4 Delta Lakeとの統合
10.3 DatabricksにおけるMLflow実装
- 10.3.1 OSS MLflowとマネージドMLflowの違い
- 10.3.2 Databricksワークスペースでの設定
- 10.3.3 Mosaic AI Agent Frameworkとの統合
- 10.3.4 Agent Bricksによる自動最適化
- 10.3.5 ResponsesAgentインターフェースによるエージェント開発
- 10.3.6 エージェント評価機能による品質保証
- 10.3.7 ベクトル検索との統合
- 10.3.8 Feature StoreとModel Registryの統合
- 10.3.9 AutoMLとの連携
- 10.3.10 移行パスと互換性
10.4 エンタープライズ環境での実践
- 10.4.1 マルチワークスペース戦略とRBAC
- 10.4.2 CI/CDパイプラインの構築
- 10.4.3 モデルサービングとスケーリング
- 10.4.4 LLMアプリのモニタリング
- 10.4.5 モデルガバナンスのベストプラクティス
10.5 まとめ
第11章 LLMOpsの未来とベストプラクティス
11.1 最後の章にあたり
11.2 LLMOpsの進化の方向性
- 11.2.1 AIエージェントの台頭とMLflowの対応
- 11.2.2 Model Context Protocolとエージェントエコシステム
- 11.2.3 マルチエージェントシステムの管理
- 11.2.4 規制環境の整備とコンプライアンス
11.3 MLflowエコシステムの拡張
- 11.3.1 MLflowの主要な新機能
- 11.3.2 フレームワーク統合の拡大
- 11.3.3 Databricksエコシステムとの統合深化
- 11.3.4 マルチプラットフォーム対応
11.4 組織におけるLLMOps文化の醸成
- 11.4.1 LLMOps成熟度モデル
- 11.4.2 役割と責任の明確化
- 11.4.3 ベストプラクティスの共有と標準化
- 11.4.4 継続的な学習と改善
11.5 今後の学習リソース
- 11.5.1 公式ドキュメントとリファレンス
- 11.5.2 コミュニティリソース
- 11.5.3 関連ツールとフレームワーク
- 11.5.4 今後のキャリアパス