GitHub CopilotのTeams連携｜共同で動かす設定

「TeamsでGitHub Copilotを動かせるようになったらしい」——そう聞いて自社でも試せるのか確かめようとしたとき、多くの人が最初の前提条件でつまずきます。

結論から言うと、2026年8月21日にGitHubが公開したのは「Teams連携そのもの」ではありません。連携自体は2025年9月からありました。今回の差分は、1人がAIに依頼していた作業を、スレッドの参加者全員が見て・文脈を足して・方向を変えられる「共同セッション」に変えた点です。使い始めるには有料のCopilotプランに加えて、管理者側での有効化が必要になります。

株式会社Fyveは、AIエージェントを無人で走らせる運用基盤を自社で組み、その結果を毎日受け取っています。この記事では公式ドキュメントの前提条件を逐語で整理したうえで、「全員が動かせる」状態にしたときに実際どこから壊れるのかを、運用する側の視点で書きます。

結論：3行でわかる今回の変更点

忙しい方のために、先に要点だけまとめます。

• 新しくなったのは「共同性」。Teamsのチャネル・スレッド・DMで @GitHub とメンションすると、そのスレッドがそのままエージェントの作業場になります
• 参加と実行は別の権利。会話の参加者は誰でも入力できますが、実際にコードを変更させられるのはリポジトリへの書き込み権限を持つ人だけです
• まだパブリックプレビュー。有料のCopilotプランに加えて、管理者によるクラウドサンドボックスの有効化と、Teams側のプレビュー設定が要ります

「とりあえず入れてみる」で始められる機能ではない、というのが実務上のいちばん大きなポイントです。前提条件は後の章で表にまとめます。

その前に：「TeamsのCopilot」は2種類あって、これは別物です

この話題でいちばん多い取り違えを先に潰しておきます。Microsoft TeamsのなかでCopilotと呼ばれるものは、少なくとも2つあります。

つまり「Microsoft 365 Copilotを契約しているから、これも使えるはず」は成り立ちません。請求書の出どころがそもそも違います。社内で「Copilotの新機能を試したい」という要望が上がってきたとき、まずどちらのCopilotの話なのかを確認してください。ここを取り違えたまま調達に進むと、必要のないライセンスを買うことになります。

2つのCopilotの違いそのものについては、別の記事で整理しています。

CopilotM365 CopilotとGitHub Copilotの違い

2026年8月21日の発表内容

GitHubの変更履歴（changelog）に掲載された内容を整理します。発表日は2026年8月21日、ステータスはパブリックプレビューです。

Teamsの会話が、そのまま作業場になる

チャネル・スレッド・ダイレクトメッセージのいずれかで @GitHub にメンションして依頼を書くと、GitHub Copilotのクラウドエージェントのセッションが始まります。公式の説明では「Microsoft Teamsでの議論を、全員が見て方向づけを手伝える共同エージェントセッションに変える」と表現されています。

会話の参加者は、質問したり、背景情報を足したり、計画に口を出したりできます。そしてリポジトリへの書き込み権限を持つ参加者は、Copilotに実際の変更を起こさせることができます。

会議の宿題を、その場で渡せる

公式が例として挙げているのが、朝会（スタンドアップ）のシーンです。議論の途中で出てきた「これ調べておいて」を、会議が終わる前にその場でCopilotに渡してしまう。人が議論を続けている間に、エージェントは調査を始めている、という使い方です。

変更履歴には、進行を追うための専用のコードチャンネルが作られ、セッションの操縦をそちらで続けられる、という記載もあります。ただしこの用語は現時点の公式ドキュメント側には説明が見当たりません。実際の画面上の見え方は、自社のテナントで有効化してから確認することをおすすめします。

始めた場所に縛られない

Teamsで始めた作業は、ターミナル、IDE、Copilotアプリといった他のGitHub Copilotの面へ非同期で引き継げるとされています。「チャットで頼んだから、チャットで完結させないといけない」わけではありません。

【重要】2025年9月からの差分——何が「新しくない」のか

ここは記事の核心です。Teams連携そのものは新機能ではありません。

GitHubは2025年9月19日にすでに「Microsoft TeamsでCopilotコーディングエージェントを使う」という変更履歴を出しています。当時の内容は、Teamsの会話から直接プルリクエストを生成させるというもので、バグ修正・小さな機能追加・リファクタリング・ログ追加・雛形作成といった用途が想定されていました。@GitHub メンションで起動する点も、当時から同じです。

では今回何が変わったのか。並べるとこうなります。

