【Claude Code 連載 第26回】ウェブ上の Claude Code を使用する(claude-code-on-the-web / 完全リファレンス)

スポンサーリンク
【Claude Code 連載 第26回】ウェブ上の Claude Code を使用する(claude-code-on-the-web / 完全リファレンス) 用語解説
【Claude Code 連載 第26回】ウェブ上の Claude Code を使用する(claude-code-on-the-web / 完全リファレンス)
この記事は約12分で読めます。
よっしー
よっしー

こんにちは。よっしーです(^^)

スポンサーリンク

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

一言でいうと何か

第25回の入門で扱った「ウェブ上の Claude Code」の詳細リファレンスです。GitHub 認証の2つの方法、クラウド環境で何が引き継がれ何が引き継がれないか、セットアップスクリプトとキャッシュ、ネットワークアクセスの制御、--cloud/--teleport によるウェブとターミナル間のセッション移動、セッション操作、プルリクエストの自動修正(Auto-fix)、セキュリティ、制限事項までを一通りカバーします。実運用でクラウドセッションを使い込むための設定・仕組みの解説がまとまっています(研究プレビュー段階)。

どういう場面で役立つか

クラウド環境を自分やチームに合わせて整えたいとき。環境ごとにネットワークアクセスレベル・環境変数・セットアップスクリプトを設定でき、Team/Enterprise では組織共有環境で標準化もできます。

ターミナルとウェブを行き来して作業したいとき。--cloud でターミナルからクラウドセッションを起動し、--teleport でクラウドセッションをローカルに引き込んで続行できます。プランはローカルで練り、実行はクラウドに投げる、といった使い分けができます。

PR を投げた後の CI 失敗やレビューコメントに自動で対応させたいとき。Auto-fix を有効にすると、Claude が PR の GitHub イベントを購読し、明確なものは調査して修正をプッシュします。

不要・向かないケース:大規模ビルドやメモリ集約的なテストなど、クラウドのリソース上限(概算で 4 vCPU・16 GB RAM・30 GB ディスク)を大きく超える作業は失敗・終了しうるため、その場合は Remote Control で自前ハードウェアを使うほうが向きます。GitHub が必須で、GitLab・Bitbucket など非 GitHub はローカルバンドルとして送れてもプッシュバックはできません。Zero Data Retention 有効の組織や、Anthropic ホストを除外していない IP 許可リスト運用の組織では利用できません。

設定と仕組みの実例

前提条件・リソース制限

利用対象は Pro・Max・Team、およびプレミアムシートまたは Chat + Claude Code シートを持つ Enterprise(研究プレビュー)。リソースは概算で 4 vCPU・16 GB RAM・30 GB ディスクで、時間とともに変わりえます。レート制限はアカウント内の他の Claude/Claude Code 利用と共有で、並列タスクほど多く消費します(クラウド VM への個別課金はなし)。

GitHub 認証の2つの方法

クラウドセッションはクローンとブランチプッシュのため GitHub アクセスが必要で、2通りあります。ひとつは Claude GitHub App を認可する方法(ブラウザオンボーディング向け。Auto-fix の PR webhook にはこの App が必須)、もうひとつはターミナルで /web-setup を実行してローカルの gh トークンを同期する方法(すでに gh を使う個人開発者向け)です。重要な注意として、どちらの方法でも、クラウドセッションは App がインストールされたリポジトリだけでなく、接続 GitHub アカウントが見られる全リポジトリにアクセスできます。到達範囲を絞るには GitHub 側でアカウントのチーム/リポジトリメンバーシップを制限します。

クラウド環境で引き継がれるもの・引き継がれないもの

各セッションはリポジトリを新規クローンした VM で動くため、リポジトリにコミットされたものは使え、自分のマシンにだけある設定は使えません。具体的には、リポジトリ内の CLAUDE.md.claude/settings.json のフック・.mcp.json.claude/rules/.claude/skills/.claude/agents/.claude/commands/、および .claude/settings.json で宣言したプラグインは引き継がれます。一方、ユーザースコープの ~/.claude/ 配下(CLAUDE.md・skills・agents・commands)、ユーザー設定だけで有効なプラグイン、claude mcp add で入れた MCP サーバー、静的 API トークン、AWS SSO のような対話ログインは引き継がれません。要するに「クラウドで使いたい設定はリポジトリにコミットする」が原則です。組織ポリシーはサーバー管理設定として別途届きます。専用のシークレットストアはまだ無く、環境変数やセットアップスクリプトは環境を編集できる全員に見えるため、その前提で扱います。

