1GB VPSでAIエージェントを動かそうとして3回失敗した話

はじめに――「全自動」の甘い誘惑

AIで業務を自動化する。そう決めたとき、最初に思い描いたのは「サーバーが勝手に全部やってくれる」という絵だった。毎朝7時、クラウドサーバー上のAIエージェントが起動し、ビジネスチャットの未読を取得→AIが要約→自動投稿。自分は整理済みの情報を眺めるだけでいい。そのために契約したのが、月額数百円のVPS（仮想サーバー）。メモリ1GB。安い。これで十分だろう、と思った。

結論から言うと、全然十分ではなかった。ここから3回の失敗と1回の方針転換を経て、最終的にたどり着いた答えは「エレガントな設計より、動く設計」だった。

失敗1: そもそもサーバーに接続できない

VPSを契約して、AIエージェント（OpenClawというオープンソースの24時間稼働型AIエージェントツール）をインストールしようとした。まずSSHで接続する。ターミナルにコマンドを打つ。

タイムアウト。

pingも通らない。サーバーが落ちているのか。障害情報を確認するが、特に出ていない。何度か試す。ダメだ。

30分ほど格闘して、ふと気づいた。接続先のIPアドレスが違う。

前回のセッションでメモしていたIPアドレスが、コントロールパネルに表示されている実際のIPと全然違っていた。どこかで書き間違えたのか、別のサーバーの情報と混同したのか。正しいIPに変えたら、一発で接続できた。

消費した時間: 約30分。原因: 自分のメモミス。

これは技術的な問題ですらない。ただの確認不足だ。クラウドサービスを使うときは、コンソール画面のURLをブックマークしておく。メモや記憶に頼らない。これだけで防げた失敗だった。でもこういう「しょうもないミス」が、実際の現場では一番多い。設定ファイルのスペルミス、パスの間違い、環境変数の入れ忘れ。技術力の問題ではなく、確認の問題。

教訓: メモを信用しすぎない。都度、一次情報を確認する。クラウドサービスのコンソール画面はブックマークしておく。

失敗2: メモリが足りなくてAIエージェントが起動しない

SSH接続できたので、AIエージェントをインストールして起動する。

クラッシュ。

エラーログを見ると、こう書いてある。

FATAL ERROR: Reached heap limit Allocation failed
- JavaScript heap out of memory

ヒープメモリの上限に達した。AIエージェントはNode.jsで動いており、470MB以上のメモリを必要とする。VPSの総メモリは960MB。OSや他のサービスで200MBほど使っている。残り760MB。数字だけ見ればギリギリ足りそうだが、実際にはメモリの断片化や一時的なスパイクがある。

対処として、Node.jsのヒープサイズ上限を手動で設定した。

• 384MBに制限 → まだ足りない。クラッシュ
• 512MBに制限 → まだ足りない。クラッシュ
• 700MBに制限 → swapメモリ（ディスクを仮想メモリとして使う仕組み）を併用して、ようやく起動

起動に40秒かかる。通常なら数秒のところが40秒。メモリがカツカツで、OSがディスクとメモリの間でデータを必死にやりくりしているからだ。

動いてはいる。でも「ギリギリ動いている」と「安定して動いている」は全く違う。他の処理が走ったら落ちる可能性がある。これはサーバーとしては不合格だ。

教訓: 「最小スペックで動くか」を検証してから設計すべきだった。 月額数百円を節約するために、何時間もデバッグに費やしている。時間のコストの方がはるかに高い。

失敗3: cronジョブがスクリプトを実行できない

メモリの問題をなんとかクリアして、次はAIエージェントのcron機能（定時実行機能）を設定する。毎朝7時にPythonスクリプトを実行して、チャットの未読を取得→AIで要約→投稿、という流れだ。

cronジョブを作成して、手動でテスト実行する。AIエージェントが返してきたのはこれだった。

「このセッションではbashツールが利用できないため、Pythonスクリプトを直接実行することができません。」

実行権限がない。AIエージェントが外部コマンドを実行するには、明示的に許可する設定が必要らしい。

• 許可リストのファイルを手動作成 → 反映されない
• CLIコマンドでpythonとbashを許可 → 反映されない
• サービス再起動 → まだ反映されない

3回試して、全部ダメだった。

さらに追い打ちがかかる。結果をDiscordに通知する機能もエラー。AIモデルの指定（安い軽量モデルを使いたい）も無視される。

ここまで来て、冷静に状況を整理した。

