Slackの会話がそのままPRに—Copilot導入前の権限設計

GitHubは2026年8月21日、Slackの会話からCopilot cloud agentへ問題調査、コード変更、検証、プルリクエスト（PR）作成を依頼できる連携をパブリックプレビューとして公開した。8月21日の公式発表 では、SlackのDM、チャンネル、スレッドで「@GitHub」とメンションすると、許可されたGitHub上の情報と会話を基に非同期の作業セッションを開始できるとしている。

この8月21日開始のプレビューで、会話からPRまでを一続きにできる一方、会話だけで変更が自動的にマージされるわけではない。TechTargetジャパンの報道 も、既存のCopilot利用枠を消費すること、成果物にCopilotアプリのIDが記録されること、マージ前に追加承認を要求できることを伝えており、導入前の焦点は会話データ、実行主体、write権限、PRルールの設計になる。

「会話がPRになる」の正確な範囲

Slackから依頼できるのは、コードやGitHub上の活動に関する質問、バグ報告の切り分け、Issueの作成・更新、障害調査、コード変更、検証、PR作成だ。Copilot cloud agentは安全なクラウドサンドボックスで非同期に作業し、完了すると変更内容の概要とGitHub上の成果物へのリンクをSlackへ返す。

したがって、タイトルの「会話がそのままPRに」とは、スレッドで合意した内容を改めて別のプロンプトへ書き直さなくても、会話を作業文脈としてコード変更とPRへ引き継げるという意味だ。差分の妥当性、テスト結果、必須チェック、承認、マージは、引き続き対象リポジトリの権限とルールに従う。

作業用にはタスク専用の「Slack Code」チャンネルが作られる。参加者は対象リポジトリ、ブランチ、進行状況、IssueやPRへのリンクを確認し、追加情報の提供、方針変更、停止を行える。コードチャンネルは1タスクにつき1セッションを扱い、終了後にアーカイブしても履歴は閲覧・検索できる。

DMと共有スレッドで変わる実行主体

GitHubの現行設定文書 は、スレッド全体が作業文脈となって生成物に保存されること、DMでは連携した個人アカウントの権限、共有スレッドやチャンネルではCopilotアプリの主体が使われることを明記している。変更を開始する利用者には対象リポジトリのwrite権限が必要で、Slackのゲストとリポジトリのoutside collaboratorはセッションを開始・誘導できない。なお、8月21日の発表はCopilot BusinessとEnterpriseの組織を対象としていたが、現行文書は全ての有料Copilotプランを対象と記載しており、公開時点から案内範囲が変わっている。

共有スレッドでは、最後の依頼文だけでなく全メッセージが判断材料になる。顧客情報、認証情報、未公開の障害情報、作業と無関係な会話が混在していれば、それらも文脈へ入るため、Copilotを呼び出す前にスレッドの内容と参加範囲を確認する必要がある。

文脈を限定したい場合は、GitHubアプリとのDMを使うか、対象タスク専用の新しいスレッドを作る。ただし、DMへ移せば実行主体は個人アカウントになる。情報を見せる範囲と、IssueやPRを誰の主体で作成するかは、別の管理項目として決めなければならない。

write権限を持つ参加者が変更を開始した後は、権限要件を満たす他の会話参加者も情報を追加して作業を誘導できる。開始者と途中で指示した人物が異なる場合に備え、Slackの会話とPR上の変更理由を監査できる状態にしておくことが重要だ。

設定はリポジトリの到達範囲から固める

プロンプトにリポジトリ名を書くことは宛先の指定であり、アクセス制御ではない。企業所有のリポジトリでは、管理者がSlack向けGitHubアプリをインストールし、アプリから到達できるリポジトリを指定する。その範囲と利用者本人のwrite権限が重なった場所で、コード変更を開始できる。

導入時は、次の順序で依存関係を確認すると整理しやすい。

1. 対象となるCopilotプランを確認し、組織またはEnterpriseのポリシーでCopilot cloud agentとクラウドサンドボックスを有効にする。
2. Slack向けGitHubアプリをインストールまたは更新し、アクセス先を必要なリポジトリに限定する。
3. 利用者のSlackアカウントとGitHubアカウントを接続し、対象リポジトリのwrite権限を持つ人を確認する。
4. 共有チャンネルごとに既定リポジトリを設定し、最初のセッションで意図せず既定値が決まるのを防ぐ。
5. Copilotアプリ名義のPRに適用されるruleset、必須チェック、CODEOWNERS、承認要件を確認する。

プレビュー段階では、まず低リスクのリポジトリだけをアプリの対象にする設計が妥当だ。これは必須仕様ではなく段階導入の判断だが、アクセス範囲、利用者権限、チャンネル設定のどこに問題があるかを切り分けやすくなる。

既定リポジトリは権限境界ではない

チャンネルに既定リポジトリが設定されていない場合、最初のセッションで使ったリポジトリが既定値になる。以後、依頼時にリポジトリやブランチを指定しなければ、その既定リポジトリとデフォルトブランチが使われる。DMにはチャンネル用の既定リポジトリを設定できない。

既定値は同じチャンネルの利用者で共有され、変更すると全員に影響する。複数の製品や障害を扱う横断チャンネルでは、会話の対象と既定値が食い違う可能性があるため、コード変更を頼む際はowner、repository、対象ブランチを明記し、作成されたPRの宛先も確認したい。

クラウドサンドボックスは、Copilotが利用者の端末ではなく隔離されたクラウド環境で変更と検証を進める実行場所だ。ただし、サンドボックスを有効にしてもリポジトリへのアクセス範囲やマージ条件は変わらない。

制御は三層に分かれる。GitHubアプリのインストール範囲が到達可能なリポジトリを決め、利用者のwrite権限が変更を開始できる人を決め、チャンネルの既定値と依頼文が実際の宛先を決める。一つの設定だけで他の役割を代替することはできない。

アプリ名義のPRに追加承認を残す

共有コンテキストから作成されたPRは、依頼者個人ではなくCopilotアプリに帰属する。リポジトリのrulesetが既に1件以上の承認を要求している場合、人に帰属しないCopilotのPRには、マージ前にもう1件の承認を必要とする設定が既定で有効になる。

この条件は、既存の承認要件がないリポジトリへ自動的に人間のレビューを追加する仕組みではない。導入担当者は、対象ブランチのrulesetに少なくとも1件の承認が設定されているか、Copilotアプリ名義のPRに追加承認が適用されるかを実際の設定画面で確認する必要がある。

追加承認だけで変更の妥当性が保証されるわけでもない。レビューでは対象ブランチ、変更ファイル、テスト結果、必須ステータスチェックに加え、Slackの会話から渡された要件とPRの差分が一致しているかを確認する。

この連携は現在も正式提供ではなくパブリックプレビューで、仕様変更の対象となる。導入判断ではプラン名だけに依存せず、管理画面で利用可能なポリシーと対象リポジトリを確認する必要がある。今後の焦点は、正式提供の時期、対象プランと利用枠の最終条件、会話コンテキストやSlack Code履歴の運用条件がどう定まるかだ。