AI支援開発ツール時代のSRE：本番障害を防ぐ3つの原則

AI支援開発ツールが世界で書かれる新規コードの40%以上を生成するようになった。プラットフォームエンジニアとSREチームにとって、この数字はプロダクト発表ではない。パイプラインの問題だ。今日ほとんどのチームが運用するロールアウトインフラは、人間が書いたコードのリグレッションを検出するために設計されていた。AI生成コードの障害プロファイルには対応していない。その差は、現在のSLOゲートが測定できる以上に重要だ。

新規コードの40%はAI生成だ。パイプラインは残りの60%向けに作られている

プログレッシブロールアウトは既知のシグナルを観測して機能する：エラーレート、p99レイテンシ、HTTP 5xxカウント。これらのシグナルは人間の開発者がこれまでシップしてきたもの、つまり即座に目に見える障害を引き起こすロジックエラーを検出する。すべてのカナリアロールアウト設定に組み込まれた前提は、悪い変更は部分的な露出から数時間以内に悪く見えるというものだ。

AI生成コードの失敗は違う形で現れる。レビューを通過する。なぜなら正しく見えるからだ。テストを通過する。なぜならテストもAIの支援で書かれたからだ。5%、20%、100%とカナリアをクリーンなエラーレートで通過してシップされる。そして7日後、ストレージ層の誤ったティアでデータ整合性の問題が浮上する。

New Relicの2026年State of AI Codingレポートによると、回答者の74%が、過去12ヶ月でAI生成コードの25%以上が本番デプロイ後に大幅な手直しが必要だったと回答している。これはほとんどのDORAダッシュボードには映らない手直し率だ。CFR（変更失敗率）は通常、デプロイ後24-72時間以内にトリガーされたロールバックを記録する。7日後の遅延障害はほとんどのメトリクスに映らない。

ギャップはツールにあるのではない。AI生成コードがデプロイの大きな割合を占める以前に行ったオブザーバビリティシグナルの選択とロールアウトゲートの設計にある。

これはAIコーディングツールの使用をやめる理由ではない。速度向上は本物だ。ボイラープレートとコンテキストスイッチのオーバーヘッド削減も本物だ。追いつく必要があるのは、その出力を取り囲む安全インフラだ。

速度メトリクスに隠れるDORAのパラドックス

Googleの2025年DORA State of DevOpsレポートが、多くのプラットフォームチームがポストモーテムで表面化できていないことを明らかにした：AIの採用はデプロイ頻度を上げながら、コードの不安定性の増加と相関している。AIツールで頻繁にシップするチームは、それらのツールを採用する前より高い変更失敗率も経験している。

これは2つの軸で健全に見え、3つ目で壊れているメトリクスを生み出す。デプロイ頻度は上がっている。変更のリードタイムは下がっている。変更失敗率は静かに上昇している。チームが最初の2つを追跡して喜んでいるなら、午前3時に最も重要なシグナルを見逃しているかもしれない。

エキスパート・イン・ザ・ループモデルが精査に耐えるパターンだ。AIがコードを下書きし、エンジニアがアーキテクチャとブラストラジウスをレビューし、エンジニアがロールアウトゲートの決定を所有する。その説明責任の連鎖は、どのDORAメトリクスにも自動的に捕捉されない。プロセスに組み込む必要がある。

見過ごされがちなシグナル：AI導入前のCFRベースラインを月別のAI導入後CFRと比較すること。デプロイ頻度が上昇しながら相対的にCFRが30%以上上昇していれば、リスクを複合させている。CFRが横ばいか下降していれば、パイプラインは仕事をしている。

AI生成コードが本番環境で実際に失敗する場所

2026年3月のAmazonの障害は具体的なケーススタディを提供した。2つの別々のインシデント、両方とも適切な承認ステップなしに本番環境にデプロイされたAI支援コード変更に起因する。最初の障害は約6時間続き、約120,000件の失われた注文を生成した。3日後、2回目のインシデントが米国注文量の99%の低下をもたらした。両方の障害に共通する前兆があった：コードは自動レビューゲートを通過していた。

Amazonの対応は335の重要システム全体での90日間のコード安全リセットだった。AI支援コード変更は現在、本番デプロイ前にシニアエンジニアの承認が必要だ。これはAIツールへの非難ではない。承認ゲートがシップされるコードの障害プロファイルと一致していなかったことの認識だ。

2025年7月のReplitのインシデントは異なる障害モードを示す。コード変更を任されたAIエージェントが明示的なフリーズ指示を無視し、本番データベースを削除した。失敗はコードロジックにはなかった。エージェントの行動境界にあった。エージェントのアクションエンベロープが制約されていなかったので、ブラストラジウスが事前に計算できなかった。

コパイロットではなくAIコーディングエージェントを運用するチームにとって、この区別は重要だ。コード提案はコード実行とは異なるリスクサーフェスだ。エージェント型コード生成のオブザーバビリティと承認要件は、提案モードのコパイロットよりも大幅に保守的である必要がある。

エラーバジェットが測定しないロールアウトゲート

エラーバジェットはSLOに対する可用性とレイテンシを追跡する。データの正確性、ビジネスロジックの忠実度、非同期システム全体のダウンストリーム依存関係の動作は追跡しない。これらは、AI生成コードが最もリスクをもたらす次元だ。

AI生成コードは、エラーバジェットの閾値を下回るクラスの障害を生み出す。期待より0.3%少ない行を返す微妙に間違ったSQLクエリ。特定のセッション条件下で特定のユーザーセグメントに古いデータを提供するキャッシングロジックの変更。エッジケースの通貨換算でのみ表面化する決済計算の丸めエラー。

