第1回：APIコストが1日で10ドルに達した理由 — サーバー設計とモデル戦略の記録

シリーズ「AIエージェントは本当に業務を動かせるのか」 Part 1

2025年後半から、AIエージェント基盤「OpenClaw」が注目を集めています。実際のところ、業務で使い物になるのでしょうか。セキュリティ面は大丈夫なのでしょうか。

本シリーズでは、OpenClawを実際のクライアント案件で使ってみた経験を、失敗や手戻りもそのまま含めて記録しています。私自身もOpenClawの利用経験はまだ浅く、一人の技術者が試行錯誤した記録という位置づけです。これからOpenClawや類似のAIエージェント基盤の導入を検討される方にとって、判断材料や「ここは気をつけたほうがいい」という注意点になれば幸いです。

本記事（Part 1）では、サーバー構築初日にAPIコストが想定の5〜10倍に膨らんだ原因を切り分けていきます。OpenClawがコンテキストを自動圧縮しないという初期設定の落とし穴、CronとHEARTBEATの二重稼働、そしてローカルLLM導入による3Tier戦略まで、導入初日に気をつけたい点を整理します。

プロジェクト全体の概要はプロジェクトページをご参照ください。

1. サーバーの選定と基本構成

24時間常駐するエージェントを動かすためのサーバーとして、Hetzner Cloud を採用しました。

項目	値
ロケーション	Helsinki (hel1)
OS	Ubuntu 24.04
スペック	4vCPU / 16GB RAM / 150GB SSD
月額	約€12

欧州リージョンですが、エージェント用途ではレイテンシは大きな問題にはなりません。クライアント案件で専用ハードウェアの調達が難しい状況だったこと、社内ネットワークから切り離されたサンドボックス環境が必要だったこと、24時間の安定稼働が求められたことがクラウドを選択した理由です。

2. OpenClawのインストールで気をつけたい点

`--accept-risk` フラグの意味

OpenClawのオンボーディングは以下のコマンドで行います。

npm install -g openclaw@latest
openclaw onboard --install-daemon --non-interactive --accept-risk

--non-interactive だけで実行すると、次のエラーが出ます。

Non-interactive setup requires explicit risk acknowledgement.

OpenClawはホスト上でフルアクセス権を持って動作するため、明示的なリスク承認を求める設計です。エージェントはファイルの読み書きとコマンド実行を自由に行えます。この前提を理解した上で使う必要があります。

サーバー環境でのブラウザ設定

GUIのないサーバー環境（root実行）でブラウザを立ち上げるには、次の2つの設定が必要でした。

openclaw config set browser.noSandbox true
openclaw config set browser.headless true

Google Chrome Stableを事前にインストールしておく必要もあります。

wget -q https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb -O /tmp/chrome.deb
apt-get install -y /tmp/chrome.deb

Webダッシュボードの外部公開

OpenClawにはWeb管理画面が内蔵されています。外部からアクセスするために、sslip.ioでIPアドレスをドメイン化し、Nginxリバースプロキシ + Let’s Encrypt でHTTPS化しました。

ここで一点、注意が必要な設定があります。OpenClawはブルートフォース対策としてデバイス認証を要求しますが、外部アクセスではこれを無効化する必要があります。

openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth true

設定名に dangerously が入っている通り、本来は慎重に扱うべき設定です。Nginx Basic認証 + Gatewayトークン + HTTPS の3層保護で補う形にしました。

3. セキュリティ設定は最初にやる

OpenClawをクラウドで動かす場合、次の点は必ずセットアップの初日に済ませておくべきです。

ホスト上のフルアクセス: --accept-risk の意味は文字通りです。エージェントはファイルの読み書きとコマンド実行を自由に行えます。
.env ファイルのパーミッション: デフォルトで 644 (誰でも読める状態)で作成されます。APIキーが含まれるため、chmod 600 が必須です。
テンプレートファイルへの誤記入: Git管理対象の .env.example に本物のAPIキーを書いてしまわないよう、取り扱いには注意が必要です。

chmod 600 /root/.openclaw/.env

動作確認を優先すると忘れがちですが、セキュリティ設定は後回しにしないことをおすすめします。

4. コスト爆発の発見 — 想定の5〜10倍

セットアップの翌日、OpenClawのWebダッシュボード /usage を確認したところ、想定を大きく上回るコストが出ていました。

想定: 1〜2ドル/日（月30〜60ドル）
現実: 8〜10ドル/日（月240〜300ドル）

