GitHub

冒頭まとめ この記事は設定ミスの記事ではありません。 2026年8月6日から7日にかけて発生した、GitHub 側のサービス障害の記録です。 permissions の見直し、workflow ファイルの書き換え、トークンの再発行、ランナーの再登録——これらを行っても状況は変わりません。原因は利用者側の設定にないためです。 対象期間は、公式の調査開始が日本時間の8月7日 0:22（UTC 8月6日 15:22）、影響の緩和が確認されたのが8月7日 9:05（UTC 0:05）です。本記事の執筆時点で公式の状態は「監視中」であり、正式な解決の宣言はまだ出ていません。最新の状況は公式のインシデントページ（Incident with Actions）で確認してください。 この障害の特徴は、単一のエラー文言では説明できないことです。停止した処理の段階によって、症状がまったく違う形で現れました。「Actions が動かない」という同じ体験でも、どの段階で止まったかによって、取るべき対応が変わります。 何が起きたか：処理段階ごとの症状 公式の更新をもとに、停止した段階ごとに整理します。 処理段階 確認された症状 Webhook の受付 push や pull request がワークフローを作成しない ジョブのキュー queued のまま長時間開始しない、時間切れになる ランナーの割り当て 既に無効になったジョブがランナーへ割り当てられる ジョブの実行 起動に失敗する、途中で失敗する Actions API REST API がエラーを返す、想定外の利用制限がかかる 関連サービス Pages、Copilot のレビューとエージェント、Enterprise Importer の遅延や失敗 とくに重要なのが1行目です。公式の説明によれば、復旧を助けるために webhook の起点が意図的に絞られていました。一時は全体の約15%しか処理されていない状態です。 つまり、push しても何も起きない、pull request を作ってもワークフローの一覧に何も現れない、という状況が発生していました。利用者から見れば「自分の設定が壊れた」ようにしか見えませんが、実際には復旧のための措置です。この段階で workflow ファイルを触っても、何も変わりません。 3行目も特徴的です。公式は途中で「既に有効でないジョブがランナーへ割り当てられている」問題を特定したと発表しています。GitHub 側が用意するランナーと、自前で用意するランナーの両方が影響を受けました。 利用者側の問題との見分け方 以下の兆候が複数当てはまる場合、原因は自分の設定ではありません。 ワークフローそのものが作成されない。特定のジョブが失敗するのではなく、実行が始まらないのが特徴です。 複数のリポジトリで同時に発生している。設定はリポジトリごとに独立しているため、同時発生は外部要因を示します。 GitHub 側のランナーと自前のランナーの両方で失敗している。この2つは実行環境が別なので、片方だけの設定問題では説明できません。 設定を変更していないワークフローまで失敗している。 Actions API や Pages など、Actions 以外にも同時に症状が出ている。 公式のステータスページにインシデントが掲載されている。 逆に、特定のジョブや特定の API 操作だけが再現性をもって失敗する場合は、利用者側の問題です。とくに Resource not accessible by integration のように権限を示す文言が特定の操作で必ず出るなら、そちらを調べてください（GitHub の Resource not accessible by integration の記事）。 ...

冒頭まとめ GitHub Actionsで次のエラーが出た場合、APIが壊れているのではなく、リクエストに使ったトークンがその操作を許可されていません。 RequestError [HttpError]: Resource not accessible by integration status: 403 同じリポジトリで、push や組織内部からの実行が起点なら、解決は失敗した操作に対応する permissions をワークフローへ追加することです。 たとえば、コードを読み、IssueとPull Requestへ書き込むジョブなら次のようにします。 permissions: contents: read issues: write pull-requests: write 必要な権限は操作ごとに違います。 リポジトリをcheckoutする → contents: read コミット、タグ、Releaseを書く → contents: write Issueへ書く → issues: write Pull Requestへ書く → pull-requests: write Check Runを作る → checks: write commit statusを書く → statuses: write コードスキャン結果を送る → security-events: write パッケージを公開する → packages: write OIDCトークンを発行する → id-token: write ただし、permissions を書けば必ず直るわけではありません。次の実行では、ワークフロー側から書き込み権限へ引き上げられないことがあります。 外部フォークからのpull_request Dependabotが作成したPull Request 呼び出し元が権限を与えていない再利用ワークフロー GITHUB_TOKENの対象外である別リポジトリや組織資源への操作 特に、外部フォークの失敗を直すために pull_request_target へ置き換え、Pull Request側のコードをcheckoutして実行するのは危険です。書き込み可能なトークンやシークレットを、信頼できないコードから利用できる状態にしないでください。 ...

