0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Renburu

AIに人間用GUIを操作させるな！～正しいMCP活用法について～

0
Posted at

あなたのMCP活用、間違ってませんか。

かなり乱暴なことを言う。

GUIは、たいてい非本質である。

GUIは、人間がソフトウェアを使うための操作盤だ。

どこに何の機能があるかをメニューで示し、ボタンを押させ、数値を入力させ、結果を画面に表示する。

コードを書けない人間でも、高度なソフトウェアを扱えるようにするための仕組みである。これは間違いなく素晴らしい発明だ。

だが、AIまで人間と同じ操作盤を使う必要があるのだろうか。

最近、Unity MCP、Blender MCP、Figma MCP、Excel MCP、ブラウザ操作MCPなどが次々に登場している。

自然言語で指示すると、AIがソフトを操作する。

オブジェクトが増える。表が埋まる。グラフが作られる。ゲームが実行される。

見た目には未来的だ。

しかし、その裏でAIが、

  1. 使用するツールを選ぶ
  2. 一つだけ操作する
  3. 結果を読み返す
  4. 次の一手を考える
  5. スクリーンショットを撮る
  6. 失敗したので別の操作を試す

という処理を延々と繰り返していたら、それは本当に賢い自動化なのだろうか。

コードを一度実行すれば終わる仕事に、世界で最も高価なリモコンを使っていないか。

この記事はMCP不要論ではない。

既存プロジェクトを人間と共同編集する。専門ソフトが持つ高度な機能を使う。既存の素材やプラグインを活用する。

そういう用途ではMCPは強い。

だが、私は次の発想にはかなり疑問を感じている。

MCPがある。
だから、そのソフトをAIに操作させよう。

順番が逆ではないか。

最初に考えるべきなのは、

そのソフトを経由する必要が、本当にあるのか。

である。

ExcelにMCPがあったら、使いますか？

AIに、CSVから売上グラフを作らせるとする。

Excelを使うなら、だいたい次の手順になる。

Excelを開く
↓
データを貼り付ける
↓
範囲を選択する
↓
グラフを挿入する
↓
種類を選ぶ
↓
タイトルと軸を設定する
↓
見た目を調整する
↓
保存する

人間が作業するなら、これでよい。

Excelは多くの人が使い慣れている。結果を見ながら直せるし、後から数字や書式も変えられる。

だが、AIにやらせるならどうだろう。

私は普通にPythonを書かせる。

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv("sales.csv")

ax = df.plot(
    x="month",
    y="revenue",
    marker="o",
    title="Monthly Revenue",
)

ax.set_xlabel("Month")
ax.set_ylabel("Revenue")

plt.tight_layout()
plt.savefig("monthly_revenue.png", dpi=200)

これなら、

  • 何をしたかコードとして残る
  • 同じデータから何度でも作り直せる
  • 100種類のグラフもループで生成できる
  • Gitで変更点を確認できる
  • Excelのウィンドウ状態に左右されない
  • AIがセルやメニューを一つずつ選ばなくてよい

という利点がある。

ところで、Excel MCPは本当に存在する。

開いているExcelを読み書きするもの、Microsoft Excelをインストールせずに.xlsxを操作するもの、数式や書式を保ったまま既存ブックを編集するものなど、複数の実装が公開されている。

では、Excel MCPは無駄なのか。

そんなことはない。

欲しいものが、

  • 人間が後から編集するExcel帳票
  • 既存ブックの数式や書式を保った修正
  • VBAやピボットテーブルを含むファイル
  • 納品形式としての.xlsx

なら、Excelを使う理由がある。

だが、欲しいものがグラフ画像一枚ならどうか。

ExcelのGUIは途中に挟まる余計な層である。

本当に欲しいもの 向いている方法
人間が編集するExcel帳票 Excel、Excel MCP
既存ブックの数式・書式を保った修正 Excel、Excel MCP
CSVからグラフ画像を作る Python、Matplotlib
100ファイルを同じ規則で処理する Python、CLI
定型集計を何度も実行する Python、SQL、スクリプト
Excelの操作手順自体を再現する Excel MCP