原因を切り分けた結果、以下の4点が複合していました。

原因1: コンテキストトークンの膨張（最大の要因）

メインセッションのコンテキストが約31万トークンまで膨張していました。

agent:main:main │ 310k/200k (155%)

OpenClawは会話履歴を自動圧縮しません。 Claude Codeとは異なり、セットアップ作業中のログやエラーメッセージがすべて蓄積されます。1回のメッセージ送信ごとに、31万トークンがまるごとAPIへ送信されます。

状態	1メッセージあたり	100回で
31万トークン	$0.023	$2.30
4万トークン（圧縮後）	$0.003	$0.30

単価の安いモデルを使っていても、コンテキストが大きければ意味がありません。

原因2: Cronジョブの常時稼働

30分間隔のモニタリング用cronが24時間動いており、48回/日のAPI呼び出しが発生していました。

原因3: CronとHEARTBEATの二重稼働

これが最も気づきにくい点でした。OpenClawには2つの定期実行メカニズムがあります。

メカニズム	セッション	停止方法
Cron	独立セッション	`openclaw cron` で管理
HEARTBEAT	mainセッション内	HEARTBEAT.md の内容変更

Cronを停止しても、HEARTBEAT.mdに同じタスクが残っていれば実行され続けます。実際、cronを全停止した後もweb_searchが継続していました。

原因4: web_searchの多用

web_search: 186 calls
web_fetch:   33 calls

HEARTBEATの自動処理が、意図せずWeb検索を多発させていました。

5. 対策 — セッション圧縮と定期処理の見直し

即座に実施した対策と効果は以下の通りです。

対策	効果
セッション圧縮（`/reset`）	31万 → 2.1万トークン（93%削減）
全Cronジョブの無効化	バックグラウンドAPI呼び出しゼロ
HEARTBEATからの監視タスク削除	30分ごとの自動検索を停止

対策の前後で、コストは次のように変化しました。

指標	対策前	対策後
メインセッショントークン	310,000	21,000
バックグラウンドAPI呼び出し	48回/日	0回/日
月間推定コスト	$240〜300	$10〜20

6. ローカルLLMの導入 — Ollama + Gemma3 4B

24時間cronを回すとAPIコストが月50〜100ドルかかる問題を根本解決するため、ローカルLLMを導入しました。

モデル選定の試行

モデル	結果	備考
Qwen3 4B	不採用	Thinkingモード強制ON。3行の回答に2,500トークン・3分を要する
Gemma3 4B	採用	同じタスクが60トークン・3秒で完了

Qwen3はチャットテンプレートに <think> タグが強制付与されており、CPU推論環境では動作が大幅に遅くなります。/no_think 指定やカスタムModelfileでの無効化も試しましたが、効果は限定的でした。

私の視点では、CPU推論環境でThinking強制モデルを採用するのは避けたほうが良いという結論になりました。

サーバーリソースの使用状況

Hetzner: 4vCPU (AMD EPYC) / 16GB RAM / GPU なし

Gemma3 4B ロード時:
  ディスク: 3.3 GB
  RAM使用:  4.2 GB（CPU推論）
  空きRAM:  10 GB（OpenClaw + OS含めて余裕あり）
  推論速度: 14-15 tok/s

16GB RAMのサーバーでも十分に動作します。GPU無しの構成でも、定型タスクであれば実用に足る応答速度が得られました。

7. 3Tierモデル戦略

以上の経験から、タスクの性質に応じてモデルを使い分ける3Tier戦略を策定しました。

Tier	モデル	用途	コスト帯
Tier 1	Claude Sonnet / Opus	コード生成、深い分析、矛盾検知	中〜高
Tier 2	Gemini 3 Flash	オーケストレーション、Web要約、HTML抽出	低
Tier 3	Gemma3 4B（ローカル）	heartbeat応答、定型処理	$0

実行戦略

Code-First: ルール判定はPythonコードに変換し、LLMを介さずに実行する（実行コスト$0）
Smart Routing: 低負荷タスクはGemini Flash、高負荷タスクはClaude Sonnet
Local Preference: 定型処理はOllama経由のGemma3で完結させる
コード生成はSonnet一択: Gemini Flashにはハードコードへ逃げる挙動があり（詳細は次回）、コード生成用途には不適

OpenClaw自身に設定させる

設定変更は、Claude Codeから直接ファイルを編集するのではなく、OpenClaw自身にプロンプトで指示して自律的に行わせる方が自然に動作しました。

