AIエージェント自動化のメモリ消費 — VRAM 議論を超える 4 階層モデル

「ローカル LLM なら VRAM 16GB で動く」 — この基準で組んだ構成が、 Claude Code とローカル LLM を並行稼働させた瞬間にシステム RAM を 50GB 食う。 VRAM 議論で完結しない領域が、 AI エージェント自動化を始めた瞬間に立ち上がっている。 メモリは VRAM だけでは語れない。 推論層、 統合層、 永続化層、 配電層の 4 階層で積み上がっている。

本記事では、 AI エージェント自動化のメモリ消費を 4 階層モデル として構造化する。 VRAM 中心の議論では拾えない並行運用ピークの実測値を階層別に分解し、 それぞれの設計判断を整理する。 GPU を選ぶ前に、 メモリの全体像を把握するための土台になる。

第 1 章: VRAM 議論で完結しない領域

「ローカル LLM 推論なら VRAM が全て」 — この前提は、 単独プロセスでモデルを動かすケースには当てはまる。 13B モデルなら 16GB、 32B モデルなら 24GB という議論は、 推論を回す瞬間のメモリ消費を捉えている。

しかし AI エージェント自動化では、 LLM は構成要素のひとつにすぎない。 Claude Code のようなエージェント実行環境、 自動化スクリプトのバックグラウンド処理、 ブラウザ操作、 動画検品で複数の Vision LLM を並列に動かす処理 — これらが同時に動く。 LLM が VRAM を食うのと並行して、 別の層が大量のシステム RAM を要求してくる。

i7-14700F + 96GB DDR5 + RTX 5080 (16GB VRAM) + RTX 5060 Ti (16GB VRAM、 Oculink 接続) の構成で、 Claude Code エージェントを動かしながら Ollama 推論を並行させた状態の実測:

VRAM は単独タスクでは余裕がある。 でも並行運用に入った瞬間、 システム RAM は VRAM の 3 倍以上を要求してくる。 この比率が VRAM 議論では出てこない領域になる。 ここから先は、 メモリ消費を 4 階層に分解して捉える必要がある。

第 2 章: 4 階層メモリモデルの全景

AI エージェント自動化のメモリ消費は、 次の 4 階層で積み上がる。

4 階層は独立しているのではなく、 上の層が下の層に依存する構造になっている。 推論層が VRAM を使い切れば統合層に spillover が発生し、 統合層のキャッシュが膨らめば永続化層の I/O が増え、 永続化層の同時アクセスが増えれば配電層のバス帯域に上限が来る。

VRAM 議論はこの 4 階層のうち、 推論層 (階層 1) しか扱っていない。 自動化を成立させる場合は、 4 階層全体を同時に設計する必要がある。 階層ごとにボトルネックの出方が違うため、 ひとつを強化しても別の階層がそこに置き換わる。

第 3 章: 階層 1 — 推論層 (VRAM)

推論層は LLM 本体が動く層。 ここで消費されるのは VRAM になる。

VRAM に乗る要素

VRAM が確保するのは、 主に次の 3 つ:

• モデル重み — 量子化形式によって変動する (FP16 / Q5_K_M / Q4_K_M 等)。 35B モデルの Q5_K_M で約 24GB
• KV cache — プロンプト処理時にトークンごとに膨らむ一時バッファ。 長文プロンプトで数 GB に達する
• 推論バッファ — 中間計算用の作業領域

RTX 5080 (16GB VRAM) + RTX 5060 Ti (16GB VRAM、 Oculink 接続) の構成では VRAM 合計 32GB に見えるが、 単一モデルを 2 GPU に分散ロードする場合は通信オーバーヘッドが入り、 単独 24GB GPU と同等の速度は出ない。 Ollama や llama.cpp は GPU 間分散をサポートするものの、 帯域差 (Oculink x4 = PCIe Gen4 x4 相当 = 約 8GB/s) が引っかかってくる。

