GEMINI Code Assist で vibe coding

前置き言い訳

整理しているといつまで経ってもアウトプットができないのと、そもそも状況が著しく変化するのもあって、メモ的な内容をそのまま書いています、とっ散らかってる感があり申し訳ないですがご容赦ください、後でまとめるかもしれませんし、しないかもしれません。加筆をするかもしれませんし、しないかもしれません。

vibe codingとは

Google検索での、AIの回答

「Vibe Coding（バイブコーディング）」とは、AI（大規模言語モデル）に自然言語で指示を出すことで、コードを生成・修正させ、アプリケーションを開発する新しいプログラミング手法です。従来のプログラミングのように、具体的な構文や文法を意識することなく、「こういう雰囲気のものが作りたい」といった、より抽象的な要望をAIに伝えるだけで、開発を進めることができます

Vibe Coding の特徴:

自然言語での指示:
開発者は、具体的なコードではなく、実現したい機能やUIの雰囲気などを自然言語でAIに伝えます。
AIによるコード生成:
AIが、伝えられた情報を基にコードを生成し、実装を行います。
開発者の役割の変化:
開発者は、コードを直接書くのではなく、AIの生成したコードをレビューし、必要に応じて修正を指示する役割を担います。
非エンジニアでも開発可能:
プログラミングの知識がなくても、アイデアを形にできる可能性が広がります。
開発効率の向上:
AIがコード生成を支援するため、開発スピードが向上する可能性があります。

Vibe Coding のメリット:

開発の民主化:
プログラミング知識がない人でも、アイデアを形にできる可能性があります。
開発効率の向上:
AIがコード生成を支援するため、開発スピードが向上する可能性があります。
アイデアの実現:
従来のプログラミングでは難しかった、抽象的なアイデアや感覚的な要望も、AIを通じて実現できる可能性があります。

Vibe Coding の注意点:

AIへの依存:
AIの能力に依存するため、生成されるコードの品質や、エラー処理など、注意が必要です。
学習コスト:
AIに指示を出すための適切なプロンプトを考えるスキルが必要になります。
`倫理的な問題:1
AIによるコード生成は、著作権やプライバシーの問題を引き起こす可能性があります。

Googleさんの回答は以上`

雰囲気でということでvibeとついているのでしょうかね。

どこまでできるのか

特徴のところで、自然言語で指示ができるとか、非エンジニアでも開発が可能ということなので、どこまでできるのか気になりました。
もちろん、今まで開発時に途中で分からないところを書籍やGoogleの代わりに使ってきていて、それなりにLLMの限界や可能性も認識しているつもりだった。
元々プログラマーな自分が今はサービス企画の真似事のような仕事をしていて、PoCの際にプロトタイプを作成して関係者のイメージ合わせや開発ベンダーに対して共通言語で話せるように実装の理解をしていたりする。
なので、開発ベンダーに依頼するつもりで Coding Agentを利用して自然言語の指示だけでどこまでできるのかを試してみたいと思った。

開発を始める

LLMを利用したCoding

リファクタリングのような多くのファイルを参照するような場合、しつこいぐらいに意図通りになっているか確認した方が良い

• 例えば、一貫性を保つためのリファクタリングなどは
  以前の修正が反映できていないとか、似たような修正は一緒にやってよと思っても無理なので、繰り返しチェックの依頼と反映が必要
• ただし、繰り返しチェックや修正を依頼したとしても、意図通りになるかは運次第w
  -　一例を挙げる
  • バックグラウンドではレイヤー構造にして責務分担を提案された。以下のように、なかなか良い構造なのでもちろん同意して実装を進めたのだが、提案してきたくせに、責務の分担を破りがちだったり、

