チャネル設定

Task Plugin チャネルの作成

プラグインをインストールして有効化した後、 ModelRouter インスタンスで「チャネル」管理を開き、チャネルを追加します。

1. **Task Plugin（タスクプラグイン、タイプ 61）**を選択します。
2. 登録済みのプラグインを選択します。
3. アップストリームのBase URLとプラグインが要求する認証情報を入力します。
4. プラグインがサポートするモデルを選択し、利用可能なグループ、優先度、重みを設定します。
5. チャネルを保存し、関連モデルの価格を設定します。

チャネルは setting.task_plugin_key を介してプラグインにバインドされます。プラグインは利用可能な状態である必要があり、モデルはプラグインが実際に宣言した名前と一致している必要があります。チャネルのグループは、呼び出し元のユーザーまたはAPIキーの利用可能なグループとも一致している必要があります。

プラグイン管理はRoot操作によって行われます。管理者がプラグインチャネルをバインドするには、task_plugin:bind 権限および対応するチャネル管理権限が必要です。

別の ModelRouter ゲートウェイへの接続

上流も ModelRouter の場合は **ModelRouter （タイプ 60）**を選び、上流ゲートウェイの URL と API キーを設定して、new_api 上流に対応するプラグインを紐付けます。両側で同じプラグインを導入・有効化し、必要な契約に対応するバージョンを使います。meta.upstreams に new_api を宣言しないプラグインは紐付けできません。

タイプ 60 は setting.task_extend_plugin_keys による複数プラグインに対応し、setting.task_plugin_key も利用できます。同じモデルに複数の紐付け済みプラグインが対応する場合、キーの昇順で最初の適格な候補を実行します。ホストは上流ゲートウェイキーを Bearer 形式で送信し、プラグインは ctx.upstream.kind に応じたネイティブパスを構築します。ベンダーの API キーや OAuth 資格情報を上流ゲートウェイキーとして使わないでください。

Base URL の意味

Base URL はアップストリームサービスのアドレスであり、plugin.js のダウンロードアドレスではありません。 インストールアドレスはコードのインポートに使用され、チャネルアドレスは実際の生成リクエストの開始に使用されます。

プラグインのデフォルトアドレスはタイプ 61 のチャネルにのみ使用されます。既存のチャネルタイプは、引き続き各タイプのアドレス設定ルールに従います。

認証と許可されたホスト

プラグインのドキュメントに従ってAPIキーまたは対応する認証設定を入力します。プラグインによって認証方式が異なる場合があります。meta.auth はAPIキー、認証なし、またはホスト管理のOAuth認証方式を宣言できます。OAuthクレデンシャルの解析はホストが担当します。

デフォルトでは、チャネルのBase URLが存在するホストへのアクセスが許可されます。他のホストにリクエストする必要がある場合、プラグインは meta.allowedHosts で追加の host または host:port を宣言する必要があります。このリストはプロトコル、パス、またはクエリパラメータを受け入れません。

モデルとモデルマッピング

まず、プラグインマーケットの詳細からサポートされているモデルを確認し、その後チャネルモデルリストを設定します。プラグインがプロトコルまたはネイティブルートを宣言する場合、特定の入口に対してモデルの範囲をさらに制限する可能性があります。

チャネルモデルマッピングを使用する場合、プラグインは2つのモデル識別子を受け取ります。

• ctx.model：ユーザーがリクエストしたモデル名で、課金および外部表示に使用され、エイリアスである可能性があります。
• ctx.upstreamModel：マッピングされたアップストリームモデル名です。アップストリームへのリクエストやモデル使用量設定の選択時にこの値を使用します。マッピングされていない場合は元のモデルと同じです。

プラグインを開発する際、通常は ctx.upstreamModel || ctx.model を使用してアップストリームのボディを構築します。リクエストディスクリプタの最上位にある model をアップストリーム名に安易に変更してはなりません。

使用量 profile は ctx.upstreamModel を優先し、一致しなければ ctx.model、さらにプラグインの既定スキーマへフォールバックします。ベンダーのエンドポイント ID にマッピングしても、クライアント側モデルの使用量設定は維持されます。

既存のチャネルタイプと共有モデル

一部の公式プラグインは、meta.channelTypes を介してOpenAI、Gemini、またはベンダー固有のタイプなどの既存のチャネルタイプをサポートしています。そのサポート範囲はマーケットの詳細に基づき、既存のチャネルをすべてタイプ 61 に変更する必要はありません。

同じ旧チャネルタイプは1つのプラグインのみが所有できます。競合は有効化時にチェックされます。複数のプラグインが同じホストプロトコル上で同じモデルを宣言できますが、最終的にどのプラグインを使用するかは選択されたチャネルによって決定されます。旧チャネルはチャネルタイプに基づき、タイプ 61 チャネルはプラグインキーに基づきます。

共有モデルであっても、使用量フィールドや価格が同じであるとは限りません。各プラグインに対応する課金設定を確認する必要があります。

設定後の検証

このグループとモデルにアクセスできるAPIキーを使用し、呼び出しガイドに従って小規模なテストを一度実行し、タスクの作成、ステータスの照会、成果物の読み取りがすべて期待通りであることを確認し、その後タスクログのモデルと使用量を確認します。