バイブコーディングとは？やり方と注意点、リスク対策チェック表

バイブコーディング（Vibe Coding）とは、作りたいものを言葉で AI に伝え、生成されたコードの中身を細かく読まずに、動かした結果を見ながら対話で作り進めるやり方です。 思いついた道具をその日のうちに形にできる一方、長く使うコードでは、仕様とテストを人が持つことが欠かせません。

この記事では、用語の由来、依頼・確認・修正の各段階で使うプロンプトテンプレート、AI に守らせるルールファイルの記入例、似たやり方との違いと使い分け、リスク別の対策チェック表と検出コマンドの実行結果をまとめます。コードそのものの確認手順ではなく、進め方と向き不向きに絞っています。

確認環境（確認日 2026-10-06）：Ubuntu、Python 3.11.15、git 2.43.0、detect-secrets 1.5.0、pip-audit 2.10.1、pip-licenses 5.5.5、pytest 9.1.1、pytest-cov 7.1.0、npm 10.9.7。検出コマンドは、小さな見本のコードに対して実行した結果を載せています。プロンプトはひな形で、モデルの出力例は載せていません。

この記事の結論

• 試作や使い捨ての道具にはバイブコーディングが向きます。 長く保守するコードは、仕様とテストを人が握ります。
• 進め方は「依頼 → 確認 → 修正」の小さな往復です。1回の依頼は1つの変更に絞ります。
• AI に守らせる決まりはルールファイル（AGENTS.md など）に書きます。 毎回の依頼文に書かずに済みます。
• 秘密情報・依存パッケージ・テスト不足・ライセンスの4点は、コマンドで機械的に確かめます。

バイブコーディングの早見表

バイブコーディングの由来と定義

この言葉は、Andrej Karpathy 氏の2025年2月の投稿で広まりました。Simon Willison 氏の記事に引用されている投稿では、「雰囲気に身を任せ、コードが存在することさえ忘れる」やり方として紹介され、差分を読まずにすべて受け入れること、そして「使い捨ての週末プロジェクトには悪くない」ことが書かれています。

Willison 氏は同じ記事で、バイブコーディングを「LLM が書いたコードをレビューせずにソフトウェアを作ること」と整理しています。AI が書いたコードを人がレビューし、十分にテストし、動きを説明できるなら、それはバイブコーディングではなくソフトウェア開発だ、という区別です。

つまり、AI を使うこと自体がバイブコーディングなのではなく、「コードを読まずに受け入れる」点が特徴です。 同記事は、向く場面を考える観点として、不具合や脆弱性があったときの害の大きさ、従量課金のサービスを呼ぶかどうか、秘密情報や非公開データに触れるかどうかを挙げています。

似たやり方との違いと選び方

どれを選ぶかは、規模・寿命・扱うデータの3つで決めます。

バイブコーディングのやり方：依頼・確認・修正の3段階

題材は、架空の「備品の貸出一覧 CSV から、返却期限を過ぎた行を取り出す道具」です。

段階1：依頼のプロンプトテンプレート

最初の依頼で、目的・入力・出力・範囲・終わりの条件を渡します。雰囲気で進めるやり方でも、ここだけは言葉にします。

# 作りたいもの
{何を、誰が、いつ使うか を1〜2文で}

# 入力と出力
- 入力: {ファイル形式、列名、文字コード、見本を3行}
- 出力: {画面／ファイル／標準出力 と、その形}

# 範囲
- 今回やること: {1つだけ}
- 今回やらないこと: {後回しにする機能}

# 決まり
- 言語と版: {例：Python 3.11、標準ライブラリのみ}
- パッケージを追加したいときは、追加する前に名前と理由を示して確認を取る
- キーやパスワードはコードに書かず、環境変数から読む
- テストを1本以上一緒に書く

# 終わりの条件
- {例：見本の3行を入れると、期限切れの1行だけが出る}

最初に、作るファイルの一覧と手順を箇条書きで示してください。私が「進めて」と返してから実装してください。

記入例です。

# 作りたいもの
備品の貸出一覧 CSV から、返却期限を過ぎて未返却の行を取り出す。総務の担当者が週に1回使う。

# 入力と出力
- 入力: UTF-8 の CSV。列は item, due, returned。
  プロジェクター,2026-10-01,
  延長コード,2026-10-01,2026-09-30
  三脚,2026-10-10,
- 出力: 期限切れの行を標準出力に表示

