MCP不要論への回答 — バイブコーディングの限界とMCPの本質的価値
SNSを眺めていると、こんな意見が目に入る。
「AIが直接コードを書けるなら、MCPなんて要らなくない？」
一見、筋が通っている。Claude CodeでC#スクリプトを生成すればUnityを操作できる。わざわざ MCP（Model Context Protocol）という仕組みを整備しなくても、目的は達成できる——そういう論理だ。
しかし今日、私はそれで丸半日を無駄にした。
URP（Universal Render Pipeline）のパイプラインアセットを設定するために、C#スクリプトを生成して配置した。作業が終わったあと、そのスクリプトを削除するのを忘れた。次のビルドからコンパイルエラーが連鎖し、原因の特定だけで2時間以上を費やした。MCP API として unity.rendering.createURPAsset が存在していれば、副作用ゼロで1コール、30秒で終わっていた作業だ。
この記事では、「MCP不要論」がなぜ誤りなのかを、この事故を軸に解説する。バイブコーディングが機能するケースとしないケース、そしてMCPが提供する「本質的価値」を整理する。
MCP不要論の主張を整理する
批判の論点はおおむね次の3つに集約される。
- AIはコードを書ける — Claude CodeはC#スクリプトを生成できる。Unityの操作もスクリプト経由で実現できる
- MCPはオーバーヘッド — API設計・実装・メンテナンスのコストが高い
- バイブコーディングで十分 — 「動けばいい」なら、AIに丸投げで問題ない
1と2は事実だ。反論の余地はない。問題は3の前提——「動けばいい」という割り切りが、どこまで通用するかだ。
バイブコーディングが機能するケースとしないケース
バイブコーディングとは、Andrej Karpathy氏が2025年に提唱した「コードを見ずにAIに丸投げする開発スタイル」だ。彼自身が「週末の使い捨てプロジェクト向け」と明言している。
バイブコーディングが機能するケース:
├── プロトタイプ・実験的プロジェクト
├── 使い捨てのスクリプト・ツール
├── 副作用が許容できる環境
└── 結果だけ確認できれば十分な作業
バイブコーディングが機能しないケース:
├── 本番プロジェクトのAsset管理
├── 複数の開発者が関わるチーム開発
├── 副作用が残ると困る操作（ファイル生成・Editor設定変更）
└── 「正しい手順」で実行する必要があるUnity操作
Unity開発でAIを使う場面の多くは、後者に該当する。
実体験：スクリプト生成の副作用事故
何をしたかったか
Unityプロジェクトに URP（Universal Render Pipeline）を導入し、パイプラインアセットを作成・設定する必要があった。
どう対処したか
MCPに該当するAPIがなかったため、Claude Codeに次の作業を依頼した。
-
SetupURPPipeline.csという Editor スクリプトを生成 -
Assets/Editor/に配置 - スクリプトがコンパイルされると自動実行し、URPアセットを作成・設定
生成されたコードはこのようなものだった。
// Assets/Editor/SetupURPPipeline.cs
// URPパイプラインアセットを自動作成・設定するEditorスクリプト
using UnityEditor;
using UnityEngine;
using UnityEngine.Rendering.Universal;
[InitializeOnLoad]
public static class SetupURPPipeline
{
static SetupURPPipeline()
{
// Editorロード時に自動実行
EditorApplication.delayCall += () =>
{
var asset = UniversalRenderPipelineAsset.Create();
var path = "Assets/Settings/URP-Balanced-Renderer.asset";
AssetDatabase.CreateAsset(asset, path);
GraphicsSettings.defaultRenderPipeline = asset;
Debug.Log("[SetupURPPipeline] URPアセットを設定しました");
};
}
}
URPの設定は問題なく完了した。
何を忘れたか
設定完了後、SetupURPPipeline.cs を削除するのを忘れた。
何が起きたか
次にプロジェクトを開いたとき、コンパイルエラーが発生した。URPパッケージのバージョンとAPIの不整合が原因だったが、[InitializeOnLoad] によって Editor起動のたびにスクリプトが走っていたため、エラーが連鎖した。
Assets/Editor/SetupURPPipeline.cs(12,13): error CS0234:
The type or namespace name 'UniversalRenderPipelineAsset' does not exist
in the namespace 'UnityEngine.Rendering.Universal'
エラーの原因がスクリプトにあると気づくまでに約90分。削除して解決するまでにさらに30分。合計2時間以上のロスだ。
MCPがあれば何が変わっていたか
unity.rendering.createURPAsset という MCP API が存在していれば、処理は次の1コールで完了する。
{
"method": "unity.rendering.createURPAsset",
"params": {
"assetPath": "Assets/Settings/URP-Balanced-Renderer.asset",
"setAsDefault": true
}
}
- ファイル生成なし
- コンパイル不要
- 削除忘れリスクなし
- 実行時間：約30秒
「コードを書いて配置して実行して削除する」という一連の副作用を、APIが完全に隠蔽する。
MCPの本質的価値
今回の事故を通じて、MCPが提供する価値は大きく2つに整理できると気づいた。
1. 副作用の隠蔽
スクリプト生成によるUnity操作は、必ず副作用を伴う。
| 操作方法 | 副作用 |
|---|---|
| C#スクリプト生成 | ファイルが残る、コンパイルが走る、削除忘れリスク |
| Editor Menu実行 | 手動トリガーが必要、再現性が低い |
| MCP API呼び出し | 副作用なし、1コールで完結 |
MCPは「操作の実装詳細」をサーバー側に閉じ込め、呼び出し側に副作用を漏らさない。これはソフトウェア工学における関心の分離そのものだ。
2. コンテキストウィンドウの節約
スクリプト生成・配置・実行・削除のサイクルをAIに任せると、その過程で大量のトークンを消費する。コードの生成、エラーの解析、修正の試行——これらすべてがコンテキストを圧迫する。
MCP API経由なら、AIはパラメータを渡すだけだ。実装の詳細はサーバーが持つ。コンテキスト消費量は、体感で5分の1以下になる。
比較表：バイブコーディング vs MCP
| 観点 | バイブコーディング（スクリプト生成） | MCP API経由 |
|---|---|---|
| 実装コスト | 低（その場で生成） | 高（事前にAPI設計が必要） |
| 副作用 | 大（ファイル残留・コンパイル） | なし |
| 削除忘れリスク | 高 | なし |
| コンテキスト消費 | 多 | 少 |
| 再現性 | 低（環境依存） | 高（APIが保証） |
| チーム展開 | 困難（手順が属人的） | 容易（APIを共有） |
| 「正しい手順」の保証 | なし | あり |
「動けばいい」ならバイブコーディングで十分だ。しかし「正しく動く」「副作用がない」「チームで再現できる」を求めるなら、MCPは必須になる。
Asset Storeアセットと MCPの展望
現在、Unity向けのサードパーティアセット（Asset Storeで販売されているもの）は、MCPでの操作に対応していないものがほとんどだ。
しかしこれは変わる。
アセットパブリッシャーが「MCPサーバー付きアセット」をリリースし始めれば、ユーザーはバイブコーディングのリスクなしにAI経由でアセットを操作できるようになる。例えば、次のようなAPIが想定できる。
// Cinemachine を MCP 経由で操作する例
unity.cinemachine.createVirtualCamera
unity.cinemachine.setFollowTarget
unity.cinemachine.blendCameras
// ProBuilder を MCP 経由で操作する例
unity.probuilder.createShape
unity.probuilder.extrude
unity.probuilder.applyMaterial
「AIがUnityを操作する」という未来において、MCPはプロトコルの標準として機能する。バイブコーディングで書いた一時スクリプトではなく、パブリッシャーが保証するAPIとして。
まとめ
- MCP不要論は「バイブコーディングで十分」という前提に依存している
- しかし、Unity開発の多くの操作は副作用を許容できない
- スクリプト生成による操作は「削除忘れ」「コンパイルエラー連鎖」などのリスクを内包する
- MCP APIは副作用を隠蔽し、コンテキスト消費を抑え、再現性を保証する
- 「動けばいい」ならバイブコーディング、「正しく動く」ならMCPが必要
MCP不要論は間違っていない。ただし、それが成立するのは「副作用を気にしない使い捨てプロジェクト」に限定される。本番のUnity開発でAIを活用するなら、MCPは「あると便利」ではなく「なければ事故る」レベルの基盤だ。
UniMCP4CC について
本記事で述べた「Unity を MCP 経由で操作する」を実現するツールが UniMCP4CC だ。
Claude Code から Unity Editor を直接操作できる MCP サーバーで、シーン管理・GameObject操作・Asset作成・レンダリング設定など、副作用なしに実行できるAPIを提供している。
スクリプト生成に頼ったバイブコーディングから脱却し、意図した動作・正しい手順でUnityを操作したい方にとって、UniMCP4CCはその出発点になる。
- GitHub: dsgarage/UniMCP4CC
- 対応Unity: 2021.3 LTS以降
- ライセンス: MIT