Claude Media
/autofix-prがGitHub組織ポリシーで拒否される — IP許可リストとSSOの対処

/autofix-prがGitHub組織ポリシーで拒否される — IP許可リストとSSOの対処

/autofix-prで「A GitHub organization policy is blocking Claude」が出る原因をIP許可リスト・SSO・条件付きアクセスに分け、対処を示す。

3種類のメッセージで、直す人と場所が変わる

/autofix-prのようにクラウドセッションを起動するコマンドが「A GitHub organization policy is blocking Claude」の系統のエラーで止まるとき、原因はGitHub組織側のポリシーです。メッセージの1行目で、どのポリシーかが分かれます。

切り分け

メッセージ別の原因

  • IP allowlist

    Your GitHub organization has an IP allowlist that is blocking Claude. GitHub組織のIP許可リストが、Claudeの接続元を弾いています。直すのはGitHub組織またはEnterpriseのオーナーです。

  • single sign-on

    Your GitHub organization requires single sign-on. SAML SSOを強制する組織で、Claude側のGitHub接続が認可されていません。直すのは本人で、claude.aiのコネクタ画面から再接続します。

  • Conditional Access

    ...(Microsoft Entra ID) has a Conditional Access policy that is blocking Claude. IdPの条件付きアクセスがClaudeを止めています。直すのはGitHub EnterpriseまたはEntra IDの管理者です。

この3つは、どれもクラウドセッションを作る前の確認で起きます。以降はメッセージごとに、誰が何を変えるかを順に見ます。

なぜセッション作成の前で止まるのか

/autofix-prは、いま居るブランチのPRをghで見つけ、クラウドセッションを起動し、Auto-fix(CI失敗やレビューコメントへの自動対応)を1回で有効にするコマンドです。

その手前で、Claude CodeはGitHub上でClaudeがリポジトリに届くかを確かめます。ここでGitHubが組織ポリシーを理由に拒否すると、セッションは作られず、ポリシーを名指ししたメッセージだけが出ます。

だから「ブランチもghも正常なのに起動しない」という見え方になります。ローカルの設定を疑う前に、メッセージの1行目で上の3種類のどれかを確かめるのが近道です。

IP許可リストに阻まれたとき

クラウドセッションとCode Reviewは、手元のネットワークではなくAnthropic管理のインフラからリポジトリに接続します。GitHub Enterprise Cloudの組織がIPアドレスでアクセスを絞っていると、その接続元が弾かれます。

組織のオーナーに頼む作業は2つです。

  1. 「インストール済みGitHub AppにIP許可リストを継承させる」設定を有効にする
  2. Anthropicのアウトバウンド(送信元)IPアドレスを、許可リストのエントリとして追加する

2つ目に入れるアドレスは、Anthropic APIのIPアドレス一覧にある送信元IPv4の160.79.104.0/21です。同じページに「使われなくなったIP」として5つの/32アドレスも載っています。以前に許可したのであれば、削除対象です。一覧の読み方と、ファイアウォールへの登録手順はClaude APIのIPアドレスをファイアウォールに許可登録する手順にまとめています。

継承の設定には注意点があります。継承が効くのは、Claude GitHub AppがインストールとしてGitHubに出すリクエストだけで、ユーザーの代理として出すリクエストは対象外です。継承だけを有効にして許可リストのエントリを足さない構成では、このエラーが残る可能性があります。

Claude側のIP許可リストとは別の話

名前が似た設定に、Claude組織側の「IPアドレス制限」があります。これは「Claudeにアクセスできる接続元」を絞る機能で、Anthropic管理のクラウドセッションが組織のAPIを呼ぶときに認証エラーで失敗する原因になります。直すのはAnthropicサポートへの申請で、GitHubの設定ではありません。Claude側の設定はClaudeのIP許可リストをEnterpriseで設定する手順で扱っています。

見分け方は単純で、今回のメッセージに「GitHub organization」と出ていればGitHub側、認証エラーとして出ていればClaude側です。

SSOに阻まれたとき

「Your GitHub organization requires single sign-on」が出たら、次の手順で直します。

手順

SSOの認可をやり直す

  1. 1

    コネクタを切断する

    ブラウザーでClaudeのコネクタ画面(claude.ai/customize/connectors)を開き、GitHubの接続を切断します。

  2. 2

    GitHubを接続し直す

    同じ画面からGitHubを接続します。

  3. 3

    組織の横のAuthorizeを押す

    GitHubが認可画面を出したら、対象の組織の横にあるAuthorizeを押します。これで新しい接続が、組織のSSO向けに認可されます。

  4. 4

    コマンドを再実行する

    /autofix-prをもう一度実行します。

公式の手順は、認可ボタンだけを押すのではなく、いったん切断してから接続し直す形です。

組織が複数あるとき

複数のGitHub組織に所属していて、SSOを強制するのが一部だけという構成はよくあります。GitHubが認可を求める画面では、/autofix-prを実行したいリポジトリの組織の横にあるAuthorizeを押します。

条件付きアクセスに阻まれたとき

