oss-issue-triage

OSS Issue Triage

プロジェクトに寄せられるイシューやプルリクエストをどのように扱うかを決める仕組みを設計します。ラベル付け、受付、応答の約束、当番制、クローズのルールを、メンテナーが実際に対応できるキャパシティに合わせて整えます。

キューが制御不能なのは、ラベルが適切でないからではありません。流入量が対応に使える時間を上回り、その差をどう扱うかを定めた文書がないからです。この収支を明確にしたうえで、設計してください。

2025年には、機械生成された投稿によって、この収支の片側が崩れました。RedMonkのKate Holterhoffは、セキュリティ報告における非対称性をこう表現しています（2026年5月）。「もっともらしい脆弱性報告を生成するコストは、今やトークン換算で数セントです。本物かどうかを評価するには、今も専門家の時間を1時間使います。」流入量はもはや人間の労力に制限されない一方、トリアージの対応能力には限りがあります。そのため、どのような設計でも分類だけでなく、量に対する計画的な対応策が必要です。

個々の項目をトリアージしたり、初回コントリビューションのキューを整理したり、コードをレビューしたり、行動上の問題に対応したりしないでください。それぞれ適切な担当先に振り分けてください。

• 初回コントリビューションの経路、初めて取り組むのに適したイシュー：samber/developer-relations-skills@oss-contributor-onboarding
• 繰り返される質問をドキュメントに反映：samber/developer-relations-skills@developer-troubleshooting-docs
• 敵対的な行動：samber/developer-relations-skills@developer-community-moderation
• スコープを決める担当者：samber/developer-relations-skills@oss-governance
• メンテナー自身のキャパシティ、活動の休止や引き継ぎ：samber/developer-relations-skills@oss-maintainer-sustainability
• 機能リクエストのプロダクト上の判断と、リクエスターへの返信：samber/developer-relations-skills@developer-feedback-loop
• より広範な測定フレームワーク：samber/developer-relations-skills@developer-community-health

インタビュー

一度に1つずつ質問します。可能であれば選択式にし、ユーザーがすでに回答した内容は飛ばします。質問1〜6がすべての前提です。これらに回答がなければ、架空のプロジェクト向けのプロセスを設計することになります。

メモリ：現在のタスクやプロジェクトのコンテキストに関する情報をいくつか保存します。メモリがファイルに保存されている場合は、devrel-context.mdを使用します。別のメモリシステムが使われている場合は、そちらを利用します。タスクに関する情報は別々のセクションに分けてください。完了したタスクは削除します。タスクには日付を追加し、一般的なプロジェクトのコンテキストには日付を付けません。インタビューの回答は、2つのタスク間で異なる場合があります。

1. 対応に割ける時間の上限はどのくらいですか。今日、トリアージを担当している人数、繁忙期に各自が週に割ける時間、トリアージ担当者を増やしたりトラッカーの設定を変更したりできるかを教えてください。
2. これをいつまでに整える必要がありますか。リリース、監査、またはすでに誰かに公表した対応目標はありますか。
3. このバックログを解消したいですか。それとも、担当者が変わっても来年まで機能するシステムが必要ですか。
4. キューの規模はどのくらいですか。未解決のイシュー数、未解決の外部プルリクエスト数、最も古いものの経過日数を教えてください。
5. どのようなものが多く寄せられていますか。主にバグ報告、機能リクエスト、それとも使い方に関する質問ですか。
6. プロジェクトはボランティア運営、企業支援、または混合のどれですか。また、契約上の対応義務を負う人はいますか。
7. 使用しているトラッカーは何ですか。ラベル、テンプレート、自動化を変更できますか。現在、どのようなもの（ラベル、テンプレート、貢献ガイド、ボット）がありますか。
8. 外部プルリクエストもここでトリアージする必要がありますか。それとも、別のレビュー工程が担当していますか。
9. 低品質または機械生成の投稿の割合は、過去1年で増えましたか。推定できますか。
10. 現在、セキュリティ報告はどこに届きますか。公開トラッカー、非公開チャネル、または決まった場所はありませんか。
11. 使い方に関する質問は、代わりにどこへ誘導しますか。フォーラム、チャット、ディスカッション、またはまだ決まっていませんか。
12. イシューをクローズできるのは誰ですか。スコープ外と判断するのは誰ですか。今回、この取り組みを始めたきっかけは何ですか。

