外部エンジニアのGitHub権限を最小化する設計｜渡してよい権限の線引きと退場フロー

外部のエンジニアにソースコードを触ってもらわないと、開発はもう前に進みません。人手が足りず、業務委託やフリーランスのエンジニアをアサインする——その判断自体はごく自然なものです。ところが、いざ GitHub の Organization に招待する直前になって、ふと手が止まる方は少なくありません。「社員には全員 Owner や Write を配ってきたけれど、外部の人にも同じ感覚で渡してよいのだろうか」と。

不安の正体は、たいてい「線引きの基準がない」ことにあります。Owner 権限を渡すのはさすがに怖い。かといって、権限を絞りすぎて開発が止まるのも困る。結局「これくらいでいいか」と、えいやで広めの権限を渡してしまう——そして渡したことを忘れたまま、契約が終わってもアクセス権が残り続ける。多くの中小企業・スタートアップで起きているのは、この「なんとなく」の積み重ねです。

GitHub には、外部の人に渡す権限を細かく制御する仕組みがひととおり揃っています。Member と Outside Collaborator の使い分け、リポジトリ単位での招待、5段階のリポジトリロール、ブランチ保護、Fine-grained PAT。これらを「最小権限の原則」に沿って組み合わせれば、開発を止めずに漏洩・事故のリスクを抑えることは十分に可能です。問題は、それらをどう組み合わせれば自社のケースに当てはまるのか、という設計の部分が属人化していることにあります。

本記事では、外部エンジニアの GitHub 権限を最小化する設計を、招待から退場（オフボーディング）までのライフサイクル全体で整理します。「何をどこまで許可するか」をロールと対象範囲のマトリクスで即断できる形に落とし込み、次に外部の人が増えても同じルールで運用できる再現性を持ち帰っていただくことを目指します。

外部エンジニアにGitHub権限を渡すとき、なぜ「最小化」が必要なのか

最小権限の設計に入る前に、まず「広めに渡すこと」の何が危険なのかを具体的に押さえておきましょう。漠然とした不安のままでは、適切な線引きはできません。リスクを具体的なシナリオに変換することが、設計の出発点になります。

外部エンジニアに過剰な権限を渡すと何が起きるか

外部エンジニアに必要以上の権限を渡したときに生じるリスクは、大きく3つに整理できます。

1つ目は、トークン流出からの被害拡大です。 GitHub のアクセストークンが何らかの形で外部に流出すると、そのトークンが持つ権限の範囲がそのまま攻撃者の侵入経路になります。実際に、流出したトークンを起点に CI/CD パイプラインが悪用され、本番環境への侵入や API の改ざんにまでつながったインシデントが報告されています（GitHub Token流出から始まったAPI改ざんとその対策）。このとき、トークンに「全リポジトリへの Write」や「Admin」が紐づいていれば被害は組織全体に広がりますが、権限が1リポジトリの Write に限定されていれば被害もそこで止まります。権限の広さは、そのまま事故が起きたときの被害の大きさになります。

2つ目は、意図しない改ざん・破壊です。 悪意がなくても、Admin 権限を持っていればブランチ保護ルールを無効化できますし、Maintain 権限があればリポジトリの設定を変更できます。外部の方が「よかれと思って」設定を触った結果、本番デプロイのフローが崩れる、といった事故は珍しくありません。

3つ目は、退場後のアクセス放置です。 契約が終了したにもかかわらず、招待時に付与したアクセス権を削除し忘れるケースです。これが最も見落とされやすく、かつ厄介です。アクセス権が残っている限り、その人は（あるいはその人のアカウントが乗っ取られた場合は第三者が）いつでもソースコードにアクセスできます。「契約は終わったのにリポジトリが見える状態」は、情報漏洩の温床そのものです。

「最小権限の原則」をGitHubに当てはめるとどうなるか

これら3つのリスクに共通して効く考え方が、最小権限の原則（least privilege）です。これは「ある人やシステムに付与する権限は、その業務を遂行するために必要な最小限にとどめる」という、情報セキュリティの基本原則です。

GitHub に当てはめると、次の3つの問いに分解できます。

• 対象範囲はどこまでか：Organization 全体か、それとも特定のリポジトリだけでよいか
• 操作の権限はどこまでか：コードを読むだけか、書き込みも必要か、設定変更まで必要か
• 期間はいつまでか：その権限はいつまで必要で、いつ失効させるか

