ローカルAIエージェント向けPCの選び方：作業・コンテキスト・常時稼働で考える

会議メモのファイルを一つ読み、要点をまとめてほしいと頼む場面を考えてみましょう。通常のチャットなら、本文を送って返答を待てば終わるかもしれません。エージェントはファイルを探し、読み取りツールを選び、結果をモデルに戻し、必要なら検索や別のツールを使ってから回答します。モデルの起動に必要な資源と、この一連の処理に必要な資源は重なりますが、同じではありません。

OpenClawやHermes Agentのようなプログラムはモデルの重みではありません。会話やセッション、ツール呼び出し²、チャネル、自動化の流れを調整するランタイムです。文章を生成するモデルは同じPCのローカルサーバーでも、LAN上の別のPCでも、ホステッドAPI³でも動かせます。したがって「OpenClawの必要スペック」という一つの見出しだけで選ぶと、実際に何を動かすかが抜け落ちます。

まず三つの問いを分けます。エージェントのランタイムをどのPCに置き、稼働させ続けますか。モデルサーバーはどこで動かしますか。一つの依頼でファイル・ブラウザー・検索・シェルのどれを何回使いますか。ランタイムだけを小型PCに置き、別のGPU⁴サーバーへ接続する構成もできます。一台で全て処理するなら、メモリの余裕に加えて熱・騒音・待機時の電力も考えます。

モデルがロードされたという表示は最初の関門にすぎません。同じモデルでも、短い質問と、会話履歴・ツール定義・ファイルの抜粋を含むエージェントの依頼では必要なメモリが変わります。チャットに答えられたからといって、ツール呼び出しの形式が合う、または依頼を完了できるとは限りません。このガイドでは会議メモの読み取りと要約という一つの作業を保ち、メモリと待ち時間の条件を一つずつ加えていきます。

候補モデルを選ぶ際、モデルファイルの容量は役立つ出発点です。ただし、同じ容量のメモリがあれば動くという意味ではありません。モデルの重みがメモリを使い、入力と会話状態を保持するコンテキストキャッシュが加わり、推論エンジン、OS、他のアプリもメモリを使います。一部をGPUに載せ、残りをシステムRAM⁵に置けるかは、エンジン・モデル形式・PCによって異なります。

OpenClawの公式ローカルモデル案内も、必要量は重み、コンテキストサイズ、ランタイム、同じホスト上の他の処理によって変わると説明しています。セットアップ時に利用可能なRAM、対応GPUメモリ、ディスク容量を確認するのはそのためです。特定の管理モデルレシピに記されたメモリの下限は、そのレシピが想定した条件の値であり、全モデル・エンジン・ツール構成の最低スペックや速度保証ではありません。

コンテキストウィンドウもモデルファイルの容量とは別です。モデルカードの最大コンテキストは、一度に処理できるトークン⁶数の上限に近く、その範囲を実際に使うとキャッシュメモリが増えることがあります。エージェントはさらに、システム指示、スキル説明、利用可能なツール名と引数形式、過去の会話、ファイルの抜粋を送る場合があります。長いコンテキスト対応と表示されたモデルでも、現在のサーバーがその長さを許可するか、メモリに確保できるかは別に確認します。

同じ作業で候補を比べるなら、会議メモのファイルだけでなく、モデルに実際に渡る入力を記録します。システムプロンプト、ツール説明、会話履歴、ファイルの長さ、回答の長さ、検索結果の有無をそろえます。そのうえでモデルをロードした状態のシステムメモリとGPUメモリ、残り容量、リクエスト失敗やメモリ回収の有無を見ます。数値はOSとランタイムの計測方法に左右されるため、別のPCの値とそのまま比較しません。

モデルがロードされて会議メモの要約を生成していても、作業全体の完了時間はモデルの速度だけでは決まりません。モデルが入力を読む時間（prefill⁷）、回答生成、ファイルツールのディスク読み込み、検索サーバーの応答、結果をエージェントが再解釈する時間が順に加わることがあります。一つの作業にモデル呼び出しが何回必要かも重要です。

簡単な計算で内訳を分けてみましょう。説明用の仮定として、モデルの入力処理に12秒、回答生成に18秒、ファイルツールに2秒、外部検索の往復に8秒かかるとします。合計は40秒です。これは実測値でも特定PCの予測でもありません。GPUによって入力処理だけが半分になり、他の区間が同じなら合計は34秒です。変わったのは12秒の区間だけで、ネットワーク待ちやファイル読み込みまで同じ割合で速くなったわけではありません。

