vibe codingとは何か — Claude Codeでの安全な始め方

vibe codingとは

vibe coding(バイブコーディング)とは、AIに実装の細部を委ね、コードの中身を細かく確認せずに開発を進めるスタイルを指す言葉です。人間はやりたいことを自然言語で伝え、動くかどうかを結果で判断します。

この語を最初に使ったのはAndrej Karpathy(元TeslaのAI部門責任者、OpenAI共同創業メンバー)です。2025年2月2日の投稿で、次のような開発スタイルをvibe codingと名付けました。

「バイブスに完全に身を任せ、指数関数的な進化を受け入れ、コードの存在を忘れる」

複数の集計によれば、投稿は400万回以上表示されたと報じられています。翌月にはMerriam-Websterがトレンド語として採録しました。2025年11月にはCollins Dictionaryが年間ワードオブザイヤーに選んでいます。この1年足らずの広がり方自体が、AIコーディングツールの普及速度をそのまま映しています。

Karpathyが挙げた条件は具体的です。差分を読まずに提案を受け入れる、エラーメッセージをそのままAIに貼り付けて直させる、コードが自分の理解を超えて肥大化しても気にしない。想定していたのは週末に作る使い捨てのプロトタイプで、本番運用のコードベースではありませんでした。

似た言葉に「agentic coding」がありますが、意味は少し異なります。vibe codingが指すのは「コードを読まない」姿勢そのものです。一方でagentic codingは、AIエージェントに複数ステップの作業を任せる開発手法全般を指し、レビューを省く前提までは含みません。Claude Codeが提供するのは後者の実行基盤で、vibe codingはその基盤の上で選べる進め方の1つです。

vibe codingが向く場面・向かない場面

用語が生まれた文脈を踏まえると、向き不向きははっきり分かれます。

Karpathyは後の講演でも、本来はプロトタイプ用途だったvibe codingが本番開発にまで広がりつつある現状に触れ、専門的な品質基準を保つ「agentic engineering」という言葉を新たに提唱しています。用語が指す範囲と、実際にチームが使う場面はずれやすいものです。「どこまでレビューを省くか」を導入前に決めておくと、後戻りが少なくなります。

Claude Codeでvibe codingを実践する手順

Claude Code全体の機能はClaude Codeとは — エージェント型AIコーディングCLI完全ガイドで解説していますが、vibe coding専用の機能を単体で持つわけではありません。Planモード・権限モード・サンドボックス・Checkpointingを組み合わせると、AIに任せる範囲を段階的に広げながら進められます。以下は個人開発やプロトタイピングを想定した手順です。

1. Planモードで計画を確認する

CLIではShift+Tabを押すとPlanモードに切り替わります。Planモードでは、Claudeはファイルの読み取りや調査は行いますが、コードの編集は実行しません。調査結果をもとに立てた計画を提示し、承認して初めて実装に進みます。

claude --permission-mode plan

単発のプロンプトだけPlanモードにしたいときは、先頭に/planを付けます。

/plan このAPIエンドポイントの認証をJWSからJWTに置き換える

vibe codingでは差分を細かく読まない代わりに、実装前の計画だけは目を通すという線引きが有効です。計画の粒度や承認後の分岐はClaude Code Planモード完全ガイドにまとめています。

2. 権限モードで自動化の範囲を決める

Claude Codeには読み取りのみのManualから、確認なしで全て実行するbypassPermissionsまで複数の権限モードがあります。

vibe codingの「コードを読まずに任せる」感覚に近いのはacceptEditsかautoモードです。bypassPermissionsは確認そのものを飛ばすため、公式ドキュメントも隔離環境以外での使用を勧めていません。

権限モードが使える範囲は動かす場所によって違います。ローカルのCLIとJetBrainsプラグインはShift+TabでdefaultからacceptEdits、planの順に循環します。bypassPermissionsとautoは有効化していれば循環に加わり、dontAskは循環に含まれず起動時に--permission-mode dontAskで明示指定します。

一方でClaude Code on the webのクラウドセッションはAccept edits・Plan・Autoの3つのみで、bypassPermissionsは選べません。Remote Controlでスマートフォンから操作する場合はさらに限定され、Manual・Accept edits・Planの3モードだけが操作対象になります。ローカル端末でbypassPermissionsへ切り替えても処理は続きますが、このモードはclaude.aiに報告されないため、アプリ側の表示は直前のモードのまま変わらないことがあります。Autoなど他のモードへの切り替えは、通常どおり表示に反映されます。

3. サンドボックスで自律実行を安全にする

/sandboxコマンドでBashサンドボックスのパネルを開けます。サンドボックスは、コマンドが読み書きできるファイルと接続できるネットワーク先をOSレベルで制限する仕組みです。既定では作業ディレクトリとセッションの一時ディレクトリ以外への書き込みができません。macOSではSeatbelt、LinuxとWSL2ではbubblewrapとsocatを使います。Windowsのネイティブ環境では利用できず、WSL2経由が前提になります。

/sandbox

