2025年10月24日·1 分
AIプロトタイプを本番システムへ移行する方法
AIプロトタイプを本番システムに移行する実践ガイド：目標設定、データ準備、評価、アーキテクチャ、セキュリティ、監視、ロールアウト手順を解説します。
AIプロトタイプを本番システムに移行する実践ガイド：目標設定、データ準備、評価、アーキテクチャ、セキュリティ、監視、ロールアウト手順を解説します。
プロトタイプは一つの問いに答えるために作られます：「これで動くか？」 本番システムは別の問いに答えなければなりません：「これを毎日、多くの人に対して、許容できるコストで、明確な責任の下で動かせるか？」 このギャップが、AIプロトタイプがデモでは輝くのに、ローンチ後につまずく理由です。
プロトタイプは通常、理想的条件で動きます：小さく手で選んだデータセット、単一の環境、問題をそっと直す人がいてくれること。デモでは遅延のスパイクや欠損フィールド、たまの誤答は説明できます。本番ではそれらがサポートチケット、ユーザー離脱、そしてリスクになります。
本番準備済みのAIは、より良いモデルというよりは予測可能な運用についてです：
チームがよく驚かされる点：
ここを終えると、再現可能な移行計画が手に入ります：成功を定義し、データを準備し、スケール前に評価し、本番アーキテクチャを選び、コスト/レイテンシを計画し、セキュリティ要件を満たし、人間の監督を設計し、性能を監視して安全にロールアウトする方法—次のプロトタイプが一度きりのデモで終わらないようにします。
プロトタイプはデモで良く見えるため「十分に良い」と感じがちです。本番は異なります：AIの目的、用途外の領域、成功の判定方法について共有され、テスト可能な合意が必要です。
AIが使われる正確な瞬間と、その前後で何が起きるかを記述します。誰がリクエストをトリガーし、誰が出力を消費し、どんな意思決定（またはアクション）を支援するか？
具体的にしましょう：
5分でワークフローが描けないなら、スコープはまだ準備できていません。
AIを既にビジネスが気にしている成果に結び付けます：サポート対応時間の短縮、文書レビューの高速化、リード精度向上、欠陥流出の削減など。「AIでモダナイズする」といった測定不可能な目標は避けます。
有用性と現実の制約を両立する少数の指標を選びます：
違反できない制約を書き出します：稼働目標、許容可能な失敗モード、送信できる／できないデータのプライバシー制限、エスカレーション要件など。
次にシンプルなv1チェックリストを作ります：含めるユースケース、明示的に範囲外にするもの、満たすべき最低メトリクス閾値、受け入れる証拠（ダッシュボード、テスト結果、サインオフ）。これが以後のすべての決定の基準になります。
プロトタイプは小さく選ばれたデータで印象的に見えます。本番ではデータが継続的に複数システムから流れ込み、「厄介な」ケースが標準になります。何かをスケールする前に、どのデータを使い、どこから来て、誰が出力に依存するかを明示してください。
まず完全なチェーンを列挙します：
このマップは所有権、必要な権限、各消費者にとって「良い出力」が何かを明確にします。
何を、どのくらいの期間、なぜ保存するかを書きます。例：デバッグのためにリクエスト／レスポンスのペアを保存するが保持期間は短くする。トレンド分析のために集計メトリクスは長く保存する。保存計画がプライバシー期待と社内ポリシーに合致していること、未加工データと匿名サンプルに誰がアクセスできるかを定義してください。
自動化できる軽量チェックリストを使います：\n\n- 欠損値と空ペイロード\n- 重複とイベントのリプレイ\n- 外れ値（長さ、サイズ、異常フォーマット）\n- クラス不均衡とバイアス信号（地域、デバイス、言語による偏り）\n- “サイレントフェイル”（デフォルト値、プレースホルダーテキスト、切り捨てファイル）\n
結果が変わったら何が変わったかを知らなければなりません。データセット（スナップショットまたはハッシュ）、ラベリングルール、プロンプト/テンプレートをバージョン管理します。各モデルリリースを使用したデータとプロンプトの正確なバージョンに紐付けて、評価やインシデント調査を再現可能にしてください。
プロトタイプのデモはハッピーパスで「良さそう」に見えます。実ユーザーに広げる前に、品質を測る再現可能な方法が必要です。
まずオフラインテスト（リリース前に実行）を用意し、次にシステムがライブになったらオンラインシグナルを追加します。\n\nオフラインは「この変更は我々が気にするタスクでモデルを良くしたか？」を答え、オンラインは「ユーザーは成功しているか、実トラフィックで安全に振る舞っているか？」を答えます。
実使用を反映する例（典型的なリクエスト、一般的なワークフロー、期待されるフォーマット）をキュレーションします。最初は小さく（例：50–200項目）して維持しやすくします。\n\n各項目について「良い」とは何かを定義します：参照回答、採点ルブリック、チェックリスト（正確性、完全性、トーン、引用等）。一貫性が重要です—二人が同じ出力を同じように採点できるようにします。
本番で壊れやすいテストを含めます：\n\n- 機微または制限コンテンツ（PII、医療/法的主張、ポリシー違反）\n- 明確でない要求で確認が必要なケース\n- 非常に長い入力や乱れたフォーマット（表、コピーメール、多言語混在）\n- 敵対的プロンプト（プロンプトインジェクション、Jailbreak風の表現）
事前に許容範囲を決めます：最低精度、最大ハルシネーション率（LLMの場合）、安全性合格率、遅延予算、リクエスト当たりコストなど。即時ロールバックを引く条件（安全違反がX%を超えた、ユーザー苦情の急増、タスク成功率の低下）も定義します。
これがあれば、各リリースはギャンブルではなく統制された実験になります。
プロトタイプはしばしば全てを一箇所に混ぜます：プロンプト調整、データ読み込み、UI、評価がノートブックに混在。本番アーキテクチャは責務を分離して、ある部分を変えても他が壊れず、故障が局所化されるようにします。
システムの実行形態を決めます：\n\n- APIのみ： リクエスト/レスポンスサービス（チャット、検索、推薦で一般的）。\n- バッチジョブ： 定期処理（夜間の文書分類、レポート生成）。\n- リアルタイムサービス： 低レイテンシのストリーミングやイベント駆動（不正検知等）。
この選択がインフラ、キャッシュ、SLA、コスト管理を左右します。
信頼できるAIシステムは通常小さな部品の集合で、境界が明確です：\n\n- UI/クライアント： 入力収集、出力表示、不確かさの説明。\n- オーケストレーション層： 検証、ルーティング、プロンプトテンプレート、ツール/関数呼び出し、状態管理。\n- モデル呼び出し： プロバイダ経由のLLM/ML推論またはセルフホストランタイム。\n- データストア： フィーチャーストア、ベクトルDB、ドキュメントストア、ログ/監査テーブル。
最初は一緒にデプロイしても、各コンポーネントが置換可能だと設計してください。
ネットワークはタイムアウトするし、ベンダーはレート制限をかける、モデルは時に使えない出力を返します。予測可能な振る舞いを作ってください：\n\n- 外部呼び出し（モデル、DB、ツール）にはタイムアウトを設定\n- 一時的エラーにはバックオフ付き再試行\n- フォールバック（単純なモデル、キャッシュ回答、安全モード）\n- グレースフルデグラデーション（部分結果、明確なメッセージ、壊れないUI）
良いルール：システムは「安全に」失敗し、何が起きたかを説明すること。黙って推測し続けるべきではありません。
アーキテクチャをスクリプトではなくプロダクトとして扱います。簡単なコンポーネントマップを維持：依存、所有者、ロールバック方法。これにより「みんながノートブックを持っているが誰もシステムを所有していない」という生産上の罠を避けられます。
デモをメンテナブルなアプリに変えるのがボトルネックなら、構造化されたビルドプラットフォームが配管作業を早めます：Web UI、API層、DB、認証、デプロイの足場。\n\n例えば、Koder.ai はチャットインターフェースでWeb・サーバ・モバイルアプリを作れるvibe-codingプラットフォームです。プロトタイピングを迅速に行い、その後も計画モード、デプロイ/ホスティング、カスタムドメイン、ソースエクスポート、スナップショットとロールバックといった実用的機能で本番へ近づけられます。プロンプト、ルーティング、検索ロジックを反復する際に、きれいなリリースと可逆性が必要な場合に有用です。
プロトタイプは少数のユーザーで「十分安い」に見えます。本番ではコストと速度がプロダクトの機能になります—遅い応答は壊れた体験に感じられ、予期せぬ請求はローンチを台無しにします。
非エンジニアにも説明できるシンプルなスプレッドシートから始めます：\n\n- リクエスト当たり： トークン入出力（LLM）、モデル実行時間、検索（ベクトル検索）呼び出し\n- インフラ： コンピュート（CPU/GPU）、ストレージ（ドキュメント、埋め込み）、ネットワーク出力\n- 運用オーバーヘッド： ログ量、監視、再試行\n\nこれから1,000リクエスト当たりのコストと想定トラフィック時の月間コストを見積もります。さらに「悪い日」も想定：トークン使用増、再試行増、大きなドキュメントなど。
プロンプトやモデルを変える前に、出力を変えずに改善できる点を探します：\n\n- キャッシュ： 繰り返し入力の結果を保存（ドキュメントが滅多に変わらないなら検索結果もキャッシュ）\n- バッチ処理： 可能なら複数リクエストをまとめて処理（埋め込み、モデレーション、分析）\n- コンテキスト縮小： 定型命令の削除、重複取得パッセージの除去、履歴長の上限設定\n これらは通常、コストを下げつつレイテンシも改善します。
許容範囲を決め（例：1リクエスト当たりの最大コスト、日次支出上限）、次のようなアラートを追加します：\n\n- トークン/リクエストの急増\n- エラーによる再試行の増加\n- ログ量の暴走\n
平均ではなくピーク負荷を想定します。レート制限を定義し、バーストワークロードに対してキューイングを検討し、明確なタイムアウトを設定します。ユーザー向けでないタスク（サマリ生成、インデックス作成）はバックグラウンドジョブに移して、メイン体験を速く予測可能に保ちます。
セキュリティとプライバシーはデモから本番へ移す際の「後回し」ではありません—何を安全に出荷できるかを形作ります。スケールする前に、システムが何にアクセスできるか（データ、ツール、内部API）、誰が操作可能か、失敗時に何が起きるかを文書化してください。
AI機能が悪用されるか失敗する現実的な方法を列挙します：\n\n- プロンプトインジェクション： ユーザーがモデルを騙してルール無視や隠し指示を実行させる。\n- データ漏洩： 機密入力（顧客情報、内部文書）が出力やログ、ベンダーのダッシュボードに現れる。\n- 不安全なツールアクセス： モデルが「ユーザーを削除する」「データをエクスポートする」などのツールを権限なしに呼べる。
この脅威モデルが設計レビューと受け入れ基準を導きます。
入力、出力、ツール呼び出しに集中してガードレールを設けます：\n\n- 入力検証： サイズ制限、ファイルタイプチェック、悪用フィルタ、未知コンテンツの明確な扱い\n- 出力フィルタ： 秘密情報や個人情報のブロック／マスキング、許可されないコンテンツの除外、安全なフォールバック応答\n- ツール許可リスト： モデルが使えるツールを制限し、パラメータも限定、高影響アクションはユーザー確認を必須にする
APIキーやトークンはコードやノートブックに置かず、シークレットマネージャに保管します。最小権限アクセスを適用し、サービスアカウントは必要最低限のデータと操作のみアクセスできるようにします。\n\nコンプライアンス面ではPIIの扱い（何を保存し、何をマスクするか）、センシティブ操作の監査ログ、プロンプト・出力・トレースの保持ルールを定義します。出発点として社内基準に合わせ、/privacy のチェックリストにリンクしてください。
プロトタイプはモデルが「十分正しい」と仮定しがちです。本番では、出力が顧客、資金、安全、評判に影響する場合に人が介入する計画が必要です。HITLは自動化の失敗ではなく、学習しながら品質を保つ制御システムです。
リスクで意思決定をマップします。低影響タスクは抜き取りでよく、高影響タスクはレビューや編集、明示的な承認を必要とします。\n\nレビューのトリガー例：\n\n- 低モデル信頼度や引用欠如\n- 機微トピック（法務、医療、人事）\n- 異常なユーザー要求や意図の曖昧さ\n- 大きな下流影響（返金、アカウント変更）
いいね/バッドは出発点ですが改善には不足しがちです。レビュアーやエンドユーザーがワンクリックで訂正や理由コード（「事実誤り」「安全でない」「トーン」「文脈不足」など）を付けられる軽量UIを用意してください。可能なら以下を保存します：\n\n- 元の入力と最終編集版\n- 理由コード\n- 問題が事実、フォーマット、方針関連、または安全性関連のどれか
有害・高影響・ポリシー違反の出力用にエスカレーション経路を作ります。単純な「報告」ボタンでアイテムをオンコールキューに送る、SLAと封じ込めプレイブック（機能無効化、ブロックリスト追加、プロンプトの厳格化）を用意しておきます。
製品が正直であるほど信頼は高まります。制限を表示し、過度の確信を避け、可能なら引用やソースを示します。システムがドラフトを生成している場合はその旨を示し、編集を容易にしてください。
プロトタイプが誤動作するときは気づきやすいものです。本番では問題はエッジケースやトラフィックスパイク、ゆっくり進行する劣化に潜みます。可観測性は問題を早期に見える化する手段です—顧客インシデントになる前に検出します。
イベントを後で再構築するために必要な項目を決めます。AIシステムでは「エラーが起きた」だけでは不十分：\n\n- リクエスト／入力（機密ならマスキング）\n- モデルとプロンプトのバージョン、主要設定（temperature、コンテキストウィンドウ、検索設定）\n- ツール呼び出しとその結果\n- レイテンシ内訳（検索時間 vs モデル時間 vs 下流呼び出し）\n ログは構造化（JSON等）にして、テナント、エンドポイント、モデルバージョン、失敗タイプでフィルタできるようにします。ログから「何が変わったか？」が答えられなければ、必要なフィールドが欠けています。
伝統的な監視はクラッシュを捕まえます。AIでは「動いているが質が悪化している」ことを捕まえる必要があります。追うべき指標：\n\n- ドリフト信号（入力トピックの変化、埋め込み距離、検索ヒット率）\n- エラー率（タイムアウト、ツール呼び出し失敗、 malformed 出力）\n- 結果/品質のプロキシ（いいね/バッド、タスク完了、サポートへのエスカレーション）\n- 安全性シグナル（ポリシー違反、応答拒否、不安全なコンテンツ）
これらは明確な閾値と担当者を持つファーストクラスの指標として扱ってください。
ダッシュボードは「健康か？」と「最速の修復は何か？」に答えるべきです。すべてのアラートにはオンコール用のランブック（何を確認するか、どうロールバックするか、誰に通知するか）を添えます。ノイズの多いアラートは無い方がマシです—ユーザー影響に基づいてページング条件を調整してください。
各リリースに対して実使用を模した定期的な「カナリア」リクエストを追加し、期待される振る舞い（フォーマット、遅延、基本的な正確さ）を検証します。安価な早期警告システムとして、実ユーザーモニタリングを補完します。
プロトタイプはローカルで一度動けば「完了」に感じられます。本番での仕事の大半は、正しい入力で繰り返し動くようにすることです。MLOpsワークフローは自動化、トレーサビリティ、安全な変更経路を提供します。
AIサービスを他のプロダクトと同様に扱います：変更ごとに自動パイプラインをトリガーします。最低限CIは：\n\n- サービスをビルド（コンテナ/アプリパッケージ）\n- コアロジックとデータ検証のユニットテストを実行\n- 固定データセットでのモデル/プロンプト評価テスト（悪いケース含む）\n- デプロイ可能なアーティファクトを生成\n そのアーティファクトを同じ手順で dev/staging/prod にデプロイするのがCDです。これにより「自分のマシンでは動く」問題が減り、ロールバックも現実的になります。
AIシステムは伝統的アプリと異なる軸で変わるため、次をバージョン管理してレビュー可能にします：\n\n- アプリケーションコード（API、オーケストレーション、フィーチャーロジック）\n- プロンプト、テンプレート、システムメッセージ（LLMコンポーネント）\n- モデル識別子（モデル名、チェックポイント、プロバイダ設定）\n- 構成（閾値、ルーティングルール、ツール権限）\n- 評価データセットとラベリングガイドライン
インシデントが起きたときに「どのプロンプト＋モデル＋設定がこの出力を生んだか？」と即答できるようにします。
最低でも3つの環境を使います：\n\n- Dev： モック統合での高速イテレーション\n- Staging： 本番に近いデータフローと権限でフル評価ゲートを実行\n- Production： 制御されたリリース、厳格なアクセス管理、監査
同じアーティファクトを環境間で昇格させ、再ビルドは避けてください。
CI/CDゲート、バージョン命名規約、環境昇格のテンプレートは /blog を参照してください。パッケージ化されたローンチ支援は /pricing を参照すると良いでしょう。\n\nKoder.ai を使って周辺アプリ（React UI＋Go API＋Postgres等）を構築する場合、スナップショット/ロールバックと環境設定を同じリリース方針に組み込み、ステージングでテストして制御されたロールアウトを行い、既知の良いバージョンに簡単に戻せるようにしてください。
AIプロトタイプの出荷は単一の「デプロイ」ボタンではなく、ガードレール付きの制御実験です。学習を早めつつユーザー信頼、予算、運用を壊さないことが目的です。
シャドウモードは新しいモデル/プロンプトを並列で動かすがユーザーには影響を与えません。実トラフィックで出力、レイテンシ、コストを検証するのに最適です。\n\nカナリアリリースは少数のリクエストを新バージョンに送ります。指標が健全なら徐々に増やします。\n\nA/Bテストはモデル、プロンプト、検索戦略、UIなどを事前定義した成功指標で比較する場合に使います。\n\n機能フラグで内部ユーザーや特定地域などのセグメント向けに機能を有効化し、再デプロイなしに振る舞いを切り替えられます。
最初のロールアウト前に「go/no-go」閾値を書きます：品質スコア、エラー率、ハルシネーション率、遅延、リクエスト当たりコストなど。停止条件（安全でない出力の急増、サポートチケット増加、p95遅延の上昇）も定義し、自動で一時停止できるようにしてください。
ロールバックはワンステップでできるべきです：以前のモデル/プロンプト/設定に戻す。ユーザー向けフローには、単純なルールベースの応答、ヒューマンレビュー経路、または「答えられません」といった安全なフォールバックを準備してください。
サポートとステークホルダーに何が変わるか、誰が影響を受けるか、問題の識別方法を伝えます。短いランブックと内部FAQを用意してチームが一貫して対応できるようにしてください。
ローンチは新しいフェーズの始まりです：AIシステムは実ユーザー、実データ、実エッジケースと相互作用します。最初の数週間を学習ウィンドウと位置づけ、改善作業を運用の計画済みな一部にしてください。
本番の結果を事前のベンチマークと比較し、評価セットを定期的に更新して実際のユーザー要求や発生するミスを反映させます。例えば毎月のペースで：\n\n- 新たに観測された失敗ケースをテストスイートに追加\n- 古いシナリオに過剰適合しないよう例をリバランス\n- 上流の変更（データソース、UI、ポリシー）後に品質を再確認
モデルを再訓練するにせよ、LLMのプロンプトやツールを調整するにせよ、同じ製品リリースの管理を通して変更を実施します。何を、なぜ変えたか、何を改善すると期待しているかを明確に記録し、段階的ロールアウトでバージョンを比較して影響を証明してから全面切替えしてください。\n\n不慣れなら軽量なワークフローを定めます：提案 → オフライン評価 → 限定ローンチ → 全面ローンチ。
定期的なレビューでは次の3つの信号を合わせます：インシデント（品質やアウトテージ）、コスト（API支出、コンピュート、人間レビュー時間）、ユーザーフィードバック（チケット、評価、解約リスク）。直感で直すのではなく、各所見を計測可能なフォローアップに落としてください。
v2計画は実用的な改良に焦点を当てます：自動化の拡大、テストカバレッジの向上、より明確なガバナンス、強化された監視/アラート。繰り返し発生するインシデントを減らし、改善をより安全かつ迅速にする作業を優先してください。
公開可能な学びをまとめるなら、チェックリストやポストモーテムを内部ドキュメントや公開ノートにすることを検討してください。一部のプラットフォーム（Koder.ai を含む）は、コンテンツ作成や紹介でクレジットを得られるプログラムを提供しており、実験コストの相殺に役立つことがあります。
プロトタイプは理想的な条件下で**「これで動くか？」に答えるものです（小さなデータセット、人間が裏で問題を直す、遅延に寛容など）。本番は「これを毎日、安定して動かせるか？」**に答える必要があります。
実務上、本番準備はモデルそのものよりも運用によって決まります：信頼性目標、安全な失敗モード、監視、コスト管理、責任の所在などです。
まず正確なユーザーワークフローとそれが改善すべきビジネス成果を定義します。
その上で、以下の少数の指標を選びます：
最後に、v1の「完了定義」を書いて、何が「出荷して良いか」を全員で合意します。
エンドツーエンドのデータフローをマップします：入力、ラベル/フィードバック、下流の消費者。
次にガバナンスを整えます：
これにより「デモでは動いたが本番で動かない」という現実世界の混乱を防げます。
小さく代表的なゴールデンセット（通常50～200件）を作り、ルブリックや参照出力で一貫して採点します。
早い段階でエッジケースを含めます：
事前に閾値とロールバックトリガーを定めておくと、リリースは制御された実験になります。
隠れた手作業は、デモを安定して見せるための“人間の接着剤”で、その人がいなくなると壊れます。
よくある例：
対策は、各ステップをアーキテクチャ上で明示し（検証、再試行、フォールバック）、個人ではなくサービスが担うようにすることです。
役割を分離して、どれか一つを変更しても全体が壊れないようにします。主要な分離点は：
運用モード（API、バッチ、リアルタイム）を選び、タイムアウト、再試行、フォールバック、グレースフルデグラデーションで失敗に備える設計が重要です。
シンプルなコストモデルを作ります：
その上で、挙動を変えずに最適化できる点を探します：
まず簡単な脅威モデルを作ります。想定される悪用や失敗を列挙してください：
高リスク箇所に対して実用的なガードレールを追加します：
さらにシークレットはシークレットマネージャに保管し、最小権限でアクセスを制限、保存・保持ポリシー（PIIの扱い、監査ログ、保持期間）を整備します。設定の参考は /privacy を参照してください。
ヒューマン・イン・ザ・ループ（HITL）は自動化の失敗ではなく、品質を保つための制御システムです。
レビューが必要な箇所をリスクに応じて決めます。低影響のタスクは抜き取り検査で良いですが、高影響（方針判断、医療・金融）ではレビューや承認が必須です。
レビューのトリガー例：
フィードバックは使える形で Capture します：理由コード（「事実誤り」「安全性」「トーン」「文脈不足」等）や、元入力と編集後の最終版を保存してください。重大なケースはオンコールやプレイブックのあるエスカレーション経路で処理します。
まず「何を再構築すればイベントを追えるか」をログで決めます。AIシステムでは「エラーが起きた」だけでは不十分です。ログに含めるべきは：
ログは構造化（JSON等）にして、テナント／エンドポイント／モデルバージョンでフィルタできるようにします。
監視は単なる稼働率ではなく品質を監視します：入力ドリフト、エラー率、結果のプロキシ（いいね/バッド、タスク完了、サポートへのエスカレーション）、安全性シグナル等。
ダッシュボードとアラートにはランブックを添えて、アラートがページングする条件はユーザー影響に基づくようにチューニングしてください。さらに、シンセティックプローブ（canaryリクエスト）を定期実行してリグレッションを早期検知します。
変更は自動化されたパイプラインを通して行うべきです。最低限のCIは：
CDは同じアーティファクトを dev → staging → prod にデプロイすること。再構築せずに同一アーティファクトを昇格させてください。
また、コードだけでなくプロンプト、モデル識別子、構成、評価データセットやラベリングルールまでバージョン管理します。インシデント時に「どのプロンプト＋モデル＋設定で出たか」をすぐ答えられることが目的です。
実務的なチェックリストやテンプレートは /blog と /pricing を参照してください。Koder.ai を使う場合はスナップショット／ロールバック機能や環境設定を同じリリース方針に組み込んでください。
AI機能の出荷は制御された実験です。リスクに応じてローンチ方式を選びます：
事前に「go/no-go」基準と停止条件を定め、ロールバックは1ステップで元に戻せるようにします。ユーザー対面フローにはルールベースの代替、ヒューマンレビュー、または「回答できません」のような安全なフォールバックを用意してください。
変更内容はサポートとステークホルダーに周知し、短いランブックと内部FAQを提供して「今日AIの回答が変わったのはなぜか？」に速やかに対応できるようにします。
ローンチは始まりです。初週は学習期間と位置づけ、改善作業を計画的な運用の一部にします。
定期的に評価を現実に合わせて更新します：生産環境の結果をベンチマークと比較し、テストセットを新たに観測された失敗ケースで更新します（例：毎月）。
再学習やプロンプト変更も変更管理を通して行い、提案→オフライン評価→限定ローンチ→本番展開のフローを回します。
定期的なポストローンチレビューではインシデント、コスト、ユーザーフィードバックを統合して、直感ではなく計測に基づいた改善タスクに落としてください。v2は自動化、テストカバレッジ、ガバナンス、監視の改善に焦点を当て、繰り返し起きる問題を減らすことを優先します。
予算上限と異常検出アラート（トークン急増、再試行急増）も設定してください。