バイブコーディングを活用した機能要件の「超・具体化」プロセス

コラムカテゴリー：ITコンサルティング, その他, 用語解説

　昨今、プログラミングの知識がなくても、AIとの対話を通じて直感的にアプリを構築できる「バイブコーディング（Vibe Coding）」が台頭しています。CursorやGoogle Antigravityといったエージェント型IDEツール（*1）は、単なるシステム開発補助にとどまりません。これらは、発注者が作成するRFP（提案依頼書）の質を向上させる手段としても、非常に有効な選択肢になり得ます。本稿では、このバイブコーディングを活用して精度の高いRFPを作成する方法について解説します。

バイブコーディングとは何か

　「バイブコーディング（Vibe Coding）」とは、AIに対するプロンプトの指示によってアプリケーションを構築する、開発スタイルを指します。大きな特徴は、厳密な設計や詳細な機能定義がなくても、大まかなイメージだけで開発をスタートできる点にあります。
　「こんな感じのものが欲しい」という大まかなイメージを伝えるだけで、AIがその意図を汲み取ります。不足している機能はAIが自ら補完し、即座に動くアプリケーションへと仕立て上げます。これにより、コーディング知識のない発注者でも「ブラウザ上で操作できるUI」を手にできるようになりました。この「頭の中のイメージ」から「すぐに動くUI」へと昇華できる体験は、これまで多くの発注者を悩ませてきた「要求の可視化」という課題を解決する有効な手段の一つになります。

バイブコーディングを「何が必要か（What）」の特定にだけ使う

　ただし、バイブコーディングをRFP作成に活かすには、その特性を正しく理解する必要があります。生成されるものは、あくまで「すぐ動くUI」を用いた「体験のシミュレーション」であり、そのまま本番で使える完成品ではないからです。
　ここを誤解したままプロジェクトを進めると、「バイブコーディングだけで開発を完結できる」という過信を招きます。「自社だけで開発できるのではないか」という無理な内製化論が浮上したり、ベンダーが提示する妥当な見積もり（コストや期間）に対して、社内から不当な批判が噴出したりする恐れがあります。
　こうしたトラブルを防ぐためにも、バイブコーディングの「得意」と「苦手」を明確に整理しておきましょう。

• 得意なこと： 「何が必要か（What）」の特定
  UIや画面仕様の具体化に真価を発揮します。プロトタイプを実際に操作することで、「ここにボタンが必要だ」「このプロセスが抜けている」といった、現場が求める機能の存在理由（UX）を直感的に定義できます。
  
  
• 苦手なこと： 「どう実現するか（How）」の精緻化
  内部設計やバックエンドの要件定義には向きません。アルゴリズムの組み立てやデータベースの負荷分散など、裏側の複雑な構造をAIだけで定義し切ることは、現時点では非常にハードルが高いです。
  

本稿におけるバイブコーディングの定義

　このように、バイブコーディングは「フロントエンド（UI/UX）の可視化」に極めて強い一方で、「バックエンドの構築」には課題が残ります。
　この特性を踏まえ、本稿ではバイブコーディングを「システム開発そのものの手段」ではなく、あくまで「フロントエンド要求定義の補助ツール」と定義します。以降では、この定義に則って要望をUIへ落とし込む手法を解説します。

従来のフロントエンドの要求定義が抱える難しさ

　発注者が要求定義をまとめる際、大きな壁となるのが「頭の中にある大まかなイメージを具体的な画面仕様や操作体験（UI/UX）として可視化できない」という点です。特に全く新しいサービスを立ち上げる場合、既存のSaaSでは対応できず、要求定義をゼロから検討してスクラッチ開発を進めるケースも多く見られます。
　こうした状況では、業務プロセスやサービスの全体像は描けていても、利用者が実際に触れる画面上で「どのような情報や入力枠が必要か」といった具体的な要求までは想像が及ばないことがあります。その結果、本来自分たちで決めるべき核心部分を「詳細はベンダーに提案してもらう」という名目で曖昧に残し、RFPを発行してしまいます。しかし、この「検討の先送り」は、いざ要件定義フェーズに入った際に「想定していたサービス設計とベンダーの認識が大きく乖離している」「追加開発が必要になり、予算が大幅に膨れ上がる」といった大きなトラブルに発展する事態が、後を絶ちません。

