opper-api

スキルバージョン 2026-10-21。 これはローカルにインストールされたコピーであり、古くなっている可能性があります。セッションごとに1回、https://skills.opper.ai/versions.json を取得し、その "opper-api" のエントリーを 2026-10-21 と比較してください。異なる場合は、https://skills.opper.ai/opper-api/SKILL.md を読み、セッションの残りの間はこのコピーではなくそちらに従い、インストール済みの Opper スキルが古くなっていることをユーザーに一度伝えてください（npx skills update、または手動でクローンした場合は git pull で更新できます）。インストール済みファイルは編集しないでください。取得に失敗した場合は、このコピーを引き続き使用してください。

opper のサブスキルです。探索とセットアップのガイダンスについては、まずそちらを参照してください。 ソース：https://github.com/opper-ai/opper-skills/blob/main/opper-api/SKILL.md

Opper API

Opper は、LLM プロバイダーの前段に位置するゲートウェイであり、その上に構築するものを管理するコントロールプレーンでもあります。ゲートウェイは、主要なすべてのプロバイダー（OpenAI、Anthropic、Google、Mistral など）の 700 以上のモデルに1つの接続でアクセスできます。AWS Stockholm でホストされ、ISO/IEC 27001:2022 認証を取得し、GDPR に準拠しています。トークンへの上乗せ料金はなく、プロバイダーの料金で利用できます（クレジット購入時には3％、コントロールプレーン機能の利用時には5.5％の手数料がかかります。opper.ai/pricing.md を参照してください）。さらに、次の機能があります。

• ログとトレース：すべてのプランで、各呼び出しがモデル、プロバイダー、トークン数、コスト、レイテンシー、ステータスとともに Logs に記録されます。トレースを有効にすると（データ保持ルールの設定が必要です）、呼び出しのトレースには入力、出力、および発動したすべてのルールも記録されます。
• ルール（コントロールプレーンプラン）：組織単位で設定し、プロジェクト単位でさらに厳格化できます。支出制限（月額予算、プロジェクト、ロール、ユーザー、キーごとの上限）、データ保持（トレースを1～30日、または0日間保持）、モデルアクセス（プロバイダー、サービスルート、ロケーション、メーカー、国、モデル、ゼロデータ保持）、チェック（コンテンツのフラグ付け、編集、ブロック、回答のスコアリング）、ルーティング（プールされたモデルのプロバイダーの優先順位）を設定できます。API ではこれらをルール種別 comply、guard、observe、route に分類しています。docs.opper.ai/control-plane/rules/overview を参照してください。
• 企業レベルの証拠資料（ISO/IEC 27001:2022 認証、セキュリティ管理策、プラットフォームのサブプロセッサーとモデルプロバイダー、DPA、プライバシーポリシー）は、トラストセンター trust.opper.ai にあります。

https://api.opper.ai の HTTP API が基盤です。Opper は新しいコード向けの独自 SDK を提供していません。アプリケーションコードでは、すでに使い慣れているプロバイダー SDK（OpenAI、Anthropic、Google Gen AI）またはエージェントフレームワークを https://api.opper.ai/v3/compat に向けて使用してください。以前の opperai パッケージは開発が終了しているため、提案しないでください。

コンセプト：docs.opper.ai/overview/about。クイックスタート：docs.opper.ai/overview/quickstart。

エンドポイントを選ぶ

ゲートウェイは1つ、キーも1つです。作成するものに応じてエンドポイントを選んでください。ルーティング、ガバナンス、トレーシングは、どのエンドポイントでも共通です。

