GitHubの権限と2段階認証：共同作業者・Organization・非公開リポジトリ

公開 2026年11月7日更新 2026年11月8日書いた人大林諒

GitHubの権限の話は、機能の話というより「いま誰が何を見られて、何を変えられるか」を答えられるかどうかの話です。「非公開」は誰にも見えないという意味ではありません。招待した人には、過去の履歴まで全部見えます。

ここでは小さな料理教室を例に、個人アカウントとOrganizationの違い、外注に渡すときの権限と外し方、2段階認証、トークン、連携アプリまで、実際に出会う順に書きます。リポジトリはファイルと履歴をまとめて入れておく保管場所、Organizationは会社やチームで持つ共有のアカウントです。読み終わると、自分のリポジトリを誰が見られるかを画面で確かめて、必要なら減らせるようになります。

この記事の内容

先に答えると
個人アカウントとOrganizationの違い
個人リポジトリに共同作業者を招待する
Organizationを作ってリポジトリを移す
Organizationのロール
外注に渡すときの最小権限
仕事が終わったら外す、退職時にすること
2段階認証を設定する
トークンは期限付きのfine-grainedを選ぶ
連携アプリの権限を見る
非公開から公開へ変えるとき
できないことと、その代わり
よく詰まるところ
次に読む

先に答えると

会社で使うならOrganizationを作り、その中にリポジトリを置きます。個人アカウントのリポジトリはその人のものなので、担当者が辞めると管理者もいなくなります。OrganizationはFreeでも作れます。外注には必要なリポジトリだけ、仕事に足りる一番弱いロールで招待し、終わったら外します。

個人の非公開リポジトリの共同作業者は、読むだけの招待ができません。必ず書き込みもできます
Organizationのロールは Read・Triage・Write・Maintain・Admin の5段階です
2段階認証は認証アプリで設定し、リカバリーコードをパスワード管理ツールに保管します
トークンは期限を付けた fine-grained を選びます
連携アプリは「Only select repositories」で範囲を絞り、使わなくなったら外します

個人アカウントとOrganizationの違い

サンプル料理教室は、Organization sample-cooking の下に website と reservation-mail を置きます。代表の個人アカウントに置いた場合との違いです（料金は2026年11月時点、1ユーザー月額）。

見るところ	個人アカウント	Organization
リポジトリの持ち主	その人個人	組織
権限の段階	持ち主と共同作業者の2段階	Read から Admin までの5段階
非公開で読むだけの招待	できない	Read でできる
管理者	本人だけ	オーナーを複数置ける
人が辞めたとき	管理者ごといなくなる	リポジトリは組織に残る
全員に2段階認証を求める	できない	設定できる
料金	Free $0	Free $0、Team $4、Enterprise $21

Organizationを勧める一番の理由は、人が辞めても残ることです。実際に運用していると、前任者や制作会社の個人アカウントに本番のコードがあり、連絡が取れなくなって困る話は珍しくありません。公式も、オーナーは少なくとも2人置くことを勧めています。サンプル料理教室なら、代表ともう1人の社内の人です。外注には渡しません。

FreeのOrganizationでも非公開リポジトリは数の制限なく作れ、非公開の共同作業者数も料金表で「Unlimited」です。ただし、保護ブランチ（直接の変更を禁じる設定）、コードオーナー、必須レビューなどは非公開では使えません。これらが要るならTeamを検討します。

個人リポジトリに共同作業者を招待する

まだ個人アカウントのリポジトリで動いているなら、共同作業者（Collaborator）として招待します。

相手のGitHubのユーザー名を聞きます。アカウントがなければ先に作ってもらいます。
リポジトリの「Settings」を開きます。見当たらなければ「More」の中にあります。
サイドバーの「Access」にある「Collaborators」または「Collaborators & teams」を開きます。
「Add people」を押します。
相手の名前を入力し、候補から選びます。
「Add NAME to REPOSITORY」を押します（NAMEとREPOSITORYは実際の名前で出ます）。
相手に届いたメールの招待を、相手が承諾します。

ここで選べる権限はありません。共同作業者は1種類で、読み書き、Issue（課題の記録）とプルリクエスト（Pull Request、PR。変更の合流の依頼）の作成とマージまでできます。逆に、招待、公開範囲の変更、リポジトリの削除は持ち主だけです。