spillover が発生する瞬間

VRAM 容量を超えるモデルをロードすると、 超過分はシステム RAM に置かれる。 これが推論層から統合層への spillover になる。 RTX 5080 (16GB) で qwen3.6:35b-a3b (24GB モデル) を動かすと、 重み 8GB がシステム RAM 側に張り付く。 推論速度は VRAM only に比べ大幅に遅くなるが、 メモリは確実に消費される。

spillover は推論層の話に見えて、 実際には統合層 (階層 2) の使用量を押し上げている。 階層 1 と階層 2 は連動している。

関連記事: RTX 5080 16GB VRAM の壁 — 27B / 32B モデルが動かない理由 / RTX 4060 8GB で Qwen3.6 35B MoE を動かす / llama.cpp で Gemma 4 実行時に RAM が枯渇する原因と対策 / VRAM 16GB で LLM が起動しない時の解決法

第 4 章: 階層 2 — 統合層 (システム RAM)

統合層は AI エージェント自動化の本丸になる。 ここで動くのは LLM そのものではなく、 エージェント実行環境、 自動化スクリプト、 並行プロセス、 ブラウザ自動操作。 全部システム RAM を消費してくる。

統合層が膨らむ要因は次の 5 つ。

4-1. Python プロセスの並列性

AI エージェント自動化は単一プロセスで完結しない。 スケジュール起動されるタスク、 バックグラウンド監視、 対話プロセスが並行稼働する構成が一般的になる。 Python プロセス 1 つあたり 200-500MB のオーバーヘッドが発生し、 10 並列で 2-5GB が固定で乗る。 仮想環境ごとに依存パッケージが別ロードされる場合、 さらに増える。

4-2. SQLite のメモリバッファ

記事 DB / メタデータ DB / ログ DB が同時にオープンされている状態では、 SQLite はクエリ頻度の高いインデックスとデータページをメモリ上に保持する。 60-80MB の DB ファイル × 数本で、 メモリ上のバッファが数 GB に達する。 WAL モードではログバッファが追加で乗り、 大量書き込み中はピークが膨らむ。

4-3. Ollama の CPU spillover

階層 1 (推論層) で発生した spillover はここに流れ込む。 35B モデルを 16GB VRAM 環境で動かすと、 重みの 6-12GB がシステム RAM に張り付く。 LLM がアイドル状態でもモデル重みはメモリから外れないため、 ロード後は常時この消費が続く。

4-4. ブラウザ + 拡張機能

Claude Code の MCP 経由でブラウザ自動操作を行う場合、 Chrome 本体 + 拡張機能 + DevTools プロトコル接続で合計 1.5-3GB が乗る。 タブを複数開いた状態では、 各タブで JavaScript 実行コンテキストが追加で 200-500MB ずつ加算される。 自動化のうち UI 操作を含む割合が高い構成では、 この層が一気に膨らむ。

4-5. キャッシュデータの常駐

マルチモーダル検品のように複数のモデル評価結果を集計する自動化や、 動画フレームのメタデータを保持しながら処理を進める構成では、 これらが in-memory cache として常駐する。 60MB 級の SQLite を Python 側で読み込み、 dict / list 形式で保持されると、 ピーク時に 2-4GB を消費する。 自動化が成熟するほどキャッシュ層が厚くなる傾向がある。

統合層が 50GB に達する経路

5 要素を積み上げると、 並行運用ピーク時に統合層だけで 30-50GB に達する。 Python プロセス 5GB + SQLite バッファ 4GB + Ollama spillover 8GB + ブラウザ拡張 3GB + キャッシュ常駐 4GB + その他 6-8GB、 これに対話的な作業負荷が加わる。 96GB DDR5 環境でも残量が半分を切る規模になる。

関連記事: AI 用 PC のメモリ (RAM) とは — DDR5 / デュアルチャネルの基礎 / マルチモーダル検品の実装例 — 動画コンテンツの多段品質ゲート / Claude Code 自動化の実例 2026 年版

