無料相談する

カテゴリー / 活用事例

Claude Code GitHub Pages公開前の接続設定と反映されない原因

NO WAVE公開 更新 読了目安 12分

この記事の目次

Claude CodeでGitHub Pagesにサイトを公開するとき、この記事が扱うのはClaude Code側の部分、つまりGitHubとの接続、pushの安全設定、どのブランチにpushされるかです。公開元の指定などの公開設定は扱いません。確認の要点は、変更がどのブランチにpushされたかと、そのブランチがあなたの設定した公開元と同じかどうかです。この記事では、手元のClaude Code（CLI）で進める場合と、クラウドセッション（Claude Code on the web）で進める場合の違いを公式ドキュメントの記述に沿って整理し、pushしたのに反映されないときの切り分けまで扱います。

Claude Code GitHub Pages公開でこの記事が扱う範囲はどこか

調べる場所を分けておくと、つまずいたときに迷いにくくなります。

項目 この記事で扱うか
公開前の表示確認 扱う
GitHubとの接続・pushの安全設定 扱う
pushされるブランチとPR 扱う
公開元の指定・公開URL・独自ドメイン 扱わない

公開元に選べるブランチやフォルダ、privateリポジトリから公開できる条件、反映までの時間、独自ドメインとHTTPSの設定は、この記事では扱いません。GitHub Docsの「GitHub Pages」の項目で現在の条件を確認してください。以降は、Claude Code側で押さえられる部分に絞って説明します。

Gitのコミットやブランチ操作そのものに不安がある場合は、Claude CodeのGit操作ガイドを先に読むと、以降の説明が追いやすくなります。

手元のClaude Code（CLI）からpushするには何を準備するか

手元で進める場合にここで扱う認証設定の準備は、GitHub CLI（gh）の認証と、push前に止まる設定です。後述の/web-setupを使うときも、GitHub CLIの認証が前提になります。

GitHub CLIの認証はシェルで行います。

gh auth login

次に、pushの前に確認を挟む設定を入れておくと、意図しないpushに気づきやすくなります。公式ドキュメントには、npm runは確認なしで許可し、git pushの前に確認を求め、.envの読み取りを拒否する設定例が載っています。

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)"],
    "defaultMode": "acceptEdits"
  }
}

acceptEditsは、作業ディレクトリ内のファイル作成・編集と、mkdirやmvなどの一般的なファイル操作コマンドを確認なしで行うモードです。この例ではそのモードで始めつつ、askのルールに一致するgit pushでは確認が出ます。公式の説明では、askのルールはacceptEditsやbypassPermissionsのように本来なら承認なしで進むモードでも確認を出します。評価の順序はdeny、ask、allowの順で、最初に一致したルールが適用されます。

注意点が一つあります。Bashのルールは最初の*より前を書いたとおりに照合するため、Bash(git push *)はgit -C . pushのような別の書き方には一致しないと公式に明記されています。確認を挟む設定は事故を減らす手段であって、すべてのpushを機械的に止めるものではありません。

設定をどこに書くかで効く範囲が変わります。リポジトリの.claude/settings.jsonはコミットしてチームで共有する設定、.claude/settings.local.jsonは自分だけに効く設定です。後者を手で作った場合は、自分で.gitignoreに追加します。保存したら、Claude Codeの中で/statusを実行して設定ファイルが読み込まれたか確認します。権限モードの選び方は権限モードの解説で扱っています。

クラウドセッション（Claude Code on the web）で公開するときは何が違うか

クラウドセッションは、Anthropicが管理する仮想マシン上でClaude Codeが動く使い方です。公式ドキュメントでは、Pro、Max、Teamプラン、およびpremium seatかChat + Claude Code seatを持つEnterpriseユーザーが使えるとされています。使用量はプランの上限に数えられ、クラウドの仮想マシンに別料金はかかりません。

GitHub Pages公開の観点で、手元のCLIと大きく違う点は三つあります。

一つ目は、pushされる先が「そのセッション用のブランチ」になることです。公式の説明では、Claudeは作業の区切りで自分のブランチをGitHubへpushし、利用者は差分を確認してPRを作ります。タスクごとに別のセッション、別のブランチになります。Claudeがpushするのはセッションのブランチなので、あなたが公開元に設定したブランチへ取り込みたい場合は、差分ビュー上部のCreate PRからPRを作ります。

二つ目は、gh prが使えないことです。Anthropicが管理する環境では、GitHub操作はすべて専用のプロキシを経由し、このプロキシはGitHubのGraphQLエンドポイントへのリクエストを403で拒否します。そのためgh prやgh issueは403になります。REST APIを使うgh apiやgh workflow listは動きます。PRは前述のCreate PRボタンから作ります。なお、クラウド環境にはghがプリインストールされていて、gh auth loginは不要です。

三つ目は、どのブランチにpushできるかをプロキシが制限しないことです。プロキシはブランチの削除と、タグのようなブランチ以外のpushを拒否しますが、どのブランチを更新できるかは制限しません。公式ドキュメントは、更新できるブランチを制限したい場合はGitHub側のブランチ保護ルールかrulesetsを使うよう案内しています。また、接続したGitHubアクセスが迂回できるルールはセッションのpushを止めません。公開元のブランチに直接pushされたくない場合は、GitHub側で保護しておきます。

手元のリポジトリからclaude --cloudでクラウドセッションを始める場合、Claude GitHub Appを入れたgithub.comのリポジトリなら、クラウドの仮想マシンはローカルの作業ツリーではなく、現在のブランチのGitHubリモートをcloneします。手元にだけあるコミットは先にpushしておきます。gitリモートが無い場合やApp未導入の場合は、後述のとおり手元のリポジトリがbundleでアップロードされます。クラウドセッションの全体像はClaude Code on the webの解説にまとめています。

