GitHub PAT（Personal Access Token）とは？作成手順・fine-grainedとclassicの違い・有効期限と組織ポリシー【2026年版】

GitHub PAT（Personal Access Token＝個人用アクセストークン）とは、GitHubのAPIアクセスやHTTPSでのGit操作（clone・push・pull）で、パスワードの代わりに使う認証用トークンです。GitHubはGit操作でのパスワード認証を廃止しているため、HTTPSでリポジトリを操作するにはPATかSSH鍵、あるいはGitHub CLIによる認証が必要になります。PATには新しいfine-grained（細粒度）と従来のclassicの2種類があり、GitHubが利用を推奨しているのはfine-grainedです。この記事では、PATの作成方法（Settings > Developer settings）、classicとfine-grainedの違い、スコープ・権限、有効期限と組織のポリシー、HTTPS認証とREST APIでの使い方、GITHUB_TOKENやGitHub Appとの使い分け、認証エラーの切り分け、漏洩時の対処までを、2026年9月時点のGitHub公式ドキュメントに沿って解説します。

まとめ：GitHub PATの要点と2026年9月時点で押さえる変更点

先に結論を整理します。詳細は各セクションで確かめてください。

• PATとは：ユーザーアカウントに紐づく認証トークン。HTTPSでのGit操作やGitHub APIの呼び出しで、パスワードの代わりに使います。
• 2種類：fine-grained PAT（推奨・リポジトリ単位＋機能ごとの権限）と classic PAT（広いスコープ）。原則はfine-grainedを選び、未対応の操作だけclassicで補います。
• 作成場所：Settings > Developer settings > Personal access tokens から発行します。
• 有効期限：fine-grainedも2024年10月から無期限を選べるようになりました。ただし組織・Enterpriseには既定で366日の上限ポリシーがあり、組織のリソースに使うトークンは期限付きになります。
• 自動化には別の手段：Actionsの中ならGITHUB_TOKEN、組織の常設自動化ならGitHub Appを選び、PATは個人作業に限ります。
• 漏洩したら：すぐに該当トークンをrevoke（無効化）して再発行します。公開リポジトリではsecret scanningが無料で自動実行されます。

GitHub PAT（個人用アクセストークン）とは何か：用途と仕組みの基本

PATは「Personal Access Token」の略で、日本語では個人用アクセストークンと呼びます。GitHubのユーザーアカウントに紐づき、そのユーザーの権限の範囲でGitHub APIやGit操作を認証するための文字列です。GitHub公式の認証の概要では、Gitのパスワード認証はより安全な方式に置き換えられて廃止済みと明記されています。そのためHTTPS経由でgit pushやgit clone（プライベートリポジトリ）を行う際は、パスワード入力欄にPATを入力する形で認証します。

用途は、コマンドラインやスクリプトからHTTPSでGitリポジトリを操作する場合と、GitHub REST API／GraphQL APIをトークン付きで呼び出す場合の2つです。ユーザー権限をそのまま代行するため、スコープの広いPATが漏れると影響範囲が大きくなります。権限と有効期限を絞る運用が前提です。

トークンは接頭辞で種類を見分けられます。classic PATはghp_、fine-grained PATはgithub_pat_、GitHub Appのインストールトークンはghs_で始まります（同じ公式ページのトークン形式一覧による）。

PATの作成方法：Developer settingsでトークンを発行する手順

PATはGitHubのWeb UIから発行します。手順はGitHub Docs「Managing your personal access tokens」に沿うと次のとおりです（2026年9月時点。UI名称は変わることがあるため、最終的な画面名は公式ドキュメントで確認してください）。

1. アカウントのメールアドレスが確認済みであることを確かめます（未確認だとトークンを発行できません）。
2. 右上のアバターをクリックしてSettingsを開き、左サイドバー最下部のDeveloper settingsを選びます。
3. Personal access tokensを開き、Fine-grained tokensかTokens (classic)のどちらかを選択します。原則はfine-grainedです。
4. Generate new tokenをクリックし、トークン名（fine-grainedは40文字まで）・有効期限・説明を入力します。
5. fine-grainedではResource owner（自分か組織）を選び、Repository accessで対象リポジトリを限定したうえで、必要なPermissionsだけを付けます。classicではrepoなどのscopeにチェックを入れます。
6. Generate tokenを押すとトークン文字列が表示されます。この画面を離れると再表示できないため、その場でパスワードマネージャー等に保管します。紛失した場合は再発行（Regenerate）が必要です。