インストール済みツールとサービス

クラウドセッションには主要言語ランタイム(Python・Node.js・Ruby・PHP・Java・Go・Rust・C/C++)、Docker、データベース(PostgreSQL 16・Redis 7.0)、各種ユーティリティがプリインストールされています(正確なバージョンはセッション内で check-tools を実行。このコマンドはクラウド専用)。全カテゴリの一覧は公式ページを参照してください。データベースは既定で起動していないため、必要ならセッション中に開始を依頼します。

service postgresql start

Redis も同様に service redis-server start で開始します。Docker も使え、docker compose up でプロジェクトのサービスを起動できます(イメージ取得は環境のアクセスレベルに従い、キャッシュ対象)。なお gh CLI はプリインストールされておらず、組み込み GitHub ツールで足りない場合はセットアップスクリプトで導入します。

セットアップスクリプトとキャッシュ

セットアップスクリプトは、新しいクラウドセッション開始時に Claude Code 起動前へ走る Bash スクリプトで、依存関係の導入やツール設定に使います(Ubuntu 24.04 上で root 実行)。環境設定ダイアログの Setup script 欄に入力します。

#!/bin/bash
apt update && apt install -y gh

このスクリプトはプリインストールされていない gh CLI を入れる例です。ゼロ以外で終了するとセッション開始に失敗するため、非必須コマンドには || true を付けます。実行結果はスナップショットとしてキャッシュされ、以降のセッションはこのステップをスキップして高速に始まります(キャッシュはファイルのみ保存し、起動中のプロセスやサービスは保存しないため、サービス起動はセッションごとに行う)。総実行時間は約5分以内に収めるのが目安で、独立インストールは &wait で並列化し、単発で長いダウンロードは SessionStart フックへ移してバックグラウンド起動にします。キャッシュはスクリプトや許可ホストの変更時、および約7日での期限到達時に再構築されます。

なお「クラウドにだけ必要なもの」はセットアップスクリプト、「ローカルとクラウド両方で要るプロジェクトセットアップ(npm install 等)」はリポジトリの .claude/settings.json の SessionStart フックへ、と使い分けます(フック内で CLAUDE_CODE_REMOTEtrue かを見てローカル実行をスキップできます)。

ネットワークアクセス

環境ごとにアウトバウンド接続のアクセスレベルを1つ選びます。None(接続なし)、Trusted(許可リストのドメインのみ=パッケージレジストリ・GitHub・クラウド SDK)、Full(任意)、Custom(独自の許可リスト、既定を含めるか選択可)。既定は Trusted です。Custom では *. でワイルドカードサブドメイン指定ができます。Trusted の既定許可ドメインは、Anthropic サービス・各種バージョン管理・コンテナレジストリ・クラウド各社・主要言語のパッケージマネージャー・Linux ディストリ・監視サービスなど広範に及びます(全リストは公式ページ参照)。GitHub 操作はこの設定とは独立した専用の GitHub プロキシを通り、認証情報をサンドボックス外に保ちつつ、push は現在の作業ブランチに制限されます。すべてのアウトバウンドはセキュリティプロキシを経由し、レート制限・コンテンツフィルタ・DNS レベルの監査証跡が働きます。

ウェブとターミナル間のセッション移動

これらは Claude Code CLI が同じ claude.ai アカウントでサインインしていることが前提です。ハンドオフは一方向で、クラウド→ターミナルは引ける一方、既存のターミナルセッションをウェブへ押し出すことはできません。ターミナルから新しいクラウドセッションを作るには --cloud を使います。

claude --cloud "Fix the authentication bug in src/auth/login.ts"

これは claude.ai 上に新しいクラウドセッションを作り、現在ディレクトリの GitHub リモートを現在ブランチでクローンします(VM は GitHub からクローンするので、ローカルコミットは先にプッシュ)。--cloud は一度に1リポジトリで、複数実行すればそれぞれ独立セッションとして並列に走ります。進捗は CLI の /tasks で監視できます。複雑なタスクはローカルのプランモード(claude --permission-mode plan)で方針を固め、プランをコミット/プッシュしてから --cloud で自律実行、という分業も推奨されています。

