@GitHubがSlack・Teamsで一般提供に｜できること・料金・使い方・注意点を整理【2026年11月】

GitHub CopilotをSlackとMicrosoft Teamsの会話から「@GitHub」で呼び出す機能が、2026年11月6日（米国時間、日本時間11月7日早朝）に一般提供（GA）になりました。メンションするとCopilotのクラウドエージェント（cloud agent）が動き出し、バグ調査からIssue作成、実装、プルリクエスト（PR）作成までを会話の中で進められます。

専用の追加料金はありません。ただし有料のCopilotプランが前提で、作業のたびにAI Creditsとクラウドサンドボックスの利用料がかかります。サンドボックスの課金は2026年11月から始まっています。

この記事でわかること

• 一般提供で何が変わったか（Teamsの「Canvas」、リポジトリの自動特定など4点）
• @GitHubでできること、できないこと
• Slack版とTeams版の違い
• 料金のかかり方（AI Credits・クラウドサンドボックス）とプラン別の可否
• Slack・Teamsそれぞれの導入手順
• 権限・情報漏えい・コストの面で、管理者が導入前に決めておくこと

普段の開発のやりとりをSlackやTeamsでしている開発チーム、エンジニアリングマネージャー、Copilotの利用ルールを決める情報システム部門に向けた記事です。2026年11月7日時点のGitHub公式Changelogとドキュメントをもとにしています。

@GitHub in Slack・Teamsとは

出典: GitHub Copilot 公式サイト

「@GitHub」は、チャットの会話をそのままGitHub Copilotへの作業依頼に変える連携機能です。 DM・チャネル・スレッド・グループチャットで呼び出せます。依頼を受けたCopilotは、GitHubが用意する隔離されたクラウド環境（クラウドサンドボックス）で非同期に作業し、結果をPRとして返します。

GitHub Copilot全体の機能やプランは、GitHub Copilotとは？で解説しています。

プレビューから一般提供までの流れ

Slack連携は約1年前から段階的に広がってきました。日付はいずれもGitHub公式Changelogによります。

2025年の記事には「coding agent」「1セッション＝1プレミアムリクエスト」という説明がよく出てきますが、これは旧体系です。現在の名称はcloud agentで、課金は2026年6月からAI Creditsに変わっています。

一般提供で変わった4つのポイント

出典: GitHub Changelog「GitHub Copilot in Slack and Teams is generally available」

GAで加わったのは、Teamsの「Canvas」、リポジトリの自動特定、会話の安定性の改善、作成元の明記の4点です。 機能が大きく増えたというより、プレビュー期に引っかかりやすかった点が直された内容になっています。

Teamsのドキュメントでは、Canvasは読み取り専用で、作業中の計画・ファイル変更・PRの概要を確かめるための画面と説明されています。Canvas上でコードを直接書き換える機能ではありません。

作成元の記載には、元の会話へのリンクまでは含まれないとGitHubコミュニティの投稿で説明されています。経緯を残したい場合は、PRのコメントに要点を書き足す運用にしておくと安心です。

@GitHubでできること

出典: GitHub Changelog「Shared agentic work with GitHub Copilot in Microsoft Teams」

会話から「調べる」「起票する」「直す」「PRを出す」までを頼めます。 公式ドキュメントに挙がっている主な作業は次のとおりです。

• コードやGitHub上の活動についての質問に答える
• バグ報告を整理し、Issueを作成・更新・ラベル付けする（作成前に似たIssueがないか確認する）
• 障害の原因を調べる
• 変更を実装し、クラウドサンドボックスで動作を確かめる
• PRを作成する
• 通知への返信で、失敗したワークフローの調査やPR説明文の作成を頼む

複数リポジトリとモデルの切り替え

1つのセッションで、同じオーナーのリポジトリを最大11個まで扱えます。フロントエンドとバックエンドにまたがるバグの調査や、「全リポジトリで自分が出しているオープンPRの一覧」のような依頼に向いています。

使うAIモデルは会話ごとに切り替えられ、同じスレッドの中では選んだモデルが維持されます。Slackではチャネルごとの既定モデルも設定できます。選べるモデルは提供状況と組織のポリシーによって変わります。

