⚖️ Governance

一言で

Organization の 3 モデル 📖 Docs 🏢 リコー事例

まず org をいくつ作るか。モデルごとに、全社員が最初から何を見られるかが変わる。

アクセスの付け方 📖 Docs

次はアクセス。IdP → team → repo の順で、個人に直接付けない。

flowchart LR
  IDP["🪪 IdP (Okta)<br/>唯一の情報源"]
  ENT["🏛️ Enterprise Team 📖<br/>Admin · 全 org"]
  ORG["🏢 Org Team 📖<br/>この org · 組織図ベース"]
  REPO["📦 Repository"]
  IDP -->|SCIM| ENT
  IDP -->|SCIM| ORG
  ORG -->|Write など| REPO
  ENT -->|Admin| REPO

  classDef idp fill:#1a0a2e,stroke:#ffb000,color:#ffb000,stroke-width:2px
  classDef ent fill:#2a0a0a,stroke:#ff5555,color:#ff5555,stroke-width:2px
  classDef org fill:#0a0e27,stroke:#00f0ff,color:#00f0ff,stroke-width:2px
  classDef repo fill:#0a1a14,stroke:#9bbc0f,color:#9bbc0f,stroke-width:2px
  class IDP idp
  class ENT ent
  class ORG org
  class REPO repo

  click ENT href "https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams" "Enterprise teams のドキュメント" _blank
  click ORG href "https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams" "Organization teams のドキュメント" _blank

Policies

人は入った。次は何をしてよいか。org と enterprise で決め、repo では決めない。

• 🏛️ Enterprise — SSO / SCIM、使える機能、全 org の基準
• 🏢 Org — メンバー権限、repo 作成、2FA、Copilot と Actions
• 📦 Repo — ポリシーは持たず継承するだけ。repo で足せるのは ruleset。
• 🔁 ルールは下に流れる。org は厳しくできるが、緩められない。

🎯 ガードレールは上から。repo ごとに設定しない。 Org policies ↗ · Enterprise policies ↗

管理者ロール 📖 Docs

ポリシーは決まった。次は、その設定を誰が触れるか。repo のロールとは別の話。

• 🏛️ Enterprise Owner — 全設定とポリシー。ただし org の設定と中身は既定で見えない
• 🏢 Org Owner — その org の全権。絞る。ただし 2 名を下回らない
• 🛡️ Security Manager — 全 repo の Read とアラート管理。セキュリティ班に Owner は要らない
• 🧩 カスタム組織ロール — 「監査ログの閲覧だけ」など、必要な権限だけを束ねる（GHEC）

🎯 Owner は肩書きではなく鍵。配る前に、足りる小さいロールを探す。 Org roles ↗ · Custom org roles ↗

リポジトリ権限ロール

ここからは repo の中。誰が何をするか。ロールは積み上げ式。

🧩 合うものがなければ、org レベルでカスタムリポジトリロールを作る。 Custom roles ↗

Rulesets 📖 Docs

ポリシーが「できること」、ロールが「誰が」。ruleset はコードに何を求めるか。

• 🛡️ branch protection の後継 — レビュー必須、必須チェック、署名、force push 禁止をひとまとめに
• 🏛️ ENT / ORG / REPO で定義 — 上位で決めれば、配下の repo すべてに効く
• 🔁 重ねて効く — 複数当たれば最も厳しいものが勝つ。下位で緩められない
• 🧪 Evaluate モード — 強制せずに影響だけ測る。既存 repo にはここから入れる

🎯 bypass は既定で付けない。付けた ruleset は強制ではなく「お願い」。 Org rulesets ↗

12 のアンチパターン

構造は以上。次はそれを壊すもの。01、02、11 は後から直しにくい。

18 項目のガードレール 📖 Docs

設定する値と、設定する場所。時間がなければ 03、15、18。

Copilot managed settings（NEW）

Copilot クライアントも同じ。copilot/managed-settings.json がローカル設定を上書きする。優先順位は MDM → server-managed → file → user。全キー ↗

.github-private & source org

置き場所は自分が持つ 1 つの repo。Enterprise → AI controls → Agents で指定する。

.github-private/
├── agents/                    # enterprise 全体に公開
├── .github/agents/            # 検証用ステージング
└── copilot/
    ├── managed-settings.json  # 基準となる設定
    ├── team-mappings.json     # file → enterprise team
    └── teams/*.json           # team ごとの上書き

• 🏢 選べるのは org だけ。repo 名と copilot/ のパスは固定。
• 🔒 repo アクセスの有無に関係なくプラン全員に効く。internal にして copilot/** を CODEOWNERS で守る。

★ 使いどころ

5 つの層、ルールは 1 つ。上から設定する。

🎯 上から決める。repo ごとでは回らない。