Wiki: ページの作成:「== 概要 == GitHub Organizations (組織) は、複数のプロジェクトにわたって大規模なチームが協力して作業するための共有アカウントである。

個人アカウントが1人のユーザに紐付いているのに対して、Organizationは複数のメンバーが共同で所有・管理するアカウントである。
企業やオープンソースプロジェクトにおいて、コードの管理・共有・ア…」

2026-03-23T20:05:52Z

ページの作成:「== 概要 == GitHub Organizations (組織) は、複数のプロジェクトにわたって大規模なチームが協力して作業するための共有アカウントである。 個人アカウントが1人のユーザに紐付いているのに対して、Organizationは複数のメンバーが共同で所有・管理するアカウントである。 企業やオープンソースプロジェクトにおいて、コードの管理・共有・ア…」

新規ページ

== 概要 ==
GitHub Organizations (組織) は、複数のプロジェクトにわたって大規模なチームが協力して作業するための共有アカウントである。 
 
個人アカウントが1人のユーザに紐付いているのに対して、Organizationは複数のメンバーが共同で所有・管理するアカウントである。 
企業やオープンソースプロジェクトにおいて、コードの管理・共有・アクセス制御を一元化する目的で広く利用されている。 
 
Organizationが提供する主な機能は以下の通りである。 
 
<center>
{| class="wikitable"
|+ Organizationの機能
|-
! 項目 !! 説明
|-
| 細粒度の権限管理 || メンバーごとにリポジトリへのアクセスレベルを細かく設定できる。
|-
| チーム組織 || メンバーをチームに分けて管理し、チーム単位でリポジトリへの権限を付与できる。
|-
| 高度なセキュリティ機能 || 二要素認証の必須化、SAML SSO、監査ログ等のセキュリティ機能を利用できる。
|-
| 集中管理 || リポジトリ、メンバー、課金をOrganization単位で一元管理できる。
|}
</center>
 

== Organizationの作成と設定 ==
==== 作成手順 ====
Organizationの作成手順を以下に示す。 
 
# GitHubにログインして、右上のプロフィール画像を選択する。
# メニューから[Your organizations]を選択する。
# [New organization]ボタンを押下する。
# Organization名とメールアドレスを入力する。
# プラン (Free / Team / Enterprise) を選択する。
# 必要な追加情報を入力して、作成を完了する。
 
作成後、メンバーの招待やリポジトリの作成といった初期設定を行うことができる。 
 
==== プロフィール設定 ====
Organizationのプロフィール情報は、[Settings]から変更できる。 
 
設定可能な項目は以下の通りである。 
 
<center>
{| class="wikitable"
|+ Organizationのプロフィール設定
|-
! 項目 !! 説明
|-
| 組織名 || Organizationの識別子となる名前 [Settings]から変更できるが、変更後に旧名は他のユーザに取得される可能性があるため、変更は慎重に行うこと。
|-
| アバター || Organizationを代表するプロフィール画像
|-
| 説明 || Organizationの目的や概要を記述するテキスト
|-
| URL || Organizationに関連するWebサイトのURL
|}
</center>
 
==== 個人アカウントからの変換 ====
個人アカウントをOrganizationへ直接変換することはできない。 
 
アカウントの種別変換が必要な場合は、以下の手順を取る必要がある。 
# 新規にOrganizationを作成する。
# 個人アカウントのリポジトリをOrganizationに移行する。
# 個人アカウントのコラボレータをOrganizationのメンバーとして招待する。
 
同様に、OrganizationをPersonalアカウントへ変換することも不可能である。 
 

== メンバー管理 ==
==== メンバーの招待 ====
Organizationへのメンバー招待は、OwnerがGitHubのユーザ名またはメールアドレスを指定して行う。 
 
招待の手順は以下の通りである。 
# Organizationページを開いて、[People]タブを選択する。
# [Invite member]ボタンを押下する。
# 招待するユーザのユーザ名またはメールアドレスを入力する。
# 対象ユーザにロールを選択して招待を送信する。
 
招待を受け入れる前であれば、OwnerはいつでもOrganizationの設定画面から招待を編集またはキャンセルできる。 
 
==== 権限ロール ====
Organizationのメンバーには、以下に示すいずれかのロールが割り当てられる。 
 
<center>
{| class="wikitable"
|+ Organizationのメンバーロール
! ロール !! 説明
|-
| Owner || Organization全体に対する最高権限を持つ。 メンバー管理、課金管理、セキュリティ設定、リポジトリ管理等の全ての操作が可能
|-
| Member || Organizationの基本的なメンバー 付与された権限の範囲でリポジトリへのアクセスや操作が可能
|-
| Billing Manager || 課金情報の管理のみを担当する。 リポジトリやメンバーへのアクセス権限は持たない。
|-
| Security Manager || セキュリティ関連の機能を管理できる。 GitHub Enterprise Cloudでのみ利用可能
|-
| Moderator || メンバーへのアクセス制限やブロックを行う権限を持つモデレータ
|}
</center>
 
