モデル

Agents SDK には、OpenAI モデルに対するすぐに使えるサポートが 2 種類あります。

• 推奨: 新しい Responses API を使用して OpenAI API を呼び出す OpenAIResponsesModel。
• Chat Completions API を使用して OpenAI API を呼び出す OpenAIChatCompletionsModel。

モデル設定の選択

設定に合う最もシンプルな方法から始めてください。

やりたいこと	推奨される方法	詳細
OpenAI モデルのみを使用する	デフォルトの OpenAI プロバイダーを Responses モデルの経路で使用する	OpenAI モデル
websocket トランスポート経由で OpenAI Responses API を使用する	Responses モデルの経路を維持し、websocket トランスポートを有効にする	Responses WebSocket トランスポート
1 つの非 OpenAI プロバイダーを使用する	組み込みのプロバイダー統合ポイントから始める	非 OpenAI モデル
エージェント間でモデルやプロバイダーを混在させる	実行ごと、またはエージェントごとにプロバイダーを選択し、機能の違いを確認する	1 つのワークフローでのモデルの混在 と プロバイダー間でのモデルの混在
高度な OpenAI Responses リクエスト設定を調整する	OpenAI Responses の経路で ModelSettings を使用する	高度な OpenAI Responses 設定
非 OpenAI または混在プロバイダーのルーティングにサードパーティアダプターを使用する	サポートされているベータ版アダプターを比較し、提供予定のプロバイダー経路を検証する	サードパーティアダプター

OpenAI モデル

ほとんどの OpenAI のみのアプリでは、デフォルトの OpenAI プロバイダーで文字列のモデル名を使用し、Responses モデルの経路に留まることを推奨します。

Agent の初期化時にモデルを指定しない場合、デフォルトモデルが使用されます。現在のデフォルトは、低レイテンシのエージェントワークフロー向けに、reasoning.effort="none" と verbosity="low" を設定した gpt-5.4-mini です。アクセス権がある場合は、明示的な model_settings を維持しつつ、より高い品質のためにエージェントを gpt-5.5 に設定することを推奨します。

gpt-5.5 のような他のモデルに切り替えたい場合、エージェントを設定する方法は 2 つあります。

デフォルトモデル

まず、カスタムモデルを設定していないすべてのエージェントで特定のモデルを一貫して使用したい場合は、エージェントを実行する前に OPENAI_DEFAULT_MODEL 環境変数を設定します。

export OPENAI_DEFAULT_MODEL=gpt-5.5
python3 my_awesome_agent.py

次に、RunConfig を使って実行のデフォルトモデルを設定できます。エージェントにモデルを設定していない場合、この実行のモデルが使用されます。

from agents import Agent, RunConfig, Runner

agent = Agent(
    name="Assistant",
    instructions="You're a helpful agent.",
)

result = await Runner.run(
    agent,
    "Hello",
    run_config=RunConfig(model="gpt-5.5"),
)

GPT-5 モデル

この方法で gpt-5.5 などの GPT-5 モデルを使用すると、SDK はデフォルトの ModelSettings を適用します。ほとんどのユースケースで最適に機能する設定が使用されます。デフォルトモデルの reasoning effort を調整するには、独自の ModelSettings を渡します。

from openai.types.shared import Reasoning
from agents import Agent, ModelSettings

my_agent = Agent(
    name="My Agent",
    instructions="You're a helpful agent.",
    # If OPENAI_DEFAULT_MODEL=gpt-5.5 is set, passing only model_settings works.
    # It's also fine to pass a GPT-5 model name explicitly:
    model="gpt-5.5",
    model_settings=ModelSettings(reasoning=Reasoning(effort="high"), verbosity="low")
)

より低いレイテンシのためには、GPT-5 モデルで reasoning.effort="none" を使用することを推奨します。

ComputerTool のモデル選択

エージェントに ComputerTool が含まれている場合、実際の Responses リクエストで有効なモデルにより、SDK が送信する computer-tool ペイロードが決まります。明示的な gpt-5.5 リクエストでは GA 組み込みの computer ツールが使用され、明示的な computer-use-preview リクエストでは古い computer_use_preview ペイロードが維持されます。

