GitHubは2026年9月25日、GitHub Copilot for Slack and Microsoft Teamsの更新を発表しました。Slackでは対応ファイル、添付、メッセージリンクを、Teamsではインライン画像、転送メッセージ、チャンネルやスレッド履歴を文脈として使えるようになり、会話からGitHub IssueやPull Requestへつなげやすくなりました。
対象はGitHub Copilot Business / Enterpriseのpublic previewです。この記事では、開発責任者と情シスが30日PoCで確認すべきポイントを、3つの運用チェックリストに整理します。
概要：会話をIssueとPRにつなぐ更新
今回の要点は、チャット上の判断をGitHub作業へ移す導線が強くなったことです。Copilotは類似Issueを確認し、作成した作業への直接リンクと、元の会話へ戻るリンクを残します。議論の背景、添付資料、決定理由がIssueやPRから追いやすくなるため、会議後の手入力や転記漏れを減らせます。
さらに、次のメッセージで使うモデルを切り替え、その選択を会話内で維持できます。Slackでは既定ownerとrepositoryも設定できるため、複数リポジトリを扱うチームでも作業先の指定ミスを減らしやすくなります。
仕様表：2026年9月25日時点の確認事項
・対象：GitHub Copilot Business / Enterpriseのpublic preview。利用は既存のCopilot entitlementにカウントされ、Copilot cloud agent budgetsで管理できます。
・Slack：GitHub app for Slackを導入または更新し、GitHubアカウント連携後に@GitHubで呼び出します。対応ファイル、添付、メッセージリンクを文脈化できます。
・Teams：GitHub app for Microsoft Teamsを導入し、@GitHubで接続します。インライン画像、転送メッセージ、チャンネル履歴、スレッド履歴を扱えます。
・作業化：Issue作成前の類似Issue確認、作成物への直接リンク、元会話リンクにより、あとから判断経緯を追跡しやすくなります。
設定方法：導入前の3ステップ
1つ目は、Copilot cloud agentとcloud sandboxのポリシー確認です。SlackでもTeamsでも、cloud agentとcloud sandboxが有効であることが前提です。Enterprise Managed Users環境では、組織またはEnterprise ownerの設定が必要になる場合があります。
2つ目は、GitHub appの導入範囲を絞ることです。最初から全社に広げず、検証用organization、1部署、1〜3リポジトリで始めます。ユーザーのwrite権限と、GitHub appに許可したrepository範囲が実行可能な作業を決めます。
3つ目は、共有チャンネルとDMを使い分けることです。DMではリンク済み個人アカウントの権限で作業し、共有コンテキストではCopilot appのidentityで成果物を作ります。機密情報を含む相談は、限定チャンネルかDMに寄せる設計が必要です。
GitHub CopilotのSlack/Teams連携を社内AI開発フローに入れるなら、対象部署、対象リポジトリ、会話ログの扱いを先に決めましょう。 導入相談はこちら
チェックリスト：30日PoCで見る3指標
指標1：会話からIssue化するまでの時間。バグ報告、仕様変更、ドキュメント修正を対象に、手作業の転記と比べて50%短縮できるかを測ります。
指標2：重複Issueの削減。Copilotが類似Issueを確認する流れを使い、「新規作成」「既存Issueに統合」「人手で重複と判断」を分けて週次で見ます。
指標3：元会話へのトレーサビリティ。IssueやPRからSlack/Teamsの起点会話へ戻れるかを確認します。監査や引き継ぎが必要な組織ほど、この指標をKPIに入れる価値があります。
セキュリティ：共有スレッドで注意すること
公式ドキュメントでは、@GitHubを呼び出すとスレッド全体が文脈として使われ、その内容が生成される成果物に保存される可能性があると説明されています。顧客名、秘密情報、契約条件、未公開ロードマップが混ざる会話では、利用場所を分けるべきです。
権限面では、write accessを持つユーザーだけがCopilotに変更作業を開始させられます。ただし、共有チャンネルの参加者は入力を提供でき、その内容が作業文脈になります。ゲストや外部協力者がいるワークスペースでは、チャンネル設計を先に棚卸ししてください。
共有コンテキストでCopilotが作るPRはアプリのidentityになります。repository rulesetで承認要件を設定している場合、追加承認が必要になることがあります。安全側の挙動ですが、PoC中にレビュー待ち時間も測っておきます。
FAQ：よくある質問
Q. SlackとTeamsのどちらから始めるべきですか？ A. 仕様相談や障害対応が多く流れている側から始めます。Slackはファイルやメッセージリンク、Teamsは画像や転送メッセージ、チャンネル履歴の活用が見やすいです。
Q. すぐ全社展開できますか？ A. まずは30日PoCがおすすめです。会話ログの扱い、Issue重複率、PRレビュー待ち時間、cloud agent予算を確認してから範囲を広げます。
Q. 既存のCopilot app記事と何が違いますか？ A. local sandboxingやOpenTelemetryは実行環境や監視の話です。今回の更新は、チャット会話をGitHub作業へ移す入口とトレーサビリティに焦点があります。
まとめ：チャット起点の開発を管理する
GitHub Copilot for Slack and Microsoft Teamsの更新は、チャットボット強化ではなく、会話から実装作業へ移る入口の整備です。元会話、Issue、PRをつなぐことで、決定理由を残しやすくなります。
導入時は「Issue化までの時間」「重複Issue削減」「元会話へのトレーサビリティ」の3指標を見ましょう。成果が出た部署から、repository設定、モデル選択、default owner、cloud agent予算を標準化していくのが現実的です。
HelloCraftAIでは、GitHub Copilot、Claude Code、ChatGPT Enterpriseを含む社内AI開発フローの設計を支援しています。Slack/Teams連携を安全に試したい場合は、 お問い合わせください 。
