GitHub プルリクエスト制限設定：ガバナンスと運用フレームワーク

GitHub の新しいプルリクエスト制限設定は、どのような問題を解決するのか

GitHub は、コード貢献の開始に対する粒度の高い制御を可能にする 2 つのリポジトリ設定オプションを導入しました。プルリクエストをコラボレーターのみに制限するか、完全に無効にするかです。これらの設定は、リポジトリガバナンスにおける文書化された課題に対応しています。すなわち、レビュー前に不正な、あるいは要請されていないコード提出を防ぐためのポリシーレイヤーメカニズムの欠落です。

  • 問題の定義：* リポジトリメンテナーは、信頼できない、あるいは要請されていないコード貢献がレビューキューに入ることを防ぐための上流アクセス制御を欠いています。従来、GitHub はバイナリアクセスモデルを強制していました。誰もがフォークしてプルリクエストを送信できるか、リポジトリアクセスが完全にロックされるかのいずれかです。この制約は、3 つのシナリオにおいて運用上の摩擦を生み出します。(1) スパムと悪意のある提出に対して脆弱なオープンソースプロジェクト、(2) 契約社員または一時的な貢献者に公開されている内部リポジトリ、(3) CI/CD パイプライン、AI エージェントなどの自動化システムと連携するリポジトリで、実行境界が明示的なポリシー強制を必要とする場合です。

  • 前提条件：* 主要なユースケースは、リポジトリが 3 つのカテゴリのいずれかに該当することを想定しています。パブリックコミュニティプロジェクト、内部組織ツール、または自動化システムインターフェースであり、それぞれが異なる貢献ガバナンスを必要とします。このフレームワークは、ハイブリッドシナリオ（例えば、コード所有権に基づくティアード貢献者アクセス）に対応しておらず、バイナリポリシー適用を想定しています。

  • 根拠：* コードベースが AI 駆動エージェントと自動化ツールとの統合を進める中で、コードが人間によるレビューに到達する前に実行境界を確立するために、上流ポリシー制御が必要になります。これは多層防御の原則と一致しています。ポリシーレイヤー制限（変更を開始できるユーザー）は、技術レイヤー制御（サンドボックス化、自動分析）に先行します。

  • 具体例：* 内部インフラストラクチャリポジトリは、以前、契約社員または一時的な貢献者からのプルリクエストを手動で閉じる必要があり、レビューのオーバーヘッドを生み出し、コードインジェクションの表面積を拡大していました。コラボレーターのみの制限により、そのような提出は作成時にブロックされ、この管理上の負担が排除され、露出が軽減されます。

  • 実行可能な示唆：* リポジトリポートフォリオの即座の監査を実施してください。各リポジトリを以下で分類します。(1) 意図された貢献者ベース（パブリック、内部、自動化システム）、(2) コード感度（インフラストラクチャ、本番環境、実験的）、(3) 現在の貢献パターン。この分類により、各リポジトリに対してコラボレーターのみの制限か完全な無効化のいずれが適切かが決まります。

2 つの設定は運用上、どのように異なるのか

コラボレーターのみの制限と完全な無効化は、異なるガバナンス姿勢を表し、異なる運用上の含意とユースケースを持ちます。

  • 運用上の区別：*