fine-grained PATは1ユーザーあたり50本が上限で、それ以上必要ならGitHub Appの利用を検討するよう公式ドキュメントは案内しています。

classic PATとfine-grained PATの違い：権限と未対応操作

GitHubのPATには、新しいfine-grained PATと従来のclassic PATの2種類があります。GitHubの推奨は、可能な限りfine-grainedを使うことです。両者は権限の与え方と対象範囲が大きく異なります。

原則はfine-grainedを選び、リポジトリと権限を必要最小限に絞ります。ただしfine-grainedはすべての操作に対応しているわけではありません。2026年9月時点の公式ドキュメントでは、fine-grainedで扱えないものとして次が挙がっています。

• 自分がメンバーでない公開リポジトリへのコントリビュート
• 外部コラボレーター（outside collaborator）やリポジトリコラボレーターとしてのアクセス
• 1本のトークンで複数の組織にまたがるアクセス
• GitHub Packagesへのアクセス
• Checks APIの呼び出し
• ユーザーアカウントが所有するProjectsへのアクセス

GitHub Packagesからのイメージ取得や、外部コラボレーター権限での客先リポジトリ操作ではclassicが必要です。その場合だけclassicを期限付き・最小scopeで発行します。

PATのスコープ・権限の考え方：最小権限で発行するための具体的な選び方

スコープ（classic）／permission（fine-grained）は、そのトークンで何ができるかを定義します。設計の原則は「最小権限」です。便利だからと広い権限を付けると、トークンが漏れたときの被害が一気に広がります。

classicのrepoはプライベートを含む全リポジトリのフルアクセスを与え、admin:orgは組織管理まで及びます。常用トークンには付けないでください。fine-grainedなら対象リポジトリを選び、機能ごとに読み取り／書き込みを選べます。用途別の目安は次のとおりです。

各REST APIエンドポイントがfine-grainedで使えるか、どの権限が要るかは、REST APIの認証ドキュメントのとおり各エンドポイントのリファレンスに載っています。迷ったらRead-onlyで作り、403で失敗した操作の権限だけを足してください。外部サービスに渡すPATの実例は、Amazon SageMakerとGitHubの連携手順｜3経路の設定とPAT権限や、MCPクライアントからPATで接続するGitHub Remote MCP Serverとは？ローカル版との違い・接続手順・OAuth/PAT認証を解説でも扱っています。

PATの有効期限と更新：無期限設定の可否とローテーションの進め方

有効期限は漏洩時の被害期間を区切る仕組みです。旧来はfine-grained PATに無期限を設定できませんでしたが、2024年10月18日のGitHub Changelogで、個人用途のfine-grainedでも無期限を選べるようになりました。ただし組織・Enterpriseには既定で366日の上限ポリシーがあり、組織のリポジトリに使うトークンは管理者が緩めない限り366日以内になります。

classic PATは期限の既定値として30日が提示され、任意の日付か無期限を選べます。無期限トークンは漏れたときに失効しないため、業務では明確な期限を付けるべきです。なお公式ドキュメントによれば、1年間使われていないPATはGitHubが自動的に削除します。

期限切れが近づくとメール通知が届きます。CIや外部サービスに登録したトークンは、新トークンを登録して動作を確かめてから旧トークンをrevokeする順序なら、処理を止めずに切り替えられます。一時作業用のトークンは作業を終えた後に削除してください。

組織側のPATポリシー：承認制・最大有効期限・classic制限を設定する方法

組織のオーナーは、メンバーが発行したPATを組織のリソースにどこまで使わせるかを制御できます。組織のPATポリシー設定の公式ドキュメントによると、設定箇所は組織の Settings > Personal access tokens > Settings で、fine-grainedとclassicのタブごとに次の3点を決められます。

• アクセスの可否：既定ではfine-grainedとclassicの両方が組織のリソースにアクセスできます。classicを禁止すれば、scopeの広いトークン経由の操作を止められます。
• 承認制：fine-grainedは既定で「組織オーナーの承認が必要」です（オーナー自身が作ったトークンは承認不要）。承認待ちの間、トークンは組織のリポジトリを操作できません。
• 最大有効期限：fine-grainedは既定で366日以内。classicには既定の上限はありませんが、1〜366日の範囲で上限を課せます。

