判断の分かれ目は、Microsoft Teamsに入っているのが「GitHub notifications」か、旧「GitHub」アプリかに尽きます。
2026年10月25日時点、新しい統合版GitHubアプリでは、チャンネル・グループチャット・個人チャットの通知を起点に、@GitHubへ調査と修正を頼み、プルリクエストの作成まで進められます。
GitHub notificationsの利用者は最新版へ更新し、旧GitHubアプリの利用者は11月16日の終了前に統合版へ入れ替えます。Copilotが提案を作っても、レビュー・テスト・マージは人が担当します。
GitHubは2026年10月23日、Microsoft Teams向けのGitHubアプリに通知機能とGitHub Copilotをまとめたと発表しました。Teamsに不具合の報告が届いた後、その会話の中で@GitHubに修正を依頼し、提案された変更をプルリクエストとして受け取れるようになります。
ただし、「通知が届けばCopilotが勝手に直して、そのまま本番へ反映する」機能ではありません。利用者が作業を依頼し、GitHub側のプラン・組織ポリシー・リポジトリ権限を満たしたうえで、最後はチームが差分を確認します。特に情シスとGitHub組織管理者は、Teamsのアプリ許可だけでなく、Copilot cloud agentとcloud sandboxesの設定まで分けて確認する必要があります。
以下では、2026年10月25日に取得したGitHubとMicrosoftの公式情報だけを使い、何が変わったか、旧アプリをどう入れ替えるか、どこまでCopilotに任せられるかを整理します。
何が変わったのか：Teams版GitHubにCopilot統合
今回の変更の中心は、TeamsでGitHubの更新を受け取る機能と、Copilot cloud agentへ作業を依頼する機能が、統合版のGitHubアプリにまとまったことです。GitHubの10月23日の発表では、新しいアプリは以前「GitHub notifications」と呼ばれていたと説明されています。
| 項目 | 内容 | 出典 |
|---|---|---|
| アプリの位置づけ | GitHubの通知とGitHub Copilotによるコーディング作業を、Teamsの1つのGitHubアプリで扱う | GitHub Changelogの2026年10月23日発表 |
| 通知を受け取る場所 | Teamsのチャンネル、グループチャット、個人チャット | Turn notifications into code with GitHub Copilot in Teams |
| Copilotへの依頼 | @GitHubとメンションし、会話やリンクされたIssue、プルリクエストを文脈にして、調査・計画・コード変更・Issueやプルリクエストの作成を頼む |
GitHub DocsのTeams連携ガイド |
| 複数リポジトリ | 1つの会話でリポジトリを切り替えながら、Issue作成、プルリクエスト確認、不具合調査などを頼める | GitHub Changelogの2026年10月15日発表 |
| 最終判断 | 提案された変更をチームがレビューし、テストしてからマージする | GitHubが示したIssue通知からプルリクエストまでの流れ |
10月15日の更新では、SlackとTeamsの@GitHubが、1つの会話の中で複数のリポジトリを扱えるようになりました。メッセージの先頭に限らず、文中のどこに@GitHubを書いてもよく、会話を作り直さずに対象リポジトリを切り替えられます。
ここで注意したいのは、「1つの会話で複数リポジトリを扱える」と「1回の作業で複数リポジトリへ変更を書き込める」は同じではないことです。GitHub Docsは、Copilot cloud agentが1回のタスクで変更できるのは開始時に指定した1つのリポジトリで、扱えるブランチと作成できるプルリクエストも各タスクにつき1つと説明しています。複数リポジトリを横断して調査する場合でも、変更作業はリポジトリごとに分けて依頼する設計が安全です。
旧アプリの入れ替え確認：11月16日終了を2系統で判断する
11月16日までの対応を間違えないためには、Teamsに入っているアプリの名前と役割を先に確認します。GitHubの発表は、既存の「GitHub notifications」と、旧「GitHub」アプリを別の扱いにしています。
GitHub notificationsを使っている場合
GitHub notificationsをすでに導入している場合は、アプリを最新版へ更新します。GitHubは、既存の通知機能はそのまま動き続けると案内しています。通知設定が消える、すべてを登録し直す、といった説明は公式発表にはありません。
旧GitHubアプリを使っている場合
旧GitHubアプリは「GitHub (deprecated)」へ名前が変わり、11月16日に終了します。TeamsでCopilotを使い続けるには、統合版GitHubアプリを導入してください。「旧通知アプリが一律に終了する」のではなく、終了対象は旧GitHubアプリです。
情シスとGitHub管理者が進める入れ替え手順
- 現在のアプリ名を確認する。 Teamsの管理画面と利用チームで、「GitHub notifications」なのか、今後「GitHub (deprecated)」と表示される旧GitHubアプリなのかを切り分けます。
- Teams側でGitHubアプリの利用を許可する。 Microsoftの公式ガイドでは、組織がアプリ中心の管理へ移行済みかどうかで操作場所が異なります。Teams管理センターの組織全体設定、個別アプリ設定、アプリ権限ポリシー、Microsoft 365管理センターの状態を確認してください。これらのポリシーを管理するにはTeams管理者以上の役割が必要です。
- 通知アプリは更新し、旧アプリは統合版へ入れ替える。 GitHub notificationsなら最新版へ更新します。旧GitHubアプリなら、GitHubが案内する統合版GitHubアプリをチームへ追加します。
- GitHub側でCopilot cloud agentとcloud sandboxesを確認する。 GitHub Copilot BusinessとGitHub Copilot Enterpriseでは、Copilot cloud agentは既定で無効です。組織またはEnterpriseの管理者がポリシーを有効にし、利用を許可するリポジトリを決めます。
- 利用者がGitHubアカウントを接続する。 Teamsで
@GitHubとメンションし、表示される案内に従ってGitHubアカウントを接続します。必要に応じて既定のリポジトリを選びます。 - 対象を限定して動作を確認する。 まずは許可済みのリポジトリで、調査または小さな変更を依頼し、Copilotが示す作業対象、Issueやプルリクエストへのリンク、実行状態を確認します。これは運用上の推奨であり、GitHubが特定の試験手順を必須としているという意味ではありません。
GitHubアプリのインストールはチームごとに1回でよく、その後は各メンバーが自分のGitHubアカウントを接続できます。一方、Teams側でアプリが許可されていても、GitHub側のCopilot cloud agentが無効、cloud sandboxesが無効、または対象リポジトリが除外されていれば、コード変更の依頼は開始できません。
Microsoft Teamsのアプリ許可については、Microsoft Learnのアプリ権限ポリシーが現行の管理方法を説明しています。自社テナントがアプリ中心の管理へ移行済みかどうかを確認し、該当する管理方式でGitHubアプリを許可してください。
加えて、GitHubのTeams連携のセットアップページは、TeamsクライアントでMicrosoft Public Developer Previewを有効にすることを前提条件に挙げています。Microsoft LearnのTeamsプレビュー機能の説明では、公開プレビューへの参加は管理者ポリシーで制御できるとされています。アプリが見つからない、またはメンションできない場合は、アプリの許可とあわせて公開プレビューの参加設定を確認してください。
Teamsから不具合修正を頼む流れ：通知からプルリクエストまで
GitHubが示した代表例は、「不具合の報告がTeamsへ届き、@GitHubへ調査と修正を頼み、チームが提案を確認する」という流れです。実務では次の5段階に分けると、Copilotの役割と人の役割が混ざりません。
1．不具合の通知をTeamsで受け取る
統合版GitHubアプリは、Issueやプルリクエストなどの通知をTeamsへ届けます。GitHub Docsでは、Issue、プルリクエスト、既定ブランチへのコミット、コメント、デプロイ、リリースなど、購読する通知を調整できます。GitHub Actionsのワークフロー通知には追加権限が必要で、初回購読時に権限付与を求められます。
2．同じ会話で対象と完了条件を伝える
通知が届いたスレッドで@GitHubとメンションし、調べてほしい現象、変更してよい範囲、対象リポジトリ、必要ならベースブランチを伝えます。GitHub Docsが示す形式では、repo=OWNER/REPO_NAMEとbranch=BRANCH_NAMEで対象を明示できます。
@GitHub このIssueの再現条件を調べ、原因に対応する変更を提案し、repo=OWNER/REPO_NAME branch=BRANCH_NAME を基準にプルリクエストを作成してください。変更対象外のファイルには触れず、確認した内容を説明してください。
上の文は運用例です。GitHubがこの日本語文面を公式テンプレートとして提供しているわけではありません。大切なのは、リポジトリとブランチ、調査対象、変更範囲、成果物を曖昧にしないことです。
3．Copilotが会話の文脈を使って作業する
Copilotは、リンクされたIssueやプルリクエストだけでなく、会話スレッド全体を判断材料として使います。Teamsではインライン画像、転送メッセージの文脈、チャンネルやスレッドの履歴も扱えるとGitHubは説明しています。作業はcloud sandboxで非同期に進み、対象リポジトリ、Issueまたはプルリクエストへのリンク、モデル、状態や要約がTeamsに表示されます。
裏返すと、スレッド内の情報が作業成果物の文脈に含まれます。関係のない機密情報や別案件の会話が混じるチャンネルでは依頼せず、必要な文脈だけを含む新しいスレッドまたは個人チャットを使う判断が必要です。GitHub Docsも、文脈を絞りたい場合はGitHubアプリへのダイレクトメッセージを検討するよう案内しています。
4．プルリクエストの提案を受け取る
Copilotは変更をプルリクエストとして提案し、同じスレッドで追加修正を頼めます。ただし、Copilot cloud agentが直接既定ブランチへ反映する流れではありません。1回のタスクで作業するのは1ブランチ、作成するプルリクエストは1件です。
5．人がレビュー・テスト・マージする
担当者は差分、テスト結果、影響範囲、セキュリティ上の懸念、既存のリポジトリルールを確認します。GitHub自身も、エージェントのログは人によるレビューとテストの代わりにならず、生成されたコードには誤りや安全上の問題が含まれる可能性があると説明しています。マージ権限をCopilotへ委ねたと考えず、既存の承認フローを通してください。
使う前に確かめること：プラン・管理設定・権限・レビュー体制
2026年10月25日時点のGitHub Docsでは、Teams連携のCopilot cloud agentはすべての有料Copilotプランで利用でき、機能は公開プレビューです。公開プレビューのため、仕様が変わる可能性があります。料金額や無料枠の可否は、このTeams連携ページだけでは確定できないため、この記事では金額を書きません。
GitHub Docsが前提として明記しているTeams側の条件は、Teamsアカウントを持っていることです。必要となるMicrosoft 365の具体的なプラン名は、2026年10月25日時点で今回確認した公式ページからは確認できていません。
| 確認項目 | 公式に確認できる条件 | 社内で決めること |
|---|---|---|
| Copilotプラン | すべての有料Copilotプラン。Teams連携は公開プレビュー | 対象者に有料Copilotへのアクセスがあるか |
| GitHub組織設定 | BusinessとEnterpriseではCopilot cloud agentが既定で無効。管理者による有効化が必要 | 全リポジトリを許可するか、選択したリポジトリだけにするか |
| cloud sandboxes | Teamsからcloud agentを使う前提条件。組織またはEnterpriseの所有者による設定が必要な場合がある | どの組織・リポジトリで利用を認めるか |
| リポジトリ権限 | コード変更を開始できるのは対象リポジトリへのwrite権限がある利用者。会話参加者は入力できる | 依頼者とレビュー担当者を分けるか、誰にwrite権限を付けるか |
| ゲストと外部協力者 | TeamsのゲストとGitHubリポジトリのoutside collaboratorは、セッションを開始または誘導できない | 社外参加者を含む会話でどこまで情報を共有するか |
| Teamsのアプリ管理 | 組織全体、個別アプリ、利用者ごとのポリシーなどで許可が必要。管理方式はテナントの移行状態で異なる | 許可する利用者またはグループ、問い合わせ窓口 |
| レビュー | 共有会話ではCopilotのアプリIDで成果物を作成。既存ルールセットが1件以上の承認を要求する場合、既定で追加の承認が必要 | コードオーナー、テスト担当、マージ担当、緊急時の停止方法 |
統合版GitHubアプリが求める権限を確認する
統合版を「通知を読むだけのアプリ」として承認しないことも重要です。GitHubのTeams連携の権限リファレンスでは、Teams側で利用者とGitHubアプリ間のプライベートな会話へのアクセス、GitHubリンクのプレビュー、@GitHubコマンド、アプリ名義のメッセージ投稿などが示されています。
GitHub側では、Issue、メタデータ、プルリクエスト、Discussions、リポジトリプロジェクトの読み取り、コードの読み取りに加え、Actions、Issue、プルリクエストへの書き込みが含まれます。Copilot cloud agentを使う場合は、プルリクエストを開くためのContentsへの書き込みと、セッションを開始するためのWorkflowsの読み書きも必要です。情シスとGitHub管理者は、通知用途とコード変更用途を分けて権限を確認してください。
既定リポジトリは「便利な初期値」ではなく作業範囲
GitHub Docsでは、チャンネルに既定リポジトリが設定されていない場合、最初のセッションで使ったリポジトリがそのチャンネルの既定になります。その後、リポジトリやブランチを指定しない依頼は、チャンネルの既定リポジトリと、そのリポジトリの既定ブランチを使います。個人チャットには既定リポジトリを設定できません。
そのため、チャンネル名と担当システムが一致していても、依頼時には対象リポジトリを明記する運用が安全です。複数プロダクトの話題が混ざるチャンネルでは、@GitHub settingsで既定リポジトリを確認する担当者を決め、誤ったリポジトリへの依頼を防ぎます。
個人チャットと共有会話では実行主体が違う
個人チャットでは、Copilotは接続したGitHub個人アカウントの権限でIssueやプルリクエストを作成します。チャンネルやグループスレッドなどの共有会話では、Copilotは個人ではなくアプリのIDで成果物を作ります。監査時に「誰の権限で始まり、誰のIDで成果物が作られたか」を説明できるよう、利用形態を運用ルールへ含めてください。
Slack版との違い：公式に書かれた範囲だけを比べる
Slack版とTeams版は、@GitHubへのメンション、会話文脈の利用、有料Copilotプラン、write権限、cloud sandbox、Issueやプルリクエストの作成といった中核部分が共通です。10月15日に発表された複数リポジトリ対応も、SlackとTeamsの両方が対象です。
| 観点 | Microsoft Teams | Slack |
|---|---|---|
| 会話から使える文脈 | インライン画像、転送メッセージ、チャンネルとスレッドの履歴 | 対応するファイル、添付、メッセージリンク、共有メッセージとスレッド |
| 作業セッションの見せ方 | Teams内に対象リポジトリ、Issueまたはプルリクエスト、モデル、状態や要約を表示 | タスクごとに専用の「Slack Code」チャンネルを作り、そこでセッションを誘導 |
| 今回の移行期限 | 旧GitHubアプリは11月16日終了。統合版GitHubアプリへの入れ替えが必要 | 10月23日の発表はTeams向け旧アプリの終了を案内しており、Slack版の同じ終了期限は記載していない |
SlackとTeamsの優劣を示す公式な性能比較や、同じ依頼に対する修正品質の差は、2026年10月25日時点で公式に確認できていません。選定時は、現在の会話基盤、管理ポリシー、保持される会話文脈、レビューの流れで判断してください。SlackとGitHubを組み合わせた別のアプローチは、BuzzのSlack・GitHub連携を扱った記事でも整理しています。
導入時に起こりやすい3つの行き違い
行き違い1：通知アプリも11月16日に終わると思う
❌ GitHub notificationsを削除し、通知設定を最初から作り直す。
⭕ GitHub notificationsは最新版へ更新し、旧GitHubアプリだけを統合版へ入れ替える。
GitHubは、既存のGitHub notifications利用者について、最新版へ更新すれば現在の通知機能が継続すると案内しています。アプリ名を確認せずに削除しないでください。
行き違い2：Teamsで許可すればすぐコード変更を頼めると思う
❌ Teams管理センターでアプリを許可しただけで準備完了とする。
⭕ Teamsのアプリ許可、GitHubアカウント接続、有料Copilotへのアクセス、Copilot cloud agent、cloud sandboxes、対象リポジトリへのwrite権限を分けて確認する。
管理主体がTeams情シスとGitHub組織管理者に分かれる会社では、チェック項目と担当者を1枚の運用表にまとめると抜けを見つけやすくなります。
行き違い3：Copilotが修正からマージまで終えると思う
❌ 通知へ返信した後は、人が確認しなくても本番へ反映されると考える。
⭕ Copilotの成果物を提案プルリクエストとして扱い、コードオーナーが差分をレビューし、テスト担当が確認し、権限を持つ人がマージする。
GitHubの発表も、最後の段階をチームによるレビュー・テスト・マージとしています。Copilotは作業開始と提案作成を短くする仕組みであり、変更責任を引き受ける仕組みではありません。
関連するCopilot管理の記事
Teamsから依頼できるようにした後は、「誰がどの機能を使っているか」と「どのモデルを許可するか」が管理テーマになります。次の記事もあわせて確認してください。
- Copilot利用状況APIでMCP・エージェント名を把握する方法：組織で使われるカスタムエージェントやMCPの利用状況を確認する観点を整理しています。
- CopilotモデルポリシーAPIで一括管理する方法：Enterprise、組織、チーム単位でモデルポリシーを扱う更新をまとめています。
- BuzzのSlack・GitHub連携を扱った記事：会話と開発作業をつなぐ別の製品設計を確認できます。
よくある質問
Q1．11月16日に終了するのはどのアプリですか？
終了するのは旧GitHubアプリで、今後「GitHub (deprecated)」と表示されるアプリです。GitHub notificationsを導入済みの場合は、統合版の最新版へ更新すれば、既存の通知機能は継続するとGitHubが案内しています。
Q2．Teamsから依頼すると、Copilotが自動でマージしますか？
いいえ。GitHubが示す流れは、Copilotが不具合を調べ、修正を提案し、プルリクエストを作成するところまでです。その後はチームがレビュー、テスト、マージします。生成コードに誤りや脆弱性が含まれる可能性もあるため、人の確認を省略しないでください。
Q3．どのCopilotプランで使えますか？
2026年10月25日時点のGitHub Docsでは、すべての有料Copilotプランで利用でき、機能は公開プレビューです。BusinessとEnterpriseではCopilot cloud agentが既定で無効のため、管理者の有効化が必要です。個別の料金額はTeams連携ページで確認できないため、契約画面または最新の公式料金ページを確認してください。
Q4．誰でもTeamsから修正を開始できますか？
コード変更を開始できるのは、対象リポジトリへのwrite権限があり、Copilot cloud agentを利用できる人です。会話の参加者は入力できますが、TeamsのゲストとGitHubリポジトリのoutside collaboratorはセッションを開始または誘導できません。さらにTeams側でGitHubアプリが許可されている必要があります。
Q5．1つの会話で複数リポジトリを直せますか？
1つの会話で複数リポジトリを参照し、対象を切り替えながら調査やIssue作成を頼めます。ただし、Copilot cloud agentが1回のタスクで変更できるのは1つのリポジトリで、作成できるプルリクエストも1件です。複数リポジトリに変更が必要なら、タスクを分けてください。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Turn notifications into code with GitHub Copilot in Teams — GitHub Changelog、2026年10月23日公開、2026年10月25日参照
- Multi-repository support and other improvements for GitHub in Slack and Teams — GitHub Changelog、2026年10月15日公開、2026年10月25日参照
- Updates to GitHub Copilot for Slack and Microsoft Teams — GitHub Changelog、2026年9月25日公開、2026年10月25日参照
- Integrating Copilot cloud agent with Teams — GitHub Docs、2026年10月25日参照
- Integrating Copilot cloud agent with Slack — GitHub Docs、2026年10月25日参照
- Adding GitHub Copilot cloud agent to your organization — GitHub Docs、2026年10月25日参照
- GitHub Copilot on GitHub.com — GitHub Docs、2026年10月25日参照
- Customizing notifications for GitHub in Teams — GitHub Docs、2026年10月25日参照
- Manage app permission policies in Microsoft Teams — Microsoft Learn、2026年10月25日参照
最後に確認すべきこと
11月16日までに必要なのは、全社一律の再設定ではありません。まずTeamsに入っているアプリを確認し、GitHub notificationsなら更新、旧GitHubアプリなら統合版への入れ替えを進めます。そのうえで、Teamsのアプリ許可、Copilot cloud agent、cloud sandboxes、対象リポジトリ、write権限を順に確認してください。
運用開始前には、依頼できるリポジトリ、チャンネルの既定リポジトリ、会話へ載せてよい情報、プルリクエストのレビュー担当、テスト担当、マージ担当を決めます。Copilotが作業を始めやすくなっても、変更を採用する責任はチームに残ります。
AIエージェントの導入範囲やレビュー体制を整理したい方へ
Uravationでは、AIエージェント導入の研修・コンサルティングを行っています。