イメージをUXへ変換し、要件を具体化する3ステップ

　こうした問題に対し、RFP策定にバイブコーディングを取り入れるのが有効です。曖昧だった要求を「UIに触れる体験（UX）」を通して可視化できます。その結果、フロントエンドの仕様を迷いなく具体化できます。
　バイブコーディングでフロントエンドの仕様を具体化するプロセスは以下の3ステップです。

1. 大まかなイメージを伝え、設計の方向性を確認する

　まずはエージェント型IDE（Google Antigravityなど）に、求めるシステムの概要をプロンプトで伝えます。
プロンプト例：
「BtoB向けの受発注システムを作りたい。注文書（PDF）をOCRで読み込んで、画面から発注登録できる機能。デザインは一般的で使いやすいものに」
　下記の図1は、上記のプロンプトから生成されたプロトタイプです。このように大まかな指示だけでも、AIが「企業名」「発注日」「注文番号」といった必須項目を推論し、さらには「OCRの読み取り精度」を表示するといった実用的な機能まで補完して構築してくれます。
図１：Google Antigravityにより自動生成された「OCR連携・受発注管理画面」のプロトタイプ

【ポイント】
　多くのエージェント型IDEツールでは、AIがコーディングを始める前に「Implementation Plan（実装計画）」でどのような機能やUI画面を作るかをユーザーに提示します。
　下記の図２は「図１受発注システム」を作成する際にAIが提示したImplementation Plan（実装計画）です。ここで計画内容を事前確認し、大きなズレがあれば再度プロンプトで修正を試みます。

図２：受発注システムを構築する時のImplementation Plan（一部）画面

2. 生成されたUIを利用者の立場で触り、修正を繰り返す

　AIが生成したUIを、実際に利用者の立場で操作します。最初はイメージと異なる部分も多いため、対話を通じてブラッシュアップを繰り返します。
　下記の図3は、図1の「受発注システム」を拡張した画面です。AIに対し、「営業担当者が注文内容を承認するワークフロー機能を追加してほしい」と指示を出しました。このように、操作しながら『足りない要素』に気づき、即座に反映させて検証できるのがバイブコーディングの強みです。

図３：営業承認ワークフローが追加実装された「受発注システム」のプロトタイプ画面

3. 体験（UX）を言語化し、ドキュメントに落とし込む 

　操作を通じて感じた「このUXを実現するために必要なフロントエンドの振る舞いや画面仕様」を抽出し、ドキュメントに記載します。

【ポイント】　
　UXを要求仕様に落とし込むことが難しければ、AIに「このUIを実現するための要求を書き出してほしい」と依頼することも有効です。ただし、AIが生成した項目をそのまま鵜呑みにせず、業務上の整合性や実現可能性を人間が最終的に確認・修正することが不可欠です。
　下記の図4は、完成したプロトタイプからAIを用いて要求仕様案を抽出している様子です。このように、動くものから仕様を逆引きできます。

図４：バイブコーディングで構築したシステムをAIで要求仕様を抽出している画面

具体事例：なぜ「動かす」必要があるのか

　プロトタイプを動かすことの効能を、具体的な事例で示します。

ケース：AIを活用した営業先のサジェスト機能

　営業支援システムにおいて、AI分析を用いて見込みの高い顧客の架電リストを作成するシステムを調達すると想像してください。
　従来のRFPであれば、以下のような要求を記載して満足していたでしょう。

・AIが過去のデータから顧客の状況を分析できる機能
・分析結果に応じて営業成功率の高い架電リストを提案する機能

