ストーリー
田
田中VPoE
LLMOps、モニタリング、インシデント対応の知識が揃った。これらを統合して、実際のAI運用設計書を作成してもらう
田
田中VPoE
ある。RAGベースの社内AIチャットボットが本番稼働して3ヶ月。ユーザーから「回答の品質にばらつきがある」「たまに嘘をつく」との声が上がっている。運用チームは手動でログを確認しているが追いつかない状況だ
あなた
まさに今学んだことが必要な状況ですね。品質の自動評価、モニタリング、インシデント対応の仕組みを一から設計する必要がある
あ
田
田中VPoE
そうだ。CTOへの提案書として、実行可能な運用設計書を仕上げてくれ。「こう運用すれば品質を維持できる」と説得力のある内容にしよう
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | AI運用設計書の作成 |
| 想定時間 | 60分 |
| 成果物 | LLMOps基盤設計 + モニタリングダッシュボード設計 + インシデント対応プレイブック |
前提条件
| 項目 | 内容 |
|---|
| システム概要 | RAGベースの社内AIチャットボット(社内規程・FAQ対応) |
| 稼働期間 | 本番稼働3ヶ月 |
| 利用状況 | 月間アクティブユーザー約500名、日次リクエスト約2,000件 |
| モデル | OpenAI GPT-4o(APIベース) |
| RAGデータ | 社内規程集(約200文書)、FAQ(約500件) |
| 現状の課題 | 品質のばらつき、ハルシネーション、手動ログ確認の限界 |
| 運用体制 | 開発チーム3名が兼務(専任の運用担当なし) |
| 月間API費用 | 約30万円 |
Mission 1: LLMOps基盤の設計
要件
現在の「コードを変更してデプロイ」という単純なフローを、AI品質を保証するCI/CDパイプラインに進化させてください。
- CI/CDパイプラインの設計: プロンプト変更、RAGデータ更新、アプリケーションコード変更の3つのトリガーに対応
- 評価自動化: 品質を定量的に判断するための評価スイートの設計
- デプロイ戦略: 安全にリリースするためのデプロイ戦略
- プロンプト管理: プロンプトのバージョン管理とレビューフロー
解答例
CI/CDパイプライン設計
# AI CI/CDパイプライン
name: AI Chatbot CI/CD
triggers:
prompt_change:
paths: ["prompts/**"]
pipeline: [lint, eval_regression, eval_safety, canary_deploy]
rag_update:
paths: ["knowledge/**"]
pipeline: [validate_docs, reindex, eval_retrieval, eval_regression, deploy]
code_change:
paths: ["src/**"]
pipeline: [unit_test, integration_test, eval_regression, canary_deploy]
stages:
lint:
- prompt_syntax_check
- template_variable_validation
- prohibited_pattern_check
eval_regression:
- name: "回帰テスト(50ケース)"
dataset: "golden_dataset_v3.jsonl"
metrics:
quality_score: ">= 4.0"
faithfulness: ">= 0.85"
relevance: ">= 0.80"
judge_model: "gpt-4o"
eval_safety:
- name: "安全性テスト(30ケース)"
dataset: "safety_test_cases.jsonl"
checks:
- prompt_injection_resistance
- pii_leak_prevention
- prohibited_content_filter
eval_retrieval:
- name: "検索精度テスト"
dataset: "retrieval_test_cases.jsonl"
metrics:
recall_at_5: ">= 0.80"
mrr: ">= 0.70"
canary_deploy:
- deploy_canary(10%)
- monitor(duration=30min, metrics=[quality, latency, error_rate])
- if_passed: deploy_full
- if_failed: rollback + alert
評価スイート設計
| 評価カテゴリ | テストケース数 | 評価方法 | 合格基準 |
|---|
| 社内規程FAQ | 30件 | LLM-as-a-Judge + リファレンス比較 | 品質スコア >= 4.0 |
| 複雑な質問 | 10件 | LLM-as-a-Judge | 品質スコア >= 3.5 |
| 安全性テスト | 20件 | ルールベース + LLM評価 | 違反ゼロ |
| 境界ケース | 10件 | カスタム評価関数 | エラーなし |
デプロイ戦略
| フェーズ | トラフィック | 期間 | 判断基準 |
|---|
| カナリア | 10% | 30分 | 品質スコア >= 4.0、エラー率 < 1% |
| 段階展開 | 50% | 2時間 | 品質スコア安定、ユーザー報告なし |
| 全展開 | 100% | - | 前フェーズの基準継続達成 |
プロンプト管理フロー
1. 開発者がプロンプトを変更(Gitブランチ)
2. PR作成 → 自動で評価スイート実行
3. 評価結果をPRにコメント
4. チームメンバーがレビュー(品質スコアの変化を確認)
5. マージ → カナリアデプロイ → 段階展開
Mission 2: 品質モニタリングダッシュボードを設計する
要件
運用チームが日常的にAIシステムの品質を把握できるモニタリングダッシュボードを設計してください。
- メトリクス定義: 監視すべきメトリクスとその計測方法
- ダッシュボードレイアウト: 何をどう表示するか
- アラートルール: いつ、誰に、どうアラートするか
- 定期レビュープロセス: 週次/月次でのレビュー内容
解答例
監視メトリクス一覧
| メトリクス | 計測方法 | 目標値 | アラート閾値 |
|---|
| 回答品質スコア | LLM-as-a-Judge(日次100件サンプリング) | >= 4.0 | < 3.5 |
| ハルシネーション率 | ソース照合チェック(全件) | < 5% | > 8% |
| ユーザー満足度 | いいね/わるいね比率 | >= 80% | < 70% |
| 再質問率 | 同セッション内の類似質問の割合 | < 15% | > 25% |
| 応答レイテンシ(p95) | アプリケーションログ | < 5秒 | > 8秒 |
| 日次API費用 | OpenAI usage API | < 1.5万円 | > 2万円 |
| エスカレーション率 | 「人間に聞く」ボタン押下率 | < 10% | > 15% |
| エラー率 | HTTP 5xx / タイムアウト | < 0.5% | > 2% |
ダッシュボードレイアウト
┌────────────────────────────────────────────────────────┐
│ 社内AIチャットボット 運用ダッシュボード │
├──────────┬──────────┬──────────┬──────────┬─────────────┤
│ 品質スコア │ 満足度 │ レイテンシ │ 日次コスト │ エラー率 │
│ 4.1 ▲ │ 82% ● │ 3.2s ● │ ¥12,400 │ 0.3% ● │
├──────────┴──────────┴──────────┴──────────┴─────────────┤
│ 品質スコア推移(30日) │
│ [折れ線グラフ: 日次品質スコアと7日移動平均] │
├────────────────────────┬───────────────────────────────┤
│ カテゴリ別品質 │ ハルシネーション率推移 │
│ 就業規則: 4.3 ████████ │ [折れ線グラフ: 日次推移] │
│ 経費精算: 4.0 ███████ │ 現在: 3.2% (目標: <5%) │
│ 福利厚生: 4.2 ████████ │ │
│ IT規程: 3.8 ██████ │ │
├────────────────────────┼───────────────────────────────┤
│ 直近の低品質回答(5件) │ アクティブアラート │
│ [リスト: 質問、スコア、 │ ● P3 IT規程カテゴリ品質低下 │
│ 問題点] │ ● P4 レイテンシ微増 │
├────────────────────────┴───────────────────────────────┤
│ ユーザーフィードバック集計 │ 利用量推移(日次リクエスト数) │
│ 👍 1,640 👎 360 │ [棒グラフ: 日次推移] │
└────────────────────────────────────────────────────────┘
アラートルール
| ルール名 | 条件 | レベル | 通知先 | 自動アクション |
|---|
| 安全性違反 | 有害出力を検知 | P1 | オンコール + マネージャー | フォールバックモード有効化 |
| 品質急落 | 日次品質スコア < 3.5 | P2 | オンコール | サンプリング率を10%→50%に増加 |
| ハルシネーション急増 | ハルシネーション率 > 8% | P2 | オンコール | 該当カテゴリの回答に警告表示 |
| コスト超過 | 日次コスト > 予算120% | P3 | チームチャンネル | レート制限の強化 |
| レイテンシ劣化 | p95 > 8秒 | P3 | チームチャンネル | なし |
| 満足度低下 | 週次満足度 < 70% | P3 | チームチャンネル | なし |
定期レビュープロセス
| 頻度 | 参加者 | レビュー内容 | 成果物 |
|---|
| 日次 | 運用担当 | ダッシュボード確認、低品質回答レビュー | 特記事項メモ |
| 週次 | 開発チーム全員 | 品質トレンド分析、フィードバック分析、改善施策検討 | 週次レポート |
| 月次 | チーム + マネージャー | ROI評価、コスト分析、次月の改善計画 | 月次レポート |
Mission 3: AIインシデント対応プレイブックを作成する
要件
社内AIチャットボットで発生しうるインシデントに対応するプレイブックを作成してください。
- インシデント分類: このシステムで想定されるインシデント類型と深刻度
- 対応フロー: 検知から復旧までの手順
- ロールバック手順: 安全にロールバックするための具体的手順
- コミュニケーションテンプレート: 社内ユーザーへの通知文
解答例
インシデント分類(社内AIチャットボット固有)
| ID | インシデント類型 | 深刻度 | シナリオ例 |
|---|
| AI-01 | 社内規程の誤回答 | SEV2 | 就業規則について事実と異なる内容を回答 |
| AI-02 | 個人情報の漏洩 | SEV1 | RAGソースに含まれる個人情報が回答に出力 |
| AI-03 | プロンプトインジェクション | SEV2 | システムプロンプトの漏洩、意図しない動作 |
| AI-04 | 品質の全体的劣化 | SEV3 | モデル更新による品質低下、RAGインデックス破損 |
| AI-05 | サービス停止 | SEV3 | OpenAI API障害、レート制限超過 |
| AI-06 | コスト急増 | SEV4 | 異常なリクエスト増加によるAPI費用の急増 |
対応フロー: AI-01(社内規程の誤回答)
検知(自動 or ユーザー報告)
│
├── 1. トリアージ(15分以内)
│ ├── 誤回答の内容確認
│ ├── 影響範囲の特定(何人が閲覧したか)
│ └── 深刻度判定(法的リスク、業務影響)
│
├── 2. 緩和(1時間以内)
│ ├── 該当カテゴリの回答に「確認中」バナー追加
│ ├── 問題のRAGソースを特定
│ └── 必要に応じてプロンプトの緊急修正
│
├── 3. 修正(4時間以内)
│ ├── RAGソースの修正 or プロンプトの修正
│ ├── 修正版の評価スイート実行
│ └── 修正版のデプロイ
│
├── 4. 事後対応(24時間以内)
│ ├── 影響ユーザーへの通知
│ ├── 正しい情報の提供
│ └── 根本原因分析
│
└── 5. 再発防止(1週間以内)
├── テストケースの追加
├── モニタリングルールの強化
└── プレイブックの更新
ロールバック手順
# ステップ1: 現在の状態を確認
kubectl get deploy ai-chatbot -o json | jq '.spec.template.spec.containers[0].env'
# ステップ2: プロンプトのロールバック(フィーチャーフラグ)
curl -X POST https://feature-flags.internal/api/flags/prompt-version \
-d '{"value": "v2", "reason": "SEV2 incident AI-01"}'
# ステップ3: RAGインデックスのロールバック(必要な場合)
python scripts/restore_rag_index.py \
--snapshot="2025-01-15T00:00:00Z" \
--reason="SEV2 incident AI-01"
# ステップ4: ロールバック後の品質確認
python scripts/run_eval_suite.py \
--suite=smoke \
--output=rollback_verification.json
# ステップ5: 確認完了後、ステータス更新
curl -X POST https://incident-mgmt.internal/api/incidents/AI-INC-2025-042 \
-d '{"status": "mitigated", "action": "rollback_completed"}'
コミュニケーションテンプレート
社内ユーザーへの通知(発生時):
件名: 【お知らせ】社内AIチャットボットの回答品質について
社内AIチャットボットをご利用の皆様
現在、[カテゴリ名]に関する一部の回答に不正確な内容が
含まれていることを確認しております。
■ 影響範囲
・対象: [カテゴリ名]に関する質問への回答
・期間: [開始日時] 〜 現在
■ 対応状況
・該当カテゴリの回答に注意喚起のバナーを表示しています
・正確な情報への修正作業を進めています
■ お願い
・[カテゴリ名]に関する重要な判断は、[担当部署]に
直接ご確認ください
・不正確な回答を発見された場合は、「わるいね」ボタンで
ご報告ください
修正完了後、改めてご連絡いたします。
ご不便をおかけし申し訳ございません。
AI基盤チーム
修正完了通知:
件名: 【完了報告】社内AIチャットボットの回答品質改善
社内AIチャットボットをご利用の皆様
先日ご連絡した[カテゴリ名]の回答品質の問題について、
修正が完了しましたのでご報告いたします。
■ 原因
・[簡潔な原因説明]
■ 対策
・[実施した修正内容]
・[再発防止策]
■ 品質確認結果
・修正後の品質テストに合格しています
・今後もモニタリングを継続します
引き続きAIチャットボットをご活用ください。
お気づきの点がございましたら、お気軽にご報告ください。
AI基盤チーム
達成度チェック
| 観点 | 達成基準 |
|---|
| LLMOps基盤 | プロンプト変更、RAGデータ更新、コード変更の3トリガーに対応したCI/CDパイプラインが設計されている |
| 評価自動化 | テストケース、評価手法、合格基準が具体的に定義されている |
| モニタリング | 品質の4軸(精度、レイテンシ、コスト、安全性)をカバーするメトリクスが定義されている |
| アラート設計 | 深刻度別のアラートルールと対応フローが明確 |
| インシデント対応 | システム固有のインシデント類型が分類され、対応手順が具体的 |
| コミュニケーション | ステークホルダー別の通知テンプレートが用意されている |
推定所要時間: 60分