PR 本ページにはプロモーションが含まれています。
この記事を読むと、SlackやMicrosoft Teamsで話している内容をもとに、GitHub Copilotへ調査や開発作業を依頼できるようになります。AIの使い方や設定が不安な方でも、この手順に沿って小さな相談から始めれば大丈夫です。
今回紹介する連携は、正式版ではなくパブリックプレビュー（一般公開中の試用段階）です。使える機能や画面は変わる可能性があります。重要な作業では、必ず人が内容を確認してください。
結論：チャットの流れからGitHubの作業につなげられます
GitHub Copilot cloud agent（作業を調査・計画・実行するAI機能）は、SlackやMicrosoft Teamsの会話コンテキスト（相談の前後関係）を読み取り、次のような作業につなげられます。
- 不具合や仕様を調査する
- 実装方法や作業手順を計画する
- コード作成を依頼する
- GitHub Issue（作業課題を管理するチケット）を作成する
- Pull Request（変更内容を確認してもらう依頼）を作成する
Slackでは、ファイル、添付ファイル、メッセージへのリンクを会話の材料にできます。Microsoft Teamsでは、インライン画像（メッセージ内に表示した画像）、転送メッセージ、チャネルやスレッドの履歴を使えます。
実際に使うと、チャットの相談をコピーしてGitHubに貼り直す作業が減ります。一方で、最初の壁は「どの会話をAIに読ませるか」と「どこまで作業を任せるか」の線引きです。最初からコード変更を頼むのではなく、調査やIssue案の作成から試すと戸惑いにくくなります。
なぜ社内チャットから使うと便利なのか
これまでは、チャットで決まった内容を人が整理し、GitHubへ手作業で転記する必要がありました。会話の抜け漏れや、担当者による書き方の違いも起こりやすい方法です。
連携後は、相談が生まれた場所からそのまま調査や依頼を始められます。たとえば「この画像の表示崩れを調べて、修正案を作って」と依頼し、内容を確認したうえでIssueやPull Requestにつなげられます。
チャットを入り口、GitHubを作業台として使うイメージです。実際の使用感としては、AIが会話の内容を整理し直してくれるため、開発者へ渡す前の「状況説明を整える作業」で特に便利です。ただし、雑談や別の話題まで含まれたスレッドでは、AIの理解がずれることがあります。
従来のやり方や他ツールとの違い
チャットから人が手作業で転記する場合
従来は、チャットの内容を読み返し、発生状況、再現手順、期待する結果を人が整理してIssueへ入力していました。正確に整理できる反面、転記に時間がかかり、忙しいと登録自体が後回しになりがちです。
GitHub上で直接Copilotを使う場合
GitHub上で直接依頼する方法は、リポジトリ（ソースコードを管理する場所）やIssueの内容を指定しやすい点が便利です。一方、最初の相談がSlackやTeamsで始まっている場合は、会話や添付画像を改めて集める必要があります。
SlackやTeamsの連携を使う場合
チャット連携では、相談の流れや画像を材料にしながら、調査、計画、Issue作成へ進めます。会話から作業を始めやすい反面、権限設定、対象リポジトリの指定、機密情報の扱いを事前に確認する必要があります。
つまり、連携によって開発そのものがすべて自動化されるわけではありません。相談を作業に変えるまでの整理と転記を短くする仕組みと考えると、期待しすぎずに使えます。
料金と利用前に知っておきたいこと
SlackおよびMicrosoft Teamsとの連携は、無料機能として誰でも使えるものではありません。有料のGitHub Copilotプラン向けに提供されているパブリックプレビューです。具体的な料金や利用条件は、契約中のプランと公式の最新情報で確認してください。
また、クラウドサンドボックス（AIが安全に作業するための隔離された環境）などの有効化が必要になる場合があります。組織で使う場合は、管理者による設定、リポジトリへのアクセス権限、チャット側のアプリ許可も確認してください。
プレビュー中は、表示名、設定場所、対応するファイル形式、利用できるモデル（AIの種類）が変わる可能性があります。画面が記事と少し違っていても、公式の現行手順を優先してください。
初心者向け：使い始める手順
最初から大きな開発を任せると、確認すべき内容が増えます。まずは調査やIssue作成のような、結果を確認しやすい作業から試しましょう。
1. 利用条件を確認する
- GitHubにサインインし、画面右上のプロフィール画像をクリックします。
- 表示されたメニューから、設定または組織の設定を開きます。
- 左側のメニューでGitHub Copilotに関する項目を探し、契約中のプランと利用可能な機能を確認します。
- 組織で利用する場合は、管理者にSlackまたはMicrosoft Teamsとの連携が許可されているか確認します。
メニュー名や位置は契約プランによって異なります。項目が見つからない場合は、個人設定ではなく組織設定を開いているか、管理者権限が必要ではないかを確認してください。
2. 作業環境を有効にする
- GitHubの設定画面または組織の管理画面で、Copilotに関する設定を開きます。
- cloud agent（クラウド上で調査や変更を進める機能）やサンドボックスに関する項目を確認します。
- 利用規約、データの扱い、リポジトリへのアクセス範囲を確認します。
- 必要な項目を有効にし、対象にするリポジトリを決めます。
ここでよくあるミスは、Copilotを契約しているだけで、すぐにすべての機能を使えると思ってしまうことです。プラン、組織の許可、リポジトリ権限、サンドボックスの設定は別々に確認します。
3. SlackまたはMicrosoft Teamsの連携を確認する
- SlackまたはMicrosoft Teamsで、GitHub Copilotに関するアプリや連携機能を開きます。
- 画面に表示された案内に従い、GitHubアカウントとの接続を許可します。
- アクセスを求められた場合は、どのワークスペース、チーム、チャネル、リポジトリが対象になるか確認します。
- テスト用の公開情報や小さな不具合を使い、接続できるか試します。
Slackでは、ファイルや添付ファイル、メッセージへのリンクを材料にできます。Teamsでは、インライン画像、転送メッセージ、チャネルやスレッド履歴を使えます。ただし、連携の対象範囲や対応形式は変更される可能性があります。
4. 最初の相談を投稿する
相談するスレッド内で、してほしいことを短く書きます。対象リポジトリが決まっている場合は、リポジトリ名も明記します。
コピペOKの例：「対象リポジトリを指定して、添付画像のスマートフォン表示の崩れについて、原因の候補と確認手順を整理してください。まだコード変更はしないでください」
最初の壁は、依頼文を長く書きすぎることです。背景をすべて貼るより、「何を調べるか」「どこまで進めるか」「変更してよいか」を先に書くと、結果を確認しやすくなります。
5. 対象と条件を追加する
次の情報があると、AIの判断が安定しやすくなります。
- 対象リポジトリとブランチ（変更を分けて管理する場所）
- 問題が起きるページや画面
- 再現手順（同じ問題を起こす操作）
- 期待する結果と実際の結果
- 利用している端末、ブラウザ、OS
- 対応してよい範囲と期限
情報が足りない場合は、「不足している情報を先に質問してください」と依頼しても構いません。分からないことを推測させたまま進めるより、安全な進め方です。
6. 調査結果と計画を確認する
- AIが返した調査結果で、対象ファイル、原因の候補、確認方法を読みます。
- 計画に含まれる変更対象、想定される影響、テスト方法を確認します。
- 意図と違う場合は、「コード変更はせず、計画を修正してください」と伝えます。
- 内容に問題がなければ、Issue作成またはコード変更へ進めます。
実際に使うと、最初に見るべきなのはコードの細部より「どのファイルをなぜ変更するのか」です。ここで違和感を見つければ、後の修正やレビューの手戻りを減らせます。
7. IssueまたはPull Requestを確認する
- 作成されたIssueを開き、タイトル、背景、再現手順、対応方針を確認します。
- Pull Requestが作成された場合は、Files changed（変更されたファイルの一覧）を開きます。
- 差分（変更前後の違い）を上から読み、意図しない変更がないか確認します。
- テスト結果、画面表示、セキュリティ上の問題、既存機能への影響を確認します。
- 問題がなければ、決められたレビューや承認の手順に進みます。
AIが作成したPull Requestは、完成品ではなくレビュー前の案です。人が確認し、必要なら修正してから採用してください。
依頼文の例
最初は、次のように具体的な条件を含めると進めやすくなります。
- 「添付画像のスマートフォン表示の崩れについて、原因の候補と確認手順を整理してください」
- 「このスレッドの内容をもとに、再現手順・期待する結果・実際の結果を整理してIssue案を作ってください」
- 「対象リポジトリのログイン画面について、影響範囲を調査し、修正方針を計画してください。まだコード変更はしないでください」
- 「計画を確認しました。この内容で修正し、Pull Requestの説明文も作成してください」
「調べる」「計画する」「変更する」を分けるのがコツです。いきなり実装を依頼せず、まず確認用の計画を出してもらうと安心です。
実際に使って分かった注意点
会話の範囲を指定しないと、情報が混ざりやすい
同じスレッドに複数の不具合や別案件の相談があると、AIが対象を取り違えることがあります。依頼するときは「このメッセージ以降の表示崩れだけを対象にしてください」のように範囲を区切ります。
画像だけでは原因まで分からないことがある
画像は症状の把握には役立ちますが、ブラウザ、端末、再現手順、期待する表示が分からないと原因の特定は難しくなります。画像を添付するときは、発生ページと操作手順も一緒に書きます。
AIが作ったIssueとPull Requestは同じものではない
Issueは「何を調べる、直すか」を管理するチケットです。Pull Requestは「実際に変更したコードを確認する依頼」です。Issueが作成された段階で修正まで完了したわけではありません。
権限エラーは依頼文の問題とは限らない
AIが止まったときは、指示が悪いとは限りません。GitHubのリポジトリ権限、組織のCopilot設定、SlackやTeamsのアプリ許可を順番に確認します。
向いている人・向いていない人
向いている人
- チャットで仕様や不具合の相談が多い社内Web担当者
- GitHubへの転記やIssue作成に時間がかかっている人
- 開発者へ渡す情報を整理するのが苦手な人
- Web制作の小さな改善を、手順を確認しながら進めたい人
- 調査、計画、レビューの流れをチームで整えたい人
- SlackやTeamsに画像や画面キャプチャをよく共有するチーム
向いていない人
- AIの出力を確認せず、そのまま公開や本番反映まで任せたい人
- 機密情報を含む会話を、組織のルール確認なしで外部サービスと連携したい人
- まだGitHubのリポジトリや作業ルールが決まっていないチーム
- 誰が承認するか、どのテストを行うかが決まっていないプロジェクト
- チャットの会話を整理せず、AIにすべて読み取ってほしい人
特に、レビュー担当者や本番反映のルールがない状態では、連携より先に開発フローを整えるのがおすすめです。
注意点と対処法
プレビュー機能なので、画面や対応範囲が変わる可能性があります。重要な開発では、AIの結果を必ず人がレビュー（内容を確認）してください。
- 情報が足りない：再現手順、対象ページ、期待する結果を追加する
- 意図と違う計画になる：コード変更の前に、計画だけを出すよう依頼する
- 機密情報が含まれる：社内ルールや管理者の方針を確認し、不要な情報は貼らない
- 権限で止まる：自分だけで解決しようとせず、GitHubやチャットの管理者に確認する
- 変更内容が不安：Pull Requestの差分と説明を読み、テスト結果を確認してから判断する
- 対象を混同する：リポジトリ名、ブランチ名、対象画面を依頼文に書く
よくある質問
無料で使えますか？
SlackやMicrosoft Teamsとの連携は、有料のGitHub Copilotプラン向けです。無料で利用できる機能として案内されているものではありません。料金や利用条件は、契約中のプランと公式の最新情報を確認してください。
SlackとTeamsのどちらを選ぶべきですか？
普段、相談やファイル共有をしている方を選ぶのがおすすめです。Slackはファイルや添付ファイル、メッセージリンクを使いやすく、Teamsはインライン画像、転送メッセージ、チャネルやスレッド履歴を材料にしやすい点が特徴です。
AIが作ったコードをそのまま使っても大丈夫ですか？
そのまま使うのは避けてください。差分、動作、セキュリティ上の問題、既存機能への影響を人が確認してから採用します。
最初は何を依頼すればよいですか？
「原因を調べる」「Issue案を作る」など、結果を確認しやすい作業がおすすめです。慣れてから計画作成やコード変更へ進みましょう。
依頼したのにAIが動きません。何を確認すればよいですか？
まず、GitHubアカウントの接続、Copilotプラン、組織の許可、対象リポジトリへの権限、サンドボックスの設定を確認します。すべて問題がなければ、プレビュー機能の対象外や一時的な障害の可能性もあります。
まとめ：今日から小さな相談をIssueに変えてみよう
GitHub CopilotのSlack・Microsoft Teams連携を使うと、会話、画像、添付ファイルをもとに、調査からIssueやPull Request作成まで進めやすくなります。特に、社内Web担当者が開発者へ依頼する前の情報整理に役立ちます。
一方で、これはAIに丸ごと任せる機能ではありません。料金、権限、社内ルールを確認し、AIの調査結果、計画、コード差分を人がレビューする前提で使いましょう。
今日からできること
- GitHub Copilotのプランと組織の利用許可を確認する
- 公開しても問題のない小さな不具合を1つ選ぶ
- 対象リポジトリ、再現手順、期待する結果を整理する
- 「原因を調べて、Issue案を作って」と依頼する
- AIの結果を読み、必要なら人が修正してからGitHubの作業に進める
最初の一歩は、身近な不具合について「原因を調べて、Issue案を作って」と依頼してみることです。いきなり本番のコード変更を任せず、まずは会話を整理するところから始めると、連携の便利さと注意点を無理なく確認できます。
関連記事
- GitHub Copilotの自動モデル選択を強化、コスト・品質・速度で使い分ける方法
- GitHub Copilotのコードレビューがプルリクエスト承認に対応、管理者設定と注意点を解説
参考・公式情報
- github.blog
- docs.github.com
- docs.github.com
Amazonで関連商品を探す
GitHub CopilotをSlack・Microsoft Teamsから使う方法｜プレビュー版で相談から開発依頼までをAmazonで探す
