@GitHub の Slack / Teams 連携が提供開始 — 変更点と導入前に確認すべき権限・コスト

2026年11月6日、GitHub は Slack と Microsoft Teams の @GitHub 連携(Copilot cloud agent との連携)が一般提供(GA)になったと発表しました。チャットで @GitHub とメンションすれば、バグの調査、Issue 作成、コード変更、プルリクエスト作成までを会話の場から依頼できます。GA で追加されたのは Teams の Canvas、リポジトリ自動判別、フォローアップ応答の不具合修正、作成物への会話元の明記の4点です。ただし「チャットにいる人=変更できる人」ではありません。権限境界は GitHub 側のリポジトリ権限のままで、コンピュート課金も2026年11月から始まっています。導入判断に必要な点を整理します。
GA で何が変わったか
GitHub の Changelog(2026年11月6日)が挙げる変更は次の4点です。
- Teams の Canvas:会話の横に実装計画・ファイル変更・プレビューを表示し、Teams を離れずにレビューと議論を続けられます。
- オンボーディングの簡素化:メッセージの内容からリポジトリを判別してセッションを開始します。未サインイン、デフォルトリポジトリ未設定、リポジトリの切り替え、アプリのアクセス許可が必要な場合の導線も改善されました。
- 会話の安定性:フォローアップのメッセージに応答が返らないことがある不具合を修正しました。
- 帰属の明確化:作成された Issue や PR の説明に「Slack/Teams の会話から、@ユーザー名 とともに作成された」旨が記載されます。
GA そのものは8月21日のパブリックプレビュー開始から約2か月半での到達です。プレビュー時の Slack 版は Copilot Business / Enterprise 組織向けと案内されていましたが、現在の公式ドキュメントは Slack・Teams ともに「すべての有料 Copilot プランで利用可能」と記載しています。Copilot Free は対象外です。
Slack と Teams で設計が違う
同じ @GitHub でも、作業を追う場所の設計が異なります。Slack では Copilot が「Slack Code」という専用のコードチャンネルを作成し、セッション開始後はそのチャンネルから操作します。1タスク1チャンネルが原則で、終了時にアーカイブを尋ねられ、アーカイブ後も閲覧・検索が可能で再オープンもできます。
Teams の Canvas は読み取り専用です。表示されるのは、リンク済みの GitHub アカウントと自分のリポジトリ権限で既に閲覧できる内容に限られます。つまり Canvas 経由で権限を越えて見えることはありません。レビューは Canvas で、指示は会話側で、という役割分担になります。
共通する制約として、1セッションで扱えるのは同一オーナー(組織または個人アカウント)の最大11リポジトリで、選択したすべてに write 権限が必要です。チャンネルのデフォルトリポジトリは全員で共有され、変更は実行中のセッションではなく新しい会話から反映されます。DM にはデフォルトリポジトリを設定できないため、プロンプト内でリポジトリ名を指定します。
権限と情報の扱いが実運用の要点
変更を実行・操作(steer)できるのは、対象リポジトリすべてに write 権限を持つ人だけです。他の参加者は文脈を補足できますが、セッションの開始や方向転換はできません。ワークスペースのゲストメンバーとリポジトリの外部コラボレーターは、開始も操作もできません。
見落としやすいのが文脈の範囲です。GitHub のドキュメントは、Copilot がスレッド全体を文脈として取り込み、その文脈が生成される成果物に保存されると明記しています。インシデント対応スレッドのように機微な情報を含む会話でメンションすると、その内容が Issue や PR の記述として長期的に残り得ます。文脈を絞りたい場合は、スレッドではなく GitHub アプリへの DM を使う方法が案内されています。
作成物の ID も surface によって異なります。Slack の DM では連携した個人アカウントの権限で動作し、チャンネルやグループスレッドなど共有の場ではアプリ ID で PR などが作成されます。レビュー要件を設計するときは、この違いを前提にしてください。
コストは「Copilot の権利」と「実行環境」で分かれる
セッションは GitHub 管理のクラウドサンドボックスで非同期に実行されます。2026年10月28日の Changelog によれば、クラウドサンドボックスの課金は2026年11月に開始し、利用分はまず Actions の含有枠から差し引かれます。この含有枠は標準ランナー分数の固定値ではなく、ビルド・クラウドサンドボックス・(Team と Enterprise Cloud では)大型ランナーに使える金額ベースの共有プールに変わりました。各製品は個別の料金レートを持つため、レートの高い計算資源ほど枠の消費は早くなります。
実務上の意味はシンプルです。チャットから起動できることで着手のハードルが下がるため、セッション数は増えやすい。枠の消費が読みにくくなる前に、予算設定と課金サイクルごとの消費状況の確認を運用に組み込んでおくほうが安全です。なお GA の告知にセッション単価の記載はありません。
導入するなら、この順番で確認する
- プランとポリシー:有料 Copilot プランであることを確認します。組織・Enterprise 経由の場合、「Copilot in the cloud」ポリシーは既定で有効ですが、オーナーが無効化できます。サンドボックスは別設定を必要としません。
- アプリのインストール範囲:GitHub アプリを Slack / Teams に導入(既存の場合はアップグレード)し、アクセスできるリポジトリを絞ります。Enterprise 所有リポジトリでは管理者側の設定が必要です。
- チャンネル設計:1チャンネル1リポジトリを基本にし、デフォルトを明示的に設定します。設定しないと最初のセッションで使ったリポジトリが既定になります。
- レビュー規則:アプリ ID による PR に追加承認を求めるルールセットを検討します。マージ前の人のレビューを省略しない前提で運用します。
- 最初のタスク選び:影響が小さく元に戻しやすい作業(Issue のトリアージ、テストの修正、ドキュメントの不備など)から始め、動作とコストの感触を掴んでから範囲を広げます。
なお、リポジトリ単位の MCP サーバー設定により、共有セッションに外部ツールの文脈を取り込めます。どのツールを許可するかはリポジトリ管理者が決める設計です。セッションをまたいで文脈を保持する Copilot Memory はパブリックプレビュー段階のため、仕様変更を前提に扱ってください。
まとめ
GA により、チャットから始まる開発作業は「試す機能」から「運用する機能」に移りました。次に取るべき行動は、有効化よりも先に、対象リポジトリの絞り込み・チャンネルのデフォルト設定・アプリ ID の PR に対する承認ルール・コンピュート予算の4点を決めることです。この4点が決まっていれば、低リスクのタスクから段階的に広げられます。
出典
- GitHub Changelog: @GitHub の Slack / Teams 連携が一般提供に(2026年11月6日)
- GitHub Changelog: 新しい Copilot クラウド体験とコンピュート枠の変更(2026年10月28日)
- GitHub Changelog: Slack における新しい GitHub Copilot 体験(2026年8月21日)
- GitHub Docs: Copilot cloud agent と Slack の連携
- GitHub Docs: Copilot cloud agent と Teams の連携
- GitHub Docs: GitHub と Slack の連携
- GitHub Docs: GitHub と Teams の連携
この記事に関連するchot Inc.の支援
chot Inc.では、生成AIを組み込んだ業務アプリケーションの開発と、AIアシスタントを搭載したWebサイトの構築を支援しています。社内向けのAIツールやRAGの仕組みはAIアプリケーション開発で、コーポレートサイトへのAIアシスタントの搭載はエージェント型Webサイト構築で、それぞれの支援内容を紹介しています。