この差分を把握しておく実務上の意味は2つあります。

ひとつは調達の判断です。「Teams連携が来たから予算を取る」という説明は、社内的には1年遅れの話になります。今回動くべき理由は「共同で操縦できるようになったこと」であって、連携の有無ではありません。

もうひとつはリスクの所在が変わったことです。1対1の依頼なら、頼んだ人が結果に責任を持ちます。全員が操縦できるようになった瞬間、その前提が消えます。ここが後半の主題です。

使い始めるまでの前提条件（公式ドキュメントの逐語）

GitHubの公式ドキュメントに記載されている前提条件は、次の4つです。訳出のブレを避けるため、原文の項目をそのまま整理しています。

加えてドキュメントには、組織やエンタープライズのメンバーは、Teamsでこれを使う前にオーナーによるクラウドサンドボックスとCopilotクラウドエージェントの有効化が必要になる場合があると書かれています。

ここで実務が止まる理由

4つのうち3番目と4番目が、中小企業でつまずきやすいところです。

3番目の「Public Developer Preview」は、Teamsクライアント側の開発者向けプレビュー設定です。全社に配布されている標準の状態では通常オフになっており、しかもこれを触る権限を持っているのはTeams管理者——多くの中小企業では、情報システムを兼任している総務担当者や、外部のパートナーです。「エンジニアが自分の判断で試す」ことができません。

4番目のクラウドサンドボックスは、GitHub側の組織設定です。こちらはGitHubの組織オーナーの領分になります。

つまりこの機能を試すには、最低でも2人の管理者の承認が要るということです。検証を始める前に、この2人を先に押さえておくと段取りが早くなります。逆にここを飛ばして「使えません」と報告が上がってくるのが、いちばんよくある詰まり方です。

なお、プレビュー段階の機能は前提条件や設定名が変わることがあります。導入判断の直前には、必ず公式ドキュメントの最新版で確認してください。

費用の考え方

前提条件の1番目にあるとおり、有料のCopilotプランが必要です。無料枠では動きません。またGitHub側は、組織が使用量ベースの予算（budget）を設定できることに触れています。共同セッションは起動する人が増える機能なので、この予算設定は後回しにしないほうが安全です（理由は次章）。

Copilotのプラン体系そのものは、個人向けと法人向けで分かれていて分かりにくい部分があります。全体像は別記事にまとめています。

CopilotCopilotの料金一覧｜個人・法人の全プラン【2026年版】

誰が何をできるのか——「参加できる人」と「変更を起こせる人」は違う

共同セッションで最初に理解すべきなのが、権利が2層に分かれていることです。公式ドキュメントはこう明記しています。

リポジトリへの書き込み（write）権限を持つユーザーだけがCopilotに変更を起こさせることができる。ただし会話の参加者は誰でも入力を与えることができる。

そしてもうひとつ、境界に関する重要な記述があります。

ワークスペースのゲストメンバー、およびリポジトリの外部コラボレーターは、TeamsでCopilotのセッションを開始したり操縦したりすることはできない。

整理すると、こうなります。

この表で注目してほしいのはいちばん左の列がすべて「できる」になっていることです。会話への入力は誰でもできます。つまり、業務委託の方や社外パートナーがチャネルに入っている場合、その人たちの発言もエージェントが読む文脈の一部になり得ます。コードを壊される心配はありませんが、会話の中身がエージェントへの入力になるという前提は、チャネル設計の段階で意識しておく必要があります。

Teamsに社外の人を招く方式そのものについては、別記事で3つの方式を比較しています。共同セッションを使うチャネルをどの方式で作るかは、ここに直結します。

CopilotTeamsに外部パートナーを招待する3方式

チャネルとDMで挙動が違う

もうひとつ、設定上の細かいが重要な差があります。

• チャネル：チャネルごとに既定のリポジトリを設定できます。リポジトリやブランチを指定しなかった場合、Copilotはそのチャネルの既定リポジトリと、そのリポジトリの既定ブランチを使います
• ダイレクトメッセージ：既定のリポジトリを設定できません。代わりに、自分の個人GitHubアカウントの権限が適用されます

リポジトリとブランチは、依頼文のなかで repo=OWNER/REPO_NAME branch=BRANCH_NAME のように明示的に指定することもできます。

運用としては、チャネルごとに既定リポジトリを1つ決めておくのが素直です。「どのチャネルで話すか」がそのまま「どのリポジトリを触るか」に対応していれば、指定忘れによる事故が構造的に起きません。DMは既定を持てない以上、探索や質問には向いていても、変更を起こす場所としては勧めにくいというのが率直なところです。

