こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。
GitHub CopilotをSlackやTeamsで使えると聞いても、「結局、何を頼めるの?」と感じますよね。サービス名だけでは、自分の仕事に役立つ場面が浮かびにくいと思います。
できるのは、いつものチャットから、GitHubに保存したプログラムや説明書をAIに調べてもらい、作業メモや修正案を作ることです。たとえば「申し込みボタンが動かない」と話している場所から、そのまま原因の調査を頼めます。
この記事では、言葉の意味、3つの活用例、使い始める手順の順に説明します。読み終わったら、あなたのチームで使えそうかを判断し、管理者に必要な設定を確認して、最初の依頼文を作れるようになります。
- GitHub・Copilot・Slack・Teamsがそれぞれ何をするものか
- 不具合の調査や作業メモづくりに使う具体例
- 使い始める前に必要な契約と設定
- そのまま参考にできる依頼文と結果の確認方法
CopilotのSlack・Teams活用とは
まずは、使う場面を思い浮かべてみましょう。ここで扱うのは、主にWebサイトやアプリを作るチーム向けの機能です。プログラムを書く人だけでなく、不具合を見つけて担当者へ伝える人にも関係があります。
まず何ができるのか
たとえば、チームのチャットに「スマートフォンだと申し込みボタンが押せません」と書き込まれたとします。これまでは、誰かが話を読み、関係するプログラムを探し、作業する人へ説明し直していたかもしれません。
この連携を使うと、その会話からCopilotへ「関係する場所を調べて」と頼めます。Copilotは、利用を許可されたGitHub上の資料やプログラムをもとに調査し、結果や作成したものへのリンクを返します。
会話の中で見つかった困りごとを、次の作業につなげやすくなる。これが、この機能を使ういちばん分かりやすい目的です。調べた内容を読んでから、作業メモの作成や修正案づくりへ進められます。
| 頼みたいこと | 受け取りたいもの | 人が次にすること |
|---|---|---|
| 不具合に関係する場所を調べる | 原因の候補と、その根拠 | 同じ不具合が起こるか確かめる |
| 会話を作業メモにする | 困っている点と直してほしい内容 | 抜けや思い違いを直す |
| 説明書やプログラムの修正案を作る | 変更した箇所を見比べられる案 | 内容と動作を確認して採用を決める |
ただし、AIの答えには間違いもあります。「修正案ができた」と「問題が解決した」は別の段階です。実際に使われているWebサイトへ反映する前に、人が確かめる時間を残しましょう。
GitHubで管理している対象がない場合は、まず何を調べてもらうのかを決める必要があります。この記事で紹介するのは、チャット内のあらゆる仕事を引き受ける機能ではなく、GitHub上の開発作業につながる使い方です。
GitHubとCopilotの役割
GitHub(ギットハブ)は、プログラムや資料を保存し、変更の記録を残しながら、複数人で作業できるサービスです。「誰が、どこを、どう変えたか」を追えるので、チームでWebサイトやアプリを作るときによく使われます。
学校の共同制作で考えると、GitHubは作品の材料と作業記録を置く共有の場所に近い存在です。原稿の最新版がどれか分からなくなるのを防ぎ、変更した内容を相談しやすくする役割があります。
GitHub Copilot(ギットハブ・コパイロット)は、その作業を助けるAIです。保存されている内容を読んで説明したり、直し方を考えたり、変更案を作ったりします。「GitHubが作業場所、Copilotが手伝うAI」と覚えると分かりやすいですよ。
今回使う仕組みは、公式には「Copilot cloud agent」と呼ばれます。この記事ではネット上で調査や修正を進めるAIの作業係と考えてください。依頼した作業は専用の環境で進み、結果をあとから確認できます。
SlackとTeamsは会話の場所
Slack(スラック)とMicrosoft Teams(マイクロソフト・チームズ)は、仕事やチーム活動で連絡を取り合うサービスです。Slackは話題ごとのチャット、Teamsはチャットやオンライン会議などに使われます。
どちらにも、チームや話題ごとの部屋にあたる「チャンネル」があります。また、一つの投稿に返信をつなげた会話を「スレッド」と呼びます。この記事では、できるだけ「部屋」「同じ会話」と言い換えて説明しますね。
今回の連携では、この会話の場所にGitHubアプリを追加します。アプリに話しかけると、依頼がCopilotへ届く仕組みです。チャット欄で使う@GitHubは、「GitHubアプリさん、お願いします」と呼びかける目印だと思ってください。
会話の場所がSlackでもTeamsでも、調査する対象はGitHubにあるプログラムや資料です。Teamsで使う場合も、ここで呼び出すのはGitHubアプリ。Microsoft 365 Copilotと名前が似ていますが、この記事の利用条件はGitHub Copilot側で確認します。
最初に覚えたい4つの言葉
ここから先で出てくるGitHubの言葉は、次の4つです。英語のまま読むと難しく見えますが、「保管場所」「作業メモ」「別の作業場所」「修正案の確認依頼」と置き換えてみてください。
| 言葉 | やさしく言うと | 今回の例 |
|---|---|---|
| リポジトリ | プログラム・資料・変更の記録をまとめた保管場所 | 申し込みサイトの材料が入った箱 |
| Issue(イシュー) | 不具合や、これからやることを書き残す作業メモ | スマートフォンでボタンが押せない、という記録 |
| ブランチ | 元の内容と分けて変更を進めるための作業の枝分かれ | ボタンを直すために分けた作業場所 |
| プルリクエスト(PR) | 変更内容を見せて、取り込んでよいか確認する依頼 | ボタンの直し方をチームに見てもらう修正案 |
たとえば「リポジトリのIssueをもとにPRを作る」は、「保管場所にある作業メモを読んで、確認してもらうための修正案を作る」という意味です。言い換えると、やろうとしていることが見えてきますね。
依頼するときは、保管場所を示すリンクがあると伝わりやすくなります。「うちのサイト」だけでは、どのサイトの材料を見るのか分かりません。GitHubの担当者に、対象のリポジトリのリンクを教えてもらいましょう。
作業メモができても、プログラムはまだ直っていません。修正案ができても、公開中のサイトに反映されたとは限りません。返ってきたものがこの4つのどれにあたるのかを確認すると、「どこまで終わったか」を判断しやすくなります。

