GitHub Copilot Teams連携とは？チャットから修正PRを作る新アプリ｜旧アプリは11月16日終了【2026年】

GitHub Copilot Teams連携を、僕は「バグの報告が届いたTeamsのスレッドで、そのまま修正のプルリクエストまで頼める窓口」と読んでいます。2026年10月23日のGitHubの発表で、通知用のアプリとCopilotが1つのGitHubアプリにまとまりました。

この記事は公式情報・公開情報をもとにまとめた解説です。僕の会社で検証していない点は、その旨を書いています。出典はGitHubのchangelogとGitHub Docsで、確認日は2026年10月30日です。

何ができるか、誰が使えるか、始め方、料金と制限、注意点を順に並べます。旧アプリを入れている会社は、11月16日の終了までに何をすればいいかも確かめてください。

GitHub Copilot Teams連携とは：@GitHubと書くとCopilotが修正まで進める新しいアプリ

GitHub Copilot Teams連携は、Microsoft TeamsのGitHubアプリから、Copilotに調査や修正を頼める仕組みです。通知を受け取る役と、Copilotに作業を頼む役を、1つのアプリが兼ねます。

発表はGitHubのchangelogの2026年10月23日の投稿です。新しいアプリは、以前「GitHub notifications」と呼ばれていたアプリを引き継いだものだと書かれています。

Docsでは、Teamsから動かす作業役を「Copilot cloud agent」と呼んでいます。チャネル・グループチャット・個人のチャットのどこからでも、作業のセッションを始められると説明されています。

何ができる：通知を受けて、@GitHubで調査・修正・プルリクエストまで

できることの中心は、Teamsに届いた通知から、そのまま作業をCopilotに渡せる点です。changelogは「通知をコードに変える」という言い方で紹介しています。

changelogの例：バグの報告から修正のPRまで

changelogには、バグの報告を例にした流れが載っています。どれも公式の説明の要約で、僕の会社で動きを確かめたものではありません。

1. バグの報告の通知がTeamsに届く
2. @GitHubをメンションすると、Copilotがバグを調べて直し、プルリクエストを作る
3. チームがプルリクエストを見直し、テストして、マージする

最後の見直しとマージは、人の役目として書かれています。Copilotが作るのはプルリクエストまでという位置づけです。

Docsに載っているほかの機能

Docsには、修正のほかにもできることが並んでいます。Copilotは会話を文脈にして、調べる・計画を立てる・コードを書く・課題を作る、といった作業を進めると説明されています。

課題（issue）は1件だけでなく、親と子の関係をつけた複数件も作れます。そのときはスレッドの履歴の全体を文脈に使うと書かれています。

ほかに、モデルの選択、MCPサーバーとの接続、複数のリポジトリにまたがる作業にも対応しています。モデルは一覧から選ぶか、頼む文の中で名前を書けば、その会話だけに効きます。

セッションを始めると「Open canvas」のボタンが出ます。計画・ファイルの変更・プルリクエストの概要を読むだけの画面で、GitHubで見る権限がある内容だけが表示されます。

通知の機能は引き継がれる

通知の機能は、これまでどおり残ります。changelogには、GitHub notificationsを入れている場合はアプリを最新版に更新すれば、通知の機能は動き続けると書かれています。

Docsでも、今ある購読（subscription）とリマインダーは更新後も残ると説明されています。Copilotのための既定のリポジトリの設定は、通知の購読とは別に持つ形です。

誰が使える：有料のCopilotプランと、リポジトリへの書き込み権限が前提

使えるのは、有料のCopilotプランでCopilotを使えるGitHubアカウントを持つ人です。Docsの前提条件にそう書かれていて、Freeで使えるという記載はありません。

ほかに、Teamsのアカウントが要ります。作業を始めたり、方向を変えたりできるのは、選んだリポジトリのすべてに書き込みの権限がある人だけです。

会話の参加者は誰でも意見を足せます。一方で、ワークスペースのゲストと、リポジトリの外部コラボレーターは、作業を始めることも方向を変えることもできないと書かれています。

組織・エンタープライズで管理者が見ること

組織やエンタープライズでは、Copilot cloud agentの方針（ポリシー）が既定でオンです。ただし、オーナーがオフにできると書かれています。

Teamsからの作業はクラウドのサンドボックスで動き、別の設定は要らないと説明されています。Copilot Memoryを使う場合は、組織やエンタープライズのプランでは管理者が先に方針を有効にする必要があります。

提供の段階と、日本で使えるか

提供の段階（一般提供か、試験提供のプレビューか）は、changelogにもTeams連携のDocsにも明記がありません。Docsでプレビューと書かれているのは、Copilot Memoryだけです。

日本で使えるかについては、地域や国、言語の制限の記載がどちらにもありません。日本語での動きの違いも書かれておらず、この記事では未確認として扱います。

始め方：アプリを入れて、@GitHubでアカウントをつなぐ

始め方は、changelogでは2つの手順だけです。新しいGitHubアプリを入れて、@GitHubをメンションし、案内に沿ってGitHubのアカウントとリポジトリを選びます。

Docsでは、もう少し細かく4つに分かれています。手順はDocsの書き方の要約で、僕の会社で通したものではありません。

1. GitHubアプリを入れる（チームごとに1回）。Docsのリンクから開いて「Add」を押し、認証して許可する
2. メッセージで@GitHubをメンションし、案内に沿ってGitHubのアカウントをつなぐ。既定のリポジトリも選べる
3. 使い方を見るときは、スレッドで「@GitHub help」と書く
4. @GitHubのあとに頼みたい作業を書いて、セッションを始める

すでにGitHub notificationsを入れているチームは、入れ直しではなくアプリの更新になります。Copilotは返事で、予定している変更の要約と、作ったもののリンクを返すと書かれています。

