こんにちは、takuです。
ここ1〜2年で、Unity案件でもAIアシスタントを入れているチームがかなり増えてきた気がします。
GitHub Copilot、各社のチャットAI、エージェント系の新機能…。
ただ、自分のまわりを見ていると、
みたいな状況も、まだまだ多いんじゃないかなと思いました。
自分も最初はその一人で、
「とりあえずC#を書いてもらう相棒」としてCopilotを使っていました。
メソッドの中身を補完してくれたり、単純な処理を一気に書いてくれたりするので、
局所的にはかなり助かります。
でも、しばらく運用していく中で、 決定的な違和感 が出てきました。
- プロジェクトのアーキテクチャを知らないまま、「それっぽいコード」だけが増えていく
- その瞬間は時短になるけれど、数週間後のリファクタが確実に重くなっている
結果として、「あとで自分が直す未来」が見えているコードを受け取る場面が増えてしまい、
心理的にはあまり楽になっていないな…と感じたんです。
そこで発想をガラッと変えて、
「コードを書いてもらう前に、レールを一緒に引いてもらう」 という使い方に寄せてみました。
この記事では、
を、かなり実務寄りにまとめてみます。
1. Copilotに「コードだけ」書かせても、手戻りコストはあまり減らなかった
まず前提として、自分が関わっているのはスマホ向けのUnity案件で、
よくある「長期運用型のゲームプロジェクト」です。
という環境です。
この手の案件で、最初にCopilotを入れたときに感じたのは、
「確かに、メソッド単位の実装は速くなる。でも、プロジェクト全体の見通しが良くなるわけではない」
ということでした。
具体的には、こんなことが起きがちでした。
- 便利そうに見えるけれど、プロジェクト固有のルールから微妙に外れた実装案が出てくる
- 一回通してしまうと、そのノリで似たコードがどんどん増えていき、「局所最適な関数」が散らばる
結果として、
- レビューコストが増える
- 後からの整理・リファクタの難易度が上がる
- 「この機能、誰が本当の責任者なんだっけ？」というモヤモヤが増える
といった、 「長期運用案件で一番避けたい負債」 の方が目立ってしまいました。
つまり、
「コード生成は速くなったけれど、判断の迷いと設計の手戻りはあまり減っていない」
という状態だったんです。
2. 先にPlanで「レール」を敷くと、迷いの8割くらいは消える
そこでやり方を変えて、
「いきなりコードを書いてもらう」のをやめて、最初にPlanにレールを引いてもらう ことにしました。
2-1. 機能追加ごとに、「どこを触るか」の地図を先に作る
Unityのゲーム開発だと、機能追加のたびにまず考えるのは、
- どのクラスに責務を持たせるか
- 既存のどこにフックするか
- プレイヤー体験やUIフローへの影響はどこに出るか
といったあたりだと思います。
ここで自分は、Copilotの Plan をかなり積極的に使っています。
実際にやっていることはシンプルで、
- 「どんな機能を足したいのか」
- 「既存のアーキテクチャや代表的なクラスの役割はどうなっているか」
を自然言語で投げて、
「今回の変更で、どのクラスをどう変えるのが一番素直か？」
を、Planに 手順として整理してもらう という使い方です。
ここで得られるメリットはかなり直接的で、
- 変な方向に実装が走り出す前に、「おおよその処理の流れ」と「触るべき場所」 が見える
- Planがタスクを分解してくれるので、レビュー時に「この粒度で進めていいか」を合意しやすい
という2点に集約されます。
「この機能ならこのクラス群にこういう責務を追加するのが良さそう」
という案を一度Planに出してもらった上で、
- 「ここは自分のプロジェクトだとこう変えたい」
- 「このステップは不要なので削る」
といった 微調整だけに人間のリソースを使う イメージに変えました。
結果として、
- 「なんとなくCopilotに書かせたけど、この方向性はやめたいな…」という後悔が減った
- 手を動かす前に 「この変更でどこまで影響が出るか」の腹づもり がつく
という、かなり実務的なメリットが出てきた感覚があります。
2-2. Planが苦手な「でかい設計変更」は、あえて任せすぎない
もちろん、Planが万能かというと、さすがにそうではありません。
特に、
- 自分側の調査や整理が甘いと、そのまま浅いPlanが返ってくる
- 複数シーン・複数サブシステムにまたがるような大規模変更は、どうしてもシンプルにまとめすぎて抜け漏れが出る
という弱さはあります。
たとえば、
- ゲーム全体のフローを組み替えるようなリファクタ
- チュートリアル〜ロビー〜バトルといった複数シーンに影響する仕様変更
みたいなところは、正直まだ 「丸ごとお任せする」のは怖い領域 です。
なので、自分の中ではざっくりと、
- 小〜中規模の機能追加やリファクタ
→ Plan中心でレールを引いてから実装 - 大きな構造変更や長期的な設計
→ 自分で設計を組み立てて、その一部だけPlanに相談
くらいの切り分けをしています。
このくらいの距離感にしておくと、
- 「Planに任せすぎて、気づいたら設計の大前提が崩れていた」
- 「でも、全部自分でやっていても時間が足りない」
みたいな両極端を避けつつ、
「迷いを減らすところだけAIに肩代わりさせる」 形に収まりやすいなと感じました。
3. Copilot CLIで「案出しとタスク分解」を並列化する
Planとセットでかなり良かったのが、Copilot CLI です。
最近は Vibe Kanban のようなツールもCLIに対応してきていて、
「設計やタスク分解の案出しを、ほぼノーコストで並列に投げられる」 ようになってきました。
3-1. 「やりたい変更案」を全部出してから、あとで人間が選ぶ
自分の使い方としては、ざっくりこんな流れです。
- 事前に、「こういう変更をやりたい」「こういう案もありそう」という候補をいくつか書き出しておく
- Copilot CLI経由で、それぞれの案に対して
- 影響範囲
- 大まかな手順
をざっと洗い出してもらう - その結果を見ながら、
- どの案を採用するか
- どの順番で実装するか
を人間側で決める
これをやると、
- 「一応検討した方がいい案」も、とりあえず並列で掘っておける
- 人間側は「どの案を採用するか」の判断に集中できる
という状態に持っていけます。
特にゲーム開発は、
- 仕様変更
- 優先順位の入れ替え
- リリースタイミングの調整
が発生しがちな分野なので、
「実装に入る前の時点で、複数ルートの『ざっくり見積もり』がある」
というのは、それだけで精神的にだいぶラクになります。
3-2. 単純でめんどくさいところは、容赦なくAIに任せる
一方で、現時点でも「全部丸投げ」はさすがに怖いので、
任せる範囲と自分で握る範囲はかなり意識して分けています。
たとえば、次のようなところは、わりと容赦なくAI側に寄せています。
- 文言修正やちょっとしたUIテキストの調整
- フラグの追加や、小さな条件分岐の変更
- 仕様としては単純だけれど、手で書くと地味にめんどくさい処理
このあたりは多少曖昧さがあっても許されやすく、
レビューで引き戻しもしやすいので、
「人間の集中力を使うには、もったいないゾーン」
だと割り切っています。
逆に、
- アーキテクチャのルールを変える
- ゲーム体験に直結するフローを触る
といった部分は、最初のレールづくり（Plan/CLI）まではAIに頼るけれど、最終判断は自分で握る というバランスにしています。
この「どこまで任せて、どこからは自分で握るか」の線引きが一度決まると、
- チーム内でのAI利用ルールも決めやすくなる
- PRレビューの観点も揃えやすくなる
ので、結果的に 「AIを入れたせいで現場がカオスになる」リスクを減らせる なと感じています。
4. 商業開発でAIを使いこなすなら、Planはほぼ必須のインフラになりつつある
ここまで、Unityのスマホゲーム案件で、
CopilotのPlanとCLIをどう組み込んでいるかを書いてきました。
自分の感覚としては、Planは
- 「仕様駆動開発」
- 「まず設計やタスク分解から入るスタイル」
とかなり相性が良くて、
よく話題になる Vibe Coding（とりあえずコードを書いてもらって形にしていくスタイル）とは、
対になる考え方 に近いなと思っています。
どちらが正しいという話ではなくて、
という 住み分けがハッキリしてきた 感覚があります。
少なくとも自分は、仕事でAIを使うときには、
- 設計・タスク分解
→ PlanやCLIでレールを一緒に引く - 実装
→ C#のコード生成は遠慮なく使いつつ、アーキテクチャから外れていないかだけ自分でチェックする - 微修正・文言・フラグ
→ ほぼAIに任せて、レビューで整える
くらいのバランスが、今のところちょうどいいなと感じています。
5. これから試すなら、いきなり本番ではなく「小さなレールづくり」から
もしこれから、
- Unityの商業案件でCopilotや類似ツールを本格的に使ってみたい
- でも、いきなりプロダクションにAIを突っ込むのは正直怖い
という状態なら、
「まずはPlanとCLIを、設計やタスク分解のところに少しずつ混ぜてみる」
くらいの始め方がちょうどいい気がします。
具体的には、
- 社内ツールや、小さめの機能追加
- 一人で完結しやすいサブ機能の改善
- バグ修正タスクの整理や再発防止のフローづくり
といった、影響範囲をコントロールしやすいところ から試すのがおすすめです。
そこで、
- 「どこまで任せるとちょうどいいか」
- 「どの粒度のタスクならPlanに切ってもらうと楽か」
- 「自分のチームのアーキテクチャだと、どこまでコンテキストを共有すれば妥当な案が返ってくるか」
を、少しずつ体感で掴んでいくと、
本番案件への展開もしやすくなるんじゃないかなと思いました。
このあたりの、
- 実際に使っているプロンプト例
- Unityプロジェクト側でのセットアップ手順
- Plan／CLIを前提にしたタスク管理のテンプレート
については、別途ストック記事としてもう少し丁寧にまとめてみたいと考えています。
参考リンク
- VS Code向けCopilot Planモードの解説（Publickey）
- https://www.publickey1.jp/blog/25/vs_codecopilotplan.html
- GitHub Copilot CLI 公式紹介ページ
- https://github.com/features/copilot/cli?locale=ja
