GitHub Organization──組織アカウントの位置づけ

これまでのPartで扱ってきた「個人アカウント」は、文字通り個人の所有物です。退職時に持ち出されてしまう・本人のスマホ紛失でロックがかかると業務が止まるなど、組織で運用するには問題が多くあります。これを解決するのが Organization（組織アカウント） です。

Organization の3つの利点

• 所有権が組織にある──個人退職時もリポジトリは組織に残る
• 権限を集中管理できる──Owner（管理者）と Member の役割を明確に分けられる
• 請求・課金を一本化できる──個人が勝手に課金プランに登録するのを防げる

Organization 作成手順

1. Owner役の管理者がGitHubにログイン
2. 右上の「+」→ New organization
3. プラン選択（Free でスタート可）
4. Organization名（URLの一部になる）を決める。会社名やドメイン名と揃えるのが一般的（例 hatenabase）
5. 請求情報（Free 以外）を入力

名前は後から変更可能ですが影響が広いので、最初に確定させましょう。すでに同名が取られている場合は company-corp、company-jp のようなバリエーションで取得します。

Teams で権限を設計する

Organization に複数メンバーが入ったら、Teams（チーム） で権限の枠を切ります。Slackのチャネルに似た概念で、メンバーを集約して、リポジトリ単位でチームに権限を付与する仕組みです。

Teams の典型的な構造

hatenabase（Organization）
├── owners              # 経営層・情シス管理者（全権）
├── engineering         # 開発チーム
│   ├── frontend
│   └── backend
├── consulting          # コンサル事業部
│   ├── accounting
│   └── dx
├── corporate           # 管理部門
│   ├── hr
│   ├── finance
│   └── it-support
└── all-staff           # 全社員（社内ナレッジ閲覧用）

Teams は階層化できるので、「all-staff の中に corporate、その中に hr」のような入れ子も可能。リポジトリの権限を上位チームに付与すれば、下位チームに自動で継承されます。

権限ロール（5段階）

9割のメンバーはWriteで十分。Maintain と Admin を持つ人を絞ることで、設定が不用意に変わるリスクを抑えられます。

Codeowners ファイル

特定のフォルダ・ファイルに「自動的にレビュアーを指名する」仕組みがあります。リポジトリ直下に CODEOWNERS というファイルを置いて記述します。

# 経理関連は accounting チームが必ずレビュー
/finance/        @hatenabase/accounting

# 全社共通の文体ガイドは経営企画＋広報
/style-guide.md  @hatenabase/strategy @hatenabase/pr

# CLAUDE.md は経営企画と情シスの両方が承認
/CLAUDE.md       @hatenabase/strategy @hatenabase/it-support

これがあると、PRを開いた瞬間に該当チームに自動で通知が飛び、Approve がないとマージできない状態にできます。組織のレビュー文化を担保する強力な仕組みです。

セキュリティ──SSO・2FA・監査ログ

組織で扱う情報の機密度が上がってきたら、3つのセキュリティ機能を設定します。

1. 2要素認証（2FA）の組織強制

個人アカウントでも2FAは必須ですが、Organization Owner として「全メンバーに2FAを強制」する設定があります。Settings → Authentication security → Require two-factor authentication。

これを有効化すると、2FA未設定のメンバーは強制的にOrganizationから外れます（個人アカウントは残ります）。導入時は2週間の猶予を取ってアナウンスしてから有効化するのが運用しやすいです。

2. SAML SSO（Single Sign-On）

Enterprise プランでのみ利用可能ですが、Okta／Microsoft Entra ID／Google Workspace との SSO 連携ができます。社員がGitHub専用のIDとパスワードを覚える必要がなくなり、入退社のプロビジョニングも自動化できます。

30人以上の組織なら、SSO は必ず入れる前提で設計してください。これが無いと退職時に各リポジトリから手動で外す作業が必要になり、抜け漏れが起きます。

3. 監査ログ（Audit Log）