質問1の回答から、対応に割ける時間が実質ゼロだと分かった場合は、設計を中止してその旨を伝えてください。実現可能な成果物は、受付対象を絞ることと、「このプロジェクトはメンテナンスモードです」という声明を公開することであり、誰も適用しない分類体系ではありません。

質問1、2、3への回答に応じて、以下の各メニューの優先順位を変更し、何をどう動かしたかを説明してください。

• 期限が厳しい場合：今週実行できる施策（約束する対応内容の縮小、選択式の振り分け、方向性の確認）を優先し、四半期以上かけて効果が出る施策の優先度を下げます。
• 「来年も機能する」ことを重視する場合：トリアージ担当者の追加と、検証済みフォームの導入を優先します。どちらも、単月だけで比較すると費用対効果で不利になります。
• 対応に割ける時間が少ない場合：選択肢の優先度を下げるのではなく、削除します。人員を増やす権限がないなら、トリアージ担当者の追加は実行できる施策ではないため、成果物に含めてはいけません。

ステップ1 - 変更前にキューを測定する

トラッカーのイシューをエクスポートしてベースラインを算出します。以降の判断では、すべてこの数値を参照します。

gh issue list --state all --limit 2000 \
  --json number,title,state,createdAt,updatedAt,closedAt,labels,author,comments > issues.json
python3 scripts/triage-baseline.py issues.json --triage-prefix "kind/,priority/"
python3 scripts/triage-baseline.py issues.json --stale-days 120 --format json > baseline.json

JSON 配列、JSON Lines、または CSV から、次の項目をレポートします。

• オープン件数
• 経過日数の中央値／p90
• 未トリアージの割合
• 非アクティブ件数
• 最初の人による応答までの時間の中央値と p90
• 作成件数とクローズ件数の推移
• ラベルの使用状況（1回だけ使われたラベルを含む）

スクリプトを実行できる環境がない場合は、オープン状態の項目を50件手作業で抽出し、同じ数値を推定します。何も測らずに設計するより推定するほうがよく、ベースラインがなければ再設計の効果を判断できません。

何かを提案する前に、数値を確認してください。キューの80%が使い方に関する質問である場合と、未回答のバグ報告が80%である場合とでは、必要な対策が異なります。

次に、項目ごとの切り分けでは見えない点について質問します。これらの項目は、何か共通点を持って集まっていますか。 大量の古いバックログがある場合、共通の根本原因を持つイシューをトラッキング用イシューの下にまとめ、残りのイシューをそこへ誘導するほうが、1件ずつトリアージするより多くのキューを解消できることがよくあります。項目ごとの仕組みを設計する前に、ここで1件ずつ対応するか、まとめて対応するかを決めてください。

ステップ 2 - 対応能力を計算する

トリアージ担当者数 × 週あたりのセッション数 × セッションあたりの分数 ÷ アイテムあたりの分数を計算し、ベースラインの流入量と比較します。

アイテムあたりの分数を定数として持ち込まないでください。ステップ 9 でパイロットセッションの所要時間を計測し、プロジェクト独自の数値を使います。それまでは、3 分はこのスキルが設定する計画上の仮置きであり、業界で測定された数値ではありません。綿密な調査はトリアージではありません。トリアージが予定を組む作業です。

対応能力が流入量を下回っている場合、ラベルの仕組みを変えても解決しません。この差を埋める手段は 3 つあります。どの手段を選ぶかは、入力の手軽さではなく、メンテナーの作業時間あたりにどれだけキューを減らせるかで判断します。

