Unity公式のClaude CodeプラグインをRachel Zhaoさんが解説。中小企業のAI活用にも効く「型を配る」発想

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Unity社が発表した公式Claude Codeプラグインの記事を紹介するね。

Unity公式ブログ「Official Unity Plugin for Claude Code」（Rachel Zhao／Unity Director of AI Products）より

現在、ゲーム開発のヘルプをエージェントに依頼すると、エージェントが代わりにゲームエンジンを選択し、インストール、実行、そして同一セッション内で共有できるものを選択する傾向があります。

Unity Engineへのアクセス方法が、2026年に入って急速に変わりました。元記事はそう書いています。

ブラウザを開いてダウンロードページへ進む代わりに、コーディングエージェントに「作りたいゲーム」を説明する。そこから始める開発者が増えています。これが今回のプラグイン発表の前提です。

この変化を読んで、私が思い出したのは別の話です。

「AIで御社の売上が10倍になります」。そう大風呂敷を広げるコンサルがいます。蓋を開けてみれば、ChatGPTに文章を書かせて終わり。何百万も払って、結局何も変わりません。経営者の切実な悩みを食い物にしている人たちを、私は何人も見てきました。

エージェントに「説明すればやってくれる」時代が来るほど、説明を受け取る側の差がそのまま結果の差になります。中身のない丸投げ先に説明しても、出てくるのは推測だらけの答えだけです。

今日から試せることは1つ。自分が普段お願いしているAIツールに、現場固有の前提を知っている型があるか、一度確かめてみてください。

ゲーム開発に限りません。AI活用の相談でも「何をどこまで説明すれば伝わるか」で悩む人が多いです。Unityがやったのは、その説明の手間を型として先回りで用意したことです。相談を受ける側が先に型を持っていれば、相談する側は「作りたいもの」だけを言えばよくなります。

Unity公式ブログより

Claude Code 用の公式Unityプラグインは、Unity CLI を操作するための unity-cli スキルを含む、Unity のエンジニアリング スキルをインストールする公式プラグインです。これにより、Claude Code はUnityが意図したとおりにUnityプロジェクト内で動作します。

元記事はこのギャップを、ある比喩で説明しています。「経験豊富だが、あなたのコードベースを見たことのない請負業者を雇う」。

腕は良くても、そのプロジェクトが資産をどこに保存するか知りません。チームが標準化したUIフレームワークも知りません。だから作業はすべて推測になります。

Claude Codeは、このプラグインをインストールできる最初のコーディングエージェントです。端末またはClaudeデスクトップアプリからインストールできます。

ここで思い出す話があります。難しいカタカナ用語で煙に巻く業者です。「DX」「トランスフォーメーション」「オートメーション」。そう言いながら、結局Excelのマクロすら組めません。中小企業の経営者は「自分が分からないだけかも」と自己嫌悪に陥ります。それが一番許せませんでした。

Unityが選んだ方向は逆です。抽象的な説明ではなく「unity-cliスキルを含むエンジニアリングスキル」という具体名で、何が入っているかをそのまま言い切っています。

説明の誠実さは、言葉の難しさでは測れません。中身を具体的に数え上げられるかどうかで測れます。

次にサービスを選ぶ時、その説明が数え上げられる中身を持っているか見てください。

Unity公式ブログより

現在、このプラグインは単一のコマンドで29個のスキルをインストールします（今後さらに追加予定です）。設定は不要で、プロジェクトごとの設定も不要、新しいマシンに移行する際にコピーする必要のあるファイルもありません。

29個のスキルは8分野に整理されています。「はじめに＆ツール」「UIとテキスト」「2Dとスプライト」「グラフィックとレンダリング」「オーディオ」「シーンとゲームプレイ」「Monetizationとライブ運用」「プラットフォーム」です。

たとえばUIとテキスト分野には、UI Toolkit・uGUI・IMGUIのどれを使っているかを検出してから処理を渡す「/ui」ルーター役のスキルがあります。導入コストの低さ自体が差別化ポイントです。

この「型を渡せば結果が引き継がれる」という発想、私にも心当たりがあります。

「抱え込みOSを書き換える」というキラーフレーズがあります。自分にしかできないと思い込んでいた仕事を、誰でも動かせる手順に分解して渡す作業です。未完成でも出す。作業を委任する。その一歩を、今まさに積み重ねている最中です。

Unityのエンジニアが29個のスキルに分解したのも、同じ作業です。自分だけが知っていたプロジェクトの前提を、誰が読んでも動ける手順に変えています。

関連して、AIに記憶や型をどう持たせるかという視点ではBasic Memoryの使い方を解説した記事も参考になります。

8分野の内訳を見ると幅が広いです。UIやオーディオのように「よく使うが毎回迷う」領域もあります。Monetizationやマルチプレイヤーのように「専門知識がないと事故りやすい」領域もあります。全部を一度に覚える必要はありません。今つまずいている分野のスキル名だけ拾えば十分です。

今日から真似できることは1つ。自分の現場で「毎回同じように教えていること」を書き出してみてください。

私がAI活用支援の現場で見てきた失敗の多くは、この「型を渡す手間を惜しんだ」ことが原因でした。AIに丸投げする前に、自分の現場の前提を1枚のメモにまとめておくだけで、返ってくる提案の質がまったく変わります。29個のスキルという規模には遠くおよびませんが、考え方は同じです。

Unity公式ブログより

スキルを使用した場合と、クロードにヘルプなしで不慣れなタスクをコードさせようとした場合とでは、出力のエラーが少なくなり、一般的にトークン効率が向上し、より少ないターンでタスクを完了できるようになります。

