GitHub Actions・2026年11月3日に確認

GitHub Actions：「Resource not accessible by integration」

ステップが使ったトークン（たいていはジョブの GITHUB_TOKEN）に、その API の呼び出しに要る権限が無かったので、GitHub が 403 を返した、という意味です（「この連携からはこのリソースにアクセスできない」）。直すのはたいてい permissions: の下の1行です。どの1行かは、呼び出しの中身と、実行を始めたきっかけで決まります。

見え方

2026年11月1日の公開の実行で、actions/configure-pages が失敗したときの表示です：

##[error]Get Pages site failed. Please verify that the repository has Pages enabled and configured to build using GitHub Actions, or consider exploring the `enablement` parameter for this action. Error: Resource not accessible by integration - https://docs.github.com/rest/pages/pages#get-a-apiname-pages-site

同じ拒否を、ほかの道具はこう表示します：

GraphQL: Resource not accessible by integration (removeLabelsFromLabelable)
gh: Resource not accessible by integration (HTTP 403)
RequestError [HttpError]: Resource not accessible by integration

「integration」は GitHub App のことです。GITHUB_TOKEN は GitHub Actions のアプリのインストールトークンで、ワークフローが動いているリポジトリにしか届きません。権限の足りない fine-grained personal access token では、代わりに「Resource not accessible by personal access token」と出ます（そのトークンに足りない権限の見分け方）。
ジョブはその呼び出しまでは普通に進みます。手前のビルドやテストは通っていることがあります。

要った権限を調べる

失敗したジョブを開いて Set up job を広げ、その中の GITHUB_TOKEN Permissions を広げます。トークンが持っていた権限の一覧です。上の Pages の実行では、これだけでした：
```
GITHUB_TOKEN Permissions
Contents: read
Metadata: read
```
403 の応答には X-Accepted-GitHub-Permissions というヘッダーが付き、そのエンドポイントが受け付ける権限が書いてあります。カンマは「両方とも要る」（pull_requests=write,contents=read）、セミコロンは「どちらか」の区切りです。actions/github-script はエラーと一緒に応答のヘッダーを出すので、issue を作る定期のワークフローでは 'issues=write' と出ていました（memphis #638）。gh なら -i で、失敗した呼び出しでもヘッダーが出ます：
```
gh api -i "repos/$GITHUB_REPOSITORY/pages"
```
ヘッダーは API の名前でアンダースコアを使います。ワークフローではハイフンで書きます。pull_requests=write は pull-requests: write です。

権限が無かった理由

permissions の欄に書いていなかった。GitHub のワークフロー構文のリファレンスには、どれか1つでも権限を指定すると、指定しなかった権限はすべて none になる、とあります。なので、ワークフローに permissions: contents: read を足すと、それまでジョブが持っていた書き込みはすべて無くなります。Lock Threads のワークフローは issues: write と pull-requests: write を付けていましたが、アクションが閉じたディスカッションも処理し、リポジトリで Discussions が有効だったので、discussions: write を足すまで毎回失敗していました（DynamicData #1212）。再利用ワークフローは、呼び出し側の権限を保つか減らすかしかできず、増やせません。なので、1行は呼び出す側のジョブに書きます（llm-d-kv-cache #743）。
既定が読み取りだけだった。Settings、Actions、General の「Workflow permissions」は、すべての権限で読み書き（permissive）か、contents と packages の読み取りだけ（restricted）のどちらかで、Organization の owner はさらに絞れます。restricted の既定で permissions の欄が無いと、書き込みはすべて失敗します。release-drafter のワークフローがこれで失敗し、contents: write と pull-requests: read が要りました（docker-buildkite-plugin #322）。
ワークフローに何を書いても、実行には読み取りだけのトークンが渡された：
- フォークからの pull_request には、読み取りだけの GITHUB_TOKEN が渡り、シークレットも渡りません。非公開のリポジトリなら「Send write tokens to workflows from pull requests」を有効にできますが、公開のリポジトリではできません。あるプロジェクトでは、ベンチマークの結果のコメントが、フォークからのプルリクエストではすべて断られ、自分のブランチからのプルリクエストでは書けていました。いまは head のリポジトリが自分のときだけコメントし、フォークの分は表をジョブのサマリーに残しています（optbench #38）：
```
- name: Comment on the pull request
  if: github.event.pull_request.head.repo.full_name == github.repository
```
  pull_request_target なら公開のフォークからでも書き込めるトークンが渡りますが、GitHub はその中でフォークのコードをチェックアウトしないよう注意しています。
- Dependabot が push・pull_request・pull_request_review・pull_request_review_comment で始めた実行は、フォークと同じ扱いです。トークンは読み取りだけで、Actions のシークレットも渡りません。フォークと違い、こちらは permissions の欄でトークンの権限を上げられます。

よくある作業ごとの権限

プルリクエストにラベルを付ける・外す：pull-requests: write。ラベルのエンドポイントは issue と共通なので、ヘッダーには issues=write; pull_requests=write と出ることがありますが、issues: write だけではプルリクエストで断られた、という公開の報告が2件あります（llm-d-kv-cache #743・StellarCred #955）。
issue を作る・issue にコメントする：issues: write。プルリクエストにコメントする：pull-requests: write。
リリースを作る・更新する、コミットやタグを push する：contents: write。
ディスカッションをロックする・閉じる：discussions: write。
GitHub Pages：actions/configure-pages には pages: read、actions/deploy-pages には pages: write と id-token: write。
SARIF のファイルを code scanning に上げる：security-events: write。非公開のリポジトリでは、さらに actions: read と contents: read。
チェックランを作る：checks: write。コミットのステータスを付ける：statuses: write。
GitHub Packages に公開する：packages: write。クラウドにサインインするための OIDC トークンを取る：id-token: write。ワークフローの実行をキャンセルする：actions: write。

権限は、その呼び出しをするジョブに付けます。書かなかった権限は none になるので、そのジョブがまだ使う読み取りも並べて書きます：

jobs:
  label:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

権限では直らないもの

別のリポジトリ。GITHUB_TOKEN はワークフローのリポジトリにしか届きません。別のリポジトリには、GitHub App のトークンか、シークレットに入れた fine-grained personal access token を使います。
リポジトリの管理（ブランチ保護を読むなど）。ワークフローが付けられる権限の中にありません。
「GitHub Actions is not permitted to create or approve pull requests」は別のメッセージです。同じ「Workflow permissions」の中の「Allow GitHub Actions to create and approve pull requests」が切れています。個人アカウントの新しいリポジトリでは、最初は切れています。
ログのダウンロードでの 403「Must have admin rights to Repository.」は、公開のリポジトリでも、リクエストにトークンがまったく付いていなかったという意味です（ログと管理者権限）。

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、断られたステップが目立ちます。いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：「Unable to resolve action」 · 「The operation was canceled」 · 「Must have admin rights to Repository」 · デバッグログ付きでジョブを再実行する · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English