OpenClaw性能最適化：ログ分析からコスト80%削減までの実践メソッド

先月、Anthropicから届いた$347の請求書を見て、私は絶句しました——OpenClawを使っていくつか記事を書き、コードレビューをしただけなのに。さらに悪いことに、最近OpenClawの反応が遅くなり、返答があるまで20秒以上待たされることもザラでした。

請求書をしばらく見つめた後、私はログを掘り下げることにしました。

流れるログを一行一行追っていくと、問題が見えてきました。対話のたびに完全な履歴が送信されており、10往復の会話でコンテキストが150Kトークンに達していました。これはまるで、話すたびにこれまでの全会話を復唱しているようなものです——請求額が跳ね上がるのも無理はありません。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

2週間かけて、あらゆる方法をテストしました。セッションのリセット、モデルの切り替え、キャッシュ戦略、コンテキスト制限など。最終的に、月額コストは$347から$68に下がり、応答時間は23秒から4秒に短縮されました。

正直に言うと、最初はなぜOpenClawがこんなにトークンを浪費するのか理解できませんでした。しかし、性能問題はOpenClawのせいではなく、こちらの使い方が間違っていたのだと気づきました。この記事では、私が踏んだ「地雷」と見つけた解決策——ログ分析から具体的な最適化戦略まで、そのまま使える実践メソッドを共有します。

性能問題の根本原因——なぜOpenClawは重くなるのか

トークン消費の5大要因

「たくさん使えばトークンを消費する」——そう思っていませんか？ 実はそれほど単純ではありません。

要因1：無限に蓄積される会話コンテキスト

OpenClawはデフォルトですべての会話履歴を保持します。最初の会話は5Kトークンでも、10往復目には150Kになります。質問するたびに、OpenClawはこれまでの全内容をClaude APIに再送信します。これは友人と話すときに、毎回先週・先月の会話をすべて復唱してから本題に入るようなもので、非効率極まりありません。

テスト結果：シンプルな「このコードに問題はないか？」というリクエストでも、コンテキストが100Kトークン溜まっていると、回答がたった200文字でも100K分の料金が発生します。

要因2：ツール出力の無制限保存

OpenClawはファイルを読んだり、ログを調べたり、コマンドを実行したりできます。問題は、ツールの出力結果が毎回コンテキストに完全保存されることです。500行のログファイル？それがずっとメモリに残ります。設定ファイルを確認？さらに数百行追加です。

以前、10MBのエラーログを分析させたところ、そのログ断片がずっとコンテキストを占有し、その後の全会話でその10MB分の料金を払い続ける羽目になりました。

要因3：システムプロンプトの毎回送信

OpenClawのシステムプロンプト（System Prompt）は通常5K～10Kトークンあり、AIの能力や振る舞いを定義しています。この内容は対話のたびに送信されます。1日50回対話すれば、システムプロンプトだけで250K～500Kトークンを消費します。

要因4：不適切なモデル選択

Claudeにはランクの異なるモデルがあります：Haiku（安くて速い）、Sonnet（バランス型）、Opus（最強だが高価）。価格差は約15倍です。

多くの人が面倒がってデフォルトをOpusにしていますが、単純なフォーマット変換や情報検索といったタスクに最上位モデルを使うのは、コンビニに行くのに戦車を出すようなものです——到着はしますが、無駄が多すぎます。

要因5：不適切なハートビート設定

OpenClawには接続維持のために定期的にAPIをPingするハートビート（heartbeat）機能があります。間隔を30秒などに設定すると、毎時120回のAPIコールが発生します。1回あたりは微々たるものですが、積み重なると馬鹿になりません。

あるユーザーはハートビート間隔を短くしすぎて、何も作業していないのに月間3600回の呼び出しが発生し、それだけで高額請求になった事例がありました。

メモリを食いつぶす犯人

OpenClawが遅いのは、ネットワークの問題ではなく、メモリ不足が原因の場合があります。

「たかがチャットツールだし、2GBメモリで十分でしょ？」と思いがちですが、実際は全く足りません。

OpenClawはメモリ集約型のアプリケーションです。Node.jsプロセスを走らせ、WebSocket接続を維持し、セッション記憶を保持し、Web UIをレンダリングします。これだけで基礎消費は1.5GB前後になります。2GBしか割り当てないのは、50kgのバックパックを背負ってマラソンを走らせるようなもの——走れなくはないですが、いつ倒れてもおかしくありません。

私の経験則：

