エージェントの実行

Runner クラスを使用してエージェントを実行できます。選択肢は 3 つあります。

1. Runner.run() は async で実行され、RunResult を返します。
2. Runner.run_sync() は sync メソッドで、内部的には単に .run() を実行します。
3. Runner.run_streamed() は async で実行され、RunResultStreaming を返します。LLM をストリーミングモードで呼び出し、受信したイベントをストリーミングします。

from agents import Agent, Runner

async def main():
    agent = Agent(name="Assistant", instructions="You are a helpful assistant")

    result = await Runner.run(agent, "Write a haiku about recursion in programming.")
    print(result.final_output)
    # Code within the code,
    # Functions calling themselves,
    # Infinite loop's dance

詳しくは 実行結果ガイド をお読みください。

Runner のライフサイクルと設定

エージェントループ

Runner の run メソッドを使用するときは、開始エージェントと入力を渡します。入力には次を指定できます。

• 文字列（ユーザーメッセージとして扱われます）、
• OpenAI Responses API 形式の入力アイテムのリスト、または
• 中断された実行を再開する場合の RunState。

その後、runner はループを実行します。

1. 現在のエージェントに対して、現在の入力で LLM を呼び出します。
2. LLM が出力を生成します。
   1. LLM が final_output を返した場合、ループは終了し、実行結果を返します。
   2. LLM がハンドオフを行った場合、現在のエージェントと入力を更新し、ループを再実行します。
   3. LLM がツール呼び出しを生成した場合、それらのツール呼び出しを実行し、実行結果を追加して、ループを再実行します。
3. 渡された max_turns を超えた場合、MaxTurnsExceeded 例外を発生させます。このターン制限を無効にするには、max_turns=None を渡します。

Note

LLM 出力が「最終出力」と見なされるかどうかのルールは、目的の型のテキスト出力を生成し、ツール呼び出しがないことです。

ストリーミング

ストリーミングを使用すると、LLM の実行中にストリーミングイベントも受信できます。ストリームが完了すると、RunResultStreaming には、生成されたすべての新しい出力を含む、実行に関する完全な情報が含まれます。ストリーミングイベントには .stream_events() を呼び出せます。詳しくは ストリーミングガイド をお読みください。

Responses WebSocket トランスポート（任意のヘルパー）

OpenAI Responses websocket トランスポートを有効にしても、通常の Runner API を引き続き使用できます。接続の再利用には websocket セッションヘルパーが推奨されますが、必須ではありません。

これは websocket トランスポート上の Responses API であり、Realtime API ではありません。

トランスポート選択ルールや、具体的なモデルオブジェクトまたはカスタムプロバイダーに関する注意点については、モデル を参照してください。

パターン 1: セッションヘルパーなし（動作します）

websocket トランスポートだけが必要で、SDK に共有プロバイダー / セッションを管理させる必要がない場合に使用します。

import asyncio

from agents import Agent, Runner, set_default_openai_responses_transport


async def main():
    set_default_openai_responses_transport("websocket")

    agent = Agent(name="Assistant", instructions="Be concise.")
    result = Runner.run_streamed(agent, "Summarize recursion in one sentence.")

    async for event in result.stream_events():
        if event.type == "raw_response_event":
            continue
        print(event.type)


asyncio.run(main())

このパターンは単発の実行には問題ありません。Runner.run() / Runner.run_streamed() を繰り返し呼び出す場合、同じ RunConfig / プロバイダーインスタンスを手動で再利用しない限り、各実行で再接続される可能性があります。

パターン 2: responses_websocket_session() の使用（複数ターンでの再利用に推奨）

複数の実行（同じ run_config を継承するネストされた agent-as-tool 呼び出しを含む）で共有の websocket 対応プロバイダーと RunConfig が必要な場合は、responses_websocket_session() を使用します。

import asyncio

from agents import Agent, responses_websocket_session