• 効率性：受付量を削減する ＞ 応答期限を延ばす ＞ トリアージ担当者を増やす
• 労力：応答期限を延ばす（1 行を書き換え、一度説明する）＞ 受付量を削減する（フォームと選択肢の設定に半日かかる）＞ トリアージ担当者を増やす（募集、権限付与、基準合わせが必要で、新しい担当者が純増に貢献するまで四半期かかる）
• 価値：受付量を削減する（計算式の左辺を恒久的に下げる）＞ トリアージ担当者を増やす（対応能力を高められる唯一の手段）＞ 応答期限を延ばす（何も改善せず、約束を破るのをやめるだけ）
• コンプライアンスコスト：受付量を削減する == トリアージ担当者を増やす（どちらも外部の相手方を伴わない内部の決定なので同率）＞ 質問 6 で契約上の義務が見つかった場合に応答期限を延ばす（その場合、公開された目標は確約であり、期限を延ばすことは契約変更にあたるため）

効率性の向上は、対応能力を高められる唯一の手段であり、効果が出るまで最も時間がかかるトリアージ担当者の増員を後回しにします。プロジェクトが 1 年後も存続する見込みなら、効率性の向上を優先してください。受付量の削減だけを続けるプロジェクトは、最悪の月に合わせて自らを縮小させてしまいます。3 か月後にユーザーが驚かないよう、選んだ手段を成果物に明記してください。

何も差し迫っていない今のうちに、流入量を制限するトリガーを決めてください。アイテムを作成できる人を制限する、作成者ごとの未解決の投稿数に上限を設ける、または流入量を増やすインセンティブを変更する基準となる、流入率または有効な報告の割合です。制限を導入したプロジェクトは、燃え尽きが深刻になってから初めて制限に手を伸ばしました。設計時にトリガーを決めておけば、危機的な状況での場当たり的な対応ではなく、ポリシーとして運用できます。./references/worked-examples.md では、curl で有効な報告の割合が 20 件に 1 件まで落ち込んだケースを、この計算に当てはめています。また、その対策がトリアージの速度ではなく、提出の経済性に働きかけた理由も示しています。

初回応答の目標は、意欲ではなく対応能力の数値から設定してください。対象は人間による返信であり、修正でもボットのあいさつでもありません。計算方法、ボランティアと企業支援を受けたプロジェクトの違い、契約上の義務については、./references/policy-and-metrics.md を参照してください。

ステップ 3 - ラベルの分類体系を設計する

ラベルは、種類、状態、優先度、領域、コントリビューター向けという直交する軸として構成し、各項目には各軸につき最大 1 つの値を付けます。状態はキューを動かし、優先度は議論のきっかけになるため、プロジェクトが無理なく扱える最小限の数に抑えます。

./references/published-findings.md の基準点を参考に、セットの規模を決めます。

• 新しいリポジトリに標準で用意される 10 個のラベル
• 最も多くインストールされているトリアージスキルにおける、5 つの状態の役割と 2 つのカテゴリー
• Kubernetes の規模で使われている、6 つのプレフィックス付きファミリー

これらをプロジェクトに当てはめるのは、このスキルの判断です。一般的に、妥当な答えは最初の 2 つの間にあり、担当が実際に分かれている場合に限って、3 つ目に近づきます。

次の 2 つのルールは、PyTorch の分類体系に基づいています。これは、本番環境で運用されていることが文書化された唯一の例であり、PyTorch 自身のメインリポジトリで使われています。

• 確信度が高い場合にのみラベルを付けます。 確信度が高または中ならラベルを適用し、低なら推測せずに「要レビュー」の状態を付けます。推測による領域ラベルは項目を誤った担当者に送り、ラベルを付けない場合よりも大きなコストになります。
• 自動化によって最上位の優先度レベルを適用してはいけません。 その候補はすべて、人間による確認に回します。優先度は、後続への影響が最も大きく、機械で定義を確認しにくい軸です。

軸、規模を調整した初期セット、命名規則、履歴を消さずに既存の混乱したラベルを整理する方法、許可リストと検証のパターン、トラッカーの仕組みについては、./references/label-taxonomy.md を参照してください。

トラッカーに手を加える前に、分類体系を提示して承認を得てください。合意していない保守担当者に押し付けられた分類体系は、1 か月も経たずに形骸化します。

