はじめに
最近話題のバイブコーディング（Vibe Coding）をご存知でしょうか？
従来のプログラミングでは、開発者がコードを一行一行書いていました。
バイブコーディングでは、AIに自然言語で「こういうアプリを作って」と指示するだけで、AIがコードを生成してくれます。
「コードを書く」から「AIと会話する」へ。
本記事では、バイブコーディングでRAG（検索拡張生成）チャットBotを作った体験をお伝えします。
しかも、
- 完全ローカル動作
という構成です。
後半では、GitHub CopilotのClaude Opus 4.6とOpus 4.5で同じプロンプトを投げた場合の比較もやってみました。
対象読者
- バイブコーディングに興味がある方
- RAGを試してみたい方
- ローカルLLMに興味がある方
- GitHub Copilotの実力を知りたい方
作ったもの
ローカルLLMで動くRAGチャットBotです。
ローカルに配置したテキストファイルを読み込ませておくと、その内容をもとにチャットで質問に答えてくれるアプリです。
社内ドキュメントなど、外部に送信したくないデータを扱う用途を想定しています。
デモ画面
※ 以下のデモ画面およびテスト結果は、すべて検証用に作成した架空のダミードキュメントに基づいています。実際の社内ドキュメントは使用していません。
システム構成
ユーザー
↓ 質問
Streamlit（チャットUI）
↓
RAGエンジン
├── ドキュメント読み込み → チャンク分割
├── sentence-transformers → ベクトル化
├── FAISS → 類似ドキュメント検索
└── Ollama（llama3） → 回答生成
↓
ユーザーに回答を表示
技術スタック
| コンポーネント | 技術 |
|---|---|
| LLM | Ollama + llama3 |
| Embedding | sentence-transformers |
| ベクトルDB | FAISS |
| UI | Streamlit |
| コード生成 | GitHub Copilot + Claude Opus |
外部APIキーは一切使っていません。
環境
| 項目 | 内容 |
|---|---|
| OS | Ubuntu 22.04 |
| GPU | NVIDIA製GPU（VRAM 20GB） |
| Python | 3.10.12 |
| Ollama | Ollama 0.16.2 |
| ローカルLLM | llama3 |
| エディタ | VS Code + GitHub Copilot |
| AIモデル | Claude Opus 4.6 / Opus 4.5 |
事前準備
Ollamaのインストール
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows: https://ollama.com/download からインストーラをDL
LLMモデルのダウンロード
ollama pull llama3
動作確認
ollama run llama3 "こんにちは"
バイブコーディング実践
使ったプロンプト（全文）
VS CodeのGitHub Copilot ChatでClaude Opus 4.6を選択し、以下のプロンプトをそのまま投げました。
以下の要件でRAGチャットBotのWebアプリを作ってください。
## 要件
- Python + Streamlitで構築
- 指定フォルダ内のテキストファイルを読み込む
- テキストをチャンク分割してベクトル化する
- ユーザーの質問に対して、関連するドキュメントを検索し、
それを元にLLMが回答を生成する
- チャット形式のUIで、会話履歴が表示される
## 技術スタック
- ベクトルDB: FAISS（ローカルで完結）
- Embedding: sentence-transformers（ローカルで完結）
- LLM: Ollama（ローカルで動作するllama3を使用）
- OllamaのAPIエンドポイント: http://localhost:11434
- requestsライブラリでOllamaのREST APIを叩く
- POST http://localhost:11434/api/generate
- UI: Streamlit
## 重要な制約
- 外部APIキーは一切使わない
- 全てローカルで完結すること
- OpenAIのライブラリは使わない
## ファイル構成
- app.py（メインアプリ）
- rag_engine.py（RAGのロジック）
- requirements.txt
- docs/（ドキュメント格納用ディレクトリ、既に作成済み）
一つずつファイルを作成してください。
これだけです。 コードは1行も自分で書いていません。
AIとのやり取り
プロンプトを投げると、Opus 4.6はファイル生成からライブラリインストール、アプリ起動まで一気に実行してくれました。ただし、初回は日本語の検索がうまく機能しませんでした（理由は後述）。
生成されたファイル
プロンプトを投げた結果、以下のファイルが自動生成されました。
-
app.py（121行） -
rag_engine.py（205行） -
requirements.txt（4行、バージョン指定あり）
動作確認
起動方法
pip install -r requirements.txt
streamlit run app.py
RAGが正しく動いているかテスト
検証用に作成した架空のダミードキュメントに対して、ちゃんと検索して回答できるか以下の質問でテストしました。
テスト1: ドキュメントに書いてある情報の取得
質問: 「対応しているカメラメーカーを教えて」
正しく回答できています。
テスト2: ドキュメントに存在しない情報への対応
質問: 「顔認識の精度はどのくらいですか？」
「情報がない」と正確に回答できています。
テスト3: 複数ドキュメントの横断検索
質問: 「検出が遅い場合の対処法と、推奨フレームレートを教えて」
複数のドキュメントから横断して回答できています。
テスト4: 意味的な検索
質問: 「誤検知を減らすにはどうすればいい？」
正しく回答できています
テスト結果まとめ
| テスト | 質問 | 正しく回答できたか |
|---|---|---|
| 1 | 対応カメラメーカー | ○ |
| 2 | 顔認識の精度（存在しない情報） | ○ |
| 3 | 複数ドキュメント横断 | ○ |
| 4 | 意味的な検索 | ○ |
Claude Opus 4.6 vs 4.5 比較
ここからは同じプロンプトをClaude Opus 4.5にも投げて、生成結果を比較してみました。
比較条件
- プロンプト: 完全に同一
- ダミードキュメント: 完全に同一
- 実行環境: 同一マシン
- 評価方法: 生成されたコードをそのまま実行
コード生成の比較
| 比較項目 | Opus 4.6 | Opus 4.5 |
|---|---|---|
| 生成されたコードの総行数 | 331行 | 370行 |
| ファイル数 | 3 | 3 |
| Embeddingモデル | all-MiniLM-L6-v2（初回） | all-MiniLM-L6-v2 |
| Ollama APIエンドポイント | /api/chat |
/api/generate |
| requirements.txtのバージョン指定 | あり | なし |
生成されたコードの構成はほぼ同じで、品質にも大きな差はありませんでした。
Opus 4.6は/api/chatエンドポイントを使い、system/userメッセージを分離する構成。Opus 4.5は/api/generateエンドポイントで単一のプロンプトに埋め込む構成でした。
コマンド実行の振る舞いの違い
バイブコーディングにおいて最も体感差が大きかったのが、コマンド実行の振る舞いです。
| 振る舞い | Opus 4.6 | Opus 4.5 |
|---|---|---|
| ファイル生成 | ✅ 自動実行 | ✅ 自動実行 |
pip install |
✅ 自動実行 | ❌ コマンドを提示するだけ |
streamlit run app.py |
✅ 自動実行 | ❌ コマンドを提示するだけ |
VS Codeのセッション内でコマンド実行を許可している場合、Opus 4.6はファイル生成 → ライブラリインストール → アプリ起動まで一連の流れを自動実行してくれました。
一方、Opus 4.5はコードの生成は行ってくれるものの、「以下のコマンドを実行してください」という回答が返ってくるだけで、実際の起動は手動で行う必要がありました。
「プロンプトを投げたら動くアプリが立ち上がる」というバイブコーディング体験として、Opus 4.6の方がよりシームレスでした。
日本語Embeddingモデルの問題
両モデルとも、初回生成で使われたEmbeddingモデルはsentence-transformers/all-MiniLM-L6-v2でした。
このモデルは英語に特化しており、日本語のドキュメントに対するベクトル検索の精度がかなり低い状態でした。
そこで、GitHub Copilotに「日本語に対応していないので修正してほしい」と伝えたところ、Opus 4.6はsentence-transformers/paraphrase-multilingual-MiniLM-L12-v2（多言語対応モデル）に修正してくれ、日本語の検索が正しく機能するようになりました。
# 修正前（英語特化）
all-MiniLM-L6-v2
# 修正後（多言語対応）
paraphrase-multilingual-MiniLM-L12-v2
これはバイブコーディングの重要な教訓です。AIが生成したコードでも、ドメイン固有の知識（例: 日本語対応のモデル選定）は人間が判断・指示する必要があります。
比較して感じたこと
- コード品質に大きな差はなかった: 両モデルとも構造化されたコードを生成し、エラー処理やドキュメンテーションも適切でした
- 体感の差はコマンド実行にあった: Opus 4.6がアプリ起動まで自動実行してくれる点は、バイブコーディングの「何もしなくていい」体験を大幅に向上させました
- モデル選定は人間の責任: 両モデルとも英語特化のEmbeddingモデルを選んだ点は同じで、日本語対応の判断はAIだけでは不十分でした
まとめ
バイブコーディングで分かったこと
- コードを1行も書かずにRAGチャットBotが動いた: プロンプト1つでファイル生成からアプリ起動まで完結する体験は衝撃的でした
- AIが苦手な部分もある: 日本語対応のEmbeddingモデル選定など、ドメイン知識が必要な判断は人間がフォローする必要がありました
- 「対話で修正」が自然にできる: 問題を日本語で伝えるだけで修正してくれるため、コードを読まなくても改善サイクルが回せました
ローカルLLM × RAGの価値
- APIキー不要: セキュリティ的に社内データを外部に送らなくて済む
- 完全無料: 従量課金の心配がない
- オフライン動作: ネットワーク環境に依存しない
特に社内ドキュメントを扱うRAGでは、データを外部APIに送信しなくて良いローカルLLMの構成は大きなメリットです。
Opus 4.6 vs 4.5
今回の検証では、生成されるコードの品質に大きな差は見られませんでした。どちらも構造化されたコードを生成し、RAGチャットBotとして正しく動作しました。
差が出たのは開発体験の部分です。Opus 4.6は「プロンプトを投げたらアプリが起動する」ところまで自動でやってくれるため、バイブコーディングの体験としてはOpus 4.6の方が一歩先を行っていました。
ただし、日本語Embeddingモデルの選定のようにAIだけでは判断できない領域もあるため、バイブコーディングは「AIに任せきり」ではなく「AIと協働する」姿勢が重要だと感じました。
最後に
ここ1〜2年のAIの進化は本当にすさまじいものがあります。特にGitHub CopilotやClaude CodeといったAIを活用した開発支援ツールの技術レベルは、驚異的なレベルにまで到達していると感じます。
「プロンプトを1つ投げるだけでアプリが動く」——ほんの数年前には想像もできなかったことが、今や当たり前のように実現できる時代になりました。この流れはまだまだ加速していくでしょう。開発者として、この波にうまく乗っていきたいですね。
参考
注意事項
本ブログに掲載している内容は，私個人の見解であり，所属する組織の立場や戦略，意見を代表するものではありません．あくまでエンジニアとしての経験や考えを発信していますので，ご了承ください．