どの設定でも、組織内の公開リソースへの読み取りはポリシーの対象外です。外部協力者が混在する現場では、classicを禁止してfine-grainedの承認制に寄せると、誰のトークンが何に触れるかを一覧で追えます。SAML SSOを使う組織でのPAT・SSH鍵の認可の落とし穴はGitHub SSOの設定手順｜SAML連携・PAT/SSH認可の落とし穴で解説しています。

HTTPSでのGit認証とREST APIでPATを使う方法：コマンド例つき

HTTPSでGit操作を行う場合、git cloneやgit pushの認証情報入力で、ユーザー名にGitHubのユーザー名、パスワード欄にPATを入力します。毎回の入力を省く方法は、Gitの資格情報ヘルパー（credential helper）への保存です。公式の資格情報キャッシュの手順では、GitHub CLIかGit Credential Manager（Windows向けGit 2.29以降に同梱）を使う方法が案内されています。PATを手で扱わずに済ませたいなら、ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧のgh auth loginが手軽です。

# GitHub CLIでログインし、gitの資格情報ヘルパーとしてghを登録する
gh auth login
gh auth setup-git

# PATを環境変数から渡してghを使う場合（CIや一時作業向け）
export GH_TOKEN="<YOUR_PAT>"
gh repo view OWNER/REPO

git config --global credential.helper storeはトークンを平文で保存するため、共有端末では避けてください。

GitHub APIを呼び出す場合は、HTTPリクエストのAuthorizationヘッダーにトークンを付与します。公式ドキュメントではAuthorization: BearerとAuthorization: tokenのどちらも受け付けるとされており、APIのバージョンをX-GitHub-Api-Versionヘッダーで固定する書き方が示されています（2026年9月時点の例は2026-03-10）。

# 認証ユーザーの情報を取得する
curl --request GET \
  --url "https://api.github.com/user" \
  --header "Authorization: Bearer $GH_TOKEN" \
  --header "X-GitHub-Api-Version: 2026-03-10"

# 残りのレート上限を確認する（rate_limitの呼び出し自体は消費しない）
curl -s -H "Authorization: Bearer $GH_TOKEN" https://api.github.com/rate_limit

REST APIのレート制限は、未認証だと1時間60リクエスト、PATで認証すると1時間5,000リクエストです。トークンはコードに直書きせず環境変数やシークレットストアから読み込み、ログにも出力しません。

PATとSSH鍵・GitHub Appsトークンの違い：認証手段ごとの主体と用途

GitHubの認証手段はPATだけではありません。用途によって、SSH鍵やGitHub Appsトークンと使い分けます。

個人がローカルでGit操作やAPIを少し叩くだけならPATで十分です。CI/CDやBotのように安定して自動化したい場合は、個人アカウントに依存しないGitHub Appsトークンが向いています。PATで組んだ自動化は、発行者の退職・異動でトークンごと止まるからです。

PATを使うか見送るかの判断基準：GITHUB_TOKENやOIDCとの使い分け

「PATを発行してSecretsに入れる」構成は動きますが、長期運用では負債になります。次の順で上から当てはまるものを選びます。

1. Actionsの中で同じリポジトリを操作するだけ：組み込みのGITHUB_TOKENを使い、PATは発行しません。権限はpermissionsキーで絞ります（詳細はGitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計）。GITHUB_TOKENのAPI上限はリポジトリあたり1時間1,000リクエストです。
2. AWSなどのクラウドへデプロイする：クラウド側の長期鍵もPATも置かず、OIDCで一時認証情報を受け取ります。Secretsの置き場所とOIDCへの移行判断はGitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断にまとめています。
3. 複数リポジトリや組織をまたいで常設で自動化する：GitHub Appを作り、インストールトークンを都度発行します。
4. 上記で賄えない、または個人の端末作業：ここで初めてPATを選びます。fine-grainedで対象リポジトリを限定し、期限を付けます。

PATを採用してよいのは、個人の作業、検証用の短期スクリプト、小さな連携に限られます。本番のデプロイ経路・複数人が依存するBot・担当者名義の自動化では、PATの採用を見送るべきです。別のプライベートリポジトリを読むなど、やむを得ずワークフローでPATを使う場合は、読み取り専用のfine-grainedをSecretsに入れて渡します。

# .github/workflows/build.yml の一部
- uses: actions/checkout@v5
  with:
    repository: OWNER/shared-config
    token: ${{ secrets.SHARED_CONFIG_PAT }}
    path: shared-config

