GitHub Copilot の Slack・Teams 連携で 2026 年 9 月に何が新しくなりましたか？

2026 年 9 月 25 日、GitHub はコンテキスト拡大 (Better context)・操作性向上 (More control)・信頼性改善 (Bug fixes and reliability improvements) の 3 系統でアップデートを発表しました。Slack はファイル・添付ファイル・メッセージリンクをコンテキストに使え、Teams は画像・転送メッセージ・履歴を扱えます。会話内でのモデル切り替え、似た既存 Issue のチェック、長時間タスクの処理改善も含まれます。いずれも 8 月 21 日発表の基本機能に乗る追加更新です。

GitHub Copilot の Slack でモデルを切り替えるとどう反映されますか？

公式発表は「次のメッセージ以降のモデルを切り替えられ、その選択が会話全体で保持される」と説明しています。IDE や CLI で使われる Auto の Efficiency・Balance・Intelligence ティアとは別の仕組みで、あちらは自動選択、こちらは会話内での手動切り替えです。

同じ報告で重複した Issue が作られる問題は解消されましたか？

新しい Issue を作る前に、似た既存 Issue をチェックする仕組みが追加されたと公式発表にあります。ただし判定基準や、誤って重複と判定した場合の挙動は一次情報に記載がありません。完全に無くなるとは断定できず、人によるトリアージは引き続き必要と考えるのが安全です。

今回のアップデートはどのプランで、いつから使えますか？

public preview として、GitHub Copilot Business・Enterprise プランの組織向けに提供されています。利用は既存の Copilot entitlement に算入され、既存の Copilot cloud agent budget で管理できます。一部の機能は順次展開されるため、組織によって見えるタイミングが異なる可能性があります。具体的な展開スケジュールは公式発表に記載がありません。

すでに Slack・Teams 連携を導入している場合、設定変更は必要ですか？

公式発表には、導入済みの利用者側で追加の設定変更が必要という記載はありません。順次展開されるため、機能が反映されるタイミングは組織によって異なる可能性があります。一方で、重複 Issue の発生状況やモデル切替の運用は、導入時に決めたルールのまま通用するか見直す価値があります。

GitHub Copilot の Slack 連携と Teams 連携の基本的な使い方はどこで確認できますか？

起動方法、対象プラン、権限、課金、PR の追加承認といった基本機能は、2026 年 8 月 21 日発表を扱った既存記事で解説しています。本記事は、その基本機能の上に 9 月 25 日発表で追加されたコンテキスト拡大・モデル切り替え・重複 Issue チェック・信頼性改善だけを扱います。

GitHub Copilot Slack・Teams 連携｜9 月 25 日アップデート

GitHub Copilot の Slack・Teams 連携に何が追加されたのか

GitHub は 2026 年 9 月 25 日、Slack・Microsoft Teams 版 GitHub Copilot のアップデートを発表しました。対象は、Slack と Microsoft Teams から GitHub Copilot を使う連携そのものではなく、その上に乗る追加更新です。基本機能 (起動方法、対象プラン、権限、課金、PR の追加承認) は 2026 年 8 月 21 日の発表で説明されています。

今回追加されたのは、公式発表が示す次の 3 系統です。

Better context (コンテキスト拡大): Slack と Teams でエージェントに渡せるコンテキストの範囲が広がった
More control (操作性向上): 会話の途中でモデルを切り替えられ、Slack では既定のオーナー・リポジトリを設定できる
Bug fixes and reliability improvements (信頼性改善): 長時間タスクの処理、Teams のチャンネル履歴、Slack のリポジトリ切り替えなど信頼性面の改善

まだ 8 月発表の基本機能を導入していない場合は、先に基本機能の解説記事で起動方法とプランを確認してから、本記事の内容を追加更新として読むと迷いにくくなります。すでに導入済みで、何が改善されたかを知りたい場合は、このまま読み進めてください。

補足

発表記事に記載がないことは、その機能が使えないという意味ではありません。今回の発表も、記載の有無と製品仕様の差を分けて読む必要があります。

コンテキストが増えた範囲

Slack と Teams では、エージェントに渡せるコンテキストの範囲がそれぞれ広がりました。公式発表の記載は次のとおりです。

チャット基盤	増えたコンテキスト
Slack	サポートされているファイル、添付ファイル、メッセージリンク
Microsoft Teams	インライン画像、転送メッセージの文脈、チャンネル・スレッドの履歴

さらに両方の基盤に共通して、次の 2 点が挙げられています。

成果物への直接リンクを含める
元の会話へのリンクを保持する

会話に貼ったファイルや転送されたメッセージの経緯も、公式発表の範囲でコンテキストとして扱えるようになりました。

FIXIT

ファイルや画像まで渡せるなら、社内の機密情報もそのまま読ませちゃっていいの？

