Claude TagのGitHub操作失敗で考えるAIエージェント障害時の人への戻し方

Claude TagにGitHubの修正を任せた際、「GitHub operations denied」と表示されたら、権限を広げる前にサービス障害かどうかを確かめてください。
2026年7月にはAnthropic側の障害で同じエラーが発生しており、自社の設定ミスとは限りません。

Claude TagのGitHub操作失敗で何が起きたか

Anthropic公式ステータスは、2026年7月7日06:49 JSTにClaude TagのGitHub関連操作でエラー率が上がっていると告知しました。
7月8日00:30 JSTにGitHubへの負荷を調整し、00:52 JSTにResolvedと更新しています。

確定できるのは、障害の時間帯とGitHubへの負荷調整、エラー率低下までです。技術的な根本原因や影響件数は公表されていません。
同日の広いClaude障害は、7月7日朝のClaude障害の影響で時系列を確認できます。

出典: Anthropic公式ステータス(英語)

Claude TagのGitHub操作はどの権限で動くか

Claude Tagは2026年6月23日に発表され、調査時点でTeam・Enterprise向けのSlackベータとして提供中。共有チャンネルから依頼できますが、依頼者個人のアカウントを借りるのではなく、組織のAgent Identityで動きます。
機能の全体像はClaude TagをSlackで使う時の仕事と情報の守り方にまとめています。

出典: Anthropic「Introducing Claude Tag」(英語)

GitHubではClaude GitHub AppがPRやコミットの作者となり、起点のSlackスレッドも追跡できます。一方、実際に読み書きできる範囲はGitHub AppのPermissionsとRepository accessで決まるため、AIの指示文だけでは制御できません。

出典: Claude Help Center「What is Claude Tag?」(英語)

出典: Claude公式「Agent identity in Claude Tag」(英語)

ClaudeのGitHub操作失敗で最初に切り分ける3点

GitHub操作失敗の初動は、エラー文だけで原因を決めないことです。サービス、権限、部分実行の順に切り分けると、障害中の不要な設定変更を避けられます。

公式ステータスが正常で、特定のリポジトリだけ失敗するなら、GitHub Appの対象と権限を管理者が見直します。ただし、障害中に全リポジトリの書き込みを許可するのは逆効果です。
AIエージェントの権限管理に沿って、必要なリポジトリだけを残してください。

出典: GitHub Docs「Reviewing and modifying installed GitHub Apps」(英語)

AIエージェント障害時に人へ戻す4段階

AIエージェント障害時の人への戻し方とは、自動実行を止め、証跡を残し、責任者へ渡し、確認済み作業から再開するプロセスである。同じエラーが二度続くか、部分実行の状態が不明なら、それ以上の自動再試行を止めます。

引継ぎには、タスクID、起点のSlackスレッド、対象リポジトリとブランチ、完了済み操作、エラー全文の5項目を残します。GitHub側の作業履歴の見方はGitHub Copilotエージェントの作業履歴管理も参考になります。

通常時から閲覧、提案、実行を分けておくと、障害時に切り戻す範囲が明確です。AIエージェントの承認フローで、人が残る操作を先に決めておけば、障害対応は特別運用ではなく日常運用の延長になります。

ClaudeのGitHub操作を復旧後に再開する判断基準

復旧後は、公式ステータスが正常に戻っただけでキューを一斉再開しないでください。読み取りや下書きなど状態を変えない仕事から確かめ、書き込みはPR・ブランチ・コミットの存在を照合してから一件ずつ戻します。

• 公式ステータスが復旧している
• 既存PR、ブランチ、コミットを人が確認した
• 同じ依頼の重複実行を防ぐタスクIDがある
• 読み取りから試し、書き込みは後に回す
• 失敗時にすぐ人へ戻す当番者がいる

Anthropicの公式資料では、失敗したGitHub操作が復旧後に自動再開されるかを確認できません。そのため、「自動で続きから委ねる」という前提は置かないのが安全です。
平時から代替手順を決める場合は、生成AIの利用停止対策の台帳と組み合わせると運用しやすくなります。

AIエージェント障害時のFAQ