SpecDojo

日本語

English

日本語

English

Appearance

frontmatter
キー値
specdojo.idprj-0001:pjr-bj97-codeowners-and-branch-protection
specdojo.typeproject
specdojo.statusready
specdojo.rulebookspecdojo:pjr-rulebook
specdojo.part_ofprj-0001:pjr-index
specdojo.item_typeissue
specdojo.item_statusdone
specdojo.prioritymedium
specdojo.ownerARC
specdojo.registered_at2026-08-09T02:12:43Z
specdojo.due_on2026-08-31
specdojo.completed_at2026-08-26T14:36:20Z
specdojo.conclusion.github/CODEOWNERS を作成し、リポジトリ全体の承認者として @naoji3x を宣言した。独立した所有者が割り当てられた時点でより限定的なルールを追加する方針をコメントで残している。branch-workflow-guide へ、管理者が実施する branch protection の設定手順と確認項目、および統合専用 actor のみが bypass できる設計を追記した。独立した承認者がいない期間は PR 強制3ケースを承認待ちとし、作成者自身の approve と管理者権限の bypass を承認として扱わないことを明記した。緊急対応で bypass する場合も承認済みとせず例外として記録する。branch protection の設定と PR 強制3ケースの検証は GitHub 上の操作であり、リポジトリ管理者が実施する。実施後は対応結果へ追記する。

PJR-BJ97 CODEOWNERS 未整備により PR 承認の職務分離が強制されていない ​

1. 課題内容 ​

.github/CODEOWNERS が存在せず branch protection の Code Owners 承認を強制できないため、PR 強制3ケースで自己承認が成立してしまう。

PR 承認を強制する 3 ケース（develop → main 昇格、change-request の承認、不可逆・高リスク・framework schema 破壊的変更）について、承認者を宣言する仕組みが未整備であり、職務分離が platform 側で強制されていない。

  • 発生日: 2026-08-09
  • 事実: リポジトリに .github/CODEOWNERS が存在しない。標準では承認者を CODEOWNERS で宣言し、branch protection の Code Owners 承認要求で強制する前提になっている。
  • 顕在化した事例: prj-0001:pjr-9y7g-register-item-file-as-ssot の承認において、PR の作成者と承認者が同一だった。標準は作成者による自己承認を承認としてカウントしないと定めており、記録上は職務分離が成立していない。
  • branch protection の設定状況は未確認。確認には platform 側の権限が必要である。

2. 影響範囲 ​

観点影響
スコープPR 承認を強制する 3 ケース全般。承認事実の実効性が担保されない
スケジュール影響は小さい。整備は独立して実施できる
コスト影響は小さい
品質承認記録が形式的になり、監査時に承認の実効性を示せない
関係者リポジトリ管理者、PO、変更承認権限者（CCB）

3. 対応方針 ​

項目内容
原因承認者宣言（CODEOWNERS）と強制設定（branch protection）が未整備で、標準が想定する強制手段が機能していない
対応策.github/CODEOWNERS を作成して main と各 project の承認対象へ承認者を割り当て、branch protection で Code Owners 承認を必須にする
依存事項承認者の GitHub アカウントは naoji3x で確定した。branch protection の設定は GitHub 上の操作であり、リポジトリ管理者が実施する
完了条件下記のとおり

単独運用の期間が続く場合は、職務分離を満たせない事実と、その期間の承認の扱いを運用ガイドまたは本個票へ明記することを検討する。承認記録を実態と異なる形で残さないことを優先する。

3.1. 本項目の範囲 ​

当初の完了条件は branch protection の設定と PR 強制 3 ケースの検証まで含んでいたが、これらは GitHub 上の操作でありリポジトリ管理者が行う。本項目はリポジトリ内で完結する作業に範囲を限定する。

作業範囲
.github/CODEOWNERS の設計と作成含む
承認対象パスへの承認者の割り当て含む
単独運用期間の扱いの明文化含む
branch protection の設定範囲外
PR 強制 3 ケースの検証範囲外

範囲外の作業は本項目の完了後に管理者が実施する。実施内容と確認結果は対応結果へ追記する。

3.2. 完了条件 ​

  • .github/CODEOWNERS が存在し、承認者として @naoji3x が宣言されている。
  • 承認対象のパスが設計され、なぜその範囲を対象にしたかが記録されている。リポジトリ全体を対象にするのか、docs/ja/projects/ や .specdojo/ など統制上重要な範囲に絞るのかを判断する。
  • 単独運用のため、現状では Code Owners 承認を必須にしても自己承認しか成立しない。この事実と、その期間の承認の扱いが明文化されている。承認記録を実態と異なる形で残さない。
  • branch protection の設定手順が記録されている。管理者が後から実施できる内容とする。
  • CODEOWNERS の記法が正しい。GitHub が解釈できる形式であることを確認する。
  • npm run lint:md、npm run lint:fm が成功する。

4. 対応結果 ​

  • .github/CODEOWNERS を作成し、リポジトリ全体の owner に @naoji3x を指定した。develop → main 昇格は任意のパスを変更し得るため、統制対象を一部の project 文書や .specdojo/ に限定すると owner のない差分が生じる。そこで * を既定ルールとし、main と全 project の承認対象を漏れなく含めた。project ごとに独立した承認者を割り当てる場合は、既定ルールより後へ限定パスのルールを追加する。
  • specdojo:branch-workflow-guide の「CODEOWNERS と branch protection を設定する」に、管理者が行う設定の前提、main と project/<project-id>/develop の保護条件、確認項目を記録した。project/<project-id>/develop では通常の自動統合を維持するため、統合専用 actor だけに bypass を限定する。actor を分離できない間は develop の保護を有効化せず、未設定期間を project register で追跡する。
  • 同ガイドの「独立した承認者がいない期間を扱う」に、単独運用中は PR 強制 3 ケースを「承認待ち」とし、自己承認や管理者 bypass を承認として記録しないことを明記した。緊急 bypass は未承認の例外として記録し、独立した承認者の参加後に遡及レビューする。
  • branch protection の GitHub 上の設定と PR 強制 3 ケースの実地確認は本項目の範囲外であり、リポジトリ管理者がガイドの手順に従って実施する。設定時には @naoji3x の明示的な write 権限と、CODEOWNERS が各 base branch に存在することも確認する。

5. 関連ドキュメント ​