async def main():
    agent = Agent(name="Assistant", instructions="Be concise.")

    async with responses_websocket_session(
        responses_websocket_options={"ping_interval": 20.0, "ping_timeout": 60.0},
    ) as ws:
        first = ws.run_streamed(agent, "Say hello in one short sentence.")
        async for _event in first.stream_events():
            pass

        second = ws.run_streamed(
            agent,
            "Now say goodbye.",
            previous_response_id=first.last_response_id,
        )
        async for _event in second.stream_events():
            pass


asyncio.run(main())

コンテキストを抜ける前に、ストリーミングされた実行結果の消費を完了してください。websocket リクエストがまだ実行中の間にコンテキストを抜けると、共有接続が強制的に閉じられる可能性があります。

長い推論ターンで websocket keepalive タイムアウトが発生する場合は、ping_timeout を増やすか、ping_timeout=None を設定して heartbeat タイムアウトを無効にしてください。websocket のレイテンシーより信頼性が重要な実行では、HTTP/SSE トランスポートを使用してください。

実行設定

run_config パラメーターを使用すると、エージェント実行の一部のグローバル設定を構成できます。

一般的な実行設定カテゴリー

各エージェント定義を変更せずに、単一の実行の動作を上書きするには RunConfig を使用します。

モデル、プロバイダー、セッションのデフォルト

• model: 各 Agent が持つ model に関係なく、使用するグローバル LLM モデルを設定できます。
• model_provider: モデル名を検索するためのモデルプロバイダーで、デフォルトは OpenAI です。
• model_settings: エージェント固有の設定を上書きします。たとえば、グローバルな temperature または top_p を設定できます。
• session_settings: 実行中に履歴を取得する際のセッションレベルのデフォルト（たとえば SessionSettings(limit=...)）を上書きします。
• session_input_callback: Sessions を使用するとき、各ターンの前に新しいユーザー入力をセッション履歴とどのようにマージするかをカスタマイズします。コールバックは sync または async にできます。

ガードレール、ハンドオフ、モデル入力の整形

• input_guardrails, output_guardrails: すべての実行に含める入力または出力ガードレールのリストです。
• handoff_input_filter: ハンドオフにすでにフィルターがない場合に、すべてのハンドオフに適用するグローバル入力フィルターです。入力フィルターを使用すると、新しいエージェントに送信される入力を編集できます。詳細については、Handoff.input_filter のドキュメントを参照してください。
• nest_handoff_history: 次のエージェントを呼び出す前に、以前の transcript を単一の assistant メッセージに折りたたむ opt-in beta です。ネストされたハンドオフを安定化する間、これはデフォルトで無効です。有効にするには True に設定し、raw transcript をそのまま渡すには False のままにします。Runner methods は RunConfig を渡さない場合に自動的に作成するため、クイックスタートとコード例ではデフォルトがオフのままになり、明示的な Handoff.input_filter コールバックは引き続きこれを上書きします。個別のハンドオフでは、Handoff.nest_handoff_history を介してこの設定を上書きできます。
• handoff_history_mapper: nest_handoff_history に opt in したときに、正規化済み transcript（履歴 + ハンドオフアイテム）を受け取る任意の callable です。次のエージェントに転送する入力アイテムの正確なリストを返す必要があり、完全なハンドオフフィルターを書かずに組み込み summary を置き換えられます。
• call_model_input_filter: モデル呼び出しの直前に、完全に準備されたモデル入力（instructions と入力アイテム）を編集する hook です。たとえば、履歴を trim したり、システムプロンプトを注入したりできます。
• reasoning_item_id_policy: runner が以前の出力を次ターンのモデル入力に変換するとき、reasoning item ID を保持するか省略するかを制御します。

トレーシングと可観測性

