OpenClawパフォーマンスチューニング｜遅いを解消する高速化の実践

Q: CDNを使うとセキュリティは大丈夫ですか？

CloudflareなどのCDNはDDoS防御やWAF機能も提供するため、むしろセキュリティが向上する場合が多いです。オリジンサーバーのIPアドレスが隠蔽され、直接攻撃を受けるリスクも低下します。

公開日：2026年3月 / 更新日：2026年3月

OpenClawが重い、応答が遅いと感じたら、まず正しく計測することが先決です。ボトルネックを特定せずに対策を打っても効果は限定的です。本記事では、計測指標の把握からDBクエリ最適化、キャッシュ導入、CDN設定、インフラスケールアップまで、段階的なパフォーマンスチューニング手法を解説します。

OpenClawパフォーマンスまず計測すべき3つの指標

パフォーマンス改善の第一歩は、「なんとなく遅い」を数値で捉えることです。計測なしに対策を打っても、効果の有無すら判断できません。まず以下の3指標を計測してください。

レスポンスタイム（応答時間）

ユーザーがリクエストを送ってからレスポンスが返るまでの時間です。curlのタイミングオプションで手軽に計測できます。

計測コマンド：curl -o /dev/null -s -w "time_total: %{time_total}s\ntime_connect: %{time_connect}s\ntime_starttransfer: %{time_starttransfer}s\n" https://your-openclaw-domain/
time_starttransfer がTTFB（最初の1バイトが返るまでの時間）。2秒超なら要対処
Google PageSpeed Insightsでも確認可能。LCP（最大コンテンツ描画）2.5秒以内が目標

スループット（RPS: リクエスト/秒）

単位時間あたりに処理できるリクエスト数です。Apache Bench（ab）で負荷をかけて計測します。

計測コマンド：ab -n 1000 -c 10 https://your-openclaw-domain/（10並列で1000リクエスト）
Requests per second の値がRPS。この値が低いほどスケール耐性が低い
htopでCPU/メモリ使用率を同時に確認し、ボトルネックがCPUかメモリかを特定

エラーレート

全リクエストに対する5xx/4xxエラーの割合です。高負荷時にエラーが増えていないか確認します。

Nginxアクセスログを集計：awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c
5xxエラーが1%超なら、アプリまたはインフラに深刻な問題がある
定期的にabでエラーなし（Failed requests: 0）を確認する習慣をつける

ポイント

計測は必ずテスト環境と本番環境の両方で実施してください。テスト環境と本番環境でスペックが異なる場合、結果に大きな差が出ることがあります。改善前後で同条件での計測を記録として残すことが重要です。

OpenClawパフォーマンスデータベースクエリの最適化

OpenClawのパフォーマンス問題の多くは、データベースクエリが原因です。アプリケーション側をどれだけ最適化しても、DBがボトルネックであれば効果は限定的です。

Slow Query Logの有効化

まずどのクエリが遅いのかを特定します。MySQLのスロークエリログを有効化して、実際に時間のかかっているクエリを洗い出してください。

slow_query_log = ON、long_query_time = 1（1秒超を記録）をmy.cnfに追記
ログファイル（/var/log/mysql/slow.log）をmysqldumpslow等で集計
実行頻度が高く、かつ実行時間が長いクエリから優先して対処する

EXPLAIN分析でクエリを診断する

遅いクエリが特定できたら、EXPLAINコマンドで実行計画を確認します。フルテーブルスキャン（type: ALL）が発生していれば、インデックスが効いていない証拠です。

EXPLAIN SELECT * FROM messages WHERE user_id = 123 AND created_at > '2026-01-01';
typeカラムが ALL → フルスキャン、ref や range → インデックス使用中
rowsカラムが大きい（数万以上）場合は絞り込みが不十分

インデックスの追加

WHERE句やORDER BY、JOIN条件に使われるカラムにはインデックスを追加します。ただし、インデックスは書き込み速度に影響するため、不要なインデックスは作らないことが原則です。

CREATE INDEX idx_user_created ON messages (user_id, created_at);（複合インデックス）
カーディナリティ（値の種類数）が高いカラムほどインデックスの効果が高い
追加後は再度EXPLAINで効いているか確認する

N+1問題の解消

ループ内でDBクエリを発行する「N+1問題」は、データ件数に比例してクエリ数が増える深刻なパターンです。

ユーザー一覧を取得後、各ユーザーのメッセージを1件ずつ取得している場合など
JOINやIN句でまとめて取得するか、アプリケーション側でキャッシュして解消する
ORMを使っている場合は eager loading（事前ロード）の設定を確認する

注意

本番DBへのEXPLAIN実行は安全ですが、インデックス追加はロック時間が発生する場合があります。大量データのテーブルにインデックスを追加する際は、メンテナンス時間帯に実施するか、ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONEオプションを検討してください。

OpenClawパフォーマンスキャッシュ導入で劇的に改善する

