OpenClaw Plugin を初めて作成する場合は、まずパッケージ構造とマニフェストの設定について
はじめにを参照してください。
手順
1
パッケージとマニフェスト
ステップ 1:パッケージとマニフェスト
setup.providers[].envVars により、OpenClaw は Plugin ランタイムを読み込まずに
認証情報を検出できます。プロバイダーのバリアントで別のプロバイダー ID の認証を
再利用する場合は、providerAuthAliases を追加します。modelSupport は
任意です。これにより、ランタイムフックが存在する前でも、OpenClaw は
acme-large のような短縮モデル ID からプロバイダー Plugin を自動的に
読み込めます。package.json 内の openclaw.compat と
openclaw.build は、ClawHub への公開に必要です
(openclaw.compat.pluginApi と openclaw.build.openclawVersion が必須の 2 フィールドで、
minGatewayVersion を省略すると openclaw.install.minHostVersion が使用されます)。2
プロバイダーを登録する
最小構成のテキストプロバイダーには、プロバイダー 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 を選択できるようになります。ライブモデル検出
プロバイダーが OpenAI 互換の/models API を公開している場合は、
単一プロバイダー用ヘルパーで共有検出を有効にします。liveModelDiscovery: true は、次の動作を定めた公開 Plugin SDK 契約です。Bearer 以外の認証または非標準の一覧エンドポイントには、
true の代わりにオプションを渡します。endpointUrl を無条件の代替ホストとして使用しないでください。その
requireBaseUrl チェックは、モデル一覧のホストと推論ホストが異なる
プロバイダーにおける認証情報の分離境界です。保守的な OpenAI 互換の投影ではなく、プロバイダーにカスタムモデルセマンティクスが
必要な場合は、その投影を Plugin 内に保持し、共有フェッチの
ライフサイクルには openclaw/plugin-sdk/provider-catalog-live-runtime を使用してください。このヘルパーを使用すると、
プロバイダーのポリシーを OpenClaw コアに組み込むことなく、保護された 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 キー認証と単一のカタログベースのランタイムを持つテキストプロバイダーを 1 つだけ登録するバンドルプロバイダーでは、より限定的な defineSingleProviderPluginEntry(...) ヘルパーを優先してください。buildProvider は、OpenClaw が実際のプロバイダー認証を解決できる場合に使用されるライブカタログ経路です。プロバイダー固有の検出を実行する場合があります。認証の設定前に安全に表示できるオフライン行にのみ buildStaticProvider を使用してください。認証情報を要求したり、ネットワークリクエストを行ったりしてはなりません。OpenClaw の models list --all 表示は現在、空の設定、空の環境、エージェント/ワークスペースパスなしで、バンドルされたプロバイダー Plugin に対してのみ静的カタログを実行します。認証フローでオンボーディング中に models.providers.*、エイリアス、エージェントのデフォルトモデルも修正する必要がある場合は、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 をネットワーク非依存に保ってください。3
動的モデル解決を追加する
プロバイダーが任意のモデル ID(プロキシやルーターなど)を受け付ける場合は、解決にネットワーク呼び出しが必要な場合は、非同期のウォームアップに
resolveDynamicModel を追加します。prepareDynamicModel を使用します。完了後に resolveDynamicModel が再度実行されます。4
ランタイムフックを追加する(必要に応じて)
ほとんどのプロバイダーに必要なのは 現在利用可能なリプレイファミリー:
catalog と resolveDynamicModel だけです。プロバイダーの要件に応じて、フックを段階的に追加してください。共有ヘルパービルダーが、最も一般的なリプレイ/ツール互換ファミリーをカバーするようになったため、通常、Plugin で各フックを 1 つずつ手動接続する必要はありません。現在利用可能なストリームファミリー:
ファミリービルダーを支える SDK の接続面
ファミリービルダーを支える SDK の接続面
各ファミリービルダーは、同じパッケージからエクスポートされる低レベルの公開ヘルパーを組み合わせて構成されています。プロバイダーが共通パターンから外れる必要がある場合に利用できます。
openclaw/plugin-sdk/provider-model-shared-ProviderReplayFamily、buildProviderReplayFamilyHooks(...)、および未加工のリプレイビルダー(buildOpenAICompatibleReplayPolicy、buildAnthropicReplayPolicyForModel、buildGoogleGeminiReplayPolicy、buildHybridAnthropicOrOpenAIReplayPolicy)。Gemini リプレイヘルパー(sanitizeGoogleGeminiReplayHistory、resolveTaggedReasoningOutputMode)と、エンドポイント/モデルヘルパー(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 プリフィルのクリーンアップ(createAnthropicThinkingPrefillPayloadWrapper)、プレーンテキストのツール呼び出し互換機能(createPlainTextToolCallCompatWrapper)、共有プロキシ/プロバイダーラッパー(createOpenRouterWrapper、createToolStreamWrapper、createMinimaxFastModeWrapper)。openclaw/plugin-sdk/provider-stream-shared- ホットなプロバイダーパス向けの軽量なペイロードおよびイベントラッパー。createOpenAICompatibleCompletionsThinkingOffWrapper、createPayloadPatchStreamWrapper、createPlainTextToolCallCompatWrapper、normalizeOpenAICompatibleReasoningPayload(...)、setQwenChatTemplateThinking(...)を含みます。openclaw/plugin-sdk/provider-tools-ProviderToolCompatFamily、buildProviderToolCompatFamilyHooks("deepseek" | "gemini" | "openai")、および基盤となるプロバイダースキーマヘルパー。
native reasoning 出力を使用する必要があります。これにより OpenClaw は、
<think> / <final> プロンプトディレクティブを追加せずに、
ネイティブな thought パートを処理できます。最終的な JSON/テキスト応答を解析する、
テキスト専用の Gemini CLI 形式バックエンドでは、共有の
google-gemini タグ付き契約を維持できます。一部のストリームヘルパーは、意図的にプロバイダー内に留められています。@openclaw/anthropic-provider は、wrapAnthropicProviderStream、resolveAnthropicBetas、resolveAnthropicFastMode、resolveAnthropicServiceTier、および低レベルの Anthropic ラッパービルダーを、独自の公開 api.ts / contract-api.ts 接続面に保持しています。これらは Claude OAuth ベータ処理と context1m ゲーティングをエンコードするためです。同様に、xAI Plugin はネイティブ xAI Responses の整形を独自の wrapStreamFn に保持しています(/fast エイリアス、デフォルトの tool_stream、未対応の厳格ツールのクリーンアップ、xAI 固有の reasoning ペイロード削除)。同じパッケージルートパターンは、@openclaw/openai-provider(プロバイダービルダー、デフォルトモデルヘルパー、リアルタイムプロバイダービルダー)と @openclaw/openrouter-provider(プロバイダービルダーおよびオンボーディング/config ヘルパー)の基盤にもなっています。- トークン交換
- カスタムヘッダー
- ネイティブトランスポートの識別情報
- 使用量と請求
各推論呼び出しの前にトークン交換が必要なプロバイダー向けです。
共通のプロバイダーフック
共通のプロバイダーフック
OpenClaw は、モデル/プロバイダー Plugin に対して、おおよそ次の順序でフックを呼び出します。
ほとんどのプロバイダーが使用するのは 2〜3 個だけです。これは完全な
ProviderPlugin 契約ではありません。現在の正確なフック一覧と
フォールバックに関する注記については、内部構造:プロバイダーランタイム
フックを参照してください。
ProviderPlugin.capabilities や suppressBuiltInModel など、
OpenClaw が呼び出さなくなった互換性専用のプロバイダーフィールドは、
ここには記載していません。ランタイムのフォールバックに関する注記:
normalizeConfigは、プロバイダー ID ごとに所有する Plugin を 1 つ解決し(まずバンドル済みプロバイダー、次に一致したランタイム Plugin)、そのフックのみを呼び出します。他のプロバイダーを横断するスキャンはありません。Google 独自のnormalizeConfigフックがgoogle/google-vertex/google-antigravityの設定エントリを正規化します。これは独立したコアのフォールバックではありません。resolveConfigApiKeyは、公開されている場合にプロバイダーフックを使用します。Amazon Bedrock は AWS 環境マーカーの解決をそのプロバイダー Plugin 内に保持します。ランタイム認証自体は、auth: "aws-sdk"で設定されている場合も AWS SDK のデフォルトチェーンを使用します。resolveThinkingProfile(ctx)は、選択されたprovider、modelId、任意のマージ済みreasoningカタログヒント、および任意のマージ済みモデルcompat情報を受け取ります。compatは、プロバイダーの思考 UI/プロファイルを選択するためにのみ使用してください。resolveSystemPromptContributionを使用すると、プロバイダーはモデルファミリー向けにキャッシュを考慮したシステムプロンプトのガイダンスを注入できます。動作が 1 つのプロバイダー/モデルファミリーに属し、安定部分と動的部分のキャッシュ分割を維持すべき場合は、従来の Plugin 全体を対象とするbefore_prompt_buildフックよりもこちらを優先してください。
5
追加機能を加える(任意)
ステップ 5:追加機能を加える
プロバイダー Plugin は、テキスト推論に加えて、埋め込み、音声、リアルタイム文字起こし、 リアルタイム音声、メディア理解、画像生成、動画生成、 Web 取得、Web 検索を登録できます。OpenClaw はこれを ハイブリッド機能 Plugin として分類します。企業 Plugin に推奨されるパターン (ベンダーごとに 1 つの Plugin)です。以下を参照してください: 内部構造:機能の所有権。既存のapi.registerProvider(...) 呼び出しとともに、各機能を register(api)
内で登録します。必要なタブのみを選択してください:- 音声(TTS)
- リアルタイム文字起こし
- リアルタイム音声
- メディア理解
- 埋め込み
- 画像と動画の生成
- Web フェッチと検索
assertOkOrThrowProviderError(...) を使用してください。これにより
Plugin 間で、上限付きのエラー本文読み取り、JSON エラー解析、および
リクエスト ID のサフィックスを共有できます。6
テスト
ステップ 6:テスト
src/provider.test.ts
ClawHub に公開する
プロバイダー Plugin は、他の外部コード Plugin と同じ方法で公開します。clawhub skill publish <path> は Plugin パッケージではなく Skills フォルダーを公開するための
別のコマンドです。ここでは使用しないでください。
ファイル構造
カタログ順序のリファレンス
catalog.order は、組み込みプロバイダーに対してカタログがいつマージされるかを
制御します。
次のステップ
- チャンネル Plugin - Plugin がチャンネルも提供する場合
- SDK ランタイム -
api.runtimeヘルパー(TTS、検索、サブエージェント) - SDK の概要 - サブパスインポートの完全なリファレンス
- Plugin の内部構造 - フックの詳細とバンドルされた例