ステップ 4 - 流入を断つ

そもそも届くべきではなかった項目に費やされる対応時間は、最も大きく取り戻せる時間です。セットアップ 1 時間あたりに取り戻せるトリアージ時間を基準に、4 つの対策を順位付けします。いずれも誰かに対する義務を生じさせないため、コンプライアンスコストの軸は適用されません。

• 効率性：振り分け先の選択 > 入力検証付きフォーム > 空のイシューの無効化 > タイプラベルの自動適用
• 労力：空のイシューの無効化 == タイプラベルの自動適用（設定 1 つ、フォーム YAML の 1 行） > 振り分け先の選択（まだ存在しない可能性のある振り分け先が必要） > 入力検証付きフォーム（実際のカテゴリごとにフォームを作成し、記述、テスト、報告者がフィールドを飛ばした場合の修正が必要）
• 価値：振り分け先の選択（処理を速めるのではなく、カテゴリ全体を取り除く） > 入力検証付きフォーム（すべてのバグ報告で、やり取りが 2 往復から 1 回の送信に減り、それがずっと続く） > 空のイシューの無効化（フォームを任意にしてしまう抜け道を塞ぐ） > タイプラベルの自動適用（1 つの項目に、1 つの軸を数秒で付与する）

1. 振り分け先の選択 - 使用方法に関する質問はフォーラムまたはチャットへ、商談の依頼は営業窓口へ振り分けます。終了条件は、振り分けられた報告がトラッカーに届かないことです。そのため、ステップ 5～8 では一切対応しません。
2. Markdown テンプレートを、入力検証付きフォームに置き換えます。結果を左右するフィールドだけを必須にします。報告者が任意フィールドを飛ばすたびに、そのフォームは飾りにすぎないと学習させてしまいます。
3. フォームで実際のカテゴリをカバーできたら、空のイシューを無効にします。
4. フォームからタイプラベルを自動適用し、トラッカーにイシュータイプがある場合はそれも適用します。

効率性を優先すると、選択肢 2 が後回しになります。継続的な価値が最も高い一方でセットアップの手間も最も大きいため、自由に使える時間が夜の 1 回だけのメンテナーは、代わりに設定を切り替え、やり取りが続くことになります。バグ報告が流入の大半を占める場合は、すべての項目でそのコストが発生するため、選択肢 2 を最優先にします。使用方法に関する質問の振り分け先がないプロジェクト（質問 12）には選択肢 1 がありません。この対応では、保留中の作業として列挙するのではなく、削除してください。

セキュリティ報告はトラッカーの外で扱います。 調査した成熟プロジェクトはすべて、一般的なトリアージとは別に、同じ 3 要素のパイプラインを運用しています。

• 非公開の受付チャネル
• 担当者が明確で、規模に上限のある対応チーム
• 協調的な情報開示のための公開猶予期間の仕組み

Apache は、コミッターに対し、脆弱性の詳細を公開トラッカーに記載しないよう指示しています。セキュリティ用のメーリングリストがない場合は、コードホストの非公開の脆弱性報告機能をデフォルトとします。パイプライン自体（SECURITY.md、公開猶予期間、アドバイザリ、CVE、修正版リリース）の運用は、samber/developer-relations-skills@oss-security-disclosure の対象です。

フォームの機能、振り分け先の設定、セキュリティ対応の全手順、流入量に応じた制限の選択肢については、./references/issue-intake-and-routing.md を参照してください。フォーム YAML を書く前に読んでください。

ステップ 5 - 担当者を割り当てる

所有者のいないプロセスは、プロセスではありません。

