Unity Editorを操作するCLIを作り直しました

Unity EditorをAIエージェントから遠隔操作するツール（UnityMCP）を開発・運用している技術者が、バージョン1から4へ全面的に作り直した過程の詳細記録だ。課題は起動時間とコンテキスト量。当初130ミリ秒かかっていた起動が14ミリ秒に短縮され、ツール定義は30,000トークン強を占めていたものが、遅延読み込み戦略で最初から2,000トークンに圧縮された。この仕事に踏み切った理由は実務的だ。複数のAIツール（Maya、Motion Builder、After Effects等）を並行運用しているとき、1つあたりの固定費用が全部に掛かってくる。業務連携では何十回も呼ぶため、マイクロ秒の固定費が何百回も積もり、やがてコンテキスト圧縮に陥る。

AIの鬼が見つけるのは、ここでの最適化が実は「単一ツール的な思考」から「マルチツール並行運用」への転換を迫っているという現実だ。デモや単発の実行なら、起動時間やトークン占有は気にならない。それは測定機（Core i9-14900KF）でも523オブジェクトを全スキャンしない限り見えない。だが業務連携では、何十回も呼ぶ。そこで初めて「そこまで最適化が必要か」という疑問が現実味を持つ。記事では自動採点エンジンの設計方針さえ「フルオプション定義を毎回送る」から「遅延読み込み・必要に応じて後から追加」に切り替えた。その決定を支えたのは実測データ——同じコードスニペットの一致率が中央値0.91という発見である。何度も同じ行が出てくるなら、定義1回の価値は何十回の呼び出しに耐える。逆算すると、390トークンのコード定義は79回呼び出せば、30,973トークンの定義セット全体と拮抗する。つまり、毎回送信するより、最初に3個の「よく使うツール」だけ載せて、残りは検索で間に合わせたほうが、総コストが下がるのだ。

中小企業がAIツール群を導入するとき、「機能数が多い」より「毎回の固定費がいくら」かを見るべきだ。導入直後は数回の試行で満足するが、本運用では数百回だ。1回あたり100トークン余計に消費する設計は、1,000回で100,000トークン、コンテキスト圧縮トリガーになる。技術的な「速さ」の話に見えるが、実務的には「使用方法に耐えうる設計か」という適性判定の問題なのだ。「デモで見映えがする」と「毎日何十回も回せる」は全く別の話である。最適化の決定は、ツールの品質ではなく、あなたの使い方に合っているかを判定する。