目次
結論
編集部では2026年6月、Unity Editorをターミナル常駐のAIコパイロットで駆動し、スクリプト編集からコンパイル、テスト実行までを自律ループで回す社内PoCを企画した。差別化の核として想定していたのは「ドメインリロード(スクリプト再コンパイル時に発生するUnity Editorの状態リセット)を越えてMCP接続を維持し、作業を再開できること」である。しかし実装に着手する前に半日かけて技術調査を行ったところ、この機能はすでに複数の無料OSS(MITまたはApache-2.0ライセンス)のMCPサーバーで実現済みであることが判明した。自社の開発効率化が目的であれば、その日のうちに既存ツールを導入すれば達成できる。汎用の「Unityコパイロット製品」として売る目的であれば、無料OSS群とUnity公式のAI機能によって市場の枠はすでにほぼ埋まっている。この記事は、その判断に至った調査記録である。
調査の前提
- 調査時期は2026年6月。対象はUnity 2022.3以降を想定した、Model Context Protocol(MCP)経由でUnity Editorを操作するコパイロット構成。
- 比較対象として想定していた競合は、接続不安定が最大の不満点として報告されているサードパーティ製コパイロット、および2026年5月にオープンベータで公開されたUnity公式のAI機能である。
- 調査の目的は2つに分けて評価した。(1) 編集部自身のUnity開発を効率化する、(2) 汎用のUnityコパイロット製品として外部に販売する。この2目的は判断基準が異なるため、結論も分けて出す必要があった。
- 本稿はいずれのOSSプロジェクトとも資本関係・提携関係になく、編集部が独自に公開リポジトリの情報(ライセンス表記、機能一覧、Issue)を調査した結果に基づく。ライセンス種別は各リポジトリの公開情報を根拠とする。
既存OSSの比較
調査時点で確認できた、UnityをMCP経由で自律駆動する主なOSSは以下の通りである。
| プロジェクト | 特徴 | ライセンス |
|---|---|---|
| hatayama/uLoopMCP(現リポジトリ名: unity-cli-loop) | CLIファーストで編集部の構想にほぼ一致。コンパイル・ログ取得・テスト実行・スクリーンショット・PlayMode制御など16ツールを提供し、ドメインリロードを明示的にまたぐオプションを持つ | MIT |
| FunplayAI/funplay-unity-mcp | メモリ上でのRoslynコンパイルにより.csファイルを書き換えずに検証できる方式。この方式自体がドメインリロードを発生させにくい |
MIT |
| hackerzhuli/unity_code_mcp | Rust実装。ドメインリロードへの対応を明記 | MIT |
| IvanMurzak/Unity-MCP | コンパイル・テスト・PlayMode・スクリーンショット等を広く網羅する70以上のツールを提供 | Apache-2.0 |
| CoplayDev/unity-mcp | 上記の中でスター数は最多クラス(13,000超)。再接続関連のIssueが継続的に報告されている(例: #1265「HTTP bridge session drops after domain-reload churn」、#1207「bridge WebSocket repeatedly drops on reload/test boundaries」、#1164「orphaned python server after domain reload」。いずれも2026-08-14時点でopen) | MIT |
これに加え、Unity自身が2026年5月に公式の「Unity AI」とMCPサーバーをオープンベータで公開しており、BYOモデル(自前のAPIキーで外部LLMを使う方式)に対応したAIゲートウェイも提供している。編集部が「作ろうとしていた箱」が、プラットフォーム側から出荷された状態である。
これらの事実が示すのは、「Claude CodeなどのAI CLIとUnity MCPサーバーを組み合わせて自律ループを回す」という組み立て自体は、2026年半ばの時点ですでにコモディティ化しているということである。チュートリアルや解説記事も多数存在し、新規性のあるハックではなく既知の構成になっている。
build vs buy の判断基準
調査結果を、当初分けていた2つの目的に当てはめると判断が分かれる。
目的1: 自社の開発効率化。 既存OSS(uLoopMCPまたはIvanMurzak/Unity-MCP)とAI CLIを導入するだけで、その日のうちに実現できる。自社開発のスキャフォールド(ハーネス層の設計)には価値があるが、ゼロから再実装する理由は薄い。
目的2: 汎用Unityコパイロット製品としての販売。 無料OSS群とUnity公式機能によって、薄い「DIYラッパー」型の製品が入る枠はほぼ埋まっている。製品化するなら、汎用機能ではなく「実際に使い込んで見つけた具体的な穴」に絞った縦特化でなければ勝ち筋が立たない。
この2つの目的を最初に分けて評価しなかった場合、「効率化のためのツール導入」と「製品としての新規開発」を混同したまま着手判断をしてしまうリスクがある。build vs buyの判断は、目的別に立てるべきという点が、この調査で得られた実務上の教訓である。
この結論が覆る条件
この結論は「作らない」で固定したものではなく、条件付きの判断である。
- ドメインリロードを越えた再接続が、既存OSSでは実運用に耐えない(切断されたまま復帰しない)ことが実際の使用で確認された場合、そこが唯一残る具体的な弱点(wedge)になりうる。ただしこの弱点についても複数の無料ツールがすでに対処を主張しており、自己申告の域を出ないとはいえ、空白は年々狭まっている。
- プロンプト設計やループの組み方それ自体は、他社が容易に模倣できるため守りにくい。差別化の根拠にするなら、模倣されにくい要素(継続的な実運用データ、特定領域への深い統合)に置く必要がある。
- 判断の前提となる各OSSの機能・ライセンス・活発度は2026年6月時点の観測であり、変化が速い領域のため、実際に採用を検討する際は該当リポジトリの最新状態を確認することを推奨する。
まとめ
「作る前に、まず使う」という順序を踏んだことで、着手していれば数週間かかっていた可能性のある自社開発を避けられた。汎用製品としての新規開発は見送り、既存OSSを実際に使い込む中で具体的な穴が見つかった場合にのみ、縦特化の開発を検討する方針とした。この整理は、社内でAIエージェント関連の技術投資判断を行う際の一般的な手順としても有効だと考えている。他社の技術選定の材料として、ご相談があれば株式会社ALLFORCES(https://ai-media.co.jp)までお問い合わせいただきたい。