マガジン

自分のPCを離れてAIに作業を任せる:クラウド実行とローカル実行の違いと確認点

AIを使いこなす

Claudeで執筆し、GPTで自動校閲・修正しています。

閉じたノートPCの横で、無地のカードを二つのトレーに振り分ける手元。
記事の内容をもとに制作したAI生成イメージです。実際の製品画面や検証結果の写真ではありません。

結論から言うと、クラウド実行は「GitHubに置いてある(コミット・push済みの)コードを、隔離された別の環境で作業させる」方式で、ローカル実行は「自分のPCの作業ツリーを、そのまま触らせる」方式です。違いの核心は速さや賢さではなく、AIが見えるもの(ファイル・秘密情報・ネットワーク)と、結果が戻る経路にあります。 そのため、任せてよいのは次の条件がそろう作業です。 • 必要なコードがすべてリモートにある(手元の未コミット変更に依存しない) • 環境のセットアップだけでテストやビルドが動く • 機密データや本番の鍵がなくても完了する • 結果がブランチやプルリクエストの差分で届き、人が読んで判断できる 逆に、手元だけにある下書きの変更、ローカルのDBや社内ネットワークが前提の作業、.envの中身が必要な作業はローカルに残すのが安全です。以下、公式資料で確認できた範囲で違いを整理します。確認日は2026年10月30日です。

この記事の目次
  1. 実行場所ごとの違い
  2. ファイルの置き場で結果が変わる
  3. 権限とネットワークを確認する
  4. 任せる前の確認リスト
  5. 依頼文の例
  6. 迷ったときの決め方

実行場所ごとの違い

次の表は、各社の公式ドキュメントの記述から、判断に効く点だけを抜き出して比べたものです。

  • 動く場所、ローカル実行:自分のPC、クラウド実行(共通の傾向):提供元が管理する隔離環境(Claude Codeは組織の自前環境も選べる)
  • コードの渡り方、ローカル実行:手元の作業ツリーをそのまま参照、クラウド実行(共通の傾向):主にGitHub等のリポジトリをcloneして始める
  • 閉じたあと、ローカル実行:PCを閉じる・スリープで止まりやすい、クラウド実行(共通の傾向):PCを閉じても動き続ける製品がある
  • 結果の戻り方、ローカル実行:ファイルが直接書き換わる、クラウド実行(共通の傾向):ブランチ・プルリクエストなど差分で戻る
  • 秘密情報、ローカル実行:手元の環境変数やファイルが見える、クラウド実行(共通の傾向):環境設定で渡したものだけが見える
  • 主なリスク、ローカル実行:手元のファイルやコマンドへの直接の影響、クラウド実行(共通の傾向):渡し忘れ、渡しすぎ、外部通信の範囲

製品ごとの違いは次のとおりです。

  • Claude Code(クラウドセッション)、実行環境:Anthropic管理のVM(自社ホスト環境へ振り分けも可)、範囲・権限:GitHub連携が前提。Anthropic管理環境のネットワークは既定で制限あり、無効化も可能、結果の戻り方:ブランチにpushし、差分確認からPR作成
  • GitHub Copilot cloud agent、実行環境:GitHub Actionsベースの環境またはクラウドサンドボックス、範囲・権限:Actionsベースは指定した単一リポジトリ、クラウドサンドボックスは複数リポジトリに対応。1度に1ブランチ・1タスク1PR、結果の戻り方:ブランチ・PRで確認。Actionsベースのセッションは最大59分
  • Codex cloud、実行環境:GitHubリポジトリから作る環境。タスクごとに独立した作業領域、範囲・権限:インターネットアクセス、許可ドメイン、ネットワークシークレットを設定可能、結果の戻り方:変更を確認し、コミットまたはPR
  • Cursor cloud agents、実行環境:開発環境つきの隔離VM、範囲・権限:ソース管理の接続はアカウント管理者が行う。送信先ドメインの制限も可能、結果の戻り方:エージェントの画面とリポジトリ経由

プランや利用条件は変わります。Claude Codeのクラウドセッションは、Pro、Max、Teamプランと、Enterpriseのプレミアムシート等で使えると記載されています(確認日時点)。ほかの製品のプラン条件は今回確認していないため、導入前に各社の公式ページで見てください。

ファイルの置き場で結果が変わる

クラウドで最初につまずくのは、「手元にあるつもりのものが、環境に届いていない」ことです。Claude Codeの公式ドキュメントでは、claude --cloudは手元のチェックアウトではなく、現在のブランチのGitHubリモートをcloneすると説明されています。ローカルだけのコミットは含まれないため、先にpushが必要です。

bash
git push
claude --cloud "src/auth/login.ts のログイン失敗時の不具合を直して、テストを追加して"

