執筆者：DigKnow株式会社　CTO　桑原　脩

　

「動いた。」その瞬間は、やっぱり気持ちいいです。Claude Codeにタスクを投げて、テストが通って、デプロイが完了する。達成感があります。でも最近、その後に小さな問いが頭に浮かぶようになりました。「これ、一週間後の私が読んだら、何をやっているか分かるだろうか」——と。

　

「とりあえず動いた」は、いつから”とりあえず”になったのか

思い返すと、私が「とりあえず動いた」という言葉を使い始めた時期と、AIコーディングツールを本格的に使い始めた時期は、ほぼ重なっています。
偶然ではないと思っています。
AIがコードを補完してくれるようになると、実装にかかる摩擦が劇的に減ります。「この処理、どう書けばいいんだっけ」と悩む時間が短くなり、「まず動かしてみる」サイクルが速くなります。これは純粋に良いことです。スピードが上がり、試行錯誤がしやすくなります。
ただ同時に、「動くこと」を確認してから先に進むハードルが下がった分、「なぜこう動くのか」を理解してから先に進む機会も、構造的に減っています。
前回の記事（Vibe Codingとは何か）でも触れたように、AIと対話しながら感覚的にコードを生成するスタイルが広がっています。そのスタイル自体を否定したいわけではありません。でも、「とりあえず動いた」の先に何が来るか——という問いは、もう少し真剣に考えてもいいタイミングに来ているのではないか、と思っています。

　

動くコードと、理解できるコードは、別物

ソフトウェア開発の世界には、昔から「動くコード」と「良いコード」は違う、という議論があります。これはAI以前からある話です。
でも今、その議論に第三の軸が加わってきた気がしています。「理解できるコード」という軸です。
動く。テストも通る。パフォーマンスも問題ない。でも、なぜこの設計になっているのかが、コードを読んでもわからない——そういうコードが、AIコーディングの現場では静かに増えています。

なぜでしょうか。

AIが生成するコードは、動作の正確さという点では高水準のことが多いです。でも、「このチームのコードベースにおいて、なぜこのパターンを選んだか」という文脈は、AIには存在しません。コードの外にある意思決定の経緯、制約、議論——そういったものを反映する必要がないまま、コードだけが生成されます。
結果として、「動くが、文脈のないコード」が積み上がっていきます。
これは品質問題とは少し違います。バグがあるわけではなく、スペックは満たしています。でも「このコードを3ヶ月後に修正しなければならない誰か」にとっては、途方もない手がかりのなさが待っています。

　

AIコーディングが加速させる「とりあえず動く」の蓄積

私がClaude Codeを使っていて実感するのは、「実装の速度」と「理解の速度」が乖離し始めているということです。
かつての開発は、実装と理解がほぼ同期していました。コードを一行一行書くプロセスが、そのままコードを理解するプロセスでもありました。書いた本人が一番よくわかっている状態が、ある程度自然に保たれていました。
AIコーディングでは、そのサイクルが崩れます。タスクを渡して、出力が返ってきて、動作を確認して、マージする。実装の速度は上がります。でも理解の速度は上がりません——むしろ、「全部を理解しなくても進める」という体験が日常になるほど、理解を後回しにする習慣が育ちます。
「とりあえず動いた」が積み重なると何になるか。答えはシンプルです。「とりあえず動いているが、誰も全体を把握していないシステム」になります。
これは急に起きることではありません。一週間、一ヶ月、一クォーターと時間が経つにつれ、じわじわと進行します。そのプロセスが見えにくいのが、この問題の厄介なところです。

　

「とりあえず動いた」の先に来るもの——三つのシナリオ

具体的に何が起きるか。私が観測してきた範囲で、三つのパターンがあります。

①：改修コストの増大
動いているシステムに変更を加えようとしたとき、影響範囲が読めません。コードは存在するが、なぜそう書いてあるかがわからないため、どこを変えると何が壊れるかの予測が立てにくいです。「とりあえず動く」が積み上がったシステムは、変更のたびに探索コストが発生します。

②：オンボーディングコストの増大
新しいメンバーがチームに入ったとき、コードを読んで「これは何をしているか」を理解する時間が増えます。ドキュメントがなく、コードだけがあり、書いた人もなぜそう書いたか覚えていない——という状況は、珍しくありません。

③：「コードを読める人」が限定されていく問題
これが一番根が深いです。AIコーディングが進むと、「コードを書ける人」は増えるかもしれません。でも「コードを深く理解できる人」は増えません——むしろ、理解しなくても進めるツールが普及するほど、その比率は下がる可能性があります。システムを動かし続けるために必要な「理解の総量」は変わらないのに、その理解を持つ人が少なくなっていきます。

　

「動く」を超えて、何を残すか

「とりあえず動いた」の次に来るものは、問いだと思っています。
このコードは、一ヶ月後の私が読んでわかるか。このシステムは、担当者が変わったときに引き継げるか。このプロジェクトは、二年後も理解可能な状態を保てるか。
AIコーディングが加速した現場では、この問いに答える仕組みを意識的に作らないと、「動くが誰も全体を把握していないシステム」が静かに、確実に育っていきます。
以前なら、コードを書く速度そのものがブレーキの役割を果たしていました。実装が遅いから、その分だけ設計を考える時間がありました。レビューがあり、議論があり、意図が共有されながら進んでいました。
AIがそのブレーキを外しました。それ自体は進歩です。でも外したブレーキの代わりに、何を置くか——それはまだ、多くの現場で問われていません。
「とりあえず動いた」が口癖になっている現場では、この問いを立てることが、次のステップになると思っています。

　

まとめ

AIコーディングツールが「動くコードを速く得る」体験を当たり前にしました。それは良いことです。でも「とりあえず動いた」が積み重なると、改修コストの増大・オンボーディングの困難・理解できる人の減少という三つの問題が静かに育ちます。速度を手に入れた現場が次に向き合うべきは、「動く」の先に「理解できる」状態をどう保つか、という問いです。

あなたのチームのコードベース、今日書いたコードを半年後の誰かが読んでも理解できる状態になっていますか？

次回は、「GitHubのスター数と技術的負債」というテーマで、人気リポジトリの裏側にある構造的問題を掘り下げます。

• « Vibe Codingとは何か——コードを”感覚で書く”新潮流の正体
• GitHubのスター数と技術的負債の意外な関係 »