GitHub Copilot のエージェントが、コードエディターの外へ出てきました。GitHub は 2026 年 8 月 21 日、Slack 統合と Microsoft Teams 統合を同日に発表しました。どちらも public preview で、普段の会話の中から @GitHub にメンションするとエージェントセッションが始まります。
一方、2 つの発表記事は説明の粒度が揃っていません。Slack 版にだけ詳しく書かれた機能も、Teams 版にだけ明記された権限・課金の説明もあります。発表記事に記載がないことは、その機能が使えないという意味ではありません。 本記事では、公式発表に書かれた範囲と、導入時に決めるべき運用を分けて比較します。
何が変わったのか
Slack 版の公式発表は、DM、チャンネル、スレッドで @GitHub にメンションするとエージェントセッションが始まると説明しています。Microsoft Teams 版の公式発表も同様に、チャンネル、スレッド、DM から @GitHub へのメンションで GitHub Copilot cloud agent のセッションを始められるとしています。
共通する流れは次のとおりです。
- チャット上で問題や依頼が話題になる
- 会話の中で
@GitHubにメンションし、対象や文脈を伝える - GitHub Copilot のエージェントセッションが始まる
- メンバーが質問や追加情報を送り、作業の方向を調整する
- write 権限を持つ担当者が内容を確認し、コード変更や PR に進む
FIXITチャットで呼べるなら、普通の質問ボットが GitHub に詳しくなった感じ？
Tsumiki入口はチャットですが、仕事は質問回答で終わりません。調査、変更、検証、PR まで進められる点が中心です。
FIXITそれなら、導入前に権限やレビューの線引きが必要ですね。
Tsumikiそのとおりです。便利な呼び出し口を増やす作業と、統制を設計する作業はセットです。
既存の GitHub Copilot 実践ポイント は IDE 内の補完や Chat、レビュー機能を中心に扱っています。本記事の対象は、その手前にある Slack / Teams の会話からクラウドエージェントへ依頼する入口です。検索意図と運用範囲が異なるため、両方を併せて読むと全体像をつかめます。
Slack 版でできること
Slack 版の発表は、質問、Issue 操作、クラウドサンドボックスでの作業、PR 作成という一連の流れを具体的に示しています。
コードと GitHub 活動について質問する
ここで重要なのは、回答だけを最終成果にしないことです。チャットの返答は判断材料であり、コード変更へ進むなら差分と検証結果を PR 上で確かめます。生成 AI の情報漏えい対策で扱っているように、入力してよい情報の境界も、利用開始前に組織で決めておく必要があります。
バグ報告をトリアージし、Issue を扱う
Slack 版では、バグ報告のトリアージ、既存 Issue の更新、新しい Issue の作成とラベル付けが明記されています。会話に流れてきた報告を、追跡可能な GitHub の作業項目へ移すところまで任せられます。
クラウドサンドボックスで調査・実装・検証する
エージェントはセキュアなクラウドサンドボックスで障害を調べ、変更を実装し、自分の作業を検証できます。会話からコード作業へ進むうえで中核となる機能です。
PR を開き、会話へのリンクを共有する
作業がまとまると、エージェントは PR を作成し、レビュー用に元の会話へのリンクを提示します。PR の差分だけでなく、なぜ作業が始まり、会話でどの方向へ調整されたかを追いやすくなります。
専用 code channel で元の会話を汚さない
Slack 版に特徴的な説明が、専用の code channel です。GitHub Copilot はタスク専用の code channel を作成でき、元の会話へ大量の作業ログを追加せず、タスクに集中できます。
そのチャンネルでは、チームが差分をレビューし、出力のプレビューを確認し、エージェントと反復できます。障害対応チャンネルを細かなコードのやりとりで埋めず、関係者向けの状況共有と実装担当者向けの作業会話を分離できる構造です。
共有セッションに複数人が参加する
Slack のエージェントセッションは共有されます。依頼が始まった場所でチームが共同作業でき、元スレッドから複数のメンバーが参加して文脈を追加したり、方針を変えたりできます。
Microsoft Teams 版でできること
Microsoft Teams 版も、チャンネル、スレッド、DM の @GitHub メンションから GitHub Copilot cloud agent のセッションを始めます。発表では、会議中の依頼と、参加者の権限による役割分担が強調されています。
会議中に問題を渡し、非同期で作業を続けさせる
会議中に問題が出たとき、その場でエージェントへ調査を依頼し、クラウドサンドボックスで非同期に作業を続けさせられます。会議の参加者全員が調査の完了まで待つ必要はありません。
質問、文脈追加、計画、方向づけに参加する
チームのメンバーは、エージェントへ質問し、文脈を追加し、作業を計画したり方向づけたりできます。専門領域が異なる人から情報を集め、調査の前提を整える使い方ができます。
変更を実行させられる人は write 権限で分かれる
Microsoft Teams 版の発表は、質問や文脈追加にはメンバーが参加できる一方、Copilot に変更を実行させられるのはリポジトリの write 権限を持つ人だけと明記しています。
会話へ参加できる範囲と、コード変更を起動できる範囲を分ける仕組みです。非エンジニアが問題の背景を伝え、write 権限を持つ担当者が内容を確認してから変更を実行させる役割分担を組めます。
Slack 版の発表には、同じ write 権限条件の記載がありません。ここから「Slack 版なら write 権限がなくても変更できる」と解釈してはいけません。確認できるのは、Teams 版の発表がこの条件を明記しているという事実までです。
パブリックチャンネルは既定リポジトリを設定する
Teams 版の設定手順には、パブリックチャンネル用の既定リポジトリが含まれます。@GitHub への依頼がどのリポジトリを対象にするか、チャンネル単位で前提をそろえるための設定です。
Slack 版と Teams 版の比較
2 つの発表を、公式に記載された範囲で比較します。「記載なし」は、使えない、対象外、無料という意味ではありません。
| 比較軸 | Slack 版の発表記事 | Microsoft Teams 版の発表記事 |
|---|---|---|
| 起動方法 | DM、チャンネル、スレッドで @GitHub にメンション | チャンネル、スレッド、DM で @GitHub にメンション |
| 提供状態 | public preview | public preview |
| 提供プラン | GitHub Copilot Business / Enterprise の組織 | 有料の GitHub Copilot プラン |
| 質問・文脈追加 | コードと GitHub 活動への質問、共有セッションへの複数人参加を記載 | 質問、文脈追加、計画、方向づけへのメンバー参加を記載 |
| 変更の実行権限 | 発表記事に write 権限条件の記載なし | リポジトリの write 権限を持つ人だけが変更を実行させられる |
| 作業場所 | セキュアなクラウドサンドボックス | クラウドサンドボックス |
| 会話の分離 | 専用 code channel を作成できる | 発表記事に専用 code channel の記載なし |
| 共有作業 | セッション共有、複数人の文脈追加・方針変更を記載 | メンバーによる質問・文脈追加・方向づけを記載 |
| 課金 | 既存 Copilot entitlement に算入。既存 cloud agent budget で管理 | 各セッションが AI クレジットを消費。usage-based billing budget で管理 |
| PR の追加承認 | Copilot app identity に帰属する PR で設定可能 | Microsoft Teams Copilot integration identity に帰属する PR で設定可能 |
| 発表記事が詳しく扱う範囲 | Issue 操作、調査・実装・検証、PR、code channel、共有セッション | 会議中の依頼、write 権限、5 段階の設定、AI クレジットと予算 |
最も注意が必要なのは課金の用語です。Slack 版は entitlement と cloud agent budget、Teams 版は AI クレジットと usage-based billing budget と表現しています。用語は各発表記事に従ったものであり、両者の課金方式が同じか異なるかを断定するものではありません。
提供プランの表現も異なります。Slack 版は Business と Enterprise の組織、Teams 版は有料の GitHub Copilot プランと書かれています。発表記事にないプラン名を推測で補わず、自社の契約が対象かは導入時に確認してください。
注意
比較表の「発表記事に記載なし」は、機能がないことを意味しません。2 つの発表は説明の重点が異なるため、記載の差と製品仕様の差を分けて読んでください。
導入の前提と設定
ここでは公式発表に加え、Slack の設定 Docsと Teams の設定 Docsを参照します。管理画面の反映時間は一次情報に記載がないため扱いません。
| 段階 | Slack 版 | Microsoft Teams 版 | 導入時の確認 |
|---|---|---|---|
| 1. 管理者設定 | Copilot cloud agent ポリシーを有効化 | クラウドエージェントとサンドボックスを有効化 | 誰が設定を変更し、承認するか |
| 2. アプリ導入 | Slack 用 GitHub App をインストール | Microsoft Teams 用 GitHub App をインストール | 許可するワークスペース、チーム、チャンネル |
| 3. アカウント接続 | 利用者が GitHub アカウントを連携 | @GitHub にメンションして GitHub アカウントを接続 | 退職・異動時の解除手順 |
| 4. リポジトリ設定 | 発表記事に既定リポジトリの記載なし | パブリックチャンネル用の既定リポジトリを設定 | チャンネルと対象リポジトリの対応 |
| 5. コマンド確認 | 発表記事に確認コマンドの記載なし | @GitHub help で利用可能なコマンドを確認 | 利用者向けの簡潔な手順 |
Slack 版の設定順序
Slack 版は 3 つの前提が示されています。
- 組織の管理者が Copilot cloud agent ポリシーを有効にする
- チームが Slack 用 GitHub App をインストールする
- 利用者が自分の GitHub アカウントを連携する
この順序で見ると、管理者が機能を許可し、チャット基盤へアプリを追加し、最後に利用者の identity を GitHub と結び付ける構造です。導入テストでは、個人の DM、限定したチャンネル、共有セッションと code channel の順に確認範囲を広げると、問題の切り分けがしやすくなります。段階導入は本記事の提案であり、公式の必須手順ではありません。
対象は GitHub Copilot Business と Enterprise の組織向け public preview です。一般提供後の条件や public preview の終了時期は、今回の一次情報に記載がありません。
Microsoft Teams 版の設定順序
Teams 版は 5 段階で説明されています。
- 管理者がクラウドエージェントとサンドボックスを有効にする
- Microsoft Teams 用 GitHub App をインストールする
@GitHubにメンションして GitHub アカウントを接続する- パブリックチャンネル用の既定リポジトリを設定する
@GitHub helpで利用可能なコマンドを確認する
アプリを入れただけでは終わらず、アカウント接続、パブリックチャンネルとリポジトリの対応、利用できるコマンドの確認まで含まれます。導入担当者は設定完了を報告するだけでなく、実際の利用者が @GitHub help を実行し、使える入口を確認できる状態まで試すとよいでしょう。
費用とガバナンスをどう決めるか
Slack 版は、利用が既存の Copilot entitlement に算入され、既存の Copilot cloud agent budget で管理できると説明しています。Teams 版では各セッションが AI クレジットを消費し、組織は usage-based billing budgets で管理します。さらに、クラウドサンドボックスの課金は product-level または SKU-level の予算で別に制御します。
具体的な AI クレジット消費量、単価、予算を超えたときの挙動は、今回の一次情報に記載がありません。そのため本記事では試算しません。Slack と Teams で使われる用語が異なるため、同じ課金方式かどうかも断定しません。
Teams 版では 2 つの予算を分けて見る
Teams 版の発表から、少なくとも管理対象を次の 2 つに分けて考えられます。
| 管理対象 | 発表記事の記載 | 導入時の運用提案 |
|---|---|---|
| エージェントセッション | AI クレジットを消費し、usage-based billing budgets で管理 | チームまたは用途ごとに利用状況を見る担当者を決める |
| クラウドサンドボックス | product-level または SKU-level の予算で別に制御 | セッション側と同じ担当者が両方を定期確認する |
PR の追加承認を防波堤にする
Slack 版では、リポジトリ管理者が Copilot app identity に帰属する PR に対し、マージ前の追加承認を必須にできます。Teams 版でも、Microsoft Teams Copilot integration identity に帰属する PR に同様の追加承認を求められます。
この仕組みは、チャットから変更を作る速さと、マージ判断を人が担う統制を分離します。エージェントが実装と検証を進めても、追加承認を通らなければマージできない運用を組めます。
ただし追加承認だけで品質が保証されるわけではありません。レビュー担当者、確認項目、テスト結果の提示方法、セキュリティに関わる変更のエスカレーション先を決める必要があります。法人向け AI ツールのプランと統制でも、契約だけでなく管理機能と運用を併せて設計する観点を解説しています。
製品仕様と運用提案を混ぜない
ここまでの事実と提案を整理します。
- 製品仕様として、Slack 版の entitlement と budget、Teams 版の AI クレジットと予算管理、両統合の PR 追加承認が発表されています
- 今回の一次情報には、具体的な消費量・単価、両統合の課金方式の異同、予算超過時の挙動、一般提供後の条件は記載されていません
- 本記事では、利用状況を見る担当者、用途ごとの起動基準、レビュー担当者、停止・問い合わせ手順を決めることを提案します
どちらの基盤でも共通して考えること
Slack と Microsoft Teams のどちらを選んでも、チャットの発言がコード変更の入口になる点は共通します。導入判断では、機能一覧より先に責任の境界を決めてください。
誰がセッションを始められるか
まず、質問セッションと変更セッションを分けて考えます。Teams 版は変更を実行させられる人を write 権限で制限すると明記しています。Slack 版の発表に同じ説明はありませんが、組織側の運用として、変更依頼を担う役割を決める価値はあります。
全員が文脈を追加できることと、全員が方針を確定できることは別です。次のような役割表を用意すると、共有セッションでの衝突を抑えられます。
| 役割 | 担当すること | 担当しないことの例 |
|---|---|---|
| 依頼者 | 問題、目的、期待結果を伝える | 実装詳細を未確認のまま確定する |
| 文脈提供者 | 影響範囲、制約、関連情報を追加する | 責任者に代わって優先順位を変える |
| 変更起動者 | 対象と方針を確認して実装を開始させる | 権限外のリポジトリを対象にする |
| レビュー責任者 | 差分、検証結果、依頼との一致を確認する | チャットの雰囲気だけで承認する |
| 管理者 | ポリシー、アプリ、予算、追加承認を管理する | 個々の変更内容の妥当性を単独で保証する |
これは公式のロール定義ではなく、導入時のたたき台です。既存の GitHub 権限とレビュー体制へ重ねて設計してください。
どこまで自動で PR を作らせるか
すべての会話をコード変更へ進める必要はありません。質問への回答、Issue 化、調査、実装、検証、PR 作成を段階として捉え、タスクのリスクに応じて止める地点を決めます。
- 影響範囲が不明な報告は、まず調査と Issue 更新までにする
- 小さく独立した修正は、実装・検証・PR 作成まで進める
- 認証、権限、課金、個人情報に関わる変更は、人が方針を確定してから実装へ進める
- 緊急対応でも、マージ前の人によるレビューは省略しない
これらは運用提案です。公式発表は、どのタスクを自動化すべきかまでは定めていません。
レビューの責任者を会話の時点で決める
チャットで気軽に依頼できると、PR が作られたあとに「誰が見るのか」が宙に浮きやすくなります。依頼時にレビュー責任者を置き、作業完了の通知先を決めてください。
レビューでは、少なくとも次を確認します。
- 元の依頼と PR の目的が一致しているか
- 変更範囲が必要以上に広がっていないか
- 検証結果を再現できるか
- セキュリティ、データ、権限への影響がないか
- エージェントへの追加指示が PR に反映されているか
Copilot のモデル選択や提供状況も運用の一部です。GitHub Copilot のモデル廃止対応で説明しているように、モデルや利用条件は変化します。チャット統合を一度設定して終わりにせず、依存する Copilot の設定やポリシーも定期的に見直してください。
チャットと GitHub のどちらを記録の正本にするか
会話は依頼の背景を集めるのに向き、Issue と PR は作業と判断を追跡するのに向きます。どちらか一方だけに情報を閉じ込めると、後から参加した人が経緯を追えません。
チャットを開始地点、Issue を追跡地点、PR をマージ判断の地点として扱います。発表に記載がない操作は、できないと断定せず Docs で確認してください。
public preview として導入する
本番の重要フローへ一気に組み込まず、対象チーム、リポジトリ、用途を限定して評価します。評価期間中は、便利だった回数だけでなく、誤った対象、追加説明が必要だった場面、レビューにかかった時間、予算の把握しやすさを記録すると、継続判断に役立ちます。
まとめ
GitHub Copilot の Slack 連携と Microsoft Teams 連携は、どちらも @GitHub メンションからエージェントセッションを始めます。チャットでの質問にとどまらず、文脈を共有し、クラウドサンドボックスで作業を進め、PR のレビューへつなげる入口です。
Slack 版の発表は、Issue 操作、調査・実装・検証、専用 code channel、共有セッションを詳しく説明しています。Teams 版は、会議中の依頼、write 権限を持つ人だけが変更を実行させられる役割分担、5 段階の設定、AI クレジットと 2 系統の予算管理を明記しています。Slack 版にも既存 entitlement と cloud agent budget の説明があります。
ただし、この記載差をそのまま機能差と考えてはいけません。課金に使う用語の違いだけで方式が別とは言えず、Teams 版に専用 code channel の記載がないから会話を分離できないとも断定できません。確認できる事実と、一次情報に記載がない論点を分けることが比較の出発点です。
導入では、管理者設定、連携アプリ、GitHub アカウント接続を済ませたうえで、起動できる人、対象リポジトリ、変更を進める条件、レビュー責任者を決めてください。Teams 版では AI クレジットとクラウドサンドボックスの予算を分けて管理し、両統合では integration identity に帰属する PR の追加承認を防波堤にできます。
選ぶ基盤は、普段の開発相談が始まる場所に合わせれば十分です。重要なのは Slack か Teams かよりも、会話からコード変更へ進む経路に、権限・費用・レビューの責任を置けるかどうかです。
Copilot のチャット連携をチームの運用へ落とし込みたい場合は、AI 開発ツール導入支援で権限・予算・レビュー体制の設計から伴走しています。自社ではどこから試すべきか整理したい方は、お問い合わせからご相談ください。