リモートがない、またはClaudeのGitHub Appが入っていないリポジトリでは、ローカルのリポジトリをまとめてアップロードする挙動になります。このときの注意点が公式に書かれています。

  • 追跡されていない(untracked)ファイルは含まれない
  • macOS・Linux・WSLでは、.envや鍵ファイルなどの未コミット変更はアップロードから外される。ネイティブWindowsでは追跡ファイルの未コミット変更がそのまま上がる
  • リポジトリは100MB未満が条件で、超えると現在のブランチのみ、さらに単一のスナップショットへと縮小される

「.envが自動で外れるから安心」と考えるより、クラウドに渡したくないものは、実行前に手元で退避または破棄すると決めておくほうが確実です。

権限とネットワークを確認する

クラウド実行では、書き込める範囲が環境ごとに決まります。

  • GitHub Copilot cloud agentは、書き込み権限のあるユーザーだけが起動でき、pushできるのはcopilot/ブランチか対象PRのブランチに限られます。コードは人がレビューしてマージします。既定では、コードのレビューと書き込み権限者による承認までワークフローは実行されませんが、自動実行を許可する設定もあります。インターネット接続もファイアウォールで制限されます(リスクと対策)。
  • Claude Codeは、Anthropic管理環境でGitHubの認証情報がVMの中に入らず、プロキシ経由で操作されると説明されています。一方で、ネットワークを無効にしても、Claude Code自体はAnthropic APIと通信するため、データが環境の外へ出る可能性があるとも明記されています。
  • Cursorは、設定画面で登録したシークレットを環境変数としてエージェントに渡せます。環境単位のシークレットも設定できるため、渡す対象を確認してください(環境設定)。

ここから言える編集上の判断は、「制限が強い環境ほど安全だが、テストに必要な外部サービスにつながらず失敗しやすい」ということです。許可ドメインは、依存パッケージの取得に必要な最小限から始めると考えやすくなります。

また、ZDR(ゼロデータ保持)やHIPAA構成が有効なClaude組織では、クラウドセッションが使えないと記載されています。学習利用の設定とデータの扱いは別の話なので、機密の扱いを社内規程と照らして決めてください。

任せる前の確認リスト

次の項目に「はい」と答えられるなら、クラウド実行に回せます。

  1. 必要な変更はすべてコミットし、対象ブランチをpushした
  2. 手元にだけある下書き、untrackedファイル、.envはクラウドに不要である
  3. セットアップ(依存関係の導入、テストコマンド)が環境側で再現できる
  4. 本番の鍵や個人情報を環境変数に入れなくても完了する
  5. 書き込み先がブランチ・PRに限られ、mainに直接入らない
  6. ネットワークの許可範囲を、必要な取得先だけに絞った
  7. CIやissue_commentで動く自動化が、AIのコメントや push で意図せず発火しない(Claude Codeのauto-fixは、コメント起点のデプロイ自動化があるリポジトリで要注意と警告されています)
  8. 結果を人がdiffで読み、テスト結果も自分で確認する時間を確保した
  9. 時間の上限や放置による期限切れ(CopilotのGitHub Actionsベースのセッションは59分、Claude Codeは無操作でVMが回収されうる)で、途中で止まっても困らない

作業別の判断の目安

これは公式の仕様ではなく、上の確認点から導いた編集上の目安です。

  • 既存テストの失敗修正、向く場所:クラウド、理由:リポジトリだけで完結しやすく、差分で確認できる
  • 複数の小さな修正の並列実行、向く場所:クラウド、理由:セッションを分けて同時に走らせられる(Claude Codeは公式に並列実行を案内)
  • 未コミットの試作の続き、向く場所:ローカル、理由:クラウドには手元の変更が届かない
  • ローカルDBや社内APIが必要な検証、向く場所:ローカル、理由:隔離環境から届かない
  • 秘密情報が必須の作業、向く場所:ローカル、または管理された環境、理由:渡す範囲を最小にできない

依頼文の例

次は説明用の例で、実行して確かめたものではありません。ポイントは、完了条件、触ってよい範囲、禁止事項を文章で渡すことです。

目的: ログイン失敗時に500が返る不具合を直す。
範囲: src/auth/ と tests/auth/ のみ変更してよい。
完了条件: 既存テストが通り、再現するテストを1件追加する。
禁止: 依存パッケージの追加、設定ファイルの変更、シークレットや.envの参照。
報告: 変更したファイル、実行したテストコマンドと結果、
      確認できなかった点を最後に書く。

返ってきた差分では、まず「範囲外のファイルが変わっていないか」「テストを弱めて通していないか」を見ます。報告にある「確認できなかった点」は、人が確認する項目の起点になります。

迷ったときの決め方

最初の1回は、機密を含まない小さなリポジトリか、影響の小さい修正で試してください。クラウドの環境設定と、結果の戻り方に慣れてから、範囲を広げるほうが事故を避けられます。

出典・参考資料