はじめに
こんにちは、テックラボの伊藤です。 最近よく聞く「Vibe Coding」ですが、これまでちゃんと試したことがありませんでした。 テックラボでは、過去に木下さんがVibe Codingによる機械学習モデルの構築を行っていましたが、今回はVibe Codingによるアプリ開発にチャレンジしてみました。
作ったものは、動画の音声を文字起こしした内容をもとに、RAG(Retrieval-Augmented Generation)で回答生成するアプリです。
この記事では、
- どんな手順でVibe Codingを進めたか
- ChatGPT / GitHub Copilotとの付き合い方
- 良かった点・ハマった点
あたりを振り返ってみます。
Vibe Codingの進め方
Vibe Codingの進め方は、「個人的 Vibe Coding のやりかた」という記事を参考にしました。 記事で紹介されていたVibe Codingの手順を簡単にまとめると、以下の通りです。
- 要件定義: 何を作るか、ターゲット、機能、画面構成などをAIと会話しながら決定し、
要件定義.mdにまとめる - 技術選定: 使用技術や構成を事前に決めることで、AIが意図しない技術で進めるのを防ぐ。DBやAPI設計もMarkdown化
- コードベース作成:
要件定義.mdを配置し、APIやクライアントの作成などを段階を踏んで進める。それぞれの段階で動作確認してエラー修正 - 微調整: リファクタリングや文言の調整
自分も基本的にはこの流れに沿いつつ、ところどころ順番を間違えながら進めました自己流でアレンジしました。
要件定義フェーズ
要件定義
まずはChatGPTに相談しながら要件定義を行いました。 記事では要件定義と技術選定を分けていましたが、要件定義と技術選定を同時に進めました。
- 何を作るのか
- 誰が使うのか
- どんな機能が必要か
といった基本的なところから、
- チャンクの粒度(ベクトルデータベースに保存するテキストの長さ)
- 検索結果の表示の仕方
まで、一通りChatGPTと会話しつつ詰めていきました。
要件定義の抜けを確認する時にもChatGPTに質問しましたが、かなり細かいことまで大量に列挙してくれました。 面倒だからAIに任せてるのに、相棒が神経質すぎてうんざりしてしまったので、非機能要件(パフォーマンス、ログ)に関する質問はすべて無視しました。
技術選定
どの技術を使えばよいか迷ったときは、その都度ChatGPTに質問し、候補となる技術のメリット・デメリットを教えてもらいながら技術選定しました。
最終的な構成はこんな感じです。
- 文字起こし: Whisper(日本語/英語対応)
- 埋め込みモデル: text-embedding-3-large (Azure OpenAI Service)
- 生成モデル: gpt-4.1-mini (Azure OpenAI Service)
- ベクトルデータベース: Qdrant
- RAGパイプライン: LangChain(Python)
- UI: Streamlit
- 開発環境: Databricks または Azure VM
- プログラミング言語: Python
要件定義のMarkdown化
ある程度会話が進んだところで、記事の通り
ここまでの内容を要件定義.mdにまとめてください
と丁寧にお願いして1、要件をMarkdownとして整理してもらいました。 要件定義の抜けを確認したときに確定させなかった事項についても、AIがよしなに決めてくれます。
実際に出力された要件定義.mdの内容は、以下のような感じです(一部抜粋)。
# ClipSearch 要件定義書 (プロトタイプ版)
## 1. 概要
ClipSearch は、社内の動画データおよび会議ログ(日本語・英語)を対象に、文字起こし・チャンク化・ベクトル検索・生成AI を組み合わせて必要な情報を素早く検索できる RAG(Retrieval-Augmented Generation)システムのプロトタイプである。
本書は、プロトタイプ構築に必要な要件を整理した要件定義書である。
---
## 2. システム構成要素
- **文字起こし**: Whisper(日本語/英語対応)
- **埋め込みモデル**: Azure OpenAI Service の埋め込みモデル
- **生成モデル**: Azure OpenAI GPT-4-mini
- **ベクトルデータベース**: Qdrant
- **RAGパイプライン**: LangChain(Python)
- **UI**: Streamlit
- **開発環境**: Databricks または Azure VM
- **プログラミング言語**: Python
...
以上がプロトタイプ用の要件定義となる。
この要件定義.mdを、そのまま 後のコード生成の「設計書」兼「プロンプト」 として使いました。
コードベースの作成
全体のコード生成
次に、要件定義.mdを読み込ませてGitHub Copilotでコード生成を行いました。参考にした記事では段階を踏んでコード生成していましたが、今回は一気にコードを生成してみました。
- バックエンド
- フロントエンド
- RAGのパイプライン
を、まとめて最初のたたき台として出してもらうイメージです。

