GitHub Copilot Slack連携 - SlackからGitHub Copilotに開発を頼める。DMは本人の権限、チャンネルはアプリ名義 anchor left anchor right

Aug 22 2026 AIニュース

SlackからGitHub Copilotに開発を頼める。DMは本人の権限、チャンネルはアプリ名義

anchor left anchor right

GitHub Copilot Slack連携は、Slack上で@GitHubをメンションするとCopilotのエージェントセッションが始まる機能です。

📖 この記事で分かること

  • Slackの@GitHubでエージェントが動くようになった
  • DMと共有チャンネルで成果物の名義が変わる
  • スレッド全体が文脈として成果物に保存される
  • 対象プランの記載がチェンジログと文書で異なる

💡 知っておきたい用語

  • アプリ名義(app identity): 個人アカウントではなく、連携アプリそのものの名前で作業記録が残る状態。誰の判断かではなく「アプリがやった」として履歴に残る

最終更新日: 2026年8月22日

▶ 公式ページ

GitHub Copilot Slack連携 - SlackからGitHub Copilotに開発を頼める。DMは本人の権限、チャンネルはアプリ名義

SlackのGitHub連携でCopilotが動き出した

この記事のポイント

  • GitHubが2026年8月21日、Slack上のGitHub連携にGitHub Copilotのエージェント機能を追加し公開プレビューを開始しました(2026年8月時点)。
  • ダイレクトメッセージでは個人アカウントの権限、共有チャンネルではアプリ名義で成果物が作られます。
  • 公式はセキュリティ上の注意として、スレッド全体が文脈として取り込まれ成果物に保存されると明記しています。

GitHubは2026年8月21日、Slack上のGitHub連携に、GitHub Copilot CLIとGitHub Copilotアプリのエージェント機能を組み込んだと発表しました。公開プレビューとしての提供です(2026年8月時点)。

ダイレクトメッセージ、チャンネル、スレッドのいずれかで@GitHubをメンションすると、エージェントのセッションが始まります。できることは、コードやGitHub上の活動に関する質問への回答、バグ報告のトリアージ、既存イシューの更新、新規イシューの作成とラベル付け、失敗の調査、変更の実装とsecure cloud sandbox内での検証、プルリクエストの作成と会話へのリンク提示です。着手後はサンドボックス内で非同期に作業し、完了時に結果を投稿します。

GitHubは、エージェント向けの新しい種類のチャンネルであるSlack Codeのローンチパートナーでもあり、Copilotはタスク専用のコードチャンネルを作れます。コードチャンネルは1タスク1チャンネルの運用で、セッション終了時にアーカイブするか尋ねられます。アーカイブ後もチャンネルと履歴は閲覧・検索可能で、必要なら再オープンできます。チャンネル内には作業対象のリポジトリ、ブランチ、イシューやプルリクエストへのリンク、ステータス、使用モデルが表示されます。

呼ぶ場所で「誰の名義か」が変わる

同じ@GitHubでも、呼んだ場所によってCopilotの身元が切り替わります。ここが導入前に押さえるべき点です。

公式ドキュメントによれば、ダイレクトメッセージで使った場合、Copilotは連携した個人GitHubアカウントの権限でプルリクエストやイシューの作成といった操作を行います。一方、グループスレッドやチャンネルのような共有の場では、成果物は個人アカウントではなくアプリ名義の下で作られます。あとから履歴を見たとき、誰の操作として記録されているかが変わるということです。

権限の線引きも明示されています。変更をトリガーできるのはリポジトリへのwrite権限を持つユーザーだけで、会話の参加者は誰でも入力そのものは出せます。ワークスペースのゲストメンバーと、リポジトリのoutside collaboratorは、セッションの開始も操舵もできません。

あわせて公式は、セキュリティ上の注意としてもう1点を明記しています。Copilotはリクエストの文脈としてスレッド全体を取り込み、その文脈はエージェントが生成する成果物に保存されます。会話の全メッセージが作業の判断材料になるためで、文脈を限定したい場合はチャンネルではなくSlack用GitHubアプリへダイレクトメッセージを送るよう案内されています。

使える条件と、記載が食い違う箇所

利用条件については、2つの公式文書で記載の粒度が異なります。ここは読み分けが必要です。

チェンジログは、公開プレビューの対象を「GitHub Copilot BusinessおよびGitHub Copilot Enterpriseプランの組織」と明記しています(2026年8月時点)。利用は既存のCopilotエンタイトルメントを消費し、既存のCopilot cloud agent budgetsで管理できるとされています。これに対して公式ドキュメントの前提条件は、「有料のCopilotプランでCopilotにアクセスできるGitHubアカウント」と「Copilotプランでクラウドサンドボックスが有効になっていること」の2点だけを挙げています。どちらの記載も公式のものなので、導入判断の前に自組織のプランで実際に有効化できるかを確認するのが安全です。日本での提供条件や価格に関する個別の記載は、両ページとも確認できませんでした。