外部検索を使わない作業なら、計算から検索待ちを外します。反対に、ブラウザーがページを開いて内容を読み、別のページを検索するなら、ツールの往復が何度か発生します。実際の製品とネットワークでどれだけかかるかは、作業ごとに測る必要があります。モデルのtokens/秒だけから「エージェント作業が何秒で終わる」と断定できないのはそのためです。

実際に比較する際は、モデルファイルと量子化⁸、エンジンのバージョン、GPUへの配置、コンテキスト設定、入力と出力の長さを固定します。準備実行の後、同じ作業を繰り返し中央値を記録します。モデルを初めてロードするコールド実行と、すでにロード済みのウォーム実行⁹を分けます。各ツール処理の開始・終了時刻と成功の有無を残せば、モデルを替えるべきか検索接続を直すべきか判断しやすくなります。測っていない数値は使いません。

メッセージボットや定期レポートを昼夜受け付けるには、エージェントのランタイムを稼働させ続ける必要があります。ただし、モデルのプロセスまで常にメモリに置く必要があるかは別の設定です。モデルサーバーがアイドル時にアンロードされるなら、次の依頼では再読み込みと初期化の時間が加わります。モデルをロードしたままにすれば一部の待ち時間は減りますが、他のアプリが使えるRAM/VRAMが減り、電力と熱も発生し続けます。

メモリ増設を検討する前に、普段起動しておくアプリと同時に届く依頼数を書き出します。会議要約を一件だけ手動で実行するなら、順番に処理すれば足りるかもしれません。複数のメッセージチャネル、定期タスク、二人の利用が重なるなら、一つのモデルに依頼をキューイングするか、複数のモデルやインスタンスを同時に起動するかを決めます。ピークメモリを左右するのはボットのプロフィール数より、同時に動く推論サーバーとコンテキストです。

ホストを再起動した後に、エージェントとモデルサーバーがどう復旧するかも確認します。ログイン前にサービスを起動する必要がありますか。モデルファイルはディスクに残っていますか。ネットワークが切れた場合もローカル作業を続けますか。メッセージチャネルに接続できない時、どう通知しますか。常時稼働のPCでは、最高速度だけでなく、復旧可能な設定、冷却、騒音、信頼できるストレージも大切です。電力は実機のアイドル時と負荷時に測定します。

Hermesの管理ローカルモデルとOpenClawの管理llama.cpp経路は、それぞれのプロジェクトが特定のランタイムとリリースでサポートする機能です。現在の公式ページでは、対応プラットフォーム、ビルドチャンネル、メモリ動作がバージョンごとに案内されています。この説明を、OllamaやLM Studioを直接運用するすべての構成に当てはめないでください。管理機能、自分で運用するサーバー、リモートサーバーはそれぞれ自分の環境で確かめます。

会議メモをたまに要約し、読み取り専用のツールだけを使うなら、まず今あるPCで小さめの候補モデルを試せます。「小さい」はモデル名ではなく、実際のファイル、量子化、コンテキスト上限、エンジンの対応状況で判断します。モデルのロード、短いチャット、会議メモの入力、読み取りツール一回、要約作業全体の順で確認します。失敗箇所を記録すれば、メモリ不足かツール互換性の問題かを分けられます。

長い会議メモや複数のファイルを扱うなら、実際の入力長と同時に起動しているアプリを含めて確認します。コンテキストを短くすると必要なメモリを減らせますが、モデルが読める資料も減ります。文書を分割して要約する、検索で必要な箇所だけを取得するといった方法で、モデルに渡すトークン数を調整できます。ただし原文全体を一度に渡す構成と同じ結果を保証するわけではないため、要約の抜けを人が確認します。

複数ユーザーや定期タスクが重なる時だけメモリが不足するなら、新しいGPUを買う前に依頼を順番に処理する、アイドル時にモデルをアンロードする設定を検討できます。一方、待ち時間で作業が何度も中断され、実測でモデル推論がボトルネックなら、GPUメモリやユニファイドメモリ¹⁰を増やす、別サーバーに配置するといった変更が役立つ可能性があります。ツール呼び出しの誤りや検索の遅さは、GPUを替えても解決しません。

最後に、なぜ常時稼働させるのかを確認します。定期実行がなければ、必要な時にデスクトップでGateway¹¹とモデルを起動する方が簡単かもしれません。メッセージ受信、定期レポート、リモートアクセスが必要なら、電源・ネットワーク・再起動・アクセス制御を含めた運用構成を作ります。購入判断はモデルファイルの容量だけでなく、目標作業、実際のコンテキスト、ツール往復、同時依頼、アイドル運用をまとめて試してから行えます。