主な例外はプロンプト管理の呼び出しです。プロンプトテンプレートがモデルを所有し、SDK がリクエストから model を省略する場合、SDK はプロンプトがどのモデルに固定しているかを推測しないよう、プレビュー互換の computer ペイロードをデフォルトにします。このフローで GA 経路を維持するには、リクエストで model="gpt-5.5" を明示するか、ModelSettings(tool_choice="computer") または ModelSettings(tool_choice="computer_use") で GA セレクターを強制します。

登録済みの ComputerTool がある場合、tool_choice="computer"、"computer_use"、"computer_use_preview" は、有効なリクエストモデルに一致する組み込みセレクターへ正規化されます。ComputerTool が登録されていない場合、これらの文字列は通常の関数名のように振る舞い続けます。

プレビュー互換のリクエストでは environment と表示寸法を事前にシリアライズする必要があるため、ComputerProvider ファクトリーを使用するプロンプト管理フローでは、具体的な Computer または AsyncComputer インスタンスを渡すか、リクエスト送信前に GA セレクターを強制する必要があります。移行の詳細については Tools を参照してください。

非 GPT-5 モデル

カスタム model_settings なしで非 GPT-5 モデル名を渡すと、SDK は任意のモデルと互換性のある汎用の ModelSettings に戻します。

Responses のみのツール検索機能

次のツール機能は OpenAI Responses モデルでのみサポートされます。

• ToolSearchTool
• tool_namespace()
• @function_tool(defer_loading=True) およびその他の遅延読み込み Responses ツールサーフェス

これらの機能は、Chat Completions モデルおよび非 Responses バックエンドでは拒否されます。遅延読み込みツールを使用する場合は、エージェントに ToolSearchTool() を追加し、裸の名前空間名や遅延専用の関数名を強制するのではなく、auto または required のツール選択によってモデルにツールを読み込ませてください。設定の詳細と現在の制約については Tools を参照してください。

Responses WebSocket トランスポート

デフォルトでは、OpenAI Responses API リクエストは HTTP トランスポートを使用します。OpenAI バックのモデルを使用する場合、websocket トランスポートを選択できます。

基本設定

from agents import set_default_openai_responses_transport

set_default_openai_responses_transport("websocket")

これは、デフォルトの OpenAI プロバイダーによって解決される OpenAI Responses モデル（"gpt-5.5" などの文字列モデル名を含む）に影響します。

トランスポートの選択は、SDK がモデル名をモデルインスタンスに解決するときに行われます。具体的な Model オブジェクトを渡す場合、そのトランスポートはすでに固定されています。OpenAIResponsesWSModel は websocket を使用し、OpenAIResponsesModel は HTTP を使用し、OpenAIChatCompletionsModel は Chat Completions のままです。RunConfig(model_provider=...) を渡す場合、そのプロバイダーがグローバルデフォルトの代わりにトランスポート選択を制御します。

プロバイダーまたは実行レベルの設定

プロバイダーごと、または実行ごとに websocket トランスポートを設定することもできます。

from agents import Agent, OpenAIProvider, RunConfig, Runner

provider = OpenAIProvider(
    use_responses_websocket=True,
    # Optional; if omitted, OPENAI_WEBSOCKET_BASE_URL is used when set.
    websocket_base_url="wss://your-proxy.example/v1",
    # Optional low-level websocket keepalive settings.
    responses_websocket_options={"ping_interval": 20.0, "ping_timeout": 60.0},
)

agent = Agent(name="Assistant")
result = await Runner.run(
    agent,
    "Hello",
    run_config=RunConfig(model_provider=provider),
)

OpenAI バックのプロバイダーは、任意のエージェント登録設定も受け付けます。これは、OpenAI 設定が harness ID などのプロバイダーレベル登録メタデータを想定している場合の高度なオプションです。

from agents import (
    Agent,
    OpenAIAgentRegistrationConfig,
    OpenAIProvider,
    RunConfig,
    Runner,
)

provider = OpenAIProvider(
    use_responses_websocket=True,
    agent_registration=OpenAIAgentRegistrationConfig(harness_id="your-harness-id"),
)

agent = Agent(name="Assistant")
result = await Runner.run(
    agent,
    "Hello",
    run_config=RunConfig(model_provider=provider),
)

MultiProvider による高度なルーティング

プレフィックスベースのモデルルーティングが必要な場合（たとえば 1 つの実行で openai/... と any-llm/... のモデル名を混在させる場合）、MultiProvider を使用し、そこで openai_use_responses_websocket=True を設定します。