中小企業がここで最初に壊すのは、権限ではなく「責任の所在」と「課金」

ここからが、私たちが実際にエージェントを運用してきた側からの話です。

権限設計は、上の表のとおり最初から用意されています。書き込み権限で線が引かれ、ゲストと外部コラボレーターは弾かれる。ここは製品側がきちんと作り込んでいる部分で、正直あまり心配していません。

実務で先に壊れるのは、製品が面倒を見てくれない2つ——責任の所在と、課金です。

「全員が見ている」は「誰も見ていない」になる

私たちは、人が介在しない時間帯にAIエージェントを走らせ、成果物を毎朝受け取る仕組みを自社で運用しています。そこで何度も踏んだのが、通知の宛先の問題でした。

結果の通知先をチーム全体のチャンネルにすると、閲覧数は増えるのに、異常を指摘する人はむしろ減ります。全員が見られる状態は、全員が「他の誰かが見ているだろう」と考えられる状態でもあるからです。逆に宛先を1人に固定すると、その人は必ず開きます。

共同エージェントセッションは、この構造をそのまま持っています。スレッドの全員がCopilotの作業を見られる。全員が方向づけできる。聞こえは良いのですが、「このプルリクエストを最終的に確認する人」が指名されていなければ、可視性は品質に変換されません。

1対1の依頼だった頃は、頼んだ人が暗黙のうちにその役でした。共同セッションではその暗黙が消えます。消えたことに気づかないまま運用を始めるのが、いちばん危ないパターンです。

対策：レビュー担当を「人」で固定する

GitHub側は、リポジトリ管理者がCopilotの作成した変更をマージする前に追加のプルリクエスト承認を必須にできる、と説明しています。この設定は、共同セッションを使うなら最初に入れるべきものだと考えています。

ポイントは、承認を「必要にする」ことそのものよりも、承認する人が機械的に決まる状態を作ることです。私たちが自社の無人運用で採っているのは、判断がつかないときは通さない、という原則です。判定が取れなければ公開しない。曖昧なら止まる側に倒す。共同セッションのように「誰かが見ているはず」と思いやすい環境ほど、この既定値が効きます。

課金は「起動する人の数」で増える

もうひとつが費用です。1対1の依頼だった頃、エージェントを起動するのは基本的に担当者1人でした。共同セッションでは、書き込み権限を持つ人全員が起動できます。使用量の見積もりの前提が変わります。

これは機能の欠陥ではなく、共同化した以上は当然の帰結です。だからこそGitHubも使用量ベースの予算設定に触れているのだと理解しています。

実務としての順番は、こうするのが安全です。

1. 予算（budget）を先に設定してから、機能を開放する
2. 最初の1〜2週間は、1つのチャネル・1つのリポジトリに限定して試す
3. その期間の実績値を見てから、開放範囲を広げる

順番を逆にして「全社に開けてから様子を見る」とやると、様子が分かった頃には請求が確定しています。上限を張るコストはゼロなので、先に張っておくほうが合理的です。

他のチャット基盤でも同じことが起きている

この「チャットの会話をそのままエージェントの作業場にする」という設計は、GitHubとMicrosoftだけの動きではありません。2026年8月20日には、Slack側でも複数のコーディングエージェントを専用チャンネル上で動かす「Slack Code」が発表されました。Anthropicの Claude Code、Cognitionの Devin、GitHub Copilot などが参加すると報じられています。GitHubの今回の発表は、その翌日です。

つまり、どのチャット基盤を使っているかにかかわらず、同じ判断を迫られるということです。自社がSlack中心なのか、Teams中心なのかで入口は変わりますが、「誰が起動できるか」「誰が承認するか」「上限をどこに張るか」という問いは共通しています。

Slack側の動きについては、別記事で扱っています。両方を見比べると、共通する論点が見えやすくなります。

Slack Codeとは｜Claude Codeをチームで動かす

何を任せて、何を任せないか

公式が想定用途として挙げているのは、バグ修正・小さな機能追加・リファクタリング・ログ追加・雛形作成といった作業です。この線引きは、私たちの実感ともほぼ一致します。

判断の目安を表にすると、次のようになります。

右の列に共通しているのは、間違っていたときに、間違っていたと気づくのが遅れる作業だという点です。チャットのスレッドという「流れていく場所」で回す以上、この観点は特に効きます。会話は下に流れていき、数時間後には誰も遡りません。

