Cinemachine 2→3移行で実際に効果があった進め方

Grandis Adventuresの開発で、Cinemachine 2から3への移行を行いました。

移行前にはUnity公式のドキュメントや、すでにCinemachine 3への移行を経験された開発者の方の記事なども参考にしています。

ただ、実際にやってみると、やっぱりProjectごとに構成が全然違います。

今回はその中でも、バックアップ、小さい環境での確認、GPTとToolsを使った切り分けがかなり役に立ちました。

最初はProject全体でいきました

まずはバックアップ。これはUnity公式の案内にもあるので、その通りに。

普段から定期的に取っていますが、こういう大きな変更の前は改めてProject全体を保存しています。

CinemachineのUpgraderでは、Object単位、Scene単位、Project全体という形で対象を広げていけます。

最初は「バックアップもあるし、まあ一気にいけるだろう」とProject全体を選びました。PCから出てる、ふぅおーん。みたいな音を聞きながら20分くらい待ち。

結果、途中でStack Overflow。

もちろん赤エラーです。

一度戻して、今度は逆に小さいところから確認することにしました。

新しく検証用のSceneを作って、必要なものだけ置いてCinemachine 3への変換を確認。

そこからObject単位、Scene単位と少しずつ広げて、「どこまでは通るのか」を見ていきました。

最初から全部を見るより、こうした方が問題が起きた場所をかなり絞りやすかったです。

ここからGPTとToolがかなり効きました

ただ、切り分けを進めても「なぜここで止まるのか」が分からない部分は当然出てきます。

例えば、CinemachineのUpgraderが内部で行っている処理をいくつかのStepに分けて、どの段階まで正常に通っているのかを見る診断Tools。実際に GetUpgradables、UpgradeNonPrefabs、UpgradeObjectReferences、DeleteObsoleteComponents と分けてログを取るようになっています。 CM3ProbeLegacyCameraCreator

ほかにも、Project内のScriptを横断して、CinemachineFreeLook や m_XAxis、m_YAxis など旧CinemachineのAPIがどこに残っているのかを探すToolも作りました。 CM3LegacyCameraCodeAudit

さらにPrefab側まで追い始めると、Scene上のCameraだけではなく、元Prefab、Nested Prefab、Override、ほかのScriptからの参照まで確認するToolも必要になりました。 CM3PrefabCameraRiskAudit

気がついたらToolsメニューがこんな感じになっていました　↓

最初からこれだけ作ろうとしたわけではありません。

一つ調べる。

「ここは問題なさそう」

でも次の部分はまだ分からない。

じゃあ、そこを見るためのToolを作る。

これを繰り返した結果です。

感覚としては、Projectの中をレントゲンで少しずつ撮っている感じでした。

「原因を聞く」より「原因を一緒に探す」

今回一番感じたのは、開発で詰まっている時って、解決方法が存在しないというより、そもそも原因がまだ分かっていないことが多いということです。

原因が見えていない状態だと、人間でもAIでも予測したり推測で補完します。

でも実際のScript、Prefab、Inspector、参照関係、ログなどを確認できれば、

「これは違う」

「ここまでは正常」

「じゃあ次はここ」

と候補を減らしていけます。

分からない部分を確認するためのToolまで、その場で作りながら一緒に原因を追ってくれたことです。どの階層なのか、Projectごとに構成は違うので、今回作ったToolをそのまま使えばいい、という話でもないと思います。

むしろ、

「自分のProjectでは、次に何を確認すれば原因を切り分けられるか」

をGPTと相談して、必要ならそのProject用の診断Toolの概念や設計思想を話したりと。

今回のCinemachine 3への移行では、この使い方がかなり有効でした。

ここからは、実際にGPTとどう調査したか

ここまでは、Cinemachine 3への移行で実際に役立った進め方を書きました。

ここからはもう少し具体的に、

「GPTに何を頼んで、どうやってProject専用の診断Toolを作っていったのか」

を書いてみます。

今回作ったToolのコードを、そのまま全部載せることはしません。