MultiProvider は 2 つの歴史的なデフォルトを維持しています。

• openai/... は OpenAI プロバイダーのエイリアスとして扱われるため、openai/gpt-4.1 はモデル gpt-4.1 としてルーティングされます。
• 不明なプレフィックスは、そのまま渡されるのではなく UserError を発生させます。

OpenAI 互換エンドポイントがリテラルな名前空間付きモデル ID を期待する場合、OpenAI プロバイダーをそのエンドポイントに向ける際は、パススルー動作を明示的に有効にしてください。websocket が有効な設定では、MultiProvider 上でも openai_use_responses_websocket=True を維持してください。

from agents import Agent, MultiProvider, RunConfig, Runner

provider = MultiProvider(
    openai_base_url="https://openrouter.ai/api/v1",
    openai_api_key="...",
    openai_use_responses_websocket=True,
    openai_prefix_mode="model_id",
    unknown_prefix_mode="model_id",
)

agent = Agent(
    name="Assistant",
    instructions="Be concise.",
    model="openai/gpt-4.1",
)

result = await Runner.run(
    agent,
    "Hello",
    run_config=RunConfig(model_provider=provider),
)

バックエンドがリテラルな openai/... 文字列を期待する場合は openai_prefix_mode="model_id" を使用します。バックエンドが openrouter/openai/gpt-4.1-mini など、他の名前空間付きモデル ID を期待する場合は unknown_prefix_mode="model_id" を使用します。これらのオプションは websocket トランスポート以外の MultiProvider でも機能します。この例では、このセクションで説明しているトランスポート設定の一部であるため、websocket を有効のままにしています。同じオプションは responses_websocket_session() でも利用できます。

MultiProvider 経由でルーティングしながら同じプロバイダーレベル登録メタデータが必要な場合は、openai_agent_registration=OpenAIAgentRegistrationConfig(...) を渡すと、基盤となる OpenAI プロバイダーに転送されます。

カスタム OpenAI 互換エンドポイントまたはプロキシを使用する場合、websocket トランスポートには互換性のある websocket /responses エンドポイントも必要です。そのような設定では、websocket_base_url を明示的に設定する必要がある場合があります。

注記

• これは websocket トランスポート経由の Responses API であり、Realtime API ではありません。Chat Completions や非 OpenAI プロバイダーには、Responses websocket /responses エンドポイントをサポートしていない限り適用されません。
• 環境でまだ利用できない場合は、websockets パッケージをインストールしてください。
• websocket トランスポートを有効にした後、Runner.run_streamed() を直接使用できます。複数ターンのワークフローで、同じ websocket 接続をターン間（およびネストされた agent-as-tool 呼び出し）で再利用したい場合は、responses_websocket_session() ヘルパーを推奨します。Running agents ガイドと examples/basic/stream_ws.py を参照してください。
• 長い reasoning ターンやレイテンシの急増があるネットワークでは、responses_websocket_options で websocket keepalive の動作をカスタマイズしてください。遅延した pong フレームを許容するには ping_timeout を増やすか、ping を有効にしたまま heartbeat タイムアウトを無効にするには ping_timeout=None を設定します。websocket レイテンシよりも信頼性が重要な場合は、HTTP/SSE トランスポートを優先してください。

非 OpenAI モデル

非 OpenAI プロバイダーが必要な場合は、SDK の組み込みプロバイダー統合ポイントから始めてください。多くの設定では、サードパーティアダプターを追加しなくてもこれで十分です。各パターンの例は examples/model_providers にあります。

非 OpenAI プロバイダーの統合方法

アプローチ	使用する場合	スコープ
set_default_openai_client	1 つの OpenAI 互換エンドポイントを、ほとんどまたはすべてのエージェントのデフォルトにしたい場合	グローバルデフォルト
ModelProvider	1 つのカスタムプロバイダーを単一の実行に適用したい場合	実行ごと
Agent.model	異なるエージェントに異なるプロバイダーまたは具体的なモデルオブジェクトが必要な場合	エージェントごと
サードパーティアダプター	組み込みの経路では提供されない、アダプター管理のプロバイダーカバレッジまたはルーティングが必要な場合	サードパーティアダプター を参照

これらの組み込み経路を使って他の LLM プロバイダーを統合できます。

