GitHub Copilot Slack、Teams更新後、チームはAgentをどう検収する？2026年チェックリスト

SlackやTeamsから頼んだ作業のPRが、元の議論や狙ったリポジトリと結び付いているか分からない。
最短の進め方：低リスクの作業だけで試し、プレビュー資格、実行者、会話の出典、リポジトリ、復旧記録を確認してください。チャットの内容をそのままコード変更の承認にせず、Xcodeが関わる成果物は実際のmacOS環境で別に検収します。

対象となる読者
- SlackまたはMicrosoft TeamsからIssue、PR、コーディング作業を始める開発チーム。
- Copilot cloud agentとクラウドサンドボックスを有効にする企業管理者。
- リポジトリ切り替えや中断後の再開を運用するプラットフォームエンジニア。

最終更新：2026年9月27日。確認対象は、GitHubの2026年9月25日更新公告、Slack接続手順、Teams接続手順です。公開プレビューの状態や利用資格は変わる可能性があるため、導入時にも各文書と自分のテナントを照合してください。

導入前：告知の対象と自分の利用資格を分ける

GitHubは9月25日の更新でSlackとMicrosoft Teamsの連携について、新しい会話コンテキスト機能、タスクへのリンク、一部の復旧改善を告知し、機能を公開プレビューとしています。また、機能によっては段階的に提供されると案内しています。告知の内容が見えていても、自分の組織やアカウントで直ちに使えるとは限りません。更新公告の対象機能と提供状況を、実際の画面と突き合わせてください。

利用資格については、告知とSlackの接続文書、Teamsの接続文書で説明が一致しない場合があります。どちらかを都合よく読み替えず、文書の記述とテナントで表示される状態を別々に記録し、管理者へ確認します。必要なプラン、アプリの許可、組織ポリシー、クラウドサンドボックスの条件が確認できない場合は、試験対象を広げないでください。

初回接続：アカウントとリポジトリの境界を固定する

接続直後は、どのGitHubアカウントが作業者になるか、既定のリポジトリとブランチは何か、対象者に書き込み権限があるかを記録します。チャンネルに設定された既定値が、すべての会話やタスクの対象を自動で決めるとは限りません。私的な会話と共有チャンネルの双方で、実行者とリポジトリが想定どおりかを確かめます。

管理者側では、Copilot cloud agentの組織アクセス設定と、クラウドAgentの保護設定を確認します。設定画面、試験アカウント、許可したリポジトリの対応が分かるように残し、チャンネルでの表示名だけを本人確認や権限の証拠にしないでください。

最初のタスク：会話から成果物まで出典を追う

代表的な依頼を、機密情報を含まない試験用のスレッドで実行します。公式の説明に照らしながら、Slackの添付やメッセージへのリンク、Teamsの画像や転送内容がタスクの文脈にどう入るかを個別に確認してください。対応していると告知された機能でも、入力したすべての情報が同じ方法で処理されるとは限りません。

依頼の元スレッド、作成されたIssueやPR、対象リポジトリが一続きにたどれるかを確認します。スレッド全体が判断材料になり得るなら、会話に含めてよい情報と参加者の範囲も運用上の確認事項です。

試験の前に、無害な文章と添付だけで確認できる依頼を用意してください。追跡可能な成果物ができても、レビュー済み、テスト済み、マージ可能という意味にはなりません。

共同作業：モデル変更とリポジトリ切り替えを切り分ける

モデルを切り替えた後に、その選択が現在の会話にどう適用されるかを確かめます。Slackで既定の担当者やリポジトリに関する更新が表示される場合も、チームが期待する設定と一致するかを試験してください。設定変更が会話や既存タスクにどう反映されるかは、画面と実際の成果物で確認し、文書に明記されていない挙動を前提にしないことが重要です。

タスクを頼む際は対象リポジトリを明示し、PRの所属先、ブランチ、会話へのリンクが依頼と一致するかを照合します。タスク作成の成功と、コードレビューやマージの許可は別の判断です。クラウドAgentの動作と制約を踏まえ、通常のレビュー、決定的なテスト、保護ブランチの承認を残してください。

