ツール
ツールにより、エージェントはデータの取得、コードの実行、外部 API の呼び出し、さらにはコンピュータ操作などのアクションを実行できます。SDK は 5 つのカテゴリーをサポートしています。
- OpenAI がホストするツール: OpenAI サーバー上でモデルと並行して実行されます。
- ローカル/ランタイム実行ツール:
ComputerToolとApplyPatchToolは常にお使いの環境で実行され、ShellToolはローカルまたはホストされたコンテナーで実行できます。 - Function Calling: 任意の Python 関数をツールとしてラップします。
- Agents as tools: 完全なハンドオフなしで、エージェントを呼び出し可能なツールとして公開します。
- 実験的: Codex ツール: ツール呼び出しからワークスペーススコープの Codex タスクを実行します。
ツール種別の選択
このページをカタログとして使い、その後、管理するランタイムに合ったセクションへ進んでください。
| 実現したいこと | 参照先 |
|---|---|
| OpenAI 管理のツール(Web 検索、ファイル検索、コードインタープリター、ホストされた MCP、画像生成)を使用する | ホストされたツール |
| ツール検索で大規模なツールサーフェスをランタイムまで遅延させる | ホストされたツール検索 |
| 自分のプロセスまたは環境でツールを実行する | ローカルランタイムツール |
| Python 関数をツールとしてラップする | 関数ツール |
| あるエージェントがハンドオフなしで別のエージェントを呼び出せるようにする | Agents as tools |
| エージェントからワークスペーススコープの Codex タスクを実行する | 実験的: Codex ツール |
ホストされたツール
OpenAI は OpenAIResponsesModel を使用する場合に、いくつかの組み込みツールを提供しています。
WebSearchToolは、エージェントが Web を検索できるようにします。FileSearchToolは、OpenAI Vector Stores から情報を取得できるようにします。CodeInterpreterToolは、LLM がサンドボックス環境でコードを実行できるようにします。HostedMCPToolは、リモート MCP サーバーのツールをモデルに公開します。ImageGenerationToolは、プロンプトから画像を生成します。ToolSearchToolは、モデルが遅延されたツール、名前空間、またはホストされた MCP サーバーを必要に応じて読み込めるようにします。
高度なホスト型検索オプション:
FileSearchToolは、vector_store_idsとmax_num_resultsに加えて、filters、ranking_options、include_search_resultsをサポートします。WebSearchToolは、filters、user_location、search_context_sizeをサポートします。
from agents import Agent, FileSearchTool, Runner, WebSearchTool
agent = Agent(
name="Assistant",
tools=[
WebSearchTool(),
FileSearchTool(
max_num_results=3,
vector_store_ids=["VECTOR_STORE_ID"],
),
],
)
async def main():
result = await Runner.run(agent, "Which coffee shop should I go to, taking into account my preferences and the weather today in SF?")
print(result.final_output)
ホストされたツール検索
ツール検索により、OpenAI Responses モデルは大規模なツールサーフェスをランタイムまで遅延できるため、モデルは現在のターンに必要なサブセットだけを読み込みます。多数の関数ツール、名前空間グループ、またはホストされた MCP サーバーがあり、すべてのツールを最初から公開せずにツールスキーマのトークンを削減したい場合に便利です。
候補となるツールがエージェントを構築する時点ですでに分かっている場合は、ホストされたツール検索から始めてください。アプリケーションが何を読み込むかを動的に決める必要がある場合、Responses API はクライアント実行のツール検索もサポートしていますが、標準の Runner はそのモードを自動実行しません。
from typing import Annotated
from agents import Agent, Runner, ToolSearchTool, function_tool, tool_namespace
@function_tool(defer_loading=True)
def get_customer_profile(
customer_id: Annotated[str, "The customer ID to look up."],
) -> str:
"""Fetch a CRM customer profile."""
return f"profile for {customer_id}"
@function_tool(defer_loading=True)
def list_open_orders(
customer_id: Annotated[str, "The customer ID to look up."],
) -> str:
"""List open orders for a customer."""
return f"open orders for {customer_id}"
crm_tools = tool_namespace(
name="crm",
description="CRM tools for customer lookups.",
tools=[get_customer_profile, list_open_orders],
)
agent = Agent(
name="Operations assistant",
model="gpt-5.5",
instructions="Load the crm namespace before using CRM tools.",
tools=[*crm_tools, ToolSearchTool()],
)
result = await Runner.run(agent, "Look up customer_42 and list their open orders.")
print(result.final_output)
知っておくべきこと:
- ホストされたツール検索は OpenAI Responses モデルでのみ利用できます。現在の Python SDK サポートは
openai>=2.25.0に依存します。 - エージェントで遅延読み込みサーフェスを設定する場合は、
ToolSearchTool()を正確に 1 つ追加してください。 - 検索可能なサーフェスには、
@function_tool(defer_loading=True)、tool_namespace(name=..., description=..., tools=[...])、HostedMCPTool(tool_config={..., "defer_loading": True})が含まれます。 - 遅延読み込みの関数ツールは
ToolSearchTool()と組み合わせる必要があります。名前空間のみの構成でも、モデルが必要に応じて適切なグループを読み込めるようにToolSearchTool()を使用できます。 tool_namespace()は、FunctionToolインスタンスを共有の名前空間名と説明の下にグループ化します。これは通常、crm、billing、shippingなど、関連するツールが多数ある場合に最適です。- OpenAI の公式ベストプラクティスガイダンスは 可能な場合は名前空間を使用する です。
- 可能な場合は、多数の個別に遅延された関数よりも、名前空間またはホストされた MCP サーバーを優先してください。通常、モデルにより良い高レベルの検索サーフェスと、より良いトークン節約を提供します。
- 名前空間では、即時ツールと遅延ツールを混在させることができます。
defer_loading=Trueがないツールは即座に呼び出し可能なままで、同じ名前空間内の遅延ツールはツール検索を通じて読み込まれます。 - 目安として、各名前空間はかなり小さく保ち、理想的には 10 個未満の関数にしてください。
- 名前付き
tool_choiceは、裸の名前空間名や遅延のみのツールを対象にできません。auto、required、または実際のトップレベルで呼び出し可能なツール名を優先してください。 ToolSearchTool(execution="client")は手動の Responses オーケストレーション用です。モデルがクライアント実行のtool_search_callを出力した場合、標準のRunnerはそれを実行する代わりに例外を発生させます。- ツール検索のアクティビティは、専用のアイテムタイプとイベントタイプで
RunResult.new_itemsおよびRunItemStreamEventに表示されます。 - 名前空間による読み込みとトップレベルの遅延ツールの両方を網羅した、完全に実行可能なコード例については
examples/tools/tool_search.pyを参照してください。 - 公式プラットフォームガイド: ツール検索。
ホストされたコンテナーシェル + スキル
ShellTool は OpenAI がホストするコンテナー実行もサポートしています。ローカルランタイムではなく、管理されたコンテナー内でモデルにシェルコマンドを実行させたい場合は、このモードを使用してください。
from agents import Agent, Runner, ShellTool, ShellToolSkillReference
csv_skill: ShellToolSkillReference = {
"type": "skill_reference",
"skill_id": "skill_698bbe879adc81918725cbc69dcae7960bc5613dadaed377",
"version": "1",
}
agent = Agent(
name="Container shell agent",
model="gpt-5.5",
instructions="Use the mounted skill when helpful.",
tools=[
ShellTool(
environment={
"type": "container_auto",
"network_policy": {"type": "disabled"},
"skills": [csv_skill],
}
)
],
)
result = await Runner.run(
agent,
"Use the configured skill to analyze CSV files in /mnt/data and summarize totals by region.",
)
print(result.final_output)
後続の実行で既存のコンテナーを再利用するには、environment={"type": "container_reference", "container_id": "cntr_..."} を設定します。
知っておくべきこと:
- ホストされたシェルは Responses API のシェルツールを通じて利用できます。
container_autoはリクエスト用にコンテナーをプロビジョニングし、container_referenceは既存のコンテナーを再利用します。container_autoにはfile_idsとmemory_limitも含めることができます。environment.skillsはスキル参照とインラインスキルバンドルを受け付けます。- ホストされた環境では、
ShellToolにexecutor、needs_approval、on_approvalを設定しないでください。 network_policyはdisabledモードとallowlistモードをサポートします。- allowlist モードでは、
network_policy.domain_secretsが名前でドメインスコープのシークレットを注入できます。 - 完全な例については
examples/tools/container_shell_skill_reference.pyとexamples/tools/container_shell_inline_skill.pyを参照してください。 - OpenAI プラットフォームガイド: Shell および Skills。
ローカルランタイムツール
ローカルランタイムツールは、モデル応答自体の外部で実行されます。モデルは依然としていつ呼び出すかを決定しますが、実際の処理はアプリケーションまたは設定された実行環境が行います。
ComputerTool と ApplyPatchTool は、常にユーザーが提供するローカル実装を必要とします。ShellTool は両方のモードにまたがります。管理された実行を行いたい場合は上記のホストされたコンテナー設定を使用し、自分のプロセスでコマンドを実行したい場合は以下のローカルランタイム設定を使用してください。
ローカルランタイムツールでは、実装を提供する必要があります。
ComputerTool: GUI/ブラウザー自動化を有効にするために、ComputerまたはAsyncComputerインターフェイスを実装します。ShellTool: ローカル実行とホストされたコンテナー実行の両方に対応する最新のシェルツールです。LocalShellTool: 従来のローカルシェル統合です。ApplyPatchTool: diff をローカルに適用するためにApplyPatchEditorを実装します。- ローカルシェルスキルは
ShellTool(environment={"type": "local", "skills": [...]})で利用できます。
ComputerTool と Responses コンピュータツール
ComputerTool は引き続きローカルハーネスです。Computer または AsyncComputer 実装を提供し、SDK がそのハーネスを OpenAI Responses API のコンピュータサーフェスにマッピングします。
明示的な gpt-5.5 リクエストでは、SDK は GA 組み込みツールペイロード {"type": "computer"} を送信します。古い computer-use-preview モデルは、プレビュー用ペイロード {"type": "computer_use_preview", "environment": ..., "display_width": ..., "display_height": ...} のままです。これは OpenAI の コンピュータ操作ガイド で説明されているプラットフォーム移行を反映しています。
- モデル:
computer-use-preview->gpt-5.5 - ツールセレクター:
computer_use_preview->computer - コンピュータ呼び出しの形状:
computer_callごとに 1 つのaction->computer_call上のバッチ化されたactions[] - 切り詰め: プレビューパスでは
ModelSettings(truncation="auto")が必要 -> GA パスでは不要
SDK は、実際の Responses リクエストで有効なモデルから、そのワイヤー形式を選択します。プロンプトテンプレートを使用し、プロンプト側がモデルを所有しているためリクエストで model を省略する場合、model="gpt-5.5" を明示したままにするか、ModelSettings(tool_choice="computer") または ModelSettings(tool_choice="computer_use") で GA セレクターを強制しない限り、SDK はプレビュー互換のコンピュータペイロードを維持します。
ComputerTool が存在する場合、tool_choice="computer"、"computer_use"、"computer_use_preview" はすべて受け付けられ、有効なリクエストモデルに一致する組み込みセレクターへ正規化されます。ComputerTool がない場合、これらの文字列は引き続き通常の関数名のように動作します。
この違いは、ComputerTool が ComputerProvider ファクトリによって支えられている場合に重要です。GA の computer ペイロードはシリアライズ時に environment や寸法を必要としないため、未解決のファクトリでも問題ありません。プレビュー互換のシリアライズでは、SDK が environment、display_width、display_height を送信できるように、解決済みの Computer または AsyncComputer インスタンスが必要です。
ランタイムでは、どちらのパスも同じローカルハーネスを使用します。プレビュー応答は単一の action を持つ computer_call アイテムを出力します。gpt-5.5 はバッチ化された actions[] を出力でき、SDK は computer_call_output スクリーンショットアイテムを生成する前に、それらを順番に実行します。実行可能な Playwright ベースのハーネスについては examples/tools/computer_use.py を参照してください。
from agents import Agent, ApplyPatchTool, ShellTool
from agents.computer import AsyncComputer
from agents.editor import ApplyPatchResult, ApplyPatchOperation, ApplyPatchEditor
class NoopComputer(AsyncComputer):
environment = "browser"
dimensions = (1024, 768)
async def screenshot(self): return ""
async def click(self, x, y, button): ...
async def double_click(self, x, y): ...
async def scroll(self, x, y, scroll_x, scroll_y): ...
async def type(self, text): ...
async def wait(self): ...
async def move(self, x, y): ...
async def keypress(self, keys): ...
async def drag(self, path): ...
class NoopEditor(ApplyPatchEditor):
async def create_file(self, op: ApplyPatchOperation): return ApplyPatchResult(status="completed")
async def update_file(self, op: ApplyPatchOperation): return ApplyPatchResult(status="completed")
async def delete_file(self, op: ApplyPatchOperation): return ApplyPatchResult(status="completed")
async def run_shell(request):
return "shell output"
agent = Agent(
name="Local tools agent",
tools=[
ShellTool(executor=run_shell),
ApplyPatchTool(editor=NoopEditor()),
# ComputerTool expects a Computer/AsyncComputer implementation; omitted here for brevity.
],
)
関数ツール
任意の Python 関数をツールとして使用できます。Agents SDK はツールを自動的にセットアップします。
- ツール名は Python 関数の名前になります(または名前を指定できます)
- ツールの説明は関数の docstring から取得されます(または説明を指定できます)
- 関数入力のスキーマは、関数の引数から自動的に作成されます
- 無効にしない限り、各入力の説明は関数の docstring から取得されます
関数シグネチャの抽出には Python の inspect モジュールを使用し、docstring の解析には griffe を、スキーマ作成には pydantic を使用します。
OpenAI Responses モデルを使用している場合、@function_tool(defer_loading=True) は ToolSearchTool() が読み込むまで関数ツールを隠します。関連する関数ツールを tool_namespace() でグループ化することもできます。完全なセットアップと制約については ホストされたツール検索 を参照してください。
import json
from typing_extensions import TypedDict, Any
from agents import Agent, FunctionTool, RunContextWrapper, function_tool
class Location(TypedDict):
lat: float
long: float
@function_tool # (1)!
async def fetch_weather(location: Location) -> str:
# (2)!
"""Fetch the weather for a given location.
Args:
location: The location to fetch the weather for.
"""
# In real life, we'd fetch the weather from a weather API
return "sunny"
@function_tool(name_override="fetch_data") # (3)!
def read_file(ctx: RunContextWrapper[Any], path: str, directory: str | None = None) -> str:
"""Read the contents of a file.
Args:
path: The path to the file to read.
directory: The directory to read the file from.
"""
# In real life, we'd read the file from the file system
return "<file contents>"
agent = Agent(
name="Assistant",
tools=[fetch_weather, read_file], # (4)!
)
for tool in agent.tools:
if isinstance(tool, FunctionTool):
print(tool.name)
print(tool.description)
print(json.dumps(tool.params_json_schema, indent=2))
print()
- 関数の引数には任意の Python 型を使用でき、関数は同期でも非同期でもかまいません。
- Docstring が存在する場合、説明と引数の説明を取得するために使用されます
- 関数は任意で
contextを受け取ることができます(最初の引数でなければなりません)。ツール名、説明、使用する docstring スタイルなどのオーバーライドも設定できます。 - デコレートされた関数をツールのリストに渡すことができます。
出力を表示するには展開してください
fetch_weather
Fetch the weather for a given location.
{
"$defs": {
"Location": {
"properties": {
"lat": {
"title": "Lat",
"type": "number"
},
"long": {
"title": "Long",
"type": "number"
}
},
"required": [
"lat",
"long"
],
"title": "Location",
"type": "object"
}
},
"properties": {
"location": {
"$ref": "#/$defs/Location",
"description": "The location to fetch the weather for."
}
},
"required": [
"location"
],
"title": "fetch_weather_args",
"type": "object"
}
fetch_data
Read the contents of a file.
{
"properties": {
"path": {
"description": "The path to the file to read.",
"title": "Path",
"type": "string"
},
"directory": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "The directory to read the file from.",
"title": "Directory"
}
},
"required": [
"path"
],
"title": "fetch_data_args",
"type": "object"
}
関数ツールからの画像またはファイルの返却
テキスト出力の返却に加えて、関数ツールの出力として 1 つ以上の画像またはファイルを返すことができます。そのためには、次のいずれかを返せます。
- 画像:
ToolOutputImage(または TypedDict 版のToolOutputImageDict) - ファイル:
ToolOutputFileContent(または TypedDict 版のToolOutputFileContentDict) - テキスト: 文字列または文字列化できるオブジェクト、または
ToolOutputText(または TypedDict 版のToolOutputTextDict)
カスタム関数ツール
Python 関数をツールとして使用したくない場合もあります。その場合は、必要に応じて FunctionTool を直接作成できます。次を提供する必要があります。
namedescriptionparams_json_schema: 引数用の JSON スキーマon_invoke_tool:ToolContextと JSON 文字列としての引数を受け取り、ツール出力(たとえば、テキスト、structured tool output オブジェクト、または出力のリスト)を返す非同期関数
from typing import Any
from pydantic import BaseModel
from agents import RunContextWrapper, FunctionTool
def do_some_work(data: str) -> str:
return "done"
class FunctionArgs(BaseModel):
username: str
age: int
async def run_function(ctx: RunContextWrapper[Any], args: str) -> str:
parsed = FunctionArgs.model_validate_json(args)
return do_some_work(data=f"{parsed.username} is {parsed.age} years old")
tool = FunctionTool(
name="process_user",
description="Processes extracted user data",
params_json_schema=FunctionArgs.model_json_schema(),
on_invoke_tool=run_function,
)
引数と docstring の自動解析
前述のとおり、ツールのスキーマを抽出するために関数シグネチャを自動的に解析し、ツールと個々の引数の説明を抽出するために docstring を解析します。これに関するいくつかの注記です。
- シグネチャ解析は
inspectモジュールを通じて行われます。型アノテーションを使用して引数の型を理解し、スキーマ全体を表す Pydantic モデルを動的に構築します。Python の基本コンポーネント、Pydantic モデル、TypedDict など、ほとんどの型をサポートします。 - Docstring の解析には
griffeを使用します。サポートされる docstring 形式はgoogle、sphinx、numpyです。docstring 形式の自動検出を試みますが、これはベストエフォートであり、function_toolを呼び出すときに明示的に設定できます。use_docstring_infoをFalseに設定して、docstring 解析を無効にすることもできます。
スキーマ抽出のコードは agents.function_schema にあります。
Pydantic Field による引数の制約と説明
Pydantic の Field を使用して、ツール引数に制約(例: 数値の最小/最大、文字列の長さやパターン)と説明を追加できます。Pydantic と同様に、デフォルトベース(arg: int = Field(..., ge=1))と Annotated(arg: Annotated[int, Field(..., ge=1)])の両方の形式がサポートされます。生成される JSON スキーマと検証には、これらの制約が含まれます。
from typing import Annotated
from pydantic import Field
from agents import function_tool
# Default-based form
@function_tool
def score_a(score: int = Field(..., ge=0, le=100, description="Score from 0 to 100")) -> str:
return f"Score recorded: {score}"
# Annotated form
@function_tool
def score_b(score: Annotated[int, Field(..., ge=0, le=100, description="Score from 0 to 100")]) -> str:
return f"Score recorded: {score}"
関数ツールのタイムアウト
非同期関数ツールに対して、@function_tool(timeout=...) で呼び出しごとのタイムアウトを設定できます。
import asyncio
from agents import Agent, Runner, function_tool
@function_tool(timeout=2.0)
async def slow_lookup(query: str) -> str:
await asyncio.sleep(10)
return f"Result for {query}"
agent = Agent(
name="Timeout demo",
instructions="Use tools when helpful.",
tools=[slow_lookup],
)
タイムアウトに達すると、デフォルトの動作は timeout_behavior="error_as_result" で、モデルに見えるタイムアウトメッセージ(例: Tool 'slow_lookup' timed out after 2 seconds.)を送信します。
タイムアウト処理は制御できます。
timeout_behavior="error_as_result"(デフォルト): モデルが回復できるようにタイムアウトメッセージを返します。timeout_behavior="raise_exception":ToolTimeoutErrorを発生させ、実行を失敗させます。timeout_error_function=...:error_as_resultを使用する場合のタイムアウトメッセージをカスタマイズします。
import asyncio
from agents import Agent, Runner, ToolTimeoutError, function_tool
@function_tool(timeout=1.5, timeout_behavior="raise_exception")
async def slow_tool() -> str:
await asyncio.sleep(5)
return "done"
agent = Agent(name="Timeout hard-fail", tools=[slow_tool])
try:
await Runner.run(agent, "Run the tool")
except ToolTimeoutError as e:
print(f"{e.tool_name} timed out in {e.timeout_seconds} seconds")
Note
タイムアウト設定は、非同期の @function_tool ハンドラーでのみサポートされます。
関数ツールでのエラー処理
@function_tool を通じて関数ツールを作成するとき、failure_error_function を渡すことができます。これは、ツール呼び出しがクラッシュした場合に LLM へエラー応答を提供する関数です。
- デフォルトでは(つまり何も渡さない場合)、エラーが発生したことを LLM に伝える
default_tool_error_functionが実行されます。 - 独自のエラー関数を渡した場合は、代わりにそれが実行され、応答が LLM に送信されます。
- 明示的に
Noneを渡した場合、ツール呼び出しエラーは再送出され、ユーザー側で処理できます。これは、モデルが無効な JSON を生成した場合のModelBehaviorErrorや、コードがクラッシュした場合のUserErrorなどである可能性があります。
from agents import function_tool, RunContextWrapper
from typing import Any
def my_custom_error_function(context: RunContextWrapper[Any], error: Exception) -> str:
"""A custom function to provide a user-friendly error message."""
print(f"A tool call failed with the following error: {error}")
return "An internal server error occurred. Please try again later."
@function_tool(failure_error_function=my_custom_error_function)
def get_user_profile(user_id: str) -> str:
"""Fetches a user profile from a mock API.
This function demonstrates a 'flaky' or failing API call.
"""
if user_id == "user_123":
return "User profile for user_123 successfully retrieved."
else:
raise ValueError(f"Could not retrieve profile for user_id: {user_id}. API returned an error.")
FunctionTool オブジェクトを手動で作成している場合は、on_invoke_tool 関数内でエラーを処理する必要があります。
Agents as tools
一部のワークフローでは、制御をハンドオフするのではなく、中央のエージェントが専門エージェントのネットワークをオーケストレーションするようにしたい場合があります。これは、エージェントをツールとしてモデル化することで実現できます。
from agents import Agent, Runner
import asyncio
spanish_agent = Agent(
name="Spanish agent",
instructions="You translate the user's message to Spanish",
)
french_agent = Agent(
name="French agent",
instructions="You translate the user's message to French",
)
orchestrator_agent = Agent(
name="orchestrator_agent",
instructions=(
"You are a translation agent. You use the tools given to you to translate."
"If asked for multiple translations, you call the relevant tools."
),
tools=[
spanish_agent.as_tool(
tool_name="translate_to_spanish",
tool_description="Translate the user's message to Spanish",
),
french_agent.as_tool(
tool_name="translate_to_french",
tool_description="Translate the user's message to French",
),
],
)
async def main():
result = await Runner.run(orchestrator_agent, input="Say 'Hello, how are you?' in Spanish.")
print(result.final_output)
ツールエージェントのカスタマイズ
agent.as_tool 関数は、エージェントをツールに変換しやすくするための便利なメソッドです。max_turns、run_config、hooks、previous_response_id、conversation_id、session、needs_approval などの一般的なランタイムオプションをサポートします。また、parameters、input_builder、include_input_schema による structured input もサポートします。高度なオーケストレーション(たとえば、条件付きリトライ、フォールバック動作、複数のエージェント呼び出しのチェーン)には、ツール実装内で Runner.run を直接使用してください。
@function_tool
async def run_my_agent() -> str:
"""A tool that runs the agent with custom configs"""
agent = Agent(name="My agent", instructions="...")
result = await Runner.run(
agent,
input="...",
max_turns=5,
run_config=...
)
return str(result.final_output)
ツールエージェントの structured input
デフォルトでは、Agent.as_tool() は単一の文字列入力({"input": "..."})を想定しますが、parameters(Pydantic モデルまたは dataclass 型)を渡すことで structured schema を公開できます。
追加オプション:
include_input_schema=Trueは、生成されるネストされた入力に完全な JSON Schema を含めます。input_builder=...により、structured tool 引数をネストされたエージェント入力に変換する方法を完全にカスタマイズできます。RunContextWrapper.tool_inputには、ネストされた実行コンテキスト内の解析済み structured payload が含まれます。
完全に実行可能な例については examples/agent_patterns/agents_as_tools_structured.py を参照してください。
ツールエージェントの承認ゲート
Agent.as_tool(..., needs_approval=...) は function_tool と同じ承認フローを使用します。承認が必要な場合、実行は一時停止し、保留中のアイテムが result.interruptions に表示されます。その後、result.to_state() を使用し、state.approve(...) または state.reject(...) を呼び出した後に再開します。完全な一時停止/再開パターンについては、ヒューマンインザループガイド を参照してください。
カスタム出力抽出
特定のケースでは、中央エージェントへ返す前にツールエージェントの出力を変更したい場合があります。これは、次のような場合に役立ちます。
- サブエージェントのチャット履歴から特定の情報(例: JSON ペイロード)を抽出する。
- エージェントの最終回答を変換または再フォーマットする(例: Markdown をプレーンテキストまたは CSV に変換する)。
- 出力を検証する、またはエージェントの応答が欠落しているか不正な形式の場合にフォールバック値を提供する。
これは、as_tool メソッドに custom_output_extractor 引数を指定することで実行できます。
async def extract_json_payload(run_result: RunResult) -> str:
# Scan the agent’s outputs in reverse order until we find a JSON-like message from a tool call.
for item in reversed(run_result.new_items):
if isinstance(item, ToolCallOutputItem) and item.output.strip().startswith("{"):
return item.output.strip()
# Fallback to an empty JSON object if nothing was found
return "{}"
json_tool = data_agent.as_tool(
tool_name="get_data_json",
tool_description="Run the data agent and return only its JSON payload",
custom_output_extractor=extract_json_payload,
)
カスタム抽出器内では、ネストされた RunResult も
agent_tool_invocation を公開します。これは、ネストされた実行結果を後処理するときに、外側のツール名、呼び出し ID、または raw 引数が必要な場合に便利です。
Results ガイド を参照してください。
ネストされたエージェント実行のストリーミング
ネストされたエージェントが出力するストリーミングイベントをリッスンしつつ、ストリーム完了後に最終出力を返すには、as_tool に on_stream コールバックを渡します。
from agents import AgentToolStreamEvent
async def handle_stream(event: AgentToolStreamEvent) -> None:
# Inspect the underlying StreamEvent along with agent metadata.
print(f"[stream] {event['agent'].name} :: {event['event'].type}")
billing_agent_tool = billing_agent.as_tool(
tool_name="billing_helper",
tool_description="Answer billing questions.",
on_stream=handle_stream, # Can be sync or async.
)
想定されること:
- イベントタイプは
StreamEvent["type"]を反映します:raw_response_event、run_item_stream_event、agent_updated_stream_event。 on_streamを指定すると、ネストされたエージェントがストリーミングモードで自動的に実行され、最終出力を返す前にストリームが排出されます。- ハンドラーは同期または非同期のどちらでもよく、各イベントは到着順に配信されます。
- ツールがモデルのツール呼び出し経由で起動された場合は
tool_callが存在します。直接呼び出しではNoneのままになる場合があります。 - 完全に実行可能なサンプルについては
examples/agent_patterns/agents_as_tools_streaming.pyを参照してください。
条件付きツール有効化
is_enabled パラメーターを使用すると、ランタイムでエージェントツールを条件付きで有効または無効にできます。これにより、コンテキスト、ユーザー設定、またはランタイム条件に基づいて、LLM が利用できるツールを動的にフィルタリングできます。
import asyncio
from agents import Agent, AgentBase, Runner, RunContextWrapper
from pydantic import BaseModel
class LanguageContext(BaseModel):
language_preference: str = "french_spanish"
def french_enabled(ctx: RunContextWrapper[LanguageContext], agent: AgentBase) -> bool:
"""Enable French for French+Spanish preference."""
return ctx.context.language_preference == "french_spanish"
# Create specialized agents
spanish_agent = Agent(
name="spanish_agent",
instructions="You respond in Spanish. Always reply to the user's question in Spanish.",
)
french_agent = Agent(
name="french_agent",
instructions="You respond in French. Always reply to the user's question in French.",
)
# Create orchestrator with conditional tools
orchestrator = Agent(
name="orchestrator",
instructions=(
"You are a multilingual assistant. You use the tools given to you to respond to users. "
"You must call ALL available tools to provide responses in different languages. "
"You never respond in languages yourself, you always use the provided tools."
),
tools=[
spanish_agent.as_tool(
tool_name="respond_spanish",
tool_description="Respond to the user's question in Spanish",
is_enabled=True, # Always enabled
),
french_agent.as_tool(
tool_name="respond_french",
tool_description="Respond to the user's question in French",
is_enabled=french_enabled,
),
],
)
async def main():
context = RunContextWrapper(LanguageContext(language_preference="french_spanish"))
result = await Runner.run(orchestrator, "How are you?", context=context.context)
print(result.final_output)
asyncio.run(main())
is_enabled パラメーターは次を受け付けます。
- ブール値:
True(常に有効)またはFalse(常に無効) - 呼び出し可能関数:
(context, agent)を受け取り、ブール値を返す関数 - 非同期関数: 複雑な条件ロジックのための非同期関数
無効化されたツールはランタイムで LLM から完全に隠されるため、次の用途に役立ちます。
- ユーザー権限に基づく機能ゲーティング
- 環境固有のツール可用性(dev と prod)
- 異なるツール構成の A/B テスト
- ランタイム状態に基づく動的なツールフィルタリング
実験的: Codex ツール
codex_tool は Codex CLI をラップし、エージェントがツール呼び出し中にワークスペーススコープのタスク(シェル、ファイル編集、MCP ツール)を実行できるようにします。このサーフェスは実験的であり、変更される可能性があります。
メインエージェントが現在の実行から離れずに、範囲が限定されたワークスペースタスクを Codex に委任したい場合に使用します。デフォルトでは、ツール名は codex です。カスタム名を設定する場合は、codex であるか、codex_ で始まる必要があります。エージェントに複数の Codex ツールを含める場合、それぞれ一意の名前を使用する必要があります。
from agents import Agent
from agents.extensions.experimental.codex import ThreadOptions, TurnOptions, codex_tool
agent = Agent(
name="Codex Agent",
instructions="Use the codex tool to inspect the workspace and answer the question.",
tools=[
codex_tool(
sandbox_mode="workspace-write",
working_directory="/path/to/repo",
default_thread_options=ThreadOptions(
model="gpt-5.5",
model_reasoning_effort="low",
network_access_enabled=True,
web_search_mode="disabled",
approval_policy="never",
),
default_turn_options=TurnOptions(
idle_timeout_seconds=60,
),
persist_session=True,
)
],
)
まず、次のオプショングループから始めてください。
- 実行サーフェス:
sandbox_modeとworking_directoryは Codex が操作できる場所を定義します。これらを組み合わせて使用し、作業ディレクトリが Git リポジトリ内にない場合はskip_git_repo_check=Trueを設定します。 - スレッドのデフォルト:
default_thread_options=ThreadOptions(...)は、モデル、推論エフォート、承認ポリシー、追加ディレクトリ、ネットワークアクセス、Web 検索モードを設定します。従来のweb_search_enabledよりもweb_search_modeを優先してください。 - ターンのデフォルト:
default_turn_options=TurnOptions(...)は、idle_timeout_secondsや任意のキャンセルsignalなど、ターンごとの動作を設定します。 - ツール I/O: ツール呼び出しには、
{ "type": "text", "text": ... }または{ "type": "local_image", "path": ... }を持つinputsアイテムを少なくとも 1 つ含める必要があります。output_schemaにより、structured Codex レスポンスを要求できます。
スレッドの再利用と永続化は別々の制御です。
persist_session=Trueは、同じツールインスタンスへの繰り返し呼び出しに対して 1 つの Codex スレッドを再利用します。use_run_context_thread_id=Trueは、同じ可変コンテキストオブジェクトを共有する実行間で、実行コンテキストにスレッド ID を保存して再利用します。- スレッド ID の優先順位は、呼び出しごとの
thread_id、次に実行コンテキストのスレッド ID(有効な場合)、次に設定されたthread_idオプションです。 - デフォルトの実行コンテキストキーは、
name="codex"の場合はcodex_thread_id、name="codex_<suffix>"の場合はcodex_thread_id_<suffix>です。run_context_thread_id_keyで上書きできます。
ランタイム設定:
- 認証:
CODEX_API_KEY(推奨)またはOPENAI_API_KEYを設定するか、codex_options={"api_key": "..."}を渡します。 - ランタイム:
codex_options.base_urlは CLI ベース URL を上書きします。 - バイナリ解決: CLI パスを固定するには
codex_options.codex_path_override(またはCODEX_PATH)を設定します。それ以外の場合、SDK はPATHからcodexを解決し、その後バンドルされたベンダーバイナリへフォールバックします。 - 環境:
codex_options.envはサブプロセス環境を完全に制御します。指定された場合、サブプロセスはos.environを継承しません。 - ストリーム制限:
codex_options.codex_subprocess_stream_limit_bytes(またはOPENAI_AGENTS_CODEX_SUBPROCESS_STREAM_LIMIT_BYTES)は stdout/stderr リーダーの制限を制御します。有効範囲は65536から67108864で、デフォルトは8388608です。 - ストリーミング:
on_streamはスレッド/ターンのライフサイクルイベントとアイテムイベント(reasoning、command_execution、mcp_tool_call、file_change、web_search、todo_list、およびerrorアイテム更新)を受け取ります。 - 出力: 実行結果には
response、usage、thread_idが含まれます。usage はRunContextWrapper.usageに追加されます。
参考:
- Codex ツール API リファレンス
- ThreadOptions リファレンス
- TurnOptions リファレンス
- 完全に実行可能なサンプルについては
examples/tools/codex.pyとexamples/tools/codex_same_thread.pyを参照してください。