「外部エンジニアだから一律に厳しくする」のではなく、「その人が担当する業務に必要な範囲・権限・期間はどこまでか」を起点に考える。これが設計の軸になります。逆に言えば、業務に不要な権限が1つでも紛れ込んでいたら、それは見直しの対象です。次の章からは、この3つの問いに答えるための GitHub の仕組みを、外部委託の視点で整理していきます。

GitHubの権限モデルを「外部委託の視点」で整理する

GitHub の権限モデルは多層的で、すべてを網羅しようとすると用語の海に飲まれてしまいます。ここでは「外部の人をどの単位で、どのロールで招くか」という意思決定に必要な要素だけに絞って地図を描きます。

Member と Outside Collaborator の違い（外部委託は原則 Outside Collaborator）

外部委託で最初に押さえるべき分岐が、Member（組織メンバー）として招くか、Outside Collaborator（外部コラボレーター）として招くかです。この選択が、外部委託では決定的に重要になります。

GitHub 公式の定義では、Outside Collaborator は「組織の1つ以上のリポジトリにアクセスできるが、組織のメンバーではない人」とされ、コンサルタントや一時的な協力者がこれに該当します（Managing outside collaborators - GitHub Docs）。両者の違いを整理すると次のとおりです。

ポイントは、Outside Collaborator は「明示的に招待されたリポジトリにしかアクセスできない」という点です。Member は組織のデフォルト権限を通じて、意図せず多くのリポジトリが見えてしまう可能性があります。一方 Outside Collaborator なら、招待していないリポジトリは原則として存在すら見えません。

したがって、外部委託のエンジニアは原則 Outside Collaborator として招くのが最小権限の基本形になります。Member として招くのは、長期的・継続的に組織へ関与してもらい、複数リポジトリやチーム運用に深く入ってもらう必要がある場合に限定するのが安全です。

リポジトリロール5段階の権限範囲（Read/Triage/Write/Maintain/Admin）

招く単位が決まったら、次は「そのリポジトリで何ができるか」を決めるリポジトリロールです。GitHub のリポジトリロールは、権限の弱い順に5段階あります（Repository roles for an organization - GitHub Docs）。

外部委託で覚えておきたいのは、多くの開発業務は Write で完結するということです。コードを書き、ブランチを切り、PR を出してマージする——実装担当として必要な操作は Write の範囲に収まります。Maintain や Admin はリポジトリの設定そのものに手を入れられる権限であり、外部の方に渡す必然性はほとんどありません。

Organizationのデフォルト権限を none にしておく意味

最後に、組織全体の安全装置として Organization のデフォルトリポジトリ権限（base permission） を確認しておきましょう。

これは「組織のメンバーが、明示的に権限を与えられていないリポジトリに対して持つ最低限の権限」を決める設定で、none・read・write・admin の中から選べます（Setting base permissions for an organization - GitHub Docs）。Read に設定されていると、メンバーは組織内のすべてのリポジトリを（少なくとも）閲覧できてしまいます。これを none（なし）に設定しておくと、メンバーは明示的に招待されたリポジトリにしかアクセスできなくなります。

このデフォルト権限 none は、厳格な機密管理が求められる組織環境で特に有効です。外部委託の文脈では、仮に外部の方を Member として招かざるを得ない場合でも、デフォルト権限が none であれば「招待されていないリポジトリは見えない」状態を担保できます。Outside Collaborator 運用とあわせて、二重の安全網として効いてきます。なお、base permission は Outside Collaborator には適用されない点には留意してください（同 GitHub Docs）。base permission を絞ったとしても、外部の方の権限は招待時に指定したリポジトリロールで個別に管理する必要があります。

外部エンジニアに渡してよい権限・渡してはいけない権限の線引き

ここからが本記事の核心です。前の章で整理した「Outside Collaborator として招く」「リポジトリロールを選ぶ」を組み合わせ、対象範囲（どのリポジトリ）×ロール（どこまで操作可）のマトリクスで、自社のケースに当てはめられる基準を作ります。

対象範囲を絞る（Organization 全体ではなくリポジトリ単位で招く）

線引きの第一歩は、対象範囲を「リポジトリ単位」まで絞ることです。

外部エンジニアに担当してもらうのは、たいてい特定のサービスや特定のリポジトリです。にもかかわらず Member として組織に招いてしまうと、デフォルト権限を通じて関係のないリポジトリまで見える状態になりかねません。前述のとおり、外部委託は原則 Outside Collaborator として、担当するリポジトリだけに招待するのが基本です。