設定プルリクエストIssueフォークディスカッションユースケース
コラボレーターのみコラボレーターに制限すべてに開放すべてに開放すべてに開放検証済み貢献を受け入れるパブリックプロジェクト
完全に無効化すべてのユーザーに対して無効すべてに開放すべてに開放すべてに開放読み取り専用リポジトリ、内部ミラー、同期のみの更新

  • 主張：* 2 つの設定は異なる組織コンテキストとリスクプロファイルに対応しています。選択は、外部の可視性とエンゲージメントメカニズムが必要かどうかに依存します。

  • 根拠：* プルリクエストをコラボレーターに制限することで、貢献ワークフローを維持します。Issue、ディスカッション、フォークは利用可能なままですが、コード変更を提案できるユーザーを絞ります。これはコミュニティエンゲージメントと透明性を保持します。完全な無効化はプルリクエストメカニズムを完全に削除し、すべての変更が代替チャネル（直接コミット、リリースパイプライン、上流同期）を通じて流れるリポジトリに適しています。選択は組織の意図に基づきます。リポジトリは外部参加を必要とするのか、それとも読み取り専用または内部管理として動作すべきなのか。

  • 前提条件：* このフレームワークは、「コラボレーター」が組織所属または実証された貢献履歴を持つ明示的に検証されたメンバーであることを想定しています。GitHub の現在の設定が提供するよりも粒度の高い制御を必要とする可能性がある、動的またはロールベースのアクセスモデルには対応していません。

  • 具体例：* パブリックドキュメンテーションリポジトリは、コラボレーターのみの制限を使用して、検証済みメンテナーからの貢献を受け入れながら、スパムと低品質の提出を防ぐことができます。対照的に、独自コードベースのミラーは、プルリクエストを完全に無効化し、ソースリポジトリからの同期更新のみを許可します。第 3 のシナリオ（内部 CI/CD 設定リポジトリ）は、プルリクエストを無効化して、すべての変更を別の承認ワークフロー（例えば、インフラストラクチャアズコードレビュープロセス）を通じて強制する場合があります。

  • 実行可能な示唆：* リポジトリポートフォリオの決定マトリックスを作成してください。各リポジトリについて、以下を文書化します。(1) リポジトリ名と目的、(2) 現在のアクセスモデル、(3) 意図された貢献者ベース、(4) 選択された設定（コラボレーターのみまたは無効化）、(5) 根拠。実装前に、このマトリックスをセキュリティ、エンジニアリング、プロダクトリーダーに配布して検証を受けてください。

プルリクエストをコラボレーターに制限することで、何が達成されるのか

プルリクエストをコラボレーターのみに制限することで、透明性とコミュニティエンゲージメントメカニズムを保持しながら、境界を設けた貢献モデルが作成されます。

  • 主張：* この設定は、外部参加または可視性を排除することなく、攻撃表面と管理上の負担を軽減します。

  • 根拠：* コラボレーターは、組織またはプロジェクトの明示的に検証されたメンバーです。彼らは意図的なプロセスを通じてアクセスが付与されています。プルリクエスト開始をこのグループに限定することで、匿名または低信頼の提出がコードレビューに到達することを防ぎます。これはダウンストリームの技術制御（コードスキャン、サンドボックステスト、人間によるレビュー）を補完するポリシーレイヤー境界を確立します。この設定は、Issue、ディスカッション、フォークを通じた外部エンゲージメントを保持し、コミュニティメンバーがバグを報告し、アイデアを提案し、直接マージ権限なしでコードを実験できるようにします。

  • 前提条件：* このアプローチは、コラボレーターステータスが積極的に管理され、定期的に監査されることを想定しています。信頼できるコラボレーターからの悪意のあるコードを防ぐことはできず、ダウンストリームレビュープロセスに依存してそのような貢献を検出します。

  • 具体例：* コラボレーターのみの制限を使用するオープンソースプロジェクトは、パブリックから Issue とディスカッションを受け入れ続けます。外部貢献者はリポジトリをフォークしてローカルで実験できますが、マージを直接提案することはできません。メンテナーは、信頼性を実証した後、有望な貢献者をコラボレーターグループに招待するオプションを保持しています。これにより、コミュニティメンバーが制御された入口を維持しながら直接貢献権を獲得するための明確なパスウェイが作成されます。

  • 実行可能な示唆：* コラボレーターのための文書化されたオンボーディングプロセスを確立してください。昇格の明示的な基準を定義します（例えば、フォーク経由で受け入れられた 3 つのプルリクエスト、組織所属、またはタイムベースの検証）。このプロセスをリポジトリ README と CONTRIBUTING.md に公開し、外部貢献者が直接貢献権を獲得するためのパスウェイを理解できるようにしてください。コラボレーター管理の所有権を割り当てます（通常、チームリードまたはセキュリティ連絡先）。四半期ごとのレビューサイクルを確立して、非アクティブなメンバーを削除し、保留中のリクエストを処理してください。

チームはリポジトリポートフォリオ全体でこれらの設定をどのように運用化すべきか

