AIコーディングで手間が増える――GoogleのSREが語る自動化の皮肉と生存戦略：「バグの優先順位」を決めない修正方法

生成AIの台頭でソフトウェア開発は容易になったが、システム全体の複雑性は増大し、運用は困難を極めている。Googleエンジニアディレクターが提唱する、ブラックボックス化したシステムに立ち向かう手法を解説する。

[TechTargetジャパン]

　「これは決して起こらないはず」。システム開発において、このような前提で記述されたソースコードが、後に想定外の障害を引き起こす要因になるケースがある。Googleのエンジニアディレクターで、同社サービスのSRE（サイト信頼性エンジニア）を務めるミシェル・ブラッシュ氏は、これを「ソースコードの中で最も恐ろしいものだ」と語る。

　システム要件や当時の前提に基づく「起こり得ない」という思い込みは、後の変更で容易に崩れ去る。前提が崩れたとき、システム全体がどう反応するかは予測不能だ。

　近年、LLM（大規模言語モデル）などの生成AIの普及によって、誰もが迅速にアプリケーションを構築し、ソースコードをリファクタリングできるようになった。開発が容易になることでソフトウェアの総量が爆発的に増加し、システム全体がかえって複雑になる「ジェボンズのパラドックス」が起きようとしている。

　このような状況では、企業のIT担当者は全体像を把握し切れないブラックボックス化されたシステムに対面しなければならない。“予測不能なカオス”と化すシステムで、IT担当者はどのようにして信頼性を確保すべきなのか。

自動化が進むと人間の仕事はより面倒になる

併せて読みたいお薦め記事

AIコーディングの実情

• 「AIで内製すれば安くなる」は半分しか正しくない
• AIがあればCOBOLエンジニアはもういらない？　それは”あり得ない”これだけの理由

　本稿は、サイト信頼性エンジニアリングのイベント「SREcon26 Americas」におけるブラッシュ氏のセッション「Taming the Unpredictable: Reliability in Chaos」の内容に基づいて、AI時代の新たなシステム運用手法を解説する。

　AIエージェントの導入が進むと、日常的なコーディングや運用作業の大半が自動化される。しかし、「自動化の皮肉」という概念が示す通り、人間の仕事は決して楽にはならない。ルール化できない高度な判断や自動化システム自体の監視、失敗時の修正といった、より複雑なタスクが人間に残されるからだ。

　ブラッシュ氏は、「システムがダウンした際に駆け付け、復旧させるのは依然として人間の役割だ」と指摘する。AIモデルは「なぜその答えを出したか説明できない『無意識的有能』な存在」になり得る一方、人間は「自分が何を知らないかを理解できる存在」だ。複雑な境界線上で起きる問題を解決し、AIエージェントがカバーし切れない領域を直感と経験で補うためには、これまで以上にスキルの高いエンジニアの存在が不可欠だ。

バグの優先順位付けを捨て、AIエージェントで継続的に修復する

　システムが巨大化し、無数のAIエージェントがソースコードを生成するようになると、小さなミスが積み重なり、思いがけない障害を引き起こす「カオス」の状態に陥る。従来の人間によるコードレビューや、事後の根本原因分析だけでは、とても変化のスピードに追い付けない。

　そこでブラッシュ氏が提唱するのが、優先順位付けに基づくバグ修正からの脱却だ。従来の開発現場は「バグバックログ」（発見されたものの未修正のまま蓄積された不具合リスト）を抱え、限られた人員で「どのバグを直すべきか」を評価することに多大な手間をかけていた。

　ここでAIエージェントを利用すれば、ソースコード全体から「リトライ処理がない」「エラー処理が不適切」といった特定のアンチパターンを瞬時に見つけ出し、自動的に修正やテストの追加を実行できる。バグの重要度を議論する時間を省き、リスクになり得る箇所をAIエージェントに片っ端から修正させることで、システムの信頼性を底上げする。ブラッシュ氏は「バグバックログを管理しない世界」を理想形として掲げる。

「適応度関数」によるフィードバックループの構築

　予測不能なシステムを制御するには、詳細な運用手順書に頼るのではなく、実験と学習に基づくアプローチが必要になる。その中核となるのが「アーキテクチャの適応度関数（フィットネス関数）」だ。

　これは、システムが常に満たすべき要件を定義し、それを継続的に自動テストする仕組みだ。ブラッシュ氏が管轄するGoogleの仮想マシン（VM）サービス「Compute Engine」では、「クラスタを任意に追加／削除しても、システム全体に影響を与えない」という要件がある。これを保証するため、背後で常にクラスタの作成と削除を繰り返す自動化プロセスを走らせている。誰かがこの要件を破る変更を加えた瞬間、即座に検出できる仕組みが整っている。

　ある消費者向けデバイスベンダーは、「エンドユーザーの操作中にクラッシュしない」という要件を満たすため、画面のピクセルをランダムにタッチし続ける「ホッパー」と呼ばれるテスト装置を活用していた。これによって、人間が想定しない奇妙なバグをデプロイ前に発見できたという。

　このアプローチは、トラブル時の「汎用（はんよう）的な緩和策」にも応用できる。再起動や過去のバージョンへのロールバックといった一時的な復旧手段をシステム要件として組み込み、日常的にテストしておくことで、いざというときに確実に機能させることができる。

　AIエージェントの登場によって、ソフトウェアの構築プロセスは根本から変わりつつある。それに伴ってIT担当者の役割も、個別のソースコードを理解して修正する現場の作業から、システム全体を俯瞰（ふかん）して変化に耐え得るフィードバックループや安全装置を設計する「アーキテクト」にシフトしている。ブラッシュ氏は「SREにとって、今はかつてないほどエキサイティングな時代だ」と締めくくった。