目次
Microsoft Teamsに届いたバグ報告を、その場でGitHub Copilot cloud agentへ渡し、調査・修正・プルリクエスト作成まで進められるようになりました。GitHubは2026年10月23日、新しいGitHub app in Teamsで、通知とCopilotを一つの会話にまとめる機能を発表しました。
便利になる一方、Teamsの会話は単なる連絡欄ではなく、コード変更を決める入力になります。GitHubの公式資料によると、エージェントはスレッド全体を文脈として取り込みます。変更を開始できるのは対象リポジトリへの書き込み権限を持つ利用者ですが、会話の参加者は実装判断へ影響する情報を入力できます。採用前に、誰が起動できるかだけでなく、どの会話を入力にし、どのリポジトリへ、どの権限で変更を返すかを決める必要があります。
本稿は2026年10月24日にGitHub ChangelogとGitHub Docsを確認したAI×セキュリティの導入解説です。この機能を使った侵害事件や脆弱性の速報ではありません。GitHubが明示する仕様と、本サイトが提案する運用手順を分け、通知からPRへ進む経路に置くべき統制を整理します。
スポンサーリンク
新機能は通知を作業依頼へ変える
GitHub Changelogの2026年10月23日付発表では、Teamsのチャンネル、グループチャット、プライベートチャットに届いた通知から、GitHubをメンションして作業を依頼できます。例として、バグ報告を受け取り、エージェントが調査・修正してPRを作り、チームがレビュー、テスト、マージする流れが示されています。
既存のGitHub notificationsを導入済みの場合は新しいアプリへ更新でき、従来の通知機能は継続します。旧GitHub appは「GitHub (deprecated)」へ改名され、11月16日に廃止予定です。新しいアプリではGitHubアカウントを接続し、必要に応じて対象リポジトリを選びます。
GitHub DocsのTeams統合手順では、この機能は全ての有料Copilotプランで利用できる一方、確認時点ではパブリックプレビューとされています。組織やEnterprise Managed Usersの環境では、所有者がcloud sandboxとCopilot cloud agentを有効にする必要がある場合があります。一般提供済みの完成仕様とみなさず、権限・ログ・UIの変更を追える小さな範囲から試すのが安全です。
最大の変化はスレッド全体が実装コンテキストになること
公式資料は、GitHubをメンションする前に、Copilot cloud agentがスレッド全体を取得し、会話を理解して成果物へ反映することを考慮するよう案内しています。作成された成果物にも、その文脈が保存されます。同じスレッドで修正を依頼すると、前回のメンション以降の全メッセージも反復作業へ使われます。
ここで確認すべきなのは、最後に依頼文を書いた人だけではありません。たとえば障害対応スレッドに、仮の回避策、古い仕様、顧客固有の情報、検証前のコマンドが混在していれば、それらも判断材料になり得ます。GitHubは、書き込み権限を持つ利用者だけが変更を起動でき、ゲストと外部コラボレーターはTeamsからセッションを開始・誘導できないと説明しています。それでも、起動権限のある担当者が長い会話全体を渡す時点で、入力の品質と機密性を評価する必要があります。
入力を絞りたい場合、GitHubは新しいスレッドを始めるか、GitHub appへのダイレクトメッセージを使う方法を案内しています。本サイトの提案として、障害チャットをそのまま作業依頼へ変換するのではなく、確認済みの再現条件、対象リポジトリ、変更しない領域、完了条件を短い専用スレッドへ転記してから起動すると、古い推測と不要な情報を減らせます。
スポンサーリンク
共有スレッドとDMでは実行主体が異なる
ダイレクトメッセージでは、Copilotは接続した個人のGitHubアカウント権限でPRやIssueを作成します。共有チャンネルやグループスレッドでは、成果物は個人ではなくアプリのアイデンティティで作成されます。共有文脈のPRが人に帰属しないため、リポジトリですでに1件以上の承認を要求している場合、rulesetによりマージ前の追加承認が既定で必要になります。
また、チャンネルには既定リポジトリを設定できます。リポジトリやブランチを依頼時に明示しなければ、チャンネルの既定リポジトリと、そのリポジトリの既定ブランチが使われます。既定リポジトリが未設定のチャンネルでは、最初のセッションで使ったリポジトリが既定になります。会話名だけで対象を推測せず、作業依頼ごとにリポジトリと既存ブランチを明記し、セッション表示に出る対象と一致するか確認する運用が向いています。
| 利用場所 | 成果物の主体 | 導入前に決めること |
|---|---|---|
| ダイレクトメッセージ | 接続した個人アカウントの権限 | 個人権限で触れてよいリポジトリ、会話へ含めてよい情報 |
| 共有チャンネル・グループ | GitHub appのアイデンティティ | チャンネル参加者、既定リポジトリ、必須承認、保護ブランチ |
| 専用の短いスレッド | 共有文脈だが入力を限定しやすい | 確認済み事実、対象外、テスト条件、レビュー担当 |
アプリが必要とする権限を通知機能だけで判断しない
GitHub DocsのTeams向け権限一覧によると、GitHubアカウントをアプリへ接続すると、Issue、メタデータ、PR、Discussion、リポジトリProjectの読み取り、コードの読み取り、Actions・Issue・PRへの書き込みが必要です。Copilot cloud agentを使う場合は、さらにコンテンツへの書き込みとWorkflowへの読み書きが追加されます。
通知を見るだけのアプリとして審査すると、コード変更とWorkflowに関する権限を見落とします。管理者は、Teams側のアプリ導入、GitHubアカウント接続、リポジトリへのアプリ導入、Copilot cloud agentの有効化を別々の管理点として記録してください。対象リポジトリを全体へ広げる前に、検証用または低影響のリポジトリだけを選び、設定変更時に再確認できる所有者を決めます。
MCP、スキル、エージェントの許可と利用実績を管理している場合は、既存のGitHub CopilotのMCPを棚卸しする運用設計と同じ台帳へ、Teams統合の有効範囲、既定リポジトリ、担当者、見直し日を追加すると、入口だけ別管理になるのを防げます。リンク先は2026年10月23日時点の仕様を前提にしています。
スポンサーリンク
サンドボックスがあっても入力と通信の確認は残る
Teamsから開始した作業は非同期のクラウドサンドボックスで続き、完了後に結果が投稿されます。サンドボックスは実行環境を分離しますが、会話内容が適切か、生成した変更が正しいか、外部通信先が必要かまで自動で決める保証ではありません。
GitHub DocsのCopilot向けファイアウォール資料では、cloud agentのインターネット接続は既定で制限されます。悪意ある指示や予期しない挙動によるコード・機密情報の外部送信リスクを抑える目的です。一方、ファイアウォールは主にエージェントがBashツールから起動したプロセスへ適用され、MCPサーバープロセスやセットアップ手順などには適用範囲の違いがあります。高度な回避の可能性もあり、包括的な防御とはされていません。
依存関係の取得に必要という理由で広い許可リストを入れる前に、実際に遮断されたホストとコマンドをPR上の警告で確認します。組織共通の許可とリポジトリ固有の許可を分け、使わなくなった通信先を削除できる形で残してください。自己修復や自動変更全体の統制を検討する場合は、自己修復AIを本番へ入れる前の4つの統制境界も次の設計材料になります。
PR作成を完了条件にせず人の判断を残す
GitHub DocsのCopilot出力レビュー手順は、生成されたPRを通常の貢献と同じように詳しく確認するよう求めています。Copilotへ作業を依頼した人の承認は必須承認数に算入されず、別のレビュー担当が必要です。
GitHub Actionsは、CopilotがPRへ変更を送っただけでは既定で自動実行されません。Workflowは秘密情報へアクセスできる場合があるため、特に.github/workflows配下の変更を確認した後で「Approve and run workflows」を実行します。自動実行へ設定変更する選択肢はありますが、Teamsの通知から変更が始まる構成では、初期導入時にこの人手の境界を残す方が、誤った入力から特権的な処理へ連鎖するのを止めやすくなります。
導入前に決める7項目
- 対象を限定する：最初は少数のリポジトリに限定し、Teams統合から変更してよい範囲を文書化する。
- 会話を整理する：長い障害スレッドを直接渡さず、確認済み事実だけの専用スレッドを作る。秘密情報や顧客データを書かない。
- 対象を明示する：依頼ごとにリポジトリ、既存ブランチ、変更対象、変更禁止領域、完了条件を記載する。
- 権限を分けて確認する：Teams権限、GitHub app権限、個人の書き込み権限、cloud agentポリシーを別々に棚卸しする。
- マージ条件を固定する：保護ブランチ、必須チェック、別担当者のレビューを有効にし、アプリ主体のPRに必要な承認を確認する。
- 通信を記録する：ファイアウォールを維持し、許可リストの追加理由、期限、所有者を残す。
- 結果を監査する：セッションログ、PR、テスト結果、Workflow承認者を結び付け、想定外の対象変更や通信警告を振り返る。
採用判断は会話の便利さより境界の明確さで行う
この機能が向くのは、Issue通知から定型的な調査と修正案作成へ進むチームで、対象リポジトリ、レビュー担当、テスト、マージ条件がすでに決まっている場合です。Teamsで議論した内容をGitHubへ転記する手間を減らしながら、PRという確認可能な成果物へ戻せます。
一方、複数顧客の情報が混ざるチャンネル、参加者の入れ替わりが多い場所、リポジトリの既定値を管理できない環境、PR承認やWorkflow実行を形式化していないチームでは、会話から変更までの距離が短くなるほど判断根拠を追いにくくなります。まず通知だけを使い、エージェント起動はGitHub上の管理されたIssueから行う段階導入も選択肢です。
2026年10月24日時点で、このTeams統合はパブリックプレビューです。料金の新設、地域別提供、一般提供日について、確認した資料には具体的な記載がありません。導入時は画面表示だけで可否を判断せず、GitHub Docsの権限、スレッド取得範囲、実行主体、承認要件を再確認してください。
スポンサーリンク