チャネルの既定リポジトリ

@GitHub settings で、チャネルごとに既定のリポジトリを決められます。障害対応チャネルや特定プロダクトのチャネルで設定しておくと、毎回リポジトリを指定する手間が減ります。ただしDMには既定リポジトリを設定できず、既定にできるのは同じオーナーのリポジトリに限られます。変更は新しい会話から反映されます。

会話の文脈をそのまま渡せる

スレッド全体がCopilotへの文脈になります。Slackでは共有メッセージ・ファイル・添付・メッセージリンク、Teamsではインライン画像・転送メッセージ・チャネルやスレッドの履歴も読み取ります。エラー画面のスクリーンショットや、ユーザーからの問い合わせを転送して「これを調べて」と頼めるのが、IDEで依頼するときとの大きな違いです。

チームで1つのセッションを共有する

セッションは会話の参加者全員で共有されます。参加者は誰でも文脈を足したり、方針を変えたり、作業を止めたりできます。ただしコードの変更を頼めるのは、対象リポジトリにwrite権限を持つ人だけです。

このほか、対象リポジトリに設定されたMCPサーバーもセッションで使われます。個人で設定したMCPサーバーが使えるのは、自分が始めたセッションだけです。MCPの基本はGitHub MCP Server 使い方ガイドを参照してください。困ったときは @GitHub help でコマンド一覧を表示できます。

実際の利用シーン

Slack版とTeams版の違い

どちらも中身は同じCopilot cloud agentですが、作業の見せ方が違います。Slackは「Slack Code」の専用チャネル、Teamsは「Canvas」で進捗を見せます。

出典: Slack公式ブログ

Slack Codeは1チャネル＝1タスクで、作業が終わったらアーカイブし、必要なら再開できます。GitHubはSlack Codeのローンチパートナーです。仕組みや対応エージェントはSlack Codeとは？で詳しく整理しています。

Teamsのプレビュー期のドキュメントには「Microsoft Public Developer Previewを有効にする」という条件がありました。現行のドキュメントにはこの記載が見当たりませんが、GAで不要になったとは明言されていません。導入時はTeamsのドキュメントの最新版を確認してください。

料金とプラン別の利用可否

出典: GitHub Copilot 料金プラン（公式）

@GitHubの専用料金はありません。セッションは通常のCopilot cloud agentと同じく、「AI Credits」と「クラウドサンドボックスの利用料」を消費します。 有料プランが前提で、Copilot Freeはcloud agentに対応していないため、SlackやTeamsから作業を頼むことはできません。

かかる費用は2種類

公式ドキュメントの計算例では、600秒・メモリ4GiBのサンドボックスで約0.0216ドルです。サンドボックス単体の費用は小さく、実際の負担の大半はAI Creditsになると考えておくとよいでしょう。消費量はやりとりの長さとモデル次第なので、「1回いくら」とは言い切れません。

プラン別の可否（2026年11月7日時点）

対象プランの書き方は、公式の中でも時期によって揺れがありました。プレビュー期のSlack向けChangelog（2026年8月・9月）は「Copilot Business / Enterpriseの組織向け」と書いていましたが、現行のSlack・Teamsのドキュメントと10月28日のChangelogは「有料のCopilotプラン」としています。GAのChangelog自体には対象プランの記載がありません。個人のProやPro+でも公式ドキュメント上は使える扱いですが、契約前に自分の環境で試しておくのが確実です。

Business・Enterpriseで特に注意したいのは、含まれる枠を使い切った後の追加課金（AI credits paid usage）が既定でオンになっている点です。チャットから気軽に頼めるぶん利用が増えやすいので、管理者は予算の上限（ハードストップ）を先に設定しておくと安心です。AI Creditsの仕組みや割引はGitHub Copilotの使用量ベース課金とは？で詳しく解説しています。

導入手順（Slack・Teams）

出典: GitHub Changelog「Copilot in Slack and Teams adds model and repository updates」

どちらも「アプリを追加する → GitHubアカウントとつなぐ → 会話で@GitHubを呼ぶ」の3ステップです。 組織のリポジトリで使う場合は、GitHub側でアプリにアクセスを許可する作業が加わります。