成果物としてExcelが必要なのか。単に計算結果が欲しいのか。

この区別をせず、「Excel MCPがあるから使う」と始めれば、AIに不要な遠回りをさせることになる。

同じことが、ゲームエンジンでも起きている。

MCPのアドと非アドを整理する

MCPには明確な利点がある。

同時に、何も考えずに使えば明確な不利益もある。

論点 MCPのアド MCPの非アド
使い慣れたUI 人間が普段使うソフトと同じ環境でAIの結果を確認・修正できる AIまで人間向けの操作手順に付き合わされる
人間との連携 人間とAIが同じファイル、シーン、ブックを編集できる GUI内の状態とコードの状態がずれやすい
既存資産 素材、プラグイン、テンプレート、過去プロジェクトを活用できる 使わない機能や古い設定まで引き継ぐ
専門ソフトの技術 高性能なレンダラー、変換機能、ビルド機能などを利用できる 専門ソフト固有の複雑さや不具合も引き受ける
標準化 複数のAIクライアントから同じ方法で接続できる MCPサーバーごとにツール名、粒度、品質が大きく違う
操作の分かりやすさ 「ビルドする」「書き出す」など、まとまった命令には向く 細かい操作を繰り返すとツール呼び出しが急増する
トークン効率 必要な情報だけ返す設計なら効率化できる 大量のツール説明や長い実行結果がコンテキストを圧迫する
デバッグ ログやシーン情報を整理して返せるなら便利 問題がコード、GUI設定、素材、実行中状態のどこにあるか分かりにくい
再現性 同じ高水準命令を安定して再実行できれば強い GUI内部の状態に依存すると、同じ操作でも結果が変わる
大量処理 サーバー側でバッチ処理するなら有効 AIが一件ずつ判断すると遅く、高く、失敗しやすい
独自機能 既存ソフトの拡張APIを利用できる エンジンの前提から外れる機能は実装しにくい
軽量化 既存の最適化された機能をそのまま使える 不要な機能を削りにくく、成果物や開発環境が重くなりやすい
処理負担 専門ソフトに重い計算を任せられる 起動、再読み込み、再コンパイル、画面取得などの固定費がある
安全性 読み取り専用なら比較的安全に利用できる 書き込み、削除、任意コード実行では事故範囲が大きい
依存関係 既存の業務環境へ導入しやすい ソフト、プラグイン、MCPサーバーの更新に振り回される

要するに、MCPが強いのは、

そのソフトを使う明確な理由があり、AIにまとまった処理をさせる場合

である。

逆に弱いのは、

AIが人間の操作を一手ずつ考え、そのたびに状態を読み直す場合

だ。

MCPは接続方法であって、作戦ではない

MCPは、AIと外部ソフトを共通の形式でつなぐための仕組みだ。

MCPを導入しても、次のことは自動的には決まらない。

  • 何をAIに任せるか
  • 何を普通のコードへ任せるか
  • どの程度まとめて実行するか
  • いつ人間が確認するか
  • 失敗したときどう戻すか
  • 本当に費用が下がったか

MCPをつないだだけで自動化が完成したと思うな。

それはLANケーブルを挿しただけで、業務改善が完了したと思うようなものだ。

MCPの使い方は、乱暴に二つへ分けられる。

使い方 例 評価
ソフトの中の情報を直接取り、まとまった処理を実行する 状態取得、テスト、ビルド、レンダリング、変換 強い
人間の操作を一手ずつ再現する 追加、選択、移動、再生、画像確認を繰り返す 怪しい

GitHubからIssueを直接取る。

Figmaから色や余白を直接取る。

Blenderへ「このスクリプトを実行して書き出せ」と頼む。

ゲームエンジンへ「テストを実行して、失敗だけ返せ」と頼む。

こうした使い方はよい。

一方で、

オブジェクトを置く
↓
少し動かす
↓
設定を変える
↓
再生する
↓
画像を見る
↓
また少し動かす

をAIに延々と判断させるのは、本当に必要なのか。

ゲームがGUIだからといって、開発までGUIである必要はない

ゲームには画面がある。

