VPSで自作AI agentを構築する方法と仕組み

AI agentの実体とは

AI agentは、language modelを包み込むループです。modelが状況を読み取り、1つのactionを決定し、codeがそのactionを実行し、その結果がmodelに返され、タスクが完了するまでこのループが繰り返されます。これが基本概念です。通常のchatbotは、1回回答して終了します。agentは、与えられた目標に到達するまで、自身のturnの間に実際のactionを実行し続けます。

actionこそが重要な要素です。language model単体では、テキストを生成することしかできません。fileの読み込み、APIの呼び出し、commandの実行は不可能です。agentは、modelに対して使用可能な一連のtoolsと、それらを要求するための手段を提供します。modelがweb検索やfileの書き込みを行いたい場合、model自身が作業を行うわけではありません。modelはstructured requestを出し、codeがtoolを実行し、その回答が次のmodelへの入力として返されます。modelが判断を提供し、serverが実行（手）を提供します。

すべてのタスクにagentが必要なわけではなく、デフォルトでagentを採用するのはよくある間違いです。手順が事前に決まっている場合は、通常のscriptの方がシンプルで高速、かつ信頼性が高いです。「1時間ごとにこのpageを取得して、価格をemailで送る」のはscheduled jobであり、agentではありません。手順が事前に固定されておらず、modelが発見した内容に基づいて次に何をすべきか判断する必要がある場合に、agentを構築してください。agentのコストは予測不可能性であるため、柔軟性がメリットをもたらす場合にのみ採用してください。

Tools: agentの動作原理

toolとは、modelに渡すあらゆる機能のことであり、modelがいつそれを使うべきか判断できる程度に十分に記述されている必要があります。fileの読み込み、shell commandの実行、databaseへのクエリ、messageの送信など、それぞれがname、短いdescription、およびinputのリストを持つtoolとなります。toolを定義するのはユーザーであり、それらをいつ呼び出すかを決定するのはmodelです。

使用するmodelに関わらず、メカニズムは共通しています。modelはtoolの名前とinputを埋めたstructured requestを返します。codeはそのrequestを検知して対応するfunctionを実行し、結果を次のturnで返します。modelはその結果を読み取り、別のtoolを呼び出すか、最終的な回答を書き出します。Function callingはすべてのagentの基盤となる仕組みであり、それを駆動するループは数行の通常のcodeで構成されます。

ここが制御を行う場所でもあります。modelはcommandの実行を要求できますが、codeが実行を選択するまで何も実行されません。その隙間に、危険なactionに対する承認プロンプト、toolがアクセスできる範囲の制限、およびagentが行ったすべてのログを配置します。agentの安全性は、提供するtoolsと、その前段に配置するチェック機能に依存します。

MCP: toolsを接続するための標準規格

サービスごとに個別のintegrationを手書きするのは非効率です。Model Context Protocol（MCP）は、この問題を解決するオープンスタンダードです。file、database、issue trackerごとに新しいtoolをコーディングする代わりに、agentを、それらをtoolとして公開している既存のMCP serverに向けるだけで済みます。agentは1つのprotocolで通信し、serverが実際のシステムとの通信を担当します。

利点は再利用性です。他の誰かが特定のサービス向けに作成したMCP serverは、新しいintegration codeなしでagentから利用可能になり、自身が作成したserverは、そのprotocolを話すあらゆるagentから利用可能になります。VPSでは、MCP serverをagentの隣で個別の小さなserviceとして実行できるため、この仕組みは重要です。セットアップについては running MCP servers on a VPS で解説しています。

Memory and retrieval

language modelは、callの間に独自のmemoryを持ちません。現在のタスクに関する情報は、各turnでモデルに渡す必要があります。短いジョブであれば、会話全体が1つのrequestに収まるため問題ありません。それより長いジョブの場合は、自身でmemoryを管理する必要があり、知っておくべき2つのパターンがあります。

1つ目はscratchpadです。agentに読み書き可能なfileを与え、学習した内容を記録するように指示します。次のturnや次のsessionで、agentはそのfileを読み込み、中断した箇所から再開します。これはドキュメントとしてのmemoryであり、agentがそのfileを単なるtoolとして扱うことで機能します。

2つ目はretrievalです。agentが、1つのrequestには収まりきらない大量のドキュメントから知識を必要とする場合、ドキュメントを検索可能な形式で保存し、必要な部分だけをmodelのコンテキストに読み込みます。このパターンはretrieval-augmented generation（RAG）と呼ばれます。agentが質問を投げ、codeが一致する数個のpassageを見つけ、それらだけをmodelに送ります。データストアはserver側に置かれるため、プライベートなドキュメントが外部に漏れることはありません。

Many agents, one coordinator

多くのtoolを持つ1つのagentは、ほとんどのタスクに適しています。ジョブが大規模であったり、自然に分割されたりする場合は、別の構成が有効です。それは、専門化されたsub-agentsにタスクを委譲するcoordinator agentです。coordinatorは目標を細分化し、各パーツをその作業に特化したsub-agentに渡し、結果を統合します。

