使用方法

バグがすでに報告されている場所を Codex に確認させます。Sentry のアラート、Linear イシュー、GitHub イシュー、PR チェック、デプロイログ、サポートチケット、Slack スレッドなどです。まず手動で一括チェックを 1 回実行し、チャットでレポートを調整してから、スケジュール実行します。

トリアージの全工程には 1 つの Codex チャットを使います：

始める前に、Sentry、Slack、Linear、GitHub など、Codex に必要な プラグイン をインストールします。スタータープロンプト内の角括弧で囲まれたプラグインリストを、実際の @ プラグインチップに置き換えます。次に、角括弧で囲まれた各データソースを、検索対象となる正確な場所に置き換えます。たとえば、Sentry のプロジェクトまたはアラート URL、Slack のチャンネルまたはスレッド、Linear のチーム、ビュー、またはクエリ、GitHub リポジトリ、イシュークエリ、または PR チェック、デプロイリンク、ログファイル、サポートキュー、ダッシュボードなどです。

フェーズ 1：一括チェックの実行

ローカルのコンテキストが役立つ場合（テスト、リポジトリ用ツール、ビルドチェック、CI の失敗など）は、バグを管理するリポジトリから Codex を起動します。バグのデータソースがプラグイン、コネクタ、MCP サーバー、リンク、エクスポート、貼り付けたログ、添付ファイルを通じて利用できる場合は、どのリポジトリからでも一括チェックを実行できます。

まず上記のスタータープロンプトを実行します。一括チェックの対象となるプラグインとデータソースだけを残してください。

たとえば、入力済みのプロンプトでは、一括チェックに含めるプラグインと、対象とする正確なキュー、チャンネル、リポジトリを指定できます。

フェーズ 2：実用的なレポートの作成

自動化する前に、毎日目を通す価値があるレポートになっていることを確認します。

有用な初回レポートには、次の内容が含まれます：

• P0 から P3 の順に並べた、確度の高いバグ
• 1 件のバグにまとめられた重複レポート
• 各バグに紐づいた根拠へのリンクまたは短い引用
• 観測された事実と分けて記載された推測
• 各バグに対する簡潔な推奨アクション

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

• リストの優先順位を決める前に、もう 1 つのデータソースを確認する
• チームがすでに把握しているノイズの多いアラートを除外する
• P0 と P1 のバグだけを返す
• 同じバグを示す Slack の報告、Sentry のアラート、GitHub のチェック失敗をまとめる
• 各バグについて、最も有用なリンクを 1 つだけ示す
• 他の人がイシューを再現したり、適切な担当先へ振り分けたりできるだけの根拠を追加する

フェーズ 3：自動化

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

トリアージ作業のスケジュール設定

フェーズ 4：フォローアップの振り分け

スケジュールに従って生成されるレポートが実用的になったら、その後の対応をどこに振り分けるか決めます。Codex は、チームの Slack チャンネル向けの更新メッセージを下書きしたり、追跡したいバグについて Linear イシューを作成したり、チェックに失敗している PR に GitHub コメントを書いたり、オンコール担当者向けの引き継ぎメモを作成したりできます。