openclaw agent --agent main --message 'デフォルトモデルを google/gemini-3-flash-preview に変更してください。
タスクの難易度に応じて以下のように使い分けてください：
- 通常: google/gemini-3-flash-preview
- 中難易度: anthropic/claude-sonnet-4-6
- 高難易度: anthropic/claude-opus-4-6'

OpenClawは自分でデフォルトモデルを変更し、SOUL.mdにルーティング戦略を記録しました。

8. この記事で得た教訓

OpenClawはコンテキストを自動圧縮しません。Claude Codeとは異なり、手動で /reset するかルール設定しない限り無制限に膨張します。
CronとHEARTBEATは別物です。片方を止めたらもう片方も必ず確認する運用が必要です。
単価の安いモデルでも油断は禁物です。Gemini Flashは低コストですが、31万トークンを毎回送信すれば結局高くつきます。コスト = 単価 × トークン数 × 回数、の3要素で評価するのが正確です。
セットアップ直後こそ /reset が効くタイミングです。試行錯誤でコンテキストが膨張しやすいからです。
CPU推論環境ではThinking強制モデルを避ける。GPU環境では問題にならなくても、CPU環境では実用的な応答速度が得られません。
/usage は毎日確認する。異常に気づくのが1日遅れるだけで10ドルの差になります。

9. セットアップ完了時のチェックリスト

/usage でコストを確認（ベースラインの把握）
openclaw status でセッションのトークン数を確認
openclaw cron list で不要なcronがないか確認
HEARTBEAT.md の内容を確認（不要なタスクがないか）
.env ファイルのパーミッションが 600 になっているか確認
セットアップ作業完了後に /reset を実行
APIプロバイダーのダッシュボードで月額上限を設定
ブラウザ設定: headless: true + noSandbox: true

次回 Part 2 では、AIにルール仕様だけを渡してPythonコードを自律生成させた実験を紹介します。3つのモデルを比較した結果、Gemini Flashが正解値をハードコードしていた事実を取り上げます。

第1回：APIコストが1日で10ドルに達した理由 — サーバー設計とモデル戦略の記録

1. サーバーの選定と基本構成

2. OpenClawのインストールで気をつけたい点

`--accept-risk` フラグの意味

サーバー環境でのブラウザ設定

Webダッシュボードの外部公開

3. セキュリティ設定は最初にやる

4. コスト爆発の発見 — 想定の5〜10倍

原因1: コンテキストトークンの膨張（最大の要因）

原因2: Cronジョブの常時稼働

原因3: CronとHEARTBEATの二重稼働

原因4: web_searchの多用

5. 対策 — セッション圧縮と定期処理の見直し

6. ローカルLLMの導入 — Ollama + Gemma3 4B

モデル選定の試行

サーバーリソースの使用状況

7. 3Tierモデル戦略

実行戦略

OpenClaw自身に設定させる

8. この記事で得た教訓

9. セットアップ完了時のチェックリスト

関連記事

中国AIの現状：養龍蝦（OpenClaw Fever）とAlibaba・Tencent・ByteDanceに見る「AIをお金にする」競争

マルチAIエージェントが動かす新しい世界 ― AIが互いにレビューし、補完し、交渉しながら価値を生む時代へ

TencentのWeChatがAIエージェントに進出する本当の意味

1. サーバーの選定と基本構成

2. OpenClawのインストールで気をつけたい点

--accept-risk フラグの意味

サーバー環境でのブラウザ設定

Webダッシュボードの外部公開

3. セキュリティ設定は最初にやる

4. コスト爆発の発見 — 想定の5〜10倍

原因1: コンテキストトークンの膨張（最大の要因）

原因2: Cronジョブの常時稼働

原因3: CronとHEARTBEATの二重稼働

原因4: web_searchの多用

5. 対策 — セッション圧縮と定期処理の見直し

6. ローカルLLMの導入 — Ollama + Gemma3 4B

モデル選定の試行

サーバーリソースの使用状況

7. 3Tierモデル戦略

実行戦略

OpenClaw自身に設定させる

8. この記事で得た教訓

9. セットアップ完了時のチェックリスト

関連記事

中国AIの現状：養龍蝦（OpenClaw Fever）とAlibaba・Tencent・ByteDanceに見る「AIをお金にする」競争

マルチAIエージェントが動かす新しい世界 ― AIが互いにレビューし、補完し、交渉しながら価値を生む時代へ

TencentのWeChatがAIエージェントに進出する本当の意味

`--accept-risk` フラグの意味