1. set_default_openai_client は、AsyncOpenAI のインスタンスを LLM クライアントとしてグローバルに使用したい場合に便利です。これは、LLM プロバイダーが OpenAI 互換 API エンドポイントを持ち、base_url と api_key を設定できる場合のためのものです。設定可能な例は examples/model_providers/custom_example_global.py を参照してください。
2. ModelProvider は Runner.run レベルにあります。これにより、「この実行のすべてのエージェントでカスタムモデルプロバイダーを使用する」と指定できます。設定可能な例は examples/model_providers/custom_example_provider.py を参照してください。
3. Agent.model を使用すると、特定の Agent インスタンスでモデルを指定できます。これにより、異なるエージェントごとに異なるプロバイダーを組み合わせて使用できます。設定可能な例は examples/model_providers/custom_example_agent.py を参照してください。

platform.openai.com の API キーを持っていない場合は、set_tracing_disabled() でトレーシングを無効化するか、別のトレーシングプロセッサー を設定することを推奨します。

from agents import Agent, AsyncOpenAI, OpenAIChatCompletionsModel, set_tracing_disabled

set_tracing_disabled(disabled=True)

client = AsyncOpenAI(api_key="Api_Key", base_url="Base URL of Provider")
model = OpenAIChatCompletionsModel(model="Model_Name", openai_client=client)

agent= Agent(name="Helping Agent", instructions="You are a Helping Agent", model=model)

Note

これらの例では、多くの LLM プロバイダーがまだ Responses API をサポートしていないため、Chat Completions API/モデルを使用しています。LLM プロバイダーが Responses をサポートしている場合は、Responses を使用することを推奨します。

1 つのワークフローでのモデルの混在

単一のワークフロー内で、各エージェントに異なるモデルを使用したい場合があります。たとえば、トリアージにはより小さく高速なモデルを使用し、複雑なタスクにはより大きく高性能なモデルを使用できます。Agent を設定するときは、次のいずれかによって特定のモデルを選択できます。

1. モデル名を渡す。
2. 任意のモデル名と、その名前を Model インスタンスにマッピングできる ModelProvider を渡す。
3. Model 実装を直接提供する。

Note

SDK は OpenAIResponsesModel と OpenAIChatCompletionsModel の両方の形をサポートしていますが、2 つの形でサポートする機能とツールのセットが異なるため、各ワークフローでは単一のモデル形を使用することを推奨します。ワークフローでモデル形を組み合わせる必要がある場合は、使用するすべての機能が両方で利用できることを確認してください。

from agents import Agent, Runner, AsyncOpenAI, OpenAIChatCompletionsModel
import asyncio

spanish_agent = Agent(
    name="Spanish agent",
    instructions="You only speak Spanish.",
    model="gpt-5-mini", # (1)!
)

english_agent = Agent(
    name="English agent",
    instructions="You only speak English",
    model=OpenAIChatCompletionsModel( # (2)!
        model="gpt-5-nano",
        openai_client=AsyncOpenAI()
    ),
)

triage_agent = Agent(
    name="Triage agent",
    instructions="Handoff to the appropriate agent based on the language of the request.",
    handoffs=[spanish_agent, english_agent],
    model="gpt-5.5",
)

async def main():
    result = await Runner.run(triage_agent, input="Hola, ¿cómo estás?")
    print(result.final_output)

1. OpenAI モデルの名前を直接設定します。
2. Model 実装を提供します。

エージェントに使用するモデルをさらに設定したい場合は、temperature などの任意のモデル設定パラメーターを提供する [ModelSettings][agents.models.interface.ModelSettings] を渡すことができます。

from agents import Agent, ModelSettings

english_agent = Agent(
    name="English agent",
    instructions="You only speak English",
    model="gpt-4.1",
    model_settings=ModelSettings(temperature=0.1),
)

高度な OpenAI Responses 設定

OpenAI Responses の経路を使用していて、より細かな制御が必要な場合は、ModelSettings から始めてください。

一般的な高度な ModelSettings オプション

OpenAI Responses API を使用している場合、いくつかのリクエストフィールドにはすでに直接対応する ModelSettings フィールドがあるため、それらに extra_args は不要です。