適切なキャッシュ戦略は、DBへの負荷を劇的に削減し、レスポンスタイムを短縮する最も費用対効果の高い施策です。3層のキャッシュを組み合わせることで高い効果を得られます。

Redisキャッシュ（アプリケーション層）

頻繁にアクセスされるDBクエリの結果や、セッションデータをRedisにキャッシュします。メモリベースのため、DBより桁違いに高速です。

Docker環境ならdocker-compose.ymlに redis: image: redis:7-alpine を追加するだけ
キャッシュキーは openclaw:user:123 のように名前空間を付けて管理する
TTL（有効期限）を設定して古いデータが残らないようにする（例：60秒〜10分）
頻繁に変わらないマスターデータ、ランキング、集計結果が特に効果的

OPcache（PHP実行層）

PHPはリクエストごとにスクリプトをコンパイルします。OPcacheを有効にすると、コンパイル済みのバイトコードをメモリにキャッシュし、再コンパイルをスキップできます。

php.iniで opcache.enable=1、opcache.memory_consumption=128（MB）を設定
設定後に php -r "var_dump(opcache_get_status());" でキャッシュ状況を確認
本番デプロイ後は opcache_reset() でキャッシュをクリアする運用が必要

Nginx fastcgi_cache（ページキャッシュ層）

NginxのfastCGIキャッシュを使うと、PHP処理を完全にスキップしてレスポンスを返せます。認証不要なページに特に有効です。

fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=openclaw:10m max_size=1g inactive=60m;
ログイン後のページや動的データが多いページはキャッシュ対象外に設定する
fastcgi_cache_valid 200 301 302 10m; でステータス別のTTLを設定

キャッシュ戦略の優先順位

まずOPcacheから始めてください（設定変更のみ、即効性あり）。次にRedisキャッシュ（DB負荷が高い場合に特に有効）、最後にNginxページキャッシュ（トップページや静的コンテンツ中心のページ向け）の順で導入するのが効率的です。

OpenClawパフォーマンス CDN導入で静的ファイルを高速配信

画像、CSS、JavaScriptなどの静的ファイルをCDN経由で配信することで、サーバー負荷を削減しつつ、ユーザーの地理的な位置に近いエッジサーバーから高速に配信できます。

Cloudflare無料プランの設定

Cloudflareは無料プランでもCDN、DDoS防御、WAFの基本機能が利用できます。DNSをCloudflare管理に移すだけで利用開始できます。

Cloudflareにアカウント作成 → ドメインを追加 → ネームサーバーをCloudflareに変更
DNSレコードのプロキシ設定（オレンジ雲のアイコン）をオンにすることでCDNが有効化される
SSL/TLSの暗号化モードは「Full (strict)」を推奨。オリジンサーバーにも有効な証明書が必要

キャッシュルールの設定

Cloudflareのキャッシュルール（旧Page Rules）でキャッシュ対象と除外対象を明確に設定します。

静的ファイル（*.css, *.js, *.png, *.jpg, *.webp, *.woff2）はキャッシュ時間を長く設定（1週間〜1ヶ月）
管理画面、APIエンドポイント、ログイン後のページはキャッシュをバイパスする
Cache-Control: public, max-age=604800, immutableをサーバー側で設定するとCloudflareが自動的に長期キャッシュする

画像最適化（WebP変換）

Cloudflareの「Polish」機能（有料プラン）またはサーバー側でWebP変換を行うことで、画像サイズを50〜80%削減できます。

サーバー側変換ツール：cwebp -q 80 input.png -o output.webp
HTML側は <picture> タグを使ってWebP非対応ブラウザにはJPEG/PNGを提供
lazy loading属性（loading="lazy"）を画像タグに追加してLCPを改善

Cloudflareの追加メリット

CDN機能に加え、Cloudflareは無料プランでもDDoS防御とWAF（Webアプリケーションファイアウォール）の基本機能が含まれます。パフォーマンス改善と同時にセキュリティも向上するため、OpenClaw運用環境への導入を強く推奨します。

OpenClawパフォーマンスインフラのスケールアップとスケールアウト

キャッシュ最適化やCDN導入を実施してもパフォーマンスが改善しない場合、インフラ自体の増強が必要です。スケールアップとスケールアウトの特性を理解して、適切な手段を選んでください。

垂直スケール（スケールアップ）

既存サーバーのCPUコア数やメモリを増やす方法です。設定変更やアプリケーションの改修が不要なため、最も手軽に実施できます。

VPSの場合はコントロールパネルからプランアップグレードが数分で完了
CPUバウンドな処理（AI推論、画像処理）にはCPUコア増強が有効
メモリバウンドな処理（大量データのキャッシュ）にはRAM増強が有効
上限：1サーバーの物理的な上限があり、コストが線形以上に増加する

水平スケール（スケールアウト）

サーバー台数を増やし、ロードバランサーで負荷を分散する方法です。理論上は無限にスケールできますが、アプリケーション設計の変更が必要です。

