「業務システムの開発を、AIを活用して短納期で作れるという会社に発注しました。確かに最初のリリースは速かったんです。ところが半年後、機能をひとつ追加しようとしたら、別の会社に見積もりを頼んでも『このコードは手を入れるのが難しい』と渋られる。結局、作った会社に言い値で頼むしかなく、当初の安さがどこかに消えました」——卸売業の会社で業務システムを管理している方から、こんな相談を受けました。「AIで速く安く」が、後になって「直すのに高くつく」に化ける。いま静かに増えている失敗のパターンです。
海外では、この問題を象徴する動きがありました。「AIが生成したコードを削除する」ことを専門にし、削った分量に応じて週1万ドルを請求するチームが登場したのです。彼らは10万行のプロジェクトを、機能はそのままに3万5千行まで削る、といった仕事を請け負います。皮肉なことに、その削除作業にもAIを使いますが、「非常に短い手綱で」慎重に扱うと明言しています。わざわざお金を払って「消してもらう」需要が生まれるほど、AIが吐き出したコードの後始末が深刻になっている、ということです。本記事では、発注者がAI活用の開発で見落としがちな「後で払うコスト」を整理します。
「動く」と「保守できる」は別の品質
AIは、指示された機能を「動く形」にするのは非常に速い。しかし、速さと引き換えに、同じような処理を何度もコピーして貼り付けたような、重複だらけのコードを生みやすいという特性があります。コードを分析する調査会社の集計では、重複したコードブロックの割合が観測史上もっとも高い水準に達し、2023年から大きく増えたと報告されています。一方で、コードを整理し直す「リファクタリング」の割合は激減し、開発者はコードを整理するより、コピー&ペーストで済ませる傾向が強まっているといいます。
重複だらけのコードは、最初は動きます。問題は改修のときです。ひとつの仕様変更を反映するのに、同じような箇所を何十カ所も直さなければならず、直し漏れがバグになる。「動くから納品された」システムが、「触ると壊れるから誰も直せない」システムに変わっていく。これは、誰も触りたがらない基幹システムが技術的負債という経営リスクになる構図と同じで、AIがその負債の蓄積を加速させているのです。
発注者からは「速さ」しか見えない
やっかいなのは、この品質の差が発注者からはほとんど見えないことです。納品時に見えるのは「動いている画面」と「早かった」という事実だけ。中身が重複だらけで将来直しにくいかどうかは、コードを読める人でないと判断できません。だからこそ、発注段階で「速さ」以外の観点を契約に織り込んでおく必要があります。
| 発注時に確認すべき点 | なぜ大事か |
|---|---|
| 他社でも保守・改修できる作りか | 作った会社に縛られず、相見積もりを取れる |
| テストが用意されているか | 直したときに壊れていないかを機械的に確認できる |
| コードの重複や複雑さの基準を設けているか | 「動けばいい」ではなく、後で直せる品質を担保する |
とくにテストは、AI生成コードの品質を守る生命線です。カバレッジの数字だけでは不十分で、テストが本当にバグを捕まえられるかを問う考え方はミューテーションテストで納品物の品質を保証する記事で整理しています。
AIは使う。ただし「短い手綱で」
誤解してほしくないのは、AIを開発に使うこと自体が悪いのではない、という点です。削除専門チームですら、後始末にAIを使っています。分かれ目は、AIの出力をそのまま納品物にするか、人がレビューし、整理し、テストで守ったうえで受け入れるかです。AIのリファクタリング提案をどこまで受け入れるかという「判断」の設計はAI時代のリファクタリング判断の記事で扱いました。AIを速さのために使いつつ、その速さが後の負債にならないよう手綱を握る——この設計こそが、受託開発で発注者を守る部分です。
「安く速く」の見積もりには、後のコストが隠れている
AI活用をうたう開発の見積もりが安いとき、そこには「後で直すときのコスト」が含まれていないことがあります。目先の安さだけで選ぶと、改修や乗り換えの段になって、当初の何倍もの費用や、特定の会社への縛りに直面しかねません。発注前に費用相場と契約形態を押さえる基本はシステム開発の外注ガイドにまとめています。「AIで作ってもらったシステムが、改修できずに困っている」「これから発注する開発で、速さと後の保守性を両立させたい」「納品されたコードの品質を、第三者の目でチェックしてほしい」——そうしたお悩みがあれば、グリームハブのシステム開発・保守相談からお気軽にお問い合わせください。速さの裏に隠れたコストまで含めて、発注の判断をご一緒します。
