AIが書いたコードは動きます。問題は動くかどうかではなく、一年後にそれを変更できるかどうかです。

初出は2025年5月です。当時話題になっていた特定ツールの品質低下について、外部から検証できる事実は確認できませんでした。そのため本稿では、個別ツールの評価ではなく「AI生成コードと保守性」という論点に絞って書き直しています。

AIエージェントにコードを丸投げすることの危うさについては、以前にも書きました。AIが出す「ギリギリ動く」コードは、長期運用のなかで技術的負債として積み上がり、いずれ保守できなくなる——という話です。

その懸念が具体的な形で見えたのが、2025年ごろにAIコーディングエディターの利用者のあいだで出ていた「アップデートのたびに提案の質が落ちている気がする」という声でした。

「直したはずのものが、別の場所で壊れる」

この訴えが興味深いのは、それ自体が保守性の低いコードで起きることと同じ形をしている点です。一箇所を直すと別の箇所が壊れる。以前できていたことが、いつのまにかできなくなる。

実際にツールが劣化していたのかどうかは、外からは検証できません。モデルの入れ替え、コンテキスト長の調整、プロンプトの内部変更——利用者から見えない変数が多すぎるからです。ただ、「昨日と同じ入力で、今日は違う品質が返る」という状況そのものは、AIを開発の土台に置くときに必ず向き合うことになります。

AIは「動くコード」は書ける。「変えられるコード」はまだ難しい

具体例を一つ。DjangoでURLを扱うとき、AIは次のようなコードを平気で提案します。

return redirect('/new_feature/' + str(item_id) + '/')

一見これで動きます。しかしURL構造を変えた瞬間、コード中に散らばった同じ形の文字列を、一つずつ手で直すことになります。

Djangoにはreverse()があり、URLを名前で参照すれば構造変更に強くなります。これは基本的なベストプラクティスですが、AIに「動くコードを書いて」と頼んだとき、この選択が自動的に採られるとは限りません。

問題は知識の欠落ではありません。「もしURL構造が変わったらどうなるか」「環境によってドメインが違ったらどうするか」という問いを、誰も立てていないことです。指示されていない問いをAIが勝手に立てることは、まだ期待できません。

数年後の姿を、誰が想像しているか

AIエージェントを使えばプロトタイプは驚くほど速く作れます。ただし保守の視点が抜けたまま進めると、そのサービスは数年で朽ちます。可読性が低く、テストが不十分で、依存関係が複雑に絡んだコードベースは、機能追加もバグ修正も極端に難しくなるからです。

地盤の弱い土地に建てた建物と同じで、建った直後はどちらも同じように見えます。差が出るのは、変化が来たときです。

それでも、道具としては手放せない

ここまで書いておいて言うのも妙ですが、私自身はAIコーディングツールを毎日使っています。書く速度は明らかに上がりました。

変わったのは使い方のほうです。設計と、レビューと、「この構造で三年もつか」という判断は手放さない。そこだけは人間が持つ、という前提でなら、これほど強力な道具はありません。

AIは開発を支援する道具です。最終的な品質に責任を持つのは、いまのところまだ人間の側にあります。