--- title: リリース検証・カナリア・復旧 url: https://doc.liz6.com/ja/ai/04-evaluation-and-production/03-release-and-recovery locale: ja area: ai tags: - 大規模モデルと Agent - 評価と運用 date: 2026-06-30 modified: 2026-09-10 description: リリース対象はコード・モデル・プロンプト・ツール・権限・索引の組合せです。その版に対応する根拠を揃えてから、カナリア・拡大・停止を判断します。本稿は検証手順を統合し、個々の式や実行規則は各専門記事を参照します。 --- # リリース検証・カナリア・復旧リリース対象はコード・モデル・プロンプト・ツール・権限・索引の組合せです。その版に対応する根拠を揃えてから、カナリア・拡大・停止を判断します。本稿は検証手順を統合し、個々の式や実行規則は各専門記事を参照します。 ## 固定された候補バージョンとタスクの境界まず、システムが何を行い、どのように完了を確認するかを明確にします。クエリ型アシスタントには、検証可能な出典を持つ回答を要求できます；実行型アシスタントには、実際のビジネスステータスの確認も必要です。モデルの応答終了、HTTP 200、またはツールが例外を投げなかったことだけでは、タスクの成功を単独で証明できません。手動処理も明確な結果分岐であり、その割合とコストを統計する必要があります。沈黙して自動成功としてカウントしてはいけません。候補バージョンには、少なくともアプリケーションコード、モデル識別子とパラメータ、プロンプトテンプレート、ツールスキーマ、権限ポリシーを特定できる必要があります。検索を使用する場合は、ドキュメントスナップショット、チャンキングと埋め込み設定、インデックスバージョンを記録します。永続状態を使用する場合は、状態フォーマットとマイグレーションルールを記録します。プロンプトにバージョン番号を割り当てるだけでなく、他の依存関係が検証後にこっそり変更されないようにしてください。浮動モデルエイリアスしか使用できないサービスの場合、実際に入手可能なバージョン情報と検証時間を記録し、供給元の変更が再現性を低下させることを認めます。アーキテクチャを選択する際は、同じタスクセット上での品質、レイテンシ、コスト、復旧の難しさを比較します。固定ワークフローにはモデルステップを含めることができ、単一エージェントは独立したツールを並列に呼び出すことができます；マルチエージェントの利点は、調整と結果のマージのオーバーヘッドを上回る必要があります。複雑さはアーキテクチャのアップグレードのための十分な理由ではなく、エラーを発見できるかどうかは「すべてのアクションをロールバックできること」と同義ではありません。特定のタスクでは、実行前に許可されない効果を防ぐ必要があります。関連解説: [エージェントループ](/ai/03-agent-systems/01-agent-loop.md)、[マルチエージェントオーケストレーション](/ai/03-agent-systems/06-multi-agent-orchestration.md)。 ## リリース前のチェックリスト各項目について、責任者、候補バージョン、検証時間、証拠の場所、結論を記録します。未実行と失敗は別々に記録しますが、どちらも合格を偽装してはいけません。該当なしの項目には理由を明記し、チェックボックスを単に削除してはいけません。 ### 品質とモデル設定 | チェック項目 | 残すべき証拠 | それに代わることはできないシグナル | |---|---|---| | [ ] タスクの成功と失敗の定義 | 出力要件、ビジネス事後条件、拒否/手動転送ルール | モデルが「完了した」と自己主張すること | | [ ] 代表的なタスクと境界条件のカバレッジ | 固定評価セット、難易度、言語、ツールタイプなどでグループ化された結果 | 単一のデモや全体の平均スコア | | [ ] 独立した検証セットの保持 | トンニングセットと検証セットの分割、反復試験戦略 | 同じ問題セットで満点になるまで調整を繰り返すこと | | [ ] スコアリング方法のキャリブレーション | プログラムチェックのカバレッジ範囲、手動レビュー、審判の誤判定サンプル | 「プログラムスコアリングを使用したので必ず客観的である」ということ | | [ ] モデル能力とパラメータの確認 | 選択したエンドポイントが実際にサポートするパラメータ、停止/拒否/切り捨てブランチの検証 | すべてのモデルに統一して high effort を設定すること | | [ ] 構造とビジネス制約の検証 | スキーマ検証および数、状態、リソース帰属などのネガティブケース | JSON が解析できること | 評価における「何を観察するか」と「誰がスコアリングするか」は2つの次元です。ビジネス結果はプログラムチェックでも、手動またはモデル審判による評価でもよく、成果（outcome）をプログラムスコアリングより低い方法として後回しにしてはいけません。1回の成功が、繰り返し実行時の安定性を示すものではありません。各タスクの試験回数と集計基準を明記する必要があります。[Anthropic: エージェント評価](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) サンプリング、推論予算、出力上限は異なる役割を持ちます。temperature を機械的に effort に翻訳しないでください。また、すべての新モデルがサンプリングパラメータを削除すると仮定しないでください。関連する原理は [トークンとサンプリング](/ai/01-model-foundations/01-tokens-and-sampling.md)、[推論と思考](/ai/01-model-foundations/04-reasoning-and-verification.md)、[評価と観測](/ai/04-evaluation-and-production/01-evaluation-and-observability.md)、[構造化出力](/ai/02-context-and-interfaces/01-prompt-and-output-contracts.md) を参照してください。 ### コンテキスト、知識、状態 | チェック項目 | 残すべき証拠 | 典型的な失敗分岐 | |---|---|---| | [ ] 完全なリクエストに予算を確保 | ツール定義、検索材料、履歴と出力用に予約された総予算 | 単一ドキュメントは収まるが、完全なリクエストはオーバーフローする | | [ ] 検索と回答の2層を検証 | 候補の召回、ランキング、引用の対応、証拠なし時の動作 | 回答は流暢だが、引用が結論をサポートしていない | | [ ] バージョンと権限の変更を確認 | ドキュメントの更新、削除、権限剥奪後のインデックスとキャッシュテスト | 原文は権限剥奪済みだが、古いスニペットがまだ返される | | [ ] セッションの復元を検証 | 完了したステップ、確認待ちの結果、外部オブジェクトIDの復元記録 | 復元後、未知の結果を未実行として扱う | | [ ] 状態の互換性を検証 | 旧状態の読み取り、新状態の書き込み、ロールバック互換範囲 | ロールバックされたアプリケーションが新チェックポイントを読み取れない | 「テナント間の読み取りを禁止する」を例に挙げると、モデルが最終的に他人のコンテンツを出力していないかどうかだけでなく、検索とツール実行の段階でこれらのコンテンツがコンテキストに取り込まれていないことを確認する必要があります。キャッシュと長期記憶もアクセスパスです。キャッシュヒットが、最新の資料を使用したことを証明するわけではありません。ヒット率の目標は、鮮度要件と合わせて判断する必要があります。詳細は [コンテキストエンジニアリング](/ai/02-context-and-interfaces/02-context-engineering.md)、[RAG](/ai/02-context-and-interfaces/03-retrieval-and-evidence.md)、[メモリと状態](/ai/03-agent-systems/04-memory-and-recovery.md) を参照してください。モデル選択における重み、KV、ハードウェア予算については [モデルアーキテクチャ](/ai/01-model-foundations/03-inference-and-kv-cache.md) を参照してください。 ### 実行権限、信頼性、観測 | チェック項目 | 残すべき証拠 | 典型的な失敗分岐 | |---|---|---| | [ ] エグゼキュータの独立した権限検証 | 跨ユーザー/プロジェクト、偽装主体、不要なパラメータの拒否テスト | モデルが approved を渡すと許可される | | [ ] 汎用ツールの能力制限 | ファイル境界、コマンドパラメータ、ネットワーク送信などの隔離検証 | コマンド名は合法だが、任意のファイルに書き込める | | [ ] インジェクションと機密データフローのチェック | 合成インジェクションケース、ログのマスキング、出力端の処理 | ツール資料が信頼できる指示として昇格する | | [ ] タイムアウトとビジネス失敗の区別 | 不明な書き込み結果のクエリ、重複排除、復旧記録 | タイムアウト後に、すでに成功したアクションを再実行する | | [ ] リトライとキューの制約 | 総デッドライン、最大試行回数、有界キュー、過負荷戦略 | SDK と外側のリトライが重なり、増幅される | | [ ] 完全なタスクの観測 | 関連ID、重要ステップの所要時間、タスク結果、完全な費用 | モデルの応答時間と単一トークンのみを統計する | | [ ] 障害分岐の検証 | スロットリング、ツール例外、ストリーム切断、切り捨て、一部バッチの失敗 | ストリーミングリクエストの確立が完了したとみなす | 既存のタスク権限は、システムが操作チェーンに沿って渡す必要があります。追加の確認が必要なアクションは、具体的なポリシーに従って処理します。逐次的な手動クリックは、リソース権限や冪等性を代替するものではありません。詳細は [セキュリティと保護](/ai/03-agent-systems/05-authority-and-tool-boundaries.md)、[コスト、パフォーマンス、信頼性](/ai/04-evaluation-and-production/02-cost-performance-and-reliability.md) を参照してください。接続プロトコルとツール発見の境界については [MCP とスキル](/ai/03-agent-systems/02-tools-and-mcp.md) を参照してください。 ## 証拠の状態とバージョンの一致 4つの状態を使用できます：`pass`（合意された条件を満たす）、`fail`（満たさない）、`not_run`（未実行）、`not_applicable`（理由があり、責任あるプロセスによって適用不可能と確認された）。レポートが存在することが通過を意味するわけではなく、レポートが通過することが現在の候補に属することを意味するわけでもありません。必須チェックについては、欠落、失敗、未実行、またはバージョンの不一致は、自動承認を阻止する必要があります。以下のローカル教育例は、このルールのみを示すものであり、何もデプロイしません。複数の実際の依存バージョンの組み合わせを `candidate` として抽象化します。実際のシステムでは、証拠のソース、内容、有効期限、適用範囲を検証する必要があり、任意の呼び出し元が報告する pass を信頼してはいけません。 ```python from copy import deepcopy REQUIRED = {"quality", "authorization", "recovery"} def blockers(candidate, evidence): problems = [] for name in sorted(REQUIRED): item = evidence.get(name) if not isinstance(item, dict): problems.append((name, "missing")) elif item.get("candidate") != candidate: problems.append((name, "stale")) elif item.get("status") != "pass": problems.append((name, "not_passed")) elif not isinstance(item.get("report"), str) or not item["report"].strip(): problems.append((name, "no_report")) return problems reports = {name: {"candidate": "release-17", "status": "pass", "report": f"reports/{name}-17.json"} for name in REQUIRED} assert blockers("release-17", reports) == [] assert len(blockers("release-18", reports)) == 3 for state in ["fail", "not_run", "not_applicable"]: changed = deepcopy(reports) changed["quality"]["status"] = state assert blockers("release-17", changed) == [("quality", "not_passed")] changed = deepcopy(reports) del changed["authorization"] assert blockers("release-17", changed) == [("authorization", "missing")] changed = deepcopy(reports) changed["recovery"]["report"] = "" assert blockers("release-17", changed) == [("recovery", "no_report")] print("バージョン一致で承認；旧バージョン、未通過、欠落項目、レポート欠落はすべて承認を阻止") ``` ここで必要な項目は、「適用不可能」でスキップすることはできません。条件付き項目は、リリースルールによって明確なシナリオで適用不可能と判断できます。例えば、ビジネスへの書き込みが完全にないクエリサービスには、返金の重複排除チェックは不要ですが、独自のタイムアウト復旧チェックは必要です。候補バージョンが自らの判断で必須項目リストを縮小することは許されません。 ### 緑の検査結果はどの候補のものかチェック状態は永久の真偽値でなく、候補・入力集合・検査環境に紐付けます。ここでは版を展開し、過去の合格と現在使える根拠を分けます。 **緑の検査結果はどの候補のものか** リリースの判定には現候補の有効な根拠が必要です。旧版の緑の結果は自動継承しません。 ## カナリアリリースと復旧オフラインでの承認が完了した後、限られた範囲の実際のタスクで新バージョンを観察し、比較可能な旧バージョンのトラフィックと比較します。カナリアリリースでは、指標、観察条件、停止ルールを事前に定義する必要があります。トラフィック比率を単に 1% に設定しただけでは、十分な証拠が自動的に得られるわけではありません。低トラフィックのビジネスでは、重要な失敗シナリオに遭遇するまでに非常に時間がかかる場合があります。[Google SRE: カナリアリリース](https://sre.google/workbook/canarying-releases/) | フェーズ | 重点的な確認 | 継続または停止の根拠 | |---|---|---| | シャドウ検証（適用可能な場合） | 同一入力に対する出力とリソース消費 | ツールへの書き込みは隔離またはシミュレートすべきであり、実際の副作用を重複させてはならない | | 小規模カナリア | 品質グループ、手動引き継ぎ、タスク費用、テールレイテンシ | 事前に設定された観察条件を満たし、停止ルールがトリガーされていない場合 | | 段階的拡大 | クォータ、キュー、キャッシュ、ダウンストリーム容量 | スケール拡大後も、予算とサービス目標内に収まっている場合 | | 安定版へのロールバック | 新タスクルーティング、実行中のタスク、状態の互換性 | 復旧結果を確認し、発生した副作用を個別に処理する | 例えば、100件のタスクのうち95件が成功したからといって、実際の成功率が少なくとも95%であることが証明されたわけではありません。独立した同一分布の簡化仮定の下では、95/100の両側95% Wilson区間の下限は約88.8%です。実際のタスクには、分布の変化や相関関係もあります。公開の拡大は、サンプルサイズ、重要なグループ、ビジネスの許容度と組み合わせて判断する必要があり、美しい一点推定で判断を代替してはいけません。ロールバック計画は、3つの異なる質問に答える必要があります：新しいリクエストを旧設定にどう戻すか、実行中のタスクをどう停止または完了させるか、すでに発生した返金/メール送信などの効果をどう照合するか。プロンプトを元に戻しても、返金は取り消されません。進行中のタスクに無理やりモデルやツールのバージョンを変更すると、状態契約が破綻する可能性があります。タスクを候補バージョンにバインドすることを優先し、アップグレード、エージングアウト、復旧の戦略を明確にします。 ### 成功率95%の根拠はどれほど強いかリリース根拠には標本情報も必要です。同じ観測比率なら標本増で区間は狭まりますが、似たタスクの反復で独立性や群の網羅は保証されません。区間は万能な公開基準ではありません。 [NIST: Wilson interval](https://www.itl.nist.gov/div898/handbook/prc/section2/prc241.htm) $$ \frac{\hat p+\frac{z^2}{2n}\ \pm\ z\sqrt{\frac{\hat p(1-\hat p)}n+\frac{z^2}{4n^2}}}{1+\frac{z^2}{n}} $$ **成功率95%の根拠はどれほど強いか** 同じ観測成功率でも少数標本では区間が広くなります。失敗0件でも失敗確率0の証明にはなりません。 ## リリース後のクローズループ事故を回帰テストに組み込む前に、失敗を説明するのに十分なバージョンと必要なトレースを保存し、個人情報や機密データに対して適切な処理を行います。実際のデータを長期評価セットに直接コピーすると、露出範囲が拡大する可能性があります。同じ失敗条件を保持する合成ケースを構築することができます。有用な回帰テストは、「同じ質問をもう一度尋ねる」だけでなく、期待される結果と失敗の位置を記録する必要があります。例えば、跨テナントのチケットイベントは、エグゼキュータの拒否テストとエンドツーエンドのインジェクションテストに分割できます：前者は権限境界を検証し、後者はモデルが本来のタスクを正しく継続して完了しているかどうかを観察します。修正後に直接関連するテストを実行し、依存関係の影響に応じて回帰を補完し、リリース前に必須の証拠が現在の構成に属していることを再確認します。チェックリストはシステムの変化に合わせて調整されます。無効化された重複チェックを削除し、理由を記録します。実際のギャップをカバーする新しいチェックを追加します。維持目標は、チェックボックスを増やすことではなく、証拠が生産環境での動作をよりよく予測できるようにすることです。