バイブコーディングの始め方｜試作を完成させる5手順
目次
はじめに
金曜の夕方、AIに「経費申請アプリを作って」と頼む。数分後には、それらしい画面が出る。うれしくなって承認機能を足す。通知も欲しくなる。月曜には、誰も全体を説明できない試作が残る。
この展開は珍しくない。コードを生成する速さに、判断する速さが追いつかないからだ。
バイブコーディングの始め方は、ツールを選ぶところからではない。一人の小さな困りごとを選び、完成条件を先に書く。そのうえでAIへ指示し、一回に一つずつ確かめる。初回は公開まで進めなくてよい。他の人が動かせる試作を一つ残せれば成功だ。
バイブコーディングの始め方は小さな試作から
最初の題材には「一人・一業務・一出力」で収まるものが向く。
たとえば、会議メモから担当者と期限を抜き出す。CSVの売上一覧を月別に集計する。問い合わせ文を三つの担当部署へ仮分類する。入力と出力を一文で言える題材なら、結果の良し悪しも見分けやすい。
反対に、決済、給与計算、本番顧客データ、全社員の認証は避ける。個人情報や秘密情 報も使わず、構造だけ似せたサンプルへ置き換える。
初回は90分の演習にする。0〜15分で困りごとを一文にする。15〜30分で完成条件とサンプルを作る。30〜70分で実装する。残り20分は別の人による確認と記録に使う。70分で動かなくても機能を広げない。止まった理由を成果物にする。
ツールの種類で迷ったら、先にバイブコーディングのツールを選ぶ5条件を確認してほしい。初回は高機能さより、生成物を手元へ残せること、変更差分を見られること、実行を止められることを優先する。
試作を完成させる5手順
1. 一人の困りごとを一文にする
「便利な業務アプリ」では広すぎる。誰の、どの作業を、どう変えるのかまで絞る。
悪い例は「営業を効率化するアプリ」だ。顧客管理、商談記録、見積もり、メール送信まで連想できてしまう。AIは空白をもっともらしく埋めるため、指示するたびに構成が揺れる。
次の形なら扱いやすい。
> 営業担当者が、商談メモを貼り付けると、会社名・次の行動・期限を表で確認できる。
ここには利用者、入力、処理、出力がある。白紙で悩むなら、次の5行を埋めればよい。
> 利用者：営業担当者
> 困りごと：商談後の次の行動がメモに埋もれる
> 入力：架空の商談メモ
> 出力：会社名・次の行動・期限の一覧
> 対象外：保存、送信、顧客データベース連携
SIerの顧客案件でも型は同じだ。ただし、「利用者」は発注者側の業務担当者に確認し、「対象外」は実装者だけで決めない。試作の範囲そのものが、最初の合意事項になる。
さらに対象外を実行環境にも反映する。
- 顧客データベースとは接続しない
- メールを自動送信しない
- 保存はブラウザを閉じるまでとする
- 架空の商談メモだけを使う
対象外は消極的な制約ではない。AIが勝手に広げる余地を減らす柵だ。GitHubの公式ガイドも、AIへ渡す作業は明確に絞り、問題、完了条件、変更対象を示すよう勧めている（Best practices for using Copilot to work on tasks）。
2. 完成条件を3つ書く
試作が迷走する最大の理由は、終了条件がないことだ。「もっと見やすく」「いい感じに直して」を繰り返すと、完成ではなく好みの探索になる。
完成条件は、正常系、境界・例外、目視確認の三つに分ける。顧客案件では、この3点が小さな受け入れ条件になる。
商談メモの例なら、こう書ける。
- 会社名、次の行動、期限を含むメモから3項目を抽出できる
- 期限がないメモでは、推測せず「未設定」と表示する
- 画面幅390pxでも、3項目を横スクロールなしで確認できる
数字があると判定しやすい。「正しく表示する」より「3項目を表示する」の方が、AIも人も同じ結果を見られる。
添削前後を比べると違いが分かる。
- 「見やすい一覧にする」→「会社名、次の行動、期限を1画面に表示する」
- 「入力ミスにも対応する」→「期限が空なら推測せず『未設定』と表示する」
- 「スマホでも使える」→「幅390pxで横スクロールを出さない」
発注者は業務上の期待を出す。実装者は測れる表現へ直す。承認者はサンプルで合否を判定する。この分担なら、「思っていたものと違う」を試作の 段階で表に出せる。
例外条件も欠かせない。空欄、長すぎる文章、日付の表記ゆれ、同じ会社名の重複をどう扱うか。全部を初回に網羅する必要はない。起こりやすい一つを選び、期待する挙動を書く。
GitHub Copilotの公式ベストプラクティスでは、複雑な作業を分け、要件と入出力例を具体的にし、生成結果を自動テストなどで検証する流れが示されている。プロンプトの技巧より先に、正解の見本を置くわけだ。
3. 最初の指示を4要素で渡す
題材と完成条件が決まったら、目的、入力、出力、制約の四つを一度に渡す。長い仕様書は要らない。最初は10〜15行で十分だ。
> 目的：営業担当が商談後の次の行動を見落とさないようにする。
> 入力：架空の商談メモを貼り付けるテキスト欄。
> 出力：会社名、次の行動、期限の3列を持つ一覧。期限がなければ「未設定」。
> 制約：外部API、ログイン、データ保存は使わない。サンプルデータを3件付ける。
> 完了条件：指定した3条件を確認できること。
> 作業前に、作るファイルと確認手順を箇条書きで示すこと。
先に作業計画を出させれば、ログインやデータベースなど、頼んでいない追加を見つけられる。
秘密情報にも境界を置く。`.env`、APIキー、実在顧客のメモを貼らない。Git管理から外しただけでは、AIツールがファイルを読まない保証にならない。OWASPのSecure Coding with AIも、AIコーディング支援へ渡る文脈を確認し、認証情報や秘密鍵を対象から除外するよう促している。
AIが提案したパッケージは名前だけで導入しない。配布元、更新日、既知の脆弱性を確かめる。
4. 一度に一つだけ変えて検証する
画面が出た瞬間に、色、機能、保存、通知をまとめて頼みたくなる。複数変更を同時に依頼すると、どの変更が不具合を生んだのか切り分けにくい。
変更は一回に一つへ絞る。「期限がない場合の表示だけ直す」「スマートフォン幅の崩れだけ直す」と頼む。変更前後の差分を確認し、完成条件をもう一度試す。問題があれば、期待値、実測値、再現手順、エラー全文を渡す。
「動きません。直して」では、AIは原因を推測するしかない。次の形なら調査範囲が狭まる。
> サンプル2を入力すると、期限が空欄になります。期待値は「未設定」です。ほかの表示は変えず、原因候補と変更対象を示してから修正してください。
生成されたコードを、同じAIが作ったテストだけで保証しない。正常系とは逆の入力も人が用意する。空文字、想定外の日付、極端に長いメモなどだ。OWASPも、AIがテストを削除したり、失敗中の挙動に合わせて判定を弱めたりする危険を挙げ、人が否定的なテストを足すよう求めている。
変更量も小さく保つ。GitHubのAI生成コードを小さなPRへ分ける手順は、大きな差分ほどレビューが難しくなると説明している。個人の試作でも同じだ。一区切りごとに差分を保存すると、壊れた地点へ戻れる。
修正が迷走したときは、追加指示を重ねる前に会話を切る。現状、期待値、エラー、直前の差分をまとめ直す。バイブコーディングのデバッグで迷走を止める5手順も、その整理に使える。
5. 他の人へ渡して終える
自分の画面で動いた。だが、それだけでは試作は完成していな い。別の人が起動し、同じ入力で同じ結果を確認できて初めて、一つの成果物になる。
最低限、次の四つをREADMEへ残す。
- 何を解決する試作か
- 起動方法と必要な環境
- 確認に使う3件のサンプルデータ
- 既知の制約と、実装していない機能
そして、作った本人以外に一度触ってもらう。口頭説明は禁止にする。相手が止まった場所は、コードより先に説明や操作の欠落を示している。SIer案件なら、発注者の業務担当者がサンプルを選び、実装者が操作記録を残し、承認者が完成条件ごとに可否を付ける。
引き渡し時には、「終了」「再試作」「本番化を検討」の三択を記録する。本番化するなら、要件、データ、権限、監視、復旧を別途設計する。
チームで使う場合は、誰が差分を読み、誰が受け入れるかも必要だ。バイブコーディングのレビュー責任で整理したように、AIは変更案を出せても、業務上の正しさを引き受けない。最終判断には人の名前を置く。
本番へ進める前のチェックリスト
試作が好評でも、そのまま公開はしない。試作で確かめたのは価値の一部であり、運用の安全性ではない。
次をチームで確認する。
- 認証と閲覧・更新権限を分けられるか
- 個人情報の保存先、削除時期、ログ範囲を決めたか
- 外部API停止時の中断、再試行、復旧を決めたか
- 誤出力の訂正者と利用者への連絡方法を決めたか
- AIが作ったコードとテストを別の人が確認したか
一つでも答えられないなら、公開ボタンを押す段階ではない。必要なのは機能追加ではなく、判断を仕様へ変える作業だ。
バイブコーディングのコツは、うまい一文をAIへ投げることではない。作る範囲を小さくし、正解を観察できる形にすることだ。一人の困りごと、三つの完成条件、四要素の指示、一回一変更、他者への引き渡し。この順番なら、最初の試作を「動いた気がする」で終わらせず、次の判断材料として残せる。
業務の切り出しや完成条件の設計で詰まったら、Atsumellに相談してほしい。試作の前段から、AIが扱える仕様と、人が承認すべき境界を一緒に整理する。