1. 誰がトリアージを担当するかを、明記された交代期間（一般的な単位は1週間）と指名されたバックアップ担当者とともに決めます。Mozillaの2層モデルは、文書化されたパターンの中で最も堅牢です。コンポーネントごとに責任を負う長期的なトリアージオーナーと、実作業を担う週替わりのトリアージ当番を設けます。
2. 実施頻度と終了ルールを決めます。セッションは未処理項目がゼロになった時点ではなく、設定した時間枠が終わった時点で終了します。これにより、急増時にもトリアージを継続できます。
3. セッションの順序を決めます。まず最も新しい未トリアージ項目（応答目標を守るため）、次に報告者から返信があった項目、最後に固定数のバックログ項目を処理します。
4. コミットアクセスではなく、トリアージレベルの権限を付与します。ほとんどのトラッカーには、書き込みアクセスなしでラベル付け、クローズ、担当者の割り当てができるロールがあります。これにより、トリアージチームをコミッター以外にも拡大できます。
5. エスカレーションの基準を定めます。トリアージ担当者が単独で判断できること、メンテナーの判断を待つこと、その待機時間の上限を決めます。

定期的なトリアージ会議が継続するかどうかを決める要素は、次の3つです。

• 会議向けに構築されたキュービュー
• 会議が最初の問い合わせ対応ではなく意思決定の場になるようにする、非同期の事前トリアージ
• 議事録だけでなく、ラベルや状態の変更として記録される決定

Rustのコンパイラトリアージ会議は、最もわかりやすい例です。Zulipのストリームで事前トリアージを行い、ラベルを置き換えて優先順位を設定するため、結果をクエリで検索できます。

ステップ 6 - プルリクエストには独自のゲート順序を設ける

プルリクエストには、イシューにはない必須の自動チェックがあります。イシューのプロセスを流用しないでください。

次の2つはメニュー項目ではありません。どちらも人間が確認する前に実行される、自動化された前提条件です。

• サインオフ（CLAまたはDCO）
• 外部作成者のPRに対するCI権限

サインオフなしでは何もマージしません。サインオフが記録するライセンスの出所情報は、コードの出所を示すプロジェクト唯一の記録だからです。

メンテナーの注意力を使う3つのゲートは、レビュアーの時間1分あたりに処理できる却下件数で順位付けします。最も安価なものから始めるのではありません。そうすると、方向性の確認が仕組みの確認に埋もれてしまいます。

• 効率：方向性の確認（「これはプロジェクトにふさわしいか」）＞サイズに基づくリスクラベル＞コードの正確性レビュー
• 工数：方向性の確認（タイトル、説明、関連イシューを1分確認）＞サイズに基づくリスクラベル（差分から算出しますが、並べ替えに使うだけです）＞コードの正確性レビュー（この順序が保護しようとしている、コストの高い確認）
• 価値：コードの正確性レビュー（変更を受け入れられる唯一のゲート）＞方向性の確認（コードとは無関係だった却下を解決）＞サイズに基づくリスクラベル（振り分けるだけで、何も決定しません）
• コンプライアンスコスト：方向性の確認 == サイズラベル（同等：メンテナーが説明を読む場合も、ボットが差分を測定する場合も、プロジェクトに負うものは何も生じません）＞コードの正確性レビュー（変更を受け入れると、その出所とセキュリティ態勢についてプロジェクトが説明責任を負います。これを文書化するのがサインオフです）

エージェントによるPRの却下の約3分の2は、そもそもコードを読む必要がなかったからです。そのため、方向性の確認を最初に行います。MSR 2026のマイニング調査による、手作業で確認した却下353件の内訳は./references/published-findings.mdにあります。

効率だけを優先すると、コードの正確性レビューが後回しになります。価値と工数が最も高いレビューが、いつまでも最後になるのです。信頼できる常連の貢献者が、すでに受け入れられたイシューに対する小さな変更を送った場合は、最初に行うようにします。PRが作成される前に方向性の確認が済んでおり、この順序で進めるコストのほうがレビュー自体より高くなるからです。

項目ごとの判断フロー、弱い例と強い例を組み合わせた返信テンプレート、PRの差分、却下ナレッジベースについては、./references/response-playbook.mdを参照してください。

ステップ 7 - クローズと滞留に関するポリシーを作成する

何を自動的にクローズし、何を決して自動クローズしないのかを明確に決めます。妥当な線引きは、返信をやめた報告者からの返答待ちの項目だけを自動クローズし、メンテナーからの対応待ちは決して自動クローズしないことです。確認済みのバグをボットがクローズすれば、報告者は自分の証拠に価値がなかったと受け取ります。