• tracing_disabled: 実行全体の トレーシング を無効にできます。
• tracing: 実行ごとのトレーシング API キーなど、trace export 設定を上書きするために TracingConfig を渡します。
• trace_include_sensitive_data: LLM やツール呼び出しの入力 / 出力など、機密の可能性があるデータを trace に含めるかどうかを構成します。
• workflow_name, trace_id, group_id: 実行のトレーシング workflow 名、trace ID、trace group ID を設定します。少なくとも workflow_name を設定することをお勧めします。group ID は、複数の実行にわたって trace をリンクできる任意フィールドです。
• trace_metadata: すべての trace に含めるメタデータです。

ツール実行、承認、ツールエラー動作

• tool_execution: 同時に実行する関数ツールの数を制限するなど、ローカルツール呼び出しに対する SDK 側の実行動作を構成します。
• tool_error_formatter: 承認フロー中にツール呼び出しが拒否された場合に、モデルに見えるメッセージをカスタマイズします。

ネストされたハンドオフは opt-in beta として利用できます。折りたたまれた transcript の動作を有効にするには RunConfig(nest_handoff_history=True) を渡すか、特定のハンドオフで有効にするために handoff(..., nest_handoff_history=True) を設定します。raw transcript（デフォルト）を保持したい場合は、フラグを未設定のままにするか、必要どおりに会話を正確に転送する handoff_input_filter（または handoff_history_mapper）を提供します。カスタム mapper を書かずに、生成される summary で使用される wrapper text を変更するには、set_conversation_history_wrappers（デフォルトを復元するには reset_conversation_history_wrappers）を呼び出します。

実行設定の詳細

tool_execution

実行に対して SDK にローカル関数ツールの同時実行数を制限させたい場合は、tool_execution を使用します。

from agents import Agent, RunConfig, Runner, ToolExecutionConfig

agent = Agent(name="Assistant", tools=[...])

result = await Runner.run(
    agent,
    "Run the required tool calls.",
    run_config=RunConfig(
        tool_execution=ToolExecutionConfig(max_function_tool_concurrency=2),
    ),
)

max_function_tool_concurrency=None はデフォルトの動作を維持します。モデルが 1 ターンで複数の関数ツール呼び出しを出力した場合、SDK は出力されたすべてのローカル関数ツール呼び出しを開始します。同時に実行されるローカル関数ツールの数に上限を設けるには、整数値を設定します。

これはプロバイダー側の ModelSettings.parallel_tool_calls とは別です。parallel_tool_calls は、モデルが 1 つのレスポンスで複数のツール呼び出しを出力してよいかどうかを制御します。tool_execution.max_function_tool_concurrency は、モデルが出力した後に SDK がローカル関数ツール呼び出しをどのように実行するかを制御します。

tool_error_formatter

承認フローでツール呼び出しが拒否されたときにモデルへ返されるメッセージをカスタマイズするには、tool_error_formatter を使用します。

formatter は ToolErrorFormatterArgs を受け取り、内容は次のとおりです。

• kind: エラーカテゴリーです。現時点では "approval_rejected" です。
• tool_type: ツールランタイム（"function"、"computer"、"shell"、"apply_patch"、または "custom"）です。
• tool_name: ツール名です。
• call_id: ツール呼び出し ID です。
• default_message: SDK のデフォルトの、モデルに見えるメッセージです。
• run_context: アクティブな実行コンテキスト wrapper です。

メッセージを置き換えるには文字列を返し、SDK のデフォルトを使用するには None を返します。

from agents import Agent, RunConfig, Runner, ToolErrorFormatterArgs


def format_rejection(args: ToolErrorFormatterArgs[None]) -> str | None:
    if args.kind == "approval_rejected":
        return (
            f"Tool call '{args.tool_name}' was rejected by a human reviewer. "
            "Ask for confirmation or propose a safer alternative."
        )
    return None


agent = Agent(name="Assistant")
result = Runner.run_sync(
    agent,
    "Please delete the production database.",
    run_config=RunConfig(tool_error_formatter=format_rejection),
)

reasoning_item_id_policy

