「去年、AIに手伝ってもらって、受発注を管理する社内ツールを自分たちで作れたんです。あのときは感動しました。ただ、半年たった今、細かい直しを入れようとしても中身が複雑すぎて、作った本人でももう追えなくて」——先日、中小企業の経営者から受けた相談です。
生成AIで、以前なら外注していたようなツールが「作れてしまう」時代になりました。これ自体はすばらしいことです。問題はその半年後に来ます。動いてはいるのに、直そうとすると誰も手を出せない。バグの原因がどこにあるか分からない。この「作れたのに、育てられない」状態こそ、いま最も増えている相談です。本記事では、AIに大半を書かせたコードがなぜ腐るのか、そして受託が引き取るときに何を立て直すのかを書きます。
腐るのはいつも「足したもの」だった
現場で実感するのは、AI生成コードが劣化するとき、壊れるのは決まって「余計に足された部分」だということです。最近このテーマを半年運用の実体験としてまとめた記事が技術者の間で話題になりましたが、そこで挙げられていた「腐った書き方」は、私たちが受託で引き取る現場の実感とほぼ一致します。
- コードを日本語に言い換えただけの、情報量ゼロのコメントが大量に付いている
- まだ二か所でしか使っていないのに「共通化」され、あとから読むと逆に追えない
- 一つの関数が数百行にふくれあがり、どこで何をしているか誰にも分からない
- エラーが起きても握り潰され、問題が起きても静かに間違った結果を返し続ける
これらに共通するのは、「動かすためには要らなかったのに、AIが親切に足したもの」だという点です。逆に、半年たっても効いていたのは、実装ではなく「仕様」と「テスト」を人間が握っていた部分でした。ここに、AI生成コードとの正しい付き合い方のヒントがあります。
なぜ腐るのか — AIは「今動く」を最短で満たすから
AIが悪いわけではありません。AIは「今、この機能を動かす」という目の前の要求を、驚くほど的確に満たします。ですが、半年後の保守しやすさや、事業が変わったときの拡張しやすさは、その場のプロンプトには含まれていません。
だからAIは、頼まれれば親切に共通化し、丁寧にコメントを付け、エラーもとりあえず握り潰して「動く形」を最短で作ります。一つひとつは善意なのですが、それを判断・取捨選択する人間がいないと、善意が積もって負債になる。AIのリファクタリング提案をどこまで受け入れるかという判断の設計はAIのリファクタリング判断の記事で、AIが量産するコードのレビューと管理はAIエージェントのコード管理の記事で詳しく扱っています。
内製と受託の線引き — 「作る」は内製、「持ち続ける」は要判断
ここで発注者がいちばん知りたいのは、「では全部プロに外注し直すべきなのか」でしょう。答えは、多くの場合ノーです。
AIで内製できるようになったこと自体は大きな武器で、それを手放す必要はありません。線を引くべきは、「作る」と「持ち続ける」を分けて考えるところです。小さな業務ツールを自分たちで素早く作り、試すのは内製が向いています。一方で、業務の中核を担い、止まると困る、長く育て続ける必要があるものは、仕様とテスト、そして保守の設計を持てる体制が要る。そこは内製だけで抱えず、受託を「作り手」ではなく「立て直し役・伴走役」として使うのが現実的です。ExcelやGASで回してきた業務を「いつシステム化すべきか」という手前の判断はExcelとGASの業務をいつシステム化すべきかの記事で扱っています。本記事はその一歩先、すでに「AIに書かせたコード」を抱えてしまったあとの話です。技術的負債を経営リスクとして判断する視点は技術的負債を発注判断する記事もあわせてご覧ください。
事例: 「作り直し」の見積もりを取りに来て、「立て直し」で済んだ会社
具体例を挙げます（社名は伏せます）。AIで作った在庫管理ツールが半年で手に負えなくなり、「一から作り直したい」と見積もりを取りに来た会社がありました。
中身を見ると、機能そのものは業務に合っていて、腐っていたのは前述の「足されたもの」——過剰な共通化と、握り潰されたエラー処理でした。そこで、作り直しは提案せず、まず何をするツールなのかという仕様を私たちが読み解いて文書に起こし、壊れやすい箇所にテストを敷き、腐った部分だけを段階的に整理しました。全面作り直しより費用も期間も大幅に小さく収まり、内製で作った資産はそのまま生きました。効いたのは新しいコードではなく、「このツールは何をするものか」を人間の言葉で取り戻したことでした。
引き取る前に、発注者側でやっておけること
最後に、相談に来る前でもできることがあります。AIで作ったツールでも、「これは何をするツールで、どういう入力に対して何を返すべきか」を短くていいので言葉で残しておくこと。これがあるだけで、受託側は立て直しの初速がまるで変わります。逆にこれが失われていると、動いているコードから仕様を推測する作業から始めることになり、そこに一番時間がかかります。
AIで作った社内ツールが半年たって直せなくなった、作り直すべきか立て直せるのか判断がつかない、内製をどこまで続けてどこから頼むべきか迷っている——そうしたお悩みがあれば、グリームハブの開発・AI・自動化のご相談からお気軽にお問い合わせください。今あるツールの仕様の読み解きから、腐った箇所の立て直し、内製と受託の役割分担の設計まで、無理のない範囲でご一緒します。