活用例:不具合の原因を調べる
ここからの3例は、使い方をイメージするための架空の場面です。実際の導入結果や、必ず同じ回答が出ることを示すものではありません。
最初は、申し込みサイトの担当チームです。パソコンでは使えるのに、スマートフォンでは送信ボタンが押せないという連絡が届きました。詳しい原因が分からなくても、まずは起きたことを具体的に伝えます。
依頼文の例
@GitHub 対象は[申し込みサイトのリポジトリのリンク]です。スマートフォンで入力後、送信ボタンを押しても次の画面に進めません。関係するプログラムを調べ、原因の候補と、その根拠を教えてください。まずは調査だけで、ファイルは変更しないでください。
ここで受け取りたいのは、「この部分が関係していそう」「この条件で問題が起こりそう」という説明です。さらに、確認したファイル名や、まだ分からない点も書いてもらうと、担当者が続きを調べやすくなります。
たとえば返答に「入力を確認する処理を調べる必要がある」とあれば、担当者は実際に同じ入力を試します。原因の候補が複数あるなら、どれを先に確認するか相談できます。最初の成果は、修理の完了ではなく、調べる場所と次の確認が分かることです。
画面の写真を添える場合は、入力した名前やメールアドレスが写っていないか確認してください。発生した日時、端末の種類、直前に押したボタンも文章で添えると、写真だけより状況が伝わります。
結果が難しい言葉で返ってきたら、「専門用語を減らして、何が起きているかを3文で説明して」と追加で頼んで構いません。分からないまま修正へ進むより、まず説明を理解することが次の判断につながります。
活用例:会話を作業メモにする
次は、チームの会話に「この画面に戻るボタンがほしい」「どこへ戻るの?」「入力内容は消したくない」と、希望や確認事項が次々に出てきた場面です。そのままだと、作る人が大事な条件を見落とすかもしれません。
そんなときは、話し合いをもとに作業メモの案を作ってもらいます。作業メモには、困っていること、望む動き、完成したかを確かめる方法を分けて書くと、読む人が迷いにくくなります。
依頼文の例
@GitHub この会話をもとに、[対象のリポジトリのリンク]で使う作業メモの案を作ってください。「困っていること」「追加したい動き」「完成を確かめる方法」に分け、決まっていない点は質問として残してください。まだIssueは作成せず、案をこの会話に出してください。
たとえば「戻るボタンを付ける」だけでなく、「前の入力画面へ戻り、入力済みの内容を残す」「戻ったあと、再び確認画面へ進めることを確かめる」と書かれていれば、何を作るのかが具体的になります。
人が内容を読み、話し合っていない条件が混ざっていないか確かめたら、「この内容でIssueを1件作って」と次の依頼をします。作成できるかどうかは、その人とアプリに許可された操作の範囲にもよります。
この使い方の成果は、会話を読み返さなくても、担当者が着手できるメモが残ることです。担当する人や期限が未定なら、AIに勝手に決めてもらわず、未定のまま残してチームで決めましょう。
活用例:説明書の修正案を作る
3つ目は、GitHubに保存した説明書を直す場面です。新しく参加した人から「最初の設定方法が分かりません」と相談されたら、困った部分を手がかりに説明を補えます。
GitHubでは、使い方をまとめたファイルが「README」という名前になっていることがあります。これは、最初に読んでほしい案内書のようなものです。ここでは、その説明書に準備の手順を足す例を考えます。
依頼文の例
@GitHub [対象のリポジトリのリンク]にあるREADMEを確認してください。初めて参加する人向けに、作業を始める前の準備を番号付きで説明する修正案を作ってください。分からない手順は推測で補わず、確認事項として残してください。プログラムは変更せず、説明書の変更だけをプルリクエストにしてください。
結果が届いたら、変更前と変更後を見比べます。「準備するものが書かれているか」「その順番で進められるか」「実際には使っていない道具が混ざっていないか」が確認のポイントです。
文章が自然でも、手順が正しいとは限りません。説明書を読んでいなかったメンバーに試してもらうと、書いた側では気づけなかった抜けが見つかることもあります。内容を確かめてから、チームの手順に沿って取り込みます。
修正案を確認する流れを知りたい場合は、Copilotによる修正内容の確認と自動対応の解説も参考にしてください。この記事の例では、まず変更する対象を説明書1つに絞ると、何が変わったかを追いやすくなります。
CopilotのSlack・Teams活用手順
使いたい場面が決まったら、契約と設定を確認しましょう。ここからは、管理者にお願いすることと、自分で操作することを分けて説明します。すでにチームで設定済みなら、自分のGitHubアカウントをつなぐところから進められます。
使えるか先に確認する
SlackやTeamsに入れるだけで、誰でもすぐに使えるわけではありません。GitHub Copilotの有料契約、GitHubアプリの導入、対象の保管場所で作業する許可などが関係します。会社のアカウントなら、最初に管理者へ確認すると話が早いです。
| 確認するもの | 何のために必要か | 主に確認する人 |
|---|---|---|
| Copilotの契約と利用対象 | 自分のアカウントで機能を使えるか確かめる | 本人・契約の管理者 |
| GitHubアプリ | チャットからGitHubへ依頼を届ける | チャットやGitHubの管理者 |
| AIがネット上で作業する設定 | 調査や修正を進める場所を使えるようにする | GitHubの管理者 |
| 自分のGitHubアカウントとの接続 | 誰の依頼かを確認できるようにする | 利用する本人 |
| 対象の保管場所への書き込み権限 | その場所で作業を開始・変更できるか確かめる | GitHubの管理者 |
管理画面では、AIの作業場所が「cloud sandboxes」と表示されます。ネット上に用意される専用の作業室という意味で捉えてください。2026年9月29日に確認した公式手順では、SlackとTeamsの両方で、この設定を有効にする必要があります。
また、「見られる」と「作業を始められる」は同じではありません。チャットの参加者が意見を書けても、対象のリポジトリで作業を始めるには書き込み権限が必要です。ゲストや外部協力者には、作業の開始・継続指示に制限もあります。
利用できる契約の確認
現在の公式手順は「すべての有料Copilotプラン」を対象としています。一方、2026年9月25日の更新案内には、組織向けのBusiness・Enterpriseを対象とする記載があります。試験提供中で変更もあるため、契約名だけで判断せず、自分の画面と管理者の設定を確認してください。
管理者には「GitHub CopilotをSlack(またはTeams)から使いたいです。対象はこのリポジトリです。アプリ、AIの作業機能、cloud sandboxes、私の作業権限を確認してください」と伝えると、確認してほしいことが一度に伝わります。
公式の確認先は、GitHub公式のSlack連携手順とTeams連携手順です。管理者にこの2つを渡しておくと、画面上の英語と照らし合わせやすくなります。