逆にクラウドセッションをターミナルへ引き込むには --teleport を使います。

claude --teleport

引数なしなら対話的なセッションピッカーが出て、claude --teleport <session-id> で特定セッションを直接再開します(CLI 内では /teleport または /tp)。テレポートは正しいリポジトリの確認、クラウド側ブランチのフェッチとチェックアウト、会話履歴の読み込みを行います。実行には、クリーンな git 状態(未コミット変更があればスタッシュを求められる)、同一リポジトリのチェックアウト、ブランチがリモートにプッシュ済みであること、同一 claude.ai アカウントでの認証、が必要です。--resume(ローカル履歴の再開)とは別物です。

GitHub 未接続のリポジトリから --cloud を実行すると、ローカルリポジトリをバンドルしてアップロードするフォールバックが自動で働きます(GitHub 接続時でも強制するなら CCR_FORCE_BUNDLE=1)。

CCR_FORCE_BUNDLE=1 claude --cloud "Run the test suite and fix any failures"

バンドルは1コミット以上・100 MB 未満などの制約があり、追跡外ファイルは含まれず、GitHub 認証も無いとリモートへプッシュバックできません。

セッション操作と Auto-fix

セッションは claude.ai/code のサイドバーに並び、diff 確認・共有・アーカイブ・削除ができます。共有の可視性は、Enterprise/Team では Private/Team、Max/Pro では Private/Public です。特に Max/Pro の Public は claude.ai ログインユーザー全員に見え、リポジトリアクセス検証が既定で無効かつ機密コード/認証情報を含みうるため、共有前の確認が要ります。組み込みコマンドはテキスト出力を返す形で使え、/model などは引数で値を渡し、/config はウェブでは値設定ではなく設定表示になります。

Auto-fix は、PR の CI 失敗やレビューコメントに Claude が自動応答する PR 単位の機能です(Claude GitHub App のインストールが必要)。有効化はウェブの CI ステータスバー、ターミナルの /autofix-pr、モバイルからの指示、既存 PR の URL 貼り付けなど複数経路があります。Claude は明確な修正はプッシュし、曖昧なリクエストは確認し、無アクションは記録します。ベースブランチ前進によるマージコンフリクトは webhook が出ないため自動対応できず、リベースを依頼します。返信は自分の GitHub アカウントで投稿されますが Claude Code 由来とラベル付けされます。コメントトリガーの自動化(Atlantis・Terraform Cloud 等)があるリポジトリでは、特権操作を誘発しうるため有効化前に確認が必要です。

セキュリティと制限

各セッションは分離 VM で動き、ネットワークは既定で制限、機密認証情報はサンドボックス外でスコープ付きプロキシ経由、という多層分離です。制限としては、レート制限の共有、同一アカウントでのみウェブ→ローカル移動可、GitHub 必須(自己ホストの GitHub Enterprise Server は Team/Enterprise でサポート)、そして組織が IP 許可リストを使う場合はクラウドセッションが認証エラーで失敗する(Anthropic ホストの除外が必要)点が挙げられます。トラブルシューティングでは、セッション作成失敗はステータス確認・再試行・リポジトリ到達性確認、テレポート系の認証エラーは /login での再認証、環境の期限切れは claude.ai/code から開き直して新環境をプロビジョニング、と案内されています。

まとめ

このリファレンスは、ウェブ上の Claude Code を実運用で使い込むための設定と仕組みを網羅しています。GitHub 認証は App か /web-setup の2通り、クラウドで使いたい設定はリポジトリにコミットするのが原則、セットアップスクリプトとキャッシュで起動を速く保ち、ネットワークは環境ごとのアクセスレベルで制御します。--cloud でターミナルからクラウドへ、--teleport でクラウドからターミナルへ移動でき、Auto-fix で PR の CI 失敗やレビューに自動対応させられます。リソース上限を超える作業や非 GitHub 運用、IP 許可リスト・ZDR 組織では制約がある点に注意します。

次回は、このページの関連リソースにも挙がっている未執筆ページ(たとえば Routines〈自動化〉や ultraplan/ultrareview など)を取り上げる予定です。


この記事は執筆時点の公式ドキュメントに基づいています。最新の情報は必ず公式ドキュメントをご確認ください。

よっしー
よっしー

何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。

それでは、また明日お会いしましょう(^^)

コメント

タイトルとURLをコピーしました