SlackとTeamsで「エージェントに頼む」が当たり前になる
チームのやり取りの多くは、いまだにSlackやMicrosoft Teamsのチャット上で交わされています。バグ報告、仕様の相談、リリース前の確認——こうした会話の中で「じゃあ誰かが直しておいて」という一言が出た瞬間、実際の作業は会話の外に切り離され、担当者の頭の中とエディタの中だけで進んでいくのがこれまでの姿でした。
2026年8月21日、GitHub CopilotはSlackとMicrosoft Teamsへの公式対応を発表しました。チャットでの会話そのものからCopilotのエージェントセッションを起動できるようになり、調査や実装、プルリクエストの作成までをチームメンバー全員が見える場所で進められます。本記事では、この新機能の中身と導入手順、あわせて2026年8月に公開された関連アップデートを整理します。
何が公開されたのか——2026年8月21日のアップデート概要
Slack：「@GitHub」とSlack Code
Slack向けのGitHub連携がリニューアルされ、GitHub Copilot CLIとGitHub Copilotアプリが持つエージェント機能がSlackに公開プレビューとして組み込まれました。@GitHubとメンションするだけで、チャンネル・スレッド・ダイレクトメッセージのどこからでもエージェントセッションを開始できます。
会話の文脈とアクセス許可されたGitHub上の情報をもとに、Copilotは次のような作業をこなします。コードやGitHub上の活動に関する質問への回答、バグ報告のトリアージや既存Issueの更新、新規Issueの作成とラベル付け、安全なクラウドサンドボックス内での不具合調査・実装・検証、そしてプルリクエストの作成とレビュー依頼です。ユーザーが会議中や移動中であっても、Copilotは非同期に作業を継続します。
あわせて、GitHubはSlackが新たに用意した「Slack Code」というエージェント専用チャンネル形式のローンチパートナーにもなりました。Copilotは作業内容ごとに専用のコードチャンネルを作成でき、元の会話を煩雑にすることなく、実装計画やコード差分、HTMLプレビューなどの成果物をチームで確認しながら進められます。
Microsoft Teams：会議の決定をそのまま作業に渡す
Teamsでも同様に、チャンネル・スレッド・ダイレクトメッセージで@GitHubとメンションすることでGitHub Copilotのクラウドエージェントセッションを開始できます。スタンドアップの最中に「この不具合を調査しておいて」と依頼すれば、会議が終わるころには調査が進んだ状態になっている、といった使い方が想定されています。
Teamsから開始したタスクは安全なクラウドサンドボックス内で非同期に実行され、その後はターミナル・GitHub Copilotアプリ・普段使いのIDEなど、好きな場所から作業を引き継げます。会話に参加している人は誰でも質問や追加の文脈提供、方向修正が可能ですが、実際にCopilotへ変更を指示できるのはリポジトリへの書き込み権限を持つメンバーに限られます。
導入手順（実装の一次情報）
Slack連携のセットアップ
- 組織の管理者が、GitHub Copilotのクラウドエージェントに関するポリシーを有効にする。
- Slack用GitHub Appをインストール、または既存のものをアップグレードする。
- GitHubアカウントを連携し、会話内で
@GitHubとメンションする。
利用にはGitHub Copilot BusinessまたはEnterpriseプランの組織であることが条件で、消費量は既存のCopilot利用枠にカウントされ、クラウドエージェント向けの予算管理機能でコントロールできます。
Teams連携のセットアップ
- 組織・Enterpriseの管理者が、GitHub Copilotのクラウドエージェントおよびクラウドサンドボックスのポリシーを有効にする（両者は同じ設定を共有します）。
- Teams用GitHub Appをインストールする。
- Teams上で
@GitHubとメンションし、案内に従ってGitHubアカウントを接続する。 - パブリックチャンネルでは、必要に応じてデフォルトのリポジトリを設定する（ダイレクトメッセージではデフォルトリポジトリは使用しません）。
@GitHubに続けて依頼内容を入力する。利用可能なコマンド一覧は@GitHub helpで確認できます。
クラウドエージェントのセッションはAIクレジットを消費し、組織単位での利用量ベース予算の対象になります。クラウドサンドボックスの利用料金は別建てで、製品単位・SKU単位の予算で管理できます。
権限管理とガバナンス——「人間の承認」を挟む仕組み
チャット上で誰でもエージェントに指示を出せるとなると、変更が野放図にマージされてしまうのではないかという懸念が当然出てきます。この点について、GitHubは両プラットフォームで共通の仕組みを用意しました。
リポジトリの管理者は、Copilotアプリ由来のプルリクエストに対して追加の承認を必須にできます。たとえばリポジトリで通常2名の承認を必須にしている場合、この設定を有効にするとCopilot発のプルリクエストには3人目の承認が必要になります。人間の目を必ず一段挟むことで、スピードを落とさずにコンプライアンス上の統制を維持する狙いです。
なお、Issueやプルリクエストの作成者は「Copilotアプリ」または「Microsoft Teams Copilot連携」のIDとして記録されるため、誰が最初に依頼したかというコンテキストはチャットの会話ログ側で追跡することになります。エージェントに渡す権限の設計という観点では、以前取り上げたMCPサーバーの許可リスト管理（GitHub CopilotのMCPサーバーを安全に管理する）とあわせて確認しておくと、社内のガバナンス設計がしやすくなります。
料金体系と利用条件
この公開プレビューは、GitHub Copilot BusinessおよびEnterpriseプランの組織で利用可能です。Teams連携は有償のGitHub Copilotプラン全般で利用可能です。どちらもクラウドエージェント経由の作業となるため、通常のIDE上でのコード補完とは別に、AIクレジットないしクラウドエージェントの利用量としてカウントされる点には注意が必要です。すでにクラウドエージェント機能を予算管理で運用している組織であれば、既存の枠組みをそのまま延長する形で導入できます。
同時期に強化されたその他のCopilotアップデート
新モデルの追加：Kimi K3とMAI-Code-1.1-Flash
2026年8月の週次アップデートでは、Kimi K3がCopilot Pro・Pro+・Max・Business・Enterpriseの各プランに展開されたほか、ネイティブな画像理解に対応したMAI-Code-1.1-Flashも利用可能になりました。コーディング品質や指示追従性、ツール利用の精度が改善されているとされ、旧モデルのMAI-Code-1-Flashは順次廃止が予告されています。加えて、Grok 4.6やGemini 3.7 Flashも同時期にGitHub Copilotで利用可能になっており、モデル選択の幅は着実に広がっています。
Agent Plugins 1.0の管理機能強化
以前の記事（GitHub CopilotがAgent Plugins 1.0に対応）で紹介したオープン標準「Agent Plugins 1.0」についても、GitHub Copilotアプリ側でインストール済みプラグインのバージョン確認や、個別・一括でのアップデートが可能になるなど、運用面の使い勝手が改善されています。あわせてGitHub Copilot CLIでは、複数サブエージェントのタスクを/tasksでまとめて管理できるようになったほか、エージェントの応答を待たせたまま次の指示をキューに積む機能や、Gitに依存せず変更を巻き戻せる/rewindコマンドなど、エージェントを並行して回すための細かな改善が積み重ねられています。
実務での活用イメージとつまずきやすいポイント
たとえばカスタマーサポートチームが不具合報告をSlackで受け取った場面を考えてみます。担当者がスレッド内で@GitHubにメンションして再現手順を共有すれば、Copilotはその場でリポジトリを調査し、必要であればIssueを起票したうえで修正案をプルリクエストとして提示します。チームメンバーは会話に参加したまま進捗を確認でき、担当エンジニアへの引き継ぎもスムーズになります。
一方で導入時につまずきやすいのは権限まわりです。組織のクラウドエージェントポリシーが無効なままだと@GitHubにメンションしても反応しない、あるいはリポジトリへの書き込み権限がないメンバーが依頼しても実際の変更には進めない、といった状態になりがちです。導入初期は、管理者側のポリシー設定とメンバー側のGitHubアカウント連携が両方完了しているかを切り分けて確認すると原因の特定がしやすくなります。また、公開プレビューという性質上、対応範囲や挙動は今後のアップデートで変わる可能性がある点も踏まえておくとよいでしょう。
まとめ
GitHub CopilotのSlack・Teams対応は、「エージェントに作業を頼む」という行為をチャットという最も身近な場所に持ち込んだ点で、これまでのIDE中心・ターミナル中心のCopilot活用とは少し違う意味を持ちます。会話から調査・実装・プルリクエスト作成までがひとつながりになり、しかもその過程がチーム全員に見える形で進む——この「マルチプレイヤー」的な体験は、エージェントへの指示の出し方をチーム内で学び合う機会にもなりそうです。
導入にあたっては、クラウドエージェントの利用量管理や、プルリクエストへの追加承認設定など、ガバナンス面の準備を先に整えておくことが安全な運用の鍵になります。まずは開発チームの一部で公開プレビューを試し、社内のポリシーやレビュー体制と照らし合わせながら展開範囲を広げていくのが現実的な進め方といえるでしょう。
