ウェブ上のClaude Codeはリモートでタスクを実行し、GitHubリポジトリのコードを操作します。この記事では、その仕組み、ターミナルやIDEでClaude Codeを実行する代わりに使用する場合、および有効にするワークフローについて説明します。
ウェブ上のClaude Codeが提供するもの
ウェブ上のClaude Codeを使用すると、アクティブな監視なしで実行されるタスクをClaudeに委任できます。ブラウザでGitHubリポジトリを選択し、実行したい内容を説明すると、Claudeはリモート環境でタスクに取り組みます。Claude Codeがタスクの実行を開始したら、ページを完全に離れることができます。Claudeは作業を続けます。完了すると、Claudeは自動的にレビュー用の変更を含むプルリクエストを作成します。
この機能は、ローカルマシンにない可能性があるリポジトリで機能します。ローカルにクローンしたり、開発環境をセットアップしたりする必要なく、アクセス権のあるGitHubリポジトリでタスクを開始できます。これは、時々貢献するプロジェクトや、まだ学習中のコードベースを探索する場合に便利です。
ウェブ用Claude Codeは非同期開発ワークフローを実現します。ターミナルまたはエディタでClaude Codeを使用する場合、通常は同期的に作業します。リクエストを行い、Claudeの応答を待ち、変更をレビューしてから、別のリクエストを行います。このような同期的な作業は細かい制御を提供しますが、プロセス全体を通じて注意が必要です。ウェブ上のClaude Codeは異なる方法で処理します。より大きなタスクを割り当て、Claudeが独立して作業するようにして、後で完了した作業をレビューするために戻ることができます。
複数のタスクを並行して実行することもできます。各タスクは独立した環境で実行されるため、Claudeが複数の異なる問題またはリポジトリで同時に作業できます。各タスクは独立して進行し、完了時に独自のプルリクエストを作成します。複数のタスクが同時に同じリポジトリで作業できます。
仕組み
タスクを開始すると、ウェブ上のClaude Codeは作業用の分離された仮想マシンを作成します。GitHubリポジトリはこの環境にクローンされ、一般的な開発ツールと言語エコシステムが事前に構成されています。
Claudeはリポジトリの設定で定義したセットアップコマンドを実行して環境を準備します。これには、依存関係のインストール、データベースのセットアップ、またはプロジェクトが必要とする他の初期化ステップが含まれます。タスクがネットワークアクセスを必要とする場合、パッケージをインストールしたりデータを取得したりするために、環境が持つインターネットアクセスのレベルを設定できます。
環境の準備ができたら、Claudeはタスクの実行を開始します。Claudeはコードを読み、変更を加え、テストを書き、コマンドを実行して作業を検証します。必要に応じて、ウェブインターフェースを通じて進捗を監視し、ガイダンスを提供できます。
Claudeがタスクを完了すると、変更をGitHubリポジトリの新しいブランチにプッシュします。通知を受け取り、変更をレビューしてから、インターフェースから直接プルリクエストを作成できます。プルリクエストにはClaudeのすべての作業が含まれており、レビューと追加の変更の準備ができています。
各タスクは完全に分離された状態で実行されます。仮想マシンはその特定のタスクのためだけに存在し、ネットワークアクセスの制限と保護された認証情報の処理などのセキュリティ制御が含まれています。GitHub認証はセキュアプロキシを通じて管理されるため、認証情報はClaudeが作業している環境に直接存在することはありません。
ウェブ上のClaude Codeとターミナルの使い分け
ウェブ上のClaude Codeはクラウドコードを操作する新しい方法です。一部のタスクはウェブでの非同期実行に適していますが、他のタスクはターミナルまたはIDEを通じてClaude Codeで実行するのが最適です。
ウェブ上のClaude Codeを使用する場合：
明確な要件を持つ明確に定義されたタスク：実行する必要があることを正確に説明でき、タスク中にClaudeを操舵する必要がないと予想される場合、ウェブインターフェースを使用すると、作業を開始して完了時に戻ることができます。
バグバックログの背景作業：バックログから複数の問題をClaudeに割り当て、並行して実行させることができます。各タスクは独立して進行し、各タスクを個別に監視することなく、複数の修正に同時に対処できます。
ローカルにないリポジトリ：クローンしていないリポジトリまたはマシンにセットアップしたくないリポジトリに変更を加える必要がある場合、ウェブ上のClaude Codeが環境セットアップを処理します。
キューに入れたいタスク：実行する変更のリストがあるが、今すぐ作業したくない場合、ウェブでタスクを開始して、後で結果をレビューできます。これにより、同様の作業をバッチ処理したり、他のことに集中している間にタスクを委任したりできます。
ターミナル/IDEでClaude Codeを使用する場合：
頻繁なコース修正が必要なタスク：正しいアプローチが正確に何であるかが不確かな場合、または見たものに基づいてClaudeをリダイレクトする必要があると予想される場合、ターミナルで作業すると即座のフィードバックが得られます。Claudeが作業する際に方向を調整でき、完全な結果を待つ必要はありません。
要件が不明確な探索的作業：問題の解決方法を理解しているか、異なるアプローチを調査している場合、ターミナルを使用すると、学習に応じてリクエストを改善できます。やり取りは、最初は明らかでなかった要件を明確にするのに役立ちます。
コミットされていない変更を伴うローカル開発：アクティブに開発していて、ローカルリポジトリにコミットされていない作業がある場合、ターミナルでClaude Codeを使用すると、すべてが1か所に保たれます。準備ができていない作業をコミットまたはプッシュする必要なく、変更を迅速に反復できます。
即座のフィードバックが必要なタスク：結果をすばやく確認したい場合、迅速に反復したい場合、ターミナルはより低いレイテンシを提供します。Claudeがリアルタイムで作業するのを見ることができ、プロセスの早い段階で何か問題が発生した場合は停止またはリダイレクトできます。
ユースケース例
テスト駆動開発によるバックエンド変更
Claudeに期待される動作を定義するテストを書かせ、それらのテストに合格するコードを実装させます。これは、自動テストを通じて動作を検証できるバックエンド変更に特に適しています。
プロンプト例：
/api/searchエンドポイントにレート制限を追加します。
レート制限は以下を行う必要があります：
- APIキーごとに1分あたり100リクエストを許可
- 制限を超えた場合は429ステータスを返す
- 60秒後に制限をリセット
- 異なるAPIキーを独立して追跡
TDDアプローチを使用します。まず包括的なテストを書き、次にそれらに合格するレート制限ロジックを実装します。
このアプローチを使用する場合：テストがClaudeに向かって作業する明確な検証基準を提供するため、これはウェブで適切に機能します。テストが問題をキャッチし、作業中のソリューションへの反復をガイドするため、Claudeの進捗を監視する必要はありません。Claudeがテストを書いてから合格させるという自己完結的なタスクの性質は、開始後の入力を必要としません。
これが効果的な理由：Claudeはテスト失敗を使用して問題を特定し、修正することで、監視なしに実装を反復できます。タスクは単純なコード変更よりも長く実行されますが、バックグラウンドで完了させることができます。プルリクエストをレビューするとき、テストと実装の両方が準備でき、テストが合格するため、ソリューションが機能することに確信があります。
ドキュメント更新
READMEファイル、APIドキュメント、コードコメント、ユーザーガイドなどの技術ドキュメントを生成または更新します。
プロンプト例：
v2.3.0リリース以降のすべての変更でCHANGELOG.mdを更新します：
- そのタグ以降のメインブランチのコミットをレビュー。
- 変更を「追加」「変更」「修正」「削除」セクションに分類。
- 各エントリのコミットハッシュを含める。
このアプローチを使用する場合：Claudeがコミット履歴を独立してレビューし、ガイダンスなしでエントリをフォーマットできるため、変更ログの更新はウェブに適しています。タスクは手動で実行するのは退屈ですが、Claudeがどのコミットを含めるか、またはそれらをどのように分類するかについての質問なしに完了するのに十分簡潔です。
これが効果的な理由：変更ログ全体の更新を委任し、完了時に結果をレビューできます。Claudeはコミットを読み取り、意味のある変更を抽出し、既存の変更ログ形式に従います。
明確なスコープでのリファクタリング
変更の明確な境界を定義できる場合、コードを再構成して組織化または読みやすさを向上させます。これには、コードの抽出、大きなファイルの分割、またはモジュール構造の整理が含まれます。
プロンプト例：
/src/services/user.goのUserServiceクラスは800行の長さです。
3つの焦点を絞ったサービスに分割します：
- UserAuthService（ログイン/ログアウト/セッション）
- UserProfileService（プロファイルCRUD操作）
- UserPreferencesService（設定/環境設定）
すべてのテストが引き続き合格することを確認します。
このアプローチを使用する場合：明確な制約を持つリファクタリングは、明確な境界を設定してClaudeが従うことができるため、ウェブで適切に機能します。テストスイートは検証を提供し、Claudeがリファクタが既存の機能を破壊しなかったことを確認できます。
これが効果的な理由：タスクは時間がかかりますが、構造が定義されたら、アクティブな入力を必要としません。リファクタを開始して、Claudeが作業を進める際に監視するのではなく、後で整理された結果をレビューできます。明確なスコープは、Claudeがタスク中にガイダンスを必要とする可能性が低いことを意味します。
効果的な使用のためのヒント
Claudeがタスクを正常に完了したことをより簡単に検証できるように、リポジトリにテストスイートを追加することを検討してください
「改善」や「修正」のような曖昧な目標ではなく、成功基準を指定します
プロンプトで何が変わるべきか、何が同じままであるべきかを定義します
Claudeがタスク中にガイダンスを必要としないように、明確な境界を持つタスクをスコープします
「まずこれがどのように進むかを見る必要があります」と考えている場合は、代わりにターミナルの使用を検討してください
タスク中にガイダンスを提供する必要があることに気付いた場合は、「CLIで開く」を使用します