📑 目次を開く

ドキュメンテーション

Editor Eye の仕組みと、上手な使い方をまとめています。LLM に話しかけるだけで Unity Editor が動く、その裏側で何が起きているのかを知っておくと、ぐっと使いこなせるようになります。

🔧

設定方法

Editor Eye は Unity への組み込みお使いの LLM クライアントへの登録の 2 ステップで使えるようになります。設定は最初の 1 回だけで、あとはアップデートも自動です。

1-1

Editor Eye のインストール

まずは インストールページ から .unitypackage ファイルをダウンロードしてください。Unity プロジェクトに組み込むだけで、LLM から操作される準備が整います。

  1. ダウンロードした .unitypackage ファイルをダブルクリック(または Unity の Assets → Import Package → Custom Package… から選択)して Unity にインポートします。
  2. Unity が再コンパイルを終えると、自動でセットアップが完了します。メニューバーに Window → Editor Eye が表示されれば成功です。
  3. Window → Editor Eye → Settings を開いて、ダッシュボードで取得したライセンスキーを貼り付け、Connect ボタンを押してください。
💡 バージョンアップ時は新しい .unitypackage を同じ手順でインポートするだけです。設定はそのまま引き継がれます。
1-2

Claude Desktop の設定(初回のみ)

Claude Desktop を使っている方は、設定ファイルに Editor Eye を「使える道具」として登録します。下の JSON をそのままコピーすれば動きます。

設定ファイルの場所: %APPDATA%\Claude\claude_desktop_config.json(Windows)/ ~/Library/Application Support/Claude/claude_desktop_config.json(Mac)

