AIエージェントをローカルで動かすかクラウドで動かすかの判断軸
この章の目次開く
エージェントはどこで動かすかによって、できることと安全に許せることが変わります。同じモデル、同じ指示を使っていても、手元のマシンで動かすのと隔離された環境で動かすのとでは、性質がまったく違います。
そして「クラウドが正解」でもありません。この章では両者の違いを構造で押さえたうえで、どちらを選ぶかの判断軸を整理します。
学習者PCを閉じたらエージェントが止まっちゃうんだけど、これって普通なの？
何が違うのか
まず全体像です。
| ローカル実行 | クラウド実行 | |
|---|---|---|
| 実行場所 | 自分のマシン | 隔離された仮想マシン |
| PCを閉じたら | 止まる | 走り続ける |
| 同時実行数 | マシン性能で頭打ち | セッションごとに独立 |
| 危険な操作 | 自分の環境が壊れる | 使い捨ての環境が壊れるだけ |
| 認証情報 | 手元にそのままある | プロキシ経由で限定的に渡る |
| 見ているコード | 手元の作業ツリー | リモートのブランチ |
| 画面を見る作業 | できる | 手間がかかる |
最後から2行目が、実務でいちばん誤解を生みます。
クラウドは「手元のコード」を見ていない
公式ドキュメントは明確に書いています。クラウドのVMがクローンするのは、あなたのローカルのチェックアウトではなく、GitHubのリモートにある現在のブランチです。
手元でコミットしただけ、あるいは編集しただけの変更は、クラウドのエージェントには見えません。先にpushする必要があります。
「指示したのに古いコードを直している」という混乱は、たいていここが原因です。クラウドに投げる前にpushする、という手順が要ります。
隔離されているから緩められる
権限設計の章で、権限を緩めてよいかは環境が隔離されているかで決まると書きました。クラウド実行はその条件をまるごと満たします。使い捨ての仮想マシンで動いているので、壊れても失うのは環境そのものだけです。
公式が挙げているクラウド側の保護は次のとおりです。
- セッションごとに隔離された仮想マシン
- ネットワークアクセスは既定で制限され、無効にもできる
- 認証情報はサンドボックスの中に本物を置かず、プロキシがスコープ付きの資格情報を実際のトークンに変換する
git pushは現在の作業ブランチに限定される- すべての操作が監査目的で記録される
- 一定時間使われないとVMは回収される
手元とクラウドを往復する
行ったきりでは使いにくいので、往復の手段があります。ただし方向に非対称性があります。
CLIからは、クラウドのセッションを手元に引き寄せることはできますが、手元のセッションをそのままクラウドへ押し出すことはできません。引き寄せる側にも条件があります。
| 条件 | 内容 |
|---|---|
| gitの状態 | 未コミットの変更がないこと（あればstashを促される） |
| リポジトリ | 同じリポジトリのチェックアウトであること（フォークは不可） |
| ブランチ | クラウド側のブランチがリモートにpush済みであること |
| アカウント | クラウドセッションと同じアカウントであること |
実務で使いやすいのは、公式も勧めている手元で計画し、クラウドで実行するという型です。計画モードで方針を固め、計画をリポジトリにコミットしてpushし、それを実行するようクラウドに投げます。
先生考える作業は手元、待つ作業はクラウド。この分け方が一番しっくりくるはずだよ。
クラウドに向かない作業
一方で、クラウドが不向きな作業もはっきりしています。
| 向かない作業 | 理由 |
|---|---|
| 画面を見ながらのUI・デザイン調整 | 往復のたびにスクリーンショットを介するため効率が落ちる |
| 社内ネットワークが必要な作業 | 到達できない |
| 未コミットの状態が前提の作業 | クラウドはリモートのブランチしか見ない |
| IP許可リストを敷いている組織 | Anthropicのインフラから通信するため、認証エラーになる |
| GitHub以外のホスティング | バンドルで送れるが、結果をpushし返せない |
このうちUI・デザインの調整は、レビューの章で触れた「エージェントが苦手な領域」とも重なります。手元で目視しながら進めるほうが速い、というのは複数の実務報告で一致している数少ない具体的知見です。
判断軸は4つ
まとめると、選択は次の4つで決まります。
| 軸 | クラウドが効く条件 |
|---|---|
| 並列性 | 同時に何本も走らせたい。手元のマシンを占有したくない |
| 環境隔離 | 危険な操作を許したい。環境を汚したくない |
| 権限境界 | 確認を大幅に省いて自走させたい |
| 再現性 | チーム全員で同じ実行環境を使いたい |
よくあるハマりどころ
pushを忘れてクラウドに投げる。 最頻出です。クラウドが見ているのはリモートのブランチです。
隔離されているから何を渡してもよいと考える。 環境が使い捨てであることと、渡した情報が守られることは別です。次の章で扱います。
ネットワーク無効を完全遮断だと思う。 前述のとおり、モデルとの通信は残ります。
未コミットの作業を前提にした指示を出す。 クラウド側には存在しません。
往復できる前提で設計する。 CLIからは片方向です。手元のセッションをそのまま送ることはできません。
ちゃんと使うためのポイント
- 実行環境は並列性・環境隔離・権限境界・再現性の4軸で選ぶ
- クラウドが見ているのはリモートのブランチ。手元の変更は見えない
- 隔離は自分のマシンを守るもの。情報が出ないことの保証ではない
- クラウド側は本物の認証情報をサンドボックスに置かない設計になっている
- 往復は片方向。手元で計画し、クラウドで実行する型が使いやすい
- UI調整・社内ネットワーク・未コミット前提の作業はローカルに残す
- ローカルのworktreeで足りるなら、それが最短
次の章では、クラウドを選んだ場合に実際どこから手を付けるのかを、通しの手順として扱います。GitHubの接続から最初のタスクを投げるところまでです。権限の設計はその次に扱います。
参考リンク
- Use Claude Code on the web（公式） — クラウドセッションの実行場所、リモートをクローンする挙動、往復の条件、制約
- Configure cloud environments（公式） — ネットワークアクセス、環境変数、セットアップスクリプトの設定
- Security（Claude Code 公式） — クラウド実行時の隔離、認証情報の保護、監査ログ