デプロイメントには、ワークフローの中断を回避し、ステークホルダーの調整を維持するための体系的なインベントリ、リスク分類、段階的なロールアウトが必要です。

  • 主張：* いずれかの設定の一括適用は、正当なワークフローを破壊するリスクがあります。リポジトリ分類による対象デプロイメントは、摩擦と運用上の中断を最小化します。

  • 根拠：* 異なるリポジトリは異なる目的とステークホルダーグループに対応しています。本番インフラストラクチャ、内部ツール、パブリックライブラリ、実験的プロジェクトは、それぞれ異なるポリシーを保証しています。段階的なアプローチ（自動化システムと連携するか、機密ロジックを含む高リスクリポジトリから開始）により、チームは影響を観察し、プロセスを改善し、より広い採用前に組織的な信頼を構築できます。

  • 前提条件：* このフレームワークは、リポジトリが離散的なリスクカテゴリに分類でき、低トラフィックリポジトリでのパイロットテストが代表的なフィードバックを提供することを想定しています。貢献パターンが非常に可変的なリポジトリ、または例外処理を必要とするリポジトリには対応していません。

  • 具体例：* パブリック SDK と内部 CI/CD 設定リポジトリの両方を管理するチームは、SDK にコラボレーターのみの制限を適用し（コミュニティエンゲージメントと Issue 報告を保持）、CI/CD リポジトリに完全な無効化を適用します（すべての変更が内部承認と監査プロセスを通じて流れることを保証）。この二重アプローチは、リスクプロファイルとステークホルダーの期待を反映しています。

  • 運用ステップ：*

  1. インベントリと分類： すべてのリポジトリをリストアップします。以下で分類します。(a) リスクレベル（重要インフラストラクチャ、本番環境、内部ツール、実験的）、(b) ステークホルダーグループ（パブリックコミュニティ、内部チーム、自動化システム）、(c) 現在の貢献パターン（頻度、ソース、レビュープロセス）。

  2. ポリシー割り当て： 各カテゴリについて、設定を割り当てます。

    • 高リスク、内部のみのリポジトリ： 完全な無効化
    • 高リスク、自動化システムを備えた内部： コラボレーターのみ（自動化システムアカウントをコラボレーターとして）
    • 中程度のリスク、内部リポジトリ： コラボレーターのみ
    • コミュニティ貢献を伴うパブリックライブラリ： コラボレーターのみ（明確なオンボーディングプロセス付き）
    • パブリック読み取り専用リポジトリ： 完全な無効化

  3. パイロットデプロイメント： 異なるカテゴリから 2～3 個の低トラフィックリポジトリで設定を有効にします。以下を監視します。(a) サポートリクエストまたはワークフローの中断、(b) 貢献率への影響、(c) コラボレーター管理のオーバーヘッド。

  4. フィードバックと改善： 2 週間後、影響を受けたチームからフィードバックを収集します。代替設定を必要とする例外または特殊なケースを文書化します。

  5. 段階的ロールアウト： 波状に残りのリポジトリにデプロイし、高リスクリポジトリを優先します。変更について、少なくとも 1 週間前にステークホルダーに通知してください。

  • 実行可能な示唆：* このデプロイメントの所有権を割り当てます（通常、プラットフォームエンジニアリングまたはセキュリティチーム）。リポジトリ分類、割り当てられた設定、デプロイメント日、フィードバックを追跡する共有スプレッドシートを作成します。パイロット段階中は週次チェックインをスケジュールし、デプロイメント後 60 日での正式なレビューをスケジュールしてください。

リポジトリ分類フレームワークの意思決定フロー。貢献者ベース（パブリック、内部、自動化システム）、コード感度レベル（インフラ、本番、実験的）、現在の貢献パターンに基づいて、各リポジトリに適切なアクセス制限とガバナンス設定を決定するプロセスを示す図。

  • 図5：リポジトリ分類と制限設定の意思決定フロー（Repository governance framework）*

これらの設定からどのようなリスクが生じ、どのように軽減するのか

これらの制御は、チームが予測し、計画する必要がある新しい運用上およびガバナンス上の考慮事項を導入します。

  • 主張：* プルリクエストの制限は、正当な貢献者を不本意に除外し、コラボレーター管理にボトルネックを作成し、ポリシーが明確に通知され、積極的に維持されていない場合に摩擦を生成する可能性があります。

  • 根拠：* 過度に制限的なポリシーは、外部貢献を阻止するか、新しいチームメンバーのオンボーディングを遅くする可能性があります。逆に、過度に許容的なコラボレーターリストは、制限の目的を無効にします。さらに、コラボレーターステータスが定期的に監査されない場合、リポジトリは非アクティブなメンバー（セキュリティリスク）を蓄積しながら、正式に追加されたことのないアクティブな貢献者へのアクセスを拒否する可能性があります（ユーザビリティリスク）。これらの設定は、明確な所有権、文書化されたプロセス、定期的なレビューサイクルと組み合わせた場合に最も効果的です。

  • 前提条件：* この分析は、コラボレーター管理が軽量な承認ワークフローと四半期ごとの監査を通じて運用化できることを想定しています。分散した意思決定が高い組織、または集中化されたガバナンスインフラストラクチャを欠く組織には対応していません。

  • リスク軽減：*

