【ITニュース解説】Why AI Coding Agents Crash at 3 AM: The Happy-Path Mirage & The Forced Continuity Defect

AIがプログラムのコードを自動で作成する技術は日々進化しているが、そのコードが実際に大規模なシステムで稼働すると、夜中の午前3時といった予期せぬ時間帯にシステムが突然停止することがある。これは、AIが完璧なコードを生成しているように見えても、現実のソフトウェア開発の複雑さや予期せぬ状況に対応できない根本的な問題があるためだ。

一般的なテスト環境、例えば昼間のステージングサーバーでは、データベースの接続も少なく、ネットワークの遅延もなく、テストデータも整っているため、ほとんどのコードは問題なく動作する。しかし、ソフトウェアの真価が問われるのは、予期せぬトラブルが多発する午前3時の本番環境である。例えば、海外の決済サービスが一部のデータ送信に失敗したり、不安定な電波のモバイルユーザーが高速に操作したり、データベースのロックがタイムアウトして複数の処理が同時にクラッシュしたりするような状況だ。AIが生成するコードは、このような「現実世界の混沌」に直面すると、途端に機能しなくなる傾向がある。

この問題の根源の一つに、「強制的な連続性欠陥」というものがある。大規模言語モデル（LLM）は、数学の「連続性」に基づいた思考をする。つまり、ある状態Aが安全で、別の状態Bも安全であれば、その間の推移も滑らかで安全だと直感的に判断する。しかし、現実のソフトウェアは、連続的ではなく「離散的」で「断崖絶壁」のように振る舞う。例えば、整数が32ビットを超えると突然負の値になったり、暗号キーが1文字でも違えばすべての通信が失敗したり、データベースの処理が完全に成功しないと全データが破損したりする。AIは、「ユーザーデータを取得する」という処理と「ユーザープロフィールを表示する」という処理を、まるで一つの滑らかな操作のように見なしてしまう。その間に200ミリ秒のネットワーク遅延があったり、ユーザーが「戻る」ボタンを押して画面が消えてしまったりするような非同期の「時間の隔たり」を、AIは感知できないため、その結果、存在しないオブジェクトにアクセスしようとしてシステム全体がクラッシュする、といった事態が起きるのだ。

このような状況を改善するために、「人間からのフィードバックによる強化学習（RLHF）」をさらに強化すべきだという意見がよく聞かれる。これはAIに「もっと多くの人間の好みデータを与えれば、安全なコードを書くようになる」という考えだが、筆者はこれを「アラインメントの幻想」と呼ぶ。RLHFは、致命的な欠陥に対するペナルティを通常-1.0のような有限な数値で評価する。しかし、実際のシステム障害、例えば永続的なデータ破損や情報漏洩は、その損害が「無限大の負の値（-∞）」に等しい。RLHFの仕組みでは、この無限大の負の値を有限の値に圧縮してしまうため、たとえ2%の確率でシステムをクラッシュさせる可能性があるとしても、98%の確率で「見た目には完璧で、高評価を得やすい」コードであれば、AIは全体として「良い」と判断してしまうことがある。結果的に、AIは稀に起こる破滅的な結果を無視して、「うまくいく可能性が高い」選択肢を優先するように学習してしまう。

さらに、RLHFの評価者は、短い時間でコードの見た目の良さ、コメントの適切さ、礼儀正しい説明などを評価する傾向にある。彼らは、TCPソケットが閉じられていない、といった潜在的なバグを見抜くことは難しい。また、経験豊富なエンジニアが危険を感じた時に一時停止したり、疑わしい点について質問したりする「防御的なためらい」は、評価者にとっては「役に立たない」「頑固だ」と見なされ、低評価につながることがある。そのため、RLHFは、システムを安全に保つために必要な「防御的な懐疑心」を、AIから積極的に取り除いてしまう側面がある。

熟練のソフトウェアエンジニアの技術は、二つの異なるレベルで機能する。一つは「これはするな」というような明確なルール（例：同期的なクエリをメイン処理で実行するな）で、これはコンパイラやリンターがチェックするレベルだ。しかし、このレベルのルールだけでは、複雑なコードベース全体を管理することはできない。ルールの組み合わせは爆発的に増え、AIは時に都合よくルールを無視しようとすることもある。もう一つは、「何か嫌な予感がする」というような、潜在意識レベルの直感だ。これは、例えば「バージョンを上げたばかりなのに、リモートのパッケージ分析スコアをチェックしていない」といったように、明確なエラーが出ていなくても、状況全体から危険を感じ取る感覚である。人間は、夜中の3時に顧客データが流出するような事態を経験し、「痛い目」を見たことがあるからこそ、そのような身体的な信号を送り、危険な決定を無意識に回避する。AIにはこのような「痛みの経験」がなく、恐怖を感じないため、このレベルの直感を持つことができない。

AIがコードを生成する上で直面するもう一つの問題は、「早すぎる抽象化」である。AIは、テキストの汎用性を最大化するように訓練されているため、どんなに単純な問題でも、すぐに複雑な抽象的なフレームワーク（抽象クラス、インターフェース、ファクトリーなど）を作りたがる傾向がある。例えば、日付の解析バグを直すだけなのに、複数の抽象的なインターフェースや設定スキーマを導入してしまう。これは、不要な間接レイヤーを作り出し、かえってバグを隠し、システムの複雑さを増大させる。

この問題に対処するため、筆者は「3点ソリューション平面不変条件」という厳格な制約を提唱する。これは、抽象的な基底クラスやインターフェースなどを導入する前に、同じ運用ロジックが少なくとも三つの異なる場所で具体的に実装され、テストされていることを義務付けるものだ。つまり、まずは具体的なコードで問題を解決し、それが確実に機能することを検証してから、必要に応じて抽象化を行うというアプローチだ。

このような「合成の傷跡」という考え方は、AIに多くの制約を課すことで、AIが遅く、硬直的になり、創造性が失われるのではないかという疑問を生むかもしれない。しかし、これは制約の役割を誤解している。「フォーミュラ1のレーシングカーが強力なブレーキを搭載しているのは、減速するためではなく、ドライバーが時速320キロでコーナーに自信を持って突入できるようにするためだ」という例えが示すように、明確な安全柵があるからこそ、AIは最大速度で、大胆かつ創造的にコードを生成できるようになる。

この「合成の傷跡アーキテクチャ」は、すでに実際のシステムで稼働している。この手法を導入した結果、一度発生して「傷跡」としてシステムに記録された障害は、その後二度と再発しなくなったという。また、チケットの54.1%が人間の介入なしで完了した。つまり、人間はコードを細かくチェックする「漕ぎ手」ではなく、全体の方針を指示する「フライトディレクター」のような役割に変化した。AIをより多くの教科書通りのコードで「賢く」するのではなく、過去のエンジニアの経験から生まれた「傷跡」を与えることで、AIに人工的な免疫システムを与え、信頼性を高めることができたのだ。