　しかし、バイブコーディングでプロトタイプを生成し、実際の担当者目線でダッシュボードを操作してみると、UXの欠陥に直面します。
　例えば、画面上にAIからの架電先が表示されています。そのうちの1件を担当者が「今は電話すべきではない」と判断して架電を見送るというシナリオを想定して操作してみます。すると、架電リストは翌日も翌々日も、同じ顧客を最優先で提示し続けます。
　この一連の操作を体験したとき、「AIの提案を現場が無視した場合、なぜ無視したのかをAIに学習させる導線が存在しない」という致命的な欠陥に気づきます。このフィードバックを行うための画面設計がないままでは、AIは的外れな提案を延々と繰り返すだけになってしまいます。
　実際に「動く画面」で体験して初めて、「AIの提案に対する『採用／却下』ボタンの設置」や「却下理由を入力させ、再学習へフィードバックするための入力インターフェース」といった、現場への定着とシステムの成長を見据えた解像度の高い要求仕様が導き出せます。
　また、この再学習サイクルの必要性に気づくことで、「その裏側の仕組み」にも目が向くようになります。例えば、「1度の却下で、再学習時のLLMのパラメータの重み付けをどう処理するか」「スコアリングのテーブルはどれぐらいの頻度で更新するのが最適か」といった、より深い技術的課題を洗い出すことができます。
　このようにプロトタイプを動かす体験（UX）は、画面仕様などの「外部設計」の精度を上げるだけなく、データ処理や学習ロジックといった「内部設計」で検討すべき課題の解像度も高めます。

「詳細」なUXによるリスクヘッジ

　ここまでの内容を読み進めた読者の中には、「RFPにそこまで詳細なUXを求める必要があるのだろうか？」という疑問を抱く方もいらっしゃると思います。しかし、私は以下の理由から、詳細まで踏み込んで記載すべきだと考えています。

ベンダーの実力を見極める

　「〇〇を分析できること」といった抽象的な要求に対しては、大抵のベンダーが「対応可能」と回答してきます。しかし、本当に重要なのは単なる「機能の有無」ではなく、「想定しているサービス設計や業務運用が、実際にそのシステムで実現できるかどうか」です。「我々はこのデータを分析し、このような結果を得たい（UX）」という目的を示し、その一例として「このデータを使って、このようなグラフで可視化したい（UI）」というレベルまで踏み込んで提示します。そうすることで発注側の目的や意図は格段に伝わりやすくなります。
　さらに、そのUXを実現するためにベンダーがどのような解決策を提示してくるかによって、ベンダーの実力を測ることが可能になります。このようにRFPの解像度を高めることは、自社にとって最適なベンダーを見極めるための重要なフィルタリング手段となります。

要件定義フェーズでのコスト増大の抑制する

　ベンダー選定において、コストは要求の実現度と並んで重視される要素です。しかし、要求が抽象的なままでは詳細な工数を見積もりに反映できず、提案時の金額が実態より安くなる傾向があります。こうした見積もりの乖離は、プロジェクト開始後の要件定義フェーズで表面化します。具体的な仕様を詰め始めた段階で、追加開発の必要性や画面数の不足といった事実が次々と発覚し、最終的な費用が当初の想定を大幅に上回ってしまいます。
　RFPの段階でプロトタイプを作成し、要求を可視化しておくことは、提案時よりもコストが高騰することを未然に防ぐための重要な防衛策となります。

活用上の注意点

　バイブコーディングで生成したUI画面は、要件を具体化するうえで非常に有用ですが、使い方を誤ればプロジェクトを失敗させる原因にもなり得ます。導入にあたっては、以下の点に特に注意していただきたいと思います。

バイブコーディングとの付き合い方

　本稿で紹介した通り、エージェント型IDEを使えば、非エンジニアでも「動く画面」を即座に作り出すことが可能です。
　昨今のSNSでは「プログラミング知識ゼロでアプリを構築する」といった主旨の動画が散見されるため、「自社でもベンダーに頼らず、簡単にシステムを作れるのではないか」と期待する方もいるかもしれません。
　しかし、現段階のバイブコーディングは、非エンジニアが本番稼働に耐えうるシステムを丸ごと作り上げられるような夢のある技術ではありません。バイブコーディングだけで本番用システムを作ろうとした場合、以下のような危険性が伴います。

• プログラムコードがスパゲティ化しやすい

