バイブコーディング開発のプロンプトはどこまで雑でも大丈夫なのか？
この記事は、freee Developers Advent Calendar 2025 の8日目です。
草間 (Kusama) と申します。普段は東京・大崎にある関東拠点で freee支出管理の設計・実装を行っています。これまでは、フリーランスのエンジニアとして開発しておりました。今年からは、freeeに参画して、フリーランスとは違った新鮮な日々を送っております。
入社後に最も印象的だったのが、AI駆動開発の最先端を進んでいる点です。「AI駆動開発へ。freee は開発環境をどう進化させているか？- 前編」でも紹介されていますが、現場では複数のエージェントツールを併用しながら、開発を進めています。
フリーランス時代は、AIエージェント（以下、エージェントと略します）利用に対して、悩んだ時に壁打ちでWeb検索的に聞く利用をしていました。もちろん、利用していたエージェントは一つでした。入社後に、AIを常に比較しながら、「このタスクはRoo Codeを使って社内LLMに聞くと良い」「Devinに聞けば解決できるのでは？」といった具合で、特徴を理解しながら、多くのツールを使い分けて利用していることが印象的でした。
バイブコーディングへの挑戦
AIを利用していく中で、細部のコーディングをAIが担い、人間はAIの意図を管理して開発するスタイル「バイブコーディング」が生まれました。freeeでは、「マジ価値・理想ドリブン」を掲げ、本質的な価値の提供を目指しています。エンジニアが、マジ価値を実現する時間を生むため、AI駆動開発が採用されています。
しかし、ここで疑問が湧きました。 「初心者（ドメイン知識が浅い）バイブコーダーは、どこまで開発できるのか？」
そこで今回は、「プロンプトだけでRailsアプリ開発はできるのか？」 をテーマに検証を行います。お題は「アルバムアプリ」。設計からAIに任せ、私はあえて「指示出し」に徹します。途中でエンジニアリング知識を少しずつ注入し、AI時代の開発における「未経験 vs 経験者」の優位性についても考察します。
今回の利用エージェントは、要件定義にてGemini、開発時にはGitHub Copilot（GPT-5）にしました。
AIに設計させてみる
AIに要件定義を任せるということで、次のプロンプトでざっくり投げてみました。ここでは、一旦 Gemini 2.5 Proを利用してみることにします。
Webで動作する、アルバムアプリをRailsで作りたいです。設計してください。
すると、1分程度で設計を終えてくれました。設計も章立てにされており、おおかたの範囲をカバーしてくれています
- コア機能の定義
- ユーザー認証
- アルバム管理
- 写真管理
- データベース設計
- モデルの役割とカラム定義
- モデルのリレーション
- 利用するライブラリ
- ルーティング設計
- コントローラ設計
- 画像アップロード処理
- 拡張機能（任意）
ある程度のラリーが必要かと思いましたが、最低限必要な実装は書かれていました。今回のアプリケーションは、Railsアプリケーションの典型的な構成要素（Scaffoldに近い）に近いものです。これは、AIが得意とする「定型パターンの出力」であるように感じました。それでは、このまま進めてみることにします。
いざ！コーディング開始？
ここからは、Copilotに引き継いでバイブコーディングをしていきたいと思います。今回は、Copilotの中でも最も有名なChatGPTを採用します。（後に設計でも利用することから、GPT5の推論モデルを採用しました）
今回はRailsでコンテナ化されたものを利用したかったので、ベースとなるコードについてはすでに用意しておきました。
プロンプトは、先に生成された設計書を貼付した上で、機能を実現するようにと指示しました。
いざ、実装開始！
どうやら、AIもかなり考え込んでいるようです。お茶を飲んで5分ぐらい待っていたら、完了したようです。
実行結果を見てみると、自動実行してくれていたようですがコンテナ起動や表示用のページも生成して、起動できるようにしてくれたみたいでした。
あと、今回気づいた点ですが、AIがやることを事前にTODOリストにしているようですね。このようにして、人が行うように、やることを順番に進めているようなので、どこでミスしたのかも見返せそうな感じになっていました。
ただ、出力結果はRailsのエンジニアでないと読めない内容になっていました。（RailsライブラリのDeviseやファイル系システムActive StorageといったRails用語満載）素人の人からすれば、よく分からないけど作れたという認識になりそうかなと感じました。
では、指示された通りに、ブラウザを起動して、アプリを実行してみることに。
実際にログイン画面が表示され、ログインをしてみると、表示されました！
アルバムを作って、適当に写真を当てはめると、ファイルのアップロードや写真の削除などができるようになっていました。
しかしお気付きの通り、実用性がない状況です。実際の画面だと、上記の内容がブラウザの左端に表示されており、サイズも小さい状況です。さらに、画像のダウンロード機能が存在せず、機能が足りていない状況でした。
機能としては申し分ないが...
エージェントに、ほとんど機能を投げて依頼して完成した「アルバムアプリ」としては問題ありません。ですが、やはりアルバムアプリとして利用していくには欠かせない機能が、いくつか抜けているように感じました。確認してみたところ、エージェントが作成した設計書で示された機能のうち、下記の内容が実装されていませんでした。
- 高画質（元データ相当）でのデータ保存
- 写真ダウンロード機能
- 写真の投稿者情報（メタ情報）
- 写真をクリックで拡大表示
- 動画ファイルのアップロード
- 複数ファイルのアップロード・ダウンロード
ここで感じたのは、Railsアプリケーションの典型的な構成要素については、実装されている点です。AIが得意とする「定型パターンの出力」として、プログラムが用意されたようにも感じます。
そこで、ここからは、エンジニアとして指示文（プロンプト）を考えながら、開発してみたいと思います。プロンプトの粒度を三段階用意して、エージェントの性能を比較してみたいと思います。以下は、粒度と対応させる機能実装の内容です。
A：そのままプロンプトに入力する（→ 技術的な話は一切しない・抽象的）
・高画質（元データ相当）でのデータ保存
・写真ダウンロード機能
B：ある程度の実現ロジックを指定して記述（→ 技術的なガイドレールを敷く）
・写真の投稿者情報（メタ情報）
・写真をクリックで拡大表示
C：プロンプトで意図を示し、ENGが実質操作（→協働操縦）
・動画ファイルのアップロード
今回の記事では、A→B→Cの順番で実装を進めていくことにします。
最初のバグ発生も、すぐに解決！
早速、A：そのままプロンプトに入力する（→ 技術的な話は一切しない・抽象的）に挙げた項目を実施してみたいと思います。早速、先程と同じように、実装したい機能名を挙げて、そのままプロンプトとして、エージェントに伝えてみました。
・高画質（元データ相当）でのデータ保存・写真ダウンロード機能
これを実際に依頼してみると、2分程度で完了しました。しかし、予想していた通り、バグが発生しました。写真ファイルがリンク切れするバグでした。初歩的なバグであったことが、驚きでした。この時、RailsのActive Storageが生成する動的なパス構造をAIは理解できていませんでした。よって、静的ファイルパスとしてリンクを生成してしまうハルシネーションを起こしていました。
そこで、ファイルがリンク切れを起こしている点を指摘すると、アクセスできるようになりました。なお、オリジナルサイズでダウンロードも問題なくできるようになっていました。
比較的、抽象的な指示でしたが、しっかりと機能として成立しました。この調子で機能開発ができてしまえば、エンジニア不要論も存在しそうなのも、よく分かります。しかし、注意しておきたい点として、このような機能の実装は、ミドルエンジニアであれば比較的手動で簡単に対応できる点です。複雑なロジックに対応することが多い場面では、ここまで簡単に実現できるかは分かりません。また、商用サービスを扱う場合には、発生した事象に対する説明責任が伴います。問題の検証には、基本的な知識が必要であることも分かりました。
エンジニアが、簡単な機能を実現するためにコーディングする機会は無くなりそうです。すると、ビギナーエンジニアがこれまで活躍してきた、簡単な実装は奪われてしまうと感じました。
Captainとして操縦すれば、優秀なCopilotが働いてくれる？
次のケースは、現在のバイブコーディングで一般的に利用されている手法であると思います。
B：ある程度の実現ロジックを指定して記述（→技術的なガイドレールを敷く）
技術的な用語やロジック、アーキテクチャを理解した技術者が、プロンプトを作成するケースを想定したいと思います。
それでは一旦話題を、写真一覧の画面に戻します。次に実装する機能は、写真を誰が投稿したのか確認できる機能です。また、写真をクリックすると、拡大表示できる機能を実装したいと思います。技術的な表現をすれば、サービス側のメタ情報（ユーザー名、アップロード日など）を併せて表示する、写真プレビューのモーダルウィンドウです。
そこで、実際に次の情報を含めてプロンプトを作成してみました。
・現状（現在実装されている内容・利用されている技術スタックを示す）
・実装したいこと（機能概要・技術スタックをどう利用するか）
・対応して欲しいこと（実装するべき内容）
これらの情報を踏まえて作成する時、注意しなければいけないポイントは「メタ情報」として表現する点です。写真のメタ情報はファイルに付随している情報を指します。よって、ユーザー情報を表示する際の指示には「メタ情報」を言葉として含めず、指示する必要があります。
ユーザー情報を表示させるところから、はじめていきます。
表示をさせることができました。
実際に表示を成功させるまでの過程では、コンテクストを与える必要が生じました。生じた箇所としては下記の内容が挙げられます。
・実行するコマンドに、docker-compose（コンテナ操作）をする点を示す
・必要に応じてマイグレーションファイルを作成して良い
次に、写真をモーダル表示にして、右側にユーザー情報を表示するようにします。しかし、指示を出して、修正が完了したようですが、表示に一切変化がない状況となりました。そこで、ブラウザ上のデバッグとサーバー側レスポンスを調査して、プロンプトに指示を与えることにしました。
写真を押しても、写真のページにリダイレクトされ、サイドバーは表示されません。<該当箇所のリンク> コンソールではエラーが発生しておらず、読み込みに失敗しているファイルもありません。写真を押すと、モーダルが表示されるように修正されているかを再度確認してください。
コマンド実行して終了後、再度コンテナの再起動やリビルドなどを試しました。それでも変化なく、写真一覧から写真が消えてしまう状況も発生しました。そこで、一歩踏み込んで、JavaScriptの動作を確認してみることにしました。開発者ツールからアクセスをしてみると、ボタンをクリックした時に発火するべきイベントが、検知されていないことが分かりました。
Rails 7以降では Turbo Drive がデフォルトで有効になっており、これが従来のJavaScript（jQuery的アプローチや DOMContentLoaded イベント）と競合することが多々あります。今回生成されたコードは、Turboの挙動を考慮しておらず、生じていたものとみられます。そこで、表示されない原因を示した上で、修正を指示しました。
すると、モーダル画面を表示させることができました。写真が表示されておらず、ユーザー名などの情報も表示されません。そこで、さらにデータのロード状況も確認しました。ファイルなどはブラウザ上に保存されており、表示する部分のみ失敗している状況であることが分かりました。そこで、スクリーンショットと、生じた事象とその背景を同様に説明して、対応するように指示をしました。
次のページが表示され、対応を終えることができました。
ここまでの対応を考えると、荒い指示を行っていた時の方が、正常に動作するようにも感じてしまいます。特に発生するエラーの大半は、ブラウザ動作における失敗エラーです。プログラムを走らせた時に、起動してブラウザ上で表示されるような文法エラーとは異なります。操作を進めていく中で、はじめて確認される失敗であり、その内容もエンジニアが犯しがちな内容から、調査・デバッグを要する内容まで様々です。エラーの内容を与えても、治りましたと示される点も厄介です。すると、プロンプトを作成するにも、方針を失ってしまいます。そこで、自力でプロンプトを作成するために、調査をする必要があります。このような観点から考えた時、この開発フライトの機長（キャプテン）として、いわゆる正確な指示（プロンプト）を副操縦士（コパイロット）に出す必要があります。
エンジニアがAIを活用できるようにするには、利用を重ねていき、正確なプロンプトを作成できるようになる必要がありそうです。また、正確なプロンプト作成をするための教育や活用本も、実は我々エンジニアも読む価値があるのかもしれません。（実際に読んだり受けたことはないので、分からないのが正直な感想ですが。）
設計段階から参加したら、優秀なエンジニアになってくれるのか？
最後のケースC：プロンプトで意図を示し、ENGが実質操作（→協働操縦） は、設計フェーズから開発まで一つのスレッドで行った場合を想定します。ソフトウェアエンジニアの業務例として、設計で影響範囲の調査や技術選定をした上で、開発をします。今回は設計フェーズにて、該当機能の構築で懸念される事項や構築に必要となる作業の検討を指示します。そして、その指示を踏まえた上で、機能の実装を指示するものとなります。すなわち、作業のコンテクストを同時に共有しながら、作業をしていく場合を検証します。
今回対応する内容は、動画ファイルのアップロード機能と複数ファイルのアップロード・ダウンロード機能になります。これらの機能を取り扱う理由は、大容量ファイル対応といった難しい内容を、どのように決めていくか、検証するためです。また、ドキュメント自体は作成しませんが、人の思考と同じく、意思決定→細かな要件を検討→決定という形で、順序立ててエージェントに意図を学習させることにします。
まず、動画アップロードの部分から対応を依頼します。
現在は、動画ファイルのアップロードに対応していません。動画ファイルについても同様に対応できるようにしたいと思います。まずは、事前調査として、どのような課題があるかを指摘してください。
すると、次の項目について検討された結果が返ってきます。
モデル／処理面
コントローラ／Strong Parameters
ビュー (表示/UI)
Active Storage 設定／インフラ
データモデル／マイグレーション
パフォーマンス／UX
セキュリティ
その他運用課題
優先度の高い改善ステップ案 (概略)
動画対応することが難しい点を同様に指摘されました。そこで、機能を絞った実装にすることを伝えて、より詳細に実装する機能を示します。
動画を取得した場合には、サムネイル画像を生成する。生成したサムネイル画像を表示させ、動画ファイルであることが分かるようにする。動画再生はブラウザ上では実現させず、代わりに動画ファイルのダウンロードができるようにする。また、セキュリティ面では、MIME タイプバリデーションを定める。この上で、必要となるライブラリをインストールして、コード修正を提案してください。
ここまで実行すると、同じ操作画面から、動画ファイルのアップロードができるようになりました。さらに、続けていきます。
アップロードやダウンロードするときに、素材を複数選択して実行できるようにしたいと考えています。この機能を実装する場合に検討するべき内容を提案してください。
すると、ユースケースと要件定義として、想定されうるケースや複数の構築例が示されるようになります。以上の内容から、開発する機能の要件を与えて、具体的なコーディングの指示に移っていきます。前半では、アップロード・ダウンロードにおける基本的な機能を実装していくことにします。以下は、実際のプロンプトです。
以上の回答から、必要な内容を決めていきたいと思います。
アップロードの要件
複数データのアップロードができるようにしたい。以下が定める要件である。以下を実現するように、ファイルを修正していきたい。
・対象となるデータをアップロードするときには、個数無制限で選択できるようにする。（ネイティブの部品を利用するか）
・一部ファイルだけ失敗した場合は、成功分だけ反映する。
・失敗したファイルだけを選択し直して再実行できるようなUI（チェックボックス＋「失敗ファイルを再試行」）にする。
・ネットワーク切断やタイムアウト時の挙動（自動リトライ、ユーザーに再試行ボタンを出すなど）を用意する。
・全体の進捗バーを用意する。APIにて、個々のファイルごとに送信していく。進捗（パーセンテージ）で表示する。
・完了／失敗の状態をアイコンや色で分かりやすく表示する。
・長時間処理（数百MBのアップロードや大量ダウンロード）では、ファイルを自動分割してパケットを送信する。また、受け取ったパケットをサーバー側で繋げて、ネットワークエラーを抑える。
・複数ファイルのアップロードは、「1つのバッチAPI」として送る。ただし、アップロードの都度、APIがリクエストされるものとする。
しかし、動作エラーが発生してしまいました。そこで、従来までと同様に、エンジニア側が手動でデバッグして内容確認してみたいと思います。その上で、修正を指示します。
Invalid batch_idと表示され、アップロードできません。
また、アルバムの画面で表示されてしまいます。別ページにアップロード機能はまとめて、統合してください。
<当該リンク>
これで、前半部分の動作が正常になり、実装が完了しました。
ここまで生じたエラーの対応やエージェントへの学習作業は、現場教育に似ているように感じました。
先輩社員として、新入社員に諭して理解させるやり方で、現場教育をしている感じでしょうか。共感を得られなかったら、申し訳ございません。
後半部分に入ります。複数ファイルのダウンロードについて実際に行えるように、操作画面の修正を行っていきます。そこで、先ほど示された内容を踏まえて、開発する機能を指示します。
今度は、写真を選択して、選択した写真をダウンロードできるようにしたいと思います。以下のダウンロード要件に合わせて、複数ファイルのダウンロードが行えるように修正を行なってください。
・ダウンロード側は、複数ファイルを ZIP などにまとめる方式
・写真の一覧画面から、ダウンロードしたい写真をクリックすると、チェックされるようにする。
・ウイルススキャンは用意しない
・Zipファイルサイズが、1GBを超過する場合に可能な場合には、Zipファイルを分割してダウンロードできるようにする。
後半部分については、特にエラーが発生せずに、完了しました。
これで全ての機能を実装することができました。
C：プロンプトで意図を示し、ENGが実質操作（→協働操縦）における開発を振り返ります。開発時にプロンプトを作成して、様々な指示を出した時よりも、機能の意図を読み違えることが少なかった印象です。また、Bで生じていたようなエラー対応件数となりました。しかしBで発生したような、システム構造を認識していないことを起因としたエラーではなく、ごく一般的な動作における問題点の修正であった点が特徴です。
結局のところ、自律した開発エージェントとして期待することは難しい状況です。期待する方向で実装をしてくれますが、動作の確認やデバッグについては、人の手がかかる部分です。そして、人間と同じく嘘をつきます。厄介な部分として、動作しているかのように、嘘をついてしまう点です。従来のエラー対応と異なり、失敗したとして示されないところが、判断を難しくすることにつながってしまいます。言い換えてしまえば、最新理論を武装をした優秀な新人といった具合でしょうか。理論的には実装できているはずだが、実際に動作をさせてみようとした時には動かず、検証までは十分に行いきれない状況です。
エンジニアとしてキャリアを考えるきっかけに
簡単な機能であれば、未経験者でも開発できる点は、冒頭で明らかになった通りです。そして、これまでミドルエンジニア以上が、ビギナーエンジニアに託してきた簡単な実装についても、置換可能であることが分かりました。
しかし、少々複雑な実装になった時に、開発のコンテキストをエージェントに伝えることが非常に難しくなります。そして、動作自体も、エージェントの発言を信用することができません。世間で言われていることは事実であることが分かります。
「AIは嘘をつく」「AIを利用すれば、作りたいアプリが作れる」
これらの言葉は正しいです。ところが、思っていた通りの物を実装すること、そして、複雑さや確実な動作を進めていくためには、設計と一定以上のエンジニアリング知識が必要になります。開発言語に対する理解というよりも、開発者として理解すべき教養に近いと思われます。さらに、デバッグやエラー対応を多く経験することにより、AIが示す方針の間違いやすれ違いに気づくことができると思います。
未経験者がコーダーとして下積みする時代は、近い将来無くなるように思えます。それでも、未経験者と経験者が同列に扱われる事態は起こりにくいと感じました。エンジニアとして従事していくためには、より多くの設計・開発経験と知識理論が必要となり、的確な指示を出せるようになる必要があります。つまり、これからのエンジニアは、コードを書く速度（タイピング）ではなく、「何を作るべきか」を定義し、AIという強力なコパイロットを正しく操縦（VibeCoding）する能力 で評価されるようになるでしょう。
将来を見据えた時、2025年現在は、エンジニアはまず多くの設計・開発経験と知識理論の理解をする必要があると思います。そして、現場で積極的にAIを利用しない場合は、利用する場合と差が大きくひらきます。1年というスパンで考えても、エンジニアの経験値として評価が変わってくると感じました。
まだ本格的にバイブコーディングをされていない方は、一度バイブコーディングを体験されることを強くおすすめします。無料版や短期間での契約で、AIエージェントを利用するだけでも、開発期間の短縮やデバッグの苦悩解消を体験することができます。個人開発で体験されてみてはいかがでしょうか。また、AIを利用できる環境にある方は、積極的に利用しながら、傾向や過程を読んでみるのも面白いと感じました。そして、浮いた時間で多くの知識を学んでみるのはいかがでしょうか。
明日の記事は、Kochanさんから、freeeで行われているAI勉強会についてです。ここまでは、個人でAIを利用することを前提としていました。しかし、エンジニア同士も仲間です！お互いに経験や知識を共有して、勉強している姿をお届けしたいと思います！
