AIによる技術的負債がプラットフォームの信頼性を壊す

AIによる技術的負債がプラットフォームの信頼性を壊す

AIによる技術的負債は、コードレビューをすり抜けて本番環境に侵入する。GitHub Copilot、Cursor、Devinといったツールで生成されたコードは動作するように見えて、境界条件やカスケード障害への耐性が欠如していることが多い。

動くコードと本番で持ちこたえるコードは別物だ。AIは「今この関数が動くか」を最適化するが、「6ヶ月後に別チームが修正する際に何が起きるか」は考慮しない。

AIが生成したコードは動くが本番で壊れる

午前3時のPagerDutyアラート。ダッシュボードには赤いグラフが広がっている。前日マージしたAI生成のPRを見ながら、「なぜこれを信頼したのか」と自問する。

AIコード生成ツールは開発速度を確かに上げる。問題はスピードではなく、AIが生成するコードが孕む見えない技術的負債だ。テストは通過する。コードレビューも通過する。問題は本番の負荷とデータの組み合わせに直面した瞬間に露呈する。

技術的負債の正体：測定できないリスク

技術的負債はWard Cunninghamが1992年に定義した古い概念だ。しかしAIによる技術的負債は質的に異なる。

従来の技術的負債では、エンジニアが意図的にトレードオフを選ぶ。彼らはそのトレードオフを理解している。AIによる技術的負債では、生成モデルがトレードオフを理解しない。モデルは訓練データ内の「よく見えるコード」を出力するだけで、本番コンテキストとの整合性を問わない。

結果として生まれるのは、一貫性のないエラーハンドリング、テストカバレッジなしの複雑なロジック、暗黙の依存関係、そして隠れたパフォーマンスのボトルネックだ。

80人規模のエンジニアリングチームを持つあるSaaSスタートアップでは、AIアシストコーディング導入後の6ヶ月間で変更失敗率が1.2%から4.7%に上昇した。DORAメトリクスで「高パフォーマー」から「中パフォーマー」への転落だ。これは偶然ではない。

SLOバジェットが溶ける本当の理由

SLOエラーバジェットが予想より早く枯渇するとき、原因の多くはAI生成コードの負債にある。

典型的なシナリオを見てみよう。AIがAPIクライアントを生成し、リトライロジックが粗雑なまま本番に入る。下流サービスで一時的な遅延が発生すると、粗雑なリトライが雪崩状の過負荷を引き起こす。p99レイテンシが200msを超え、SLOバジェットが20分で溶ける。

問題はコード行数ではなく境界条件の処理だ。AIは「ハッピーパス」は得意だが、「カスケード障害」は苦手だ。エラーバジェットが月の半ばで枯渇したなら、まずAI生成PRのマージ履歴を確認せよ。相関関係は偶然ではないことが多い。

ロールバックコストを正直に計算する

手動ロールバックのコストを計算したことがあるか。

即時revertは5から15分を要し、部分的なデータ不整合リスクをはらむ。段階的ロールバックは30から60分かかるが、ユーザー影響を最小化できる。ホットフィックスデプロイは45から90分を要し、新しいリスクを導入する可能性がある。

AI生成コードのインシデントでは「即時revert」が使えないケースが増えている。AIが生成したマイグレーション、スキーマ変更、非同期ジョブが絡むからだ。ロールバック不能なコードをshipするのは、退路を断って戦場に進むことと同義だ。

SLOゲート付きロールアウトはこの問題を軽減する。カナリアが5%のトラフィックでSLO違反を引き起こしたなら、自動ロールバックがトリガーされる前にインシデントを止められる。ブラストラディウスを計算するのはshipする前だ。

AIコードの負債を可視化するパターン

負債は見えなければ管理できない。以下のパターンを本番前パイプラインに組み込む。

第一に、AIコードタギングだ。PRテンプレートにAI生成コードを明示するチェックボックスを設け、エラーハンドリングと境界条件のレビューを必須化する。これだけで可視性が劇的に上がる。

第二に、静的解析の強化だ。AI生成コードは通常の静的解析では不十分で、Cyclomatic Complexityのしきい値を下げ、AI PRに対してより厳格なルールを適用する必要がある。

第三に、SLO相関分析だ。デプロイイベントをSLOメトリクスと相関させるダッシュボードを構築し、AI生成PRのマージ後24時間のエラーバジェット消費率を追跡する。パターンが見えれば、優先度をつけた対処が可能になる。

予防よりも検知：監視戦略を立て直す

「AIコードを書かせなければいい」は解ではない。現実的な解は早期検知だ。

AI生成コードは本番でのみ発症する障害パターンを持つ。ユニットテストが通り、ステージングが通り、本番で落ちる。負荷パターン、データ分布、依存サービスの挙動が本番でしか再現しないからだ。

検知レイヤーを3段階に分ける。デプロイ直後の最初の30分はエラーレートのp95とp99のトレース、レイテンシの異常検知、新規エラータイプの出現を監視する。24時間以内はSLOエラーバジェット消費率の加速、依存サービスへの負荷パターン変化、データベースクエリプランの劣化に着目する。1から2週間にかけてはChange Failure RateのトレンドとMTTR（平均復旧時間）の変化を評価する。

これはSREとして当然の姿勢だ。ツールが生成したコードだからといって、監視の目を緩める理由にはならない。

本番で生き残るためのデプロイゲート

技術的負債を完全に排除することは不可能だ。しかしゲートを設けてコントロールすることはできる。

SLOゲート付きロールアウトの設計原則は3つある。第一に最小ブラストラディウス：最初の1から5%のユーザーで観測する。第二に自動判定：人間を待たずにSLO違反でロールバックする。第三に可観測性ファースト：ゲート判定に使うメトリクスはデプロイ前に動作確認する。

AIによる技術的負債は消えない。しかしゲートがあれば、本番での被害を局所化できる。ポストモーテムで「なぜこのコードが本番に到達したか」ではなく「なぜゲートが機能したか」を議論できるようになる。それが成熟したプラットフォームエンジニアリングの証だ。

インシデント対応の認知負荷を下げるツール

AIによる技術的負債への対処は技術的なパターンだけでは完結しない。インシデント対応の品質を支えるツール選択も同様に重要だ。