「@GitHub」と打つだけで、チャットに“作る同僚”が来る──CopilotがSlackとTeamsの両方に降り、PRまで面倒を見る

コーディングエージェントを「呼ぶ場所」が、ターミナルやIDEからチームの雑談へと移りつつあります。GitHubは2026年8月21日、GitHub CopilotをSlackとMicrosoft Teamsの両方でパブリックプレビューとして使えるようにしました。チャットで @GitHub とメンションすれば、その場でエージェントの作業が始まります。

チャットで「@GitHub」と呼ぶだけで動き出す

使い方は素朴です。ダイレクトメッセージでも、チャンネルでも、スレッドの返信でも、@GitHub と書いて用件を伝えるだけ。するとCopilotが会話の中でタスクを受け取り、調査や修正に取りかかります。何ができるか分からなければ、@GitHub help でコマンド一覧を確認できます。

これまでCopilotの主戦場は、エディタ（VS CodeやJetBrains）とコマンドライン（Copilot CLI）でした。今回の更新は、そのCLIとアプリの機能をチャットツールの中へそのまま持ち込むものです。「ひとりで開いた画面」ではなく、チームが見ている画面の中でエージェントが動く点が今回の肝です。

Slackで先行したSalesforceとの違いは「既存の権限」

チャットで開発エージェントを回す発想自体は新しくありません。前日にはSalesforceがSlackネイティブの「Slack Code」を出したばかりです。GitHubの一手が異なるのは、すでに開発現場が使っているGitHubの権限・IDの上に乗せてくる点にあります。

• 変更の実行はリポジトリの権限の範囲に限られる
• Copilotが作ったプルリクエストはCopilotアプリ名義で残る
• リポジトリ管理者は、そのPRのマージ前に人手の承認を必須にできる

コードの正本がGitHubにある以上、「チャットで頼んだ結果がそのままGitHubのIssueやPRになる」導線は自然です。SlackではさらにSlack Codeと連携し、専用のコードチャンネルでチーム全員が「計画を追い、差分を確認し、HTMLなどの出力プレビューを見ながら反復する」使い方も想定されています。

チャットからできること

SlackとTeamsで共通して、次の作業をチャットの中から起動できます。

• 質問への回答：コードやGitHub上の活動について尋ねる
• Issueのトリアージ：バグ報告を仕分けし、Issueの作成・更新・ラベル付けをする
• 調査と修正：失敗の原因を調べ、安全なクラウドのサンドボックスで変更を試し、検証する
• PRの作成：プルリクエストを開き、レビュー用に会話へのリンクを返す

指示を出したあとは、Copilotがサンドボックス内で非同期に作業を続けます。チームは別の仕事に戻り、進捗はスレッドで追える。Teamsでは、生成された成果物をあとからターミナルやCopilotアプリ、IDEで開いて続きに取りかかることもできます。

「誰でも変更を起動できる」わけではない

参加のしかたには段階が設けられています。Teamsの説明が分かりやすく、次のように整理されています。

• 会話に参加する誰もが、質問したり文脈を補ったりできる
• 実際にコードを変更させられるのは、リポジトリへの書き込み権限を持つ人だけ
• 管理者は、Copilotが作ったPRに追加の承認を課せる

利用の前提もエンタープライズ寄りです。Slack版はGitHub Copilot BusinessまたはEnterpriseが必要で、管理者がクラウドエージェントのポリシーを有効化し、Slackアプリの導入とGitHubアカウントの連携を済ませておく必要があります。Teams版も有料プランが前提で、管理者がクラウドエージェントとクラウドサンドボックスの両方を有効にしておく設計です。

ビジネスへの意味：開発の入口が「会話」に変わる

この動きが効いてくるのは、エンジニア以外も同じ画面に居るときです。バグ報告を受けたチャンネルで、そのまま @GitHub と打てば、トリアージからIssue化、修正のPRまでが会話の延長線でつながります。「Slackで気づく → GitHubに切り替えて起票 → 誰かが着手」という往復が、1本のスレッドに畳まれるわけです。

非同期で進む点も、時差のあるチームには実務的です。誰かが依頼を投げておけば、サンドボックスの中で作業が進み、起きたらPRのリンクが待っている──そうしたワークスタイルを、既存の権限管理を崩さずに敷ける点が今回の価値だと言えます。

見落とせない注意点

便利さの裏側で、運用前に詰めておきたい論点もあります。断定はできませんが、次のような懸念が指摘され得ます。

• コストが見えにくい：クラウドのエージェント実行とサンドボックスは別枠のAIクレジットを消費し、組織の従量課金予算で管理される。チャットから気軽に呼べるぶん、消費が積み上がりやすい
• 責任の所在：PRが人ではなくCopilotアプリ名義で残るため、レビューと責任分界の運用を先に決めておく必要がある
• 入口＝操作面になる：チャットが変更の起点になるからこそ、書き込み権限と承認ゲートの設計を誤ると影響が大きい

いずれもパブリックプレビュー段階の話であり、既定は「管理者が明示的に有効化して初めて動く」設計になっています。まずは小さなリポジトリと限られたチャンネルで、承認フローとクレジット消費の見え方を確かめてから広げるのが穏当でしょう。

参照: The new GitHub Copilot experience in Slack（GitHub Changelog） ／ Shared agentic work with GitHub Copilot in Microsoft Teams（GitHub Changelog） ／ GitHub Changelog（2026年8月）