reasoning_item_id_policy は、runner が履歴を次へ引き継ぐとき（たとえば RunResult.to_input_list() やセッションに基づく実行を使用する場合）に、reasoning item を次ターンのモデル入力へどのように変換するかを制御します。

• None または "preserve"（デフォルト）: reasoning item ID を保持します。
• "omit": 生成される次ターン入力から reasoning item ID を取り除きます。

"omit" は主に、reasoning item が id とともに送信されているものの、必須の後続アイテムがない場合（たとえば Item 'rs_...' of type 'reasoning' was provided without its required following item.）に発生する Responses API 400 エラーのクラスに対する opt-in 緩和策として使用します。

これは、SDK が以前の出力から follow-up 入力を構築する複数ターンのエージェント実行（セッション永続化、サーバー管理の会話差分、ストリーミング / 非ストリーミングの follow-up ターン、resume paths を含む）で、reasoning item ID が保持されている一方、プロバイダーがその ID を対応する後続アイテムとペアのままにすることを要求する場合に発生することがあります。

reasoning_item_id_policy="omit" を設定すると、reasoning content は保持しつつ reasoning item の id を取り除くため、SDK が生成する follow-up 入力でその API invariant をトリガーするのを回避できます。

スコープに関する注意:

• これは、SDK が follow-up 入力を構築するときに SDK によって生成 / 転送される reasoning items のみを変更します。
• ユーザーが提供した初期入力アイテムは書き換えません。
• call_model_input_filter は、このポリシー適用後でも意図的に reasoning IDs を再導入できます。

状態と会話管理

メモリー戦略の選択

状態を次のターンへ引き継ぐ一般的な方法は 4 つあります。

戦略	状態の所在	最適な用途	次のターンで渡すもの
result.to_input_list()	アプリのメモリー	小規模なチャットループ、完全な手動制御、任意のプロバイダー	result.to_input_list() からのリストと次のユーザーメッセージ
session	ストレージと SDK	永続的なチャット状態、再開可能な実行、カスタムストア	同じ session インスタンス、または同じストアを指す別のインスタンス
conversation_id	OpenAI Conversations API	ワーカーやサービス間で共有したい名前付きのサーバー側会話	同じ conversation_id と新しいユーザーターンのみ
previous_response_id	OpenAI Responses API	会話リソースを作成せずに行う軽量なサーバー管理の継続	result.last_response_id と新しいユーザーターンのみ

result.to_input_list() と session はクライアント管理です。conversation_id と previous_response_id は OpenAI 管理であり、OpenAI Responses API を使用している場合にのみ適用されます。ほとんどのアプリケーションでは、会話ごとに 1 つの永続化戦略を選択します。両方のレイヤーを意図的に照合しているのでない限り、クライアント管理の履歴と OpenAI 管理の状態を混在させると、コンテキストが重複する可能性があります。

Note

セッション永続化は、サーバー管理の会話設定 （conversation_id、previous_response_id、または auto_previous_response_id）と 同じ実行内で組み合わせることはできません。呼び出しごとに 1 つのアプローチを選択してください。

会話 / チャットスレッド

いずれかの run メソッドを呼び出すと、1 つ以上のエージェントが実行される（したがって 1 回以上の LLM 呼び出しが行われる）可能性がありますが、チャット会話における単一の論理ターンを表します。例:

1. ユーザーターン: ユーザーがテキストを入力します
2. Runner run: 最初のエージェントが LLM を呼び出し、ツールを実行し、2 番目のエージェントへハンドオフし、2 番目のエージェントがさらにツールを実行してから出力を生成します。

エージェントの実行の最後に、ユーザーに何を表示するかを選択できます。たとえば、エージェントによって生成されたすべての新しいアイテムをユーザーに表示することも、最終出力だけを表示することもできます。いずれの場合も、ユーザーが続けて質問することがあり、その場合は run メソッドを再度呼び出せます。

手動での会話管理

RunResultBase.to_input_list() メソッドを使用して次のターンの入力を取得することで、会話履歴を手動で管理できます。