　バイブコーディングは、AIとの対話を重ねながら機能を追加・修正していくスタイルです。この時、AIは「ユーザーの指示通りに、とにかく動くUIを素早く実装する」ことを最優先に行動します。
　そのため、AIが自ら全体を俯瞰した設計やコードの最適化（リファクタリング）を行うことはありません。ユーザー自身が全体像を意識して、適切に指示を出す必要があります。
　もし指示が不十分なまま、場当たり的な追加や修正を繰り返してしまうと、プログラムの内部構造はツギハギだらけの「スパゲティコード」と化してしまいます。こうなると、不具合が起きた際の原因究明や、将来的な機能拡張といった「保守運用」が事実上不可能になります。

• セキュリティ対策が抜け落ちやすい

　AIは「動かすこと」には長けていますが、プロンプトに明示的な指示がない限り、セキュリティを自発的に強固にしてくれるわけではありません。
　例えば、ユーザーが文字を入力できる投稿サイトを作る場合、悪意のあるプログラム（クロスサイトスクリプティング等 *2）を実行させないための「入力値のエスケープ処理」などが不可欠です。
　エンジニアであれば当然実装するセキュリティ対策も、AIに「動くこと」だけを求めて生成したコードでは、すっぽりと抜け落ちてしまう危険性があります。
　技術的な制約は、上記以外にも存在します。データベースの正規化といった従来の設計課題に加え、バイブコーディング特有の「コンテキストウィンドウの不足（*3）」もその一つです。この制約により、AIが突如として辻褄の合わないコードを出力し始めるなど、実用的なシステムを作り上げるには越えるべきハードルが山ほどあります。
　だからこそ、バイブコーディングの活用は、「UI/UXの解像度を上げるためのプロトタイプ作り」と明確に線引きをすることが重要になります。

「UIの完成」は「システムの完成」ではない 

　前述の通り、バイブコーディングのみで本番稼働に耐えうるシステムを構築することは至難の業です。しかし、この技術の裏側を知らない経営層やプロジェクトメンバーが完成したUIを見ると、「すでに本番利用できるシステムが出来上がった」と錯覚してしまうことがあります。
　作成したプロトタイプは、あくまで画面側（フロントエンド）だけの「外装のみのモックアップ」に過ぎません。データベース設計や外部システム連携といった裏側（バックエンド）の仕組みは空っぽの状態です。
　実際の開発プロジェクトの工数割合から考えても、画面として見えている部分は全体の2割に過ぎません。残りの8割にあたるデータ整合性の担保、外部連携、例外処理の構築などには、依然として緻密な設計と実装が求められます。
　しかし、プロトタイプにはこの「見えない8割」がほとんど組み込まれていません。そのため、「画面が動いているからといって、そのまま本番環境で使えるわけではない」という事実を事前に関係者へ徹底して周知しておく必要があります。
　この認識ギャップを放置したままプロジェクトを進めると、以下のような事態を招き、要件定義フェーズでの期待値コントロールが極めて困難になります。

• コストやスケジュールに対する不信感

　「AIを使えばシステムはすぐに作れる」と思い込まれ、RFPでのベンダーからの妥当な見積もりに対して「なぜこんなに費用と期間がかかるのか」と社内から不満が噴出してしまう。

• プロトタイプの「仕様化」による硬直

　あくまで検証用だったはずのUIが「既定路線の仕様」として社内で独り歩きを始め、「後戻りできない状態」に陥ってしまう。

「画面仕様の要求」は「UXを実現する一例」 として提示する

　「バイブコーディングで生成されたUI（画面分割や特定のボタン配置など）は、あくまで解決策の「一例」に過ぎません。これを「唯一の正解」としてRFPの要求定義に固定してしまうと、ベンダーからのより優れた提案を封殺することになってしまいます。
　では、RFPにはどのように書けば良いのでしょうか。
　「UXの実現（目的）」を明記したうえで、プロトタイプで作成した「画面構成」をあくまで一例として提示することです。
　前述の「営業先サジェスト機能」を参考に考えてみましょう。
　ここでの「実現したい体験（UX）」と「フロントエンドの要求（手段）」は、それぞれ以下のようになります。

• UXの実現（目的）

AIの提案に対して現場の判断を即座にフィードバックし、サジェスト精度を継続的に高める仕組み作り。

• フロントエンドの要求（手段）

