AIが生成した自動化スクリプト15本に共通のバグが発見された：別AIによる監査が明らかにした「モデルの盲点」
20歳の大学生が、Claude Codeを用いて運用している、メール監視、自動返信ドラフト、カレンダー登録、収益集計など、外部に副作用を持つ自動化スクリプト（sender）15本について、品質監査を実施した。このスクリプト群は、ChatGPT Plusに課金したことを機に、Codex CLI（GPT系）とGemini CLIという別系統のAIモデルに一斉に監査を依頼した結果、驚くべき共通点が見つかった。それは、15本すべてが「同じ3箇所」にバグを抱えていたという点である。個別のミスではなく、モデル共通の「書き癖」が原因であったと分析されている。
発見されたバグパターンは以下の3点である。一つ目は「non-atomicな read-modify-write (check-then-write race)」であり、複数のプロセスが同時に実行された際に、状態ファイル（STATE_FILE）の読み取りと書き込みが競合し、同じ処理が複数回実行されるリスク（例：招待メールの4重送信事故）がある。二つ目は「parse失敗のfail-open」であり、状態ファイルが破損した場合に空オブジェクトを返す処理（`catch { return {}; }`）が、破損を「未処理」と誤認させ、全件再送を引き起こす危険性がある。三つ目は「副作用失敗の握りつぶし」であり、通知や送信の失敗を`catch (_) {}`で処理することで、失敗が観測されず、再送もされないという問題がある。
筆者は、これらの共通のバグは、AIが「並行プロセスが同時に走る場合」「状態が破損している場合」「通知が落ちた場合」といった例外的な状況を、確率的に同じ優先度で省略する「モデルの盲点」であると指摘。この学びから、AIにコードを書かせる際は、必ず別系統のモデル（GPT ⇄ Claude ⇄ Gemini）にレビューを依頼し、また、外部副作用を持つコードには「並行実行時のテスト」を必須とすべきだと提言している。具体的な修正策として、`fs.openSync`の`wx`フラグを用いたアドバイザリーロック（advisory lock）を導入し、チェックと書き込みをロック内で行う手法が提案されている。
背景
AIによるコード生成は急速に進んでいるが、そのコードが実運用環境で予期せぬバグを抱えるリスクが指摘されている。特に、複数のプロセスが同時に動作する「並行処理」や、外部ファイルの状態が不安定な状況でのエラーハンドリングは、AIが陥りやすい盲点とされる。本記事は、実運用を通じてこの盲点を発見し、具体的な対策を提示した事例である。
重要用語解説
- non-atomicな read-modify-write (check-then-write race): 複数のプロセスが同時に状態ファイルを読み書きする際、読み取り（check）と書き込み（write）の間に競合が発生し、データが不整合になる状態。排他制御（ロック）が必要な典型的な並行処理バグ。
- fail-open / fail-closed: システムがエラーや破損に遭遇した際の挙動の設計指針。fail-openはエラー時にサービスを継続させるが、データ破損のリスクがある。fail-closedはエラー時に処理を停止させ、安全性を優先する。
- advisory lock: ファイルシステムレベルで実装される排他制御メカニズム。ファイルを開く際にロックをかけ、他のプロセスが同時にアクセスするのを防ぐことで、データの整合性を保つ。
- 影響: 本事例は、AIが生成したコードの信頼性検証における重要な知見を提供する。今後は、AIのコードレビュープロセスにおいて、単なる機能検証だけでなく、「並行処理」「エラーリカバリ」「例外状態」といった視点でのクロスチェック（別モデルによる監査）が必須となる。これにより、AI開発の品質保証基準が一段引き上げられると予想される。