リリース検証・カナリア・復旧

リリース対象はコード・モデル・プロンプト・ツール・権限・索引の組合せです。その版に対応する根拠を揃えてから、カナリア・拡大・停止を判断します。本稿は検証手順を統合し、個々の式や実行規則は各専門記事を参照します。

固定された候補バージョンとタスクの境界

まず、システムが何を行い、どのように完了を確認するかを明確にします。クエリ型アシスタントには、検証可能な出典を持つ回答を要求できます；実行型アシスタントには、実際のビジネスステータスの確認も必要です。モデルの応答終了、HTTP 200、またはツールが例外を投げなかったことだけでは、タスクの成功を単独で証明できません。手動処理も明確な結果分岐であり、その割合とコストを統計する必要があります。沈黙して自動成功としてカウントしてはいけません。

候補バージョンには、少なくともアプリケーションコード、モデル識別子とパラメータ、プロンプトテンプレート、ツールスキーマ、権限ポリシーを特定できる必要があります。検索を使用する場合は、ドキュメントスナップショット、チャンキングと埋め込み設定、インデックスバージョンを記録します。永続状態を使用する場合は、状態フォーマットとマイグレーションルールを記録します。プロンプトにバージョン番号を割り当てるだけでなく、他の依存関係が検証後にこっそり変更されないようにしてください。浮動モデルエイリアスしか使用できないサービスの場合、実際に入手可能なバージョン情報と検証時間を記録し、供給元の変更が再現性を低下させることを認めます。

アーキテクチャを選択する際は、同じタスクセット上での品質、レイテンシ、コスト、復旧の難しさを比較します。固定ワークフローにはモデルステップを含めることができ、単一エージェントは独立したツールを並列に呼び出すことができます；マルチエージェントの利点は、調整と結果のマージのオーバーヘッドを上回る必要があります。複雑さはアーキテクチャのアップグレードのための十分な理由ではなく、エラーを発見できるかどうかは「すべてのアクションをロールバックできること」と同義ではありません。特定のタスクでは、実行前に許可されない効果を防ぐ必要があります。

関連解説: エージェントループ、マルチエージェントオーケストレーション。

リリース前のチェックリスト

各項目について、責任者、候補バージョン、検証時間、証拠の場所、結論を記録します。未実行と失敗は別々に記録しますが、どちらも合格を偽装してはいけません。該当なしの項目には理由を明記し、チェックボックスを単に削除してはいけません。

品質とモデル設定

評価における「何を観察するか」と「誰がスコアリングするか」は2つの次元です。ビジネス結果はプログラムチェックでも、手動またはモデル審判による評価でもよく、成果（outcome）をプログラムスコアリングより低い方法として後回しにしてはいけません。1回の成功が、繰り返し実行時の安定性を示すものではありません。各タスクの試験回数と集計基準を明記する必要があります。Anthropic: エージェント評価

サンプリング、推論予算、出力上限は異なる役割を持ちます。temperature を機械的に effort に翻訳しないでください。また、すべての新モデルがサンプリングパラメータを削除すると仮定しないでください。関連する原理は トークンとサンプリング、推論と思考、評価と観測、構造化出力 を参照してください。

コンテキスト、知識、状態

「テナント間の読み取りを禁止する」を例に挙げると、モデルが最終的に他人のコンテンツを出力していないかどうかだけでなく、検索とツール実行の段階でこれらのコンテンツがコンテキストに取り込まれていないことを確認する必要があります。キャッシュと長期記憶もアクセスパスです。キャッシュヒットが、最新の資料を使用したことを証明するわけではありません。ヒット率の目標は、鮮度要件と合わせて判断する必要があります。

詳細は コンテキストエンジニアリング、RAG、メモリと状態 を参照してください。モデル選択における重み、KV、ハードウェア予算については モデルアーキテクチャ を参照してください。

実行権限、信頼性、観測

既存のタスク権限は、システムが操作チェーンに沿って渡す必要があります。追加の確認が必要なアクションは、具体的なポリシーに従って処理します。逐次的な手動クリックは、リソース権限や冪等性を代替するものではありません。詳細は セキュリティと保護、コスト、パフォーマンス、信頼性 を参照してください。接続プロトコルとツール発見の境界については MCP とスキル を参照してください。

証拠の状態とバージョンの一致

4つの状態を使用できます：pass（合意された条件を満たす）、fail（満たさない）、not_run（未実行）、not_applicable（理由があり、責任あるプロセスによって適用不可能と確認された）。レポートが存在することが通過を意味するわけではなく、レポートが通過することが現在の候補に属することを意味するわけでもありません。必須チェックについては、欠落、失敗、未実行、またはバージョンの不一致は、自動承認を阻止する必要があります。

以下のローカル教育例は、このルールのみを示すものであり、何もデプロイしません。複数の実際の依存バージョンの組み合わせを candidate として抽象化します。実際のシステムでは、証拠のソース、内容、有効期限、適用範囲を検証する必要があり、任意の呼び出し元が報告する pass を信頼してはいけません。

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: カナリアリリース

例えば、100件のタスクのうち95件が成功したからといって、実際の成功率が少なくとも95%であることが証明されたわけではありません。独立した同一分布の簡化仮定の下では、95/100の両側95% Wilson区間の下限は約88.8%です。実際のタスクには、分布の変化や相関関係もあります。公開の拡大は、サンプルサイズ、重要なグループ、ビジネスの許容度と組み合わせて判断する必要があり、美しい一点推定で判断を代替してはいけません。

ロールバック計画は、3つの異なる質問に答える必要があります：新しいリクエストを旧設定にどう戻すか、実行中のタスクをどう停止または完了させるか、すでに発生した返金/メール送信などの効果をどう照合するか。プロンプトを元に戻しても、返金は取り消されません。進行中のタスクに無理やりモデルやツールのバージョンを変更すると、状態契約が破綻する可能性があります。タスクを候補バージョンにバインドすることを優先し、アップグレード、エージングアウト、復旧の戦略を明確にします。

成功率95%の根拠はどれほど強いか

リリース根拠には標本情報も必要です。同じ観測比率なら標本増で区間は狭まりますが、似たタスクの反復で独立性や群の網羅は保証されません。区間は万能な公開基準ではありません。 NIST: Wilson interval

$$\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}}$$

リリース後のクローズループ

事故を回帰テストに組み込む前に、失敗を説明するのに十分なバージョンと必要なトレースを保存し、個人情報や機密データに対して適切な処理を行います。実際のデータを長期評価セットに直接コピーすると、露出範囲が拡大する可能性があります。同じ失敗条件を保持する合成ケースを構築することができます。

有用な回帰テストは、「同じ質問をもう一度尋ねる」だけでなく、期待される結果と失敗の位置を記録する必要があります。例えば、跨テナントのチケットイベントは、エグゼキュータの拒否テストとエンドツーエンドのインジェクションテストに分割できます：前者は権限境界を検証し、後者はモデルが本来のタスクを正しく継続して完了しているかどうかを観察します。修正後に直接関連するテストを実行し、依存関係の影響に応じて回帰を補完し、リリース前に必須の証拠が現在の構成に属していることを再確認します。

チェックリストはシステムの変化に合わせて調整されます。無効化された重複チェックを削除し、理由を記録します。実際のギャップをカバーする新しいチェックを追加します。維持目標は、チェックボックスを増やすことではなく、証拠が生産環境での動作をよりよく予測できるようにすることです。