🤖 バイブコーディング？」正直よく分からないので整理してみた

📌 はじめに

最近、「バイブコーディング」という言葉をよく見かけるようになりました。

CursorやWindsurfのようなAI対応IDEが登場し、「エージェント」や「MCP」といった新しい概念も次々と出てきています。でも正直、サービスやプロダクト、モデルが多すぎて、もう何がなんだか分からない...😅

技術系の記事を読むたびに新しい言葉が登場して、「これって何？」と思いながらそっと記事を閉じる。そんな経験、ありませんか？

僕自身、Cursorを使っているものの、IDEとモデルとエージェントの役割分担がまだ曖昧なまま、なんとなく使っている状態です。

だからこそ、一度立ち止まって、これらの概念や関係性を整理してみたいと思いました。この記事では、自分なりにAIコーディングを構成する要素をレイヤー構造で整理しています。

※ 僕自身も「これからバイブコーディングをちゃんと理解していこう」と考え始めた段階なので、ここに書いている内容は完成された答えというより、理解を深めるための整理メモに近いです。一緒に学んでいきましょう！

📌 バイブコーディングのレイヤー構造

色々とサービスやプロダクトやモデルを見ていって、こんな感じで分類できるんじゃないかなと思いました。

レイヤー	役割	代表例
インターフェース	人間が操作する環境（IDE / CLI / アプリ生成）	Cursor / Windsurf / VS Code / Replit / Kiro / GitHub Copilot / Claude Code / Bolt.new / Lovable / CodeRabbit
エージェント	作業を判断・実行する主体	Cursor Agent / Devin / Continue Agent
AI基盤	モデル実行環境 + 生成AI	OpenAI API / Anthropic API / GPT-5 / Claude / Gemini
外部連携	MCP + MCPサーバー	Model Context Protocol / Docker MCP / Filesystem MCP

ここで示しているレイヤー構造は正式に定義されているものではありません。僕なりにレイヤーとして分解・整理してみたものです。

正直、レイヤーに当てはまらないプロダクトとか、複数あてはまるものもあって、MECEでもないので、「こうやって分類したんだ〜」程度に思ってください。

📌 インターフェース層

インターフェース層は、人間が実際に画面を見て操作しながら開発を進めるための作業環境です。

コードを書いたり、差分を確認したり、AIに指示を出したり、アプリを生成したりと、人間が日常的に触っているインターフェース部分がこのレイヤーです。

ここで注意したいのは、IDE自体が推論したりコードを生成したりしているわけではなく、あくまで、モデルやエージェントを呼び出して使っている側であり、それらの結果を人間に分かりやすく見せ、操作できるようにしているということです。

インターフェース層は、以下の5つのカテゴリに分類できます：

カテゴリ	説明	代表例
IDE 本体	AI機能が組み込まれた統合開発環境	Cursor、Antigravit、Windsurfなど
IDE拡張プラグイン	既存IDEにAI機能を追加する拡張	GitHub Copilot、Continue、Roo Codeなど
CLI インターフェース	コマンドライン上でAIとやり取りするツール	Claude Code、aider、Cursor CLIなど
アプリ生成プラットフォーム	自然言語からフルスタックアプリを自動生成	Bolt.new、Lovable、v0など
コードレビューツール	AIを活用したコードレビュー自動化ツール	CodeRabbitなど

（1）IDE 本体

人間が直接操作し、AIと対話しながら開発を進めるための環境です。

プロダクト	位置づけ	特徴・補足
Cursor	AIネイティブIDE	エージェント機能が標準搭載。最も人気のAIネイティブIDE
Antigravit	AIネイティブIDE	Google発のAI IDE
VS Code（＋AI拡張）	汎用IDE + AI拡張	本体は従来IDE。Copilotや拡張でAI機能を追加。広く使われている
JetBrains（＋AI拡張）	汎用IDE + AI拡張	IntelliJ IDEA/PyCharm/WebStorm/GoLandなど。JetBrains AI AssistantやCopilotでAI機能を追加
Windsurf	AIネイティブIDE	Cursorと同系統
Kiro	AIネイティブIDE	spec-driven developmentを特徴とする。Code OSSベース（VS Code互換）。CLIも提供。MCPサポートあり
Replit	クラウドIDE	ブラウザベース。エディタ・ターミナル・デプロイ環境を一体化。AIは強化機能として追加

