Tips - 普段業務でCopilotを使ってみる

GitHub Copilotに、開発プロセスを効率化する新しい機能が追加されました。今回は、Issue作成・更新機能とプルリクエスト要約機能について、実務での活用を想定しながら解説します。

1. Issue作成・更新機能の概要

この機能の利用条件：GitHub Copilotライセンスを持つユーザーが対象です。現在、パブリックプレビュー段階のため、仕様が変更される可能性があります。

1.1 基本的な使い方

GitHub Copilot Chat（https://github.com/copilot）から自然言語でIssueを作成できるようになりました。これまで手作業で入力していたタイトル、本文、ラベル、担当者などを、Copilotが自動的に提案します。

例：octo-org/octo-repo に、検索機能にファジーマッチングを追加する
機能リクエストを作成してください

リポジトリを指定する際は owner/repository の形式を使用します。指定しない場合、最後にIssueを作成したリポジトリが対象になります。

重要な制約：この機能は既存の権限設定を変更しません。ユーザーがすでにIssue作成権限を持っているリポジトリでのみ使用できます。

1.2 画像からのIssue作成

スクリーンショットをアップロードして、そこからIssueを作成することも可能です。エラー画面や不具合の状況を画像で共有し、テキストで補足説明を加えるだけで構造化されたIssueが生成されます。

画像の追加方法は以下の3つです：

• コピー&ペーストで貼り付け
• プロンプトボックスの画像アイコンからファイルを選択
• ドラッグ&ドロップ

画像をアップロード後、テキストでの説明を追加できます（例：「パスワードリセット時にこのエラーが表示されるため、Issueを作成」）。

1.3 Issue FormとTemplateへの対応

リポジトリにIssue FormやTemplateが設定されている場合、Copilotは適切なフォームを選択し、プロンプトの内容を各フィールドに振り分けます。情報が不足しているフィールドがあれば、追加のコンテキストを求めてきます。

フォームやテンプレートを途中で変更しても、入力した情報は失われません。Copilotが自動的に新しい形式に合わせて再フォーマットします。

2. 複数Issue・サブIssueの作成

2.1 一括作成

プロンプトに複数のタスクやバグを含めると、Copilotは複数のIssueドラフトを同時に生成します。

例：owner/repository に3つのIssueを作成：
1) ログイン機能のバリデーション強化
2) エラーメッセージの多言語対応
3) レスポンスタイムの計測機能追加

各ドラフトは個別に表示され、それぞれレビュー・編集してから作成できます。

2.2 サブIssueの構造化

大きな機能開発を計画する際、エピックとサブIssueの階層構造を作成できます。

例：octo-org/octo-repo に新しいユーザーダッシュボードを計画。
エピックに分解し、主要な機能とタスクごとにサブIssueを作成してください

Copilotは親Issueとサブ-Issueのツリー構造を生成します。各Issueは個別に編集可能で、ワークベンチで詳細を確認できます。

親Issueをクリックすると、ワークベンチでその詳細が表示され、サブIssueのリストも確認できます。各サブIssueをクリックして詳細を編集することも可能で、サブIssueから「Parent」ドロップダウンを使ってIssue tree内を移動できます。ワークベンチ上部の「Review and create」をクリックすると、全体のIssue treeを表示し、任意のIssueに直接移動できます。

Issue tree内の操作も柔軟です：

# サブIssueをツリーから削除
Issue tree から「認証機能強化」のサブIssueを削除

# サブIssueをツリーに追加
Issue tree に「パフォーマンス最適化」の詳細を含む
追加のサブIssueを追加

すべての編集が完了し、Issueを公開する準備ができたら、「Review and create」をクリックし、その後「Create issues」をクリックします。

3. 既存Issueの更新と連携

3.1 Issueの更新

既存のIssueに対しても、自然言語で更新を指示できます。

例：octo-org/octo-repo の Issue #123 を更新し、バグの詳細と
再現手順を追加。ラベルを「bug」に変更し、@yamada に割り当て

既存Issueとの紐付け

すでにリポジトリ内に存在するIssueと新しいIssueを関連付けることもできます。