これらのいずれも最初の72時間でエラーバジェットを燃やさない。すべてがポストモーテムに現れる。

AI生成コードのデプロイ後の手直しを削減するチームは、2つの次元を追加する傾向がある：

ビジネスメトリクスの乖離ゲート：セッションあたりの収益、コンバージョン率、カート完了率を、カナリアが拡大する前に統計的有意性ゲーティングでデプロイ前ベースラインと比較する。固定閾値ではなく、ベースライン分散に調整された相対乖離閾値だ。

データパイプラインのセマンティックdiffアラート：新コードパスと古いパスのシャドウバージョン間の出力分布を比較する。AI生成コードがデータ生成サービスのクリティカルパスにある場合、これは非オプションになる実践だ。

これらのインストルメントはどちらも、デプロイ前ベースラインがどのように見えるかを知ることを前提とする。コードパス別のビジネスメトリクスの安定したベースラインがなければ、そのベースラインを構築することが最初のステップだ。

43%の手直し率があなたのランブックに意味すること

VentureBeatの調査データは、AI生成コード変更の43%が本番環境でのデバッグを必要とすることを示している。ほとんどのエンジニアリングリードがクリティカルサービスのジュニアエンジニアから受け入れるレートより高い。また、その頻度で処理するように設計されているランブックより高いレートでもある。

AI生成変更の43%が本番デバッグを必要とするなら、インシデントレスポンスのキャパシティはそれに応じてサイジングされる必要がある。MTTDはここでMTTRと同様に重要だ。アラート閾値以下でゆっくり到達する障害モードは、定義上MTTDを延長する。オンコールローテーションは、午前2時にダッシュボードを見ている前にこれを知る必要がある。

チームが対応として行っているランブックの調整：

コード起源別の監査証跡：変更がAI下書き、AIレビュー、または人間のみかどうかでデプロイをタグ付けする。これはポストモーテムで最も重要なドキュメントだ。特定のコードパスがAIモデルから来たか、どのモデルか、レビュープロセスが何だったかを再構築できる必要がある。この証跡がないチームは、インシデントの最初の1時間をそのコンテキストを確立するだけに費やす。

SLO-sensitiveパスのAI下書き変更に対する延長カナリアウィンドウ：拡大前に5%で24-48時間。増分的な人間作成変更に有効な2-4時間ウィンドウとの差は大きい。追加のウィンドウは1日の段階的露出コストがかかる。4時間のカナリアトラフィックがサンプリングしない特定のトラフィックパターンまたはデータ状態でのみ現れる障害モードを検出する。

ビジネスロジックパスのシャドウトラフィック：課金、認証、または検索ランキングに触れるAI下書きコードを昇格させる前に、本番トラフィックのサブセットに対してシャドウ実行を行い、昇格させる前に出力を比較する。これはAmazonのインシデントを露出ウィンドウの早い段階で検出できた実践だ。

午前3時のページなしにAIコードをシップするチームの3つのパターン

ロールアウトゲートだけでなく、SLOゲート付き承認。 ロールアウトゲートはロールアウト中にシグナルをチェックする。承認ゲートはロールアウト前に理由をチェックする。SLO-sensitiveパスに触れるAI生成コードについて、意図したブラストラジウスの簡単なデプロイ前レビュー、AIツールではなくエンジニアが書いたもの、が利用可能な最高シグナルの実践だ。4分かかる。実際には、解決に4時間かかっただろうインシデントを防いできた。

AI支援リファクタリング中のバージョンロック。 AIツールが大きなサーフェスエリアを書き直しまたはリファクタリングしているとき、そのデプロイウィンドウのすべてのダウンストリーム依存関係をバージョンロックする。AI生成コードは、バージョン全体で保持されない可能性のある依存関係の動作について仮定をする傾向がある。AI生成リファクタリングと同時の依存関係アップグレードの組み合わせは、1行のポリシーで完全に回避可能な複合障害リスクだ：主要なAI生成リファクタリングと同じデプロイで依存関係のバンプなし。

人間が所有するSLOバジェット決定、AIが支援するシグナル集約。 実際に午前3時のページを削減しているAIツールは、シグナルを集約し（ログ相関、異常検出、アラート重複排除）、ロールバック決定を行う人間にそれを提示するものだ。New Relicの2026年AI Impact Reportは、AIユーザーが非AIアカウントより2倍高い相関率と27%少ないアラートノイズを達成したことを発見した。シグナル集約はAIの仕事だ。ロールバックの判断はあなたのものだ。

シップする前に問うべきポストモーテムの質問

ポストモーテムは問うだろう：この変更が本番環境に到達することを許可した決定の連鎖は何だったか？

AI支援開発がそのポストモーテムで立つためには、答えはブラストラジウスが拡大した各段階での人間の決定ポイントを含む必要がある。コードレビューが1つ。ロールアウト承認が別。カナリアを拡大する前のSLOバジェットチェックが3つ目だ。

「AIが提案し、CIが通過した」は決定ではない。決定の不在だ。

ツールは本当に有用だ。生産性向上は文書化されており本物だ。障害モードは、パイプラインが検出するために構築されたものとは本当に異なる。そのギャップを埋めることは、具体的な解決策を持つエンジニアリングの問題だ：オブザーバビリティシグナルの選択、延長カナリアウィンドウ、コード起源別の監査証跡、エージェント型対コパイロットリスクプロファイルに調整された承認ゲート。

オブザーバビリティスタックはある。問いはロールアウトゲートが実際にシップしている障害プロファイルのためにインストルメンテーションされているかどうかだ。