【日次ログ】Slack・TeamsのCopilot:利用条件と追加承認の確認点

2026年9月5日の公式導入資料では、Slack・TeamsのCopilot連携はどちらも有料Copilotプランが対象です。初稿の「両方ともBusiness/Enterprise限定」「個人開発者は対象外」という説明を訂正しました。ただし、有料契約があれば、どの会話・リポジトリでも無条件に変更を依頼できるわけではありません。
この記事は公式資料の照合記録です。連携アプリの導入、会話の送信、PR作成、課金の実測は行っていません。表紙は初稿時の見出しを残していますが、「常駐」は全会話の常時監視を意味しません。
1. 発表時の記載と現在の導入条件
8月21日のSlack発表はBusiness/Enterprise組織を対象と説明していました。一方、同日のTeams発表は有料プランと記載しています。二つの告知を一括りにしたのが初稿の問題でした。
さらに9月5日に開いたSlack導入資料とTeams導入資料は、どちらも有料プランを対象としています。Slackの対象が広がった正確な日付は、今回確認した資料からは特定していません。
| 確認する項目 | 9月5日の導入資料で確認できる条件 |
|---|---|
| 提供段階 | 両方ともパブリックプレビュー。今後変更されうる |
| 契約 | 有料Copilotプラン。法人向けだけに限定しない |
| 接続 | 対応するGitHubアプリとGitHubアカウント連携が必要 |
| 実行環境 | cloud sandboxesの有効化が必要。組織では管理者設定も確認 |
| 変更の依頼 | 対象リポジトリへのwrite権限が必要 |
会話の参加者が補足できることと、コード変更を開始できる権限は別です。公式資料ではゲストやリポジトリの外部コラボレーターにも開始・誘導の制限があります。「チームのチャットにいるから使える」と判断せず、自分の所属と権限を確認します。
2. DMと共有会話では、PRの名義が異なる
現行資料では、DMからの操作は連携した個人アカウントの権限を使い、グループスレッドやチャンネルではアプリ名義で成果物を作ると説明されています。初稿の「作成物はCopilot名義」という一律の説明では、この差が抜けていました。
これは表示名だけの違いではありません。追加承認を判断するときは、どの文脈から作ったPRかと、適用されるリポジトリのルールを見ます。
承認ルールの公式資料では、個人に帰属しないCopilotのPRに追加承認を要求する設定は既定で有効です。ただし、ルールがもともと1件以上の承認を要求する場合に1件増える仕組みで、承認数が0ならこの設定による効果はありません。設定を無効にした場合や、適用対象・例外権限も別に確認が必要です。
したがって「導入すれば誰かが必ずマージ前に見る」という保証にはできません。チャットで依頼した人、実行を管理する人、変更をレビューする人を決めるのは運用側の仕事です。
3. 会話の範囲と費用を見落とさない
Slack・Teamsの導入資料は、メンションしたスレッド全体を文脈に使い、その内容が生成した成果物に保存される点を注意事項に挙げています。直前の一文だけを渡すつもりで、顧客情報や別案件を含む会話から呼び出すのは避けたいところです。
文脈を絞るなら、新しいスレッドや必要事項だけのDMを用意します。ただしDMにすれば機密性が保証されるわけではありません。送る内容と、作成先のIssue・PRを誰が読めるかを合わせて確認してください。
費用面では、Teamsの告知がAIクレジットとクラウドサンドボックスの別課金を明記しています。現行のクラウド実行環境資料でも、実行中の計算・メモリと、停止中のスナップショット保存を別々に計測します。「チャットを閉じた」「セッションを停止した」だけで、すべての費用がなくなるとは限りません。
ここでは料金の総額を試算していません。実行時間や保存量が不明なまま、少額・定額・無料という結論にはしないでください。
4. 実務ではこの順に小さく確認する
以下は文書から整理した導入前の点検手順で、当サイトの成功実績ではありません。
- 契約と管理者設定を確認し、検証に使うリポジトリを一つに絞る。
- アプリに許可した対象と、自分のwrite権限を確認する。
- メンション前にスレッド全体を読み、別案件・秘密情報を外した依頼を用意する。
- 作成先のリポジトリとブランチを明示する。既定値に任せた場合も、開始後の表示を照合する。
- 機密のない小さな変更で、PRの名義、必要承認数、差分、検証結果、使用量を確認する。
- 実行終了後はセッションと保存状態を確認し、不要になったデータの扱いを管理者と決める。
最初の一件は「PRができた」で終えず、誰が何を確認してマージするのかまで記録します。表紙の「承認フローが分かれ目」は、この実際の設定と担当者を見て初めて判断できます。
5. 訂正した点と残る未確認
9月5日の改稿で、プラン対象、DMと共有会話の違い、追加承認の条件、取り込む会話範囲を修正・補足しました。GitHubの設計意図を推測した説明や、人数・事業形態だけで利用対象外とする案内は取り下げています。
実際の接続、承認画面、請求、一般提供への移行日は未確認です。導入判断では、過去の発表と現行の導入資料を分けたうえで、自分の契約・権限・対象リポジトリに条件を当てはめてください。