UnityでGitHub Copilotを使用するための5つのヒント
UnityのAIツールがベータ版として利用可能になったことで、エディター内のAIアシスタントや人気の開発者ツールとの統合といった新機能に大きな期待が寄せられています。ベータ版を初めて使用する場合は、AIツールのウェブページで詳細を確認できます。また、そのコア機能を使い始めるのに役立つビデオチュートリアルシリーズを作成しました。
ゲーム開発のワークフローを最適化するために、GitHub CopilotとUnityをどのように利用しているのか、ステイシー・ハフナー氏に話を聞いた。Stacey氏はマイクロソフトの元プリンシパル開発者アドボケートであり、独立系ゲーム開発者として10年以上の経験を有するYouTuberです。NET、Xbox、Unityにわたるクリエイターテクノロジーの背景。開発者のアドボカシーをしていないときは、自身のインディーズスタジオを運営し、隔週でゲーム開発のチュートリアルを公開しています。
飛び込んでみましょう。
ヒント 1：ウィンドウに対してではなく、コンテキストウィンドウに対して操作する
「ウィンドウは、制限のあるセッションに対するAIの作業メモリです。使用している基本モデルによっては、限界に達する前にパフォーマンスの低下を開始できるため、セッションが進むにつれて応答の精度が低下する可能性があります。GitHubHub Copilotはセッションを圧縮できるようにすることでこれを支援しますが、基になるモデルがすでに劣化し始めた後に圧縮をトリガーすると、劣化した状態が新しいベースラインになります。だからこそ、開始からこの上限を中心にワークフローを構造化しておくことをおすすめします」
「より複雑な機能については、メインのチャットスレッドを使用してその作業を調整しています。大きな特徴としては、メインスレッドに作業を集中したチャンクに分割させてから、それぞれをハンドルする背景エージェントを開始させます。コーディングエージェントが実装を処理し、検証エージェントがレビューを行います。レビューに合格すると、特徴付けが完了するまでこのサイクルが繰り返されます。各エージェントは独自のコンテキストで動作するため、メインスレッドは集中力を維持し、より長い時間安定して動作します」
ヒント 2：プロジェクト環境の設定
「GitHub Copilotのベースとなるモデルは一般的にジェネラリストですが、プロジェクト内の.GitHubフォルダーに構成ファイルを追加することでCopilotの動作をカスタマイズできます。GitHubHub Copilotがプロジェクトとドメインを理解するのにヘルプつ3つの主なファイルタイプを追加できます」
- カスタムインストラクションは、Copilotがプロジェクトのベースラインを定義するすべてのセッションで読み込む常時接続のコンテキストです。これらには、好みのコーディング規約、Unityプロジェクトの仕様（Unityエンジンのバージョンやレンダーパイプライン例えば アーキアーキテクチャります。プロジェクトのどの部分に取り組んでいるかに関係なく、常に真であるべきものにこれらを使用してください。
- エージェントは、各ドメインの専門家のペルソナであり、それぞれに専用のツールと手順があります。シェーダー、UI Toolkit、ゲームシステムなどを中心としたエージェントを持っています。最も単純なものでは、目の前の作業にマッチするエージェントを選択しますが、エージェント間のハンドオフを含めることで、より構造体を追加できます。
- スキルは、特定のタスクがトリガーしたときにのみロードされる、モジュール化された再利用可能な命令です。スキルの説明はすべてのセッションでロードされるため、モデルはいつ呼び出すべきかを把握できます。しかし、完全な詳細情報は実際に必要なときだけロードされます。例えば、私のUI Toolkitエージェントは、スタイル設定、UXML記述、および関連するタスクについて、必要なものに応じて個々のスキルを呼び出します。これにより、モデルのメモリコンテキストがタスク間で効率的に保たれます。
ヒント 3：優れたプランは長い道のりを
「プランモードは、あらゆる実装が始まる前の最初のステップです。/planコマンドに続いて特定の命令を使用すると、GitHub Copilotはコードベースを通じて理由を示し、1行のコードを書く前に実装パスをマップするように要求します。
特徴や修正箇所をできるだけ関連のある詳細に記載してください。その後、Copilotに調査を依頼し、質問を添えて返送してください。エクスチェンジは、エッジケースが表面化することが多い、ユーザーエクスペリエンスと機能についてより詳細に考えるためのヘルプになります。その繰り返しが終われば、AIに、どのような既存のシステムを使用するか、どのような新しいクラスやメソッドを作成する必要があるか、そしてそれらがどのように組み合わされるかなど、実装の大まかなストロークを定義させます。そのときだけ、コードを書くようにさせるべきです」
ヒント 4：コードレビューをスキップしない
「AIが生成するコードは、特にプロジェクトに長期間留まるコードの場合はレビューが必要です。実装が戻ったら、プルリクリクエストのように扱い、最後まで読むべきです」
「VSコードがエージェントウィンドウを出荷する前に、これに対するいくつかの異なるアプローチを試しましたが、今ではそれを最もよく使用しています。特定のコードをハイライトして 、 / Explainコマンドを使ってAIに動作を説明させたり 、 / コマンドを使って、今書いたコードを批評させたりすることができます。そこから実際のプルリクリクエストのように、差分に直接インラインコメントを追加して、グループとしてAIに送り返し、反復処理を行います」
「この習慣が重要なのは、コードが私の標準に保たれ、システムに対する深い理解が確実に維持されるからです。その知識は、ゲームが成長するにつれて、正しい設計上の決定を下すのに役立ちます」
ヒント 5：AIを個人講師として活用
「GitHub Copilotを使用して、学習したいUnityの概念に合わせてカスタムチュートリアルを作成できます。GitHub Copilotはプロジェクトを読むことができるので、ゲームのニーズとスキルレベルに合わせてレッスンをカスタマイズするよう依頼できます」
「シェーダーをずっと学びたかったので、ティーチングに一生懸命傾けるUnity Shader Graphエージェントを作り、それを使って戦闘用の地上照準オーバーレイを作りました。よくわからない概念に遭遇したときは、質問することができ、準備ができて初めて次のステップに進むことができた」
「時間をかけて独立性をビルドする一連のレッスンを使用することが重要です。例えば、最初の2つのシェーダーのガイド付きチュートリアルを提供するように依頼しました。見慣れないノードと数学を解説してくれたので、各シェーダーの動作が実際に理解できました。3つ目のシェーダーは自分でビルドしたかったので、行き詰まったときは答えではなくヒントだけを求めました。次のステップを見極めるための指針となる質問をいくつかいただきました。そのまま進めました。そのプロセスが終わる頃には、自分が何を作ったのかが実際に理解できました」
