バイブコーディング実践ガイド：AIエージェントで本番運用まで進める8つの手順

ソフトウェア開発のあり方が、大きく変わりつつあります。コードを一行ずつ書く開発から、入力補完ツールを使う開発へ。そして今、AIエージェントに実装の多くを任せる「バイブコーディング」が広がっています。

バイブコーディングでは、人間がすべてのコードを書く必要はありません。人間はプロダクトの方向性や設計、品質管理に集中し、コードの作成、デバッグ、リファクタリングなどをAIエージェントに任せます。

ただし、AIに「こんなアプリを作って」と一度指示するだけで、複雑なソフトウェアが完成するわけではありません。曖昧な指示から生成されたコードを継ぎ足していくと、途中で整合性が崩れ、修正が難しくなることがあります。

重要なのは、アイデアの整理から設計、UI/UX、実装、テスト、セキュリティ、本番公開までを一つの開発プロセスとして管理することです。

本記事では、クロード・コードなどのAIエージェントを使い、アイデアを本番運用できるソフトウェアに仕上げるまでの流れを8つのフェーズに分けて解説します。

まず決めたいAIモデルと開発環境

バイブコーディングを始める前に、使用するAIモデルと開発環境を決めます。長時間にわたってAIエージェントに作業を任せる場合、モデルの性能だけでなく、利用制限や開発環境との相性も重要になります。

AIモデルはクロードを中心に使う

本稿では、AIモデルとしてクロードの有料プランを第一候補としています。

複数の要素が絡む設計や長時間の開発を進めやすく、作業の途中で利用上限を意識する場面を減らせるためです。AIエージェントに半日単位の作業を任せる場合、工程の途中で処理が止まると、その後の開発にも影響します。

次の候補として挙げられるのがコーデックスです。コーデックスも高い性能を持っていますが、本稿では、複雑なアーキテクチャを含む一連の開発ではクロードを中心に使う方法を採用しています。

もちろん、個別のタスクであれば他のAIモデルでも対応できます。重要なのは、企画から実装までの流れをなるべく分断せず、プロジェクト全体の文脈を維持できる環境を選ぶことです。

開発環境はVS Codeかクロード・コード

ファイル構成を画面で確認しながら作業したい場合は、VS Codeとクロードのプラグインを組み合わせる方法が使いやすいでしょう。

一方、クロード・コードを単体で使ったり、コマンドラインから操作したりする方法もあります。クロード・コードには、より深い自動化を利用できる利点があります。

どちらが適しているかは開発スタイルによって異なるため、実際に両方を試して選ぶのが現実的です。以下では、利用する画面にかかわらず、AIエージェントを使った開発プロセスを「クロード・コード」と表記します。

フェーズ1：コードを書く前に、何を作るのかを固める

最初に考えるべきなのは技術ではなく、プロダクトそのものです。

よくある失敗は、開発ツールを開いてすぐに「〇〇ができるアプリを作って」と入力することです。要件が曖昧なまま実装を始めると、機能同士のつながりが弱くなり、後から大幅な修正が必要になりやすくなります。

まずはChatGPTやクロードの通常のチャット画面を使って、アイデアを整理します。この段階では、プログラミング言語やデータベース、システム構成について考える必要はありません。

AIには、アイデアの弱点や見落としている点、実際に使うと問題になりそうな部分を指摘させます。自分の案を肯定させるのではなく、あえて批判的に検討させることがポイントです。

プロンプトでは「究極の」「洗練された」「意外性のある」といった言葉を加え、一般的な回答だけで終わらず、例外的なケースまで考えさせる方法もあります。

アイデアが固まったら、内容を一つのマークダウン（.md）ファイルにまとめます。この文書が、その後の設計や開発の基準になります。

フェーズ2：「スーパーパワーズ」で実装前の検討を徹底する

実装に入る前に、本稿ではクロード向けの「スーパーパワーズ」というスキルを利用します。

アイデア → スーパーパワーズを有効化 → 計画と検証 → 実装

スーパーパワーズを使うと、AIがいきなりコードを書くのではなく、先に計画を作り、テスト方法を検討し、複数の選択肢を整理してから実装を始めるようになります。

その分、開発には時間がかかります。原文では、処理時間が最大で10倍になる場合があるとしています。通常なら1時間程度で進む作業に、半日ほどかかることもあります。