# 範囲
- 今回やること: 期限切れの行の取り出し
- 今回やらないこと: メール通知、画面

# 決まり
- Python 3.11、標準ライブラリのみ
- パッケージを追加したいときは、追加する前に名前と理由を示して確認を取る
- キーやパスワードはコードに書かず、環境変数から読む
- テストを1本以上一緒に書く

# 終わりの条件
- 今日を 2026-10-06 とすると、プロジェクターの1行だけが出る

段階2：確認のプロンプトテンプレート

動かして結果を見た後、受け入れる前に AI 自身に説明させます。コードを全部読まない代わりに、変更の範囲と前提を言葉で受け取ります。

いまの変更について、次の順で答えてください。
1. 変更・追加したファイルの一覧（1行ずつ、何をしたか）
2. 追加したパッケージと、その理由（無ければ「なし」）
3. 私が指示していないのに変えた箇所（無ければ「なし」）
4. 入力が空、列が足りない、日付の形式が違う場合の動き
5. このコードが前提にしていること（文字コード、タイムゾーン、ファイルの場所）
6. まだ書いていないテスト
推測で答えた項目には「推測」と付けてください。

段階3：修正のプロンプトテンプレート

直してほしいときは、起きたことをそのまま貼り、範囲を1つに絞ります。

# 起きたこと
- 実行したコマンド: {そのまま貼る}
- 期待した結果: {…}
- 実際の結果: {エラー文や出力をそのまま貼る。キーやパスワードは伏せる}

# 頼みたいこと
- 原因の候補を、可能性の高い順に3つまで挙げる
- 直すのは {ファイル名／関数名} だけ。ほかのファイルは変えない
- 直す前に、同じ現象を再現するテストを先に書く
- 直した後、変更点を3行以内で説明する

同じ修正を3回頼んでも直らないときは、会話を新しく始めて、段階1のテンプレートに「分かっていること」を足して依頼し直すと進みやすくなります。

進め方のチェック表

AIに守らせるルールファイルの記入例

毎回の依頼に同じ決まりを書く代わりに、リポジトリに置くファイルへまとめます。AGENTS.md は、コーディングエージェントに文脈と指示を渡すためのオープンな形式で、リポジトリのルートに置きます。公式サイトでは、プロジェクトの概要、ビルドとテストのコマンド、コードスタイル、テストの手順、セキュリティ上の注意、コミットや PR の決まりといった見出しが例に挙がっています。サブフォルダにも置くことができ、編集中のファイルに最も近いものが優先されます。ツールによっては別の名前のファイルを読むので、使うツールの公式ドキュメントで読み込まれるファイル名を確かめてください。

# AGENTS.md

## このリポジトリについて
- 備品の貸出一覧 CSV を扱う社内向けの小さな道具
- Python 3.11、標準ライブラリのみ

## コマンド
- テスト: python3 -m pytest -q
- 網羅率つき: python3 -m pytest --cov=loan_tool --cov-fail-under=80

## 守ること
- 変更の前に計画を箇条書きで示し、確認を取ってから実装する
- 1回の変更は1つの目的に絞る。頼まれていないファイルは変えない
- パッケージを追加する前に、名前・版・理由・ライセンスを示して確認を取る
- キー・パスワード・トークンをコードやテストに書かない。環境変数から読む
- .env、secrets/ 以下、本番の設定ファイルは読まない・書き換えない
- 機能を足したら、同じ変更の中でテストも足す
- テストを通すためにテストの中身を弱めない

## 確認を取ってから行う操作
- ファイルの削除、git の履歴を書き換える操作、外部への送信

## 終わったら
- 変更したファイル、追加したパッケージ、書いていないテストを報告する

ルールファイルは「お願い」であって、必ず守られる仕組みではありません。次の章のコマンドで機械的に確かめる工程と組み合わせます。

リスク別の対策チェック表（コピペ用）

タブ区切り版です。先頭の列は確認済みの印を入れる欄です。