キャラクターが動き、敵が攻撃し、UIが表示される。見た目や操作感は重要だ。

だが、

ゲームがGUIを持つこと

と、

ゲームを作るAIがGUIを主な操作方法にすること

は別の話である。

敵を10体出したいなら、AIにゲームエンジン上で10回複製させる必要はない。

foreach (var point in spawnPoints)
{
    SpawnEnemy(point);
}

と書かせればよい。

3Dシーンに100本の柱が必要なら、「柱を追加」を100回実行させる必要はない。

for spec in pillar_specs:
    create_pillar(spec)

でよい。

RPG用の敵データが必要なら、名前、HP、攻撃力をGUIへ一項目ずつ入力させるより、検査済みのデータをまとめて生成したほうが早いかもしれない。

GUIは、人間にとって便利な入口だ。

AIにとって最短の入口とは限らない。

ゲームを作る前から、ツール説明に何万トークンも使っていないか

MCPでは、AIが使えるツールの名前、説明、引数をモデルへ伝える必要がある。

ツールが増えれば、その説明だけでコンテキストを消費する。

Anthropicが公開した例では、58個のツール定義などによって、利用者の依頼を読む前から5万トークン以上を使う場合があると説明されている。現在は、必要なツールだけを後から読み込む仕組みなどによって、この問題を減らそうとしている。

問題は、料金だけではない。

ツールが増えるほど、

  • どの機能を使うか迷う
  • 似た機能を選び間違える
  • 引数を間違える
  • 古い機能と新しい機能を混同する
  • 本来のコードを読む余裕が減る

可能性も高くなる。

Redditには、MCPサーバーを増やした結果、質問を入力する前から約6万7000トークンを消費していたという報告もある。もちろん個人環境の測定であり、MCP全体へそのまま一般化はできない。それでも、無制限にMCPを追加することが無料ではないのは確かだ。

使えるツールを増やすことと、AIが賢くなることは同じではない。

Playwright MCPですら「CLIのほうがトークン効率がよい」と言っている

ブラウザ操作用のPlaywright MCPは、比較的よくできた例だ。

画面を単なる画像として見るだけでなく、ボタン、入力欄、文章などをAIが読み取りやすい形で取得できる。

その公式READMEには、はっきりこう書かれている。

“CLI invocations are more token-efficient.”

大きなツール説明や長い画面情報を毎回モデルへ渡さずに済むため、高い処理量が必要なコーディングエージェントではCLIのほうが向く場合があるという。

ブラウザ操作MCPの代表格ですら、

仕事によってはMCPよりCLIのほうがよい

と認めている。

当たり前なのだ。

同じ操作を何十回も繰り返すなら、AIに一手ずつ考えさせる必要はない。

スクリプトを書いて、一回実行すればよい。

AIに確認まで全部やらせると、確認作業のほうが高くなる

ゲームや3D制作では、作ることよりも、その後の確認と修正が高くつくことがある。

完全自動で修正させようとすると、次のような流れになる。

ゲームやシーンを実行
↓
スクリーンショットを取得
↓
AIが画像を確認
↓
シーンや設定を調査
↓
原因を予想
↓
修正
↓
再び実行

これを何度も繰り返す。

しかもGUIソフトでは、問題の原因が一か所にない。

  • コード
  • オブジェクトの設定
  • シーン構造
  • 素材
  • プラグイン
  • ビルド設定
  • 実行中だけ存在する状態

のどこにあるか分からない。

例えば、複数階の3Dシーンで一部の階段だけ向きが逆になったとする。

AIが自力で特定するなら、各階の座標、回転、上下階との接続、画面上の見た目を調べる必要がある。

だが、人間が画像を見れば、

2階と3階の階段だけ逆。ほかは合っている。

で済む。

さらに、

手すりは直っている。そこは触るな。壁との重なりだけ直せ。

と伝えれば、変更してはいけない場所まで一度に指定できる。

人間を途中に入れることは、自動化の敗北ではない。

今のAIの弱点を、人間の一目で補っているだけだ。

AIに画面を10回見せるより、人間が一回見たほうが安い場合は普通にある。