リスク軽減戦略
正当な貢献者が除外される明確なオンボーディング基準と公開されたプロセスを確立し、コラボレーターリクエストの所有権を割り当てます
コラボレーターリストが古くなる四半期ごとの監査を実施し、非アクティブなメンバーを削除し、各コラボレーターの根拠を文書化します
承認プロセスのボトルネック軽量な承認ワークフローを定義し（例えば、チームリードの承認）、目標応答時間を設定します（例えば、48 時間）
ポリシーが外部貢献者に誤解されるREADME と CONTRIBUTING.md でポリシーを文書化し、アクセスをリクエストするための明確なパスウェイを提供します
コラボレーターステータスが検証なしで付与されるコラボレーターを追加する前に文書化された承認を要求し（例えば、GitHub Issue またはプルリクエストコメント）、監査ログを維持します

  • 具体例：* プルリクエストを制限しても、コラボレーターレビュープロセスを確立しないチームは、非アクティブなメンバー（元請負業者、退職した従業員）を蓄積しながら、正式に追加されたことのないアクティブな貢献者へのアクセスを拒否する可能性があります。これはセキュリティ債（不要なアクセス）とユーザビリティ債（正当な貢献者の不満）の両方を作成します。規律あるアプローチ（四半期ごとの監査、文書化された承認プロセス、明確な通信）がこのドリフトを防ぎます。

  • 実行可能な示唆：*

  • 四半期ごとのコラボレーター監査を確立します。アクセス権を持つユーザーをレビューし、非アクティブなメンバーを削除し、保留中のリクエストを優先処理します。

  • 軽量な承認ワークフローを作成します（例えば、GitHub Issue またはプルリクエストコメント経由でのチームリード承認）。

  • リポジトリ README と CONTRIBUTING.md に各制限の根拠を文書化します。

  • コラボレーターリクエストの目標応答時間を設定し（例えば、48 時間）、コンプライアンスを追跡します。

  • コンプライアンスとセキュリティレビューのために、コラボレーターの追加と削除の監査ログを維持します。

これらの設定はより広いセキュリティと自動化戦略にどう統合されるのか