冒頭まとめ git clone、git pull、git push で次のエラーが出た場合、GitHubとのSSH認証が完了していません。 git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. 最初に押さえるべきは、この時点では対象リポジトリの権限確認まで進んでいないことです。GitHub公式の説明でも、Permission denied はサーバーが接続を拒否した状態とされています。共同編集者の権限、ブランチ保護、リポジトリの公開・非公開を調べる前に、SSH認証を直します。 また、末尾の publickey は「公開鍵ファイルが壊れた」という意味ではありません。サーバーが続行を許可した認証方式が公開鍵認証だけで、その方式では利用者を確認できなかったという意味です。実際の認証では、端末にある秘密鍵で署名し、GitHubに登録した公開鍵で検証します。GitHubへ追加するのは .pub 側だけです。秘密鍵は送信も貼り付けもしません。 最初の診断は次の1行です。 ssh -vT git@github.com 注目するのは、長い出力の中に Offering public key があるかどうかです。 Offering public key がない → 使える鍵を見つけていない、または選択していない Offering public key はあるが、認証されない → 提示した鍵がGitHubの該当アカウントに登録されていない、または別の鍵を提示している Server accepts key の後に signing failed → 鍵は認識されたが、ssh-agentなどが署名できていない Hi USERNAME! You've successfully authenticated... → SSH認証は成功。次にリポジトリ権限、remote、SSOを確認する つまり、新しい鍵を作ることから始めないのが要点です。まず、失敗したGit操作と同じ端末・同じSSHクライアントが、どの鍵を提示したかを確定します。 ...

冒頭まとめ Host key verification failed. を出しているのは GitHub ではありません。**手元の SSH クライアント**です。意味は「接続先が名乗っている身元を、こちらでは確認できなかった」ということです。 認証の失敗ではない点に注意してください。鍵が正しいかを問う以前の段階で、相手が本物の github.com かどうかを確かめています。 実装を読むと、この段階には2つの分岐があります。1つは記録に無い場合です。相手の鍵を初めて見たとき、対話できる環境なら「この接続先の真正性を確認できません」と表示して確認を求めます。対話できない環境では、確認のしようがないので失敗します。自動処理やコンテナの中でこのエラーが出るのは、ほぼこの形です。 もう1つは記録と違う場合です。この場合は大きな警告が出ます。実装では「接続先の識別情報が変わった」という囲み枠に加えて、記録の何行目が該当するかまで表示されます。 そして重要なのは、この警告は「攻撃かもしれない」と「正当な鍵の交換かもしれない」の両方を意味することです。どちらかを判断するのは利用者の側です。判断材料はあります。GitHub は接続先の鍵の指紋を文書として公開し、API からも配信しています。突き合わせれば、自分で判断できます。 エラーの概要 記録に無い場合、対話できる環境ではこう表示されます。 The authenticity of host 'github.com (140.82.x.x)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. Are you sure you want to continue connecting (yes/no/[fingerprint])? 対話できない環境では確認が省略され、そのまま次の文言で終わります。 Host key verification failed. fatal: Could not read from remote repository. 記録と違う場合は、囲み枠付きの警告になります。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ... Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending RSA key in /home/user/.ssh/known_hosts:12 Host key verification failed. Offending の行に、記録ファイルの何行目が該当するかが書かれています。この番号があれば、消すべき行が特定できます。 ...