「ローカル LLM なら VRAM 16GB で動く」 — この基準で組んだ構成でも、 Claude Code とローカル LLM を並行させるだけでシステム RAM を 25〜35GB 使う。 そこに Python マルチプロセスの自動化と動画生成まで重ねると 50GB 前後まで伸びる。 VRAM 議論で完結しない領域が、 AI エージェント自動化を始めた瞬間に立ち上がっている。 実際に詰まるのは VRAM、 システム RAM、 ストレージ I/O、 そして電源とバス帯域という性質の違う 4 か所。 前の 2 つは容量で先に効き、 後ろの 2 つは HDD や同期書き込みの多い設計、 電源・レーン不足といった構成条件がそろった時に表面化する。
本記事では、 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 推論 / Python マルチプロセス自動化 / 動画生成 + 検品を段階的に重ねた各状態の実測:
| 稼働状態 | システム RAM 使用量 | VRAM 使用量 |
|---|---|---|
| アイドル (OS + 常駐のみ) | 約 10 GB | 0 GB |
| Claude Code 単独稼働 | 15-20 GB | 0-2 GB |
| Claude Code + Ollama 推論 (qwen3.6:35b-a3b) | 25-35 GB | 14-16 GB |
| 並行運用ピーク | 50 GB 前後 | 14-16 GB × 2 GPU |
VRAM は単独タスクでは余裕がある。 でも並行運用ピークではシステム RAM が 50GB 前後に達し、 VRAM 合計 (28-32GB) の 1.6〜1.8 倍を消費していた。 この領域が VRAM 議論では出てこない。 ここから先は、 この 4 か所を層ごとに分けて見ていく。
第 2 章: 詰まりどころ 4 か所の全景
AI エージェント自動化のメモリ消費は、 次の 4 か所で積み上がる。 以下では上から順に推論層 / 統合層 / 永続化層 / 配電層と呼んで整理する (本記事内での呼び分け)。
| 階層 | 名称 | 主な消費要素 | 典型サイズ |
|---|---|---|---|
| 1 | 推論層 (VRAM) | LLM 重み + KV cache + 推論バッファ | 16-24 GB |
| 2 | 統合層 (システム RAM) | エージェント実行 + 並行プロセス + DB バッファ + Ollama spillover | 25-50 GB (並行運用ピークで 50GB 前後) |
| 3 | 永続化層 (ストレージ + I/O) | DB 書き込み / ログ / モデル swap | 帯域 (MB/s) |
| 4 | 配電層 (電源 + バス + 帯域) | GPU 電源 / PCIe / Oculink / DDR5 チャネル | W / Gbps |
4 階層は独立しているのではなく、 上の層が下の層に依存する構造になっている。 推論層が VRAM を使い切れば統合層に spillover が発生し、 統合層が RAM を使い切れば永続化層への swap が始まる。 配電層はこの 3 層の土台で、 電源やメモリ帯域が足りなければ上の層がカタログ通りに動かない。 逆に、 永続化層の書き込み量そのものが配電層の帯域を埋めることは、 NVMe を使う限りほぼ起きない (第 5 章)。
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 に分散した 32GB は単独 32GB と同じには使えない。 レイヤー分割では GPU 間を流れるのは分割境界の中間状態だけで転送量は小さく、 速度を決めるのは片方が計算している間もう片方が待つ逐次実行のほうになる。 1 枚に収まるモデルなら単独 GPU が有利な場面が多い一方、 収まらず CPU オフロードが起きる構成では 16GB×2 に分散したほうが速い。 Ollama や llama.cpp は GPU 間分散をサポートする。 リンク帯域差 (Oculink x4 = PCIe Gen4 x4 相当 = 約 8GB/s) が引っかかってくる。
spillover が発生する瞬間
VRAM 容量を超えるモデルをロードすると、 超過分はシステム RAM に置かれる。 これが推論層から統合層への spillover になる。 RTX 5080 (16GB) で qwen3.6:35b-a3b (24GB モデル) を動かすと、 重みの一部 (当環境では 6-12GB) がシステム RAM 側に張り付く。 推論速度は落ちるが、 MoE はトークンごとに使う重みが一部に限られるため、 同サイズの dense モデルをあふれさせた場合より低下は緩やかになる。
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 ファイルが数本なら、 SQLite 自身のページキャッシュとOS のファイルキャッシュを合わせても数百 MB 規模にとどまる。 効いてくるのは 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 に達する経路
OS・常駐で約 10GB、 そこに Python プロセス群 5GB + Ollama spillover 6-12GB + ブラウザ 3GB + Python 側キャッシュ 2-4GB + SQLite 数百 MB が乗り、 ここまでで 30GB 前後。 並行運用ピークの 50GB は、 これに動画生成ワークフローと対話作業が重なった状態で、 内訳の再現性は環境差が大きい。 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 単位に膨らむことがある。 一方でメモリ側に乗るのは WAL インデックスと書き込みバッファで、 こちらは数百 MB 規模にとどまる (第 4 章)。 チェックポイント頻度を下げると書き込みは速くなるが、 WAL が伸びるぶん読み出しとメモリ側の常駐が増える。 階層 2 と階層 3 はトレードオフ関係にある。
ログ I/O の累積
自動化スクリプトは大量のログを出力する。 1 時間で数百 MB に達する構成も珍しくない。 ログローテーションを入れないと、 帯域より先にディスク容量を食い潰す。 帯域そのものは NVMe でも SATA SSD でも余裕がある。 本記事で扱う規模で先に効くのは、 容量とローテーションの設計。
モデルファイル swap
VRAM / システム RAM 両方が不足した場合、 OS はモデル重みの一部をストレージに swap する。 35B モデルの一部 (数 GB 単位) が SSD に書き出される瞬間、 推論速度は数十分の一に落ちる。 モデルロード時の I/O 帯域も無視できない要素になる。
並行 DB アクセスの集積
動画検品の処理ログ、 ストックフォト動画の量産で生成される結果データ、 メタデータ DB が同時に書き込みを行う構成では、 ストレージ I/O の同時アクセス数が積み上がる。 ただし 64KB 級の書き込みが秒間数百回でも実効は数十 MB/s 程度で、 NVMe の IOPS・帯域には十分余裕がある。 ここで詰まりやすいのは HDD (ランダム書き込みが数百 IOPS 程度で頭打ちになりやすい) や、 同期書き込みで fsync 待ちが積み上がる場合。 SATA SSD は数万 IOPS の余力があるので、 この程度の書き込み回数では通常問題にならない。
第 6 章: 階層 4 — 配電層 (電源 + バス + 帯域)
配電層は最下層で、 上の 3 層を支える物理基盤。 メモリ消費の話とは外れて見えるが、 配電層が弱ければ上の層がスペック通りに動かない。
GPU 電源系統
マルチ GPU 構成では電源容量が問題になる。 NVIDIA 公式が示す必要電源 (Required System Power) は RTX 5080 単体で 850W、 RTX 5060 Ti 単体で 600W。 カードの TDP を足すだけだと (360W + 180W + CPU ほか 250W で 800W 程度) 公式値を下回る見積もりになるので、 マルチ GPU では単体の公式値を土台に積み増して考えたい。 いずれにせよ単一 850W 電源では 2 枚を同時に賄いきれない。
運用上の解決策として、 メイン GPU を本体 850W 電源で駆動し、 Oculink 接続のサブ GPU を独立した 750W 電源で駆動する 2 系統独立構成 が成立する。 この場合、 単一 PSU の容量計算からはサブ GPU 分が外れる (ただし壁のコンセントとブレーカーは共有なので、 合計消費電力の上限は残る)。 メイン側 850W は CPU + RTX 5080 を支え、 Oculink 側 750W は RTX 5060 Ti 専用。 それぞれの PSU にヘッドルームを確保できるのが利点になる。 ただし 2 系統構成は起動タイミングの同期が別途必要で、 単一の大容量電源より無条件に安定するわけではない。
PCIe x16 vs Oculink x4 の帯域差
メイン GPU が PCIe Gen 5 x16 (帯域 64GB/s) で接続される一方、 Oculink x4 は PCIe Gen 4 x4 相当 (帯域 8GB/s)。 帯域差は 8 倍ある。 ただしレイヤー分割の推論では、 GPU 間を毎トークン流れるのは分割境界の中間状態だけで転送量は小さく、 生成速度に効くのはリンク帯域よりも「片方が計算している間もう片方が待つ」逐次実行のほうになる。 当サイトの実測でも、 PCIe Gen 5 x16 と Oculink (Gen 4 x4) で同一モデルの生成時間に帯域比ほどの差は出ていない。 帯域差が効きやすいのはプロンプト処理とモデルのロード時。 VRAM に収まりきらず CPU オフロードが発生する構成なら、 16GB×2 に分散したほうが速くなる場面もある。
DDR5 チャネル数と並行プロセス
DDR5 デュアルチャネル構成では、 並行プロセス間でメモリ帯域が共有される。 Python プロセス 10 並列 + SQLite 並行アクセス + Ollama 推論が同時稼働する状態では、 メモリ帯域の競合が発生する。 シングルチャネル構成だと、 統合層 (階層 2) の処理速度がメモリ帯域で詰まる。
配電層が上の層に与える影響
配電層が弱い構成 (= 電源容量不足、 PCIe レーン数不足、 シングルチャネル DDR5) では、 上の 3 層がカタログスペック通りに動かない。 VRAM 16GB あっても電源不足で GPU クロックが落ちる、 RAM 96GB 積んでも帯域不足で並行プロセスが詰まる、 M.2 スロットが GPU とレーンを共有していれば SSD が本来の速度を出せないこともある (もっとも、 この記事で扱う書き込み量なら SSD 側の帯域には余裕があるので、 ここが効くのは大きなファイルを連続で読み書きする場面)。 配電層は表に出ないが、 構成全体の上限を決める。
関連記事: Ollama が2枚目の GPU を使わない理由 / 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 までなら 30GB 前後で、 そこに動画生成と検品を並行させて初めて 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 (1 モデルの分割ではなく、 GPU ごとに別ワークロード)、 階層 2 は 50GB 前後、 階層 3 は SQLite WAL とログ書き込みが継続発生、 階層 4 は 2 系統の電源が同時に負荷を受け、 DDR5 の帯域競合が最も強く出る状態になる (容量自体はメイン側 850W に対し 600W 台、 サブ側 750W に対し 200W 未満で、 上限に張り付くわけではない)。 96GB DDR5 環境でも残量は半分程度になる。
| フェーズ | 階層 1 (VRAM) | 階層 2 (RAM) | 階層 3 (I/O) | 階層 4 (配電) |
|---|---|---|---|---|
| 1: アイドル | 0 GB | ~10 GB | 軽微 | 軽微 |
| 2: Claude Code | 0-2 GB | 15-20 GB | 低 | 低 |
| 3: +ローカル LLM | 14-16 GB | 25-35 GB | 中 (ロード時ピーク) | 中 (GPU 電源継続) |
| 4: 並行運用ピーク | 14-16 × 2 GB | 50 GB 前後 | 高 (継続書込) | 高 (2 系統 + DDR5) |
関連記事: 量産型 AI 自動化の 4 層構造 — ストックフォト動画系で動かしている中身
第 8 章: メモリ予算設計の指針 — 階層別
用途別に必要なメモリ予算を、 階層別に整理する。
| 用途 | 階層 1 (VRAM) | 階層 2 (RAM) | 階層 3 (Storage) | 階層 4 (配電) |
|---|---|---|---|---|
| シングルタスク (LLM 推論のみ) | 16-24 GB | 32 GB | NVMe (Gen 3 で足りる) | 650W 単一電源 |
| Claude Code + ローカル LLM 1 つ | 16 GB | 48-64 GB | NVMe (世代より容量) | 750W 単一電源 |
| 並行運用 (3 タスク以上) | 16-24 GB | 64-96 GB | NVMe (世代より容量 1TB+) | 850W + DDR5 デュアル |
| 動画生成 + 検品処理を並行 | 16 GB × 2 GPU | 96 GB+ | NVMe (世代より容量 2TB+) | 2 系統独立電源 + DDR5 デュアル |
32GB 構成でも一応動く — ただし詰まる
32GB 構成でも仮想メモリ (swap) を使えば動作はする。 OS が RAM 不足を検知するとモデル重みやプロセスデータをストレージに退避するため、 多少足りない程度なら遅くなるだけで済む。 ただしページファイルの上限を超えればアロケーション自体が失敗し、 プロセスが落ちることはある。 32GB は今でも一般的な選択肢として成立する。
ただし swap が発生した瞬間、 階層 3 (永続化層) のストレージ I/O が継続的に消費される。 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 で複数領域の同時稼働、 という段階で考えると判断しやすい。
階層別チェックリスト
- RAM は VRAM 容量からの比率ではなく、 同時に動かすプロセスの積み上げで決める — 当環境では Python マルチプロセス + SQLite + ブラウザ MCP + Ollama で 30GB 前後、 これに動画生成と検品を重ねたピークで 50GB 前後だった。 同じワークロードなら、 VRAM を増やすと spillover (当環境で 6-12GB) が減るぶん RAM 需要はむしろ下がる。 上の表で VRAM と RAM が一緒に増えているのは比例しているからではなく、 行ごとに同時に動かすものが増えているため。 目安は実測ピークに 1.5〜2 倍の余裕を乗せる — Claude Code + ローカル LLM 1 つは実測 25-35GBなので 48-64GB、 動画生成や検品まで重ねると実測 50GB 前後なので 96GB
- DDR5 デュアルチャネル以上を確保する — 並行プロセス間でメモリ帯域が共有される
- HDD を避けて SSD にする。 SATA か NVMe かは二の次 — 詰まるのは帯域ではなく fsync 待ちと小サイズのランダムアクセスで、 SATA SSD でも数万 IOPS の余力がある。 当環境の書き込み量なら Gen 3 と Gen 4 の差も表に出ないので、 インターフェースの世代より容量 (ログ + モデルで 1-2TB) と書き込み耐久を優先する
- サブ GPU を独立電源にすると、 メイン PSU の容量計算からサブ GPU 分を外せる — ただし壁のコンセントとブレーカーは共有で合計消費電力の上限は残り、 2 系統は起動タイミングの同期が別途必要になる
- 並行プロセス数は CPU コア数より RAM 容量で先に頭打ちになる — 1 プロセスあたり 200-500MB 載るため、 10 並列なら 2-5GB が固定で乗る。 CPU bound な処理を混ぜる場合はコア数、 待ち時間の長い I/O 中心なら RAM の残量が実質的な上限になる
VRAM と RAM の予算配分では、 単独推論なら VRAM 優先、 並行運用なら RAM 優先の傾向が出る。 ハードウェア更新時に VRAM だけ増やしても、 並行プロセスを増やした瞬間に RAM 側に上限が来る構造になっている。 4 か所すべてを見て、 次にどこが詰まるかを判断する必要がある。
第 9 章: 関連記事
このうち推論層・統合層・配電層について、 さらに掘り下げた記事を以下に並べる。
推論層 (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 / デュアルチャネルの基礎
- マルチモーダル検品の実装例 — 多段品質ゲートと評価軸の組み方
- Claude Code 自動化の実例 2026 年版
- 量産型 AI 自動化の 4 層構造
配電層 (電源 + バス) を深掘りする
- Ollama が2枚目の GPU を使わない理由
- ComfyUI デュアル GPU 運用ガイド
- DDR5-6000 — AI 用 PC メモリの買い時と必要容量ガイド
- RTX 5080 で MoE モデルだけ消費電力が 1/4 に落ちる