ユーザー設定でsandbox.enabledをtrueにすると全プロジェクトでサンドボックスが有効になります。sandbox.failIfUnavailableをtrueにすれば、依存パッケージが無い環境でサンドボックスなしの実行そのものを止められます。acceptEditsやautoモードと組み合わせると、確認を減らしつつ被害範囲を作業ディレクトリの外へ広げない構成になります。

4. Checkpointingで巻き戻せる状態を保つ

Claude Codeはユーザーのプロンプトごとに自動でチェックポイントを作成します。入力欄が空の状態でEscを2回押すか/rewindを実行すると、コードと会話のどちらか、または両方を任意の時点まで戻せます。

/rewind

ただし制限もあります。Bashコマンドによるrmやmvはチェックポイントの対象外で、巻き戻せません。バックグラウンドで動くサブエージェントの編集も、Restoreの対象に含まれないことがあります。vibe codingで試行錯誤を重ねるなら、Checkpointingだけに頼らずGitのコミットも並行して残すと安全です。

5. CLAUDE.mdとHooksでガードレールを敷く

vibe codingでレビューの手間を減らすほど、Claude自身に守らせるルールの比重が重くなります。プロジェクト直下のCLAUDE.mdに、触ってよいディレクトリやテストの実行方法を書いておくと、セッションが変わっても同じ前提で進められます。書き方の具体例はClaude CodeのCLAUDE.mdを実用に引き上げる10のパターンにまとめています。

さらに一歩進めるなら、Hooksでファイル編集の前後に自動でlintやテストを走らせ、失敗時は編集そのものをブロックできます。設定方法はClaude Code Hooks完全ガイドを参照してください。

ここまでの手順を日常の計画・実行・レビューにどう組み込むかは、Claude Codeワークフローでも扱っています。

よくあるつまずきと対処

• acceptEditsやautoモードのまま長時間走らせ、途中の失敗に気づかずコードが壊れる → 数プロンプトごとに/rewindで状態を確認する運用にする
• Bashコマンドで直接ファイルを消したり移動したりして、Checkpointingで戻せなくなる → git管理下に置き、こまめにコミットする
• バックグラウンドで動くサブエージェントやSkillの編集がRewindで戻らず混乱する → フォアグラウンド実行に切り替えるか、影響範囲を確認してからGitで戻す
• CLAUDE.mdを整備せず、毎回同じ前提を説明し直す → プロジェクト直下に置き、触ってよい範囲とテストコマンドを明文化する
• 使い捨てのつもりで書いたコードが、そのまま本番にマージされる → 投入前にレビュー工程を挟むか、そもそもvibe codingの対象から外す

よくある質問

vibe codingとagentic codingは何が違いますか

vibe codingは差分を読まずに進める姿勢そのものを指す言葉で、agentic codingはAIエージェントに複数ステップの作業を任せる開発手法全般を指す、より広い概念です。Claude Codeの自律実行機能は後者の基盤であり、その上でどこまで差分確認を省くかが利用者の選択になります。

Claude CodeでPlanモードを使うとvibe codingではなくなりますか

Planモードで計画を確認する行為は、提案を無条件に受け入れるという元々の定義からは外れます。ただし実装後の差分自体は読まずに進められるため、実務では計画だけ確認する「部分的なvibe coding」として運用されることもあります。

組織でvibe codingの利用範囲を制限するにはどうすればよいですか

Team・Enterpriseプランでは、管理者がmanaged settingsでサンドボックスの利用を必須化したり、bypassPermissionsモードの可否を組織ポリシーで制御したりできます。個人開発と違い、チーム導入時はこうした管理者設定を先に決めておくと安全です。

vibe codingで書いたコードにテストは必要ですか

vibe codingという語自体は差分を読まないことに主眼があり、テストの有無には触れていません。動作確認をテストとして残しておくと、差分を読まずに変更を重ねても、壊れた箇所に気づきやすくなります。

非エンジニアでもvibe codingはできますか

コードを読まずに進める前提そのものは可能ですが、動作確認やデプロイ、セキュリティ設定などコード以外の判断は依然として必要です。プロトタイピング目的であれば、非エンジニアが試すハードルは低くなっています。

vibe codingにセキュリティ上のリスクはありますか

差分を確認しないまま実行範囲を広げると、意図しない削除や外部への通信が起きるリスクは高まります。サンドボックスや権限モードでの制限は、このリスクを下げるための仕組みです。

まとめ

vibe codingは、Karpathyが2025年2月に投稿した1文から広まった、AIに実装を委ねて差分を読まずに進める開発スタイルです。用語自体は使い捨てのプロトタイピングを想定していますが、実際にはより広い場面で使われています。

Claude Codeで実践するなら、Planモードで計画だけは確認します。そのうえで権限モードとサンドボックスで自動化の範囲を区切り、Checkpointingで巻き戻せる状態を保つ、という段階的な組み合わせが現実的です。CLAUDE.mdとHooksでガードレールを敷いておけば、レビューを省いた分の安全性を仕組み側で補えます。