---
title: "AIエージェント基盤にサーバーレスが向かない理由｜14構成を比較して分かったこと"
excerpt: "複数のAIエージェントを動かすインフラを14パターン横断比較しました。作りたいのは軽量APIサーバーではなく「リモートに置くAI実行端末」——CLIエージェントはOS・シェル前提のため、ステートレス短時間処理のサーバーレスとは思想が噛み合いません。満たすべき6条件と推奨スペックをまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-06-03T00:00:00+00:00
verified_at: 2026-06-03T00:00:00+00:00
models: ["Claude Code"]
tools: ["Browser Use", "Google Cloud"]
tasks: ["AIエージェント", "業務プロジェクト"]
domain: "社内基盤・インフラ"
canonical_url: https://ai-katsu.jp/articles/multi-agent-infra-comparison
---
# AIエージェント基盤にサーバーレスが向かない理由｜14構成を比較して分かったこと

AIエージェントを動かすインフラを選ぶとき、普通のWebアプリと同じ基準で考えると失敗します。**作りたいのは「軽量APIサーバー」ではなく「リモートに置くAI実行端末」**だからです。

この検証では、その前提の違いを起点に、**14の構成パターンを横断比較**しました。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年6月3日〜（Phase 0：構成整理のみ） |
| 目的 | 複数のAIエージェントを実行できる環境を作る場合、どのインフラ構成が考えられるかを整理する |
| 比較対象 | VPS / 物理PC・ミニPC / AWS各種 / GCP各種 / PaaS各種の**14パターン** |
| 第一候補 | **VPS + Docker Compose** |
| 状況 | 構成比較まで完了。本番構築は未着手 |

## 結論：サーバーレスは思想が噛み合わない

この検証で最も重要な指摘です。

**CLIエージェント系は「OS・シェル・ファイルシステム・作業ディレクトリがありCLIを起動できる」世界観が前提です。これはVPS・VM・物理PC・コンテナホストと相性が良く、ステートレス短時間処理が得意なサーバーレスとはやや噛み合いません。**

APIの中で何が動くのかを列挙すると、この違いがはっきりします。

-   CLI実行
-   自律ブラウザ操作
-   Chromium起動
-   長めのLLM推論
-   複数ステップのエージェントループ
-   ファイル生成・作業ログ保存

**サーバーレスに寄せすぎると起きる問題も具体的です。**

メモリ不足、Chromiumが起動しない、タイムアウト、コールドスタートが重い、作業状態を残しにくい、複数エージェントの干渉、デバッグ困難、SSHで中身を見られない——といった不整合が出やすくなります。

## 満たすべき条件

この検証では、問題設定を「クラウドに何を置くか」から**「AIエージェント用の実行端末をどう設計するか」**へ再定義しています。

満たすべき条件は6つです。

1.  **Dockerで持ち運べる**
2.  **HTTPで外部から呼べる**
3.  **役割ごとに分離できる**
4.  **ログと状態を追える**
5.  **ブラウザ操作に耐えるスペック**
6.  **必要時にRDP・SSHで中身を見られる**

最後の1つが、サーバーレスでは満たしにくい条件です。**エージェントが何をしているか分からなくなったとき、中に入って確認できるかどうかは運用の成否を分けます。**

## 構成パターンの比較

| パターン | 月額 | 自由度 | デバッグ | 総合コメント |
| --- | --- | --- | --- | --- |
| **VPS** | 低〜中 | 高 | 高 | **最もバランス良・第一候補** |
| **物理PC / ミニPC** | 低（電気代） | **最高** | **最高** | 自分用の実験基盤として有力 |
| クラウドVM（EC2 / Compute Engine） | 中 | 高 | 高 | そのクラウド前提なら現実的 |
| **コンテナオーケストレーション（Fargate等）** | 中〜高 | 中 | 中 | **本番の役割別分離の本命** |
| サーバーレスコンテナ（Cloud Run等） | 低〜中 | 中 | 中 | 技術的には良いが制約あり |
| **関数系サーバーレス（Lambda等）** | 安い | **低** | **低** | **自律ループには窮屈・見送り寄り** |
| 各種PaaS | 中 | 中 | 中 | 早く試す用。ブラウザ操作には弱いものも |

**関数系サーバーレスの評価が明確です。**コストは安いものの、自由度とデバッグ性が低く、自律ループには向きません。

## 推奨スペックの目安

