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

vibe codingとは

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

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

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

2025年11月にはCollins Dictionaryが年間ワードオブザイヤーに選んでおり、1年足らずで一般語になりました。

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

似た言葉に「agentic coding」があります。両者は指す層が違います。

Claude Codeが提供するのは後者の実行基盤で、vibe codingはその基盤の上で選べる進め方の1つです。

最初から近い状態で始まる — 既定の権限モードがauto

Claude Codeの権限モードの既定値は、バージョンで変わっています。v2.1.283以降では、ターミナルとVS Code拡張で新しく始めたセッションの既定がautoです。autoでは分類器(別のモデル)が裏で各操作を審査し、人間の承認プロンプトはほとんど出ません。つまり設定を何も触らなくても、vibe codingに近い感覚で始まります。

autoが使えないセッション(対応外のモデル、組織の設定で無効化など)はManualで始まります。v2.1.283より前では、Pro・Max・Teamプランのうち機能フラグを取得するセッションだけがautoで、それ以外はManualでした。

手元のv2.1.289で、指定できるモードを--helpから確かめた出力です。

claude --version
claude --help | grep -A3 -e "--permission-mode"

2.1.289 (Claude Code)
  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

選択肢にdefaultが無くmanualが並んでいる点に注意が必要です。CLIでは「確認を求める」モードをManualと呼び、設定ファイルやフックでの値はdefaultのままです。--permission-mode manualと--permission-mode defaultのどちらも受け付けます。

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

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

Karpathyは2026年のSequoia Ascentでの対談で、vibe codingはプロトタイプや個人用ツールには向き、真剣なチームに要るのは品質を保つ「agentic engineering」だと説明しています(本人公開の要約より)。用語が指す範囲と、実際にチームが使う場面はずれやすいものです。「どこまでレビューを省くか」を導入前に決めておくと、後戻りが少なくなります。認証のような重要度の高い処理でClaudeに実装を任せつつ本番品質を保った実例は、ClaudeにOAuth実装を任せた公開実例で扱っています。

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

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

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

Planモードでは、Claudeはファイルの読み取りや調査は行いますが、ソースコードの編集はしません(bypassPermissionsを有効にした対話端末は例外で、編集がブロックされないことがあります)。調査結果をもとに立てた計画を提示し、承認して初めて実装に進みます。起動時に指定するなら次のとおりです。

claude --permission-mode plan

セッション中はShift+Tabでモードを循環できます。autoで始まったセッションでは、最初の1回でManualに移り、そのあとacceptEdits、planの順に進みます。ステータスバーの表示は、順にmanual mode on、accept edits on、plan mode onです。

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

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

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

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

権限モードは、Claudeが確認なしで実行できる範囲を決めます。

vibe codingの「コードを読まずに任せる」感覚に近いのはacceptEditsかautoモードです。bypassPermissionsはプロンプトinjectionや意図しない操作への防御がなく、隔離環境以外での使用は想定されていません。ただしbypassPermissionsでも、明示的なaskルールに合致するツールや、重要パス(critical path)に対するrm・rmdirは承認なしでは通りません。

プロジェクトの.claude/settings.jsonにdefaultModeを書いても、autoとbypassPermissionsは反映されません。この2つをチームの共有設定で強制することはできない作りです。

権限モードが使える範囲は動かす場所によって違います。

3. サンドボックスで自律実行の被害範囲を絞る

サンドボックスは既定でオフです。/sandboxでパネルを開くか、ユーザー設定のsandbox.enabledをtrueにすると有効になります。有効な間、Claudeが実行するシェルコマンドは、書き込み先と通信先をOSレベルで制限されます。macOSはSeatbelt、LinuxとWSL2はbubblewrapとsocatを使い、Windowsのネイティブ環境では使えません。

/sandbox

注意が要るのは「何を守って何を守らないか」です。サンドボックスで守られるのはシェルコマンドだけで、vibe codingで気づかないうちに抜け道になりやすい箇所が残ります。

sandbox.failIfUnavailableをtrueにすると、依存パッケージが無い環境でサンドボックスなしの実行へ黙って進む挙動を止められます。既定では、サンドボックスが起動できないときもコマンドはサンドボックスなしで走ります。acceptEditsやautoと組み合わせると確認が減る一方、読み取りの範囲は広いままなので、秘密情報が置かれた環境ではfilesystem.denyReadでの絞り込みも選択肢です。

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

Claude Codeはターンを始めるプロンプトごとに、自動でチェックポイントを作成します。入力欄が空の状態でEscを2回押すか/rewindを実行すると、メニューが開きます。コードと会話の両方、会話だけ、コードだけのいずれかを選んで戻せます。

/rewind

チェックポイントはセッション内の直近100件分のスナップショットが残ります。セッションの保存から約30日後の掃除で消えるため、古いセッションを再開して巻き戻すとNo files were restoredで失敗することがあります。保持を延ばすならcleanupPeriodDaysを設定します。

戻せるものと戻せないものは次のとおりです。

vibe codingで試行錯誤を重ねるなら、Checkpointingだけに頼らずGitのコミットも並行して残します。公式もチェックポイントはセッション単位の復旧用で、バージョン管理の代わりではないとしています。

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

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

さらに一歩進めるなら、Hooksを使うと、編集前のフックで編集を止め、編集後のフックでlintやテストの結果をClaudeに返せます。設定方法はClaude Code Hooks完全ガイドを参照してください。フックのコマンドはサンドボックスの外で動くため、フックに書いた処理は制限を受けません。

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

よくあるつまずきと対処

• acceptEditsやautoモードのまま長時間走らせ、途中の失敗に気づかずコードが壊れる → 数プロンプトごとに/rewindで状態を確認する
• Bashで消したファイルやサブエージェントの編集がRewindで戻らない → git管理下に置き、こまめにコミットする
• サンドボックスを有効にしたつもりで、依存パッケージ不足のまま無防備に走っていた → /sandboxのパネルで依存関係を確認し、必要ならsandbox.failIfUnavailableを使う
• defaultModeにautoを書いたのにプロジェクトで効かない → プロジェクトの設定ファイルでは無視される仕様なので、ユーザー設定か起動時のフラグで指定する
• 使い捨てのつもりで書いたコードが、そのまま本番にマージされる → 投入前にレビュー工程を挟むか、vibe codingの対象から外す

よくある質問

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

管理者はmanaged settingsで、permissions.disableBypassPermissionsModeによるbypassPermissionsの禁止や、disableAutoModeによるautoの無効化ができます。disableAutoModeを"disable"にすると、Shift+Tabの循環からautoが外れ、--permission-mode autoで起動してもManualで始まります。サンドボックスの強制は、sandbox.failIfUnavailableを使う構成が公式に挙げられています。

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

コードを読まずに進める前提そのものは可能です。ただ、動作確認やデプロイ、セキュリティ設定などコード以外の判断は残ります。コードを読めない分、実装前にPlanモードで計画の文面を確認する手順が判断の足場になります。

まとめ

Claude Codeは既定でautoから始まるため、vibe codingの入口はすでに用意されています。どこまでレビューを省くかを導入前に決めておくことが、vibe codingを続けられるかの分かれ目です。そのうえで、サンドボックスが守るのはシェルコマンドだけで、Rewindが戻せるのはファイル編集ツールの変更だけという境界を押さえておくのが現実的です。