diff --git a/docs/ja/agents.md b/docs/ja/agents.md
index e461d54f1..56457d4e5 100644
--- a/docs/ja/agents.md
+++ b/docs/ja/agents.md
@@ -4,16 +4,16 @@ search:
 ---
 # エージェント
 
-エージェントはアプリケーションの主要な構成要素です。エージェントとは、instructions と tools で構成された大規模言語モデル (LLM) です。
+エージェントはアプリケーションの中心的な構成要素です。エージェントは、instructions とツールで設定された大規模言語モデル ( LLM ) です。
 
 ## 基本設定
 
-エージェントでよく設定するプロパティは次のとおりです。
+エージェントで最も一般的に設定するプロパティは次のとおりです。
 
--   `name`: エージェントを識別する必須の文字列です。  
+-   `name`: 必須の文字列で、エージェントを識別します。  
 -   `instructions`: developer メッセージまたは system prompt とも呼ばれます。  
--   `model`: 使用する LLM を指定します。任意の `model_settings` で temperature、top_p などのモデル調整パラメーターを設定できます。  
--   `tools`: エージェントがタスクを達成するために使用できる tools です。  
+-   `model`: 使用する LLM と、temperature や top_p などのチューニングパラメーターを設定するための任意の `model_settings`。  
+-   `tools`: エージェントがタスクを遂行するために使用できるツール。  
 
 ```python
 from agents import Agent, ModelSettings, function_tool
@@ -30,9 +30,9 @@ agent = Agent(
 )
 ```
 
-## コンテキスト
+## Context
 
-エージェントは汎用的に `context` 型を取り込みます。コンテキストは dependency-injection (依存性注入) 用のオブジェクトで、あなたが作成して `Runner.run()` に渡すことで、すべてのエージェント、tool、ハンドオフなどに共有されます。実行中の依存関係や状態をまとめて保持する入れ物として機能し、任意の Python オブジェクトを渡せます。
+エージェントはその `context` 型に対してジェネリックです。Context は依存性注入ツールで、`Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、実行時の依存関係や状態をまとめて保持します。任意の Python オブジェクトを context として提供できます。
 
 ```python
 @dataclass
