バイブコーディング雑感: 2026年3月時点ではまだ油断できない
この記事は、Notionにあった反省メモを、GPTでQiita向けに書き直した
2026年3月時点での個人的な実務メモです。
今はかなり過渡期だと思っています。
半年後には今できないことが普通にできるようになっているかもしれないし、5年後にはプログラミングの仕事のかなり大きな部分が変わっている可能性もあると思います。
ただ、少なくとも今の時点では、「AIに書かせるからこそ、コードはきれいに保ったほうがよい」 と感じています。
バイブコーディングでもコードはきれいに書いたほうがよいと思う理由
1. 指示しないと設計を無視しがち
AIは、明示しないと設計方針をあまり守ってくれないことがあります。
例えば、以下のようなことは起きやすい印象があります。
- すぐに
normalizeしたがる - すぐに patch 的なメソッドを生やす
- 根本原因を直さず、その場しのぎの修正を入れる
- あまり意味のない validation を増やす
例えば、直前で "" を入れているのに、その後で None チェックをして raise するようなコードが出てくることがあります。
動くことは動いても、「なぜこの処理が必要なのか」が曖昧なコードは、後でかなり扱いづらいです。
2. 品質が安定しない
うまく書ける時はかなりうまく書いてくれますが、品質はまだ安定しないと感じます。
- きれいにまとまる時もある
- でも少し条件が変わると急に崩れる
- 生成結果に一貫性がないことがある
そのため、何も考えずに一気に任せるより、ある程度分割して依頼したほうが安定しやすいです。
3. セキュリティ面はまだ油断しづらい
特に backend や公開系のシステムでは、この点が大きいです。
- 設計を詰めずに、各種インジェクションやスクリプティング対策まで十分にできていると言い切れるか
- Permission チェックが漏れていないか
- 「AIがやってくれたから大丈夫」とはまだ言いづらい
2026年3月時点では、危ないコードが生成されうるという話もそれなりに見かけます。
なので、少なくとも今は 生成コードをそのまま信用しない前提 のほうが安全だと思っています。
4. テストもまだ過信しづらい
AIにテストコードを書かせること自体はできます。
ただ、テストがあることと、十分に安心できることは別です。
個人的には、以下のような点がまだ気になります。
- カバレッジが高くても、不具合検出力が十分とは限らない
- 外から叩いてOKでも、内部に不要な分岐や無駄な実装が残ることがある
- 挙動だけ見ていると、設計の歪みを見逃しやすい
インターネット上でも、AI生成コードまわりの不具合増加を指摘する話はよく見かけます。
もちろん全部が全部そうではないですが、まだ「自動テストがあるから安心」とまでは言いづらい印象です。
5. 結局、後で人間が困ることが多い
一番つらいのはここかもしれません。
- レビューしづらい
- 不具合修正しづらい
- LLMで直せない時に、人間が汚いコードを読むことになる
これがかなりしんどいです。
特に、LLMでもうまく直せない不具合に当たった時に、ぐちゃぐちゃのコードを人間が追うことになると、途端にコストが跳ね上がります。
将来的にできるようになるかもしれないことは、今の判断に入れすぎない
これはかなり大事だと思っています。
- 今できないことは、今の開発では前提にしない
- 「そのうちいい感じに直してくれるかも」に引っ張られない
- 今うまく扱えないなら、今作っているものにそのまま使うのは危ない
「将来もっと賢くなるはず」はたぶん正しい方向だと思います。
でも、今納品するもの に対しては、今の能力で判断したほうがよいです。
不具合が多いままでも後で直せる前提で進めると、結局あとで苦しくなりやすいです。
とはいえ、バイブコーディングでもきれいなコードは書けると思う
ここは希望があります。
ちゃんと条件を揃えると、かなり良いコードが出ることも多いです。
1. 設計をちゃんと伝える
例えば、こういうことを最初に明示するとかなり違います。
- validation のタイミング
- 各レイヤーで実装すべき内容
- コーディングルール
- 命名規則
- 例外処理の方針
- DI の方針
AGENTS.md のような形でルールを置いておくのは、かなり効くと思います。
2. 大きすぎるタスクを渡さない
一気に大きな実装を投げるより、分割したほうがかなり安定します。
例えばこのくらいで分けると、比較的きれいに出やすいです。
- domain の model
- application の UseCase と contract を UseCase ごと
- infrastructure の実装を contract ごと
CRUD などはまとめて依頼してもよいかもしれませんが、結局レビューするなら、1つずつでもそこまで変わらないことが多いです。
3. レイヤーはやはりあったほうがよい気がする
これは AI で書いても、人が書いても同じだと思っています。
レイヤーがあると、保守しやすいです。
例えば、ビジネスロジックの修正のはずなのに infrastructure 層まで更新されていたら、すぐ異常に気づけます。
また、GPT を Gemini に差し替えるような変更も、DI の差し替え中心で済みやすくなります。
4. 妥協しない
これも大事でした。
「とりあえず動いたからOK」で進めると、あとでだいたい苦しくなります。
しかも、一度ぐちゃぐちゃに出たコードを後からきれいにさせるのは、あまりうまくいかないことが多いです。
原因はよくわかりませんが、
- コンテキストが汚れるからなのか
- 読ませるコード量が増えすぎるからなのか
- 途中経過の悪い構造を引きずるからなのか
このあたりの理由で、後からの立て直しは難しい印象があります。
もちろん、domain -> application -> framework のように段階的に整理させると持ち直すこともあります。
ただ、最初から崩さないほうがやはり楽です。
5. 実装コストはそこまで増えない気がする
体感では、きれいに書かせるためのコストは、そこまで大きくないです。
むしろ、
- 最初に設計を伝える
- 粒度を小さくする
- レビューしやすい単位で出させる
このあたりをやったほうが、後工程のしんどさが減ります。
集中力を切らさないのも大事
これは開発者側の話です。
待ち時間に次の設計やプロンプト準備を進めると、かなり効率が変わります。
- 元気な時はいくつかスレッドを立てて並列で進める
- backend と frontend を並列で進めるのはやりやすい
- ただし、同じファイルを触る作業を並列にやるのは危険
あと、待ち時間に YouTube を開き始めると、かなり危険で作業効率が一気に落ちます。
何をやらせてたのか、何が残ってるのか忘れちゃう。え？歳のせいじゃ。。
例外的に、かなり割り切って使ってよい場面もあると思う
全部を堅くやる必要はないとも思っています。
例えば以下のようなケースです。
- mock
- R&D
- 捨てコード
- インターネット公開しないもの
- 悪意あるユーザーをあまり想定しないもの
- 部署内だけで使う小さなツール
こういう用途なら、かなり強気に使ってもよいかもしれません。
役目が終わったら捨てる前提なら、スピード優先の価値は大きいです。
また、最初は社内向けに雑に便利ツールを作っておいて、
「これは本格的に広げたい」となった段階で、開発会社やしっかりした体制で製品版を作る、という流れはかなり現実的に思えます。
この場合は、
- 要件定義が進んでいる
- 基本設計の材料がある
- 実際の業務導線も見えている
ので、結果として低コスト・高品質に寄せやすそうです。
Frontend は比較的やりやすい気もする
ここは少し自信薄めですが、Frontend は backend より割り切りやすい印象があります。
ある程度しっかりしたフレームワークに乗っていれば、見た目や簡単な画面はそこそこ作りやすいです。
もちろんコードを見ると微妙なことはありますが、backend ほど即危険になりにくいケースも多いです。
ただし、
- 規模の大きいライブラリ改修
- 既存コードの複雑な修正
- 状態管理が重いアプリ
このあたりは、まだ結構つらい印象があります。
新規は比較的やりやすいけれど、修正は重い、という感じです。
今後どうなるのか
この先1年で、きれいなコードを書く必要がかなり薄れるのか。
それとも2年くらいはまだ必要なのか。
このあたりは正直まだよくわかりません。
ただ、次のような方向には進みそうだとは思っています。
- B2C や比較的ゆるめの B2B は、アイデアを出して AI で形にする流れが強まりそう
- 運用はまだ人間の比重が残りそう
- Terraform などもかなり書かせられるが、レビューは必要そう
- セキュリティチェックに特化した AI は強そう
- 金融、宇宙、軍事、原発、オフライン系組み込みのような厳格な分野は、もう少し時間がかかりそう
一方で、ラフなアイデアをすばやく形にするハードルは確実に下がっていると思います。
なので、試作や小さなアプリ開発はどんどんやったほうがよさそうです。
最終的にどう落ち着くのかはまだわかりませんが、
- AI がもっときれいなコードを書くようになるのか
- 外部テストや検証がさらに強化されるのか
- その両方になるのか
などになるのでしょうか。
AIしか分からない超高効率なコードになる可能性もあります。
個人的には、やはり AI にもきれいなコードを書いてほしいです。