• メモリがギリギリで不安定
• cron機能の実行権限が解決できない
• 通知機能もモデル指定も動かない
• これ以上このアプローチに時間を使うのは合理的ではない

ここで、このアプローチを諦めた。

方針転換: シンプルに作り直す

AIエージェントのcron機能にこだわるのをやめて、発想を切り替えた。

やりたいことを分解すると、こうだ。

1. 毎朝7時にスクリプトを実行する
2. チャットAPIで未読メッセージを取得する
3. AIのAPIに送って分類・要約してもらう
4. チャットAPIでダイジェストを投稿する

1はLinux標準のcrontab（定時実行の仕組み）でできる。2〜4はPythonスクリプト1本でできる。AIエージェントを仲介する必要がない。APIを直接叩けばいい。

crontab（毎朝7時）
  → Pythonスクリプト1本
    → チャットAPIで未読取得
    → AI APIに直接送信（分類・要約）
    → チャットAPIでダイジェスト投稿

これだけだ。AIエージェントの複雑なcron機能も、実行権限の設定も、一切不要。Linuxが標準で持っている仕組みと、APIを叩くだけのPythonスクリプト。シンプルだが確実に動く。

ただし、最初のバージョンは品質が低かった。プロンプト（AIへの指示文）が雑だったからだ。

「このメッセージを要約して」だけでは、実用レベルの出力にならない。改善として以下を追加した。

• 出力フォーマットの明示的な指定（セクション構成、区切り線のスタイルまで）
• 「人名を省略するな」「対応済みのものはそう明記しろ」「期限があるものは必ず日付を書け」といった具体的なルール
• マイタスク（自分宛のタスク）の件数表示
• 緊急アラートのキーワード検知

同じAIモデルでも、プロンプトの具体性で出力品質は全く変わった。「要約して」と「誰が、何を、いつまでに、の形式で書け」では、出てくるものが別物になる。

最終的なコスト: 1回あたり約3円。月90円。

この失敗で学んだ3つのこと

1. エレガントな設計より、動く設計

最初に描いた「AIエージェントがVPS上で24時間稼働して、cronで自律的にタスクを実行する」という絵は美しかった。でも動かなかった。

最終的に動いたのは、crontab + Pythonスクリプト1本という、何の変哲もない構成だった。

設計の美しさと実用性は別の話だ。特に個人や中小企業がAIを業務に導入するとき、「動くこと」が最優先であるべきだ。動かないシステムの設計がどれだけ美しくても、1円の価値も生まない。

2. スペックの見積もりは「試してから」

月額数百円のVPSで動くだろう、というのは希望的観測だった。AIエージェントの公式ドキュメントには最小要件が明記されていなかった（あるいは自分が見落とした）。

正解は、契約前に「最低でもこのスペックが必要」を調べるか、最小構成で動作検証してから本番環境を選ぶことだった。安いプランで始めること自体は悪くない。でも「安いプランで動かなかったときのプランB」を持っておくべきだった。

3. 失敗しても資産は残る

AIエージェント経由での自動化は失敗したが、その過程で作ったものは全て再利用できた。

• チャットAPIから未読メッセージを取得するコード → そのまま使用
• AIで分類・要約するプロンプト → 改善して使用
• チャットAPIにダイジェストを投稿するコード → そのまま使用
• 運用フローの設計 → crontab版にそのまま適用

遠回りに見えても、作ったコードや設計は資産として残る。「失敗した」のではなく「動かないアプローチを1つ潰した」のだ。次のアプローチの成功確率が上がっている。

おわりに

この経験を通して確信したのは、AIの業務導入は「一発で正解にたどり着く」ものではないということだ。

試す。失敗する。原因を調べる。別のアプローチを試す。この繰り返しでしか、自分の環境に合った解にはたどり着けない。そして、その過程で作ったコードや設計は、たとえ当初の目的を果たせなくても、次の実装の部品になる。

自分は今も業務のAI自動化を続けている。この失敗のあと、チャットダイジェストの自動投稿は毎朝問題なく動いている。月90円で。

次回は「中小企業がAIを業務に入れるとき、最初にやるべきこと」を書く予定。実践の続きはXで発信中。

技術スタック: VPS 1GB, OpenClaw, Python, crontab, LLM API, ビジネスチャットのAPI

筆者について: コンサル・事業会社を経て中小企業の経営に参画。AIで業務自動化の仕組みを構築中。日々の実験はXで発信中。