@@ -50,7 +50,7 @@ agent = Agent[UserContext](
 
 ## 出力タイプ
 
-デフォルトでは、エージェントはプレーンテキスト (つまり `str`) を出力します。特定の型で出力させたい場合は、`output_type` パラメーターを使用してください。よく使われる選択肢として [Pydantic](https://docs.pydantic.dev/) オブジェクトがありますが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型であれば、dataclass、list、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
@@ -71,11 +71,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.md) のドキュメントをご覧ください。
+ハンドオフは、エージェントが委譲できるサブエージェントです。ハンドオフのリストを渡すと、エージェントは必要に応じてそれらに委譲できます。これは、単一タスクに特化したモジュール型エージェントをオーケストレーションする強力なパターンです。詳細は [handoffs](handoffs.md) のドキュメントをご覧ください。
 
 ```python
 from agents import Agent
@@ -96,7 +96,7 @@ triage_agent = Agent(
 
 ## 動的 instructions
 
-多くの場合、エージェント作成時に instructions を渡せますが、関数を介して動的に instructions を生成することも可能です。その関数は agent と context を受け取り、プロンプトを返さなければなりません。同期関数と `async` 関数のどちらも利用できます。
+通常はエージェント作成時に instructions を渡しますが、関数を介して動的に instructions を生成することもできます。この関数はエージェントと 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.md) のドキュメントをご覧ください。
+ガードレールは、エージェントの実行と並行してユーザー入力に対するチェックやバリデーションを行えます。たとえば、ユーザー入力の関連性をフィルタリングすることができます。詳細は [guardrails](guardrails.md) のドキュメントをご確認ください。
 
 ## エージェントのクローン／コピー
 
-エージェントの `clone()` メソッドを使うと、既存のエージェントを複製し、必要に応じて任意のプロパティを変更できます。
+`clone()` メソッドを使用すると、エージェントを複製し、任意のプロパティを変更できます。
 
 ```python
 pirate_agent = Agent(
@@ -138,15 +138,15 @@ robot_agent = pirate_agent.clone(
 
 ## ツール使用の強制
 
-tools のリストを渡しても、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 にツールの使用を必須とします (どのツールを使うかは LLM が判断)。  
+3. `none`: LLM にツールを使わないことを要求します。  
+4. 特定の文字列 (例: `my_tool`): その特定のツールを使用することを LLM に要求します。  
 
 !!! note
 
-    無限ループを防ぐため、フレームワークはツール呼び出し後に自動で `tool_choice` を "auto" にリセットします。この挙動は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。ツールの実行結果が再び LLM に送られ、`tool_choice` の設定により新たなツール呼び出しが発生し続けるのが無限ループの原因です。
+    無限ループを防ぐために、フレームワークはツール呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この動作は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。無限ループとは、ツール結果が LLM に送られ、`tool_choice` により再びツール呼び出しが生成される、というサイクルを指します。
 
-    ツール呼び出し後に自動モードで継続せず完全に停止したい場合は、[`Agent.tool_use_behavior="stop_on_first_tool"`] を設定してください。ツールの出力をそのまま最終応答として使用し、追加の LLM 処理を行いません。
\ No newline at end of file
+    ツール呼び出し後にエージェントを完全に停止させたい (auto モードで続行させたくない) 場合は、[`Agent.tool_use_behavior="stop_on_first_tool"`] を設定すると、ツールの出力をそのまま最終応答として使用し、追加の LLM 処理を行いません。
\ No newline at end of file
diff --git a/docs/ja/config.md b/docs/ja/config.md
index ca7dea2ca..16f120d16 100644
--- a/docs/ja/config.md
+++ b/docs/ja/config.md
@@ -6,7 +6,7 @@ search:
 
 ## API キーとクライアント
 
-デフォルトでは、 SDK は import された時点で、 LLM リクエストとトレーシング用に `OPENAI_API_KEY` 環境変数を探します。アプリを起動する前にその環境変数を設定できない場合は、[`set_default_openai_key()`][agents.set_default_openai_key] 関数を使ってキーを設定できます。
+デフォルトでは、 SDK はインポートされた直後に LLM リクエストとトレーシングのために `OPENAI_API_KEY` 環境変数を参照します。アプリ起動前にその環境変数を設定できない場合は、 [set_default_openai_key()][agents.set_default_openai_key] 関数を使用してキーを設定できます。
 
 ```python
 from agents import set_default_openai_key
@@ -14,7 +14,7 @@ from agents import set_default_openai_key
 set_default_openai_key("sk-...")
 ```
 
-別の方法として、使用する OpenAI クライアントを設定することもできます。デフォルトでは、 SDK は環境変数または上記で設定したデフォルトキーを用いて `AsyncOpenAI` インスタンスを生成します。これを変更したい場合は、[`set_default_openai_client()`][agents.set_default_openai_client] 関数を使用してください。
+また、使用する OpenAI クライアントを設定することもできます。デフォルトでは、 SDK は環境変数または前述のデフォルトキーを用いて `AsyncOpenAI` インスタンスを生成します。これを変更するには、 [set_default_openai_client()][agents.set_default_openai_client] 関数を使用します。
 
 ```python
 from openai import AsyncOpenAI
@@ -24,7 +24,7 @@ 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] 関数をご利用ください。
+最後に、使用する 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
@@ -34,7 +34,7 @@ set_default_openai_api("chat_completions")
 
 ## トレーシング
 
-トレーシングはデフォルトで有効になっています。デフォルトでは、上記のセクションで設定した OpenAI API キー（環境変数またはデフォルトキー）を使用します。トレーシングで使用する API キーを個別に設定したい場合は、[`set_tracing_export_api_key`][agents.set_tracing_export_api_key] 関数を使用できます。
+トレーシングはデフォルトで有効です。デフォルトでは、前述の OpenAI API キー（環境変数または設定したデフォルトキー）が使用されます。トレーシングに使用する API キーを個別に設定したい場合は、 [`set_tracing_export_api_key`][agents.set_tracing_export_api_key] 関数を使用します。
 
 ```python
 from agents import set_tracing_export_api_key
@@ -42,7 +42,7 @@ from agents import set_tracing_export_api_key
 set_tracing_export_api_key("sk-...")
 ```
 
-さらに、[`set_tracing_disabled()`][agents.set_tracing_disabled] 関数を使うことで、トレーシングを完全に無効化できます。
+トレーシングを完全に無効化することも可能です。 [`set_tracing_disabled()`][agents.set_tracing_disabled] 関数を使用してください。
 
 ```python
 from agents import set_tracing_disabled
@@ -52,9 +52,9 @@ set_tracing_disabled(True)
 
 ## デバッグログ
 
- SDK には、ハンドラーが設定されていない Python ロガーが 2 つあります。デフォルトでは、警告とエラーのみが `stdout` に出力され、それ以外のログは抑制されます。
+SDK には、ハンドラーが設定されていない Python ロガーが２つあります。そのため、デフォルトでは警告とエラーのみが `stdout` に出力され、それ以外のログは抑制されます。
 
-詳細なログを有効にするには、[`enable_verbose_stdout_logging()`][agents.enable_verbose_stdout_logging] 関数を使用してください。
+詳細なログを有効にするには、 [`enable_verbose_stdout_logging()`][agents.enable_verbose_stdout_logging] 関数を使用します。
 
 ```python
 from agents import enable_verbose_stdout_logging
@@ -62,7 +62,7 @@ from agents import enable_verbose_stdout_logging
 enable_verbose_stdout_logging()
 ```
 
-ハンドラー、フィルター、フォーマッターなどを追加してログをカスタマイズすることもできます。詳細は [Python logging guide](https://docs.python.org/3/howto/logging.html) をご覧ください。
+また、ハンドラー、フィルター、フォーマッターなどを追加してログをカスタマイズすることもできます。詳細は [Python logging guide](https://docs.python.org/3/howto/logging.html) をご覧ください。
 
 ```python
 import logging
@@ -81,17 +81,17 @@ logger.setLevel(logging.WARNING)
 logger.addHandler(logging.StreamHandler())
 ```
 
-### ログに含まれる機微なデータ
+### ログ内の機密データ
 
-一部のログには機微なデータ（例: ユーザー データ）が含まれる場合があります。これらのデータの記録を無効化したい場合は、以下の環境変数を設定してください。
+一部のログには機密データ（例: ユーザーデータ）が含まれる場合があります。これらのデータを記録しないようにするには、以下の環境変数を設定してください。
 
-LLM の入力および出力のロギングを無効にするには:
+LLM の入力および出力のログを無効化する:
 
 ```bash
 export OPENAI_AGENTS_DONT_LOG_MODEL_DATA=1
 ```
 
-ツールの入力および出力のロギングを無効にするには:
+ツールの入力および出力のログを無効化する:
 
 ```bash
 export OPENAI_AGENTS_DONT_LOG_TOOL_DATA=1
diff --git a/docs/ja/context.md b/docs/ja/context.md
index eb1410d93..e25a25e7f 100644
--- a/docs/ja/context.md
+++ b/docs/ja/context.md
@@ -4,30 +4,30 @@ search:
 ---
 # コンテキスト管理
 
-コンテキスト (context) という言葉には複数の意味があります。主に次の 2 つのコンテキストを扱います。
+コンテキストという言葉には複数の意味があります。ここでは主に次の 2 つのカテゴリーについて扱います。
 
-1. コード側でローカルに利用できるコンテキスト: これはツール関数実行時や `on_handoff` のようなコールバック、ライフサイクルフックなどで必要になるデータや依存関係です。  
-2. LLM が利用できるコンテキスト: これはレスポンス生成時に LLM が参照できるデータです。
+1. コード内でローカルに利用できるコンテキスト: ツール関数の実行時、`on_handoff` のようなコールバック、ライフサイクルフックなどで必要となるデータや依存関係。
+2. LLM が参照できるコンテキスト: LLM がレスポンスを生成する際に参照するデータ。
 
 ## ローカルコンテキスト
 
-ローカルコンテキストは [`RunContextWrapper`][agents.run_context.RunContextWrapper] クラスと、その中の [`context`][agents.run_context.RunContextWrapper.context] プロパティで表現されます。動作の流れは次のとおりです。
+これは [`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. 任意の Python オブジェクトを作成します。一般的には dataclass や Pydantic オブジェクトを使うパターンが多いです。
+2. そのオブジェクトを各種 run メソッド（例: `Runner.run(..., **context=whatever**)`）に渡します。
+3. すべてのツール呼び出しやライフサイクルフックには `RunContextWrapper[T]` というラッパーオブジェクトが渡されます。`T` はコンテキストオブジェクトの型で、`wrapper.context` からアクセスできます。
 
-**最も重要なポイント** : 1 つのエージェント実行につき、エージェント、ツール関数、ライフサイクルフックなどはすべて同じ _型_ のコンテキストを使用する必要があります。
+最も重要なポイントは、1 回のエージェント実行内で使用されるすべてのエージェント、ツール関数、ライフサイクルフックが同じ「型」のコンテキストを共有しなければならないということです。
 
-コンテキストの主な用途は次のとおりです。
+コンテキストを利用して、次のようなことが可能です。
 
--   実行に関するデータ (例: ユーザー名 / uid などの ユーザー 情報)
--   依存関係 (例: ロガーオブジェクト、データフェッチャーなど)
+-   実行に関するデータ（例: ユーザー名 / UID などユーザーに関する情報）
+-   依存関係（例: ロガーオブジェクト、データフェッチャーなど）
 -   ヘルパー関数
 
 !!! danger "Note"
 
-    コンテキストオブジェクトは **LLM に送信されません**。あくまでローカルで読み書きやメソッド呼び出しを行うためのオブジェクトです。
+    コンテキストオブジェクトは **LLM に送信されません**。これは完全にローカルなオブジェクトであり、読み書きやメソッド呼び出しのみが行えます。
 
 ```python
 import asyncio
@@ -66,17 +66,17 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-1. これがコンテキストオブジェクトです。ここでは dataclass を使っていますが、任意の型で構いません。  
-2. これはツールです。`RunContextWrapper[UserInfo]` を受け取り、実装内でコンテキストを参照しています。  
-3. エージェントにジェネリック型 `UserInfo` を指定することで、型チェッカーがエラーを検出できます（異なるコンテキスト型のツールを渡そうとした場合など）。  
-4. `run` 関数にコンテキストを渡します。  
-5. エージェントはツールを正しく呼び出し、年齢を取得します。  
+1. これはコンテキストオブジェクトです。ここでは dataclass を使用していますが、どのような型でも構いません。
+2. これはツールです。`RunContextWrapper[UserInfo]` を受け取り、実装内でコンテキストを読み取っています。
+3. ジェネリック型 `UserInfo` をエージェントに指定し、型チェッカーがエラーを検出できるようにします（例: 異なるコンテキスト型を要求するツールを渡そうとした場合など）。
+4. `run` 関数にコンテキストを渡します。
+5. エージェントはツールを正しく呼び出し、年齢を取得します。
 
 ## エージェント / LLM コンテキスト
 
-LLM が呼び出される際、LLM が参照できるデータは会話履歴のみです。そのため、新しいデータを LLM に渡したい場合は、会話履歴に含める形で提供する必要があります。主な方法は次のとおりです。
+ LLM が呼び出される際、**唯一** 参照できるデータは会話履歴に含まれるものだけです。つまり、新しいデータを LLM に利用させたい場合は、会話履歴にそのデータを含める必要があります。主な方法は次のとおりです。
 
-1. Agent の `instructions` に追加する。これは「システムプロンプト」や「デベロッパーメッセージ」とも呼ばれます。システムプロンプトは静的な文字列でも、コンテキストを受け取って文字列を返す動的関数でも構いません。ユーザー名や現在の日付など、常に有用な情報を渡す場合によく使われます。  
-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. function tools を通じて公開する。オンデマンドでコンテキストを取得させたい場合に便利で、LLM が必要に応じてツールを呼び出してデータを取得します。  
-4. retrieval や web search を使用する。retrieval はファイルやデータベースから関連データを取得し、web search は Web から取得します。これにより、回答を関連コンテキストで「グラウンディング」できます。
\ No newline at end of file
+1. Agent の `instructions` に追加する。これは「system prompt」あるいは「developer message」とも呼ばれます。system prompt は静的な文字列でも、コンテキストを受け取って文字列を返す動的関数でも構いません。ユーザー名や現在の日付など常に役立つ情報に適した方法です。
+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. リトリーバルや Web 検索を使用する。これはファイルやデータベースから関連データを取得する（リトリーバル）あるいは Web から取得する（Web 検索）特殊なツールです。関連コンテキストに基づいてレスポンスを「グラウンディング」する際に有用です。
\ No newline at end of file
diff --git a/docs/ja/examples.md b/docs/ja/examples.md
index b00ce3f9a..8486317cb 100644
--- a/docs/ja/examples.md
+++ b/docs/ja/examples.md
@@ -4,41 +4,44 @@ search:
 ---
 # コード例
 
-[リポジトリ](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 のさまざまなサンプル実装が掲載されています。これらのコード例は、異なるパターンや機能を示す複数のカテゴリーに整理されています。
 
 ## カテゴリー
 
-- **[エージェントパターン](https://github.com/openai/openai-agents-python/tree/main/examples/agent_patterns):**  
-  このカテゴリーでは、以下のような一般的なエージェント設計パターンを紹介します。  
+- **[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/basic):**  
-  ここでは、SDK の基礎となる機能を確認できます。  
     - 動的な system prompt  
     - ストリーミング出力  
     - ライフサイクルイベント  
 
-- **[ツール例](https://github.com/openai/openai-agents-python/tree/main/examples/tools):**  
-  Web 検索やファイル検索などの OpenAI がホストするツールを実装し、エージェントに統合する方法を学べます。  
+- **[tool examples](https://github.com/openai/openai-agents-python/tree/main/examples/tools):**  
+  OpenAI がホストするツールである Web 検索やファイル検索を実装し、エージェントに統合する方法を学べます。
 
-- **[モデルプロバイダー](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers):**  
-  OpenAI 以外のモデルを SDK と併用する方法を学べます。  
+- **[model providers](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers):**  
+  OpenAI 以外のモデルを SDK で使用する方法を確認できます。
 
-- **[ハンドオフ](https://github.com/openai/openai-agents-python/tree/main/examples/handoffs):**  
-  エージェントのハンドオフを実践的に示す例です。  
+- **[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](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**: シンプルな deep research クローン。  
+  実際のユースケースを想定した、さらに作り込まれた 2 つのコード例です。
+
+    - **customer_service**: 航空会社向けの顧客サービスシステムの例  
+    - **research_bot**: シンプルなディープリサーチ クローン  
 
-- **[音声](https://github.com/openai/openai-agents-python/tree/main/examples/voice):**  
-  TTS や STT モデルを使用した音声エージェントの例を確認できます。  
+- **[voice](https://github.com/openai/openai-agents-python/tree/main/examples/voice):**  
+  TTS と STT モデルを使った音声エージェントの例を確認できます。
 
-- **[リアルタイム](https://github.com/openai/openai-agents-python/tree/main/examples/realtime):**  
-  SDK を用いてリアルタイム体験を構築する方法を示す例です。
\ No newline at end of file
+- **[realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime):**  
+  SDK を用いてリアルタイム体験を構築する方法を示すコード例です。
\ No newline at end of file
diff --git a/docs/ja/guardrails.md b/docs/ja/guardrails.md
index 568c6c50c..cddc56083 100644
--- a/docs/ja/guardrails.md
+++ b/docs/ja/guardrails.md
@@ -4,44 +4,44 @@ search:
 ---
 # ガードレール
 
-ガードレールはエージェントと _並行して_ 実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、非常に高性能（その分、低速かつ高コスト）のモデルを用いて顧客の問い合わせを処理するエージェントがあるとします。悪意のあるユーザーに、そのモデルを使って数学の宿題を解かせたくはありません。そこで、低コストかつ高速なモデルでガードレールを実行します。ガードレールが不正利用を検知した場合、ただちにエラーを発生させ、高価なモデルの実行を止めて時間とコストを節約できます。
+ガードレールはエージェントと _並列_ で実行され、ユーザー入力をチェックしてバリデーションを行えます。たとえば、非常に賢い（つまり遅くて高価な）モデルを用いてカスタマーリクエストに対応するエージェントがあるとします。悪意のあるユーザーがそのモデルに数学の宿題を手伝わせようとするのは避けたいでしょう。そこで、速くて安価なモデルを使ったガードレールを実行します。ガードレールが不正な使用を検知した場合はただちにエラーを発生させ、高価なモデルの実行を止めることで時間と費用を節約できます。
 
-ガードレールには 2 種類あります:
+ガードレールには 2 種類あります。
 
 1. Input ガードレールは最初のユーザー入力に対して実行されます  
-2. Output ガードレールは最終的なエージェント出力に対して実行されます
+2. Output ガードレールは最終的なエージェント出力に対して実行されます  
 
-## Input ガードレール
+## 入力ガードレール
 
-Input ガードレールは 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] 例外が送出されるため、ユーザーへ適切に応答するか、例外を処理できます。
+1. まず、エージェントに渡されたものと同じ入力をガードレールが受け取ります。  
+2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、それが [`InputGuardrailResult`][agents.guardrail.InputGuardrailResult] にラップされます。  
+3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。true の場合は [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered] 例外を送出し、ユーザーへの応答や例外処理を行います。  
 
 !!! Note
 
-    Input ガードレールはユーザー入力に対して実行されることを想定しています。そのためガードレールはエージェントが *最初の* エージェントである場合にのみ実行されます。「`guardrails` プロパティがエージェントにあるのはなぜで、`Runner.run` に渡さないのか？」と思うかもしれません。ガードレールは実際のエージェントと強く関連する傾向があるため、エージェントごとに異なるガードレールを設定します。コードを同じ場所に置くことで可読性が向上します。
+    入力ガードレールはユーザー入力に対して実行されることを想定しているため、エージェントが *最初* のエージェントである場合にのみガードレールが実行されます。`guardrails` プロパティがエージェントにあるのはなぜか、`Runner.run` に渡さないのはなぜかと疑問に思うかもしれません。これはガードレールが実際のエージェントに密接に関連していることが多く、エージェントごとに異なるガードレールを実行するため、コードを同じ場所に置いたほうが可読性が高いからです。
 
-## Output ガードレール
+## 出力ガードレール
 
-Output ガードレールは 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] 例外が送出されるため、ユーザーへ適切に応答するか、例外を処理できます。
+1. まず、エージェントが生成した出力をガードレールが受け取ります。  
+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 ガードレールは最終的なエージェント出力に対して実行されることを想定しています。そのためガードレールはエージェントが *最後の* エージェントである場合にのみ実行されます。Input ガードレールと同様に、ガードレールは実際のエージェントと強く関連するため、コードを同じ場所に置くことで可読性が向上します。
+    出力ガードレールは最終的なエージェント出力に対して実行されることを想定しているため、エージェントが *最後* のエージェントである場合にのみガードレールが実行されます。入力ガードレールと同様に、ガードレールは実際のエージェントに密接に関連しているため、コードを同じ場所に置いたほうが可読性が高いという理由です。
 
-## Tripwires
+## トリップワイヤー
 
-入力または出力がガードレールに失敗した場合、ガードレールはトリップワイヤーでこれを通知できます。トリップワイヤーが発火したガードレールを検知すると、ただちに `{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
+入力または出力がガードレールを通過しなかった場合、ガードレールはトリップワイヤーをトリガーすることでそれを知らせます。トリップワイヤーが作動したガードレールを検知した時点で、ただちに `{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
 
 ## ガードレールの実装
 
-入力を受け取り、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。以下の例では、その裏でエージェントを実行してこれを行います。
+入力を受け取り、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。以下の例では、その内部でエージェントを実行してこれを行います。
 
 ```python
 from pydantic import BaseModel
@@ -95,11 +95,11 @@ async def main():
 ```
 
 1. このエージェントをガードレール関数内で使用します。  
-2. これはエージェントの入力/コンテキストを受け取り、結果を返すガードレール関数です。  
-3. ガードレール結果には追加情報を含めることができます。  
-4. こちらがワークフローを定義する実際のエージェントです。
+2. これはエージェントの入力／コンテキストを受け取り、結果を返すガードレール関数です。  
+3. ガードレール結果に追加情報を含めることができます。  
+4. これはワークフローを定義する実際のエージェントです。  
 
-Output ガードレールも同様です。
+出力ガードレールも同様です。
 
 ```python
 from pydantic import BaseModel
@@ -152,7 +152,7 @@ async def main():
         print("Math output guardrail tripped")
 ```
 
-1. こちらは実際のエージェントの出力型です。  
-2. こちらはガードレールの出力型です。  
+1. これは実際のエージェントの出力型です。  
+2. これはガードレールの出力型です。  
 3. これはエージェントの出力を受け取り、結果を返すガードレール関数です。  
-4. こちらがワークフローを定義する実際のエージェントです。
\ No newline at end of file
+4. これはワークフローを定義する実際のエージェントです。
\ No newline at end of file
diff --git a/docs/ja/handoffs.md b/docs/ja/handoffs.md
index f8e29cca2..a57ccae11 100644
--- a/docs/ja/handoffs.md
+++ b/docs/ja/handoffs.md
@@ -4,19 +4,19 @@ search:
 ---
 # ハンドオフ
 
-ハンドオフを使用すると、エージェント がタスクを別の エージェント に委任できます。これは、異なる エージェント がそれぞれ固有の分野を専門とするシナリオで特に便利です。たとえば、カスタマーサポートアプリでは、注文状況、返金、 FAQ などのタスクを個別に処理する エージェント が存在する場合があります。
+ハンドオフを使用すると、あるエージェントが別のエージェントへタスクを委任できます。これは、異なるエージェントがそれぞれ異なる領域を専門としているシナリオで特に役立ちます。たとえば、カスタマーサポートアプリでは、注文状況、返金、FAQ などを個別に担当するエージェントがいる場合があります。
 
-ハンドオフは LLM にはツールとして表現されます。したがって `Refund Agent` へのハンドオフがある場合、ツール名は `transfer_to_refund_agent` になります。
+ハンドオフは LLM に対してツールとして表現されます。たとえば、`Refund Agent` へのハンドオフがある場合、ツール名は `transfer_to_refund_agent` になります。
 
 ## ハンドオフの作成
 
-すべての エージェント には [`handoffs`][agents.agent.Agent.handoffs] パラメーターがあります。これは `Agent` を直接渡すことも、ハンドオフをカスタマイズする `Handoff` オブジェクトを渡すこともできます。
+すべてのエージェントは [`handoffs`][agents.agent.Agent.handoffs] パラメーターを持ち、ここには `Agent` を直接渡すことも、ハンドオフをカスタマイズする `Handoff` オブジェクトを渡すこともできます。
 
-Agents SDK が提供する [`handoff()`][agents.handoffs.handoff] 関数を使用してハンドオフを作成できます。この関数では、ハンドオフ先の エージェント を指定できるほか、オーバーライドや入力フィルターも任意で設定できます。
+Agents SDK が提供する [`handoff()`][agents.handoffs.handoff] 関数を使用してハンドオフを作成できます。この関数では、ハンドオフ先のエージェントに加え、オプションで上書き設定や入力フィルターを指定できます。
 
-### 基本的な使用方法
+### 基本的な使い方
 
-シンプルなハンドオフを作成する方法は次のとおりです:
+以下はシンプルなハンドオフの作成例です。
 
 ```python
 from agents import Agent, handoff
@@ -28,18 +28,18 @@ refund_agent = Agent(name="Refund agent")
 triage_agent = Agent(name="Triage agent", handoffs=[billing_agent, handoff(refund_agent)])
 ```
 
-1. `billing_agent` のように エージェント を直接渡すことも、`handoff()` 関数を使用することもできます。
+1. `billing_agent` のようにエージェントを直接指定することも、`handoff()` 関数を利用することもできます。
 
 ### `handoff()` 関数によるハンドオフのカスタマイズ
 
-[`handoff()`][agents.handoffs.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`: 次の エージェント が受け取る入力をフィルターできます。詳細は後述します。
+- `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
@@ -57,9 +57,9 @@ handoff_obj = handoff(
 )
 ```
 
-## ハンドオフの入力
+## ハンドオフ入力
 
-状況によっては、ハンドオフを呼び出す際に LLM から何らかのデータを渡してほしい場合があります。たとえば「Escalation agent」へのハンドオフを考えてみましょう。理由を渡してログに残したいかもしれません。
+場合によっては、LLM がハンドオフを呼び出す際にデータを渡すことが必要です。たとえば「Escalation agent」へのハンドオフでは、理由を渡してログに残したいかもしれません。
 
 ```python
 from pydantic import BaseModel
@@ -83,9 +83,9 @@ handoff_obj = handoff(
 
 ## 入力フィルター
 
-ハンドオフが発生すると、新しい エージェント が会話を引き継ぎ、これまでの会話履歴をすべて閲覧できる状態になります。これを変更したい場合は、[`input_filter`][agents.handoffs.Handoff.input_filter] を設定できます。入力フィルターは、[`HandoffInputData`][agents.handoffs.HandoffInputData] を介して既存の入力を受け取り、新しい `HandoffInputData` を返す関数です。
+ハンドオフが発生すると、新しいエージェントが会話を引き継ぎ、これまでの会話履歴全体を閲覧できます。これを変更したい場合は、[`input_filter`][agents.handoffs.Handoff.input_filter] を設定します。入力フィルターは [`HandoffInputData`][agents.handoffs.HandoffInputData] を受け取り、新しい `HandoffInputData` を返す関数です。
 
-履歴からすべてのツール呼び出しを削除するなど、よくあるパターンが [`agents.extensions.handoff_filters`][] に実装されています。
+よくあるパターン (たとえば履歴からすべてのツール呼び出しを削除する) は [`agents.extensions.handoff_filters`][] に実装されています。
 
 ```python
 from agents import Agent, handoff
@@ -99,11 +99,11 @@ handoff_obj = handoff(
 )
 ```
 
-1. `FAQ agent` が呼び出されたとき、履歴からすべてのツールが自動的に削除されます。
+1. これにより、`FAQ agent` が呼び出されたときに履歴からすべてのツールが自動的に削除されます。
 
 ## 推奨プロンプト
 
-LLM がハンドオフを正しく理解できるよう、 エージェント にハンドオフに関する情報を含めることを推奨します。[`agents.extensions.handoff_prompt.RECOMMENDED_PROMPT_PREFIX`][] に推奨プレフィックスが用意されているほか、[`agents.extensions.handoff_prompt.prompt_with_handoff_instructions`][] を呼び出してプロンプトに推奨データを自動的に追加することもできます。
+LLM がハンドオフを正しく理解できるように、エージェントにハンドオフに関する情報を含めることを推奨します。[`agents.extensions.handoff_prompt.RECOMMENDED_PROMPT_PREFIX`][] に推奨の接頭辞が用意されているほか、[`agents.extensions.handoff_prompt.prompt_with_handoff_instructions`][] を呼び出してプロンプトに推奨情報を自動的に追加することもできます。
 
 ```python
 from agents import Agent
diff --git a/docs/ja/index.md b/docs/ja/index.md
index a13c6ec3b..53b8738d0 100644
--- a/docs/ja/index.md
+++ b/docs/ja/index.md
@@ -4,31 +4,31 @@ search:
 ---
 # OpenAI Agents SDK
 
-[OpenAI Agents SDK](https://github.com/openai/openai-agents-python) は、少ない抽象化で軽量かつ使いやすいパッケージを通じて、エージェント指向の AI アプリを構築できるようにします。これは、以前のエージェント向け実験プロジェクトである [Swarm](https://github.com/openai/swarm/tree/main) を本番利用向けにアップグレードしたものです。Agents SDK にはごく少数の基本コンポーネントが用意されています。
+[OpenAI Agents SDK](https://github.com/openai/openai-agents-python) は、最小限の抽象化でエージェント的な AI アプリを軽量かつ簡単に構築できるパッケージです。これは、以前のエージェント向け実験プロジェクトである [Swarm](https://github.com/openai/swarm/tree/main) を本番環境向けにアップグレードしたものです。Agents SDK には、非常に小さな基本コンポーネントがあります:
 
-- **エージェント** — instructions と tools を備えた LLM  
-- **ハンドオフ** — エージェントが特定タスクを他のエージェントへ委任できます  
-- **ガードレール** — エージェントへの入力を検証できます  
-- **セッション** — エージェント実行間で会話履歴を自動的に保持します  
+-   **エージェント**: instructions と tools を備えた LLM
+-   **ハンドオフ**: 特定タスクを他のエージェントに委任する仕組み
+-   **ガードレール**: エージェントへの入力を検証する仕組み
+-   **セッション**: エージェント実行間で会話履歴を自動的に保持
 
-Python と組み合わせることで、これらの基本コンポーネントはツールとエージェント間の複雑な関係性を表現でき、学習コストを抑えながら実運用レベルのアプリケーションを構築できます。さらに、SDK にはワークフローを可視化・デバッグできる **トレーシング** が組み込まれており、評価やファインチューニング、蒸留など OpenAI の各種ツールも利用可能です。
+Python と組み合わせることで、これらの基本コンポーネントはツールとエージェント間の複雑な関係を表現でき、急な学習コストなしに実用的なアプリケーションを構築できます。さらに、SDK には組み込みの **トレーシング** があり、エージェントフローの可視化とデバッグに加えて、評価やモデルのファインチューニングまで行えます。
 
-## Agents SDK の利点
+## Agents SDK を使用する理由
 
-本 SDK には、次の 2 つの設計原則があります。
+SDK には 2 つの設計原則があります:
 
-1. 使う価値がある十分な機能を備えつつ、学習が速いように基本コンポーネントを最小限にする。  
-2. すぐに使える状態で動作する一方、挙動を細かくカスタマイズできる。
+1. 使う価値のある十分な機能を持ちつつ、学習コストが低い最小限の基本コンポーネント。
+2. デフォルトで優れた動作を提供しつつ、挙動を自由にカスタマイズできること。
 
-主な機能は以下のとおりです。
+主な機能は次のとおりです:
 
-- **Agent loop**: ツール呼び出し、結果を LLM へ送信、LLM が完了するまでループする処理を内蔵  
-- **Python ファースト**: 新しい抽象を覚えることなく、Python の言語機能でエージェントをオーケストレーション・連鎖可能  
-- **ハンドオフ**: 複数エージェント間の協調や委任を行える強力な機能  
-- **ガードレール**: エージェントと並行して入力検証を実行し、チェック失敗時には早期終了  
-- **セッション**: エージェント実行間の会話履歴を自動管理し、手動での状態管理を不要化  
-- **Function tools**: 任意の Python 関数をツール化し、自動スキーマ生成と Pydantic でのバリデーションを提供  
-- **トレーシング**: ワークフローの可視化・デバッグ・モニタリングに加え、OpenAI の評価、ファインチューニング、蒸留ツールを利用可能  
+-   Agent loop: ツールの呼び出し、実行結果を LLM へ渡し、LLM が完了するまでループする処理を組み込みで提供します。
+-   Python ファースト: 新しい抽象を学ぶ必要なく、Python の言語機能だけでエージェントをオーケストレーションして連鎖できます。
+-   Handoffs: 複数エージェント間での調整と委任を可能にする強力な機能。
+-   Guardrails: エージェントと並行して入力バリデーションやチェックを実行し、失敗時には早期終了します。
+-   Sessions: エージェント実行をまたいで会話履歴を自動管理し、手動の状態管理を排除します。
+-   Function tools: 任意の Python 関数をツール化し、自動スキーマ生成と Pydantic によるバリデーションを提供します。
+-   Tracing: ワークフローの可視化、デバッグ、モニタリングができ、OpenAI の評価・ファインチューニング・蒸留ツール群とも連携します。
 
 ## インストール
 
@@ -51,7 +51,7 @@ print(result.final_output)
 # Infinite loop's dance.
 ```
 
-(_実行する場合は `OPENAI_API_KEY` 環境変数を設定してください_)
+ (_実行する際は、`OPENAI_API_KEY` 環境変数を設定してください_) 
 
 ```bash
 export OPENAI_API_KEY=sk-...
diff --git a/docs/ja/mcp.md b/docs/ja/mcp.md
index 6d45c717e..8019430c8 100644
--- a/docs/ja/mcp.md
+++ b/docs/ja/mcp.md
@@ -2,25 +2,25 @@
 search:
   exclude: true
 ---
-# Model context protocol (MCP)
+# モデルコンテキストプロトコル (MCP)
 
-[Model context protocol](https://modelcontextprotocol.io/introduction)（以下 MCP）は、LLM にツールとコンテキストを提供するための方法です。MCP のドキュメントより引用します。
+[Model context protocol](https://modelcontextprotocol.io/introduction) (通称 MCP) は、LLM にツールとコンテキストを提供するための方法です。MCP ドキュメントからの引用:
 
-> MCP は、アプリケーションが LLM にコンテキストを提供する方法を標準化するオープンプロトコルです。MCP を AI アプリケーション向けの USB-C ポートのようなものと考えてください。USB-C がデバイスを周辺機器やアクセサリに接続する統一規格を提供するように、MCP は AI モデルをさまざまなデータソースやツールに接続する統一規格を提供します。
+> MCP は、アプリケーションが LLM にコンテキストを提供する方法を標準化するオープンプロトコルです。MCP を AI アプリケーション向けの USB-C ポートと考えてみてください。USB-C がデバイスをさまざまな周辺機器やアクセサリに接続するための標準化された方法を提供するように、MCP も AI モデルを多様なデータソースやツールに接続するための標準化された方法を提供します。
 
-Agents SDK は MCP をサポートしています。これにより、多様な MCP サーバーを使用してエージェントにツールやプロンプトを提供できます。
+Agents SDK は MCP をサポートしています。これにより、幅広い MCP サーバーを使用してエージェントにツールやプロンプトを提供できます。
 
 ## MCP サーバー
 
-現在、MCP の仕様では、使用するトランスポート方式に基づき 3 種類のサーバーが定義されています。
+現時点で MCP 仕様では、使用するトランスポートメカニズムに基づいて次の 3 種類のサーバーを定義しています。
 
-1. **stdio** サーバー: アプリケーションのサブプロセスとして実行されます。ローカルで動作するイメージです。  
-2. **HTTP over SSE** サーバー: リモートで実行され、URL を介して接続します。  
-3. **Streamable HTTP** サーバー: MCP 仕様で定義されている Streamable HTTP トランスポートを用いてリモートで実行されます。  
+1. **stdio** サーバーは、アプリケーションのサブプロセスとして実行されます。ローカルで動作していると考えてください。
+2. **HTTP over SSE** サーバーはリモートで動作し、URL を介して接続します。
+3. **Streamable HTTP** サーバーは、MCP 仕様で定義された Streamable HTTP トランスポートを使用してリモートで動作します。
 
 これらのサーバーへは [`MCPServerStdio`][agents.mcp.server.MCPServerStdio]、[`MCPServerSse`][agents.mcp.server.MCPServerSse]、[`MCPServerStreamableHttp`][agents.mcp.server.MCPServerStreamableHttp] クラスを使用して接続できます。
 
-たとえば、[公式 MCP filesystem サーバー](https://www.npmjs.com/package/@modelcontextprotocol/server-filesystem) を利用する場合は次のようになります。
+たとえば、[公式 MCP filesystem サーバー](https://www.npmjs.com/package/@modelcontextprotocol/server-filesystem) を使用する場合は次のようになります。
 
 ```python
 from agents.run_context import RunContextWrapper
@@ -41,7 +41,7 @@ async with MCPServerStdio(
 
 ## MCP サーバーの使用
 
-MCP サーバーはエージェントに追加できます。Agents SDK はエージェントが実行されるたびに MCP サーバーへ `list_tools()` を呼び出し、LLM に MCP サーバーのツールを認識させます。LLM が MCP サーバーのツールを呼び出すと、SDK はそのサーバーの `call_tool()` を実行します。
+MCP サーバーはエージェントに追加できます。Agents SDK はエージェント実行のたびに MCP サーバーの `list_tools()` を呼び出し、LLM に MCP サーバーのツールを認識させます。LLM が MCP サーバーのツールを呼び出すと、SDK はそのサーバーの `call_tool()` を実行します。
 
 ```python
 
@@ -52,13 +52,13 @@ agent=Agent(
 )
 ```
 
-## ツールのフィルタリング
+## ツールフィルタリング
 
-MCP サーバーではツールフィルターを設定して、エージェントが利用できるツールを制御できます。SDK は静的フィルタリングと動的フィルタリングの両方をサポートします。
+MCP サーバーにツールフィルターを設定することで、エージェントが利用できるツールを制限できます。SDK は静的および動的フィルタリングの両方をサポートします。
 
 ### 静的ツールフィルタリング
 
-単純な許可 / ブロック リストの場合は静的フィルタリングを使用します。
+単純な許可 / ブロックリストには静的フィルタリングを使用します。
 
 ```python
 from agents.mcp import create_static_tool_filter
@@ -88,14 +88,14 @@ server = MCPServerStdio(
 ```
 
 **`allowed_tool_names` と `blocked_tool_names` の両方を設定した場合の処理順序は次のとおりです。**  
-1. まず `allowed_tool_names`（許可リスト）を適用し、指定したツールのみを残します。  
-2. 次に `blocked_tool_names`（ブロックリスト）を適用し、残ったツールから指定したツールを除外します。  
+1. まず `allowed_tool_names` (許可リスト) を適用し、指定されたツールのみを残します。  
+2. 次に `blocked_tool_names` (ブロックリスト) を適用し、残ったツールから指定されたツールを除外します。  
 
-例として `allowed_tool_names=["read_file", "write_file", "delete_file"]` と `blocked_tool_names=["delete_file"]` を設定すると、利用可能なのは `read_file` と `write_file` のみになります。
+たとえば、`allowed_tool_names=["read_file", "write_file", "delete_file"]` と `blocked_tool_names=["delete_file"]` を設定すると、`read_file` と `write_file` のみが利用可能になります。
 
 ### 動的ツールフィルタリング
 
-より複雑なフィルタリングが必要な場合は、関数を使った動的フィルタリングを利用できます。
+より複雑なフィルタリングロジックには、関数を使った動的フィルターを使用できます。
 
 ```python
 from agents.mcp import ToolFilterContext
@@ -147,8 +147,8 @@ MCP サーバーは、エージェントの instructions を動的に生成す
 
 プロンプトをサポートする MCP サーバーは、次の 2 つの主要メソッドを提供します。
 
-- `list_prompts()`: サーバー上で利用可能なすべてのプロンプトを列挙します  
-- `get_prompt(name, arguments)`: パラメーターを指定して特定のプロンプトを取得します  
+- `list_prompts()`: サーバー上の利用可能なプロンプトを一覧表示します  
+- `get_prompt(name, arguments)`: オプションのパラメーター付きで特定のプロンプトを取得します  
 
 ```python
 # List available prompts
@@ -173,19 +173,19 @@ agent = Agent(
 
 ## キャッシュ
 
-エージェントが実行されるたびに、MCP サーバーへ `list_tools()` が呼び出されます。特にリモートサーバーの場合、これはレイテンシの原因になります。ツール一覧を自動的にキャッシュするには、[`MCPServerStdio`][agents.mcp.server.MCPServerStdio]、[`MCPServerSse`][agents.mcp.server.MCPServerSse]、[`MCPServerStreamableHttp`][agents.mcp.server.MCPServerStreamableHttp] に `cache_tools_list=True` を渡します。ツールリストが変わらないと確信できる場合のみ行ってください。
+エージェントが実行されるたびに、MCP サーバーの `list_tools()` が呼ばれます。サーバーがリモートの場合、これはレイテンシの原因となることがあります。ツール一覧を自動的にキャッシュするには、[`MCPServerStdio`][agents.mcp.server.MCPServerStdio]、[`MCPServerSse`][agents.mcp.server.MCPServerSse]、[`MCPServerStreamableHttp`][agents.mcp.server.MCPServerStreamableHttp] に `cache_tools_list=True` を渡します。ツール一覧が変更されないことが確実な場合のみ使用してください。
 
 キャッシュを無効化したい場合は、サーバーの `invalidate_tools_cache()` を呼び出します。
 
-## エンドツーエンド code examples
+## エンドツーエンドのコード例
 
-完全な動作例は [examples/mcp](https://github.com/openai/openai-agents-python/tree/main/examples/mcp) をご覧ください。
+[examples/mcp](https://github.com/openai/openai-agents-python/tree/main/examples/mcp) に完全な動作例があります。
 
 ## トレーシング
 
-[トレーシング](./tracing.md) は MCP 操作を自動的に記録します。内容は次のとおりです。
+[トレーシング](./tracing.md) では MCP 操作を自動的に取得します。対象は次のとおりです。
 
-1. ツール一覧取得のための MCP サーバー呼び出し  
-2. 関数呼び出しに関する MCP 関連情報  
+1. ツール一覧取得のための MCP サーバーへの呼び出し  
+2. 関数呼び出しにおける MCP 関連情報  
 
 ![MCP Tracing Screenshot](../assets/images/mcp-tracing.jpg)
\ No newline at end of file
diff --git a/docs/ja/models/index.md b/docs/ja/models/index.md
index a32e93d05..814d767ce 100644
--- a/docs/ja/models/index.md
+++ b/docs/ja/models/index.md
@@ -4,54 +4,51 @@ search:
 ---
 # モデル
 
-Agents SDK には OpenAI モデルの 2 種類が標準でサポートされています:
+ Agents SDK は、 OpenAI モデルに対してすぐに使える 2 つのオプションを提供しています:
 
-- **推奨**: [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel] は、新しい Responses API を用いて OpenAI API を呼び出します。  
-- [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] は、Chat Completions API を用いて OpenAI API を呼び出します。
+- **推奨**: [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel]。これは新しい [Responses API](https://platform.openai.com/docs/api-reference/responses) を使用して OpenAI API を呼び出します。  
+- [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel]。これは [Chat Completions API](https://platform.openai.com/docs/api-reference/chat) を使用して OpenAI API を呼び出します。
 
-## Non-OpenAI モデル
+## OpenAI 以外のモデル
 
-ほとんどの Non-OpenAI モデルは [LiteLLM インテグレーション](./litellm.md) 経由で利用できます。まず、litellm の依存グループをインストールします:
+ ほとんどの他社 LLM を [LiteLLM integration](./litellm.md) 経由で利用できます。まず、 litellm 依存関係グループをインストールしてください:
 
 ```bash
 pip install "openai-agents[litellm]"
 ```
 
-次に、`litellm/` プレフィックスを付けて [サポートされているモデル](https://docs.litellm.ai/docs/providers) を使用します:
+ その後、 `litellm/` プレフィックスを付けて [supported models](https://docs.litellm.ai/docs/providers) を指定します:
 
 ```python
 claude_agent = Agent(model="litellm/anthropic/claude-3-5-sonnet-20240620", ...)
 gemini_agent = Agent(model="litellm/gemini/gemini-2.5-flash-preview-04-17", ...)
 ```
 
-### Non-OpenAI モデルを利用するその他の方法
+### OpenAI 以外のモデルを使用する他の方法
 
-他の LLM プロバイダーは、次の 3 つの方法でも統合できます (コード例は [こちら](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/)):
+ 他社 LLM プロバイダーを統合する方法はさらに 3 つあります（コード例は [here](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/) を参照）:
 
-1. [`set_default_openai_client`][agents.set_default_openai_client]  
-   `AsyncOpenAI` のインスタンスを LLM クライアントとしてグローバルに利用したい場合に便利です。LLM プロバイダーが OpenAI 互換エンドポイントを持つ場合、`base_url` と `api_key` を設定できます。設定例は [examples/model_providers/custom_example_global.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_global.py) をご覧ください。
-2. [`ModelProvider`][agents.models.interface.ModelProvider]  
-   これは `Runner.run` レベルで、「この実行ではすべてのエージェントにカスタムモデルプロバイダーを使う」と指定できます。設定例は [examples/model_providers/custom_example_provider.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_provider.py) をご覧ください。
-3. [`Agent.model`][agents.agent.Agent.model]  
-   特定の Agent インスタンスにモデルを指定できます。これにより、エージェントごとに異なるプロバイダーを組み合わせられます。設定例は [examples/model_providers/custom_example_agent.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_agent.py) をご覧ください。多くのモデルを簡単に使う方法として [LiteLLM インテグレーション](./litellm.md) があります。
+1. [`set_default_openai_client`][agents.set_default_openai_client] は、 `AsyncOpenAI` インスタンスを LLM クライアントとしてグローバルに使用したい場合に便利です。 LLM プロバイダーが OpenAI 互換 API エンドポイントを持ち、 `base_url` と `api_key` を設定できるケース向けです。設定例は [examples/model_providers/custom_example_global.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_global.py) を参照してください。  
+2. [`ModelProvider`][agents.models.interface.ModelProvider] は `Runner.run` レベルで利用できます。これにより、「この実行内のすべてのエージェントでカスタムモデルプロバイダーを使用する」と指定できます。設定例は [examples/model_providers/custom_example_provider.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_provider.py) を参照してください。  
+3. [`Agent.model`][agents.agent.Agent.model] により特定の エージェント インスタンスに対してモデルを指定できます。これにより、エージェントごとに異なるプロバイダーを組み合わせられます。設定例は [examples/model_providers/custom_example_agent.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_agent.py) を参照してください。ほとんどの利用可能なモデルを簡単に使う方法として、 [LiteLLM integration](./litellm.md) が便利です。
 
-`platform.openai.com` の API キーをお持ちでない場合は、`set_tracing_disabled()` でトレーシングを無効化するか、[別のトレーシングプロセッサー](../tracing.md) を設定することをおすすめします。
+ `platform.openai.com` からの API キーをお持ちでない場合は、 `set_tracing_disabled()` でトレーシングを無効化するか、 [different tracing processor](../tracing.md) を設定することを推奨します。
 
 !!! note
 
-    これらの例では、ほとんどの LLM プロバイダーがまだ Responses API をサポートしていないため、Chat Completions API/モデルを使用しています。もしご利用の LLM プロバイダーが Responses API をサポートしている場合は、Responses を使用することを推奨します。
+    これらの例では Chat Completions API/モデルを使用しています。これは、多くの LLM プロバイダーがまだ Responses API をサポートしていないためです。もしご利用の LLM プロバイダーが Responses API をサポートしている場合は、 Responses の使用を推奨します。
 
 ## モデルの組み合わせ
 
-1 つのワークフロー内でエージェントごとに異なるモデルを使いたい場合があります。たとえば、簡単な振り分けには小さく高速なモデルを、複雑なタスクには大きく高性能なモデルを使うといったパターンです。[`Agent`][agents.Agent] を設定する際には、次のいずれかでモデルを指定できます:
+ 1 つのワークフロー内でエージェントごとに異なるモデルを使用したい場合があります。たとえば、トリアージには小型で高速なモデルを使用し、複雑なタスクには大型で高性能なモデルを使うといった形です。 [`Agent`][agents.Agent] を設定するとき、次のいずれかの方法で特定のモデルを指定できます:
 
-1. モデル名を直接渡す  
-2. 任意のモデル名 + その名前を Model インスタンスにマップできる [`ModelProvider`][agents.models.interface.ModelProvider] を渡す  
-3. [`Model`][agents.models.interface.Model] 実装を直接渡す
+1. モデル名を直接渡す。  
+2. 任意のモデル名 + その名前を Model インスタンスへマッピングできる [`ModelProvider`][agents.models.interface.ModelProvider] を渡す。  
+3. [`Model`][agents.models.interface.Model] 実装を直接渡す。  
 
 !!!note
 
-    SDK は [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel] と [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] の両方をサポートしていますが、ワークフローごとに 1 種類のモデル形状を使うことを推奨します。両者は対応する機能や tools が異なるためです。もし混在が必要な場合は、利用する全機能が両方でサポートされているか確認してください。
+    SDK では [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel] と [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] の両方をサポートしていますが、各ワークフローで 1 つのモデル形状を使用することを推奨します。両モデル形状はサポートする機能やツールが異なるためです。ワークフローで両形状を混在させる場合は、使用するすべての機能が両方で利用可能か確認してください。
 
 ```python
 from agents import Agent, Runner, AsyncOpenAI, OpenAIChatCompletionsModel
@@ -84,10 +81,10 @@ async def main():
     print(result.final_output)
 ```
 
-1. OpenAI モデル名を直接設定します。  
-2. [`Model`][agents.models.interface.Model] 実装を提供します。
+1. OpenAI モデル名を直接設定しています。  
+2. [`Model`][agents.models.interface.Model] 実装を提供しています。  
 
-エージェントで使用するモデルをさらに設定したい場合は、`temperature` などのオプションを指定できる [`ModelSettings`][agents.models.interface.ModelSettings] を渡します。
+ エージェントで使用するモデルをさらに設定したい場合は、温度などのオプション設定パラメーターを含む [`ModelSettings`][agents.models.interface.ModelSettings] を渡せます。
 
 ```python
 from agents import Agent, ModelSettings
@@ -100,7 +97,7 @@ english_agent = Agent(
 )
 ```
 
-また、OpenAI の Responses API を使う場合は [追加のオプションパラメーター](https://platform.openai.com/docs/api-reference/responses/create) (例: `user`, `service_tier` など) も利用できます。トップレベルにない場合は `extra_args` から渡してください。
+ また、 OpenAI の Responses API を使用する場合、 `user`、 `service_tier` など [その他のオプションパラメーター](https://platform.openai.com/docs/api-reference/responses/create) があります。トップレベルで指定できない場合は、 `extra_args` に渡すこともできます。
 
 ```python
 from agents import Agent, ModelSettings
@@ -116,29 +113,27 @@ english_agent = Agent(
 )
 ```
 
-## 他の LLM プロバイダー利用時によくある問題
+## 他社 LLM 利用時によくある問題
 
-### トレーシング クライアントのエラー 401
+### Tracing client error 401
 
-トレースは OpenAI サーバーへアップロードされるため、OpenAI API キーがない場合にエラーが発生します。以下のいずれかで解決できます:
+ トレーシングに関連するエラーが発生する場合、これはトレースが OpenAI サーバーへアップロードされる際に OpenAI API キーがないためです。次のいずれかで解決できます:
 
-1. トレーシングを完全に無効化: [`set_tracing_disabled(True)`][agents.set_tracing_disabled]  
-2. トレーシング用の OpenAI キーを設定: [`set_tracing_export_api_key(...)`][agents.set_tracing_export_api_key]  
-   このキーはトレースのアップロードのみに使用され、[platform.openai.com](https://platform.openai.com/) のものが必要です。  
-3. OpenAI 以外のトレースプロセッサーを使用: [tracing ドキュメント](../tracing.md#custom-tracing-processors) を参照
+1. トレーシングを完全に無効化する: [`set_tracing_disabled(True)`][agents.set_tracing_disabled]  
+2. トレーシング用に OpenAI キーを設定する: [`set_tracing_export_api_key(...)`][agents.set_tracing_export_api_key]  
+   この API キーはトレースのアップロードのみに使用され、 [platform.openai.com](https://platform.openai.com/) のものが必要です。  
+3. OpenAI 以外のトレースプロセッサーを使用する。詳細は [tracing docs](../tracing.md#custom-tracing-processors) を参照してください。
 
 ### Responses API のサポート
 
-SDK はデフォルトで Responses API を使用しますが、ほとんどの LLM プロバイダーはまだ対応していません。そのため 404 などのエラーが発生する場合があります。以下のいずれかで解決してください:
+ SDK はデフォルトで Responses API を使用しますが、多くの他社 LLM プロバイダーはまだサポートしていません。その結果、 404 エラーなどが発生することがあります。解決策は次の 2 つです:
 
-1. [`set_default_openai_api("chat_completions")`][agents.set_default_openai_api] を呼び出す  
-   これは環境変数 `OPENAI_API_KEY` と `OPENAI_BASE_URL` を設定している場合に有効です。  
-2. [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] を使用する  
-   コード例は [こちら](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/) にあります。
+1. [`set_default_openai_api("chat_completions")`][agents.set_default_openai_api] を呼び出す。環境変数で `OPENAI_API_KEY` と `OPENAI_BASE_URL` を設定している場合に機能します。  
+2. [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] を使用する。コード例は [here](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/) にあります。
 
 ### structured outputs のサポート
 
-一部のモデルプロバイダーは [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) をサポートしていません。その場合、次のようなエラーになることがあります:
+ 一部のモデルプロバイダーは [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) をサポートしていません。その場合、次のようなエラーが発生することがあります:
 
 ```
 
@@ -146,12 +141,12 @@ BadRequestError: Error code: 400 - {'error': {'message': "'response_format.type'
 
 ```
 
-これは、JSON 出力には対応しているものの、出力に使用する `json_schema` を指定できないプロバイダーの制限です。修正に取り組んでいますが、JSON スキーマ出力に対応しているプロバイダーを利用することを推奨します。そうでない場合、生成される JSON が不正でアプリが頻繁に壊れる可能性があります。
+ これは一部プロバイダーの制限で、 JSON 出力はサポートしていても、出力に使用する `json_schema` を指定できないというものです。現在修正に取り組んでいますが、 JSON schema 出力をサポートするプロバイダーを利用することを推奨します。そうでない場合、不正な JSON によりアプリが頻繁に壊れる可能性があります。
 
-## プロバイダーをまたいだモデルの組み合わせ
+## プロバイダー間でのモデル混在
 
-モデルプロバイダー間の機能差に注意しないとエラーが発生することがあります。たとえば、OpenAI は structured outputs、マルチモーダル入力、ホストされたファイル検索と Web 検索をサポートしますが、多くの他プロバイダーは対応していません。以下の制限に注意してください:
+ モデルプロバイダー間の機能差異を理解しておかないと、エラーが発生する場合があります。たとえば、 OpenAI は structured outputs、マルチモーダル入力、ホストされた file search や web search をサポートしていますが、多くの他社プロバイダーはこれらをサポートしていません。以下の制限に注意してください:
 
-- 対応していないプロバイダーにはサポート外の `tools` を送らない  
-- テキストのみのモデルを呼び出す前にマルチモーダル入力を除外する  
-- structured JSON 出力をサポートしないプロバイダーは無効な JSON を返す場合がある点を認識する
\ No newline at end of file
+- サポートされていない `tools` を理解しないプロバイダーに送らない  
+- テキストのみのモデルを呼び出す前にマルチモーダル入力をフィルタリングする  
+- structured JSON outputs をサポートしないプロバイダーでは、無効な JSON が返される可能性があることを理解する
\ No newline at end of file
diff --git a/docs/ja/models/litellm.md b/docs/ja/models/litellm.md
index dd3a53d58..fa3e10726 100644
--- a/docs/ja/models/litellm.md
+++ b/docs/ja/models/litellm.md
@@ -2,33 +2,33 @@
 search:
   exclude: true
 ---
-# LiteLLM 経由で任意モデルの利用
+# LiteLLM 経由でのモデル利用
 
 !!! note
 
-    LiteLLM 統合は現在ベータ版です。特に小規模なモデルプロバイダーでは問題が発生する可能性があります。問題を見つけた場合は [Github issues](https://github.com/openai/openai-agents-python/issues) からご報告ください。迅速に対応します。
+    LiteLLM インテグレーションはベータ版です。特に規模の小さいモデルプロバイダーで問題が発生する場合があります。問題が発生した場合は [Github issues](https://github.com/openai/openai-agents-python/issues) からご報告ください。迅速に対応します。
 
-[LiteLLM](https://docs.litellm.ai/docs/) は、単一のインターフェースで 100 以上のモデルを利用できるライブラリです。Agents SDK に LiteLLM 統合を追加したことで、任意の AI モデルを使用できるようになりました。
+LiteLLM は、単一のインターフェースで 100 以上のモデルを利用できるライブラリです。Agents SDK に LiteLLM インテグレーションを追加したことで、任意の AI モデルをエージェントで利用できます。
 
 ## セットアップ
 
-`litellm` が利用可能であることを確認する必要があります。オプションの `litellm` 依存グループをインストールすることで準備できます。
+`litellm` が利用可能であることを確認してください。オプションの `litellm` 依存関係グループをインストールすることで対応できます:
 
 ```bash
 pip install "openai-agents[litellm]"
 ```
 
-インストール後、任意のエージェントで [`LitellmModel`][agents.extensions.models.litellm_model.LitellmModel] を使用できます。
+インストール後は、どのエージェントでも [`LitellmModel`][agents.extensions.models.litellm_model.LitellmModel] を使用できます。
 
-## 例
+## 使用例
 
-以下は完全に動作する例です。実行すると、モデル名と API キーの入力を求められます。たとえば、次のように入力できます。
+以下は完全に動作する例です。実行すると、モデル名と API キーの入力を求められます。たとえば次のように入力できます。
 
--   モデルに `openai/gpt-4.1`、API キーに OpenAI API キー
--   モデルに `anthropic/claude-3-5-sonnet-20240620`、API キーに Anthropic API キー
+-   `openai/gpt-4.1` をモデル名として、OpenAI API キーを入力  
+-   `anthropic/claude-3-5-sonnet-20240620` をモデル名として、Anthropic API キーを入力  
 -   など
 
-LiteLLM がサポートしているモデルの一覧は、[litellm providers docs](https://docs.litellm.ai/docs/providers) をご覧ください。
+LiteLLM でサポートされているモデルの完全な一覧は、[litellm providers docs](https://docs.litellm.ai/docs/providers) をご覧ください。
 
 ```python
 from __future__ import annotations
diff --git a/docs/ja/multi_agent.md b/docs/ja/multi_agent.md
index 6b32b6d21..26aaabde8 100644
--- a/docs/ja/multi_agent.md
+++ b/docs/ja/multi_agent.md
@@ -2,40 +2,40 @@
 search:
   exclude: true
 ---
-# 複数のエージェントのオーケストレーション
+# 複数エージェントのオーケストレーション
 
-オーケストレーションとは、アプリ内でのエージェントのフローを指します。どのエージェントが実行されるのか、その順序はどうなるのか、次に何を行うかをどのように決定するのか。エージェントをオーケストレーションする方法は大きく 2 つあります。
+オーケストレーションとは、アプリ内でエージェントがどのように流れるかを指します。どのエージェントをどの順番で実行し、次に何をすべきかをどのように決定するかということです。エージェントをオーケストレーションする主な方法は 2 つあります。
 
-1.  LLM に意思決定を任せる方法: LLM の知性を活用して計画・推論し、その結果に基づき次のステップを決定します。  
-2.  コードでオーケストレーションする方法: コードによってエージェントのフローを決定します。
+1. LLM に意思決定させる: LLM の知能を利用して計画・推論を行い、その結果に基づいて次のステップを決定します。  
+2. コードでオーケストレーションする: コードによってエージェントの流れを決定します。
 
-これらのパターンは組み合わせて使用できます。それぞれにトレードオフがあるため、以下で説明します。
+これらのパターンは組み合わせて使うことも可能です。それぞれメリットとデメリットがあり、以下で説明します。
 
 ## LLM によるオーケストレーション
 
-エージェントとは、LLM に instructions、tools、handoffs を組み合わせたものです。オープンエンドなタスクが与えられた場合、LLM はタスクに取り組む方法を自律的に計画し、tools を使って行動やデータ取得を行い、handoffs を使ってサブエージェントにタスクを委任できます。たとえば、リサーチ用エージェントには次のようなツールを持たせることができます。
+エージェントとは、LLM に instructions、tools、handoffs を装備させたものです。これにより、オープンエンドなタスクが与えられた場合でも、LLM はタスクをどうこなすかを自律的に計画し、tools を使ってアクションやデータ取得を行い、handoffs でサブエージェントにタスクを委任できます。たとえば、リサーチエージェントには次のようなツールを持たせることができます:
 
--   Web 検索でオンライン情報を取得  
--   ファイル検索とリトリーバルで独自データや接続先を検索  
--   コンピュータ操作でコンピュータ上のアクションを実行  
--   コード実行でデータ解析を実施  
--   計画立案やレポート作成などに長けた専門エージェントへの handoffs  
+- Web 検索でオンライン情報を取得  
+- ファイル検索と取得で独自データや接続を検索  
+- コンピュータ操作で PC 上の操作を実行  
+- コード実行でデータ分析を実施  
+- 計画立案やレポート作成に特化したエージェントへのハンドオフ  
 
-このパターンは、タスクがオープンエンドであり LLM の知性に頼りたい場合に最適です。主なポイントは以下のとおりです。
+このパターンはタスクがオープンエンドで、LLM の知能に依存したい場合に有効です。ここで重要な戦術は次のとおりです。
 
-1.  質の高いプロンプトに投資する。利用可能なツール、その使い方、守るべきパラメーターを明確にします。  
-2.  アプリを監視し、改善を重ねる。問題が発生した箇所を確認し、プロンプトを改善します。  
-3.  エージェントに内省と改善を許可する。たとえばループで実行し、自己批評させる、またはエラーメッセージを提供して改善させるなどです。  
-4.  何でもこなす汎用エージェントではなく、 1 つのタスクに特化したエージェントを用意します。  
-5.  [evals](https://platform.openai.com/docs/guides/evals) に投資する。これによりエージェントを訓練し、タスク性能を向上できます。  
+1. 良いプロンプトに投資する。利用可能なツール、その使い方、守るべきパラメーターを明確にします。  
+2. アプリをモニタリングして反復する。問題が起きた箇所を確認し、プロンプトを改善します。  
+3. エージェントに内省と改善を許可する。たとえばループで実行して自己批評させたり、エラーメッセージを与えて改善させるなどです。  
+4. 1 つのタスクに特化したエージェントを用意し、何でもこなせる汎用エージェントに期待しすぎないようにします。  
+5. [evals](https://platform.openai.com/docs/guides/evals) に投資する。これによりエージェントを学習させ、タスク遂行能力を向上できます。  
 
 ## コードによるオーケストレーション
 
-LLM によるオーケストレーションは強力ですが、コードでオーケストレーションすると速度・コスト・性能面でより決定論的かつ予測可能になります。代表的なパターンは次のとおりです。
+LLM によるオーケストレーションは強力ですが、コードでオーケストレーションすることで、速度・コスト・パフォーマンスの面でより決定論的かつ予測可能になります。主なパターンは以下のとおりです。
 
--   [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を用いて、コードで検査できる適切な形式のデータを生成する。たとえば、エージェントにタスクをいくつかのカテゴリーへ分類させ、そのカテゴリーに応じて次のエージェントを選択できます。  
--   複数のエージェントをチェーンし、前の出力を次の入力に変換する。ブログ記事執筆を例にすると、リサーチ → アウトライン作成 → 記事執筆 → 批評 → 改善という一連のステップに分解できます。  
--   タスクを実行するエージェントと、評価してフィードバックを返すエージェントを `while` ループで回し、評価者が基準を満たしたと判断するまで繰り返します。  
--   Python の基本コンポーネントである `asyncio.gather` などを使って複数エージェントを並列実行する。互いに依存しない複数タスクを扱う際の速度向上に有用です。  
+- [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用して、コードで検査できる適切な形式のデータを生成します。たとえば、エージェントにタスクをいくつかのカテゴリーに分類させ、そのカテゴリーに基づいて次のエージェントを選択できます。  
+- あるエージェントの出力を変換して次のエージェントの入力とすることで、複数のエージェントをチェーンします。ブログ記事の作成であれば、リサーチ → アウトライン作成 → 本文作成 → 批評 → 改善という一連のステップに分解できます。  
+- タスクを実行するエージェントを `while` ループで回し、評価とフィードバックを行うエージェントを併走させ、評価者が基準を満たしたと判断するまで繰り返します。  
+- `asyncio.gather` などの Python の基本コンポーネントを使って複数エージェントを並列実行します。互いに依存しない複数タスクがある場合、速度向上に役立ちます。  
 
-詳細なコード例は [`examples/agent_patterns`](https://github.com/openai/openai-agents-python/tree/main/examples/agent_patterns) に用意しています。
\ No newline at end of file
+[`examples/agent_patterns`](https://github.com/openai/openai-agents-python/tree/main/examples/agent_patterns) には多数のコード例があります。
\ No newline at end of file
diff --git a/docs/ja/quickstart.md b/docs/ja/quickstart.md
index 8797a4ee7..1049e1d8c 100644
--- a/docs/ja/quickstart.md
+++ b/docs/ja/quickstart.md
@@ -6,7 +6,7 @@ search:
 
 ## プロジェクトと仮想環境の作成
 
-この手順は一度だけ実行すれば十分です。
+これは一度だけ実行すれば十分です。
 
 ```bash
 mkdir my_project
@@ -14,7 +14,7 @@ cd my_project
 python -m venv .venv
 ```
 
-### 仮想環境の有効化
+### 仮想環境のアクティブ化
 
 新しいターミナルセッションを開始するたびに実行してください。
 
@@ -30,13 +30,13 @@ pip install openai-agents # or `uv add openai-agents`, etc
 
 ### OpenAI API キーの設定
 
-API キーをお持ちでない場合は、[こちらの手順](https://platform.openai.com/docs/quickstart#create-and-export-an-api-key) に従って OpenAI API キーを作成してください。
+まだお持ちでない場合は、[こちらの手順](https://platform.openai.com/docs/quickstart#create-and-export-an-api-key)に従って OpenAI API キーを作成してください。
 
 ```bash
 export OPENAI_API_KEY=sk-...
 ```
 
-## 最初のエージェントを作成する
+## はじめてのエージェントの作成
 
 エージェントは instructions、名前、そして `model_config` などのオプション設定で定義します。
 
@@ -49,9 +49,9 @@ agent = Agent(
 )
 ```
 
-## さらにエージェントを追加する
+## 追加のエージェントの定義
 
-追加のエージェントも同じ方法で定義できます。`handoff_descriptions` はハンドオフ先を決定するための追加コンテキストを提供します。
+追加のエージェントも同じ方法で定義できます。`handoff_descriptions` はハンドオフのルーティングを決定する際の追加コンテキストを提供します。
 
 ```python
 from agents import Agent
@@ -69,9 +69,9 @@ math_tutor_agent = Agent(
 )
 ```
 
-## ハンドオフを定義する
+## ハンドオフの定義
 
-各エージェントでは、タスクを進めるために選択できる送信側ハンドオフオプションの一覧を定義できます。
+各エージェントには、タスクを進めるために選択できる外向きハンドオフオプションの一覧を定義できます。
 
 ```python
 triage_agent = Agent(
@@ -81,9 +81,9 @@ triage_agent = Agent(
 )
 ```
 
-## エージェントオーケストレーションを実行する
+## エージェント オーケストレーションの実行
 
-ワークフローが実行され、トリアージエージェントが 2 つの専門エージェント間で正しくルーティングすることを確認してみましょう。
+ワークフローが正しく実行され、トリアージ エージェントが 2 つのスペシャリスト エージェント間で正しくルーティングすることを確認しましょう。
 
 ```python
 from agents import Runner
@@ -93,9 +93,9 @@ async def main():
     print(result.final_output)
 ```
 
-## ガードレールを追加する
+## ガードレールの追加
 
-入力または出力に対して実行されるカスタムガードレールを定義できます。
+入力または出力に対して実行するカスタム ガードレールを定義できます。
 
 ```python
 from agents import GuardrailFunctionOutput, Agent, Runner
@@ -121,9 +121,9 @@ async def homework_guardrail(ctx, agent, input_data):
     )
 ```
 
-## すべてをまとめて実行する
+## すべてを組み合わせる
 
-これまでの内容を組み合わせて、ハンドオフと入力ガードレールを使用したワークフロー全体を実行してみましょう。
+ハンドオフと入力ガードレールを使用して、すべてを組み合わせた完全なワークフローを実行してみましょう。
 
 ```python
 from agents import Agent, InputGuardrail, GuardrailFunctionOutput, Runner
@@ -190,14 +190,14 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-## トレースを表示する
+## トレースの閲覧
 
-エージェント実行中に何が起こったかを確認するには、[OpenAI Dashboard の Trace viewer](https://platform.openai.com/traces) に移動してトレースを表示してください。
+エージェント実行中に何が起こったか確認するには、[OpenAI Dashboard の Trace viewer](https://platform.openai.com/traces) に移動してエージェントのトレースを表示してください。
 
 ## 次のステップ
 
-より複雑なエージェントフローの構築方法を学びましょう。
+より複雑なエージェント フローの構築方法を学びましょう:
 
-- [Agents](agents.md) の設定方法を学ぶ。
-- [エージェントの実行](running_agents.md) について学ぶ。
-- [tools](tools.md)、[guardrails](guardrails.md)、[models](models/index.md) について学ぶ。
\ No newline at end of file
+-   [エージェント](agents.md) の設定方法を学ぶ  
+-   [エージェントの実行](running_agents.md) について学ぶ  
+-   [ツール](tools.md)、[ガードレール](guardrails.md)、および [モデル](models/index.md) について学ぶ
\ No newline at end of file
diff --git a/docs/ja/realtime/guide.md b/docs/ja/realtime/guide.md
index d48e5c391..dc70c5635 100644
--- a/docs/ja/realtime/guide.md
+++ b/docs/ja/realtime/guide.md
@@ -4,14 +4,14 @@ search:
 ---
 # ガイド
 
-このガイドでは、OpenAI Agents SDK のリアルタイム機能を使って音声対応 AI エージェントを構築する方法を詳しく説明します。
+このガイドでは、 OpenAI Agents SDK のリアルタイム機能を用いて音声対応の AI エージェントを構築する方法を詳しく解説します。
 
-!!! warning "ベータ機能"
-リアルタイムエージェントはベータ版です。実装の改善に伴い、互換性が壊れる変更が発生する可能性があります。
+!!! warning "Beta feature"
+リアルタイムエージェントはベータ版です。今後の改善に伴い非互換の変更が入る可能性があります。
 
 ## 概要
 
-リアルタイムエージェントは、音声とテキスト入力をリアルタイムで処理し、音声で応答する対話フローを実現します。OpenAI の Realtime API との永続的な接続を維持し、低レイテンシで自然な音声会話を行いながら、割り込みにもスムーズに対応できます。
+リアルタイムエージェントは、音声とテキスト入力をリアルタイムに処理し、音声で応答する会話フローを実現します。 OpenAI の Realtime API との永続接続を維持することで、低レイテンシかつ自然な音声会話を可能にし、ユーザーの割り込みにもスムーズに対応します。
 
 ## アーキテクチャ
 
@@ -19,45 +19,44 @@ search:
 
 リアルタイムシステムは、以下の主要コンポーネントで構成されます。
 
-- **RealtimeAgent**: instructions、tools、handoffs を設定したエージェント  
-- **RealtimeRunner**: 設定を管理します。`runner.run()` を呼び出してセッションを取得できます。  
-- **RealtimeSession**: 1 回の対話セッション。ユーザーが会話を開始するたびに作成し、会話が終了するまで保持します。  
-- **RealtimeModel**: 基盤となるモデルインターフェース（通常は OpenAI の WebSocket 実装）
+- ** RealtimeAgent **: instructions、tools、handoffs を設定したエージェント  
+- ** RealtimeRunner **: 設定を管理します。 `runner.run()` を呼び出してセッションを取得します  
+- ** RealtimeSession **: 1 回の対話セッション。ユーザーが会話を開始するたびに作成し、会話終了まで維持します  
+- ** RealtimeModel **: 基盤となるモデルインターフェース (通常は OpenAI の WebSocket 実装)
 
 ### セッションフロー
 
-典型的なリアルタイムセッションは次の流れで進みます。
+一般的なリアルタイムセッションは次の流れで進みます。
 
-1. instructions、tools、handoffs を使用して **RealtimeAgent** を作成する  
-2. エージェントと設定オプションを指定して **RealtimeRunner** をセットアップする  
-3. `await runner.run()` で **セッションを開始** し、RealtimeSession を受け取る  
-4. `send_audio()` または `send_message()` で **音声またはテキストメッセージを送信** する  
-5. セッションをイテレートして **イベントを監視** する  
-   - イベントには音声出力、文字起こし、ツール呼び出し、ハンドオフ、エラーなどが含まれます  
-6. ユーザーがエージェントの発話を遮った場合に **割り込みを処理** する（現在の音声生成が自動で停止）
+1. instructions、tools、handoffs を指定して ** RealtimeAgent ** を作成  
+2. エージェントと設定オプションを渡して ** RealtimeRunner ** をセットアップ  
+3. `await runner.run()` で **セッション開始**。 RealtimeSession が返されます  
+4. `send_audio()` または `send_message()` を使用して **音声またはテキスト** を送信  
+5. セッションをイテレートしながら **イベントを受信**。音声出力、転写、ツール呼び出し、ハンドオフ、エラーなどのイベントが含まれます  
+6. ユーザーがエージェントの発話に被せて話した場合、 **割り込み** を処理。現在の音声生成を自動停止します  
 
 セッションは会話履歴を保持し、リアルタイムモデルとの永続接続を管理します。
 
 ## エージェント設定
 
-RealtimeAgent は通常の Agent クラスとほぼ同じですが、いくつか重要な違いがあります。完全な API 仕様は [`RealtimeAgent`][agents.realtime.agent.RealtimeAgent] リファレンスをご覧ください。
+RealtimeAgent は通常の Agent クラスと似ていますが、いくつか重要な違いがあります。詳細な API 仕様は [`RealtimeAgent`][agents.realtime.agent.RealtimeAgent] を参照してください。
 
 主な違い:
 
-- モデルの選択はエージェントレベルではなくセッションレベルで設定します。  
-- structured outputs（`outputType`）には対応していません。  
-- 音声はエージェントごとに設定できますが、最初のエージェントが話し始めた後は変更できません。  
-- tools、handoffs、instructions などその他の機能は同じように動作します。  
+- モデルの選択はエージェントではなくセッションレベルで設定します  
+- structured outputs (`outputType`) はサポートされていません  
+- 音声はエージェントごとに設定できますが、最初のエージェントが発話した後は変更できません  
+- tools、handoffs、instructions などその他の機能は同じ方法で利用できます  
 
 ## セッション設定
 
 ### モデル設定
 
-セッション設定では基盤となるリアルタイムモデルの動作を制御できます。モデル名（例: `gpt-4o-realtime-preview`）、音声（alloy、echo、fable、onyx、nova、shimmer）や対応モダリティ（テキスト／音声）を指定できます。音声の入出力フォーマットは PCM16 がデフォルトですが、変更可能です。
+セッション設定では、基盤となるリアルタイムモデルの挙動を制御できます。モデル名 (例: `gpt-4o-realtime-preview`)、ボイス (alloy、echo、fable、onyx、nova、shimmer)、対応モダリティ (text / audio) を指定できます。音声の入出力フォーマットは両方とも設定可能で、デフォルトは PCM16 です。
 
-### オーディオ設定
+### 音声設定
 
-オーディオ設定では、音声入力と出力の扱いを制御します。Whisper などのモデルを使った音声入力の文字起こし、言語の指定、ドメイン固有語句の精度を高めるための transcription prompts を設定できます。ターン検出では、音声活動検出の閾値、無音時間、検出前後のパディングなどにより、エージェントが応答を開始・停止するタイミングを調整します。
+音声設定では、音声入力と出力の扱いを制御します。 Whisper などのモデルを使った入力音声の転写、言語の指定、ドメイン固有語の認識精度を高める転写プロンプトの指定が可能です。ターン検出設定では、音声活動検出のしきい値、無音時間、検出音声の前後余白などを設定し、エージェントが応答を開始・終了するタイミングを調整します。
 
 ## ツールと関数
 
@@ -91,7 +90,7 @@ agent = RealtimeAgent(
 
 ### ハンドオフの作成
 
-ハンドオフを使うと、会話を専門化されたエージェント間で引き継げます。
+ハンドオフにより、会話を特化した別のエージェントへ引き継ぐことができます。
 
 ```python
 from agents.realtime import realtime_handoff
@@ -120,40 +119,40 @@ main_agent = RealtimeAgent(
 
 ## イベント処理
 
-セッションはストリーミングでイベントを送信するため、セッションオブジェクトをイテレートして受け取ります。主なイベント:
+セッションはイベントをストリーミングします。セッションオブジェクトをイテレートしてイベントを受信してください。イベントには、音声出力チャンク、転写結果、ツール実行開始・終了、エージェントハンドオフ、エラーなどがあります。主なイベントは以下のとおりです。
 
 - **audio**: エージェントの応答からの raw 音声データ  
 - **audio_end**: エージェントの発話が終了  
-- **audio_interrupted**: ユーザーがエージェントの発話を遮った  
-- **tool_start/tool_end**: ツール実行の開始／終了  
-- **handoff**: エージェントのハンドオフが発生  
+- **audio_interrupted**: ユーザーがエージェントを割り込み  
+- **tool_start / tool_end**: ツール実行のライフサイクル  
+- **handoff**: エージェント間のハンドオフが発生  
 - **error**: 処理中にエラーが発生  
 
 詳細は [`RealtimeSessionEvent`][agents.realtime.events.RealtimeSessionEvent] を参照してください。
 
 ## ガードレール
 
-リアルタイムエージェントでは出力ガードレールのみサポートされます。リアルタイム生成中のパフォーマンスを保つためにデバウンスされ、毎回の単語ではなく一定間隔で実行されます。デフォルトのデバウンス長は 100 文字ですが、設定で変更できます。
+リアルタイムエージェントでは出力ガードレールのみサポートされています。パフォーマンス低下を防ぐため、ガードレールはデバウンスされ、リアルタイム生成のたびにではなく周期的に実行されます。デフォルトのデバウンス長は 100 文字ですが、変更可能です。
 
-ガードレールが発動すると `guardrail_tripped` イベントが生成され、エージェントの現在の応答を割り込むことがあります。デバウンスにより、安全性とリアルタイム性能のバランスを取ります。テキストエージェントと異なり、リアルタイムエージェントではガードレール発動時に Exception は発生しません。
+ガードレールが発火すると `guardrail_tripped` イベントが生成され、エージェントの現在の応答を中断できます。デバウンスにより、安全性とリアルタイム性能のバランスを取っています。テキストエージェントと異なり、リアルタイムエージェントはガードレール発火時に Exception を送出しません。
 
-## オーディオ処理
+## 音声処理
 
-音声を送信するには [`session.send_audio(audio_bytes)`][agents.realtime.session.RealtimeSession.send_audio]、テキストを送るには [`session.send_message()`][agents.realtime.session.RealtimeSession.send_message] を使用します。
+[`session.send_audio(audio_bytes)`][agents.realtime.session.RealtimeSession.send_audio] を使って音声を、 [`session.send_message()`][agents.realtime.session.RealtimeSession.send_message] でテキストをセッションへ送信できます。
 
-音声出力を取得するには `audio` イベントを受け取り、任意のオーディオライブラリで再生してください。`audio_interrupted` イベントを監視し、ユーザーが割り込んだ際は直ちに再生を停止し、キューにある音声をクリアします。
+音声出力を受け取るには `audio` イベントを監視し、任意の音声ライブラリで再生してください。ユーザーが割り込んだ場合に即座に再生を停止し、キューにある音声をクリアするため、 `audio_interrupted` イベントも必ず監視してください。
 
-## モデルへの直接アクセス
+## 直接モデルアクセス
 
-低レベルの制御が必要な高度なユースケースでは、基盤モデルに直接アクセスし、カスタムリスナーを追加できます。
+基盤となるモデルにアクセスし、独自リスナーを追加したり高度な操作を行うことができます。
 
 ```python
 # Add a custom listener to the model
 session.model.add_listener(my_custom_listener)
 ```
 
-これにより、[`RealtimeModel`][agents.realtime.model.RealtimeModel] インターフェースを直接操作できます。
+これにより、低レベルで接続を制御したい高度なユースケース向けに [`RealtimeModel`][agents.realtime.model.RealtimeModel] インターフェースへ直接アクセスできます。
 
-## コード例
+## 例
 
-動作する完全なサンプルは、[examples/realtime ディレクトリ](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) をご覧ください。UI 付き・なしのデモが含まれています。
\ No newline at end of file
+動作する完全なサンプルは、 [examples/realtime ディレクトリ](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) を参照してください。 UI コンポーネントあり / なし両方のデモが含まれています。
\ No newline at end of file
diff --git a/docs/ja/realtime/quickstart.md b/docs/ja/realtime/quickstart.md
index 57e6a0c16..071e58fd2 100644
--- a/docs/ja/realtime/quickstart.md
+++ b/docs/ja/realtime/quickstart.md
@@ -4,16 +4,16 @@ search:
 ---
 # クイックスタート
 
-リアルタイム エージェントを使用すると、OpenAI の Realtime API を利用して AI エージェントとの音声会話が可能になります。このガイドでは、初めてのリアルタイム音声エージェントの作成方法を説明します。
+Realtime エージェントを使用すると、OpenAI の Realtime API を介して AI エージェントとの音声会話が可能になります。このガイドでは、最初の Realtime 音声エージェントを作成する手順を説明します。
 
-!!! warning "Beta feature"
-リアルタイム エージェントはベータ版です。実装を改善する過程で破壊的変更が入る可能性があります。
+!!! warning "ベータ機能"
+Realtime エージェントはベータ版です。実装の改善に伴い、互換性が損なわれる変更が発生する可能性があります。
 
 ## 前提条件
 
 -   Python 3.9 以上
 -   OpenAI API キー
--   OpenAI Agents SDK への基本的な習熟
+-   OpenAI Agents SDK の基本的な知識
 
 ## インストール
 
@@ -23,7 +23,7 @@ search:
 pip install openai-agents
 ```
 
-## 初めてのリアルタイム エージェントの作成
+## 初めての Realtime エージェントの作成
 
 ### 1. 必要なコンポーネントのインポート
 
@@ -32,7 +32,7 @@ import asyncio
 from agents.realtime import RealtimeAgent, RealtimeRunner
 ```
 
-### 2. リアルタイム エージェントを作成
+### 2. Realtime エージェントの作成
 
 ```python
 agent = RealtimeAgent(
@@ -41,7 +41,7 @@ agent = RealtimeAgent(
 )
 ```
 
-### 3. ランナーを設定
+### 3. Runner のセットアップ
 
 ```python
 runner = RealtimeRunner(
@@ -56,7 +56,7 @@ runner = RealtimeRunner(
 )
 ```
 
-### 4. セッションを開始
+### 4. セッションの開始
 
 ```python
 async def main():
@@ -79,9 +79,9 @@ async def main():
 asyncio.run(main())
 ```
 
-## 完全なコード例
+## 完全なサンプル
 
-以下は動作する完全なコード例です:
+以下は動作する完全な例です:
 
 ```python
 import asyncio
@@ -139,40 +139,40 @@ if __name__ == "__main__":
 
 ### モデル設定
 
--   `model_name`: 利用可能なリアルタイムモデルから選択します (例: `gpt-4o-realtime-preview`)
--   `voice`: 音声を選択します (`alloy`, `echo`, `fable`, `onyx`, `nova`, `shimmer`)
--   `modalities`: テキストおよび/またはオーディオを有効にします (`["text", "audio"]`)
+-   `model_name`: 利用可能な Realtime モデルから選択 (例: `gpt-4o-realtime-preview`)
+-   `voice`: 音声を選択 (`alloy`, `echo`, `fable`, `onyx`, `nova`, `shimmer`)
+-   `modalities`: テキストおよび／またはオーディオを有効化 (`["text", "audio"]`)
 
 ### オーディオ設定
 
--   `input_audio_format`: 入力オーディオのフォーマット (`pcm16`, `g711_ulaw`, `g711_alaw`)
--   `output_audio_format`: 出力オーディオのフォーマット
+-   `input_audio_format`: 入力オーディオの形式 (`pcm16`, `g711_ulaw`, `g711_alaw`)
+-   `output_audio_format`: 出力オーディオの形式
 -   `input_audio_transcription`: 文字起こしの設定
 
 ### ターン検出
 
 -   `type`: 検出方法 (`server_vad`, `semantic_vad`)
--   `threshold`: 音声アクティビティの閾値 (0.0–1.0)
+-   `threshold`: 音声アクティビティ閾値 (0.0-1.0)
 -   `silence_duration_ms`: ターン終了を検出する無音時間
 -   `prefix_padding_ms`: 発話前のオーディオパディング
 
 ## 次のステップ
 
--   [リアルタイム エージェントについてさらに学ぶ](guide.md)
--   [examples/realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) フォルダーにある動作するコード例を参照してください
--   エージェントに tools を追加する
--   エージェント間のハンドオフを実装する
--   安全のためにガードレールを設定する
+-   [Realtime エージェントの詳細](guide.md) を学ぶ
+-   [examples/realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) フォルダーの動作する code examples を確認
+-   エージェントに tools を追加
+-   エージェント間のハンドオフを実装
+-   安全のためのガードレールを設定
 
 ## 認証
 
-OpenAI API キーが環境変数に設定されていることを確認してください:
+環境変数に OpenAI API キーが設定されていることを確認してください:
 
 ```bash
 export OPENAI_API_KEY="your-api-key-here"
 ```
 
-あるいは、セッション作成時に直接渡します:
+または、セッション作成時に直接渡します:
 
 ```python
 session = await runner.run(model_config={"api_key": "your-api-key"})
diff --git a/docs/ja/release.md b/docs/ja/release.md
index 7a06e2505..741c5f952 100644
--- a/docs/ja/release.md
+++ b/docs/ja/release.md
@@ -2,31 +2,31 @@
 search:
   exclude: true
 ---
-# リリースプロセス／変更履歴
+# リリースプロセス / 変更履歴
 
-本プロジェクトでは、`0.Y.Z` 形式のわずかに変更した semantic versioning を採用しています。先頭の `0` は SDK が依然として急速に進化していることを示します。各コンポーネントは次のように増分します。
+このプロジェクトでは、`0.Y.Z` という形式を用いたセマンティックバージョニングのやや修正されたバージョンに従っています。先頭の `0` は SDK がまだ急速に進化していることを示します。各コンポーネントは以下のように増分します。
 
 ## マイナー ( `Y` ) バージョン
 
-beta でないパブリックインターフェースに対する breaking changes がある場合、マイナーバージョン `Y` を増やします。たとえば、`0.0.x` から `0.1.x` への更新では互換性のない変更が含まれる可能性があります。
+ベータでマークされていない公開インターフェースに **破壊的変更** がある場合、マイナーバージョン `Y` を増やします。たとえば、`0.0.x` から `0.1.x` への更新には破壊的変更が含まれる可能性があります。
 
-breaking changes を避けたい場合は、プロジェクトで `0.0.x` バージョンに固定することを推奨します。
+破壊的変更を避けたい場合は、プロジェクトで `0.0.x` バージョンにピン留めすることをお勧めします。
 
 ## パッチ ( `Z` ) バージョン
 
-非互換性のない変更の場合に `Z` を増やします。
+下記のような非破壊的変更では `Z` を増分します。
 
-- Bug fixes  
-- 新機能  
-- プライベートインターフェースへの変更  
-- beta 機能の更新  
+- バグ修正
+- 新機能
+- 非公開インターフェースの変更
+- ベータ機能の更新
 
-## 互換性のない変更履歴
+## 破壊的変更の変更履歴
 
 ### 0.2.0
 
-このバージョンでは、以前は引数として `Agent` を受け取っていたいくつかの箇所が、代わりに `AgentBase` を受け取るようになりました。たとえば MCP サーバーの `list_tools()` 呼び出しです。これは型の変更のみであり、実際に受け取るオブジェクトは依然として `Agent` です。アップデートするには、`Agent` を `AgentBase` に置き換えて型エラーを修正してください。
+このバージョンでは、以前は `Agent` を引数として受け取っていたいくつかの箇所が、代わりに `AgentBase` を受け取るようになりました。例としては MCP サーバー内の `list_tools()` 呼び出しなどです。これは型に関する変更のみで、実際には引き続き `Agent` オブジェクトを受け取ります。更新の際は、型エラーを解消するため `Agent` を `AgentBase` に置き換えてください。
 
 ### 0.1.0
 
-このバージョンでは、[`MCPServer.list_tools()`][agents.mcp.server.MCPServer] に新しいパラメーター `run_context` と `agent` が追加されました。`MCPServer` を継承しているすべてのクラスにこれらのパラメーターを追加する必要があります。
\ No newline at end of file
+このバージョンでは、[`MCPServer.list_tools()`][agents.mcp.server.MCPServer] に `run_context` と `agent` の 2 つの新しいパラメーターが追加されました。 `MCPServer` をサブクラス化しているクラスでは、これらのパラメーターを追加する必要があります。
\ No newline at end of file
diff --git a/docs/ja/repl.md b/docs/ja/repl.md
index d6e383bb9..8c372986c 100644
--- a/docs/ja/repl.md
+++ b/docs/ja/repl.md
@@ -4,7 +4,7 @@ search:
 ---
 # REPL ユーティリティ
 
-SDK は、簡易的なインタラクティブテスト用に `run_demo_loop` を提供します。
+SDK では、素早く対話的にテストできる `run_demo_loop` を提供しています。
 
 ```python
 import asyncio
@@ -18,4 +18,4 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-`run_demo_loop` はループでユーザー入力を促し、ターン間の会話履歴を保持します。デフォルトでは、生成されたモデル出力をストリーミングします。ループを終了するには `quit` または `exit` と入力するか（または `Ctrl-D` を押してください）。
\ No newline at end of file
+`run_demo_loop` は、ループ内でユーザー入力を促し、各ターン間で会話履歴を保持します。デフォルトでは、生成されたとおりにモデル出力をストリーミング表示します。ループを終了するには `quit` または `exit` と入力するか、`Ctrl-D` を押してください。
\ No newline at end of file
diff --git a/docs/ja/results.md b/docs/ja/results.md
index b44669bc8..4045e4518 100644
--- a/docs/ja/results.md
+++ b/docs/ja/results.md
@@ -2,54 +2,55 @@
 search:
   exclude: true
 ---
-# 結果
+# 実行結果
 
-` Runner.run ` メソッドを呼び出すと、戻り値は次のいずれかになります。
+`Runner.run` メソッドを呼び出すと、次のいずれかが返されます。
 
--   [`RunResult`][agents.result.RunResult] （ `run` または `run_sync` を呼び出した場合）
--   [`RunResultStreaming`][agents.result.RunResultStreaming] （ `run_streamed` を呼び出した場合）
+- `run` または `run_sync` を呼び出した場合は [`RunResult`][agents.result.RunResult]
+- `run_streamed` を呼び出した場合は [`RunResultStreaming`][agents.result.RunResultStreaming]
 
-どちらも [`RunResultBase`][agents.result.RunResultBase] を継承しており、ほとんどの有用な情報はここに含まれています。
+どちらも [`RunResultBase`][agents.result.RunResultBase] を継承しており、多くの有用な情報はここに格納されています。
 
 ## 最終出力
 
-[`final_output`][agents.result.RunResultBase.final_output] プロパティには、最後に実行されたエージェントの最終出力が入っています。内容は次のいずれかです。
+[`final_output`][agents.result.RunResultBase.final_output] プロパティには、最後に実行されたエージェントの最終出力が入ります。内容は次のいずれかです。
 
--   最後のエージェントに `output_type` が定義されていない場合は `str`
--   エージェントに `output_type` が定義されている場合は `last_agent.output_type` 型のオブジェクト
+- 最後のエージェントで `output_type` が定義されていない場合は `str`
+- `last_agent.output_type` が定義されている場合はその型のオブジェクト
 
 !!! note
-    `final_output` の型は `Any` です。ハンドオフが発生する可能性があるため静的に型付けできません。ハンドオフが発生した場合、どのエージェントが最後になるか分からないため、可能な出力型の集合を静的に知ることはできません。
 
-## 次のターンへの入力
+    `final_output` の型は `Any` です。ハンドオフがある可能性があるため、静的に型付けすることはできません。ハンドオフが発生すると、どのエージェントが最後になるか分からないため、可能な出力型の集合を静的に特定できないからです。
 
-[`result.to_input_list()`][agents.result.RunResultBase.to_input_list] を使うと、元の入力とエージェント実行中に生成されたアイテムを連結して入力リストを作成できます。これにより、一度のエージェント実行の出力を別の実行に渡したり、ループで実行して毎回新しいユーザー入力を追加したりするのが簡単になります。
+## 次ターン用の入力
 
-## 最後のエージェント
+[`result.to_input_list()`][agents.result.RunResultBase.to_input_list] を使用すると、最初に渡した入力にエージェント実行中に生成された項目を連結した入力リストを取得できます。これにより、一度のエージェント実行の出力を次の実行に渡したり、ループ処理でユーザーの新しい入力を都度追加したりするのが簡単になります。
 
-[`last_agent`][agents.result.RunResultBase.last_agent] プロパティには、最後に実行されたエージェントが入っています。アプリケーションによっては、ユーザーが次に入力する際にこれを再利用すると便利です。たとえば、最初にフロントラインのトリアージエージェントが言語別エージェントへハンドオフする場合、最後のエージェントを保存しておけば、ユーザーが次にメッセージを送ったときに再利用できます。
+## 最後に実行したエージェント
+
+[`last_agent`][agents.result.RunResultBase.last_agent] プロパティには、最後に実行されたエージェントが格納されます。アプリケーションによっては、次にユーザーが入力した際に役立つことが多いです。たとえば、一次対応のトリアージエージェントが言語固有のエージェントへハンドオフする場合、`last_agent` を保存しておき、次回ユーザーがメッセージを送ったときに再利用できます。
 
 ## 新規アイテム
 
-[`new_items`][agents.result.RunResultBase.new_items] プロパティには、実行中に生成された新しいアイテムが入っています。アイテムは [`RunItem`][agents.items.RunItem] でラップされており、LLM が生成した生のアイテムを保持します。
+[`new_items`][agents.result.RunResultBase.new_items] プロパティには、実行中に生成された新規アイテムが含まれます。アイテムは [`RunItem`][agents.items.RunItem] でラップされています。RunItem は LLM が生成した raw アイテムを保持します。
 
--   [`MessageOutputItem`][agents.items.MessageOutputItem] は LLM からのメッセージを示します。生のアイテムは生成されたメッセージです。
--   [`HandoffCallItem`][agents.items.HandoffCallItem] は LLM がハンドオフツールを呼び出したことを示します。生のアイテムはツールコールアイテムです。
--   [`HandoffOutputItem`][agents.items.HandoffOutputItem] はハンドオフが発生したことを示します。生のアイテムはハンドオフツールコールへのツール応答です。アイテムからソース／ターゲットエージェントにもアクセスできます。
--   [`ToolCallItem`][agents.items.ToolCallItem] は LLM がツールを呼び出したことを示します。
--   [`ToolCallOutputItem`][agents.items.ToolCallOutputItem] はツールが実行されたことを示します。生のアイテムはツール応答です。ツール出力にもアクセスできます。
--   [`ReasoningItem`][agents.items.ReasoningItem] は LLM からの推論アイテムを示します。生のアイテムは生成された推論です。
+- [`MessageOutputItem`][agents.items.MessageOutputItem] は LLM からのメッセージを示します。raw アイテムは生成されたメッセージです。
+- [`HandoffCallItem`][agents.items.HandoffCallItem] は LLM がハンドオフツールを呼び出したことを示します。raw アイテムはツール呼び出しアイテムです。
+- [`HandoffOutputItem`][agents.items.HandoffOutputItem] はハンドオフが発生したことを示します。raw アイテムはハンドオフツールへの応答です。ソース／ターゲットエージェントにもアクセスできます。
+- [`ToolCallItem`][agents.items.ToolCallItem] は LLM がツールを呼び出したことを示します。
+- [`ToolCallOutputItem`][agents.items.ToolCallOutputItem] はツールが呼び出されたことを示します。raw アイテムはツール応答です。ツールの出力にもアクセスできます。
+- [`ReasoningItem`][agents.items.ReasoningItem] は LLM からの推論アイテムを示します。raw アイテムは生成された推論内容です。
 
 ## その他の情報
 
 ### ガードレール結果
 
-[`input_guardrail_results`][agents.result.RunResultBase.input_guardrail_results] と [`output_guardrail_results`][agents.result.RunResultBase.output_guardrail_results] プロパティには、ガードレールの結果（存在する場合）が入っています。ガードレール結果にはログや保存に有用な情報が含まれることがあるため、こちらで参照できます。
+[`input_guardrail_results`][agents.result.RunResultBase.input_guardrail_results] と [`output_guardrail_results`][agents.result.RunResultBase.output_guardrail_results] プロパティには、ガードレールの結果が入ります（存在する場合）。ガードレール結果にはログや保存に役立つ情報が含まれることがあるため、参照できるようにしています。
 
 ### raw 応答
 
-[`raw_responses`][agents.result.RunResultBase.raw_responses] プロパティには、LLM が生成した [`ModelResponse`][agents.items.ModelResponse] が入っています。
+[`raw_responses`][agents.result.RunResultBase.raw_responses] プロパティには、LLM が生成した [`ModelResponse`][agents.items.ModelResponse] が格納されます。
 
 ### 元の入力
 
-[`input`][agents.result.RunResultBase.input] プロパティには、 `run` メソッドに渡した元の入力が入っています。通常は必要ありませんが、必要に応じて参照できます。
\ No newline at end of file
+[`input`][agents.result.RunResultBase.input] プロパティには、`run` メソッドに渡した元の入力が保存されています。大半のケースでは不要ですが、必要に応じて参照できます。
\ No newline at end of file
diff --git a/docs/ja/running_agents.md b/docs/ja/running_agents.md
index a26be1478..33670ccfc 100644
--- a/docs/ja/running_agents.md
+++ b/docs/ja/running_agents.md
@@ -4,12 +4,11 @@ search:
 ---
 # エージェントの実行
 
-エージェントは [`Runner`][agents.run.Runner] クラスを介して実行できます。選択肢は 3 つあります。
+エージェントは `Runner` クラスを介して実行できます。方法は 3 つあります。
 
-1. 非同期で実行し、[`RunResult`][agents.result.RunResult] を返す [`Runner.run()`][agents.run.Runner.run]  
-2. 同期メソッドで、内部的に `.run()` を実行する [`Runner.run_sync()`][agents.run.Runner.run_sync]  
-3. 非同期で実行し、[`RunResultStreaming`][agents.result.RunResultStreaming] を返す [`Runner.run_streamed()`][agents.run.Runner.run_streamed]  
-   LLM をストリーミング モードで呼び出し、受信したイベントを逐次配信します。
+1. `Runner.run()` : 非同期で実行し、 `RunResult` を返します。  
+2. `Runner.run_sync()` : 同期メソッドで、内部的には `.run()` を呼び出します。  
+3. `Runner.run_streamed()` : 非同期で実行し、 `RunResultStreaming` を返します。LLM をストリーミングモードで呼び出し、受信したイベントを逐次ストリームします。
 
 ```python
 from agents import Agent, Runner
@@ -24,55 +23,55 @@ async def main():
     # Infinite loop's dance
 ```
 
-詳細は [結果ガイド](results.md) をご覧ください。
+詳細は [結果ガイド](results.md) を参照してください。
 
 ## エージェントループ
 
-` Runner ` の run メソッドを使用する際は、開始エージェントと入力を渡します。入力は文字列（ユーザー メッセージと見なされます）または OpenAI Responses API の項目リストのいずれかです。
+`Runner` の run メソッドを使う際には、開始エージェントと入力を渡します。入力は文字列（ユーザー メッセージと見なされます）か、OpenAI Responses API のアイテムのリストを指定できます。
 
-Runner は次のループを実行します。
+ランナーは次のループを実行します。
 
-1. 現在のエージェントに対して LLM を呼び出し、現在の入力を渡します。  
+1. 現在のエージェントと入力を用いて LLM を呼び出します。  
 2. LLM が出力を生成します。  
     1. `final_output` が返された場合、ループを終了し結果を返します。  
-    2. ハンドオフが発生した場合、現在のエージェントと入力を更新し、ループを再実行します。  
-    3. ツール呼び出しが生成された場合、それらを実行し結果を追加してループを再実行します。  
-3. 渡された `max_turns` を超えた場合、[`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded] 例外を送出します。
+    2. ハンドオフが行われた場合、現在のエージェントと入力を更新してループを再実行します。  
+    3. ツール呼び出しを含む場合は、それらを実行し結果を追加してループを再実行します。  
+3. `max_turns` を超えた場合は `MaxTurnsExceeded` 例外を送出します。
 
 !!! note
 
-    LLM の出力が「最終出力」と見なされる条件は、望ましい型のテキスト出力を生成し、かつツール呼び出しが存在しない場合です。
+    LLM の出力が「最終出力」と見なされる条件は、望ましい型のテキスト出力であり、ツール呼び出しが存在しないことです。
 
 ## ストリーミング
 
-ストリーミングを利用すると、LLM 実行中のイベントを逐次受け取れます。ストリーム完了後、[`RunResultStreaming`][agents.result.RunResultStreaming] には実行に関する完全な情報（生成されたすべての新規出力を含む）が格納されます。`.stream_events()` を呼び出してストリーミング イベントを取得できます。詳細は [ストリーミング ガイド](streaming.md) を参照してください。
+ストリーミングを有効にすると、LLM の実行中にストリーミングイベントも受け取れます。ストリーム完了後、 `RunResultStreaming` には実行に関する完全な情報（新しく生成されたすべての出力を含む）が格納されます。`.stream_events()` を呼び出してストリーミングイベントを取得できます。詳細は [ストリーミングガイド](streaming.md) を参照してください。
 
-## Run 設定
+## 実行設定
 
-` run_config ` パラメーターでエージェント実行のグローバル設定を行えます。
+`run_config` パラメーターでは、エージェント実行に対するグローバル設定を行えます。
 
-- [`model`][agents.run.RunConfig.model]: 各エージェントの `model` 設定に関わらず、使用する LLM モデルをグローバルに指定します。  
-- [`model_provider`][agents.run.RunConfig.model_provider]: モデル名を解決するプロバイダー。既定では OpenAI です。  
-- [`model_settings`][agents.run.RunConfig.model_settings]: エージェント固有の設定を上書きします。例として `temperature` や `top_p` をグローバルに設定可能です。  
-- [`input_guardrails`][agents.run.RunConfig.input_guardrails], [`output_guardrails`][agents.run.RunConfig.output_guardrails]: すべての実行に含める入力／出力ガードレールのリスト。  
-- [`handoff_input_filter`][agents.run.RunConfig.handoff_input_filter]: 既に handoff にフィルターが指定されていない場合に適用されるグローバル入力フィルター。新しいエージェントへ送信する入力を編集できます。詳細は [`Handoff.input_filter`][agents.handoffs.Handoff.input_filter] のドキュメントを参照してください。  
-- [`tracing_disabled`][agents.run.RunConfig.tracing_disabled]: 実行全体の [トレーシング](tracing.md) を無効にします。  
-- [`trace_include_sensitive_data`][agents.run.RunConfig.trace_include_sensitive_data]: LLM やツール呼び出しの入出力など、機微情報をトレースに含めるかどうかを設定します。  
-- [`workflow_name`][agents.run.RunConfig.workflow_name], [`trace_id`][agents.run.RunConfig.trace_id], [`group_id`][agents.run.RunConfig.group_id]: 実行のトレーシング workflow 名、trace ID、trace group ID を設定します。少なくとも `workflow_name` の設定を推奨します。group ID は複数実行にまたがるトレースを関連付けるための任意フィールドです。  
-- [`trace_metadata`][agents.run.RunConfig.trace_metadata]: すべてのトレースに含めるメタデータ。  
+- `model` : 各エージェントの `model` 設定に関わらず、グローバルに使用する LLM モデルを指定します。  
+- `model_provider` : モデル名を解決するモデルプロバイダーで、デフォルトは OpenAI です。  
+- `model_settings` : エージェント固有の設定を上書きします。例として、グローバルな `temperature` や `top_p` を設定できます。  
+- `input_guardrails`, `output_guardrails` : すべての実行に適用する入力／出力ガードレールのリスト。  
+- `handoff_input_filter` : 既にフィルターが設定されていないハンドオフに対し、すべてのハンドオフに適用するグローバル入力フィルター。詳細は `Handoff.input_filter` のドキュメントを参照してください。  
+- `tracing_disabled` : 実行全体に対して トレーシング を無効化します。  
+- `trace_include_sensitive_data` : トレースに LLM やツール呼び出しの入出力など、機密の可能性があるデータを含めるかどうかを設定します。  
+- `workflow_name`, `trace_id`, `group_id` : 実行のトレーシングに使うワークフロー名、トレース ID、トレース グループ ID を設定します。少なくとも `workflow_name` を設定することを推奨します。`group_id` は複数実行にわたるトレースを関連付けるための任意フィールドです。  
+- `trace_metadata` : すべてのトレースに含めるメタデータ。  
 
 ## 会話／チャットスレッド
 
-いずれかの run メソッドを呼び出すと、1 回または複数回のエージェント実行（つまり複数回の LLM 呼び出し）が発生しますが、チャット会話における 1 つの論理ターンを表します。例:
+いずれの run メソッドを呼び出しても、1 回または複数のエージェント（＝複数の LLM 呼び出し）が実行されますが、チャット会話上は 1 つの論理的ターンとなります。例:
 
-1. ユーザー ターン: ユーザーがテキストを入力  
-2. Runner 実行: 第 1 エージェントが LLM を呼び出しツールを実行、次に第 2 エージェントへハンドオフし追加のツールを実行、最終出力を生成  
+1. ユーザーターン: ユーザーがテキストを入力  
+2. Runner 実行: 第 1 エージェントが LLM を呼び出しツールを実行し、第 2 エージェントへハンドオフ。第 2 エージェントがさらにツールを実行し、最終出力を生成。  
 
-エージェント実行後、ユーザーにどの項目を表示するか選択できます。たとえば、エージェントが生成したすべての新規項目を表示することも、最終出力のみを表示することもできます。いずれの場合でも、ユーザーがフォローアップ質問をしたら再度 run メソッドを呼び出せます。
+エージェント実行の最後に、ユーザーへ何を表示するかを選択できます。たとえばエージェントが生成したすべての新規アイテムを表示するか、最終出力のみを表示するかを選べます。いずれの場合も、ユーザーが追加入力を行ったら再び run メソッドを呼び出します。
 
-### 手動の会話管理
+### 手動での会話管理
 
-[`RunResultBase.to_input_list()`][agents.result.RunResultBase.to_input_list] メソッドを使用して次のターンの入力を取得し、会話履歴を手動で管理できます。
+[`RunResultBase.to_input_list()`] メソッドを使って次のターンの入力を取得し、会話履歴を手動で管理できます。
 
 ```python
 async def main():
@@ -92,9 +91,9 @@ async def main():
         # California
 ```
 
-### Sessions による自動会話管理
+### Session を使った自動会話管理
 
-より簡単な方法として、[Sessions](sessions.md) を使用すると `.to_input_list()` を手動で呼ばずに会話履歴を自動管理できます。
+より簡単な方法として、[Sessions](sessions.md) を利用すれば `.to_input_list()` を手動で呼び出さずに会話履歴を自動管理できます。
 
 ```python
 from agents import Agent, Runner, SQLiteSession
@@ -117,20 +116,20 @@ async def main():
         # California
 ```
 
-Sessions は次を自動で行います。
+Session は自動で以下を行います。
 
 - 各実行前に会話履歴を取得  
-- 各実行後に新規メッセージを保存  
-- 異なるセッション ID ごとに個別の会話を維持  
+- 各実行後に新しいメッセージを保存  
+- 異なる session ID ごとに個別の会話を維持  
 
 詳細は [Sessions のドキュメント](sessions.md) を参照してください。
 
 ## 例外
 
-SDK は特定の場合に例外を送出します。完全な一覧は [`agents.exceptions`][] にあります。概要は次のとおりです。
+特定の状況で SDK は例外を送出します。完全な一覧は `agents.exceptions` にあります。概要は以下のとおりです。
 
-- [`AgentsException`][agents.exceptions.AgentsException] : SDK で送出されるすべての例外の基底クラス  
-- [`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded] : 実行が run メソッドに渡した `max_turns` を超えた場合に送出  
-- [`ModelBehaviorError`][agents.exceptions.ModelBehaviorError] : モデルが無効な出力（例: 不正な JSON や存在しないツールの使用）を生成した場合に送出  
-- [`UserError`][agents.exceptions.UserError] : SDK を使用するコードの記述者が誤った使い方をした場合に送出  
-- [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered], [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered] : [ガードレール](guardrails.md) がトリップした際に送出
\ No newline at end of file
+- `AgentsException` : SDK が送出するすべての例外の基底クラス。  
+- `MaxTurnsExceeded` : 実行が run メソッドに渡した `max_turns` を超えた場合に送出。  
+- `ModelBehaviorError` : モデルが無効な出力（例: 不正な JSON や存在しないツールの使用）を生成した場合に送出。  
+- `UserError` : SDK 利用時の実装ミスなど、ユーザー側のエラーで送出。  
+- `InputGuardrailTripwireTriggered`, `OutputGuardrailTripwireTriggered` : ガードレール がトリップした際に送出。
\ No newline at end of file
diff --git a/docs/ja/sessions.md b/docs/ja/sessions.md
index cb006fedc..fb45e7685 100644
--- a/docs/ja/sessions.md
+++ b/docs/ja/sessions.md
@@ -4,9 +4,9 @@ search:
 ---
 # セッション
 
-Agents SDK には組み込みのセッションメモリーがあり、複数回のエージェント実行にわたって会話履歴を自動的に保持します。これにより、ターンごとに `.to_input_list()` を手動で扱う必要がなくなります。
+Agents SDK では、組み込みのセッションメモリを提供しており、複数回のエージェント実行にわたって会話履歴を自動的に保持します。これにより、ターンごとに `.to_input_list()` を手動で扱う必要がなくなります。
 
-Sessions は特定のセッションに対して会話履歴を保存し、エージェントが明示的なメモリー管理なしでコンテキストを維持できるようにします。チャットアプリケーションやマルチターンの会話で、エージェントに前回の対話内容を覚えさせたい場合に特に便利です。
+Sessions は特定のセッションの会話履歴を保存し、明示的なメモリ管理を行わなくてもエージェントがコンテキストを維持できるようにします。これは、チャットアプリケーションやマルチターンの会話で、エージェントに以前のやり取りを覚えさせたい場合に特に便利です。
 
 ## クイックスタート
 
@@ -49,19 +49,19 @@ print(result.final_output)  # "Approximately 39 million"
 
 ## 仕組み
 
-セッションメモリーが有効な場合:
+セッションメモリが有効になっている場合:
 
-1. **各実行前**: Runner はそのセッションの会話履歴を自動的に取得し、入力アイテムの先頭に追加します。  
-2. **各実行後**: 実行中に生成された新しいアイテム (ユーザー入力、アシスタントの応答、ツール呼び出しなど) がすべて自動的にセッションに保存されます。  
-3. **コンテキスト維持**: 同じセッションでの後続の実行には完全な会話履歴が含まれるため、エージェントはコンテキストを保持できます。
+1. **各実行前**: Runner はセッションの会話履歴を自動的に取得し、入力アイテムの先頭に追加します。  
+2. **各実行後**: 実行中に生成された新しいアイテム (ユーザー入力、アシスタントの応答、ツール呼び出しなど) はすべて自動的にセッションへ保存されます。  
+3. **コンテキストの保持**: 同じセッションでの後続の実行には完全な会話履歴が含まれるため、エージェントはコンテキストを維持できます。
 
 これにより、`.to_input_list()` を手動で呼び出したり、実行間で会話状態を管理したりする必要がなくなります。
 
-## メモリー操作
+## メモリ操作
 
 ### 基本操作
 
-Sessions では会話履歴を管理するためのさまざまな操作がサポートされています:
+Sessions では、会話履歴を管理するために複数の操作がサポートされています:
 
 ```python
 from agents import SQLiteSession
@@ -86,9 +86,9 @@ print(last_item)  # {"role": "assistant", "content": "Hi there!"}
 await session.clear_session()
 ```
 
-### 修正のための pop_item の使用
+### pop_item を使った修正
 
-`pop_item` メソッドは、会話の最後のアイテムを取り消したり修正したりしたい場合に特に便利です:
+`pop_item` メソッドは、会話の最後のアイテムを取り消したり変更したりしたい場合に特に役立ちます。
 
 ```python
 from agents import Agent, Runner, SQLiteSession
@@ -117,16 +117,16 @@ result = await Runner.run(
 print(f"Agent: {result.final_output}")
 ```
 
-## メモリーオプション
+## メモリオプション
 
-### メモリーなし（デフォルト）
+### メモリなし (デフォルト)
 
 ```python
 # Default behavior - no session memory
 result = await Runner.run(agent, "Hello")
 ```
 
-### SQLite メモリー
+### SQLite メモリ
 
 ```python
 from agents import SQLiteSession
@@ -168,9 +168,9 @@ result2 = await Runner.run(
 )
 ```
 
-## カスタムメモリー実装
+## カスタムメモリ実装
 
-独自のセッションメモリーを実装する場合は、[`Session`][agents.memory.session.Session] プロトコルに従うクラスを作成してください:
+[`Session`][agents.memory.session.Session] プロトコルに従ったクラスを作成することで、独自のセッションメモリを実装できます。
 
 ````python
 from agents.memory import Session
@@ -230,15 +230,15 @@ Use meaningful session IDs that help you organize conversations:
 ### Session management
 
 ```python
-# Clear a session when conversation should start fresh
+# 会話をリセットしたい場合にセッションをクリア
 await session.clear_session()
 
-# Different agents can share the same session
+# 複数のエージェントが同じセッションを共有可能
 support_agent = Agent(name="Support")
 billing_agent = Agent(name="Billing")
 session = SQLiteSession("user_123")
 
-# Both agents will see the same conversation history
+# 両方のエージェントが同じ会話履歴を参照
 result1 = await Runner.run(
     support_agent,
     "Help me with my account",
@@ -261,19 +261,19 @@ from agents import Agent, Runner, SQLiteSession
 
 
 async def main():
-    # Create an agent
+    # エージェントの作成
     agent = Agent(
         name="Assistant",
         instructions="Reply very concisely.",
     )
 
-    # Create a session instance that will persist across runs
+    # 複数回の実行にわたって保持されるセッションを作成
     session = SQLiteSession("conversation_123", "conversation_history.db")
 
     print("=== Sessions Example ===")
     print("The agent will remember previous messages automatically.\n")
 
-    # First turn
+    # 1ターン目
     print("First turn:")
     print("User: What city is the Golden Gate Bridge in?")
     result = await Runner.run(
@@ -284,7 +284,7 @@ async def main():
     print(f"Assistant: {result.final_output}")
     print()
 
-    # Second turn - the agent will remember the previous conversation
+    # 2ターン目 － エージェントは前回の会話を覚えている
     print("Second turn:")
     print("User: What state is it in?")
     result = await Runner.run(
@@ -295,7 +295,7 @@ async def main():
     print(f"Assistant: {result.final_output}")
     print()
 
-    # Third turn - continuing the conversation
+    # 3ターン目 － 会話を継続
     print("Third turn:")
     print("User: What's the population of that state?")
     result = await Runner.run(
diff --git a/docs/ja/streaming.md b/docs/ja/streaming.md
index f765a06ef..7b7d8e24d 100644
--- a/docs/ja/streaming.md
+++ b/docs/ja/streaming.md
@@ -4,15 +4,15 @@ search:
 ---
 # ストリーミング
 
-ストリーミングを使用すると、エージェントの実行が進行するにつれて、その更新情報を購読できます。これは、エンドユーザーに進捗状況や途中経過のレスポンスを表示する際に役立ちます。
+ストリーミングを使用すると、 エージェント 実行の進行に合わせて更新を購読できます。これは、エンド ユーザー に進捗状況の更新や部分的なレスポンスを表示するのに役立ちます。
 
-ストリーミングを行うには、 `Runner.run_streamed()` を呼び出します。これにより `RunResultStreaming` が返されます。続いて `result.stream_events()` を呼び出すと、 `StreamEvent` オブジェクトの async ストリームが取得できます。これらは後述します。
+ストリーミングを行うには `Runner.run_streamed()` を呼び出します。これにより `RunResultStreaming` が返されます。さらに `result.stream_events()` を呼び出すと、下記で説明する `StreamEvent` オブジェクトの非同期ストリームを取得できます。
 
-## Raw response イベント
+## Raw レスポンスイベント
 
-`RawResponsesStreamEvent` は、 LLM から直接渡される raw イベントです。これらは OpenAI Responses API フォーマットであり、各イベントにはタイプ（ `response.created` 、 `response.output_text.delta` など）とデータが含まれます。生成された直後にレスポンスメッセージをユーザーにストリーミングしたい場合に便利です。
+`RawResponsesStreamEvent` は、  LLM  から直接渡される raw イベントです。これらは  OpenAI Responses API 形式であり、各イベントには `response.created` や `response.output_text.delta` などの type と data が含まれます。生成されたメッセージをすぐにユーザーへストリーミングしたい場合に便利です。
 
-たとえば、以下のコードは LLM が生成したテキストをトークンごとに出力します。
+たとえば、以下のコードは  LLM  が生成したテキストをトークンごとに出力します。
 
 ```python
 import asyncio
@@ -35,11 +35,11 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-## Run item イベントとエージェントイベント
+## Run item イベントおよびエージェント イベント
 
-`RunItemStreamEvent` は、より高レベルのイベントです。アイテムが完全に生成されたタイミングを通知します。これにより、トークンごとの更新ではなく「メッセージが生成された」「ツールが実行された」などの粒度で進捗をユーザーに伝えられます。同様に、 `AgentUpdatedStreamEvent` は、ハンドオフの結果などで現在のエージェントが変化した際に更新を通知します。
+`RunItemStreamEvent` はより高レベルのイベントで、アイテムが完全に生成されたタイミングを知らせます。これにより、各トークンではなく「メッセージが生成された」「ツールが実行された」などの単位で進捗を通知できます。同様に `AgentUpdatedStreamEvent` はハンドオフの結果などで現在の エージェント が変更された際にアップデートを提供します。
 
-例として、以下のコードは raw イベントを無視し、ユーザーへ更新のみをストリーミングします。
+たとえば、次のコードは raw イベントを無視し、ユーザーへアップデートのみをストリーミングします。
 
 ```python
 import asyncio
diff --git a/docs/ja/tools.md b/docs/ja/tools.md
index b6b2b1de1..77e674c3e 100644
--- a/docs/ja/tools.md
+++ b/docs/ja/tools.md
@@ -4,23 +4,23 @@ search:
 ---
 # ツール
 
-ツールはエージェントに行動を取らせるための手段です。例えばデータの取得、コードの実行、外部 API の呼び出し、さらにはコンピュータ操作などが可能になります。Agents SDK には 3 種類のツールがあります。
+ツールを使うとエージェントは行動を実行できます。たとえばデータの取得、コードの実行、外部 API の呼び出し、さらにはコンピュータ操作まで行えます。Agents SDK には次の 3 種類のツールがあります。
 
--   ホスト型ツール: これらは LLM サーバー上で AI モデルと並行して動作します。OpenAI は retrieval、Web 検索、コンピュータ操作をホスト型ツールとして提供しています。  
--   Function calling: 任意の Python 関数をツールとして使用できます。  
--   エージェントをツールとして使用: ハンドオフを行わずに、エージェント同士が相互に呼び出せるようにします。  
+-   ホストツール: これらは AI モデルと同じ LLM サーバー上で実行されます。OpenAI は retrieval、Web 検索、コンピュータ操作をホストツールとして提供しています。
+-   関数呼び出し: 任意の Python 関数をツールとして利用できます。
+-   エージェントをツールとして利用: エージェントをツール化し、ハンドオフなしで他のエージェントを呼び出すことができます。
 
-## ホスト型ツール
+## ホストツール
 
 OpenAI は [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel] を使用する際に、いくつかの組み込みツールを提供しています。
 
--   [`WebSearchTool`][agents.tool.WebSearchTool] はエージェントに Web 検索を行わせます。  
--   [`FileSearchTool`][agents.tool.FileSearchTool] は OpenAI ベクトルストアから情報を取得します。  
--   [`ComputerTool`][agents.tool.ComputerTool] はコンピュータ操作タスクを自動化します。  
--   [`CodeInterpreterTool`][agents.tool.CodeInterpreterTool] はサンドボックス環境でコードを実行します。  
--   [`HostedMCPTool`][agents.tool.HostedMCPTool] はリモート MCP サーバーのツールをモデルに公開します。  
--   [`ImageGenerationTool`][agents.tool.ImageGenerationTool] はプロンプトから画像を生成します。  
--   [`LocalShellTool`][agents.tool.LocalShellTool] はローカルマシンでシェルコマンドを実行します。  
+-   [`WebSearchTool`][agents.tool.WebSearchTool] はエージェントに Web 検索を行わせます。
+-   [`FileSearchTool`][agents.tool.FileSearchTool] は OpenAI ベクトルストアから情報を取得します。
+-   [`ComputerTool`][agents.tool.ComputerTool] はコンピュータ操作タスクを自動化します。
+-   [`CodeInterpreterTool`][agents.tool.CodeInterpreterTool] は LLM がサンドボックス環境でコードを実行できるようにします。
+-   [`HostedMCPTool`][agents.tool.HostedMCPTool] はリモート MCP サーバーのツールをモデルに公開します。
+-   [`ImageGenerationTool`][agents.tool.ImageGenerationTool] はプロンプトから画像を生成します。
+-   [`LocalShellTool`][agents.tool.LocalShellTool] はローカルマシンでシェルコマンドを実行します。
 
 ```python
 from agents import Agent, FileSearchTool, Runner, WebSearchTool
@@ -41,16 +41,16 @@ async def main():
     print(result.final_output)
 ```
 
-## Function tools
+## 関数ツール
 
-任意の Python 関数をツールとして使用できます。Agents SDK が自動的に設定を行います。
+任意の Python 関数をツールとして使用できます。Agents SDK が自動で設定を行います。
 
--   ツール名は Python 関数名になります（または名前を指定可能）。  
--   ツールの説明は関数の docstring から取得されます（または説明を指定可能）。  
--   関数の引数から入力スキーマが自動生成されます。  
--   各入力の説明は docstring から取得されます（無効化可）。  
+-   ツール名は Python 関数名になります（任意で名前を指定可能）。
+-   ツールの説明は関数の docstring から取得します（任意で説明を指定可能）。
+-   関数入力のスキーマは関数の引数から自動生成されます。
+-   各入力の説明は docstring から取得されます（無効化も可能）。
 
-関数シグネチャの抽出には Python の `inspect` モジュールを使用し、docstring の解析には [`griffe`](https://mkdocstrings.github.io/griffe/)、スキーマ作成には `pydantic` を使用しています。
+Python の `inspect` モジュールで関数シグネチャを抽出し、[`griffe`](https://mkdocstrings.github.io/griffe/) で docstring を解析し、`pydantic` でスキーマを作成します。
 
 ```python
 import json
@@ -102,10 +102,10 @@ for tool in agent.tools:
 
 ```
 
-1.  引数には任意の Python 型を使用でき、関数は sync / async いずれでも構いません。  
-2.  docstring があれば、説明や引数の説明を取得します。  
-3.  関数の最初の引数として `context` を取ることができます。また、ツール名や説明、docstring スタイルなどのオーバーライドも設定可能です。  
-4.  デコレーターを付けた関数をツールのリストに渡せます。  
+1.  関数の引数には任意の Python 型を使え、同期でも非同期でも構いません。
+2.  docstring があれば、説明と引数の説明を取得します。
+3.  関数はオプションで `context` を最初の引数として受け取れます。また、ツール名や説明、docstring スタイルなどを上書き設定できます。
+4.  デコレートした関数をツールのリストに渡してください。
 
 ??? note "出力を表示"
 
@@ -177,14 +177,14 @@ for tool in agent.tools:
     }
     ```
 
-### カスタム Function tool
+### カスタム関数ツール
 
-Python 関数をそのままツールとして使いたくない場合は、[`FunctionTool`][agents.tool.FunctionTool] を直接作成できます。必要なものは以下のとおりです。
+Python 関数を使わずにツールを作成したい場合は、直接 [`FunctionTool`][agents.tool.FunctionTool] を作成できます。次の項目を指定してください。
 
--   `name`  
--   `description`  
--   `params_json_schema` : 引数の JSON スキーマ  
--   `on_invoke_tool` : [`ToolContext`][agents.tool_context.ToolContext] と引数（JSON 文字列）を受け取り、ツール出力を文字列で返す async 関数  
+-   `name`
+-   `description`
+-   `params_json_schema`（引数の JSON スキーマ）
+-   `on_invoke_tool`（[`ToolContext`][agents.tool_context.ToolContext] と JSON 文字列の引数を受け取り、ツール出力を文字列で返す async 関数）
 
 ```python
 from typing import Any
@@ -219,16 +219,16 @@ tool = FunctionTool(
 
 ### 引数と docstring の自動解析
 
-前述のとおり、関数シグネチャを解析してツールのスキーマを生成し、docstring を解析してツールおよび各引数の説明を取得します。ポイントは次のとおりです。
+前述のとおり、関数シグネチャを解析してツールのスキーマを生成し、docstring を解析してツールおよび各引数の説明を抽出します。補足事項は以下のとおりです。
 
-1. シグネチャ解析は `inspect` モジュールで行います。型アノテーションを利用して引数の型を理解し、Pydantic モデルを動的に構築してスキーマを表現します。Python プリミティブ、Pydantic モデル、TypedDict などほとんどの型をサポートします。  
-2. docstring の解析には `griffe` を使用します。サポートされる docstring 形式は `google`、`sphinx`、`numpy` です。自動判定を試みますが、`function_tool` 呼び出し時に明示的に指定することもできます。`use_docstring_info` を `False` に設定すると docstring 解析を無効化できます。  
+1.  シグネチャ解析には `inspect` モジュールを使用します。型アノテーションから引数型を取得し、動的に Pydantic モデルを構築して全体のスキーマを表現します。Python の基本型、Pydantic モデル、TypedDict などほとんどの型をサポートします。
+2.  docstring の解析には `griffe` を使用します。サポートしている docstring 形式は `google`、`sphinx`、`numpy` です。自動判定を試みますが、`function_tool` 呼び出し時に明示指定もできます。`use_docstring_info` を `False` に設定すると解析を無効化できます。
 
 スキーマ抽出のコードは [`agents.function_schema`][] にあります。
 
-## エージェントをツールとして使用
+## エージェントをツールとして利用
 
-ワークフローによっては、ハンドオフせずに中央のエージェントが専門エージェント群をオーケストレーションしたい場合があります。その際、エージェントをツールとしてモデル化できます。
+一部のワークフローでは、ハンドオフせずに中心となるエージェントが複数の専門エージェントをオーケストレーションしたい場合があります。その際はエージェントをツールとしてモデル化します。
 
 ```python
 from agents import Agent, Runner
@@ -267,9 +267,9 @@ async def main():
     print(result.final_output)
 ```
 
-### ツール化したエージェントのカスタマイズ
+### ツールエージェントのカスタマイズ
 
-`agent.as_tool` はエージェントを簡単にツール化するための便利メソッドです。ただし、すべての設定をサポートしているわけではありません。例えば `max_turns` は設定できません。高度なユースケースでは、ツール実装内で `Runner.run` を直接使用してください。
+`agent.as_tool` はエージェントを簡単にツール化するためのユーティリティですが、すべての設定をサポートするわけではありません（例: `max_turns` の設定は不可）。高度なユースケースでは、ツール実装内で `Runner.run` を直接呼び出してください。
 
 ```python
 @function_tool
@@ -288,15 +288,15 @@ async def run_my_agent() -> str:
     return str(result.final_output)
 ```
 
-### 出力のカスタム抽出
+### 出力抽出のカスタマイズ
 
-場合によっては、中央エージェントに返す前にツール化したエージェントの出力を加工したいことがあります。例えば次のようなケースです。
+場合によっては、ツールエージェントの出力を中央エージェントに返す前に加工したいことがあります。たとえば以下のようなケースです。
 
-- サブエージェントのチャット履歴から特定の情報（例: JSON ペイロード）を抽出したい。  
-- エージェントの最終回答を別形式に変換したい（例: Markdown → プレーンテキストや CSV）。  
-- 出力を検証し、欠損・不正な場合にはフォールバック値を返したい。  
+-   サブエージェントのチャット履歴から特定情報（例: JSON ペイロード）だけを抽出する。
+-   エージェントの最終回答を変換・再フォーマットする（例: Markdown をプレーンテキストや CSV に変換）。
+-   出力を検証し、欠落や不正の場合にフォールバック値を返す。
 
-これを行うには、`as_tool` メソッドに `custom_output_extractor` 引数を渡します。
+その場合、`as_tool` メソッドに `custom_output_extractor` 引数を渡してください。
 
 ```python
 async def extract_json_payload(run_result: RunResult) -> str:
@@ -315,12 +315,12 @@ json_tool = data_agent.as_tool(
 )
 ```
 
-## Function tool 内のエラー処理
+## 関数ツールでのエラー処理
 
-`@function_tool` で Function tool を作成する際、`failure_error_function` を渡すことができます。これはツール呼び出しがクラッシュした場合に LLM へエラー応答を提供する関数です。
+`@function_tool` で関数ツールを作成する際、`failure_error_function` を渡すことができます。この関数はツール呼び出しが失敗した場合に LLM へ返すエラー応答を生成します。
 
--   何も渡さない場合は、デフォルトで `default_tool_error_function` が実行され、LLM にエラーが発生したことを伝えます。  
--   独自のエラー関数を渡した場合は、その関数が実行され、その結果が LLM に送信されます。  
--   明示的に `None` を渡した場合、ツール呼び出しのエラーは再送出されます。これには、モデルが無効な JSON を生成した場合の `ModelBehaviorError` や、コードがクラッシュした場合の `UserError` などが含まれます。  
+-   既定では `default_tool_error_function` が実行され、LLM にエラー発生を通知します。
+-   独自のエラー関数を渡した場合、その関数が実行され、その応答が LLM に送信されます。
+-   明示的に `None` を渡すと、ツール呼び出しエラーは再スローされます。モデルが無効な JSON を生成した場合は `ModelBehaviorError`、コードがクラッシュした場合は `UserError` などが発生します。
 
-`FunctionTool` オブジェクトを手動で作成する場合は、`on_invoke_tool` 関数内でエラー処理を行う必要があります。
\ No newline at end of file
+`FunctionTool` オブジェクトを手動で作成する場合は、`on_invoke_tool` 関数内でエラーを処理する必要があります。
\ No newline at end of file
diff --git a/docs/ja/tracing.md b/docs/ja/tracing.md
index b328f4899..b366b46f8 100644
--- a/docs/ja/tracing.md
+++ b/docs/ja/tracing.md
@@ -4,52 +4,52 @@ search:
 ---
 # トレーシング
 
-Agents SDK にはトレーシングが組み込まれており、エージェントの実行中に発生する LLM 生成、関数ツール呼び出し、ハンドオフ、ガードレール、さらにカスタムイベントまでを含む包括的なイベント履歴を収集します。 [Traces ダッシュボード](https://platform.openai.com/traces) を使用すると、開発中および本番環境でワークフローをデバッグ・可視化・モニタリングできます。
+Agents SDK にはビルトインのトレーシング機能が含まれており、エージェントの実行中に発生する LLM 生成、ツール呼び出し、ハンドオフ、ガードレール、さらにはカスタムイベントまでの詳細な履歴を収集します。Traces ダッシュボードを使用すると、開発時および本番環境でワークフローをデバッグ、可視化、モニタリングできます。
 
 !!!note
 
-    トレーシングはデフォルトで有効になっています。無効化する方法は 2 つあります。
+    トレーシングはデフォルトで有効になっています。無効化する方法は 2 つあります:
 
-    1. 環境変数 `OPENAI_AGENTS_DISABLE_TRACING=1` を設定して、グローバルにトレーシングを無効化する  
-    2. 単一の実行に対しては [`agents.run.RunConfig.tracing_disabled`][] を `True` に設定する
+    1. 環境変数 `OPENAI_AGENTS_DISABLE_TRACING=1` を設定してトレーシングをグローバルに無効化する  
+    2. 単一の実行に対して [`agents.run.RunConfig.tracing_disabled`][] を `True` に設定してトレーシングを無効化する  
 
-***OpenAI の API を使用し、Zero Data Retention (ZDR) ポリシーを採用している組織では、トレーシングは利用できません。***
+    ***OpenAI の API をゼロデータ保持 (ZDR) ポリシーの下で利用する組織では、トレーシングは利用できません。***
 
 ## トレースとスパン
 
--   **トレース** は 1 回のワークフロー全体のエンドツーエンド操作を表します。スパンで構成されます。トレースには次のプロパティがあります。  
-    -   `workflow_name`: 論理的なワークフローまたはアプリ名。例: 「Code generation」や「Customer service」。  
-    -   `trace_id`: トレースの一意 ID。指定しない場合は自動生成されます。形式は `trace_<32_alphanumeric>` である必要があります。  
-    -   `group_id`: 省略可能なグループ ID。同一会話からの複数トレースをリンクするために使用します。たとえばチャットスレッド ID を使用できます。  
-    -   `disabled`: `True` の場合、このトレースは記録されません。  
-    -   `metadata`: 省略可能なメタデータ。  
--   **スパン** は開始時刻と終了時刻を持つ操作を表します。スパンには次のものがあります。  
-    -   `started_at` と `ended_at` のタイムスタンプ  
-    -   属するトレースを示す `trace_id`  
-    -   親スパンを指す `parent_id` (存在する場合)  
-    -   スパンに関する情報を保持する `span_data`。たとえば `AgentSpanData` はエージェント情報、`GenerationSpanData` は LLM 生成情報などを含みます。  
+- **Traces** は 1 度のワークフロー全体を表すエンドツーエンドの操作です。複数の Span で構成されます。Trace には次のプロパティがあります:  
+    - `workflow_name`: 論理的なワークフローまたはアプリ名。例: “Code generation” や “Customer service”  
+    - `trace_id`: Trace の一意 ID。指定しない場合は自動生成されます。形式は `trace_<32_alphanumeric>`  
+    - `group_id`: 省略可。同一会話からの複数の Trace を関連付けるための ID。たとえばチャットスレッド ID など  
+    - `disabled`: `True` の場合、この Trace は記録されません  
+    - `metadata`: 省略可。Trace に付随するメタデータ  
+- **Spans** は開始時刻と終了時刻を持つ操作を表します。Span には次の情報があります:  
+    - `started_at` と `ended_at` タイムスタンプ  
+    - `trace_id`: 所属する Trace の ID  
+    - `parent_id`: 親 Span がある場合、その Span への参照  
+    - `span_data`: Span に関する情報。例: `AgentSpanData` はエージェント、`GenerationSpanData` は LLM 生成などの情報を保持  
 
 ## デフォルトのトレーシング
 
-デフォルトで SDK は以下をトレースします。
+デフォルトでは、SDK は次をトレースします:
 
--   `Runner.{run, run_sync, run_streamed}()` 全体を `trace()` でラップ  
--   エージェントが実行されるたびに `agent_span()` でラップ  
--   LLM 生成を `generation_span()` でラップ  
--   関数ツール呼び出しをそれぞれ `function_span()` でラップ  
--   ガードレールを `guardrail_span()` でラップ  
--   ハンドオフを `handoff_span()` でラップ  
--   音声入力 (speech-to-text) を `transcription_span()` でラップ  
--   音声出力 (text-to-speech) を `speech_span()` でラップ  
--   関連する音声スパンは `speech_group_span()` の下に配置される場合があります  
+- `Runner.{run, run_sync, run_streamed}()` 全体を `trace()` でラップ  
+- エージェントが実行されるたびに `agent_span()` でラップ  
+- LLM 生成を `generation_span()` でラップ  
+- 関数ツール呼び出しを `function_span()` でラップ  
+- ガードレールを `guardrail_span()` でラップ  
+- ハンドオフを `handoff_span()` でラップ  
+- 音声入力 (音声→テキスト) を `transcription_span()` でラップ  
+- 音声出力 (テキスト→音声) を `speech_span()` でラップ  
+- 関連する音声 Span は `speech_group_span()` の下にネストされる場合があります  
 
-デフォルトでは、トレース名は「Agent workflow」です。`trace` を使用してこの名前を設定するか、[`RunConfig`][agents.run.RunConfig] で名前やその他プロパティを構成できます。
+デフォルトでは Trace の名前は “Agent workflow” です。`trace` を使用してこの名前を設定するか、[`RunConfig`][agents.run.RunConfig] で名前や他のプロパティを構成できます。
 
-さらに、[カスタムトレーシングプロセッサー](#custom-tracing-processors) を設定して、トレースを他の送信先へ送ることもできます (置き換え、または追加送信)。
+さらに、[カスタムトレーシングプロセッサー](#custom-tracing-processors) を設定して、Trace を別の送信先にプッシュすることもできます (置き換えまたは追加送信先として)。
 
-## 上位レベルのトレース
+## より高レベルのトレース
 
-複数回の `run()` 呼び出しを 1 つのトレースにまとめたい場合があります。その場合は、コード全体を `trace()` でラップしてください。
+複数回の `run()` 呼び出しを 1 つの Trace にまとめたい場合は、コード全体を `trace()` でラップします。
 
 ```python
 from agents import Agent, Runner, trace
@@ -64,62 +64,60 @@ async def main():
         print(f"Rating: {second_result.final_output}")
 ```
 
-1. `Runner.run` への 2 回の呼び出しが `with trace()` でラップされているため、個別トレースは作成されず、全体で 1 つのトレースになります。
+1. 2 回の `Runner.run` 呼び出しが `with trace()` でラップされているため、それぞれが個別の Trace を作成するのではなく、全体で 1 つの Trace になります。
 
 ## トレースの作成
 
-[`trace()`][agents.tracing.trace] 関数でトレースを作成できます。トレースには開始と終了が必要で、方法は 2 つあります。
+[`trace()`][agents.tracing.trace] 関数を使って Trace を作成できます。Trace は開始と終了が必要で、次の 2 つの方法があります:
 
-1. **推奨**: `with trace(...) as my_trace` のように context manager として使用する。開始と終了が自動で行われます。  
-2. [`trace.start()`][agents.tracing.Trace.start] と [`trace.finish()`][agents.tracing.Trace.finish] を手動で呼び出す。  
+1. **推奨**: `with trace(...) as my_trace` のようにコンテキストマネージャーとして使用する。適切なタイミングで自動的に開始・終了します  
+2. [`trace.start()`][agents.tracing.Trace.start] と [`trace.finish()`][agents.tracing.Trace.finish] を手動で呼び出す  
 
-現在のトレースは Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) で管理されるため、並行処理でも自動的に機能します。トレースを手動で開始・終了する場合は、`start()`/`finish()` に `mark_as_current` と `reset_current` を渡して現在のトレースを更新する必要があります。
+現在の Trace は Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) により管理され、並行処理でも自動で機能します。Trace を手動で開始・終了する場合は、`start()`/`finish()` に `mark_as_current` および `reset_current` を渡して現在の Trace を更新してください。
 
 ## スパンの作成
 
-さまざまな [`*_span()`][agents.tracing.create] メソッドでスパンを作成できますが、通常は手動で作成する必要はありません。カスタムスパン情報を追跡するには [`custom_span()`][agents.tracing.custom_span] を利用できます。
+さまざまな [`*_span()`][agents.tracing.create] メソッドを使用して Span を作成できますが、通常は手動で作成する必要はありません。カスタム情報を記録したい場合は [`custom_span()`][agents.tracing.custom_span] を利用できます。
 
-スパンは自動的に現在のトレースに含まれ、最も近い現在のスパンの下にネストされます。これも Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) で追跡しています。
+Span は自動的に現在の Trace に属し、最も近い現在の Span の下にネストされます。これも Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) で追跡されます。
 
 ## 機密データ
 
-一部のスパンは機密データを含む可能性があります。
+一部の Span には機密データが含まれる可能性があります。
 
-`generation_span()` は LLM の入力／出力を、`function_span()` は関数呼び出しの入力／出力を保存します。これらが機密情報を含む場合は、[`RunConfig.trace_include_sensitive_data`][agents.run.RunConfig.trace_include_sensitive_data] で記録を無効化できます。
+`generation_span()` は LLM の入力／出力を、`function_span()` は関数呼び出しの入力／出力を保存します。これらに機密データが含まれる場合は、[`RunConfig.trace_include_sensitive_data`][agents.run.RunConfig.trace_include_sensitive_data] で記録を無効化できます。
 
-同様に、オーディオスパンはデフォルトで base64 エンコードされた PCM データ (入力・出力音声) を含みます。音声データの記録を無効化するには、[`VoicePipelineConfig.trace_include_sensitive_audio_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_audio_data] を設定してください。
+同様に、Audio Span にはデフォルトで base64 エンコードされた PCM データが含まれます。音声データの記録を停止したい場合は、[`VoicePipelineConfig.trace_include_sensitive_audio_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_audio_data] を設定してください。
 
 ## カスタムトレーシングプロセッサー
 
-トレーシングの高レベルアーキテクチャは次のとおりです。
+トレーシングの高レベルアーキテクチャは次のとおりです:
 
--   初期化時にグローバルな [`TraceProvider`][agents.tracing.setup.TraceProvider] を作成し、トレースの生成を担当させます。  
--   `TraceProvider` に [`BatchTraceProcessor`][agents.tracing.processors.BatchTraceProcessor] を設定し、バッチ単位でスパンとトレースを [`BackendSpanExporter`][agents.tracing.processors.BackendSpanExporter] に送信します。このエクスポーターが OpenAI バックエンドへバッチ送信します。  
+- 初期化時に、Trace を生成するグローバルな [`TraceProvider`][agents.tracing.setup.TraceProvider] を作成  
+- `TraceProvider` に [`BatchTraceProcessor`][agents.tracing.processors.BatchTraceProcessor] を設定し、Trace／Span をバッチで [`BackendSpanExporter`][agents.tracing.processors.BackendSpanExporter] へ送信。Exporter は OpenAI バックエンドへバッチ送信を行います  
 
-デフォルト設定をカスタマイズして、別のバックエンドへ送信したり、エクスポーターの動作を変更したりするには、次の 2 通りがあります。
+デフォルト設定を変更して別のバックエンドへ送信したり、Exporter の挙動を変更したりするには次の 2 通りがあります:
 
-1. [`add_trace_processor()`][agents.tracing.add_trace_processor]  
-   追加のトレースプロセッサーを登録し、トレース／スパンが準備完了した時点で受け取ります。OpenAI バックエンドへ送信しつつ独自処理を実行する場合に使用します。  
-2. [`set_trace_processors()`][agents.tracing.set_trace_processors]  
-   デフォルトのプロセッサーを **置き換え** ます。OpenAI バックエンドへトレースが送信されなくなるので、必要に応じて送信用の `TracingProcessor` を含めてください。  
+1. [`add_trace_processor()`][agents.tracing.add_trace_processor] を使用して **追加** の Trace プロセッサーを登録する。これにより、OpenAI バックエンドへの送信に加えて独自の処理を実行できます  
+2. [`set_trace_processors()`][agents.tracing.set_trace_processors] を使用してデフォルトのプロセッサーを **置き換える**。OpenAI バックエンドへ送信したい場合は、その機能を持つ `TracingProcessor` を自分で含める必要があります  
 
 ## 外部トレーシングプロセッサー一覧
 
--   [Weights & Biases](https://weave-docs.wandb.ai/guides/integrations/openai_agents)
--   [Arize-Phoenix](https://docs.arize.com/phoenix/tracing/integrations-tracing/openai-agents-sdk)
--   [Future AGI](https://docs.futureagi.com/future-agi/products/observability/auto-instrumentation/openai_agents)
--   [MLflow (self-hosted/OSS](https://mlflow.org/docs/latest/tracing/integrations/openai-agent)
--   [MLflow (Databricks hosted](https://docs.databricks.com/aws/en/mlflow/mlflow-tracing#-automatic-tracing)
--   [Braintrust](https://braintrust.dev/docs/guides/traces/integrations#openai-agents-sdk)
--   [Pydantic Logfire](https://logfire.pydantic.dev/docs/integrations/llms/openai/#openai-agents)
--   [AgentOps](https://docs.agentops.ai/v1/integrations/agentssdk)
--   [Scorecard](https://docs.scorecard.io/docs/documentation/features/tracing#openai-agents-sdk-integration)
--   [Keywords AI](https://docs.keywordsai.co/integration/development-frameworks/openai-agent)
--   [LangSmith](https://docs.smith.langchain.com/observability/how_to_guides/trace_with_openai_agents_sdk)
--   [Maxim AI](https://www.getmaxim.ai/docs/observe/integrations/openai-agents-sdk)
--   [Comet Opik](https://www.comet.com/docs/opik/tracing/integrations/openai_agents)
--   [Langfuse](https://langfuse.com/docs/integrations/openaiagentssdk/openai-agents)
--   [Langtrace](https://docs.langtrace.ai/supported-integrations/llm-frameworks/openai-agents-sdk)
--   [Okahu-Monocle](https://github.com/monocle2ai/monocle)
--   [Galileo](https://v2docs.galileo.ai/integrations/openai-agent-integration#openai-agent-integration)
--   [Portkey AI](https://portkey.ai/docs/integrations/agents/openai-agents)
\ No newline at end of file
+- [Weights & Biases](https://weave-docs.wandb.ai/guides/integrations/openai_agents)
+- [Arize-Phoenix](https://docs.arize.com/phoenix/tracing/integrations-tracing/openai-agents-sdk)
+- [Future AGI](https://docs.futureagi.com/future-agi/products/observability/auto-instrumentation/openai_agents)
+- [MLflow (self-hosted/OSS](https://mlflow.org/docs/latest/tracing/integrations/openai-agent)
+- [MLflow (Databricks hosted](https://docs.databricks.com/aws/en/mlflow/mlflow-tracing#-automatic-tracing)
+- [Braintrust](https://braintrust.dev/docs/guides/traces/integrations#openai-agents-sdk)
+- [Pydantic Logfire](https://logfire.pydantic.dev/docs/integrations/llms/openai/#openai-agents)
+- [AgentOps](https://docs.agentops.ai/v1/integrations/agentssdk)
+- [Scorecard](https://docs.scorecard.io/docs/documentation/features/tracing#openai-agents-sdk-integration)
+- [Keywords AI](https://docs.keywordsai.co/integration/development-frameworks/openai-agent)
+- [LangSmith](https://docs.smith.langchain.com/observability/how_to_guides/trace_with_openai_agents_sdk)
+- [Maxim AI](https://www.getmaxim.ai/docs/observe/integrations/openai-agents-sdk)
+- [Comet Opik](https://www.comet.com/docs/opik/tracing/integrations/openai_agents)
+- [Langfuse](https://langfuse.com/docs/integrations/openaiagentssdk/openai-agents)
+- [Langtrace](https://docs.langtrace.ai/supported-integrations/llm-frameworks/openai-agents-sdk)
+- [Okahu-Monocle](https://github.com/monocle2ai/monocle)
+- [Galileo](https://v2docs.galileo.ai/integrations/openai-agent-integration#openai-agent-integration)
+- [Portkey AI](https://portkey.ai/docs/integrations/agents/openai-agents)
\ No newline at end of file
diff --git a/docs/ja/visualization.md b/docs/ja/visualization.md
index 4b6311e9d..a0919cebe 100644
--- a/docs/ja/visualization.md
+++ b/docs/ja/visualization.md
@@ -4,11 +4,11 @@ search:
 ---
 # エージェント可視化
 
-エージェント可視化を使用すると、 **Graphviz** を用いてエージェントとその関係を構造的なグラフィカル表現として生成できます。これにより、アプリケーション内でエージェント、ツール、ハンドオフがどのように相互作用するかを理解しやすくなります。
+エージェント可視化を使用すると、 **Graphviz** を用いてエージェントとその関係を構造化されたグラフィカル表現として生成できます。これは、アプリケーション内でエージェント、ツール、ハンドオフがどのように相互作用するかを理解するのに役立ちます。
 
 ## インストール
 
-オプションの `viz` 依存グループをインストールします:
+オプションの `viz` 依存関係グループをインストールします:
 
 ```bash
 pip install "openai-agents[viz]"
@@ -16,11 +16,11 @@ pip install "openai-agents[viz]"
 
 ## グラフの生成
 
-`draw_graph` 関数を使用してエージェントの可視化を生成できます。この関数は次のような有向グラフを作成します:
+`draw_graph` 関数を使ってエージェントの可視化を生成できます。この関数は有向グラフを作成し、次のように表現します:
 
-- エージェントは黄色のボックスで表されます。  
-- ツールは緑色の楕円で表されます。  
-- ハンドオフはエージェント間の有向エッジとして表されます。
+- **エージェント** は黄色のボックスで表されます。
+- **ツール** は緑色の楕円で表されます。
+- **ハンドオフ** は一方のエージェントから別のエージェントへの有向エッジとして表されます。
 
 ### 使用例
 
@@ -54,31 +54,32 @@ draw_graph(triage_agent)
 
 ![Agent Graph](../assets/images/graph.png)
 
-これにより、 **triage agent** の構造とサブエージェントおよびツールへの接続を視覚的に示すグラフが生成されます。
+これにより、 **triage エージェント** とそのサブエージェントおよびツールへの接続を視覚的に表すグラフが生成されます。
+
 
 ## 可視化の理解
 
 生成されたグラフには次の要素が含まれます:
 
-- エントリーポイントを示す **start node** ( `__start__` )。  
-- エージェントは黄色で塗りつぶされた長方形として表示されます。  
-- ツールは緑色で塗りつぶされた楕円として表示されます。  
-- 相互作用を示す有向エッジ:  
-  - **Solid arrows** はエージェント間のハンドオフを示します。  
-  - **Dotted arrows** はツール呼び出しを示します。  
-- 実行が終了する位置を示す **end node** ( `__end__` )。
+- エントリーポイントを示す **start ノード** (`__start__`)  
+- 黄色の塗りつぶしの **長方形** で表されたエージェント  
+- 緑色の塗りつぶしの **楕円** で表されたツール  
+- 相互作用を示す有向エッジ  
+  - エージェント間のハンドオフには **実線の矢印**  
+  - ツール呼び出しには **点線の矢印**  
+- 実行終了地点を示す **end ノード** (`__end__`)
 
 ## グラフのカスタマイズ
 
 ### グラフの表示
-デフォルトでは、 `draw_graph` はグラフをインラインで表示します。別ウィンドウで表示するには、次のようにします:
+デフォルトでは、`draw_graph` はインラインでグラフを表示します。別ウィンドウで表示するには、次のようにします:
 
 ```python
 draw_graph(triage_agent).view()
 ```
 
 ### グラフの保存
-デフォルトでは、 `draw_graph` はグラフをインラインで表示します。ファイルとして保存するには、ファイル名を指定します:
+デフォルトでは、`draw_graph` はインラインでグラフを表示します。ファイルとして保存するには、ファイル名を指定します:
 
 ```python
 draw_graph(triage_agent, filename="agent_graph")
diff --git a/docs/ja/voice/pipeline.md b/docs/ja/voice/pipeline.md
index 99c7ce065..3db986993 100644
--- a/docs/ja/voice/pipeline.md
+++ b/docs/ja/voice/pipeline.md
@@ -4,7 +4,7 @@ search:
 ---
 # パイプラインとワークフロー
 
-[`VoicePipeline`][agents.voice.pipeline.VoicePipeline] は、エージェント型ワークフローを音声アプリへ簡単に変換できるクラスです。実行したいワークフローを渡すだけで、入力音声の書き起こし、音声終了の検出、適切なタイミングでのワークフロー呼び出し、そしてワークフロー出力を再び音声へ変換する処理をパイプラインが自動で行います。
+[`VoicePipeline`][agents.voice.pipeline.VoicePipeline] は、エージェントワークフローを音声アプリに簡単に変換できるクラスです。ワークフローを渡すだけで、音声入力の文字起こし、音声終了の検出、適切なタイミングでのワークフロー呼び出し、そしてワークフロー出力を音声へ戻す処理を自動で行います。
 
 ```mermaid
 graph LR
@@ -34,34 +34,29 @@ graph LR
 
 ## パイプラインの設定
 
-パイプラインを作成する際に設定できる項目は次のとおりです。
+パイプラインを作成する際に次の項目を設定できます。
 
-1. [`workflow`][agents.voice.workflow.VoiceWorkflowBase]  
-   新しい音声が書き起こされるたびに実行されるコードです。  
-2. [`speech-to-text`][agents.voice.model.STTModel] と [`text-to-speech`][agents.voice.model.TTSModel]  
-   使用する STT／TTS モデルです。  
-3. [`config`][agents.voice.pipeline_config.VoicePipelineConfig]  
-   以下のような設定を行えます。  
-    - モデルプロバイダー : モデル名をモデルにマッピングします  
-    - トレーシング : トレーシングの有効／無効、音声ファイルのアップロード可否、ワークフロー名、トレース ID など  
-    - TTS と STT モデルの設定 : プロンプト、言語、使用するデータ型 など  
+1. [`workflow`][agents.voice.workflow.VoiceWorkflowBase] — 新しい音声が文字起こしされるたびに実行されるコード  
+2. 使用する [`speech-to-text`][agents.voice.model.STTModel] と [`text-to-speech`][agents.voice.model.TTSModel] モデル  
+3. [`config`][agents.voice.pipeline_config.VoicePipelineConfig] — 以下のような内容を設定できます  
+    - モデルプロバイダー：モデル名をモデルにマッピング  
+    - トレーシング：トレーシングの有効 / 無効、音声ファイルのアップロード可否、ワークフロー名、トレース ID など  
+    - TTS および STT モデルの設定：プロンプト、言語、使用するデータ型 など
 
 ## パイプラインの実行
 
-[`run()`][agents.voice.pipeline.VoicePipeline.run] メソッドでパイプラインを実行できます。音声入力は 2 つの形式で渡せます。
+パイプラインは [`run()`][agents.voice.pipeline.VoicePipeline.run] メソッドで実行できます。音声入力は次の 2 つの形式で渡せます。
 
-1. [`AudioInput`][agents.voice.input.AudioInput]  
-   完全な音声トランスクリプトがある場合に使用し、その内容に対する結果だけを生成します。発話終了検出が不要な、事前録音音声やプッシュトゥトーク アプリなどで便利です。  
-2. [`StreamedAudioInput`][agents.voice.input.StreamedAudioInput]  
-   発話終了を検出する必要がある場合に使用します。検出された音声チャンクを順次プッシュでき、パイプラインが「アクティビティ検出」と呼ばれるプロセスを通じて適切なタイミングでエージェント ワークフローを自動実行します。  
+1. [`AudioInput`][agents.voice.input.AudioInput] — 完全な音声トランスクリプトがある場合に使用し、その内容に対して結果を生成します。発話が終了したタイミングを検出する必要がないケース（例：事前収録音声や push-to-talk アプリでユーザーが話し終えるタイミングが明確な場合）で便利です。  
+2. [`StreamedAudioInput`][agents.voice.input.StreamedAudioInput] — ユーザーの発話終了を検出する必要がある場合に使用します。検出された音声チャンクをプッシュでき、 VoicePipeline がアクティビティ検出と呼ばれるプロセスを介して適切なタイミングでエージェントワークフローを自動実行します。
 
-## 実行結果
+## 結果
 
-音声パイプライン実行の結果は [`StreamedAudioResult`][agents.voice.result.StreamedAudioResult] です。これは、発生するイベントをストリーミングできるオブジェクトで、いくつかの [`VoiceStreamEvent`][agents.voice.events.VoiceStreamEvent] を含みます。
+VoicePipeline 実行結果は [`StreamedAudioResult`][agents.voice.result.StreamedAudioResult] です。このオブジェクトでは、発生するイベントをストリームで受け取れます。以下のような複数種類の [`VoiceStreamEvent`][agents.voice.events.VoiceStreamEvent] があります。
 
-1. [`VoiceStreamEventAudio`][agents.voice.events.VoiceStreamEventAudio] : 音声チャンクを含みます。  
-2. [`VoiceStreamEventLifecycle`][agents.voice.events.VoiceStreamEventLifecycle] : ターンの開始／終了などライフサイクルイベントを通知します。  
-3. [`VoiceStreamEventError`][agents.voice.events.VoiceStreamEventError] : エラーイベントです。  
+1. [`VoiceStreamEventAudio`][agents.voice.events.VoiceStreamEventAudio] — 音声チャンクを含みます。  
+2. [`VoiceStreamEventLifecycle`][agents.voice.events.VoiceStreamEventLifecycle] — ターンの開始・終了などライフサイクルイベントを通知します。  
+3. [`VoiceStreamEventError`][agents.voice.events.VoiceStreamEventError] — エラーイベントです。
 
 ```python
 
@@ -81,5 +76,4 @@ async for event in result.stream():
 
 ### 割り込み
 
-Agents SDK には [`StreamedAudioInput`][agents.voice.input.StreamedAudioInput] 用のビルトイン割り込みサポートは現在ありません。そのため、検出された各ターンごとにワークフローが個別に実行されます。アプリケーション内で割り込みを扱いたい場合は、[`VoiceStreamEventLifecycle`][agents.voice.events.VoiceStreamEventLifecycle] を監視してください。  
-`turn_started` は新しいターンが書き起こされ処理が始まったことを示し、`turn_ended` は該当ターンの音声がすべて送信された後に発火します。これらのイベントを用いて、モデルがターンを開始した際に話者のマイクをミュートし、ターンに関連する音声をすべて送信し終えた後でアンミュートする、といった実装が可能です。
\ No newline at end of file
+Agents SDK は現在 [`StreamedAudioInput`][agents.voice.input.StreamedAudioInput] に対して組み込みの割り込み処理をサポートしていません。検出された各ターンごとにワークフローの個別実行がトリガーされます。アプリケーション内で割り込みを扱いたい場合は [`VoiceStreamEventLifecycle`][agents.voice.events.VoiceStreamEventLifecycle] イベントを監視してください。`turn_started` は新しいターンが文字起こしされ処理が開始されたことを示します。`turn_ended` は該当ターンのすべての音声がディスパッチされた後に発火します。これらのイベントを使い、モデルがターンを開始した際にスピーカーのマイクをミュートし、そのターンに関連する音声をすべて出力し終えたあとでアンミュートする、といった制御が可能です。
\ No newline at end of file
diff --git a/docs/ja/voice/quickstart.md b/docs/ja/voice/quickstart.md
index 50509896e..db0af808d 100644
--- a/docs/ja/voice/quickstart.md
+++ b/docs/ja/voice/quickstart.md
@@ -4,21 +4,21 @@ search:
 ---
 # クイックスタート
 
-## 必要条件
+## 前提条件
 
-まず、 base [クイックスタート手順](../quickstart.md) に従って  Agents SDK をセットアップし、仮想環境を作成してください。次に、 SDK からオプションの音声依存関係をインストールします:
+まず、 [クイックスタート手順](../quickstart.md) に従い、 Agents SDK の基本設定を行って仮想環境を構築してください。そのうえで、 SDK から音声関連のオプション依存関係をインストールします。
 
 ```bash
 pip install 'openai-agents[voice]'
 ```
 
-## コンセプト
+## 概念
 
-知っておくべき主な概念は [`VoicePipeline`][agents.voice.pipeline.VoicePipeline] で、これは 3 つのステップで構成されます:
+ここで理解すべき主な概念は `VoicePipeline` で、 3 ステップのプロセスです:
 
-1. 音声をテキストに変換する speech-to-text モデルを実行する  
-2. 通常はエージェント的なワークフローであるあなたのコードを実行して、実行結果を生成する  
-3. 生成されたテキストを音声に戻す text-to-speech モデルを実行する  
+1. 音声をテキストに変換するために音声認識モデルを実行します。  
+2. 通常はエージェント的なワークフローとなるあなたのコードを実行し、結果を生成します。  
+3. 結果のテキストを再び音声に変換するために音声合成 (text-to-speech) モデルを実行します。  
 
 ```mermaid
 graph LR
@@ -48,7 +48,7 @@ graph LR
 
 ## エージェント
 
-まずはエージェントをいくつか設定します。すでにこの SDK でエージェントを作ったことがある場合は、見覚えのある内容でしょう。ここでは 2 つのエージェント、1 つのハンドオフ、そして 1 つのツールを用意します。
+まず、いくつかのエージェントをセットアップしましょう。この SDK でエージェントを構築したことがあれば、見覚えがあるはずです。ここでは 2 つのエージェント、 1 つのハンドオフ、そして 1 つのツールを用意します。
 
 ```python
 import asyncio
@@ -92,7 +92,7 @@ agent = Agent(
 
 ## 音声パイプライン
 
-ワークフローとして [`SingleAgentVoiceWorkflow`][agents.voice.workflow.SingleAgentVoiceWorkflow] を使用し、シンプルな音声パイプラインを構築します。
+`SingleAgentVoiceWorkflow` をワークフローとして使用し、シンプルな音声パイプラインを構築します。
 
 ```python
 from agents.voice import SingleAgentVoiceWorkflow, VoicePipeline
@@ -195,4 +195,4 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-この例を実行すると、エージェントがあなたに話しかけてきます。自分でエージェントと会話できるデモについては、[examples/voice/static](https://github.com/openai/openai-agents-python/tree/main/examples/voice/static) のコード例をご覧ください。
\ No newline at end of file
+このコード例を実行すると、エージェントがあなたに話しかけてきます！自分でエージェントと対話できるデモを確認したい場合は、[examples/voice/static](https://github.com/openai/openai-agents-python/tree/main/examples/voice/static) にあるサンプルコードを参照してください。
\ No newline at end of file
diff --git a/docs/ja/voice/tracing.md b/docs/ja/voice/tracing.md
index 19dcdc537..2dd4c687c 100644
--- a/docs/ja/voice/tracing.md
+++ b/docs/ja/voice/tracing.md
@@ -4,15 +4,15 @@ search:
 ---
 # トレーシング
 
-[エージェントがトレーシングされる方法](../tracing.md) と同様に、音声パイプラインも自動的にトレーシングされます。
+[エージェント](../tracing.md) と同様に、 voice パイプラインも自動でトレーシングされます。
 
-基本的なトレーシング情報については上記のドキュメントをご覧ください。また、パイプラインのトレーシングは [`VoicePipelineConfig`][agents.voice.pipeline_config.VoicePipelineConfig] を通じて追加設定できます。
+基本的なトレーシングの情報については上記のドキュメントを参照してください。さらに、 `VoicePipelineConfig` を使用してパイプラインのトレーシングを設定できます。
 
-トレーシングに関連する主なフィールドは次のとおりです:
+トレーシングに関する主なフィールドは次のとおりです。
 
--   [`tracing_disabled`][agents.voice.pipeline_config.VoicePipelineConfig.tracing_disabled]: トレーシングを無効にするかどうかを制御します。デフォルトではトレーシングは有効です。  
--   [`trace_include_sensitive_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_data]: トレースに音声の書き起こしなどの機微情報を含めるかどうかを制御します。これは音声パイプラインに特有で、 Workflow 内で行われる処理には影響しません。  
--   [`trace_include_sensitive_audio_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_audio_data]: トレースに音声データを含めるかどうかを制御します。  
--   [`workflow_name`][agents.voice.pipeline_config.VoicePipelineConfig.workflow_name]: トレース Workflow の名前です。  
--   [`group_id`][agents.voice.pipeline_config.VoicePipelineConfig.group_id]: 複数のトレースを関連付けるための `group_id` です。  
--   [`trace_metadata`][agents.voice.pipeline_config.VoicePipelineConfig.tracing_disabled]: トレースに含める追加のメタデータです。
\ No newline at end of file
+-   [`tracing_disabled`][agents.voice.pipeline_config.VoicePipelineConfig.tracing_disabled]：トレーシングを無効にするかどうかを制御します。デフォルトではトレーシングは有効です。  
+-   [`trace_include_sensitive_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_data]：音声の文字起こしなど、機微なデータをトレースに含めるかどうかを制御します。これは voice パイプライン専用であり、Workflow 内部の処理には影響しません。  
+-   [`trace_include_sensitive_audio_data`][agents.voice.pipeline_config.VoicePipelineConfig.trace_include_sensitive_audio_data]：音声データ自体をトレースに含めるかどうかを制御します。  
+-   [`workflow_name`][agents.voice.pipeline_config.VoicePipelineConfig.workflow_name]：トレースの Workflow 名です。  
+-   [`group_id`][agents.voice.pipeline_config.VoicePipelineConfig.group_id]：複数のトレースをリンクするための `group_id` です。  
+-   [`trace_metadata`][agents.voice.pipeline_config.VoicePipelineConfig.tracing_disabled]：トレースに追加するメタデータです。
\ No newline at end of file