第9章 GitHub Organizationの管理

ここまではリポジトリ単位の管理を学んできました。
この章では視野を広げて、Organization 全体 の管理を学びましょう。

管理者の腕の見せどころです 👔

この章のゴール

1. Organization の役割とメンバー管理を理解できる
2. Team を使った権限設計ができる
3. リポジトリ権限の階層構造を理解している
4. Audit Log を活用してセキュリティ監査ができる
5. Webhooks / GitHub Apps による外部連携を管理できる

---

9.1 Organization の構成と役割

Organization とは？

Organization は、複数のリポジトリとメンバーをまとめて管理するための仕組みです。
会社、チーム、OSSプロジェクトなど、グループ単位の開発 に使います。

flowchart TD
    ORG["🏢 Organization
(your-company)"]
    ORG --> T1["👥 Team: Frontend"]
    ORG --> T2["👥 Team: Backend"]
    ORG --> T3["👥 Team: DevOps"]
    T1 --> R1["📁 web-app"]
    T1 --> R2["📁 design-system"]
    T2 --> R1
    T2 --> R3["📁 api-server"]
    T3 --> R1
    T3 --> R3
    T3 --> R4["📁 infrastructure"]

    style ORG fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style T1 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style T2 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style T3 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1

Organization の役割

役割	権限	対象者
Owner	Organization のすべての設定を管理	CTO、管理責任者（最小限に）
Member	Team 経由でリポジトリにアクセス	一般の開発者
Billing Manager	課金情報のみ管理	経理担当
Outside Collaborator	特定リポジトリのみアクセス	外部パートナー

Owner は最小限に

Owner はすべてのリポジトリ・設定にアクセスできるため、
2〜3名 に限定するのがベストプラクティスです。

Owner が1名だけだと、その人がアクセスできなくなったときに困るため、
最低2名 は設定しましょう。

---

9.2 Team の作成と権限設計

Team の役割

Team は、メンバーをグループ化して リポジトリへのアクセス権限 をまとめて管理する仕組みです。

Team の階層構造

Team は 入れ子（ネスト） にできます。
親 Team の権限は子 Team に 継承 されます。

flowchart TD
    E["🏢 engineering
(親Team)"]
    E --> FE["👥 frontend
(子Team)"]
    E --> BE["👥 backend
(子Team)"]
    E --> INFRA["👥 infrastructure
(子Team)"]
    FE --> FE_LEAD["👤 frontend-leads
(孫Team)"]

    style E fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style FE fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style BE fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style INFRA fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1

Team の権限レベル

レベル	説明
Read	コードの閲覧、Issue / PR の作成
Triage	Issue / PR の管理（ラベル、アサインなど）
Write	コードの push、PR のマージ
Maintain	リポジトリ設定の一部管理（ブランチルールなど）
Admin	リポジトリのすべての設定を管理

設計例

flowchart LR
    subgraph "Team → Repository 権限マッピング"
        FE["frontend
(Team)"]
        BE["backend
(Team)"]
        DO["devops
(Team)"]

        WA["web-app"]
        API["api-server"]
        INF["infrastructure"]
    end

    FE -- "Write" --> WA
    FE -- "Read" --> API
    BE -- "Read" --> WA
    BE -- "Write" --> API
    DO -- "Admin" --> WA
    DO -- "Admin" --> API
    DO -- "Admin" --> INF

    style FE fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style BE fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style DO fill:#FFF3E0,stroke:#FB8C00,color:#E65100

権限設計のコツ

• 最小権限の原則 — 必要最低限の権限を付与
• Team 経由でアクセス — 個人に直接権限を付けない
• 新メンバーは Read から — 慣れてきたら Write に昇格
• Admin は DevOps / Tech Lead のみ — 全員に Admin は不要

---

9.3 リポジトリ権限の階層

権限は 3つの階層 から決まります。
より狭い範囲の設定が優先されます。

flowchart TD
    O["🏢 Organization
デフォルトの権限
(Base permissions)"]
    T["👥 Team
Team 経由の権限"]
    C["👤 Collaborator
個別の権限"]

    O --> T --> C

    P["⬇️ 下にいくほど優先度が高い"]

    style O fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style T fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style C fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style P fill:#FFF9C4,stroke:#F9A825,color:#F57F17

Base Permissions の設定

Organization Settings → Member privileges → Base permissions

設定	おすすめ
No permission	最も安全。 Team 経由でのみアクセス
Read	社内リポジトリを全員が閲覧可能にしたい場合
Write	⚠️ 全員が全リポジトリに push できてしまう

おすすめは「No permission」か「Read」

• No permission — セキュリティ重視。
  Team 設計が必須
• Read — 社内の知識共有を重視。
  コード閲覧は全員OK

---

9.4 Audit Log ─ 監査ログ

Audit Log とは？

Organization 内で 誰が何をしたか を記録するログです。
セキュリティインシデントの調査や、コンプライアンス監査に使います。

確認方法

Organization → Settings → Audit log

記録される主なイベント

カテゴリ	イベント例
org	メンバーの追加・削除、役割変更
repo	リポジトリの作成・削除・Visibility変更
team	Team の作成・削除・メンバー変更
hook	Webhook の作成・変更・削除
protected_branch	Branch Protection の変更
integration_installation	GitHub App のインストール
oauth_application	OAuth アプリの認可

API 経由でのアクセス

# GitHub CLI でAudit Logを取得
gh api \
  -H "Accept: application/vnd.github+json" \
  /orgs/your-org/audit-log?phrase=action:repo.create \
  --paginate

定期的なログ確認を習慣に

月に1回は以下を確認しましょう。

• 不審なメンバー追加がないか
• リポジトリの Visibility 変更がないか
• Branch Protection の変更がないか
• 見覚えのない GitHub App がインストールされていないか

---

9.5 Webhooks / GitHub Apps

Webhooks

Webhook は、GitHub でイベントが発生したときに 指定した URL に HTTP リクエストを送信 する仕組みです。

flowchart LR
    GH["GitHub
(イベント発生)"]
    WH["Webhook
(POST リクエスト)"]
    SV["外部サーバー
(Slack, CI, etc.)"]

    GH -- "push, PR, etc." --> WH --> SV

    style GH fill:#F3E5F5,stroke:#8E24AA,color:#4A148C
    style WH fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style SV fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1

用途例

連携先	用途
Slack	PR 作成やマージを通知
CI/CD	push をトリガーにビルド開始
社内ツール	Issue 作成をタスク管理ツールに連携
監視ツール	デプロイイベントを記録

GitHub Apps

GitHub Apps は Webhook よりも高度な連携ができるアプリケーションです。
API 操作、コメント投稿、ステータスチェックなどを プログラムから実行 できます。

Webhook vs GitHub Apps

項目	Webhook	GitHub Apps
方向	GitHub → 外部（一方向）	双方向
認証	Secret で検証	Installation Token
権限	なし（通知のみ）	細かく設定可能
API 操作	不可	可能
使いどころ	シンプルな通知	高度な自動化

Webhook のセキュリティ

• Secret token を必ず設定して、リクエストの送信元を検証する
• 受信サーバーは HTTPS で公開する
• 不要になった Webhook は速やかに削除する

---

まとめ

管理項目	やるべきこと
Organization 設定	Owner を最小限に、Base permissions を適切に
Team 設計	組織構造に合わせた階層設計、最小権限
権限管理	Team 経由でアクセス、個人への直接権限は避ける
Audit Log	定期的な監査、不審なアクティビティの監視
Webhook / Apps	Secret 設定、不要な連携の削除

達成チェック ✅

• Organization の役割（Owner / Member）を理解している
• Team の階層構造と権限設計ができる
• Base Permissions の適切な設定を選択できる
• Audit Log の確認方法と主要なイベントを把握している
• Webhook と GitHub Apps の違いを説明できる

次は 第10章「GitHub CLI（gh コマンド）」 に進みましょう！ 🎉