スイープを次のように設定します。

• 報告者からの返答待ちの状態だけを対象にする
• 確認済みとブロック中の状態は対象外にする
• クローズ前に警告する
• 最初の実行はドライランモードにして、実行前に影響範囲を把握する

クローズする際は必ず理由を伝え、再オープンする方法を説明します。

各期間は、項目全般ではなく、名前が明示された返答待ちの相手を基準に設定します。Kubernetes が公開している期間、スイープ設定、および一度限りのバックログ整理が正当化される条件については、./references/policy-and-metrics.md を参照してください。

ステップ 8 - 分類を自動化し、最初の返信は自動化しない

まず、機械的な処理を決定論的に自動化します。

• 変更されたパスから領域ラベルを設定する
• フォームに基づいて種類を適用する
• 担当チームにレビューを依頼する
• 滞留期間の計測を実行する

機械学習を使ったトリアージの導入事例では、いずれも最終決定者を人間としています。モデルの支援はスコアリングと提案のレイヤーとして扱い、自動での受理、却下、クローズには決して使わないでください。

分類器を検討する前に、次の 2 つのパターンを取り入れてください。

• 何を判断するかではなく、誰が担当するかを自動化する。 Mozilla はトリアージ担当者フィールドをローテーションカレンダーの担当者と同期し、依頼が 1 人の名前に集中するのではなく、実際に対応中の人に届くようにしています。
• ラベルセットを検証済みの成果物として保持する。 これにより、自動化がラベルを勝手に作成したり、人間の作業を上書きしたりできないようにします。仕組みについては label-taxonomy.md を参照してください。

最初の人間による一文は、人間に任せます。返信メトリクスでは定義上ボットの返信は除外され、報告者も同様にそれを評価しません。自動のあいさつの後に 3 週間沈黙が続けば、待ち時間はさらに悪化します。エージェントがトリアージコメントを投稿する場合は、そのコメントで開示してください。

ステップ 9 - 公開し、試験運用を行い、測定する

ポリシーを公開します。

• リポジトリ内のコントリビューションガイドの隣に記載する
• 受付フォームからリンクする
• プロジェクト独自のチャンネルで、変更を一度告知する

新しいシステムを使って、ユーザーとともに実際のトリアージセッションを 1 回、15～20 件の項目を対象に実施し、所要時間を計ります。これにより、ステップ 2 で保留にした 1 項目あたりの所要時間が得られ、設計の問題点（状態の不足、曖昧なラベル、合わない返信テンプレートなど）が明らかになります。一度も実行されていないポリシーは、草案にすぎません。

最初の四半期は毎月 triage-baseline.py を再実行し、3 つの初期目標に照らして改善します。これら 3 つはこのスキルが独自に定めたベースラインであり、業界標準ではありません。データが 1 四半期分たまったら、それぞれをプロジェクトで測定した独自の推移に置き換えてください。

• 未トリアージの項目を、オープンな項目全体の 10% 未満にする。
• 公開した初回返信の目標を、項目の少なくとも 90% で達成する。
• 四半期の純流入をゼロ以下にする。

達成されるまで改善するか、達成できる水準まで公開済みの約束を引き下げてください。

件数のメトリクスだけで判断しないでください。CHAOSS のガイダンスでは、これらの測定値は「主に人間が行った」活動に限定されています。また、機械生成の件数が増えると、実際のメンテナーの負担が増えているにもかかわらず、クローズ率やクローズまでの時間が改善して見えることがあります。すべての件数に、人間による活動を示す指標を組み合わせてください。ボットと投稿者自身による返信を除外した初回返信、および、1 人が抜けた場合に何人がトリアージを担当できるかを確認します。

永続メモリが利用できる場合は、長期的に有効な決定を保存します。

• 対応能力の数値
• 合意した返信目標
• ラベルの軸とその定義
• トラッカー外に振り分けるカテゴリ
• 件数に応じた制限を発動する条件
• 対象外と宣言した依頼

