Claude Media
Claude Code on the webとCopilot cloud agentの違い — 起動・権限・成果物
Claude Code解説

Claude Code on the webとCopilot cloud agentの違い — 起動・権限・成果物

GitHubのリポジトリをクラウドで動かす2つのエージェントを、起動経路・push先と承認の関門・成果物の残り方で比べます。

読了目安 約10分

Claude Code on the webとCopilot cloud agentは、どちらもGitHubのリポジトリを使い捨てのクラウド環境で動かし、結果をブランチとプルリクエスト(PR)で返します。違いが出るのは、仕事の渡し方と、エージェントが触れる範囲を誰がどこで絞るかです。

結論を先に書きます。Claude側は「自分のアカウントの権限で、手元のターミナルやスマホからも投げる」道具で、絞り込みはGitHub側のブランチ保護に任せます。Copilot側は「GitHub上のIssueやPRを起点に、push先が最初から1本に固定される」道具で、人間の承認の関門が製品に組み込まれています。

起動経路は、どこから仕事を投げるかで分かれる

Claude Codeのクラウドセッションは、複数の入口から作れます。ブラウザのclaude.ai/code、Claudeアプリの「Code」タブ、Desktopアプリで「Cloud」を選ぶ方法、ターミナルのclaude --cloud、そしてRoutinesによる定期・イベント起動です。どの入口でも同じクラウド環境の設定を使います。

Copilot cloud agentの入口は、GitHub.comの中にあります。エージェントパネル、会話(チャット)、リポジトリのIssueやPRから始められます。チャットから始めると、それまでの会話の文脈がセッションに引き継がれ、実行中もチャットで進み具合を聞いたり方向を直したりできます。

比べる点Claude Code on the webCopilot cloud agent
起点Claude Code on the webブラウザ・スマホ・Desktop・ターミナルCopilot cloud agentエージェントパネル・チャット・Issue・PR
ターミナルからClaude Code on the webclaude --cloud "タスク"Copilot cloud agent起点として挙がるのはGitHub.com内の操作
定期・イベント起動Claude Code on the webRoutinesCopilot cloud agentAutomations(対象は条件を満たす非公開・社内リポジトリ)
実行中の追加指示Claude Code on the web画面、またはCLIから-pで投函Copilot cloud agentチャットで会話

ターミナルから投げられる点は、Claude側の特徴です。cloudに送る前にローカルで計画を詰めておく使い方が、公式ドキュメントにも載っています。

claude --permission-mode plan
# 計画をdocs/migration-plan.mdに保存してcommit・push
claude --cloud "Execute the migration plan in docs/migration-plan.md"

--cloudが複製するのは、手元のチェックアウトではなくGitHub上の現在のブランチです。pushし忘れたローカルコミットはクラウドに届きません。GitHub連携が無いリポジトリや、Claude GitHub Appが入っていないリポジトリでは、リポジトリごとアップロードする経路に切り替わります。その条件はclaude --cloudとCCR_FORCE_BUNDLEの解説にまとまっています。

実行後の追加指示も、CLIから出せます。既存セッションにメッセージを1件投函して、返事を待たずに終わります。

claude -p "テストの失敗も直して" --cloud session_xxxxxxxx

セッションIDは、claude.ai/codeのセッション一覧に出ます。

権限は、GitHubへの接続の仕方で決まる

Claude側は「自分のトークン」か「GitHub Appの範囲」

Claude Code on the webがGitHubに触れる方法は2つです。

  • Claude GitHub App: 公開リポジトリと、Appを入れた非公開リポジトリに届く。PRの自動修正(Auto-fix)もこの方式が前提
  • /web-setup: ローカルのghトークンをClaudeアカウントに送る。ghが届くリポジトリならAppが無くても使える

Anthropicが管理する環境では、GitHubの認証情報はVMの中に入りません。VMからのGitHub操作は専用のプロキシを通り、プロキシが認証情報を差し込みます。このプロキシはブランチの削除と、ブランチ以外(タグなど)へのpushを拒否します。一方で、どのブランチを更新できるかは制限しません。ここを締めるのは、GitHubのブランチ保護かルールセットの役目です。

プロキシはセッションに紐づくリポジトリだけを相手にします。他のリポジトリへのAPI要求は403になります。GraphQLも通りません。gh prやgh issueのようにGraphQLを使うサブコマンドも403になり、REST経由のgh apiで代替することになります。

