openai-agents 0.3.0__tar.gz → 0.3.2__tar.gz

{openai_agents-0.3.0 → openai_agents-0.3.2}/.github/workflows/update-docs.yml

@@ -13,6 +13,10 @@ on:
       - 'docs/**'
       - mkdocs.yml
 
+permissions:
+  contents: write
+  pull-requests: write
+
 jobs:
   update-docs:
     if: "!contains(github.event.head_commit.message, 'Update all translated document pages')"

{openai_agents-0.3.0 → openai_agents-0.3.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: openai-agents
-Version: 0.3.0
+Version: 0.3.2
 Summary: OpenAI Agents SDK
 Project-URL: Homepage, https://openai.github.io/openai-agents-python/
 Project-URL: Repository, https://github.com/openai/openai-agents-python
@@ -26,6 +26,8 @@ Requires-Dist: pydantic<3,>=2.10
 Requires-Dist: requests<3,>=2.0
 Requires-Dist: types-requests<3,>=2.0
 Requires-Dist: typing-extensions<5,>=4.12.2
+Provides-Extra: encrypt
+Requires-Dist: cryptography<46,>=45.0; extra == 'encrypt'
 Provides-Extra: litellm
 Requires-Dist: litellm<2,>=1.67.4.post1; extra == 'litellm'
 Provides-Extra: realtime

{openai_agents-0.3.0 → openai_agents-0.3.2}/docs/ja/agents.md

@@ -4,15 +4,15 @@ search:
 ---
 # エージェント
 
-エージェントはアプリの中核となる基本コンポーネントです。エージェントは、instructions とツールで構成された大規模言語モデル（ LLM ）です。
+エージェントはアプリの中核となる構成要素です。エージェントは、instructions とツールで構成された大規模言語モデル ( LLM ) です。
 
-## 基本構成
+## 基本設定
 
-エージェントで最も一般的に設定するプロパティは次のとおりです。
+最も一般的に設定するエージェントのプロパティは次のとおりです。
 
 -   `name`: エージェントを識別する必須の文字列です。
 -   `instructions`: developer メッセージまたは system prompt とも呼ばれます。
--   `model`: 使用する LLM と、temperature、top_p などのモデル調整パラメーターを設定する任意の `model_settings`。
+-   `model`: 使用する LLM と、temperature、top_p などのモデル調整パラメーターを構成する任意の `model_settings`。
 -   `tools`: エージェントがタスク達成のために使用できるツールです。
 
 ```python
@@ -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、lists、TypedDict など）をサポートします。
+デフォルトでは、エージェントはプレーンテキスト (すなわち `str`) を出力します。特定の型の出力をエージェントに生成させたい場合は、`output_type` パラメーターを使用できます。一般的な選択肢は [Pydantic](https://docs.pydantic.dev/) オブジェクトを使うことですが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる任意の型をサポートします—dataclasses、list、TypedDict など。
 
 ```python
 from pydantic import BaseModel
@@ -73,20 +73,20 @@ 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) を使用するよう指示されます。
 
 ## マルチエージェント システムの設計パターン
 
-マルチエージェント システムの設計方法は多様ですが、一般的に広く適用できるパターンが 2 つあります。
+マルチエージェント システムを設計する方法は多岐にわたりますが、広く適用できるパターンとして次の 2 つがよく見られます。
 
-1. マネージャー（エージェントをツールとして使用）: 中央のマネージャー／オーケストレーターが、ツールとして公開された専門のサブエージェントを呼び出し、会話の制御を保持します。
-2. ハンドオフ: ピアのエージェントが制御を専門のエージェントに引き渡し、そのエージェントが会話を引き継ぎます。これは分散型です。
+1. マネージャー（ツールとしてのエージェント）: 中央のマネージャー/オーケストレーターが、ツールとして公開された特化型サブエージェントを呼び出し、会話の制御を保持します。
+2. ハンドオフ: 対等なエージェント間で、会話を引き継ぐ特化型エージェントに制御をハンドオフします。これは分散型です。
 