複数のリポジトリにまたがる作業を依頼する場合でも、「念のため全部に招く」のではなく、実際に触る必要があるリポジトリだけを1つずつ招待するのが最小権限の考え方です。手間は増えますが、この手間こそが事故時の被害範囲を限定します。判断に迷ったときの原則はシンプルで——迷ったら狭い方を選ぶ。後から足すのは簡単ですが、一度広く渡した権限を「使われていないから」と削るのは、運用上なかなか実行されないからです。

ロールを絞る（多くの外部委託は Write で足り、Admin/Maintain は不要）

対象範囲を絞ったら、次はロールです。原則は明快です。

• 実装を担当してもらうなら Write：push・ブランチ作成・PR・マージができれば開発業務は回ります
• レビューや参照だけなら Read：コードを見てもらうだけなら書き込み権限は不要です
• Issue 整理を任せるなら Triage：コードに触らずプロジェクト管理を手伝ってもらう場合に適します
• Maintain / Admin は原則渡さない：リポジトリ設定やブランチ保護に手を入れられる権限を外部に渡す必然性は、ほとんどありません

特に強調したいのは、Owner（組織オーナー）・Admin（リポジトリ管理者）・全リポジトリへの一律 Write は、外部エンジニアには原則として渡さないという線引きです。Owner は組織全体を管理できる最上位権限であり、外部の方に渡すのは論外です。Admin はリポジトリのブランチ保護を無効化したり、他のコラボレーターを追加・削除したりできてしまうため、「設定変更まで外部に任せたい」という明確な理由がない限り避けるべきです。

ケース別・推奨権限マトリクス（実装のみ／PR前提開発／CI・インフラ込み）

ここまでの考え方を、典型的な3つのケースに当てはめた推奨権限マトリクスとして整理します。自社の依頼内容に近いケースを選び、そのまま当てはめてみてください。

このマトリクスの背骨にあるのは、「ほとんどのケースは Outside Collaborator × Write × 単一リポジトリで足りる」という事実です。CI やインフラに触る必要がある場合でも、Admin を渡すのではなく、必要な操作だけを Fine-grained PAT（次の章で解説します）で切り出す方が安全です。

「広めに渡しておけば作業がスムーズ」という発想を、「足りなければ後から足す」という発想に切り替える。これが、えいやで広い権限を渡してしまう状態から抜け出す具体的な一歩です。

権限を絞った上で開発を止めない仕組み

ここまで読んで、「権限を絞ると開発が回らなくなるのでは」と感じた方もいるかもしれません。実は逆で、適切な"守りの仕組み"を併用すれば、Write を渡しても本番ブランチは守れますし、最小権限のまま開発はスムーズに回ります。この章では、線引きを実行に移すための具体的な仕組みを整理します。

Writeを渡しても本番を守るブランチ保護ルール

「Write を渡すと main ブランチに直接 push されて本番が壊れるのでは」という不安には、ブランチ保護ルール（branch protection rule）が答えになります。

ブランチ保護ルールを設定すると、特定のブランチ（通常は main や release）に対して、次のような制約をかけられます。

• 直接 push の禁止：変更は必ず Pull Request を経由させる
• PR レビューの必須化：指定した人数のレビュー承認がないとマージできない
• ステータスチェックの必須化：CI（テスト・Lint 等）が通らないとマージできない

required review を有効にすると、コラボレーターは「Write 権限を持つレビュアーの承認を得た PR を通じてのみ」保護ブランチに変更を反映できます（Managing a branch protection rule - GitHub Docs）。つまり、外部エンジニアに Write を渡しても、社内レビュアーの承認なしには本番ブランチへ変更が入らない状態を作れます。Write を渡すことの不安は、ブランチ保護とレビュー必須化でほぼ解消できるわけです。

ただし、利用プランによる制約には注意が必要です。基本的なブランチ保護は、パブリックリポジトリであれば無料プランでも利用できますが、プライベートリポジトリで PR レビュー必須などの保護ルールを使うには GitHub Team 以上のプランが必要になります（About protected branches - GitHub Docs）。自社のソースコードをプライベートリポジトリで管理している場合は、外部委託の受け入れにあわせて Team プランへの移行を検討する価値があります。

トークンはFine-grained PATで最小スコープに

外部エンジニアが CI/CD や外部サービスとの連携で GitHub API を使う場合、アクセストークンが必要になります。ここで渡すべきは、権限を細かく制御できる Fine-grained personal access token（Fine-grained PAT） です。