次回のレビューでは、これらとの差分を確認します。

呼び出し例

ユーザーの発言	生成する内容
「未解決の課題が900件あり、どこから手をつければよいかわかりません」	ベースラインを実施し、平易な言葉で読み解いてから、個別対応かクラスタリングかを判断します。分類はまだ行いません
「メンテナーチームのトリアージプロセスを設計してください」	5つの成果物をすべて順番に作成し、1つずつ検証します
「ラベルがめちゃくちゃなので、やり直してください」	まずラベルの使用数を確認し、次に作成・名前変更・統合・削除の変更リストを作成します。各ラベルには定義を1つ、分類軸を1つ設定します
「古い課題をクローズするボットを有効にすべきでしょうか？」	報告者からの返答待ちの課題だけを対象とするルール、最初のドライラン、除外する状態の一覧を提示し、メンテナーが担当する課題の一括処理は拒否します
「外部のコントリビューターからのPRに誰も対応しません」	ステップ6のゲートの順序と、課題プロセスを流用しない独立したPR対応目標を提示します
「AI生成の報告に追われています」	分類器を導入する前に、ステップ2の件数ゲートのトリガー、受付にかかるコスト、プラットフォームの制御を提示します

成果物

以下の5つの成果物を順番に作成し、次の成果物に進む前にユーザーと検証してください。確認なしに一度にすべて作成してはいけません。

1. ベースライン - ステップ1の数値、その数値の簡潔な解釈、個別対応かクラスタリングかの判断。
2. トリアージポリシー - 公開する文書です。トラッカーに登録する対象、対応目標、状態とその意味、項目をクローズするタイミング、トリアージ担当者、件数ゲートのトリガーを記載します。テンプレートは ./references/policy-and-metrics.md にあります。
3. ラベル変更リスト - 作成・名前変更・統合・削除を記載し、それぞれに1文の定義と分類軸を付けます。
4. 受付変更リスト - 必須フィールドを含む追加・書き換え対象のフォーム、選択肢による振り分け項目、セキュリティ対応経路、有効化する自動化を記載し、それぞれで削減できるトリアージ時間も示します。
5. 当番とゲートの設計 - 担当者名とシフト期間を含むローテーション、エスカレーションルール、プルリクエストのゲート順序を記載します。

すべての成果物で、プロジェクト独自の用語を使ってください。実際のラベル文字列、実際のチャンネル、実際のメンテナー名を使います。

失敗パターン

各行には、手順ですでに明記されていない失敗を示しています。対策は行全体に記載されています。

失敗	対策
達成困難な目標 - ボランティア2人で「24時間以内に対応」	ベースラインで裏付けられる数値を公開する
形骸化したローテーション - 文書化されているが、1年間誰も実施していない当番表	責任者と稼働確認を設け、実施されなくなったら明確に廃止する
優先度の形骸化 - すべてが priority/high	影響度に基づいて定義した2〜3段階にする
一斉移行 - 新しいラベル、古いフォーム、古い保存済みビュー	ラベル、フォーム、ビュー、自動化をまとめて移行する
トリアージが修正作業になる - 1件のデバッグに時間を費やすセッション	時間を区切って実施します。トリアージは作業を計画するものであり、作業そのものではありません
効果を測らない再設計 - 新しいプロセスを導入したが、効果がわからない	毎月ベースラインを再実施する

参考資料

• ./references/label-taxonomy.md - 軸、スターターセット、整理手順、トラッカーの仕組み。
• ./references/issue-intake-and-routing.md - フォーム項目、選択ツール、トラッカー対象外の振り分け、セキュリティ対応ルート。
• ./references/response-playbook.md - 各項目の判断手順、返信テンプレート、却下ナレッジベース。
• ./references/policy-and-metrics.md - キャパシティの計算、ポリシーテンプレート、クローズのルール、測定計画。
• ./references/worked-examples.md - キャパシティの判定例と、ポジティブ／ネガティブなローテーションの一組の例。
• ./references/published-findings.md - 出典のある数値と、独自に設定したベースライン。