（2）IDE拡張プラグイン

IDE に組み込まれ、コード補完やエージェント機能を提供するコンポーネントです。

プロダクト	特徴・補足
GitHub Copilot	VS CodeやJetBrains IDEなどに統合可能。最も有名なコード補完ツール
JetBrains AI Assistant	JetBrains提供。IntelliJ IDEA/PyCharm/WebStorm/GoLandなどJetBrains IDEに統合。コード補完・生成・AIチャット・ドキュメント生成・テスト生成を提供。VS Code拡張としても利用可能
Continue	VS Code拡張として動作。無料でエージェント機能あり
Roo Code	VS Code拡張（オープンソース、無料）。ロール別エージェント（Architect/Code/Ask/Debug/Test）。モデル非依存。マルチファイル編集・コマンド実行可能
Codeium	個人向け無料のAIコーディングアシスタント。70以上の言語、40種類以上のIDEに対応。プライバシー重視
Amazon CodeWhisperer	AWS提供。個人利用無料。セキュリティスキャン機能あり。AWSサービスとの統合が強み
Amazon Q Developer	AWS提供。エージェント機能あり。IDE拡張（JetBrains/VS Code/Visual Studio/Eclipse）とCLI対応。AWSコンソール/Slack/Teamsでも利用可能。無料利用枠あり
IntelliCode	Microsoft提供。Visual Studio / VS Code向け。無料でコード補完機能を提供
Cline	VS Code拡張として動作。Plan → Act 型のエージェント
Tabnine	VS Code / JetBrains 向け拡張。コード補完に特化

（3）CLI インターフェース

エディタではなく、コマンドライン上で AI とやり取りするインターフェースです。

プロダクト	特徴・補足
Claude Code	Anthropic公式。ClaudeをCLIから操作。リポジトリ文脈を読みやすい。人気のCLIツール
aider	Git連携が強いCLIエージェント。差分ベースでコード編集
Kiro CLI	Kiro付属。ターミナルからエージェント機能を利用可能。SSH経由での操作も可能
Cursor CLI	Cursor付属。IDE操作をCLIから補助的に実行
Continue (CLIモード)	VS Code拡張が有名だがCLI利用も可能
Amazon Q Developer CLI	AWS提供。CLIオートコンプリートとAIチャット。ローカルおよびSSH経由で利用可能
OpenAI Codex CLI	OpenAI公式CLI。自然言語からコード生成・修正

（4）アプリ生成プラットフォーム

自然言語の要望から、フルスタックアプリケーション（フロント・バックエンド・DB・認証など）を一式自動生成するプラットフォーム。コード編集が主目的ではなく、アプリ生成に特化。

プロダクト	特徴・補足
Bolt.new	マルチエージェント開発。複数のエージェントがUI・ロジック・バックエンド・状態管理を分担して生成
Lovable	シンプルでopinionatedな設計。Supabaseなどと強く連携。MVPやデモ作成に最適
v0	Vercel提供。Reactコンポーネントを自然言語から生成

（5）コードレビューツール

AIを活用してコードレビューを自動化するツール。プルリクエスト、IDE、CLIなど複数のインターフェースで利用可能。コード生成が主目的ではなく、コードレビューに特化。

プロダクト	特徴・補足
CodeRabbit	AIコードレビューに特化。PRレビュー（GitHub/GitLab/Bitbucket）、IDEレビュー、CLIレビューに対応。バグ検出、コード品質向上、カスタマイズ可能なレビュー設定を提供