Tsumiki

範囲が広がったのは公式発表どおりです。でも渡していい情報かは別問題で、境界は自社で決める必要がありますよ。

コンテキストに使える範囲が広がったぶん、Slack・Teams に流れてくるファイルや添付、転送メッセージのうち、どこまでを Copilot に渡してよいかの判断が重くなります。生成 AI の情報漏えい対策で扱っている入力してよい情報の境界は、この更新後にあらためて確認しておくとよい観点です。

似た既存 Issue をチェックする仕組み

公式発表は「新しい Issue を作る前に、似た既存 Issue をチェックする」という一文でこの機能を説明しており、Better context の見出しの中で挙げています。会話から @GitHub にメンションして Issue 化できる以上、同じ話題で複数人が別々に依頼すれば Issue は重複しえます。その対策として読める更新です。

ただし、次の点は公式発表・Docs のいずれにも記載がありません。

「似ている」と判定する基準
誤って重複と判定した場合の挙動 (無視されるのか、確認を求められるのか)

判定の中身が分からない以上、この仕組みだけで重複 Issue が無くなると断定しないのが安全です。トリアージ担当者による目視確認は、引き続き運用に残しておく前提で考えてください。

モデル切り替えと Slack の既定設定

More control の柱の 1 つが、会話内でのモデル切り替えです。公式発表は次のように説明しています。

次のメッセージ以降のモデルを切り替えられる
その選択は会話全体で保持される

会話の途中で「ここからは別のモデルで進めたい」というときに、次のメッセージから切り替え、それ以降の会話でもその選択を保持する、という説明です。切り替え前の回答がどう扱われるかについて、公式発表に記載はありません。

Slack ではもう 1 つ、既定のオーナーとリポジトリを設定できるようになりました。Slack の連携 Docsには、「既定リポジトリは Copilot が応答時に使う文脈を提供する」という説明があります。毎回のメンションでリポジトリを指定する手間を減らし、複数リポジトリ・複数の共有会話をまたいで作業を進めやすくする位置づけです。

コツ

既定リポジトリは「指定を省略できる」設定であり、指定を上書きできない制約ではありません。チャンネルごとに主に触るリポジトリが決まっているなら、先に設定しておくと依頼のたびの手間が減ります。

IDE の Auto ティアとの違い

GitHub Copilot には、IDE や CLI 向けに Auto のモデル選択を Efficiency・Balance・Intelligence の 3 ティアに分けた仕組みが別にあります。詳細はGitHub Copilot の自動モデル選択の記事で解説していますが、あちらはタスクの特性に応じて Copilot 側が自動でモデルを選ぶ仕組みです。

今回の Slack・Teams のモデル切り替えは、これとは別物です。利用者が会話の中で明示的に指定し、次のメッセージから反映されるという手動の切り替えです。「自動で選ばれる基準を知りたい」なら Auto ティアの記事、「会話の途中で自分から切り替えたい」なら本記事の範囲、と分けて捉えてください。

信頼性の改善点

公式発表は Bug fixes and reliability improvements の中で、両基盤に共通する改善と、Teams 固有・Slack 固有の改善を挙げています。

系統	改善点
共通	長時間タスクの処理、実装計画のステータス表示、中断・古い返信への対応、会話がアイドルになったときの再接続動作、タスク停滞・接続中断・アクセス設定の問題時のメッセージ精度
Teams 固有	チャンネル・スレッド履歴の保持、重複回答の回避、Teams で変換された画像の処理、user-owned リポジトリ・大規模チャンネルでの動作の一貫性
Slack 固有	実装計画の復旧、リポジトリピッカーと code channel の不具合修正、リポジトリ切り替えの安全性 (置き換えられた古いセッションが旧リポジトリで継続しない)

共通系の改善は、長時間タスクを Slack・Teams から依頼したときの進捗表示や、会話がアイドルになったあとの再接続動作に関わる内容です。個々の改善が具体的にどの程度の効果を持つかまでは、公式発表に数値の記載はありません。

提供状況と対象プラン

今回のアップデートの提供状況は、次のように発表されています。

public preview として提供
対象は GitHub Copilot Business・Enterprise プランの組織
利用は既存の Copilot entitlement に算入され、既存の Copilot cloud agent budget で管理できる
一部の機能は 順次展開 (rolling out gradually) される

9 月 25 日の発表は、Slack・Teams を区別せず、Business・Enterprise 向けで既存 entitlement と cloud agent budget で管理すると説明しています。一方、8 月 21 日の Teams 版の発表は、有料の Copilot プラン向けで、Teams から始めたセッションは AI クレジットを消費すると説明していました。Teams の課金方式が変わったのかどうかは今回の発表に明記がないため、Teams で使っている組織は契約中のプランと請求設定を確認してください。