UnityのVersionも、Packageも、Prefabも、ScriptもProjectごとに違うからです。

自分のProjectをAIに調べてもらって、そのProject用のToolを作ってもらう方が実用的

だと考えました。

例えばCinemachineのUpgraderでは

Upgraderの処理を、

GetUpgradables
UpgradeNonPrefabs
UpgradeObjectReferences
DeleteObsoleteComponents

という単位に分けて、どこまで正常に進んだのかを見るToolを作りました。

次はProject内のScriptを横断して、CinemachineFreeLook、m_XAxis、m_YAxis など、Cinemachine 2時代のAPIが残っている場所を調査。

さらに必要になればPrefabを見る。

Nested Prefabを見る。

Overrideを見る。

Cameraを参照している別のComponentまで見る。

最初から全部調べたわけではありません。

一つ確認した結果、次に見る場所が決まっていったという感じです。

前に書いた「Projectをレントゲンで少しずつ撮っていく」という感覚に近いです。

最初にAIへ渡すプロンプト

別のUnity Projectで同じ考え方を使うなら、まずはこのくらいから始められると思います。

Unity Projectで発生している問題を調査したいです。

【環境】
Unity Version：
Package / Version：
対象機能：
関連するScene / Prefab / Script：

【現在の症状】
ここに症状を書く。

【確認済みのこと】
ここに実際に確認できた事実を書く。

【まだ分からないこと】
ここに不明点を書く。


最初から原因を決めつけたり、
修正コードを書いたりしないでください。

まず、

・確認済みの事実
・まだ推測のもの
・現在の原因候補
・次に何を観測すれば原因候補を減らせるか

を分けてください。

必要であれば、
Unity Editor上で実行できる診断Toolを作ってください。

診断Toolは原則Read Onlyとし、
Scene、Prefab、Assetなどを変更しないでください。

変更を伴う検証が必要な場合は、
先に理由と影響範囲を説明してください。

診断結果をこちらから返すので、
その結果を見て次の調査を決めてください。

GPT以外のAIを使っている場合でも、考え方自体は同じだと思います。

これだけでも、AIとのやり取りはかなり変わります。

Read Onlyは結構大事でした

今回作ったAudit系Toolは、できるだけRead Onlyにしました。

調査するためのToolがPrefabを書き換えたり、SceneをDirtyにしたら、調査Tool自身が新しい問題を作る可能性があるからです。

ただし、すべてをRead Onlyにはできません。

UpgraderをStepごとに実行する診断Toolのように、実際のUpgrade処理を呼ぶものもありました。

その場合は、バックアップした検証環境で実行します。

つまり、

「Read Onlyと書いてあるか」ではなく、実際に何をするToolなのかを見る

ということです。

コードより、調べ方を残す

今回作ったToolはGrandis AdventuresのProject用なので、別のProjectへそのまま入れることを想定していません。

でも、完成したコードより、

「何を確認したかったのか」

「何を観測すれば原因候補を減らせるのか」

「そのためにどんなToolを作ったのか」

を残した方が、別のProjectにも応用しやすいと思っています。

Unity開発をしていると、

「何かがおかしい。でも、どこがおかしいのか分からない」場合もあります。

そういう時にAIへ答えだけを求めるのではなく、

「じゃあ、それを確認するToolを作って」

と頼む。

実際のProjectで確認する。

結果をAIに返す。

そこから次に見る場所を決める。

今回のCinemachine 3への移行では、この繰り返しがかなり役に立ちました。
そして個人的には、これがAIを開発に使う上でかなり面白い部分だと思っています。

今回使った基本メソッド

症状を確認する
↓
事実と推測を分ける
↓
次に何を観測すれば原因候補を減らせるか決める
↓
必要なら専用の診断Toolを作る
↓
実Projectで観測する
↓
結果をAIへ戻す
↓
否定できた候補を捨てる
↓
次の観測へ進む
↓
原因が絞れてから最小修正する

短くすると、こんな感じです。

この先では、実Script ZIPファイルと今回実際にProjectで使った考え方を、そのままお使いのAIへ渡せる形にまとめています。