受付Aに料金表を見せたいだけでも、書き込み権限ごと渡すことになります。読むだけにしたいならOrganizationに移します。

Organizationを作ってリポジトリを移す

右上のプロフィール写真から「Settings」を開きます。
サイドバーの「Access」にある「Organizations」を開きます。
「New organization」を押し、画面に沿って作ります。プランはFreeを選べます。
移すリポジトリの「Settings」の一番下、「Danger Zone」の「Transfer」を押します。
「New owner」で sample-cooking を指定します。
確認欄にリポジトリ名を入れ、「I understand, transfer this repository」を押します。

古い場所へのリンクや git push（手元の履歴を送る操作）は新しい場所へ転送されますが、混乱を避けるため手元の送り先も変えておきます。練習用のフォルダで動かした表示です。

$ git remote -v
origin	https://github.com/YOUR-USERNAME/website.git (fetch)
origin	https://github.com/YOUR-USERNAME/website.git (push)
$ git remote set-url origin https://github.com/sample-cooking/website.git
$ git remote -v
origin	https://github.com/sample-cooking/website.git (fetch)
origin	https://github.com/sample-cooking/website.git (push)

移す前の持ち主は、移したあと共同作業者として残ります。不要なら外します。

Organizationのロール

リポジトリごとに、人へロールを渡します。公式の説明を短くしたのが次の表です。料金表では「Role-based access control」はFreeを含む全プランに入っています。

操作	Read	Triage	Write	Maintain	Admin
読む、Issueを作る	可	可	可	可	可
Issueやプルリクエストの整理	不可	可	可	可	可
ブランチに書き込む	不可	不可	可	可	可
プルリクエストをマージする	不可	不可	可	可	可
保護されたブランチに書き込む	不可	不可	不可	可	可
リポジトリの一般設定	不可	不可	不可	不可	可
Webhookやデプロイキーの管理	不可	不可	不可	不可	可
公開範囲の変更、削除、移管	不可	不可	不可	不可	可

「保護されたブランチに書き込む」は、ルールセット（枝を守るもう1つの設定）で守った枝には当てはまりません。

ブランチは変更を分けて作る枝、マージは枝を合流させる操作です。Webhookは外部への自動の通知、デプロイキーはサーバーが使う鍵のことです。サンプル料理教室の割り当てはこうなります。

人	組織での立場	`website`	`reservation-mail`
代表	オーナー	全部できる	全部できる
受付A	メンバー	Read	なし
外注エンジニアB	外部の共同作業者	Write	必要になった仕事の間だけ Write

組織のメンバー全員に共通で渡す権限は、「Settings」の「Member privileges」にある「Base permissions」で決まります。ここが高いと、全員がすべてのリポジトリに届きます。外部の共同作業者には適用されません。

外注に渡すときの最小権限

外注エンジニアBをメンバーにする必要はありません。外部の共同作業者（Outside collaborator）は、組織には入らず、指定したリポジトリにだけ入れる立場です。公式も、コンサルタントや期間限定の人を想定しています。

対象のリポジトリの「Settings」を開きます。
サイドバーの「Access」にある「Collaborators & teams」を開きます。
「Manage access」の横の「Add people」を押します。
相手を選びます。
「Choose a role」で Write を選び、「Add NAME to REPOSITORY」を押します。

渡す前に3つ考えます。どのリポジトリか、読むだけで足りないか、いつ外すか。頼む内容に対して広すぎないかを見ます。依頼書に終了予定日を書いて、その日に外す、まで決めておくと忘れません。

TeamやEnterprise Cloudでは、外部の共同作業者を非公開リポジトリに入れると有料の席を1つ使います。Freeでは席の課金はありません。

Freeの非公開では保護ブランチが使えないので、Writeの人は main（本流のブランチ）に直接書き込めます。変更は枝で作ってプルリクエストにする、を約束で決めるか、仕組みで止めたければTeamにします。

仕事が終わったら外す、退職時にすること

外すのは簡単です。「Collaborators & teams」で相手の行の「Remove」を押すだけです。メンバーを組織ごと外すなら、次の順です。

右上のプロフィール写真から「Organizations」を開き、組織を選びます。
組織名の下の「People」タブを開きます。
外す人にチェックを入れます。
上の「X members selected…」から「Remove from organization」を選びます。
一覧を確かめて「Remove members」を押します。