📌 エージェント

エージェントは、モデルを使いながら作業を段階的に進めるための制御レイヤーです。

平たく言えば、モデルに「何をどう考えさせるか」を管理する役割を担います。

エージェントは、以下のカテゴリに分類しました。

カテゴリ	説明	代表例
🎯 インターフェース組込型	インターフェース（IDEやCLIなど）に組み込まれ、プロジェクト文脈を理解しながら作業を進めるエージェント	Cursor Agent、Continue Agent、Roo Code Agentなど
🎯 自律エージェント	インターフェースに組み込まれる前提ではなく、タスクを自律的に分解・実行する「仮想エンジニア」に近い存在	Devin、SWE-agent、OpenHandsなど

🎯 インターフェース組込型

インターフェース（IDEやCLIなど）に組み込まれ、プロジェクト文脈を理解しながら作業を進めるエージェントです。

エージェント名	組み込み先	特徴
Cursor Agent	Cursor	プロジェクト全体を文脈として理解し、複数ファイル編集や修正を自律的に実行。最も人気のエージェント
Copilot Workspace / Copilot Agent	GitHub Copilot	VS Code / GitHub。タスク単位でコード生成・修正を行う方向に進化中
Kiro Agent	Kiro	spec-driven developmentを特徴とする。要件→設計→実装計画→コード生成の流れを自動化
Roo Code Agent	VS Code（拡張）	ロール別エージェント（Architect/Code/Ask/Debug/Test）。モデル非依存。マルチファイル編集・コマンド実行可能。オープンソース
Continue Agent	VS Code（拡張）	ローカルLLMやAPIを使い、比較的透明なエージェント挙動。無料で使える
Amazon Q Developer Agent	IDE拡張/CLI/AWSコンソール/Slack/Teams	エージェントコーディング機能。機能実装・文書化・テスト・レビュー・リファクタリング・アップグレードを自律実行。SWE-Bench Leaderboardで最高スコア達成
Cline Agent	VS Code（拡張）	Plan → Act 型で、実行前に計画を提示するエージェント

（１）エージェントはインターフェース側のロジック

インターフェース内エージェントの「考えて → 試して → また考える」という振る舞いは、生成AI（モデル）そのものの機能ではありません。

これは、生成AI（モデル）自身の機能ではなく、Cursor などのインターフェースに組み込まれたエージェント実装が、モデルを何度も呼び出すための制御ロジックを持っていることで実現されています。

（２）エージェントが扱う情報

エージェントがモデルを呼び出す際には、以下の情報がまとめて入力として渡されます。

種類	内容
エージェント用の前提プロンプト	エージェントとしての役割や振る舞い方、制約条件。作業の進め方や判断の前提となるもの
ユーザーの指示	ユーザーがやりたいこと、達成したい目的
現在のプロジェクト状態	開いているファイル、差分、プロジェクト構造など

これらの情報が毎回まとめてモデルに渡され、モデルが何度も呼び出されながら、作業の分解や検討、コード生成が行われます。

（３）エージェント用の前提プロンプト

この中で特に重要なのが、エージェント用の前提プロンプトです。

ユーザーの指示はその都度変わりますが、エージェント用の前提やルールはインターフェース側であらかじめ設定されています。

エージェントの前提やルールの詳細は、通常ユーザーに公開されていませんが、仕組みをイメージしやすくするため、ここでは簡略化したサンプルを掲載します。

あなたはインターフェースに組み込まれた AI エージェントです。
	•	ユーザーの指示を達成するために、作業を段階的に進めてください。
	•	現在開いているプロジェクトの文脈を重視してください。
	•	操作できるのは、ワークスペースとして開かれている範囲のみです。
	•	危険な操作や不明点がある場合は、必ずユーザーに確認してください。

ユーザーの開発を安全に前進させることを最優先に行動してください。

