Vibe Coding、最初は速い。でも後半で急にしんどくなる

163

Last updated at 2026-04-02Posted at 2026-04-02

実際にやってみて分かったこと

最近 Vibe Coding を続けていて、最初はかなり便利だと感じました。
画面も処理もすぐ形になるし、初速は本当に速いです。

ただ、機能が増えてくると、しんどさの種類が変わってきます。
大変なのは「コードを書くこと」より、その後の設計、整合性、テスト、レビューでした。

今回は、実際に進める中で感じたことを、開発の流れに沿って短くまとめます。

Vibe Coding では、思いついた機能をそのまま作り始めても、最初はそれなりに進んで見えます。
でも機能が増えてくると、開発順序を考えていないこと自体が問題 になります。

どの機能を先に作るか、何を共通化してから個別機能に入るか、依存関係をどう整理するか。
この順番を設計していないと、後で作り直しや矛盾が増えやすいです。

これは普通にあります。
同じエラーや同じ機能でも、AI が何度繰り返しても正しいコードを出せないことがあります。

それっぽい修正は出てきますが、根本原因に届いていないまま、似た修正を繰り返しがちです。
途中からは、AI に直させ続けるより、原因を人が切り分けるほうが大事になります。

AI は共通機能を意識して整理するのがあまり得意ではありません。
そのため、同じような機能が別のモジュールに何度も生成されやすいです。

しかも実装が少しずつ違うので、あとで修正すると統一できなくなります。
最初は速くても、後半になるほどこのズレが効いてきます。

開発前半は、機能を1つずつ足していけば進みます。
でも後半は、機能単体よりも、機能同士の関係のほうが難しくなります。

互いに前提が食い違ったり、矛盾したり、片方を直すともう片方に影響したりします。
この衝突をうまく解くのは簡単ではなく、ここは人が設計を見ないと厳しいです。

最初は AI 開発がすごく速く感じます。
でも、機能が増えるほどコードも増え、AI に必要な文脈も増えていきます。

その結果、実装にかかる時間も長くなります。
さらに変更の影響範囲も広がるので、1つの修正で終わらなくなります。

AI で実装速度が上がるほど、テストの重要性は上がります。
コードが増えるスピードに対して、手動確認だけでは追いつかなくなるからです。

特に後半は、AI が直した箇所だけでなく、別の機能まで影響を受けやすくなります。
Vibe Coding を続けるなら、効率よく回せるテスト機構は必須だと思います。

一方で、UI の一部は AI だけでは完結しません。
機能として動くことと、使いやすいことは別だからです。

レイアウト、見た目、余白、操作感、エラー表示、非同期中の分かりやすさ。
こういう部分は、最後まで人が実際に触って確認する必要があります。

bug が少ないうちは、見つけたものから順に直しても何とか回ります。
でも数が増えてくると、修正の順番を考えないと全体が回らなくなります。

影響範囲が大きいもの、再発しやすいもの、根本原因に近いものを先に直すのか。
それとも業務影響が強いものを優先するのか。
ここを整理しないと、頑張って直しているのに全体はあまり良くならない、という状態になりやすいです。

後半になると、AI が一度にかなり大きな差分を出してくるようになります。
数百行単位になると、reviewer が前提を十分に知らない限り、正直ちゃんと見きれません。

結果として、細かいところしか見られないか、全体を把握しないまま通してしまうリスクが出ます。
AI が書けることと、人がレビューできることは別問題です。

実際の開発では、機能が動くだけでは足りません。

こういう部分は、最初は見えにくいですが、後半になるほど確実に効いてきます。
しかも、後からまとめて直すのはかなり重いです。

Vibe Coding は本当に速いです。
でも、続けていくと大変になるのは「書くこと」そのものではありません。

個人的には、Vibe Coding は実装を速くしてくれる一方で、
設計、順序付け、共通化、テスト、レビューの大事さをむしろ強くするもの だと感じています。

最初はかなり楽です。
でも、本当に差が出るのは後半でした。