GitHub PAT（Personal Access Token）とは？作成方法・classic／fine-grainedの違い・スコープ・有効期限を解説

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認証での使い方、SSH鍵やGitHub Appsトークンとの違い、漏洩時の対処までを2026年6月時点の公式仕様で解説します。

まとめ：GitHub PATの要点

先に結論を整理します。詳細は各セクションで解説します。

• PATとは：ユーザーアカウントに紐づく認証トークン。HTTPSでのGit操作やGitHub APIの呼び出しで、パスワードの代わりに使います。
• 2種類：fine-grained PAT（推奨・リポジトリ単位＋細粒度権限・有効期限必須）と classic PAT（広いスコープ・無期限設定可）。原則はfine-grainedを選びます。
• 作成場所：右上アバター > Settings > 左サイドバー最下部の Developer settings > Personal access tokens から発行します。発行値は一度しか表示されません。
• 有効期限：fine-grainedは1〜366日で無期限不可。classicは無期限も設定できますが、短い期限を付けるのが安全です。
• 漏洩したら：すぐに該当トークンをrevoke（無効化）して再発行します。GitHubのsecret scanningが公開リポジトリ上のトークンを検出します。

以下で、PATの意味・作成手順・種類の違い・スコープ・HTTPS認証での使い方・SSHやAppsトークンとの違い・漏洩対策の順に確認していきましょう。

GitHub PAT（個人用アクセストークン）とは何か

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

用途は大きく2つです。1つはコマンドラインやスクリプトからHTTPSでGitリポジトリを操作する場合。もう1つはGitHub REST API／GraphQL APIをトークン付きで呼び出す場合です。CLIツールやCIの簡易な認証手段として広く使われていますが、ユーザー権限をそのまま代行するため、スコープの広いPATが漏れると影響範囲が大きくなります。後述のとおり、権限と有効期限を絞る運用が前提になります。

PATの作成方法（Settings > Developer settings の手順）

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

1. ブラウザでGitHubにサインインし、右上のアバターをクリックしてSettingsを開きます。
2. 左サイドバーを一番下までスクロールし、Developer settingsを選びます。
3. Personal access tokensを開き、Fine-grained tokensかTokens (classic)のどちらかを選択します。原則はfine-grainedです。
4. Generate new tokenをクリックし、トークン名・有効期限・対象リソース（fine-grainedはリポジトリ単位）・権限（scope/permissions）を設定します。
5. 生成すると一度だけトークン文字列が表示されます。この画面を離れると再表示できないため、その場でパスワードマネージャー等に安全に保管します。紛失した場合は再発行が必要です。

発行したトークンは、HTTPSでのGit操作ならパスワード欄に貼り付け、API呼び出しならAuthorizationヘッダーに付与して使います。具体的な使い方は後述のHTTPS認証の章で扱います。

classic PATとfine-grained PATの違い

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

原則はfine-grainedを選び、リポジトリと権限を必要最小限に絞ります。ただしfine-grainedはすべての操作に対応しているわけではなく、Gistやnotificationsなど一部はfine-grainedで扱えないため、その種の操作にはclassicが必要になる場合があります。用途がfine-grainedで完結するか先に確認し、足りない場合のみclassicを期限付き・最小scopeで使うのが安全です。

PATのスコープ・権限の考え方（最小権限）

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

classicのrepoはプライベートを含む全リポジトリのフルアクセスを与え、admin:orgは組織管理まで及びます。これらを常用トークンに付けたままにするのは避けます。fine-grainedでは、対象リポジトリを選んだうえで「Contents: read-only」「Issues: read and write」のように機能ごとに読み取り／書き込みを選べるため、CIで必要なのがコードの読み取りだけなら書き込み権限を付けない、といった絞り込みができます。判断に迷う場合は、最初はread-onlyで作り、操作が失敗したら必要な権限だけを足す進め方が安全です。

PATの有効期限と更新（ローテーション）

有効期限は漏洩リスクを下げる重要な要素です。fine-grained PATは1〜366日の範囲で必ず期限を設定し、無期限にはできません。classic PATは無期限も選べますが、無期限トークンは漏れたときに失効しないため、業務では明確な期限を付けるべきです。

期限切れが近づくとGitHubから通知が届くため、運用中のトークンは期限に合わせて再発行（ローテーション）します。CIに登録しているトークンを更新する場合は、新トークンをSecretsに登録してから旧トークンをrevoke（無効化）する順序にすると、ワークフローを止めずに切り替えられます。一時的な作業用に発行したトークンは、作業が終わったら放置せず削除しておきます。

HTTPSでのGit認証・APIでのPATの使い方

