OpenClaw plugins が初めてですか?パッケージ構造とマニフェスト設定については、まず はじめに
を読んでください。
ウォークスルー
Package and manifest
ステップ 1: パッケージとマニフェスト
setup.providers[].envVars により、OpenClaw は Plugin ランタイムを読み込まずに認証情報を検出できます。
プロバイダーのバリアントが別のプロバイダー ID の認証を再利用する必要がある場合は、providerAuthAliases を追加します。modelSupport は任意で、ランタイムフックが存在する前に、acme-large のような短縮形のモデル ID から OpenClaw がプロバイダー Plugin を自動読み込みできるようにします。package.json の openclaw.compat
と openclaw.build は ClawHub 公開に必要です(openclaw.compat.pluginApi と openclaw.build.openclawVersion
が 2 つの必須フィールドです。minGatewayVersion は省略時に
openclaw.install.minHostVersion にフォールバックします)。Register the provider
最小限のテキストプロバイダーには、プロバイダー API がよりリッチなメタデータを返し、Plugin 自身が OpenClaw モデル定義へ行を投影する必要がある場合は、
id、label、auth、catalog が必要です。
catalog はプロバイダー所有のランタイム/設定フックです。ライブのベンダー API を呼び出し、
models.providers エントリを返すことができます。index.ts
registerModelCatalogProvider は、リスト/ヘルプ/ピッカー UI 向けの新しいコントロールプレーンカタログサーフェスで、
text、voice、image_generation、video_generation、music_generation の行をカバーします。ベンダーエンドポイントの呼び出しとレスポンスのマッピングは Plugin に保持してください。OpenClaw は共有の行形状、ソースラベル、ヘルプ表示を所有します。これで動作するプロバイダーになります。ユーザーは
openclaw onboard --acme-ai-api-key <key> を実行し、
acme-ai/acme-large をモデルとして選択できるようになります。ライブモデル検出
プロバイダーが/models スタイルの API を公開している場合は、プロバイダー固有のエンドポイントと行への投影を Plugin に保持し、共有フェッチライフサイクルには
openclaw/plugin-sdk/provider-catalog-live-runtime を使用します。このヘルパーは、プロバイダーポリシーを OpenClaw core に入れることなく、保護された HTTP フェッチ、プロバイダー認証ヘッダー、構造化 HTTP エラー、TTL キャッシュ、静的フォールバック動作を提供します。ライブ API が、プロバイダー所有の静的カタログ行のうち現在利用可能なものだけを示す場合は、buildLiveModelProviderConfig を使用します。index.ts
getCachedLiveProviderModelRows を使用します。index.ts
run は認証で保護されたままにし、利用可能な認証情報がない場合は null を返す必要があります。セットアップ、ドキュメント、テスト、ピッカーサーフェスがライブネットワークアクセスに依存しないように、オフラインの staticRun または静的フォールバックを保持してください。モデルリストの鮮度に適した TTL を使用し、リクエスト時のファイルシステムポーリングを避け、上流レスポンスが OpenAI 互換の { data: [{ id, object }] }
形状でない場合にのみ、プロバイダー固有の readRows / readModelId を渡してください。上流プロバイダーが OpenClaw と異なる制御トークンを使用している場合は、ストリームパスを置き換えるのではなく、小さな双方向テキスト変換を追加します。input はトランスポート前に最終的なシステムプロンプトとテキストメッセージ内容を書き換えます。output は、OpenClaw が自身の制御マーカーを解析する前、またはチャンネル配信の前に、アシスタントのテキスト差分と最終テキストを書き換えます。API キー認証と単一のカタログ backed ランタイムを持つ 1 つのテキストプロバイダーのみを登録するバンドルプロバイダーでは、より狭い
defineSingleProviderPluginEntry(...) ヘルパーを優先してください:buildProvider は、OpenClaw が実際のプロバイダー認証を解決できる場合に使用されるライブカタログパスです。プロバイダー固有の検出を実行する場合があります。buildStaticProvider は、認証が設定される前に表示しても安全なオフライン行にのみ使用してください。認証情報を要求したり、ネットワークリクエストを実行したりしてはいけません。
OpenClaw の models list --all 表示は現在、バンドルされたプロバイダー Plugin に対してのみ、空の設定、空の env、agent/workspace パスなしで静的カタログを実行します。認証フローでオンボーディング中に models.providers.*、エイリアス、agent のデフォルトモデルもパッチする必要がある場合は、openclaw/plugin-sdk/provider-onboard のプリセットヘルパーを使用してください。最も範囲の狭いヘルパーは
createDefaultModelPresetAppliers(...)、
createDefaultModelsPresetAppliers(...)、および
createModelCatalogPresetAppliers(...) です。プロバイダーのネイティブエンドポイントが通常の openai-completions トランスポート上でストリーミングされた使用量ブロックをサポートする場合は、プロバイダー ID チェックをハードコードするのではなく、openclaw/plugin-sdk/provider-catalog-shared の共有カタログヘルパーを優先してください。supportsNativeStreamingUsageCompat(...) と
applyProviderNativeStreamingUsageCompat(...) は、エンドポイントのケイパビリティマップからサポートを検出するため、Plugin がカスタムプロバイダー ID を使用している場合でも、ネイティブの Moonshot/DashScope 形式のエンドポイントはオプトインできます。上記のライブ検出例は、/models 形式のプロバイダー API を対象としています。その検出は catalog.run 内に置き、使用可能な認証でゲートし、staticRun はオフラインカタログ生成のためにネットワークなしに保ってください。動的モデル解決を追加する
プロバイダーが任意のモデル ID(プロキシやルーターなど)を受け付ける場合は、解決にネットワーク呼び出しが必要な場合は、非同期ウォームアップに
resolveDynamicModel を追加します。prepareDynamicModel を使用してください。完了後に resolveDynamicModel が再度実行されます。ランタイムフックを追加する(必要に応じて)
ほとんどのプロバイダーは 現在利用可能な replay ファミリー:
現在利用可能な stream ファミリー:
catalog + resolveDynamicModel だけで十分です。プロバイダーが必要とする場合に、フックを段階的に追加してください。共有ヘルパービルダーは現在、最も一般的な replay/tool-compat ファミリーをカバーしているため、Plugin が各フックを一つずつ手作業で配線する必要は通常ありません。| ファミリー | 配線される内容 | バンドル例 |
|---|---|---|
openai-compatible | OpenAI 互換トランスポート向けの共有 OpenAI 形式 replay ポリシー。tool-call-id のサニタイズ、assistant-first 順序修正、トランスポートが必要とする場合の汎用 Gemini ターン検証を含みます | moonshot, ollama, xai, zai |
anthropic-by-model | modelId によって選択される Claude 対応 replay ポリシー。これにより、Anthropic-message トランスポートは、解決済みモデルが実際に Claude ID の場合にのみ Claude 固有の thinking-block クリーンアップを受けます | amazon-bedrock |
native-anthropic-by-model | anthropic-by-model と同じ Claude-by-model ポリシーに加え、tool-call-id のサニタイズと、ベンダーネイティブ ID を維持する必要があるトランスポート向けのネイティブ Anthropic tool-use ID 保持 | anthropic-vertex, clawrouter |
google-gemini | ネイティブ Gemini replay ポリシーと bootstrap replay サニタイズ。共有ファミリーは、タグ付き reasoning でテキスト出力の Gemini CLI を維持します。直接の google プロバイダーは、Gemini API の thinking がネイティブ thought parts として届くため、resolveReasoningOutputMode を native にオーバーライドします。 | google, google-gemini-cli |
passthrough-gemini | OpenAI 互換プロキシトランスポート経由で実行される Gemini モデル向けの Gemini thought-signature サニタイズ。ネイティブ Gemini replay 検証や bootstrap 書き換えは有効にしません | openrouter, kilocode, opencode, opencode-go |
hybrid-anthropic-openai | 1 つの Plugin 内で Anthropic-message と OpenAI 互換モデルサーフェスを混在させるプロバイダー向けのハイブリッドポリシー。任意の Claude 専用 thinking-block ドロップは Anthropic 側に限定されます | minimax |
| ファミリー | 配線される内容 | バンドル例 |
|---|---|---|
google-thinking | 共有 stream パス上での Gemini thinking ペイロード正規化 | google, google-gemini-cli |
kilocode-thinking | 共有プロキシ stream パス上の Kilo reasoning ラッパー。kilo/auto と未サポートのプロキシ reasoning ID では挿入 thinking をスキップします | kilocode |
moonshot-thinking | config + /think レベルからの Moonshot バイナリ native-thinking ペイロードマッピング | moonshot |
minimax-fast-mode | 共有 stream パス上の MiniMax fast-mode モデル書き換え | minimax, minimax-portal |
openai-responses-defaults | 共有ネイティブ OpenAI/Codex Responses ラッパー: attribution ヘッダー、/fast/serviceTier、テキスト詳細度、ネイティブ Codex Web 検索、reasoning-compat ペイロード整形、Responses コンテキスト管理 | openai |
openrouter-thinking | プロキシルート向けの OpenRouter reasoning ラッパー。未サポートモデル/auto のスキップは中央で処理されます | openrouter |
tool-stream-default-on | 明示的に無効化されない限り tool streaming を求める Z.AI のようなプロバイダー向けのデフォルト有効 tool_stream ラッパー | zai |
ファミリービルダーを支える SDK シーム
ファミリービルダーを支える SDK シーム
各ファミリービルダーは、同じパッケージからエクスポートされる下位レベルの公開ヘルパーから構成されています。プロバイダーが共通パターンから外れる必要がある場合に利用できます。
openclaw/plugin-sdk/provider-model-shared-ProviderReplayFamily、buildProviderReplayFamilyHooks(...)、および raw replay ビルダー(buildOpenAICompatibleReplayPolicy、buildAnthropicReplayPolicyForModel、buildGoogleGeminiReplayPolicy、buildHybridAnthropicOrOpenAIReplayPolicy)。Gemini replay ヘルパー(sanitizeGoogleGeminiReplayHistory、resolveTaggedReasoningOutputMode)と endpoint/model ヘルパー(resolveProviderEndpoint、normalizeProviderId、normalizeGooglePreviewModelId)もエクスポートします。openclaw/plugin-sdk/provider-stream-ProviderStreamFamily、buildProviderStreamFamilyHooks(...)、composeProviderStreamWrappers(...)に加え、共有 OpenAI/Codex ラッパー(createOpenAIAttributionHeadersWrapper、createOpenAIFastModeWrapper、createOpenAIServiceTierWrapper、createOpenAIResponsesContextManagementWrapper、createCodexNativeWebSearchWrapper)、DeepSeek V4 OpenAI 互換ラッパー(createDeepSeekV4OpenAICompatibleThinkingWrapper)、Anthropic Messages thinking prefill クリーンアップ(createAnthropicThinkingPrefillPayloadWrapper)、プレーンテキスト tool-call compat(createPlainTextToolCallCompatWrapper)、共有 proxy/provider ラッパー(createOpenRouterWrapper、createToolStreamWrapper、createMinimaxFastModeWrapper)。openclaw/plugin-sdk/provider-stream-shared- ホットなプロバイダーパス向けの軽量ペイロードおよびイベントラッパー。createOpenAICompatibleCompletionsThinkingOffWrapper、createPayloadPatchStreamWrapper、createPlainTextToolCallCompatWrapper、normalizeOpenAICompatibleReasoningPayload(...)、setQwenChatTemplateThinking(...)を含みます。openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily、buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai")、および基盤となるプロバイダースキーマヘルパー。
<think> / <final> プロンプトディレクティブを追加せずにネイティブ thought parts を消費できるよう、native reasoning 出力を使用する必要があります。最終的な JSON/text 応答を解析するテキスト専用の Gemini CLI 形式バックエンドは、共有の google-gemini タグ付き契約を維持できます。一部の stream ヘルパーは意図的にプロバイダー内に留められています。@openclaw/anthropic-provider は、Claude OAuth beta 処理と context1m ゲートをエンコードするため、wrapAnthropicProviderStream、resolveAnthropicBetas、resolveAnthropicFastMode、resolveAnthropicServiceTier、および下位レベルの Anthropic ラッパービルダーを独自の公開 api.ts / contract-api.ts シームに保持しています。xAI Plugin も同様に、ネイティブ xAI Responses 整形を独自の wrapStreamFn(/fast エイリアス、デフォルト tool_stream、未サポート strict-tool クリーンアップ、xAI 固有の reasoning-payload 削除)に保持しています。同じパッケージルートパターンは、@openclaw/openai-provider(プロバイダービルダー、デフォルトモデルヘルパー、realtime プロバイダービルダー)と @openclaw/openrouter-provider(プロバイダービルダーに加え、オンボーディング/config ヘルパー)も支えています。- トークン交換
- カスタムヘッダー
- ネイティブトランスポート ID
- Usage and billing
各推論呼び出しの前にトークン交換が必要なプロバイダーの場合:
Common provider hooks
Common provider hooks
OpenClaw はモデル/プロバイダー Plugin に対して、おおよそこの順序でフックを呼び出します。
ほとんどのプロバイダーが使うのは 2〜3 個だけです。これは完全な
ランタイムフォールバックの注記:
ProviderPlugin
契約ではありません。完全かつ現時点で正確なフック一覧とフォールバックの注記については、内部: プロバイダーランタイムフック を参照してください。
ProviderPlugin.capabilities や suppressBuiltInModel など、OpenClaw がもう呼び出さない互換性専用のプロバイダーフィールドは、ここには記載していません。| フック | 使用するタイミング |
|---|---|
catalog | モデルカタログまたはベース URL のデフォルト |
applyConfigDefaults | 設定の具体化中の、プロバイダー所有のグローバルデフォルト |
normalizeModelId | 検索前のレガシー/プレビューモデル ID エイリアスのクリーンアップ |
normalizeTransport | 汎用モデル組み立て前の、プロバイダーファミリーの api / baseUrl クリーンアップ |
normalizeConfig | models.providers.<id> 設定の正規化 |
applyNativeStreamingUsageCompat | 設定プロバイダー向けのネイティブストリーミング使用量互換の書き換え |
resolveConfigApiKey | プロバイダー所有の env マーカー認証解決 |
resolveSyntheticAuth | ローカル/セルフホスト、または設定に基づく合成認証 |
resolveExternalAuthProfiles | CLI/アプリ管理の認証情報に対して、プロバイダー所有の外部認証プロファイルを重ねる |
shouldDeferSyntheticProfileAuth | env/設定認証の背後にある合成保存プロファイルのプレースホルダーを下げる |
resolveDynamicModel | 任意の上流モデル ID を受け入れる |
prepareDynamicModel | 解決前の非同期メタデータ取得 |
normalizeResolvedModel | ランナー前のトランスポート書き換え |
normalizeToolSchemas | 登録前の、プロバイダー所有のツールスキーマクリーンアップ |
inspectToolSchemas | プロバイダー所有のツールスキーマ診断 |
resolveReasoningOutputMode | タグ付き reasoning 出力とネイティブ reasoning 出力の契約 |
prepareExtraParams | デフォルトのリクエストパラメーター |
createStreamFn | 完全カスタムの StreamFn トランスポート |
wrapStreamFn | 通常のストリーム経路上のカスタムヘッダー/本文ラッパー |
resolveTransportTurnState | ネイティブのターン単位ヘッダー/メタデータ |
resolveWebSocketSessionPolicy | ネイティブ WS セッションヘッダー/クールダウン |
formatApiKey | カスタムランタイムトークン形状 |
refreshOAuth | カスタム OAuth 更新 |
buildAuthDoctorHint | 認証修復ガイダンス |
matchesContextOverflowError | プロバイダー所有のオーバーフロー検出 |
classifyFailoverReason | プロバイダー所有のレート制限/過負荷分類 |
isCacheTtlEligible | プロンプトキャッシュ TTL のゲート |
buildMissingAuthMessage | カスタムの認証不足ヒント |
augmentModelCatalog | 合成の前方互換行(非推奨 - registerModelCatalogProvider を推奨) |
resolveThinkingProfile | モデル固有の /think オプションセット |
isBinaryThinking | バイナリ thinking のオン/オフ互換性(非推奨 - resolveThinkingProfile を推奨) |
supportsXHighThinking | xhigh reasoning サポート互換性(非推奨 - resolveThinkingProfile を推奨) |
resolveDefaultThinkingLevel | デフォルトの /think ポリシー互換性(非推奨 - resolveThinkingProfile を推奨) |
isModernModelRef | ライブ/スモークモデルのマッチング |
prepareRuntimeAuth | 推論前のトークン交換 |
resolveUsageAuth | カスタム使用量認証情報の解析 |
fetchUsageSnapshot | カスタム使用量エンドポイント |
createEmbeddingProvider | メモリ/検索向けの、プロバイダー所有 embedding アダプター |
buildReplayPolicy | カスタムのトランスクリプト再生/Compaction ポリシー |
sanitizeReplayHistory | 汎用クリーンアップ後のプロバイダー固有の再生書き換え |
validateReplayTurns | 埋め込みランナー前の厳格な再生ターン検証 |
onModelSelected | 選択後コールバック(例: テレメトリ) |
normalizeConfigはプロバイダー ID ごとに 1 つの所有 Plugin(まずバンドルプロバイダー、次に一致したランタイム Plugin)を解決し、そのフックだけを呼び出します。他のプロバイダーを横断してスキャンすることはありません。google/google-vertex/google-antigravityの設定エントリを正規化するのは Google 自身のnormalizeConfigフックであり、別個のコアフォールバックではありません。resolveConfigApiKeyは公開されている場合、プロバイダーフックを使用します。Amazon Bedrock は AWS env マーカー解決をそのプロバイダー Plugin に保持します。ランタイム認証自体は、auth: "aws-sdk"で設定されている場合、引き続き AWS SDK のデフォルトチェーンを使用します。resolveThinkingProfile(ctx)は、選択されたprovider、modelId、任意でマージされたreasoningカタログヒント、任意でマージされたモデルcompatファクトを受け取ります。compatは、プロバイダーの thinking UI/プロファイルを選択するためだけに使用してください。resolveSystemPromptContributionにより、プロバイダーはモデルファミリー向けにキャッシュを考慮したシステムプロンプトガイダンスを注入できます。その振る舞いが 1 つのプロバイダー/モデルファミリーに属し、安定キャッシュと動的キャッシュの分割を保持すべき場合は、レガシーな Plugin 全体のbefore_prompt_buildフックよりもこれを優先してください。
Add extra capabilities (optional)
ステップ 5: 追加機能を追加する
プロバイダー Plugin は、テキスト推論と並行して、embedding、音声、リアルタイム文字起こし、リアルタイム音声、メディア理解、画像生成、動画生成、Web 取得、Web 検索を登録できます。OpenClaw はこれを ハイブリッド機能 Plugin として分類します。これは企業 Plugin(ベンダーごとに 1 つの Plugin)に推奨されるパターンです。 内部: 機能の所有権 を参照してください。既存のapi.registerProvider(...) 呼び出しと並べて、各機能を register(api) 内で登録します。必要なタブだけを選択してください:- Speech (TTS)
- Realtime transcription
- リアルタイム音声
- メディア理解
- 埋め込み
- 画像と動画の生成
- Web 取得と検索
assertOkOrThrowProviderError(...) を使用してください。これにより Plugin 間で、上限付きのエラー本文読み取り、JSON エラー解析、リクエスト ID サフィックスを共有できます。テスト
ステップ 6: テスト
src/provider.test.ts
ClawHub に公開する
プロバイダー Plugin は、他の外部コード Plugin と同じ方法で公開します。clawhub skill publish <path> は、Plugin パッケージではなく Skills フォルダーを
公開するための別のコマンドです。ここでは使用しないでください。
ファイル構造
カタログ順序リファレンス
catalog.order は、組み込みプロバイダーに対してカタログがいつマージされるかを制御します。
| 順序 | タイミング | ユースケース |
|---|---|---|
simple | 最初のパス | 単純な API キーのプロバイダー |
profile | simple の後 | 認証プロファイルでゲートされるプロバイダー |
paired | profile の後 | 複数の関連エントリを合成する |
late | 最後のパス | 既存のプロバイダーを上書きする(衝突時に優先) |
次のステップ
- チャンネル Plugin - Plugin がチャンネルも提供する場合
- SDK ランタイム -
api.runtimeヘルパー(TTS、検索、サブエージェント) - SDK 概要 - 完全なサブパス import リファレンス
- Plugin 内部 - フックの詳細とバンドル例