元記事は「開発者コミュニティのプラグインも素晴らしい仕事をしてきた」と前置きしています。そのうえで、セキュリティレビューを受けた自社製の一次情報だという位置づけを強調しています。

エラーが減る。トークン効率が上がる。ターン数が減る。この3つの実利で、公式であることの価値を語っている点が興味深いです。

「誰でも簡単に」「今すぐ」。この手の言葉は、AIを魔法だと錯覚させます。使いこなすには「縦に掘る」努力が必要です。それを隠して売りつける姿勢を、私はずっと許せませんでした。

3万円で買った情報商材が、見た目は豪華で中身はスカスカでした。そんな原体験もあります。

Unityが今回示したのは、その逆張りです。エラーが減る、効率が上がるという成果は、誰かが縦に掘った結果として出てきたものだからです。

あなたが日々使っている効率化ツールも、「誰でも簡単に」の看板だけで選ばないでください。その裏にどれだけ実測があるか、1つ確かめてみてください。

「エラーが少ない」「トークン効率が良い」という言い方は、地味で煽りが弱いです。だからこそ、実測で裏付けを取った上でこの言い方を選んでいる姿勢に信頼が置けます。地味な実利を淡々と語る方が、結局は長く使われるツールになります。

Unity公式ブログより

私たちは、この特徴を所有し、セキュリティレビューを受け、エンジンとステップを合わせたドキュメントを提供するUnityチームが作成したスキルを活用できるように、ファーストパーティプラグインを作成することにしました。

開発者コミュニティが作った非公式プラグインも、すでに多く存在します。その中でUnityがあえて自社製のファーストパーティプラグインを作った理由は3つです。「特徴の所有」「セキュリティレビュー」「ドキュメントとエンジンのバージョン一致」です。

誰が作ったかを隠しません。責任の所在を明確にする選択です。

「期待値コントロール＋内容しっかり」という信念があります。中身の薄いものを、雰囲気だけで売ってはいけないという学びから生まれた信念です。やるからには、期待を超えるものを届けたい。

Unityが「誰が作ったか」「何を保証しているか」を隠さなかったのは、まさにこの信念を製品づくりの形にしたものだと思います。中身の薄さを雰囲気で隠す代わりに、保証の中身を先に見せています。

スキルという単位を丸ごと届ける発想についてはJinba MCPがSkillsを中身ごと渡さず届ける方法を解説した記事も合わせて読むと理解が深まります。

何かを人に勧める時、自分がどこまで検証したかを言い添える。その習慣を今日から始めてみてください。

これはAI活用支援の現場でも同じです。私が提案するツールは、必ず自分で触ってから紹介しています。触っていないものを「良さそうだから」で勧めることはしません。それが公式にこだわる姿勢と重なる、私なりの最低限の誠実さです。

Unity公式ブログより

今後チームが追加するすべてのスキルは、リリース当日に既に開いているツール内に表示され、次に試そうとするエージェントでも、 Unityが既にそのスキルに対応している状態になります。

ユーザーが手動でアップデートを取りに行く必要はありません。Unity側が追加したスキルは自動的に反映されます。

記事の最後は「今日ぜひ試してみて、感想をお聞かせください」という現場フィードバック募集で締められています。公式プラグインを完成品としてではなく、育て続ける前提で出していることが伝わります。

自分の経験や価値観、口癖まで、すべてを文字にしてObsidianに蓄積しています。これが分身AIの「魂」になります。

「分身AIを育てる＝自分が育つ」を体現している作業です。Unityのエンジニアが持っている暗黙知をスキルという形に言語化し、配り続ける。この仕組みは、私がObsidianへ自分の経験を言語化し続けているのと根っこが同じだと思います。

渡す形さえ整えれば、追加も更新も黙って届くようになります。

あなたの中にある「毎回同じように教えていること」を、今日1つだけ文字にして残してみてください。それが誰かに黙って届く型の第一歩になります。

アップデートを「取りに行く」から「気づいたら届いている」へ変える設計は、地味ですが効く工夫です。型を配る側が更新の手間を引き受けることで、受け取る側は追いかける負担から解放されます。この非対称の引き受け方こそ、公式が果たすべき責任の形だと思います。

Unity公式Claude Codeプラグインの本質は、機能の多さではありません。「プロジェクト固有の前提を知っている型」を、1コマンドで渡せる形にしたことにあります。

汎用エージェントに丸投げする状態と、公式の型を渡された状態の差。それは経験のない請負業者に一から説明する手間があるかないかの差です。

この発想は、ゲーム開発に限った話ではありません。自分の現場で毎回同じように教えていることを、渡せる形の「型」に書き出せているか。これがこれからのAI活用の分かれ目になっていきます。

今日紹介したのは5つの視点です。「請負業者の比喩」「8分野29スキルの一覧」「エラー減・効率向上の実利」「ファーストパーティにこだわる理由」「アップデートが黙って届く仕組み」。専門知識を型にできているか、あなたの現場でも一度点検してみてください。

Unityがゲームエンジンでやったことは、業種を選びません。会計、接客、製造、どの現場にも「毎回同じように教えていること」があります。それを型にして渡せるかどうかが、これからのAI活用の分かれ目になります。

私自身、AI課題解決の相談を受けるたびに、同じ説明を繰り返していることに気づきます。それを毎回話すのではなく、1枚のメモに固定して渡す。今回の記事を書きながら、自分の現場でもすぐ真似できる宿題をもらった気持ちになりました。

次にあなたがAIへ何かを頼む前に、一度立ち止まってみてください。今から渡す指示は、型のある指示でしょうか。それとも、請負業者に丸投げする指示になっていないでしょうか。