Copilot側は「push先が1本」に固定される

Copilot cloud agentは、トリガーできる人からして絞られています。リポジトリに書き込み権限のあるユーザーだけが起動でき、権限の無い人のコメントはエージェントに渡りません。

pushできるブランチは1本です。既存PRで@copilotにメンションしたときはそのPRのブランチ、それ以外では新しく作るcopilot/ブランチになります。ブランチ保護と必須チェックの対象でもあります。git pushのようなGitコマンドは直接は実行できず、単純なpush操作に限られます。

作業の範囲は、起動時に指定した1つのリポジトリです。複数リポジトリをまたぐ変更はできず、同時に作業するブランチも1つ、1タスクで開くPRも1つです。

組織のルールとぶつかったとき

Copilot側には、GitHubのルールとの相性問題があります。特定のコミット作成者しか許さないルールのように、エージェントと両立しない保護ルールがあると、エージェントへのアクセス自体がブロックされます。ルールセットで設定している場合は、管理者がCopilotをバイパス対象に加えれば解消します。

Claude側はプロキシがpush先のブランチを絞りません。重要なブランチを守るなら、GitHub側の保護ルールを先に整えておく必要があります。

成果物は、PRの扱いと痕跡の残り方が違う

どちらも最終的な成果物はブランチとPRです。違いは、その後に人間が通る関門の数です。

関門

Copilotに組み込まれた承認の関門

  • 下書きPRで止まる

    Copilotが作るPRは下書きです。「Ready for review」への切り替え、承認、マージはCopilotにはできず、人間が行います。

  • ワークフローは承認待ち

    既定では、コードがレビューされ、書き込み権限のあるユーザーが「Approve and run workflows」を押すまでGitHub Actionsは動きません。自動実行に設定を変えることもできます。

  • 依頼者は承認できない

    PRの作成を頼んだ本人は、そのPRを承認できません。必須承認ルールの意味が保たれます。

  • 作者が人でないPRは承認がもう1つ必要

    Copilot自身の名義でPRが開かれ、リポジトリがすでに1件以上の承認を要求している場合、マージにはさらに1件の承認が要ります。ルールセットでは既定で有効で、管理者が外せます。ブランチ保護では常に適用されます。

Claude側の成果物は、セッションごとの差分(+42 -18のような表示)で確認します。差分は既定でベースブランチと比べますが、別のブランチを選んで比較することもできます。行ごとにコメントを付けて、次のメッセージと一緒にClaudeへ戻せます。PRはclaude.ai/codeから作るか、セッションをターミナルに取り込んで続けます。

取り込みはclaude --teleportで、クラウドで作業したブランチをfetchして会話履歴ごとローカルに持ってきます。条件は4つです。作業ディレクトリに未コミットの変更が無いこと、同じリポジトリ(フォークでない)であること、ブランチがリモートにpush済みであること、同じclaude.aiアカウントであることです。取り込み後の作業はローカルだけに残り、claude.ai側のセッションには反映されません。

Copilot側の痕跡は、GitHubの機能に乗ります。コミットの作者はCopilotで、依頼した開発者が共同作者に入ります。コミットは署名されて「Verified」と表示され、コミットメッセージにはセッションログへのリンクが付きます。管理者にはセッションログと監査ログのイベントも見えます。

自動修正と定期実行は、権限の見え方が逆になる

PR作成後の動きにも違いがあります。Claude側のAuto-fixは、PRのCI失敗とレビューコメントを購読して、直し方が明確なら修正をpushします。解釈が割れるコメントや設計に関わる指摘は、Claudeがユーザーに聞き返します。ベースブランチの更新で生じたコンフリクトは、GitHubがWebhookを出さないため自動では検知できず、セッションで頼んでrebaseさせます。

注意が要るのは、返信の名義です。ClaudeがレビューコメントのスレッドへGitHub上で返信するとき、その返信は自分のGitHubアカウントで投稿されます。各返信には「Claude Codeが書いた」旨のラベルが付きますが、表示されるユーザー名は自分です。issue_commentイベントで動くAtlantisやTerraform Cloud、自前のGitHub Actionsがあるリポジトリでは、この返信が別のワークフローを起動しかねません。インフラをデプロイできるリポジトリでは、Auto-fixを切る選択肢が公式に示されています。