• 2GBメモリ：起動はするが、しばらく使うとカクつき、頻繁にクラッシュする
• 4GBメモリ：通常使用に耐える最低ライン、個人開発向け
• 8GBメモリ：スムーズで安定、チームや高頻度利用向け
• 16GBメモリ：本番環境の標準、長期稼働でも安心

さらに「メモリリーク」の問題もあります。長時間稼働するとメモリ使用量が徐々に増えていきます。最初は1.8GBでも、1週間後は3.5GB、数日後には4GB超え…となり、システムが頻繁にスワップ（HDDをメモリ代わりにする）し始め、応答速度が垂直落下します。

VPS（4GBメモリ）で運用していた時、2週間後に突然OpenClawが激重になりました。docker stats で確認するとメモリ使用量は3.8GB、システムの空きは200MB以下。コンテナを再起動したら即座に1.8GBに戻り、快適になりました。

つまり、応答が遅いのはOpenClawの不具合ではなく、VPSのスペック不足である可能性が高いです。

ログ分析と監視——OpenClawのすべてを可視化する

Dockerログの正しい読み方

では、OpenClawが裏で何をしているか、どうやって知ればいいでしょう？

答えはシンプル、「ログを見る」です。しかし多くの人が見方を知らないか、見ても理解できません。

リアルタイムログの監視

docker logs -f openclaw-gateway

このコマンドはOpenClawのログをリアルタイムで出力し続けます。メッセージを送ると、OpenClawがどう処理し、どのツールを呼び出し、何トークン消費したかが手に取るように分かります。

直近のエラーを確認

docker logs openclaw-gateway 2>&1 | tail -50

これは最新の50行を表示します。私はトラブル時にまずこれを叩きます——コンテナが起動しない？まず最後の50行を見れば、90%の確率で答えがそこにあります。

重要なエラー識別子

ログによく出るエラーキーワードを覚えておくと、素早い対応が可能です：

• WebSocket Error 1008：認証切れ。ブラウザのキャッシュクリアが必要
• No API key found for anthropic：APIキー設定ミス
• Error: Address already in use：ポート競合
• FATAL ERROR: Reached heap limit：メモリ不足。スペックアップの合図

以前、突然繋がらなくなりログが WebSocket Error 1008 で埋め尽くされたことがありました。調べると、システム時間をいじったせいで認証トークンが無効になったのが原因でした。ブラウザの localStorage を消したら一発で直りました。

openclaw-telemetry監視ツール

より本格的に監視したいなら、openclaw-telemetry というツールがあります。

実行された全コマンド、プロンプト、ツール呼び出しを記録し、syslog経由で収集、SIEMシステム転送による監査も可能です。機密情報の自動マスキングや、改ざん防止ハッシュチェーンによるログ保全機能もあります。

個人利用にはオーバースペックですが、企業導入や顧客データを取り扱うチームなら導入価値大です。GitHubに詳細ドキュメントがありますが、私は個人開発なので使っていません。

リソース監視コマンド

リソース消費を一発でチェック：

docker stats openclaw-gateway

リアルタイムでコンテナのリソース状況が表示されます：

CONTAINER ID   NAME               CPU %   MEM USAGE / LIMIT   MEM %   NET I/O
a1b2c3d4e5f6   openclaw-gateway   12.5%   1.85GB / 4GB       46.25%  15.2MB / 8.3MB

注目すべき指標：

• CPU使用率：処理中に80-100%になるのはOK。アイドル時に高負荷なら異常。
• メモリ使用量：これが最重要。常時90%以上ならスペックアップ必須。
• メモリ使用率（MEM %）：80%超えで警戒、90%超えはいつ落ちてもおかしくない。

定期的にこれを見る癖をつけましょう。メモリ使用量が右肩上がり（昨日1.8GB、今日2.5GB…）ならメモリリークの兆候です。コンテナ再起動かセッションリセットが必要です。

以前、メモリ3.6GB（上限4GB）まで行っても「まだいける」と放置していたら、翌朝コンテナが死んでいました。ログは Out of memory だらけ。それ以来、3GBを超えたら即再起動しています。

7大性能最適化戦略——40%から80%のコスト削減へ

戦略1：定期的なセッションリセット（40-60%削減）

最も簡単で、最も効果的な方法です。

なぜ効くのか？

リセットすると蓄積されたコンテキストが消去されます。過去の履歴、ツール出力、中間結果がすべてリセットされ、次の対話はゼロからのスタートになります。数十～数百Kトークンの荷物を下ろすわけです。

操作方法

好きな方法を選んでください：

# 方法1：コマンドライン
openclaw "reset session"

