GitHub Copilot、SlackとMicrosoft Teamsに参入 - チャットで起きるエージェントを全員で見る

GitHubが2026年8月21日、GitHub Copilot の Slack 連携と Microsoft Teams 連携を、同じ日にそれぞれパブリックプレビューとして公開した¹²。どちらもチャットの中で @GitHub をメンションするとエージェントのセッションが始まり、その会話にいる人たちが一緒に見て、口を出せる。

前日の8月20日にSalesforceとSlackがコーディングエージェント専用の「code channel」を持つSlack Codeを公開したばかりで、GitHubはそのローンチパートナーの1社に名を連ねていた¹。今回はその反対側——エージェントを出す側——から、どの契約でいくら払えば入ってくるのかが出てきた形になる。

`@GitHub` と書くとセッションが始まる

Slack側の変更は、SlackのGitHub連携が GitHub Copilot CLI と GitHub Copilot アプリのエージェント機能をSlackの中に持ち込むものだ¹。DM・チャンネル・スレッドのどこでも @GitHub をメンションすればエージェントのセッションが始まる¹。

会話と、許可されたGitHub側の文脈を使って、Copilotができるのは次の4つとされている¹。

コードやGitHub上の活動についての質問に答える
バグ報告のトリアージ、既存Issueの更新、新しいIssueの作成とラベル付け
失敗の調査、変更の実装、安全なクラウドサンドボックス内での検証
プルリクエストを開き、レビュー用に会話へのリンクを添える

会議中でも移動中でも別のことをしていても、Copilotは非同期で作業を続ける¹。動いているあいだSlackから方向を指示でき、その後はターミナル、GitHub Copilot アプリ、IDEのいずれかでプルリクエストから続けられる¹。

Teams側もほぼ同じ形で、チャンネル・スレッド・DMで @GitHub をメンションするとCopilotのクラウドエージェントのセッションが始まる²。GitHubが挙げている例は、スタンドアップで問題を議論しているあいだにCopilotに調査を頼み、そのまま解決に着手させる、という使い方だ²。会議でアクションアイテムが出たら、その場か終わる前に渡してしまえる、という位置づけである²。

「見えるところでやる」ことの設計

この2つの連携で繰り返し出てくるのは、エージェントとの作業を1人の画面に閉じ込めないという考え方だ。

Slackでは、エージェントのセッションが共有される。1人がエージェントと私的に作業するのではなく、依頼が始まった場所でチームが協働できるようにする、というのがGitHubの説明である¹。開かれた場でやることは、有効なエージェントの使い方を学びやすくもする——開発者は同僚がどうプロンプトしているかを見て互いに学べる、という主張も添えられている¹。

Teamsでは権限の線がもう少しはっきり書かれている。会話にいる誰もが質問し、文脈を足し、計画や方向づけを手伝えるが、Copilotに実際の変更を起こさせられるのはリポジトリへの書き込み権限を持つ参加者だ²。

どちらの場合も、Copilotは専用の code channel を作る。Slack側の説明では、元の会話にノイズを足さずにタスクを集中させるためのもので、チャンネルの中では計画を追い、diffを確認し、HTMLアーティファクトのような出力プレビューをレビューし、Copilotと反復できる¹。元のスレッドから誰でもチャンネルに参加でき、文脈を足す、進め方を変える、セッションを止める、といった操作ができる¹。Teams側でも、Copilotが専用の code channel を作り、全員が進捗を見て文脈を足せる、と説明されている²。

なお、Slackにおける code channel はSlack Code側の仕組みで、GitHubはそこに乗るローンチパートナーの立場にある¹。Teams側のchangelogにはSlack Codeへの言及はなく、Copilotが専用の code channel を作るとだけ書かれている²。Slack Code自体は、チャンネルにいる誰でもエージェントを一時停止・方向修正・停止できる設計になっており、ローンチ時点ではGitHubのCopilotのほかにAnthropicのClaude、CognitionのDevin、ChatGPT、Vercelのエージェントが参加している³。

契約と課金は2つで別物になっている

実務で先に確認すべきなのはここだ。同じ日に出た2つの連携で、提供条件と課金の書かれ方が違う。

	Slack連携¹	Microsoft Teams連携²
