バイブコーディング 生成AI→チャット→エージェントによる「本番品質のソフトウェア」の未来

ジーン・キム(著者), スティーブ・イェギ(著者), 長尾高弘(訳者)

• 販売会社／発売会社: 日経BP/日経BPマーケティン
• 発売年月日: 2026/07/18
• JAN: 9784296071517

商品レビュー

2026/08/19

バイブコーディングを実践してきた二人の著者が書いた本。まさしく、この変化に適応できないと時代に取り残されていくのだろうなと思う。まあ、現時点ではバイブコーディングで開発することを想定していないだろう案件もあるけど。

本書によるとバイブコーディングの長所として下記５つがあるとのこと。
・Fast：速い
・Ambitious：意欲的な仕事に取り組める
・Autonomous：自律的に仕事できる
・Fun：楽しい
・Optionality：選択制が広がる
この５つを統合して「FAAST」という造語が何度もでてきて印象的だった。
なお、必ずしも品質が良くなる(Better、Best)というわけではないらしいともあって、そこは設計次第なのだろうなと思った。

中には優秀なエンジニアでもバイブコーディングを危険視する人もいるらしく、GitLabのジェシー・ヤング氏という方も「私がオンコール待機するときはバイブコーディング禁止」とまで言っているらしい。だいぶよくなってるきてるとおもうけど、今でもそう思ってるのだろうか。

コンテキストウィンドウの残量が少なくなってくると、ショートカットを選ぶというのは確かに今でもあるなと思う。先日も、時間のかかる処理をCodexにやらせると、なぜか途中で終わるということがよくあり、試しにセッションを新しく作ると最後までやってくれるようになった。あれはいったいなんなのだろう。

AIにコードを書かせると、無駄なコメントが増えるというのは確かにある。いちいち「消して」というのも面倒なので許容することも多いけど、もう少し減らしたほうがいいだろうか。
最初に書いたコードで不具合をだしたのでそれを修正してもらったら、もともと不具合があったことをコメントに書くのは消してもらうこともあるけど。

作業量の見積もりが難しいというのは本当にそうだなと思う。基本、AIでやればすぐ終わるのだけど、何度やってもうまくいかなくて結局時間がかかってしまうということもある。
ただ、人がやる見積もりもうまいことだせるものじゃないのだから、難しさは同じかもしれない。

先日読んだ本にも書いてあったけど、敵対的な意見をAIにいってもらうというのはいい使い方だそう。レビューはしてもらうことはあるけど、あえて敵対的にチェックまでしてもらうとまた違うということなのかな。

なお、著者によると、Gitの制御は自分でやるほうがいいとのこと。自分は完全にGitも含めてAIにやってもらっているのだけど、それで後戻りができない事故っていまのところないなぁ。おかしなことになっても、だいたい伝えたらやり直しできるし。
今でもそうしているのだろうか。

なお、AIでコーディングする時代には、よりコミュニケーションスキルが求められるとのこと。コミュ力がない自分だけど、AIとはうまくコミュニケーションとれるようになっていきたいと思う。