Slack で出たバグ報告や仕様メモを、あとで誰かが GitHub issue に転記する。多くの開発チームで、このひと手間が作業漏れの原因になります。2026年3月30日の GitHub changelog で追加されたのが、Slack から Copilot を使って GitHub issue を作成する機能です。GitHub app を Slack でメンションし、自然言語で依頼すると、会話の文脈をもとに issue の下書きが作られ、確認してそのまま起票できます。子 issue の作成や、スレッドでの詰めにも対応しています。 (The GitHub Blog)
この記事では、Slack から Copilot で GitHub issue 作成する流れ、従来の Slack 連携との違い、現場で効く使い方、詰まりやすいポイントをまとめます。結論を先に言うと、この機能が強いのはSlack の議論を、その熱量のままタスクに変えられることです。QA の指摘、障害対応、会議の決定事項を、別タブに移って手でまとめ直す前に issue 化できます。
Slack の会話から GitHub issue を起こす機能で何が変わるのか
今回の追加でできるようになったのは、Slack で @GitHub に「何を追跡したいか」を自然言語で伝えるだけで、タイトル・本文・担当者・ラベル・マイルストーンなどを含む構造化された issue を作る流れです。さらに、親子関係を持つ sub-issue の作成や、スレッド上で詳細を詰めてから起票する使い方も想定されています。GitHub はこれを、チームがすでに議論しているチャットの文脈に issue 作成を持ち込むものとして案内しています。 (The GitHub Blog)
重要なのは、Slack で issue を作れるようになったこと自体ではありません。会話の要約と転記を人手ではなく Copilot の下書き作成に置き換えられることが、本当の変化です。
従来の Slack issue 化との違い
Slack から GitHub issue を作ること自体は、以前からできました。従来は /github や /github open owner/repo でダイアログを開き、タイトルや説明を人が入力して起票する形です。新しい Copilot 連携では、GitHub app へのメンションで依頼し、スレッド履歴を文脈として取り込んだ issue ドラフトを Review draft で確認してから作成できます。ラベルや担当者、issue type などのメタデータ候補も提案されます。 (GitHub Docs)
現場で効く差は、主に次の3つです。
- Slack を出ずに「話す」「整理する」「起票する」がつながる
- issue の書式に慣れていない人でも、たたき台を作りやすい
- 起票前にスレッドで詰められるので、曖昧な issue が減りやすい
つまり、Slack 起点の issue 化が“速くなる”だけでなく、抜け漏れと粒度のばらつきを減らしやすいのがポイントです。
導入前に押さえたい前提条件
使い始める前に確認したい前提は5つです。Slack ワークスペースには GitHub app のインストールが必要で、対象チャンネルには /invite @github で app を招待します。各ユーザーは Slack 上で GitHub アカウントを接続し、Copilot が使える状態で、かつ対象リポジトリに issue を作成できる権限を持っている必要があります。GitHub の docs では、Copilot による issue 作成は既存の権限を超えて実行されず、権限を回避もしないと明記されています。 (GitHub Docs)
| 確認項目 | 最低限チェックしたいこと |
|---|---|
| Slack 側 | GitHub app がワークスペースに入っているか |
| チャンネル側 | 起票したいチャンネルに app を招待済みか |
| アカウント連携 | Slack 上の GitHub app と自分の GitHub アカウントが接続済みか |
| Copilot | 自分の GitHub アカウントで Copilot が利用可能か |
| 権限 | その repo で issue を作成できるか |
Slack から Copilot で GitHub issue 作成する基本手順
Copilot は Slack のスレッド履歴を文脈として使って issue の下書きを作ります。なので、長い雑談の途中よりも、論点ごとに分けたスレッドや DM で使うほうが精度を上げやすいです。実際の流れは次のとおりです。 (GitHub Docs)
まずは既定リポジトリを決める
頻繁に起票するチャンネルでは、@GitHub settings で既定のリポジトリを決めておくのが安全です。GitHub の changelog では、チャンネル単位で issue や pull request の作成先となる既定リポジトリを設定できると案内されています。repo を毎回書かなくて済むだけでなく、誤ったリポジトリに issue が立つ事故を減らせます。初回は GitHub app から GitHub アカウント接続や既定リポジトリ設定を求められることがあります。 (The GitHub Blog)
Slack で GitHub app に起票を依頼する
repo を固定していないなら、メッセージ内で対象 repo を明示します。重要なのは、やってほしいことだけでなく、なぜ必要かと完了条件まで入れることです。
@GitHub acme/web-app に bug issue を作成してください。
内容: Safari でプロフィール画像のアップロードに失敗する。
再現手順:
1. 設定画面を開く
2. JPG を選択する
3. 保存する
期待結果: 正常に保存できる
実際の結果: エラーになり保存できない
影響: iPhone ユーザーが画像変更できない@GitHub acme/search に feature request を作成してください。
Slack のこの議論をもとに、検索結果のあいまい一致対応をまとめてください。
完了条件は「typo を含む検索でも主要候補が返ること」です。@GitHub acme/platform に親 issue を作成してください。
テーマは「監査ログの整備」。
あわせて API、画面、テストの子 issue に分けてください。Review draft で下書きを確認する
Copilot は Review draft から issue の下書きを開き、タイトルや変更内容の要約を提案します。prompt に応じて、ラベル・担当者・issue type などのメタデータ候補も付けられるため、そのまま作成せずにタイトルが抽象的すぎないか、再現手順や完了条件が落ちていないか、担当者やラベルが妥当かを確認してから Create するのが実務向きです。 (GitHub Docs)
1件で重ければ親子 issue に分ける
議論の中に複数の作業が混ざっている場合は、無理に1本の issue に閉じ込めないほうが後で楽です。今回の機能は sub-issue の作成にも対応しているので、親 issue に目的や背景を書き、実装・検証・ドキュメントを子 issue に分ける運用がしやすくなります。 (The GitHub Blog)
Slack 起点の issue 化が特に効く場面
QA や障害対応の一次整理
不具合報告は、口頭やチャットのままだと流れやすい領域です。再現手順、影響範囲、期待結果と実際の結果をその場でまとめて issue 化すれば、報告者の記憶が新しいうちに必要情報を残せます。
会議の決定事項をその場でタスク化
設計レビューや週次定例で決まったことは、議事録と issue が分かれると抜けやすくなります。Slack スレッドから起票すれば、「決まったこと」と「誰がいつまでにやるか」を同じ流れで残せます。
技術的負債の見つけっぱなしを防ぐ
レビュー中に出た「今すぐ直さないけれど放置したくない改善点」は、後回しにされがちです。短いスレッドからでも issue の下書きに落とせると、負債を backlog に乗せる心理的ハードルが下がります。
Copilot 連携で開発フローはどう変わる？
一番大きい変化は、作業の開始地点が GitHub ではなく Slack になることです。これまでは「気づく」「話す」「誰かが別で起票する」の3段階でしたが、今後は「気づく」「その場で下書き生成する」「確認して起票する」に縮みます。
起票の責任者が曖昧でも止まりにくい
issue の書き方に慣れていない人でも、まずは自然言語で依頼すればたたき台が出るため、PM・QA・CS・デザイナーなども起点になりやすくなります。ただし、最終的な作成可否は対象 repo の権限に依存します。 (GitHub Docs)
会話の文脈が消えにくい
Copilot はスレッド履歴を文脈として使うため、「なぜこのタスクが必要か」が issue に落ちやすくなります。単なる todo ではなく、背景のある issue を残しやすいのは大きな差です。 (GitHub Docs)
分解と優先順位づけをその場でやりやすい
親子 issue やラベル候補が扱えるので、起票直後から triage しやすい形に近づけられます。作業漏れ防止だけでなく、後工程の整理コストも下げやすくなります。 (The GitHub Blog)
失敗しやすいポイントと防ぎ方
Slack 起点の issue 化は便利ですが、雑に使うと backlog が荒れます。最低限、次の点は押さえておくと安定します。
| 失敗しやすい点 | 起きがちなこと | 防ぎ方 |
|---|---|---|
| スレッドが長すぎる | 関係ない文脈まで下書きに混ざる | 1論点ごとに新しいスレッドか DM を使う |
| repo を指定しない | 別 repo に起票してしまう | @GitHub settings で既定 repo を決めるか、毎回 repo 名を書く |
| 依頼が抽象的 | 「改善する」「対応する」だけの曖昧 issue になる | 背景・影響・完了条件を1行ずつ入れる |
| 下書きを確認しない | タイトルやラベルがずれて triage が遅れる | Review draft で 30 秒だけ確認する |
| 何でも 1件に詰める | 実装・検証・周辺作業が混在する | 親 issue と子 issue に分ける |
もう1つ見落としやすいのが複数ワークスペース運用です。GitHub docs では、Slack の mentions は最後に GitHub app にログインしたワークスペースでのみ動くと案内されています。複数の Slack 環境を行き来するチームでは、「昨日まで反応したのに今日は動かない」というときに、まず再ログイン状況を疑うと切り分けが早いです。 (GitHub Docs)
定着させるなら、この運用だけは決めておく
機能を入れただけでは、Slack から Copilot で GitHub issue 作成は定着しません。現場で効くのは、次のような小さなルールです。
- バグ報告チャンネル、改善提案チャンネルのように、チャンネルごとに既定 repo を分ける
- 起票依頼には「何が困るか」「誰に影響するか」「完了条件」を入れる
- Slack 発の issue には source 用のラベルを付ける
- 週1回、Slack 起点で作られた issue をまとめて triage する
この4つだけでも、「とりあえず起票は増えたが整理されない」状態をかなり防げます。
まず試すなら、1チャンネルで十分
Slack から Copilot で GitHub issue 作成する機能は、単なる便利機能ではありません。Slack に埋もれがちな議論を、そのまま GitHub の追跡対象に変える仕組みです。特に、作業漏れが出やすい QA、障害対応、会議後のタスク化で効果が出やすいはずです。
最初から全社展開する必要はありません。まずは1つの開発チャンネルに GitHub app を招待し、既定 repo を決め、バグ報告を1週間だけ Slack 起点で issue 化してみてください。そこで下書きの品質、誤起票の有無、triage のしやすさを確認すれば、自チームに合う運用が見えてきます。 (GitHub Docs)
コメント