| 用途 | 最低 | 推奨 | 余裕 / 複数同時 |
| --- | --- | --- | --- |
| CLIエージェント単体（推論はクラウド側） | 2 vCPU / 4GB | 2〜4 vCPU / 8GB | — |
| メモリ・ツール・ブラウザ込みのエージェント | 2 vCPU / 4GB | 4 vCPU / 8GB | 4〜8 vCPU / 16GB |
| **Playwright / Chromium込み（最も重い）** | 2 vCPU / 4GB | 4 vCPU / 8GB | **4〜8 vCPU / 16GB以上** |
| 役割別エージェント複数 | — | 8GB | 16GBあると安心 |

ブラウザ操作が最も重い要因です。

**Chromiumを使うためCLIエージェントよりメモリを食います。動的・SPA・ログイン付きサイトでは4GBはカツカツになりうる**という評価です。

対策も具体的です。**役割別に複数動かす場合、各エージェントが常時ブラウザを起動するのは避け、ブラウザ操作だけ専用コンテナに切り出すか、ジョブ実行時のみChromiumを起動する**設計にします。

## 同期型から始めて、重くなったら非同期型へ

アーキテクチャの選択についても整理されています。

| 方式 | 構成 | 特性 |
| --- | --- | --- |
| **同期型** | `POST /run` → 実行 → 結果JSON返却 | **構成がシンプルでPoC向き。**ただし処理が長いとタイムアウトしやすい |
| **非同期型** | `POST /jobs` → job\_id即返し → 裏で実行 → 完了後Webhookへ | **長時間処理に強く実務運用向き。**ただしjob\_id管理・キュー・再実行設計が必要 |

**最初から非同期にすると、作るものが増えます。**まず同期型で動かし、タイムアウトが問題になってから非同期に移すという順番が現実的です。

## この検証の位置づけ

ログの冒頭に、明確な但し書きがあります。

**「今すぐ本番構築するためではなく、後から再検討するときに壁打ち結果を引き出せるようにするための整理メモ」**

これは記録として重要な姿勢です。**決めきらないまま整理を残しておくと、実際に必要になったときの判断が速くなります。**

あわせて、役割別エージェント組織の設計案、セキュリティ設計、ロードマップ、再検討時のチェックリストも整理されています。

## 選定の判断軸

この比較から導ける判断軸を整理すると、こうなります。

-   **ブラウザ操作を含むか** — 含むならメモリ要件が跳ね上がる
-   **デバッグのために中に入る必要があるか** — あるならSSH可能な環境
-   **状態を保持する必要があるか** — あるならステートレス前提の環境は不向き
-   **役割別に分離したいか** — したいならコンテナオーケストレーション
-   **コストを固定にしたいか** — したいならVPSの月額固定

**「安いから」でサーバーレスを選ぶと、動かないものを動かそうとして時間を失います。**

## よくある質問

### なぜサーバーレスでは難しいのですか？

**CLIエージェントはOS・シェル・ファイルシステムがある前提で動くためです。**メモリ不足、Chromiumが起動しない、タイムアウト、状態を残しにくい、中を見られない——といった問題が出ます。

### どの構成から始めるべきですか？

**VPS + Docker Composeが第一候補です。**月額固定でコストが読め、SSHでログを追え、役割別エージェントを増やしやすくなります。自分用の検証なら物理PC/ミニPCも有力です。

### どのくらいのスペックが必要ですか？

**ブラウザ操作を含むなら4 vCPU / 8GBが推奨です。**複数のエージェントを同時に動かすなら16GBあると安心です。動的・ログイン付きサイトでは4GBはカツカツになります。

### 最初から非同期型にすべきですか？

**まず同期型で始めるほうがシンプルです。**処理が長くタイムアウトが問題になってから、非同期型へ移行します。

## まとめ

-   作りたいのは軽量APIサーバーではなく**「リモートに置くAI実行端末」**
-   **CLIエージェントはOS・シェル前提。ステートレス短時間処理のサーバーレスとは思想が噛み合わない**
-   満たすべき条件は**Docker化・HTTP呼び出し・役割分離・ログ追跡・ブラウザ耐性・SSH可能**の6点
-   第一候補は**VPS + Docker Compose**。本番の役割別分離ならコンテナオーケストレーション
-   **ブラウザ操作が最もメモリを食う。**専用コンテナに切り出すか、ジョブ実行時のみ起動する
-   アーキテクチャは**同期型から始め、重くなったら非同期型へ**
-   **決めきらないまま整理を残しておく**と、必要になったときの判断が速くなる

インフラ選定では、動かすものの性質を先に言語化すると選択肢が絞れます。同じ「APIを立てる」でも、中で何が動くかによって適した環境は変わります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAI基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。