• parallel_tool_calls: 同じターン内で複数のツール呼び出しを許可または禁止します。
• truncation: コンテキストがあふれる場合に失敗するのではなく、Responses API が最も古い会話アイテムを削除できるようにするには "auto" を設定します。
• store: 生成されたレスポンスを後で取得できるようサーバー側に保存するかどうかを制御します。これは、レスポンス ID に依存するフォローアップワークフローや、store=False の場合にローカル入力へフォールバックする必要がある可能性のあるセッション圧縮フローに関係します。
• context_management: compact_threshold を使用した Responses 圧縮など、サーバー側のコンテキスト処理を設定します。
• prompt_cache_retention: たとえば "24h" で、キャッシュされたプロンプトプレフィックスをより長く保持します。
• response_include: web_search_call.action.sources、file_search_call.results、reasoning.encrypted_content など、より豊富なレスポンスペイロードを要求します。
• top_logprobs: 出力テキストの top-token logprobs を要求します。SDK は message.output_text.logprobs も自動的に追加します。
• retry: モデル呼び出しに対して runner 管理のリトライ設定を有効にします。Runner 管理のリトライ を参照してください。

from agents import Agent, ModelSettings

research_agent = Agent(
    name="Research agent",
    model="gpt-5.5",
    model_settings=ModelSettings(
        parallel_tool_calls=False,
        truncation="auto",
        store=True,
        context_management=[{"type": "compaction", "compact_threshold": 200000}],
        prompt_cache_retention="24h",
        response_include=["web_search_call.action.sources"],
        top_logprobs=5,
    ),
)

store=False を設定すると、Responses API はそのレスポンスを後でサーバー側で取得できるようには保持しません。これはステートレスまたはゼロデータ保持スタイルのフローに便利ですが、通常であればレスポンス ID を再利用する機能が、代わりにローカル管理の状態に依存する必要があることも意味します。たとえば、OpenAIResponsesCompactionSession は、最後のレスポンスが保存されていなかった場合、デフォルトの "auto" 圧縮経路を入力ベースの圧縮に切り替えます。Sessions guide を参照してください。

サーバー側圧縮は OpenAIResponsesCompactionSession とは異なります。context_management=[{"type": "compaction", "compact_threshold": ...}] は各 Responses API リクエストとともに送信され、レンダリングされたコンテキストがしきい値を超えると、API はレスポンスの一部として圧縮アイテムを出力できます。OpenAIResponsesCompactionSession はターン間でスタンドアロンの responses.compact エンドポイントを呼び出し、ローカルセッション履歴を書き換えます。

extra_args の渡し方

SDK がまだトップレベルで直接公開していない、プロバイダー固有またはより新しいリクエストフィールドが必要な場合は extra_args を使用します。

また、OpenAI の Responses API を使用する場合、その他の任意パラメーターがいくつかあります（例: user、service_tier など）。それらがトップレベルで利用できない場合も、extra_args を使って渡せます。同じリクエストフィールドを直接の ModelSettings フィールドでも設定しないでください。

from agents import Agent, ModelSettings

english_agent = Agent(
    name="English agent",
    instructions="You only speak English",
    model="gpt-4.1",
    model_settings=ModelSettings(
        temperature=0.1,
        extra_args={"service_tier": "flex", "user": "user_12345"},
    ),
)

Runner 管理のリトライ

リトライはランタイム専用で、明示的に有効化する必要があります。ModelSettings(retry=...) を設定し、リトライポリシーがリトライを選択しない限り、SDK は一般的なモデルリクエストをリトライしません。

from agents import Agent, ModelRetrySettings, ModelSettings, retry_policies

agent = Agent(
    name="Assistant",
    model="gpt-5.5",
    model_settings=ModelSettings(
        retry=ModelRetrySettings(
            max_retries=4,
            backoff={
                "initial_delay": 0.5,
                "max_delay": 5.0,
                "multiplier": 2.0,
                "jitter": True,
            },
            policy=retry_policies.any(
                retry_policies.provider_suggested(),
                retry_policies.retry_after(),
                retry_policies.network_error(),
                retry_policies.http_status([408, 409, 429, 500, 502, 503, 504]),
            ),
        )
    ),
)

ModelRetrySettings には 3 つのフィールドがあります。