外すと、その人の非公開フォーク（GitHub上の複製）へのアクセスもなくなります。ただし手元のクローン（リポジトリの複製）は残ります。GitHubからは消せません。だから、外すだけで終わらせず、次も一緒に片づけます。

やること	理由
その人が知っていた鍵を作り直す	クローンの中や本人の記憶に残っている
オーナーが2人以上いるか確かめる	辞める人が唯一のオーナーだと管理者がいなくなる
請求先の情報を更新する	組織から抜けても登録情報は消えない
その人のfine-grainedトークンを取り消す	組織の「Personal access tokens」の「Active tokens」で見られる
その人が入れた連携アプリを見直す	GitHub Appsは入れた人が抜けても動き続ける

なお、classicのトークンはこの画面には出ません。組織で制限していなければ、期限まで組織のものに届きます。抜けた人は組織の権限を失うので届かなくなりますが、見えないものがあることは覚えておきます。

外された人のデータは3か月保存され、その間に招き直すと戻せます。

2段階認証を設定する

2段階認証（2FA）は、パスワードの他にもう1つ確認を求める仕組みです。GitHubは2023年3月から、コードを投稿する人にこれを求めています。全員が同じ時期ではなく、活動をもとに選ばれた人に通知メールが届きます。届いてから45日が登録期間で、そのあとに7日の猶予があり、過ぎると有効にするまで入れなくなります。通知が届いていなくても設定します。

GitHubが主な方法に勧めているのは認証アプリです。SMSは傍受されやすく、バックアップにはセキュリティキーを勧めています。

スマートフォンに認証アプリを入れます。
右上のプロフィール写真から「Settings」を開きます。
サイドバーの「Access」にある「Password and authentication」を開きます。
「Enable two-factor authentication」を押します。
「Scan the QR code」のQRコードをアプリで読みます。
アプリに出たコードを「Verify the code from the app」の欄に入れます。
「Save your recovery codes」で「Download」を押して保存します。
「I have saved my recovery codes」を押すと有効になります。

パスキーはそのあとに足します。パスキーは指紋や顔で入れる方法で、パスワードと2段階認証を1回で済ませられます。ただし、最初の2段階認証の代わりにはなりません。

同じ「Password and authentication」の「Passkeys」にある「Add a passkey」を押します。
求められたら認証します。
「Add passkey」を押します。
端末の案内に従って登録し、「Done」を押します。

リカバリーコードは、スマートフォンをなくしたときの入口です。16個あり、1個は1回しか使えません。公式はパスワード管理ツールでの保管を勧め、共有しないよう求めています。新しく作り直すと、古いコードは全部無効になります。認証アプリの他にパスキーやセキュリティキーも足して、入口を2つ以上にしておきます。

組織で全員に求めるなら、組織の「Settings」から「Authentication security」を開き、「Require two-factor authentication for everyone in your organization」を選びます。未設定のメンバーは設定するまで組織のものに入れず、未設定の外部の共同作業者は組織から外されます。押す前に、外注エンジニアBに設定を頼みます。

トークンは期限付きのfine-grainedを選ぶ

トークン（Personal access token）は、パスワードの代わりにプログラムやツールが使う文字列です。2種類あります。

見るところ	fine-grained	classic
届く範囲	1つのユーザーか組織のもの	自分が入っている全部
リポジトリの指定	選べる	選べない
権限	細かく選べる	広いスコープ（権限のまとまり）で選ぶ
使えない場面	一部の機能に非対応	なし（ただし公式は安全性が低いと明記）

公式は fine-grained を勧めています。作り方です。

右上のプロフィール写真から「Settings」、「Developer settings」と開きます。
「Personal access tokens」の下の「Fine-grained tokens」を開きます。
「Generate new token」を押します。
「Token name」に用途、「Expiration」に期限を入れます。
「Resource owner」で sample-cooking を選びます。
「Repository access」で対象のリポジトリだけを選びます。
「Permissions」で必要な権限だけを付けます。
「Generate token」を押します。

出来上がった文字列 xxxxxxxx はパスワードと同じ扱いです。組織で承認を求める設定なら、承認されるまで公開のものしか読めません。1年使わないと自動で消えます。コードやチャットには書かず、要らなくなったら消します。

連携アプリの権限を見る

外部のツールやAIにリポジトリを渡すとき、見るのはここです。「Settings」の「Integrations」にある「Applications」に、3つのタブがあります。

