バイブコーディングとは？AIで開発する考え方を解説

バイブコーディングとは、作りたいものを自然言語でAIへ伝え、生成されたコードを実行して結果を見ながら修正する開発の進め方です。小さな試作品を早く形にするには便利ですが、動いたことと、安全に運用できることは別です。公開・課金・個人情報・認証に関わる機能では、コード差分、テスト、権限、障害時の動きを人が確認してください。

「バイブコーディング」は決まった開発規格ではない

この言葉は、AIに実装を任せて結果を確かめながら進めるスタイルを表します。使う人によって意味の幅があり、AI補助を使う開発全般を指すこともあれば、コードをほとんど読まずに試行錯誤するやり方を指すこともあります。特定の工程や品質保証を定めた標準規格ではありません。

そのため、「バイブコーディングを使った」と聞いただけで、AIへどこまで任せたか、誰が検証したかは分かりません。仕事で使う場合は用語より、変更した範囲・確認方法・責任者を記録する方が役立ちます。

AIに任せる範囲は、失敗したときの影響で決める

表は横にスクロールできます

作業	まず試しやすい進め方	公開・運用前に人が見る点
画面のたたき台、捨てられる試作品	画面を作り、実際に触って改善する	想定利用者が目的の操作を完了できるか
社内向けの小さな補助ツール	入出力と利用者を限定して試す	誤入力、権限、保存先、バックアップ
認証、決済、個人情報を扱う機能	AIに案を作らせても、設計・レビューを先に置く	認可境界、秘密情報、ログ、失敗時の処理
顧客へ公開する機能	小さく分けて実装し、検証環境で確認する	回帰テスト、監視、復旧手順、責任者

これは「AIを使える／使えない」の区分ではありません。戻せる試作品なら速さを優先しやすく、失敗が利用者やデータへ波及するほどレビューと検証を厚くする、という判断表です。

一度に頼まず、成果物と確認条件を小さく区切る

「便利な顧客管理アプリを作って」だけでは、AIが想定する画面、データ構造、権限、保存方法が依頼者の意図とずれる可能性があります。最初の依頼には、目的・利用者・入力・出力・対象外・成功条件を入れます。

たとえば、次のように依頼を分けられます。

> 目的：社内イベントの参加者一覧を確認する試作品を作る。

> 利用者：担当者1人。公開範囲：ローカル環境のみ。

> 入力：名前と参加可否を手入力。実在の個人情報は使わない。

> 出力：参加者数と一覧。永続保存、ログイン、外部送信は今回の対象外。

> 成功条件：追加・編集・削除ができ、入力が空の場合に説明が出る。

> まず画面とデータの流れを提案し、合意後に実装する。

この例は仕様の切り方を示すもので、実際に動作確認した製品の説明ではありません。はじめから外部送信や実データを入れないことで、試作品の検証と本番設計を混ぜずに済みます。

試作品を作るときのループ

1. 一つの利用場面を選ぶ。 何を入力し、何を得たいのかを一文で書きます。

2. 制約を伝える。 使用技術、触ってよいファイル、変更禁止箇所、使ってはいけない実データを指定します。

3. 実装単位を小さくする。 最初は画面の骨組み、次に入力と表示、最後に保存など、差分を追える単位に分けます。

4. 生成物を実行する。 画面を見るだけでなく、通常入力、空欄、境界値、誤った形式も試します。

5. 結果を根拠と一緒に返す。 「動かない」だけでなく、入力、操作、表示された結果、エラーを伝えて修正します。

6. 変更を読み返す。 AIの説明ではなく、実際の差分と実行結果で、依頼外の変更や不要な依存追加がないか確認します。

一度に複数の問題を直させると、どの変更が結果を変えたか分かりにくくなります。直す対象と合格条件を一回ごとに絞ると、やり直しもしやすくなります。

「動いた」の次に見るべき失敗パターン

• 要件の取り違え： 見た目は完成していても、必要な入力や例外処理が欠けている。依頼文と画面を対応させ、条件ごとに確認します。

• 誤ったデータ処理： 表示はできても、保存・更新・削除の対象が違う。試験用データで操作前後を比べます。

• 権限や秘密情報の混入： APIキーを画面側へ置く、アクセス制限を付けないなど。秘密情報はクライアントへ渡さず、認証・認可の境界を設計者が確認します。

• 依存関係や既存機能への影響： 新しいライブラリや共通部品の変更で、別画面が壊れる。変更理由を確認し、関連テストを実行します。

• 失敗時に止まらない： ネットワーク切断や不正入力で、誤った状態を保存する。失敗を表示し、再試行・取消し・復旧方法を確認します。

AIが作ったコードには、もっともらしい説明と実際の挙動が一致しないことがあります。説明文を検証結果として扱わず、diff、テスト、画面、ログを照合してください。テストが通っても、要件にない動作や運用手順の欠落までは保証しません。

