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

参考リンク