テクノロジーに追従する覚悟
日本人は「温故知新」が好きすぎて、テクノロジーに追従する覚悟が足りていないと常々感じています。
温故知新は政治における意思決定の話で、時間をかけても正確に判断するための方法論です。
つまり、ビジネスシーンのように迅速さが求められるシーンでは全く無用の考え方です。
そんなわけで最近リリースされて、Visual Studioを開くたびに気になっていたGitHub Copilotについて、30日間の試用を開始しました。
公式のベストプラクティス
どういったシーンに適しているのか、公式のドキュメントに記載があります。
Copilot が最適な場合の一部を次に示します。
- テストと繰り返しコードの記述
- デバッグと構文の修正
- コードの説明とコメント
- 正規表現の生成
Copilot は次の場合には適していません。
- コーディングとテクノロジに関係のないプロンプトに対応する
- 専門知識やスキルを更新する。 自分自身が責任者であって、Copilot はサービスの強力なツールであることを忘れないでください。
プロンプトエンジニアリング
どういうプロンプトを書いたら良いかも、公式のドキュメントが分かりやすいです。
プロンプト エンジニアリング、つまり Copilot が簡単に理解して対応できるように要求を構造化することは、Copilot が価値のある応答を生成する能力において重要な役割を果たします。 プロンプトを作成するときに覚えておく必要があるいくつかの簡単なヒントを次に示します。
- 複雑なタスクを分割する。
- 要件について具体化する。
- 入力データ、出力、実装などの例を提供する。
- 適切なコーディング プラクティスに従う。
GitHub Copilotならではの機能
プロンプトエンジニアリングのドキュメント内に、下記の記述がありました。
Copilot をより価値のある応答に導くために、次のようないくつかの調整を行うことができます。
- Copilot に役立つコンテキストを次のように指定します。
- IDE で Copilot を使用している場合は、関連するファイルを開き、無関係なファイルを閉じます。
- Copilot Chat では、特定の要求が有用なコンテキストでなくなった場合は、その要求を会話から削除します。 または、特定の会話のどのコンテキストも役に立たない場合は、新しい会話を開始します。
- Copilot Chat in GitHub を使用している場合は、特定のリポジトリ、ファイル、シンボルなどをコンテキストとして指定します。 「Asking GitHub Copilot questions in GitHub」を参照してください。
- IDE で Copilot Chat を使用している場合は、キーワードを使用して、Copilot を特定のタスクまたはコンテキストにフォーカスします。 「IDE で GitHub Copilot に質問する」を参照してください。
つまり、Visual StudioのようなIDE内で開いているファイルは関連ファイルとして、応答の生成にしようされるようです。
このあたりの使い勝手が、メッセージのみでやり取りするChat GPTとは大きく異なりますね。
ちょっとだけ触ってみた
Chat GPTでなかなか解決しなかったバグについて質問したところ、バグが解消されました。
このバグは異なるプログラムモジュール間の受け渡しが焦点だろうと思っていたので、Chat GPTではプログラム構造を正しく理解できない為、解決できなかったんですよね。
「#プログラム名.cs」のように指示することで、コードをコピーせずともプロンプトを書けるので、素晴らしい。関数名まで指定しなくても、文脈である程度バグの症状を理解してくれます。
しかし、エラー出力まではウォッチしていないようで、バグが出た際のエラーメッセージはプロンプト生成に寄与していないようでした。
エラー解決が殆どの用途だと思うので、ここはどうにかして欲しい。
まとめ
バグに対する解像感はChatGPT 4.0oの方が上回っているように感じました。
しかし、プロンプト生成の負荷は下がっているように思います。
まだ触り始めたばかりなので、このブログでもフィードバックしていきます。