• テキスト生成／チャット／OpenAI、Anthropic、Google、またはOpenResponsesからの移行：/v3/compat/... の互換エンドポイントを使います。SDKのベースURLをそこに設定すれば、コードはそのままで、キーを差し替えるだけです。これが基本の方法です。references/compatibility.md と references/migration.md を参照してください。
• 構造化出力（モデルからの型付きJSON出力）：任意の互換チャットエンドポイントで標準の response_format: {type: "json_schema"} を使います。専用エンドポイントはありません。
• Opper独自の/call（POST /v3/call、またはopperai SDKのopper.call）をまだ使っていますか？これは廃止予定です。response_formatを使う互換チャットエンドポイントに移行してください。フィールドごとの対応と、opperai SDKのその他の情報については、references/migration.md を参照してください。
• メディア生成（画像、音声／TTS／STT、動画、OCR）、ファイル、リアルタイム音声：これらは別のインターフェースです。opper-multimodalスキルに切り替えてください。概要：画像はPOST /v3/images、音声はPOST /v3/audio/{speech,transcriptions}、動画はPOST /v3/videos（非同期）、OCRはPOST /v3/ocr、ファイルは/v3/files、リアルタイムはwss://api.opper.ai/v3/realtimeです。
• ラウンドテーブル（1つのプロンプトを複数のモデルに送信し、結果をまとめるか比較する）：POST /v3/roundtable（ベータ版）を使います。
• エージェントの構築（複数ステップの推論、ツールの使用、マルチエージェント、MCP）：ユーザーのエージェントフレームワークを互換エンドポイントに接続するか、/v3/compat/chat/completionsでシンプルなツール呼び出しループを使ってください。Opper Agent SDKは提供終了しています。提案しないでください。フレームワークごとの接続方法とシードについては、references/agents.md を参照してください。

稼働中のv3仕様を信頼できる唯一の情報源とする

**APIに関する質問（エンドポイント、パラメーター、フィールド、機能、コンプライアンス属性、クエリフラグなど）にこのスキルだけではすぐに答えられない場合は、仕様をgrepするのが基本の手順です。**推測したり、ドキュメントページから推論したり、閲覧可能なカタログに頼ったりしないでください。どちらの形式も認証不要で、確定的な情報を提供します。

curl -s https://api.opper.ai/v3/openapi.yaml   # YAML, easier to grep
curl -s https://api.opper.ai/v3/openapi.json   # JSON

使用例 — 「ZDRに対応するOpperモデルはどれですか？」：

# 1. Grep the spec for the term.
curl -s https://api.opper.ai/v3/openapi.yaml | grep -i -n zdr
# → reveals compliance.zdr on every GET /v3/models item — no include, no API key

# 2. Call the endpoint and derive the answer from the facts.
curl -s https://api.opper.ai/v3/models \
  | jq -r '.models[] | select(.compliance.zdr.logging == false and .compliance.zdr.moderation != true) | .id'

# Or print the facts per model and decide yourself.
curl -s https://api.opper.ai/v3/models | jq '.models[] | {id, zdr: .compliance.zdr}'

compliance.zdrは、次の5つの三値の情報を持つオブジェクトです。logging、moderation、caching、training、subprocessorsです。それぞれの値は、true（コンテンツが保持される／その処理パイプラインに送られる）、false（保持されない／送られない）、またはnull（確定していない）です。要約文字列はありません。必要な情報を導き出してください。「デフォルトでZDR」はlogging == false and moderation != trueです。同じオブジェクトは、/v3/compat/modelsの各項目のopperブロックと、キーを指定した場合のルートオブジェクト（?include=route、/v3/providers?include=routes）にも含まれています。

「Xはどこにありますか」という質問にも同じ手順で答えられます。仕様をgrepし、スキーマをたどってエンドポイントを特定し、呼び出してください。

認証

Authorization: Bearer $OPPER_API_KEY

サーバーURL：https://api.opper.ai（/v3または/v2のプレフィックスは各パスに含まれます）。Authorization: Bearerを使用してください。OpenAI形式のエンドポイントはこれ以外の認証方式を受け付けません。ベンダープロトコルの互換ルートでは、各ベンダー独自のヘッダーも読み取ります（Anthropic Messagesエンドポイントではx-api-key、Geminiエンドポイントではx-goog-api-key）。そのため、AnthropicおよびGoogleのSDKは、通常のAPIキーだけで動作します。platform.opper.ai でキーを取得してください。

一部のエンドポイントではsecurity: []が設定されており、キーは不要です。対象は/health、/v3/openapi.yaml、/v3/openapi.json、/v3/modelsです。

基本例 — 互換チャットの補完