-詳細は [エージェント構築の実践ガイド](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)をご覧ください。
+詳細は [エージェント構築の実践ガイド](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf) を参照してください。
 
-### マネージャー（エージェントをツールとして使用）
+### マネージャー（ツールとしてのエージェント）
 
-`customer_facing_agent` はすべてのユーザーとの対話を処理し、ツールとして公開された専門のサブエージェントを呼び出します。詳細は [ツール](tools.md#agents-as-tools) ドキュメントをお読みください。
+`customer_facing_agent` はすべてのユーザー対応を行い、ツールとして公開された特化型サブエージェントを呼び出します。詳しくは [ツール](tools.md#agents-as-tools) のドキュメントを参照してください。
 
 ```python
 from agents import Agent
@@ -115,7 +115,7 @@ customer_facing_agent = Agent(
 
 ### ハンドオフ
 
-ハンドオフは、エージェントが委任できるサブエージェントです。ハンドオフが発生すると、委任先のエージェントは会話履歴を受け取り、会話を引き継ぎます。このパターンは、単一のタスクに特化して優れた性能を発揮する、モジュール式で専門的なエージェントを可能にします。詳細は [ハンドオフ](handoffs.md) ドキュメントをお読みください。
+ハンドオフは、エージェントが委任できるサブエージェントです。ハンドオフが発生すると、委任先のエージェントは会話履歴を受け取り、会話を引き継ぎます。このパターンにより、単一のタスクに秀でたモジュール型・特化型エージェントが可能になります。詳しくは [ハンドオフ](handoffs.md) のドキュメントを参照してください。
 
 ```python
 from agents import Agent
@@ -136,7 +136,7 @@ triage_agent = Agent(
 
 ## 動的 instructions
 
-多くの場合、エージェントを作成するときに instructions を指定できますが、関数を介して動的な instructions を提供することもできます。関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方が使用できます。
+多くの場合、エージェント作成時に instructions を指定できますが、関数を介して動的な instructions を提供することもできます。この関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数のどちらも使用できます。
 
 ```python
 def dynamic_instructions(
@@ -153,15 +153,15 @@ agent = Agent[UserContext](
 
 ## ライフサイクルイベント（フック）
 
-エージェントのライフサイクルを観測したい場合があります。たとえば、イベントをログに記録したり、特定のイベント発生時にデータを事前取得したりできます。`hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、関心のあるメソッドをオーバーライドしてください。
+場合によっては、エージェントのライフサイクルを観察したいことがあります。たとえば、イベントのログ記録や、特定のイベント発生時にデータを事前取得したい場合です。`hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、関心のあるメソッドをオーバーライドしてください。
 
 ## ガードレール
 
-ガードレールにより、エージェントの実行と並行してユーザー入力に対するチェック／検証を行い、さらにエージェントの出力が生成された後のチェック／検証も実行できます。たとえば、ユーザーの入力とエージェントの出力の関連性をスクリーニングできます。詳細は [ガードレール](guardrails.md) ドキュメントをお読みください。
+ガードレールにより、エージェントの実行と並行してユーザー入力に対するチェック/検証を行い、エージェントの出力が生成された後にもチェックを実行できます。たとえば、ユーザー入力とエージェント出力の関連性をスクリーニングできます。詳しくは [ガードレール](guardrails.md) のドキュメントを参照してください。
 
-## エージェントのクローン／コピー
+## エージェントのクローン/コピー
 
-エージェントの `clone()` メソッドを使用すると、エージェントを複製し、必要に応じて任意のプロパティを変更できます。
+エージェントの `clone()` メソッドを使用すると、エージェントを複製し、任意のプロパティを変更できます。
 
 ```python
 pirate_agent = Agent(
@@ -178,12 +178,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`: LLM にツールを使用しないことを要求します。
+4. 特定の文字列（例: `my_tool`）を設定すると、その特定のツールを LLM に使用させます。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -201,12 +201,12 @@ agent = Agent(
 )
 ```
 
-## ツール使用時の動作
+## ツール使用の挙動
 
-`Agent` 構成の `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。
+`Agent` の `tool_use_behavior` パラメーターは、ツール出力の扱いを制御します。
 
-- `"run_llm_again"`: 既定。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
-- `"stop_on_first_tool"`: 最初のツール呼び出しの出力を、追加の LLM 処理なしで最終応答として使用します。
+- `"run_llm_again"`: デフォルト。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
+- `"stop_on_first_tool"`: 最初のツール呼び出しの出力を、その後の LLM 処理なしで最終応答として使用します。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -224,7 +224,7 @@ agent = Agent(
 )
 ```
 
-- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかのツールが呼び出された場合に停止し、その出力を最終応答として使用します。
+- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかのツールが呼び出されたら停止し、その出力を最終応答として使用します。
 
 ```python
 from agents import Agent, Runner, function_tool
@@ -286,4 +286,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.3.2/docs/ja/config.md

@@ -0,0 +1,98 @@
+---
+search:
+  exclude: true
+---
+# SDK の設定
+
+## API キーとクライアント
+
+デフォルトでは、SDK はインポートされた直後から LLM リクエストと トレーシング のために `OPENAI_API_KEY` 環境変数を探します。アプリ起動前にその環境変数を設定できない場合は、[デフォルトの OpenAI キーを設定する (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` インスタンスを作成します。これを変更するには、[デフォルトの OpenAI クライアントを設定する (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 を使用するには、[デフォルトの OpenAI 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.3.2/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 に新しいデータを利用させたい場合は、その履歴に含められる形で提供する必要があります。方法はいくつかあります。
+
+1. エージェントの `instructions` に追加します。これは「システムプロンプト」または「開発者メッセージ」とも呼ばれます。システムプロンプトは静的な文字列でも、コンテキストを受け取って文字列を出力する動的な関数でも構いません。常に有用な情報（例: ユーザーの名前や現在の日付）に適した手法です。
+2. `Runner.run` を呼び出す際の `input` に追加します。これは `instructions` の手法に似ていますが、[指揮系統](https://cdn.openai.com/spec/model-spec-2024-05-08.html#follow-the-chain-of-command)の下位にメッセージを配置できます。
+3. 関数ツール経由で公開します。これはオンデマンドのコンテキストに有用で、LLM が必要になったタイミングでツールを呼び出してデータを取得できます。
+4. リトリーバルまたは Web 検索を使用します。これらは、ファイルやデータベース（リトリーバル）、あるいは Web（Web 検索）から関連データを取得できる特別なツールです。関連するコンテキストデータに基づいて応答に根拠付けを行うのに有用です。

openai_agents-0.3.2/docs/ja/examples.md

@@ -0,0 +1,48 @@
+---
+search:
+  exclude: true
+---
+# コード例
+
+[repo](https://github.com/openai/openai-agents-python/tree/main/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 の基礎的な機能を紹介します。
+
+    - 動的な システムプロンプト
+    - ストリーミング 出力
+    - ライフサイクルイベント
+
+- **[ツールのコード例](https://github.com/openai/openai-agents-python/tree/main/examples/tools):**
+  Web 検索 や ファイル検索 といった OpenAI がホストするツール の実装方法と、それらを エージェント に統合する方法を学べます。
+
+- **[モデルプロバイダー](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers):**
+  SDK で OpenAI 以外のモデルを使う方法を紹介します。
+
+- **[ハンドオフ](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 を使って リアルタイム 体験を構築する方法の例。

{openai_agents-0.3.0 → openai_agents-0.3.2}/docs/ja/guardrails.md

@@ -4,7 +4,7 @@ search:
 ---
 # ガードレール
 
-ガードレールはエージェントと_並行して_動作し、ユーザー入力のチェックや検証を行います。たとえば、顧客からのリクエストに対応するために非常に賢い（そのため遅く/高価な）モデルを使うエージェントがあるとします。悪意のあるユーザーに、そのモデルで数学の宿題を手伝わせるようなリクエストは避けたいはずです。そのために、高速/低コストなモデルでガードレールを実行できます。ガードレールが悪用を検知した場合、即座にエラーを発生させ、高価なモデルの実行を止めて時間やコストを節約できます。
+ガードレールはエージェントと _並列_ に実行され、ユーザー入力のチェックと検証を行います。たとえば、顧客対応に非常に賢い（そのため遅く/高価な）モデルを使うエージェントがあるとします。悪意のあるユーザーがそのモデルに数学の宿題を手伝わせるよう依頼するのは避けたいはずです。そこで、速く/安価なモデルでガードレールを走らせます。ガードレールが不正利用を検出した場合、即座にエラーを発生させ、高価なモデルの実行を止め、時間やコストを節約できます。
 
 ガードレールには 2 種類あります:
 
@@ -13,35 +13,35 @@ search:
 
 ## 入力ガードレール
 
-入力ガードレールは次の 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
@@ -96,7 +96,7 @@ async def main():
 
 1. このエージェントをガードレール関数内で使用します。
 2. これはエージェントの入力/コンテキストを受け取り、結果を返すガードレール関数です。
-3. ガードレール結果に追加情報を含めることができます。
+3. ガードレール結果に追加情報を含められます。
 4. これはワークフローを定義する実際のエージェントです。
 
 出力ガードレールも同様です。

openai_agents-0.3.2/docs/ja/handoffs.md

@@ -0,0 +1,118 @@
+---
+search:
+  exclude: true
+---
+# Handoffs
+
+Handoffs は、ある エージェント が別の エージェント にタスクを委譲できるようにする仕組みです。これは、異なる エージェント がそれぞれ別の分野を専門にしている状況で特に有用です。例えば、カスタマーサポートアプリでは、注文状況、返金、FAQ などのタスクをそれぞれ専任で担当する エージェント がいるかもしれません。
+
+Handoffs は LLM に対してツールとして表現されます。したがって、`Refund Agent` という名前の エージェント への handoff がある場合、そのツール名は `transfer_to_refund_agent` になります。
+
+## Handoff の作成
+
+すべての エージェント には [`handoffs`][agents.agent.Agent.handoffs] パラメーターがあり、これは `Agent` を直接渡すか、Handoff をカスタマイズする `Handoff` オブジェクトを受け取ります。
+
+Agents SDK が提供する [`handoff()`][agents.handoffs.handoff] 関数を使用して handoff を作成できます。この関数では、ハンドオフ先の エージェント の指定に加えて、任意の上書きや入力フィルターを指定できます。
+
+### 基本的な使い方
+
+シンプルな 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 のカスタマイズ
+
+[`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`: handoff が呼び出されたときに実行されるコールバック関数です。handoff が呼ばれたことが分かった時点でのデータ取得開始などに役立ちます。この関数は エージェント コンテキストを受け取り、任意で LLM が生成した入力も受け取れます。入力データは `input_type` パラメーターで制御します。
+-   `input_type`: handoff が想定する入力の型（任意）。
+-   `input_filter`: 次の エージェント が受け取る入力をフィルタリングできます。詳細は以下を参照してください。
+-   `is_enabled`: handoff を有効にするかどうか。ブール値、またはブール値を返す関数を指定でき、実行時に動的に handoff を有効化・無効化できます。
+
+```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",
+)
+```
+
+## Handoff の入力
+
+状況によっては、handoff を呼び出す際に LLM に何らかのデータを提供してほしいことがあります。例えば、「エスカレーション エージェント」への handoff を想定してみてください。ログに残すために理由を提供してほしい、ということがあるかもしれません。
+
+```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,
+)
+```
+
+## 入力フィルター
+
+handoff が発生すると、新しい エージェント が会話を引き継ぎ、直前までの会話履歴全体を閲覧できるかのように扱われます。これを変更したい場合は、[`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 が handoff を正しく理解するようにするため、エージェント に handoff に関する情報を含めることを推奨します。[`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>.""",
+)
+```