Claude CodeでCloudflare Pagesへデプロイする権限とスキル設定

Claude CodeでCloudflare Pagesにサイトを公開するとき、決めるべきことは「Claudeにどこまで自動で実行させ、どこで人の判断に戻すか」です。Claude Codeから見ると、デプロイはBashツールで実行するシェルコマンドの一つです。そのため、ビルドは許可ルールで任せ、デプロイコマンドは確認（ask）ルールか、Claudeが自分では起動できない /deploy スキルに閉じ込め、.env は読み取り禁止にする。この3点は、Claudeが打つ通常のデプロイコマンドには確認を求め、デプロイ用スキルの自己起動を防ぎ、ファイルツールによる .env の読み取りを止める設定です。どんなコマンド経路でも防げるわけではない点は、後の節で整理します。

この記事はClaude Code側の設定に絞ります。Cloudflare Pagesのプロジェクト作成、デプロイ用CLIのコマンドと認証、独自ドメインやビルド設定の画面操作は、この記事の対象外です。ここではそのコマンドを「デプロイコマンド」と呼び、具体名は書きません。

Claude CodeはCloudflare Pagesへのデプロイをどう実行するのか？

Claude Codeは、ファイルの読み書きやシェルコマンドの実行をツールとして行います。Cloudflare Pagesへの公開も、Claudeがデプロイコマンドを打つ以上はBashツールの呼び出しとして扱われます。

公式の権限表では、ツールごとに承認の要否が次のように決まっています。

ツールの種類	承認が要るか	「今後は聞かない」を選んだ場合
読み取り（ファイル読み込み、Grep）	作業ディレクトリ内なら不要	対象外
Bashコマンド	必要（組み込みの読み取り専用コマンドを除く）	リポジトリとコマンドの組み合わせ単位で恒久的に保存
ファイル変更（Edit/Write）	必要	セッション終了まで

ここで押さえたいのは表の右列です。Cloudflare Pagesのデプロイコマンドの確認画面で「Yes, and don’t ask again」を選ぶと、その承認は .claude/settings.local.json に許可ルールとして保存され、同じリポジトリの今後のセッションに効きます。最初の一回を気軽に恒久許可すると、以後は一致する deny や ask が無い限り、そのallowに一致するデプロイコマンドは確認なしで実行されます。デプロイコマンドは毎回その場で一回限りの「Yes」を選ぶか、次の節のように最初から ask ルールにしておくのが安全です。

もう一つ、公式は権限ルールについて、モデルではなくClaude Codeが強制するものだと明記しています。プロンプトやCLAUDE.mdに「本番デプロイは勝手にしないで」と書いても、それはClaudeの行動を方向づけるだけで、Claude Codeが定める実行範囲は変わりません。止めたい操作はCLAUDE.mdではなく、権限ルール・スキル・フックのどれかで止めます。

ビルドは任せてデプロイだけ止める権限ルールはどう書くのか？

Claude Codeの権限ルールには3種類あります。allow は承認なしで実行、ask は毎回確認、deny は実行させない、です。権限評価の順序は deny → ask → allow で、最初に一致したものが結果になり、ルールの具体性では順序が変わりません。ask と、より狭い allow が両方一致する場合も、ask の確認が出ます。

公式の設定例は、lintとテストを承認なしにし、.env を読ませない形です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Cloudflare Pagesに出すサイトなら、これに「ビルドコマンドを allow」「デプロイコマンドを ask」を足すのが基本形です。書き方の要点は次のとおりです。

Bash(npm run build) は npm run build との完全一致です。Bash(npm run *) にすると npm run build や npm run test --watch に一致し、npm install には一致しません。
* はサブコマンドの後ろに置きます。* より前の語が書いたとおりに一致するので、そこが許可範囲の上限になります。Bash(git *) はgitの全コマンドを許可してしまいます。
デプロイコマンドは ask に入れます。ask は allow より先に評価されるため、広い allow ルールがあっても確認画面が出ます。

npx経由のデプロイコマンドは特に注意する

デプロイ用CLIを npx で呼ぶ場合は注意が要ります。公式によると、Claude Codeは timeout や nohup などのラッパーを剥がしてから照合しますが、npx はその対象に含まれません。さらに公式は、引数をコマンドとして実行するランナーについて、Bash(devbox run *) のようなルールが run の後ろの何にでも一致してしまうと注意し、ランナーと内側のコマンドの両方を含む具体的なルールを書くよう勧めています。

つまり npx 全体を allow にするのは避け、許可するなら「npx＋特定のコマンド」まで書いたルールにします。デプロイを確認制にしたい場合も、ask ルールはデプロイコマンドを特定できる形で書きます。