async def main():
    agent = Agent(name="Assistant", instructions="Reply very concisely.")

    thread_id = "thread_123"  # Example thread ID
    with trace(workflow_name="Conversation", group_id=thread_id):
        # First turn
        result = await Runner.run(agent, "What city is the Golden Gate Bridge in?")
        print(result.final_output)
        # San Francisco

        # Second turn
        new_input = result.to_input_list() + [{"role": "user", "content": "What state is it in?"}]
        result = await Runner.run(agent, new_input)
        print(result.final_output)
        # California

セッションによる自動会話管理

よりシンプルな方法として、Sessions を使用すると、.to_input_list() を手動で呼び出さずに会話履歴を自動的に処理できます。

from agents import Agent, Runner, SQLiteSession

async def main():
    agent = Agent(name="Assistant", instructions="Reply very concisely.")

    # Create session instance
    session = SQLiteSession("conversation_123")

    thread_id = "thread_123"  # Example thread ID
    with trace(workflow_name="Conversation", group_id=thread_id):
        # First turn
        result = await Runner.run(agent, "What city is the Golden Gate Bridge in?", session=session)
        print(result.final_output)
        # San Francisco

        # Second turn - agent automatically remembers previous context
        result = await Runner.run(agent, "What state is it in?", session=session)
        print(result.final_output)
        # California

Sessions は自動的に次を行います。

• 各実行の前に会話履歴を取得します
• 各実行の後に新しいメッセージを保存します
• 異なるセッション ID ごとに別々の会話を維持します

詳細については、Sessions ドキュメント を参照してください。

サーバー管理の会話

to_input_list() や Sessions でローカルに処理する代わりに、OpenAI の会話状態機能にサーバー側で会話状態を管理させることもできます。これにより、過去のすべてのメッセージを手動で再送信することなく、会話履歴を保持できます。以下のいずれのサーバー管理アプローチでも、各リクエストでは新しいターンの入力のみを渡し、保存された ID を再利用します。詳細については、OpenAI Conversation state guide を参照してください。

OpenAI はターン間で状態を追跡する 2 つの方法を提供しています。

1. conversation_id の使用

まず OpenAI Conversations API を使用して会話を作成し、その ID を以降のすべての呼び出しで再利用します。

from agents import Agent, Runner
from openai import AsyncOpenAI

client = AsyncOpenAI()

async def main():
    agent = Agent(name="Assistant", instructions="Reply very concisely.")

    # Create a server-managed conversation
    conversation = await client.conversations.create()
    conv_id = conversation.id

    while True:
        user_input = input("You: ")
        result = await Runner.run(agent, user_input, conversation_id=conv_id)
        print(f"Assistant: {result.final_output}")

2. previous_response_id の使用

もう 1 つの選択肢は response chaining で、各ターンが前のターンの response ID に明示的にリンクされます。

from agents import Agent, Runner

async def main():
    agent = Agent(name="Assistant", instructions="Reply very concisely.")

    previous_response_id = None

    while True:
        user_input = input("You: ")

        # Setting auto_previous_response_id=True enables response chaining automatically
        # for the first turn, even when there's no actual previous response ID yet.
        result = await Runner.run(
            agent,
            user_input,
            previous_response_id=previous_response_id,
            auto_previous_response_id=True,
        )
        previous_response_id = result.last_response_id
        print(f"Assistant: {result.final_output}")

実行が承認のために一時停止し、RunState から再開する場合、 SDK は保存された conversation_id / previous_response_id / auto_previous_response_id 設定を保持するため、再開されたターンは同じサーバー管理の会話で継続します。

conversation_id と previous_response_id は相互に排他的です。システム間で共有できる名前付きの会話リソースが必要な場合は conversation_id を使用します。あるターンから次のターンへ最も軽量な Responses API の継続プリミティブが必要な場合は previous_response_id を使用します。

Note