一方で、短時間でコードを生成することよりも、設計や検証を丁寧に進めたいプロジェクトでは有効です。

スーパーパワーズを有効にしたら、フェーズ1で作成したマークダウンファイルをクロード・コードに読み込ませます。内容を確認させ、不明点があれば質問するように指示します。

その回答を文書に反映してから開発を始めることで、要件に対する思い込みや認識違いを早い段階で減らせます。

フェーズ3：技術仕様を作り、必要な情報を先に調べる

プロダクトの方向性が固まったら、次は技術設計です。

クロード・コードに、使用するプログラミング言語、データ構造、技術スタックなどを整理させ、技術仕様書として別のマークダウンファイルに保存します。

ここで、すぐに実装へ進むのではなく、開発中に問題になりそうな点を先に調べておきます。

本稿では、次の流れを使います。

クロード・コード → 調査すべき10の質問を作成 → Web検索が可能なAIで調査 → 結果をマークダウンで保存 → クロード・コードに読み込ませる

ライブラリの仕様や実装方法が分からず、開発途中で作業が止まるのを防ぐためです。

必要な技術情報やライブラリのドキュメントをあらかじめ調査し、AIエージェントが参照できる資料としてプロジェクト内に残しておきます。

フェーズ4：UI/UXは後回しにせず、先に形にする

画面設計は、開発の最後ではなく早い段階で進めます。実際の画面があれば、機能や操作性の問題を早く見つけられるためです。

まず、技術仕様をもとにクロード・コードで詳細なUI/UXの設計書を作成します。ここはAIに任せきりにせず、人間が内容を確認し、必要に応じて修正します。

次に、その設計書をクロード・デザインに入力し、実際に操作できるプロトタイプを作成します。要件を満たすまで画面を調整します。

デザインが固まったら、同じチャットでデザインシステムとコンポーネントライブラリも作成しておきます。新しい画面やUI部品が必要になったときに、同じ設計ルールを使えるようにするためです。

最後にプロトタイプのデータをプロジェクトフォルダへ入れ、クロード・コードに構造を分析させます。画面構成についてもマークダウンで記録します。

フェーズ5：プロジェクト全体の開発計画を作る

ここまでで、コンセプト、技術仕様、調査結果、UI/UX設計が揃いました。

次にクロード・コードへ、開発全体を複数のフェーズに分けた詳細な計画を作らせます。計画は一つのマスターファイルにまとめ、プロジェクト全体の基準として使います。

本番公開は最後に回す

開発中はローカル環境や自宅サーバーで実装とテストを進め、本番環境へのデプロイは最後に行います。

開発途中から本番サーバーを前提にすると、問題の切り分けや修正が複雑になりやすいためです。

Gitで変更履歴を残す

スーパーパワーズではGitによるバージョン管理を自動化できるため、問題が起きた場合も以前の状態へ戻しやすくなります。

GitHubへの接続は、チームで共同開発する必要がある場合に行えば十分です。

AIを使うアプリでは基盤を早めに用意する

アプリ自体が大規模言語モデルを利用する場合は、必要なAI基盤を早めに設定します。

本稿では、ローカルサーバー上のAIモデルやBitrix24 Vibe CodeのAPIを利用し、必要に応じてオープンルーターを使う構成を想定しています。

AIが作った計画は人間が並べ替える

AIが提案した開発計画は、そのまま採用しません。

特に2点を見直します。1つ目は、UIの組み立てをできるだけ早い段階へ移すことです。画面を早く確認できれば、設計や実装の問題にも気づきやすくなります。

2つ目は、開発初日から詳細なログを残すことです。後から不具合が起きた場合に、原因を追いやすくなります。

フェーズ6：AIエージェントに実装を任せ、人間が品質を管理する

原文では、実際の実装工程がプロジェクト全体の約95％を占めるとしています。

AIエージェントが数時間にわたって自律的に作業を進めることもあり、人間は進捗を確認し、節目ごとに成果物をチェックしながら、必要な場面で指示を追加します。

ここで重要になるのが、テストとレビューです。

自動テストをできるだけ広く行う

プレイライトなどのヘッドレスブラウザを使い、実際の画面操作を含めてテストします。

バックエンドのログだけではなく、画面が正しく表示され、ユーザーの操作に対して期待通りに動いているかまで確認します。