誰がいつ何をしたか（リポジトリ作成・削除、メンバー追加、権限変更、Public化など）が全部記録されます。Settings → Logs → Audit log で参照可能。エクスポートして社内のSIEM/ログ基盤に流し込むことで、セキュリティ監査の要件を満たせます。

不正な持ち出しの調査でも使えます。退職予定者がリポジトリを大量に Fork したり Clone した形跡は、ここから追えます。

プランと費用感（Free／Team／Enterprise）

2026年4月時点の主要プランを整理します。価格は1ユーザーあたりの月額（USD）です。

どこから Enterprise にするべきか

判断軸は以下のうち1つでも当てはまるかです。

• 従業員50人を超える
• SSO（Okta／Entra ID／Workspace）を入れている
• 監査ログを SIEM に流す要件がある（ISO27001・SOC2 取得済み／取得中）
• 顧客から「セキュリティ要件として GitHub Enterprise」を求められた

該当するなら Enterprise、しないなら Team で十分。30人未満で「ガバナンス強化したい」だけなら Team + 運用ルールで賄えます。

GitHub Copilot Business／Enterprise の選び方

GitHub Copilot は、コーディング補助 AI として始まりましたが、現在は「組織の知識を踏まえた質問応答」へと拡張されています。非エンジニアの業務でも、Copilot Business 以上を使うと実感する効果があります。

非エンジニア業務での価値が高いのは Copilot Enterprise の Knowledge Bases 機能です。Part 4 で構築したコンテキスト・リポジトリを Copilot に登録すると、社内独自の文脈を踏まえた回答を社員が自然言語で得られるようになります。

Copilot Enterprise vs Claude / ChatGPT Enterprise

Copilot Enterprise は 「GitHub上の社内ナレッジを直接読む」のが強みですが、汎用AIとしての能力は2026年時点で Claude や ChatGPT のフラッグシップに分があります。実務では次の組み合わせが多いです。

• Claude Pro / Team──汎用思考力が必要な分析・文章作成
• ChatGPT Team / Enterprise──マルチモーダル（画像・音声）が必要な業務
• Copilot Business──開発者向けコーディング支援＋GitHub内検索
• Copilot Enterprise──全社員に「社内ナレッジに基づくチャットUI」を提供したい時

「全部入れる」のは一見過剰ですが、用途が異なるので併用するケースが多いです。月20人の利用で月10万円弱、これを「効率化されている時間」と比較すると十分元が取れる水準です。

社内浸透のロードマップ（4 Phase）

GitHub の組織導入は、4フェーズで段階的に進めるのが定着率を高めます。一気に全員強制ではなく、まず実感ファンを作って、そこから波及させるアプローチです。

Phase 1：パイロット（1〜2ヶ月）

• 3〜5名の Champion を選定（情シス1、開発1、ビジネス側2〜3）
• Organization 立ち上げ、Teams の枠だけ作成
• 個人リポジトリ・部門リポジトリ・全社リポジトリの初版を作る
• Champion 間で Issue・PR・Discussions を「とにかく使ってみる」

Phase 2：部門展開（2〜3ヶ月）

• 1〜2部門を選んで全員に展開（経理 or 人事から始めると効果が見えやすい）
• 本シリーズ Part 1〜3 をベースにした2時間の社内ハンズオン研修を実施
• 部門ごとにリポジトリ構造とラベル設計を決定
• 導入KPI: 「Issueが週何件立ったか」「PRが何件マージされたか」

Phase 3：全社展開（3〜6ヶ月）

• SSO 連携（Okta/Entra ID/Workspace）を本番化
• 2FA 強制を有効化、Audit Log を社内SIEMに連携
• 全部門でリポジトリ構造を立ち上げ
• Copilot Business を希望者に提供開始（最初は20〜30名で試す）

Phase 4：継続改善（半年以降ずっと）