ルールは「いつもの書き方」を止めるだけと理解しておく

公式は、Bashルールがコマンドの文字列に対して一致するもので、プログラムそのものを囲うセキュリティ境界ではないと説明しています。例えば Bash(git push *) を deny にしても、git -C . push origin main のような別の書き方は止まりません。&& でつないだ複合コマンドについては、allow は各サブコマンドが個別に一致する必要があり、deny と ask はどれか一つのサブコマンドに一致すれば効きます。

コマンドの書き方に左右されずに止めたいなら、公式はファイルシステムとネットワークの制御にサンドボックス、コマンド全文を自分のロジックで検査するならPreToolUseフックを使うよう案内しています。設定の詳細はClaude Codeのサンドボックス設定とClaude Codeのフック活用ガイドに分けています。

個人用とチーム用、どのsettingsファイルに書けばいいのか？

ルールを書く場所で、効く範囲が変わります。

書く場所	効く範囲	向いている内容
`~/.claude/settings.json`	自分の全プロジェクト	個人の好み、自分用の権限ルール
`.claude/settings.json`	そのフォルダで作業する全員（gitにコミットして共有）	チームの権限、フック、プラグイン
`.claude/settings.local.json`	自分のこのプロジェクトだけ	個人的な上書き、共有前の試験

デプロイを確認制にするルールや .env の deny は、チーム全員に効かせたいので .claude/settings.json に書いてコミットするのが筋です。.claude/settings.local.json は、Claude Codeが自分で作成した場合はgitの管理外に置かれますが、手で作った場合は自分で .gitignore に追加する必要があります。

Claude Codeの設定ファイルは厳格なJSONで、// コメントや末尾のカンマがあると構文エラーとして扱われます。保存したら /status を開き、Setting sources の行に該当ファイルが並んでいるかを確認します。どのルールがどのファイルから来ているかは /permissions で一覧できます。settingsの変更は、permissions やフックも含めて実行中のセッションに再読み込みされるため、多くの場合は再起動が要りません。ファイル全体の構成はsettings.jsonの書き方で扱っています。

APIトークンや.envをClaudeに読ませないにはどうするのか？