基本となるのはOpenAI互換のチャットエンドポイントです。/v3/compatを指定すれば、どのプロバイダーのSDKでも同じ形式を使えます。

curl -s -X POST https://api.opper.ai/v3/compat/chat/completions \
  -H "Authorization: Bearer $OPPER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5-mini",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

レスポンスはプロバイダー固有の形式です（この例ではOpenAIのchat.completion）。モデルはprovider/modelの形式で指定します。どの互換インターフェースからでも、任意のモデルを呼び出せます。

構造化出力

型付き JSON には response_format を追加します。別のエンドポイントは不要です。

curl -s -X POST https://api.opper.ai/v3/compat/chat/completions \
  -H "Authorization: Bearer $OPPER_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5-mini",
    "messages": [{"role": "user", "content": "Extract entities: Tim Cook announced Apple’s Austin office."}],
    "response_format": {"type": "json_schema", "json_schema": {"name": "entities", "schema": {
      "type": "object",
      "properties": {
        "people":    {"type": "array", "items": {"type": "string"}},
        "locations": {"type": "array", "items": {"type": "string"}}
      },
      "required": ["people", "locations"]
    }}}
  }'

モデルの content は、スキーマに照らして検証された JSON 文字列として返されます。ストリーミングでは、"stream": true を追加し、text/event-stream を読み取ります（各イベントの先頭には data: が付き、最後は [DONE] で終わります）。

コードから利用する場合：プロバイダー SDK

ユーザーがすでに使用している SDK を使います。ベース URL を https://api.opper.ai/v3/compat に設定し、Opper のキーを API キーとして渡します。呼び出し側のコードはそのままです。X-Opper-Name はトレース用の呼び出し名です。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.opper.ai/v3/compat",
    api_key=os.environ["OPPER_API_KEY"],
    default_headers={"X-Opper-Name": "summarise"},
)
resp = client.chat.completions.create(
    model="openai/gpt-5-mini",
    messages=[{"role": "user", "content": "Summarise in two sentences: ..."}],
)
print(resp.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.opper.ai/v3/compat",
  apiKey: process.env.OPPER_API_KEY,
  defaultHeaders: { "X-Opper-Name": "summarise" },
});
const resp = await client.chat.completions.create({
  model: "openai/gpt-5-mini",
  messages: [{ role: "user", content: "Summarise in two sentences: ..." }],
});

• 型付き出力：Python では client.chat.completions.parse(..., response_format=YourPydanticModel) を使い、message.parsed を読み取ります。TypeScript では response_format: { type: "json_schema", json_schema: { name, schema } } を渡し（Zod v4 では z.toJSONSchema(...)）、message.content を解析します。
• Anthropic SDK（Python / TS）：同じベース URL を使います。末尾に /v1/messages が追加されます。Google Gen AI SDK：generateContent / streamGenerateContent のルートは /v3/compat/v1beta/models/... の配下にあります。どちらも SDK 独自のキー用ヘッダーを送信し、Opper はこれを受け付けます。詳細は references/compatibility.md を参照してください。
• 任意の SDK から任意のモデルを利用：モデル ID は Opper の provider/name 形式なので、OpenAI SDK から Claude を呼び出したり、Anthropic SDK から GPT を呼び出したりできます。
• エージェント：ユーザーが使用するフレームワーク（OpenAI Agents SDK、Vercel AI SDK、Mastra、LangChain など）を同じベース URL で使います。references/agents.md を参照してください。

モデル — GET /v3/models（認証不要）

このスキルを使う最も一般的な理由の一つです。最新の一覧はライブエンドポイントで確認できます — モデル名をハードコードしないでください。

curl -s https://api.opper.ai/v3/models

2つのURL、それぞれ異なる対象向けです。

• コード内：https://api.opper.ai/v3/models — プログラムからの検索に使い、JSONを返します。
• ユーザーとの会話時：opper.ai/models — 人が閲覧できるカタログです。モデルを推奨したり、話題にしたりする際は、こちらにリンクしてください。