セッション管理をRedisに移行（各サーバーのローカルセッションは使えない）
ファイルアップロードは共有ストレージ（S3互換サービス等）に保存する設計に変更
ロードバランサー：Nginx（upstream設定）、HAProxy、またはクラウドのマネージドLBを使用
Nginxロードバランサー例：upstream openclaw { server app1:8080; server app2:8080; }

スケールアップとスケールアウトの判断基準

どちらを先に検討すべきか、以下の基準を参考にしてください。

まずスケールアップを試す：設定変更のみで対応でき、コストも予測しやすい
スケールアウトに移行するタイミング：スケールアップの上限コストを超えた場合、または単一障害点（SPOF）を排除したい場合
スケールアウトの前提：アプリケーションがステートレス（状態をサーバーに持たない）設計になっていること

注意

スケールアウトはアプリケーション設計の変更を伴う場合があります。OpenClawのセッション管理やファイル保存の設計を事前に確認してください。設計変更なしでスケールアウトしても、正常に動作しないことがあります。

まとめ

OpenClawのパフォーマンスチューニングは、計測 → ボトルネック特定 → 対策の順で段階的に進めることが重要です。いきなりインフラを増強するのではなく、まず計測で問題の所在を明確にしてください。

Step 1 計測：curl -w、ab、htopでレスポンスタイム・RPS・エラーレートを把握
Step 2 DB最適化：Slow Query Log + EXPLAINでボトルネッククエリを特定し、インデックス追加・N+1解消
Step 3 キャッシュ：OPcache（即効性あり）→ Redis → Nginxページキャッシュの順で導入
Step 4 CDN：Cloudflareで静的ファイルをエッジ配信、WebP変換で画像を軽量化
Step 5 インフラ：上記で解消しない場合のみスケールアップ（先）→ スケールアウト（後）を検討

保守運用と並行してパフォーマンス改善を継続的に行うことで、ユーザー体験と運用コストの両方を最適化できます。運用体制の整備については運用保守ガイドを、セキュリティとの両立についてはセキュリティ設計ガイドを参照してください。

よくある質問

パフォーマンスの目標値はどの程度ですか？

Web画面の応答は2秒以内、APIは500ms以内が目安です。Google PageSpeed Insightsスコア90以上を目標に設定してください。LCP（最大コンテンツ描画）2.5秒以内、FID（初回入力遅延）100ms以内、CLS（累積レイアウトシフト）0.1以下がCore Web Vitalsの基準です。

Redisの導入は難しいですか？

Docker環境ならdocker-compose.ymlにRedisサービスを追加するだけです。アプリケーション側の設定も数行の変更で済みます。redis: image: redis:7-alpineを追加し、アプリケーションからredis:6379に接続するだけで動作します。PHPであればpredis/predisライブラリを使うのが一般的です。

CDNを使うとセキュリティは大丈夫ですか？

CloudflareなどのCDNはDDoS防御やWAF機能も提供するため、むしろセキュリティが向上する場合が多いです。トラフィックがCloudflareを経由することで、オリジンサーバーのIPアドレスが隠蔽され、直接攻撃を受けるリスクも低下します。ただし、機密データをキャッシュしないよう適切なキャッシュルールの設定が必要です。

負荷テストはどう実施すべきですか？

Apache Bench（ab）やk6で本番相当のリクエストを送信します。必ずテスト環境で実施し、段階的に負荷を上げて限界値を把握してください。k6はJavaScriptでシナリオを記述でき、実際のユーザー行動に近い負荷テストが可能です。本番環境での負荷テストは絶対に事前告知と合意のうえで実施してください。

画像の最適化で効果はありますか？

PNG→WebP変換で50〜80%のファイルサイズ削減が期待できます。lazy loadingとの併用でLCP改善にも効果的です。特に画像を多用するページ（商品一覧、ギャラリー等）では、ページ全体の転送量が大幅に削減され、モバイル回線のユーザーにとっての体感速度が著しく改善します。

PHPのバージョンアップで速くなりますか？

PHP 7→8で約20〜30%の性能向上が報告されています。OPcacheの有効化と合わせて対応すると効果が大きいです。PHP 8.1以降はFibers（非同期処理）や、JIT（Just-In-Time）コンパイラの改善が含まれており、計算処理の多いワークロードでは特に顕著な改善が見られます。バージョンアップ前は互換性テストを必ず実施してください。

スケールアップとスケールアウトのどちらが先ですか？

まずスケールアップ（CPU/メモリ増強）を検討してください。それでも限界に達したらスケールアウト（サーバー台数追加）を検討します。スケールアウトはアプリケーションの設計変更が必要になる場合があります。セッション管理の外部化、ファイル共有ストレージの導入など、事前準備が伴うため、スケールアップで対応できる間は慌てる必要はありません。

OpenClawの導入を検討していますか？

設計・構築・保守まで、構築代行会社を比較して最適なパートナーを見つけましょう。

構築代行会社を比較する →