使い方

バグの兆候や報告が普段どこに集まるかを踏まえ、Sentry のアラート、Linear のイシュー、GitHub イシュー、PR チェック、デプロイログ、サポートチケット、Slack のスレッドを Codex に確認してもらいます。まずは手動で一度調査を実行し、チャットでレポートの内容を調整してから、定期実行を設定します。

トリアージの一連の作業は、すべて同じ Codex チャットで行います。

始める前に、Sentry、Slack、Linear、GitHub など、Codex が必要とするプラグインをインストールします。最初のプロンプトでは、角かっこ内のプラグイン一覧を、実際に使用するプラグインの @ チップに置き換えます。次に、角かっこ内の各情報源を具体的な検索対象に置き換えます。たとえば、Sentry のプロジェクトやアラートの URL、Slack のチャンネルやスレッド、Linear のチーム、ビュー、クエリ、GitHub のリポジトリ、イシューの検索クエリ、PR チェックのほか、デプロイへのリンク、ログファイル、サポートキュー、ダッシュボードを指定できます。

フェーズ 1：調査の実行

テスト、リポジトリ内のツール、ビルドチェック、CI の失敗など、ローカルの情報が調査に役立つ場合は、対象のバグを扱うリポジトリから Codex を起動します。プラグイン、コネクタ、MCP サーバー、リンク、エクスポートしたデータ、貼り付けたログ、添付ファイルを通じてバグの情報源を参照できる場合は、どのリポジトリからでも調査を実行できます。

まず、上記の開始用プロンプトを実行します。プロンプトには、調査で使うプラグインと情報源だけを残してください。

たとえば、次の入力例のように、使用するプラグインに加え、調査対象のキュー、チャンネル、リポジトリを具体的に指定できます。

フェーズ 2：レポートの改善

自動化する前に、毎日読む価値のあるレポートになっているかを確認します。

初回のレポートでは、次の点を確認します。

• 注目すべきバグが P0 から P3 の優先度順に並んでいること
• 同じバグについての報告が一つにまとまっていること
• 各バグに根拠となる情報へのリンクまたは短い引用があること
• 推測と実際に確認できた事実が区別されていること
• 各バグについて、次に取るべき対応が簡潔に示されていること

スケジュールを設定する前に、同じチャットでレポートを調整します。たとえば、Codex に次のように依頼できます。

• 優先順位を付ける前に、もう一つ情報源を確認してください。
• チームがすでに把握していて、ノイズになっているアラートを除いてください。
• P0 と P1 のバグだけを表示してください。
• Slack の報告、Sentry のアラート、GitHub での失敗が同じバグを示している場合は、一つにまとめてください。
• バグごとに、最も参考になるリンクを一つだけ示してください。
• 別の人でも問題を再現したり、適切な担当者に回したりできるよう、十分な根拠を添えてください。

フェーズ 3：トリアージの自動化

オンデマンドのレポートが役立つ内容になったら、同じチャットからトリアージタスクのスケジュールを設定します。Codex は、チャットで調整した内容をもとに、定期実行用のプロンプトを作成できます。

トリアージタスクのスケジュール設定

フェーズ 4：調査後の引き継ぎ

定期実行のレポートが役立つ内容になったら、その後の対応をどこに引き継ぐかを決めます。Codex は、チームの Slack チャンネル向けの共有文、追跡したいバグに対応する Linear のイシュー、チェックに失敗した PR に付ける GitHub コメント、オンコール担当者向けの引き継ぎメモを作成できます。