AIエージェント

AIエージェントは、LLMが「次に何をするか」を自分で決め、道具を使い、結果を見て、目標に達するまで繰り返す使い方です。チャットが「一問一答」なのに対し、エージェントは「頼んだら勝手に何手も進める」もの。同じモデルでも、チャットで使うときとエージェントで使うときでは、必要なVRAMが変わります——理由は後述します。

3つの要素

• 道具を使う(tool calling / function calling) — 検索・コード実行・ファイル操作・API呼び出しなどを、モデル自身が呼び出す
• ループする — 実行 → 結果を見る → 次の手を決める、を繰り返す
• 自分で判断する — 人が毎回指示するのではなく、目標だけ与えれば経路はモデルが決める

「エージェント」と呼ばれがちだが違うもの

この言葉は広く使われすぎていて、中身が違うものが同じ名前で呼ばれています。区別の軸は「次の手を誰が決めるか」です。

例えば「毎朝ニュースを取得→要約→投稿」は手順が固定なのでワークフローです。「このバグを直して」と言われて、自分でファイルを探し、読み、直し、テストを走らせ、失敗したら別の方法を試す——これがエージェント。失敗を検知してやり直せるか(Failure Recovery)が、実用上の分かれ目になります。

ローカルで動かすとき、何が変わるのか

ここが当サイトの本題です。エージェントの3要素は、そのままハードウェアの要求に跳ね返ります。

• ループする → 文脈が長くなる。過去の手順とツールの出力が積み上がるため、チャットの数千トークンに対し、エージェントでは数万〜十数万トークンが要ります。文脈が伸びるとKVキャッシュが膨らみ、必要VRAMが増えます。
• 道具を使う → 出力の正確さが要る。ツール呼び出しはJSONなどの決まった形で出す必要があり、量子化を効かせすぎると形が崩れて失敗しやすくなります。
• 多ステップ → 誤差が積み上がる。1ステップで97%成功しても、20ステップ続けば完走率は約54%です。「1回の返答が良い」ことと「20手やり切れる」ことは別です。

意外な逆転 — 大きいモデルのほうが有利なことがある

文脈を延ばしたときの増え方は、モデルの構造によって大きく違います。当サイトの判定式で計算すると、Q4_K_Mで文脈8Kから128Kに延ばした場合:

KVヘッドの少ない構成(MoEやMLA系)は、文脈を延ばしても増え方がゆるやかです。その結果、同じ24GBのGPUでも、短い文脈なら32B denseが載るのに、長い文脈では35B-A3B(MoE)しか載らないという逆転が起こります。チャットではパラメータ数が効き、エージェントではKVの構造が効く——これが実務上の勘所です。

上の数値は当サイトの判定式による理論値で、実測値ではありません。実際の必要量は使うランタイム・KVキャッシュの量子化設定などで変わります。

始めるには

ローカルのモデルをエージェントの「頭脳」として使うには、OllamaやLM Studioでモデルを立て、エージェント側のツール(ツール利用に対応したクライアント)から接続します。まずはお使いのGPUで、長めの文脈でも収まるモデルを選ぶところからです——トップの判定で確認したうえで、各モデルページの「エージェント用途」の注記を見てください。手元で足りない場合はクラウドGPUという手もあります。

関連用語

• ツール利用(function calling / MCP / スキル) — 汎用モデルに検索・コード実行・API操作などの「手順」を外付けする仕組み。ローカル小型は苦手
• KVキャッシュ — 会話の文脈を保持する作業メモリ。GQA・MLA・ハイブリッドアテンションでサイズが数十倍変わる
• コンテキスト長 — モデルが一度に覚えていられる会話・文書の長さ。長いほどKVキャッシュがVRAMを食う
• MoE(Mixture of Experts) — 「総パラメータは大きいが、毎回動くのは一部だけ」という設計。容量は総量・速度は実効で決まる

参考資料(出典)

• https://docs.ollama.com/
• https://github.com/ggml-org/llama.cpp

▶ あなたのPCで動くモデルを自動判定する(スペック送信なし・ブラウザ内完結)