SDK は conversation_locked エラーを backoff 付きで自動的に retry します。サーバー管理の 会話実行では、同じ準備済みアイテムをきれいに再送できるように、retry 前に内部の conversation-tracker 入力を巻き戻します。

ローカルセッションベースの実行（conversation_id、 previous_response_id、または auto_previous_response_id と組み合わせることはできません）では、SDK は retry 後の重複した履歴エントリーを減らすため、 最近永続化された入力アイテムの best-effort rollback も実行します。

この互換性 retry は、ModelSettings.retry を構成していない場合でも発生します。モデルリクエストに対する、より広範な opt-in retry 動作については、Runner 管理の retry を参照してください。

フックとカスタマイズ

モデル呼び出し入力フィルター

モデル呼び出しの直前にモデル入力を編集するには、call_model_input_filter を使用します。この hook は、現在のエージェント、context、および結合された入力アイテム（存在する場合はセッション履歴を含む）を受け取り、新しい ModelInputData を返します。

戻り値は ModelInputData オブジェクトである必要があります。その input フィールドは必須で、入力アイテムのリストでなければなりません。それ以外の形を返すと UserError が発生します。

from agents import Agent, Runner, RunConfig
from agents.run import CallModelData, ModelInputData

def drop_old_messages(data: CallModelData[None]) -> ModelInputData:
    # Keep only the last 5 items and preserve existing instructions.
    trimmed = data.model_data.input[-5:]
    return ModelInputData(input=trimmed, instructions=data.model_data.instructions)

agent = Agent(name="Assistant", instructions="Answer concisely.")
result = Runner.run_sync(
    agent,
    "Explain quines",
    run_config=RunConfig(call_model_input_filter=drop_old_messages),
)

runner は準備済み入力リストのコピーを hook に渡すため、呼び出し元の元のリストをその場で変更せずに、trim、置換、並べ替えができます。

セッションを使用している場合、call_model_input_filter はセッション履歴がすでにロードされ、現在のターンとマージされた後に実行されます。その前のマージ手順自体をカスタマイズしたい場合は、session_input_callback を使用します。

conversation_id、previous_response_id、または auto_previous_response_id を使用した OpenAI サーバー管理の会話状態を使用している場合、hook は次の Responses API 呼び出しのために準備された payload に対して実行されます。その payload は、以前の履歴全体の再生ではなく、すでに新しいターンの差分のみを表している場合があります。返したアイテムだけが、そのサーバー管理の継続に対して送信済みとしてマークされます。

機密データを redact したり、長い履歴を trim したり、追加のシステムガイダンスを注入したりするには、run_config 経由で実行ごとに hook を設定します。

エラーと復旧

エラーハンドラー

すべての Runner エントリーポイントは error_handlers を受け入れます。これはエラー種別をキーとする dict です。サポートされるキーは "max_turns" と "model_refusal" です。MaxTurnsExceeded または ModelRefusalError を発生させる代わりに、制御された最終出力を返したい場合に使用します。

from agents import (
    Agent,
    RunErrorHandlerInput,
    RunErrorHandlerResult,
    Runner,
)

agent = Agent(name="Assistant", instructions="Be concise.")


def on_max_turns(_data: RunErrorHandlerInput[None]) -> RunErrorHandlerResult:
    return RunErrorHandlerResult(
        final_output="I couldn't finish within the turn limit. Please narrow the request.",
        include_in_history=False,
    )


result = Runner.run_sync(
    agent,
    "Analyze this long transcript",
    max_turns=3,
    error_handlers={"max_turns": on_max_turns},
)
print(result.final_output)

fallback 出力を会話履歴に追加したくない場合は、include_in_history=False を設定します。

モデル拒否で ModelRefusalError により実行を終了する代わりに、アプリケーション固有の fallback を生成したい場合は "model_refusal" を使用します。

from pydantic import BaseModel

from agents import Agent, ModelRefusalError, RunErrorHandlerInput, Runner