AIは、本当にゲーム一本を完成させたことがあるのか

短いブラウザゲームや、Pong、Flappy Birdに近い小作品なら、AIはかなり作れる。

だが、

  • ゲーム全体を設計する
  • コードを書く
  • 素材を組み込む
  • UIを作る
  • セーブを作る
  • バグを探す
  • バランスを調整する
  • ビルドする
  • 数時間遊べる内容を用意する
  • 後から保守できる状態にする

ところまで、ほぼ無人で完成させた中規模以上の事例は、まだ一般化できるほど確立していない。

2026年のGameCraft-Benchは、Godot上でAIエージェントにゲームを最初から作らせる140課題を評価した。最も強いエージェントでも総合スコアは41.46％で、多くのエージェントは40％未満だった。基本的な仕組みは実装できても、十分な内容、分かりやすい反応、統一された見た目を持つ完成ゲームへまとめることに苦戦した。

GameDevBenchでは、ゲーム一本を作るより狭い「既存ゲームへの機能追加」でも、最良の成功率は54.5％だった。特に2Dグラフィックスを扱う課題では成功率が31.6％まで下がっている。

さらにJamBenchでは、プロジェクトが大きくなるにつれて、実行まで通る割合が小規模の80.4％から大規模では5.7％まで落ちた。コードエージェントを使ってコンパイル率が改善しても、実際の動作の質は改善せず、研究者は全体設計が主要な壁だと分析している。

規模・作業 現在のAIが得意か
一つの仕組みを試作する 比較的得意
短い小規模ゲームを動かす 人間の監督があれば可能
複数機能のつじつまを保つ 不安定
見た目・素材・コードをまとめる 苦手
中規模以上の全体設計を維持する かなり難しい
自分で作ったものを完全にデバッグする まだ信用できない
長期保守できる製品へ仕上げる 人間が必要

MCPで操作できる機能を200個に増やせば、この問題は解決するだろうか。

私はそうは思わない。

道具が足りないのではない。

全体のつじつまを長期間保つ能力が足りない。

Unityを使う理由はある。だが、Unityを使わない理由もある

Unityには明確な強みがある。

  • 複数環境へのビルド
  • 物理
  • アニメーション
  • 素材管理
  • プロファイリング
  • 大量の既存アセット
  • 各種SDKとの連携

こうした機能を使うなら、Unityを選ぶ価値は大きい。

既存のUnityプロジェクトを人間と共同編集するなら、Unity MCPにも意味がある。

だが、小さな単一環境向けゲームで、これらの多くを使わない場合はどうか。

Unity MCPをつないでも、

  • フォント設定
  • Prefabの参照
  • シーン上の設定
  • パッケージの相性
  • 通信サービス
  • ビルド先固有の設定

は残る。

MCPはUnityを操作可能にする。

Unity固有の面倒まで消してくれるわけではない。

小さなゲームを作るために、巨大な統合環境をAIへ丸ごと理解させる必要が本当にあるのか。

そこは疑ってよい。

RPGツクールの強みは「高度な技術」より「もうRPGになっていること」

RPGツクールの本当の強みは、最先端の実行技術ではない。

  • マップ
  • 会話イベント
  • キャラクター
  • 職業
  • スキル
  • アイテム
  • 戦闘
  • ショップ
  • セーブ

が、最初からRPGの形になっていることだ。

人間が典型的なRPGを作るための面倒な前準備を、最初から済ませてくれている。

これは非常に強い。

だが、AIがデータやJavaScriptを直接生成し、人間が後からEditorを触らず、標準戦闘や既存素材も使わないならどうか。

その場合、ツクール固有の入力画面を経由する意味は薄くなる。

RPGツクールMCPがあるからRPGツクールを使うのではない。

RPGツクールの便利な部分を使いたいから、必要ならMCPを使う。

順番を間違えてはいけない。

Blenderは使え。ただし、一個ずつ操作させるな

Blenderには明確な技術的価値がある。

  • モデリング
  • UV
  • アニメーション
  • レンダリング
  • Geometry Nodes
  • 各種形式への書き出し