同じモデル（GPT や Claude など）を使っていても、インターフェースごとに使い勝手や挙動が大きく異なるのは、エージェント用の前提やルール（内部プロンプト）の設計が異なるためです。

########（４）エージェントが操作できる範囲について

インターフェースに組み込まれたエージェントは、開いているプロジェクトの範囲内であれば、ソースコードの編集やファイルの変更といった作業を自律的に行うことができます。

ただし、これはインターフェースが許可している範囲に限られたものです。

例えば Cursor のエージェントは、「ユーザーがワークスペースとして開いた範囲」に限って、ローカルアプリとしての権限でファイル操作を行います。

そのため、プロジェクト外のディレクトリや、OS 全体を自由に操作できるわけではありません。

🎯 自律エージェント

インターフェースに組み込まれる前提ではなく、タスクを自律的に分解・実行する「仮想エンジニア」に近い存在です。

• インターフェースのワークスペース制限を前提としない
• 固定された「インターフェース用前提プロンプト」を持たない
• 実行範囲や権限管理を独自に設計する

といった点で、インターフェース内エージェントとは **設計思想が根本的に異なります。

プロダクト	特徴
Devin	仮想エンジニア。タスクを自律分解し、実装・実行・修正まで一貫して行う。最も有名な自律エージェント
SWE-agent	GitHub Issue を入力として、修正・PR作成まで自律実行
OpenHands（旧 Auto-GPT 系）	CLIベースの自律エージェント。目標を与えると自己ループで実行
Auto-GPT	初期の自律エージェント代表例。実験色が強い
BabyAGI	タスク分解・再計画を行う研究寄りエージェント

📌 AI基盤層

AI基盤層は、生成AI（LLM）を実際に動かし、入力を与えると出力を返すための基盤です。

（1）モデル実行環境

生成AI（LLM）を実際に動かし、入力を与えると出力を返す実行基盤。クラウドAPIまたはローカル環境として提供されます。

実行環境	特徴・補足
OpenAI API	GPT-4 / GPT-5 などのモデルをクラウド経由で利用
Anthropic API	Claude をクラウド経由で利用
Google AI API	Gemini をクラウド経由で利用
LM Studio	ローカル環境でLLMを実行。プライバシー重視の場合に適する

（2）生成AI（モデル / LLM）

モデルとは、いわゆる生成AI（LLM）のことです。

人間から渡された文章やコードを読み取り、その文脈をもとに「次に来そうな内容」を考えて返す、という役割を持っています。

モデルが基本的にやっているのは、

• 与えられた文脈をもとに続きを予測する
• その結果として、文章やコードを生成する
• 質問に対して、それっぽく筋の通った回答を返す

といった処理です。

一方で、ファイルを書き換えたり、コマンドを実行したりするのは、モデルの仕事ではありません。

コード補完や質問応答といった機能は、この「文脈を読んで続きを生成する」というモデルの能力をそのまま利用したものです。

平たく言えば、ChatGPT に質問して回答が返ってくる、あの仕組みだと考えると分かりやすいかもしれません。

モデル名	提供元	位置づけ・特徴
GPT-4 / GPT-5	OpenAI	汎用性が高く、推論・コード生成・文章生成を幅広くカバーする代表的LLM。最も広く使われている
Claude	Anthropic	長文理解や設計思考が強く、エージェント用途や大規模コードベースに向く。人気の高いモデル
Claude Opus	Anthropic	Claudeシリーズの最高性能モデル。高精度だが高コスト
Claude Sonnet	Anthropic	Claudeシリーズの中性能モデル。バランス型
Composer 1	Cursor	Cursor独自開発のコーディング特化型LLM。MoEアーキテクチャ採用。同等レベルの他モデルと比べて約4倍の速度。コーディングタスクを30秒以内で完了
Gemini	Google	Google製LLM。検索・マルチモーダル連携を前提とした設計が特徴
Grok	xAI	xAI社が開発したAIモデル。リアルタイム情報へのアクセスが特徴
Codex	OpenAI	コード生成・補完に特化したモデル（GPT系の派生）
Code Llama	Meta	オープン寄りのコード特化LLM。ローカル実行や研究用途でも使われる