中断後：再開表示より成果物の重複を調べる

応答が止まった、返信が古く見える、しばらく使っていなかった会話を再び開いた、あるいは会話中にリポジトリを変えた、といった条件で状態を確認します。見るべきなのは「再開した」という表示だけではありません。タスクの状態、元の会話、IssueやPRの有無と所属先を突き合わせ、同じ依頼に対する重複回答や、意図しない古い対象への作業がないかを記録します。

公式公告は一部の復旧改善に触れていますが、すべての中断や再接続で同じ結果になるとは限りません。表示された状態や最終成果物で確認できない場合は、成功扱いにせず担当者による確認に戻します。再実行の前に、既存のタスクと成果物を探す手順を決めておくと、重複作成を見落としにくくなります。

試験結果：拡大、範囲制限、保留を決める

次の条件分岐で判断します。

• 資格、実行者、リポジトリ権限が確認でき、会話から成果物まで追跡でき、中断後の状態も照合できる場合は、低リスクの作業に限って試験を続けます。
• 会話の出典やリポジトリの対応は確認できるものの、復旧状態や一部機能がテナントで確かめられない場合は、利用者と許可リポジトリを絞り、人の確認を維持します。
• 利用資格、実行者、書き込み範囲のいずれかが不明な場合、または重複や対象違いを解消できない場合は、試験を保留して管理者が設定を再確認します。

記録には、資格の確認結果、実行者、会話の出典、リポジトリとPRの対応、復旧時の状態、用量の帰属を含めます。Copilotの会話やクラウドAgentのタスクは、決定的なテスト、コードレビュー、マージ承認の代わりにはなりません。

iOSやmacOS向けの成果物では、チャット上の作業完了とビルドの合格を分けてください。AppleのXcodeビルドシステムの説明に照らし、必要なツールチェーンを備えた実際のmacOS環境でビルドを確認します。Mac環境はSlackやTeams連携の必須条件ではなく、Apple向けのビルドが成果物に含まれるときの別工程です。遠隔環境での検収境界はMacを使わないiOS開発とXcodeの確認項目も参考になります。

よくある確認事項

SlackやMicrosoft TeamsからCopilot cloud agentを使う準備

GitHub側の組織ポリシーと利用資格を確認してから、それぞれの接続文書に従ってアプリを設定します。試験アカウントで、実行者、対象リポジトリへの権限、クラウドサンドボックスの条件を確かめてください。公開プレビュー中は、告知や文書に利用可能とあっても、自分のテナントで使えることを別に確認します。

会話のどの情報がタスクに渡るか

依頼文だけでなく、添付、メッセージへのリンク、画像、転送内容の扱いを公式説明と試験で確認します。機密情報を含まない会話からIssueやPRまでたどり、元の議論と成果物の関係を記録してください。スレッド全体が判断材料になり得る点を、共有範囲と情報管理の判断に含めます。

TeamsのPRと対象リポジトリの照合

依頼時にリポジトリを明記し、GitHub上のPRの所属先、ブランチ、作成者、元のTeams会話への参照を照らし合わせます。既定リポジトリだけでは確認を済ませず、実行者の権限も確かめてください。PRの作成は、レビューやマージの承認とは別です。

中断後の二重実行の確認

再実行する前に、元の会話とGitHub上のタスク、Issue、PRを照合します。同じ依頼から複数の応答や成果物が出ていないか、リポジトリ切り替え前の会話が意図しない対象で続いていないかを確認してください。復旧状態が不明なら、自動で再実行せず人が判断します。

SlackやTeams連携の検収だけなら、Macを用意しても会話の出典、GitHubの権限、復旧記録の不足は埋まりません。一方、既存のクラウド実行環境ではAppleのツールチェーンを扱えない、または実際のXcodeビルドを確認できない場合があります。継続的な重負荷や物理機器が必要なら自社のMacを検討し、iOS／macOSの一時的なビルド検証が必要なときは、MacPullのMacレンタル料金を確認して、クラウドAgentの検収とは別の工程として組み込んでください。

よくある質問