上記を実現する一例として、「サジェストされたリストに対して、現場が即座に『採用／却下』を選択でき、加えてその理由を記録できる」インターフェース。

　もし「UXの実現（目的）」だけを書いた場合、ベンダーからの提案は「弊社の〇〇ツールでフィードバック管理が可能です」といった、具体性の欠片もない曖昧なものになりがちです。
　一方で「画面構成（手段）」だけを提示してしまうと、ベンダーは思考停止に陥り、「とりあえず言われた通りにボタンと入力欄を作ればいい」という受け身の姿勢を招きます。そうなるとベンダーからより良い提案を受けられなくなってしまいます。

重要な部分だけをバイブコーディングで可視化する

　バイブコーディングで手軽に画面が作れることが社内で認知されると、経営層やプロジェクトメンバーから「簡単に作れるなら、全画面のUIを作ってよ」という要望が挙がることがよくあります。
　しかし、全画面のUIをバイブコーディングで作成するのは、リソースの割き方として非常に効率が悪いです。なぜなら、ログイン画面や標準的なデータ一覧画面など、既存のSaaSや一般的なシステムでも容易に想像がつきます。それらの画面まで、わざわざプロトタイプを作る必要はありません。
　「画面を作る」こと自体が目的化してしまうと、「真に必要な要求（What）を可視化する」という本来の目的を見失ってしまいます。
　バイブコーディングを活用すべきなのは「頭の中のイメージだけでは、実現するための具体的な機能（UX）が想像しきれない部分」に限定しましょう。

非機能要件の記載漏れ

　バイブコーディングで作るプロトタイプは、手元の環境や少量のダミーデータで動かすため、非常に軽快に動作します。この「サクサク」とした快適な体験により、発注者は「本番環境でもこのスピードで動くのが当然だ」と錯覚しがちです。
　その結果、応答速度や同時アクセス数、データ容量といった「非機能要件」の定義を疎かにしてしまう危険性があります。
　こうした要件の記載が漏れると、納品後に「動作が重くて実務に耐えないシステム」という最悪の結果を招きかねません。プロトタイプの操作感に惑わされず、RFPには必ず性能に関する要求事項を明記しましょう。

まとめ

　バイブコーディングの登場により、発注者はベンダーが参画する前の段階で、自ら「動くUX」を体験する手段を手に入れました。
　これにより、システムイメージの解像度は飛躍的に高まります。精緻なフロントエンド要求をRFPに反映できれば、ベンダーから自社の課題に寄り添った「独自の解決策」を引き出すことが可能です。発注者側も、提示された提案をより高い精度で評価できるようになります。
　一方で、バイブコーディングは決して万能な技術ではありません。
　本稿で触れたように、「UIの完成」を「システムの完成」と錯覚しないための期待値コントロールは不可欠です。生成された画面をあくまで「要件を具体化するための検証ツール」と割り切るなど、技術に対する正しい理解と適切な距離感が求められます。その限界やリスクを正しくコントロールできれば、バイブコーディングは強力な武器となります。
　本稿で紹介した手法を実践し、後悔のないベンダー選定、そしてプロジェクトの成功へと繋げていただければ幸いです。

---

(*1)エージェント型IDEツール：
AIエージェントを内蔵した統合開発環境のことです。CursorやGoogle Antigravityがその代表格です。AIとの対話を通じて、仕様策定からコーディング、デバッグまでを一気通貫で実行できる環境を指します。

(*2)クロスサイトスクリプティング：
Webサイトの脆弱性を狙ったサイバー攻撃の一つ。掲示板や入力フォームなどに悪意のあるプログラムを紛れ込ませ、そのページを閲覧した他のユーザーの画面上で強制的に実行させる手口を指します。

(*3)コンテキストウィンドウの不足：
開発が進みコード量が膨大になると、AIが過去の文脈や指示を記憶しきれなくなる現象を指します。この状態に陥ると、以下のような問題を引き起こすことがあります。
・修正済みの不具合が再発する
・初期に定めた設計ルールから突然逸脱してコーディングを行う

2026年03月11日 (水)

青山システムコンサルティング株式会社

柴田 将吾