フィールド	型	注記
max_retries	int | None	初回リクエスト後に許可されるリトライ試行回数。
backoff	ModelRetryBackoffSettings | dict | None	ポリシーが明示的な遅延を返さずにリトライする場合のデフォルト遅延戦略。backoff.max_delay は、この計算された backoff 遅延のみを上限設定します。ポリシーが返す明示的な遅延や retry-after ヒントには上限を設けません。
policy	RetryPolicy | None	リトライするかどうかを決定するコールバック。このフィールドはランタイム専用で、シリアライズされません。

リトライポリシーは、次を含む RetryPolicyContext を受け取ります。

• attempt と max_retries により、試行回数を意識した判断ができます。
• stream により、ストリーミングと非ストリーミングの動作を分岐できます。
• raw な検査のための error。
• status_code、retry_after、error_code、is_network_error、is_timeout、is_abort などの正規化された事実。
• 基盤となるモデルアダプターがリトライ指針を提供できる場合の provider_advice。

ポリシーは次のいずれかを返せます。

• シンプルなリトライ判断としての True / False。
• 遅延を上書きしたり診断理由を添付したりしたい場合の RetryDecision。

SDK は retry_policies 上に既製のヘルパーをエクスポートしています。

ヘルパー	動作
retry_policies.never()	常にリトライしません。
retry_policies.provider_suggested()	利用可能な場合、プロバイダーのリトライ指針に従います。
retry_policies.network_error()	一時的なトランスポート障害およびタイムアウト障害に一致します。
retry_policies.http_status([...])	選択した HTTP ステータスコードに一致します。
retry_policies.retry_after()	retry-after ヒントが利用可能な場合にのみ、その遅延を使ってリトライします。このヘルパーは retry-after 値を明示的なポリシー遅延として扱うため、backoff.max_delay はそれを上限設定しません。
retry_policies.any(...)	ネストされたポリシーのいずれかが有効にした場合にリトライします。
retry_policies.all(...)	ネストされたすべてのポリシーが有効にした場合にのみリトライします。

ポリシーを合成する場合、provider_suggested() は、プロバイダーが区別できる場合にプロバイダーの拒否や再実行安全性の承認を保持するため、最も安全な最初の構成要素です。

安全境界

一部の失敗は自動的にリトライされません。

• Abort エラー。
• プロバイダーの助言が再実行を安全ではないと示すリクエスト。
• 出力がすでに開始され、再実行が安全でなくなるような形になった後のストリーミング実行。

previous_response_id または conversation_id を使用するステートフルなフォローアップリクエストも、より保守的に扱われます。これらのリクエストでは、network_error() や http_status([500]) などの非プロバイダー述語だけでは十分ではありません。リトライポリシーには、通常 retry_policies.provider_suggested() を介して、プロバイダーからの再実行安全性の承認を含める必要があります。

Runner とエージェントのマージ動作

retry は runner レベルとエージェントレベルの ModelSettings の間でディープマージされます。

• エージェントは retry.max_retries だけを上書きし、runner の policy を継承できます。
• エージェントは retry.backoff の一部だけを上書きし、runner から兄弟 backoff フィールドを保持できます。
• policy はランタイム専用であるため、シリアライズされた ModelSettings は max_retries と backoff を保持しますが、コールバック自体は省略します。

より詳しい例については、examples/basic/retry.py と アダプター backed リトライ例 を参照してください。

非 OpenAI プロバイダーのトラブルシューティング

トレーシングクライアントエラー 401

トレーシングに関連するエラーが発生する場合、これはトレースが OpenAI サーバーにアップロードされるためであり、OpenAI API キーを持っていないことが原因です。これを解決するには 3 つの選択肢があります。

1. トレーシングを完全に無効化する: set_tracing_disabled(True)。
2. トレーシング用の OpenAI キーを設定する: set_tracing_export_api_key(...)。この API キーはトレースのアップロードにのみ使用され、platform.openai.com のものである必要があります。
3. 非 OpenAI トレースプロセッサーを使用する。トレーシングドキュメント を参照してください。

Responses API のサポート

SDK はデフォルトで Responses API を使用しますが、他の多くの LLM プロバイダーはまだこれをサポートしていません。その結果、404 などの問題が発生することがあります。解決するには 2 つの選択肢があります。

1. set_default_openai_api("chat_completions") を呼び出す。これは、環境変数で OPENAI_API_KEY と OPENAI_BASE_URL を設定している場合に機能します。
2. OpenAIChatCompletionsModel を使用する。こちら に例があります。

structured outputs のサポート