レイヤー	ディレクトリ	責務
API (Router)	app/api/v1/	HTTPリクエストの受付、リクエストデータのバリデーション、適切なServiceの呼び出し、レスポンスの返却。
Service	app/services/	アプリケーションのビジネスロジックを実装。複数のRepositoryを組み合わせてユースケースを実現する。
Repository	app/repositories/	ビジネスロジックとデータ永続化層の間の抽象化レイヤー。DAOやStoreに依存し、データの永続化や取得をServiceに提供する。
DAO	app/dao/	Data Access Object。FirestoreへのCRUD操作など、特定のデータベースに特化したデータアクセス処理を担う。
Store	app/store/	Cloud Storageへのファイルアップロード/ダウンロードなど、オブジェクトストレージに特化した処理を担う。

• firestoreデータの扱い
  • 内部ではdictで扱っているのに、attributeアクセスするようなコードを生成してくる
  • 堅牢性を考えた時に、スキーマベースでやり取りをするのか、dictベースになるのかは悩ましい、明確な判断をしないと、中途半端なコードを出してくる。
  • 影響するすべての部分の更新が難しい、抜け漏れがあったり、こちらで修正した部分を認識していなかったりする

結局、この辺りは自前で修正することになりました‥

まとまった範囲の修正や追加

途中で機能追加やリファクタリングを行いたいといった場合がありました。
前節に記載した通り、広い範囲を同時に参照するような修正はかなり難航します。現状オートパイロットのように自動化は難しいと感じました。その上で対応する場合、どのようにしたのか試した方法を提示します。（この方法が幾分ましだったという程度で眺めていただければと思います）

とにかくチェックリスト

• 広い範囲でも、スコープを小さく保ちながら必要な修正を確実に行うには修正対象をリストアップして貰い、その対象で問題がないかを確認しながら進めるというのは、精神的にも、修正漏れや修正したくないところを勝手に修正されるということも最小限にできるという意味でも非常に効果的だったと思います
• 修正対象のスコープを小さく保てるということは、修正された内容が意図通りではない時の手戻りを最小化できること、誤って修正提案を適応してしまった場合の混乱を最小限にできること、修正提案が意図通りでない場合に修正指示をしやすいことなどがメリットとして感じました
• 一度に使うtokenを少なくできるので、コンテキストを失わずに作業ができるのと、もしtokenが不足したとか、一度作業を中断してといった場合でも、チェックリストを読ませることで最小限のコストで作業が継続できる
• うまくいく範囲であれば、プロンプトの提案もしてくれるので、それをクリックするだけで次々にタスクをこなしていける
• コンテキストが多くなると反応速度が遅くなるので、そんな時はセッションを一度クリアすると良かったりするので、そういう意味でも気兼ねなくクリアができる
• あえてデメリットを言うと、前述したような広範囲にまたがる修正をする場合、統一的な修正をすることが難しくなる。これは意図的に参照となるファイルを指定した上で、この修正と同じようにとか、より具体的な指示をしてあげる必要があります。とは言え、スコープを広げたとしても、統一感があるように修正できるかは運次第という面もあるので、スコープを小さくして、必要な時に必要となる詳細な指示をするのが良いと思います

ということで、個人的に一番のオススメ。

ドキュメント化

• https://gmo-aozora.hatenablog.com/entry/2025/07/24/142410
  仕様書駆動開発なんて言葉が出てきているようですが、わたしも仕様を適切に提示することで、LLMに対するコンテキストが明確になりうまくいくだろうと思い、仕様の作成から始めました。
• この方法は、前述のようなリファクタリングなどがなければ、結構スムーズに進むと感じました
• 個人的にはRFI的なものを作成して、そこからRFPを開発者（coding agent）に作成依頼していくようなイメージ
• 仕様書を作成しながらアジャイルで進めることができるとなかなかスムーズにことが進むと感じました
• RFPができたら、より具体的な仕様書を作成するが、そこは一気にでなく、フロントエンド、バックエンドに分けてとか依頼すると解像度が上がると思う
• 仕様書ができたら、その仕様をベースにチェックリストを作成するという流れ
• この方法であれば、新規プロジェクトではなく、途中から改修を行うというケースでもある程度対応が見込めると思う

仕様書が全部できないと先に進めないのは苦痛問題