リポジトリとブランチの指定

頼む文の中で、使うリポジトリとブランチを指定できます。Docsの例では、文の最後に repo=OWNER/REPO と branch=BRANCH-NAME を付ける形です。

branch は、プルリクエストの土台にする既存のブランチです。チャネルやグループチャットの既定のリポジトリは「@GitHub settings」で決められます。

続きを頼むときは、同じスレッドでもう一度@GitHubをメンションします。前回のメンションから後のメッセージを、すべて文脈として使うと説明されています。

料金・制限：Teams連携の料金は記載なし、1回の作業はリポジトリ11本まで

料金は、changelogにもTeams連携のDocsにも書かれていません。プレミアムリクエストやAI credits、GitHub Actionsの実行時間の扱いも、今回読んだ2つのページには記載がありませんでした。

CopilotのAI creditsとプランごとの割り当ては、GPT-6.1 TerraがGitHub Copilotで提供開始の料金の節にまとめています。

Teams連携からの作業がその数え方に乗るかは、今回読んだページからは分からず、この記事では未確認として扱います。

制限は、Docsにいくつか書かれています。数字が出ているのは、1回のセッションで扱えるリポジトリの数です。

• 1回のセッションで扱えるのは、同じ組織か同じ個人アカウントのリポジトリ11本まで
• 個人のチャット（DM）では既定のリポジトリを決められない。頼む文の中で書く
• 既定のリポジトリは、持ち主が同じものにそろえる必要がある
• 個人で設定したMCPサーバーは、自分が始めたセッションでだけ使われる
• リポジトリのMCPの設定が正しくないか大きすぎると、セッションが始まらない

最後の点は、リポジトリの管理者が設定を直す必要があると書かれています。MCPを使っている会社は、Teamsから頼む前に設定を見直しておくと安心です。

注意点：スレッド全体が文脈になる・旧アプリは11月16日に終了

注意したい点は3つあります。公式に書かれていることを、場面ごとに分けて並べます。

1つ目：どこで頼むかで、作業の名義と承認が変わる

どこで頼むかによって、Copilotが動くときの名義が変わります。Docsの説明を、個人のチャットと共有の場で比べると下の表になります。

共有の場で作られたものは人に紐づかないため、承認がもう1件増えます。この動きは既定でオンです。僕なら、チャネルで頼む前提で、レビューする人を先に決めておきます。

2つ目：スレッドの全体がCopilotに渡り、成果物に残る

Copilot cloud agentは、スレッドの全体を文脈として取り込みます。その文脈は、Copilotが作ったプルリクエストなどの成果物に保存されると書かれています。

文脈を絞りたいときは、GitHubアプリに個人のチャットで頼むか、新しいスレッドを立てるよう案内されています。社外の人の名前や金額が出るスレッドで頼む前に、一度考えたいところです。

MCPサーバーについても、リポジトリの管理者が使える道具と認証情報を決めます。Docsは、サーバーを有効にする前に、道具とデータへのアクセスを見直すよう勧めています。

3つ目：旧来のGitHubアプリは11月16日に終了

旧来のGitHubアプリは「GitHub (deprecated)」に名前が変わり、11月16日に提供が終わります。changelogの文には年が書かれておらず、投稿の日付は2026年10月23日です。

この旧アプリでCopilotを使っている場合、続けて使うには新しいGitHubアプリを入れる必要があると書かれています。GitHub notificationsのほうは、更新すれば通知が続く扱いです。

Copilotが作るコードについて、Teams連携のDocsは冒頭で、Copilotは間違えることがあるので確認するよう書いています。マージ前の見直しは省けない前提で考えます。

中小企業での使いどころ（僕の見立て）

ここからは事実ではなく、僕の見立てです。社内でTeamsとGitHubの両方を使い、担当が1〜3人ほどの会社なら、小さな修正の受け口として合うと読んでいます。

理由は、報告を受けてから直し始めるまでの「読み直し」が減りそうだからです。報告のスレッドがそのままCopilotへの指示になり、続きも同じスレッドで頼めます。

僕の会社は、社内の連絡にTeamsを使っておらず、この連携を業務で回した記録はありません。下の場面は一般論として読んでください。

合いそうな場面

• 社内のWebサイトや業務の道具の不具合を、Teamsで受け付けている会社
• 文言の直しや小さなバグなど、レビューすれば済む修正が多いチーム
• 外注先とTeamsのチャネルを共有し、修正の依頼をそこで出している会社

先に決めておきたいこと

チャネルで頼むとアプリの名義になり、承認が1件増えるので、誰がレビューするかを先に決めたほうが安全と考えています。スレッドの全体が渡る点も、チャネルの使い分けで調整したいところです。

AIが作ったプルリクエストの見直しを、人とAIでどう分けるかは、Claude CodeのCode Reviewの記事で考え方を並べています。

Copilotの使うモデルを自動で選ばせる仕組みは、GitHub Copilot Fusionとはにまとめました。Teamsからの作業でも、モデルの選択はプランと組織の方針に左右されます。

まとめ

• GitHub Copilot Teams連携は、TeamsのGitHubアプリで@GitHubと書くと、Copilotが調査・修正・プルリクエストの作成まで進める仕組み
• 使うには有料のCopilotプランと、対象のリポジトリへの書き込み権限が要る。ゲストと外部コラボレーターは作業を始められない
• 料金・提供の段階・日本での提供は、changelogとTeams連携のDocsに記載がない
• 旧来のGitHubアプリは11月16日に終了。Copilotを続けて使うには新しいアプリを入れる
• 僕なら、まず個人のチャットで小さな修正を頼み、レビューする人を決めてからチャネルへ広げます