はじめに
最近、ある学会発表に参加させてもらい、「ローカルLLM」や「マルチエージェントシステム」で課題解決をしているセッションが多く見受けられたのが印象にあります。そこで、私も自分のPCにローカルLLMやマルチエージェントシステムを実装してみてみたいと思い立ちました。
ですが、いきなり実装に入ると「モデルが大きすぎてVRAMが溢れる」「フレームワーク選定を間違えて作り直し」といった事故が起きる。
そこで本記事では、実際に手を動かす前の検討・準備フェーズにあえて時間を使い、「自分のPCでどこまでできそうか」「どのツール・フレームワークを選ぶべきか」「どんなエージェント構成にするか」を整理しようと思います。
検証環境
今回構築に使う予定のPCは、以前まとめたスペック紹介記事のものを使います。
ゲーミング・開発兼用機として組まれたものですが、ローカルLLMの実行環境としても十分にポテンシャルがある構成だと感じています。
一方で、マルチエージェント構築を考えるうえで事前に潰しておきたい論点もいくつかあるため、順に見ていきます。
| パーツ | スペック |
|---|---|
| CPU | AMD Ryzen 7 7700X (8コア16スレッド) |
| GPU | NVIDIA GeForce RTX 4060 Ti |
| メモリ | DDR5 64GB (16GB×4、5600MHz/6000MHz混在) |
| ストレージ | M.2 SSD 2TB + SSD 1TB |
| OS | Windows 11 Pro |
論点1: GPUのVRAM容量を確認する
RTX 4060 Tiは8GBモデルと16GBモデルが存在し、ローカルLLM用途では搭載VRAM容量が最初に確認すべき最重要項目になります。
マルチエージェント構成では「複数のエージェント＝複数モデルを同時にVRAMへ載せる」発想に陥りがちですが、VRAM容量が限られる場合はこの前提自体が成立しません。構築前に、まず自分のGPUのVRAM容量をnvidia-smi等で確認しておく必要があります。
■ 8GBモデルの場合
7B〜8B級モデルをQ4程度の量子化で動かすのが現実的なライン
■ 16GBモデルの場合
13B〜14B級、あるいはQ4量子化の32B級モデルまで視野に入る
■ 私の環境だと
8GBモデルなので、Gemma 3 4B / Gemma 3 12B（量子化次第） / Qwen3 4B / Qwen3 8Bの辺が快適に動作しそうですね。
$ nvidia-smi
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 591.86 Driver Version: 591.86 CUDA Version: 13.1 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Driver-Model | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 4060 Ti WDDM | 00000000:01:00.0 On | N/A |
| 0% 46C P5 27W / 160W | 674MiB / 8188MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
論点2: 実行基盤の選定
モデルを構築するうえで、玄人だと「Ollama」が一番に思い浮かぶと思います。ですが、わたしはOllamaは使わない方法で構築しようと思っています。
理由は以下の記事のように、脆弱性が見つかったことを知っているからです。
なので、Gemmaを直接構築する方法で、軽量に実行する選択肢で考えようと思っています。
■ 1. Python + Transformers（推奨）
Hugging FaceのtransformersライブラリでGemmaを直接ロードし、Pythonコード内で実行する最も単純なアプローチです。
import torch
from transformers import AutoTokenizer, AutoModelForCausalLM
model_id = "google/gemma-2-2b"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
device_map="cuda",
torch_dtype=torch.float16,
)
# 推論
inputs = tokenizer("Hello, my name is", return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_length=50)
print(tokenizer.decode(outputs[0]))
利点としては導入が簡単で、Pythonエコシステム内に完全に閉じており、セキュリティ面でも外部プロセスを立てないため安心です。一方、複数のCrewAIエージェントから同時呼び出しする際のマルチプロセッシング対応は自分で実装する必要があります。
■ 2. llama.cpp + Python バインディング
llama.cpp（C++ベース）をPythonから呼び出す方法です。Windows環境ではllama-cpp-pythonがシンプルです。
from llama_cpp import Llama
# GemmaのGGUF形式ファイルを事前に取得
llm = Llama(
model_path="./gemma-2b-q4_k_m.gguf",
n_gpu_layers=35, # GPU層の指定
n_ctx=2048,
verbose=False,
)
output = llm("Hello, my name is", max_tokens=50)
細かいチューニング（量子化形式・コンテキスト長・GPU層数の制御）が可能で、推論速度もTransformersより高速化する傾向にあります。ただし、GGUFファイルの事前取得と変換が必要です。
■ 2-3. LM Studio（GUI/API）
GUI ベースのアプリケーションで、モデルのダウンロード・管理・実行を見える化できます。バックグラウンドでREST API も提供するため、CrewAIから呼び出す場合はエンドポイント指定で利用可能です。セキュリティについてはGUIアプリであり、外部への通信も明示的です。
| 項目 | Transformers直接 | llama.cpp | LM Studio |
|---|---|---|---|
| 導入難易度 | 低（pip installのみ） |
中（GGUFファイル取得が別途必要） | 低（GUIで完結） |
| 推論速度 | 標準 | 高速 | 標準〜高速 |
| メモリ効率 | やや高め | 優秀（量子化制御可） | 優秀 |
| マルチプロセッシング | 自分で実装 | 自分で実装 | API経由（容易） |
| Windows対応 | ○ | ○（pythonバインディング経由） | ◎（公式対応） |
今回の用途を考えると、Python + Transformersで直接実行する方法からスタートするのがシンプルです。Gemmaは軽量モデルなので、RTX 4060 Tiでもgemma-2-2bやgemma-2-9bをfloat16で実行できます。複数エージェント間の呼び出しはスレッドやプロセスプールで管理することで対応可能です。
論点3: Gemmaモデルの選定
Gemmaシリーズはサイズが複数用意されているため、エージェントの役割ごとに使い分けることで効率的な運用が可能です。
- gemma-2-2b: 軽量タスク向け（ルーティング、要約、分類）
- gemma-2-9b: 標準的な推論・コード生成向け
- gemma-2-27b: より複雑な推論が必要な場面向け（RTX 4060 Tiではメモリが厳しい可能性）
Python + Transformersでの実行時は、float16またはint8量子化でVRAM消費を抑えることができます。
# float16での実行（VRAM効率重視）
model = AutoModelForCausalLM.from_pretrained(
"google/gemma-2-9b",
device_map="cuda",
torch_dtype=torch.float16, # 16ビット浮動小数点
)
# bitsandbytesでint8量子化（さらに軽量）
from transformers import BitsAndBytesConfig
bnb_config = BitsAndBytesConfig(load_in_8bit=True)
model = AutoModelForCausalLM.from_pretrained(
"google/gemma-2-9b",
quantization_config=bnb_config,
device_map="auto",
)
RTX 4060 Tiのメモリを考慮すると、最初はgemma-2-2bの複数インスタンスか、gemma-2-9bをfloat16で1つ立ち上げて役割ごとに切り分ける形がバランスが良さそうです。量子化についてはメモリに余裕があればfloat16から、逼迫してくればint8への移行を検討する、という段階的アプローチが現実的だと考えています。
論点4: マルチエージェントフレームワークの選定
2026年時点でのマルチエージェント系フレームワークの立ち位置を整理すると、おおよそ次のように分類できます。
| フレームワーク | 特徴 | 向いている場面 |
|---|---|---|
| LangChain | LLM呼び出し・プロンプト・RAGなどの基礎部品 | フレームワーク選定の前段、最小構成のPoC |
| LangGraph | 状態管理と実行フローをグラフ構造で制御 | 条件分岐・ループ・中断再開などが必要な本番運用 |
| CrewAI | 役割ベースでAIチームを組む直感的な設計 | アイデア検証や業務PoCを素早く形にしたい場合 |
| Microsoft Agent Framework | AutoGenとSemantic Kernelを統合したMicrosoft系基盤 | Microsoft/Azureエコシステム前提のエンタープライズ用途 |
なお、AutoGenは2026年に向けてメンテナンスモードへ移行し、Microsoft Agent Frameworkへ統合される流れにあるため、新規にAutoGen単体を選ぶのは現時点では避けたほうが無難そうです。
今回の用途（ローカル環境での個人開発・検証）を考えると、
- まずはCrewAIで役割ベースのエージェント構成をプロトタイピングする
- 構成が固まり、条件分岐や状態管理が複雑になってきたらLangGraphへ移行する
という二段階のアプローチが、Windows + Gemmaという今回の環境とも相性が良さそうです。
論点5: エージェント構成のたたき台
■ Phase 1: 単一エージェント時分割実行
今回の実装では、以下の2つのエージェントを「週1回ずつ、時間をずらして実行」する構成を想定しています。
【毎週金曜 18:00】AIトレンドエージェント実行
└─ 最近のAI動向を取得 → Gemmaで要約・構造化
【毎週金曜 19:30】政策発表エージェント実行
└─ 最近の国が発表したことを取得 → Gemmaで要約・構造化
※時間をずらすことでVRAM競合を回避
※同じGemma（AI特化ファインチューニング版）を使用
メリット
- メモリ効率：同時にGemmaを1つだけロード（約18GB float16）
- 実装が単純：CrewAI + APScheduler で素朴に実装可能
デメリット
- エージェント間の連携がない
- 複雑な判定ロジックが実装不可
■ Phase 1の期間
約4ヶ月（16回の実行）を予定し、以下を達成したらPhase 2へ移行：
- メモリ安定性：16回の実行後、エラーログ0件、メモリリーク < 100MB/月
- 出力品質：各記事の人手修正率 < 20%
- 運用安定性：スケジュール遅延0件
■ Phase 2: 複数エージェント構成への進化（将来予定）
Phase 1が安定したら、以下のような複数エージェント構成への拡張を検討：
【常時実行】軽量エージェント群
├─ リサーチエージェント：情報取得・スクレイピング
└─ ルーティングエージェント：取得した情報を分類・振り分け
【オンデマンド起動】重量エージェント
└─ 要約・構造化エージェント：詳細な内容生成
この構成では、軽量エージェントが常に情報を集め、必要に応じて重量モデルを起動することで、リアルタイム性と精度のバランスが取れます。
論点6: 開発・実行環境について
OSはWindows 11 Proですが、Pythonベースのフレームワーク（CrewAI/LangGraph）を扱う場合、WSL2上のUbuntu環境を使うか、Windowsネイティブで進めるかも検討ポイントです。
- Windowsネイティブ: PyTorchやtransformersはWindows対応が充実しているため、手早く試すなら問題なし
- WSL2: Pythonパッケージのビルドやツール群との相性が良く、将来的なDocker化を視野に入れると有利
Gemmaを直接ロードする場合、事前準備としては以下の環境が必要です。
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118
pip install transformers accelerate bitsandbytes
pip install crewai langchain langraph
ストレージは2TB＋1TBという構成のため、Gemmaのモデルファイル（2bで5GB程度、9bで20GB程度）の保存先を考えても容量面の不安は小さそうです。
今回はまずWindowsネイティブで、Pythonの仮想環境（venv）を作成して進める方針にする。
※ 単一エージェントの収集項目内容は変更する可能性もある。
まとめ
今回はローカルLLMでのマルチエージェント構築に向けて、以下を整理した。
■ 実行基盤はOllamaではなく、Python + Transformersで直接Gemmaをロードする方針（セキュリティ面で安心）
■ Gemmaは軽量モデルで、選定先としては現実的
■ エージェント構成はオーケストレーター＋リサーチ／コーディング／レビューの4役からスタートする
■ 開発環境はWindowsネイティブ＋Python仮想環境で進める