Github Copilot Agentモード使用経験共有

本稿はGitHub Copilot Agentモードの使用方法をまとめ、実際の操作経験を共有します。

事前設定

1. VSCode Insiderを使用する；
2. GitHub Copilot（プレビュー版）プラグインをインストールする；
3. Claude 3.7 Sonnet（プレビュー版）モデルを選択する。このモデルはコード作成において優れた性能を発揮し、他のモデルは速度、マルチモーダル（画像認識等）、推論能力において優位性を持つ；
4. 作業モードはAgentを選択する。

操作手順

1. 「Copilot Edits」タブを開く；
2. 「Codebase」、「Get Errors」、「Terminal Last Commands」等の添付ファイルを追加する；
3. 「Working Set」ファイルを追加する。デフォルトで現在開いているファイルが含まれるが、手動で他のファイル（例：「Open Editors」）を選択可能；
4. 「Instructions」を追加し、Copilot Agentに特に注意してもらいたいプロンプトを入力する；
5. 「Send」ボタンをクリックして対話開始し、Agentの動作を観察する。

その他の説明

• VSCodeは言語プラグインが提供するlint機能によりErrorやWarningを生成でき、Agentはこれらのヒントに基づいてコードを自動修正できる。
• 対話が深まるにつれ、Agentが生成するコード修正が期待から逸脱する可能性がある。各セッションは明確なテーマに集中し、対話を長くしすぎず、短期目標達成後は現在のセッションを終了し、新しいタスクを開始することを推奨する。
• 「Working Set」の「Add Files」には「Related Files」オプションがあり、関連ファイルを推奨できる。
• 単一コードファイルの行数を制御し、token消費が過速になるのを防ぐ必要がある。
• 基礎コードを先に生成し、次にテストケースを作成することで、Agentがテスト結果に基づいてデバッグと自己検証を行うことが推奨される。
• 修正範囲を制限するには、settings.jsonに以下設定を追加し、指定ディレクトリ内のファイルのみを修正するようにする。参考までに：

 "github.copilot.chat.codeGeneration.instructions": [
        {
            "text": "指定された ./script/ ディレクトリ内のファイルのみを修正し、他のディレクトリのファイルは修正しない."
        },
        {
            "text": "コードファイルの行数が1000行を超える場合、新しい関数は新しいファイルに置き、参照呼び出しを行う。修正によりファイルが長くなる場合は、この規則を厳密に守らなくてもよい."
        }
    ],
    "github.copilot.chat.testGeneration.instructions": [
        {
            "text": "既存の単体テストファイルにテストケースを生成する."
        },
        {
            "text": "コード修正後は必ずテストケースを実行して検証する."
        }
    ],

よくある質問

入力した要件で望む業務コードが得られない

大きなタスクを小さなタスクに分割し、各会話で小さなタスクのみを処理する必要がある。これは大規模モデルのコンテキストが多すぎると注意力が散漫になるためである。

単回対話に与えるコンテキストは、自身で推測する必要がある。多すぎても少なすぎても要件を理解できない原因となる。

DeepSeekモデルは注意力散漫問題を解決したが、cursorでDeepseek APIを使用する必要がある。その効果は不明である。

応答が遅い問題

token消費メカニズムを理解する必要がある。token入力は安価で時間も短く、token出力は高価で、明らかに遅くなる。

あるコードファイルが非常に大きく、実際に修正が必要なコード行が3行だけでも、コンテキストが多いと出力も増えるため、token消費が急速に進み、応答が遅くなる。

そのため、ファイルサイズを制御し、大きなファイルや大きな関数を書かないことが必須である。大ファイルや大関数は適宜分割し、参照呼び出しを行うことが望ましい。

業務理解問題

問題理解はコード内のコメントやテストファイルに依存する可能性がある。コードに十分なコメントとテストケースを補足することで、Copilot Agentの業務理解が向上する。

Agentが自ら生成した業務コードには十分なコメントがあり、これらのコメントを検証することで、Agentが要件を正しく理解しているかを迅速に判断できる。

大量コード生成によるデバッグ時間の長さ

特定機能の基礎コード生成後、まずテストケースを生成し、その後業務ロジックを調整することで、Agentが自らデバッグと自己検証を行うことが可能になる。

Agentはテストコマンド実行を許可するか尋ね、実行後はターミナル出力を読み取り、コードが正しいか判断する。正しくなければエラーメッセージに基づき修正し、テストが通るまで繰り返す。

つまり、自身が業務をより深く理解する必要があるが、手動で書く必要はそれほど多くない。テストケースコードと業務コードが両方とも間違っている場合、Agentは業務から正しいテストケースを書けず、テストケースから正しい業務コードも書けないため、デバッグ時間が長くなる可能性がある。

まとめ

大規模モデルのtoken消費メカニズムを理解する。入力コンテキストは安価で、出力コードは高価であり、修正不要のコード部分も出力としてカウントされる可能性がある。証拠は修正不要のコードもゆっくりと出力されることである。

そのため、単一ファイルのサイズをなるべく制御する必要がある。使用中にAgentが大ファイルと小ファイルを処理する際の応答速度の差を体感すれば、この差は非常に顕著であることがわかる。

• ←前へ
• 次へ→