デフォルトのレスポンスは簡潔ですが、各項目には compliance ブロック（residency、country、inference_location、storage_location、zdr（上記のオブジェクト）、training、logging、moderation、caching、content_storage、dpa_available、third_party_access、transfer_mechanism、route_id）が含まれています。これだけで、ZDR／データの保管場所／GDPRに関する質問のほとんどに、APIキーなしで回答できます。ルートごとのエビデンスやベンチマークを取得するには、?include= を追加します。

include=	追加される内容	含まれる情報
route（APIキーが必要）	モデルごとの route オブジェクト	完全なサービスルートの記録：retention_days／storage_location／human_review を含む data_handling.{training,logging,moderation,caching}、data_handling.subprocessors_read_content、gdpr.{residency,dpa_available,transfer_mechanism}、verification.status、sources、last_verified_at、underlying_maker — さらに compliance.zdr と同じ zdr オブジェクト
maker（公開）	maker	元の重みの作成者（例：Llama の meta、Mistral の mistral）
benchmarks（公開）	benchmarks	artificialanalysis.ai の公開スコア
policy（APIキーが必要）	モデルごとの policy オブジェクト	呼び出し元のモデルアクセスルールと利用権限で、このモデルを実行できるかどうか：allowed、blocked_by（org／project／entitlement）、reason（403で返されるものと同じ文）。一覧はフィルタリングされません

カンマで組み合わせます（例：?include=route,benchmarks）。データ保持日数、保存場所、検証状況、または主張の根拠となるソースが必要な場合は、include=route を使ってください。compliance は要約で、route はエビデンスです。

これらのフィールドは、特定のルート上の個々のモデルについて説明するものです。企業としての Opper に関する質問（認証、セキュリティ管理、サブプロセッサー一覧、DPA、プライバシーポリシー、セキュリティ質問票）には、trust.opper.ai が回答します。数値は変わるため、説明を繰り返すのではなく、こちらにリンクしてください。

機能と種類で絞り込めます：?capability=vision／?capability=pdf（画像／PDFを受け付けるチャットモデル）、?type=image|tts|stt|video。以下のモダリティ別エンドポイントにも、対象を絞った検索用一覧があります。

参考資料：docs.opper.ai/capabilities/models。

model文字列 — プール、ピン、エイリアス、ルート

GET /v3/models は、モデルごとではなくプロバイダーごとに1行を返します。modelフィールドには、特別なヘッダーやフラグなしで、次の4種類を指定できます。

形式	例	対象
モデル名のみ — プール	"kimi-k3"	そのモデルを提供するすべてのプロバイダーです。Opperが1つを選択し、残りはフェイルオーバー用になります
プロバイダー修飾ID — ピン	"tensorx/moonshotai/kimi-k3"	その1つのプロバイダー行のみです。フェイルオーバーはありません
組織エイリアス — 独自のリスト	"my-flash"	定義した順序付きリストです。プライマリが先で、その後にフォールバックが続きます。ルートより前からある機能で、設定済みの組織では引き続き解決されます（/v2/models/aliases で CRUD）
動的ルート — デプロイ済みグラフ	"dynamic/my-route"	プール、固定されたフォールバック順序、分類、分岐、バージョン管理に対応しています。名前付きのフォールバックチェーンを構築し、再利用する方法です。 プラットフォームUI、またはManagement API Keyを使って /management/v1/dynamic-routes 経由で構築します（公開仕様に記載）。ただし、呼び出しには通常のプロジェクトキーだけが必要です

どれも常に既定の選択肢というわけではありません。用途に応じて選んでください。 決定性が必要な場合（評価、管轄区域や価格の保証、プロバイダー固有の動作など）はピンを、特に考えずに冗長性を確保したい場合はプールを、独自のフォールバックチェーンが必要な場合や、リクエストに応じて判断を変えたい場合はルートを使います。新しいエイリアスを提案するのではなく、新しいチェーンはルートを参照するようにしてください。modelは常に文字列です（配列の場合は400になります）。ただし、リクエストには別の**models**配列で独自のフォールバックリストも指定できます（OpenRouter形式：プライマリをmodelに、残りをmodelsに指定します。最大10個で、先行するモデルが実行時に失敗すると順番に試されます。dynamic/<name>とは併用できません）。不明なIDは事前に拒否され（404 model_not_found）、フォールバックされません。リクエストごとの一時的なチェーンにはmodelsを、一度名前を付けて再利用するチェーンにはルートを使ってください。