class Recipe(BaseModel):
    ingredients: list[str]
    refusal_reason: str | None = None


def on_model_refusal(data: RunErrorHandlerInput[None]) -> Recipe:
    assert isinstance(data.error, ModelRefusalError)
    return Recipe(ingredients=[], refusal_reason=data.error.refusal)


agent = Agent(
    name="Recipe assistant",
    instructions="Return a structured recipe.",
    output_type=Recipe,
)

result = Runner.run_sync(
    agent,
    "Make me something unsafe.",
    error_handlers={"model_refusal": on_model_refusal},
)
print(result.final_output)

Durable execution 統合と human-in-the-loop

ツール承認の pause/resume パターンについては、専用の Human-in-the-loop ガイド から始めてください。 以下の統合は、実行が長い待機、retry、またはプロセス再起動にまたがる可能性がある場合の durable orchestration のためのものです。

Dapr

Agents SDK の Dapr Diagrid 統合を使用して、人間参加型のサポートにより障害から自動的に復旧する、durable で長時間実行されるエージェントを実行できます。Dapr はベンダー中立の CNCF workflow orchestrator です。Dapr と OpenAI エージェントの開始方法は こちら です。

Temporal

Agents SDK の Temporal 統合を使用して、人間参加型タスクを含む durable で長時間実行される workflow を実行できます。長時間実行タスクを完了するために Temporal と Agents SDK が実際に連携するデモは この動画 で確認でき、ドキュメントはこちら です。

Restate

Agents SDK の Restate 統合を使用して、人間の承認、ハンドオフ、セッション管理を含む軽量で durable なエージェントを利用できます。この統合は依存関係として Restate の single-binary runtime を必要とし、エージェントをプロセス / コンテナーまたはサーバーレス関数として実行することをサポートします。 詳細については、概要 を読むか、ドキュメント を参照してください。

DBOS

Agents SDK の DBOS 統合を使用して、障害や再起動をまたいで進行状況を保持する信頼性の高いエージェントを実行できます。長時間実行エージェント、人間参加型 workflow、ハンドオフをサポートします。sync と async の両方のメソッドをサポートします。この統合に必要なのは SQLite または Postgres データベースだけです。詳細については、統合 repo と ドキュメント を参照してください。

例外

SDK は特定の場合に例外を発生させます。完全なリストは agents.exceptions にあります。概要は次のとおりです。

• AgentsException: これは SDK 内で発生するすべての例外の基底クラスです。他のすべての具体的な例外が派生する汎用型として機能します。
• MaxTurnsExceeded: この例外は、エージェントの実行が Runner.run、Runner.run_sync、または Runner.run_streamed メソッドに渡された max_turns 制限を超えたときに発生します。指定された対話ターン数内でエージェントがタスクを完了できなかったことを示します。制限を無効にするには max_turns=None を設定します。
• ModelBehaviorError: この例外は、基盤となるモデル（LLM）が予期しない、または無効な出力を生成したときに発生します。これには次が含まれます。
  • 不正な JSON: モデルがツール呼び出し用、または直接出力内で不正な JSON 構造を提供した場合。特に特定の output_type が定義されている場合です。
  • 予期しないツール関連の失敗: モデルが期待される方法でツールを使用できなかった場合
• ToolTimeoutError: この例外は、関数ツール呼び出しが構成された timeout を超え、そのツールが timeout_behavior="raise_exception" を使用している場合に発生します。
• UserError: この例外は、あなた（SDK を使用してコードを書く人）が SDK の使用中にエラーを起こした場合に発生します。これは通常、不正なコード実装、無効な設定、または SDK API の誤用によって発生します。
• InputGuardrailTripwireTriggered, OutputGuardrailTripwireTriggered: この例外は、入力ガードレールまたは出力ガードレールの条件がそれぞれ満たされた場合に発生します。入力ガードレールは処理前に受信メッセージをチェックし、出力ガードレールは配信前にエージェントの最終応答をチェックします。