プルリクエスト制限は、特にチームがAI駆動のコード生成と自動化エージェントを採用する際に、多層防御アプローチの一層を形成します。

  • 主張：* これらの設定は、スタンドアロンの制御ではなく、ランタイム分離、コードレビュー自動化、監視と組み合わせた場合に最も効果的です。

  • 根拠：* プルリクエスト作成者を制限することで、信頼できない投稿がレビューキューに入るのを防ぎます。しかし、コード品質の検証、信頼できる投稿内の悪意あるロジックの検出、あるいは侵害されたコラボレーターアカウントから有害なコードが投稿されるのを防ぐことはできません。包括的なセキュリティ体制には複数の層が必要です。(1) ポリシー層の制御（プルリクエスト制限、ブランチ保護）、(2) 技術層の制御（サンドボックス化、静的解析、依存関係スキャン）、(3) 運用層の制御（コードレビュー、監視、インシデント対応）です。プルリクエスト制限はポリシー層に対応しており、効果を発揮するには下流の技術層制御と組み合わせる必要があります。

  • 前提条件：* このフレームワークは、組織が下流の技術層制御（自動スキャン、サンドボックステスト）を実装しているか、実装できることを想定しています。そうしたインフラストラクチャが実現不可能なリソース制約環境には対応していません。

  • 統合ポイント：*

  1. ブランチ保護ルール： プルリクエスト制限をブランチ保護ルールと組み合わせ、マージ前にステータスチェック（自動テスト、セキュリティスキャン）とコードレビュー承認を要求します。

  2. 自動コード解析： すべてのプルリクエストを、人間によるレビュー前に自動セキュリティスキャン（SAST、依存関係スキャン、シークレット検出）を通します。

  3. サンドボックステスト： AIエージェントまたは自動化システムと連携するリポジトリの場合、マージ前にサンドボックス実行と検証を要求します。

  4. CODEOWNERSファイル： CODEOWNERSを使用して、コードパスに基づいてプルリクエストを指定されたレビュアーにルーティングし、レビューにおけるドメイン専門知識を確保します。

  5. 監視とアラート： プルリクエスト作成パターン、コラボレーター追加、ポリシー違反を追跡します。異常（例えば、通常と異なる投稿者、新しいコラボレーターからの大規模なコード変更）についてアラートを発します。

  • 具体例：* GitHub Copilotまたは他のAIエージェントを使用するチームは、(1) プルリクエストをコラボレーター（AIエージェントサービスアカウントを含む）に制限し、(2) すべての投稿を自動セキュリティスキャンとサンドボックステストを通し、(3) マージ前に人間によるレビューを要求し、(4) 異常なパターン（例えば、レビューをバイパスするエージェント生成コード）を監視します。この多段階アプローチは、外部からの注入と意図しないエージェント動作の両方を防ぎます。

  • 実行可能な示唆：*

  • 現在のコードレビューとテストパイプラインを監査します。悪意あるコードまたは低品質なコードが通過する可能性のあるギャップを特定します。

  • プルリクエスト制限を既存の制御（ブランチ保護ルール、必須ステータスチェック、CODEOWNERSファイル）の上に重ねます。

  • すべてのプルリクエストに対して自動セキュリティスキャン（SAST、依存関係スキャン、シークレット検出）を実装します。

  • 自動化システムと連携するリポジトリの場合、サンドボックステストと実行検証を追加します。

  • プルリクエスト作成パターン、コラボレーター管理、ポリシー違反について監視とアラートを確立します。

  • 各リポジトリの完全なセキュリティ体制（ポリシー、技術、運用層の制御）をリポジトリREADMEに文書化します。

プルリクエスト制限設定がセキュリティスタック全体に統合される方法を示すアーキテクチャ図。上部のプルリクエスト制限設定から、ブランチ保護ルール、CODEOWNERS、IAMポリシーの3つの制御層に分岐し、それぞれレビュー・マージ制御、コード所有者検証、アクセス権限管理を実行。これらが自動化ワークフローに統合され、監査ログに記録される。最終的にセキュリティスタックとして脅威検知、コンプライアンス、インシデント対応の3つの機能に接続される構成を表現。

  • 図8：プルリクエスト制限とセキュリティ・自動化戦略の統合アーキテクチャ（GitHub security architecture）*

チームが今から採用に向けて準備すべきことは何か