順次展開という記載から分かるのは、「組織によって機能が見えるタイミングが異なる可能性がある」ということまでです。具体的な展開スケジュールは公式発表に記載がなく、本記事でも推測を書きません。自分の組織にまだ来ていない機能があっても、それが不具合だと断定しないでください。

注意

費用面では、既存 entitlement・cloud agent budget に算入されると明記されている一方、モデル切り替えそのものによる消費量の変化は公式発表に記載がありません。AI クレジットの単価や消費量を試算する材料は、今回の一次情報には含まれていません。

導入前提の確認 (Get started)

導入の前提は、Slack・Teams それぞれ 3 ステップで説明されています。

Slack

管理者が Copilot cloud agent ポリシーを有効化する
Slack 用 GitHub App をインストール、または既存のアプリをアップグレードする
利用者が GitHub アカウントを連携し、@GitHub にメンションする

Microsoft Teams

管理者がクラウドエージェントとクラウドサンドボックスを有効化する
Microsoft Teams 用 GitHub App をインストール、または既存のアプリをアップグレードする
@GitHub にメンションし、プロンプトに従って GitHub アカウントを接続する

すでに 8 月時点の基本機能を導入している組織は、多くの場合この前提を満たしています。権限設定、課金の考え方、PR の追加承認といった詳細は、基本機能の解説記事で扱っています。

なお、Copilot Business・Enterprise では、新機能を組織単位で一括有効化するかどうかを決める「新機能の既定ポリシー」という別の管理者向け設定もあります。今回のアップデートは cloud agent のポリシーで管理される話であり、混同しないよう区別しておいてください。

すでに導入している組織が確認すること

ここからは、公式基準ではなく本記事独自の提案です。8 月時点で Slack・Teams 連携を導入し、しばらく運用してきた組織向けに、再評価のチェックリストとして提示します。

確認項目	見るポイント
重複 Issue の発生率	導入直後と比べて、同じ話題での重複 Issue がどの程度減ったか。人によるトリアージをまだ外せない水準だと考えて運用する
モデル切替の誤操作	「次のメッセージから反映」という条件を利用者が理解しているか。切り替えたつもりで実は反映されていない、といった混乱がないか
既定リポジトリの設定	既定が未設定のチャンネルでは、最初のセッションで使ったリポジトリが自動で既定になる。意図しないリポジトリが既定になっていないか。既定はチャンネル全員に共有され、DM では設定できない点も周知したか
コンテキスト範囲の運用ルール	ファイル・添付・転送メッセージまで渡せる範囲が広がったことを踏まえ、渡してよい情報の境界を利用者に周知し直したか
長時間タスクの追跡状況	アイドル後の再接続やタスク停滞時のメッセージが変わったことで、依頼者側の確認手順を見直す必要がないか

FIXIT

8 月に導入したまま放置してたけど、これって設定し直したほうがいいの？

Tsumiki

必須という記載はありません。でも運用ルールが今も合っているか、まず自分たちで確かめてみるのが早いですよ。

いずれの項目も、GitHub の公式発表が示す合格ラインではありません。導入時に決めたルールが、今回の更新後も同じ前提で通用するかを確かめるための、たたき台として使ってください。

まとめ

2026 年 9 月 25 日のアップデートで、GitHub Copilot の Slack・Teams 連携には、コンテキスト拡大 (重複 Issue チェックを含む)・モデル切り替えと Slack の既定設定・信頼性改善という 3 系統の追加が入りました。いずれも 2026 年 8 月 21 日発表の基本機能に乗る更新です。ただし Teams の課金方式が 8 月の説明から変わったかは明記がないため、契約・請求設定を確認してください。

一方で、重複 Issue チェックの判定基準、モデル切り替えによる費用への影響、順次展開の具体的なスケジュールは、今回の一次情報に記載がありません。記載が無い論点を「機能が無い」「まだ来ていないのは不具合」と決めつけず、公式 Docs や自組織の管理者に確認しながら判断してください。

すでに導入済みの組織は、重複 Issue の発生率やモデル切替の運用ルールを見直すタイミングです。導入をまだ検討中の組織にとっては、プレビュー機能に改善が継続的に入っている状況を、判断材料の 1 つに加えられます。

GitHub Copilot をはじめとした AI 開発ツールの運用ルールを整理し、プレビュー機能を本番運用に上げるかどうかを判断したい場合は、AI 開発ツール定着支援で導入状況の診断からガバナンス設計まで支援しています。自社の運用が今の発表内容に合っているか相談したい方は、お問い合わせからご連絡ください。

GitHub Copilot の Slack・Teams 連携がアップデート — コンテキスト拡大・モデル切り替え・重複 Issue チェックを一次情報で確認