OpenClaw（旧称 Moltbot、コミュニティスレッドではClawdbotと呼ばれることが多い）は、チャットボットのデモだけでなく、実用的なエージェントワークフローに焦点を当てているため、急速に成長しました。採用が拡大するにつれて、主要なエンジニアリング上の疑問は単純明快です。
OpenClawは、実際にどのAIモデルを本番環境で確実に実行できるのか？
この疑問は、コミュニティの投稿や以下の議論で繰り返し登場します。
- ハートビートスタイルのゲーティング（「まず安価なチェック、必要な時だけモデル」）、
- セルフホスティングとクラウドポータビリティ、
- サンドボックスを使用した安全なツール実行、
- そして、Nanobotのような軽量な代替手段とのトレードオフ。
OpenClawを中心にAPIを設計する場合、モデルのサポートは互換性だけの問題ではありません。それはレイテンシ、コスト、ツールの信頼性、そしてエラー処理に直接影響します。
このガイドでは、実装の観点からモデルのサポートを解説し、ApidogのAPI設計、テスト、モック機能を使用して統合を検証する方法を示します。
OpenClawのモデルサポート：実用的なカテゴリ
OpenClawは通常、ハードコードされた単一のバックエンドではなく、プロバイダーアダプターを介してモデルをサポートします。実際には、4つのカテゴリで考えることができます。
1) OpenAI互換のチャット/補完API
多くのOpenClawデプロイメントでは、まずOpenAI互換インターフェースを使用します。これは以下の点を標準化しているためです。
- チャットメッセージフォーマット、
- 関数/ツール呼び出しペイロード、
- ストリーミングトークンイベント、
- 使用状況メタデータ（プロンプト/補完トークン）。
これには、ホスト型プロバイダーとOpenAIスタイルのエンドポイントを公開するセルフホスト型ゲートウェイの両方が含まれます。
エンジニアリング上の影響：プロバイダーがOpenAI互換であっても、ツール呼び出しのJSON形式が異なる場合、OpenClawのプランナー/エグゼキューターステージの前に正規化レイヤーが必要になることがあります。
2) AnthropicスタイルのメッセージAPI
OpenClawは、ロール、コンテンツブロック、ツール使用のセマンティクスをOpenClawの内部エージェントプロトコルにマッピングするアダプターモジュールを介して、Anthropicスタイルのモデルに接続できます。
トレードオフ：Anthropicスタイルの構造化出力は、長文コンテキストの推論に堅牢なことが多いですが、トークン課金とストリーミングセマンティクスがOpenAI互換プロバイダーと異なる場合があります。
3) ローカル/セルフホスト型モデル（Ollama、vLLM、llama.cppブリッジ）
プライバシー、コスト管理、またはオンプレミスでのコンプライアンスのために、チームはOpenClawをローカルモデルランタイムに接続することがよくあります。
一般的なパターン：
- 高速なローカルサービスにはOllama、
- 高スループットのGPUサービスにはvLLM、
- 制約のある環境にはllama.cppベースのアダプター。
トレードオフ：ローカルデプロイメントは制御と予測可能なデータレジデンシーを提供しますが、ツール呼び出しの品質はモデルファミリーと量子化レベルによって大きく異なります。
4) 埋め込みモデルとリランカーモデル
OpenClawの「モデルサポート」には、非生成モデルも含まれることがよくあります。
- 検索用の埋め込みAPI、
- コンテキスト順序付け用のリランカー、
- 事前ルーティング用の軽量分類器（ハートビートチェック）。
これは「まず安価なチェック」というアプローチの中心です。信頼度しきい値がエスカレーションを必要としない限り、高価な推論モデルを呼び出さないようにします。
実際に重要な能力マトリックス
人々が「OpenClawはモデルXをサポートしていますか？」と尋ねるとき、本当の疑問は、モデルXが必要なエージェントの振る舞いをサポートしているかどうかです。
各モデルをこのマトリックスと照らして評価してください。
ツール/関数呼び出しの信頼性
有効なスキーマ制約付き呼び出しを繰り返し発行できますか？
構造化出力の適合性
脆いプロンプトハックなしにJSONスキーマに従いますか？
同時実行下でのレイテンシプロファイル
単一実行の平均よりもP95/P99が重要です。
コンテキストウィンドウの振る舞い
大きなコンテキストは、検索と切り捨てポリシーが安定している場合にのみ有用です。
成功したタスクあたりのコスト
単独のトークンあたりのコストではなく、完了までのコストを測定します。
安全性と拒否パターン
過剰な拒否は自動化を妨げ、過小な拒否はリスクを生み出します。
ストリーミング+キャンセルサポート
UXにとって重要であり、古いリクエストでの無駄なトークンを防ぎます。
OpenClawは多くのモデルに接続できますが、本番環境のティアには、これらの能力ゲートを通過したモデルのみを含めるべきです。
OpenClawの参照ルーティングアーキテクチャ
堅牢なOpenClawスタックは通常、階層型モデルルーティングを実装します。
- ティア0：ルール/ハートビートチェック（正規表現、キーワード、意図分類器）
- ティア1：分類/抽出用の安価な小型モデル
- ティア2：ツール計画用の中型モデル
- ティア3：困難な推論やリカバリー用の高性能モデル
これは、ハートビート投稿の傾向と一致します。可能な限り早期にショートサーキットします。
ルーティングポリシーの例（疑似設定）
yaml router: stages: - name: heartbeat type: deterministic checks: - spam_filter - known_intent_map on_match: return_or_route
- name: fast_classifier
model: local-small-instruct
max_tokens: 128
timeout_ms: 900
on_low_confidence: escalate
- name: planner
model: hosted-mid-toolcall
require_tool_schema: true
timeout_ms: 3500
on_tool_schema_error: retry_once_then_escalate
- name: reasoning_fallback
model: premium-large-reasoner
max_tokens: 1200
timeout_ms: 9000
このポリシーは、困難なリクエストの品質を維持しながら、費用を削減します。
ツール呼び出し：モデルサポートが通常失敗する箇所
OpenClawのインシデントのほとんどは、トークン制限が原因ではありません。それらは一貫性のないツール呼び出しが原因です。
一般的な失敗モード：
- モデルが部分的なJSONを出力する、
- ツール名の大文字と小文字が間違っている、
- スキーマにない引数を幻覚する、
- 状態の進行なしにツールをループで呼び出す、
- ツールエラーの後、古いコンテキストで再試行する。
堅牢化戦略
実行前の厳密なスキーマ検証
不正な形式のツール呼び出しはすぐに拒否します。
引数修復レイヤー（限定的）
小さな修正（型強制、列挙型の正規化）は行いますが、サイレントなセマンティック書き換えは行いません。
実行予算のガードレール
ツール呼び出しの深さと再試行回数を制限します。
副作用のあるツールに対する冪等性キー
再試行の嵐での重複書き込みを防ぎます。
モデル固有のプロンプトアダプター
プロバイダーファミリーごとに互換性テンプレートを保持します。
モデル接続型エージェントにおけるセキュリティとサンドボックス化
安全なサンドボックス（nonoなど）に対するコミュニティの関心は、OpenClawの核となる現実を反映しています。ツールがコードやシェルコマンドを実行する場合、モデルの品質は問題の半分にすぎません。
分離レイヤーが必要です。
- ネットワーク出力ポリシー、
- ファイルシステムスコープ、
- CPU/メモリ/時間制限、
- システムコール制約、
- ツールごとのシークレットスコープ。
OpenClawの場合、モデルサポートはセキュリティコンテキストで評価されるべきです。
- このモデルは危険なコマンドを過剰に生成するか？
- 拒否された操作から安全に回復するか？
- 内部プロンプト/サンドボックスのメタデータを漏洩するか？
モデルがQAプロンプトではうまく機能しても、サンドボックスポリシーテストに失敗する場合、それは本番環境で利用できる状態ではありません。
可観測性：時間の経過とともにモデルサポートを検証する
今日機能するモデルも、プロバイダーの更新、量子化の変更、プロンプトテンプレートのドリフト後に劣化する可能性があります。
モデル/プロバイダー経路ごとに以下のメトリクスを追跡します。
- ツール呼び出し成功率、
- スキーマ検証失敗率、
- 再試行増幅率、
- タスク完了レイテンシ（P50/P95/P99）、
- 完了したワークフローあたりのコスト、
- 上位ティアへのエスカレーション率、
- 安全ポリシー違反件数。
モデルの更新にはカナリアルーティングを使用します。
- 候補モデルに5%のトラフィック、
- 完了品質とエラー予算を比較、
- しきい値違反時には自動ロールバック。
Apidogを使用したOpenClawモデル統合のテスト
OpenClawのデプロイメントはAPIが豊富です。ルーターAPI、ツールAPI、埋め込みAPI、実行ログ、コールバックなどです。Apidogは、単純なリクエストテストを超えて、ここで役立ちます。
1) 最初に統合契約を設計する
ApidogのスキーマファーストOpenAPIワークフローを使用して以下を定義します。
/v1/agent/run/v1/agent/events（ストリームメタデータ）/v1/tools/{toolName}/invoke/v1/router/decision
明確なスキーマにより、モデルアダプターのバグを早期に発見できます。
2) ツール呼び出しの回帰シナリオを構築する
Apidogの自動テストと視覚的アサーションを使用して、シナリオスイートを作成します。
- 有効なツール呼び出し、
- 不正な形式のツールペイロード、
- タイムアウト+再試行パス、
- フォールバックモデルのエスカレーション、
- サンドボックス拒否アクション。
モデルやプロンプトの変更をデプロイする前に、これらのテストをCI/CDで品質ゲートとして実行します。
3) プロバイダーをモックしてルーティングロジックを分離する
Apidogのスマートモックを使用してモデルプロバイダーをシミュレートします。
- 遅延ストリーミングチャンク、
- 無効なJSONツール応答、
- レートリミット（429）のバースト、
- 断続的な5xxエラー。
これにより、推論予算を浪費することなく、OpenClawのルーター/エグゼキューターの動作を堅牢化できます。
4) チーム間の連携のために内部ドキュメントを公開する
OpenClawプロジェクトには通常、バックエンド、QA、プラットフォーム、セキュリティチームが関与します。Apidogの自動生成されるインタラクティブドキュメントは、リクエスト/レスポンス契約と障害セマンティクスについて全員の認識を合わせるのに役立ちます。
OpenClawチーム向けの一般的なモデル戦略パターン
パターンA：ローカルファースト、クラウドフォールバック
- ローカルの中規模モデルがルーティンタスクを処理。
- クラウドのプレミアムモデルが複雑な長尾を処理。
最適：プライバシー重視のワークロードで、たまに難しいクエリが発生する場合。
パターンB：厳密な予算ルーターを備えたクラウドファースト
- ホスト型モデルのみを使用するが、アグレッシブなハートビートフィルタリングを行う。
- 予算がしきい値に近づくと、コストガードレールと動的なダウングレード。
最適：運用上のシンプルさを最適化するチーム。
パターンC：ドメイン特化型分割
- 抽出/分類用のモデルが1つ、
- 計画用のモデルがもう1つ、
- 応答合成用のモデルがもう1つ。
最適：各ステージで異なる品質制約を持つ大容量パイプライン。
チームが見落としがちなエッジケース
- プロバイダー間のトークナイザーの不一致が、切り捨てロジックの破損を引き起こす。
- ツールを多用するフローで、関数呼び出しトークンのインフレーションが隠れたコストを増加させる。
- プロバイダーがデルタ形式を変更すると、ストリーミングパーサーのドリフトが発生し、機能が停止する。
- バージョン固定なしのモデル更新が、サイレントに動作を退化させる。
- クロスリージョンフェイルオーバーが、タイムアウトカスケードを引き起こすのに十分なレイテンシの変化をもたらす。
これらは、明示的なプロバイダーバージョン固定、統合テスト、そして直感ではなくP95データに基づいたタイムアウト予算で対処します。
では、OpenClawはどのモデルをサポートしているのか？
正確なエンジニアリングの回答は次のとおりです。
OpenClawは、アダプターを介して複数のモデルファミリーをサポートしています。これには、OpenAI互換API、AnthropicスタイルのAPI、ローカル/セルフホスト型ランタイムが含まれ、さらに検索とルーティングで使用される埋め込みモデル/リランカーも含まれます。
しかし、サポートは二元的ではありません。本番環境でのサポートは、特定のモデルが以下の要件を確実に満たすかどうかにかかっています。
- ツール呼び出し、
- スキーマ準拠、
- 負荷下でのレイテンシ、
- 安全性に関する挙動、
- そして完了までのコスト。
モデルのオンボーディングをAPI契約の問題として捉えれば、プロバイダーを客観的に評価し、エージェントの信頼性に関するほとんどの障害を回避できます。
実用的な次のステップは、ApidogでOpenClawの契約を定義し、ルーティングとツール実行のためのシナリオベースの回帰テストを追加し、CI/CDでモデルの昇格をゲートすることです。これにより、OpenClawがあなたの環境でどのモデルを真にサポートしているかについて、再現性のある証拠が得られます。
このワークフローを迅速に実装したい場合は、Apidogで無料で試して、OpenClaw互換性テストスイートを1つの共有ワークスペースで構築してください。