試作品から本番へ移すときの引き継ぎ

試作品を残すと決めたら、まず「何を検証できたか」と「未確認のまま残したこと」を分けます。少なくとも、利用者、データの保存場所、外部通信、権限、運用責任者、障害時の連絡・復旧を決めます。仮の認証やローカル保存を本番仕様として流用しないでください。

次に、生成されたコードを読み、依存関係、入力検証、エラー処理、アクセス制御、テストを人が確認します。決済や個人情報のように影響が大きい範囲では、担当者レビューを省略せず、必要なら小規模な試験公開を挟みます。AIに説明やテスト案を作らせることはできますが、公開判断の責任は運用者に残ります。

AIものさしの判断

バイブコーディングは、コードを速く作る方法というより、短い指示と実行結果を往復する開発スタイルです。捨てられる試作品では、その速さを活かしやすいでしょう。一方、利用者データ、権限、決済、長期運用が関わるなら、AIに実装を任せる範囲と人が承認する範囲を先に分けます。

始める前に、①試作品か運用機能か、②使うデータは実データか、③失敗時に誰へ影響するか、④何を確認すれば合格か、を決めてください。失敗しても戻せる小さな作業なら試し、戻せない変更や高い影響がある作業は、コードレビューとテストを通してから進めるのが現実的です。

変更を依頼するときの小さなレビュー表

AIが次の変更を提案したら、作業前後でこの表を埋めると「何を直したのか」を追いやすくなります。

表は横にスクロールできます

確認欄	作業前に決めること	作業後に照合すること
目的	誰のどの作業を短くするか	目的の操作が実際に完了するか
変更範囲	変更してよい画面・ファイル	依頼外のファイルや設定も変わっていないか
データ	入力例、保存先、機密性	送信先、保存内容、削除動作が説明と一致するか
失敗時	エラーをどう知らせるか	通信失敗や空欄で誤った成功表示をしないか
合格条件	目で見て分かる条件とテスト	条件ごとに結果を記録したか
戻し方	試作品を捨てる方法	変更前へ戻せる状態か

たとえば一覧画面なら、「画面が出る」だけでなく、空の一覧、1件、長い名前、重複入力、削除後の表示まで確認します。最初にこうした境界を決めておくと、AIが見た目だけを整えて終わるのを防ぎやすくなります。

本番利用へ進める判断

次の条件がすべて揃っていない場合は、利用者へ公開せず、試作品として扱います。

• 対象利用者とデータの種類が明確

• 保存先と外部送信先が把握できる

• 認証・認可を誰が確認したか分かる

• 主要な通常系と失敗系を再現できる

• 変更差分と依存追加をレビューできる

• 問題が起きた際の停止・復旧担当が決まっている

足りない項目があれば、いきなり「AIにもう一度直させる」のではなく、まず未決事項として書き出します。たとえば保存先が未定なら、データベース実装を先に追加するのではなく、保存しない試作品の範囲で検証する、という選択ができます。

このチェックリストは全案件の安全を保証するものではありません。扱う情報や利用者数、外部連携によって追加の審査が必要です。

AIへの追加指示で避けたいこと

不具合を見つけた直後に「全部作り直して」と頼むと、必要な部分まで変更され、原因の切り分けが難しくなります。先に再現手順と期待結果を短く書き、対象箇所だけを直すよう頼みます。変更後は、差分に加えて実行した確認と未確認項目を回答させます。

また、「セキュリティを万全に」「絶対に壊れないように」といった抽象的な指示は、検証可能な条件ではありません。どの利用者のどの操作を許可するか、どの入力を拒否するか、秘密情報をどこに置くかのように、判断できる形にします。

実務では、AIへ実装を任せる前に「変更しない範囲」も伝えてください。たとえば既存のURL、データ形式、認証方式を変えず、まず現在の作りを調べるように頼みます。依頼が大きいときは、調査結果、実装案、変更、検証を順に出してもらい、各段階で記録を残します。これはAIの能力を制限するためというより、作業の影響範囲を人が追える状態に保つためです。試作品では完成度より学びを得ることが目的ですが、公開する段階では、その試作品に含まれる仮定を一つずつ本番条件へ置き換える必要があります。

引き継ぎメモには、作ったものの用途、利用できる人、試した入力、確認済みの動作、未確認の動作、既知の不具合を残します。次の担当者がコードだけを見て意図を推測する必要を減らせます。AIに生成させたREADMEも、実装と一致しているか照合してから共有してください。

公開範囲が広がる変更では、試作品の利用者にも「未検証の機能」と「入力してはいけない情報」を伝えます。検証環境でも、アクセス権を必要最小限にし、実在の顧客情報や秘密鍵を貼り付けない運用を続けてください。