Slackで使い始める
Slackでは、チームの作業スペースにGitHubアプリが入っていることを確認します。すでに入っていても、古い状態なら管理者に更新を確認してもらってください。次に、自分のGitHubアカウントをアプリにつなぎます。
- SlackでGitHubアプリを開くか、会話の中で
@GitHubと入力する - 画面の案内に従って、自分のGitHubアカウントを接続する
@GitHub helpで使い方を確認する- 対象のリポジトリと、頼みたいことを書いて送る
- 作業用の場所が作られたら、そこで結果や追加の指示を確認する
現在の公式手順では、作業を頼むと「Slack Code」という専用の部屋が作られます。作業が始まったあとの追加指示は、その専用の部屋にまとめます。元の会話にも別の場所にも同じ依頼を書くと、どの指示が続きなのか分かりにくくなるためです。
最初の依頼は「この説明書に、初めて読む人が迷いそうな箇所があるか調べて」のように、小さくすると確認しやすいですよ。返ってきた文章とリンクを開き、どの保管場所についての回答かを確かめます。
Teamsで使い始める
Teamsでも、入り口はGitHubアプリです。Teamsを使っているから設定済みとは限らないので、アプリがチームに追加され、必要な利用許可が済んでいるかを確かめましょう。
- Teamsの対象チームにGitHubアプリが追加されているか確認する
- アプリの案内に従って、自分のGitHubアカウントを接続する
- 会話の中で
@GitHub helpと入力し、使い方を確認する @GitHubに続けて、対象の保管場所と依頼内容を書く- 結果を読み、追加の依頼は同じ会話で
@GitHubを付けて伝える
たとえば会議のあと、「今日決めた内容を、開発担当者が読める作業メモにして」と頼む場面が考えられます。その場合は、決定した内容を会話へ書いておきましょう。AIが参照できる場所にない会議内容まで、分かっているとは考えないことが大切です。
話しかける相手がGitHubアプリかも確認してください。Teamsの中には複数のアプリやAI機能があり、別のCopilotを開いていても、この記事の手順どおりには進まない場合があります。
伝わる依頼文を作る
依頼文は、長くするより「どこを」「何のために」「どこまで」「どんな形で」をそろえると伝わりやすくなります。「全部よくして」では、何を変えたら終わりなのか判断できません。
「どこを」には、対象のリポジトリや説明書の名前を書きます。「何のために」には、誰が何に困っているか。「どこまで」には調査だけか、修正案までか。「どんな形で」には、短い説明、箇条書き、作業メモなどを指定します。
初回に使いやすい依頼文
@GitHub 対象は[確認したいリポジトリのリンク]です。[困っていること]を解決したいので、関係するプログラムや資料を調べてください。まずは調査だけにして、ファイルは変更しないでください。結果は「分かったこと」「まだ不明なこと」「人が次に確認すること」の3つに分け、専門用語には短い説明を付けてください。
角括弧の部分を、自分たちの対象と困りごとに置き換えて使います。正確なファイル名が分からなければ、「申し込み画面に関係する部分を探して」と書いても構いません。その場合は、見つけた対象が合っているかを先に確認しましょう。
返答が広すぎたら、「今回はスマートフォンの送信ボタンだけに絞って」と対象を小さくします。説明が足りなければ、「その判断の根拠になった場所を示して」と頼めます。最初の1回で完璧な依頼文を作ろうとせず、結果を見ながら具体的にしていく進め方です。
なお、「変更しないで」と書くことは作業内容の指示です。アプリの権限そのものを制限する設定ではありません。触れてよい保管場所や操作の範囲は、管理者側の設定でも確認してください。
料金と共有情報を確認する
使い始める前に、料金の確認先を決めておきましょう。Copilotには「AI credits」という利用量を数える単位があります。ここでは、AIに仕事を頼むと消費する利用枠と考えると分かりやすいです。今回の機能が無料で使い放題になる、という意味ではありません。
会社で使うなら、管理者に「今の契約に含まれる範囲」「追加料金が発生する条件」「使いすぎを止める設定」の3点を確認します。金額を一つだけ覚えるより、自分たちの契約でどこまで使えるかを把握することが大切です。
組織向けの公式説明では、支出の上限を設定しても、通知だけで利用が止まらない場合があります。追加利用を止めたい場合は、「上限に達したら利用を停止する」という設定まで確認します。詳しくはGitHub公式の予算設定手順と、当サイトのCopilotの予算と上限に達したときの対応をご覧ください。
もう一つは、会話に含まれる情報です。公式手順では、呼びかけた会話のつながり全体がAIへの材料となり、その内容が作成物にも保存されると説明されています。最後に送った1文だけが渡るとは限りません。
必要な情報だけで頼みたい場合は、GitHubアプリへの個別メッセージを使いましょう。話題を絞った新しい会話を作る方法もあります。パスワード、顧客の個人情報、共有する許可のない資料は、依頼文や添付画像に含めないようにします。
2026年9月25日の更新では、会話に添えたファイルや画像などを使いやすくする改善が案内されました。対応する内容はSlackとTeamsで異なるので、使うときはGitHub公式の更新案内を確認してください。便利になっても、見せてよい情報を選ぶ作業は人が行います。
表示されないときの確認
@GitHubに話しかけても始まらないときは、同じ文章を何度も送る前に、止まっている場所を確認します。アプリが見つからないのか、アカウントを接続できないのか、依頼したあとにエラーが出るのかで、確認先が違います。
| 困っている状態 | 先に確認すること |
|---|---|
| GitHubアプリが見つからない | 対象のチームに導入されているか、アプリの使用が許可されているか |
| アカウントの接続を求められる | 作業に使うGitHubアカウントと接続しているか |
| 保管場所を使えない | 対象のリンクが正しいか、自分とアプリに必要な許可があるか |
| 作業を開始できない | 契約の対象か、AIの作業機能と専用の作業室が有効か |
| 途中で止まる・利用上限が出る | エラーの内容、利用枠、管理者が決めた上限 |
管理者に相談するときは、「どの画面で」「何をしたら」「どんな表示が出たか」を伝えます。表示された文章や、個人情報を隠した画面の写真があると、状況を共有しやすくなります。パスワードを送る必要はありません。
結果が届かない場合は、GitHub側に作業メモや修正案ができていないかも確認してください。すでに作成されているのに同じ依頼を再送すると、似た作業が重なるおそれがあります。Slackなら作業用の専用の部屋、Teamsなら依頼した会話も見直します。