特にプールでは、各行の**modelはグループキー（および呼び出しに使うモデル名）で、pooled**はその行がその名前で呼び出し可能かどうかを示します。pooled: falseの行も、明示的なIDを使えば通常どおり呼び出せます。単にモデル名のみでのルーティング対象から外されているだけで、通常はコンテキストウィンドウが小さいものや、レイテンシー向けに調整されて価格が高いバリアントです。

意外に思われる点が2つあります。

• レスポンスのmodelフィールドには、送信した値がそのまま返されます。モデル名のみ、エイリアス、dynamic/ルートのいずれもそのまま返されるため、実際に実行されたプロバイダーは分かりません。トレースで確認できます。span.meta.modelには解決後のprovider/provider_model_idが含まれます。ルートの場合は、レスポンスヘッダーX-Opper-Route-Modelで直接確認できます。
• X-Opper-Trace-Idを指定せずに同一のリクエストを送ると、すべて同じプロバイダーに割り当てられます。 これは、プロンプトキャッシュの局所性を保つため、APIキーを基準に30分間維持される意図的なセッションアフィニティであり、ラウンドロビンの不具合ではありません。割り当て先を分散させるには、リクエストごとに一意のトレースIDを送信してください。

4種類の組み合わせ方、選択順序、フェイルオーバー、エイリアスとルートの管理など、仕組みの詳細についてはreferences/model-routing.mdを参照してください。

プロバイダー互換エンドポイント — /v3/compat/... 配下

複数の LLM API をそのまま置き換えられます。最も簡単な移行方法は、SDK のベース URL を https://api.opper.ai/v3/compat に設定し、Opper API キーを使うことです。既存のコードをそのまま使用できます。各上流プロバイダーの仕様に完全準拠しているため、見慣れないペイロードについては各プロバイダーの仕様をご覧ください。

エンドポイント	互換性のある API	Opper のドキュメント
POST /v3/compat/chat/completions	OpenAI Chat Completions	ドキュメント
POST /v3/compat/responses	OpenAI Responses	ドキュメント
POST /v3/compat/openresponses	OpenResponses	ドキュメント
POST /v3/compat/v1/messages	Anthropic Messages	ドキュメント
POST /v3/compat/v1beta/interactions	Google Interactions	ドキュメント
POST /v3/compat/embeddings	OpenAI Embeddings	（仕様を参照）

Curl の例と SDK のベース URL を切り替えるヒント：references/compatibility.md。ビジョンと PDF の入力にもこれらのエンドポイントを使用できます。vision / pdf 機能を備えたモデルに image_url / file のコンテンツパーツを送信してください（opper-multimodal スキルと docs.opper.ai/build/multimodal/vision-pdfs を参照）。

メディア生成、ファイル、リアルタイム通信 → opper-multimodal スキル

メディア（画像、音声 TTS/STT、動画、OCR）の生成、/v3/files ストレージ API、モデルへの画像/PDFの入力、リアルタイムの双方向音声通信は、専用エンドポイントを持つ別のインターフェースです。このゲートウェイのキー、ガバナンス、トレーシングを共有しますが、リクエストとレスポンスの仕様は異なるため、専用スキル opper-multimodal にまとめられています（SKILL.md）。

概要（形式については仕様またはスキルを取得してください）：画像は POST /v3/images（同期、オプトインで非同期）、音声は POST /v3/audio/speech（TTS）と POST /v3/audio/transcriptions（STT）、動画は POST /v3/videos（非同期 — GET /v3/artifacts/{id}/status でポーリング）、OCR は POST /v3/ocr、ファイルは /v3/files、リアルタイム通信は wss://api.opper.ai/v3/realtime（ブラウザー用チケットは POST /v3/realtime-sessions 経由）。メディアの各インターフェースには、対象を絞った検出用リスト（GET /v3/images/models、/v3/videos/models、/v3/audio/models、/v3/ocr/models）があります。