📌 外部連携層

外部連携層は、AIエージェントやインターフェースが外部ツールやデータとやり取りするための仕組みです。

（1）MCP（Model Context Protocol）

MCP（Model Context Protocol）は、AIエージェントやインターフェースが外部ツールやデータとやり取りするための共通の通信ルール（プロトコル）で、考え方としては HTTP や gRPC のような「約束事」に近いものです。

MCPの動作フロー

モデル（LLM）自体はMCPの存在を直接認識しているわけではありません。実際の動作フローは以下のようになります：

1. エージェントがモデルにツールを提示: エージェントが、モデルに対して「MCPサーバーから情報を取得できるツール」を提示する
2. モデルがツールを使うか判断: モデルが「この情報が必要だ」と判断し、そのツールを使いたいと判断する
3. エージェントがMCPサーバーにアクセス: エージェントがMCPクライアントとして実際にMCPサーバーにアクセスする
4. 情報をモデルに渡す: 取得した情報をモデルにコンテキストとして渡す

構造を図にすると、次のようになります。

┌─────────────────────────────────────┐
│ ユーザー                              │
└─────────────────────────────────────┘
      │
      ▼
┌────────────────────────────────────────┐
│ インターフェース / エージェント (Cursorなど) 
│  ┌──────────────────────────────┐  
│  │ モデル（LLM）                    
│  │ → ツールを使うか判断              
│  └──────────────────────────────┘  
└────────────────────────────────────────┘
      │  MCP（共通ルール）
      │  （エージェントがMCPクライアントとしてアクセス）
      ▼
┌────────────┐
│ MCPサーバー 
└────────────┘
      │
      ▼
┌────────────────────────────────────┐
│ Docker / OS / DB / Browser / API    
└────────────────────────────────────┘

注意: MCPに接続するかどうかの判断は、エージェントが提示したツールに対してモデルが判断する形になりますが、実際のMCPサーバーへのアクセスはエージェントが行います。この境界は実装によって異なる場合があり、エージェントとモデルの役割分担は必ずしも明確ではない場合もあります。

例えば、エージェントが「Dockerコンテナ内でテストを実行したい」と考えた場合、MCPを通じて次のような形式で依頼します。

{
  "tool": "docker.exec",
  "arguments": {
    "container": "web",
    "command": "npm test"
  }
}

※ 実際のツール名や引数形式は、利用するMCPサーバーの実装によって異なります。

（2）MCPサーバー

MCPサーバーはMCPクライアント（Cursorなどのインターフェース）からのリクエストを受け取り、Docker やクラウド、外部サービスなどを 実際に操作する役割を担う仕組みです。

例えばCursorでは、以下のページの外部ツールやデータソースと連携することができます。
https://cursor.com/ja/docs/context/mcp

MCP連携を有効にすると、CursorはMCPサーバーを介して、クラウドサービスや外部ツールに対する操作や情報取得を行えるようになります。

MCPサーバー	特徴・補足
Docker MCP	Dockerコンテナの操作を実行
Filesystem MCP	ファイルシステムの操作を実行
Database MCP	データベースへの接続・操作を実行

📌 まとめ

本記事では、いわゆる「バイブコーディング」と呼ばれる開発スタイルについて、レイヤー構造として整理、全体像がかなり見えやすくなると感じています。

今回は概念や関係性の整理が目的で、具体的なベストプラクティスについては、これから調べていく段階です。

ただ、このようなメンタルモデルを一度作っておくことで、新しいツールや概念が出てきたときにも「これはどのレイヤーの話か？」と整理しやすくなるかなと思い、まとめてみました。

僕と同じように「なんとなく使っているけど、全体像がよく分からない」と感じている方の整理のきっかけになれば嬉しいです。