{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer あなたのライセンスキー"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

{ユーザー名} はあなたの Windows ユーザー名に置き換えてください。
editor-eye-windows は Windows 専用です。Mac / Linux の場合は不要です。

💡 ライセンスキーは ダッシュボード で確認できます。editor-eye はクラウド側を HTTP で直接呼ぶ仕組みなので、ローカルに Node.js や npm パッケージのインストールは不要です。
次回以降のアップデートは設定変更不要です。editor-eye(クラウド)はサーバー側でロールアウト、editor-eye-windows-cli.exe は Unity 起動時に自動で最新版へ更新されます。
1-3

Claude Code CLI の設定(初回のみ)

ターミナルで Claude Code を使っている方は、~/.claude/settings.jsonmcpServers セクションに同じ内容を追記します。エディタを離れずに Unity を操作できるようになります。

{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer あなたのライセンスキー"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

設定後、Claude Code を再起動すると editor-eye ツール群が使えるようになります。

📝 ライセンスキーの取得方法: 無料登録 後、ダッシュボード の「ライセンスキー」欄に表示されます。
1-4

editor-eye-windows の設定 Windows 専用

🪟 このセクションは Windows ユーザー向けです。 Mac / Linux では editor-eye-windows は動作しません。1-2 / 1-3 の editor-eye-windows 設定ブロックを省略してください。

editor-eye-windowsあなたの PC 上で直接動く Windows 専用のサポート役です。Unity Editor のウィンドウをそのまま撮影したり、ウィンドウを前面に出したり、強制終了したり——クラウド経由ではどうしても届かない「目の前の Unity」への操作を担当します。

📦 CLI バイナリの自動インストール

Editor Eye の .unitypackage をインポートして Unity を起動すると、editor-eye-windows-cli.exe が自動で下記パスにコピーされます。手動操作は不要です。

C:\Users\{ユーザー名}\AppData\Local\EditorEye\editor-eye-windows-cli.exe

バージョンアップ時も Unity の起動時に自動で最新版に差し替わります。

⚙️ MCP 設定への追加方法

1-2 / 1-3 の設定ファイルに以下のブロックを追加してください({ユーザー名} を実際のユーザー名に置き換え)。

"editor-eye-windows": {
  "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
  "args": ["mcp-server"]
}

✅ 動作確認

  1. Unity Editor を起動する(editor-eye-windows-cli.exe が自動インストールされる)
  2. Claude Desktop / Claude Code を 再起動 する(MCP 設定の再読み込みのため)
  3. Claude に 「editor-eye-windows で Unity のウィンドウタイトルを取得して」 と伝える
  4. Unity ウィンドウのタイトルが返ってくれば設定成功です
以下(1-5〜1-8)は参考情報です。現時点で当社が動作を検証・保証しているのは Claude Code および Claude Desktop のみです。MCP 規格に準拠した設計のため他のクライアントも接続できる可能性がありますが、実際の動作は各クライアントの MCP 実装状況に依存します。設定を試みる場合は自己責任でお願いします。
1-5

Cursor の設定

Cursor が MCP に対応している場合、設定ファイルに Editor Eye を追記すると Cursor のチャットから Unity を操作できる可能性があります(動作は当社では未検証です)。

  1. プロジェクトルートの .cursor/mcp.json(特定プロジェクトのみで使う場合)、またはホームの ~/.cursor/mcp.json(全プロジェクト共通)を開きます。
  2. 1-2 で示した Claude Desktop と同じ内容をそのまま貼り付けます(mcpServers の中身が同じ形式です)。
  3. Cursor を再起動すると、editor-eye ツール群が使えるようになります。
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer あなたのライセンスキー"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ 具体的なファイルパスや有効化手順は Cursor 公式ドキュメント の最新情報も合わせて確認してください。

1-6

GitHub Copilot(VS Code)の設定

VS Code 1.99 以降で GitHub Copilot の MCP 機能が有効な場合、以下の設定で Editor Eye を呼び出せる可能性があります(動作は当社では未検証です)。

  1. VS Code の settings.json"github.copilot.chat.mcp.discovery.enabled": true を有効化します。
  2. プロジェクトの .vscode/mcp.json を作成し、1-2 と同じ内容を貼り付けます。
  3. VS Code を再起動すると、Copilot Chat から Editor Eye ツールが呼び出せるようになります。
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer あなたのライセンスキー"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ MCP まわりの設定キーや有効化フラグは VS Code / Copilot 側のアップデートで変わることがあります。VS Code 公式ドキュメント も合わせて確認してください。

1-7

Gemini CLI の設定

Gemini CLI が MCP に対応している場合、以下の設定で接続できる可能性があります(動作は当社では未検証です)。

  1. ~/.gemini/settings.json を開きます(無ければ新規作成)。
  2. mcpServers セクションに 1-2 と同じ内容を追記します。
  3. Gemini CLI を再起動すると editor-eye ツールが使えるようになります。
{
  "mcpServers": {
    "editor-eye": {
      "url": "https://api.editor-eye.app/mcp",
      "headers": {
        "Authorization": "Bearer あなたのライセンスキー"
      }
    },
    "editor-eye-windows": {
      "command": "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe",
      "args": ["mcp-server"]
    }
  }
}

※ ファイルパスや設定キー名は Gemini CLI のバージョンで変わることがあります。Gemini CLI 公式リポジトリ を確認してください。

1-8

OpenAI Codex の設定

OpenAI の Codex CLI が MCP に対応している場合、以下の設定で接続できる可能性があります(動作は当社では未検証です)。

  1. ~/.codex/config.toml に MCP サーバーの定義を追記します(または環境変数 CODEX_MCP_SERVERS 経由でも設定可能)。
  2. 設定内容は Claude Desktop と同じ mcpServers 構造をベースにします。
  3. Codex CLI を再起動すると Editor Eye ツールが認識されます。
# ~/.codex/config.toml の mcp_servers セクションに追記
[mcp_servers.editor-eye]
url = "https://api.editor-eye.app/mcp"
headers = { Authorization = "Bearer あなたのライセンスキー" }

[mcp_servers.editor-eye-windows]
command = "C:/Users/{ユーザー名}/AppData/Local/EditorEye/editor-eye-windows-cli.exe"
args = ["mcp-server"]
💡 どの LLM クライアントでも、設定の構造はほぼ同じです。mcpServers キーの下に editor-eye のエントリを追加するだけ。具体的なファイルパスや拡張子(JSON / TOML 等)は各ツールの公式ドキュメントを確認してください。

📐

技術資料

Editor Eye は 2 つのコンポーネントで動いています。それぞれ役割が違い、片方がもう片方を補い合うことで「どんな OS でも使える便利さ」と「Windows でしかできない深い操作」を両立しています。

2-1

MCP の 2 層構造

LLM からの指示は、まず editor-eye(クラウド経由)か editor-eye-windows(ローカル直結)のどちらかを経由して Unity に届きます。シーンの中身を読む・GameObject を編集する・スクリプトを実行する——こうした操作はクラウド側、画面を撮る・ウィンドウを前面に出すといった OS レベルの操作はローカル側、と自然に振り分けられます。

LLM(Claude Code)
  │
  ├─ editor-eye(全 OS 対応)
  │    └─ editor-eye-server(Railway クラウド)
  │         └─ Unity Bridge(WebSocket)
  │              └─ Unity Editor
  │
  └─ editor-eye-windows(Windows のみ)
       └─ editor-eye-windows-cli.exe(ローカル実行)
            └─ Unity Editor(IPC 直接制御)

🌐 editor-eye

  • 全 OS 対応(Windows / Mac / Linux)
  • ✓ クラウド経由で Unity の状態取得・操作
  • ✓ GameObject 状態取得、知識注入など主要ツール
  • ✓ ネットワーク接続が必要

🪟 editor-eye-windows

  • Windows 専用
  • ✓ ローカル IPC で Unity Editor を直接制御
  • ✓ スクリーンショット・画面操作・階層取得
  • ✓ ネットワーク不要(オフラインも可)
💡 両方を入れておくのがおすすめです。LLM は「シーンを読む」「コードを実行する」といった操作には editor-eye を、「画面を見たい」「ウィンドウを前に出して」といった操作には editor-eye-windows を自動で使い分けます。
2-2

接続を維持するための方法論

Editor Eye は LLM と Unity の橋渡しをずっと維持し続けます。ネットワークが一瞬切れても、Unity を再起動しても、ユーザーは特に何もしなくて大丈夫です。気をつけるのは、たった 3 つだけ。

🎮

Unity Editor を起動した状態で使う

LLM に指示を出す前に、Unity Editor を立ち上げておいてください。Unity が起きていなければ操作の届け先がなく、LLM の指示は宙に浮きます。

🔄

接続が切れたら「再接続して」と伝えるだけ

回線の不調などで切れた場合は、LLM に 「Unity に再接続して」 と言うだけで自動で接続を取り戻します。

🔃

Unity 再起動後も自動で回復

Unity Editor を一度閉じて開き直しても、Editor Eye が自動で接続をやり直します。多くの場合、数秒で元通りに戻ります。


📸

キャプチャー画面の送り方

LLM に Unity の画面を「見せる」と、見た目を確かめながら作業できるようになります。Editor Eye には 2 種類の撮影方法があり、それぞれ得意なシーンが違います。

方法 1

editor-eye の screenshot ツール — 全 OS 対応

gateway_core_screenshot を使うと、Unity の Game View または Scene View(ゲームの見た目そのもの)を撮って LLM に渡せます。Mac / Linux でも動くので、まずはこちらを試すのがおすすめです。

# Claude への指示例
「Game View のスクリーンショットを撮って確認して」

✓ 向いている場面

  • Game View の見た目を確認したいとき
  • Mac / Linux でも使いたいとき
  • ネットワーク経由で使いたいとき

⚠ 制限

  • Unity Editor 全体は撮れない(Game View のみ)
  • Play Mode でない場合は黒画面になることがある
💡 gateway_scene_capture_with_camera なら、カメラの位置や画角を細かく指定して撮れます。「敵の真上から見下ろした構図」「キャラの目線で前方を見た構図」といった、特定のアングルから確認したいときに重宝します。
方法 2

editor-eye-windows の capture_window ツール Windows 専用

capture_windowUnity Editor のウィンドウをそっくりそのまま撮影します。Game View だけでなく Inspector・Hierarchy・Console まで丸ごと映るので、「画面のここの値を見てほしい」「このエラー表示を読んで」といった依頼に最適です。

# Claude への指示例
「Unity の画面全体をキャプチャして現在の状態を確認して」

✓ 向いている場面

  • Inspector の設定値を視覚的に確認したいとき
  • エラー表示や Console を LLM に見せたいとき
  • 編集モード(Play Mode 外)の状態を確認するとき
  • UI レイアウト全体を確認したいとき

⚠ 制限

  • Windows 専用(Mac / Linux 不可)
  • editor-eye-windows の設定が必要(1-4 参照)

2 種類の比較

項目 方法 1
screenshot(全 OS)
方法 2
capture_window(Windows)
対応 OS 全 OS Windows のみ
撮影範囲 Game View / Scene View Editor 全体
Play Mode 外での撮影 △(黒くなる場合あり)
Inspector / Console の確認
カメラアングル指定 ✓(capture_with_camera)

Domain Reload・Compile ポーリング

Unity でスクリプトを保存すると、その直後に「コンパイル → Domain Reload」が走ります。この数秒間は Unity の中身が一度リセットされるため、Editor Eye と Unity の接続も瞬間的に切れます。Editor Eye はこの状態を自動で見守って、コンパイル完了と同時に再接続する仕組みを持っています。ユーザー側で何かする必要は基本的にありません。

4-1

Domain Reload とは何か

Unity で .cs ファイルを保存すると、Unity が自動で コードを再ビルドします。そのあとに走るのが Domain Reload で、ざっくり言うと 「Unity が一瞬眠って、新しいコードで目覚め直す」 動作です。

  • あなたが書いた変更が、Editor 上で動くために必要な仕込みです
  • この間、Unity の C# 環境(変数の状態など)はすべてリセットされます
  • 完了すると、新しいコードが反映された Unity が戻ってきます
⏳ プロジェクト規模にもよりますが、小〜中規模で数秒、大規模だと 10〜30 秒かかることもあります。
4-2

Editor Eye はどう対応しているか

Domain Reload の間、Editor Eye と Unity をつないでいる WebSocket は一度切断されます。ですが、Editor Eye は勝手に切れて、勝手に戻るように作られています。

  • 切断を検知したら、内部で 2〜3 秒間隔で接続を試し続けます
  • Unity が目覚めた瞬間に WebSocket がつながり直します
  • ユーザーが「再接続して」とお願いする必要もありません(自動回復)
✅ つまり、スクリプトを編集 → 保存 → 数秒待つ、これだけで Editor Eye はまた使えるようになります。
4-3

コンパイル完了をどう知るか

LLM がスクリプトを作ったり書き換えたりした直後に次の操作へ進むと、まだ Unity が目覚めていない(コンパイル中)の状態に当たってしまいます。これを避けるため、LLM は 「少し待ってログを確認する」 パターンを使います。

  • gateway_core_get_logs でコンパイルエラーが出ていないか確認
  • ログに [EditorEye] Bridge connected が出ていれば、再接続も終わっている合図
  • 不安な場合は gateway_core_sleep(3000)get_logs の順で「待ってから見る」のが定番
4-4

推奨される待機パターン

スクリプトを作成したり書き換えたりしたあとに使う、定番の 3 ステップです。LLM はこの流れを自然に踏むので、あなたが「ちょっと待ってからエラー見て」と細かく指示する必要はありません。

# スクリプト作成 → コンパイル完了待ち → 確認
1. manage_script(action: create, ...) # スクリプトを作成
2. gateway_core_sleep(ms: 3000) # Domain Reload を待つ
3. gateway_core_get_logs(logType: Error) # エラーが出ていないか確認
💡 3 秒は目安です。小さな変更ならもっと短くて済みますし、プロジェクトの規模次第ではもう少し長く取ったほうが安心な場合もあります。
4-5

Domain Reload が長引く場合

大規模なプロジェクトや、たくさんのアセンブリを抱えたプロジェクトでは、Domain Reload に 10〜30 秒かかることがあります。そんなときは次のような対処をしてください。

  • 待ち時間を長めに取る(gateway_core_sleep(ms: 5000)10000
  • get_logs を何度か呼び直して、完了の合図が出ているか確認する
  • コンパイルが終わるまで待ってから確認して」と LLM に伝えれば、自動でリトライしてくれます
⚠ 何度待っても Bridge connected が出ない場合、コンパイルエラーで Unity が止まっている可能性があります。get_logs(logType: Error) でエラー内容を確認してください。

🎮

上手なゲーム制作のコツ

Editor Eye を使い込んでいくと、「LLM とどう組むと速いか」が見えてきます。ここで紹介するコツは、どれも実際の制作で効いてくる小さな工夫です。一番大事なのは——LLM には「手順」ではなく「どうなってほしいか」を伝えること。

5-1

「手順」ではなく「最終状態」を伝える

LLM に細かい手順を指示するより、「こうなってほしい」というゴールを伝えるほうが、結果的に速く・正確に仕上がります。途中のやり方は LLM に任せましょう。

❌ 手順ベース(非効率)

「まず GameObject を作って、次に Rigidbody を追加して、質量を 2 にして、重力を無効にして…」

✓ 状態ベース(効率的)

「Enemy オブジェクトに Rigidbody を追加して、質量 2・重力なしで設定して」

💡 LLM は batch_execute を使って、複数の操作を 1 回でまとめて実行できます。「〜して〜して〜して」と続けて伝えれば、自動でまとめて処理してくれます。
5-2

Action(実行)→ Verify(検証)→ Adjust(修正)を意識する

Editor Eye がいちばん力を発揮するのは、Action(実行)→ Verify(検証)→ Adjust(修正) のサイクルを高速で回しているときです。指示のあとに「確認して」と一言添えるだけで、LLM は自分でスクリーンショットを撮ったり、ログを読んだりして結果をチェックします。

# AVA の典型的な流れ
1. 指示: 「Main Camera に Bloom エフェクトを追加して」
2. LLM が操作を実行
3. LLM が自動でスクリーンショットを撮って確認
4. 必要なら「もう少し強く」と調整指示

AVA を加速させるポイント:

  • 📸 こまめに撮らせる — 「いまの状態を見せて」と言うだけで LLM が画面を撮って確認します
  • 📋 ログを読ませる — 「エラーが出てないか確認して」でエラーログを自動チェックします
  • 🔍 選択状態を使う — Unity で GameObject を選んだあとに「選択中のオブジェクトの状態を確認して」と頼むと、詳細情報が返ってきます
5-3

量産は batch_execute に任せる

「50 体の敵に NavMeshAgent を仕込む」「全ステージのライティングを揃える」——こういう繰り返し作業は、batch_execute でまとめて片付きます。手作業なら数時間かかるものが、数秒で終わります。

# 指示例
「Hierarchy の Enemy_* という名前の GameObject 全部に
NavMeshAgent を追加して、speed を 3.5 にして」
✅ batch_execute は Unity の Undo に対応しています。失敗した場合は「元に戻して」と伝えると、一括でロールバックできます。
5-4

小さく試してから大きく展開する

いきなり全部に適用するより、まず 1 つで試してから量産するのが安全です。LLM もこの流れを自然に取りますし、途中で「やっぱり違うな」と気づいたときの戻し作業が最小限で済みます。

Step 1

テスト用の GameObject 1 個に操作を適用 → スクリーンショットで確認

Step 2

意図通りなら「残り全部にも同じ設定を適用して」と指示

Step 3

batch_execute で一括適用 → ログでエラー確認

5-5

詰まったら「調べてから実装」を頼む

Editor Eye には Unity 固有のノウハウ(よくあるバグ・回避策・API の癖)を集めた Knowledge DB が組み込まれています。LLM が手詰まりになったときや、エラーが解決しないときに、自動で参照してくれます。

# 効果的な頼み方
「NavMesh が正しくベイクされない。エラーログを確認してから、
知識DBでこのエラーパターンを調べて対処して」
💡 execute_dynamic_script は万能ツールです。専用ツールが用意されていない操作(独自コンポーネントの読み取り、Reflection で内部状態を覗くなど)も、C# コードを直接走らせて解決できます。「〜を C# で実行して」と頼めば、LLM が適切なコードを書いて動かします。
🛠️

トラブルシュート

セットアップで詰まりやすいポイントと対処法をまとめています。同じ症状が出たら、まずこのページを確認してください。

T-1

「401 Unauthorized」または「invalid license」エラーが出る

症状

LLM クライアントから editor-eye のツールを呼ぼうとすると、MCP ログに次のようなレスポンスが返ってくる:

HTTP 401 Unauthorized
{ "error": "invalid_license" }

[editor-eye] tool call failed

原因

MCP 設定の Authorization: Bearer ... に渡しているライセンスキーが、次のいずれかに該当します:

  • キーをコピー漏れ・余分な空白・改行が混入している
  • ライセンスが解約済み / 期限切れ
  • キー文字列を "Bearer " プレフィックスごとコピーしてしまっている(プレフィックスは Authorization 側に書く)

対処

  1. ダッシュボード を開いて、現在のライセンスキーをそのまま再コピー(クリックでクリップボード反映)
  2. MCP 設定ファイル(claude_desktop_config.json / ~/.claude/mcp.json など)の Authorization 行を以下の形式で書き直す:
    "headers": {
      "Authorization": "Bearer 9b2c-…-fa4d"
    }
  3. LLM クライアントを完全終了 → 再起動して MCP 設定を再読込
  4. ツール呼び出しが success で返れば成功

補足

  • ライセンスキー文字列は UUID v4 形式(例: 9b2cabc1-3e7f-4d2a-9c10-fa4d…)です。プレフィックスは付きません。
  • 解約済み・期限切れの場合は /upgrade から再開できます。
  • editor-eye-windows 側はライセンスキー不要(ローカル CLI のため)です。401 が出るのは必ず editor-eye(クラウド)側です。
T-2

「Unity bridge not connected」と返ってくる

症状

LLM が editor-eye のツールを呼んだとき、認証は通っているが 「Unity bridge not connected」「No active Unity session」 といったエラーが返る。

原因

サーバー (api.editor-eye.app) は LLM の指示を受け取れているものの、あなたの Unity Editor との WebSocket セッションが張られていない 状態です。Editor が起動していない、もしくは Settings の Connect が押されていません。

対処

  1. Unity Editor を起動する
  2. Window → Editor Eye → Settings を開く
  3. ライセンスキーが空ならダッシュボードのキーを貼り付け、SaveConnect をクリック
  4. ウィンドウ下部のステータスが Connected になれば成功
  5. LLM 側でもう一度ツールを呼び出す

補足

  • ネットワーク切断やスリープ後は自動再接続が走ります。LLM に「Unity に再接続して」と依頼すれば即時復旧できます。
  • 同じライセンスキーで複数の Unity Editor を同時起動すると、後から起動した Editor が前の Editor を切断します(既知の仕様)。
  • サーバー側障害の有無は リリースノート の最新エントリで告知します。