第 5 章: 階層 3 — 永続化層 (ストレージ + I/O)

永続化層はストレージへの読み書きと、 それに伴う I/O 帯域を扱う層。 メモリの「容量」 ではなく「速度」 で詰まるため、 GB 単位ではなく MB/s 単位で考える必要がある。

SQLite WAL の挙動

WAL (write-ahead log) モードの SQLite は、 書き込みを WAL ファイルに先行記録してからメインファイルにチェックポイントする。 大量書き込み中は WAL ファイルが GB 単位に膨らむことがあり、 同時にバッファが統合層 (階層 2) のメモリを消費する。 WAL のチェックポイント頻度を下げると書き込みは速くなるが、 統合層のメモリ消費が増える。 階層 2 と階層 3 はトレードオフ関係にある。

ログ I/O の累積

自動化スクリプトは大量のログを出力する。 1 時間で数百 MB に達する構成も珍しくない。 ログローテーション設定を入れないと、 永続化層の書き込み帯域が常時消費される。 NVMe Gen 4 以上の SSD なら帯域は十分だが、 SATA SSD では並行プロセスの I/O 競合がはっきり出てくる。

モデルファイル swap

VRAM / システム RAM 両方が不足した場合、 OS はモデル重みの一部をストレージに swap する。 35B モデルの一部 (数 GB 単位) が SSD に書き出される瞬間、 推論速度は数十分の一に落ちる。 モデルロード時の I/O 帯域も無視できない要素になる。

並行 DB アクセスの集積

動画検品の処理ログ、 ストックフォト動画の量産で生成される結果データ、 メタデータ DB が同時に書き込みを行う構成では、 ストレージ I/O の同時アクセス数が積み上がる。 64KB 級のランダム書き込みが秒間数百回発生する状態では、 NVMe Gen 4 以上でも IOPS 上限に近づく。 階層 4 (配電層) のバス帯域とも干渉してくる。

第 6 章: 階層 4 — 配電層 (電源 + バス + 帯域)

配電層は最下層で、 上の 3 層を支える物理基盤。 メモリ消費の話とは外れて見えるが、 配電層が弱ければ上の層がスペック通りに動かない。

GPU 電源系統

マルチ GPU 構成では電源容量が問題になる。 RTX 5080 (TDP 360W) + RTX 5060 Ti (TDP 180W) の合算 540W に CPU + その他で +250W、 合計 800W 程度に達する。 単一 850W 電源で賄うとピーク時に容量を圧迫する。

運用上の解決策として、 メイン GPU を本体 850W 電源で駆動し、 Oculink 接続のサブ GPU を独立した 750W 電源で駆動する 2 系統独立構成 が成立する。 この場合、 合算 TDP の議論は意味を持たなくなる。 メイン側 850W は CPU + RTX 5080 を支え、 Oculink 側 750W は RTX 5060 Ti 専用。 電源容量の同時ピークが発生しないため、 単一 1500W 電源より安定する場面もある。

PCIe x16 vs Oculink x4 の帯域差

メイン GPU が PCIe Gen 5 x16 (帯域 64GB/s) で接続される一方、 Oculink x4 は PCIe Gen 4 x4 相当 (帯域 8GB/s)。 帯域差は 8 倍ある。 推論層 (階層 1) で 2 GPU 分散をかけると、 この帯域差がそのまま速度差になる。 単一 GPU で 24GB VRAM を確保する方が、 16GB×2 を分散させるより推論速度は出る。

DDR5 チャネル数と並行プロセス

DDR5 デュアルチャネル構成では、 並行プロセス間でメモリ帯域が共有される。 Python プロセス 10 並列 + SQLite 並行アクセス + Ollama 推論が同時稼働する状態では、 メモリ帯域の競合が発生する。 シングルチャネル構成だと、 統合層 (階層 2) の処理速度がメモリ帯域で詰まる。

