自分なりのPOC用途のバイブコーディングのすすめ方
この記事は人間が記述し個人的な主観に基づいている点に注意してください。
使っているもの：VsCode x Cli版ClaudeCode（Opus4.1）＋Codex
前提条件
- 商用リリースはしません
- クローズド環境でのプロダクトの内部お披露目までがゴールです
- 商用リリースまでにはシニアエンジニア全チェックと網羅的テスト、セキュリティチェックとまだまだ道のり長いのでそこは考慮しません
- ぶっちゃけこの工程で作ったコードは捨てるのでむしろBDDなどの仕様が固くなることとインフラ検証が終わってるのでコスト試算ができることこそが成果物だと感じています
基本的な流れ
- 仕様駆動型にプラスして先にインフラを決定します
- 大きな流れは先にインフラ決定、仕様作成、コード開発の流れ
- AIが作るコードのスコープを狭めて人間が逐一確認するスタイルです
- 仕様はざっくり人間が指示出し後に詳細はAIに文書を作成してもらっています
- POCなので人間は極力省力化して会議に参加している間にAIに１仕事してもらうように下準備します、会議前に５つくらい並行起動したAIに指示をだしていくのが現代的なITエンジニアだとおもってください（うそです）
- なるべくAIに考えてもらうし、書いてもらいます。人間はその間AIが解答したわからない技術用語の説明を別のAIに教えてもらいます
1. 作業分類をする
作業のボリュームにあわせてGitの作業Branchと作業用のディレクトリを作成、下記の例だと６つ。
Web３層構造の作業分類例
- インフラ＋パイプライン
- フロント
- BFF層のAPI
- アプリケーション層
- DB
- コード開発
- フロント
- BFF層のAPI
- アプリケーション層
細かく分ける理由はAIのビックバン修正で意図しないところの修正の防止のためとそれぞれの作業で個別のルールを与えたたいためです。
また以下の作業分類が全部１セッションで上手くいかずに必ず手戻りが入るのでそのさいはその手戻り用のBranchを切っています、この辺はGitのBranch戦略にあわせてやるのがいいかと思います。
ポイント
- セッションあたり２時間程度を目安にしてください、会話の量にもよりますが圧縮が入る前に人間の目けんチェックで60%合格であればいいです
- セッションの終わりに振り返りをして文書にまとめさせます、このさいにまちがったことなどもAIに記述してもらいます
- これはAIは長期記憶がないのでその補填です、人間がしつこくAIが嵌った箇所を（いらいらした記憶と共に）覚えているもんですがAIはさすがに間違って悔しいとかはないので再起動したら綺麗さっぱり忘れて同じ事繰り返します、なのでその時にはこのときに書いた文書を読み直してねと言ってあげると良いです
2. インフラとパイプラインの構築
自分は初めにインフラを決定してから実際のコード作成をおこなっています。
これはインフラ構成を決めずにコードの記述を始めると手戻りが多く、機能の細部を考えているタイミングで分断されると復帰に時間がかかると感じているためです。
AIとの共同は自分の何万倍も知識があるもの（？）へのディレクション作業で正解をだしてもらうために人間もそれなりに苦労すます、そんな中で思考が妨げられるのは防ぎたいところです。
とはいえパイプラインの中身まではこの時点で決まっているわけもないのでその辺は後々いじる前提です。
大体の流れ
- 技術スタックを決定（ここではTerraform、Git Hub Actions）しADRとして文書で残す
- 秘匿情報の取り扱いなどをルールに追記
- インフラ構成決定：IaC（Terraform）で記述してGitHubActionsでクラウドにアップするパイプラインをAIに組んでもらう
- いったんクラウドインフラにHello World相当のコード資材があがるのを確認
- フロント→API→アプリケーション→DBの簡単な連携テストを実施
- Gherkinフォーマットでペネトレーションテストのシナリオを作成して実施
ポイント
- 別にTerraformでなくてもいいですが IaC必須です。人間が書くより100倍はやいです
- オンプレ？スコープ外です
- IaCはコードが正確でもいろんな理由でこけるのでこけたら人間がコンソール画面で目視チェックしてAIに伝えますこの辺はまさにAIと人間の共同作業ですね（人間がAIの丁稚をしてるともいう）
- ちなみにClaude Codeは画像を解釈するので管理画面をスクショしてドラッグ＆ドロップで状況把握してくれます
- ペネトレーションテストも後述のGherkinフォーマットでAIに作成してもらっています、BDDは本来そういった目的ではないですが人間が読みやすくAIがどこで間違えているかを人間が理解するのに役立ちます
2. 仕様の作成
- AIに仕様の作成を明示します、作成物は下記の通りです
- 5w1H
- Gherkinフォーマットでのシナリオ作成
- Mermaidを使った業務フロー図
- AIに資材の詳細設計をしてもらいます
- DBスキーマ
- アプリケーション層のインターフェース
- BFF層API
- フロント層の画面設計
- AIにコード開発のための技術選定をしてもらいます
- フロント、BFF層API、アプリケーションで検討しADR文書を作成
- 選定技術により簡単なコードを作成しパイプラインの修正箇所を洗い出し
- GitHub Actionsのworkflowsを修正
ポイント
- 人間の指示の曖昧さを補填するのに時間を使います
- またこの先の工程で何回かAIの暴走によるビックバン修正が起こるので、仕様を作成しておくことでここまで積み重ねた地点に戻ってやり直すことができます
- 個人的な感触ですがGherkinでテストシナリオを作るのがAIでのコーディングにかなり効くような気がしています
- Gherkinのテストシナリオの作成には必ず失敗するケースも書いてもらうようにしましょう
3. 機能開発コーディング
- AIに全ての機能のクラス名を考えてもらいます
- どの準で開発すればいいか提案してもらいます
- 通過しないテストを書いてもらいます
- 通過するテストを書いてもらいます
- 連携テスト用のローカルテスト資材を作成してもらい、連携テストを実施してもらいます
- 改めてセキュリティの確認をし、公開範囲を確認し全世界に公開していないか確認します
- 必要なDB更新のGitHub Actions を動かします
- アプリケーション層の資材をデプロイします
- BFF層APIの資材をデプロイします
- フロント層の資材をデプロイします
- 出来上がりを人間が目視します
ポイント
- 2と３の工程の精度が高いと実装は一瞬で終わります、この辺は本当にAIのすごいところです
- 上記の工程は商用にあげない事を前提とすると少し冗長かもしれないです
- PlayWrightを使ったE2Eテストも組み込みしたいところですがまだ検証中なのでいれていません
まとめ
「商用にあげない前提なら、AIに適当に指示だしして正解がでるまでAIガチャすればいいじゃん」って意見あるかと思いますがそれはごもっともです。
バイブコーディングをしたプロダクトが商用化を目指さないならばそれでいいと思います。
このやり方は仮組したPOCの成果物を本格的な商用化に向けた作業に向けてなるべく良い状態で渡すことを目標にしています。
以上現場からでした