これを一から作り直すのは馬鹿げている。

だからBlenderは使えばよい。

しかし、BlenderはGUIからしか使えないソフトではない。

AIにBlenderのボタンを何度も押させるのではなく、Blender Pythonを書かせればよい。

blender --background scene.blend --python generate.py

100本の柱を一個ずつ追加させるのではなく、100本を作るループを書かせる。

MCPは、

  • シーン状態の取得
  • 生成スクリプトの実行
  • レンダリング
  • エクスポート
  • エラー取得

のために使えばよい。

MCPをPythonの代わりにするな。

Pythonを動かす入口として使え。

AI向けには「機能が少ない」が強みになる

人間向けのソフトウェアでは、機能が多いほど高性能に見える。

AIにとっては、必ずしもそうではない。

機能が増えるほど、

  • 選ぶ機能が増える
  • 設定項目が増える
  • バグの原因候補が増える
  • 読む説明が増える
  • バージョン違いが増える

からだ。

小規模ゲームなら、あえて単純な環境を使う価値がある。

環境 AIにとっての強み 弱点 向いているもの
Pyxel Python、APIが小さい、制約が明確 表現力と規模に限界 レトロゲーム、小規模2D
raylib GUI Editorがなく、処理がコードに直結 Editorや便利機能を自分で補う 軽量2D・3D
Bevy Rustの型検査、状態をコードで管理 RustとECSの難しさ 独自ルール、シミュレーション
Godot GUIも使え、シーンをテキスト保存できる 複雑になるとEditor依存も残る GUIとコード中心の中間
Three.js / Phaser ブラウザですぐ動き、自動テストしやすい ネイティブ機能は別途必要 Webゲーム
Pygame / LÖVE 構成が単純で、全体を読みやすい 大規模開発支援が弱い 試作、小規模2D

Pyxel

PyxelはPython向けのレトロゲームエンジンで、16色、4音チャンネルなど、意図的に強い制約を持っている。

普通に考えれば低機能だ。

だが、AIにとっては利点にもなる。

選択肢が少ない。

APIが小さい。

プロジェクト全体を読みやすい。

制約は、AIの弱点を補う。

何でもできる巨大なEditorへAIを投げ込むより、Pyxelのようにやることが絞られた環境のほうが、AIが本当に一本を完成させる可能性は高いかもしれない。

raylib

raylibは公式サイトで、自らこう説明している。

“no fancy interface, no visual helpers, no gui tools or editors”

豪華な画面も、視覚的な補助も、GUIツールもEditorもない。ただコードを書く。

小さなゲームなら、それでよい。

入力、描画、更新処理が全部コードにある。

AIはコンパイルエラーを読み、修正し、再実行できる。

Inspectorに隠れた設定を探す必要がない。

Bevy

BevyはRust製のデータ駆動型ゲームエンジンで、エンジンとゲームのロジックにECSを使っている。

例えば体力を、

#[derive(Component)]
struct Health(i32);

と書ける。

AIは体力がどこにあるかをGUIから探さなくてよい。

Rustのコードを読めばよい。

型の間違いはコンパイラが教える。

もちろん、Unityほど完成したEditorや周辺機能はない。

人間にとって使いやすいことと、AIにとって扱いやすいことは別なのである。

Godot

GodotはGUIエンジンだが、シーンをTSCNというテキスト形式で保存でき、--headlessによるコマンドライン実行にも対応している。

つまり、

AI：コードとTSCNを編集
自動処理：headlessでテスト
人間：Editorで見た目と操作感を確認

という分担ができる。

GUIを捨てる必要はない。

AIにGUIだけを使わせる必要がないのだ。

ゲーム以外のMCPも、同じ基準で考えろ

この話はゲームだけではない。

対象 MCPが向いている仕事 コードやCLIを先に検討する仕事
Excel 既存ブック、数式、VBA、書式を維持 単純な集計やグラフ生成
Figma 部品、色、余白、変数の取得 レイヤーを一つずつ操作
GitHub Issue、PR、差分の取得・更新 Web画面の遠隔操作
データベース SQL、スキーマ取得、定型更新 管理画面をクリック
CAD 寸法取得、形式変換、検査 面や頂点を一つずつ選択
DAW トラック作成、MIDI入力、定型処理 曲の良し悪しを何度も自動判定
ブラウザ テスト、定型入力、情報取得 長大な画面を毎回すべて読み直す

