GitHubは2026年8月21日、Microsoft TeamsでGitHub Copilotのcloud agentを共同利用できるpublic previewを公開しました。会話スレッドから調査、計画、コード変更、issue作成、pull request作成まで進められる点はSlack版と似ていますが、Teams版は「どの会話をそのまま実装に接続するか」という運用設計で差が出ます。この記事では、Slack版との違いまで含めて、Teamsを選ぶべき条件を整理します。
GitHub CopilotのMicrosoft Teams連携で何が変わるのか
GitHub Docsによると、Teamsの会話からCopilot cloud agent sessionを開始し、リポジトリ調査、実装計画、コード変更、issue作成、pull request作成まで実行できます。会話内容がそのままタスク文脈になるため、会議で決めた修正方針やレビューコメントを別の場所へ転記せずにGitHubへつなげられるのが主な価値です。
ただし、これはIDE内のagent modeの延長ではありません。公式ドキュメントでは、cloud agentはGitHub Actionsベースのephemeral development environmentで非同期に動き、ブランチ作成、コード変更、テスト実行、PR作成候補まで進める仕組みと説明されています。つまりTeams連携は「会話UIだけTeamsに広がった」のではなく、GitHub上で走るagent作業の入口が会話ツールに増えた、と捉えるのが正確です。
Slack版とTeams版の違いはどこか
共通点は多いものの、Slack版の公式DocsにはCopilotがタスクごとに専用のSlack Code channelを作り、そこだけでsessionをsteerする仕組みが明記されています。一方、Teams版Docsは既存のconversationやthreadを中心に説明しており、Slackのような専用code channel運用は前面に出ていません。この差は、作業を専用部屋へ分離したいか、既存スレッドの流れを保ちたいかで使い分けの判断軸になります。
導入前提も異なります。Teams版ではGitHub accountとTeams accountに加え、Microsoft Teams clientでPublic Developer Previewを有効にする要件があります。Slack版はGitHub app for Slackをworkspaceへ入れ、必要なchannelへ招待すれば利用を始められます。2026年8月22日時点では、導入の手軽さはSlack寄り、既にMicrosoft 365運用が定着した組織で会議や部門チャネルに直結させやすいのはTeams寄り、と整理できます。
リポジトリ設定の考え方も少し違います。Slack版はchannelごとにdefault repositoryを持てる設計がDocsで案内されていますが、Teams版は初回接続時にdefault repositoryを設定し、そこへissueやpull requestを開く流れです。複数repoをまたぐ現場ならSlackのchannel単位運用は整理しやすく、特定チームが主に1つのrepo群を扱うならTeamsでも運用しやすい、という差が出ます。
利用条件と管理者が先に確認すべき項目
対象は有料のGitHub Copilot全プランです。ただし、BusinessとEnterpriseではCopilot cloud agentが既定で無効のため、管理者が組織またはenterpriseレベルで有効化する必要があります。Pro、Pro+、Maxは既定で有効ですが、repoごとのopt-outやrulesetの影響は受けます。管理者は「使えるか」だけでなく、「どのrepoで許可するか」「誰がsteerできるか」を合わせて決める必要があります。
Teams版ではGitHub appをteamに一度追加した後、各メンバーが初回利用時にGitHub accountを接続します。Cloud sandboxesも有効でなければならず、cloud sandbox policyはcloud agent policyと同じ設定を共有します。GitHub changelogでは、Teamsから開始したcloud agent sessionはAI creditsを消費し、cloud sandbox usageは別建て課金と案内されています。cloud agent全体としてGitHub Actions minutesも使うため、予算設計なしで広げると運用コストが読みづらくなります。
Teams運用で見落としやすい権限とセキュリティ
Teams版Docsは、shared contextではCopilotが会話全体をartifact生成の文脈として取り込むと説明しています。会議ログや障害対応の議論をそのまま渡せる便利さがある一方で、不要な内部事情まで文脈へ混ざりやすいので、機密度が高い依頼はGitHub appへのdirect messageへ切り分ける運用が必要です。これはTeams導入時の明確な設計ポイントです。
権限の扱いも重要です。direct messageでは接続した個人のGitHub権限でissueやpull requestを作成できますが、channelやgroup threadのshared contextではCopilot app identityでartifactが作られます。さらにwrite accessを持つ人だけが変更作業を開始でき、guest memberやoutside collaboratorはsession開始やsteerができません。Teamsを社内横断の会話基盤にしている組織ほど、この差を知らずに始めると「話せるが実装は走らない」状態になりやすいです。
レビュー条件にも影響があります。shared contextで作られたPRはapp identityに紐づくため、repository rulesetで既に1件以上の承認を要求している場合、追加でもう1承認が必要になります。またCopilot cloud agentは1タスクにつき1ブランチ、1本のPR、最大59分という制約があります。長い会議スレッドを丸ごと投げるのではなく、受け入れ条件を切った小さな依頼へ分解する方が成功率は高いです。
Teamsを選ぶべきケースと導入フロー
Teamsが向くのは、会議や部門チャネルで決まった内容をそのまま実装タスクへ落としたい組織です。たとえば、仕様調整、障害一次切り分け、レビュー会議の結論をその場でissue化し、必要ならコード変更まで進めたいケースでは、conversation continuityを保てるTeams版が相性良好です。逆に、1タスクごとに専用の作業部屋を自動で分けたい、channelごとにrepo運用を細かく整理したいなら、Slack Code channelのあるSlack版の方が明快です。
導入順は、小さなrepoでcloud agentとcloud sandboxのポリシーを有効にし、GitHub app for Teamsを追加し、default repositoryを固定して試すのが安全です。最初のユースケースは、既存issueの調査、テスト追加、ドキュメント更新、軽微な修正のように、PR差分を短時間でレビューできるものが向いています。会議中の大きな抽象議論をそのまま投げるより、Teamsスレッド内で対象repo、対象ブランチ、受け入れ条件を明文化して依頼する方が定着しやすくなります。
よくある質問
Q. Teams版だけでコード変更まで完結できますか？ A. できます。公式情報では、Teamsの会話から調査、計画、コード変更、issue作成、pull request作成まで可能です。ただし実行本体はsecure cloud sandbox上で非同期に進むため、ローカルIDEのagent modeそのものではありません。
Q. Slack版とどちらを先に試すべきですか？ A. 既にSlackを開発ハブにしていて、タスクごとに専用code channelを切りたいならSlackが試しやすいです。Microsoft 365やTeams会議を中心に動く組織で、会話の連続性を重視するならTeamsが向きます。どちらもpublic previewなので、まずは1チーム・1repoで比較導入し、権限・レビュー・予算の運用差を見たうえで広げるのが無難です。
