openai-agents 0.2.7__tar.gz → 0.2.8__tar.gz

{openai_agents-0.2.7 → openai_agents-0.2.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openai-agents
-Version: 0.2.7
+Version: 0.2.8
 Summary: OpenAI Agents SDK
 Project-URL: Homepage, https://openai.github.io/openai-agents-python/
 Project-URL: Repository, https://github.com/openai/openai-agents-python

{openai_agents-0.2.7 → openai_agents-0.2.8}/docs/agents.md

@@ -115,7 +115,7 @@ Sometimes, you want to observe the lifecycle of an agent. For example, you may w
 
 ## Guardrails
 
-Guardrails allow you to run checks/validations on user input, in parallel to the agent running. For example, you could screen the user's input for relevance. Read more in the [guardrails](guardrails.md) documentation.
+Guardrails allow you to run checks/validations on user input in parallel to the agent running, and on the agent's output once it is produced. For example, you could screen the user's input and agent's output for relevance. Read more in the [guardrails](guardrails.md) documentation.
 
 ## Cloning/copying agents
 

{openai_agents-0.2.7 → openai_agents-0.2.8}/docs/ja/agents.md

@@ -4,16 +4,16 @@ search:
 ---
 # エージェント
 
-エージェントは、アプリの中核となる構成要素です。エージェントは、instructions とツールを設定した大規模言語モデル ( LLM ) です。
+エージェントはアプリにおける中核的な構成要素です。エージェントは、 instructions と tools で構成された大規模言語モデル ( LLM ) です。
 
-## 基本設定
+## 基本構成
 
 エージェントで最も一般的に設定するプロパティは次のとおりです。
 
--   `name`: エージェントを識別する必須の文字列。
--   `instructions`: developer message または システムプロンプト とも呼ばれます。
--   `model`: どの LLM を使用するか、またオプションの `model_settings` で temperature、top_p などのモデル調整パラメーターを設定します。
--   `tools`: エージェントがタスクを達成するために使用できるツール。
+-   `name`: エージェントを識別する必須の文字列です。
+-   `instructions`: developer メッセージ、または system prompt とも呼ばれます。
+-   `model`: 使用する LLM と、 temperature、 top_p などのモデル調整パラメーターを設定する任意の `model_settings`。
+-   `tools`: エージェントがタスク達成のために使用できるツールです。
 
 ```python
 from agents import Agent, ModelSettings, function_tool
@@ -33,7 +33,7 @@ agent = Agent(
 
 ## コンテキスト
 
-エージェントは `context` 型に対して汎用的です。コンテキストは依存性注入のツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、エージェントの実行に必要な依存関係や状態をまとめて保持します。コンテキストには任意の Python オブジェクトを渡せます。
+エージェントは `context` 型に対してジェネリックです。コンテキストは依存性注入のためのツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、エージェント実行のための依存関係や状態をまとめたものとして機能します。コンテキストには任意の 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/) でラップできる任意の型 (dataclasses、リスト、TypedDict など) をサポートします。
+既定では、エージェントはプレーンテキスト ( `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
@@ -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 を指定できますが、関数を使って動的に instructions を提供することもできます。この関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方が使用できます。
+多くの場合、エージェント作成時に instructions を指定しますが、関数を通じて動的な instructions を提供することもできます。関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方が利用可能です。
 
 ```python
 def dynamic_instructions(
@@ -115,15 +115,15 @@ agent = Agent[UserContext](
 
 ## ライフサイクルイベント (フック)
 
-エージェントのライフサイクルを観測したい場合があります。例えば、イベントをログに記録したり、特定のイベントが発生したときにデータを事前取得したりする場合です。`hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、関心のあるメソッドをオーバーライドしてください。
+エージェントのライフサイクルを観測したい場合があります。たとえば、イベントをログ記録したい、または特定のイベント発生時にデータを事前取得したい場合です。 `hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、関心のあるメソッドをオーバーライドしてください。
 
 ## ガードレール
 
-ガードレールにより、エージェントの実行と並行して ユーザー 入力に対するチェック/バリデーションを実行できます。例えば、ユーザー の入力の関連性をスクリーニングできます。詳しくは [guardrails](guardrails.md) ドキュメントをご覧ください。
+ガードレールにより、エージェント実行と並行してユーザー入力に対するチェックや検証を行い、生成後のエージェント出力にも同様の処理を行えます。たとえば、ユーザー入力やエージェント出力の関連性をスクリーニングできます。詳しくは [guardrails](guardrails.md) のドキュメントを参照してください。
 
 ## エージェントのクローン/コピー
 
-エージェントの `clone()` メソッドを使うと、エージェントを複製し、必要に応じて任意のプロパティを変更できます。
+エージェントの `clone()` メソッドを使用すると、エージェントを複製し、必要に応じて任意のプロパティを変更できます。
 
 ```python
 pirate_agent = Agent(
@@ -140,12 +140,12 @@ robot_agent = pirate_agent.clone(
 
 ## ツール使用の強制
 
-ツールのリストを指定しても、LLM が必ずツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定してツール使用を強制できます。有効な値は次のとおりです。
+ツールのリストを指定しても、 LLM が必ずツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定してツール使用を強制できます。有効な値は次のとおりです。
 
-1. `auto`: ツールを使用するかどうかを LLM が判断します。
-2. `required`: LLM にツールの使用を要求します (ただし、どのツールを使うかは賢く判断します)。
-3. `none`: LLM にツールを使用「しない」ことを要求します。
-4. 特定の文字列 (例: `my_tool`) を設定: LLM にその特定のツールを使用させます。
+1. `auto`: ツールを使用するかどうかを LLM に委ねます。
+2. `required`: LLM にツールの使用を要求します ( どのツールを使うかは賢く選択できます )。
+3. `none`: ツールを使用しないことを要求します。
+4. 特定の文字列 ( 例: `my_tool` ) を設定: LLM にその特定のツールの使用を要求します。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -165,9 +165,9 @@ agent = Agent(
 
 ## ツール使用の挙動
 
-`Agent` 設定の `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。
-- `"run_llm_again"`: デフォルト。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
-- `"stop_on_first_tool"`: 最初のツール呼び出しの出力を最終応答として使用し、以降の LLM 処理は行いません。
+`Agent` の構成にある `tool_use_behavior` パラメーターは、ツール出力の処理方法を制御します。
+- `"run_llm_again"`: 既定。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
+- `"stop_on_first_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=[...])`: 指定されたいずれかのツールが呼び出されたら停止し、その出力を最終応答として使用します。
 ```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`: ツール結果を処理し、停止するか 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` のために LLM がさらに別のツール呼び出しを生成し続けることで発生します。
+    無限ループを防ぐため、フレームワークはツール呼び出し後に自動的に `tool_choice` を "auto" にリセットします。この挙動は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定できます。無限ループが起きるのは、ツール結果が LLM に送られ、`tool_choice` のために LLM が再びツール呼び出しを生成し続けるためです。

openai_agents-0.2.8/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 は環境変数または上記で設定したデフォルトキーから API キーを用いて `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 を使用します。これを上書きして Chat Completions API を使用するには、[set_default_openai_api()][agents.set_default_openai_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 にはハンドラーが設定されていない 2 つの Python ロガーがあります。デフォルトでは、これは警告とエラーが `stdout` に送られ、それ以外のログは抑制されることを意味します。
+
+詳細なログ出力を有効にするには、[`enable_verbose_stdout_logging()`][agents.enable_verbose_stdout_logging] 関数を使用します。
+
+```python
+from agents import enable_verbose_stdout_logging
+
+enable_verbose_stdout_logging()
+```
+
+また、ハンドラー、フィルター、フォーマッターなどを追加してログをカスタマイズすることもできます。詳しくは [Python logging ガイド](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.8/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. そのオブジェクトを各種の実行メソッドに渡します（例: `Runner.run(..., **context=whatever**)`）。
+3. すべてのツール呼び出しやライフサイクルフックなどにはラッパーオブジェクト `RunContextWrapper[T]` が渡されます。ここで `T` はコンテキストオブジェクトの型を表し、`wrapper.context` でアクセスできます。
+
+最も重要な点: 特定のエージェント実行におけるすべてのエージェント、ツール関数、ライフサイクルなどは、同じ型のコンテキストを使わなければなりません。
+
+コンテキストは次のような用途に使えます:
+
+-   実行のための状況データ（例: ユーザー名 / uid や、ユーザーに関するその他の情報）
+-   依存関係（例: ロガーオブジェクト、データフェッチャーなど）
+-   ヘルパー関数
+
+!!! danger "注意"
+
+    コンテキストオブジェクトは 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. エージェントの `instructions` に追加します。これは「system prompt」や「デベロッパーメッセージ」とも呼ばれます。system prompt は静的な文字列でも、コンテキストを受け取って文字列を出力する動的な関数でも構いません。これは常に有用な情報（例: ユーザー名や現在の日付）に一般的な戦略です。
+2. `Runner.run` 関数を呼び出すときに `input` に追加します。これは `instructions` の戦略に似ていますが、[指揮系統](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.8/docs/ja/examples.md

@@ -0,0 +1,48 @@
+---
+search:
+  exclude: true
+---
+# コード例
+
+リポジトリの [code examples](https://github.com/openai/openai-agents-python/tree/main/examples) セクションで、 SDK のさまざまなサンプル実装をご覧ください。code examples は、異なるパターンや機能を示す複数のカテゴリーに整理されています。
+
+
+## カテゴリー
+
+-  **[エージェントパターン (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 の基礎的な機能を紹介します。
+
+    - 動的な システムプロンプト
+    - ストリーミング 出力
+    - ライフサイクルイベント
+
+-  **[ツールのサンプルコード (tools)](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):**
+  SDK で OpenAI 以外のモデルを使用する方法を探ります。
+
+-  **[ハンドオフ (handoffs)](https://github.com/openai/openai-agents-python/tree/main/examples/handoffs):**
+  エージェント の ハンドオフ の実用例をご覧ください。
+
+-  **[MCP (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 を使ってリアルタイム体験を構築する方法を示す code examples。

{openai_agents-0.2.7 → openai_agents-0.2.8}/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
@@ -94,9 +94,9 @@ async def main():
         print("Math homework guardrail tripped")
 ```
 
-1. このエージェントをガードレール関数で使用します。
+1. このエージェントをガードレール関数内で使用します。
 2. これはエージェントの入力/コンテキストを受け取り、結果を返すガードレール関数です。
-3. ガードレールの結果に追加情報を含めることができます。
+3. ガードレール結果に追加情報を含めることができます。
 4. これはワークフローを定義する実際のエージェントです。
 
 出力ガードレールも同様です。

openai_agents-0.2.8/docs/ja/handoffs.md

@@ -0,0 +1,118 @@
+---
+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`: 次のエージェントが受け取る入力をフィルタリングできます。詳細は以下を参照してください。
+-   `is_enabled`: ハンドオフを有効にするかどうか。真偽値、または真偽値を返す関数を指定でき、実行時に動的に有効/無効を切り替えられます。
+
+```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>.""",
+)
+```