AI駆動開発でPCスペックが限界に来たら？ローカルとクラウドをどう使い分けるか
AIを使った開発では、以前とは少し違う理由でPCスペックが重要になってきています。
単純にコードを書くためだけなら、そこまで高性能なPCは必要ありません。しかし、AIエージェントを複数並列で動かしながら、Docker、APIサーバー、フロントエンド、テスト、Playwrightなどを同時に実行すると、話が変わってきます。
例えば、複数のGit worktreeを作り、
- 1つは実装
- 1つはATDD
- 1つはテスト
- 1つはレビュー・修正
といった形で4つ並列に開発を進める場合です。
AIは同時に仕事を進めてくれますが、それぞれの作業環境でNode.jsやDocker、ブラウザ、DBなどが動きます。
すると、AIの処理速度より先に、開発者のPCスペックがボトルネックになるケースが増えてきます。
そこで考えたいのが、すべてをローカルで動かすのではなく、一部の処理をクラウドの開発環境へ逃がすという考え方です。
AI駆動開発では「人」より「マシン」が忙しくなる
従来の開発では、開発者が1つのブランチを開いて実装し、テストし、PRを作るという流れが一般的でした。
ところがAI駆動開発では、並列化が簡単です。
例えば、
worktree A → 機能Aの実装
worktree B → 機能Bの実装
worktree C → ATDD作成
worktree D → リファクタリングという状態を、1人の開発者でも作れます。
これは大きなメリットですが、各worktreeで、
Next.js
NestJS
Docker
PostgreSQL
Redis
Playwright
Chrome
AIエージェントなどが動き始めると、CPUやメモリをかなり消費します。
特にPlaywrightによるE2Eテストや、Dockerコンテナを複数起動する処理は重くなりやすいです。
AIエージェントを増やせば開発速度は上げられるはずなのに、実際には、
PCが重くてテストが遅い
Dockerが不安定になる
ブラウザテストが止まる
といった別の問題が出てきます。
ここまで来ると、開発手法だけではなく、計算資源そのものをどう配分するかを考える必要があります。
すべてクラウドに移す必要はない
クラウド開発環境というと、「ローカル開発をやめて全部クラウドに移す」というイメージを持ちやすいですが、必ずしもそうする必要はありません。
むしろ現実的なのは、
ローカルでやった方が速い作業はローカル、重い処理だけクラウド
という使い分けです。
例えば次のようになります。
| 作業 | 実行場所 |
|---|---|
| 設計・仕様整理 | ローカル |
| 小規模な実装 | ローカル |
| UI調整 | ローカル |
| 通常の単体テスト | ローカル |
| ATDD | クラウド |
| 大量のE2E | クラウド |
| 負荷試験 | クラウド |
| CIエラー調査 | クラウド |
| 長時間の解析 | クラウド |
特にクラウドと相性が良いのは、開発者が結果をずっと見ている必要のない処理です。
ダミー環境ならクラウドと非常に相性が良い
クラウド環境を利用するときに注意しなければならないのが、環境変数やシークレットです。
ローカル開発なら、
.env
.env.localなどにAPIキーやデータベース接続情報を保存していることも多いでしょう。
当然ですが、Gitに含まれていない.envは、クラウド側へリポジトリを渡しただけでは利用できません。
また、受託開発などでは、本番DBのパスワードや顧客環境のAPIキーを、安易に外部クラウドへ渡すべきではありません。
そこで相性が良いのが、ダミーの開発環境です。
例えば、
クラウド開発環境
Next.js
NestJS
Playwright
Docker
├ PostgreSQL
└ Redis
テストユーザー
ダミーデータ
ダミーAPIキーだけで完結する環境を用意します。
これであれば本番環境へアクセスする必要はありません。
ATDDやE2Eテストの多くは、「本番データを使うこと」よりも、
アプリケーションが期待通り動くか
を確認することが目的です。
そのためテスト用DBをコンテナ内に毎回作り、seedデータを投入できるようにしておけば、クラウド環境との相性はかなり良くなります。
負荷試験は特にクラウドへ逃がしやすい
もう1つクラウドと非常に相性が良いのが負荷試験です。
例えば、
100ユーザー同時アクセス
APIを1万回実行
大量データを投入
長時間E2Eを繰り返すといった処理です。
これを普段使っているMacで実行すると、負荷試験をしている間、ほかの開発がほぼできなくなる可能性があります。
さらに問題なのは、
自分のPCの性能を測っているのか
アプリケーションの性能を測っているのか
分からなくなることです。
負荷試験用の環境をクラウドに分離すれば、
開発PC
↓
普通に開発を続ける
クラウド
↓
負荷試験を実行するという役割分担ができます。
AIエージェントに、
「このAPIに対して負荷試験を実行し、ボトルネックを分析する」
と任せるような使い方とも相性が良いでしょう。
クラウドを使うメリット
最も大きなメリットは、ローカルPCの物理的な制約を超えられることです。
ローカルでは、
Mac
├ Agent A
├ Agent B
├ Agent C
└ Agent Dと、全員が同じCPUとメモリを奪い合います。
クラウドなら、
Mac
├ Agent A
└ Agent B
Cloud
├ Agent C
└ Agent Dのように分散できます。
そのほかにもメリットがあります。
1. 作業環境を完全に分離できる
各タスクが独立したVMやコンテナで動けば、ポート競合やDBデータ衝突を減らせます。
2. 長時間処理を開発PCから切り離せる
E2E、負荷試験、解析などをクラウドに任せている間も、ローカルでは別の開発を続けられます。
3. テスト環境を再現しやすい
Dockerとseedデータを整備しておけば、
「自分のPCでは動く」
という問題も減らせます。
4. AIエージェントとの相性が良い
AIエージェントは、必ずしも人間が画面を見続ける必要がありません。
そのため、
Issueを渡す
↓
クラウドで作業
↓
テスト
↓
PR作成という形にしやすくなります。
一方でデメリットもある
もちろん、クラウドにすればすべて解決するわけではありません。
コストが増える可能性がある
AIモデルの利用料金に加え、サービスによってはコンピュート料金が関係する場合があります。
並列数を増やせば、その分だけAIの利用量も増えます。
そのため、
クラウドにすれば安くなる
と考えるのは危険です。
クラウドを使う目的はコスト削減というより、
開発速度と計算資源の確保
と考えた方が良いでしょう。
環境構築が必要
ローカルでは.envを置けば動いていたプロジェクトでも、クラウドでは、
セットアップスクリプト
Docker Compose
seed
テストユーザー
環境変数などを整備する必要があります。
逆に言えば、これを整備することで開発環境自体が標準化されます。
外部サービス依存のテストは難しい
SaaSや外部APIなど、実際の環境へ接続しなければ成立しないテストもあります。
こうしたものは無理にクラウド化せず、
クラウド → ダミー・モック中心
CI → 結合テスト
ステージング → 実サービス接続のように分けた方が安全です。
worktreeとクラウドは競合するものではない
クラウドエージェントが増えてくると、
「もうworktreeはいらないのでは？」
という議論も出てきます。
しかし現時点では、どちらか一方に決める必要はありません。
worktreeはローカルで複数の作業を高速に切り替える方法として非常に便利です。
一方、クラウドは計算資源を分散させるのに向いています。
つまり、
worktree
＝ ローカルでの並列化
Cloud Agent
＝ マシンをまたいだ並列化と考えれば良いでしょう。
最初は「2ローカル＋2クラウド」くらいがちょうどいい
いきなりすべての開発をクラウド化すると、環境整備や運用変更のコストも大きくなります。
まずは、
Local
├ 実装
└ UI・確認
Cloud
├ ATDD / E2E
└ 負荷試験・長時間処理くらいから始めるのが現実的です。
特に、
- PCのメモリ使用量
- Dockerのコンテナ数
- Playwrightの実行時間
- AIエージェント待ち時間
が増えてきた場合は、クラウド移行を検討するタイミングです。
AI駆動開発では「計算資源の設計」も開発プロセスになる
AI駆動開発では、人間がコードを書く時間は少しずつ減っています。
代わりに、
どのAIに何を任せるか
どのテストを並列化するか
どこまで自動化するか
どのマシンで実行するかという設計が重要になっています。
つまりこれからは、
CPUやメモリも開発チームのリソース
として考える必要があります。
ローカルPCをさらに高性能にするのも1つの方法です。
しかしAIエージェントが5個、10個と並列に動くようになれば、いずれ1台のPCでは限界が来ます。
そのとき、
人間が触る仕事はローカル。
AIが長時間処理する仕事はクラウド。
という役割分担は、かなり自然な形ではないでしょうか。
AI駆動開発の並列化が進むほど、「どうコードを書くか」だけではなく、どこでコードを書かせるかまで考える時代になってきています。