デプロイ用の認証情報を扱う場合、トークンを .env などに置く場合は、Read の読み取り拒否ルールを使ってClaudeのファイル読み取りツールから外します。公式の例は Read(./.env) や Read(./secrets/**) です。上の公式設定例には Read(./.env) とあわせて Read(./.env.*) も含まれています。

勘違いしやすい点が一つあります。プロジェクトに .claudeignore を置いても効果はありません。公式は、その中身を Read の deny ルールへ移すよう案内しています。

編集も止めたい場合は、PreToolUseフックが使えます。公式ガイドには、Edit と Write のツール呼び出しの前にスクリプトを走らせ、.env などの保護対象パターンに一致したら終了コード2で編集をブロックする例があります。ブロックの理由はClaudeにフィードバックとして返るので、Claudeは進め方を調整できます。

トークンの値はチャットに貼らず、Cloudflare側の設定画面やgitの管理外のファイルで扱い、Claudeには変数名だけを伝える運用にしておくと、上のルールと矛盾しません。

デプロイ手順を/deployスキルにしてClaudeに勝手に実行させないには？

Cloudflare Pagesのデプロイ手順を毎回プロンプトで説明する代わりに、スキルにまとめておけます。.claude/skills/deploy/SKILL.md を置くと /deploy というコマンドとして呼び出せます。

公式がデプロイ用に勧めているのが disable-model-invocation: true です。これを付けたスキルはClaudeが自分の判断で起動できません。公式は、副作用があるワークフローやタイミングを自分で決めたいワークフロー、例えば /deploy に使うものだと説明し、コードが整って見えたからといってClaudeにデプロイを決めさせたくはない、という趣旨を添えています。

公式のdeployスキル例はこうです。

---
name: deploy
description: Deploy the application to production
disable-model-invocation: true
---

Deploy $ARGUMENTS to production:
1. Run the test suite
2. Build the application
3. Push to the deployment target
4. Verify the deployment succeeded

$ARGUMENTS には /deploy の後ろに付けた引数が入ります。Cloudflare Pagesに出すなら、3の「Push to the deployment target」を採用するデプロイ手順に、4を公開URLの表示確認に書き換えます。手順本文は短く保ちます。公式によると、スキルの内容は読み込まれた後もターンをまたいでコンテキストに残るためです。

このスキルを付けておくと、Claudeがスキルを起動しようとしてもClaude Codeが呼び出しをブロックし、同じ手順を別の方法で再現しないよう指示します。結果としてClaudeは、/deploy を人が実行するよう促す形になります。

allowed-toolsで確認を省くのは、そのターンだけ

スキルのfrontmatterに allowed-tools を書くと、そのスキルを呼んだターンの間だけ、列挙したツールを確認なしで使わせられます。次にメッセージを送ると許可は解除されます。セッション全体ではなく、スキルを呼んだそのターンに限った事前承認です。既存の ask や deny ルールとの優先関係は、使う前に公式の該当ページで確認してください。また公式は、リポジトリにコミットされたスキルの allowed-tools は、そこでClaude Codeを動かす前に確認するよう注意しています。スキル全般の作り方はClaude Codeのスキル活用ガイドにまとめています。

CLAUDE.mdには何を書けばいいのか？

公式は、CLAUDE.mdを毎セッションでClaudeが持っておくべき事実の置き場としています。具体的にはビルドコマンド、規約、プロジェクト構成、「常にXをする」というルールです。複数手順の手順書や、コードベースの一部だけに関わる内容は、スキルやパス単位のルールに移すよう勧めています。

Cloudflare Pagesに出すプロジェクトなら、CLAUDE.mdに置くのは次のような短い事実です。

ビルドに使うコマンド
ビルド結果が出力されるディレクトリ
デプロイは /deploy から人が起動する、という運用の一文

デプロイの手順そのものはCLAUDE.mdではなく前の節のスキルに置きます。CLAUDE.mdの「勝手にデプロイしない」は行動の方向づけにとどまり、実行を止める仕組みではない点は先に書いたとおりです。読み込まれているかは /context を開き、Memory files の一覧で確認します。書き方の全体はCLAUDE.mdの書き方で扱っています。

デプロイが止まった・通らないときはどこから確認するのか？

ここではClaude Code側の権限ルールと設定の読み込みを、症状ごとに確認します。

毎回確認が出て止まる。 allow ルールが一致していない可能性があります。/permissions で実際に読み込まれているルールを見て、コマンドの書き方と照らし合わせます。&& でつないだ複合コマンドは、各部分がそれぞれ allow に一致しないと確認が出ます。npx経由なら、npxとコマンドの組み合わせまで書いたルールになっているかを見ます。確認画面に一回限りの承認しか出ないこともあります。公式によると、保存されるルールが許可する範囲を画面で示し切れない場合で、そのときは /permissions から自分でルールを追加します。

ask にしたはずのデプロイが確認なしで通った。 まずsettingsファイルが読み込まれているかを /status の Setting sources で確認します。JSONの構文エラー（コメント、末尾カンマ）があると、そのファイルはSettings Errorとして報告されます。読み込まれている場合は、/permissions で ask ルールが実際にどのファイルから有効になっているかを確かめ、Claudeが打ったコマンドの文字列がそのルールに一致しているかを見ます。ルールは文字列の一致なので、別の書き方は ask に一致せず、そのとき一致する allow があれば確認なしで通ります。一致する ask があれば、allow が残っていても確認が出ます。

/deploy を打ってもスキルが出てこない。 ファイルの置き場所が .claude/skills/deploy/SKILL.md になっているか、frontmatterの name を確認します。

デプロイコマンド自体がエラーで終わる。 権限ルール以外のエラーは、まず出力されたメッセージを確認します。Cloudflare固有の設定はこの記事の対象外です。自分でコマンドを打って結果を見たいときは、入力の先頭に ! を付けるシェルモードが使えます。Claudeを通さずにコマンドを直接実行し、出力は会話に追加されるので、そのままClaudeにエラーの読み解きを頼めます。公式の例は次のような形です。

! npm test

GitHub経由で公開する場合はどこが変わるのか？

ここまではローカルのClaude Codeからデプロイコマンドを打つ前提でした。GitHubへのpushを公開の起点にする構成では、Claude Codeが握るのは「pushするかどうか」になり、Bash(git push *) を ask か deny にする設計が中心になります。GitHub側で自動化する場合の権限設計はClaude CodeのGitHub Actions活用ガイド、GitHub Pagesに出す場合はClaude CodeでGitHub Pagesに公開する手順を参照してください。

この記事のClaude Code側の仕様は、2026年10月18日に取得したClaude Code公式ドキュメント（権限、settings、スキル、メモリ、フック、インタラクティブモードの各ページ）の記述に基づいています。導入時は公式の該当ページで現在の記述を確認してください。チームでの運用ルールづくりから相談したい場合は、研修の選び方やトレーニングのご案内もあわせてご覧ください。