開始手順は、管理者が組織のCopilot cloud agentポリシーを有効化し、Slack用GitHubアプリをインストールまたは更新したうえで、GitHubアカウントを連携して@GitHubをメンションする流れです。

統制側の仕掛けも用意されています。リポジトリ管理者は、Copilotアプリ名義に帰属するプルリクエストに対して、マージ前の追加承認を必須にできます。同日にGitHubは、Microsoft Teamsでも@GitHubメンションでCopilot cloud agentセッションを開始できる公開プレビューを発表しており、こちらは対象が「有料のGitHub Copilotプラン」、セッションはAIクレジットを消費し、クラウドサンドボックスの利用は別課金と記載されています。Teams側の承認ゲートについては、2承認が必須のリポジトリならCopilot作成のプルリクエストは3承認になる、と具体例が示されています。

編集部の見方

編集部は、この機能で最初に決めるべきはツールの導入可否ではなく、社内で「どこからCopilotを呼ぶか」の運用ルールだと見ています。

根拠1: ダイレクトメッセージと共有の場で成果物の名義が切り替わるため、監査ログに残る主体が呼び出し場所で変わります。追跡の単位が変わるので、後から責任範囲を確認する作業の難易度が変わります。

根拠2: スレッド全体が文脈として取り込まれ、成果物に保存されると公式が明記しています。雑談や検討過程を含むチャンネルでそのまま呼ぶと、意図しない範囲が記録に残ります。文脈を絞りたい場合はダイレクトメッセージ、という使い分けが公式側の想定です。

根拠3: 追加承認をアプリ名義のプルリクエストに設定できる設計になっており、名義が権限管理の単位として扱われています。名義の切り替わりを理解しないまま運用すると、承認ゲートが想定どおりに効きません。

この見方が変わる条件: 共有チャンネルでも個人アカウント名義を選べるようになれば、呼び出し場所を運用ルールで縛る必要性は下がります。


よくある質問

Q: ダイレクトメッセージとチャンネルで何が違いますか?

A: 公式ドキュメントでは、ダイレクトメッセージでは連携した個人GitHubアカウントの権限で操作が行われ、グループスレッドやチャンネルなど共有の場では成果物がアプリ名義で作られると説明されています。

Q: チャンネルの参加者なら誰でもコードを変更させられますか?

A: 変更をトリガーできるのはリポジトリへのwrite権限を持つユーザーだけです。他の参加者も入力は出せますが、ワークスペースのゲストメンバーとoutside collaboratorはセッションの開始も操舵もできません。

Q: どのプランで使えますか?

A: チェンジログはCopilot BusinessとCopilot Enterpriseの組織向け公開プレビューと明記し、公式ドキュメントの前提条件は有料のCopilotプランとクラウドサンドボックスの有効化を挙げています。記載の粒度が異なるため、自組織のプランでの有効化可否を確認してください。


まとめ

GitHubは2026年8月21日、Slack上のGitHub連携にGitHub Copilotのエージェント機能を追加し、公開プレビューを開始しました。@GitHubのメンションでセッションが始まり、サンドボックス内で調査から実装、プルリクエスト作成までを非同期に進めます。運用上の要点は、ダイレクトメッセージでは個人アカウント権限、共有の場ではアプリ名義という身元の切り替わりと、スレッド全体が文脈として成果物に保存される点です。リポジトリ管理者はアプリ名義のプルリクエストに追加承認を課せます。

似た仕組みは他のAIベンダーでも進んでおり、Slack上でチームにタスクを委任する事例は以下の記事でも解説しています:


【用語解説】

  • 公開プレビュー: 正式提供の前段階として、条件を満たす利用者に広く開放される提供形態。仕様が変わる可能性がある
  • サンドボックス: 本番環境から隔離された作業用の実行環境。ここで変更を試すため、失敗しても本番に影響しない
  • outside collaborator: 組織のメンバーではないが、特定のリポジトリにだけ招待されている協力者

引用元:


この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

anchor left anchor right
KOJI TANEMURA

15 年以上の開発経験を持つソフトウェアエンジニア / テクノロジーライター。AI エージェントの実務活用を研究し、現場や経営者向けセミナーでその知見を発信。本メディア tech-noisy.com では、一次情報に基づく最新ニュース・解説記事を執筆。また、音楽生成 AI による DJ パフォーマンスを企業イベントで行うなど、テクノロジーと表現の融合も探求している。