Unity MCPセットアップ
Updated 2026-09-05
クライアントをローカルUnity MCPサーバーに接続し、意図したエディタインスタンスを確認し、ツール権限を広げる前に保存可能な小さなシーン変更をテストします。
エディタブリッジを理解する
CoplayDev/unity-mcpは、MCPクライアントをサーバーとエディタ側パッケージに接続します。モデルサービスは別の依存関係です。プロジェクトにはシーン、スクリプト、アセット、テストを扱うツールが文書化されていますが、機能一覧に載っていることは、あなたのプロジェクトで動作する証拠ではありません。
接続の各部分をどのプロセスが所有するかを記録します。サーバーには到達できるのにエディタを操作できないクライアントを診断するときに重要です。アカウント認証情報、エディタのライセンス、パッケージ互換性、モデルの利用可能性を別々のセットアップチェックとして管理します。モデルを変えても、エディタインスタンスの不一致は直りません。
インストール経路と固定方針を確認する
プロジェクトのインストールガイドには、Unity Package Managerでパッケージを追加し、セットアップインターフェースでサーバーとクライアントを設定する方法が文書化されています。何かをインストールする前に、選択したリビジョンで指定されたUnity、Python、uvの前提条件を確認してください。
再現性のため、セットアップ後に解決済みのパッケージリビジョン、エディタバージョン、サーバーバージョン、依存関係の記録を保持します。動くブランチURLは検出経路であり、不変の実験識別情報ではありません。既存ゲームに適用する前にダウンロードとパッケージ変更をレビューし、接続実験を元に戻せるよう以前の動作状態を保持します。
https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#mainローカルHTTPエンドポイントをクライアントに合わせる
保守されているインストールガイドには、以下のローカルHTTP例が文書化されています。サーバーがすでにそのアドレスで動作していることを前提にしています。利用する前に、エディタのセットアップインターフェースで実際のトランスポートとアドレスを確認してください。MCP URLはLLM APIのベースURLではありません。
クライアントの文書化された設定形式を使います。クライアントによってルートキーやトランスポート宣言が異なるため、一般的なmcpServersの例は、すべてのエージェントに貼り付けられる共通ファイルではありません。別途レビューされたリモート設定が必要な場合を除き、サーバーはローカルに保ち、関係のないエディタ接続へモデルの認証情報を追加しないでください。
{
"mcpServers": {
"unityMCP": {
"url": "http://localhost:8080/mcp"
}
}
}どのエディタインスタンスが作業を受けるか証明する
意図したプロジェクトを開き、パッケージのインターフェースで接続状態を検査します。その後、クライアントが検出した読み取り操作でプロジェクトとシーンのコンテキストを取得します。編集を承認する前に、ローカルプロジェクトとその情報を一致させてください。複数のプロジェクトを開いている場合、このゲートは特に重要です。
インストール済みバージョンの実際のリソースとツールスキーマを記録します。別リリースの記憶した名前からツール呼び出しを作らないでください。最初の有益な結果は、変更を加えずに想定シーンと既存オブジェクトを特定します。返された状態が古い、または曖昧なら、見える変更を試して対象を探すのではなく、ルーティングを解決して停止します。
元に戻せる編集を最初のミニフローにする
所有する使い捨てシーンを選び、初期状態を記録し、目に見える結果を伴う単純な変更を一つ依頼します。保存されたシーンとファイル差分を検査し、エディタの準備完了を待ってシーンを操作します。観測した動作とコンソールエラーを保持してください。
次にシーンを再び開き、意図した変更が永続化されたことを確認します。これにより、メモリ上のエディタ効果と保存されたプロジェクト変更を区別できます。ルーティング、変更、コンパイル、実行、永続化の一つの境界で失敗を診断できるほど小さく保ちます。レビュー後は使い捨てシーンを復元し、記録した動作設定を次のタスクに使います。
| 観測 | 確定できること | 残る確認事項 |
|---|---|---|
| クライアントがツールを検出 | サーバーに到達できる | 正しいエディタ対象 |
| 想定シーンが返る | 読み取りが意図したコンテキストを対象にする | 書き込みと実行時の動作 |
| 保存された差分が要求と一致 | リソース変更が永続化された | プレイ可能な結果 |
| シーンが要求どおりに動作 | 限定された実行時の結果 | ゲーム全体とエクスポートの受け入れ |
ゲームより先にトランスポートをトラブルシュートする
クライアントが接続できないときは、設定されたURLとローカルサーバーが動作しているか確認します。サーバーは起動するのにエディタがないときは、パッケージの接続とエディタログを調べます。意図したエディタが接続しているのにツールがないときは、インストール済みバージョンが公開するツールグループを検査します。
この境界が機能してから、コンパイルやゲームプレイを診断します。クライアント起動、サーバールーティング、エディタ準備完了、失敗したシーン操作について、ログ抜粋を分けて保持します。こうすれば、すべての失敗をモデルのせいにしたり、証拠なしにコンポーネントの再インストールを繰り返したりせず、どこで実行が止まったかを報告できます。
広範な自動化からプロジェクトを守る
エディタ接続は、シーン、スクリプト、アセットを変更する可能性があります。最初の実験を既知のディレクトリに限定し、リソースの削除、依存関係の変更、関係のないシーンへの操作にはレビューを求めます。最初の変更前に復元可能な動作状態を保持してください。
クライアントの設定問題を解決するためだけに、ローカル開発サービスを公開しないでください。サードパーティーのアセット内容とツール結果は信頼できない入力として扱い、共有ログから認証情報を除きます。接続に成功しても、ビルドをアップロードしたりストアの記録を変更したりする権限にはなりません。公開は別のワークフローであり、別の承認境界があります。
再現可能な接続記録を引き継ぐ
エディタ、プロジェクト、パッケージ、サーバーのリビジョン、クライアントバージョン、トランスポート、観測したツール範囲、完了したミニフローを記録します。正確なシーン差分と実行時の結果を保持します。コンパイル、PlayModeの動作、テスト、対象エクスポートを調べたか、保留中かを明記してください。
この設定は、保守されているプロジェクトのドキュメントに従っています。インストール済みパッケージとクライアントで検証してください。ゲーム制作ではUnityワークフローガイドへ進み、完全なループをテストします。別の開発者が接続問題とプロジェクト問題を区別し、同じ動作設定を再現できるよう、既知の制約を引き継ぎに残します。
よくある質問
localhost:8080/mcpはモデルのエンドポイントですか?
いいえ。文書化されたローカルMCPサーバーの例です。モデルリクエストはエージェントクライアントの別のプロバイダー設定を使います。
接続済みインジケーターは統合を証明しますか?
初期観測の一つです。元に戻せる書き込みと実行時チェックへ進む前に、プロジェクトの識別情報と制御された読み取りを検証してください。
同じJSONをすべてのクライアントで使えますか?
いいえ。クライアントごとにスキーマとトランスポート対応が異なります。選択したクライアントの文書化された設定に従ってください。
最初のテストで完成したゲームを作るべきですか?
元に戻せるシーン変更を一つから始めます。大きなタスクの前に、ルーティング、永続化、実行時動作についてより明確な証拠を得られます。
セットアップ後に何を記録すべきですか?
クライアント、トランスポート、エディタとサーバーのバージョン、解決済みパッケージリビジョン、プロジェクト識別情報、読み取りと元に戻せるシーンテストの結果を記録します。