AI Agent にどれだけのインフラが必要か？

過去半年、数十チームの「Agent 導入」相談で最も多かったのは、モデル API だけ買って本番を自動変更させようとする極端と、Kubernetes + ベクトル DB + MCP 3 系統 + 自律 Agent プラットフォームを一気に入れて、3 ヶ月で誰も保守しないというもう一つの極端でした。本当に納期を止めるのは「モデルが賢くない」ことではなく、実行環境・検証チェーン・コンテキストゲートウェイの三層が揃っていないことです。本稿では Cloud Mac AI Stack のレイヤー言語で「AI Agent にどれだけのインフラが必要か」を意思決定可能な表に分解します。チーム規模に合わせて選べばよく、某アーキテクチャ記事のフルスタックをそのままコピーする必要はありません。

1. なぜ問題が起きる：「会話できる」≠「届けられる」

Agent という語が乱用されるうち、対話インターフェースとエンジニアリング Agentが混同されがちです。対話にはモデル API だけで足りますが、エンジニアリング Agent には最低でもリポジトリ読取・ファイル変更・コマンド実行・客観的な検証シグナルが必要です。どれか一つでも欠けると、次のような症状が出ます。

• Agent がコードを直したあと、テストしたか誰も分からない——L1 Fact（Runner 実行エンジン）の欠如。
• 開いているファイルしか直せず、モジュール横断のリファクタは推測頼み——L4 Context（MCP 三連結）の欠如。
• 各ツールは単体で優秀だが、1 件の issue に 40 分人が張り付く——L5 Workflow（OpenHands プラットフォーム）の欠如。
• Windows ノートで Xcode ビルドを試み、Agent に合法な実行面がない——L0 実 macOS（Cloud Mac vs ローカル Mac）の欠如。

旧来の発想は「より強いモデルを買う」こと。新しい発想はレイヤーごとに実行と検証能力を埋めることです。ZavCloud で Cloud Mac を借りるお客様がよく聞くのも、Ollama を回すメモリが足りるかではなく、そのノードがスタックでどの役割を担うかという点です。

2. Agent インフラの分類：6 レイヤー、6 製品ではない

以下は L0–L5 の表記（Stack 連載と同一）。レイヤーは責務であり、必ず全部買うリストではありません。 個人は L3 で止めてよく、L2 推論層（Ollama）は常にオプションです。

ここでの構造は明快です。チャット型 Agent は L3 手前で止まる。エンジニアリング型は最低 L0+L3。マージ可能な Agent は L1 まで必須。スケールを語るなら L4+L5。 多くのチームが失敗するのはレイヤーを飛ばすから——Runner なしで OpenHands を入れ、自律タスクがコードを書き換えてもビルド成功を誰も証明できない、といったパターンです。

3. 中核比較：個人 / 小チーム / エンジニアリングの 3 段階

比較記事と同じ軸で整理します：入口、実行能力、コンテキスト、コスト規模、向いている人。

ハードウェア仕様では、L0 と L1 を同機に載せる（よくある構成）場合は下表を参照。CPU 型番より先にメモリが頭打ちになります。Agent、Runner、任意の Ollama がユニファイドメモリを奪い合うためです。

4. シナリオ別の選び方：意思決定マトリクス

「あなたが X なら Y を選ぶ」で素早く振り分けます。

5. 推奨構成：そのまま使える 3 段階スタック

構成 A · 個人の最速立ち上げ（1 日以内）

L0  ローカル MacBook または日額 Cloud Mac
L3  Claude Code（インストール手順）
モデル  Anthropic API サブスクリプション

やらない：Runner、MCP、ベクトル DB、K8s

構成 B · 小チームでマージ可能（1–2 週間）

L0  Cloud Mac M4 16GB 常駐ノード
L1  GitHub Actions 自前ホスト Runner（導入の是非）
L3  Claude Code + CLAUDE.md チーム規約
L4  GitHub MCP 読み取り専用（issue 駆動）

任意 L2：Ollama 7B で私有ドラフト、本線は阻害しない

構成 C · エンジニアリング自律納品（1 ヶ月以上）

L0  Cloud Mac M4 24GB+
L1  Runner · 1 job 1 workspace
L3  Claude Code
L4  MCP 三連結 + CodeGraph
L5  OpenHands（サンドボックスリポジトリで試験）
オーケストレーション  OpenClaw でトリガーと監査（任意）

レッドライン：本番 API / Runner 認証情報は MCP に入れない（権限ガイド）

6. よくある誤解：避けるべき 5 つ

1. モデル API をインフラ全体とみなす。 API は「考える」だけで、「やる」「検証する」は解決しない。
2. Runner なしで L5 にリポジトリ書き込みを開放する。 Fact 層のない自律 Agent は盲書きに等しく、ロールバックコストが極大。
3. 最初からベクトル DB + RAG プラットフォームを建てる。 多くのコード Agent のボトルネックは embedding 検索ではなく、シンボルレベルのコンテキスト（CodeGraph）。
4. Windows 上の VM で macOS CI をごまかす。 署名・公証・実機テストには Apple Silicon の実環境が依然必要。
5. 他人のフルスタックをそのまま調達する。 まず実行境界を書き、レイヤーごとに追加購入。スタックの層数とチーム人数は比例しない。

7. 導入ステップ：7 項目チェックリスト

1. 実行境界を定義 — Agent に許可する操作を列挙：どのディレクトリを変更できるか、shell を実行できるか、本番を触れるか。
2. L0 を確定 — Xcode / 公証が必要なら macOS 必須。レンタルか購入かを評価。
3. L3 コーディング Agent を接続 — まず単一ファイル・単一リポジトリで通す。CLAUDE.md / チーム Prompt 規約を整備。
4. L1 Runner を構築 — macOS job と Linux job を分離。シークレットと Agent トークンは分離課金。
5. 必要に応じて L4 MCP — デフォルト読み取り専用。書き込み権限は短命トークンの別サービスで。
6. L5 を評価 — 2 週間連続で手動ツール連結が続くなら、OpenHands 系 Workflow を導入。
7. 監査とレッドライン — 各自律タスクを PR + CI run ID にマッピング。四半期ごとに権限マトリクスを再確認。

よくある質問

まとめ

AI Agent に必要なインフラは、実行境界がどのレイヤーで止まるかで決まり——モデルランキングでは決まりません。 個人は L3 までで着手可能。組織がマージを恐れなければ L1 まで。大規模リポジトリで迷子にならなければ L4。無人納品を目指すなら L5。Cloud Mac や Mac mini を買うときは、TOPS より先に、そのマシンがスタックで「実行面」「検証面」「推論面」のどれかを問うほうが実用的です。