Moltbot → Clawdbot → OpenClaw という名称変更のサイクルを追ってきた方なら、おそらく他の皆さんと同様の現実的な疑問を抱いていることでしょう。
「OpenClaw を確実に動作させるには、何に料金を支払い、どのキーが必要なのか？」
このガイドでは、マーケティングコピーではなく、技術的な回答を提供します。アーキテクチャ、機能面、コストモデル、運用リスク別に解説していきます。
簡潔な回答
OpenClaw は通常、単一のホスト型モデルではなく、オーケストレーターです。ほとんどのセットアップでは、以下のものが必要です。
- 少なくとも1つのLLMプロバイダーAPIキー（推論/チャット/ツール利用のため）
- オプションの埋め込みプロバイダーキー（セマンティックメモリ/検索を実行する場合）
- オプションのリランカーキー（RAGスタックでリランキングを使用する場合）
- オプションのウェブ/検索APIキー（ブラウジングツールのため）
- オプションの音声キー（音声ワークフローのためのSTT/TTS）
- オプションの可観測性キー（LangSmith、Helicone、OpenTelemetryバックエンドなど）
- クラウド/ランタイムのサブスクリプション（マネージドインフラをデプロイする場合のみ、例：DigitalOcean droplet、マネージドDB、オブジェクトストレージ）
これらすべてが常に必要というわけではありません。
最小限のインストールであれば、1つのLLMキーとローカルストレージで動作可能です。
OpenClawコミュニティでこれが混乱を招く理由
OpenClawに関するコミュニティ投稿（ハートビート、名称変更の混乱、本番環境のチュートリアル、サンドボックス化）は、ある中心的な現実を反映しています。
- 人々はOpenClawをモノリシックなSaaSとして期待してインストールします。
- しかし、OpenClawはしばしば複数の外部サービスの制御プレーンのように振る舞います。
したがって、「サブスクリプションのフットプリント」は、どの機能を有効にするかによって異なります。
有用なメンタルモデル：
- OpenClawコア：ルーティング、ツールオーケストレーション、メモリ抽象化、エージェントループ
- あなたのプロバイダー：モデル、ベクトル、検索、テレメトリー、ストレージ
- あなたのインフラ：コンピューティング + シークレット + ネットワーク + 永続性
認証情報マトリックス：機能 → キー/サブスクリプション
| OpenClawの機能 | 通常必要 | 典型的な例 |
|---|---|---|
| チャット/推論 | LLM APIキー | OpenAI、Anthropic、Groq、ローカルゲートウェイ |
| ツール呼び出しエージェント | ツール/関数サポート付きLLMキー | 上記と同じ |
| 長期的なセマンティックメモリ | 埋め込みキー + ベクトルDB認証情報 | OpenAI/Cohere埋め込み + Pinecone/Weaviate/pgvector |
| 検索/ブラウズツール | 検索APIキー | Tavily、SerpAPI、カスタムクローラーバックエンド |
| コード実行 / サンドボックス | サンドボックスサービス トークン | セルフホスト型コンテナランタイム、セキュアなサンドボックスツール |
| 音声入力/出力 | STT/TTSキー | Deepgram、ElevenLabs、クラウド音声API |
| トレーシング/モニタリング | 可観測性トークン | LangSmith、Helicone、OTLPコレクター認証 |
| チーム機能 | ホスト型OpenClaw/組織サブスクリプション（該当する場合） | プロジェクト/組織シート、ホスト型コントロールプレーン |
「チャット + シンプルなツール」しか必要としない場合、1つのモデルキーで十分です。
最小限の実用的なセットアップ
1) ローカル開発スターター（最低コスト）
- 1つのLLMキー
- ローカルSQLite/Postgres
- 埋め込みなし、リランカーなし
- ホスト型トレーシングなし
オーケストレーションロジックとプロンプトの動作を確認するためにこれを使用します。
2) RAG対応ステージング
- LLMキー
- 埋め込みキー
- ベクトルDB認証情報
- オプションのリランカーキー
- オプションの検索APIキー
検索中心のワークロードで品質テストを行うためにこれを使用します。
3) 本番エージェントスタック
- プライマリ + フォールバックLLMキー
- 埋め込み + ベクトルDB認証情報
- 検索/ブラウズキー
- 可観測性トークン
- サンドボックス実行トークン/ランタイム
- クラウドインフラサブスクリプション（コンピューティング、DB、オブジェクトストレージ、シークレット）
稼働時間と安全性が重要な場合、これを使用します。
サブスクリプション数を左右するアーキテクチャ上のトレードオフ
トレードオフ1：単一プロバイダー vs マルチプロバイダールーティング
- 単一プロバイダー：認証が簡単、課金が容易
- マルチプロバイダー：回復力と価格裁定が向上、キー管理の複雑さが増す
モデルのフェイルオーバー（例：複雑なタスクにはプレミアムモデル、ハートビートには安価なモデル）を実装する場合、複数のキーを維持することになるでしょう。
トレードオフ2：ホスト型ベクトルDB vs pgvectorセルフホスト型
- ホスト型ベクトルDB：起動が速い、追加の請求とAPIトークンが必要
- セルフホスト型pgvector：ベンダーキーが少ない、運用オーバーヘッドが大きい
トレードオフ3：マネージド可観測性 vs DIYログ
- マネージドトレーシング：根本原因分析が速い、追加のトークン/コストがかかる
- DIY：直接コストは低い、デバッグ時間が長い
エージェントシステムでは、デバッグ時間が通常、隠れたコストセンターです。これを早期に最適化しすぎないでください。
コスト管理パターン：「まず安価なチェック、必要な時だけモデルを使用」
コミュニティで議論されているパターンとして、ハートビートゲートがあります。高価なモデル呼び出しの前に低コストのチェックを実行するものです。
実践的な実装：
- 決定論的チェックで鮮度/状態を検証する
- ルールベースのガードレールを実行する
- 安価なモデル層を呼び出す
- 信頼度が低下した場合のみ、プレミアムモデルにエスカレートする
これにより、キー戦略が直接変わります：
- ティアごとに別のキー/プロジェクトを維持する
- プロバイダーごとに予算上限を追加する
- 意図クラスと信頼度スコアでルーティングする
推奨される環境変数レイアウト
明示的で名前空間化された変数を使用すると、ローテーションやインシデント対応が容易になります。
コアモデルルーティング
OPENCLAW_LLM_PRIMARY_PROVIDER=openai OPENCLAW_LLM_PRIMARY_KEY=... OPENCLAW_LLM_FALLBACK_PROVIDER=anthropic OPENCLAW_LLM_FALLBACK_KEY=...検索
OPENCLAW_EMBED_PROVIDER=openai OPENCLAW_EMBED_KEY=... VECTOR_DB_URL=... VECTOR_DB_API_KEY=...ツール
SEARCH_API_KEY=... SANDBOX_API_TOKEN=...可観測性
LANGSMITH_API_KEY=... OTEL_EXPORTER_OTLP_ENDPOINT=... OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer ...セキュリティ
OPENCLAW_ENCRYPTION_KEY=...ヒント：
- 開発/ステージング/本番環境で同じキーを再利用しない
- 最低でも四半期ごとにローテーションする
- トークンは最小限の権限に限定する
- プロバイダー固有のレート制限ダッシュボードをブックマークしておく
セキュリティとサンドボックス化：スキップすると後悔するサブスクリプション
OpenClawエージェントがコードを実行したり、ウェブをブラウズしたり、ファイルシステム/ネットワークツールに触れたりする場合、サンドボックスレイヤーを含めてください。安全なサンドボックスにコミュニティが注力しているのは正当です。
最低限必要なもの：
- ネットワーク送信制御
- 一時的な実行環境
- リソースクォータ（CPU、メモリ、ランタイム）
- コマンド許可/拒否ポリシー
- ファイルマウント制限
これにより、別のサービス/トークンが導入されるかもしれませんが、壊滅的なリスクを軽減します。
Apidogでキー設定をテストする
キーを接続したら、繰り返し可能なAPI検証が必要です。ここでApidogが自然に役立ちます。
Apidogを使用して以下を実行します：
- OpenAPI仕様でOpenClawゲートウェイAPIを定義する
- 環境（開発/ステージング/本番）全体で自動テストを実行する
- レスポンス構造、ツール出力、エラーエンベロープに対して視覚的なアサーションを追加する
- フォールバックロジックをテストするために、スマートモックでプロバイダーの障害をモックする
- 内部チーム向けにインタラクティブなドキュメントを公開する
迅速に作業を進める場合、これによりキー/設定のずれが本番環境を密かに破壊するのを防ぐことができます。
自動化すべきテストケースの例
- キー欠落パス：401/500エラー処理と明確なエラーメッセージングを確認する
- レート制限パス：プロバイダーの429エラーをシミュレートし、フォールバックルーティングを確認する
- 予算ガードパス：しきい値を超えた場合、高価なモデルの使用を拒否する
- サンドボックス拒否パス：ブロックされたツール呼び出しが安全に失敗することを確認する
- RAG劣化パス：埋め込み/ベクトル障害が正常に劣化することを確認する
Apidogでは、これらをシナリオスイートとしてグループ化し、CI/CDでリリースゲートとして実行できます。
「OpenClawが壊れている」場合のデバッグチェックリスト
ほとんどの障害はオーケストレーションのバグではなく、認証情報やクォータに起因します。
この順序で確認してください：
- キーの存在：ランタイムコンテナに環境変数がロードされているか？
- キーのスコープ：トークンは必要なモデルエンドポイントにアクセスできるか？
- レート制限/クォータ：プロバイダーダッシュボードでスロットリングが表示されているか？
- 誤ったエンドポイントリージョン：モデル/キーが別のリージョンに関連付けられているか？
- クロックスキュー / 認証ヘッダー：時刻のずれにより署名付きリクエストが失敗しているか？
- フォールバックが無効：二次プロバイダーの使用を妨げる設定ミスはないか？
- ベクトルインデックスの不一致：埋め込みモデルが変更されたが、インデックスが再構築されていないか？
ゲートウェイに構造化されたエラーコードを追加し、ログが認証、クォータ、ルーティング、ツールのエラーを区別できるようにしてください。
意思決定フレームワーク：今日実際に必要なもの
この簡単なマトリックスを使用してください：
- 個人/ローカル実験 → 1つのLLMキー
- ドキュメント付き知識アシスタント → LLM + 埋め込み + ベクトルDB
- ウェブ対応アシスタント → 検索キーを追加
- 音声エージェント → STT/TTSキーを追加
- チーム本番システム → 可観測性 + サンドボックス + マルチプロバイダーフェイルオーバーを追加
時期尚早なベンダー乱立は避けてください。機能が稼働し、テストされた場合にのみサブスクリプションを追加してください。
よくある間違い
全てのサブスクリプションを最初から購入する
- 複雑さと遊休費用につながります。
全ての環境で一つのキーを使い回す
- インシデントの封じ込めが困難になります。
フォールバックモデル戦略がない
- 単一プロバイダーの障害がアプリケーション全体の障害になります。
トレーシングをスキップする
- 観測できないものは最適化できません。
ゲートウェイでコントラクトテストがない
- サイレントなスキーマのずれがクライアントを破壊します。
最終回答
ほとんどの開発者にとって、OpenClawを実行するために必要な最小限のものは次のとおりです。
- 1つのLLM APIキー
ほとんどの本番チームにとって、現実的なベースラインは次のとおりです。
- プライマリ + フォールバックLLMキー
- 埋め込み + ベクトルDB認証情報
- オプションの検索キー（ブラウジング/RAGの強化が必要な場合）
- 可観測性トークン
- サンドボックス/ランタイム制御
- デプロイインフラのためのクラウドサブスクリプション
OpenClawをオーケストレーション層として扱ってください。あなたのキー戦略は、バズワードではなく、あなたのアーキテクチャを反映すべきです。