プログラミングやテストへ入る前に
GitHub Copilotにソースコードやテストコードを効率的に実装してもらうためには、事前の準備が重要です。
この章では、実装を依頼する前に準備すべきドキュメントの種類や、AIへの指示の方針について説明します。
AIのオンボーディングでは、AIをプロジェクトに迎え入れ、期待に近い振る舞いをさせるためにインストラクションファイルを使ってプロジェクトの共通知識を教え込む必要があることを説明しました。
ここでは次のステップとして、共通知識を持ったAIに対して個別の機能やテストの実装を指示する方法を解説します。
ただし、レビューについては観点別にレビューを実施するを参照してください。
AIへタスクに必要な情報を与える
GitHub Copilotにソースコードやテストコードを実装してもらうためには、どのようなものを作成して欲しいのかを明確に指示する必要があります。そのために、以下のような設計情報などをインプットします。
- 設計書： 実装したい機能の仕様が書かれたドキュメント
- テスト仕様書： 実施したいテストの内容が書かれたドキュメント
- その他関連ドキュメント： テーブル定義や外部インターフェースの仕様など、機能横断で参照される情報
これらの情報は、AIが最も理解しやすいMarkdown形式で渡すことが推奨されます。情報をAIに渡すことは、一般的に「コンテキストに追加する」と呼ばれます。
指示（プロンプト）の標準化と使い分け
ソースコード作成やテストコード作成といった定型的なタスクでは、指示（プロンプト）をプロンプトファイルとして共通化することが有効です。
これにより、開発者ごとの指示の品質のばらつきを防ぎ、AIから安定して質の高い結果を引き出せるでしょう。
一方で、GitHub Copilotとのすべての対話をプロンプトファイルにする必要はありません。
例えば、生成されたコードに対する微修正やフィードバックは、その場限りの使い捨てプロンプトで行うのが効率的です。AIは会話の文脈を記憶しているため、都度すべての情報を与え直す必要はありません。
タスクの性質に応じて、共通化されたプロンプトファイルと、アドホックなプロンプトを使い分けましょう。
継続的な改善
インストラクションファイルやプロンプトファイルは、一度作成したら終わりではありません。
開発を進める中で、「この指示は毎回使っている」「この情報を加えたらより精度が上がった」といった発見があるでしょう。
そうした知見を随時ファイルに反映させてAIにフィードバックしていくことが、生産性をより向上させるポイントとなります。
本ガイドでは、多くのプロジェクトで一般的に使用されているOfficeドキュメントで設計書やテスト仕様書が作成されていることを想定しています。
そのため、GitHub Copilotに情報を与える際には、これらのドキュメントをAIが理解しやすいMarkdown形式に変換することを推奨しています。
この変換作業は、一見すると追加の工数に思えるでしょう。
しかし、これはAIにプロジェクトのコンテキストを正確に伝え、期待する成果を得るために必要な作業です。この一手間が、結果として開発全体の生産性向上につながるでしょう。
将来的には、開発プロセス全体でAIの活用を前提とし、設計工程からAIフレンドリーなドキュメントを作成することが理想形です。
本ガイドではまず製造および単体テスト工程を対象としているため、現行プロセスへの影響を最小限に抑えつつAI活用の第一歩を踏み出し、効果を実感していくことを目指しています。
もちろんすでにドキュメントをMarkdown形式で作成しているなど、AIが直接利用できる形式であればこの変換作業は不要です。
📄️ 実装例をプロンプトに含める
開発者がソースコードを作成するには、手本となるサンプルコードが必要です。
📄️ 観点別にレビューを実施する
GitHub Copilotはコードレビューにおいても有用です。しかし、その能力を最大限に引き出すためには、レビューを依頼する方法、特に「レビュー観点の与え方」に工夫が求められます。