• これはそれなりの大きさのシステムだと出てきそうな問題
• アジャイル開発で当然のように小さく始めるので、同じように必要な部分だけ記載して確認を進めれば良いと思う
• もちろん、大きくなってくると組み込む際のインパクトが大きくなってくるので、大きくなるほど大変になる。だからこそモダンな開発（小さな機能をサーバレスで作成して組み合わせていく）ような方法とも親和性が良いと思う（ただ、何度も言うようだが一貫性を持たせるような方法は結構難しい可能性があるけどね）

例）既存プロジェクトである機能（A）を追加する場合

• 既存プロジェクトのソースを確認して、仕様書を作成して貰う
• それに対して機能Aを追加する場合の影響範囲を調査して関連するファイルをリストアップしてといった依頼を行う
• テストが充実しているのであれば、テストファーストで、テストを作成して貰いつつ、影響範囲ごとにチェックリストを作成してと依頼する（GEMINIの場合、markdownファイルとして作成される）

開発ルール設定

• これうまくいくと思ったけど、coding agentに組み込まれたプロンプトが強力（邪魔をする）
• rule.mdと言う実装方針（ルール）を定めた文書を作成し、セッション（コンテキスト）が途切れた場合に読み込ませる方法をとっている。以下例

rule.md

# ドキュメントについて
※略（関連ドキュメント一覧）
# 実装方針について
実装するにあたり、以下に示すルールを守ること
- 一貫性を保つこと
  - ファイル名やディレクトリ名、モジュール名などを新規作成する際には、一貫性を持って命名すること
- 問題発生時の対処について
  - 原因が明らかではなく、推測を含む場合、必ずその推測を確かめてから次のステップに進むこと
  -問題の調査にあたっては、前提を明確にし確認をした上で進めるこ
と。さらに該当システム（バックエンドやフロントエンドなど）のみを調査するのではなく、常に全体をレビューし、影響範囲を横断的に分析

• 実はここに書いているルールを読ませてコンテキストに入れていても、残念ながら守られません
  • 推測を確かめてといっても、すぐ解決案をコードに適応して提示してくる
  • 前提なんか確認せず、すぐ解決案を提示してくる
  • デバッグの際に、原因を確認してから進めないと、修正がループした状態になることもあり、修正をして修正をすると元のようなコードに戻っているといったことが発生する
  • 修正案・解決案のサイズが大きいと、時間もかかるし、tokenも奪われるので泣きそうになります
  • coding agentに泣きながら尋ねると、そんな聞き方だからしょうがない、修正案が不要なら、「リストにして」と出力フォーマットを明記しろと言われました。なので、agentに依頼する際に言葉遣いに気をつけるようにしています。ただうっかり曖昧な依頼をすると、修正案が出てくるまで待たされるので、ぐぬぬとなることもしばしば
• gemini code assistの設定に、 Geminicodeassist Rulesというのがあるのですが、そちらで確認はしていません。ここに設定するともう少しマシになるのかもしれないので、後で確認してみようと思います

結局

• kiroがこの辺いいようにやってくれるんじゃないか
• https://dev.classmethod.jp/articles/kiro-getting-started/
• とも思うけど、もう少しノウハウが蓄積されるまで待つことになりそうに感じました（自身では試してないけども‥）→ノウハウ蓄積がagentの賢さをアップするという意図
• VSCode＋Gemini Code Assistで試したのですが、ソースへの反映がうまくいかないことも多く、この辺りもフラストレーションが溜まる点でした
• 今回はgeminiでしか試していないので、他のagentとの比較は時間があれば試してみたい
• 開発委託するというイメージになるので、細かい動きを理解できなくなる、よくこういう時どうなるのって聞かれたりするけど、自分で実装していると答えられるけど、委託していると委託先に聞かないとわかりません〜となるので、その辺りをどう考えるかという部分もありますね。もちろん、agentに聞けば良いでしょとなるのでしょうけど
• 今後はより開発があったとしてもテンプレ化され、自分はこうやってたとかこうやりたいとかは非効率に繋がっていくように思う。キーバインドをバッキバキにカスタマイズとかエディタをカスタマイズしまくりとかいう人たちが淘汰されてきたように…（個人の感想です〜）