Slack のメッセージから GitHub Issue、そして修正へ
Slack で普段の言葉でバグを説明するだけ。Zero が GitHub Issue を書いて担当者を割り当て、原因が 1 つのコンポーネントに収まる場合は修正とリグレッションテストを含むプルリクエストまで作成し、あなたのレビューを待ちます。
Zero が提供するもの：Slack のメッセージからレビュー待ちの修正まで
vm0 チームの #bug-report チャンネルで実際にやり取りされたスレッドを、そのまま切り取ったものです。メンバーが顧客からの報告を貼り、修正を依頼しました。4 分後には Zero が診断付きで GitHub Issue を作成。最初のメッセージから 14 分後にはプルリクエストを開き、プレビューリンクを投稿しています。 下に 2 枚のキャプチャを並べています。発端となったスレッドと、Zero が書いたプルリクエストです。どちらも公開されているので、Issue も差分もレビューもご自身で確認できます。
スレッドで起きたこと
メンバーが #bug-report に顧客から報告された PWA のレイアウト不具合をスクリーンショット付きで投稿しました。Zero はスレッドを読み、iOS のセーフエリアインセットを考慮していない上部バーが原因だと特定し、ラベルと根拠を添えて Issue #11708 を作成しました。スレッドで修正を求められると、ファイル 1 つ（モバイル上部バーの最小高さとセーフエリアの padding）だけを変更し、プレビューリンク付きでプルリクエスト #11709 を開いて、そこで止めました。レビューとマージは人が行っています。
- メッセージから Issue まで
- 4 分Issue #11708、ラベルは bug と PWA
- メッセージからプルリクエストまで
- 14 分PR #11709、プレビューリンク付き
- 修正が変更したファイル
- 1マージしたのは Zero ではなく人
Slack から GitHub Issue を作成するとはどういうことか
Slack から GitHub Issue を作成するとは、会話の中で誰かが報告したバグを、スレッドを離れて入力し直すことなく、リポジトリ上の構造化された Issue に変えることです。難しいのは API 呼び出しではありません。分かりやすいタイトルを書き、再現手順と期待される挙動を切り分け、ラベルを選び、優先度を決め、適切な担当者を見つけることです。Zero がその作業を引き受けます。Slack のメッセージと前後の返信を読み、Issue の本文を書き、根拠を説明できるラベルと優先度を付け、Slack の表示名を GitHub のハンドルに突き合わせて担当者を割り当て、同じスレッドに Issue のリンクを返信するので、報告者はその場で確認できます。
バグ報告が Slack のスレッドに埋もれてしまう理由
デモの最中に誰かがバグを見つける。あるいは土曜日に顧客から連絡が来る。従来の道のりは長いものでした。GitHub を開き、リポジトリを探し、整形された Issue を書き、担当者を割り当て、その人が着手してコードを読み、修正を書くのを待つ。10 分で終わる変更が、3 人をまたぐ数日がかりの往復になり、しかも報告の半分はスレッドから出ないまま消えていきます。代わりに Slack で説明してください。Zero が再現手順・ラベル・担当者付きで Issue を作成し、原因が限定できる場合はさらに修正とテストを含むプルリクエストまで進めます。あなたはレビューしてリリースするだけです。
Zero が Slack から GitHub Issue を作成する仕組み
ステップ1：ツールを接続する
ステップ2：Zeroに聞く
ステップ3：さらに活用する
このワークフローを支える Slack と GitHub の連携
これはエージェントを間に挟んだ Slack と GitHub の連携です。Zero は Slack で会話を読み、GitHub に記録を書き込みます。各コネクタは個別に許可され、ワークフローが実際に使う範囲に限定されるため、チャンネルの読み取りがリポジトリへの書き込み権限を意味することはありません。
Slack 連携：Zero が読む会話
必須Zero は指定されたメッセージとその前後の返信を読むため、3 つ後の返信で補足された文脈も Issue に反映されます。添付されたスクリーンショットを引き継ぎ、報告者の表示名から担当者を解決し、メッセージのパーマリンクを保持するので、すべての Issue が報告の出発点にリンクします。書き込みは 1 つだけ、同じスレッドへの Issue 番号とリンクの返信です。他のチャンネルへの投稿、DM の送信、他人のメッセージの編集は行いません。
GitHub 連携：Zero が作成する Issue
必須Zero は指定されたリポジトリに Issue を作成します。タイトルは元のメッセージの複製ではなく報告内容から書き起こし、説明、再現手順、期待される挙動、スレッドで言及されていれば対象箇所を含めます。指定されたラベルを適用するか文面から推測し、理由を説明できる優先度を設定し、担当者を割り当てます。作成前に同じ症状の Open Issue を検索し、一致すれば新規作成せず既存 Issue にコメントします。バグを修正できる場合は、ブランチをプッシュし、その Issue をクローズするプルリクエストを作成してレビューを依頼します。書き込み権限は許可されたリポジトリに限定され、範囲はそれで全部です。Issue、コメント、そしてレビュー用に作成するプルリクエスト。マージ、強制プッシュ、リポジトリ設定の変更は行いません。
Zero と Slack 版 GitHub アプリ、自動化ツールの比較
Slack のメッセージからバグを GitHub に届けるには 3 つの工程があります。報告を捕まえること、使える Issue を書くこと、担当者に渡すことです。既存の選択肢はそれぞれ 1 つだけを解決します。
Slack 版 GitHub アプリ
/github と入力するとダイアログが開き、タイトル・本文・ラベル・担当者を自分で埋めます。ブラウザに移動する手間は省けますが、Issue を書くのは依然としてあなたであり、会話の途中でフォームが出てくること自体が「あとで起票しよう」を生む摩擦です。
自動化ツール
ノーコードのツールはトリガーに応じて Slack のメッセージを新しい Issue にコピーできます。コピーされるのは生のメッセージなので、報告者がたまたま書いた文面がそのまま Issue になり、ラベル・優先度・担当割り当て・重複判定のルールはチャンネルごとに自分で定義して保守することになります。
Zero の Slack から GitHub へのワークフロー
Zero はスレッドを読んで Issue を書きます。実際のタイトル、期待される挙動と切り分けた再現手順、根拠を説明できるラベルと優先度、報告者の表示名から一致させた担当者。原因が 1 つのコンポーネントに収まる場合はそこで止まらず、修正とリグレッションテストを含むプルリクエストを Issue に紐付けて作成し、あなたのレビューを待ちます。先に Open Issue を確認し、重複なら新規作成せずコメントし、スレッドにリンクを返信します。
より良い結果のためのヒント
よくある質問
Slack のメッセージから GitHub Issue を作成するには？
Slack と GitHub を Zero に接続し、チャンネルでバグを説明して Zero にメンションします。Zero はメッセージと周辺の返信を読み、タイトル・再現手順・期待される挙動・ラベル・優先度を備えた Issue を書き、指定したリポジトリに作成し、担当者を割り当て、Issue 番号とリンクをスレッドに返信します。フォーム入力は不要です。
Slack 版 GitHub アプリとの違いは？
GitHub アプリは入力用のダイアログを提供するもので、タイトル・本文・ラベル・担当者は自分で書きます。Zero はそれらを会話から書き起こし、作成前に同じ症状の既存 Issue を確認し、1 件ずつではなくチャンネル全体を定期的に処理することもできます。
Zero は Issue を作るだけですか、それともバグを修正できますか？
どちらも行い、どちらをなぜ選んだかを明示します。Issue は必ず作成します。スレッドまたはコードから対象が 1 つのコンポーネントに特定でき、期待される挙動が明確で、先に失敗するテストを書ける場合は、修正とそのテストを含むプルリクエストも作成し、Issue に紐付けてレビューを依頼します。共通ユーティリティ、デザイントークン、プロダクト判断が必要なものは変更せず起票にとどめます。Zero がマージすることはありません。修正はすべて、あなたがレビューするプルリクエストとして届きます。
担当者は自動で割り当てられますか？
はい。Zero はメッセージ内で挙げられた名前、または報告者の Slack 表示名をリポジトリの GitHub ハンドルと突き合わせて割り当てます。メッセージで担当者を明示するのが最も確実です。誰も指定されていない場合はスレッドが指す領域のオーナーにフォールバックし、判断の根拠を Issue に記載します。
重複した GitHub Issue はどう防いでいますか？
作成前に、同じ症状・対象箇所・表現の Open Issue を検索します。一致した場合は新しい Slack スレッドを報告者とタイムスタンプ付きでその Issue にコメントとして追加し、2 件目を作らずに既存 Issue のリンクを Slack に返信します。
再現手順のないバグ報告はどうなりますか？
報告が失われないよう Issue は作成し、再現手順が必要であることを示すラベルを付けたうえで、Slack のスレッドで報告者に手順を尋ねます。回答は、すでに Issue からリンクされているスレッドに集まります。
チャンネル全体からまとめて定期的に起票できますか？
はい。対象のチャンネルとスケジュール（たとえば毎週金曜 16 時）を指定してください。その週のメッセージを読み、不具合を説明しているものごとに Issue を作成し、重複にはコメントし、機能要望や質問は対象外とし、実行内容を報告します。
GitHub ではなく Linear や Jira でも使えますか？
同じワークフローの形は Zero が接続されている任意のトラッカーに適用できます。このページは GitHub コネクタを使う GitHub 版の手順です。Linear も同じ手順で接続でき、指示の中でトラッカーを指定します。
次のバグは Slack を離れずに起票する
Slack と GitHub を接続し、同僚に話すようにバグを説明するだけで、Zero が Issue を書いて担当者を割り当てます。原因が限定できる場合は、プルリクエストも一緒に待っています。