クラウドセッションのGitHub接続はどちらを選ぶか

クラウドセッションがcloneやpushをするには、GitHubとの接続が必要です。公式ドキュメントでは方法が二つあります。

方法 接続のしかた セッションが届くリポジトリ
GitHub App ブラウザのオンボーディングでClaude GitHub Appを認可 すべてのpublicリポジトリと、Claude GitHub Appをインストールしたprivateリポジトリ
/web-setup 手元のghのトークンをClaudeアカウントへ送る ghのトークンで届くすべてのリポジトリ

普段からGitHub CLIを使っているなら/web-setupで接続できます。手順は、シェルでgh auth loginを済ませ、Claude Codeの中で/loginを実行してclaude.aiアカウントでサインインし、/web-setupを実行します。/web-setupはgh auth tokenのトークンを読み、送信してよいかを確認してからAnthropicへ送ります。APIキーでの認証はこの条件を満たしません。成功するとConnected as <GitHubユーザー名>と表示されます。

/web-setup

/web-setupはシェルではなくClaude Code CLIの中で入力するコマンドです。TeamとEnterpriseプランでは、組織のOwnerがQuick setupをオンにするまで使えないため、その場合はブラウザからGitHub Appで接続します。

認証情報の扱いについて、公式ドキュメントではGitHubの認証情報はAnthropicのサーバーで暗号化して保管され、セッションの仮想マシンには入らないと説明されています。

GitHub Actionsのワークフローを含む構成でpushが拒否されるとき

リポジトリにGitHub Actionsのワークフローファイルがあり、それを変更する場合の注意です。/web-setupで接続した場合、ghのトークンにworkflowスコープがないと、ワークフローファイルを変更するpushがGitHubに拒否されることがあると公式に書かれています。/web-setupがこの警告を出したら、シェルで次を実行してから/web-setupをやり直します。

gh auth refresh -s workflow

Claude CodeそのものをGitHub Actionsの中で動かす設定は別のテーマなので、Claude Code GitHub Actionsの設定方法を参照してください。

APIキーや.envを公開リポジトリに載せないには

GitHub Pagesで公開するリポジトリは、秘密情報を含む中身を人に見られる前提で扱う必要があります。Claude Code側でできる対策は次のとおりです。

  • 読み取りを止める: Read(./.env)やRead(./secrets/**)のようなdenyルールで、Claudeのファイルツールがそのファイルを読めないようにします。公式ドキュメントでは、.claudeignoreは効果がないためReadのdenyルールへ移すよう案内されています。
  • pushの前で止まる: 前述のaskルールでgit pushの前に確認を出し、コミット内容を見てから許可します。
  • クラウドへ送るときの扱いを知っておく: gitリモートが無いリポジトリや、Claude GitHub Appを入れていないgithub.comのリポジトリからclaude --cloudを実行すると、Claude Codeは手元のリポジトリをbundleしてアップロードします。このときmacOS、Linux、WSLでは.envや*.pemのような資格情報らしいファイルの未コミットの変更送信は行われません。対象は未コミットの変更なので、コミットに入れないこと自体が前提です。

個人利用でのセキュリティ設定全般はセキュリティ設定の解説で扱っています。

pushしたのにサイトが変わらないときはどう切り分けるか

Claude Code側で確認できる点を上から順に並べます。

  1. 変更の送信成功は確認できたか: 手元のCLIなら、askルールの確認で拒否していないか、pushのエラーが出ていないかを見ます。ワークフローファイルを含む変更なら、前節のworkflowスコープを疑います。
  2. どのブランチにpushされたか: クラウドセッションはセッション用のブランチにpushします。公開元に設定したブランチとセッションのブランチが別なら、そのブランチへ取り込まれたかを確認します。
  3. PRが作れない: クラウドセッションでgh prが403になるのはプロキシの仕様です。差分ビューのCreate PRを使います。
  4. リポジトリが選択肢に出ない: ブラウザで接続した場合、privateリポジトリはClaude GitHub Appがそのリポジトリを含む形でインストールされているときだけ表示されます。/web-setupで接続した場合は、シェルでgh repo view OWNER/REPOを実行して、GitHub CLIのログインからそのリポジトリが見えるか確認します。ghのアカウントを切り替えたなら/web-setupをやり直します。
  5. 別のリポジトリに触れようとして403になる: クラウドセッションは、セッションに紐づいたリポジトリ以外へのGitHub APIリクエストをGitHub access toで始まるメッセージの403で拒否します。触れようとしたリポジトリがセッションに紐づいているか確認します。
  6. ここまでに問題が見当たらない: 公開元の設定を、冒頭で触れたとおりGitHub Docsで確認してください。

エラーメッセージ別の調べ方はClaude Codeのエラー対処ガイドにもまとめています。

公開前に表示を手元で確かめるには

公開後の見え方の崩れはpushする前に見つけておくと手戻りが減ります。Claude Code Desktopを使っている場合、Claudeは開発サーバーを起動してBrowserペインで表示を開き、自分の変更を確認できます。起動方法の設定は、セッションを始めたフォルダの.claude/launch.jsonに保存されます。また、チャットや差分ビューに出たファイルパスはクリックで開け、HTMLのパスはBrowserペインで開きます。

同じ流れをCloudflare Pagesで組む場合はClaude CodeでCloudflare Pagesに公開する手順を参照してください。

CONTINUE THE SESSION

関連記事