従来の Classic PAT は、トークンに紐づくスコープが粗く、「リポジトリ全体への広い権限」を持ちがちでした。Fine-grained PAT は、対象リポジトリを限定し、操作の種類（コンテンツの読み書き、Issue の操作など）ごとに権限を絞れる点が特徴です。最小権限の原則を、トークンのレベルでも徹底できます（Fine-grained personal access tokens を使ってみた - DevelopersIO）。

運用面では、有効期限とローテーションが要点です。Fine-grained PAT には有効期限を設定でき、組織管理者はトークンの最大有効期間を1〜366日の範囲で制限できます（Setting a personal access token policy for your organization - GitHub Docs）。万一トークンが流出しても、有効期限が切れていれば被害は限定されます。

実務的には、長すぎず短すぎない有効期限を設定し、シークレットマネージャーで管理した上で、期限前にローテーション（再発行）するリマインダーを仕込んでおく運用が現実的とされています（New PAT rotation policies preview - GitHub Changelog）。既存トークンの有効期限は後から変更できないため、ローテーションは「新しいトークンを発行して差し替える」運用になる点も押さえておきましょう。

2要素認証（2FA）必須化と、無料/有料プランでできることの差

最小権限の設計と並んで効くのが、アカウントそのものの保護です。外部エンジニアのアカウントが乗っ取られれば、付与した権限がそのまま攻撃者の手に渡ってしまいます。

GitHub の組織設定では、メンバー・Outside Collaborator・課金管理者を含む全員に2要素認証（2FA）を必須化できます（Requiring two-factor authentication in your organization - GitHub Docs）。外部委託の受け入れにあたっては、この設定を有効にしておくことを強く推奨します。

注意点として、2FA を必須化した時点で 2FA を有効にしていない Outside Collaborator は組織から自動的に削除され、リポジトリへのアクセスを失います。そのため、外部の方を招く前に「2FA の有効化」を依頼の前提条件として伝えておくと、招待後の混乱を避けられます。2FA 必須化は無料プランでも利用できる組織設定であり、最小権限設計とあわせて最初に有効化しておきたい守りの一手です。

なお、外部エンジニアに渡すのは GitHub のアクセス権だけとは限りません。API キーやデータベースの認証情報を共有する場面では、別の配慮が必要になります。具体的な渡し方は外部エンジニアへのAPIキー・認証情報の安全な渡し方で整理しているので、あわせて確認しておくと安心です。

招待から退場まで——権限のライフサイクルを契約と連動させる

ここまでで「どの権限をどう渡すか」の設計は整いました。しかし、設計は付与した時点で終わりではありません。最小権限を維持し続けるには、招待→運用→退場のライフサイクル全体を仕組みに乗せる必要があります。とりわけ、契約終了時のアクセス失効を確実にすることが、漏洩リスクを断つ最後の砦になります。

招待時のチェックリスト（最小権限で招く手順）

外部エンジニアを招く際に、毎回同じ手順で実行できるチェックリストとして整理しておくと、属人化を防げます。

• 2FA を有効化してもらう（依頼の前提条件として事前に伝える）
• Outside Collaborator として招く（Member として招かない）
• 担当するリポジトリ単位で招待する（組織全体ではない）
• ロールは原則 Write（参照のみなら Read、Issue 整理なら Triage）
• Admin / Maintain は付与しない
• 対象リポジトリにブランチ保護ルール（直 push 禁止・PR レビュー必須）を設定済みにしておく
• CI・連携で API が必要なら、Classic PAT ではなく Fine-grained PAT を最小スコープ・有効期限付きで発行する

このチェックリストを招待フローに組み込めば、「えいやで広めに渡す」余地そのものがなくなります。

定期棚卸しで権限の"盛りすぎ"を防ぐ

権限は、放っておくと増えていく一方で減ることはまずありません。「一時的に Admin を渡したまま戻し忘れる」「終わったプロジェクトのリポジトリ権限が残り続ける」といった"盛りすぎ"を防ぐには、定期的な棚卸しが欠かせません。

四半期に一度など頻度を決めて、次の観点で確認します。

• 現在アクセス権を持つ Outside Collaborator の一覧と、それぞれの担当業務が今も継続しているか
• 各人のロールが、現在の業務に対して過剰になっていないか（Admin のまま放置されていないか）
• 発行済みの Fine-grained PAT に、すでに不要なものや期限切れ間近のものがないか

GitHub の組織設定からは Outside Collaborator の一覧を確認できるため、棚卸しのたびにこのリストを業務の実態と突き合わせるだけでも、不要な権限の多くは洗い出せます。

契約終了＝権限失効を必ず連動させる（退場チェックリスト・監査ログ確認）