Slackの場合

1. slack.github.com から「Add to Slack」でGitHubアプリを追加する（ワークスペースの設定によってはSlack管理者の承認が必要）
2. 初回に @GitHub を呼ぶと案内が出るので、GitHubアカウントでサインインしてつなぐ
3. 使いたいチャネルにGitHubアプリを招待し、@GitHub settings で既定リポジトリを決めておく。あとはスレッドで @GitHub ○○を調べて と頼む

エンタープライズが所有するリポジトリでは、管理者がSlack用のGitHubアプリを導入し、アクセスできるリポジトリを指定する必要があります。許可されていないリポジトリを指定すると、アプリのインストールを求めるエラーが返ります。

Microsoft Teamsの場合

1. teams.github.com からGitHubアプリをTeamsに追加する（一般的には、組織のアプリのポリシーによってTeams管理者の許可が必要になる）
2. GitHubアカウントでサインインしてつなぐ
3. チャットやチャネル、ミーティングチャットで @GitHub を呼び、作業を頼む。進行中の計画や差分はCanvasで確認する

作業の引き継ぎ先

@GitHubが作ったPRは、ターミナル、Copilot app、IDEで続きを進められます。チャットで方向性を決め、細かい修正は手元で行う、という分担がしやすくなっています。

出典: GitHub Blog

デスクトップでの引き継ぎについてはGitHub Copilot Appとは？で解説しています。

弱み・制約

使える人と範囲は、はっきり決められています。 導入前に次の制約を知っておくと、「呼んだのに動かない」を避けられます。

• write権限がないリポジトリでは、セッションを始めることも操作することもできない。 会話に参加して文脈を足すことはできる
• ゲストや外部コラボレーターはセッションを開始・操作できない。 社外の協力会社と共有しているチャネルでは注意
• 1セッションで扱えるのは同じオーナーのリポジトリ最大11個まで
• DMには既定リポジトリを設定できない
• 対象リポジトリのMCP設定が無効、または大きすぎるとセッションが始まらない
• マージは人が判断する。 ブランチ保護や必須レビューはそのまま適用される
• GitHub Enterprise Server（GHES）への対応は、2026年11月7日時点の公式情報では確認できない
• Proプランではサードパーティのエージェント（ClaudeやCodexなど）に作業を任せられない。Slack・Teams経由でも同じ扱いかは公式に明記がない

AIの出力には誤りが混ざります。PRになったからといってそのまま取り込まず、通常のコードレビューを通すことがGitHubのResponsible useでも求められています。

セキュリティ面で導入前に決めておくこと

押さえたいのは「何が文脈として持ち出されるか」と「誰の権限でPRが作られるか」の2点です。 チャットに組み込まれるため、IDEで使うときよりも意図しない情報が混ざりやすくなります。

スレッド全体が文脈になり、成果物に残る

@GitHubを呼んだスレッドは全体が文脈として取り込まれ、Issue・PRなどの成果物に保存されます。顧客情報や認証情報、人事の話が混ざったスレッドで呼ぶと、その内容がリポジトリ側に残るおそれがあります。公式は、文脈を絞りたいときはGitHubアプリへのDMを使うよう勧めています。

権限の主体は場所によって変わる

アプリidentityで作られたPRには、ルールセットで追加の承認1件が求められます（ドキュメントでは既定で有効と説明。Changelogでは「管理者が求められる」という書き方で、表現に揺れがあります）。たとえば承認2件が必須のリポジトリなら、3件必要になります。チャネルで頼んだ作業は、レビューの手間が1人分増えると考えておくとよいでしょう。

管理者のチェックリスト

クラウドサンドボックスは手元のPCや他のセッションから隔離されています。PC上でエージェントを動かすときの制限は、GitHub Copilotのローカルサンドボックスとは？で別に解説しています。

チャットから作った試作や社内向けの小さなツールを、社内の実データや既存システムにつないで業務で使うには、認証・権限・データの扱い・運用の担当を別に決めておく必要があります。その段階で何を準備するかは、バイブコーディング・Lovableで作ったアプリを本番運用するにはにまとめています。

