# REST API に対する認証 REST API に対して認証を行って、より多くのエンドポイントにアクセスし、レート制限を高めることができます。 ## 認証について 多くの REST API エンドポイント操作では、認証が必要であるか、認証されている場合は追加情報が返されます。 さらに、認証されている場合は 1 時間あたりの要求を増やすことができます。 要求を認証するには、必要なスコープまたはアクセス許可を持つ認証トークンを提供する必要があります。 トークンを取得するには、いくつかの方法があります。personal access tokenを作成したり、GitHub Appでトークンを生成したり、`GITHUB_TOKEN`ワークフローで組み込みのGitHub Actionsを使用したりできます。 トークンを作成すると、要求の `Authorization` ヘッダーでトークンを送信することで要求を認証できます。 たとえば、次の要求では、`YOUR-TOKEN` をトークンへの参照に置き換えます。 ```shell curl --request GET \ --url "https://api.github.com/octocat" \ --header "Authorization: Bearer YOUR-TOKEN" \ --header "X-GitHub-Api-Version: 2026-03-10" ``` > \[!NOTE] > ほとんどの場合は、`Authorization: Bearer` または `Authorization: token` を使用してトークンを渡すことができます。 ただし、JSON Web トークン (JWT) を渡す場合は、`Authorization: Bearer` を使用する必要があります。 ### ログイン失敗の制限 トークンなしで、またはアクセス許可が不十分なトークンで REST API エンドポイントを使用しようとすると、`404 Not Found` または `403 Forbidden` 応答を受け取ります。 無効な資格情報で認証すると、`401 Unauthorized` 応答が返されます。 無効な資格情報を含むリクエストを短期間に複数回検出すると、API は、`403 Forbidden` 応答で、そのユーザに対するすべての認証試行 (有効な資格情報による試行を含む) を一時的に拒否します。 詳しくは、「[REST API のレート制限](/ja/rest/using-the-rest-api/rate-limits-for-the-rest-api)」をご覧ください。 ## personal access tokenを使用した認証の実行 個人用に GitHub REST API を使用する場合は、 personal access tokenを作成できます。 可能であれば、GitHubはfine-grained personal access tokenではなくpersonal access token (classic)を使用することをお勧めします。 personal access tokenの作成の詳細については、「[個人用アクセス トークンを管理する](/ja/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)」を参照してください。 fine-grained personal access tokenを使用している場合、各 REST API エンドポイントにアクセスするには、fine-grained personal access tokenに特定のアクセス許可が必要です。 各エンドポイントの REST API リファレンス ドキュメントでは、エンドポイントが fine-grained personal access tokenで動作するかどうかを示し、トークンがエンドポイントを使用するために必要なアクセス許可を示します。 一部のエンドポイントでは複数のアクセス許可が必要な場合があり、一部のエンドポイントでは複数のアクセス許可のうちの 1 つが必要な場合があります。 各アクセス許可で fine-grained personal access token がアクセスできる REST API エンドポイントの概要については、 [詳細に制御された個人用アクセス トークンに必要なアクセス許可](/ja/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens) を参照してください。 personal access token (classic)を使用している場合は、各 REST API エンドポイントにアクセスするために特定のスコープが必要です。 選択するスコープに関する全般的なガイダンスについては、「[OAuth アプリのスコープ](/ja/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes)」を参照してください。 Personal access tokens は、REST API に要求を行うときに ID として機能します (選択したスコープまたはアクセス許可によって制限されます)。 そのため、 personal access tokens をセキュリティで保護することが重要です。 personal access tokensのセキュリティ保護の詳細については、「[API 資格情報をセキュリティで保護する](/ja/rest/authentication/keeping-your-api-credentials-secure?apiVersion=2022-11-28)」を参照してください。 ### Personal access tokens と SAML SSO 認証に SAML シングル サインオン (SSO) を適用する組織にアクセスするために personal access token (classic) を使用する場合は、作成後にトークンを承認する必要があります。 Fine-grained personal access tokenは、組織へのアクセスが許可される前に、トークンの作成時に承認されます。 詳しくは、「[シングル サインオンに使用する個人用アクセス トークンの認可](/ja/authentication/authenticating-with-single-sign-on/authorizing-a-personal-access-token-for-use-with-single-sign-on)」をご覧ください。 SAML SSO を適用する単一の組織にアクセスする前に SAML SSO の personal access token (classic) を承認しないと、 `404 Not Found` または `403 Forbidden` エラーが発生する可能性があります。 `403 Forbidden` エラーが発生した場合、`X-GitHub-SSO` ヘッダーには、トークンを承認するために従うことができる URL が含まれます。 URL は 1 時間後に期限切れになります。 SAML SSO の personal access token (classic) を使用して複数の組織にアクセスしようとする前に承認しない場合、API は SAML SSO を必要とする組織からの結果を返しません。 `X-GitHub-SSO` ヘッダーには、 personal access token (classic)の SAML SSO 承認を必要とする組織の ID が示されます。 例: `X-GitHub-SSO: partial-results; organizations=21955855,20582480`。 ## アプリによって生成されたトークンを使用した認証 組織または別のユーザーの代わりに API を使用する場合は、GitHubGitHub Appを使用することをお勧めします。 詳しくは、「[GitHub アプリでの認証について](/ja/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app)」をご覧ください。 各エンドポイントの REST API リファレンス ドキュメントでは、エンドポイントが GitHub Apps で動作するかどうかを示し、アプリがエンドポイントを使用するために必要なアクセス許可を示しています。 一部のエンドポイントでは複数のアクセス許可が必要な場合があり、一部のエンドポイントでは複数のアクセス許可のうちの 1 つが必要な場合があります。 各アクセス許可で GitHub App がアクセスできる REST API エンドポイントの概要については、 [GitHub Apps に必要なアクセス許可](/ja/rest/authentication/permissions-required-for-github-apps) を参照してください。 REST API にアクセスするための OAuth app を使用して OAuth トークンを作成することもできます。 ただし、 GitHub では、代わりに GitHub App を使用することをお勧めします。 GitHub Apps を使用すると、アプリが持つアクセスとアクセス許可をより詳細に制御できます。 アプリによって作成されたアクセス トークンは、SAML SSO に対して自動的に承認されます。 ### 基本認証を使用する GitHub AppsおよびOAuth appsの一部の REST API エンドポイントでは、基本認証を使用してエンドポイントにアクセスする必要があります。 ユーザー名としてアプリのクライアント ID を使用し、パスワードとしてアプリのクライアント シークレットを使用します。 次に例を示します。 ```shell curl --request POST \ --url "https://api.github.com/applications/YOUR_CLIENT_ID/token" \ --user "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \ --header "Accept: application/vnd.github+json" \ --header "X-GitHub-Api-Version: 2026-03-10" \ --data '{ "access_token": "ACCESS_TOKEN_TO_CHECK" }' ``` クライアント ID とクライアント シークレットは、アプリの所有者またはアプリを承認したユーザーではなく、アプリに関連付けられます。 アクセス トークンの作成など、アプリに代わって操作を実行するために使用されます。 GitHub AppまたはOAuth appの所有者である場合、またはGitHub Appのアプリ マネージャーである場合は、アプリの設定ページでクライアント ID を見つけてクライアント シークレットを生成できます。 アプリの設定ページに移動するには: 1. GitHubのページの右上隅にあるプロフィール画像をクリックします。 2. アカウント設定にアクセスしてください。 * 個人用アカウントが所有するアプリの場合は、**\[設定]** をクリックします。 * 組織が所有するアプリの場合: 1\. **\[自分の組織]** をクリックします。 1. 組織の右側にある **\[設定]** をクリックします。 3. 左側のサイドバーの ** \[Developer settings]** をクリックします。 4. 左側のサイドバーで、\[ **GitHub Apps** ] または \[ **OAuth apps**] をクリックします。 5. GitHub Appsの場合は、アクセスするGitHub Appの右側にある \[**編集**] をクリックします。 OAuth appsの場合は、アクセスするアプリをクリックします。 6. **\[クライアント ID]** の横に、アプリのクライアント ID が表示されます。 7. **\[クライアント シークレット]** の横にある **\[新しいクライアント シークレットの生成]** をクリックして、アプリのクライアント シークレットを生成します。 ## GitHub Actions ワークフローでの認証 GitHub Actions ワークフローで API を使用する場合GitHubは、トークンを作成するのではなく、組み込みの`GITHUB_TOKEN`で認証することをお勧めします。 `GITHUB_TOKEN` キーを使用して、`permissions` へのアクセス許可を付与できます。 詳しくは、「[ワークフローでの認証に GITHUB\_TOKEN を使用する](/ja/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token)」をご覧ください。 これが不可能な場合は、トークンをシークレットとして格納し、 GitHub Actions ワークフローでシークレットの名前を使用できます。 シークレットの詳細については、「[GitHub Actions でのシークレットの使用](/ja/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets)」を参照してください。 ### GitHub Actions を使用した GitHub CLI ワークフローでの認証 GitHub Actionsを使用して、GitHub CLI ワークフロー内の API に対して認証済み要求を行うには、`GITHUB_TOKEN`の値を環境変数として格納し、`run` キーワードを使用して GitHub CLI`api` サブコマンドを実行します。 `run` キーワードについて詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun)」をご覧ください。 次のワークフロー例では、`PATH` をエンドポイントのパスに置き換えます。 パスの詳細については、 [REST API を使用した作業の開始](/ja/rest/using-the-rest-api/getting-started-with-the-rest-api?tool=cli#path) を参照してください。 ```yaml jobs: use_api: runs-on: ubuntu-latest permissions: {} steps: - env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | gh api /PATH ``` ### `curl` を使用した GitHub Actions ワークフローでの認証 GitHub Actionsを使用して、`curl` ワークフロー内の API に対して認証された要求を行うには、`GITHUB_TOKEN`の値を環境変数として格納し、`run` キーワードを使用して API に`curl`要求を実行します。 `run` キーワードについて詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun)」をご覧ください。 次のワークフロー例では、`PATH` をエンドポイントのパスに置き換えます。 パスの詳細については、 [REST API を使用した作業の開始](/ja/rest/using-the-rest-api/getting-started-with-the-rest-api?tool=cli#path) を参照してください。 ```yaml copy jobs: use_api: runs-on: ubuntu-latest permissions: {} steps: - env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | curl --request GET \ --url "https://api.github.com/PATH" \ --header "Authorization: Bearer $GH_TOKEN" ``` ### JavaScript を使用した GitHub Actions ワークフローでの認証 JavaScript を使用して GitHub Actions ワークフローで認証する方法の例については、 [REST API と JavaScript を使用したスクリプト](/ja/rest/guides/scripting-with-the-rest-api-and-javascript#authenticating-in-github-actions) を参照してください。 ## ユーザー名とパスワードによる認証 ユーザー名とパスワードによる認証はサポートされていません。 ユーザー名とパスワードを使用して認証しようとすると、4xx エラーが表示されます。 ## 参考資料 * [API 資格情報をセキュリティで保護する](/ja/rest/authentication/keeping-your-api-credentials-secure) * [REST API を使用した作業の開始](/ja/rest/using-the-rest-api/getting-started-with-the-rest-api#authentication)