クラウド上に開発環境がぽんと立ち上がって、そこにリポジトリが落ちてきて、AIエージェントが実装を進めてくれる。便利だし、実際それで終わる作業もたくさんある。ところが、いざ「いつもの流れ」でやろうとすると、手が止まる瞬間がある。使いたかった自分用のツールが、その環境に居ないのだ。クラウドで一度試して、便利なはずなのに何かが物足りなかった——そんな引っかかりを覚えたことはありませんか？
Claude CodeはGitHubと連携して、リポジトリをクラウド環境に落としたまま実装を回せる。ブラウザを閉じても続きが進むし、PCのスペックにも縛られない。ここまでは文句なしに気持ちいい。問題はその先で、クラウドに落ちてくるのは「そのリポジトリ」だけ、という一点にある。普段の作業を支えている自分用のツール一式は、どのリポジトリにも属していない。だから、付いてこない。
この記事は、その「付いてこないもの」の正体を、実際の設定ファイルまで下りて確かめた考察の記録です。結論を先に言えば、クラウドで足りるかどうかは「その作業がリポジトリの中で閉じているか」で綺麗に割れる。そして自分用ツールがグローバルに散らばっているのは、ズボラだからではなく、そうならざるを得ない理由があった——という話です。
クラウドで足りる場面、足りない場面
まず線引きから。クラウド実行が向いているのは、作業に必要なものが「そのリポジトリの中に全部ある」ケースです。
依存が package.json に書いてあって、テストもリポジトリ内で完結する——こういう「バグ修正」「機能追加」は、クラウドに落として任せて全く困りません。むしろ手元のマシンを占有されないぶん快適です（正直、自分のPCのファンが唸り出さないだけでもありがたい）。
足りなくなるのは、作業の途中で「リポジトリの外」に手を伸ばした瞬間です。いつも使っている自作の定型作業ツール、複数プロジェクトで共通の下ごしらえスクリプト、エディタやシェルの手癖——こういう「どのリポジトリにも入れていないが、自分の作業には常に居るもの」を前提にした瞬間、借りた環境ではそれが空っぽになる。問題はツールの優劣ではなく、置き場所なんです。リポジトリの中にあるものは付いてくる。外にあるものは付いてこない。ただそれだけ。
| 作業のタイプ | 必要なもの | クラウドで足りる？ |
|---|---|---|
| リポジトリ内のバグ修正・機能追加 | リポジトリ内の依存・テスト | ✅ 足りる |
| 依存が閉じたリファクタ | 同上 | ✅ 足りる |
| 自分用ツールを絡めた定型作業 | リポジトリ外のグローバル資産 | ❌ 付いてこない |
| 複数リポジトリ横断の下ごしらえ | 同上 | ❌ 付いてこない |
なぜ「グローバル配置」になってしまうのか
ここが本題です。「じゃあそのツールもリポジトリに入れておけばいいのでは？」と思いますよね。私も最初そう思っていました。でも実際に自分の設定を並べてみると、入れられない理由のほうが多かった。
理由その一は、そのツールが特定のリポジトリの持ち物ではないからです。たとえば手元では、複数のAIコーディングツールで同じスキル集を共有する構成にしています。設定スクリプトが一本のスキル集を、各ツールの設定ディレクトリ（~/.claude/skills などの決まった場所）へ配っていく。dotfilesの説明にもそのまま「複数のAIエージェントツール間でスキルを共有できます」と書いてあります。共有される以上、置き場所は特定のプロジェクトの中ではあり得ない。ホーム直下の、ツールが必ず見に行く決まった場所でなければならない。
理由その二は、ツール側が「決まった場所」しか見に来ないからです。エージェントのサブ定義（下請けの振る舞いを書いたファイル）を、あるプロジェクトのリポジトリの中に置いていた時期がありました。すると別のリポジトリで作業したとき、それが解決されない。設定の注記にもこう残っています——agents は cwd 非依存解決が必須なのでここで貼る。つまり「どのディレクトリにいても効く」ためには、ホーム直下のグローバルな場所に置くしかない。プロジェクトに紐付けた瞬間、そのプロジェクトの外では消える。
理由その三は、運用しているうちに自然とグローバルへ「昇格」していくからです。最初はスキル集のリポジトリの中だけに入れていた挙動設定を、あとからグローバル側へ引き上げた記録が残っています。コミットの説明はそっけなくて、skills repo にのみ入れていた設定 (bgIsolation: none) をグローバルへ昇格 の一行だけ。でもこれは象徴的で、「全プロジェクトで一律に効いてほしい設定」は、放っておくと必ずグローバルへ滲み出す。プロジェクト単位に閉じ込めておけないものが、確かに存在するんです。
同じことは配布の作法にも出ます。自作の小さなCLIを、環境構築をコードで管理する仕組み（Home Manager）に乗せて配る——cca を writeShellApplication で home-manager 配布 というコミットがそれです。ここで配られる先はリポジトリの中ではなく、環境そのもの。CLIも、それが依存する実行時コマンドも、まとめて「マシンのグローバルな一部」として据え付けられる。つまり自分の作業環境は、意図的に「リポジトリの外」に厚みを持たせて作られている。クラウドが落としてくれるのは、この厚みの外側にある一枚だけなんです。
念のため補足すると、これは散らかっているわけではありません。設定を管理する仕組み（Home Manager）の初期化処理が、起動時に settings.json や共通ルールのテキスト、hooks/*.{py,sh} をホーム直下の決まった場所へ配っていく。手作業で散らばったのではなく、意図してグローバルに集約している。だからこそ、その集約先ごと持っていけないクラウドとは相性が悪い。
だから「手元で動く」にこだわる
ここまで来ると、ローカル実行にこだわる理由は「なんとなく手元が好き」ではないことがわかります。自分の作業の半分近くが、リポジトリの外に据え付けたグローバル資産の上に成り立っているから、その資産ごと動かせる場所でしか本来の速度が出ない、というだけの話です。
面白いのは、Claude Code自身がこの制約に効く機能を持っていることです。Remote Control（執筆時点ではリサーチプレビュー）で起動したセッションは、クラウドに逃がさず手元のマシンで動いたまま、別デバイスから操作できる。「モバイルから触りたいけど、クラウドには出したくない」という、一見わがままな要求（まあ、口に出すとわがままですよね）にちゃんと応えてくれる。手元で動く限り、グローバルに据えた自分用ツール一式はまるごと生きたままです。
私の場合はこのRemote Controlを手元で起動する部分を小さな自作CLIで埋めていて、その過程で fix(cc-launch): Remote Control 起動判定を --remote-control プロセスに限定 のような地味なバグ潰しもしました（通常の作業セッションと取り違えて誤判定していた、というオチ付きです）。そのあたりの起動まわりの詳細はiPhoneから手元のClaude Codeを1タップで起動する記録に書いたので、ここでは繰り返しません。本筋は「なぜ手元で動くことにこだわるのか」——その答えが、リポジトリの外に据えたツール一式だった、という一点です。
なお、Claude Code（Pro $20/月、Max $100〜200/月のサブスク）にせよ、併用しているCodex CLI（ChatGPTのサブスクに紐づく）にせよ、費用はサブスクの枠のなかで回している前提です。クラウドかローカルかは、この枠の外にある「環境の作り方」の問題として考えています。
この線引きを自分でやるには
同じ判断を自分の環境でしたいなら、問いはひとつだけです。「この作業でAIに触らせたいものは、リポジトリの中に全部あるか？」
- 全部リポジトリの中にある → クラウドに落として任せる。手元を占有されないぶん快適
- リポジトリの外の自分用ツールに依存する → 手元で動かす。グローバル資産が生きる場所を選ぶ
そして、もし「外の自分用ツール」がまだ手作業で散らばっているなら、先にそこを一箇所へ集約しておくと、この線引き自体がくっきりします。どのツールも見に来る決まった場所（ホーム直下の設定ディレクトリ）へ、スキルもエイリアスもCLIも寄せておく。集約しておけば、「これはリポジトリの外の資産だから手元で」という判断が、迷わず一瞬でできるようになります。
まとめ
クラウド実行が足りるかどうかは、突き詰めると「その作業がリポジトリの中で閉じているか」だけで決まります。閉じているならクラウドで快適に終わるし、外の自分用ツールに手を伸ばすなら手元で動かすしかない。
そして自分用ツールが手元にグローバル配置されているのは、ズボラだからではありませんでした。特定リポジトリの持ち物ではないから、ツールが決まった場所しか見に来ないから、全プロジェクト一律の設定は放っておくとグローバルへ昇格するから——理由を並べると、外に置かざるを得ないものが確かにある。クラウドが落としてくれる一枚のリポジトリと、その外に据えた環境の厚み。この二層を意識できると、「クラウドで試したけど何か足りなかった」あの感覚の正体が、少しはっきり見えてきます。