他のツールとの違い

@GitHubの強みは、GitHubのリポジトリ・権限・ブランチ保護をそのまま使いながら、チャットから作業を頼める点です。 似た連携との違いは次のとおりです。

Claude Codeとの全体的な比べ方はClaude Code vs GitHub Copilot 徹底比較で整理しています。

こんな人・チームにおすすめ／おすすめしない

開発の相談をすでにSlackやTeamsでしていて、GitHubで権限管理ができているチームほど効果が出やすい機能です。 逆に、チャットに機密情報が多いチームや、レビューの手が足りないチームは、ルールを決めてからのほうが安全です。

こんな人・チームにおすすめ

• 障害対応や不具合の報告をSlack・Teamsのチャネルで受けている
• 有料のCopilotプラン（特にBusiness/Enterprise）をすでに契約している
• エンジニア以外のメンバー（PM・CS）が見ている場で、調査や起票を進めたい
• Teamsの会議で決めたことを、その場で作業に回したい
• ブランチ保護と必須レビューがすでに運用されている

おすすめしない人・チーム

• Copilot Freeだけで使いたい人（cloud agentに非対応）
• 顧客情報や認証情報がチャットに流れやすく、スレッドの持ち出しを管理できない
• 社外のゲストが多いチャネルで作業を回したい（ゲストは開始・操作できない）
• GitHub Enterprise Serverで運用している（2026年11月7日時点で対応を確認できない）
• レビューの担当が少なく、追加承認1件の負担を吸収できない
• 予算の上限を設けずに全社へ一斉に開放しようとしている

よくある質問

「@GitHub」と書かずに返信しても反応しますか？

2025年のプレビュー期の検証記事では、@GitHub を付けない返信は無視される挙動が報告されていました。現在の挙動は公式に明記されていないため、追加の指示を出すときもメンションを付けておくのが確実です。メンションは文頭でなくても、文中のどこに入れても認識されます。

作ったPRはすぐにマージされますか？

自動ではマージされません。マージは人が判断し、ブランチ保護や必須レビューも通常どおり効きます。チャネルで頼んだ場合はアプリ名義のPRになるため、承認が1件多く必要になります。

Slackの無料プランでも使えますか？

GitHubのドキュメントは、Slack側のプランではなく「有料のCopilotプランを持つGitHubアカウント」を条件にしています。ただし、Slackワークスペースへのアプリ追加には管理者の承認が必要な場合があり、Slack Codeの展開状況もワークスペースによって異なります。

日本語で依頼できますか？

Copilotのチャットやエージェントへの指示は日本語でも行えます。IssueやPRの文面も日本語で頼めば日本語で書かれますが、リポジトリの慣例が英語なら、そのように指示しておくと揃います。

使いすぎを防ぐ方法はありますか？

Business/Enterpriseは追加課金が既定でオンなので、管理者がAI Controlsで追加課金を止めるか、予算でハードストップを設定します。個人プランでは、自動モデル選択を使うとAI Creditsの消費が10%割り引かれます（個人向けの課金ドキュメント）。チャネルを絞って試し、1か月の消費量を見てから広げるのも有効です。

まとめ

• 2026年11月6日（米国時間）に、SlackとTeamsの「@GitHub」が一般提供になった
• GAで加わったのは、TeamsのCanvas、リポジトリの自動特定、会話の安定性の改善、作成元の明記の4点
• 会話からバグ調査・Issue作成・実装・PR作成までを頼め、1セッションで同じオーナーの最大11リポジトリを扱える
• 専用料金はないが、有料のCopilotプランが前提。AI Creditsと、2026年11月から課金が始まったクラウドサンドボックスの利用料を消費する
• スレッド全体が文脈として残ること、チャネルではアプリ名義でPRが作られ承認が1件増えることを踏まえて、使うチャネルと予算を先に決めておく

まずは機密情報の少ない開発用チャネルやDMで小さな調査を頼み、消費されるAI Creditsとレビューの負担を確かめてから、使うチャネルを広げていく進め方がおすすめです。