Claude Code on the webは、GitHubリポジトリの作業をブラウザから依頼し、クラウド上の隔離環境で進められる機能です。ローカル環境を起動したまま待つ必要はなく、完了後にブランチやプルリクエストの差分を確認できます。
向いているのは、要件と完了条件を明確に書ける作業。READMEの更新、テストで合否を判定できる修正、範囲を限定したリファクタリングなどです。一方、途中で何度も方向を変える調査や、手元の未コミット変更を含む作業はCLI・IDE版のほうが扱いやすいでしょう。
便利だからこそ、「リポジトリを選んで一言依頼すれば終わり」では危険です。接続先、実行権限、ネットワーク、変更範囲、テスト結果、プルリクエストを人が確認できる運用にします。
Claude Code on the webとは
Web版は、Claude Codeのタスクをリモート環境へ委任する仕組みです。ブラウザでGitHubリポジトリを選び、依頼内容を入力すると、タスクごとに用意された隔離環境でリポジトリを複製し、調査・編集・コマンド実行・テストを進めます。
公式ヘルプでは、作業開始後にページを離れても処理が続くこと、複数タスクを独立した環境で並行実行できることが案内されています。ローカルへリポジトリを複製していなくても、アクセス権のあるGitHubリポジトリを対象にできる点も特徴です。
認証情報を作業環境へ直接置く構成ではありません。Anthropicの説明では、Git操作はスコープを限定した資格情報と専用プロキシを介し、対象ブランチやリポジトリを検証します。ただし、隔離されていることと、変更内容が常に正しいことは別問題。最終レビューは必要です。
CLI版とWeb版はどう使い分けるか
違いは画面ではなく、作業中に人がどれだけ関与するかです。Web版は非同期で任せる作業、CLI・IDE版は対話しながら探索する作業に向きます。
たとえば「壊れている箇所を全部直して」はWeb版向きではありません。原因も範囲も曖昧で、途中の判断が多いためです。「/api/searchのレート制限を追加し、指定した4条件のテストを通す」のように、入力と合格条件が固定された課題なら任せやすくなります。
Claude Code on the webを始める手順
設定前に対象リポジトリの状態を整えます。秘密情報を除外し、既定ブランチが正常にビルド・テストできることを確認してから接続してください。
- ClaudeのCode画面を開く
- GitHub連携を許可する
- 対象リポジトリを選択する
- 必要なセットアップコマンドを確認する
- タスクの目的・範囲・禁止事項・完了条件を入力する
- 必要な場合だけネットワークアクセスを設定する
- 実行中のログと質問を確認する
- 完了後に変更差分とテスト結果を読む
- ブランチまたはプルリクエストを人がレビューする
GitHub連携では、組織の全リポジトリへ無条件で許可を広げないこと。最初は検証用または影響の小さいリポジトリに限定し、必要になった時点で対象を追加する方が管理しやすくなります。
失敗しにくいタスク指示の書き方
Web版では、対話回数を増やさなくても判断できる依頼が強みを引き出します。最低限、目的、対象、変更しない範囲、確認コマンド、完了報告を含めます。
目的:
お問い合わせフォームのバリデーション不具合を修正してください。
対象:
- src/validation/contact.ts
- 対応するテストファイル
守ること:
- 公開APIとエラーメッセージは変更しない
- 依存パッケージを追加しない
- .envや本番設定を編集しない
完了条件:
- 空のメールアドレスを拒否する
- 正常な日本語入力を受け付ける
- npm testとnpm run lintが成功する
完了時:
- 変更ファイル、理由、テスト結果、未解決事項をまとめる「きれいにする」「最適化する」といった言葉だけでは、終了地点を判定できません。処理速度を改善したいなら測定条件、文書を更新したいなら対象範囲、バグ修正なら再現手順と期待結果を渡します。
セットアップとネットワーク権限の注意点
クラウド環境は、ローカルPCと同じ前提では動きません。依存関係、ビルド、データベース、環境変数など、作業に必要な初期化手順をリポジトリ側で再現可能にしておきます。
セットアップスクリプトへ、本番データの取得やデプロイ処理を混ぜないでください。インストールとテスト準備だけで完了する小さな手順が安全です。外部通信が必要な場合も、理由のある接続先に絞ります。
パッケージ取得のためにネットワークを許可する場合、依存関係の更新まで自由にしてよいとは限りません。ロックファイルを維持する、不要な最新版更新を禁止する、取得元を限定するなど、変更の再現性を守る条件を指示へ加えます。
秘密鍵、APIキー、顧客データをプロンプトやリポジトリへ追加するのは避けます。テストで外部サービスが必要なら、モックや専用の検証環境で置き換えられないか先に検討してください。
完了後に必ず確認する7項目
作業完了の表示は、レビュー開始の合図です。次の順番で確認すると、見た目の差分だけで承認する失敗を減らせます。
- 依頼していないファイルが変わっていないか
- 削除や設定変更が含まれていないか
- コードの理由とテスト内容が一致しているか
- テストが実行され、失敗を無視していないか
- ロックファイルや生成ファイルに不要な差分がないか
- 秘密情報や個人情報が追加されていないか
- 本番反映前に人が再現確認できるか
テストが通っていても、テスト自体が要件を確認していなければ安心できません。変更されたテストが、実装に合わせて期待値を弱めていないかも読みます。ビルドやテストを実行できなかった場合は、その理由を未解決事項として残し、承認前に別環境で実行しましょう。
複数タスクを並行実行するときのルール
Web版では複数の独立タスクを同時に進められます。ただし、同じファイルを触る課題を並行させると競合が増え、レビューも難しくなります。
分けやすいのは、ドキュメント更新と独立したテスト追加、異なる機能の小さな修正など。反対に、大規模な依存関係更新と複数機能の改修を同時に走らせると、どの変更が不具合原因か切り分けにくくなります。
各タスクには1つの目的だけを持たせ、別々のブランチとプルリクエストにします。先に基盤となる変更を統合し、後続タスクは最新の既定ブランチから開始する流れが無難です。
向かない作業と止める判断
本番データの直接変更、権限設計が不明なデプロイ、要件の定まらない全面改修は、最初のWeb版タスクに向きません。実行環境から再現できない手作業が多い案件も同様です。
途中経過を見て「結果を見ないと次を決められない」と感じたら、CLI・IDE版へ切り替える判断をします。公式ヘルプでは、途中で細かな誘導が必要になった場合にCLIで開く選択肢も案内されています。
Web版かCLI版かは優劣ではなく、作業の形で選ぶもの。非同期に任せるための条件が整っていないなら、先に要件とテストを整えることが最短ルートです。
よくある質問
ローカルにリポジトリがなくても使えますか
GitHub上でアクセス権があるリポジトリなら、ローカルへ複製していない場合も対象にできます。組織のGitHubアプリ承認やリポジトリ制限がある場合は、管理者の設定を確認してください。
ページを閉じても作業は続きますか
公式ヘルプでは、開始後にページを離れてもリモート環境で処理が続くと説明されています。戻ったらログ、変更差分、テスト結果を確認します。
同じリポジトリで複数タスクを実行できますか
可能ですが、同じファイルを変更するタスクは競合しやすくなります。目的と対象ファイルを分け、別ブランチでレビューしてください。
完了した変更をそのまま本番へ出してよいですか
いいえ。プルリクエストで人が差分を読み、テストと検証環境で確認してから通常の承認手順へ進めます。AIの完了判定をデプロイ承認の代わりにしないでください。
Web版なら秘密情報を渡しても安全ですか
隔離環境と資格情報保護の仕組みはありますが、不要な秘密情報を渡さない原則は変わりません。リポジトリ、プロンプト、ログへAPIキーや顧客情報を入れず、必要な場合は専用の秘密管理と最小権限を使います。
まとめ
Claude Code on the webは、GitHub上の明確な作業をクラウドへ委任し、後から差分をレビューする使い方に適しています。成功の鍵は、AIへ広く任せることではなく、対象範囲と合格条件を狭く正確に書くことです。
最初は、READMEの更新や小さなテスト追加など、失敗しても戻しやすい課題を1件選んでください。変更しない範囲、実行するテスト、完了時の報告形式まで指定し、プルリクエストを人が確認する。これが安全な第一歩です。
コメント