AIが​「コードを​書く」から​「制作ソフトを​操作する」へ​ ──MCPが、​ゲームエンジンと​3Dの​現場に​染み出した

気になるAIの話を、分かりやすく ｜ 最新動向を、現場目線で

去年のAIエージェントは「コードを書く道具」だった。テキストを読み、テキストを書く。得意なのは、あくまで文字の世界だ。

ところが2026年に入って、その境界が静かに溶け始めた。AIが、ゲームエンジンや3Dソフトの"編集画面そのもの"を操作し始めた。シーンにオブジェクトを置き、マテリアルを塗り、ゲームを実行して、画面を見て、おかしければ直す——これまで人間がマウスで何百回もクリックしていた作業を、AIが直接エディタに手を突っ込んでやるようになった。

その裏側にあるのが MCP（Model Context Protocol） という仕組みだ。もともとは開発ツール向けの"接続規格"だったが、いまその接続先が Unity・Blender・Godot・Unreal といった制作ソフトへ広がっている。今日はこの動きを、専門用語ゼロで見ていく。何が起きたのか、AIに何ができるのか、そして任せる前に知っておくべきことは何か。私たち電脳技巧集団（AI職人ギルド）も毎日AIエージェントで開発している側なので、その現場目線で軽く一筆添える。

01何が​起きた？​ ──"接続先"が、​開発ツールから​制作ソフトへ

MCPは、AIと外部ツールをつなぐ共通の差し込み口だ（詳しくは次章）。2025年から2026年前半にかけて、その差し込み先はデータベース・API・プロジェクト管理ツールが中心だった。要するに「開発者の道具」だ。

それが2026年、一気に制作ソフトへ染み出した。公開されているオープンソースを並べるだけでも、勢いが分かる。

• Unity（ゲームエンジン）：CoplayDev/unity-mcp（47のツール）、IvanMurzak/Unity-MCP（70以上・MITライセンス）など複数。AIが Unity エディタを直接操作する^[1]。
• Blender（3D制作）：Python（bpy）API を経由して、メッシュ作成・マテリアル・レンダリング・GLTF/FBX書き出しまでAIが動かす^[2]。
• Godot（ゲームエンジン）：IvanMurzak/Godot-MCP（39ツール・11カテゴリ・Apache-2.0）、Godot MCP Pro（163ツール）、godot-ai（2026年4月ごろ）など、独立した実装が複数^[3]。
• Unreal Engine も同時期にMCP対応。複数エンジンを1つのAI制御面にまとめる試みも出ている^[4]。

数の細かい違いはバージョンや実装で動くが、方向は完全に一致している。クリックだらけの制作ソフトが、AIから"操作できる"プラットフォームに変わりつつある。

02そも​そも​MCPって？​ ──AIツールの​「USB-C」

一度だけ、土台を押さえておく。

MCPは、Anthropicが2024年11月に公開したオープンな接続規格だ。よく「AIツールのUSB-C」と例えられる。AIアシスタント（Claude、Cursor、Gemini、ローカルモデルなど）が、外部のソフトやデータに決まった作法でつながれるようにする。

つなぐ相手が公開するのは、大きく2つ。ツール（呼び出せる操作＝「オブジェクトを作る」「ゲームを実行する」など）と、リソース（読み取れる情報＝「今のシーンの状態」「ログ」など）だ。AIはこの2つを通して、相手のソフトを"見て"、"操作する"。

なぜこれが効くのか。MCPが無い世界では、AIツールの数×つなぎたいアプリの数だけ、個別の接続を作らねばならなかった（いわゆるN×M問題）。MCPはその真ん中に共通規格を置くことで、一度MCPに対応すれば、対応済みのどのAIからでも操作できるようにした。だからこそ、Unityが対応すればClaude CodeでもCursorでもCopilotでも同じように動かせる。

この「AIに何を触らせるか」という視点は、以前の記事でも扱った。MCPは便利な拡張ではなく、AIに操作権限を渡すレイヤーでもある。

関連記事 ｜ MCPの正体をもう一段深くMCPは「便利な拡張機能」ではなく、AIに何を触らせるかの“権限レイヤー”だ →

03何が​できる​①：シーンを​組み、​アセットを​置く

では、AIは制作ソフトの中で具体的に何ができるのか。まず「作る」側から。

Unity向けの実装を例にとると、AIが操作できる範囲はかなり広い^[1]。

• シーンと階層：シーンの作成・保存、オブジェクト（GameObject）の生成・選択・複製・移動・回転・拡大縮小・削除。
• 部品・マテリアル・アセット：コンポーネントの追加、プレハブ（再利用部品）の作成、マテリアルの作成と適用、アセットやパッケージの管理。
• スクリプト：C#スクリプトの生成・編集をプロジェクト内で直接。
• テスト・ビルド：Unityのテスト実行、コンソールログの確認、プロファイリング、プロジェクトのビルドまで。

