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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openai-agents
-Version: 0.2.4
+Version: 0.2.5
 Summary: OpenAI Agents SDK
 Project-URL: Homepage, https://openai.github.io/openai-agents-python/
 Project-URL: Repository, https://github.com/openai/openai-agents-python
@@ -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.5}/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.5}/docs/ja/agents.md

@@ -4,16 +4,16 @@ search:
 ---
 # エージェント
 
-エージェントはアプリの中心的な構成要素です。エージェントとは、指示とツールで構成された大規模言語モデル（ LLM ）です。
+エージェントはアプリのコアとなる構成要素です。エージェントとは、 instructions と tools で設定された大規模言語モデル ( LLM ) です。
 
 ## 基本設定
 
-エージェントを設定する際によく使うプロパティは次のとおりです。
+最も一般的に設定するプロパティは次のとおりです。
 
 - `name`: エージェントを識別する必須の文字列です。  
-- `instructions`: 開発者メッセージ、またはシステムプロンプトとも呼ばれます。  
-- `model`: 使用する LLM と、`temperature`、`top_p` などのモデル調整用パラメーターを設定する任意の `model_settings`。  
-- `tools`: エージェントがタスクを達成するために利用できるツール群です。  
+- `instructions`: developer message または system prompt とも呼ばれます。  
+- `model`: 使用する LLM と、 temperature や top_p などのモデル調整パラメーターを指定できる `model_settings` ( 任意 )。  
+- `tools`: エージェントがタスクを達成するために使用できる tools です。
 
 ```python
 from agents import Agent, ModelSettings, function_tool
@@ -33,7 +33,7 @@ agent = Agent(
 
 ## コンテキスト
 
-エージェントは `context` 型を汎用的に扱います。コンテキストは依存性注入のためのツールで、`Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、エージェント実行時の依存関係や状態をまとめて保持します。任意の Python オブジェクトをコンテキストとして提供できます。
+エージェントは `context` の型がジェネリックです。 context は依存性注入のためのツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、 tool、 handoff などに渡され、依存関係や実行時の状態をまとめて保持します。 context には任意の Python オブジェクトを渡せます。
 
 ```python
 @dataclass
@@ -52,7 +52,7 @@ agent = Agent[UserContext](
 
 ## 出力タイプ
 
-デフォルトでは、エージェントはプレーンテキスト（`str`）を出力します。特定の型で出力させたい場合は `output_type` パラメーターを使用します。一般的には [Pydantic](https://docs.pydantic.dev/) オブジェクトを指定しますが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型（ dataclass、リスト、TypedDict など）であれば利用できます。
+デフォルトでは、エージェントはプレーンテキスト ( つまり `str` ) を出力します。特定の型で出力させたい場合は `output_type` パラメーターを使用します。一般的には [Pydantic](https://docs.pydantic.dev/) オブジェクトを使いますが、 dataclass や list、 TypedDict など、 Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型なら何でも対応しています。
 
 ```python
 from pydantic import BaseModel