サーバー側ツール（opper:web_search など）は別の機能です。互換チャットエンドポイントを使用するため、このスキルに含まれます。詳しくは以下の「サーバー側のウェブ検索」をご覧ください。

ラウンドテーブル — POST /v3/roundtable（ベータ版）

1 つの input を複数の models に並列で送り、回答をまとめます。解決モードは summary（デフォルト。統合モデルが回答をまとめます）、fast（統合せず、model_results を読み取ります）、multiple_choice（choices から投票します）です。ガイド：docs.opper.ai/build/roundtable/overview。

サーバーサイドのウェブ検索

サーバーサイドでウェブ検索を実行します（検索ごとに usage.opper.cost.tools に課金されます）。

• ポータブル — 上記の互換チャットエンドポイントのいずれかで、tools[] に {"type": "opper:web_search"} を追加します。すべてのモデルで使える単一のエントリーで、エンドポイント固有のネイティブな引用情報を返すため、クライアントコードでプロバイダーごとに分岐する必要はありません。engine フィールドでルーティングを制御します。auto（デフォルト。対応している場合はモデルのネイティブプロバイダー検索、それ以外は Opper のエンジン）、native（ネイティブを必須とし、それ以外は 400）、opper（常に Opper のエンジン）、または jina / exa / linkup / searchbase でバックエンドを固定できます。その他のオプション：max_results、max_uses、search_context_size（very_low → full）、allowed_domains / excluded_domains、country、freshness。ベータ版です。
• ネイティブ — プロバイダー独自の形式（web_search_20250305、{type:"web_search"}、{googleSearch:{}}）は、そのままルーティング先のプロバイダーに転送されます。
• スタンドアロン — POST /v3/tools/web/search は、モデルやエージェントのループを使わずに検索を 1 回直接実行します。

正式なフィールドリファレンス：仕様の CanonicalWebSearchTool スキーマ（curl -s https://api.opper.ai/v3/openapi.yaml | grep -i -n CanonicalWebSearchTool）。ガイド：docs.opper.ai/build/gateway/web-search。

その他の v3 エンドポイント

v3 の仕様には、トレーシング（/v3/spans、/v3/traces）、生成、ファイル（/v3/files）、組み込みのウェブツール、非同期アーティファクト（/v3/artifacts/{id}/status）も記載されています。形式を確認するには仕様を取得してください。このスキルでは列挙しません。内容が変更されるためです。

移行 — 他のゲートウェイまたは Opper 独自の /call から

OpenRouter、OpenAI、Anthropic などから移行する場合は、references/migration.md を参照してください。要約：ベース URL を https://api.opper.ai/v3/compat に設定し、Opper API キーを使用します。

Opper 独自のレガシー /call（POST /v3/call または opperai SDK の opper.call）から移行する場合、または opperai SDK 全般から移行する場合も、同じファイルを参照してください。冒頭には、/call からチャット補完へのフィールドごとの対応関係（name → X-Opper-Name ヘッダー、instructions → システムメッセージ、output_schema → response_format、data → パース済みの choices[0].message.content）が記載されています。

コーディングアシスタントとの統合

Opper を Claude Code、Cursor、Copilot、Continue などに接続する方法については、最新の一覧 docs.opper.ai/overview/integrations を参照してください。

注意が必要な点