ここはポリシーが実践に転換する重要な局面です。次の30日間が、これらの設定が真の統治ツールになるか、単なる設定チェックボックスに留まるかを決定します。

  • 主張：* 採用を成功させるには、明確なコミュニケーション、文書化された根拠、反復的な調整、継続的な統治が必要です。一度限りの設定変更ではありません。

  • 根拠：* ステークホルダーの合意なしにこれらの設定を単に有効にするチームは、しばしば抵抗に直面するか、ワークフローが破損したときに変更を戻します。コミュニケーション、文書化、パイロットテスト、定期的なレビューに投資するチームは、組織の成長とともにスケールする耐久性のある統治慣行を構築します。

  • 30日間採用計画：*

  • 第1週：インベントリと分類*

  • すべてのリポジトリをリストアップし、リスク、目的、ステークホルダーグループごとに分類します。

  • 各リポジトリに設定（コラボレーターのみまたは無効）を割り当て、根拠を文書化します。

  • パイロットリポジトリ（異なるカテゴリから2～3個の低トラフィックリポジトリ）を特定します。

  • 第2週：コミュニケーションと文書化*

  • チームに新しい設定と分類根拠を通知します。

  • 決定マトリックスとコラボレーターのオンボーディングプロセスを公開します。

  • 外部投稿者がコラボレーターアクセスをリクエストする方法を説明します。

  • 一般的な質問と懸念に対応するFAQを作成します。

  • 第3週：パイロット展開*

  • パイロットリポジトリで制限を有効にします。

  • 問題、サポートリクエスト、ワークフロー摩擦を監視します。

  • 影響を受けるチームからフィードバックを収集します。

  • 第4週：レビューと改善*

  • パイロット結果を評価します。予期しない影響やエッジケースを文書化します。

  • フィードバックに基づいてポリシーを改善します。

  • 残りのリポジトリへの段階的なロールアウトを計画します。

  • 継続的な統治（展開後）：*

  • 月次： プルリクエスト作成パターンとコラボレーター管理メトリクスをレビューします。

  • 四半期ごと： コラボレーター監査を実施します。非アクティブなメンバーを削除します。保留中のリクエストを処理します。

  • 半年ごと： ポリシー有効性をレビューします。設定が組織のリスクプロファイルと投稿者ベースに合致しているかを評価します。

  • 実行可能な示唆：*

  1. 所有権の割り当て： プラットフォームエンジニアリングまたはセキュリティチームをこのイニシアティブの所有者として指定します。コラボレーターリクエストとポリシー質問の主要な連絡先を割り当てます。
  2. 決定ログの作成： 各リポジトリが選択した設定を使用する理由を説明する共有ドキュメント（例えば、GitHubウィキまたは内部ウィキ）を保持します。オンボーディングプロセス、承認ワークフロー、監査スケジュールを含めます。
  3. メトリクスの確立： 以下を追跡します。(a) 制限が有効なリポジトリ、(b) コラボレーターリクエストボリュームと承認時間、(c) プルリクエスト作成パターン、(d) サポートリクエストまたはワークフロー中断。
  4. レビューのスケジュール： 60日間のレビュー会議をカレンダーに入れて、影響を評価し、フィードバックを収集し、ポリシーを改善します。四半期ごとのコラボレーター監査をスケジュールします。
  5. 例外の文書化： 例外処理が必要なリポジトリを特定します（例えば、ハイブリッドアクセスモデル、外部パートナー投稿）。例外の根拠と承認プロセスを文書化します。
  • 重要な問いかけ：* 組織がスケールし、自動化システムがコードベースの主要な投稿者になるにつれて、セキュリティ、開発者の速度、ステークホルダーの信頼のバランスを取るためにこれらのポリシーをどのように進化させるのか。この問いかけが統治フレームワークに情報を与え、将来のポリシー改善を導くべきです。

GitHubのプルリクエスト制御の進化を示す図。従来モデルでは完全許可または完全拒否の二者択一で、オープンソースではスパムPR増加、内部リポジトリでは正規ユーザアクセス不可、自動化システムではボット作成不可という3つの問題が発生。新しい制限設定ではロール別のきめ細かい制御により、各シナリオで信頼済みユーザ・メンバー・認可ボットのみを許可することで、セキュリティと利便性の両立を実現する。

  • 図2：GitHubアクセス制御の進化：従来モデルから新制限設定へ（GitHub repository governance framework）*

2つのリポジトリ制限設定の操作上の違いを比較するツリー図。左側は「コラボレーターのみ制限」で、プルリクエスト・Issue・ディスカッション・リリースはコラボレーターのみ作成可能、Forkは誰でも可能。右側は「完全無効化」で、プルリクエスト・Issue・ディスカッション・リリースは完全に無効化、Forkのみ誰でも可能。各機能の制限状態を色分けで視覚化。

  • 図3：プルリクエスト制限設定の機能比較マトリックス（GitHub settings documentation）*

GitHubの2つのリポジトリ設定（コラボレーターのみ制限と完全無効化）における7つの機能の動作比較表。プルリクエスト、Issue、ディスカッション、リリースはコラボレーターのみ制限で制限可能だが完全無効化では不可。Fork、Webhook、APIアクセスはコラボレーターのみ制限で部分的または完全に制御可能。各機能の推奨用途を示している。

  • 表1：プルリクエスト制限設定の機能比較表（GitHub公式ドキュメント参照）*

プルリクエスト制限設定から生じる4つのリスク（正当な貢献者の排除、コミュニティ参加の低下、自動化ワークフローの中断、権限昇格の可能性）を示し、各リスクに対する具体的な軽減策と軽減効果を段階的に表示するリスク・マトリックス図。リスク評価レベルは高から極高まで段階付けされている。

  • 図7：プルリクエスト制限設定のリスク軽減マトリックス*