==== メンバーの削除 ====
Ownerは、Organization設定の[People]タブからメンバーを削除できる。 
 
メンバーを削除した場合の影響は以下の通りである。 
* 該当メンバーはOrganizationの全てのリポジトリへのアクセスを失う。
* プライベートリポジトリをフォークしていた場合、そのフォークは削除される。
*: ただし、ローカルにクローン済みのコードはそのまま保持される。
 
==== 外部コラボレータ ====
外部コラボレータとは、Organizationのメンバーではないが、特定の1つ以上のリポジトリへのアクセス権限を持つ人物のことである。 
 
外部コラボレータの特徴は以下の通りである。 
* Organizationのメンバーシップは持たず、特定リポジトリへのアクセスのみが付与される。
* プライベートリポジトリに外部コラボレータを追加する場合は、有料ライセンスを消費する。
* セキュリティの観点から、外部コラボレータへのアクセス権は最小限にとどめることが推奨される。
 
==== 元メンバーの再招待 ====
以前にOrganizationに所属していたメンバーを再招待する場合、過去の設定を復元するオプションが提供される。 
 
再招待時に復元を選択できる項目は以下の通りである。 
 
<center>
{| class="wikitable"
|+ メンバー復帰時に復元される情報
|-
! 項目 !! 説明
|-
| ロール || 削除前に保持していたOrganizationロール
|-
| アクセス権 || 削除前に付与されていたリポジトリへのアクセス権限
|-
| フォーク || 削除時に削除されたプライベートリポジトリのフォーク
|-
| 各種設定 || その他の個人設定
|}
</center>
 
これらの復元は任意であり、再招待時に個別に選択できる。 
 

== チーム ==
==== チームの作成 ====
チームはOrganization内のメンバーをグループ化して、リポジトリへの権限を一括管理するための機能である。 
 
チームの作成手順は以下の通りである。 
# [Organization]ページの[Teams]タブを開く。
# [New team]ボタンを押下する。
# チーム名と説明を入力する。
# チームの可視性を選択する。
# チームを作成する。
 
チームの可視性には、以下に示す2種類がある。 
* Visible team
*: Organizationの全メンバーから検索・メンション (@チーム名) が可能な公開チーム
* Secret team
*: チームのメンバーとOwnerのみが存在を確認できる非公開チーム
 
==== ネストされたチーム ====
チームは階層構造 (ネスト) を持つことができ、親チームと子チームの関係を定義できる。 
 
ネストされたチームの主な特徴は以下の通りである。 
* 子チームは親チームの権限を自動的に継承する。
* 親チームに対して @メンション を行うと、全ての子チームメンバーにも通知が届く。
* 組織の部門・チーム構造を反映した権限管理が可能になる。
 
==== チームへのリポジトリ割り当て ====
チームには複数のリポジトリを割り当てることができ、リポジトリごとにアクセスレベルを設定できる。 
 
設定できるアクセスレベルは以下の通りである。 
 
<center>
{| class="wikitable"
|+ チームのリポジトリ権限レベル
|-
! 権限 !! 説明
|-
| Read || リポジトリの参照のみ可能
|-
| Write || コードの閲覧とプッシュが可能
|-
| Admin || リポジトリの設定を含む全ての操作が可能
|}
</center>
 
親チームに割り当てられたリポジトリアクセス権は、子チームに自動的に継承される。 
 
==== チームの権限とメンテナー ====
チームメンテナーは、Ownerから委任されてチームの管理を行うロールである。 
 
チームメンテナーが実行できる操作は以下の通りである。 
* チームメンバーの追加・削除
* チームのプロフィール画像の変更
* チーム名の編集
* チームの表示・非表示の変更
* チームの通知設定の管理
* チームに割り当てられたリポジトリのアクセス権限の管理
 

== リポジトリ管理 ==
==== Organization所有リポジトリ ====
Organizationが所有するリポジトリは、個人アカウントのリポジトリとは独立して管理される。 
 
Organizationリポジトリの主な特徴は以下の通りである。 
* 複数のメンバーやチームが協調してリポジトリを管理できる。
* メンバーの退職・脱退後もOrganizationのリポジトリは保持される。
* Organizationのプランに応じて、プライベートリポジトリの作成が可能。
 
==== リポジトリ権限レベル ====
リポジトリへのアクセス権限は5段階のレベルで設定できる。 
 
