AI研究
Helper CTO シリーズ 18｜AIがいつも同じ箇所を壊す：テストのないプロダクトはなぜ改修のたびに脆くなるのか
AIにAを直させるとBが壊れ、Bを直すとAがまた壊れ、プロダクトは「動くけれど誰も触れない」状態になります。本記事は非技術者向けに、原因は「変更後に再確認すべきこと」のリストがないことだと説明し、自動化テストはそのリストの機械版であること、そして損失に直結する経路から補っていくべきことを伝えます。
「一応できて、お客さんに試してもらっても評判はいいです。本番公開するなら、あとどんな機能を足せばいいですか。」AIツールでプロトタイプを作ったオーナーの十人中九人が、最初にこう聞きます。答えは意外に思われることが多いです。まだ機能を足さないでください。プロトタイプが壊れても作り直せますが、本番の製品には実際の顧客の注文が乗っており、一度壊れたら本当の損失になります。機能が足りないのではなく、「誰かが長期的に責任を持つ」という土台が欠けているのです。保守性は4つの要素に分解でき、本記事ではその補い方を解説します。
プロトタイプと製品では、目指すものが違う
プロトタイプの目的はアイデアの検証で、作り方はどうであっても構いません。本番の製品は、見ていないときにも正常に動く必要があります。目的が変われば、評価基準も変わります。
- プロトタイプは「動くか」を問い、製品は「壊れたとき誰が最初に気づくか」を問います。
- プロトタイプは「どれだけ速く作れるか」を問い、製品は「半年後もまだ手を入れられるか」を問います。
- プロトタイプは「自分が理解できるか」を問い、製品は「別の人が引き継げるか」を問います。
- プロトタイプは「作れるか」を問い、製品は「放っておいても安心か」を問います。
プロトタイプの作り方のまま機能を足し続けると、機能が増えるほど誰も手を出せなくなり、最後にはAIとの対話履歴だけが内容を理解できる状態になります。デモができることと本番公開できることは違うの記事で挙げた5つの項目も、根っこは同じ問題です。
保守性とは何か：4つの要素
平たく言えば、このシステムを長期的に人が世話できるかどうかです。4つとも自分に問いかけてみてください。
| 4つの要素 | 自分への問い方 | なければどうなるか |
|---|---|---|
| 理解できる | 関わったことがない人がコードを開いて、何をしているか把握するまでどれくらいかかるか | 担当者が変わるたびに一から評価し直すことになる |
| 変更できる | ある箇所を直したとき、別の箇所が壊れないか | 誰も手を出せなくなり、要望が滞留していく |
| 異常に気づける | 不具合が起きたとき、システムが先に知らせるか、顧客からの電話で先に気づくか | クレーム対応が唯一の監視手段になる |
| 作り直せる | 今日サーバーが壊れたら、どれくらいの時間で一式復旧できるか | 一度のトラブルで振り出しに戻る |
4つすべてを満たせば、システムは「作った人にしか分からないもの」から「適任者なら誰でも引き継げるもの」に変わります。
なぜ機能追加より先にこれを補うのか
機能はシステムの上に積み重なるものです。土台が不安定なら、積むほど危険になります。もっと現実的な理由もあります。保守性は後回しにするほど補うコストが高くなるのです。
- 機能がまだ少ないうちに構造とテストを補えば、影響範囲は小さく、リスクも低く済みます。
- 機能を1年積み上げてから補おうとすると、一箇所直すたびに10箇所に気を配る必要が出てきます。
- 誰も手を出せない段階まで放置すると、補うコストは丸ごと作り直すコストに近づきます。
- 土台を補わずに機能を足し続けることは、未来の自分のために穴を掘っているのと同じです。
AIがいつも同じ箇所を壊してしまうの記事は、この負債が積み上がった後の姿を描いています。
補う順番
4つを一度に終わらせる必要はありません。「壊れたときの代償」の大きさで順番を決めます。
- まずバックアップ：データベースとアップロードファイルを毎日バックアップし、別の場所に保管する。
- 次に作り直せるようにする：構築手順を書き出し、実際にその通りに一度やってみて、本当に構築できるか確認する。
- 次に壊れたら知らせるようにする：サイトが生きているか、エラーが記録されているか、サーバーのリソースは足りているか。
- 次にテストを補う：損失に直結する経路から始める——決済、ログイン、フォーム送信。
- 最後にコードを整理する：AIが生成したまま誰も使っていないものを取り除く。
原則は、まず「壊れても助かる」状態にし、次に「壊れにくい」状態にし、最後に「直しやすい」状態にすることです。これはVibe Codingと本物のシステム設計のギャップの記事の結論と同じで、差は機能の下に隠れています。
補った後、誰が世話をするか
「世話ができる状態」まで補っても、実際に世話をする人が必要です。必要なのは専任の人材ではなく、仕組みです。
- バックアップが本当に復元できるか、成功ログを見るだけでなく定期的に誰かが確認する。
- 監視アラートが鳴ったとき、内容を理解できて次の対応が分かる人がいる。
- セキュリティ更新を定期的に行う人がいて、問題が起きてから思い出すのではない。
- 小さな変更はその都度交渉し直さず、誰かがすぐに対応する。
- サーバーやサービスに問題が起きたら、1営業日以内に対応する人がいる。
これが私たちの言う「引き継ぎ」です。作り直すのではなく、保守できる状態に整えて、その後も継続して世話をすることです。
Nerdtechnic（恩梯科技）がAIプロトタイプを引き継ぐときの4つの約束
- まず製品を保守できる状態に整えてから機能追加を検討します。作り直しを急いで勧めることはしません。
- システム健診はコードが見えれば十分で、本番環境のアカウントやパスワードは不要です。
- 基本保守はNT$6,000／月から、月単位でのご請求で、いつでも解約できます。
- 引き継ぎ、保守、改善、継続開発を、同じチームが最初から最後まで担当します。
プロトタイプはアイデアを検証するもの、製品は長期運用するもの——その間をつなぐ一歩に付き合う相手がいたほうが、結局は安上がりです。
プロトタイプから本番の製品へ進むとき、足りていないのは多くの場合機能ではなく、長期的に責任を持つ人です。Nerdtechnic（恩梯科技）は Helper CTO として、こうしたシステムを引き継ぎ保守します——社内の技術責任者のような存在ですが、御社の正社員ではありません。最初のステップは60分のシステム健診です。コードさえ見せていただければよく、本番環境のアカウントやパスワードは不要で、3～5営業日以内に、4つの要素が今どこまで補われているかが分かる1ページのレポートをお渡しします。すでに実際の顧客が使っているプロトタイプで、それが持ちこたえられるか不安な場合は、まず一度測らせてください。Helper CTO：システム保守プラン