環境構築
今回はCodexやClaude CodeのようなCLIベースのツールではなく、GitHub Copilotに聞きながら環境構築を進めました。
- 必要なライブラリとそのインストール方法を教えてもらう
- 全体のコード生成で作られなかったQdrant用のdocker-compose.ymlを作ってもらう
- 足りないものやエラーが出たら、その都度Copilotに質問する
といった形で、VS Codeの中で完結させています。
バグ修正
開発時間のかなりの割合を、このバグ修正に使いました。 全体のコード生成でアプリのほとんどの部分は一瞬でできましたが、残り少しの部分でハマってしまいました。 90対90の法則もそうですが、完成までの最後の10%に時間がかかることを実感します。
バグ修正のときにやったことはシンプルで、
- アプリを実行する
- エラーが出る
- エラー出力をGitHub Copilotに入力する
- 修正案をもらって直す
- もう一度実行する
を、ひたすら繰り返しました。 論理的思考は放棄し、エラー出力をそのままAIに投げて解決してもらいます。 AIの力を借りれば、私も1日に10,000行以上のプログラムを書くことができるエンジニアになれそうです。
発生したバグの中で特に多かったのは、環境やライブラリのバージョンによるエラーです。
- 参照情報が古く、古いバージョン前提のコードが混ざる
- Qdrantのサーバーとクライアントのバージョン違い
- 廃止されたメソッド
QdrantClient.search()の使用
社内環境ではGitHub Copilotがインターネット検索を使えず、古い情報を参照していたようです。
微調整
急いでアプリを完成させたかったので、リファクタリングや文言の調整はしませんでした。
完成
実際に動画を取り込み、RAG検索できることを確認しました! 結果として、1週間でプロトタイプが完成しました。

感想
関数ごとにコードを生成(「○○する関数を定義して」)してもらう使い方はしたことがありましたが、コード全体を丸ごと生成したのは今回が初めてでした。 1週間でアプリが完成し、意外と問題なく動いたので、今後もVibe Codingを積極的に活用していきたいと思いました。
良かった点
短い期間で気軽にアプリ開発ができる
要件定義からUIまで、一気に「動くもの」まで持っていけた。README.mdなどの面倒でさぼりがちなドキュメントも自動で更新してくれる
普段なら後回しにしてしまうドキュメント周りも、AIに任せることで最低限の品質を確保できた。生成されたコードが読みやすかった
シンプルなアプリだったこともあり、個人的には「あとから自分で保守できそう」なレベルのコードになっていた。
悪かった点・ハマりどころ
要件定義に反した実装
要件定義・技術選定の段階で「LangChainを使って実装する」と決めていたはずが、生成されたコードはLangChainを全く使わずに実装されていました。 アプリが完成してから気づきました。 AIを信頼しすぎたかもしれません。
環境構築が原因のバグ
参照情報が古いのか、古いバージョンのライブラリを前提としたコードが生成されてしまいました。 社内環境ではGitHub Copilotのインターネット検索が制限されており、最新の情報を前提としたコードにはならなかったようです。 具体的には、
- Qdrantサーバーとクライアントのバージョン違い
- 廃止された
QdrantClient.search()の使用
などの問題が発生しました。
生成されたrequirements.txtには、qdrant-client>=1.11.0と書かれていたので、ライブラリのバージョンを固定するか、インストールされたバージョンをAIに伝えていれば防げたかもしれません。
余計な実装
おそらく「リファクタリングして」という指示である程度整理できると思いますが、まったく使われていない関数が作成されていることもありました。 生成・動作確認の後に「未使用コードの削除」や「リファクタリング」の指示を行う必要がありそうです。
まとめ
Vibe CodingとAIツール(ChatGPT / GitHub Copilot)を使って、
- 要件定義〜技術選定をAIと会話しながら進める
要件定義.mdをそのまま「設計書兼プロンプト」として使う- コードベース全体を一気に生成し、エラーを潰しながら整えていく
という流れで、文字起こしRAGアプリのプロトタイプを1週間で構築することができました。
一方で、
- 要件定義どおりの技術が使われないことがある
- ライブラリのバージョン起因のエラーは普通に発生する
- 余計なコードも混ざる
といった問題もありました。 人間のエンジニアでも起きそうなミスではあるので、実際の開発の際には、他の人が書いたコードをレビューするような感覚でAIが生成したコードをチェックする必要があるなと感じました。

- AIを無下にするとスカイネット(ターミネーターに登場するAI)に何をされるかわからないので、日頃から指示を出すときは丁寧にお願いしています。また、「AIに丁寧に接すると精度が上がるが、余計なコストがかかる」という話もあります。↩