vibe coding のワークフロー：アイデアからリリースまで（Claude Code、2026年）

vibe coding とは？（おさらい）

Vibe coding とは、欲しいものを自然な言葉で説明し、AI にコードを生成させ、そして一行ずつ自分で打ち込む代わりに「期待どおりに動くかどうか」で結果を判断する、というソフトウェアの作り方です。Andrej Karpathy が2025年初めにこの言葉を作り、インディーハッカーからプロの開発者まで、あっという間に一般的な働き方になりました。ひとことで言えば、あなたは意思決定者でありレビュアー、そして AI が実際の作業を担う側です。

vibe coding が混乱に陥らずに済む唯一の鍵はワークフローです。思いつきでプロンプトを撃ちまくることではありません。基礎がまだ固まっていない場合は、まずvibe coding とは何かを読んでから、ここに戻って繰り返し使えるプロセスを学んでください。この記事では、AI 支援コーディングを最初から最後まで進める「やり方」に焦点を当てます。

vibe coding ワークフロー概要：アイデアからリリースまでの6ステップ

vibe coding のワークフロー全体は6つのステップに収まり、それぞれに明確な成果物と「意思決定ゲート」——先へ進むか、いったん戻って何かを直すかを判断する地点——があります。この意思決定ゲートこそが、AI を「その場のノリ」で漂わせず、軌道に乗せ続ける仕組みです。

この6ステップは、より無駄のないメンタルモデル——brainstorm -> plan -> cook -> ship フレームワーク——に対応します。brainstorm がステップ1〜2、plan がステップ3、cook がステップ4、そして ship がステップ5〜6をまとめます。ここではClaude Code——リポジトリを読み、複数ファイルを編集し、コマンドを一度の流れで実行できるエージェント型 CLI（Claude Code ドキュメント、Anthropic）——でワークフローを示しますが、同じ原則は Cursor や Copilot にも当てはまります。

ステップ1 — アイデアを明確にして brainstorm する

いちばんよくある間違いは、ターミナルを開いていきなりプロンプトを打ち込むことです。その結果、AI はあなたの意図を推測し、推測を外し、最初から存在しなくてよかったものの修正に半日を費やすことになります。ステップ1は AI slop を根元で止めます。AI に指示を出す前に、自分が何を欲しいのかを知っておく必要があるのです。

プロンプトを一つ打つ前に、次の4つの問いに答えてください。

• 成果（Outcome）：この製品は誰を、何のために助けるのか？ 一文で言い切りましょう。
• 制約（Constraints）：どの言語／スタックか、どこで動くか、オフラインで動く必要があるか、使える時間の予算はどれくらいか。
• 非目標（Non-goals）：このバージョンであえてやらないこと（AI が余計な機能を「発明」しないために重要です）。
• 「完了」基準：そこに到達したと分かるために何を見ればよいか——たとえば「ユーザーが支出を追加すると合計が更新されるのが見える」。

具体例：「個人向けの支出トラッカー」というアイデア。成果：個人が日々の支出をすばやく記録し、月間合計を見られるようにする。制約：静的な Web ページ、ブラウザで動作、データはローカルに保存、1日の午後で作れる。非目標：ログインなし、クラウド同期なし、凝ったグラフなし。完了基準：支出を追加でき、一覧と月間合計が見える。この4つの答えが、以降のすべてのプロンプトが従うべき「憲法」になります。

ステップ2 — AI 向けに spec／ブリーフを書く（ただの「ふわっとしたプロンプト」ではなく）

ここが品質に最も大きな差を生むステップです。「支出アプリを作って」のようなふわっとしたプロンプトからは、行き当たりばったりの結果しか得られません。構造化されたspecがあれば、意図に近い結果が返ってきます。spec は一度書けば、計画（plan）にも実装（cook）にも使い回せます。

コピペして埋められる spec／ブリーフのテンプレートを示します（リポジトリのルートに SPEC.md または CLAUDE.md として置くと、Claude Code が自動的に読み込みます）。

# SPEC - Expense tracker

## Goal
A single-page web app that lets an individual quickly log expenses and view a monthly total.

