Vibeコーディングとやらをしてみたので感想を書く
公開日:最近話題のVibeコーディング。否定派と肯定派がいる中で、実際どうなのか?ということを0からアプリケーションを作成することで自分の実感として持ち合わせる体験をしました。その感想を書き記していこうと思います。
Vibeコーディングとは
この記事をご覧の方はすでにVibeコーディングについてなんとなく知っている人がほとんどかとも思いますが、念のため記しておきます。
バイブ コーディングは、AI を使用して自然言語プロンプトから機能コードを生成する新しいソフトウェア開発手法です。
引用元:vibe コーディングとは (Google Cloud)
簡単に言えば、自然言語を用いて指示を出して、AI主体でコード生成・修正を行うプログラミング手法ですが、曖昧な指示でも作成してくれるのでVibe(雰囲気・ノリ・感覚)コーディングと名付けられているという認識をしています。
使ったもの
- エディタ
- Antigravity (Googleの)
- コードレビュー
- GitHub Copilot
- CodeRabbitAI
作ったもの
Tainy tune
GitHub https://github.com/tai-cha/tainy-tune
認知行動療法(CBT)におけるコラム法を参考に、日記を入力するとLLM(gemini-2.5-flash)が「事実」「感情」に書き分けたうえで認知の歪みの可能性についてタグ付け・アドバイスしてくれるアプリケーション
主な機能
- 日記の入力・保存
- 日記の入力に対してLLMが分析し・認知の歪みの可能性をタグ付け・アドバイス
- RAGに基づいて、ある程度関連のありそうな日記も参照する
- 日記の内容をRAGで引っ張ってこれるAIとのチャット
- 日記の振り返り機能(一覧・検索)
- 直近の感情のグラフ化・思考の偏り傾向のグラフ
- PWAによるオフライン記入・同期機能
現状の課題
- gemini(Google)以外のモデルに対応できていない(
@google/genaiを利用しているため) - llmの認知の歪みタグが少し過剰に評価してタグを付けがちな気がする(プロンプトの調整)
使い始め
- pnpmを使うのが好みだが、pnpmのファイルがあってもantigravityがnpmを使おうとする
.agent/rulesにnpmではなくpnpmを使うように指示。それでもnpmを実行しようとするときがあるので、その場合は拒否してpnpmで実行するように指示
- gemini 3 Pro (High)を基本的に使って開発したが、TypeScriptで
anyを連発する- これも
.agent/rulesに書いたが、割とanyを書く - anyを書いたことを確認したら
シバく優しく指摘する- LLMは統計確率的に人間の動きを模倣しようとするので、優しく指示するほうが動きがよくなりやすい
ツールなのに指摘しまくると精度が落ちるのでめんどいが、あまりにダメな時は別のチャットでやるとあっさり解決することがある
- これも
人間がきちんと注意しないで使うとどうなるか
- nodeなどを含め古いバージョンを使おうとする
- 依存関係は人間が確認したほうがよさそう
- DBのスキーマが
snake_caseとcamelCaseで混在します。しました(うわ~)- とはいえ完全に私が忘れていたこと
- その修正もLLMに投げて最後にプロジェクト全体検索で目視確認、migrationが動くのも確認とスムーズだったので、意外とそういう修正まで含めても理解がある人が触れば早い可能性はある
- 指示していない範囲のコードも弄ろうとすることが多々あるのでコミット単位やPR単位が大きくなりやすい
- もしかしたらLLMへの指示文で改善できる可能性はあるかも
- また、一指示に対して素早くコードの変更や追加が起きるので、結構な頻度でこまめなコミットを忘れがちになる
- 一人開発だから問題がないが、集団開発だと問題になりそう
- コンポーネント間でデザインの方針がずれることがあった
- 共通スタイルシートや
app/components以下のコンポーネントのstyleを参考にスタイルを書くように指示することである程度解決
- 共通スタイルシートや
- 基本的に言わなかったことを勝手にやることが多いので、少し冗長目に指示を出すといい
- AntigravityでのGemini 3 Proの特有の癖としてImplementation Planの提案後、質問をしただけで承認や拒否と受け取ることがあったので、「
明確な同意なしで勝手に先走って実装をしないこと。実装を開始する際には**明確な同意**をもって実装を開始すること」と指示
少し工夫して使ったところ
- 開発の流れを
./agent/docs/workflowに置いて、それを実行させる流れで実装させた - 同じく実装したものを
./agent/docs/walkthroughに書かせて、workflowとwalkthroughを見比べて実装してもらった - TSの型パズルは苦手。基本的に人間がやったほうがいい結果になる
コードレビュー
- CodeRabbitAIがいい感じ
- 修正したほうがいい場所をレビューしてくれるのだが、その際にLLM向けのプロンプトも一緒に吐き出してくれる
- GitHub Copilotは結構基礎的なレビューはするが、PR全体にまたがった文脈的なレビューはやや苦手か…?
- とはいえ基礎的なレビューも助かりはする
- ただCodeRabbitはほかのBotレビューを検知すると重複しないように動くので、CodeRabbit単体である程度指摘が尽きるまで使わず、最後に使うほうが結果的にいい可能性がある
所感
- LLMを多用するVibeコーディング的開発は「とりあえずコードを書く、とりあえず指示を出す」ではなく「ある程度LLMが参照可能なドキュメントを作る」を一番最初にやったほうがいいと思った
- 書き漏らしがあるとそこを突いてくるので、その都度ドキュメントを改定する覚悟が必要
- コーディングスタイルに対するガイドと、自動ドキュメンテーション追記、指示に対する動き方は最初のほうにきちんと書いておいたほうがよさそう。ある程度同じような技術スタックを多用するなら個人やチーム用にルールのテンプレートを作って・育てておくとスムーズな可能性がありそう
- 人間がある程度違和感に気づけない状態や「やるべきじゃない実装」を知らない状態でのVibeコーディングは極端に保守性を下げそうだと感じた
- 個人的にひとり開発においてCodeRabbitのようなAIコードレビューにはかなり可能性を感じた。Vibeコーディングはちょっと微妙という人でも、AIコードレビューはまず取り入れてみてもいいかもしれない
シェアする?