配電層が上の層に与える影響

配電層が弱い構成 (= 電源容量不足、 PCIe レーン数不足、 シングルチャネル DDR5) では、 上の 3 層がカタログスペック通りに動かない。 VRAM 16GB あっても電源不足で GPU クロックが落ちる、 RAM 96GB 積んでも帯域不足で並行プロセスが詰まる、 NVMe Gen 4 以上でも PCIe レーンが食い合って実効帯域が半減する。 配電層は表に出ないが、 構成全体の上限を決める。

関連記事: Oculink 接続の RTX 5060 Ti が Ollama に認識されない問題 / ComfyUI デュアル GPU 運用ガイド / DDR5-6000 — AI 用 PC メモリの買い時と必要容量

第 7 章: 4 階層が同時に動く時の実測値

稼働状態を 4 つのフェーズに分け、 階層別の負荷分布を整理する。 同一ハードウェア (i7-14700F / 96GB DDR5 / RTX 5080 16GB / RTX 5060 Ti 16GB Oculink、 電源 2 系統 850W + 750W) での実測。

環境前提について: 以下の数値は Python ベースの自動化スクリプトを複数プロセスで並行稼働させた環境での計測値になる。 Claude Code を単独で使う場合や、 単一の LLM 推論だけを回す構成では、 ここまでメモリが膨らまない。 Python マルチプロセス + SQLite + Ollama + ブラウザ MCP の組み合わせで初めて 50GB 帯に達する数値として捉えてほしい。 一般的な利用 (Claude Code 単独 + 軽い検索や文章生成) なら 15-20GB 程度で収まる。

フェーズ 1: アイドル (~10 GB)

OS + 常駐プロセスのみ。 階層 1 (VRAM) は 0、 階層 2 (RAM) が 10GB、 階層 3 / 4 はほぼ動いていない。 自動化を始める前のベースライン。

フェーズ 2: Claude Code 単独稼働 (15-20 GB)

階層 1 はほぼ 0 (LLM 推論はクラウド側)、 階層 2 が 15-20GB に膨らむ。 Python ランタイム + Node.js (MCP サーバ) + ブラウザ拡張で構成される。 階層 3 / 4 は軽微。 自動化を始めた直後はこの帯域に収まる。

フェーズ 3: Claude Code + ローカル LLM 推論 (25-35 GB)

階層 1 が 14-16GB を消費 (qwen3.6:35b-a3b ロード)、 階層 2 が 25-35GB に達する (Claude Code + Ollama spillover 6-12GB)。 階層 3 はモデルロード時の I/O が一時的にピーク。 階層 4 は GPU 電源と PCIe 帯域が継続使用される。

フェーズ 4: 並行運用ピーク (~50 GB)

マルチモーダル検品やストックフォト動画の量産処理 (ComfyUI で動画生成しながら、 別 GPU で品質スコアリングを並行で回す等) を稼働させた状態。 階層 1 は 14-16GB × 2 GPU、 階層 2 は 50GB 前後、 階層 3 は SQLite WAL とログ書き込みが継続発生、 階層 4 は電源 2 系統と DDR5 デュアルチャネルが上限近くで動く。 96GB DDR5 環境でも残量は半分程度になる。

関連記事: 量産型 AI 自動化の 4 層構造 — ストックフォト動画系で動かしている中身

第 8 章: メモリ予算設計の指針 — 階層別

用途別に必要なメモリ予算を、 階層別に整理する。

32GB 構成でも一応動く — ただし詰まる

32GB 構成でも仮想メモリ (swap) を使えば動作はする。 OS が RAM 不足を検知するとモデル重みやプロセスデータをストレージに退避するため、 メモリが足りなくても処理が止まることはない。 32GB は今でも一般的な選択肢として成立する。