CI/CDの認証設計ごと見直したい、PAT依存のワークフローをGitHub AppやOIDCへ移したいといった場合は、一創のDevOps・CI/CD導入支援で、現状の棚卸しから移行まで対応しています。

PATの認証エラーを切り分ける：401・403・承認待ちでよくある原因

つまずきやすいのは次の4パターンです。

• 「Support for password authentication was removed」と表示される：パスワード欄にGitHubのログインパスワードを入れています。PATを入力し直し、資格情報ヘルパーに古いパスワードが残っていれば削除します。
• 401 Bad credentials：期限切れ、revoke済み、コピー時の欠けが主な原因です。トークン一覧で期限を確認します。
• 403や「Resource not accessible by personal access token」：fine-grainedの権限不足か、Repository accessに対象リポジトリが含まれていません。前述の表を見て権限を足します。
• 組織のリポジトリだけ失敗する：fine-grainedが組織オーナーの承認待ちか、組織のポリシーでclassicが禁止されている、あるいはSAML SSOの認可が済んでいない可能性があります。

PATが漏洩したときの対処とリスク管理：revokeと再発行の手順

広いスコープを持つclassic PATが公開リポジトリに載ると、不正アクセスやコード改ざんにつながります。漏洩に気づいたら、まず該当トークンをすぐにrevoke（無効化）し、新しいトークンを再発行してください。利用中のCIやスクリプトも新トークンへ更新し、組織の監査ログで漏洩期間中の操作を確認します。

GitHubのsecret scanningは公開リポジトリで無料・自動で実行され、パートナー企業のトークンを検出すると提供元へ通知します。プライベートリポジトリで使うには有償のSecret Protectionが必要です（料金はGitHub Advanced Securityとは｜Secret Protection月19ドル・Code Security月30ドルの料金と課金の数え方）。コミット前の混入防止には、ghp_やgithub_pat_で始まる文字列をgitleaksとは？シークレット検出の仕組みとv8.30時点の使い方・設定のようなツールでローカル検査できます。実際の事故例はマネーフォワードのGitHub不正アクセス事案の全容と利用者がとるべき対応を参照してください。

GitHub PATについてよくある質問（FAQ）：作成・種類・期限・push

GitHubのPATとは何ですか？

PAT（Personal Access Token＝個人用アクセストークン）は、GitHubのユーザーアカウントに紐づく認証トークンです。Git操作のパスワード認証は廃止済みで、HTTPSでのclone・pushやAPI呼び出しではパスワードの代わりにPATを使います。

GitHubのPATはどこで作成（設定）しますか？

右上のアバター > Settings > 左サイドバー最下部の Developer settings > Personal access tokens から作成します。Generate new token で名前・期限・対象リポジトリ・権限を設定し、一度しか表示されないトークンをその場で保管してください。

classic PATとfine-grained PATはどちらを使うべきですか？

原則はfine-grained PATです。リポジトリ単位かつ機能ごとに権限を絞れ、組織側で承認制にもできます。ただしGitHub Packages・Checks API・複数組織へのアクセス・外部コラボレーターとしての操作などはfine-grainedが未対応のため、その場合だけclassicを期限付き・最小スコープで使います。

fine-grained PATを無期限にすることはできますか？

2024年10月以降、個人のリソースに使うfine-grained PATは無期限を選べます。組織のリポジトリ向けは既定の上限ポリシーにより366日以内です。業務用途では期限を付けてローテーションしてください。

PATを使ってHTTPSでgit pushするにはどうすればよいですか？

認証を求められたら、ユーザー名にGitHubのユーザー名、パスワード欄にPATを入力します。fine-grainedならContentsのRead and write権限が必要です。毎回の入力を省くにはGit Credential Managerか、gh auth loginとgh auth setup-gitでGitHub CLIを資格情報ヘルパーとして登録します。

関連記事

• ghコマンド（GitHub CLI）とは？インストール方法と使い方・コマンド一覧【v2.101対応】
• GitHub SSOの設定手順｜SAML連携・PAT/SSH認可の落とし穴
• GitHub Actionsのpermissions｜GITHUB_TOKENの既定権限と最小権限の設計
• GitHub ActionsのSecrets管理｜置き場所の選定と漏えい経路・OIDC移行の判断
• gitleaksとは？シークレット検出の仕組みとv8.30時点の使い方・設定
• マネーフォワードの銀行連携はいつ復旧した？GitHub不正アクセス事案の全容と利用者がとるべき対応