利点は集中（focus）です。狭いjobと限定的なtool setを持つsub-agentは、すべてをこなそうとする汎用的なagentよりも優れた判断を下し、各パーツを並列に実行することも可能です。ただし、調整（coordination）にはコストがかかるため、タスクが明確にそれを必要とするまでは、単一のagentに留めておいてください。まずはシンプルに始め、1つのagentに負荷がかかり始めたときにagentを追加してください。

Self-hosted or hosted: どのモデルを動かすか

modelは、agentの中で自身で実行する必要がない唯一のパーツであり、どこに配置するかは最も重要な決定事項です。API経由でアクセスするhosted modelは、運用コストなしで強力な推論を提供します。textを送信すれば、textが返ってきます。self-hosted modelは自身のserverで動作するため、すべてのrequestがプライベートに保たれ、tokenごとの料金ではなく固定料金で利用でき、他者の稼働状況に依存しません。トレードオフは、能力と工数です。優れたhosted modelは、自身で実行できるものよりも高性能であり、自身のモデルを動かすには、十分なmemoryを供給する必要があります。

この最後の点が実用上の制約となります。modelはserverのmemoryに収まる必要があり、GPUを使用する場合はvideo memoryにも収まる必要があります。ハードウェアに対して大きすぎるmodelはロードできません。self-hosted agentを計画する前に、使用したいmodelが所有するマシンに収まるか確認してください。

数値が合わない場合は、3つの選択肢があります。より小さなmodelを選ぶ、より強力なquantizationを使用してサイズを縮小する、あるいは推論にはhosted APIを使用し、serverにはtoolとデータのみを置く、という方法です。多くのself-hosted agentは、まず Ollama on a VPS を介したローカルmodelから始め、最も困難なステップにおいてhosted APIへフォールバックします。

The server is the dangerous part

shell commandを実行し、fileを書き込めるagentは強力ですが、だからこそ危険です。modelの判断は優れていますが完璧ではありません。誤った指示、バグ、または悪意のある入力によって、便利なagentが、誤ったものを削除したり機密を漏洩させたりする存在に変わる可能性があります。セキュリティ対策は任意ではなく、server運用においては最も重要な部分です。

いくつかの習慣がリスクを大幅に軽減します。agentは、エラーの影響範囲を限定するために、rootではなく専用のunprivileged userとして実行してください。詳細は running services as an unprivileged user を参照してください。API keyなどの機密情報はcodeから分離し、そのuserのみが読み取れるようにしてください。また、systemに触れるtoolはsandbox化し、agentが必要なものだけにアクセスできるように制限してください。実際のself-hosted agentの要塞化（hardening）の例については、running OpenClaw safely on a VPS を参照してください。推論にhosted modelを使用したい場合は、building an agent with Claude on a VPS が、同じ概念を特定のmodelに適用して解説しています。

具体的な実装例として、building an OpenClaw-style personal agent がこれらの要素を適用しています。完成されたものを使用したい場合は、self-hosting Hermes Agent on a VPS または running Agent Zero on your own server から始めてください。また、the best self-hosted AI agents in 2026 では、紹介しているすべての既製品の選択肢を比較しています。

FAQ

AI agentとchatbotの違いは何ですか？

chatbotはメッセージに回答して終了します。agentはループを実行します。modelがactionを決定し、codeがそれを実行し、結果がmodelに返され、タスクが完了するまで繰り返されます。違いは、agentはテキストを生成するだけでなく、fileの読み込み、commandの実行、サービスのクエリなどの実際のactionをturnの間に実行する点です。

VPSでAI agentを動かすためにGPUは必要ですか？

modelをself-hostする場合のみ必要です。agentのループ、tool、memoryは通常のcodeであり、GPUのない通常のVPSでも問題なく動作します。GPUが必要になるのは、language modelを自身のハードウェアで動かしたい場合です。modelはmemoryに収まる必要があるからです。API経由でhosted modelを使用する場合、重い計算は別の場所で行われるため、控えめなスペックのVPSで十分です。

MCPとは何ですか？agentの構築に必要ですか？

MCP（Model Context Protocol）は、agentをtoolやデータソースに接続するためのオープンスタンダードです。各toolを手書きできるため、厳密には必須ではありません。しかし、MCPを使用すれば、一般的なサービス向けの既存のserverを再利用でき、自身のシステムも一度の定義で任意のagentから利用可能になるため、作業を大幅に削減できます。統合する数が増えるにつれて、その利便性が高まります。

AI agentにserverへのアクセス権を与えるのは安全ですか？

制御（contain）できていれば安全になり得ます。commandを実行できるagentの安全性は、実行ユーザーと許可したtoolに依存します。unprivileged userとして実行し、機密情報はアクセス不能にし、filesystemに触れるtoolはsandbox化し、取り消しが困難なactionには承認を必要とするようにしてください。agentは「賢いだけの信頼できないcode」として扱い、タスクに必要な最小限の権限のみを与えてください。