ただし swap が発生した瞬間、 階層 3 (永続化層) のストレージ I/O が継続的に消費される。 NVMe Gen 4 以上でも書き込み帯域の数 % は swap で取られ、 LLM 推論速度は VRAM only に比べ数十分の一に落ちることがある。 並行プロセスを動かしている場合は、 swap 競合で全体が詰まる挙動も出てくる。

RAM を 32GB から 64GB / 96GB に増やすメリット:

• swap 発生を避けて推論速度を維持できる — Ollama の CPU spillover が発生してもストレージに書き出されない
• 並行プロセス数の上限が上がる — Python プロセス + Ollama + ブラウザ拡張を同時に動かしても余裕がある
• SQLite のメモリバッファに余裕ができる — DB 読み書きの速度が安定する
• 動画フレームや中間データを RAM 上で保持できる — マルチモーダル検品で複数フレームを同時評価する場合に有効
• LLM の重みを完全に RAM 上に置ける — VRAM 不足時の CPU spillover でもストレージへのフォールバックが発生しない

32GB は最低ラインで「動く」、 64GB で並行運用に余裕、 96GB で複数領域の同時稼働、 という段階で考えると判断しやすい。

階層別チェックリスト

• VRAM:RAM 比率は 1:3-1:4 を目安にする — 並行運用前提なら VRAM 16GB に対し RAM 64GB 以上
• DDR5 デュアルチャネル以上を確保する — 並行プロセス間でメモリ帯域が共有される
• NVMe Gen 4 以上の SSD を採用する — SQLite WAL / ログ書き込み / モデル swap の I/O が累積する
• マルチ GPU 構成は電源を分離する — Oculink 接続のサブ GPU は独立電源にすると、 メイン側の容量制約を受けない
• 並行プロセス数は CPU 物理コア数の 1.5-2 倍まで — Python の GIL があっても、 I/O bound タスクは並列度が活きる

VRAM と RAM の予算配分では、 単独推論なら VRAM 優先、 並行運用なら RAM 優先の傾向が出る。 ハードウェア更新時に VRAM だけ増やしても、 並行プロセスを増やした瞬間に RAM 側に上限が来る構造になっている。 4 階層モデルの全体を見て、 次にどこが詰まるかを判断する必要がある。

第 9 章: 関連記事

4 階層モデルの各階層を、 個別領域で深掘りした派生記事を以下に並べる。

推論層 (VRAM) を深掘りする

• RTX 5080 16GB VRAM の壁 — 27B / 32B モデルが動かない理由
• VRAM 16GB で LLM が起動しない時の解決法
• RTX 4060 8GB で Qwen3.6 35B MoE を動かす — VRAM 不足時の挙動
• llama.cpp で Gemma 4 実行時に RAM が枯渇する原因と対策
• llama.cpp 対応プラットフォーム完全ガイド
• 推論モデルとは — deepseek-r1 と qwen3 thinking の違い

統合層 (システム RAM) を深掘りする

• AI 用 PC のメモリ (RAM) とは — DDR5 / デュアルチャネルの基礎
• Ollama × NVIDIA ドライバの推論速度検証
• マルチモーダル検品の実装例 — 多段品質ゲートと評価軸の組み方
• Claude Code 自動化の実例 2026 年版
• 量産型 AI 自動化の 4 層構造

配電層 (電源 + バス) を深掘りする

• Oculink 接続の RTX 5060 Ti が Ollama に認識されない問題
• ComfyUI デュアル GPU 運用ガイド
• DDR5-6000 — AI 用 PC メモリの買い時と必要容量ガイド
• RTX 5080 で MoE モデルだけ消費電力が 1/4 に落ちる

参考資料

• NVIDIA 公式: GeForce RTX 5080 製品ページ
• Ollama 公式: GitHub リポジトリ (ローカル LLM 実行環境)
• llama.cpp 公式: GitHub リポジトリ (量子化 / GPU 分散ロード仕様)
• SQLite 公式: Write-Ahead Logging (WAL) ドキュメント
• Anthropic 公式: Claude Code 概要ドキュメント