ほとんどのエンジニアリングチームはデプロイチェックリストを持っている。環境変数、データベースマイグレーション、ロールバック手順、APIへのスモークテストをカバーしている。そのチェックリストはソフトウェアには正しい。AIパイプラインには不完全だ。
以下の6項目は標準チェックリストに載っていない。それぞれが特定の障害モードに対応している。各障害モードは、既存のプロセスで十分だと思い込んでいたチームで実際の本番インシデントを引き起こしている。
AI固有の6つのチェックリスト項目
1. プロンプトバージョンのロック
防ぐもの: 環境間のプロンプトドリフト。
プロンプトはコードだ。バージョンハッシュまたはタグ付きリリースに固定されていない場合、ステージングでの変更が通常のデプロイ時に本番へサイレントに伝播する可能性がある。障害モード：対応するスキーマ更新なしに出力フォーマットが変わり、下流のパーサーが壊れ、エラーが実際の原因から3ステップ離れた場所で表面化する。
チェックリスト項目：本番のプロンプトバージョンハッシュがステージングでテストしたバージョンと一致することを確認する。乖離している場合はデプロイを失敗させる。
2. 検索スモークテスト
防ぐもの: インデックスレベルでのサイレントな検索失敗。
検索システムは結果を返しても、正しい結果を返さない場合がある。ベクターインデックスがスキーマ変更、埋め込み次元の不一致、または古いドキュメントセットで再構築された場合、クエリは解決されるが回答は間違っている。障害モード：システムは正常に見えるが、誰かが気づくまでの48時間、ユーザーは自信を持って間違った回答を受け取る。
チェックリスト項目：トラフィックが有効になる前に、既知の回答を持つ3つのクエリを本番インデックスに対して実行する。期待するドキュメントIDに対して完全一致またはしきい値一致を要求する。これは以前の投稿で取り上げた検索リグレッションプローブとは異なる――これはトラフィック前のゲートであり、リグレッションスイートではない。
3. フォールバックパスの検証
防ぐもの: プライマリモデルまたは検索レイヤーが利用不可の場合のサイレント障害。
すべてのAIパイプラインにはフォールバックが必要だ：シンプルなモデル、キャッシュされたレスポンス、またはグレースフルデグラデーションメッセージ。これを省略した場合の障害モード：プライマリパスがダウンし、フォールバックは本番で一度も実行されたことがなく、フォールバックルートにAPIキーの設定ミスや20秒ではなく2秒に設定されたタイムアウトがあることが判明する。
チェックリスト項目：プライマリトラフィックを有効にする前に、本番でフォールバックパスを手動でトリガーする。許容レイテンシ内で有効なレスポンスが返ることを確認する。
4. 出力スキーマバリデーション
防ぐもの: 不正な形式のモデル出力が下流のコンシューマーを壊すこと。
モデルは常に期待通りのものを返すわけではない。JSONフィールドが欠落する。文字列フィールドが整数を返す。障害モード：モデル出力を消費する下流サービスが未処理の例外をスローし、エラーがAI出力エラーではなく汎用の500としてログに記録され、追跡が困難になる。
チェックリスト項目：ライブトラフィックをルーティングする前に、本番で5つの標準的な入力に対してモデルを実行し、宣言されたスキーマに対して出力を検証する。寛容なバリデーターではなく、厳格なバリデーターを使用する。
5. 信頼度しきい値の確認
防ぐもの: ガードなしで低信頼度の出力がユーザーに届くこと。
ほとんどのパイプラインは開発中に信頼度しきい値を設定し、デプロイ後に生き残っているかを確認しない。環境の違い、モデルバージョンの変更、またはインデックスの更新によってスコア分布がシフトする可能性がある。障害モード：ステージングで出力の15%をフィルタリングしていたしきい値が本番では2%しかフィルタリングせず、意図した割合より高い率で低品質なレスポンスがユーザーに届く。
チェックリスト項目：デプロイ直後に20件の本番リクエストをサンプリングする。信頼度スコアの分布が許容誤差内でステージングの期待範囲と一致することを確認する。
6. アラートルーティングの確認
防ぐもの: AI固有のエラーが誤ったチームまたはどのチームにもルーティングされずに検出されないこと。
AIパイプラインは、標準的なアプリケーション監視が正しく分類しない障害シグナルを生成する。検索ミス、トークン制限超過、モデルタイムアウトエラーは汎用エラーバケットに入ることが多い。障害モード：アラートが発火しなかったか、誰も監視していないキューにアラートが発火したため、AI固有の劣化が何時間も続く。
チェックリスト項目：AI固有のエラークラス――検索失敗、スキーマバリデーション失敗、信頼度しきい値超過、モデルタイムアウト――それぞれに名前付きオーナーとテスト済みのアラートパスがあることを確認する。本番稼働前にテストアラートを送信する。
既存のCI/CDパイプラインへの統合
これらの項目はどれも新しいツールを必要としない。新しいステップが必要なだけだ。
既存のパイプラインにデプロイ後の検証ステージを追加する。このステージはインフラが稼働した後、トラフィックが有効になる前に実行される。上記の6つのチェックをスクリプトまたはテストケースとして実行する。いずれかのチェックが失敗した場合、パイプラインは停止してロールバックする。
実装パターン：
- プロンプトバージョンのロック: シェルスクリプトでの1行のハッシュ比較。
- 検索スモークテスト: ライブインデックスにクエリを実行してドキュメントIDをアサートするPythonスクリプト。
- フォールバックパスの検証: タイムアウトアサーション付きのフォールバックエンドポイントへのHTTPコール。
- 出力スキーマバリデーション: ライブモデル出力に対して実行するJSONスキーマバリデーター。
- 信頼度しきい値の確認: スコア分布をログに記録し、許容誤差外で失敗するサンプリングスクリプト。
- アラートルーティングの確認: アラートシステムに発火するテストイベントと手動確認ステップ。
追加されるパイプライン時間の合計：モデルレイテンシによって3〜8分。最初の本番インシデントを引き起こす障害モードを検出するための合理的なトレードオフだ。
このステップを省略するチームは、ロジックに異議があるから省略しているわけではない。最初のデプロイ前に誰もチェックリストを書かなかったから省略している。最初のデプロイ前に書いておくこと。