Helper CTO シリーズ 18｜AIがいつも同じ箇所を壊す：テストのないプロダクトはなぜ改修のたびに脆くなるのか

「決済を直すよう指示したら直ったのですが、今度はログインが壊れました。ログインを直すよう指示したら、決済がまた壊れました」。この往復が1回起きるたびに、注文を1日分よけいに失います。最後にはもう手を入れる勇気がなくなり、プロダクトは「動いてはいるが、誰も触ろうとしない」状態で止まります。指示の出し方が悪いのではなく、このプロダクトには「変更後に何を再確認すべきか」というリストがないだけです。以下の4つを、原因から補い方まで順に説明します。

Aを直したらBが壊れる：あなただけではありません

この現象には決まったパターンがあります。自分がどの段階にいるか照らし合わせてみてください。

• 第1段階：プロダクトは順調で、機能が次々と生まれ、どんな変更も速く進みます。
• 第2段階：「Aを直したらBが壊れる」が起き始めます。単なる運の悪さだと思っています。
• 第3段階：変更するたびに、すべての機能を自分で手動でクリックして確認しなければならず、その時間がどんどん長くなります。
• 第4段階：とうとう変更をやめてしまいます。プロダクトはまだ動きますが、誰も触ろうとしません。

これはAI特有の問題ではなく、テストのないコードはいずれこの状態に行き着きます。ただAIはそこに到達する速度を速めているだけです。AIがコードを生み出す速度は、誰かがそれを確認する速度をはるかに超えています。デモができることと本番で使えることは別の記事では、よく欠けている5つのことを取り上げました。この記事では、その中でも改修を最も怖くさせる1つに絞って説明します。

なぜこうなるのか：「変更後に再確認すべきこと」のリストがない

あるレストランが1つの料理を変更した場面を想像してください。厨房は、新しい作り方が既存の食材と合っているか、提供の順番が変わらないか、テイクアウトの容器に収まるかを確認する必要があります。これが「変更後に確認すべきこと」のリストです。コードも同じですが、つながりがはるかに見えにくいという違いがあります。

• 決済とログインは一見無関係に見えますが、実は「ユーザーが誰であるかを確認する」同じ処理を共有していることがあります。
• AIが決済を直すときにその共有部分を変更すると、ログインが壊れます。しかもAIはそのことにまったく気づきません。
• 「ここを直したら、ログインもまだ開けるか確認する」ことを、誰もAIに伝えていないからです。
• 当初どの部分同士がつながっていたかは、過去のいくつかの会話の中にしか存在せず、会話を閉じれば消えてしまいます。

テストとはそのリストのことです。機械が代わりに実行してくれるだけです

「自動化テスト」は技術的に聞こえますが、実際にはそのリストをプログラムとして書き起こしたものです。1件ずつが「これを行えば、この結果になるはずだ」という内容になっています。

変更のたびに、機械がリスト全体を実行し、おかしい箇所があればすぐに知らせてくれます。壊れた箇所は公開前に見つかり、お客様から指摘されることはありません。

まず損失に直結する経路から始める

すべての機能に一度にテストを書く必要はありません。それでは費用がかかりすぎますし、いつまでも終わりません。まず「どの経路が壊れたら、直接損失につながるか」を問い、次の順番で補っていきます。

1. 損失に直結する主要フロー：登録から決済まで、注文から出荷まで、ログインからレポート閲覧まで、1本ずつ最初から最後まで確認します。
2. 過去に壊れたことがある箇所：一度壊れた箇所は再び壊れる可能性が高いので、先にテストを補います。
3. 外部サービスと接続している箇所：決済や、SMSは、相手側の変更によって突然問題が起きやすい部分です。
4. それ以外は後回しにする：急がない機能が壊れても見た目が悪くなる程度で、今日の売上が減るわけではありません。

AIツールに「この機能のテストを書いて」と頼めば、速く書いてくれます。しかし、それが重要なことをテストしているかどうかは、誰かが判断する必要があります。

テストを補ってくれる人がいないとき

テストを補う上で一番難しいのは、書くことではなく判断することです。

• どの経路が最も重要か：これはあなたのビジネスを理解していないと分からず、コードが分かるだけではできません。
• 正しい点をテストできているか：一見すべて緑（成功）に見えても、実際には重要でない箇所ばかりテストしていることがあります。
• 失敗したときにどちらが悪いか：テストの書き方が間違っているのか、プログラムが本当に壊れているのか。ここを見誤ると、警告を無視する習慣がついてしまいます。
• いつ止めるべきか：テストにも保守が必要です。十分な量まで補えばよく、多ければ多いほど良いわけではありません。

こうした判断ができる人がいなければ、プロダクトは「変更するたびに脆くなる」状態のまま止まり、あるとき壊れた箇所がたまたま損失に直結する経路だった、ということになります。これはVibe Codingと本当のシステムアーキテクチャの差の記事の核心でもあります。AIは機能を生み出せますが、責任は生み出せません。テストが整うまでの間は、少なくともサイトが落ちたときに誰かが真っ先に気づける状態にしておきましょう。それはテストより安価な最初の保険です。

Nerdtechnicがその経路をどう守るか

• まず損失に直結する経路を守る：引き継ぎ後はまず主要フローにテストを補い、その後に開発の継続を検討します。
• 同じチームが最初から最後まで担当する：テストを書いた人がそのまま保守も担当し、書いたら終わりということはありません。
• エラーには対応する人がいます：エラーを報告いただくと、2営業日以内に評価をご回答します。
• 記録はすべてお渡しします：テストとドキュメントはすべてあなたのものになり、担当者が変わっても理解できます。

テストはエンジニアに提出する宿題ではなく、あなたが安心して前に進んで改修し続けるための保険です。

AIが壊した箇所は、代わりに「ここは壊してはいけない」と覚えておく人が必要です。Nerdtechnic（恩梯科技）はHelper CTOとしてあなたのAIプロダクトを引き継ぎ、まず損失に直結する経路を守ったうえで開発を続けます。最初のステップは60分のシステム健診です。コードさえ見せていただければよく、本番環境のアカウントやパスワードは不要で、3～5営業日で読んで分かる1枚のレポートをお渡しします。あなたのプロダクトがすでに「動くけれど誰も触れない」状態に入っているなら、まずどこに触れてはいけないのかを一緒に確認しましょう：Helper CTO：システム保守プラン。