asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです! <br> 食事管理アプリ『あすけん』 について <br> https://www.asken.jp/ <br>

「速く作るために、作らない」— Vibe Coding時代に大切な3つのこと

こんにちは。AX推進部のテックリードの山口です。

今回はVibe Codingに大切だと感じていることを書きました。

LLMが何でも作ってくれる時代に

ChatGPTやClaudeに指示を出せば、数分でアプリケーションのコードが生成されます。いわゆる「Vibe Coding」が当たり前になりつつある今、私たちは「たくさん作れる=速い」と思いがちではないでしょうか。

でも、本当にそうでしょうか?

LLMに次々とコードを書かせて、機能を追加して、また別の機能を追加して——気づけば、何がどこにあるのか分からなくなり、ちょっとした修正にも時間がかかるようになっていた。

そんな経験はありませんか?「速く作れたはず」のコードが、いつの間にか足かせになっている。

以前、非エンジニアのメンバーが LLM を使って Lambda で API を開発し、PR を出してきたことがあります。 見てみると、既存のフレームワークを使わず、独自のルーティングや認証の仕組みが作り込まれていました。目的に沿って LLM に指示を出し続けた結果、気づかないうちにそうなってしまったのです。 このまま進めばメンテナンス不能になることは明らかでした。結局、フレームワークを使った形に書き直してもらうことになりました。

「速く作りたいから、保守性は後回しでいい」——そう思ってしまうこともあるかもしれません。でも、その判断が後から自分の首を絞めることになるのです。

この記事では、Vibe Codingで開発を進めるときに大切にしたい3つの考え方をご紹介します。

キーワードは「長期的な速さ」です。

「長期的な速さ」という考え方

今日速く作れることと、来週も速く作れること。この2つは、実は違うものなんです。

ここで「トロッコとレール」を想像してみてください。トロッコを走らせるためには、車輪はなるべく円がよいです。ただ少し歪んでいても進むことはできます。でも、レールの上に障害物があったらどうでしょう。その都度止まって、どかして、また走り出す。これでは速く走れませんよね。

Vibe Codingでも同じことが言えます。細かいコードの書き方が多少雑でも、走り続けることはできます。でも、「何を作っているのか分からない」「同じようなコードがあちこちにある」「どこを直せばいいのか分からない」——こうした障害物があると、途端にスピードが落ちてしまいます。

100mトラックをまっすぐ走るように、トラックに障害物を置かないこと。それが、結局は最速につながるのではないでしょうか。

原則①:最短距離で作る

「本当にこれを作る必要があるかな?」

Vibe Codingをしていると、この問いを忘れがちになります。LLMが何でも作ってくれるから、「とりあえず作ってみよう」となりやすいですよね。でも、作ったものには必ず管理コストが発生します。

例えば、何らかの新機能を価値検証したいときのことを想像してみましょう。もし、サーバもDBも立てず、静的なHTMLで必要な検証ができるのなら、それが最速です。検証したいことが「このUIで伝わるかな?」なら、動くコードは必要ないかもしれません。

LLMが実装してくれる時代だからこそ、「LLMに何を作らせるか」の選択が重要になってきます。作れるから作るのではなく、目的に向かって最短距離で作る。作らないことが、最速の道であることも多いんです。

原則②:目的を明確にする

「誰のために、何を解決するために作るんだっけ?」

この問いに明確に答えられないまま作り始めると、実装がブレてしまいます。あれも必要、これも必要と機能が膨らみ、結局何がしたかったのか分からなくなる——同じようなこと、ありませんか?

目的が曖昧なまま作ったものは、ふりかえるのも難しくなります。「これで良かったのかな?」と思っても、そもそも正しさの基準がないからです。

検証したいことの解像度を高め、フォーカスを絞ること。これが最もコストが低い方法です。Vibe Codingは便利な手段ですが、目的ではありません。何を検証したいのか、誰に価値を届けたいのか——それを言葉にしてから作り始めてみてください。

原則③:最低限の保守性を守る

「車輪は円であれ」

スピード重視だからといって、何でもありではありません。あとで自分を苦しめないラインは守っておきたいところです。

では、何を見て、何を見なくていいのでしょうか。

見ておきたいこと:

  • 既存のライブラリやフレームワークの仕組みを使っているか(車輪の再発明をしていないか)
  • 同じロジックが何度も書かれていないか
  • 目的に対して複雑すぎないか

見なくても大丈夫なこと:

  • 細かいロジックの分岐
  • コードのフォーマット
  • プログラミング的な「美しさ」

すべてを完璧にする必要はありません。車輪が楕円でも走れます。でも、車輪が四角になったら走れません。そのラインを見極めることが大切です。

まとめ:スピードと保守性は対立しない

「速く作りたいから保守性は後回し」——これは実は誤解かもしれません。

最低限の保守性を保つことが、長期的なスピードにつながります。障害物のない道を走ることが、結局は最速なんです。

速く作るために、作らない判断をすること。この3つの原則を守ることで、長期的に速く作り続けられる状態を実現できます。

Vibe Codingで何でも作れる時代だからこそ、大切にしたい3つのこと:

  1. 最短距離で作る——本当に必要?と問いかける
  2. 目的を明確にする——誰のために何を解決する?
  3. 最低限の保守性を守る——車輪は円であれ

LLMに「何を作らせるか」を考えること。これが、これからの開発で最も重要なスキルになっていくのかもしれませんね。

さいごに

LLMが当たり前になっていく中で、何を作るかだけでなく、どう作るかも問われる時代になりました。
askenでも、その変化のど真ん中でプロダクトづくりを進めています。 今、一緒に悩んで、一緒に作っていけるエンジニアの仲間を探しています。
↓↓よければ、まずはカジュアルにお話しできればうれしいです!

カジュアル面談 応募フォーム | 株式会社asken

関連情報

また、2025年12月22日に公開したこちらの記事も私が執筆しましたので、ご興味があればぜひご覧ください! tech.asken.inc

asken techのXアカウントで、askenのテックブログやイベント情報など、エンジニアリングに関する最新情報を発信していますので、ぜひフォローをお願いします!