• 四半期で Champion 会を開催、運用ルールの見直し
• Copilot Enterprise への昇格判断（コンテキストが十分溜まってから）
• 新人入社時のオンボーディングに GitHub研修を組み込む
• 放置されたリポジトリの棚卸し（年1回）

このロードマップに沿うと、半年〜1年で「GitHubが社内ナレッジ基盤として当たり前」の文化に到達できます。組織サイズが大きいほど時間はかかりますが、Phase 1 を飛ばさないことが何より重要です。

よくある反対意見と返し方

導入提案の際、必ずと言っていいほど受ける質問・反対意見があります。事前の答えを準備しておくとスムーズです。

「Notion／Confluence で十分では？」

Notion は体験のリッチさでは勝りますが、変更履歴の精度・コードとの親和性・AI連携の柔軟性でGitHubに分があります。実務では「軽い議事録・案件管理は Notion、社内ナレッジ正本・AI 用コンテキストは GitHub」という併用が現実解です。完全に置き換える必要はありません。

「Markdown が書けない人がいる」

Markdown は10個の記号を覚えるだけで実用範囲です（Part 2 を参照）。それでも難しい場合は、Visual Studio Code や Typora などWYSIWYGプレビュー付きエディタを使うと、書きながら表示が確認できます。半日の研修で全員カバーできるレベルです。

「英語UI で挫折者が出る」

主要操作は10〜20語で覚えられます。Repository（保管庫）／Branch（枝）／Commit（保存）／Issue（議題）／Pull Request（変更提案）／Merge（合流）／Settings（設定）──このあたりを社内用語集に載せて、新人研修で1回学ぶだけで定着します。

「機密情報が漏れたら？」

本シリーズPart 4 で扱った原則を守れば、機密漏洩リスクはむしろ Drive・メールよりも低くなります。誰がアクセスしたかが Audit Log に残り、退職時のアクセス遮断が SSO で自動化できるからです。逆に、メール添付や個人 Drive の方が追跡できないため、現状維持こそが最大のリスクです。

「コストが追加で発生する」

Team プラン $4/人/月 は、コーヒー1杯の値段です。AI関連の効率化で月10時間／人の削減が見込めるなら、人件費換算で2〜3万円の効果。投資対効果は明らかにポジティブです。Enterprise は要件次第ですが、コンプライアンスを満たすコストとして他社製品と比較しても標準的です。

シリーズ完了後の次のステップ

5回のシリーズはここまでです。Part 1 で歴史と意義を理解し、Part 2 で個人として使い始め、Part 3 でチームでコラボし、Part 4 で AI コンテキストを集約し、本記事 Part 5 で組織として運用設計を整える──この流れを踏むと、GitHubは単なるツールではなく、組織の知性を増幅させる基盤に姿を変えます。

本シリーズの内容を実践に移すうえでの次のステップは2つあります。

1. 1〜2人の Champion 選定と Phase 1 の開始──組織内で本記事を読んだ人がもう何人かいれば、そのまま Phase 1 のメンバーになり得ます。今週中に1時間、ホワイトボード前で「うちのリポジトリ構造どうする？」を話すところから
2. Part 4 の CLAUDE.md ／用語集の初版作成──最初の1ファイルを書くまでが一番重い。30分集中して書けば最初の版ができます。完璧でなくて構いません。あとから改訂を続ける前提で動き出すのが正解です

はてなベース 研修事業部では、本シリーズの内容をベースにした研修プログラムを提供しています。社内に Champion を作る支援、Organization 立ち上げの設計、Phase 2の部門展開研修、AI用コンテキストの初版作り──個別の悩みに合わせて伴走させてください。

本シリーズの全体像（再掲）

1. Part 1──GitHubとは何か（理論編）
2. Part 2──アカウント作成と最初のリポジトリ（個人ハンズオン）
3. Part 3──編集・履歴・チーム共有（チーム運用入門）
4. Part 4──AI用コンテキストをGitHubで管理する実践（AI連携）
5. Part 5（本記事）──組織導入と運用（情シス・経営層向け）