HTTPSでGit操作を行う場合、git cloneやgit pushの認証情報入力で、ユーザー名にGitHubのユーザー名、パスワード欄にPATを入力します。毎回入力しないように、Gitの資格情報ヘルパー（credential helper）にPATを保存しておくのが一般的です。なお、コマンドラインで対話的に認証を済ませたいだけなら、PATを直接扱わずに済むGitHub CLIとは？コマンドラインでGitHub操作を効率化するツールの概要のgh auth loginを使う方法もあります。

GitHub APIを呼び出す場合は、HTTPリクエストのAuthorizationヘッダーにトークンを付与します。

curl -H "Authorization: Bearer <YOUR_PAT>" \
  https://api.github.com/user

トークンはコードに直書きせず、環境変数やシークレットストアから読み込みます。スクリプトやログにトークンを出力しないことも、漏洩を防ぐうえで重要です。

PATとSSH鍵・GitHub Appsトークンの違い

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

個人がローカルでHTTPSのGit操作やAPIを少し叩くだけならPATで十分です。一方、CI/CDやBotのようにシステム間で安定して自動化したい場合は、個人アカウントに依存せず短命なトークンを払い出せるGitHub Appsトークンの方が向いています。Appsトークンの作成手順やJWT署名、Installation Access Tokenの取り回しなど、組織自動化向けの詳細はPATとGitHub Appsトークンの違いと使い分けのポイントで扱っています。組織全体の認証統制を整えたい場合は、GitHub SSOの概要とその導入によるメリットとはも合わせて検討するとよいでしょう。

PATが漏洩したときの対処とリスク管理

PAT、特に広いスコープを持つclassic PATの漏洩は深刻なインシデントになり得ます。誤って公開リポジトリにコミットすると、不正アクセスやコード改ざんにつながります。漏洩に気づいたら、まず該当トークンをすぐにrevoke（無効化）し、新しいトークンを再発行します。トークンを使っていたCIやスクリプトの設定も新トークンへ更新します。

GitHubは公開リポジトリ等でトークン形式の文字列を検出するsecret scanningを備えており、検出時には通知や無効化が行われます。ただし検出に頼り切らず、コミット前にトークンを混入させない仕組みも重要です。リポジトリ内のシークレット混入はオープンソースシークレット検出ツールとして注目を集めるgitleaksとは何か？ソースコード内のシークレット検出機能と用途を徹底解説のようなツールで検査できます。トークン管理を軽視した結果がどのような事故につながるかは、マネーフォワードGitHub不正アクセス事案2026年5月公表の全体像のような実例からも確認できます。

よくある質問（FAQ）

GitHubのPATとは何ですか？

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

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

右上のアバター > Settings > 左サイドバー最下部の Developer settings > Personal access tokens から作成します。Fine-grained tokens（推奨）か Tokens (classic) を選び、Generate new token で名前・有効期限・対象リポジトリ・権限を設定します。発行されたトークンは一度しか表示されないため、その場で安全に保管してください。

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

原則はfine-grained PATです。fine-grainedはリポジトリ単位かつ機能ごとに権限を絞れ、有効期限も必須（1〜366日）で安全です。ただしGistやnotificationsなどfine-grainedが未対応の操作があり、その場合はclassicを期限付き・最小スコープで使います。GitHub自身もfine-grainedの利用を推奨しています。

GitHub PATの有効期限はどのくらいですか？

fine-grained PATは1〜366日の範囲で必ず期限を設定し、無期限にはできません。classic PATは無期限も設定できますが、漏洩時に失効しないため、業務では短い期限を付けて定期的にローテーションするのが安全です。期限が近づくとGitHubから通知が届きます。

PATを使ってHTTPSでgit pushするには？

HTTPSのリポジトリで認証を求められたら、ユーザー名にGitHubのユーザー名、パスワード欄にPATを入力します。毎回入力しないようGitの資格情報ヘルパーに保存できます。コマンドラインの認証をまとめて済ませたい場合は、GitHub CLIのgh auth loginを使う方法もあります。

PATとSSH鍵・GitHub Appsトークンの違いは？

PATはユーザーに紐づきHTTPSのGit操作やAPIに手軽に使えます。SSH鍵はSSHでのGit操作向けで、鍵ペアの管理が必要です。GitHub AppsトークンはアプリにインストールしてCI/CDやBotで使う短命（最大1時間）・最小権限のトークンで、個人アカウントに依存しません。個人作業はPAT、組織の自動化はAppsトークンが向きます。

関連記事

• PATとGitHub Appsトークンの違いと使い分けのポイント
• GitHub CLIとは？コマンドラインでGitHub操作を効率化するツールの概要
• GitHub SSOの概要とその導入によるメリットとは
• オープンソースシークレット検出ツールとして注目を集めるgitleaksとは何か？ソースコード内のシークレット検出機能と用途を徹底解説
• マネーフォワードGitHub不正アクセス事案2026年5月公表の全体像