非エンジニアが同じ場所にいることの効用

否定的な話が続いたので、この機能の本当に良いところも書いておきます。

Teamsは、Slackと違って日本の中小企業では全社の連絡網であることが多いツールです。開発チーム専用ではありません。営業も総務も経営者も同じ場所にいます。

そこでエージェントの作業が可視化されることには、思っている以上の意味があります。「この修正には半日かかる」と言葉で説明しても伝わらなかったことが、作業の進行がスレッドに流れるだけで伝わる。依頼した営業担当が、途中で「あ、それなら仕様はこっちで良いです」と口を挟める。仕様の確認が、往復のメールではなくその場の一言で済む場面が確実に増えます。

先ほど「全員が見ていると誰も見なくなる」と書きましたが、それはレビュー責任の話です。文脈の共有という意味では、全員が見えることは純粋な利得です。この2つを分けて考えると、設計を間違えにくくなります。

導入の進め方（実務の順番）

ここまでを踏まえた、現実的な進め方です。

1. どちらのCopilotの話か確定させる。GitHub Copilotの有料プランの契約状況を確認する
2. 2人の管理者を押さえる。Teams管理者（Public Developer Previewの有効化）と、GitHubの組織オーナー（クラウドサンドボックスとクラウドエージェントの有効化）
3. 予算の上限を設定する。使用量ベースの予算を先に張る
4. 検証用のチャネルを1つ作り、既定リポジトリを1つ設定する。いきなり既存の業務チャネルで始めない
5. プルリクエストの追加承認を必須にする。承認者を人の名前で決める
6. 向いている作業から試す。前章の表の左の列から始める
7. 2週間の実績を見てから開放範囲を決める。使用量と、レビューが回っているかの両方を見る

プレビュー段階の機能なので、この順番で進めても想定どおりに動かないことはあります。その場合に「使えなかった」で終わらせず、どの段階で止まったのかを記録しておくと、正式版が来たときにそこから再開できます。

よくある質問

Microsoft 365 Copilotを契約していれば使えますか

使えません。今回の機能はGitHub Copilotの有料プランが前提です。Microsoft 365 Copilotとは契約も請求先も別になります。

無料のCopilotプランでは動きませんか

公式ドキュメントの前提条件に「有料のCopilotプランを通じてCopilotを利用できるGitHubアカウント」と明記されているため、無料枠では対象外と読むのが妥当です。

エンジニアではない社員が、勝手にコードを変更させてしまう心配はありますか

ありません。コードの変更を起こせるのはリポジトリへの書き込み権限を持つ人だけで、これはTeams側ではなくGitHub側の権限で決まります。ただし会話への入力自体は誰でもできるため、エージェントが読む文脈には全員の発言が含まれ得ます。

社外のパートナーが入っているチャネルでも使えますか

ゲストメンバーと外部コラボレーターは、セッションの開始も操縦もできません。ただし会話には参加できます。社外の方が入っているチャネルを共同セッションの場にするかどうかは、招待方式とあわせて設計してください。

すぐに全社導入すべきですか

パブリックプレビューの段階であること、そして管理者2人の設定変更が必要であることを踏まえると、まずは1チャネル・1リポジトリでの検証をおすすめします。共同で操縦できること自体は価値がありますが、レビュー担当と予算上限を決めないまま開放すると、可視性が品質にも節約にも変換されません。

まとめ

2026年8月21日の発表を、実務の視点で要約します。

• 新しいのは共同性。Teams連携自体は2025年9月からある。今回はスレッド参加者全員が見て操縦できるようになった
• 前提条件は4つ。有料Copilotプラン／Teamsアカウント／TeamsのPublic Developer Preview／クラウドサンドボックスの有効化。管理者が2人絡む
• 権利は2層。参加者は誰でも入力でき、変更を起こせるのは書き込み権限者だけ。ゲストと外部コラボレーターは開始も操縦もできない
• 製品が面倒を見ないのは2つ。レビュー責任の所在と、使用量の上限。この2つは開放する前に人と数字で決めておく

「全員が見られる」ことは、文脈の共有としては大きな利得です。一方でレビューの責任は、可視性では代替できません。ここを分けて設計できるかどうかが、この機能を資産にできるか、請求書だけが増えるかの分かれ目になると考えています。

自社の体制でどこまで任せられるのか、どの業務から始めるべきかの判断に迷う場合は、私たちの専属AI活用顧問サービスで、現在の運用に合わせた設計からご一緒しています。