Copilot側の定期実行(Automations)は、作業の名義が違います。自動化で開いたPRやpushしたコードは、その自動化を作ったユーザーの名義になり、作成者本人は承認できません。自動化が使えるツールは作成時に選べ、書き込み権限のないユーザーのイベントは既定で無視されます。ワークフローの承認が人間に残る点は、通常のタスクと同じです。

実行の枠: 時間・ネットワーク・対応するホスト

項目Claude Code on the webCopilot cloud agent
利用できる契約Claude Code on the webPro・Max・Team、およびEnterpriseのプレミアムシート等Copilot cloud agentプランと組織のポリシーに依存。リポジトリ単位で無効化も可
費用の扱いClaude Code on the webプランの利用上限を他のClaude利用と共有Copilot cloud agentプランの利用枠と課金に従う
1セッションの上限Claude Code on the web一定期間の無操作でVMが回収される。コマンドとSessionStartフックには変更できる既定タイムアウトCopilot cloud agent実行時間は最大59分で、延長不可。timeout-minutesで短くはできる
ネットワークClaude Code on the webNone・Trusted・Full・Customの4段階Copilot cloud agentファイアウォールで制限。設定変更や無効化も可能
対応するホストClaude Code on the webGitHub。Team・EnterpriseはGitHub Enterprise Serverも可Copilot cloud agentGitHub上のリポジトリのみ

使える範囲に関して、Claude側には「ホストが違っても動かす道」があります。GitLabやBitbucketのリポジトリは、CCR_FORCE_BUNDLE=1でローカルのバンドルとして送れます。ただしセッションからそのリモートへ結果をpushすることはできません。Copilot側は、GitHub以外のホストにあるリポジトリでは使えません。

並列実行にも差があります。claude --cloudはコマンドを重ねるたびに独立したセッションを作ります。3つのタスクを同時に走らせられますが、使用量はそのぶん増えます。レート制限は他のClaude利用と共有されるためです。Copilotは1タスクにつき1ブランチ・1PRで、並列は複数タスクを別々に投げる形になります。

セキュリティ検査も、Copilot側は製品が持っています。生成コードはCodeQLで検査され、新しい依存関係はGitHub Advisory Databaseと照合され、シークレットスキャンも走ります。しかも、GitHub Secret ProtectionやAdvanced Securityのライセンスは要りません。Claude Code on the webのページには、こうした組み込みの検査の記載がありません。検査はCIとレビューで担保する前提で組むことになります。

どちらを選ぶか

Issueを起点にチーム全体で非同期に回したいなら、Copilot cloud agentは組み込みの関門が多い選択肢です。push先が固定され、PRは下書きで止まり、ワークフローは承認待ちになります。管理者側の統制がそのまま既定値になっています。

ターミナルで計画を詰めてから投げたい、手元のブランチを送りたい、スマホから実行中のセッションを見たい、といった個人の作業の延長にはClaude Code on the webが合います。その代わり、ブランチ保護とCIの整備が前提になります。

状況合いやすい側理由
Issueを割り当てて放っておきたい合いやすい側Copilot cloud agent理由Issueから起動でき、PRは下書きで返る
ローカルで詰めた計画を実行させたい合いやすい側Claude Code on the web理由--cloudと--teleportで行き来できる
GitLabやBitbucketのコードを触らせたい合いやすい側Claude Code on the web理由バンドルで送れる(結果のpushは不可)
1回の実行が59分を超えそう合いやすい側Claude Code on the web理由Copilotは59分で打ち切られ、延長できない
監査証跡と承認の強制が必須合いやすい側Copilot cloud agent理由署名付きコミットと承認ルールが標準

1回の実行が長い場合、Claude側のページには59分のような固定の上限は載っていません。ただし無操作が続くとVMが回収されるため、承認待ちで長く止めるとセッションが途切れます。

エディタの中で動く対話型のagent modeとの比較は、Claude CodeとCopilot agent modeの違いにあります。Claudeのクラウド環境そのものの仕組みはClaude Code Webのクラウド環境の解説が扱っています。

よくある質問

Claudeのクラウドセッションが「Session creation failed」で始まらないときは

VMを確保できなかった状態です。status.claude.comで障害を確認し、1分ほど待ってやり直します。それでも失敗するなら、GitHub接続からリポジトリが見えているかを確かめます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →