AIエージェント（Claude Code等）を24時間VPSで常駐運用する方法｜制作者の実運用ガイド

「AIエージェントを動かしっぱなしにしたいのに、ノートPCを閉じると止まる」——これは、Claude Codeのような自律的に動くツールを本格的に使い始めた制作者が、ほぼ全員ぶつかる壁です。結論から言うと、24時間止めずにAIエージェントを常駐させたいなら、ローカルPCではなくVPS（仮想専用サーバー）で動かすのが現実的な答えです。この記事では、実際にVPS上でエージェントを常駐運用している制作者の目線で、つまずきポイントと注意点を厚めに解説します。

この記事でできること（結論サマリー）

この記事を読み終えると、AIエージェントをVPS上で24時間落とさず動かすための全体像と、コストで事故らないための守りの設計まで一通り分かります。まず要点を先に置いておきます。

• 常駐運用の最短ルート：VPSを契約 → SSHで接続 → tmux/screenで切っても消えないセッションを作る、あるいは systemd/Docker でサービス化する。
• スペックの目安：APIを叩くタイプのエージェント（Claude Code等）は軽量。2〜4コア / メモリ4〜8GBクラスで十分動くことが多い（2026年時点・用途による）。
• VPS選び：初めての常駐運用なら、日本語UIとテンプレートが揃うConoHa VPSが扱いやすい。比較は後述の内部リンクへ。
• 最大のリスクはコスト暴走：APIキーの課金上限を必ず設定し、GPU時間課金の停止忘れに注意する。
• セキュリティは鍵認証＋ファイアウォールが基本。パスワード認証は切る。

なお、料金・プラン・各ツールの仕様は変動が速いため、本文の数値は目安です。契約前・実装前には各社公式で最新を確認してください。

なぜローカルPCでなくVPSで常駐させるのか

結論：AIエージェントを「常時動かす」用途では、ローカルPCは電源・ネットワーク・スリープの制約が多すぎて向いていません。VPSは常時起動・固定回線・遠隔操作を前提に作られたサーバーなので、そもそもの土俵が違います。

ローカルPCで常駐させようとすると、次のような問題が積み重なります。

• スリープ・シャットダウンで止まる：ノートPCを閉じたり再起動したりするたびに、動いていたエージェントのセッションが切れる。
• 回線・電源が不安定：自宅のWi-Fiや停電、PCの熱暴走に運用が左右される。
• PCを占有される：エージェントがCPUやメモリを使い続け、本来の制作作業が重くなる。
• 外出先から触れない：家のPCで動かしていると、外からログを見たり止めたりしづらい。

一方でVPSなら、電源とネットワークが常時前提で、SSHさえ通ればスマホのテザリングからでも様子を見られます。「自分のPCとは切り離した、AI専用の作業マシン」を1台持つイメージです。この考え方の土台は、なぜAIサービスにはVPSが必要か（自宅PC・SaaS APIとの違い）で詳しく整理しているので、そもそも論が気になる方は先に読むと理解が早まります。

VPS常駐運用のメリット・デメリット

VPS常駐は「止まらない・触りやすい」代わりに、サーバー管理の責任が自分に乗ってくるのがトレードオフです。導入前に両面を把握しておきましょう。

ポイントは、「止まらないこと」に価値を感じる用途かどうかです。数分だけ試すならローカルで十分ですが、定期実行・長時間タスク・監視ボットのように「動きっぱなし」が前提のエージェントなら、VPSに移す価値があります。

常駐運用に必要なスペックの目安

Claude CodeのようにAPIを叩くタイプのエージェントは、実は軽量なVPSでも動きます。重い計算はAPIの向こう側（クラウド）で行われるため、手元のVPSは「指示を出して結果を受け取る司令塔」に徹するからです。逆に、モデル本体をVPS内で動かす（ローカルLLM）場合はGPUやメモリが一気に必要になります。

まずは2〜4コア / メモリ4〜8GBクラスから始め、足りなければプランを上げるのが安全です。多くのVPSは後からプラン変更（スケールアップ）できるので、最初から盛りすぎる必要はありません。ローカルLLMを併用したい場合はGPUの要否も絡むため、VPSでOllama＋Open WebUIの自分専用AIを作る（実体験）で、モデルを手元で動かす場合のリソース感を掴んでおくと判断しやすくなります。

なお具体的なコア数・メモリ・料金は各社で異なり、キャンペーンでも変わります。2026年時点の目安として捉え、契約前に各社公式で最新プランを確認してください。

VPSの選び方（ConoHa VPSを主軸に）

初めてAIエージェントを常駐させるなら、日本語の管理画面とテンプレートが充実したConoHa VPSが扱いやすい、というのが実運用での実感です。サーバー管理に慣れていない制作者ほど、GUIとドキュメントの親切さが効いてきます。

常駐運用のVPSを選ぶときに、最低限見ておきたい観点は次の通りです。

• プラン変更のしやすさ：後からコア/メモリを増やせるか。最初は小さく始めて後で拡張できると安心。
• 課金体系：月額固定か時間課金か。時間課金は止め忘れると膨らむので、常駐用途では固定額が読みやすい。
• 管理画面・日本語ドキュメント：トラブル時に迷わないか。
• コンソール（VPS直結の画面）：SSHが締め出された時に、ブラウザから復旧できるか。

ConoHa VPSは月額型で日本語UIが分かりやすく、コンソールからの復旧もしやすいため、常駐運用の1台目として無難です。さくら・XServerを含めたAI用途での違いは、AI用途のVPS比較：さくら vs ConoHa vs XServerで条件ごとに整理しているので、比較したうえで選びたい方はそちらもどうぞ。

迷ったら、まずはConoHa VPSの小さめプランで1台立てて感覚を掴むのがおすすめです。

常駐運用の仕組み（tmux / systemd / Docker）

「SSHを切ってもエージェントを動かし続ける」には、大きく3つの方法があります。tmux/screen、systemd、Dockerです。それぞれ得意分野が違うので、用途に合わせて選びます。

まず、基本の流れはこうです。

1. VPSを契約し、OS（一般的にはLinuxディストリビューション）をセットアップする。
2. 手元のPCからSSHでVPSに接続する（後述の鍵認証を推奨）。
3. エージェントの実行環境（ランタイムや必要ツール）を入れる。
4. tmux / systemd / Docker のいずれかでプロセスを常駐化する。
5. SSHを切っても動き続けることを確認し、ログの出力先を決める。

方法1：tmux / screen（一番手軽・お試し向き）

tmux（またはscreen）は、SSHを切ってもセッションを保持してくれる「切れない画面」を作る仕組みです。まずはこれで動かしてみるのが、つまずきが少なくおすすめです。

1. tmux new -s agent のように名前付きセッションを作る。
2. その中でエージェントを起動する。
3. キー操作でセッションから「デタッチ（離脱）」する（画面は裏で動き続ける）。
4. SSHを切って再接続後、tmux attach -t agent で元の画面に戻る。

メリットは手軽さ。デメリットは、VPS自体が再起動すると自動では復帰しない点です。あくまで「人が張り付いて確認する運用」向けと考えてください。

方法2：systemd（自動起動・自動再起動に強い）

systemdは、Linuxにサービスとして登録して「VPSが再起動しても勝手に立ち上がる」ようにする仕組みです。本格的な常駐運用の主役になります。

概念としては、エージェントの起動コマンドを「サービス定義ファイル」に書いて登録し、OSに管理を任せます。うまく設定すると、次のような挙動が得られます。

• OS再起動後の自動起動：VPSが落ちて上がっても、エージェントが自動で復活する。
• クラッシュ時の自動再起動：プロセスが異常終了しても、設定に応じて再起動させられる。
• ログの一元管理：標準のログ機構でまとめて確認できる。

ただし、自動再起動を強く設定しすぎると、エラーで落ちては再起動を延々繰り返し、その間ずっとAPI課金が発生するという事故が起き得ます。再起動回数や間隔に上限をかける発想を必ず持ってください（後述のコスト暴走対策と関わります）。

方法3：Docker（環境を丸ごと閉じ込める）

Dockerは、エージェントとその実行環境を「コンテナ」という箱に丸ごと閉じ込めて動かす方法です。環境の再現性が高く、作り直しやすいのが強みです。

• 環境の再現性：同じ設定でどのVPSでも立て直せる。乗り換え時に楽。
• 再起動ポリシー：コンテナが落ちたら自動で立て直す設定ができる。
• 分離：ホスト側を汚さず、複数エージェントを分けて動かしやすい。

Difyのようなツールを常駐させる場合はDockerが前提になることも多く、ConoHa VPSでDifyをノーコード運用する（実体験）ではDocker運用の実際の流れを扱っています。Dockerに触れておくと、常駐運用全般の見通しが良くなります。

迷ったら、まずtmuxで動作確認 → 安定したらsystemdかDockerで自動化、という順番が失敗しにくいです。

AIエージェント別の注意点（Claude Code等）

API型のエージェントで最も気をつけるべきは、APIキーの管理と課金です。VPSに常駐させると「動かしっぱなし＝課金し続ける可能性」が生まれます。ここを軽視すると、後述のコスト暴走に直結します。

• APIキーはコードに直書きしない：環境変数や設定ファイル（権限を絞る）で渡し、Gitなどのリポジトリに含めないよう設定しておく。
• キーの権限は最小限に：必要な範囲だけのキーを発行し、用途ごとに分ける。
• 課金上限・使用量アラートを設定：提供元の管理画面で、月次の上限や通知を必ず有効化する。
• 使い終わったキーは失効させる：VPSを解約・作り直すときは古いキーを無効化する。

Claude Codeのような自律的に動くエージェントは、指示次第で連続してAPIを呼び続けることがあります。無限ループやリトライの設計ミスがあると、気づかないうちにリクエストが積み上がります。常駐させる前に、少ない予算枠で挙動を確認し、上限に達したら止まる作りにしておくのが安全です。

また、各ツールの設定項目・課金体系・レート制限は頻繁に変わります。2026年時点の一般論として捉え、実際の上限設定は各ツールの公式ドキュメントで最新を確認してください。

APIキーと課金上限の管理を実運用で徹底する

常駐運用でトラブルの引き金になりやすいのは、技術的な設定ミスよりも「キーの管理」と「上限の設定漏れ」です。ここは仕組みで守るのが鉄則です。人の注意力に頼ると、忙しい時ほど抜けてしまいます。

制作の現場で実際に効いた、キー管理まわりの守り方を挙げておきます。

• キーは環境変数か権限を絞った設定ファイルで渡す：ソースコードやメモに直書きしない。読み取り権限を必要最小限にする。
• リポジトリに上げない仕組みを先に入れる：Gitの除外設定などで、キーを含むファイルがうっかり公開されないようにする。
• 用途ごとにキーを分ける：エージェントごと・環境ごとにキーを分けておくと、漏れた時に影響範囲を切り分けやすい。
• 定期的にキーを入れ替える：長く使い続けず、一定期間で発行し直す運用にしておく。
• VPSを解約・作り直す時は古いキーを失効：使わなくなったキーを残さない。

そして、キー管理と同じくらい重要なのが課金の上限設定です。自律的に動くエージェントは、こちらの想定を超えてAPIを呼び続けることがあります。次の3つは、常駐させる前に必ず用意してください。

1. 月次の課金上限を設定する：上限に達したら止まる、あるいは通知が飛ぶ状態にしておく。
2. 使用量アラートを複数の閾値で設定する：50％・80％など段階的に通知を受け、暴走の兆候を早めに掴む。
3. 少額の予算枠で試運転する：本番の予算をいきなり与えず、小さな枠で数日動かして消費ペースを確かめる。

特に、「エラーで落ちては再起動し、そのたびにAPIを叩く」という自動再起動ループは、課金上限を設定していないと一晩で大きな金額に膨らむことがあります。上限設定は、常駐運用における最も安い保険だと考えてください。なお、これらの設定画面や名称はツールごとに異なり更新も速いので、各ツールの公式で最新の手順を確認しましょう。VPSそのものの費用を抑える考え方は、AI用途のVPS比較：さくら vs ConoHa vs XServerでもプラン選びの観点として触れています。

セキュリティ（鍵認証・ファイアウォール）

常時起動のVPSは、常に外部からアクセスを試みられる前提で守りを固めます。基本は「鍵認証」と「ファイアウォールで最小開放」です。ここを緩くすると、乗っ取られてAPIキーごと悪用される最悪ケースもあり得ます。

• SSHは鍵認証にする：パスワード認証は無効化し、公開鍵認証で入る。パスワード総当たりを防ぐ。
• ファイアウォールで最小開放：使うポートだけ開け、不要なポートは閉じる。管理画面のセキュリティグループも活用する。
• rootで直接運用しない：作業用ユーザーを作り、必要なときだけ権限昇格する。
• OS・ソフトを更新する：放置は脆弱性の温床。定期的にアップデートする。
• アクセス元を絞る：可能なら接続を許可するIPを限定する。

特に見落としがちなのが、「エージェントが外部に公開するポート」です。Web UIやAPIサーバーを立てる構成だと、意図せずインターネット全体に開いてしまうことがあります。公開が必要な場合も、認証を必ずかけ、開くポートは最小限にしてください。

コスト暴走の防止（時間課金・停止忘れ・API課金）

常駐運用で一番怖いのは、技術的な失敗より「請求の事故」です。止め忘れと課金上限の未設定が二大原因になります。ここは厚めに対策してください。

コストが膨らむ典型パターンは次の3つです。

• 時間課金リソースの停止忘れ：特にGPUなど時間課金のサーバーは、使い終わったのに起動したままにすると課金が続く。検証で立てたインスタンスを消し忘れるのは定番の事故。
• APIの呼びすぎ：自律エージェントが想定より多くリクエストを出し、月の予算を超える。
• 自動再起動ループ：エラーで落ちるたびに再起動し、その都度APIを叩き続ける。

対策としては、次を「必ず動かす前に」やっておきます。

1. API側で課金上限・使用量アラートを設定する（提供元の管理画面で）。
2. VPSは常駐なら月額固定型を選ぶ。時間課金を使うなら、使わない時は確実に停止・削除する運用ルールを決める。
3. 自動再起動に上限をかける：一定回数失敗したら停止し、通知する設計にする。
4. ログと請求を定期チェック：週次で使用量と請求を見る習慣をつける。

なお、エンタープライズ向けのGPU（時間課金）は用途が限られ、停止忘れの被害額も大きくなりがちです。常駐のAIエージェント用途では、まずConoHa VPSのような月額固定のVPSで組む方が、コストが読みやすく事故りにくいというのが実感です。

監視と自動再起動の設計

「常駐＝放置」ではありません。落ちたことに気づける仕組みと、勝手に立ち直る仕組みをセットで用意して初めて、安心して寝られます。

• プロセス監視：エージェントが動いているか（プロセスが生きているか）を定期的に確認する。
• 自動再起動（上限付き）：落ちたら立て直す。ただし前述の通り無限リトライにしない。
• 通知：停止や異常時に、チャットやメールで手元に届くようにする。
• ログの保存とローテーション：ログが膨らんでディスクを食い潰さないよう、古いログを整理する。
• リソース監視：CPU・メモリ・ディスクの使用率を見て、逼迫の兆候を早めに掴む。

最初から完璧を目指す必要はありません。まず「落ちたら通知が来る」だけでも入れておくと、事故の発見が早くなり、被害を小さく抑えられます。systemdやDockerの再起動ポリシーと、通知の仕組みを組み合わせるのが定番です。

実運用で効いてくるのは、「異常に気づいてから対応するまでの時間」をどれだけ短くできるかという視点です。深夜に落ちても朝まで気づけなければ、その間ずっと処理が止まり、場合によっては課金だけが進みます。通知が手元のスマホに届くようにしておくだけで、被害の大きさは大きく変わります。監視は派手な仕組みより、まず気づける状態を作ることから始めるのが実用的です。

ローカルPCから常駐運用へ移すときの実際の流れ

手元で試したエージェントをVPSへ移すときは、いきなり本番へ載せず「小さく立てて数日観察」の一段階をはさむのが安全です。ローカルとサーバーでは、パスや権限、通信の前提が微妙に違うため、移した直後は必ずどこかで引っかかると考えておくと気が楽です。

制作者目線で、つまずきを減らせる現実的な進め方を並べておきます。

1. 小さいプランでVPSを1台立てる：最初から高いプランにせず、後から上げられる前提で最小構成から始める。
2. 手動でエージェントを一度動かす：まずSSH内で普通に起動し、ローカルと同じ挙動になるかを目で確認する。
3. tmuxで数日回して観察する：ログの出方、メモリの使われ方、想定外の停止がないかを見る。
4. 問題がなければ自動化に載せ替える：systemdやDockerに移し、自動起動・自動再起動・通知を組み込む。
5. 最後に「わざと落として」復旧を確かめる：プロセスを止めてみて、ちゃんと立ち直り、通知が届くかをテストする。

特に大事なのは、最後の「わざと落とす」テストです。自動再起動や通知は、実際に落ちるまで正しく動くか分かりません。本番で初めて障害に遭遇するより、平常時に一度壊してみるほうが、はるかに安全に検証できます。移行のたびにこの一手間を入れておくと、夜間や外出中でも安心して任せられるようになります。

また、ローカルとVPSでファイルの置き場所や環境変数の渡し方が変わるため、APIキーや設定ファイルの移行は特に丁寧に行ってください。ここを雑にすると、動かない・キーが漏れるといったトラブルに直結します。

常駐させるエージェントの向き・不向き

すべてのAIエージェントを常駐させる必要はありません。「動きっぱなしであることに価値がある」タスクだけをVPSに載せるのが、コストと手間のバランスが良い考え方です。

常駐運用と相性が良いのは、次のようなタスクです。

• 定期実行のタスク：決まった時間に情報を集める、レポートを作る、といった繰り返し処理。
• 長時間かかる処理：手元のPCを閉じられない、数時間〜数日の連続作業。
• 監視・通知系のボット：何かが起きたら知らせる、常に見張っている必要のある用途。
• 外部からのトリガーで動くもの：Webhookやメッセージを受けて反応する常駐サービス。

逆に、数分で終わる単発の作業や、自分が画面を見ながら対話的に進めたい作業は、無理にVPSへ常駐させる必要はありません。手元で起動して終わったら閉じる、という使い方のほうが、課金も管理もシンプルです。

制作の現場では、「対話しながら試す作業はローカル、動かしっぱなしの自動処理はVPS」と役割を分けると、コストと快適さの両立がしやすくなります。まずは一番『止めたくない』タスクを1つ選び、それだけをVPSに移すところから始めると、失敗が小さく済みます。VPS側で自分専用のAI環境を育てていく発想は、VPSでOllama＋Open WebUIの自分専用AIを作る（実体験）とも地続きです。

実運用でつまずきやすいポイント

ここでは、実際にVPSでエージェントを常駐させたときに引っかかりがちな点を、先回りでまとめておきます。知っているだけで回避できるものばかりです。

• tmuxのまま満足してしまう：手軽ゆえに、VPS再起動で復帰しないことを忘れがち。長期運用ならsystemd/Dockerへ移行する。
• APIキーをうっかり共有：スクリーンショットや設定ファイルの共有でキーが漏れる。共有前に必ずマスクする。
• ディスクがログで満杯：常駐で出続けるログを放置すると、ディスクが埋まってプロセスが止まる。
• タイムゾーンのズレ：VPSの時刻設定がずれていると、定期実行の時間が意図とずれる。
• ネットワーク切断時の挙動：一時的な通信断で処理が止まったまま放置される。リトライと通知でカバーする。

いずれも「動き始めた後」に効いてくる話です。小さく立てて、数日回して観察してから本運用に載せると、こうした落とし穴に早めに気づけます。

よくある質問（FAQ）

Q. Claude CodeのようなAIエージェントは、GPU付きのVPSでないと動きませんか？

A. APIを叩くタイプのエージェントであれば、GPUは基本的に不要です。重い処理はAPIの向こう側で行われるため、手元のVPSは2〜4コア / メモリ4〜8GBクラスでも動くことが多いです（2026年時点・用途による）。GPUが要るのは、モデル本体をVPS内で動かす（ローカルLLM）場合です。

Q. tmuxとsystemd、どちらで常駐させるべきですか？

A. まずtmuxで動作を確認し、安定してきたらsystemd（またはDocker）で自動起動・自動再起動まで面倒を見させる、という順番がおすすめです。tmuxは手軽ですがVPS再起動で復帰しないため、長期の常駐運用にはsystemd/Dockerが向いています。

Q. APIの課金が暴走しないか不安です。何をしておけば安心ですか？

A. 提供元の管理画面で課金上限と使用量アラートを設定するのが最優先です。加えて、自動再起動に回数上限をかける・少額の予算枠で挙動を確認してから本運用する・週次で請求とログを見る、を習慣にすると事故を抑えられます。設定項目は変わるため、各ツールの公式で最新を確認してください。

Q. VPSはどこがおすすめですか？

A. 初めての常駐運用なら、日本語UIとテンプレートが揃い、月額固定でコストが読みやすいConoHa VPSが扱いやすいです。さくら・XServerとの比較は「AI用途のVPS比較：さくら vs ConoHa vs XServer」で条件別に整理しています。プランは後から変更できることが多いので、小さく始めて拡張する前提で選べば大丈夫です。

Q. VPSに常駐させると、セキュリティ的に危なくないですか？

A. 常時起動のサーバーは狙われる前提で守ります。SSHを鍵認証にしてパスワード認証を切る・ファイアウォールで使うポートだけ開ける・OSを更新する、が基本です。特にエージェントが公開するポートと、APIキーの取り扱いには注意してください。

まとめ：まず1台、小さく常駐させてみる

AIエージェントを24時間止めずに動かすなら、ローカルPCを卒業してVPSで常駐させるのが現実的な解です。要点をもう一度おさらいします。

• API型エージェントは2〜4コア / メモリ4〜8GBクラスの軽量VPSでも動くことが多い（2026年時点・用途による）。
• 常駐化はtmuxでお試し → systemd/Dockerで自動化の順が失敗しにくい。
• 最大のリスクは技術ではなくコスト暴走。課金上限・停止忘れ対策・再起動上限を先に用意する。
• セキュリティは鍵認証＋ファイアウォールが土台。
• 初めての1台は、日本語UIと月額固定で扱いやすいConoHa VPSが無難。

完璧な構成を最初から目指すより、小さなプランで1台立て、数日回して観察してから本運用に載せるのが、結局いちばん早く安定します。まずは手を動かして、あなたのエージェントを「落ちない場所」に移してあげましょう。VPS選びで迷ったら、AI用途のVPS比較：さくら vs ConoHa vs XServerもあわせて参考にしてください。

関連記事

• 自作AIサービス・アプリを公開するVPSのおすすめと選び方｜AI時代のサーバー入門【2026年】
• なぜAIサービスにはVPSが必要か｜自宅PC・SaaS APIとの違いを制作者が解説
• AI用途のVPS比較：さくら vs ConoHa vs XServer｜制作者が選ぶAIサーバー
• ConoHa VPSでDifyを動かす全手順｜安く・セキュアに自作AIを運用【実運用】
• VPSでOllama＋Open WebUIの自分専用AIを作る手順｜制作者の実運用ガイド
• GPUが必要なときのGPU VPS・GPUクラウドの選び方｜時間課金・審査の注意【2026年】
• AIサービスのVPSコスト暴走を防ぐ運用の注意点｜時間課金の止め忘れ・API課金対策【2026年】