はじめに
こんにちは！GitHub Copilot User Group Japan の運営をしている横浜情報機器株式会社インターン生のロホマン シャヒンです！
2026年9月25日に Teams / Slack 版 GitHub Copilot のアップデートが出て、「チャットの会話コンテキストを Copilot が読む」という触れ込みだったので、検証用リポジトリを用意して Teams から全部試してきました。社内からも「Teams から Issue とか立てられるらしいけど、ウチで使えるの？」と聞かれることが増えてきたタイミングでもあります。
触ってみた結論として、これは企業で使うと化ける機能です。その理由を、実機検証と活用事例で整理してみました。
1. 9月25日アップデートの要点
まず今回のアップデート内容を表で整理します。公式の changelog はこちらです。
| カテゴリ | 内容 |
|---|---|
| コンテキスト強化 | Teams でインライン画像・転送メッセージ・チャネル/スレッド履歴を読めるように。Slack はファイル・添付・メッセージリンクが対象 |
| コントロール強化 | 次のメッセージからモデルを切り替え可能に。選択は会話中ずっと維持される |
| 作業との紐付け | Issue 作成前に類似 Issue を自動チェック。成果物と元スレッドを相互リンク |
| 信頼性向上 | 長時間タスクの進捗表示、中断・再接続の改善、Teams での重複回答の抑制 |
これまでは「メンションしたらエージェントが動く」だけだったのが、今回で「目（画像・転送メッセージ）」と「記憶（スレッド履歴）」が追加されました。文章で言うと地味ですが、実際に使うと体感がかなり変わります。
なお、本機能は 2026年9月30日時点でパブリックプレビューです。対象は GitHub Copilot Business / Enterprise の組織で、機能によっては段階的ロールアウト中のため、自テナントでまだ使えないものもあります。
2. そもそも Teams/Slack の Copilot 連携とは
土台のおさらいです。2026年8月21日に「Shared agentic work with GitHub Copilot in Microsoft Teams」がパブリックプレビューとして公開されました。
やってくれることはシンプルで、Teams のチャネルやスレッド、DM
で @GitHub とメンションするだけで Copilot
クラウドエージェントのセッションが始まるというものです。
企業利用で効いてくるポイントを絞ると：
- 会話に参加している全員がエージェントの調査・作業を見られる
- リポジトリへの書き込み権限を持つ人だけが変更作業を指示できる（ゲストや outside collaborator は不可）
- 作業は GitHub ホストのセキュアなクラウドサンドボックスで非同期に進行する
- Teams で始めたタスクは、あとからターミナル・GitHub Copilot アプリ・IDE で続きを触れる
「会議中に出たアクションアイテムを、その場で @GitHub
に投げる。会議が終わる頃には調査が終わっている」という使い方が公式でも推奨されていて、実際やってみるとこれが思ったより快適でした。
3. 実機検証：Teams から全部試してみた
ここからは実機での検証レポートです。検証用リポジトリとして
YJK-Inc/Test-Repo を用意し、Python
の在庫管理スクリプトにデモ用の ZeroDivisionError
バグをわざと仕込んであります。
セットアップとデフォルトリポジトリ
Teams のチャネルで @GitHub
とメンションすると、アカウント連携の案内が出ます。このメッセージは自分にだけ表示されるタイプなので、チャネルのメンバーには見えません。ブラウザで数クリック連携するだけでした。
その後 @GitHub settings
でこのチャネルのデフォルトリポジトリを YJK-Inc/Test-Repo
に変更。ここで「以前の会話で別リポジトリを選択した名残が残っていた」という通知が出たんですが、これが後で効いてきます（伏線です）。
README 更新を依頼 → PR が自動作成
まずは軽めのタスクから。「README を最新の構成に更新して」とだけ投げました。
すぐにタスクが分解されて進捗バーが出ます。右上にモデル名のバッジが出るのも分かりやすい。しばらくして GitHub 側を見ると PR が作られていて、説明文には 「Created from a Microsoft Teams conversation.」 と明記されていました。会話から PR へのトレーサビリティが自動で残るのは、あとで監査するときに効いてきます。
トレースバックを貼って「このエラー直して」→ まさかの展開
本番です。ZeroDivisionError
のトレースバックをスレッドに貼って「このエラー直して」と依頼しました。
返ってきたのは予想外の回答でした。
要約すると、
- トレースバック自体は正確に解析済み（
app/main.pyのcalculate_total_priceでquantity == 0のときに100 / quantityが走っている、と行レベルで特定） - ただしこのスレッドは古い方のリポジトリに接続されたままで、該当ファイルが見つからない
- 「チャネルのデフォルトは Test-Repo に変わっていますが、このスレッドは古い方のままです」と状況を説明した上で、切り替えるか、そのまま進めるかの選択肢を提示してくれた
さっきの伏線の回収です。スレッド単位でリポジトリが紐づく仕様なので、古いスレッドは前のリポジトリを見たままだったわけですね。勝手に見当違いの場所を探しに行かず、状況を説明して確認を取ってくる。正直なところ、ここが今回の検証で一番感動しました。
「切り替えて」と返すと、即座にリポジトリを切り替えて修正まで完走。報告には原因・修正内容・動作確認までフルセットでした。
ちなみに画像添付の解析も試したんですが、初回は「読み取れませんでした」とエラーが出て、添付し直したら成功しました。画像の中身を正確に読み取った上で「これは PR #1 で既に修正済みの内容です」とまで答えてくれました。段階ロールアウト中の機能なので、初回でエラーが出ても再送するのがコツです。
転送した要件メッセージから Issue を自動生成
次はコンテキスト読解の本領発揮です。「在庫 0 の商品でもエラーにならないようにしてほしい」「税込み金額は整数で表示したい」という要件のやり取りを転送・引用した上で、「この内容を踏まえて Issue を立てて」と依頼しました。
返ってきたのは「Issue を作成しました。重複する既存 Issue はありませんでした」との報告。さらに「これらは既に PR #1 で修正済みであることも Issue 本文に記載しています」とのこと。前の修正と今回の要件を頭の中で繋げてくれています。Issue 本文は「内容 → 背景 → 対応」の3段構成で、エンジニアが読んでそのまま判断できる粒度でした。
モデル切り替えと重複 Issue の検出
最後に2つまとめて。まずモデル切り替え。「Change可能なモデル一覧を出して」と聞くと、自分にだけ見える選択プロンプトが出ました。
一覧を開くと、Claude 系・GPT 系に加えて
MAI-Code-1.1-Flash や Kimi K3
まであって、マルチベンダーの模型店と化しています。MAI-Code-1.1-Flash
に切り替えたあと、会話の終盤まで選択が維持されていることをバッジ表示で確認できました。
そして、さっき作った Issue とほぼ同じ内容をわざと依頼してみると、「同内容の Issue はすでに作成済みです。重複を避けるため新規作成はしません」と新規作成をストップしてくれました。類似 Issue チェック、ちゃんと効いています。
4. 企業導入で効く活用事例
実機検証を踏まえて、「これ企業でどう使うの？」を具体例で整理します。私が実際に効くと思った順です。
事例① 定例会議のアクションアイテムを、その場で Issue 化
定例の開発会議で「この件、来週までに調べておいて」という話が出たら、議事録係が会話中に
@GitHub へ要件を転送して Issue
化まで済ませられます。会議が終わる頃には調査が終わっている、という流れです。
議事録に書き留めて、あとで誰かが Issue に起こす、という二度手間がまるごと消えます。これが一番導入効果を実感しやすい場面だと思います。
事例② 障害報告チャネルに貼られたトレースバックから修正 PR
障害対応チャネルにユーザー報告のトレースバックが貼られたら、その場で「このエラー直して」。検証で試したとおり、行レベルで原因を特定して修正 PR まで作ってくれます。しかも「Created from a Microsoft Teams conversation」の記録が残るので、あとから「なぜこの修正が入ったか」を辿れます。
障害対応の初動が「調査」から「レビュー」に変わるイメージです。
事例③ 情シスへの依頼受付をスレッドで完結させる
情シスや開発部門への依頼って、チャットにバラバラに流れて拾い漏らしが起きがちです。転送メッセージを読めるようになったおかげで、「さっき別チャネルで来た依頼だけどこれ Issue にして」と転送して投げるだけで、内容・背景・対応の3段構成で整形されます。類似 Issue チェックも効くので、重複起票の乱立も防げます。
事例④ 非エンジニアからの要望をエージェントが「翻訳」する
営業やカスタマーサポートから来る「ここが動かない」という曖昧な報告も、スクリーンショット付きで Teams に貼ってもらえば、画像を読み取ってエンジニアが読める形式に落としてくれます。非エンジニアと開発の間の通訳として使えるのは、組織が大きいほど効くポイントです。
5. 情シス視点：ガバナンスとセキュリティ
「便利なのは分かった、でも管理は？」という情シス目線の論点を整理します。ここは稟議でそのまま使えるレベルで押さえておきたいところです。
権限モデルは既存の GitHub 権限を逸脱しない
変更作業を指示できるのはリポジトリへの write 権限を持つユーザーのみです。DM では個人アカウントの権限、共有チャネルでは app identity で動作し、ゲストメンバーや outside collaborator はセッションの開始・舵取りができません。Teams から使えるようになったからといって、権限の穴が広がるわけではない設計です。
PR の追加承認がデフォルトで有効
Teams 連携経由で作られた PR には、追加の承認を必須にする ruleset が用意されています。承認 2 人必須のリポジトリなら、Copilot 作成の PR は 3 人必要になる計算です。「エージェントが作ったものには人間の目を必ず通す」という統制が標準で入っているのは安心材料です。
作業はセキュアなクラウドサンドボックスで実行
エージェントの作業は、完全分離・エフェメラルな Linux 環境（Azure Container Apps の Sandboxes 基盤）で実行されます。ファイアウォールはデフォルト有効で、推奨許可リストによるエグレス制御もあるので、データ流出リスクを抑えた設計になっています。
注意点：スレッド全体がコンテキストになる
一方で注意点もあります。スレッド全体がコンテキストとして取得され、成果物に保存される仕様なので、機微情報を含む会話で使うのは避けて、そういう用途は DM に寄せるのが無難です。ここは運用ルールとして決めておくといいと思います。
よくある混同：M365 Copilot の GitHub コネクタとは別物
ちなみに、Microsoft 365 Copilot にも「GitHub コネクタ」がありますが、あれは GitHub の Issue/PR データを M365 Copilot の検索インデックスに取り込む機能で、今回の「コードを書いて PR まで作るエージェント」とは別物です。社内で話がすれ違いやすいので、先に区別しておくと楽です。
6. コストとライセンス
コスト面も整理しておきます。せっかちな人（私含む）が真っ先に気にするところです。
- 対象プランは GitHub Copilot Business / Enterprise
- Teams/Slack から起動したクラウドエージェントは、既存の AI クレジットを消費します。付与量は Business が 1,900、Enterprise が 3,900（ユーザー/月）で、1 クレジット = $0.01。課金エンティティ単位でプールされ、毎月リセットです
- クレジット超過時の追加使用はデフォルトで有効（従量課金）。止めたい場合は管理者が「AI credits paid usage」ポリシーを明示的に無効化します。予算はユーザーレベル／コストセンター／エンタープライズ上限／組織レベルの 4 層で設定可能
- クラウドサンドボックスの利用は別途課金（Compute・Memory・Storage の 3 メーター）。プレビュー期間の $10/月 entitlement は 2026年7月末で終了済みなので、現在は全量課金です。AI クレジットの予算とは別系統で、プロダクト/SKU 単位の予算で制御します
「Teams から気軽に呼べるようになった分、使いすぎ注意」ではあるんですが、予算管理の枠組みが既存のものに乗るので、運用でカバーできる範囲だと判断しました。導入時に予算上限だけ先に設定しておくのがおすすめです。
7. 導入手順（管理者向け）
導入手順はシンプルです。管理者側の作業を先に済ませるのがポイントです。
- 管理者が Copilot cloud agent ポリシーとクラウドサンドボックスを有効化する（Business/Enterprise はデフォルト無効なので、ここが最初の関門です）
- GitHub app for Microsoft Teams をインストール（またはアップグレード）する
- Teams で
@GitHubとメンションして、案内に従い GitHub アカウントを連携する - パブリックチャネルでは
@GitHub settingsでデフォルトリポジトリを設定する（DM では不要） @GitHubに続けてタスクを書いて送信。@GitHub helpでコマンド一覧も確認できます
Slack の場合もほぼ同じ流れです。ポリシー有効化 → GitHub app for Slack
のインストール → アカウント連携 → @GitHub
メンション、という順番になります。
8. まとめ
実際に全部試した上で、導入判断の軸になりそうな点をまとめます。
- 会話のコンテキスト読解は本物。トレースバックの行特定、転送要件からの Issue 化、会話履歴を踏まえた補足まで、ちゃんと拾って動く
- リポジトリ不一致を検出して対話で切り替える挙動が思ったより賢かった。見当違いの場所を勝手に探しに行かないのは、企業利用で大事な信頼性です
- 会議 → Issue → PR → レビューの流れが Teams で完結する。議事録からの転記という二度手間が消えるのが一番の導入効果だと思います
- ガバナンスは既存の GitHub 権限モデルに乗る設計。write 権限者のみ変更指示可能、PR 追加承認がデフォルト有効と、統制面も抜かりない
- コストは AI クレジット＋サンドボックス課金の 2 系統。導入時に予算上限を設定しておけば、使いすぎの心配は運用でカバーできます
「メンションしたら動くエージェント」に「目と記憶」が実装されつつあるのを、実機で体感できた検証でした。パブリックプレビューのうちに社内で試して、GA 後の本格展開に備えるのはアリだと思います。
この記事が少しでも参考になったら、ぜひシェアしていただけると嬉しいです！
出典
- Updates to GitHub Copilot for Slack and Microsoft Teams – The GitHub Blog（2026年9月25日）
- Shared agentic work with GitHub Copilot in Microsoft Teams – The GitHub Blog（2026年8月21日）
- Integrating GitHub Copilot cloud agent with Microsoft Teams – GitHub Docs
- Integrating Copilot cloud agent with Slack – GitHub Docs
- Usage-based billing for organizations and enterprises – GitHub Docs
- Billing for cloud and local sandboxes – GitHub Docs
- About cloud and local sandboxes – GitHub Docs