GitHub CopilotがSlack・Teamsで複数リポジトリに対応。進捗確認の頼み方

この記事でわかること

• 新しい対応：複数リポジトリのPRや活動を会話の中で確認できます。
• 依頼の組み立て：対象・期間・状態・根拠リンクを指定します。
• 実務上の確認：要約を進捗の確定情報にする前に、元のPRを見ます。

何が新しくなった？

GitHubの更新案内は、複数リポジトリをまたぐオープン中のプルリクエスト（PR）の確認や、画面側とサーバー側にまたがる問題の調査を、一つの会話で依頼する例を紹介しています。PRは、コードの変更を確認して取り込むための単位です。

@GitHubをメッセージの途中で使うことや、会話中のリポジトリ切り替えも改善されています。ただし、複数の場所を見られることと、アクセスできない場所の情報まで取得できることは別です。既存の権限を越える機能として扱わないでください。

週次確認は「対象・期間・状態」から始める

「今週どう？」を、確認可能な依頼に変える

たとえば、予約サービスの画面とサーバーを別々に管理しているとします。週次会議前に欲しいのは、変更の全件一覧ではなく、公開予定に影響するレビュー待ちと、すでに取り込まれた変更です。この場合は、二つのリポジトリ名、集計する日付、確認したい状態を指定します。

依頼文にするなら、「指定した2リポジトリの対象期間を確認し、取り込み済みとレビュー待ちを分け、各項目にPRリンクを付けてください。閲覧できない対象は未確認とし、コード変更やPR作成は行わないでください」のようにします。これは説明用の依頼例であり、実行結果ではありません。

PRが取り込まれたことと、利用者に届いたことを分ける

マージ済みのPRが、そのまま本番公開済みとは限りません。リリース作業、機能フラグ、確認待ちなど、チームごとの工程が残る場合があります。AIの要約を会議資料へ移すときは、「コードへ取り込み済み」「公開予定」「本番確認済み」を混ぜないようにします。

たとえばAIが「予約機能を改善」とまとめても、それが画面の文言修正なのか、予約処理の不具合修正なのかでは、関係者への伝え方が変わります。PRの目的と、影響する画面・業務を一段確認してから説明しましょう。

導入条件と会話の範囲を確認する

公式の連携資料では有料Copilotプランが対象とされ、連携ごとの追加条件もあります。SlackのガイドではGitHubアプリとアカウント接続が必要です。組織ではCopilot in the cloudのポリシーを確認します。cloud sandboxを別途許可する設定は不要です。セッションを開始するには、選択したリポジトリへの書き込み権限も必要です。

連携では会話のスレッド全体が文脈として使われるため、別案件の相談や不要な情報が混ざった長いスレッドをそのまま渡すより、対象案件の確認用スレッドを分けると依頼の意図を保ちやすくなります。途中で方針が変わった場合も、最新の確認範囲を明示します。

Copilotの利用可否が契約と管理ポリシーに分かれる考え方は、GitHub Copilotの対象プランと管理設定の記事でも説明しています。個別モデルの条件と、今回の連携機能の条件は分けて見てください。

実務上の注意

Slack・Teams連携は2026年11月6日に一般提供が発表されました。個別アカウントでの利用可否や画面操作は本記事では検証していません。進捗を確認する依頼と、コードを書き換える依頼は分けましょう。出力に見当たらないPRを「存在しない」と決めず、対象範囲と閲覧権限を確認します。

まとめ

複数リポジトリ対応で、進捗を一つの会話に集めやすくなります。対象・期間・状態・根拠リンクを指定し、マージと公開を区別して読めば、週次会議やレビュー待ち確認に使いやすくなります。

よくある質問

出典・参考情報

• GitHub：複数リポジトリ対応の更新
• GitHub Docs：Copilot integrations
• GitHub Docs：Slack連携