# 既存の親IssueにサブIssueを追加
octo-org/octo-repo の Issue #456 のサブIssueを作成

# 既存のIssueに親Issueを作成
octo-org/octo-repo の Issue #456 の親Issueを作成

# 複数の既存Issueに親Issueを作成
octo-org/octo-repo の Issue #456、#457、#458 の親Issueを作成

ドラフトがワークベンチに表示されるので、レビュー・編集できます。Issueを公開するには、「Review and create」をクリックし、その後「Create issues」をクリックします。

4. CopilotへのIssue割り当て

Copilot coding agentが有効になっている場合、Issueを直接Copilotに割り当てることができます。

割り当て方法は2つです：

1. 自然言語: 「このIssueをCopilotに割り当て」とプロンプト
2. 手動選択: 担当者リストから「Copilot」を選択

Issueが作成されると、Copilotは自動的に作業を開始します。Issue上に👀の絵文字リアクションが表示され、Copilotが作業中であることがわかります。

5. プルリクエスト要約機能

5.1 利用条件と基本概要

PRの説明文やコメントとして、変更内容の要約を自動生成できます。レビュアーにとっては変更の全体像を把握しやすくなり、作成者にとっては説明文を書く時間を短縮できます。

重要：この機能はGitHub Copilot Freeでは利用できません。

また、GitHub Copilotは既存のPR説明文を考慮しないため、空白の説明文から始めるのが最適です。

5.2 要約の生成手順

1. 新規PRを作成するか、既存のPRに移動
2. テキストフィールドに移動
   • 新規PR: "Add a description"フィールド
   • 既存PR: 冒頭のコメントを編集
   • コメントとして追加: ページ下部の"Add a comment"セクション
3. テキストフィールドのヘッダーにあるアイコンをクリックし、"Summary"を選択
4. Copilotが要約を生成するまで待機
5. 結果を注意深く確認
6. 必要に応じて追加のコンテキストを記述
7. 満足できる内容になったら、"Create pull request"または"Update comment"をクリック

5.3 フィードバックの提供

生成された要約の品質について、エンタープライズや組織の設定によってはフィードバックを提供できます。テキストボックスの下に表示される"How did Copilot perform?"のボタンから評価できます。

要約を「良い」または「悪い」と評価した後、表示されるリンクをクリックすることで、さらに詳細なフィードバックを記述することも可能です。

6. 実務での活用ポイント

6.1 Issue作成の効率化

従来のIssue作成では、フォームの各フィールドを埋めるために、何度も入力欄を行き来する必要がありました。Copilotを使えば、一度のプロンプトで必要な情報がほぼ揃った状態のドラフトが生成されます。

特に、リポジトリのIssue Formが複雑な場合や、複数のIssueを作成する必要がある場合に効果を発揮します。

6.2 PR要約による情報共有の改善

変更内容が多岐にわたるPRでは、レビュアーが全体像を把握するのに時間がかかります。Copilotが生成する要約は、変更の主要なポイントを簡潔にまとめるため、レビューの開始点として有効です。

ただし、要約はあくまで出発点です。プロジェクト固有の文脈や、変更の背景となった議論などは、適宜手動で補足する必要があります。

7. GitHub CLI Copilot拡張機能の変更

従来のGitHub CLI用Copilot拡張機能は廃止され、新しい「GitHub Copilot CLI」に置き換えられました。CLI環境での作業フローに影響がある場合は、新しいCLIツールへの移行を検討してください。

8. まとめ

これらの機能は、開発プロセスの定型作業を効率化するものです。特に以下のシーンで効果が期待できます：

• 大量のIssueを整理・作成する必要がある場合
• 複雑な機能開発をサブタスクに分解する場合
• PRのレビューに時間がかかっている場合
• チーム内でのIssue記述の品質を標準化したい場合

ただし、生成された内容は必ず確認し、プロジェクトの文脈に合わせて調整することが重要です。Copilotは効率化のツールであり、最終的な判断は開発者が行う必要があります。

実際の開発フローに組み込む際は、チーム内でガイドラインを設定し、どの程度Copilotの提案を活用するか、どのような場合に手動での編集が必要かを明確にしておくことをお勧めします。