Blenderなら、同じことが3D制作の言葉で起きる。「中央に光る球を置いて、周りに金属のキューブを並べて」と伝えると、AIがBlenderのPythonスクリプトを生成・実行し、ビューポートに結果が現れる^[2]。メッシュ、マテリアル、パーティクル、ジオメトリノード、ライティング——手作業なら熟練が要る工程を、自然言語から組み立てる。

ポイントは、これがファイルの編集ではないということ。AIはエディタの"今の状態"を認識したうえで、その中で手を動かす。人間が横でずっとUnityを開いて確認していなくても、AI自身がエディタの状態を見て、次の一手を打てる。

04何が​できる​②：見て、​直す ──​「書くだけの​AI」との​違い

制作ソフト連携がただの自動化と一線を画すのは、AIが結果を"見て"、自分で直せる点にある。

Godot向けの実装を見ると、それがよく分かる^[3]。ツールは11のカテゴリに分かれ、その中に「編集する」だけでなく「観察する」ためのものが並ぶ。

• スクリーンショット：ビューポートやカメラ、特定のノードだけを画像で取得（見た目の検証に使う）。
• 実行状態の制御：ゲームを再生・停止し、その状態を取得する。
• コンソールログ／実行時エラー：走らせて出たエラーを拾う（しかも「エラーが無い」と「取得できていない」をちゃんと区別する設計）。
• 入力の注入：座標クリックではなく、ゲームのアクションを直接送って動作を試す。

これで何が変わるか。AIは、シーンを編集する → ゲームを実行する → スクリーンショットとログで結果を見る → おかしければ直す、というループを人手なしで一周できる。「コードを書いて終わり」ではなく、「作って、動かして、見て、直す」までを閉じられる。これは、AIが自分でブラウザを触ってQAし始めた流れと、まったく同じ構造の変化だ。制作の現場でも、評価軸が「作れるか」から「作って、確かめて、直せるか」へ動いている。

関連記事 ｜ 同じ「見て直す」構造の変化AIが、自分で画面を触って直す時代 ──「コードを書くAI」から「動かして確かめるAI」へ →

05任せる​前に​ ──"できる​"と​"任せていい"は​違う

ここまで読むと万能に見えるが、現場の声はもっと冷静だ。使う前に押さえておくべき注意が、はっきりしている。

• 破壊的な操作に気をつける：オブジェクトの削除や上書きは、AIが一発で大量に実行できてしまう。変更前のチェックポイント（復元点）を取り、差分をレビューする運用が要る。
• 「見るだけ」と「変えるだけ」を分ける：状態を読み取るツールと、編集するツールを分離し、AIに渡す権限に境界を引く。これはMCP全般に共通する統制の話でもある。
• 視覚推論の限界：AIは概念やエフェクトの雛形づくりは得意だが、ボーン（骨格）のリギング、パーティクルの精密な配置、複雑な構図は苦手で、何度もやり直しが要る。仕上げの品質は人の目が要る。
• 大きなプロジェクトでの遅延：巨大で複雑なシーンでは反応が重くなる。

CAGでも、AIエージェントに実務を任せるときの原則は同じだ。読み取りと書き込みの権限を分け、破壊的な操作の前にゲート（承認・復元点）を置き、最終判断は人間が持つ。制作ソフトが相手でも、この作法は変わらない。むしろ「AIがマウスの代わりに手を動かす」からこそ、境界を先に設計しておくことの重みが増す。

06まとめ ──AIが​触れる​「言語化できる​もの」が、​制作へ​広がった

MCPが制作ソフトへ広がったことの意味は、シンプルだ。これまでテキストの世界に閉じていたAIの手が、3Dシーンやゲームの現場にまで届き始めた。しかもそれは、特定の1社の囲い込みではなく、オープンな規格の上で、複数のエンジンに同時多発的に起きている。

もちろん、AIが制作者を置き換えるわけではない。センス、複雑なリギング、最終の詰め、方向づけ——人の役割はむしろ上流に寄る。だが「クリックの反復」や「雛形づくり」「動かして確かめる」の部分は、確実にAIに移りつつある。

私たちのモットーは「言語化できるものは、すべて作る」だ。その"作る"の対象が、コードや文章だけでなく、動く3Dやゲームにまで素直に伸びていく——今回の動きは、その地続きの一歩に見える。

観点	「書くだけ」のAI	制作ソフトを操作するAI（MCP連携）
触る対象	テキスト・ファイル	エディタの状態・シーン・アセット
できること	コード/スクリプト生成	シーン構築・マテリアル・ビルド・実行
結果の確認	人がソフトを開いて確認	AIがスクショ/ログ/状態で自分で観察
直し方	人が動かして手戻り	作る→動かす→見る→直すを自走
人の役割	実装の指示と確認	方向づけ・仕上げ・破壊操作の承認

※対比は「書くだけのAI」と「制作ソフト操作AI」の一般的な違いを整理したもの（CAGによる編集的まとめ）。