状態	パブリックプレビュー	パブリックプレビュー
対象	GitHub Copilot Business / GitHub Copilot Enterprise の組織	有料のGitHub Copilotプラン
消費するもの	既存のCopilot entitlements	AIクレジット
予算管理	既存のCopilot cloud agent budgets	組織では usage-based billing budgets
サンドボックス	（記載なし）	別課金。product-level または SKU-level の予算で制御

Slack側は「既存のCopilotの権利枠を消費し、既存のクラウドエージェント予算で管理できる」と書かれている¹。Teams側は「TeamsのCopilotクラウドエージェントのセッションはAIクレジットを消費する」「クラウドサンドボックスの利用は別課金」と明記されている²。どちらも同じ条件だろうと読むと、費用の見積もりが変わる。

管理者側の前提も少し違う。Slackでは組織のCopilotクラウドエージェントのポリシーが管理者によって有効化されている必要があり¹、Teamsではクラウドエージェントに加えてクラウドサンドボックスも有効化されている必要がある（サンドボックスのポリシーはクラウドエージェントのポリシーと同じ設定を共有する）²。Teamsの公開チャンネルでは、求められたらデフォルトのリポジトリを設定する必要があり、DMではデフォルトリポジトリは使われない²。

Copilotが作ったPRだけ承認を1つ増やせる

エージェントに書かせた変更をどう通すかについて、両方の連携が同じ道具を用意している。リポジトリ管理者は、特定のIDに帰属するプルリクエストにだけ、マージ前の追加承認を必須にできる。

Slack側では対象が「Copilot app identity に帰属するプルリクエスト」¹、Teams側では「Microsoft Teams Copilot integration identity に帰属するプルリクエスト」である²。帰属先のIDが違うので、片方を設定すればもう片方も効く、とは読めない。

Teams側にはもう少し具体的な説明がある。リポジトリで2承認を必須にしている場合、これを有効にするとCopilotが作ったプルリクエストには3承認が必要になる²。「速さを落とさずにコンプライアンスの目を残す」というのがGitHubの言い方だ²。

Slackでは、会話から作られたIssueとプルリクエストは Copilot app identity に帰属し、操作は既存のGitHubの権限とコントロールの範囲に収まる、とも書かれている¹。エージェントが独自の権限体系を持ち込むのではなく、すでにあるリポジトリ権限の中で動く、という設計である。

エージェントの操作盤がチャットに寄っている

この1週間で出た更新を並べると、方向がはっきりする。8月19日にはCursorがクラウドエージェントにイベント購読の仕組みを入れ、PRやSlackスレッドを見張って自分で起き上がるようにした。8月20日にSlackが code channel という置き場所を作り、8月21日にGitHubがそこへ乗ると同時にTeams側にも入った。

エージェントの側が自分で動き出せるようになるほど、どこで人が見て、どこで止めるかの設計が重い。今回のGitHubの2つのchangelogが、機能の説明と同じ分量で提供プラン・課金・追加承認について書いているのは、その現れと考えられる。

出力が増えたあとの見え方についても、GitHubは手を打っている。8月19日には組織全体のコード品質の推移を追う「Trends」タブを一般提供しており、こちらは未対応の指摘が増えているか減っているかを組織単位で見る道具だった。個々のタスクをチャットで追い、集計した結果をダッシュボードで見る、という2階建てになりつつある。

もっとも、エージェントが長い作業を最後まで持ちこたえるかどうかは、置き場所を整えるだけでは決まらない。本日別に取り上げたNVIDIAの研究報告は、モデルの外側にある仕組み——何を持ち越すか、停滞を誰が検知するか——が長時間タスクの成否を左右すると論じていた。チャット連携はそのうち「人が介入する経路」を整えるものにあたる。

社内で導入を検討する場合、最初に決めることは絞られる。どちらの連携を先に開けるか（対象プランが違う）、AIクレジットとサンドボックスの費用を誰が持つか、そしてCopilot帰属のプルリクエストに追加承認を掛けるかどうか。いずれも changelog に書かれている範囲で判断できる。日本での提供可否や時期については、どちらの changelog にも記載がない。