PJR-T0VQ PJR-ID の桁数は4桁で十分（衝突可能性を評価済み）

1. メモ

32^4=1,048,576 の ID 空間と再抽選方式の評価結果を記録する。通常経路では衝突せず、桁数拡張は後方互換で後から可能。

PJR-ID の桁数（4文字）は将来の大規模プロジェクトでも十分であり、桁数を増やす必要はない。評価結果は次のとおり。

• ID 空間は 32 文字セット（0123456789ABCDEFGHJKMNPQRSTVWXYZ）の4文字で 32⁴ = 1,048,576 通り。ブロックリストは6語のみで実質的な減少はない。空間はプロジェクト単位であり、複数プロジェクトで分母を共有しない。
• generatePjrId（src/register.ts）は候補を既存 ID 集合と照合して一致時に再抽選する方式（rejection sampling、maxAttempts = 256）のため、既存 ID を見た状態で採番する通常経路では重複 ID は採番されない。
• 空間の飽和による再抽選コストは、期待試行回数 1 / (1 - 負荷率) で評価できる。

登録件数	負荷率	期待試行回数	256回連続失敗の確率
1,000	0.10%	1.001	約 10⁻⁷⁶⁸
10,000	0.95%	1.010	約 10⁻⁵¹⁷
100,000	9.5%	1.105	約 10⁻²⁶¹
524,288	50%	2.0	約 10⁻⁷⁷

• 登録簿は schedule で管理しない計画外の単発事項を対象とするため、大規模プロジェクトでも数百〜数千件の規模に留まる。飽和は実運用で発生しない。
• 実質的な衝突リスクは桁数ではなく分散採番の窓の大きさで決まる。--local の使用、統合ブランチの未同期、rebase や cherry-pick を経た履歴の混在では、相手の採番が見えないまま引くため、衝突確率は概ね「見えていない ID 数 ÷ 1,048,576」になる。未同期で20件を見落とした状態では1回あたり約 1.9×10⁻⁵ となる。桁数を増やしても分母が変わるだけで、この構造的なリスク源は残る。
• 混入した場合は npm run validate:schema:pjr-index が重複 ID と該当行位置を示して必ず失敗し、register renumber で復旧できる。サイレントに壊れる設計にはなっていない。

2. 背景・文脈

大規模プロジェクトで4桁の ID が枯渇または衝突するのではないかという懸念から評価した。同じ懸念が繰り返し提起されないよう、判断根拠を記録する。

参照時の注意点は次のとおり。

• 「誕生日のパラドックスにより約1,205件で衝突確率が50%に達する」という計算は、重複排除を一切行わない場合の式であり、本実装には当てはまらない。本実装は必ず既存 ID 集合と照合して再抽選するため、通常経路の衝突確率はゼロである。この点は誤解されやすい。
• 桁数の拡張は後方互換で実施できる。ID の正規表現を {4} から {4,5} へ広げれば5文字 ID を混在させられ、既存の4文字 ID は無効化されない。生成長は PJR_ID_LENGTH の切り替えで済む。したがって、今の時点で桁数を決め打ちで増やす必要はない。
• 拡張時に変更が必要な箇所は、src/register.ts の PJR_ID_LENGTH と PJR_ID_RE、および tools/docs/src/remark-md-content.ts の PJR_ID_PATTERN である（2026-08-09 時点）。
• 旧来の数字4桁 ID（例: PJR-0163）も同じ文字集合に含まれるため、乱数 ID と混在しても検証と再採番は従来どおり機能する。

3. フォローアップ

対応は不要。参照のみのメモとする。ただし次のいずれかに該当した場合は再評価する。

• 登録件数が 10,000 件（負荷率 1%）を超える規模に到達した場合。
• --local での起票が常態化するなど、未同期の分散採番が通常運用になった場合。

再評価の際は、桁数の拡張よりも先に、負荷率が閾値を超えたときに register add が警告を出す仕組みの導入を検討する。

4. 関連ドキュメント

• specdojo:register-operation-guide: PJR-ID の採番と統合ブランチ集約、ID 重複の検知と復旧（評価対象の仕様）
• prj-0001:pjr-0137-register-id-uniqueness: PJR-ID の一意性確保（先行対応）
• prj-0001:pjr-0138-register-add-on-integration-branch: 統合ブランチ集約による採番（先行対応）