最後は人間が実際に操作する

自動テストで問題がなくても、使いにくさや画面上の違和感までは見つからないことがあります。

人間が実際にアプリを操作し、一連の流れを確認する作業は欠かせません。

画面上の文章は必ず読み直す

AIが生成したボタン名や説明文は、不自然な表現になることがあります。

特にユーザーが直接目にする文章は、人間が確認し、必要に応じて書き直します。

定期的に別のAIにもレビューさせる

数フェーズごとに新しいチャットを立ち上げ、これまで開発に参加していないAIエージェントへコード全体を確認させます。

それまでの判断に影響されていない状態でレビューさせることで、見落としていた脆弱性や設計上の問題を発見しやすくなります。

フェーズ7：セキュリティを確認して本番環境へ移す

開発が終わっても、すぐに公開してはいけません。セキュリティ確認は、独立した工程として行います。

まずコードの脆弱性を調べる

GitHub上のセキュリティ用スクリプトや、クロードへの専用プロンプトを使ってコードベースを確認します。

特に、インジェクション攻撃につながる脆弱性や、データ漏えいの可能性を本番公開前にチェックします。

用途に合わせて公開先を選ぶ

原文では、主に3つの選択肢を挙げています。

• ローカルの自宅サーバー：個人向けツールや社内の自動化に使います。
• Bitrix24 Vibe Codeのブラックホールサーバー：Bitrix24との連携やセキュアな環境が必要なアプリに利用します。
• 一般的なVPS：独自ドメインで一般公開するアプリに利用します。

クロードには、サーバー環境の構築、基本的なファイアウォール設定、デプロイスクリプトの作成なども任せられます。

公開後にもセキュリティ監査を行う

本番環境へ移した後は、もう一度セキュリティを確認します。

サーバー固有の設定によって、開発環境では発生しなかった問題が生じる可能性があるためです。

ユーザーから大規模言語モデルへの入力を受け付けるアプリでは、プロンプトインジェクション攻撃についても十分にテストします。

フェーズ8：公開後の修正は、小さな単位で進める

アプリを公開した後は、本番環境のログをクロードへ読み込ませ、スモークテストを実施しながら細かな不具合を修正します。

ここで守りたいのが、機能追加やバグ修正のたびにプロジェクト全体を書き換えないことです。

AIに大規模な変更を一度に依頼すると、すでに正常に動いている部分まで壊れる可能性があります。

修正範囲は、一つの関数や一つのファイルなど、できるだけ小さな単位に限定します。そして変更するたびにテストを実行します。

別のAIモデルへ移行するときも、記録があれば困らない

開発途中でクロードからコーデックスなど別のAIへ移行する場合、プロジェクト内に残してきた文書が役立ちます。

コンセプト、技術仕様、調査結果、開発計画などのマークダウンファイルが揃っていれば、新しいAIモデルに読み込ませることで、これまでの設計や判断を引き継げます。

プロジェクトの記憶を、一つのAIモデルや長いチャット履歴だけに依存させないことが重要です。

バイブコーディングで最も重要なのは、記録を残すこと

この開発フローを通して共通しているのが、コンセプト、技術仕様、調査結果、UI設計、開発計画などをマークダウンファイルとしてプロジェクト内に保存することです。

マークダウンで記録を残すメリットは、大きく3つあります。

1. 人間が判断の経緯を確認できる

時間が経ってからでも、なぜ特定の技術や設計を選んだのかを確認できます。

2. AIがプロジェクトの文脈を取り戻せる

過去の文書を読み直せば、長いチャット履歴を維持し続けなくても、AIエージェントが必要な情報を確認できます。

3. 別のAIモデルへ移行しやすい

マークダウンファイル群がプロジェクト独自の記録として残るため、使用するAIを変更しても情報を引き継ぎやすくなります。

バイブコーディングで一つだけ習慣にするなら、仕様や判断、調査結果をすべて記録として残すことです。

AIにコードを書かせるだけなら、それほど難しくありません。難しいのは、生成されたコードを一つの製品としてまとめ、安定して使える状態まで仕上げることです。

バイブコーディングを実務で使ううえでは、AIにどこまで任せるか以上に、人間が設計、テスト、セキュリティ、記録をどこまで管理できるかが重要になります。