済   リスク 起きること   対策  検出に使えるコマンド例
    秘密情報の混入 APIキーやパスワードがコードや会話に入る   キーは環境変数か .env に置き、.env を .gitignore に入れる。AIに貼る前に値を伏せる   detect-secrets scan
    秘密情報の混入 コミット済みのファイルに残る  コミット前に追跡対象を検索する git grep -n -i -I -E "(api[_-]?key|secret|token|password)[a-z_]*\s*=\s*[\"'][^\"']{8,}"
    依存パッケージ 既知の脆弱性がある版が入る   版を固定し、追加のたびに検査する    pip-audit -r requirements.txt ／ npm audit
    依存パッケージ 頼んでいないパッケージが増える ルールファイルに「追加前に確認を取る」と書き、差分で依存ファイルを見る git diff -- requirements.txt package.json
    テスト不足   動いた画面だけ見て受け入れる  受け入れ条件を先に渡し、テストを一緒に書かせる python3 -m pytest -q
    テスト不足   通っていない行が残る  網羅率の下限を決めて、下回ったら止める python3 -m pytest --cov=パッケージ名 --cov-report=term-missing --cov-fail-under=80
    ライセンス   依存のライセンスを把握していない    一覧を出して、自社の規程で使えるものか確かめる pip-licenses --format=markdown
    ライセンス   生成されたコードが既存のコードと似ている    長い定型のコードは出どころを確かめ、判断は自社の規程と法務の確認に従う （人が確認）

ライセンスの扱いは法律上の助言ではありません。利用の可否は自社の規程と法務の確認に従ってください。

検出コマンドを見本のコードで実行した結果

次の見本に対して、チェック表のコマンドを実行します。トークンの値は見本用に作った偽の文字列です。

# loan_tool.py
"""備品の貸出一覧 CSV から、返却期限を過ぎた行を取り出す小さな道具。"""
import csv
from datetime import date

API_TOKEN = "ghp_R4nd0mExampleTokenValue1234567890abcd"   # 見本用の偽の値


def overdue(rows, today):
    return [r for r in rows if r["returned"] == "" and date.fromisoformat(r["due"]) < today]


def load(path):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

# test_loan_tool.py
from datetime import date
from loan_tool import overdue


def test_overdue_picks_only_unreturned_past_due():
    rows = [
        {"item": "プロジェクター", "due": "2026-10-01", "returned": ""},
        {"item": "延長コード", "due": "2026-10-01", "returned": "2026-09-30"},
        {"item": "三脚", "due": "2026-10-10", "returned": ""},
    ]
    assert [r["item"] for r in overdue(rows, date(2026, 10, 6))] == ["プロジェクター"]

# requirements.txt（脆弱性検査の見本として、以前の版を指定）
requests==2.25.0

秘密情報：detect-secrets と git grep

pip install detect-secrets
detect-secrets scan loan_tool.py

出力の results の部分です。

{
  "loan_tool.py": [
    {
      "type": "Base64 High Entropy String",
      "filename": "loan_tool.py",
      "hashed_secret": "cb9a80b69b52652510deeb7d831b451109e682d9",
      "is_verified": false,
      "line_number": 5
    },
    {
      "type": "GitHub Token",
      "filename": "loan_tool.py",
      "hashed_secret": "e175c6f5f2a92e8623bd9a4820edb4e8c1b0fd10",
      "is_verified": false,
      "line_number": 5
    }
  ]
}

道具を入れずに確かめるなら、git の追跡対象を正規表現で検索します。

git grep -n -i -I -E "(api[_-]?key|secret|token|password)[a-z_]*\s*=\s*[\"'][^\"']{8,}"

loan_tool.py:5:API_TOKEN = "ghp_R4nd0mExampleTokenValue1234567890abcd"   # 見本用の偽の値

見つかった行があると終了コードは 0、無ければ 1 です。

依存パッケージ：pip-audit と npm audit

pip install pip-audit
pip-audit -r requirements.txt --no-deps --disable-pip

Found 8 known vulnerabilities in 1 package
Name     Version ID              Fix Versions
-------- ------- --------------- ------------
requests 2.25.0  PYSEC-2023-74   2.31.0
requests 2.25.0  PYSEC-2023-74   2.31.0
requests 2.25.0  PYSEC-2026-1873 2.32.0
requests 2.25.0  PYSEC-2026-1872 2.32.4
…（省略）…

見つかると終了コードが 1 になるので、そのまま自動チェックに組み込めます。Node.js では、lodash 4.17.15 だけを依存に持つ見本で npm audit を実行すると次の表示になりました。

# npm audit report

lodash  <=4.17.23
Severity: high
…（省略）…
fix available via `npm audit fix`
node_modules/lodash

1 high severity vulnerability

テスト不足：pytest と網羅率の下限

pip install pytest pytest-cov
python3 -m pytest -q --cov=loan_tool --cov-report=term-missing --cov-fail-under=80