## User flow
1. The user enters an amount + category + date, then clicks "Add".
2. The expense appears in the list, newest on top.
3. The current month's total shows at the top of the page and updates automatically.

## Sample data
- { amount: 12.50, category: "Food", date: "2026-08-09" }
- { amount: 30.00, category: "Transit", date: "2026-08-08" }

## Technical constraints
- Plain HTML + CSS + JavaScript, no framework.
- Persist with localStorage, no backend.
- Works when you open index.html directly.

## Test criteria (definition of "done")
- Add an expense -> it appears in the list.
- Reload the page -> the data is still there.
- The monthly total matches the entered expenses.

## Non-goals
- No login, no cloud sync, no charts.

リスクが低いとき（プロトタイプ、社内ツール、静的ページ）は、かなり自由に vibe で進めて構いません。ですが、リスクが高いとき——ユーザーデータ、金銭を扱うロジック、サードパーティ連携——はspec 駆動開発に切り替えましょう。より詳細な spec、厳密な受け入れ基準、そしてそれを即興で崩さずに守る AI が必要です。spec が明確なほど、AI slop は減ります。

ステップ3 — 計画を立てて分割する

AI に「アプリを一発で全部書いて」と言ってはいけません。モデルが一度に頭の中に抱えるものが多いほど、抜け漏れ・自己矛盾・存在しない API の発明が起きやすくなります。代わりに、AI にコードの前に計画させ、その計画をあなたがレビューします。

Claude Code では、よい計画用プロンプトはこんな感じです。

Read SPEC.md. DO NOT write code yet.
Propose a plan: list the modules to build,
the order to implement them, and for each module
spell out its input/output. Then stop and wait for my approval.

例のアプリなら、妥当な計画は各パーツの「ノリ」を確認できるよう小さなモジュールに分けます。

1. HTML の骨組み＋入力フォーム——インターフェースを作る、ロジックはまだなし。
2. localStorage への保存と読み込み——データの追加／読み込み、合計はまだなし。
3. 一覧の描画——保存した支出を表示する。
4. 月間合計の計算——合計ロジック＋追加ごとの更新。

作業を分割することには3つの利点があります。各ステップを承認できること、何かが壊れても探索範囲が狭いこと、そして巨大なコードの塊が一度に返ってきてレビューに苦労する代わりに、各意思決定ゲートで主導権を握り続けられることです。

ステップ4 — Cook：AI に1モジュールずつコードを書かせる

「Cook」とは、承認済みの計画に沿って AI が実際にコードを書く段階です。Claude Code では、典型的な cook セッションはこう進みます。エージェントがリポジトリと SPEC.md を読む -> 現在のモジュールのファイルを編集または作成する -> コマンド／テストを実行する -> 結果を報告する -> あなたが次のモジュールへ進む承認をするのを待つ。作業は1モジュールずつ。アプリ全体を「手放す」ことは決してありません。

計画に紐づけた、最初のモジュール用の cook プロンプト。

Implement module 1 from the plan: the HTML shell + input form
(amount, category, date, Add button). No save logic yet.
When you're done, briefly describe what you created.

cook 中のチェックポイントのコツをいくつか。

• すぐに動かす——各モジュールの後、最後まで待たずに実行する。ズレを早く捕まえるほど、はるかに安上がりです。
• diff を読む——AI がたった今生成した差分を読む。モジュールの範囲外のファイルに触れていたら、理由を尋ねましょう。
• 手で介入する——AI が同じ間違いを2回続けて繰り返したら、小さな箇所を直接直すほうが、言葉で説明し直すより速いことが多いです。
• コミットは小さく——1モジュールにつき1コミット。後のモジュールが前のものを壊しても巻き戻しやすくなります。

ステップ5 — テスト、レビュー、そして AI slop を避ける

動くコードと、よいコードは同じではありません。このステップは、製品と「AI slop」の山——見た目は問題なさそうでも、肥大化していて、保守しづらく、あるいは静かに間違っているコード——を切り分けるところです。黄金律：理解していないものは出荷しない。

各 cook セッション後の手早いレビュー用チェックリスト。