よくある質問
Q1. プログラムが書けなくても役立ちますか?
A. 不具合の状況を伝えたり、会話から作業メモの案を作ったりする場面では役立ちます。ただし、作業を始めるための権限は必要です。プログラムの変更内容や動作の確認は、分かる担当者と一緒に進めましょう。
Q2. 無料で使えますか?
A. 現行の公式手順では、GitHub Copilotの有料プランが前提です。SlackやTeamsを使っているだけでは条件を満たしません。利用枠や追加料金の条件は、自分の契約または管理者に確認してください。
Q3. TeamsのCopilotと同じものですか?
A. この記事で使うのは、TeamsのGitHubアプリから呼び出すGitHub Copilotです。Microsoft 365 Copilotとは別に、GitHub側の契約、アプリの接続、作業する保管場所への権限を確認します。
Q4. 頼めばサイトの修正まで完了しますか?
A. 依頼に応じて調査や修正案の作成を進められますが、公開中のサイトで問題が解決したとは限りません。変更内容と動作を人が確認し、チームの手順に沿って取り込みや公開を行います。
Q5. 最初は何を頼めばよいですか?
A. 自分で答えを確かめられる、小さな調査がおすすめです。「この説明書で初めての人が迷いそうな点を教えて」など、対象を一つに絞り、まずは変更せず調べてもらいましょう。
CopilotのSlack・Teams活用まとめ
この機能で目指せるのは、チャットで出た困りごとを、調査結果、作業メモ、修正案へつなげることです。GitHubがプログラムや資料の保管場所、Copilotが作業を手伝うAI、SlackやTeamsが依頼を伝える会話の場所になります。
使い方を考えるときは、「AIに何でも任せる」では広すぎます。「不具合に関係する場所を知りたい」「会話から次の作業を決めたい」「説明書を読みやすく直したい」のように、受け取りたい結果を一つ決めてみてください。
読み終わったら、この3つから始めましょう
- GitHubにある対象を一つ選び、そのリポジトリのリンクを確認する
- 管理者と契約・アプリ・作業機能・権限を確認し、自分のアカウントを接続する
- 記事中の依頼文を使って「調査だけ」を頼み、返ってきた結果を自分で確かめる
まず一つの困りごとについて、「どこを調べればよいか」が分かれば、最初の一歩は十分です。その結果を見てから、作業メモや修正案へ進みましょう。何を頼み、何が返り、人が何を確認するかを決めておくと、チームの日々の相談に取り入れやすくなります。
