ローカルLLMはAIエージェントのバックエンドとして機能するのか
ローカルLLMをOllamaで動かし、AIエージェントとして使うときに確認すべきポイントを整理しました。
この記事は、以下のブログ記事のイントロダクションです。
チャットでは、多少おかしな文章が返ってきても人間が読んで補正できます。しかしエージェントは、LLMがツールを呼び出し、その結果を読み、次の処理を選びます。たとえば、ファイルを検索して内容を読み、修正し、テストを実行するという流れです。ツール呼び出しのJSONに説明文が混ざる、必須プロパティが抜ける、数値と文字列の型が違う、存在しないツール名やパスを生成するといった問題は、そのまま実行エラーになります。
このため、モデルの能力だけでなく、ランタイム側の設計も重要です。JSON SchemaやStructured Outputsで形式を検証し、失敗した場合はエラー内容をツール結果としてLLMに返します。ツール数を必要最小限に絞り、ループ上限とタイムアウトも設定します。ローカル環境はAPI課金がないため、失敗や無限ループに気づきにくい点にも注意が必要です。
OllamaをWSL2で使う場合は、まずサービスの起動とAPIの疎通を確認します。
curl -fsSL https://ollama.com/install.sh | sh
ollama serve &
curl -s http://localhost:11434/api/tags | head
NVIDIA GPUを利用する場合は、WSL2からGPUが見えているかをnvidia-smiで確認し、モデル実行中にollama psを実行します。PROCESSOR列がGPUだけでなくCPUになっている場合、VRAM不足によるオフロードで処理速度が大きく低下している可能性があります。
もう一つの重要な確認項目がコンテキスト長です。エージェントでは、LLMへの指示だけでなく、ファイル内容や検索結果などのツール実行結果も履歴に追加されます。Ollamaの実行時パラメータnum_ctxが小さいと、履歴の古い部分がエラーなしで切り捨てられ、エージェントが最初の指示を忘れたまま処理を続けることがあります。
ollama show --parameters <モデル名>
APIで明示的に設定する場合は、次のように指定します。
curl -s http://localhost:11434/api/chat -d '{
"model": "<モデル名>",
"messages": [{"role": "user", "content": "ping"}],
"options": {"num_ctx": 32768, "temperature": 0},
"stream": false
}'
ただし、num_ctxを大きくするとKVキャッシュがVRAMを消費します。モデルの重みがGPUに載るかだけでなく、必要なコンテキスト長を確保した状態でGPU実行できるかを確認してください。
記事では、ローカルLLMを評価するためのタスクも提案しています。ファイル操作、Web検索から要約までの処理、テストが失敗するコードの修正という3種類です。評価指標には、タスク完了率、スキーマ検証を通過したツール呼び出し率、平均ターン数、所要時間、生成トークン毎秒、同一操作の反復回数を使います。検索結果などの入力を固定し、最低5回、できれば10回程度は試行します。
この記事では、Ollamaを実行できなかったため、モデルごとの性能を示す実測値は掲載していません。未測定の数字を推測せず、読者が自分の環境で再現できる評価手順と記録項目を示しています。GPU、VRAM、量子化方式、num_ctx、Ollamaのバージョン、ツール定義が違えば結果も変わるため、他人のベンチマークをそのまま自分の判断に使うのは危険です。
ローカルLLMが向いているのは、機密データのマスキング・分類、大量文書の夜間処理、定型的なツール実行などです。難しい計画はクラウドLLMに任せ、機密データを扱う反復処理はローカルLLMに任せるハイブリッド構成も紹介しています。
ローカルLLMを「チャットとして動いた」だけで評価せず、ツール呼び出し、長いループ、コンテキストの保持、失敗からの回復まで含めて検証したい方に向けた記事です。
参考リンク
- Ollama：https://ollama.com/