GitHub Enterpriseのアイデンティティプロバイダーに、Microsoft Entra IDが入っている組織の話です。Conditional Access(条件付きアクセス)ポリシーがClaudeからのアクセスを止めると、IP許可リストともSSOとも違うメッセージが出ます。

このケースでは、本人が画面で直せる手順が公式に書かれていません。GitHub EnterpriseまたはEntra IDの管理者に、そのポリシーでClaudeを許可するよう頼むのが対処になります。

管理者に出す依頼文の例

3つのうち2つは、自分では直せません。依頼する側が迷わないよう、再現条件と求める変更をひとまとめにして渡すと往復が減ります。次の例は、IP許可リストの場合の書き方です。

件名: Claude Codeのクラウドセッション用に、GitHub IP許可リストの変更をお願いします
 
事象:
  /autofix-pr 実行時に次のメッセージで止まります。
  "Your GitHub organization has an IP allowlist that is blocking Claude."
 
お願い:
  1. 組織(またはEnterprise)で、インストール済みGitHub AppへのIP許可リスト継承を有効化
  2. AnthropicのアウトバウンドIPv4 160.79.104.0/21 を許可リストに追加
 
参考: Anthropic APIのIPアドレス一覧(アウトバウンド節)

SSOや条件付きアクセスの場合も、同じ形でメッセージの原文を貼ります。原文があれば、管理者はどのポリシーかをすぐ特定できます。

/install-github-appのSSO警告は別物

同じ「SAML SSO」でも、/install-github-appが出す警告は別の仕組みです。こちらはクラウドセッションとは無関係で、手元のghトークンの認可が対象になります。

Single sign-on authorization needed
<owner>/<repo> belongs to an organization that enforces SAML single sign-on, and your GitHub CLI token isn't authorized for it yet.
くらべる

同じSSOでも直す場所が違う

クラウドセッション

/autofix-prなど

認可の対象はClaude側のGitHub接続です。claude.aiのコネクタ画面で切断して接続し直し、組織のAuthorizeを押します。

手元のgh

/install-github-app

認可の対象はghのトークンです。ターミナルで再認可し、GitHubのSSOプロンプトで組織を認可します。

/install-github-appの側は、repoとworkflowのスコープを付けてghを再認可します。

gh auth refresh -h github.com -s repo,workflow

環境変数GH_TOKENにPersonal Access Tokenを入れている場合は、GitHubのトークン設定画面でそのトークンのConfigure SSOから組織を認可します。どちらの場合も、終わったら/install-github-appを再実行します。

このコマンド自体の手順はClaude GitHub Appのインストール手順にあります。なお、v2.1.273より前のバージョンは、この条件でAdmin permissions requiredという別の警告を出していました。古いClaude Codeでは、文言が本記事と一致しない点に注意してください。

症状から原因を絞る流れ

メッセージの文言を上から順に照らすと、直す相手が決まります。/autofix-prそのものの使い方はClaude Code autofix-prの使い方にあります。

切り分け

/autofix-prが起動しないときの切り分け

  1. Qメッセージに「GitHub isn't connected to your Claude account」とあるか?
    答えがはい

    GitHub組織のポリシーではなく、GitHubアカウントが未接続です。/web-setupを実行するか、claude.ai側でGitHubを接続してから、1分ほど待って再実行します。接続方式の違いはClaude Code WebのGitHub認証で比べています。

    答えがいいえ
  2. Qメッセージに「IP allowlist」とあるか?
    答えがはい

    GitHub組織またはEnterpriseのオーナーに、IP許可リストの継承と、アウトバウンドIPの追加を依頼します。

    答えがいいえ
  3. Qメッセージに「single sign-on」とあるか?
    答えがはい

    コネクタ画面でGitHubを切断し、接続し直して、組織のAuthorizeを押します。

    答えがいいえ

Conditional Accessの場合

GitHub EnterpriseまたはEntra IDの管理者に、そのポリシーでClaudeを許可するよう依頼します。

どの場合も、変更が終わったらコマンドを実行し直します。

似て見える別のエラー

ポリシー系の失敗は、他にも似た見え方をします。混同しやすいものを挙げます。

  • クラウドセッションが「組織のポリシーで無効」という文言で止まる場合は、allow_remote_sessionsという組織ポリシーがオフになっています。GitHub側の設定ではなく、Claude組織の管理者の設定です
  • クラウドセッションの中で特定ドメインへの通信が弾かれる場合は、クラウド環境のネットワークアクセス(許可ドメイン)の話です。GitHubの操作は別の経路を通るため、他のドメインが弾かれていてもGitHub操作だけ動くことがあります
  • Zero Data Retentionが有効な組織や、HIPAA構成を適用した組織は、そもそもクラウドセッションの機能を使えません

Auto-fixを使うには、リポジトリにClaude GitHub Appが入っていることも前提です。ポリシーを解いても動かないときは、インストール状況を確かめます。GitHub Actionsを組織全体に入れる文脈の権限整理はClaude CodeのGitHub Actionsを組織全体に導入する手順が参考になります。

この記事を共有:XはてブLinkedIn