openai-agents 0.2.4__tar.gz → 0.2.6__tar.gz

{openai_agents-0.2.4 → openai_agents-0.2.6}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openai-agents
-Version: 0.2.4
+Version: 0.2.6
 Summary: OpenAI Agents SDK
 Project-URL: Homepage, https://openai.github.io/openai-agents-python/
 Project-URL: Repository, https://github.com/openai/openai-agents-python
@@ -21,7 +21,7 @@ Classifier: Typing :: Typed
 Requires-Python: >=3.9
 Requires-Dist: griffe<2,>=1.5.6
 Requires-Dist: mcp<2,>=1.11.0; python_version >= '3.10'
-Requires-Dist: openai<2,>=1.97.1
+Requires-Dist: openai<2,>=1.99.6
 Requires-Dist: pydantic<3,>=2.10
 Requires-Dist: requests<3,>=2.0
 Requires-Dist: types-requests<3,>=2.0
@@ -196,6 +196,10 @@ The Agents SDK is designed to be highly flexible, allowing you to model a wide r
 
 The Agents SDK automatically traces your agent runs, making it easy to track and debug the behavior of your agents. Tracing is extensible by design, supporting custom spans and a wide variety of external destinations, including [Logfire](https://logfire.pydantic.dev/docs/integrations/llms/openai/#openai-agents), [AgentOps](https://docs.agentops.ai/v1/integrations/agentssdk), [Braintrust](https://braintrust.dev/docs/guides/traces/integrations#openai-agents-sdk), [Scorecard](https://docs.scorecard.io/docs/documentation/features/tracing#openai-agents-sdk-integration), and [Keywords AI](https://docs.keywordsai.co/integration/development-frameworks/openai-agent). For more details about how to customize or disable tracing, see [Tracing](http://openai.github.io/openai-agents-python/tracing), which also includes a larger list of [external tracing processors](http://openai.github.io/openai-agents-python/tracing/#external-tracing-processors-list).
 
+## Long running agents & human-in-the-loop
+
+You can use the Agents SDK [Temporal](https://temporal.io/) integration to run durable, long-running workflows, including human-in-the-loop tasks. View a demo of Temporal and the Agents SDK working in action to complete long-running tasks [in this video](https://www.youtube.com/watch?v=fFBZqzT4DD8), and [view docs here](https://github.com/temporalio/sdk-python/tree/main/temporalio/contrib/openai_agents).
+
 ## Sessions
 
 The Agents SDK provides built-in session memory to automatically maintain conversation history across multiple agent runs, eliminating the need to manually handle `.to_input_list()` between turns.

{openai_agents-0.2.4 → openai_agents-0.2.6}/README.md

@@ -157,6 +157,10 @@ The Agents SDK is designed to be highly flexible, allowing you to model a wide r
 
 The Agents SDK automatically traces your agent runs, making it easy to track and debug the behavior of your agents. Tracing is extensible by design, supporting custom spans and a wide variety of external destinations, including [Logfire](https://logfire.pydantic.dev/docs/integrations/llms/openai/#openai-agents), [AgentOps](https://docs.agentops.ai/v1/integrations/agentssdk), [Braintrust](https://braintrust.dev/docs/guides/traces/integrations#openai-agents-sdk), [Scorecard](https://docs.scorecard.io/docs/documentation/features/tracing#openai-agents-sdk-integration), and [Keywords AI](https://docs.keywordsai.co/integration/development-frameworks/openai-agent). For more details about how to customize or disable tracing, see [Tracing](http://openai.github.io/openai-agents-python/tracing), which also includes a larger list of [external tracing processors](http://openai.github.io/openai-agents-python/tracing/#external-tracing-processors-list).
 
+## Long running agents & human-in-the-loop
+
+You can use the Agents SDK [Temporal](https://temporal.io/) integration to run durable, long-running workflows, including human-in-the-loop tasks. View a demo of Temporal and the Agents SDK working in action to complete long-running tasks [in this video](https://www.youtube.com/watch?v=fFBZqzT4DD8), and [view docs here](https://github.com/temporalio/sdk-python/tree/main/temporalio/contrib/openai_agents).
+
 ## Sessions
 
 The Agents SDK provides built-in session memory to automatically maintain conversation history across multiple agent runs, eliminating the need to manually handle `.to_input_list()` between turns.

{openai_agents-0.2.4 → openai_agents-0.2.6}/docs/index.md

@@ -4,7 +4,7 @@ The [OpenAI Agents SDK](https://github.com/openai/openai-agents-python) enables
 
 -   **Agents**, which are LLMs equipped with instructions and tools
 -   **Handoffs**, which allow agents to delegate to other agents for specific tasks
--   **Guardrails**, which enable the inputs to agents to be validated
+-   **Guardrails**, which enable validation of agent inputs and outputs
 -   **Sessions**, which automatically maintains conversation history across agent runs
 
 In combination with Python, these primitives are powerful enough to express complex relationships between tools and agents, and allow you to build real-world applications without a steep learning curve. In addition, the SDK comes with built-in **tracing** that lets you visualize and debug your agentic flows, as well as evaluate them and even fine-tune models for your application.

openai_agents-0.2.6/docs/ja/agents.md

@@ -0,0 +1,249 @@
+---
+search:
+  exclude: true
+---
+# エージェント
+
+エージェントはアプリの中核となるビルディングブロックです。エージェントとは、指示とツールで構成された大規模言語モデル ( LLM ) です。
+
+## 基本設定
+
+エージェントで最もよく設定するプロパティは次のとおりです。
+
+- `name`: エージェントを識別する必須の文字列。
+- `instructions`: developer メッセージまたは system prompt とも呼ばれます。
+- `model`: 使用する LLM、および temperature や top_p などのチューニングパラメーターを設定する `model_settings` (オプション)。
+- `tools`: エージェントがタスク達成のために使用できるツール。
+
+```python
+from agents import Agent, ModelSettings, function_tool
+
+@function_tool
+def get_weather(city: str) -> str:
+     """returns weather info for the specified city."""
+    return f"The weather in {city} is sunny"
+
+agent = Agent(
+    name="Haiku agent",
+    instructions="Always respond in haiku form",
+    model="o3-mini",
+    tools=[get_weather],
+)
+```
+
+## コンテキスト
+
+エージェントはその `context` 型に対して汎用的です。コンテキストは依存性注入ツールであり、あなたが作成して `Runner.run()` に渡すオブジェクトです。このオブジェクトはすべてのエージェント、ツール、ハンドオフなどに渡され、エージェント実行の依存関係や状態をまとめて保持します。コンテキストには任意の Python オブジェクトを渡せます。
+
+```python
+@dataclass
+class UserContext:
+    name: str
+    uid: str
+    is_pro_user: bool
+
+    async def fetch_purchases() -> list[Purchase]:
+        return ...
+
+agent = Agent[UserContext](
+    ...,
+)
+```
+
+## 出力タイプ
+
+デフォルトでは、エージェントはプレーンテキスト (すなわち `str`) を出力します。特定の型で出力させたい場合は、`output_type` パラメーターを使用します。一般的には [Pydantic](https://docs.pydantic.dev/) オブジェクトを使いますが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型―dataclass、list、TypedDict など―であれば利用できます。
+
+```python
+from pydantic import BaseModel
+from agents import Agent
+
+
+class CalendarEvent(BaseModel):
+    name: str
+    date: str
+    participants: list[str]
+
+agent = Agent(
+    name="Calendar extractor",
+    instructions="Extract calendar events from text",
+    output_type=CalendarEvent,
+)
+```
+
+!!! note
+
+    `output_type` を指定すると、モデルは通常のプレーンテキスト応答ではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用するよう指示されます。
+
+## ハンドオフ
+
+ハンドオフは、エージェントが委譲できるサブエージェントです。ハンドオフのリストを提供すると、エージェントは関連する場合にそれらへ委譲できます。これは、単一タスクに特化したモジュール型エージェントをオーケストレーションする強力なパターンです。詳しくは [handoffs](handoffs.md) ドキュメントをご覧ください。
+
+```python
+from agents import Agent
+
+booking_agent = Agent(...)
+refund_agent = Agent(...)
+
+triage_agent = Agent(
+    name="Triage agent",
+    instructions=(
+        "Help the user with their questions."
+        "If they ask about booking, handoff to the booking agent."
+        "If they ask about refunds, handoff to the refund agent."
+    ),
+    handoffs=[booking_agent, refund_agent],
+)
+```
+
+## 動的 instructions
+
+通常はエージェント作成時に instructions を渡しますが、関数を通じて動的に渡すこともできます。この関数はエージェントと context を受け取り、プロンプトを返さなければなりません。同期関数と `async` 関数の両方を使用できます。
+
+```python
+def dynamic_instructions(
+    context: RunContextWrapper[UserContext], agent: Agent[UserContext]
+) -> str:
+    return f"The user's name is {context.context.name}. Help them with their questions."
+
+
+agent = Agent[UserContext](
+    name="Triage agent",
+    instructions=dynamic_instructions,
+)
+```
+
+## ライフサイクルイベント (フック)
+
+エージェントのライフサイクルを監視したい場合があります。たとえば、イベントをログに記録したり、特定のイベント発生時にデータをプリフェッチしたりするケースです。`hooks` プロパティを使ってエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] をサブクラス化し、関心のあるメソッドをオーバーライドしてください。
+
+## ガードレール
+
+ガードレールを使うと、エージェント実行と並行してユーザー入力に対するチェックやバリデーションを実行できます。たとえば、ユーザー入力の関連性をスクリーニングすることが可能です。詳細は [guardrails](guardrails.md) ドキュメントをご覧ください。
+
+## エージェントのクローン／コピー
+
+エージェントの `clone()` メソッドを使うと、エージェントを複製し、任意のプロパティを変更できます。
+
+```python
+pirate_agent = Agent(
+    name="Pirate",
+    instructions="Write like a pirate",
+    model="o3-mini",
+)
+
+robot_agent = pirate_agent.clone(
+    name="Robot",
+    instructions="Write like a robot",
+)
+```
+
+## ツール使用の強制
+
+ツールのリストを渡しても、必ずしも LLM がツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定するとツール使用を強制できます。有効な値は次のとおりです。
+
+1. `auto` : LLM がツールを使用するかどうかを自動で判断します。
+2. `required` : LLM にツール使用を必須とします (使用するツールはインテリジェントに決定)。
+3. `none` : LLM にツールを使用しないことを要求します。
+4. 具体的な文字列 (例: `my_tool`) を設定すると、そのツールを必ず使用させます。
+
+```python
+from agents import Agent, Runner, function_tool, ModelSettings
+
+@function_tool
+def get_weather(city: str) -> str:
+    """Returns weather info for the specified city."""
+    return f"The weather in {city} is sunny"
+
+agent = Agent(
+    name="Weather Agent",
+    instructions="Retrieve weather details.",
+    tools=[get_weather],
+    model_settings=ModelSettings(tool_choice="get_weather") 
+)
+```
+
+## ツール使用の挙動
+
+`Agent` の `tool_use_behavior` パラメーターはツール出力の扱い方を制御します。
+
+- `"run_llm_again"`: デフォルト設定。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
+- `"stop_on_first_tool"`: 最初に呼び出されたツールの出力をそのまま最終応答として使用し、追加の LLM 処理を行いません。
+
+```python
+from agents import Agent, Runner, function_tool, ModelSettings
+
+@function_tool
+def get_weather(city: str) -> str:
+    """Returns weather info for the specified city."""
+    return f"The weather in {city} is sunny"
+
+agent = Agent(
+    name="Weather Agent",
+    instructions="Retrieve weather details.",
+    tools=[get_weather],
+    tool_use_behavior="stop_on_first_tool"
+)
+```
+
+- `StopAtTools(stop_at_tool_names=[...])`: 指定したツールのいずれかが呼び出されると停止し、その出力を最終応答とします。  
+```python
+from agents import Agent, Runner, function_tool
+from agents.agent import StopAtTools
+
+@function_tool
+def get_weather(city: str) -> str:
+    """Returns weather info for the specified city."""
+    return f"The weather in {city} is sunny"
+
+@function_tool
+def sum_numbers(a: int, b: int) -> int:
+    """Adds two numbers."""
+    return a + b
+
+agent = Agent(
+    name="Stop At Stock Agent",
+    instructions="Get weather or sum numbers.",
+    tools=[get_weather, sum_numbers],
+    tool_use_behavior=StopAtTools(stop_at_tool_names=["get_weather"])
+)
+```
+- `ToolsToFinalOutputFunction`: ツール結果を処理し、停止するか LLM を続行するかを決定するカスタム関数。  
+
+```python
+from agents import Agent, Runner, function_tool, FunctionToolResult, RunContextWrapper
+from agents.agent import ToolsToFinalOutputResult
+from typing import List, Any
+
+@function_tool
+def get_weather(city: str) -> str:
+    """Returns weather info for the specified city."""
+    return f"The weather in {city} is sunny"
+
+def custom_tool_handler(
+    context: RunContextWrapper[Any],
+    tool_results: List[FunctionToolResult]
+) -> ToolsToFinalOutputResult:
+    """Processes tool results to decide final output."""
+    for result in tool_results:
+        if result.output and "sunny" in result.output:
+            return ToolsToFinalOutputResult(
+                is_final_output=True,
+                final_output=f"Final weather: {result.output}"
+            )
+    return ToolsToFinalOutputResult(
+        is_final_output=False,
+        final_output=None
+    )
+
+agent = Agent(
+    name="Weather Agent",
+    instructions="Retrieve weather details.",
+    tools=[get_weather],
+    tool_use_behavior=custom_tool_handler
+)
+```
+
+!!! note
+
+    無限ループを防ぐため、フレームワークはツール呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この挙動は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定できます。ツール結果が LLM に送られ、その後 `tool_choice` により再度ツール呼び出しが生成され…という無限ループを防止するためです。

openai_agents-0.2.6/docs/ja/config.md

@@ -0,0 +1,98 @@
+---
+search:
+  exclude: true
+---
+# SDK の設定
+
+## API キーとクライアント
+
+デフォルトでは、SDK をインポートした直後から、LLM リクエストとトレーシングに使用する環境変数 `OPENAI_API_KEY` を参照します。アプリ起動前にこの環境変数を設定できない場合は、[set_default_openai_key()][agents.set_default_openai_key] 関数でキーを設定できます。
+
+```python
+from agents import set_default_openai_key
+
+set_default_openai_key("sk-...")
+```
+
+また、使用する OpenAI クライアントを個別に設定することも可能です。デフォルトでは、SDK は環境変数または上記で設定したデフォルトキーを用いて `AsyncOpenAI` インスタンスを生成します。[set_default_openai_client()][agents.set_default_openai_client] 関数を使うことで、この設定を変更できます。
+
+```python
+from openai import AsyncOpenAI
+from agents import set_default_openai_client
+
+custom_client = AsyncOpenAI(base_url="...", api_key="...")
+set_default_openai_client(custom_client)
+```
+
+さらに、使用する OpenAI API もカスタマイズできます。デフォルトでは OpenAI Responses API を利用しますが、[set_default_openai_api()][agents.set_default_openai_api] 関数を使用して Chat Completions API に切り替えられます。
+
+```python
+from agents import set_default_openai_api
+
+set_default_openai_api("chat_completions")
+```
+
+## トレーシング
+
+トレーシングはデフォルトで有効です。上記セクションで説明した OpenAI API キー（環境変数または設定したデフォルトキー）が使用されます。トレーシング専用の API キーを指定したい場合は、[`set_tracing_export_api_key`][agents.set_tracing_export_api_key] 関数を利用してください。
+
+```python
+from agents import set_tracing_export_api_key
+
+set_tracing_export_api_key("sk-...")
+```
+
+トレーシングを完全に無効にする場合は、[`set_tracing_disabled()`][agents.set_tracing_disabled] 関数を使用します。
+
+```python
+from agents import set_tracing_disabled
+
+set_tracing_disabled(True)
+```
+
+## デバッグ ロギング
+
+SDK にはハンドラーが設定されていない Python ロガーが 2 つあります。デフォルトでは、警告とエラーは `stdout` に送られますが、それ以外のログは抑制されます。
+
+詳細なロギングを有効にするには、[`enable_verbose_stdout_logging()`][agents.enable_verbose_stdout_logging] 関数を使用します。
+
+```python
+from agents import enable_verbose_stdout_logging
+
+enable_verbose_stdout_logging()
+```
+
+ログを独自にカスタマイズしたい場合は、ハンドラー、フィルター、フォーマッターなどを追加できます。詳細は [Python logging guide](https://docs.python.org/3/howto/logging.html) を参照してください。
+
+```python
+import logging
+
+logger = logging.getLogger("openai.agents") # or openai.agents.tracing for the Tracing logger
+
+# To make all logs show up
+logger.setLevel(logging.DEBUG)
+# To make info and above show up
+logger.setLevel(logging.INFO)
+# To make warning and above show up
+logger.setLevel(logging.WARNING)
+# etc
+
+# You can customize this as needed, but this will output to `stderr` by default
+logger.addHandler(logging.StreamHandler())
+```
+
+### ログ内の機密データ
+
+一部のログには機密データ（例：ユーザーデータ）が含まれる場合があります。こうしたデータの出力を無効にしたい場合は、以下の環境変数を設定してください。
+
+LLM の入力と出力のロギングを無効にする:
+
+```bash
+export OPENAI_AGENTS_DONT_LOG_MODEL_DATA=1
+```
+
+ツールの入力と出力のロギングを無効にする:
+
+```bash
+export OPENAI_AGENTS_DONT_LOG_TOOL_DATA=1
+```

openai_agents-0.2.6/docs/ja/context.md

@@ -0,0 +1,82 @@
+---
+search:
+  exclude: true
+---
+# コンテキスト管理
+
+コンテキストという語は多義的です。ここでは、気に掛けるべきコンテキストには大きく 2 つのクラスがあります。
+
+1. コードでローカルに利用できるコンテキスト: これは、tool 関数の実行時や `on_handoff` のようなコールバック、ライフサイクルフック内などで必要になるデータや依存関係です。  
+2. LLM が利用できるコンテキスト: これは、LLM が応答を生成する際に参照できるデータです。
+
+## ローカルコンテキスト
+
+ローカルコンテキストは [`RunContextWrapper`][agents.run_context.RunContextWrapper] クラスと、その中の [`context`][agents.run_context.RunContextWrapper.context] プロパティで表現されます。動作の流れは次のとおりです:
+
+1. 任意の Python オブジェクトを作成します。一般的には dataclass や Pydantic オブジェクトを使うパターンが多いです。  
+2. そのオブジェクトを各種 run メソッド（例: `Runner.run(..., **context=whatever**)`）に渡します。  
+3. すべての tool 呼び出しやライフサイクルフックなどには `RunContextWrapper[T]` が渡されます。ここで `T` は作成したコンテキストオブジェクトの型で、`wrapper.context` からアクセスできます。  
+
+ **最も重要なのは**、同一のエージェント実行内では、エージェント・tool 関数・ライフサイクルフックなどがすべて同じ _型_ のコンテキストを使う必要があるという点です。
+
+コンテキストは次のような用途に利用できます。
+
+- 実行のためのコンテキストデータ（例: username/uid などユーザーに関する情報）  
+- 依存関係（例: logger オブジェクトやデータフェッチャーなど）  
+- ヘルパー関数  
+
+!!! danger "Note"
+
+    コンテキストオブジェクトは **送信されません** LLM へ。これは純粋にローカルオブジェクトで、読み書きやメソッド呼び出しを自由に行えます。
+
+```python
+import asyncio
+from dataclasses import dataclass
+
+from agents import Agent, RunContextWrapper, Runner, function_tool
+
+@dataclass
+class UserInfo:  # (1)!
+    name: str
+    uid: int
+
+@function_tool
+async def fetch_user_age(wrapper: RunContextWrapper[UserInfo]) -> str:  # (2)!
+    """Fetch the age of the user. Call this function to get user's age information."""
+    return f"The user {wrapper.context.name} is 47 years old"
+
+async def main():
+    user_info = UserInfo(name="John", uid=123)
+
+    agent = Agent[UserInfo](  # (3)!
+        name="Assistant",
+        tools=[fetch_user_age],
+    )
+
+    result = await Runner.run(  # (4)!
+        starting_agent=agent,
+        input="What is the age of the user?",
+        context=user_info,
+    )
+
+    print(result.final_output)  # (5)!
+    # The user John is 47 years old.
+
+if __name__ == "__main__":
+    asyncio.run(main())
+```
+
+1. これはコンテキストオブジェクトです。ここでは dataclass を使っていますが、任意の型を利用できます。  
+2. これは tool です。`RunContextWrapper[UserInfo]` を受け取り、その実装でコンテキストを読み取ります。  
+3. ジェネリック型 `UserInfo` でエージェントをマークすることで、型チェッカーがエラーを検出できます（例えば、異なるコンテキスト型を受け取る tool を渡そうとした場合）。  
+4. `run` 関数にコンテキストが渡されます。  
+5. エージェントは tool を正しく呼び出し、年齢を取得します。  
+
+## エージェント／LLM コンテキスト
+
+LLM が呼び出されたとき、LLM が参照できる **唯一の** データは会話履歴に含まれるものだけです。そのため、新しいデータを LLM に利用させたい場合は、そのデータを履歴に含める形で提供する必要があります。主な方法は次のとおりです。
+
+1. Agent の `instructions` に追加する。これは「system prompt」や「developer message」とも呼ばれます。system prompt は静的な文字列でも、コンテキストを受け取って文字列を返す動的な関数でもかまいません。たとえばユーザー名や現在の日付など、常に有用な情報を渡す一般的な方法です。  
+2. `Runner.run` を呼び出す際の `input` に追加する。`instructions` と似ていますが、[指揮系統](https://cdn.openai.com/spec/model-spec-2024-05-08.html#follow-the-chain-of-command) の下位メッセージとして渡せる点が異なります。  
+3. function tools を介して公開する。これは *オンデマンド* のコンテキストに便利です。LLM が必要になったタイミングで tool を呼び出し、データを取得できます。  
+4. retrieval や Web 検索を利用する。これらはファイルやデータベースから関連データを取得する retrieval、あるいは Web から取得する Web 検索といった特別なツールです。関連コンテキストデータで応答を「グラウンディング」するのに役立ちます。

openai_agents-0.2.6/docs/ja/examples.md

@@ -0,0 +1,47 @@
+---
+search:
+  exclude: true
+---
+# コード例
+
+[リポジトリ](https://github.com/openai/openai-agents-python/tree/main/examples) の examples セクションでは、 SDK のさまざまなサンプル実装をご覧いただけます。これらのコード例は、異なるパターンや機能を示す複数のカテゴリーに整理されています。
+
+## カテゴリー
+
+- **[agent_patterns](https://github.com/openai/openai-agents-python/tree/main/examples/agent_patterns)** :
+  このカテゴリーでは、一般的な エージェント 設計パターンを紹介しています。
+
+    - 決定論的ワークフロー  
+    - ツールとしての エージェント  
+    - エージェント の並列実行  
+
+- **[basic](https://github.com/openai/openai-agents-python/tree/main/examples/basic)** :
+  ここでは、 SDK の基本的な機能を取り上げています。
+
+    - 動的な system prompt  
+    - ストリーミング 出力  
+    - ライフサイクルイベント  
+
+- **[tool examples](https://github.com/openai/openai-agents-python/tree/main/examples/tools)** :
+  Web 検索 や ファイル検索 など、 OpenAI がホストするツールの実装方法と、それらを エージェント に統合する方法を学べます。
+
+- **[model_providers](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers)** :
+  OpenAI 以外のモデルを SDK で利用する方法を探ります。
+
+- **[handoffs](https://github.com/openai/openai-agents-python/tree/main/examples/handoffs)** :
+  エージェント のハンドオフの実践的な例をご覧いただけます。
+
+- **[mcp](https://github.com/openai/openai-agents-python/tree/main/examples/mcp)** :
+  MCP を使用して エージェント を構築する方法を学びます。
+
+- **[customer_service](https://github.com/openai/openai-agents-python/tree/main/examples/customer_service)** と **[research_bot](https://github.com/openai/openai-agents-python/tree/main/examples/research_bot)** :
+  実際のユースケースを想定した、より作り込まれた 2 つの例
+
+    - **customer_service** : 航空会社向けカスタマーサービスシステムの例。  
+    - **research_bot** : シンプルな ディープリサーチ クローン。  
+
+- **[voice](https://github.com/openai/openai-agents-python/tree/main/examples/voice)** :
+  TTS と STT モデルを利用した音声 エージェント の例をご覧ください。
+
+- **[realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime)** :
+  SDK を使って Realtime API の体験を構築する方法を示す例。

{openai_agents-0.2.4 → openai_agents-0.2.6}/docs/ja/guardrails.md

@@ -4,44 +4,44 @@ search:
 ---
 # ガードレール
 
-ガードレールはエージェントと _並列_ に実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、非常に賢い（つまり遅く／高価な）モデルを使ってカスタマーリクエストに対応するエージェントがあるとします。悪意のあるユーザーがモデルに数学の宿題を手伝わせようとするのは避けたいでしょう。そこで、速く／安価なモデルを使ってガードレールを実行できます。ガードレールが悪意のある利用を検知した場合、即座にエラーを送出し、高価なモデルの実行を停止して時間とコストを節約します。
+ガードレールはエージェントと _並列_ に実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、とても賢い (そのため遅く / 高価な) モデルを使用してカスタマーリクエストを処理するエージェントがあるとします。悪意のあるユーザーがモデルに数学の宿題を手伝わせようとした場合は避けたいでしょう。そこで、速く / 低コストなモデルで動くガードレールを実行できます。ガードレールが悪意ある利用を検知したら、直ちにエラーを発生させることで高価なモデルの実行を止め、時間とお金を節約できます。
 
-ガードレールには 2 種類あります。
+ガードレールには 2 つの種類があります:
 
-1. 入力ガードレール: 最初のユーザー入力に対して実行されます  
-2. 出力ガードレール: 最終的なエージェント出力に対して実行されます  
+1. 入力ガードレールは最初のユーザー入力に対して実行されます  
+2. 出力ガードレールはエージェントの最終出力に対して実行されます  
 
 ## 入力ガードレール
 
-入力ガードレールは 3 つのステップで実行されます。
+入力ガードレールは 3 ステップで実行されます:
 
 1. まず、ガードレールはエージェントに渡されたものと同じ入力を受け取ります。  
-2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、それが [`InputGuardrailResult`][agents.guardrail.InputGuardrailResult] でラップされます。  
-3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。true の場合は [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered] 例外が送出されるため、ユーザーへの応答や例外処理を適切に行えます。  
+2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、これを [`InputGuardrailResult`][agents.guardrail.InputGuardrailResult] でラップします。  
+3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が `true` かどうかを確認します。`true` の場合は [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered] 例外が発生し、ユーザーへの適切な応答や例外処理を行えます。  
 
 !!! Note
 
-    入力ガードレールはユーザー入力に対して実行されることを想定しているため、エージェントが *最初* のエージェントである場合にのみ実行されます。`guardrails` プロパティが `Runner.run` の引数ではなくエージェントにあるのはなぜでしょうか? それは、ガードレールが実際のエージェントに密接に関連しているからです。エージェントごとに異なるガードレールを実行するため、コードを同じ場所に置いておくと可読性が向上します。
+    入力ガードレールはユーザー入力に対して実行されることを想定しているため、エージェントが *最初の* エージェントである場合にのみガードレールが実行されます。`guardrails` プロパティがエージェントにあるのはなぜか、`Runner.run` に渡さないのはなぜかと思われるかもしれません。これは、ガードレールが実際のエージェントに関連する傾向があるためです。エージェントごとに異なるガードレールを実行するため、コードを同じ場所に置くことで読みやすさが向上します。
 
 ## 出力ガードレール
 
-出力ガードレールは 3 つのステップで実行されます。
+出力ガードレールは 3 ステップで実行されます:
 
 1. まず、ガードレールはエージェントが生成した出力を受け取ります。  
-2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、それが [`OutputGuardrailResult`][agents.guardrail.OutputGuardrailResult] でラップされます。  
-3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。true の場合は [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered] 例外が送出されるため、ユーザーへの応答や例外処理を適切に行えます。  
+2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、これを [`OutputGuardrailResult`][agents.guardrail.OutputGuardrailResult] でラップします。  
+3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が `true` かどうかを確認します。`true` の場合は [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered] 例外が発生し、ユーザーへの適切な応答や例外処理を行えます。  
 
 !!! Note
 
-    出力ガードレールは最終的なエージェント出力に対して実行されることを想定しているため、エージェントが *最後* のエージェントである場合にのみ実行されます。入力ガードレールと同様、ガードレールは実際のエージェントに密接に関連しているため、ガードレールのコードを同じ場所に置くことで可読性が向上します。
+    出力ガードレールはエージェントの最終出力に対して実行されることを想定しているため、エージェントが *最後の* エージェントである場合にのみガードレールが実行されます。入力ガードレールと同様に、ガードレールは実際のエージェントに関連する傾向があるため、コードを同じ場所に置くことで読みやすさが向上します。
 
-## トリップワイヤー
+## トリップワイヤ
 
-入力または出力がガードレールを通過できなかった場合、ガードレールはトリップワイヤーでそれを示します。トリップワイヤーを発動したガードレールが検知され次第、ただちに `{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
+入力または出力がガードレールに失敗した場合、ガードレールはトリップワイヤを用いてそれを示します。トリップワイヤが作動したガードレールを検知するとすぐに、`{Input,Output}GuardrailTripwireTriggered` 例外を発生させ、エージェントの実行を停止します。
 
 ## ガードレールの実装
 
-入力を受け取り [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。この例では、内部でエージェントを実行することでこれを実現します。
+入力を受け取り、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。以下の例では、その処理を内部でエージェントを実行することで行っています。
 
 ```python
 from pydantic import BaseModel
@@ -95,9 +95,9 @@ async def main():
 ```
 
 1. このエージェントをガードレール関数内で使用します。  
-2. これはエージェントの入力／コンテキストを受け取り、結果を返すガードレール関数です。  
-3. ガードレール結果に追加情報を含めることができます。  
-4. これがワークフローを定義する実際のエージェントです。  
+2. これはエージェントの入力 / コンテキストを受け取り、結果を返すガードレール関数です。  
+3. ガードレールの結果に追加情報を含めることができます。  
+4. これはワークフローを定義する実際のエージェントです。  
 
 出力ガードレールも同様です。
 
@@ -155,4 +155,4 @@ async def main():
 1. これは実際のエージェントの出力型です。  
 2. これはガードレールの出力型です。  
 3. これはエージェントの出力を受け取り、結果を返すガードレール関数です。  
-4. これがワークフローを定義する実際のエージェントです。
+4. これはワークフローを定義する実際のエージェントです。