# 方法2：セッションファイル削除
rm -rf ~/.openclaw/agents.main/sessions/*.jsonl

# 方法3：組み込みコマンド
# チャット欄に入力
/compact

ベストプラクティス

私の習慣：1つのタスクが終わるたびにリセットします。記事を書き終わったらリセット、PRレビュー終了でリセット、バグ修正完了でリセット。

常に「軽量級」のOpenClawを使うことで、応答も速く、コストも下がります。

「コンテキストが消えると困るのでは？」と心配するかもしれませんが、大抵の場合、前のタスクの文脈は次のタスクには不要です。ブログを書くために調べた資料は、次のコードデバッグには役に立ちません。メモリを占有させ続ける理由がないのです。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

実測データ：月額$347かかっていたのが、定期リセット導入後の翌月は$195に。これだけで40%以上削減できました。

戦略2：大出力操作の隔離（20-30%削減）

巨大なログ確認、設定ファイルのエクスポート、大数据セット分析——これらは大量の出力を生みます。これらがメインセッションに入ると、ガムのようにこびりつき、その後の全対話で課金され続けます。

解決策：独立セッションを使う

# 独立debugセッションで巨大設定を確認
openclaw --session debug "show full system config"

# 必要な部分だけコピー
# メインセッションに戻って作業継続

ゴミの分別と同じです——粗大ゴミは別に捨てる。日常のゴミ箱には入れない。

実例

300行のエラーログを分析させる必要があった時、メインセッションに貼ると300行が永久に残ります。私はこうしました：

1. --session analyze-log で一時セッション作成
2. ログを貼って分析させる
3. AIの結論「127行目のNullPointerExceptionが原因」を得る
4. 結論だけメインセッションにコピー
5. debugセッションは破棄。メインセッションは汚れない。

手間ですが、特に巨大ファイルを扱う時は確実に効きます。

戦略3：スマートなモデル切り替え（50-80%削減）

効果は絶大ですが、意外と実践している人は少ないです。

Claudeのモデル構成：

• Haiku：最安・高速。単純作業向け。
• Sonnet：性能とコストのバランス型。
• Opus：最強・最高額。Haikuの約15倍の価格。

多くの人がデフォルトをOpusにして放置していますが、それは「コンビニへ買い物に行くのも、出勤するのも全部飛行機」という状態です。

タスク分担の原則

私の使い分け：

Haikuを使う場面：

• フォーマット変換（JSON→YAML、Markdown→HTML）
• 情報検索（「このコードの言語は何？」）
• 単純Q&A（「このエラーの意味は？」）
• テキスト抽出（「関数名リストを作って」）

Sonnetを使う場面：

• コードレビュー（論理チェック、性能評価）
• コンテンツ作成（記事執筆、ドキュメント作成）
• 技術分析（アーキテクチャ分析、案の評価）

Opusを使う場面：

• アーキテクチャ設計（システム全体の設計）
• 大規模リファクタリング（広範囲のコード変更）
• 重要決定（技術選定、リスク評価）

設定例

{
  "defaultModel": "claude-3-haiku",
  "complexTaskModel": "claude-3-5-sonnet",
  "triggerKeywords": ["分析", "リファクタリング", "アーキテクチャ", "設計"]
}

デフォルトをHaikuにし、複雑な時だけ手動で切り替えます。これで操作の80%が格安モデルで処理されます。

実測効果：戦略1（リセット）と組み合わせて、月額$195から$68へ。モデル切り替えだけで65%近い節約です。

戦略4：キャッシュ最適化（30-50%削減）

Claude APIにはキャッシュ機能があります。同じ（または似た）プロンプトを連続送信すると、結果がキャッシュされ、後続のリクエストが安くなります。

活用法

1. プロンプトキャッシュ有効化（多くのOpenClaw版でデフォルトON）
2. Temperatureを下げる：0.2程度にすると出力が安定し、キャッシュヒット率が上がる
3. ハートビートでキャッシュ維持：頻繁過ぎず（5-10分間隔推奨）

{
  "temperature": 0.2,
  "enablePromptCaching": true,
  "heartbeatInterval": 300000  // 5分（ミリ秒）
}

4. キャッシュ対応リレーサービスの利用：サードパーティの中継サービスが独自キャッシュを提供している場合も。

実測効果

最大の恩恵は、システムプロンプト（5K-10Kトークン）がキャッシュ期間中は1回分しか課金されないことです。1時間で10回リクエストしても、システムプロンプト代は1回分で済みます。

効果は頻度によります。低頻度（1日数回）だとキャッシュ切れが多く効果薄ですが、高頻度（1日数十回）なら30-50%節約できます。

戦略5：コンテキストウィンドウ制限（20-40%削減）

OpenClawはデフォルトで400Kトークンまで対応していますが、器が大きいと無意識に詰め込んでしまいます。

大きなバックパックだと荷物が増え、小さなバッグなら厳選するのと同じです。

設定方法

{
  "maxContextTokens": 100000  // 400Kから100Kへ制限
}

なぜ効くのか？

上限を設けることで、OpenClawはコンテキスト整理を強制してきます。一杯になりそうになると、リセットや要約を提案してくれます。数十往復の重荷を引きずり続けることがなくなります。

それに、400Kも必要なタスクは稀です。超大規模リファクタリングでもない限り、100Kで足ります。

注意点

制限しすぎると弊害も出ます。コンテキストが必要なタスク（全体設計の分析など）で「記憶喪失」を起こし、文脈を失います。

推奨設定：

• 日常使用：50K-100K
• 複雑タスク：200K
• 超大型案件：デフォルト400K

私にとって100Kがスイートスポットです——節約でき、不便もありません。

戦略6：ローカルモデルの活用（60-80%削減）

手間を惜しまないなら、特定タスクのコストをゼロにできます。

基本思想

Ollamaでローカルモデル（Llama, Mistral等）を動かし、OpenClawの単純タスクをそちらに投げる。Claude APIを呼ばないのでタダです。

適用シーン

• フォーマット変換（JSON/YAML/Markdown相互変換）
• 単純クエリ（「TODOコメントを列挙して」）
• 情報抽出（テキストからの特定情報抜き出し）

不向きなシーン

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

• コードレビュー（品質がClaudeに劣る）
• クリエイティブ（文章作成はClaude一択）
• 複雑推論（設計・分析系）

設定例

# Ollamaインストール＆モデルPull
ollama pull llama3.2

# OpenClaw設定：単純タスクをローカルへ
{
  "localModel": "llama3.2",
  "localModelTasks": ["format", "extract", "simple-query"]
}

リアルな感想

正直、設定は面倒で、出力品質もClaudeには及びません。フォーマット変換でも10回中2-3回ミスり、手直しが必要です。

しかし予算が厳しい場合や、大量の単純反復タスクがあるなら、検討の価値はあります。その部分のコストを60-80%カットできます。

戦略7：不要スキルの無効化（10-15%削減）

OpenClawは多様なSkills（ブラウザ操作、ファイル操作、コード実行）をサポートしています。しかし、有効化された各スキルはコンテキスト（使用説明書）を消費します。

現在の有効スキルを確認

使っていないツールはありませんか？ブラウザ自動化、前回いつ使いました？Gmail連携、本当にOpenClawにメールさせますか？

最適化戦略

実際に使うものだけ有効化します。私の設定：

• ファイル読み書き（必須）
• Git操作（頻用）
• Bash実行（デバッグ用）

ブラウザ、カレンダー、メール等はすべて無効化。これでリクエストごとのシステムプロンプトが数千トークン軽くなります。

設定例

{
  "enabledSkills": [
    "file-operations",
    "git",
    "bash"
  ],
  "disabledSkills": [
    "browser-automation",
    "gmail",
    "calendar"
  ]
}

単体効果は小さい（10-15%程度）ですが、他の戦略と組み合わせることで効果を発揮します。

よくある故障・トラブル速見表——5分で90%解決

トラブル時はこの表を見てください。大抵のことは即解決します。

実戦テクニック集：

技1：WebSocket問題の最終手段

localStorageクリアでダメなら：

# Docker環境でデバイスペアリング無効化（内网環境のみ推奨）
docker run -e OPENCLAW_DISABLE_DEVICE_PAIRING=true openclaw/openclaw

技2：メモリかネットワークか瞬時に判断

# 複数指標同時監視
watch -n 1 'docker stats openclaw-gateway --no-stream && curl -s https://api.anthropic.com'

メモリ安定でレスポンス遅延ならネットワーク、メモリ高騰ならリソース不足です。

技3：ログの洪水から重要情報を探す

# エラーと警告だけ抽出
docker logs openclaw-gateway 2>&1 | grep -E "ERROR|WARN|FATAL"

数千行のログから、一瞬で「APIキー期限切れ」のERRORを見つけ出せます。

上級チューニング——OpenClawに翼を授ける

基礎最適化に飽き足らない方へ、さらなる性能向上テクニック。

高度なコンテキスト管理

コンテキスト三角測量（Context Triangulation）

ファイルを丸ごと渡さず、タスクに関連する断片だけ注入します。関数修正なら：

• その関数のコード
• 呼び出し元のシグネチャ
• 関連する型定義

これだけでコンテキストを70-80%削減できます。

階層的グローバルアンカー（TGAA）

プロジェクトルートに ARCHITECTURE.md を置き、システムの高レベル設計を記述。全体像が必要な時、全ソースではなくこれだけを読ませます。

私は各モジュールに README.md を置き、概要を書いています。OpenClawは構造理解のためにこれらを読むだけで済み、全ソースロードを回避できます。

動的ツールロード

最初から全ツール定義をロードせず、オンデマンドで注入します。ファイル操作が必要な時だけファイルツールをロード。

設定ファイルの修正が必要で技術的ハードルは高いですが、システムプロンプトを約30%削減できます。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

プリ圧縮メモリフラッシュ

セッションリセット前に、重要情報を MEMORY.md に書き出させます。リセット後、新セッションでその軽量な記憶ファイルを読み込めば、文脈を引き継げます。

# 1. 重要な決定・ToDoを保存
openclaw "議論した決定事項とToDoをMEMORY.mdに追記して"

# 2. セッションリセット
openclaw "reset session"

# 3. 文脈復帰
openclaw "MEMORY.mdを読んで作業再開"

Dockerセキュリティ強化

2026年1月、BitdefenderがCVE-2026-25253を公開。設定不備のOpenClawインスタンスからAPIキー等が漏洩する問題でした。セキュリティ設定は必須です。

非root実行

services:
  openclaw-gateway:
    user: "1000:1000"  # 特権なしユーザー

最小権限原則

docker run \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --read-only \
  --tmpfs /tmp \
  openclaw/openclaw

ネットワーク分離

外部アクセス不要なら完全遮断：

services:
  openclaw-gateway:
    network_mode: none

アクセス制御が必要ならホワイトリストプロキシ経由で。

環境変数保護

docker-compose.yml にAPIキーを直書きせず、envファイルを使用：

services:
  openclaw-gateway:
    env_file:
      - .env  # 中身：ANTHROPIC_API_KEY=sk-xxx

.env は .gitignore に追加し、絶対にコミットしないこと。

本番環境ベストプラクティス

ログローテーション

ディスク溢れ防止：

services:
  openclaw-gateway:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

最大30MBに制限されます。

定期更新

OpenClawは更新が早いです。月一で確認を：

docker pull openclaw/openclaw:latest
docker compose up -d

監視アラート

簡易スクリプトでリソース監視：

#!/bin/bash
MEM_PERCENT=$(docker stats openclaw-gateway --no-stream --format "{{.MemPerc}}" | sed 's/%//')
if (( $(echo "$MEM_PERCENT > 85" | bc -l) )); then
    # アラート送信（メール/Webhook）
    echo "OpenClawメモリ85%超！" | mail -s "OpenClaw Alert" [email protected]
fi

cronで毎時実行させます。

VPN/Tailscale利用

公网にポートを晒さず、Tailscale等でプライベートネットワーク化を推奨。

# Tailscaleインストール
curl -fsSL https://tailscale.com/install.sh | sh
# 起動
sudo tailscale up
# VPN経由で安全にアクセス可能

カフェや空港からでも安全に自宅のOpenClawを使えます。

結論

$347から$68へ、23秒から4秒へ——これは宣伝文句ではなく、実測値です。

振り返ると、OpenClawのパフォーマンス問題はシンプルです：

1. コンテキスト制御：溜め込むな
2. モデル選択：適切な道具を使え
3. リソース監視：メモリ不足に気づけ

7つの戦略を全部やる必要はありません。私のおすすめ：

• 今すぐ：メモリ確認（docker stats）、4GB未満ならアップグレード
• 今週中に：スマートモデル切替（デフォルトHaiku）＋キャッシュON（temp 0.2）
• 習慣化：タスク完了ごとのセッションリセット（/compact）

これだけでコストは半減します。

最後に。OpenClawは素晴らしいツールですが、あくまで道具です。使い手の理解と設定、習慣が性能を左右します。少しの時間を投資して理解すれば、必ずリターンがあります。

トラブル時はログを見ましょう。速見表を活用しましょう。9割は5分で解決します。困ったらGitHub Issuesもあります。

あなたのOpenClawが、より速く、より安く稼働することを願っています。

10 min read · 公開日: 2026年2月5日 · 更新日: 2026年2月5日

Easton

AI・インテリジェンス