一部のモデルプロバイダーは structured outputs をサポートしていません。これにより、次のようなエラーが発生することがあります。

BadRequestError: Error code: 400 - {'error': {'message': "'response_format.type' : value is not one of the allowed values ['text','json_object']", 'type': 'invalid_request_error'}}

これは一部のモデルプロバイダーの制約です。JSON 出力はサポートしていますが、出力に使用する json_schema を指定できません。現在この修正に取り組んでいますが、JSON スキーマ出力をサポートするプロバイダーに依存することをおすすめします。そうしないと、不正な形式の JSON によりアプリが頻繁に壊れる可能性があります。

プロバイダー間でのモデルの混在

モデルプロバイダー間の機能差を把握しておく必要があります。そうしないとエラーに遭遇する可能性があります。たとえば、OpenAI は structured outputs、マルチモーダル入力、ホストされたファイル検索および Web 検索をサポートしていますが、他の多くのプロバイダーはこれらの機能をサポートしていません。次の制限に注意してください。

• 未対応の tools を、それを理解しないプロバイダーに送信しないでください
• テキスト専用モデルを呼び出す前に、マルチモーダル入力を除外してください
• 構造化 JSON 出力をサポートしていないプロバイダーは、ときどき無効な JSON を生成することに注意してください。

サードパーティアダプター

SDK の組み込みプロバイダー統合ポイントでは不十分な場合にのみ、サードパーティアダプターを使用してください。この SDK で OpenAI モデルのみを使用している場合は、Any-LLM や LiteLLM ではなく、組み込みの OpenAIResponsesModel 経路を優先してください。サードパーティアダプターは、OpenAI モデルを非 OpenAI プロバイダーと組み合わせる必要がある場合、または組み込み経路では提供されないアダプター管理のプロバイダーカバレッジやルーティングが必要な場合のためのものです。アダプターは SDK と上流のモデルプロバイダーの間に別の互換性レイヤーを追加するため、機能サポートやリクエストのセマンティクスはプロバイダーによって異なる場合があります。SDK には現在、ベストエフォートのベータ版アダプター統合として Any-LLM と LiteLLM が含まれています。

Any-LLM

Any-LLM のサポートは、Any-LLM 管理のプロバイダーカバレッジやルーティングが必要な場合のために、ベストエフォートのベータ版として含まれています。

上流プロバイダーの経路によって、Any-LLM は Responses API、Chat Completions 互換 API、またはプロバイダー固有の互換性レイヤーを使用する場合があります。

Any-LLM が必要な場合は、openai-agents[any-llm] をインストールし、examples/model_providers/any_llm_auto.py または examples/model_providers/any_llm_provider.py から始めてください。MultiProvider で any-llm/... モデル名を使用する、AnyLLMModel を直接インスタンス化する、または実行スコープで AnyLLMProvider を使用できます。モデルサーフェスを明示的に固定する必要がある場合は、AnyLLMModel の構築時に api="responses" または api="chat_completions" を渡します。

Any-LLM はサードパーティアダプターレイヤーのままなので、プロバイダーの依存関係や機能のギャップは SDK ではなく上流の Any-LLM によって定義されます。上流プロバイダーが使用量メトリクスを返す場合、それらは自動的に伝播されますが、ストリーミング Chat Completions バックエンドでは、使用量チャンクを出力する前に ModelSettings(include_usage=True) が必要な場合があります。structured outputs、ツール呼び出し、使用量レポート、または Responses 固有の動作に依存する場合は、デプロイ予定の正確なプロバイダーバックエンドを検証してください。

LiteLLM

LiteLLM のサポートは、LiteLLM 固有のプロバイダーカバレッジやルーティングが必要な場合のために、ベストエフォートのベータ版として含まれています。

LiteLLM が必要な場合は、openai-agents[litellm] をインストールし、examples/model_providers/litellm_auto.py または examples/model_providers/litellm_provider.py から始めてください。litellm/... モデル名を使用するか、LitellmModel を直接インスタンス化できます。

一部の LiteLLM バックのプロバイダーは、デフォルトでは SDK の使用量メトリクスを設定しません。使用量レポートが必要な場合は、ModelSettings(include_usage=True) を渡し、structured outputs、ツール呼び出し、使用量レポート、またはアダプター固有のルーティング動作に依存する場合は、デプロイ予定の正確なプロバイダーバックエンドを検証してください。