VPSでAIエージェントを自作する方法
AIエージェントは、言語モデルが判断し、コードがツールを実行するループです。VPS上で作る基本構造から、ツール、MCP、メモリ、安全対策まで学べます。
AI エージェントとは実際には何か
AI エージェントは、言語モデルを中心としたループです。モデルが状況を読み取り、1 つのアクションを決定し、コードがそのアクションを実行します。その結果をモデルに返し、タスクが完了するまでループを繰り返します。これが基本的な仕組みです。通常のチャットボットは 1 回だけ回答して停止します。エージェントは自分のターンの間に実際のアクションを実行しながら、与えられた目標に到達するまで処理を続けます。このループは午後の作業だけで自分で実装できるほど小規模です。ここから、ツール、メモリ、安全対策を追加する前に、エージェントをゼロから学ぶ段階的な道筋が始まります。
重要なのはアクションです。言語モデル単体が生成できるのはテキストだけです。ファイルの読み取り、API の呼び出し、コマンドの実行はできません。エージェントは、モデルが使用を許可されたツールのセットと、それらを要求する方法を提供します。モデルが Web を検索したりファイルを書き込んだりする場合、モデル自体が処理を実行するわけではありません。構造化されたリクエストを出力し、コードがツールを実行します。その結果が、モデルが次に読み取る情報として返されます。モデルが判断を担い、サーバーが実行手段を担います。
すべてのタスクにエージェントが必要なわけではありません。何でもエージェントで処理しようとするのは、よくある誤りです。手順があらかじめ決まっているなら、通常のスクリプトのほうが単純で高速、かつ信頼性も高くなります。「このページを 1 時間ごとに取得し、価格をメールで送信する」という処理は、エージェントではなくスケジュールジョブです。事前に経路を固定できず、モデルが取得した情報を確認して次の処理を判断する必要がある場合に、エージェントを構築します。エージェントのコストは予測不能性です。その柔軟性に価値がある場合にだけ、そのコストを負担してください。
ツール: エージェントの動作
ツールとは、モデルがいつ使うべきか判断できるよう十分に説明された、モデルに与える機能です。ファイルの読み取り、シェルコマンドの実行、データベースへの問い合わせ、メッセージの送信などは、それぞれ名前、短い説明、入力項目の一覧を持つツールです。ツールを定義するのはあなたであり、呼び出すタイミングを判断するのはモデルです。通常、最初に追加する価値があるのは Web 検索です。すでに独自の SearXNG インスタンスを運用している場合は、商用検索 API に料金を支払う代わりに、エージェントの検索バックエンドに変えることもできます。
使用するモデルに関係なく、仕組みは同じです。モデルは、ツール名を指定し、入力項目を埋めた構造化リクエストを返します。コードはそのリクエストを受け取り、対応する関数を実行して、次のターンで結果を返します。モデルは結果を読み取り、別のツールを呼び出すか、最終回答を書きます。Function calling はすべてのエージェントを支える処理であり、それを動かすループは通常のコード数行だけで実装できます。
ここで制御も行います。モデルはコマンドの実行を要求できますが、コードが実行を選択するまで、コマンドは実行されません。この間に、危険な操作に対する承認プロンプト、ツールが操作できる対象の制限、エージェントが実行したすべての操作のログを組み込みます。エージェントの安全性は、与えるツールと、その前段に置くチェックによって決まります。
MCP: ツールを接続する標準的な方法
サービスごとに新しい統合を手作業で作るのは、すぐに負担になります。Model Context Protocol、または MCP は、この問題を解決するオープン標準です。ファイル、データベース、issue tracker 用にそれぞれ新しいツールを実装する代わりに、それらをすでにツールとして公開している MCP server をエージェントに指定します。エージェントは 1 つのプロトコルで通信し、実際のシステムとの処理はサーバーが担います。
利点は再利用できることです。利用しているサービス向けに他の人が作成した MCP server は、新しい統合コードを書かなくてもエージェントから利用できます。また、自分で作成した server は、そのプロトコルに対応するあらゆるエージェントで使えます。現在では、自身の MCP server を同梱する self-hosted アプリもあります。openGym、ワークアウト記録アプリは read-only の MCP server を公開しているため、エージェントはトレーニング履歴に関する質問に回答できますが、履歴を変更することはできません。VPS では、この構成が重要です。MCP server をエージェントの隣で、それぞれ必要なアクセス権だけを持つ独立した小規模サービスとして実行できるためです。これらの server の背後にあるシステムが、VPS から到達できないネットワーク上にある場合もあります。たとえば、自宅やオフィス内のデータベースです。subnet router でそのネットワークを tailnet に広告すると、パブリックインターネットに公開せず、プライベートアドレス経由でエージェントから接続できます。設定方法は VPS で MCP server を実行するで説明します。
メモリと検索
言語モデルは、呼び出しと呼び出しの間で自分の記憶を保持しません。現在のタスクに必要な情報は、毎回のリクエストでモデルに渡す必要があります。短い処理であれば、会話全体を 1 回のリクエストに収められるため問題ありません。収まる量はコンテキストウィンドウによって決まります。GPU メモリが 24 GiB 未満、または GPU を搭載していないサーバー上で Ollama により self-hosted model を提供する場合、デフォルトのコンテキストは 4k と小さく、古いターンが静かに破棄されます。そのため、エージェントが忘れたことを疑う前に、ループが生成するトラフィックに合わせて num_ctx を設定する価値があります。より長い処理では、メモリを自分で管理する必要があります。知っておくべき方法は 2 つあります。
1 つ目はスクラッチパッドです。エージェントが読み書きできるファイルを用意し、処理中に学習した内容を記録するよう指示します。次のターン、または次のセッションでエージェントがファイルを読み戻し、中断したところから再開します。これは通常のドキュメントとしてのメモリです。エージェントがそのファイルを別のツールとして扱うため機能します。
2 つ目は検索です。1 回のリクエストには収まらない大量のドキュメントから知識が必要になった場合、ドキュメントを検索可能な形式で保存し、必要なときに関連する部分だけをモデルのコンテキストへ取り込みます。この方法は retrieval-augmented generation、または RAG と呼ばれます。エージェントが質問し、コードが一致する数個の文章を検索して、それらだけをモデルに渡します。データストアはサーバー上にあるため、非公開のドキュメントがサーバーの外へ出ることはありません。
エージェントを複数、コーディネーターを1つ
多くのタスクでは、ツールを多数備えた1つのエージェントで対応できます。作業量が多い場合や、自然に複数の部分へ分割できる場合は、別の構成が役立ちます。専門のサブエージェントへ委任するコーディネーターエージェントを使う構成です。コーディネーターは目標を複数の部分に分け、それぞれの作業に適したサブエージェントへ割り当て、結果を統合します。委任には各部分の間で通信する手段が必要です。その最も単純な方法は、すでにサーバー上にあります。同じ VPS 上の2つの Claude Code セッションで相互にメッセージを送信できます。独自の調整機構を構築する前に、処理の引き渡しがどのように機能するかを低コストで確認できます。
利点は、作業に集中できることです。担当範囲が狭く、使用するツールも少ないサブエージェントは、すべてを同時に扱う汎用エージェントより適切な判断を下せます。また、独立した作業は同時に実行できます。一方で、調整には実際のコストがかかります。そのため、明確に複数のエージェントが必要になるまで、1つのエージェントに絞ってください。まずは単純な構成から始め、1つのエージェントでは明らかに負荷が高い場合にだけエージェントを追加します。
self-hosted と hosted の比較: エージェントで実行するモデル
エージェントの構成要素のうち、モデルだけは自分で実行する必要がありません。モデルをどこで実行するかは、最も重要な判断になります。API 経由で利用する hosted model なら、運用するものがなくても高度な推論を利用できます。テキストを送ると、テキストが返ります。self-hosted model は自分のサーバーで実行するため、管理下のハードウェア内にリクエストを留められます。また、トークン単位の料金をサーバーの費用に置き換えられ、モデルプロバイダーの API が稼働し続けることにも依存しません。トレードオフは、性能と運用負担です。最も優れた hosted model は、自分で実行できるモデルより先行しています。一方、自分でモデルを実行する場合は、モデルを収めるのに十分なメモリを用意する必要があります。
ここが実際の制約になります。モデルはサーバーのメモリに収まる必要があります。GPU を使う場合は、GPU のビデオメモリにも収まらなければなりません。ハードウェアに対して大きすぎるモデルはロードできません。self-hosted agent を計画する前に、使用したいモデルが手元のマシンに収まるか確認してください。
数値が合わない場合、選択肢は 4 つあります。より小さいモデルを選ぶ、より強い量子化でモデルを縮小する、より多くのメモリを持つサーバーへ移行するか複数の GPU にモデルを分散する、または推論に hosted API を使い、ツールとデータだけをサーバーに保持する、のいずれかです。多くの self-hosted agent は、VPS 上の Ollama でローカルモデルを使い始め、難しい処理では hosted API にフォールバックします。
サーバーが危険な部分です
シェルコマンドを実行し、ファイルを書き込めるエージェントは強力です。だからこそ危険でもあります。モデルの判断は優れていますが、完璧ではありません。誤った指示、バグ、悪意のある入力によって、有用なエージェントが誤ったファイルを削除したり、Secret を漏えいさせたりする可能性があります。セキュリティ対策は省略できません。サーバーでは、そこが最も重要な部分です。
いくつかの習慣で、大部分のリスクを抑えられます。エージェントは専用の非特権ユーザーとして実行し、決して root で実行しないでください。これにより、ミスによる影響を限定できます。同じ考え方については、非特権ユーザーとしてサービスを実行する を参照してください。API キーなどの Secret はコードに埋め込まず、そのユーザーだけが読み取れるようにしてください。また、システムに触れるツールはサンドボックス化し、エージェントが本当に必要な範囲にだけアクセスできるようにします。すべてのチェックを手作業で記述したくない場合は、インストールする価値のある DeepSeek Harness プラグイン に、すぐ使える構成要素が用意されています。ツールの権限ルール、プロンプトインジェクションのスキャン、停止するまでにエージェントが使用できる費用の上限などを扱います。実際にセルフホストしたエージェントを堅牢化する例については、VPS 上で OpenClaw を安全に実行する を参照してください。知能処理にホスト型モデルを使いたい場合は、VPS 上で Claude を使ってエージェントを構築する で、同じ考え方を特定のモデルに適用しています。
実例として、OpenClaw 型の個人用エージェントを構築する では、これらの要素を組み合わせています。完成済みのものを実行したい場合は、VPS 上で Hermes Agent をセルフホストする または 自分のサーバーで Agent Zero を実行する から始めてください。2026 年の最適なセルフホスト AI エージェント では、対象とする完成済みの選択肢をすべて横並びで比較しています。
FAQ
AI agent と chatbot の違いは何ですか?
chatbot はメッセージに回答して停止します。agent はループを実行します。モデルがアクションを決定し、コードがそれを実行し、結果をモデルに返します。これをタスクが完了するまで繰り返します。違いは、agent が各ターンの間に実際のアクションを実行する点です。ファイルの読み取り、コマンドの実行、サービスへの問い合わせなどで tool を呼び出します。テキストを生成するだけではありません。
VPS で AI agent を実行するには GPU が必要ですか?
モデルを self-host する場合に限り必要です。agent のループ、tool、memory は通常のコードであり、GPU がない一般的な VPS でも問題なく実行できます。GPU が重要になるのは、言語モデルを自分のハードウェアで実行する場合です。モデルをメモリに収める必要があるためです。API 経由でホスト型モデルを使用する場合、負荷の高い計算は別の場所で実行されるため、控えめな構成の VPS で十分です。
MCP とは何ですか?agent の構築に必要ですか?
MCP(Model Context Protocol)は、agent を tool やデータソースに接続するためのオープン標準です。各 tool を手作業で記述できるため、厳密には必要ありません。MCP を使うと、一般的なサービス向けの既存サーバーを再利用でき、自分のシステムも一度公開するだけで任意の agent から利用できるため、その作業を省けます。統合する対象が増えるほど、その利便性が有効になります。
AI agent にサーバーへのアクセスを許可しても安全ですか?
適切に隔離すれば安全にできます。コマンドを実行する agent の安全性は、実行する account と許可する tool に左右されます。権限のないユーザーとして実行し、secret にアクセスできないようにします。filesystem に触れる tool は sandbox 化し、元に戻しにくい操作には承認を必須にします。賢いだけの信頼できないコードとして agent を扱い、タスクに必要な権限だけを与えてください。