• spec に書いた「完了」基準に対してテストを実行する。例のアプリなら、支出を追加し、ページを再読み込みし、月間合計を確認する。
• コードを読んで理解する。ざっと眺めるだけにしない。説明できない箇所があれば、AI に説明させるか、もっと単純に書き直させましょう。
• デッドコードを狩る：誰も呼ばない関数、インストールされたのに使われないライブラリ、起こり得ないケースの処理。
• 端を確認する：空の入力、負の数、書式の崩れた日付——AI はこうしたケースをよく忘れます。

AI が生み出しがちな「におい」と、その止め方をさらに深掘りするにはAI slop を避ける方法を参照してください。テストが赤くなったりコードが奇妙な挙動をしたりしたときの、筋道立てたデバッグ手順はAI でのデバッグにあります。エラーを貼って「直して」と言うだけにせず、AI に文脈を与え、まず原因を診断させましょう。

ステップ6 — Ship：動く製品をデプロイする

多くの vibe coding 記事はプロトタイプで止まります。ですが「ship」こそ、アイデアが他の人に実際に使える製品になる瞬間です。プロトタイプから本当のデプロイへ進むには、いくつかのことが関わります。

1. ビルド：パッケージング工程（バンドラー、フレームワーク）があるなら、どこかへ持っていく前にビルドを実行して警告を潰しておく。
2. 環境変数の設定：鍵／環境変数をコードから外に出す。秘密情報をリポジトリにコミットしない。
3. ホスティング：実行に適した場所を選ぶ。静的ページなら数分で静的ホスティングに上げられる。バックエンドを伴うアプリはサーバーに対応したプラットフォームが必要。
4. ドキュメント：spec とコード自体から AI に README を書かせる。動かし方、設定の仕方、現在の制限を記す。

自分を欺かないための正直な一言：よいプロトタイプは意思決定の道具であって、小さな本番ビルドではありません。それはアイデアに取り組む価値があるかを確かめる助けになります。価値があると確信できたら、大勢の実ユーザーに開く前に、コアの堅牢化（セキュリティ、エラー処理、テスト）に時間をかけましょう。

実例：小さなアプリを6ステップすべてで作る

すべてをまとめると、支出トラッカーはワークフロー全体をこう進みます。これは私が Claude Code で実際に回したウォークスルーで、作業のリズムを思い描けるようステップごとに示します。

• ステップ1（アイデア）：上記のとおり成果／制約／非目標／完了基準を固める——静的 Web、localStorage、1日の午後。
• ステップ2（spec）：上記のとおりの SPEC.md テンプレートをプロジェクトのルートに保存する。
• ステップ3（plan）：Claude Code に spec を読ませて4つのモジュールを提案させ、実装順を承認する。
• ステップ4（cook）：1モジュールずつ進める。「月間合計」モジュールの後で実行し、新しい支出を追加すると合計が正しく更新されるのを確認する。
• ステップ5（テストとレビュー）：3つの「完了」基準をすべて実行する。1つのエッジケースのバグ——カンマ付きの数値を入力すると合計が狂う——を捕まえ、合計する前に入力を正規化するよう AI に依頼する。
• ステップ6（ship）：静的ページなので、フォルダを静的ホストに push するだけ。実行手順つきの README を AI に生成させる。

結果：支出を追加・表示・合計でき、再読み込みしてもデータが残る1ページのアプリが、1日の午後でゆとりを持って作れました。大事なのはアプリが「見栄えする」ことではなく、ワークフローが次のプロジェクトでも繰り返せることです。

vibe coding が通用しないとき（正直な限界の話）

vibe coding はどんな釘にも使えるハンマーではありません。ペースを落とし、より厳密な spec 駆動に切り替え、あるいは自分で書くべき領域があります。

• 認証と認可：小さなバグ一つでデータが丸ごと露出しかねません。ログイン／アクセス制御の部分を「vibe」で済ませてはいけません。
• 決済と課金：ここでの誤りは、実際のお金や信頼の損失を意味します。厳密な spec、入念なテスト、そして人による手作業のレビューが必要です。
• 機微なデータ：個人・医療・金融の情報——ミスは法的な結果を伴います。
• 大規模で密結合なシステム：ある一箇所を変えると多くに影響する場合、AI は自分が「見えていない」ものを簡単に壊します。
• 生成されたコードを読めないとき：レビューできないなら責任も取れません——それは立ち止まる合図です。

