最近話題のバイブコーディングについて、現役エンジニアの筆者が私見を述べていくぜ！という会です！
では早速本題に入っていこうと思います。
バイブコーディングとは？
OpenAI共同創業者アンドレイ・カルパシー氏によって提唱された、開発者がコードを書くのではなく、感覚（vibe）をAIに委ねるスタイルのコーディング手法です。
「こういうアプリケーションを作りたいです！」とAIにお願いするところから始まるイメージですね。
バイブコーディングの進め方
基本ステップ
- 自然言語プロンプトを用いてAIに要望を伝える
- AIがコードを生成
- 動作を確認し、必要に応じて修正や追加を依頼する
人間は基本的にコーディングしないのがバイブコーディングです。ただ、アプリケーションを利用するのは人間なので、人間目線での動作確認や修正依頼を出す必要があります。
要件定義・受入試験 → 人間
実装 → AI
みたいなイメージですね！
メリット
- コーディングが速い：アイデアを即形にできる
- ロースキルでも開発できる：プログラミング未経験者でも始めやすい
- 開発効率の向上：ツールによる開発速度と効率改善、UIのたたき台作成にも◎
- チーム開発での支援：新人教育やレビューの促進にも有効
一番大きいのは、やっぱりスピード感ですね。今の生成AIはPowerShellで動く軽めのツールくらいなら一発で動かしてくれたりしますし。また、ノンプログラミングでいけるので、非エンジニアの方でも手軽に業務効率化できるようになっています！
余談ですが、筆者が初めて仕事で触ったのはVBScript（PowerShellの前身。Windowsで動く自動化が得意な言語）でした。今ならAIでさくっと出来ちゃうなあ。
デメリット・リスク
- プロンプト精度の重要性：曖昧な指示では意図通りに動かない。人間にお願いするのと同様に、テキストコミュニケーション能力が必要
- AIの記憶・学習の限界：情報を忘れやすく、毎回明示が必要
- コード品質・セキュリティの懸念：品質管理が課題、セキュリティ脆弱性など留意すべき点が多い
- 属人化のリスク：AI依存によって理解や移行が困難になる懸念
- 大規模開発や複雑構造には注意：設計上の制限や適用範囲の限界あり
- 運用ミスによるリスク：デバッグログの放置や運用ミスなどが情報漏洩リスクに
生成AIはコーディングは得意ですが、実際にシステム運用をするわけではありません。なので、生成AIで作成したコードはセキュリティ面や運用面についておざなりになりがちです。
そのまま商用で動かしてしまうのはリスクになります。また、運用者（人間）がコードを理解していないと、本番障害時の解析が遅れる懸念もあります。
開発は早いけれど、リスクは大きい。これがバイブコーディングの現状だと思います。現場導入するのであれば、範囲を絞ったり人間によるレビュー、リファクタリングは必須かなあ。オフショア開発に似たような感じかもしれません。
実施時のポイント
- プロンプト設計を工夫する：明確で具体的かつ段階的な指示を心掛ける。文章スキルは重要！
- 手動レビューを必須にする：生成したコードは必ず人の目で検証する
- セキュリティ対策を並行して行う：人間による最終リファクタリングは必須！
- バージョン管理とドキュメント整備：生成結果にもバージョン管理を適用。自分でコーディングをしないと、エラー発生時に戻せなくなる！
- 段階的適用：まずはプロトタイプやUIから導入し、徐々に適用範囲を広げる。こうすることで人間側も慣れます
- チームで共有する：知見の蓄積やレビュー体制を作る。ベストプラクティスをまとめる
理想としては全てAIがやってくれるのが望ましいですが、人間が指示を出す以上これは困難です。なので「バイブコーディング時のガイドライン」みたいなものを作ってチームで共有する必要があると思います。
また、レビュアーをしっかり立てないと、人間がコーディングした際と同様、品質がばらつくことになります。
うーんちょっとキツイかなあ。
バイブコーディングの現状
ここまでバイブコーディングについてメリデメなんかを書いてきましたが、そろそろ現状について私見を述べていこうと思います。
スキルは必要
AIがたたき台を作ってくれるわけですが、結局動作確認→修正依頼にもスキルは必要です。また、現場目線で言うと「なぜこういうコーディングをしているのか」を作成者が説明できないと、改善点を示すこともできません。
バイブコーディング的にはレビューすらやらないのが正攻法なのかもしれませんが、これはあくまでスキルがある人間だからこそです。
スキルがない人間がバイブコーディングでモノを上げると「動くけど、意志はないコード」が生まれます。こういったコードは保守性が悪くデバッグ工数がかさむ原因となり、結局開発工数は下がったけど、試験工数が上がる、といった未来に繋がります。
また、AIに頼りすぎると「開発者のスキル」が育たない懸念もあります。もちろん個人の向き合い方によってスキルが向上するケースもあると思いますが、人間はそんなに真面目な生き物じゃありません。楽をしたくなります。たぶんAIが生成したコードを読まなくなってきます。
「なんでここのコードこういう書き方してるの？」みたいな質問を適宜投げていくのは必要になるでしょう。逆にこれができないと、コード理解が進みませんし、コード理解ができないとAIへの指示出し精度も上がりません。
「生成AIに振り回されるだけの人」になってしまわないよう、スキルアップのための工夫が必要です。
ツール作成には向いてる
開発支援ツールなどの作成には向いていると思います。
例えば
- テストデータ作成支援
- 設計書→モジュール自動生成
みたいなものは生成AIで作りやすいです。これらのツールは基本的に納品物にならないので、品質を意識することはありませんし、多少コードが汚くても動けばオッケーです。
筆者が現場目線でバイブコーディングをするなら、ツール作成が中心になるでしょう。
個人開発にも向いてる
ここまでは現場目線、要はチーム単位で動いているプロジェクトの目線だったわけですが、個人開発であればバイブコーディングのデメリットを受けづらいと思います。
筆者もよくプライベートでバイブコーディングしていますが、1人でやるなら保守性は二の次でもいいですし、作るものを限定的にすることで、リスクを下げたりもできます。
例えば「決済系システムを自サイトに導入」すると、障害時のリスクは大きく跳ね上がります。なので決済をしたいのであれば、決済系システム側で全てできるようにすると、自サイトのコーディングに依存することがないわけです。UIの一貫性は失われますが、個人でやる分にはリスクを取らないのが優先ですよね。
また、個人でやる分にはナレッジの共有も別にいりませんし、ルール策定も不要です。一応自分用にNotionに作業メモ残していますが、その程度で全然問題ありません。
個人開発をしたい人にはバイブコーディングはうってつけだと思います！
まとめ
以下を抑えて、バイブコーディングとうまく付き合っていきましょう。
「楽しさ」と「効率」を両立する入口
バイブコーディングはアイデアを形にするワクワク感を与える一方で、品質管理やセキュリティへの配慮も不可欠。まずは個人でやってみよう！
ミニマムスタートでやろう
バイブコーディングの導入検討は「ツール系」など範囲を限定して進めるのが吉。どんな事でも人間には慣れが必要！
生成されたコードを理解する
エンジニアがバイブコーディングをするのであれば、生成されたコードを読んで「どこでどんな処理をしてるか」「なぜこういうコードになっているか」を把握するようにしましょう。分からない部分をAIに聞くことでスキルアップに繋がります！
最後に
正直、日本の開発現場とは相性が悪い部分も多いですが、プライベート開発では非常に楽しい手法です。
スピード感と自由度を活かして、うまく付き合っていきたいですね。
コメント