自動テスト0件の現場でAIをフル活用する「狂気」の開発フロー

「自動テストが1件もない」。この言葉を聞いて、背筋が凍るエンジニアは少なくないはずだ。10年以上運用されているWebサービスにおいて、コードを一行書き換えるたびに「どこが壊れるか分からない」という恐怖と隣り合わせで開発を続けることは、まさに地雷原を裸足で歩くようなものだ。しかし、株式会社セレスのエンジニアチームが直面したのは、単なる技術的負債の放置ではなく、それを抱えたまま「開発速度を前期比2倍にする」という極めて野心的なミッションだった。

彼らが最初に行ったのは、現状の「検知力」の可視化である。以下の表は、彼らが直面していた当時の絶望的な環境を如実に物語っている。

この環境下で、彼らは「人の確認を増やす」という、いわゆる「守りの姿勢」を完全に捨てた。なぜなら、レビュー人員を増やせば並行稼働数は減り、開発速度は低下するからだ。彼らが選んだのは、AI（Claude Code）を主軸に据え、人間は「承認」というゲートキーパーに徹する、極めて攻撃的なフローへの転換だった。これは、テストコードを整えてからAIを導入するという「教科書的な正攻法」を、時間的制約のためにあえて無視するという、現場のシニアエンジニアとしての苦渋の決断であったと私は推察する。彼らは「壊したことを自動検知できない」という致命的な欠陥を、AIによる要件整理と試験仕様書の自動生成という「別のレイヤー」で補完しようと試みたのである。

彼らが構築したフローは、全15工程のうち、人間が介在する「承認」ポイントを6箇所に絞り込むという大胆なものだ。特筆すべきは、AIが書いたコードを人間が行単位で読む工程を完全に排除した点にある。これは、コードレビューの概念を「行の正しさ」から「要件との整合性」へとシフトさせることを意味する。しかし、ここで一つの技術的懸念が浮かび上がる。それは「要件自体が間違っていた場合、AIと人間が同じ方向に誤る」という構造的な脆弱性だ。

彼らはこのリスクを、ドキュメントの整備という泥臭い作業で埋めようとしている。READMEやDBスキーマ、ドメインマップなどをAIが参照可能な形式で整備し、AIに「文脈」を理解させる。このアプローチは、いわゆるRAG（検索拡張生成）の概念を開発プロセスに持ち込んだものと言える。しかし、運用には強制力がなく、あくまで努力義務であるという点に、現場のリアリティが垣間見える。実際に1ヶ月運用した結果、スピードは落ちなかったものの、トークン消費量という新たな壁に突き当たった。OpusやSonnetといった上位モデルを並行稼働させると、あっという間にトークン制限に達する。つまり、この開発フローのボトルネックは、もはや人間のレビュー能力ではなく、AIモデルの「実行コスト」と「契約プラン」に依存しているという皮肉な状況が生まれているのだ。

「事故は起きていないが、観測もできていない」。この言葉は、自動テストなき現場でAIを導入するすべてのエンジニアが抱える、拭い去れない不安の正体である。彼らは、指摘ゼロで通過するPRが皆無であることに救いを見出しているが、それはあくまで「AIが生成したコードの品質」に対する信頼であり、システム全体の整合性に対する保証ではない。我々エンジニアは、AIにコードを書かせることの快感に溺れるあまり、その背後にある「検知不能なバグ」という時限爆弾を忘れてはならない。

この事例は、単なる「AI導入の成功談」ではない。むしろ、技術的負債が極限まで積み上がった現場において、AIという強力なツールを「いかにして安全装置なしで使いこなすか」という、極めて現代的かつ危険な実験記録である。彼らが最後に提示した「壊したとき、何が反応するか」というチェックリストは、すべてのエンジニアが明日から自らのプロジェクトに対して行うべき、最も重要な診断である。自動テストが1件もない環境で、あなたは自分の書いたコードが本番環境で引き起こすかもしれない「沈黙の障害」を、どうやって検知するつもりだろうか？

AIは確かに開発速度を加速させる。しかし、それは「正しい方向への加速」を保証するものではない。むしろ、間違った方向へ猛スピードで突き進むリスクを増大させる可能性すらある。彼らがこれからE2Eテストを実装し、自動化の網を広げていく過程は、まさに「負債を返済しながら、同時にAIでレバレッジをかける」という、極めて高度な綱渡りである。読者諸氏に問いたい。あなたの現場にある「自動テストの欠如」は、単なる怠慢か、それとも戦略的なトレードオフか。もし後者であるならば、その欠落を埋めるための「AI以外の代替手段」を、あなたは論理的に説明できるだろうか？

明日から取るべきアクションは明確だ。まずは自チームの「検知力」を可視化すること。そして、AIに任せる範囲を「勘」ではなく「検知可能な範囲」に限定すること。AIを魔法の杖と勘違いしてはならない。AIは、あなたの現場の「負債の深さ」を、より鮮明に照らし出す鏡に過ぎないのだから。この実験的なフローが、最終的に「成功」と呼べる結果に結びつくのか、それとも「技術的負債の爆発」という結末を迎えるのか。その答えを出すのは、AIではなく、現場で泥をすすりながらコードを書き続ける我々エンジニアの「設計思想」そのものである。