<center>
{| class="wikitable"
|+ リポジトリ権限レベル
! 権限レベル !! 説明
|-
| Read || リポジトリの参照のみ可能 コードの閲覧、Issue・PRの閲覧ができる。
|-
| Triage || Issueやプルリクエストの管理が可能 コードのプッシュはできない。
|-
| Write || コードの閲覧・プッシュ、プルリクエストのマージが可能
|-
| Maintain || リポジトリの設定管理が可能 ただし、リポジトリの削除・アーカイブはできない。
|-
| Admin || リポジトリの削除を含む全ての操作が可能なフル権限
|}
</center>
 
==== デフォルト権限設定 ====
Organization設定でデフォルト権限を設定すると、新規メンバー参加時に自動的に適用される。 
 
設定可能なデフォルト権限レベルは以下の通りである。 
 
<center>
{| class="wikitable"
|+ Organization のベースパーミッション
|-
! 権限 !! 説明
|-
| None || リポジトリへのデフォルトアクセスなし (デフォルト値)
|-
| Read || 全てのリポジトリを参照可能
|-
| Triage || Issue / PR管理が可能
|-
| Write || コードのプッシュが可能
|-
| Maintain || リポジトリ設定の管理が可能
|-
| Admin || 全てのリポジトリに対するフル権限
|}
</center>
 
デフォルト権限はOrganizationの全メンバーに適用されるため、最小権限の原則に従い <code>None</code> または <code>Read</code>> を設定することが推奨される。 
 
==== リポジトリの可視性ポリシー ====
Ownerは、Organizationメンバーがリポジトリを作成・変更できる可視性をポリシーで制限できる。 
 
<center>
{| class="wikitable"
|+ リポジトリの可視性に関するポリシー
|-
! カテゴリ !! 設定内容
|-
| rowspan="3" | 作成時の可視性制限 || PublicとPrivateの両方を許可する。
|-
| Publicのみ許可する。
|-
| リポジトリの作成を禁止する。
|-
| rowspan="2" | 可視性変更の権限制限 || Ownerのみが変更可能とする。
|-
| Admin権限を持つ全メンバーが変更可能とする。
|}
</center>
 

== セキュリティ ==
==== 2要素認証の必須化 ====
Ownerは、Organizationの全メンバーに対して2要素認証 (2FA) の有効化を必須とするポリシーを設定できる。 
 
設定手順は以下の通りである。 
# [Organization]の[Settings]を開く。
# [Security]セクションの[Authentication security]を選択する。
# [Require two-factor authentication]を有効にする。
 
設定時の重要な注意点は以下の通りである。 
* OwnerはOrganizationで2FAを必須化する前に、自分自身のアカウントで2FAを有効化する必要がある。
* 2FA未設定のメンバー
*: Organizationリソースへのアクセスが不可になるが、メンバーシップ自体は保持される。
* 2FA未設定の外部コラボレータ
*: Organizationから削除される。
 
==== SAML SSO ====
SAML SSO (Security Assertion Markup Language Single Sign-On) は、Organizationメンバーが企業のIDプロバイダを通じてGitHubにアクセスするための認証機能である。 
 
SAML SSOを使用することにより、以下のセキュリティ要件を満たすことができる。 
* メンバーの認証を社内のIDプロバイダに統合できる。
* メンバーが退職した場合、IDプロバイダ側で無効化するだけでアクセスを即座に遮断できる。
* SAML SSOはGitHub Enterprise Cloudプランで利用可能
 
==== SSH証明書機関 ====
Organizationは独自のSSH証明書機関 (CA) を設定でき、メンバーのSSH鍵の代わりに証明書を利用してリポジトリへアクセスさせることができる。 
 
SSH証明書機関を使用することにより、SSH鍵の個別管理を不要にして、一元的な認証管理が実現する。 
 
==== IPアドレス許可リスト ====
Organization設定でIPアドレスの許可リストを設定することにより、特定のIPアドレスまたはIPアドレス範囲からのみアクセスを許可できる。 
 
許可リストを使用することで、不正なネットワークからのアクセスをブロックして、セキュリティを強化できる。 
 
==== 監査ログ ====
監査ログは、Organization内で発生した全ての操作を記録する機能である。 
 
下表に、監査ログの主な特徴を示す。 
 
<center>
{| class="wikitable"
|+ 監査ログの概要
|-
! 項目 !! 説明
|-
| アクセス権限 || Ownerのみがアクセス可能
|-
| 保持期間 || 過去180日間の操作ログが保持される。
|}
</center>
 