最小権限設計の総仕上げが、契約終了と権限失効の連動です。前述のとおり、退場後のアクセス放置は最も見落とされやすく、かつ漏洩に直結するリスクです。契約終了の連絡を受けたら、その日のうちに次のチェックリストを実行する運用にしておきましょう。

• 該当者を Outside Collaborator から削除する（招待した全リポジトリで）
• その人が発行・使用していた Fine-grained PAT を失効（revoke）する
• 連携していた GitHub Apps・OAuth アプリの認可が残っていないか確認する
• 監査ログ（audit log）で、退場前後の最終操作に不審な点がないか確認する

GitHub の組織には監査ログ（audit log）が用意されており、組織からメンバーが削除されたイベントなどを、操作の種類・リポジトリ・実行者・日時といった条件で検索・確認できます（Reviewing the audit log for your organization - GitHub Docs）。退場時に監査ログを一度確認しておくことで、「削除し忘れがないか」「契約終了直前に想定外の操作がなかったか」を客観的に検証できます。

重要なのは、この退場フローを契約管理と連動させることです。契約終了日が決まったら、その日を権限失効のトリガーとしてカレンダーやタスク管理に登録しておく。人の記憶に頼るのではなく、契約のライフサイクルと権限のライフサイクルを同じ仕組みの上で動かす。これができて初めて、「設計したルールが継続的に運用される」状態になります。

自社だけで設計しきれないときの考え方

ここまで、外部エンジニアの GitHub 権限を最小化する設計を、招待から退場まで一気通貫で整理してきました。とはいえ、「自社の知識だけでセキュリティ設計を完結させるのは不安が残る」という方も多いはずです。最後に、その不安に対する選択肢を整理しておきます。

権限設計とセキュリティ要件・契約（NDA等）はセットで考える

GitHub の権限設計は、技術的な設定だけで完結するものではありません。契約面のルールと一体で設計することで、初めて実効性を持ちます。

たとえば、外部エンジニアと交わす契約のなかに、以下のような項目を含めておくと、技術的な権限制御と契約上の取り決めが補完し合います。

• 秘密保持（NDA）：ソースコードや業務上知り得た情報の取り扱い
• 再委託の禁止または制限：渡したアクセス権が、契約していない第三者に渡らないようにする
• 契約終了時のデータ・アクセスの取り扱い：手元に残したコードやトークンの破棄、アクセス権の失効への協力

「権限を Write に絞った」という技術的な対策と、「契約で再委託を禁止した」という契約上の対策は、どちらか一方では片手落ちです。両方をセットで設計することで、外部委託のリスクは大きく下がります。権限設計に着手するタイミングで、契約書の内容もあわせて見直すことをおすすめします。

権限・契約に加えて、「どの情報をどこまで共有するか」という情報共有の設計まで含めて整理しておくと、外部委託の受け入れ体制はさらに堅牢になります。体制づくりの全体像は外部エンジニアへの情報共有体制を設計する方法で詳しく解説しています。

発注先・専門家に任せる範囲の決め方

社内にセキュリティ設計の専門知識が十分にない場合、無理にすべてを内製で抱え込む必要はありません。「どこまでを自社でやり、どこからを外部に任せるか」を切り分けるのも、立派な意思決定です。

判断の目安として、次のように整理できます。

• 自社で持つべきもの：Organization の Owner 権限、権限付与・失効の最終判断、契約の締結。ここは外部に委ねるべきではありません
• 外部に任せられるもの：個別の実装、CI/CD やインフラの構成、そしてセキュリティ要件の設計支援そのもの

特に、外部に開発を依頼する際は「セキュリティ設計込みで依頼する」という発注の仕方が有効です。権限設計やブランチ保護、トークン管理といった運用ルールの整備を、開発委託の範囲に含めて相談すれば、自社にノウハウがなくても適切な体制を組めます。発注先を選ぶ際には、こうしたセキュリティ面の設計まで提案してくれるかどうかを、判断材料の1つに加えるとよいでしょう。

外部エンジニアの受け入れは、人手不足を補う有効な手段である一方、権限設計という見えにくいリスクが伴います。本記事で整理した「Outside Collaborator として、リポジトリ単位で、Write を基本に招く」「ブランチ保護と Fine-grained PAT で守る」「契約終了と権限失効を連動させる」という設計ルールを、自社の招待フロー・退場フローに落とし込んでいただければ、次に外部の方が増えても同じ基準で安心して受け入れられるはずです。線引きの基準を持つことが、開発を止めずにリスクを抑える第一歩になります。