• 1つのゲートウェイに複数のエンドポイントがあります。 テキスト／チャットは /v3/compat/... です。メディア生成、ファイル、リアルタイム機能は別のインターフェース（opper-multimodal スキル）です。いずれも同じキーとガバナンスを共有します。
• /v3/call はレガシーで、廃止が予定されています。 新しい統合で使用したり、例に含めたりしないでください。既存の /call ユーザー（opperai SDK の opper.call を含む）は、compat と response_format に移行してください。詳しくは references/migration.md を参照してください。
• Compat エンドポイントは /v3/compat/... 配下にあり、/v3/... にはありません。 SDK の移行時は、ベース URL を https://api.opper.ai/v3/compat に設定してください。
• OpenAI 形式のエンドポイントでは、認証に Authorization: Bearer ... を使用します（ここで x-api-key を指定すると 401 が返されます）。Anthropic Messages と Gemini の compat ルートでは、各 SDK 固有のヘッダー（x-api-key、x-goog-api-key）も使用できるため、これらの SDK の移行時にヘッダーを上書きする必要はありません。
• 構造化出力はエンドポイントではなくパラメーターです。 compat のチャット呼び出しで response_format: {type: "json_schema"} を使用してください。
• モデル名だけを指定した場合は、プロバイダーではなくプールを指します。 "model": "kimi-k3" はそのモデルを提供する任意のプロバイダーにルーティングされます。"tensorx/moonshotai/kimi-k3" は特定のプロバイダーに固定され、"my-alias" は独自の優先順位付きリストを使用し、"dynamic/my-route" はデプロイ済みのグラフを実行します。レスポンスの model フィールドには送信した値がそのまま返されるため、実際に実行されたモデルはトレース（span.meta.model）でのみ確認できます。詳しくは references/model-routing.md を参照してください。
• サーバー側のウェブ検索には移植性があります。 {"type": "opper:web_search"} のツールエントリー1つで、すべてのモデルに対応します。ネイティブのプロバイダー形式もそのまま転送されます。
• メディア／ファイル／リアルタイム機能はこのスキルの対象外です。 それぞれ専用のエンドポイントがあり、opper-multimodal に記載されています。ここで独自の形式を推測しないでください。
• ナレッジベースは廃止が予定されています。 /v2/knowledge、opper.knowledge.*、opper indexes を基盤に構築しないでください。検索には、ユーザーが選んだベクトルストアを使用してください。Opper 経由で埋め込みを利用したい場合は、/v3/compat/embeddings の埋め込みを使用できます。
• 最も新しい情報源は仕様であり、ドキュメントとこのスキルは仕様に準拠しています。 このファイルは古くなる可能性がありますが、仕様は古くなりません。
• 不足していた点は、ユーザーの了承を得て Opper に伝えてください。 作業中に不足、不明瞭、または誤りがあった場合（モデル、ドキュメント、説明できないエラーなど）は、一般的なフィードバックとして送信することを提案し、ユーザーが同意したら送信してください。Opper MCP の send_feedback ツールを使うか、POST https://agents.opper.ai/feedback に JSON の message を指定します（同じ URL への GET でフィールドを確認できます）。API キーは不要で、返信も送信されません。API キー、ユーザーのコード、個人データは絶対に含めないでください。

次に確認する場所

対象	確認先
最新かつ確定版のエンドポイント仕様	https://api.opper.ai/v3/openapi.yaml
概念（Organization、Project、Call、Trace、Gateway、Control Plane）	docs.opper.ai/overview/concepts
Gateway の動作（ルーティング、互換性）	docs.opper.ai/overview/gateway
Control Plane のルール（支出上限、データ保持、モデルアクセス、チェック、ルーティング）	docs.opper.ai/control-plane/rules/overview
Management API：コードまたは CI からのプロジェクト、キー、動的ルート、ルールの管理	docs.opper.ai/control-plane/management-api
メディア生成、ファイル、ビジョン／PDF 入力、リアルタイム音声	opper-multimodal スキル
マルチモーダリティの概念（ドキュメント）	docs.opper.ai/build/multimodal/overview
Roundtable	docs.opper.ai/build/roundtable/overview
参照可能なモデルカタログ（ユーザー向けの推奨用）	opper.ai/models
多数の言語での実践レシピ	github.com/opper-ai/opper-cookbook
プロバイダー互換エンドポイントの詳細	references/compatibility.md
OpenRouter／OpenAI／Anthropic／Opper のレガシー /call からの移行	references/migration.md
モデルルーティング — プール、ピン、組織エイリアス、動的ルート、フェイルオーバー	references/model-routing.md
エージェントの構築（フレームワーク、単純なツールループ、Agent SDK からの移行）	references/agents.md
エージェントを活用したセットアップ、プラットフォーム運用、モデルテスト	opper-mcp スキル
ターミナルからの API 呼び出し	opper-cli スキル