<center>
{| class="wikitable"
|+ 監査ログのフィルタリング方法
|-
! フィルタ !! 説明
|-
| カテゴリフィルタ || <code>repo</code> / <code>team</code> / <code>org</code> / <code>billing</code> / <code>hook</code> 等でフィルタリング可能。
|-
| アクションフィルタ || <code>action:team.create</code> のように特定のアクションで検索可能
|-
| アクターフィルタ || <code>actor:username</code> のように特定ユーザの操作で検索可能
|}
</center>
 
エクスポート形式は以下の通りである。 
* JSON形式
* CSV形式
 

== 組織のポリシー ==
==== リポジトリ作成の制限 ====
Ownerは、Organizationメンバーがリポジトリを作成できる範囲をポリシーとして設定できる。 
 
設定可能なポリシーは以下の通りである。 
* 全メンバーがパブリックおよびプライベートリポジトリを作成可能とする。
* 全メンバーがパブリックリポジトリのみ作成可能とする。
* リポジトリ作成をOwnerのみに制限する。
 
==== フォークポリシー ====
Ownerは、プライベートリポジトリやインターナルリポジトリのフォークを許可するかどうかをポリシーで制御できる。 
 
フォークポリシーの設定項目は以下の通りである。 
* プライベートリポジトリのフォークを許可または禁止する。
* インターナルリポジトリのフォーク先をOrganition内に限定するか、外部も許可するかを設定する。
 
==== GitHub Actionsのポリシー ====
Ownerは、Organization全体のGitHub Actionsの使用ポリシーを設定できる。 
 
設定可能なポリシーは以下の通りである。 
* All actions allowed
*: 全てのActionの使用を許可する。
* Local actions only
*: Organization内またはリポジトリ内のActionのみ使用を許可する。
* Selected actions allowed
*: 指定した特定のActionのみ使用を許可する。
 
その他のActionsに関するポリシーとして、セルフホストランナーの利用制限や外部コントリビュータによるフォークからのプルリクエスト実行時の承認設定も管理できる。 
 
==== GITHUB_TOKEN権限 ====
GitHub Actionsで自動生成される <code>GITHUB_TOKEN</code> のデフォルト権限をOrganization全体で設定できる。 
 
設定できる権限は以下の通りである。 
* Read-only
*: 読み取り専用権限 (推奨)
* Read and write
*: 読み取りおよび書き込み権限
 
セキュリティの観点から、デフォルトは <code>>Read-only</code> に設定することが推奨される。 
 

== 課金と管理 ==
==== 組織のプラン ====
Organizationでは、以下に示す3つのプランから選択できる。 
 
<center>
{| class="wikitable"
|+ Organizationのプラン比較
! プラン !! 主な特徴
|-
| Free || 基本的な機能を無料で提供 パブリックリポジトリは無制限、プライベートリポジトリも利用可能。GitHub Actionsの無料枠あり。
|-
| Team || 小・中規模チーム向けの有料プラン コードオーナー設定、必須レビュアー等の高度なコラボレーション機能を含む。
|-
| Enterprise || 大規模組織向けの上位プラン SAML SSO、カスタムロール、高度なセキュリティ機能、GitHub Advanced Security等が利用可能
|}
</center>
 
==== 課金管理者 ====
Billing Manager (課金管理者) は、Organizationの課金情報を専門に管理するロールである。 
 
Billing Managerが管理できる項目は以下の通りである。 
* 支払い方法の設定・変更
* 請求先情報の管理
* 利用レポートの確認
* サブスクリプションとライセンスの管理
 
Billing Managerは、セキュリティ機能や機密リポジトリへのアクセス権を持たないため、課金管理のみを委任したい場合に適している。 
 
==== 使用量の確認 ====
Organizationの使用量は、[Settings]の[Billing and plans]から確認できる。 
 
確認できる情報は以下の通りである。 
* 現在のプラン情報
* 月間の支払い額
* GitHub Actionsの使用量 (分数・ストレージ)
* Git LFS等のストレージ使用量
* 共同編集者数とライセンス消費状況
 

{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,Electric Circuit,Electric,pcb,Mathematics,AVR,TI,STMicro,AVR,ATmega,MSP430,STM,Arduino,Xilinx,FPGA,Verilog,HDL,PinePhone,Pine Phone,Raspberry,Raspberry Pi,C,C++,C#,Qt,Qml,MFC,Shell,Bash,Zsh,Fish,SUSE,SLE,Suse Enterprise,Suse Linux,openSUSE,open SUSE,Leap,Linux,uCLnux,電気回路,電子回路,基板,プリント基板
|description={{PAGENAME}} - 電子回路とSUSE Linuxに関する情報 | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}

__FORCETOC__
[[カテゴリ:Git]]

GitHub - Organizations - 版の履歴