@@ -73,11 +73,11 @@ agent = Agent(
 
 !!! note
 
-    `output_type` を渡すと、モデルは通常のプレーンテキスト応答ではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用するようになります。
+    `output_type` を渡すと、モデルは通常のプレーンテキストではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を利用して応答します。
 
 ## ハンドオフ
 
-ハンドオフは、エージェントが委譲できるサブエージェントです。ハンドオフのリストを渡すと、エージェントは必要に応じてそれらに委譲します。これにより、単一タスクに特化したモジュール型のエージェントをオーケストレーションする強力なパターンが実現します。詳細は [handoffs](handoffs.md) ドキュメントをご覧ください。
+ハンドオフは、エージェントが委任できるサブエージェントです。 handoffs のリストを渡すと、エージェントは必要に応じてそれらに委任できます。これは、単一タスクに特化したモジュール化されたエージェントを編成する強力なパターンです。詳細は [ハンドオフ](handoffs.md) ドキュメントをご覧ください。
 
 ```python
 from agents import Agent
@@ -98,7 +98,7 @@ triage_agent = Agent(
 
 ## 動的インストラクション
 
-多くの場合、エージェント作成時に instructions を指定しますが、関数を通じて動的に instructions を提供することも可能です。その関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方を使用できます。
+多くの場合、エージェント作成時に instructions を渡しますが、関数を介して動的に instructions を生成することもできます。この関数は agent と context を受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方に対応しています。
 
 ```python
 def dynamic_instructions(
@@ -113,15 +113,15 @@ agent = Agent[UserContext](
 )
 ```
 
-## ライフサイクルイベント（フック）
+## ライフサイクルイベント ( hooks )
 
-エージェントのライフサイクルを監視したい場合があります。たとえば、イベントをログに記録したり、特定のイベント発生時にデータを事前取得したりできます。`hooks` プロパティを使ってエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、必要なメソッドをオーバーライドしてください。
+エージェントのライフサイクルを監視したい場合があります。たとえば、イベントをログに記録したり、特定のイベント発生時にデータを事前取得したりできます。 `hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスを継承し、必要なメソッドをオーバーライドしてください。
 
 ## ガードレール
 
-ガードレールを使用すると、エージェント実行と並行してユーザー入力に対するチェックやバリデーションを実行できます。たとえば、ユーザー入力の関連性をスクリーニングすることが可能です。詳細は [guardrails](guardrails.md) ドキュメントをご覧ください。
+ガードレールを使うと、エージェント実行と並行してユーザー入力のチェックやバリデーションを実行できます。たとえば、ユーザー入力を関連性でフィルタリングするなどが可能です。詳細は [guardrails](guardrails.md) ドキュメントをご覧ください。
 
-## エージェントのクローン／コピー
+## エージェントのクローン / コピー
 
 エージェントの `clone()` メソッドを使用すると、エージェントを複製し、任意のプロパティを変更できます。
 
@@ -138,14 +138,14 @@ robot_agent = pirate_agent.clone(
 )
 ```
 
-## ツール使用の強制
+## ツール利用の強制
 
-ツールをリストで渡しても、必ずしも LLM がツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定することでツール使用を強制できます。利用可能な値は次のとおりです。
+tools のリストを渡しても、 LLM が必ずしも tool を利用するとは限りません。 [`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定してツール利用を強制できます。使用可能な値は次のとおりです。
 
-1. `auto`: LLM がツールを使用するか否かを決定します。  
-2. `required`: LLM にツールの使用を必須とします（どのツールを使用するかは自動で選択）。  
-3. `none`: LLM にツールを使用しないことを要求します。  
-4. 特定の文字列（例: `my_tool`）を設定すると、そのツールを必ず使用します。  
+1. `auto` : LLM が tool を使うかどうかを決定します。  
+2. `required` : LLM に tool の使用を必須にします ( どの tool を使うかは自動で判断 )。  
+3. `none` : LLM に tool を _使わない_ ことを要求します。  
+4. 具体的な文字列 ( 例: `my_tool` ) を指定すると、その特定の tool の使用を要求します。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -163,11 +163,11 @@ agent = Agent(
 )
 ```
 
-## ツール使用時の挙動
+## ツール利用の挙動
 
-`Agent` の `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。
-- `"run_llm_again"`: デフォルト。ツールを実行後、その結果を LLM が処理して最終応答を生成します。  
-- `"stop_on_first_tool"`: 最初のツール呼び出しの出力を最終応答として使用し、以降の LLM 処理は行いません。  
+`Agent` の `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。  
+- `"run_llm_again"` : 既定値。 tool を実行し、その結果を LLM が処理して最終応答を生成します。  
+- `"stop_on_first_tool"` : 最初の tool 呼び出しの出力を最終応答として使用し、追加の LLM 処理は行いません。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -185,7 +185,7 @@ agent = Agent(
 )
 ```
 
-- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかのツールが呼び出された時点で停止し、そのツールの出力を最終応答として使用します。  
+- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかの tool が呼び出された時点で停止し、その出力を最終応答として使用します。  
 ```python
 from agents import Agent, Runner, function_tool
 from agents.agent import StopAtTools
@@ -207,7 +207,7 @@ agent = Agent(
     tool_use_behavior=StopAtTools(stop_at_tool_names=["get_weather"])
 )
 ```
-- `ToolsToFinalOutputFunction`: ツール結果を処理し、停止するか LLM 継続かを決定するカスタム関数です。  
+- `ToolsToFinalOutputFunction`: tool の結果を処理し、 LLM を続行するか停止するかを判断するカスタム関数です。
 
 ```python
 from agents import Agent, Runner, function_tool, FunctionToolResult, RunContextWrapper
@@ -245,4 +245,4 @@ agent = Agent(
 
 !!! note
 
-    無限ループを防ぐため、ツール呼び出し後にフレームワークは自動的に `tool_choice` を "auto" にリセットします。この挙動は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。ツール結果が LLM に送られるたびに `tool_choice` により再度ツール呼び出しが発生し、無限に続く可能性があるためです。
+    無限ループを防ぐため、フレームワークは tool 呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この動作は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。ツール結果が LLM に送られ、その後 `tool_choice` により再度ツール呼び出しが生成されることで無限ループが発生するためです。

openai_agents-0.2.5/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.5/docs/ja/context.md

@@ -0,0 +1,82 @@
+---
+search:
+  exclude: true
+---
+# コンテキスト管理
+
+コンテキストという語は多義的です。ここでは主に 2 つのコンテキスト クラスが存在します。
+
+1. コード側でローカルに利用できるコンテキスト: ツール関数の実行時や `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. すべてのツール呼び出しやライフサイクル フックには `RunContextWrapper[T]` 型のラッパー オブジェクトが渡されます。ここで `T` はコンテキスト オブジェクトの型で、`wrapper.context` からアクセスできます。
+
+**最重要ポイント**: 1 回のエージェント実行において、エージェント本体・ツール関数・ライフサイクル フックなどはすべて同じ _型_ のコンテキストを使用しなければなりません。
+
+コンテキストは次のような用途で利用できます。
+
+-   実行に関連するデータ（例: username/uid などユーザーに関する情報）  
+-   依存オブジェクト（例: ロガーやデータフェッチャーなど）  
+-   ヘルパー関数  
+
+!!! 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. これはツールです。`RunContextWrapper[UserInfo]` を受け取り、実装内でコンテキストを参照しています。  
+3. エージェントにジェネリック型 `UserInfo` を指定することで、型チェッカーがエラーを検出できます（例えば異なるコンテキスト型を取るツールを渡そうとした場合など）。  
+4. `run` 関数にコンテキストを渡します。  
+5. エージェントは正しくツールを呼び出し、年齢を取得します。  
+
+## エージェント / LLM コンテキスト
+
+LLM が呼び出される際、LLM が参照できるデータは **会話履歴だけ** です。そのため、新しいデータを LLM が利用できるようにするには、履歴に追加する形で渡す必要があります。主な方法は次のとおりです。
+
+1. Agent の `instructions` に追加する。これは「system prompt」や「developer message」とも呼ばれます。システム プロンプトは静的な文字列でも、コンテキストを受け取って文字列を返す動的関数でも構いません。常に有用な情報（例: ユーザー名や現在の日付）を渡す際によく用いられます。  
+2. `Runner.run` を呼び出す際の `input` に追加する。`instructions` と似ていますが、[chain of command](https://cdn.openai.com/spec/model-spec-2024-05-08.html#follow-the-chain-of-command) の下位にメッセージを配置できる点が異なります。  
+3. 関数ツール経由で公開する。これはオンデマンド コンテキストに適しており、LLM が必要に応じてツールを呼び出してデータを取得できます。  
+4. Retrieval や Web 検索を使う。これらはファイルやデータベース（retrieval）あるいは Web（Web 検索）から関連データを取得できる特別なツールです。応答を適切なコンテキスト データに基づいて「グラウンディング」する際に有効です。

{openai_agents-0.2.4 → openai_agents-0.2.5}/docs/ja/examples.md

@@ -2,46 +2,44 @@
 search:
   exclude: true
 ---
-# サンプル
+# コード例
+
+[repo](https://github.com/openai/openai-agents-python/tree/main/examples) の examples セクションには、SDK のさまざまなサンプル実装が用意されています。これらのコード例は、異なるパターンや機能を示す複数のカテゴリーに整理されています。
 
-[`repo`](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 の基礎的な機能を紹介します。例:
-
+  SDK の基礎的な機能を示すコード例です。  
     - 動的な system prompt  
     - ストリーミング出力  
     - ライフサイクルイベント  
 
 - **[tool examples](https://github.com/openai/openai-agents-python/tree/main/examples/tools):**  
-  Web 検索やファイル検索など、OpenAI がホストするツールの実装方法と、それらをエージェントに統合する方法を学べます。
+  Web 検索やファイル検索といった OpenAI がホストするツールの実装方法と、それらをエージェントに統合する方法を学べます。
 
 - **[model providers](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers):**  
-  OpenAI 以外のモデルを SDK と共に利用する方法を探ることができます。
+  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 を用いたエージェントの構築方法を学べます。
+  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 つの例:
-
+  実際のユースケースを想定した、より発展的な 2 つのコード例です。  
     - **customer_service**: 航空会社向けカスタマーサービスシステムの例。  
-    - **research_bot**: シンプルなディープリサーチ クローン。  
+    - **research_bot**: シンプルなディープリサーチクローン。  
 
 - **[voice](https://github.com/openai/openai-agents-python/tree/main/examples/voice):**  
-  TTS と STT モデルを使用した音声エージェントの例を確認できます。
+  TTS と STT モデルを用いた音声エージェントのコード例です。
 
 - **[realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime):**  
-  SDK を用いたリアルタイム体験の構築方法を示す例です。
+  SDK を使用してリアルタイム体験を構築する方法を示すコード例です。

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

@@ -4,44 +4,47 @@ search:
 ---
 # ガードレール
 
-ガードレールはエージェントと _並列_ に実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、非常に賢い（つまり遅く／高価な）モデルを使ってカスタマーリクエストに対応するエージェントがあるとします。悪意のあるユーザーがモデルに数学の宿題を手伝わせようとするのは避けたいでしょう。そこで、速く／安価なモデルを使ってガードレールを実行できます。ガードレールが悪意のある利用を検知した場合、即座にエラーを送出し、高価なモデルの実行を停止して時間とコストを節約します。
+ガードレールはエージェントと _並列で_ 実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、顧客からのリクエストを支援するために、とても賢い（そのぶん遅く／高価な）モデルを利用するエージェントがあるとします。このとき、悪意のあるユーザーがそのモデルに数学の宿題を手伝わせようとするのは避けたいでしょう。そこで、高速かつ低コストのモデルでガードレールを実行できます。ガードレールが悪意のある利用を検知すると、ただちにエラーを送出して高価なモデルの実行を停止し、時間とコストを節約できます。
 
-ガードレールには 2 種類あります。
+ガードレールには 2 種類あります:
 
-1. 入力ガードレール: 最初のユーザー入力に対して実行されます  
-2. 出力ガードレール: 最終的なエージェント出力に対して実行されます  
+1. Input guardrails は最初のユーザー入力に対して実行されます  
+2. Output guardrails は最終的なエージェント出力に対して実行されます
 
-## 入力ガードレール
+## Input guardrails
 
-入力ガードレールは 3 つのステップで実行されます。
+Input guardrails は 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` の引数ではなくエージェントにあるのはなぜでしょうか? それは、ガードレールが実際のエージェントに密接に関連しているからです。エージェントごとに異なるガードレールを実行するため、コードを同じ場所に置いておくと可読性が向上します。
+    Input guardrails はユーザー入力に対して実行することを想定しているため、エージェントが *最初の* エージェントである場合のみ実行されます。  
+    ところで、`guardrails` プロパティが `Runner.run` に渡されるのではなくエージェントにあるのはなぜでしょうか？  
+    それは、ガードレールが実際のエージェントに密接に関係していることが多いからです。異なるエージェントには異なるガードレールを実行したいので、同じ場所にコードを置くと可読性が向上します。
 
-## 出力ガードレール
+## Output guardrails
 
-出力ガードレールは 3 つのステップで実行されます。
+Output guardrails も 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
 
-    出力ガードレールは最終的なエージェント出力に対して実行されることを想定しているため、エージェントが *最後* のエージェントである場合にのみ実行されます。入力ガードレールと同様、ガードレールは実際のエージェントに密接に関連しているため、ガードレールのコードを同じ場所に置くことで可読性が向上します。
+    Output guardrails は最終的なエージェント出力に対して実行することを想定しているため、エージェントが *最後の* エージェントである場合のみ実行されます。  
+    Input guardrails と同様に、ガードレールは実際のエージェントに密接に関係しているため、異なるエージェントには異なるガードレールを実行したいという理由から、コードを同じ場所に置くと可読性が向上します。
 
-## トリップワイヤー
+## Tripwires
 
-入力または出力がガードレールを通過できなかった場合、ガードレールはトリップワイヤーでそれを示します。トリップワイヤーを発動したガードレールが検知され次第、ただちに `{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
+入力または出力がガードレールを通過できなかった場合、ガードレールはトリップワイヤーでこれを通知できます。トリップワイヤーが発動したガードレールを検知するとすぐに、`{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
 
 ## ガードレールの実装
 
-入力を受け取り [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。この例では、内部でエージェントを実行することでこれを実現します。
+入力を受け取り、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。以下の例では、その内部でエージェントを実行して実装します。
 
 ```python
 from pydantic import BaseModel
@@ -96,10 +99,10 @@ async def main():
 
 1. このエージェントをガードレール関数内で使用します。  
 2. これはエージェントの入力／コンテキストを受け取り、結果を返すガードレール関数です。  
-3. ガードレール結果に追加情報を含めることができます。  
-4. これがワークフローを定義する実際のエージェントです。  
+3. ガードレール結果には追加情報を含めることができます。  
+4. こちらがワークフローを定義する実際のエージェントです。
 
-出力ガードレールも同様です。
+Output guardrails も同様です。
 
 ```python
 from pydantic import BaseModel
@@ -152,7 +155,7 @@ async def main():
         print("Math output guardrail tripped")
 ```
 
-1. これは実際のエージェントの出力型です。  
-2. これはガードレールの出力型です。  
+1. こちらは実際のエージェントの出力型です。  
+2. こちらはガードレールの出力型です。  
 3. これはエージェントの出力を受け取り、結果を返すガードレール関数です。  
-4. これがワークフローを定義する実際のエージェントです。
+4. こちらがワークフローを定義する実際のエージェントです。

openai_agents-0.2.5/docs/ja/handoffs.md

@@ -0,0 +1,117 @@
+---
+search:
+  exclude: true
+---
+# ハンドオフ
+
+ハンドオフを使用すると、エージェントが他のエージェントへタスクを委譲できます。これは、異なるエージェントがそれぞれ異なる分野を専門としているシナリオで特に有用です。たとえば、カスタマーサポートアプリでは、注文状況、返金、 FAQ などのタスクを個別に処理するエージェントが存在する場合があります。
+
+ハンドオフはLLMに対してツールとして表現されます。そのため、`Refund Agent` というエージェントへのハンドオフがある場合、ツール名は `transfer_to_refund_agent` となります。
+
+## ハンドオフの作成
+
+すべてのエージェントには [`handoffs`][agents.agent.Agent.handoffs] パラメーターがあり、直接 `Agent` を渡すことも、ハンドオフをカスタマイズする `Handoff` オブジェクトを渡すこともできます。
+
+Agents SDK が提供する [`handoff()`][agents.handoffs.handoff] 関数を使用すると、ハンドオフを作成できます。この関数では、ハンドオフ先のエージェントに加えて、任意のオーバーライドや入力フィルターを指定できます。
+
+### 基本的な使用方法
+
+以下はシンプルなハンドオフの作成例です。
+
+```python
+from agents import Agent, handoff
+
+billing_agent = Agent(name="Billing agent")
+refund_agent = Agent(name="Refund agent")
+
+# (1)!
+triage_agent = Agent(name="Triage agent", handoffs=[billing_agent, handoff(refund_agent)])
+```
+
+1. `billing_agent` のようにエージェントを直接渡すことも、`handoff()` 関数を使用することもできます。
+
+### `handoff()` 関数によるハンドオフのカスタマイズ
+
+[`handoff()`][agents.handoffs.handoff] 関数では、次の項目をカスタマイズできます。
+
+- `agent`: ハンドオフ先のエージェント。  
+- `tool_name_override`: 既定では `Handoff.default_tool_name()` が使用され、`transfer_to_<agent_name>` となります。これを上書きできます。  
+- `tool_description_override`: `Handoff.default_tool_description()` から生成される既定のツール説明を上書きします。  
+- `on_handoff`: ハンドオフが呼び出されたときに実行されるコールバック関数。ハンドオフが発生した時点でデータ取得を開始するなどに便利です。この関数はエージェントコンテキストを受け取り、オプションでLLMが生成した入力も受け取れます。入力データは `input_type` パラメーターで制御します。  
+- `input_type`: ハンドオフが受け取る想定の入力型 (任意)。  
+- `input_filter`: 次のエージェントが受け取る入力をフィルタリングします。詳細は後述します。  
+
+```python
+from agents import Agent, handoff, RunContextWrapper
+
+def on_handoff(ctx: RunContextWrapper[None]):
+    print("Handoff called")
+
+agent = Agent(name="My agent")
+
+handoff_obj = handoff(
+    agent=agent,
+    on_handoff=on_handoff,
+    tool_name_override="custom_handoff_tool",
+    tool_description_override="Custom description",
+)
+```
+
+## ハンドオフ入力
+
+状況によっては、LLMにハンドオフの呼び出し時にデータを渡してほしい場合があります。たとえば、"Escalation agent" へのハンドオフを考えてみましょう。理由を提供しておき、ログに残せるようにしたいかもしれません。
+
+```python
+from pydantic import BaseModel
+
+from agents import Agent, handoff, RunContextWrapper
+
+class EscalationData(BaseModel):
+    reason: str
+
+async def on_handoff(ctx: RunContextWrapper[None], input_data: EscalationData):
+    print(f"Escalation agent called with reason: {input_data.reason}")
+
+agent = Agent(name="Escalation agent")
+
+handoff_obj = handoff(
+    agent=agent,
+    on_handoff=on_handoff,
+    input_type=EscalationData,
+)
+```
+
+## 入力フィルター
+
+ハンドオフが発生すると、新しいエージェントが会話を引き継ぎ、これまでの会話履歴全体を参照できます。これを変更したい場合は、[`input_filter`][agents.handoffs.Handoff.input_filter] を設定します。入力フィルターは、既存の入力を [`HandoffInputData`][agents.handoffs.HandoffInputData] 経由で受け取り、新しい `HandoffInputData` を返す関数です。
+
+代表的なパターン (たとえば履歴からすべてのツール呼び出しを削除する) が [`agents.extensions.handoff_filters`][] に実装されています。
+
+```python
+from agents import Agent, handoff
+from agents.extensions import handoff_filters
+
+agent = Agent(name="FAQ agent")
+
+handoff_obj = handoff(
+    agent=agent,
+    input_filter=handoff_filters.remove_all_tools, # (1)!
+)
+```
+
+1. これにより、`FAQ agent` が呼び出された際に履歴からすべてのツールが自動的に削除されます。
+
+## 推奨プロンプト
+
+LLMがハンドオフを正しく理解できるよう、エージェントにハンドオフに関する情報を含めることを推奨します。[`agents.extensions.handoff_prompt.RECOMMENDED_PROMPT_PREFIX`][] に推奨プレフィックスを用意しているほか、[`agents.extensions.handoff_prompt.prompt_with_handoff_instructions`][] を呼び出すことで、プロンプトに推奨データを自動的に追加できます。
+
+```python
+from agents import Agent
+from agents.extensions.handoff_prompt import RECOMMENDED_PROMPT_PREFIX
+
+billing_agent = Agent(
+    name="Billing agent",
+    instructions=f"""{RECOMMENDED_PROMPT_PREFIX}
+    <Fill in the rest of your prompt here>.""",
+)
+```