タブ	何が見えるか	できること
Installed GitHub Apps	入れたアプリ	「Configure」で権限と範囲を見る、「Suspend」「Uninstall」
Authorized GitHub Apps	自分の名前で動くのを許したアプリ	「Revoke」
Authorized OAuth Apps	許可した古い形式のアプリ	「Revoke」

公式は、一般にGitHub AppsをOAuth Appsより勧めています。GitHub Appsは入れるときにリポジトリを選べますが、OAuth Appsは許可した人が届く範囲全部に届きます。OAuth Appsでは、ソースコードを読むだけに絞ることもできません。

入れるときに確かめるのは次の3つです。

「Repository access」が「All repositories」になっていないか。「Only select repositories」で website だけを選びます。
「Permissions」に、頼む仕事に要らない書き込みがないか。
誰が作ったアプリか、使い終わったらいつ外すか。

Organizationの場合は、組織の「Settings」の「Third-party Access」にある「GitHub Apps」で見ます。新しく作った組織では、OAuth Appsは既定で制限されていて、オーナーの承認が要ります。

なお、許可の取り消しは許可した本人しかできません。オーナーが止めるなら、アプリを「Uninstall」します。

非公開から公開へ変えるとき

「Settings」の「Danger Zone」にある「Change visibility」で変えられます。押す前に、公式が挙げる影響を読みます。

誰でもコードを見られて、フォークできるようになります
GitHub Actions（自動で動かす仕組み）の実行履歴とログも公開されます
すべてのpushのルールセットが無効になります
変更がアクティビティとして公開されます
スターとウォッチャーは消えます

公開されるのは今のファイルだけではなく、履歴全部です。昔のコミットに .env や名簿があれば、それごと出ます。公開の前に鍵や個人情報を履歴から探し、見つかれば止めて作り直します。一度公開したものは、誰かがクローンしていれば戻せません。

実際に多いのは、GitHub Pages（リポジトリからサイトを公開する機能）を無料で使うために公開したい場面です。個人のFreeのPagesは公開リポジトリだけです。その場合、website をそのまま公開せず、公開していいものだけを新しいリポジトリに入れ直す方が安全です。

できないことと、その代わり

できないこと	その代わり
個人の非公開リポジトリで読むだけの招待	Organizationに移して Read を渡す
外した人の手元のクローンを消す	鍵を作り直し、契約で削除を取り決める
Freeの非公開で `main` への直接の変更を止める	約束で運用する。止めるならTeam
リポジトリの中でフォルダごとに見せ分ける	リポジトリを分ける
他の人の許可した連携アプリを取り消す	組織の設定で「Uninstall」する

GitHubの権限は基本的にリポジトリ単位です。見せたくないものが混ざるなら、リポジトリを分けるか、別の場所に置きます。社内で共有する名簿や資料は、Googleドライブのようにファイルごとに権限を決められる道具の方が向いています。

よく詰まるところ

症状	原因	直し方
「Settings」が見えない	「More」の中にある、または管理権限がない	「More」を開く。なければ持ち主かオーナーに頼む
招待しようとして読むだけが選べない	個人の非公開リポジトリは共同作業者1種類	Organizationに移す
2段階認証を必須にしたら外注が入れなくなった	未設定の外部の共同作業者は外される	本人に設定してもらい招き直す。3か月以内なら権限を戻せる
トークンで組織のリポジトリが読めない	承認待ち、または選んだ範囲の外	オーナーが承認する。「Repository access」を見直す
AIのツールから別のリポジトリが見える	「All repositories」で入れている	「Configure」で「Only select repositories」に変える
アプリを絞ったのに新しいリポジトリに届く	そのアプリが作ったリポジトリには自動で届く	「Configure」で見直す
古いURLに `git push` してしまう	転送されるので気づきにくい	`git remote set-url` で直す

次に読む

アカウントがまだなら「GitHubの使い方：アカウント作成から最初のリポジトリまで」から始めます。鍵やトークンが漏れたら「APIキーやパスワードをGitHubにpushしてしまったときの対応」です。Writeを渡した人の変更を確かめる流れは「プルリクエストとは：作り方・レビュー・マージの流れ」に、プランごとの違いは「GitHubの料金：Free・Team・Enterpriseと無料でできる範囲」にまとめています。

あわせて読む

画面に出てくる言葉の意味はGit用語集で引けます。