Name           Stmts   Miss  Cover   Missing
--------------------------------------------
loan_tool.py       8      2    75%   13-14
--------------------------------------------
TOTAL              8      2    75%
FAIL Required test coverage of 80% not reached. Total coverage: 75.00%
1 passed in 0.02s

テストは1本通っていますが、CSV を読み込む load 関数（13〜14行目）が一度も実行されていないため、下限の 80% に届かず終了コードが 1 になりました。「テストが通った」と「必要な箇所がテストされた」は別のことだと分かります。80% は例の値です。

ライセンス：pip-licenses

pip install pip-licenses
pip-licenses --packages pytest detect-secrets pip_audit pytest-cov --format=markdown

| Name           | Version | License                 |
|----------------|---------|-------------------------|
| detect-secrets | 1.5.0   | Apache Software License |
| pip_audit      | 2.10.1  | Apache Software License |
| pytest         | 9.1.1   | MIT                     |
| pytest-cov     | 7.1.0   | MIT                     |

--packages を外すと、入っているパッケージすべてが一覧になります。

注意点：試作を残すと決めたときにやること

バイブコーディングで作ったものが好評で、そのまま使い続けることになる場面はよくあります。そのときは次の順で足していきます。

1. 何をする道具かを文章にする（入力・出力・やらないこと）。
2. 受け入れ条件をテストにする。 いま動いている振る舞いをテストで固定します。
3. コードを通して読む。 説明できない箇所は AI に説明させ、納得できなければ書き直させます。
4. チェック表の4点をコマンドで通す。
5. 秘密情報と設定をコードの外に出す。
6. 以降の変更は、人が読んで受け入れる流れにする。

確かめて分かったこと

• detect-secrets は、同じ1行を2種類の検出（高エントロピー文字列と GitHub Token）として報告しました。 件数は「秘密情報の数」ではなく「検出の数」として読みます。
• git grep の簡単な正規表現でも同じ行が見つかりました。 ただし変数名に token や password などの語が入っている場合に限られるので、専用の道具と組み合わせます。
• pip-audit は同じ ID を2行ずつ表示しました（8件のうち ID は4種類）。対応の数は ID で数えます。
• テストが全部通っていても、網羅率の下限で止まりました。 読み込みの関数のように「動かして見ただけ」の部分が数字で見えます。
• pip-audit と pytest の下限指定は、問題があると終了コードが 1 になりました。 人が出力を読まなくても、自動チェックで止められます。

よくある質問

Q. バイブコーディングとは何ですか？ A. 作りたいものを言葉で AI に伝え、コードを細かく読まずに、動かした結果を見ながら対話で作るやり方です。2025年2月の Andrej Karpathy 氏の投稿で広まりました。

Q. バイブコーディングと AI支援コーディングの違いは何ですか？ A. 生成されたコードを人が読んで受け入れるかどうかが違います。読んで、テストして、説明できる状態にするなら AI支援コーディングです。

Q. バイブコーディングと仕様駆動開発の違いは何ですか？ A. 先に文書を書くかどうかが違います。仕様駆動開発は要件・設計・タスクを文書にしてから実装させ、バイブコーディングは対話しながら形にします。

Q. プログラミングの経験が少なくてもできますか？ A. 試作や自分用の道具なら始められます。ただし、残して使うと決めた時点で、仕様・テスト・秘密情報の扱いを確かめる工程が要ります。

Q. AI が同じところを直せないときはどうしますか？ A. 会話を新しく始め、分かっている事実（エラー文、試したこと）を整理して依頼し直します。範囲を1つの関数まで絞ると進みやすくなります。

まとめ

• バイブコーディングは、言葉で伝え、動かして、対話で直すやり方です。特徴は「コードを細かく読まずに受け入れる」点にあります。
• 試作や使い捨ての道具に向きます。 長く保守するコードは、仕様とテストを人が握ります。
• 依頼・確認・修正のテンプレートで、1回1変更の小さな往復にします。
• 決まりはルールファイルに書き、機械的な検査と組み合わせます。
• 秘密情報・依存パッケージ・テスト不足・ライセンスの4点は、コマンドで確かめます。
• 残すと決めたら、仕様とテストを書き足して流れを切り替えます。

参考・出典

• Simon Willison「Not all AI-assisted programming is vibe coding (but vibe coding rocks)」（2025-03-19。Andrej Karpathy 氏の投稿の引用を含む） https://simonwillison.net/2025/Mar/19/vibe-coding/
• AGENTS.md 公式サイト https://agents.md/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。