覚えておく価値のある、静かな2つのリスク：ハルシネーション（AI が存在しない API・関数・結果を発明する）と技術的負債（今日は動くが、絡まりを溜め込み明日を難しくするコード）。どちらも、出力を盲信するのではなく、各ステップの同じ意思決定ゲートで抑えられます。

既製キット（AgentKit）でワークフローを加速する

上記の6ステップは、毎回あなたが brainstorm 用プロンプトを考え出し、spec テンプレートを手作りし、AI に計画するよう促す代わりに、各ステップに専用ツールが用意されていると、より速く、より確実に回ります。そこで、Claude Code 向けの既製 skill／subagent／ワークフローのキットが真価を発揮します。

注：ここでの AgentKit はClaude Code 向けのキット（agentkit.best、ak CLI）を指し、OpenAI の AgentKit とは別物です。Engineer Kit — 20%オフ、今なら$79.20は、このプロセスの各ステップ（brainstorm、plan、cook、test、コードレビュー）をちょうどカバーする60以上の skill と30以上のワークフローを$79.20でまとめています。ページに継続課金の記載はなく、返金保証と生涯アップデートが付きます。どの skill がどのステップに合うかを見たいなら、決める前にEngineer Kit レビューを読んでください。キットがワークフローをあなたの代わりに回してくれるわけではありません——毎回あなたが組み直すことになる、繰り返しの足場づくりを取り除いてくれるだけです。

よくある質問（FAQ）

vibe coding のワークフローは何ステップですか？

ワークフローは繰り返し使える6ステップです。アイデアを明確にして brainstorm する、AI 向けの spec／ブリーフを書く、計画して作業を分割する、cook（AI に1モジュールずつコードを書かせる）、テストとレビューで AI slop を避ける、そして ship（製品をデプロイする）。各ステップには意思決定ゲートがあり、先へ進む前に確認できます。

vibe coding にコードの知識は必要ですか？

強いコーダーでなくても始められますが、信頼できる製品を出荷するには、AI が生成したコードを読んで理解できる必要があります。ルールはこうです。理解していないものは出荷しない。読めるコードが多いほど、レビューは良くなり、静かなバグを避けられます。

vibe coding は従来のプログラミングとどう違いますか？

従来のプログラミングでは一行ずつ自分で打ち込みます。vibe coding では、欲しいものを自然な言葉で説明して AI に生成させ、あなたは舵を取り承認します。あなたの役割は「書き手」から「意思決定者でありレビュアー」へと移ります。

vibe coding にはどのツールを使うべきですか？

Claude Code はリポジトリを読み、複数ファイルを編集し、コマンドを一度に実行するため、端から端までのエージェント型ワークフローに向いています。Cursor や GitHub Copilot でも可能で、エディタ内の補完に強みがあります。自分の習慣に合わせて選んでください。6ステップのワークフローは3つとも当てはまります。

vibe coding で作ったプロトタイプは本番にデプロイできますか？

小さく低リスクな製品なら、はい。ただし、よいプロトタイプは意思決定の道具であって、小さな本番ビルドではありません。大勢のユーザーに開く前に、コアのセキュリティ・エラー処理・テストを堅牢化してください。

vibe coding で AI slop を避けるには？

最初に明確な spec を書き、作業を小さく分割し、各モジュールをレビューします。「完了」基準に対してテストを実行し、ざっと眺めるのではなく読んで理解し、デッドコードを削除し、エッジケースを確認する。説明できないものは何も出荷しないこと。

まとめ＋次のステップ

vibe coding のワークフローは魔法ではありません——AI を使いながら主導権を保つための6ステップの規律です。アイデア -> spec -> plan -> cook -> test -> ship、そして各段階に AI slop を止める意思決定ゲート。次の一歩は必要に応じて変わります。高リスクなプロジェクト向けに、より厳密な spec が欲しいならspec 駆動開発を、無駄のないメンタルモデルが欲しいならbrainstorm -> plan -> cook -> shipを読んでください。そしてコードを整った状態に保つには、AI slop を避ける方法を学びましょう。