MLOpsエンジニアのtomoppiです。
データエンジニアリング部 データサイエンスグループ（以下、DS G）に所属し、ML/LLM基盤の構築・改善に取り組んでいます。
概要
2025年4月、タイミーPlatform EngineerのMoneyForestさんが、「タイミーにおけるProduction Readiness Checkの取り組み」という記事を公開しました。サブシステムや新規サービスのリリースに際しての評価基準を定めたもので、MLOpsとしても参考になる部分が非常に多くありました。
その記事に触発され、DS Gとしても再現性高くLLM Applicationを構築・運用するための評価基準を定めたいと思うようになり、本記事で言及する Production Readiness Checklist for LLM Applicationの策定に至りました。
背景
2024年以降、DS Gでは複数のLLMを活用したプロダクト開発に取り組んできました。しかし、前述のチェックリストをDS Gが構築・運用する LLM Applicationに適用しようとすると、以下のような課題に直面しました。
- AWS前提で書かれているため、DS Gで利用しているGoogle Cloud用に読み替える必要がある
- LLM特有の非決定性への考慮が必要
- 継続的評価やGenerative AI ライフサイクルの観点が不足している
チェックリスト策定の方針
技術に依存しない普遍的な原則と、タイミーDS Gでの具体的な実装に基づいたガイドの2部構成としました。
理由としては、現在はCloud Runをベースとした運用となっていますが、将来的にGKEの採用やECSへの移行などが十分に可能性としてあるためです。
また、RAG、Agentic Workflow、tool useなどのより高度なLLM利用は対象外としました。
それらを利用するアプリケーション設計・構築の際は、本記事で紹介するチェックリストを土台とし、新たにより専門性の高いチェックリストやそれに準ずる評価基準を設ける想定です。
ビジネス目標に関してはスコープアウトすることも考えましたが、ROIは大事にしていきたいというDS Gの意思として入れ込むことにしました。
チェックリスト
0. 戦略的目標とビジネスアライメント
LLM導入の目的と期待される成果を明確にします。
0-1. ビジネス目標の明確化
- [ ] 測定可能なビジネスゴール（コスト削減率、顧客満足度向上、処理時間短縮等）が設定されている
- [ ] ユースケースに対する期待される精度・応答速度が定義されている
0-2. 成功指標（KPI）の設定
- [ ] ユースケース固有のKPIが定義されている
- [ ] KPIの測定方法とダッシュボードが整備されている
1. 安定性・信頼性
システムを再現可能かつ自動化された方法でデプロイ・運用できるようにします。
1-1. 構成管理
- [ ] すべてのコードがバージョン管理システムで管理されている
- [ ] プロンプト（システムプロンプト、テンプレート等）がバージョン管理されており、変更履歴が追跡可能（監査可能）な状態になっている
1-2. CI/CD
- [ ] Lint、単体テスト、セキュリティスキャン（静的解析）がCIパイプラインで自動化されている
- [ ] 開発(dev)、ステージング(stg)、本番(prod)環境へのデプロイがCDパイプラインで自動化されている
1-3. リリースプロセス
- [ ] プロンプトやモデルの変更が、ステージング環境で品質評価を実行した後に本番にデプロイされるプロセスになっている
- [ ] カナリアリリースや段階的ロールアウトで、主要メトリクス（エラーレート、精度、コスト）を監視しながらリリースされる仕組みが確立している
1-4. LLM選定と継続性
- [ ] 利用モデルのSLA/SLOを踏まえたフォールバック戦略が定義されている
- プライマリLLM APIが利用不可時のフォールバック先（別モデル/静的レスポンス/エラー表示）
- リトライポリシー（回数、待機時間、指数バックオフ等）
- タイムアウト設定
- [ ] モデル非推奨・廃止のスケジュールを把握しており、利用不可能になる前にモデルを更新するプロセスが確立している
2. スケーラビリティとパフォーマンス
トラフィックの増減に対応し、効率的なリソース利用を目指します。
2-1. キャパシティプランニング
- [ ] コンテナ実行環境でオートスケーリングが設定されている
- [ ] 利用するLLM APIプロバイダーのレート制限（TPM: Tokens Per Minute / RPM: Requests Per Minute）を把握し、自システムのキャパシティプランに反映されている
- プロバイダー側の制限値を文書化
- 制限値を超えないための流量制御（レートリミッター）の実装
2-2. トラフィック・トークン管理
- [ ] ビジネス要求の変化に伴うトラフィック増加とその影響について、ステークホルダーと認識を揃えている
- [ ] リリース時点で必要なスループットと、システムの最大許容スループットを算出している
- [ ] 1セッションあたりの消費トークン数の見積もりを算出している
- 入力トークン数（プロンプト + ユーザー入力 + コンテキスト）
- 出力トークン数（予想される生成テキスト長）
3. 耐障害性と大惨事対応
システムの一部が故障しても、サービス全体が停止しないようにします。
3-1. 障害シナリオ
- [ ] 想定される障害シナリオが洗い出され、文書化されている
- LLM API障害（タイムアウト、5xx エラー、レート制限超過）
- 依存サービス障害（データベース、外部APIなど）
- ネットワーク障害
- リソース枯渇（メモリ、CPU、ディスク）
- [ ] 各障害シナリオに対応したRunbook（対応手順書）が作成されている
- [ ] 障害発生時の影響（ビジネス損失、ユーザー影響等）を見積もっている
- [ ] LLM API起因による長時間の回復困難な障害が発生した場合の対応方針についてステークホルダーと合意されている
3-2. LLM APIの可用性
- [ ] システム要求（即時性、UX等）とLLM APIの可用性を踏まえたLLM処理コンポーネントの呼び出し方式（同期/非同期）が選択され、システムアーキテクチャに反映されている。
- [ ] LLM API障害時のフォールバック・リトライ戦略が実装されている
- エラー種別ごとのリトライ可否判定（429はリトライ、4xxの多くはリトライ不可等）
- Exponential Backoffによるリトライ間隔の調整
- Circuit Breakerパターンの導入（連続失敗時に一時的にリクエストを停止）
- [ ] LLM APIの冗長化が検討され、必要に応じて実装されている
- 複数のLLMプロバイダーまたは複数のモデルを利用可能にする
- フェイルオーバーの仕組みを実装
3-3. 回復性テスト
- [ ] 負荷テストを実施し、想定トラフィック下での挙動を確認している
- [ ] 主要な障害シナリオを再現させた際、その障害が検知・アラートされることを確認している（カオステスト）
4. 安全性
LLMが生成する有害なコンテンツや不適切な振る舞いを防ぎます。
4-1. リスク分類とインシデント対応
- [ ] ユースケースに合わせた安全性リスク分類が定義されている
- 例: 誤情報、バイアス、プライバシー侵害、非倫理的なアドバイス、有害コンテンツ（ヘイトスピーチ、暴力的表現等）
- [ ] 安全性に関するインシデント発生時の対応プロセス（Runbook）が定義されている
- インシデントの検知方法
- エスカレーションフロー
- 緊急時の対応（プロンプトの切り戻し、機能の一時停止等）
4-2. ガードレール
- [ ] 安全性リスク分類がガードレールのルールに反映されている
- [ ] 入力ガードレールが実装されており、以下を検知・ブロックできる
- プロンプトインジェクション攻撃
- 不適切なトピック（暴力、ヘイト、性的コンテンツ等）
- 機密情報（PII等）を含む入力
- [ ] 出力ガードレールが実装されており、モデルが生成した以下のコンテンツをユーザーに届ける前に検知・フィルタリングできる
- 有害コンテンツ（ヘイトスピーチ、暴力的表現等）
- 機密情報（PII、APIキー等）
- 明らかなハルシネーション（事実と異なる情報）
- [ ] ガードレールで検知された違反はすべて記録されている
4-3. Red Teaming
- [ ] 定期的なレッドチーミング（敵対的テスト）が計画・実行されており、新たな脆弱性を継続的に探索するプロセスが確立している
- ジェイルブレイク（システム制約の回避）
- 巧妙なプロンプトインジェクション
- 複数ターンにわたる対話での安全性回避
5. 監視
システムの状態を可視化し、問題に迅速に対応できるようにします。
5-1. アプリケーションロギング・トレーシング
- [ ] アプリケーションログが構造化ログ（JSON等）で出力されている
- [ ] リクエストごとに一意のIDが生成され、ログとトレースに出力されている
- 分散トレーシング対応（トレースID、スパンIDの伝播）
- 上流サービスから受け取ったIDを継承
- [ ] APM（Application Performance Monitoring）ツールでエンドツーエンドのトレースが可能になっている
5-2. 可視化とアラート
- [ ] 主要メトリクスを一覧できるダッシュボードが整備されている
- システムメトリクス: CPU、メモリ、リクエスト数、レイテンシ
- ビジネスメトリクス: 利用回数、成功率、ユーザー満足度
- LLM固有メトリクス: トークン消費量、API利用料金、エラーレート
- [ ] サービスレベル指標(SLI)と目標(SLO)が定義されている
- 例: 可用性 99.9%、P95 レイテンシ < 3 秒、エラーレート < 1%
- [ ] SLO違反やシステム異常（エラーレート急増やリソース逼迫）時にアラートが発報される
- [ ] LLMガードレール違反検知数や検知率をダッシュボードで確認できる
- [ ] LLMガードレールにより検知された違反を重大度に応じてアラート通知する仕組みが確立している
5-3. LLM Observability
- [ ] LLM APIへのリクエストが分散トレーシングシステムと統合されており、同一リクエスト内のLLM呼び出しがスパンとして関連づけられている
- [ ] LLM APIへのリクエスト単位で以下の情報がトレース可能になっている
- 入力プロンプト（機密情報をマスキング済み）
- 出力レスポンス（機密情報をマスキング済み）
- 利用モデルとパラメータ（temperature、max_tokens等）
- レイテンシ（TTFB: Time To First Byte、全体レスポンス時間）
- 消費トークン数（入力/出力）
- 概算コスト
- [ ] トークン消費量とコストの急増を検知するアラートが設定されている
6. 品質保証(QA)と評価プロセス
LLMの出力品質と安定性を客観的に担保します。
6-1. オフライン評価セット
- [ ] LLM出力を評価するためのデータセット（ゴールデンセット）が定義・管理されている
- 代表的なユースケースをカバーする入力と期待される出力のペア
- データセットの保存場所と管理方法が明確
- [ ] エッジケース、既知の失敗パターン、敵対的入力を評価するデータセットが定義・管理されている
6-2. オフライン評価指標
- [ ] タスクの目的に沿った具体的な評価指標が定義されている
- 分類タスク: Accuracy、Precision、Recall、F1-score
- 生成タスク: BLEU、ROUGE、人手評価（流暢性、正確性、関連性）
- 安全性: 有害コンテンツ検出率、PII漏洩率
6-3. オンライン評価
- [ ] 本番環境での評価項目について導入の必要性を検討し、適切に導入している
- Direct Feedback: ユーザーからの明示的なフィードバック（👍/👎等）
- Functional Correctness: 生成結果が機能的に正しいか
- User Acceptance: ユーザーが結果を採用したか（コピー、編集、実行等）
- Achieved Impact: ビジネスKPIへの影響
- Incidental Metrics: レイテンシ、エラーレート、コスト等
6-4. 継続的改善
- [ ] 評価データセットを継続的に更新するための仕組みが整っている
- 本番トラフィックから評価データセットへのサンプリング
- 失敗ケースの追加プロセス
- [ ] 評価データセットのバージョン管理がされている
- [ ] プロンプトバージョン・モデルバージョン・評価データセットバージョン・パラメータを1単位として評価結果を管理する仕組みが整っている
- 実験管理ツールで各バージョンの組み合わせと評価結果を記録
6-5. 自動テスト
- [ ] LLM API呼び出しを含む主要なE2Eテスト（正常系）が自動化されている
- [ ] プロンプトやモデル変更時に、品質評価セットを用いた回帰テストが自動化または半自動化されている
- [ ] 負荷テストが自動化または半自動化されており、リリース前に負荷テストを行う基準がチーム内で合意されている
7. セキュリティとコンプライアンス
不正アクセスやデータ漏洩、意図しないモデルの振る舞いを防ぎます。
7-1. データ保護
- [ ] LLMへの入力データのうち、PII等のセンシティブ情報が分類され、マスキング対象が特定されている
- 分類基準（例: PII、機密情報、公開情報）が定義されている
- マスキング対象のデータ種別（例: 氏名、メールアドレス、電話番号、住所等）がリスト化されている
- [ ] 転送中および保存データが暗号化されている
- 転送中: TLS/HTTPS
- 保存時: ディスク暗号化、データベース暗号化
7-2. プロンプトインジェクション対策
- [ ] プロンプトインジェクション対策として、多層防御の仕組みが実装されている
- 入力検証・サニタイゼーション
- プロンプトテンプレートの使用（ユーザー入力を直接連結しない）
- 出力の検証・パース
- [ ] ユーザー入力とシステム指示が明確に分離されている
- システムプロンプトとユーザー入力の役割分離（system role / user role）
7-3. アクセス制御
- [ ] LLM APIの認証に、長期的なAPIキーやサービスアカウントキーを使用せず、一時クレデンシャルによる認証方式を利用している
- [ ] APIへのアクセスが適切に認証・認可されている
- ユーザー認証（必要に応じて）
- リクエスト元の検証
7-4. モデルのリスク管理
- [ ] ユーザー入力がLLMの学習データとして利用されないよう設定されているか、リスクが評価・受容されている
- LLMプロバイダーのデータ利用ポリシーを確認
- オプトアウト設定（必要に応じて）
- [ ] 社内のモデル利用ポリシーに沿って利用モデルを選定している
- [ ] Open‑weightモデルを利用する場合、Pickle形式ではなくsafetensors形式を利用している
8. ドキュメントと組織運営
チームメンバーがシステムを理解し、スムーズに運用できるようにします。
- [ ] システム概要・システム構成図・依存関係図が最新の状態に保たれている
- [ ] 主要なアラートへの対応手順（Runbook）や障害対応プロセスがドキュメント化されている
- [ ] 障害発生時のインシデント対応プロセスが定義されており、インシデント発生後のポストモーテム（振り返り）を実施し、再発防止策を講じるプロセスが確立している
タイミーでの実装ガイド
本ガイドは、上記チェックリストを踏まえ、DS Gの技術スタック（Google Cloud、Datadog等）を踏まえた具体の実装例に落とし込んだものです。
1. 安定性・信頼性
構成管理
- コード管理: Git（GitHub）でコード管理
- プロンプト管理: Gitでプロンプトファイルを管理、またはプロンプトバージョニング機能を持つツールを使用
CI/CD
- CI: GitHub ActionsでLint・テスト・SASTを実行
- CD: GitHub ActionsからGoogle Cloud（Cloud Run）へ自動デプロイ
リリースプロセス
- 段階的ロールアウト: Cloud Runのトラフィック分割機能、またはリリース管理ツールを使用
2. スケーラビリティとパフォーマンス
キャパシティプランニング
- オートスケーリング: Cloud Runの「最大インスタンス数」「最小インスタンス数」「同時実行数（concurrency）」を設定
3. 耐障害性と大惨事対応
回復性テスト
- 負荷テスト: Locustを負荷テストツールとして使用
4. 安全性
ガードレール
- 違反記録: 構造化ログまたはDatadogイベントとして記録
5. 監視
アプリケーションロギング・トレーシング
- APM: Datadog APM（Cloud Runのサイドカーに
datadog/serverless-initを設定）
可視化とアラート
- ダッシュボード: Datadog Dashboard、Looker
- アラート: Datadog Monitor、Slack連携
LLM Observability
- LLM監視: Datadog LLM Observability
6. 品質保証(QA)と評価プロセス
オフライン評価セット
- データセット管理: Datadog LLM ObservabilityのDatasets機能の利用、またはBigQuery・GCSをベースとしたデータセットのバージョン管理
継続的改善
- 実験管理: MLflow、Datadog LLM Observability
7. セキュリティとコンプライアンス
アクセス制御
- 認証: Workload Identity Federation（GCP）等
モデルのリスク管理
- タイミー社内の基準を満たすモデルを利用している
振り返りと今後の取り組み
これまでDS Gでは、データサイエンティスト中心のCSチーム（Complicated Subsystem Team）とMLOps（Platform Team）がCollaborationモード（Embedded SREに近い形）の関わり方で、LLMアプリケーションの構築・運用に取り組んできました。これは初期の知見蓄積と開発のアジリティ確保の点で、不可欠で有効なものでした。
しかし、今後サービスが増加するにつれ、この密な連携体制が組織全体のスケールのボトルネックになる懸念がありました。そうした課題を乗り越えるため、MLOpsチームは、CSチームが高速に高品質なアプリケーションを構築できるようなゴールデンパスの整備を進めています。
今回のチェックリスト作成は、その一つの取り組みとして知見を整理し、また現状の課題を再認識するものになったと考えています。
今後DS Gでは、RAGやAgentic Workflowのような、より複雑性の高いアプリケーションの構築や、LLM Gatewayといった基盤導入が控えています。
そうした複雑な課題に対し、CSチームとMLOpsチームがそれぞれの強みを発揮し、協調しながらスケールしていける体制が不可欠だと考えています。 本チェックリストの活用・改善を含め、常により良い協業の形を模索し、再現性高く信頼性のあるML/LLMアプリケーションによる価値創出にチャレンジしていきたいと思っています。