GitHubのデータが欲しいなら、Web画面をAIに操作させず、IssueやPRを直接取得すればよい。

データベースを更新したいなら、管理画面ではなくSQLやAPIを使えばよい。

CADで100個の穴を開けたいなら、面を100回選ばせるより、パラメーターを与えて一括生成したほうがよい。

GUIは、最後に人間が確認・調整する場所として残せばよい。

AIの主な作業場所にする必要はない。

完全自律にこだわるな。人間を一回入れろ

AI自動化というと、「人間を一切入れないこと」が最高だと思われがちだ。

私はそうは思わない。

AIがゲーム画面を10回確認し、そのたびに、

  • 画像を読む
  • 設定を調べる
  • 原因を考える
  • 修正する
  • 再実行する

くらいなら、人間が一回遊んで問題点を返したほうがよい。

・HP表示が右端から切れている
・2階の階段だけ逆向き
・敵が壁の中に出現する
・移動速度が少し速い
・それ以外は触らない

これでよい。

AIに画面を見せるな、と言っているのではない。

見る必要のないものまで、何度も見せるな。

座標で判断できる問題は座標で判断する。

重なりは衝突検査で調べる。

参照切れは自動で検査する。

セーブの一致はテストする。

それでも分からない見た目や操作感だけ、人間が見る。

MCPを使う前の確認表

質問 「はい」なら
最終成果物をそのソフトで人間が編集するか MCPを使う理由がある
既存のプロジェクトやファイルを維持するか MCPを使う理由がある
そのソフトにしかない機能を使うか MCPを使う理由がある
既存素材やプラグインが重要か MCPを使う理由がある
まとまった処理を一回で実行できるか MCP向き
同じ細かい操作を何十回も繰り返すか コードやCLIにする
一つのスクリプトで再現できるか スクリプトを優先する
結果を数値やテストで確認できるか GUI確認を減らす
見た目や面白さの判断が中心か 人間を途中に入れる
使わないツールまで大量に読み込んでいるか ツールを減らす
失敗時に簡単に元へ戻せるか 戻せないなら自動実行させない

一番重要な質問はこれだ。

MCPでできるかではなく、MCPを使うことで本当に安くなるか。

結論：AIを人間の操作方法に閉じ込めるな

GUIは、人間にとって便利である。

だが、人間に便利な手順が、そのままAIにも便利だとは限らない。

AIにExcelを操作させてグラフを作るより、PythonとMatplotlibを書かせたほうが早い。

AIにBlenderで柱を一個ずつ置かせるより、Pythonで100本生成させたほうが早い。

AIにUnityのInspectorを何度も変更させるより、C#や生成スクリプトを書かせたほうが早い。

AIにRPGツクールの項目を一つずつ埋めさせるより、データをまとめて生成したほうが早いかもしれない。

それでもExcel、Blender、Unity、RPGツクールを使う理由があるなら、使えばよい。

既存資産、人間との共同作業、複数環境への出力、高性能なレンダラー、専門的な編集機能。

そうした理由があるなら、MCPは強力である。

だが、

MCPがあるから、そのソフトを使う。

は逆だ。

GUIをAIに触らせることが目的になった瞬間、手段と目的がひっくり返る。

AIに人間用GUIを一クリックずつ操作させるな。

一回で書けるコードは、一回で書かせろ。

ループで済む仕事を、100回ツール呼び出しさせるな。

数値で確認できる問題を、画像から推測させるな。

人間が一目で分かることに、何万トークンも使うな。

そして何より、

GUIが本当に必要なのかを、最初に疑え。

MCPは、AIとあらゆるソフトをつなぐ未来の標準になるかもしれない。

だが、その未来が、

AIが人間のマウス操作を、延々と高い金を払って真似する世界

だとしたら、私はあまり賢い未来だとは思わない。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?