diff --git a/docs/ja/agents.md b/docs/ja/agents.md
index 86c962451..4298b44ef 100644
--- a/docs/ja/agents.md
+++ b/docs/ja/agents.md
@@ -4,16 +4,16 @@ search:
 ---
 # エージェント
 
-エージェントはアプリのコアとなる構成要素です。エージェントは instructions とツールで設定された大規模言語モデル（LLM）です。
+エージェントはアプリのコアとなる構成要素です。エージェントとは、 instructions と tools で設定された大規模言語モデル ( LLM ) です。
 
 ## 基本設定
 
-エージェントで最も一般的に設定するプロパティは次のとおりです。
+最も一般的に設定するプロパティは次のとおりです。
 
-- `name`: エージェントを識別する必須の文字列。  
-- `instructions`: developer メッセージまたは system prompt とも呼ばれます。  
-- `model`: 使用する LLM、および temperature や top_p などのモデルチューニングパラメーターを設定する任意の `model_settings`。  
-- `tools`: エージェントがタスクを達成するために使用できるツール。  
+- `name`: エージェントを識別する必須の文字列です。  
+- `instructions`: developer message または system prompt とも呼ばれます。  
+- `model`: 使用する LLM と、 temperature や top_p などのモデル調整パラメーターを指定できる `model_settings` ( 任意 )。  
+- `tools`: エージェントがタスクを達成するために使用できる tools です。
 
 ```python
 from agents import Agent, ModelSettings, function_tool
@@ -33,7 +33,7 @@ agent = Agent(
 
 ## コンテキスト
 
-エージェントは `context` 型に対してジェネリックです。コンテキストは依存性インジェクション用のツールで、`Runner.run()` に渡すオブジェクトです。これがすべてのエージェント、ツール、ハンドオフなどに渡され、実行時の依存関係や状態をまとめて保持します。任意の Python オブジェクトをコンテキストとして渡すことができます。
+エージェントは `context` の型がジェネリックです。 context は依存性注入のためのツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、 tool、 handoff などに渡され、依存関係や実行時の状態をまとめて保持します。 context には任意の Python オブジェクトを渡せます。
 
 ```python
 @dataclass
@@ -52,7 +52,7 @@ agent = Agent[UserContext](
 
 ## 出力タイプ
 
-デフォルトでは、エージェントはプレーンテキスト（つまり `str`）を出力します。特定の型で出力させたい場合は、`output_type` パラメーターを使用します。よく使われるのは [Pydantic](https://docs.pydantic.dev/) オブジェクトですが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型—dataclasses、list、TypedDict など—であれば何でもサポートされています。
+デフォルトでは、エージェントはプレーンテキスト ( つまり `str` ) を出力します。特定の型で出力させたい場合は `output_type` パラメーターを使用します。一般的には [Pydantic](https://docs.pydantic.dev/) オブジェクトを使いますが、 dataclass や list、 TypedDict など、 Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる型なら何でも対応しています。
 
 ```python
 from pydantic import BaseModel
@@ -73,11 +73,11 @@ agent = Agent(
 
 !!! note
 
-    `output_type` を渡すと、モデルは通常のプレーンテキスト応答ではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用するよう指示されます。
+    `output_type` を渡すと、モデルは通常のプレーンテキストではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を利用して応答します。
 
 ## ハンドオフ
 
-ハンドオフは、エージェントが委任できるサブエージェントです。ハンドオフのリストを渡しておくと、エージェントは適切な場合にそれらへ委任できます。これは、単一タスクに特化したモジュール式エージェントをオーケストレーションする強力なパターンです。詳細は [ハンドオフ](handoffs.md) のドキュメントを参照してください。
+ハンドオフは、エージェントが委任できるサブエージェントです。 handoffs のリストを渡すと、エージェントは必要に応じてそれらに委任できます。これは、単一タスクに特化したモジュール化されたエージェントを編成する強力なパターンです。詳細は [ハンドオフ](handoffs.md) ドキュメントをご覧ください。
 
 ```python
 from agents import Agent
@@ -96,9 +96,9 @@ triage_agent = Agent(
 )
 ```
 
-## 動的 instructions
+## 動的インストラクション
 
-多くの場合、エージェント作成時に instructions を指定しますが、関数を介して動的に instructions を提供することもできます。その関数はエージェントとコンテキストを受け取り、プロンプトを返さなければなりません。同期関数・`async` 関数のどちらも使用できます。
+多くの場合、エージェント作成時に instructions を渡しますが、関数を介して動的に instructions を生成することもできます。この関数は agent と context を受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方に対応しています。
 
 ```python
 def dynamic_instructions(
@@ -113,17 +113,17 @@ 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,14 +138,14 @@ robot_agent = pirate_agent.clone(
 )
 ```
 
-## ツール使用の強制
+## ツール利用の強制
 
-ツールのリストを指定しても、LLM が必ずしもツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定することでツール使用を強制できます。有効な値は次のとおりです。
+tools のリストを渡しても、 LLM が必ずしも tool を利用するとは限りません。 [`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定してツール利用を強制できます。使用可能な値は次のとおりです。
 
-1. `auto`: LLM がツールを使うかどうかを判断します。  
-2. `required`: LLM にツール使用を必須とします（使用するツールは自動選択されます）。  
-3. `none`: LLM にツールを使用しないことを要求します。  
-4. 具体的な文字列（例: `my_tool`）を設定すると、その特定のツールの使用を要求します。  
+1. `auto` : LLM が tool を使うかどうかを決定します。  
+2. `required` : LLM に tool の使用を必須にします ( どの tool を使うかは自動で判断 )。  
+3. `none` : LLM に tool を _使わない_ ことを要求します。  
+4. 具体的な文字列 ( 例: `my_tool` ) を指定すると、その特定の tool の使用を要求します。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -163,11 +163,11 @@ agent = Agent(
 )
 ```
 
-## ツール使用動作
+## ツール利用の挙動
 
-`Agent` の `tool_use_behavior` パラメーターはツール出力の扱いを制御します。  
-- `"run_llm_again"`: デフォルト。ツールを実行した後、LLM が結果を処理して最終応答を生成します。  
-- `"stop_on_first_tool"`: 最初のツール呼び出しの出力を最終応答として使用し、LLM による追加処理を行いません。  
+`Agent` の `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。  
+- `"run_llm_again"` : 既定値。 tool を実行し、その結果を LLM が処理して最終応答を生成します。  
+- `"stop_on_first_tool"` : 最初の tool 呼び出しの出力を最終応答として使用し、追加の LLM 処理は行いません。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -185,7 +185,7 @@ agent = Agent(
 )
 ```
 
-- `StopAtTools(stop_at_tool_names=[...])`: 指定したツールのいずれかが呼び出された時点で停止し、その出力を最終応答として使用します。  
+- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかの tool が呼び出された時点で停止し、その出力を最終応答として使用します。  
 ```python
 from agents import Agent, Runner, function_tool
 from agents.agent import StopAtTools
@@ -207,7 +207,7 @@ agent = Agent(
     tool_use_behavior=StopAtTools(stop_at_tool_names=["get_weather"])
 )
 ```
-- `ToolsToFinalOutputFunction`: ツールの結果を処理し、停止するか LLM を継続するかを判断するカスタム関数です。  
+- `ToolsToFinalOutputFunction`: tool の結果を処理し、 LLM を続行するか停止するかを判断するカスタム関数です。
 
 ```python
 from agents import Agent, Runner, function_tool, FunctionToolResult, RunContextWrapper
@@ -245,4 +245,4 @@ agent = Agent(
 
 !!! note
 
-    無限ループを防ぐため、フレームワークはツール呼び出し後に自動で `tool_choice` を "auto" にリセットします。この動作は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。ツール結果が LLM に送られ、`tool_choice` により再度ツール呼び出しが生成される…というループを防ぐためです。
\ No newline at end of file
+    無限ループを防ぐため、フレームワークは tool 呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この動作は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定可能です。ツール結果が LLM に送られ、その後 `tool_choice` により再度ツール呼び出しが生成されることで無限ループが発生するためです。
\ No newline at end of file
diff --git a/docs/ja/config.md b/docs/ja/config.md
index 36969a7f6..080f6b859 100644
--- a/docs/ja/config.md
+++ b/docs/ja/config.md
@@ -6,7 +6,7 @@ search:
 
 ## API キーとクライアント
 
-デフォルトでは、 SDK はインポートされるとすぐに 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` インスタンスを作成し、環境変数または前述のデフォルトキーに設定された API キーを使用します。これを変更するには、[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 を使用します。[set_default_openai_api()][agents.set_default_openai_api] 関数を使用して Chat Completions 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 キー（環境変数または設定したデフォルトキー）が使用されます。[`set_tracing_export_api_key`][agents.set_tracing_export_api_key] 関数を使用して、トレーシングに使用される API キーを個別に設定できます。
+トレーシングはデフォルトで有効になっています。デフォルトでは前述の 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
@@ -50,11 +50,11 @@ from agents import set_tracing_disabled
 set_tracing_disabled(True)
 ```
 
-## デバッグログ
+## デバッグ ログ
 
-SDK にはハンドラーが設定されていない Python ロガーが 2 つあります。そのため、デフォルトでは警告とエラーは `stdout` に送られますが、それ以外のログは抑制されます。
+SDK にはハンドラーが設定されていない Python ロガーが 2 つあります。デフォルトでは、警告とエラーは `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 ロギングガイド](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 a64cdcc42..a8c737a90 100644
--- a/docs/ja/context.md
+++ b/docs/ja/context.md
@@ -4,30 +4,30 @@ search:
 ---
 # コンテキスト管理
 
-コンテキストという言葉には複数の意味があります。ここでは主に 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 やその他ユーザー情報）
--   依存関係（例: ロガーオブジェクト、データフェッチャーなど）
--   ヘルパー関数
+-   実行に関連するデータ（例: username/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 が参照できるデータは **会話履歴だけ** です。そのため、新しいデータを LLM が利用できるようにするには、履歴に追加する形で渡す必要があります。主な方法は次のとおりです。
 
-1. エージェントの `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
+1. Agent の `instructions` に追加する。これは「system prompt」や「developer message」とも呼ばれます。システム プロンプトは静的な文字列でも、コンテキストを受け取って文字列を返す動的関数でも構いません。常に有用な情報（例: ユーザー名や現在の日付）を渡す際によく用いられます。  
+2. `Runner.run` を呼び出す際の `input` に追加する。`instructions` と似ていますが、[chain of command](https://cdn.openai.com/spec/model-spec-2024-05-08.html#follow-the-chain-of-command) の下位にメッセージを配置できる点が異なります。  
+3. 関数ツール経由で公開する。これはオンデマンド コンテキストに適しており、LLM が必要に応じてツールを呼び出してデータを取得できます。  
+4. Retrieval や Web 検索を使う。これらはファイルやデータベース（retrieval）あるいは Web（Web 検索）から関連データを取得できる特別なツールです。応答を適切なコンテキスト データに基づいて「グラウンディング」する際に有効です。
\ No newline at end of file
diff --git a/docs/ja/examples.md b/docs/ja/examples.md
index cbccb7519..40d13e67f 100644
--- a/docs/ja/examples.md
+++ b/docs/ja/examples.md
@@ -2,47 +2,44 @@
 search:
   exclude: true
 ---
-# サンプルコード
+# コード例
 
-さまざまな実装例は、[repo](https://github.com/openai/openai-agents-python/tree/main/examples) の examples セクションでご覧いただけます。これらのサンプルコードは、異なるパターンや機能を示すいくつかのカテゴリーに整理されています。
+[repo](https://github.com/openai/openai-agents-python/tree/main/examples) の examples セクションには、SDK のさまざまなサンプル実装が用意されています。これらのコード例は、異なるパターンや機能を示す複数のカテゴリーに整理されています。
 
 
 ## カテゴリー
 
 - **[agent_patterns](https://github.com/openai/openai-agents-python/tree/main/examples/agent_patterns):**  
-  このカテゴリーでは、代表的なエージェント設計パターンを示しています。
-
+  このカテゴリーのコード例では、一般的なエージェント設計パターンを紹介しています。  
     - 決定論的ワークフロー  
-    - エージェントをツールとして扱うパターン  
+    - ツールとしてのエージェント  
     - エージェントの並列実行  
 
 - **[basic](https://github.com/openai/openai-agents-python/tree/main/examples/basic):**  
-  ここでは、 SDK の基礎的な機能を紹介しています。
-
+  SDK の基礎的な機能を示すコード例です。  
     - 動的な system prompt  
     - ストリーミング出力  
     - ライフサイクルイベント  
 
 - **[tool examples](https://github.com/openai/openai-agents-python/tree/main/examples/tools):**  
-  Web 検索やファイル検索といった OpenAI がホストするツールを実装し、エージェントに統合する方法を学べます。
+  Web 検索やファイル検索といった OpenAI がホストするツールの実装方法と、それらをエージェントに統合する方法を学べます。
 
 - **[model providers](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers):**  
-  OpenAI 以外のモデルを SDK で利用する方法を確認できます。
+  OpenAI 以外のモデルを SDK で利用する方法を探究できます。
 
 - **[handoffs](https://github.com/openai/openai-agents-python/tree/main/examples/handoffs):**  
-  エージェントのハンドオフを実践的に示すサンプルです。
+  エージェントのハンドオフを実践的に示すコード例です。
 
 - **[mcp](https://github.com/openai/openai-agents-python/tree/main/examples/mcp):**  
-  MCP でエージェントを構築する方法を学びます。
+  MCP でエージェントを構築する方法を学べます。
 
 - **[customer_service](https://github.com/openai/openai-agents-python/tree/main/examples/customer_service)** と **[research_bot](https://github.com/openai/openai-agents-python/tree/main/examples/research_bot):**  
-  実用的なアプリケーションを示す、より完成度の高い 2 つの例です。
-
-    - **customer_service**: 航空会社向けカスタマーサービスシステムの例  
-    - **research_bot**: シンプルなディープリサーチ クローン  
+  実際のユースケースを想定した、より発展的な 2 つのコード例です。  
+    - **customer_service**: 航空会社向けカスタマーサービスシステムの例。  
+    - **research_bot**: シンプルなディープリサーチクローン。  
 
 - **[voice](https://github.com/openai/openai-agents-python/tree/main/examples/voice):**  
-  TTS と STT モデルを用いた音声エージェントの例をご覧いただけます。
+  TTS と STT モデルを用いた音声エージェントのコード例です。
 
 - **[realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime):**  
-  SDK を使ってリアルタイム体験を構築する方法を示す例です。
\ No newline at end of file
+  SDK を使用してリアルタイム体験を構築する方法を示すコード例です。
\ No newline at end of file
diff --git a/docs/ja/guardrails.md b/docs/ja/guardrails.md
index 1339652c1..9df22dd9e 100644
--- a/docs/ja/guardrails.md
+++ b/docs/ja/guardrails.md
@@ -4,44 +4,47 @@ search:
 ---
 # ガードレール
 
-ガードレールは _並行して_ エージェントと動作し、ユーザー入力のチェックとバリデーションを行えます。たとえば、非常に賢い（ゆえに遅く/高価な）モデルを用いて顧客対応を行うエージェントがあるとします。不正なユーザーがそのモデルに数学の宿題を解かせようとするのは避けたいでしょう。そこで、低コストで高速なモデルを使ったガードレールを実行できます。ガードレールが悪意ある利用を検出した場合、ただちにエラーを発生させて高価なモデルの実行を中止し、時間とコストを節約できます。
+ガードレールはエージェントと _並列で_ 実行され、ユーザー入力のチェックとバリデーションを行えます。たとえば、顧客からのリクエストを支援するために、とても賢い（そのぶん遅く／高価な）モデルを利用するエージェントがあるとします。このとき、悪意のあるユーザーがそのモデルに数学の宿題を手伝わせようとするのは避けたいでしょう。そこで、高速かつ低コストのモデルでガードレールを実行できます。ガードレールが悪意のある利用を検知すると、ただちにエラーを送出して高価なモデルの実行を停止し、時間とコストを節約できます。
 
-ガードレールには 2 種類あります：
+ガードレールには 2 種類あります:
 
-1. 入力ガードレールは初回のユーザー入力に対して実行されます  
-2. 出力ガードレールは最終的なエージェントの出力に対して実行されます  
+1. Input guardrails は最初のユーザー入力に対して実行されます  
+2. Output guardrails は最終的なエージェント出力に対して実行されます
 
-## 入力ガードレール
+## Input guardrails
 
-入力ガードレールは次の 3 ステップで実行されます：
+Input guardrails は 3 つのステップで動作します:
 
 1. まず、ガードレールはエージェントに渡されたものと同じ入力を受け取ります。  
-2. 次に、ガードレール関数が実行され、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成します。その結果は [`InputGuardrailResult`][agents.guardrail.InputGuardrailResult] にラップされます。  
-3. 最後に、[`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。 true の場合、[`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered] 例外が送出されるため、ユーザーへの応答や例外処理を適切に行えます。  
+2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、それが [`InputGuardrailResult`][agents.guardrail.InputGuardrailResult] にラップされます。  
+3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。true の場合は [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered] 例外が送出され、ユーザーへの応答や例外処理を適切に行えます。
 
 !!! Note
 
-    入力ガードレールはユーザー入力に対して実行することを想定しているため、エージェントのガードレールはそのエージェントが *最初* のエージェントである場合にのみ実行されます。「なぜ `guardrails` プロパティが `Runner.run` への引数ではなくエージェントにあるのか？」と疑問に思うかもしれません。ガードレールは実際の エージェント に密接に関連する傾向があり、エージェントごとに異なるガードレールを走らせることになるので、コードを同じ場所に置くほうが可読性に優れるためです。
+    Input guardrails はユーザー入力に対して実行することを想定しているため、エージェントが *最初の* エージェントである場合のみ実行されます。  
+    ところで、`guardrails` プロパティが `Runner.run` に渡されるのではなくエージェントにあるのはなぜでしょうか？  
+    それは、ガードレールが実際のエージェントに密接に関係していることが多いからです。異なるエージェントには異なるガードレールを実行したいので、同じ場所にコードを置くと可読性が向上します。
 
-## 出力ガードレール
+## Output guardrails
 
-出力ガードレールは次の 3 ステップで実行されます：
+Output guardrails も 3 つのステップで動作します:
 
 1. まず、ガードレールはエージェントが生成した出力を受け取ります。  
-2. 次に、ガードレール関数が実行され、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成します。その結果は [`OutputGuardrailResult`][agents.guardrail.OutputGuardrailResult] にラップされます。  
-3. 最後に、[`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。 true の場合、[`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered] 例外が送出されるため、ユーザーへの応答や例外処理を適切に行えます。  
+2. 次に、ガードレール関数が実行され [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を生成し、それが [`OutputGuardrailResult`][agents.guardrail.OutputGuardrailResult] にラップされます。  
+3. 最後に [`.tripwire_triggered`][agents.guardrail.GuardrailFunctionOutput.tripwire_triggered] が true かどうかを確認します。true の場合は [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered] 例外が送出され、ユーザーへの応答や例外処理を適切に行えます。
 
 !!! Note
 
-    出力ガードレールは最終出力に対して実行することを想定しているため、エージェントのガードレールはそのエージェントが *最後* のエージェントである場合にのみ実行されます。入力ガードレールと同様に、ガードレールは実際の エージェント に関連しているため、エージェントごとに異なるガードレールを設定できるようコードを同じ場所に置いておくと可読性が向上します。
+    Output guardrails は最終的なエージェント出力に対して実行することを想定しているため、エージェントが *最後の* エージェントである場合のみ実行されます。  
+    Input guardrails と同様に、ガードレールは実際のエージェントに密接に関係しているため、異なるエージェントには異なるガードレールを実行したいという理由から、コードを同じ場所に置くと可読性が向上します。
 
-## トリップワイヤー
+## Tripwires
 
-入力または出力がガードレールに失敗した場合、ガードレールはトリップワイヤーでこれを通知できます。トリップワイヤーが発動したガードレールを検出するとただちに `{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
+入力または出力がガードレールを通過できなかった場合、ガードレールはトリップワイヤーでこれを通知できます。トリップワイヤーが発動したガードレールを検知するとすぐに、`{Input,Output}GuardrailTripwireTriggered` 例外を送出し、エージェントの実行を停止します。
 
 ## ガードレールの実装
 
-入力を受け取り [`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。この例では、内部で エージェント を実行して実現します。
+入力を受け取り、[`GuardrailFunctionOutput`][agents.guardrail.GuardrailFunctionOutput] を返す関数を用意する必要があります。以下の例では、その内部でエージェントを実行して実装します。
 
 ```python
 from pydantic import BaseModel
@@ -95,11 +98,11 @@ async def main():
 ```
 
 1. このエージェントをガードレール関数内で使用します。  
-2. これがエージェントの入力/コンテキストを受け取り、結果を返すガードレール関数です。  
-3. ガードレールの結果に追加情報を含めることもできます。  
-4. こちらがワークフローを定義する実際のエージェントです。  
+2. これはエージェントの入力／コンテキストを受け取り、結果を返すガードレール関数です。  
+3. ガードレール結果には追加情報を含めることができます。  
+4. こちらがワークフローを定義する実際のエージェントです。
 
-出力ガードレールも同様です。
+Output guardrails も同様です。
 
 ```python
 from pydantic import BaseModel
@@ -152,7 +155,7 @@ async def main():
         print("Math output guardrail tripped")
 ```
 
-1. こちらが実際のエージェントの出力型です。  
-2. こちらがガードレールの出力型です。  
-3. これがエージェントの出力を受け取り、結果を返すガードレール関数です。  
-4. こちらがワークフローを定義する実際のエージェントです。  
\ No newline at end of file
+1. こちらは実際のエージェントの出力型です。  
+2. こちらはガードレールの出力型です。  
+3. これはエージェントの出力を受け取り、結果を返すガードレール関数です。  
+4. こちらがワークフローを定義する実際のエージェントです。
\ No newline at end of file
diff --git a/docs/ja/handoffs.md b/docs/ja/handoffs.md
index 794f1ac3e..d6b1c8187 100644
--- a/docs/ja/handoffs.md
+++ b/docs/ja/handoffs.md
@@ -2,21 +2,21 @@
 search:
   exclude: true
 ---
-# Handoffs
+# ハンドオフ
 
-Handoffs により、あるエージェントがタスクを別のエージェントに委譲できます。これは、異なるエージェントがそれぞれ特定分野を専門とするシナリオで特に便利です。たとえばカスタマーサポートアプリでは、注文状況、払い戻し、FAQ などを個別に処理するエージェントがいる場合があります。
+ハンドオフを使用すると、エージェントが他のエージェントへタスクを委譲できます。これは、異なるエージェントがそれぞれ異なる分野を専門としているシナリオで特に有用です。たとえば、カスタマーサポートアプリでは、注文状況、返金、 FAQ などのタスクを個別に処理するエージェントが存在する場合があります。
 
-Handoffs は LLM からはツールとして表現されます。たとえば `Refund Agent` への handoff がある場合、ツール名は `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] 関数を使って handoff を作成できます。この関数では、委譲先のエージェントの指定に加えて、各種オーバーライドや入力フィルターを設定できます。
+Agents SDK が提供する [`handoff()`][agents.handoffs.handoff] 関数を使用すると、ハンドオフを作成できます。この関数では、ハンドオフ先のエージェントに加えて、任意のオーバーライドや入力フィルターを指定できます。
 
-### 基本的な使い方
+### 基本的な使用方法
 
-シンプルな 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 のカスタマイズ
+### `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`: handoff が呼び出された際に実行されるコールバック関数です。handoff が行われた時点でデータ取得を開始したい場合などに便利です。この関数はエージェントコンテキストを受け取り、必要であれば LLM が生成した入力も受け取れます。どの入力データが渡されるかは `input_type` パラメーターで制御します。
--   `input_type`: handoff が想定する入力の型です (任意)。
--   `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(
 )
 ```
 
-## Handoff の入力
+## ハンドオフ入力
 
-状況によっては、LLM が handoff を呼び出す際に何らかのデータを渡してほしい場合があります。たとえば「Escalation agent」への handoff では、ログ用に理由も渡したいといったケースです。
+状況によっては、LLMにハンドオフの呼び出し時にデータを渡してほしい場合があります。たとえば、"Escalation agent" へのハンドオフを考えてみましょう。理由を提供しておき、ログに残せるようにしたいかもしれません。
 
 ```python
 from pydantic import BaseModel
@@ -81,11 +81,11 @@ handoff_obj = handoff(
 )
 ```
 
-## Input filters
+## 入力フィルター
 
-Handoff が発生すると、新しいエージェントが会話を引き継ぎ、これまでの会話履歴全体を閲覧できる状態になります。これを変更したい場合は [`input_filter`][agents.handoffs.Handoff.input_filter] を設定できます。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 が handoffs を正しく理解するように、エージェント内に handoff に関する情報を含めることを推奨します。[`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 ab22a3fa1..76b6fc938 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 アプリを構築できる SDK です。これは、以前のエージェント向け実験プロジェクト [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 とツールを備えた LLM
+-   **ハンドオフ**: エージェントが特定のタスクを他のエージェントに委任できる
+-   **ガードレール**: エージェントへの入力を検証できる
+-   **セッション**: エージェントの実行間で会話履歴を自動的に管理する
 
-Python と組み合わせることで、これらのコンポーネントは tools と エージェント 間の複雑な関係を表現でき、学習コストを抑えつつ実用的なアプリケーションを構築できます。さらに SDK には、エージェントフローの可視化・デバッグを可能にする **トレーシング** が組み込まれており、評価やファインチューニングまで行えます。
+これらの基本コンポーネントは、 Python と組み合わせることでツールとエージェント間の複雑な関係を表現でき、急な学習コストなしで実用的なアプリケーションを構築できます。さらに、 SDK には組み込みの **tracing** があり、エージェントフローを可視化・デバッグできるほか、評価やファインチューニングにも活用できます。
 
 ## Agents SDK を使用する理由
 
-SDK の設計原則は次の 2 点です。
+SDK には 2 つの設計原則があります:
 
-1. 利用価値のある十分な機能を持ちつつ、学習が速いようにコンポーネントを最小限に抑える。  
-2. デフォルト設定で優れた動作をしつつ、挙動を細部までカスタマイズできる。  
+1. 使う価値があるだけの機能を備えつつ、プリミティブを絞ることで習得を迅速にすること  
+2. すぐに高いパフォーマンスを発揮し、必要に応じて挙動を細かくカスタマイズできること  
 
-主な機能は次のとおりです。
+主な機能は次のとおりです:
 
-- エージェントループ: tools の呼び出し、結果を LLM へ送信、LLM が完了するまでのループを自動処理。  
-- Python ファースト: 新しい抽象を学ばずに、組み込み言語機能で エージェント をオーケストレーション・連鎖。  
-- ハンドオフ: 複数のエージェント間で調整・委任を行う強力な機能。  
-- ガードレール: エージェントと並行して入力検証を実行し、失敗時は早期停止。  
-- セッション: エージェント実行間の会話履歴を自動管理し、手動での状態管理を不要に。  
-- 関数ツール: 任意の Python 関数を tool 化し、スキーマ生成と Pydantic ベースの検証を自動化。  
-- トレーシング: フローを可視化・デバッグ・監視でき、OpenAI の評価、ファインチューニング、蒸留ツールも利用可能。  
+-   Agent loop: ツールの呼び出し、実行結果を LLM に送信し、 LLM が完了するまでループ処理を行う組み込みのエージェントループ
+-   Python ファースト: 新しい抽象を学ぶことなく、組み込みの言語機能でエージェントのオーケストレーションとチェーンを実現
+-   Handoffs: 複数のエージェント間で協調・委任を行う強力な機能
+-   Guardrails: エージェントと並列で入力検証を実行し、失敗した場合は早期に処理を中断
+-   Sessions: エージェント実行間の会話履歴を自動管理し、手動での状態管理を排除
+-   関数ツール: 任意の 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 b97f11735..177562738 100644
--- a/docs/ja/mcp.md
+++ b/docs/ja/mcp.md
@@ -4,23 +4,23 @@ search:
 ---
 # Model context protocol (MCP)
 
-Model context protocol （別名 MCP） は、 LLM にツールとコンテキストを提供するための方法です。 MCP のドキュメントから引用します:
+[Model context protocol](https://modelcontextprotocol.io/introduction)（別名 MCP）は、LLM にツールとコンテキストを提供する方法です。MCP のドキュメントから引用します。
 
-> MCP は、アプリケーションが LLM にコンテキストを提供する方法を標準化するオープンプロトコルです。 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` 、 `MCPServerSse` 、 `MCPServerStreamableHttp` クラスを使用して接続できます。
+これらのサーバーへは [`MCPServerStdio`][agents.mcp.server.MCPServerStdio]、[`MCPServerSse`][agents.mcp.server.MCPServerSse]、[`MCPServerStreamableHttp`][agents.mcp.server.MCPServerStreamableHttp] クラスを使用して接続できます。
 
-たとえば、公式 MCP ファイルシステムサーバーを使用する場合は次のようになります。
+たとえば、[公式 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
 
@@ -54,11 +54,11 @@ agent=Agent(
 
 ## ツールフィルタリング
 
-MCP サーバーでツールフィルターを設定することで、エージェントが利用できるツールを制限できます。 SDK は静的フィルタリングと動的フィルタリングの両方をサポートします。
+MCP サーバーでツールフィルターを設定することで、エージェントが利用できるツールを制限できます。SDK は静的フィルタリングと動的フィルタリングの両方をサポートしています。
 
 ### 静的ツールフィルタリング
 
-単純な許可 / ブロックリストには静的フィルタリングを使用します:
+シンプルな許可／ブロックリストには静的フィルタリングを使用できます。
 
 ```python
 from agents.mcp import create_static_tool_filter
@@ -87,15 +87,15 @@ server = MCPServerStdio(
 
 ```
 
-**`allowed_tool_names` と `blocked_tool_names` の両方を設定した場合の処理順序は次のとおりです:**
-1. まず `allowed_tool_names` （許可リスト）を適用し、指定したツールのみを残します
-2. 次に `blocked_tool_names` （ブロックリスト）を適用し、残ったツールから指定したツールを除外します
+**`allowed_tool_names` と `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
@@ -134,10 +134,10 @@ server = MCPServerStdio(
 )
 ```
 
-`ToolFilterContext` では次の情報にアクセスできます:
-- `run_context`: 現在のランコンテキスト
-- `agent`: ツールを要求しているエージェント
-- `server_name`: MCP サーバー名
+`ToolFilterContext` では次の情報にアクセスできます。  
+- `run_context`: 現在の実行コンテキスト  
+- `agent`: ツールを要求しているエージェント  
+- `server_name`: MCP サーバー名  
 
 ## プロンプト
 
@@ -145,10 +145,10 @@ MCP サーバーは、エージェントの instructions を動的に生成す
 
 ### プロンプトの使用
 
-プロンプトをサポートする MCP サーバーは、次の 2 つの主要メソッドを提供します:
+プロンプトをサポートする MCP サーバーは、次の 2 つの主要メソッドを提供します。
 
-- `list_prompts()`: サーバー上で利用可能なすべてのプロンプトを一覧表示します
-- `get_prompt(name, arguments)`: オプションのパラメーター付きで特定のプロンプトを取得します
+- `list_prompts()`: サーバー上で利用可能なすべてのプロンプトを一覧表示します  
+- `get_prompt(name, arguments)`: オプションのパラメーター付きで特定のプロンプトを取得します  
 
 ```python
 # List available prompts
@@ -173,19 +173,19 @@ agent = Agent(
 
 ## キャッシュ
 
-エージェントが実行されるたびに、 `list_tools()` が MCP サーバーへ呼ばれます。リモートサーバーの場合はこれがレイテンシの原因になることがあります。リストを自動でキャッシュするには、 `MCPServerStdio` 、 `MCPServerSse` 、 `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()` を呼び出します。
+キャッシュを無効化したい場合は、サーバーの `invalidate_tools_cache()` を呼び出せます。
 
 ## エンドツーエンドのコード例
 
-完全な動作例は [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](./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 a59447851..e67ff0d13 100644
--- a/docs/ja/models/index.md
+++ b/docs/ja/models/index.md
@@ -4,54 +4,52 @@ search:
 ---
 # モデル
 
- Agents SDK には、 OpenAI モデルをすぐに利用できる 2 種類のサポートが用意されています:
+Agents SDK には、OpenAI モデルをすぐに利用できる 2 種類のサポートが付属しています。
 
-- **推奨**: [`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 を呼び出します。
+-   **推奨**: [`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 依存グループをインストールしてください:
+[LiteLLM 連携](./litellm.md)を利用すると、ほとんどの OpenAI 以外のモデルを使用できます。まずは litellm 依存グループをインストールします。
 
 ```bash
 pip install "openai-agents[litellm]"
 ```
 
- その後、 `litellm/` プレフィックスを付けて、 [サポートされているモデル](https://docs.litellm.ai/docs/providers) を使用します:
+その後、`litellm/` プレフィックスを付けて、[サポートされているモデル](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 つの方法で統合できます（[コード例](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/)はこちら）。
 
 1. [`set_default_openai_client`][agents.set_default_openai_client]  
-   OpenAI 互換の API エンドポイントを持つ LLM プロバイダーで、 `base_url` と `api_key` を設定できる場合に、 `AsyncOpenAI` インスタンスをアプリ全体で使用する際に便利です。設定例は [examples/model_providers/custom_example_global.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_global.py) をご覧ください。  
+   OpenAI 互換の API エンドポイントを持つ LLM プロバイダーで、`base_url` と `api_key` を設定できる場合に、`AsyncOpenAI` インスタンスをグローバルに LLM クライアントとして利用したいときに便利です。設定例は [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` レベルで使用します。「この run 内のすべてのエージェントでカスタムモデルプロバイダーを使う」と宣言できます。設定例は [examples/model_providers/custom_example_provider.py](https://github.com/openai/openai-agents-python/tree/main/examples/model_providers/custom_example_provider.py) を参照してください。  
+   `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) があります。
+   特定の `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)があります。
 
- `platform.openai.com` の API キーをお持ちでない場合は、 `set_tracing_disabled()` で tracing を無効化するか、 [別の tracing プロセッサー](../tracing.md) を設定することをおすすめします。
+`platform.openai.com` の API キーをお持ちでない場合は、`set_tracing_disabled()` でトレーシングを無効化するか、[別のトレーシングプロセッサー](../tracing.md)を設定することを推奨します。
 
 !!! note
-
-    これらの例では、ほとんどの LLM プロバイダーが Responses API をまだサポートしていないため、 Chat Completions API/モデルを使用しています。ご利用の LLM プロバイダーが Responses API をサポートしている場合は、 Responses の利用を推奨します。
+    これらの例では、ほとんどの LLM プロバイダーがまだ Responses API をサポートしていないため、Chat Completions API/モデルを使用しています。お使いの LLM プロバイダーが Responses API をサポートしている場合は、Responses の利用を推奨します。
 
 ## モデルの組み合わせ
 
- 1 つのワークフロー内でエージェントごとに異なるモデルを使用したい場合があります。たとえば、振り分け (triage) には小型で高速なモデルを、複雑なタスクには大型で高性能なモデルを使用するといった具合です。 [`Agent`][agents.Agent] を設定する際、以下のいずれかでモデルを選択できます:
+1 つのワークフロー内で、エージェントごとに異なるモデルを使用したい場合があります。たとえば、振り分けには小型で高速なモデルを、複雑なタスクには大型で高性能なモデルを使用するといったケースです。[`Agent`][agents.Agent] を設定する際、以下のいずれかでモデルを選択できます。
 
-1. モデル名を直接指定する。  
-2. 任意のモデル名と、それをモデルインスタンスにマッピングできる [`ModelProvider`][agents.models.interface.ModelProvider] を渡す。  
-3. [`Model`][agents.models.interface.Model] 実装を直接渡す。  
+1. モデル名を直接渡す  
+2. いずれかのモデル名と、それをモデルインスタンスへマッピングできる [`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 +82,10 @@ async def main():
     print(result.final_output)
 ```
 
-1.  OpenAI モデル名を直接設定します。  
-2.  [`Model`][agents.models.interface.Model] 実装を提供します。  
+1. OpenAI モデル名を直接設定しています。  
+2. [`Model`][agents.models.interface.Model] 実装を提供しています。
 
- エージェントで使用するモデルをさらに設定したい場合は、 [`ModelSettings`][agents.models.interface.ModelSettings] を渡して `temperature` などのオプションパラメーターを指定できます。
+エージェントで使用するモデルをさらに設定したい場合は、`temperature` などの任意パラメーターを指定できる [`ModelSettings`][agents.models.interface.ModelSettings] を渡せます。
 
 ```python
 from agents import Agent, ModelSettings
@@ -100,7 +98,7 @@ english_agent = Agent(
 )
 ```
 
- OpenAI の Responses API を使用する場合には、 `user` や `service_tier` など [追加のオプションパラメーター](https://platform.openai.com/docs/api-reference/responses/create) があります。トップレベルで指定できない場合は、 `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,28 +114,29 @@ english_agent = Agent(
 )
 ```
 
-## 他の LLM プロバイダーを使用する際の一般的な問題
+## 他の LLM プロバイダー使用時の一般的な問題
 
-### Tracing クライアントの 401 エラー
+### Tracing クライアントエラー 401
 
- tracing 関連のエラーが発生する場合、トレースが OpenAI サーバーにアップロードされるのに OpenAI API キーを持っていないことが原因です。解決策は次の 3 つです:
+トレーシング関連のエラーが発生する場合、トレースは OpenAI サーバーへアップロードされるため、OpenAI API キーが必要です。以下のいずれかの方法で解決できます。
 
-1. tracing を完全に無効化する: [`set_tracing_disabled(True)`][agents.set_tracing_disabled]  
-2. tracing 用に OpenAI キーを設定する: [`set_tracing_export_api_key(...)`][agents.set_tracing_export_api_key]  
-   この API キーはトレースのアップロードのみに使用され、 [platform.openai.com](https://platform.openai.com/) から取得したものである必要があります。  
-3. 非 OpenAI の trace プロセッサーを使用する。詳しくは [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 ドキュメント](../tracing.md#custom-tracing-processors) を参照してください。
 
 ### Responses API のサポート
 
- SDK はデフォルトで Responses API を使用しますが、ほとんどの LLM プロバイダーはまだ対応していません。その結果、 404 などのエラーが発生することがあります。解決策は次の 2 つです:
+SDK はデフォルトで Responses API を使用しますが、ほとんどの LLM プロバイダーはまだ対応していません。そのため 404 エラーなどが発生する場合があります。解決策は以下のとおりです。
 
-1. [`set_default_openai_api("chat_completions")`][agents.set_default_openai_api] を呼び出す。  
+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/) にあります。
+2. [`OpenAIChatCompletionsModel`][agents.models.openai_chatcompletions.OpenAIChatCompletionsModel] を使用する  
+   [コード例](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) をサポートしていません。その場合、次のようなエラーが発生することがあります。
 
 ```
 
@@ -145,12 +144,12 @@ BadRequestError: Error code: 400 - {'error': {'message': "'response_format.type'
 
 ```
 
- これは一部プロバイダーの制限で、 JSON 出力はサポートしていても、出力に使用する `json_schema` を指定できないためです。現在この問題の解決に取り組んでいますが、 JSON schema 出力をサポートするプロバイダーを利用することを推奨します。そうでない場合、 JSON が不正な形式で返され、アプリが頻繁に壊れる可能性があります。
+これは一部プロバイダーの制限で、JSON 出力はサポートしていても、出力に使用する `json_schema` を指定できないためです。現在修正に取り組んでいますが、JSON スキーマ出力をサポートしているプロバイダーを使用することを推奨します。そうでない場合、不正な JSON によりアプリが頻繁に壊れる可能性があります。
 
 ## プロバイダーをまたいだモデルの混在
 
- モデルプロバイダーごとの機能差を理解していないと、エラーに遭遇することがあります。たとえば、 OpenAI は structured outputs、マルチモーダル入力、ホスト型 file search や web search をサポートしていますが、多くの他社プロバイダーはこれらをサポートしていません。以下の制限に注意してください:
+モデルプロバイダー間の機能差を理解しておかないと、エラーが発生する可能性があります。たとえば、OpenAI は 構造化出力、マルチモーダル入力、ホスト型ファイル検索・Web 検索 をサポートしていますが、多くの他プロバイダーはこれらをサポートしていません。以下の制限に注意してください。
 
-- サポートしていない `tools` を理解できないプロバイダーに送信しない  
-- テキストのみのモデルを呼び出す前にマルチモーダル入力を除外する  
-- structured JSON outputs をサポートしないプロバイダーでは、無効な JSON が返されることがある点を理解する  
\ No newline at end of file
+-   対応していないプロバイダーへ `tools` を送信しない  
+-   テキストのみのモデルを呼び出す前に、マルチモーダル入力を除外する  
+-   構造化 JSON 出力をサポートしないプロバイダーでは、無効な JSON が時折生成される点に注意する
\ No newline at end of file
diff --git a/docs/ja/models/litellm.md b/docs/ja/models/litellm.md
index 4f4f0ae41..b9531ddb6 100644
--- a/docs/ja/models/litellm.md
+++ b/docs/ja/models/litellm.md
@@ -2,17 +2,17 @@
 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](https://docs.litellm.ai/docs/) は、単一のインターフェースで 100 以上のモデルを利用できるライブラリです。Agents SDK では LiteLLM 連携を追加し、あらゆる AI モデルを利用できるようにしました。
 
 ## セットアップ
 
-`litellm` が利用可能であることを確認してください。オプションの `litellm` 依存グループをインストールすることで導入できます。
+`litellm` が利用可能であることを確認してください。オプションの `litellm` 依存関係グループをインストールすることで対応できます。
 
 ```bash
 pip install "openai-agents[litellm]"
@@ -24,11 +24,11 @@ pip install "openai-agents[litellm]"
 
 以下は完全に動作する例です。実行すると、モデル名と API キーの入力を求められます。たとえば次のように入力できます。
 
--   `openai/gpt-4.1` をモデルに指定し、OpenAI API キーを入力
--   `anthropic/claude-3-5-sonnet-20240620` をモデルに指定し、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 647102724..bb856ca19 100644
--- a/docs/ja/multi_agent.md
+++ b/docs/ja/multi_agent.md
@@ -4,38 +4,38 @@ search:
 ---
 # 複数エージェントのオーケストレーション
 
-オーケストレーションとは、アプリ内でエージェントがどのように流れるかを指します。どのエージェントを、どの順番で実行し、その後の処理をどのように決定するかということです。エージェントをオーケストレーションする方法は大きく 2 つあります。
+オーケストレーションとは、アプリ内でのエージェントの流れを指します。どのエージェントをどの順番で実行し、次に何を行うかをどのように決定するか、ということです。エージェントをオーケストレーションする主な方法は 2 つあります。
 
-1.  LLM に意思決定させる:  LLM の知性を利用して計画・推論し、次に取るべきステップを決定します。  
-2.  コードでオーケストレーションする: コード側でエージェントのフローを決定します。
+1.  LLM に意思決定を委ねる: LLM の知能を活用して計画・推論し、それに基づいて次のステップを決定します。  
+2.  コードによるオーケストレーション: コードでエージェントの流れを制御します。
 
-これらのパターンは組み合わせて使うこともできます。それぞれにトレードオフがあり、以下で説明します。
+これらのパターンは組み合わせて使うことも可能です。それぞれに一長一短があります。
 
 ## LLM によるオーケストレーション
 
-エージェントとは、 instructions、tools、handoffs を備えた LLM です。つまり、オープンエンドなタスクが与えられた場合、 LLM は自律的にタスクへの取り組み方を計画し、tools を用いてアクションを実行してデータを取得し、handoffs でサブエージェントへタスクを委譲できます。例えば、リサーチ用エージェントには次のような tools を持たせられます。
+エージェントとは、instructions、tools、handoffs を備えた LLM です。これにより、オープンエンドなタスクに対して、LLM が自律的に計画を立て、tools を用いてアクションを実行しデータを取得し、handoffs によってサブエージェントへタスクを委任できます。たとえば、リサーチ エージェントには以下のような tools を用意できます。
 
--   Web 検索でオンラインの情報を取得  
--   ファイル検索および取得で専有データや接続を検索  
--   コンピュータ操作でコンピュータ上のアクションを実行  
+-   Web 検索でオンライン情報を取得する  
+-   ファイル検索と取得で専有データや接続を検索する  
+-   コンピュータ操作でコンピュータ上のアクションを実行する  
 -   コード実行でデータ分析を行う  
--   計画やレポート作成に優れた専門エージェントへの handoffs  
+-   計画立案やレポート作成などに特化したエージェントへのハンドオフ  
 
-このパターンはタスクがオープンエンドで、 LLM の知性に頼りたい場合に最適です。ここで重要となる戦略は次のとおりです。
+このパターンはタスクがオープンエンドで、LLM の知能に頼りたい場合に最適です。ここで重要な戦略は次のとおりです。
 
-1. 良質なプロンプトに投資すること。利用可能な tools、その使い方、および動作すべきパラメーターの範囲を明確に示します。  
-2. アプリを監視して継続的に改善すること。不具合が発生した箇所を確認し、プロンプトを繰り返し改善します。  
-3. エージェントが自己分析して改善できるようにすること。たとえばループで実行して自己評価させる、あるいはエラーメッセージを提示して改善させます。  
-4. 何でもこなす汎用エージェントではなく、 1 つのタスクに特化したエキスパートエージェントを用意すること。  
-5. [evals](https://platform.openai.com/docs/guides/evals) に投資すること。これによりエージェントを訓練してタスク遂行能力を向上させられます。  
+1.  良いプロンプトに投資する。利用可能な tools、使用方法、および運用パラメーターを明確にします。  
+2.  アプリをモニタリングしてイテレーションを重ねる。問題が発生した箇所を確認し、プロンプトを改善します。  
+3.  エージェントに内省させて改善させる。たとえばループで実行し自己批評させる、あるいはエラーメッセージを渡して改善させるなどです。  
+4.  一つのタスクに特化したエージェントを用意し、何でもこなす汎用エージェントに過度な期待をしないようにします。  
+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` ループで回し、別のエージェントが評価とフィードバックを行い、評価者が基準を満たしたと判断するまで繰り返します。  
+-   Python の基本コンポーネントである `asyncio.gather` などを用いて複数エージェントを並列実行する。相互に依存しない複数タスクを高速に処理したい場合に有用です。  
 
-[`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) には多数の code examples があります。
\ No newline at end of file
diff --git a/docs/ja/quickstart.md b/docs/ja/quickstart.md
index 9f64383a4..7f2933f48 100644
--- a/docs/ja/quickstart.md
+++ b/docs/ja/quickstart.md
@@ -6,7 +6,7 @@ search:
 
 ## プロジェクトと仮想環境の作成
 
-この操作は 1 回だけでかまいません。
+この作業は一度だけ行えば十分です。
 
 ```bash
 mkdir my_project
@@ -14,7 +14,7 @@ cd my_project
 python -m venv .venv
 ```
 
-### 仮想環境の有効化
+### 仮想環境を有効化
 
 新しいターミナルセッションを開始するたびに実行してください。
 
@@ -28,17 +28,17 @@ source .venv/bin/activate
 pip install openai-agents # or `uv add openai-agents`, etc
 ```
 
-### OpenAI API キーの設定
+### OpenAI 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` などのオプション設定で定義します。
+エージェントは instructions、名前、任意の設定（`model_config` など）で定義します。
 
 ```python
 from agents import Agent
@@ -49,7 +49,7 @@ agent = Agent(
 )
 ```
 
-## エージェントをさらに追加する
+## さらにエージェントを追加
 
 追加のエージェントも同様に定義できます。`handoff_descriptions` はハンドオフのルーティングを判断するための追加コンテキストを提供します。
 
@@ -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
@@ -123,7 +123,7 @@ 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 ダッシュボードの [Trace viewer](https://platform.openai.com/traces) に移動してエージェント実行のトレースを閲覧してください。
+エージェント実行中に何が起こったかを確認するには、[OpenAI ダッシュボードの Trace ビューア](https://platform.openai.com/traces)に移動してトレースを閲覧してください。
 
 ## 次のステップ
 
 より複雑なエージェントフローの構築方法を学びましょう:
 
--   [Agents](agents.md) の設定方法を学ぶ。  
--   [running agents](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 d1a7a90ab..70185e05c 100644
--- a/docs/ja/realtime/guide.md
+++ b/docs/ja/realtime/guide.md
@@ -4,65 +4,65 @@ search:
 ---
 # ガイド
 
-本ガイドでは、OpenAI Agents SDK の realtime 機能を利用して音声対応の AI エージェントを構築する方法を詳しく説明します。
+このガイドでは、 OpenAI  Agents SDK の realtime 機能を使用して音声対応 AI  エージェントを構築する方法を詳しく説明します。
 
 !!! warning "Beta feature"
-Realtime エージェントはベータ版です。実装を改善する過程で破壊的変更が入る可能性があります。
+Realtime エージェントはベータ版です。実装の改良に伴い、互換性が破壊される変更が入る可能性があります。
 
 ## 概要
 
-Realtime エージェントは、音声とテキスト入力をリアルタイムで処理し、リアルタイム音声で応答できる会話フローを実現します。OpenAI の Realtime API との永続接続を維持し、低レイテンシで自然な音声対話と、割り込みへのスムーズな対応が可能です。
+Realtime エージェントは、音声とテキスト入力をリアルタイムで処理し、リアルタイム音声で応答する会話フローを可能にします。これらは OpenAI の Realtime API と永続的な接続を維持し、低レイテンシで自然な音声対話と割り込み処理を実現します。
 
 ## アーキテクチャ
 
 ### 主要コンポーネント
 
-realtime システムは次の主要コンポーネントで構成されます。
+realtime システムは以下の主要コンポーネントで構成されます。
 
-- **RealtimeAgent**: instructions、tools、handoffs を設定したエージェントです。  
-- **RealtimeRunner**: 設定を管理します。`runner.run()` を呼び出すことでセッションを取得できます。  
-- **RealtimeSession**: 単一の対話セッションです。ユーザーが会話を開始するたびに作成し、会話が終了するまで保持します。  
-- **RealtimeModel**: 基盤となるモデルインターフェース（通常は OpenAI の WebSocket 実装）です。  
+- ** RealtimeAgent**: instructions、tools、handoffs で構成されたエージェント  
+- ** RealtimeRunner**: 設定を管理します。 `runner.run()` を呼び出してセッションを取得します  
+- ** RealtimeSession**: 単一の対話セッション。ユーザーが会話を開始するたびに作成し、会話が終了するまで保持します  
+- ** RealtimeModel**: 基盤となるモデルインターフェース (通常は OpenAI の WebSocket 実装)
 
 ### セッションフロー
 
-一般的な realtime セッションの流れは次のとおりです。
+典型的な realtime セッションの流れは次のとおりです。
 
-1. instructions、tools、handoffs を設定して **RealtimeAgent** を作成します。  
-2. そのエージェントと設定オプションを使って **RealtimeRunner** をセットアップします。  
-3. `await runner.run()` で **セッションを開始** し、`RealtimeSession` を取得します。  
-4. `send_audio()` または `send_message()` で **音声またはテキストメッセージを送信** します。  
-5. セッションをイテレートして **イベントをリッスン** します。イベントには音声出力、文字起こし、ツール呼び出し、ハンドオフ、エラーが含まれます。  
-6. ユーザーがエージェントの発話を遮った場合に **割り込みを処理** します。割り込みが発生すると現在の音声生成は自動的に停止します。  
+1. ** RealtimeAgent** を instructions、tools、handoffs 付きで作成します  
+2. ** RealtimeRunner** をエージェントと設定オプションでセットアップします  
+3. `await runner.run()` を使用して **セッションを開始** し、 RealtimeSession を取得します  
+4. `send_audio()` または `send_message()` で **音声またはテキストメッセージを送信** します  
+5. セッションを反復処理して **イベントをリッスン** します — イベントには音声出力、トランスクリプト、ツール呼び出し、ハンドオフ、エラーが含まれます  
+6. ユーザーがエージェントの話し中に話した場合 **割り込みを処理** し、現在の音声生成を自動で停止します  
 
-セッションは会話履歴を保持し、realtime モデルとの永続接続を管理します。
+セッションは会話履歴を保持し、リアルタイムモデルとの永続接続を管理します。
 
 ## エージェント設定
 
-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 など他の機能は同じように動作します  
 
 ## セッション設定
 
 ### モデル設定
 
-セッション設定では、基盤となる realtime モデルの動作を制御できます。モデル名（例: `gpt-4o-realtime-preview`）、音声選択（alloy、echo、fable、onyx、nova、shimmer）、対応モダリティ（text と／または audio）を指定できます。入出力の音声フォーマットはどちらも PCM16 がデフォルトです。
+セッション設定では、基盤となる realtime モデルの動作を制御できます。モデル名 (例: `gpt-4o-realtime-preview`)、音声 (alloy、echo、fable、onyx、nova、shimmer)、サポートするモダリティ (テキストおよび / または音声) を指定できます。音声フォーマットは入力・出力ともに設定可能で、デフォルトは PCM16 です。
 
-### 音声設定
+### オーディオ設定
 
-音声設定では、セッションが音声入力と出力をどのように扱うかを制御します。Whisper などのモデルを使用した入力音声の文字起こし、言語の指定、ドメイン固有用語の精度を高めるための文字起こしプロンプトが設定可能です。ターン検出設定では、音声検出閾値、無音時間、検出された音声周辺のパディングなどを調整し、エージェントがいつ応答を開始・終了すべきかを決定します。
+オーディオ設定では、音声入力と出力の扱いを制御します。Whisper などのモデルを使用した入力音声の文字起こし、言語設定、ドメイン固有用語の精度向上用トランスクリプションプロンプトが指定できます。ターン検出設定では、音声活動検出のしきい値、無音時間、検出した音声の前後パディングなど、エージェントがいつ応答を開始・停止するかを調整します。
 
 ## ツールと関数
 
 ### ツールの追加
 
-通常のエージェントと同様に、realtime エージェントは会話中に実行される function tools をサポートします。
+通常のエージェントと同様に、realtime エージェントも会話中に実行される function tools をサポートします。
 
 ```python
 from agents import function_tool
@@ -119,30 +119,30 @@ main_agent = RealtimeAgent(
 
 ## イベント処理
 
-セッションはイベントをストリーミングします。セッションオブジェクトをイテレートしてイベントをリッスンしてください。イベントには音声出力チャンク、文字起こし結果、ツール実行開始と終了、エージェントのハンドオフ、エラーが含まれます。主に処理すべきイベントは次のとおりです。
+セッションはイベントをストリーム配信します。セッションオブジェクトを反復処理してリッスンしてください。イベントには音声出力チャンク、トランスクリプション結果、ツール実行開始・終了、エージェントハンドオフ、エラーなどがあります。主なイベント:
 
-- **audio**: エージェントの応答からの raw 音声データ  
-- **audio_end**: エージェントが発話を完了  
-- **audio_interrupted**: ユーザーがエージェントを割り込み  
-- **tool_start/tool_end**: ツール実行ライフサイクル  
-- **handoff**: エージェントハンドオフが発生  
+- **audio**: エージェント応答の raw 音声データ  
+- **audio_end**: エージェントが話し終えた  
+- **audio_interrupted**: ユーザーがエージェントを割り込んだ  
+- **tool_start / tool_end**: ツール実行のライフサイクル  
+- **handoff**: エージェントのハンドオフが発生  
 - **error**: 処理中にエラーが発生  
 
 完全なイベント詳細は [`RealtimeSessionEvent`][agents.realtime.events.RealtimeSessionEvent] を参照してください。
 
 ## ガードレール
 
-realtime エージェントでは出力ガードレールのみサポートされています。ガードレールはデバウンスされ、リアルタイム生成中のパフォーマンス問題を避けるために定期的（全単語ではなく）に実行されます。デフォルトのデバウンス長は 100 文字ですが、設定可能です。
+Realtime エージェントでは出力ガードレールのみがサポートされます。パフォーマンス低下を防ぐためにデバウンスされ、リアルタイム生成中に毎単語ではなく定期的に実行されます。デフォルトのデバウンス長は 100 文字で、設定可能です。
 
-ガードレールがトリガーされると `guardrail_tripped` イベントが生成され、エージェントの現在の応答を中断できます。このデバウンス動作により、安全性とリアルタイム性能のバランスが取れます。テキストエージェントとは異なり、realtime エージェントはガードレールがトリップしても Exception を送出しません。
+ガードレールがトリガーされると `guardrail_tripped` イベントが生成され、エージェントの現在の応答を中断できます。デバウンス動作により安全性とリアルタイム性能のバランスを取ります。テキストエージェントとは異なり、realtime エージェントはガードレールがトリップしても 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` イベントをリッスンし、直ちに再生を停止してキューにある音声をクリアします。
 
-## 直接モデルアクセス
+## モデルへの直接アクセス
 
 基盤となるモデルにアクセスしてカスタムリスナーを追加したり、高度な操作を行うことができます。
 
@@ -151,8 +151,8 @@ realtime エージェントでは出力ガードレールのみサポートさ
 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 41b1ce511..6a0ab1d05 100644
--- a/docs/ja/realtime/quickstart.md
+++ b/docs/ja/realtime/quickstart.md
@@ -4,35 +4,35 @@ search:
 ---
 # クイックスタート
 
-Realtime エージェントは、OpenAI の Realtime API を使用して AI エージェントとの音声会話を実現します。本ガイドでは、初めての Realtime 音声エージェントを作成する手順を説明します。
+Realtime エージェントを使用すると、OpenAI の Realtime API を介して AI エージェントと音声会話が行えます。ここでは、最初の realtime 音声エージェントを作成する方法を説明します。
 
-!!! warning "ベータ機能"
-Realtime エージェントは現在ベータ版です。実装の改善に伴い、非互換の変更が発生する可能性があります。
+!!! warning "Beta feature"
+Realtime エージェントはベータ版です。実装の改善に伴い、破壊的変更が発生する可能性があります。
 
 ## 前提条件
 
--   Python 3.9 以上  
--   OpenAI API キー  
--   OpenAI Agents SDK の基本的な知識  
+-   Python 3.9 以上
+-   OpenAI API キー
+-   OpenAI Agents SDK の基本的な知識
 
 ## インストール
 
-まだインストールしていない場合は、OpenAI Agents SDK をインストールしてください:
+まだインストールしていない場合は、OpenAI Agents SDK をインストールしてください：
 
 ```bash
 pip install openai-agents
 ```
 
-## 初めての Realtime エージェントの作成
+## 初めての realtime エージェント作成
 
-### 1. 必要なコンポーネントをインポートする
+### 1. 必要なコンポーネントをインポート
 
 ```python
 import asyncio
 from agents.realtime import RealtimeAgent, RealtimeRunner
 ```
 
-### 2. Realtime エージェントを作成する
+### 2. realtime エージェントを作成
 
 ```python
 agent = RealtimeAgent(
@@ -41,7 +41,7 @@ agent = RealtimeAgent(
 )
 ```
 
-### 3. Runner をセットアップする
+### 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`: 利用可能な Realtime モデルから選択します (例: `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_transcription`: 音声文字起こしの設定
+-   `input_audio_format`: 入力音声のフォーマット（`pcm16`, `g711_ulaw`, `g711_alaw`）
+-   `output_audio_format`: 出力音声のフォーマット
+-   `input_audio_transcription`: 音声認識の設定
 
 ### ターン検出
 
--   `type`: 検出方式 (`server_vad`, `semantic_vad`)
--   `threshold`: 音声活動しきい値 (0.0-1.0)
--   `silence_duration_ms`: ターン終了と判断する無音時間
--   `prefix_padding_ms`: 発話前のオーディオパディング
+-   `type`: 検出方法（`server_vad`, `semantic_vad`）
+-   `threshold`: 音声アクティビティ閾値（0.0–1.0）
+-   `silence_duration_ms`: ターン終了を検出する無音時間
+-   `prefix_padding_ms`: 発話前の音声パディング
 
 ## 次のステップ
 
--   [Realtime エージェントについてさらに学ぶ](guide.md)
--   [examples/realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) フォルダにある実動作する code examples をご覧ください
--   エージェントに tools を追加する
--   エージェント間のハンドオフを実装する
--   安全のためのガードレールを設定する
+-   [realtime エージェントについて詳しく学ぶ](guide.md)
+-   [examples/realtime](https://github.com/openai/openai-agents-python/tree/main/examples/realtime) フォルダーの動作する code examples を確認
+-   ツールをエージェントに追加
+-   エージェント間のハンドオフを実装
+-   安全のためのガードレールを設定
 
 ## 認証
 
-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 13905d471..6819c93a5 100644
--- a/docs/ja/release.md
+++ b/docs/ja/release.md
@@ -2,31 +2,31 @@
 search:
   exclude: true
 ---
-# リリースプロセス / 変更ログ
+# リリースプロセス／変更履歴
 
-このプロジェクトは、`0.Y.Z` 形式を用いたセマンティックバージョニングをやや変更した方式に従っています。先頭の `0` は、 SDK がいまだ急速に進化していることを示します。各コンポーネントの増分ルールは以下のとおりです。
+このプロジェクトは、`0.Y.Z` という形式を使用したセマンティック バージョニングのわずかに改変されたバージョンに従っています。先頭の `0` は、 SDK がまだ急速に進化していることを示しています。各コンポーネントの増分ルールは次のとおりです。
 
 ## マイナー (`Y`) バージョン
 
-ベータでない公開インターフェースに **破壊的変更** が入る場合、マイナーバージョン `Y` を増やします。たとえば、`0.0.x` から `0.1.x` への移行には破壊的変更が含まれる可能性があります。
+ベータでない公開インターフェースに **破壊的変更** が入った場合は、マイナー バージョン `Y` を上げます。たとえば、`0.0.x` から `0.1.x` への更新には破壊的変更が含まれる可能性があります。
 
-破壊的変更を避けたい場合は、プロジェクトで `0.0.x` バージョンに固定することをおすすめします。
+破壊的変更を避けたい場合は、プロジェクトで `0.0.x` バージョンを固定して使用することを推奨します。
 
 ## パッチ (`Z`) バージョン
 
-互換性を損なわない変更の場合は `Z` を増やします。
+互換性を壊さない変更については `Z` を増分します。
 
 -   バグ修正
 -   新機能
 -   非公開インターフェースの変更
 -   ベータ機能の更新
 
-## 破壊的変更の変更ログ
+## 破壊的変更の変更履歴
 
 ### 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 0644dc462..c7affc53a 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,6 +18,6 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-`run_demo_loop` はループでユーザー入力を促し、ターン間の会話履歴を保持します。デフォルトでは、生成されたとおりにモデルの出力をストリーミングします。上記の例を実行すると、 run_demo_loop がインタラクティブなチャット セッションを開始します。このセッションではユーザー入力を継続的に受け取り、ターン間の全会話履歴を記憶するため、エージェントはすでに話題に上がった内容を理解できます。また、エージェントの応答を生成と同時にリアルタイムで自動ストリーミングします。
+`run_demo_loop` は、ループ内で ユーザー入力 を促し、ターン間で 会話履歴 を保持します。デフォルトでは、生成されたとおりにモデル出力を ストリーミング します。上記の例を実行すると、 `run_demo_loop` が 対話型チャットセッション を開始します。これはあなたの入力を継続的に求め、全 会話履歴 をターン間で記憶するため、エージェントはこれまでに話し合われた内容を把握できます。また、生成されたエージェントの応答を リアルタイム で自動的にストリーミング表示します。
 
-チャット セッションを終了するには、`quit` または `exit` と入力して Enter を押すか、`Ctrl-D` のキーボード ショートカットを使用してください。
\ No newline at end of file
+チャットセッションを終了するには、`quit` または `exit` と入力（ Enter キーを押す）するか、 `Ctrl-D` キーボードショートカットを使用してください。
\ No newline at end of file
diff --git a/docs/ja/results.md b/docs/ja/results.md
index 36f67c2cb..7915ad12b 100644
--- a/docs/ja/results.md
+++ b/docs/ja/results.md
@@ -4,53 +4,53 @@ search:
 ---
 # 結果
 
-`Runner.run` メソッドを呼び出すと、戻り値は次のいずれかです:
+`Runner.run` メソッドを呼び出すと、次のいずれかが返されます。
 
--   `run` または `run_sync` を呼び出した場合は [`RunResult`][agents.result.RunResult]
--   `run_streamed` を呼び出した場合は [`RunResultStreaming`][agents.result.RunResultStreaming]
+-   [`RunResult`][agents.result.RunResult]   `run` または `run_sync` を呼び出した場合  
+-   [`RunResultStreaming`][agents.result.RunResultStreaming]   `run_streamed` を呼び出した場合
 
 どちらも [`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`  
+-   エージェントに `output_type` が定義されている場合は `last_agent.output_type` 型のオブジェクト
 
 !!! note
 
-    `final_output` の型は `Any` です。ハンドオフ がある可能性があるため、静的に型付けすることはできません。ハンドオフ が発生すると、どの エージェント が最後になるか分からないため、取り得る出力型の集合を静的に決定できないからです。
+    `final_output` の型は `Any` です。handoffs が発生する可能性があるため、静的に型を決定できません。handoffs が起こると、どのエージェントが最後になるか分からないため、可能な出力型の集合を静的に特定できないのです。
 
-## 次ターン用の入力
+## 次のターンへの入力
 
-[`result.to_input_list()`][agents.result.RunResultBase.to_input_list] を使用すると、元の入力と エージェント 実行中に生成されたアイテムを連結した入力リストへ変換できます。これにより、ある エージェント 実行の出力を別の実行に渡したり、ループで実行して毎回新しい ユーザー 入力を追加したりすることが容易になります。
+[`result.to_input_list()`][agents.result.RunResultBase.to_input_list] を使用すると、元の入力とエージェント実行中に生成されたアイテムを連結した入力リストを取得できます。これにより、あるエージェント実行の出力を次の実行にそのまま渡したり、ループで実行して毎回新しい user 入力を追加したりすることが容易になります。
 
 ## 最後のエージェント
 
-[`last_agent`][agents.result.RunResultBase.last_agent] プロパティには、最後に実行された エージェント が格納されます。アプリケーションによっては、これは次回の ユーザー 入力時に非常に便利です。たとえば、一次受付の振り分け エージェント が言語別の エージェント にハンドオフ する場合、最後の エージェント を保存しておき、次回 ユーザー からメッセージが来た際に再利用できます。
+[`last_agent`][agents.result.RunResultBase.last_agent] プロパティには、最後に実行されたエージェントが格納されます。アプリケーションによっては、次に user が入力した際にこれを再利用すると便利です。たとえば、フロントラインのトリアージ エージェントが言語別エージェントへ handoff する場合、最後のエージェントを保存しておき、次回の user メッセージで再利用できます。
 
 ## 新規アイテム
 
-[`new_items`][agents.result.RunResultBase.new_items] プロパティには、実行中に生成された新しいアイテムが含まれます。各アイテムは [`RunItem`][agents.items.RunItem] であり、LLM が生成した raw アイテムをラップします。
+[`new_items`][agents.result.RunResultBase.new_items] プロパティには、実行中に生成された新しいアイテムが格納されます。アイテムは [`RunItem`][agents.items.RunItem] でラップされており、raw アイテムは LLM が生成したものです。
 
--   [`MessageOutputItem`][agents.items.MessageOutputItem]: LLM からのメッセージを示します。raw アイテムは生成されたメッセージです。  
--   [`HandoffCallItem`][agents.items.HandoffCallItem]: LLM が handoff ツールを呼び出したことを示します。raw アイテムは LLM からのツール呼び出しアイテムです。  
--   [`HandoffOutputItem`][agents.items.HandoffOutputItem]: ハンドオフ が発生したことを示します。raw アイテムは handoff ツール呼び出しへのツール応答です。このアイテムからソース / ターゲット エージェント も取得できます。  
--   [`ToolCallItem`][agents.items.ToolCallItem]: LLM がツールを呼び出したことを示します。  
--   [`ToolCallOutputItem`][agents.items.ToolCallOutputItem]: ツールが呼び出されたことを示します。raw アイテムはツールの応答です。また、このアイテムからツール出力にアクセスできます。  
--   [`ReasoningItem`][agents.items.ReasoningItem]: LLM からの reasoning アイテムを示します。raw アイテムは生成された reasoning です。
+-   [`MessageOutputItem`][agents.items.MessageOutputItem]   LLM からのメッセージを示します。raw アイテムは生成されたメッセージです。  
+-   [`HandoffCallItem`][agents.items.HandoffCallItem]   LLM が handoff ツールを呼び出したことを示します。raw アイテムは LLM からのツール呼び出しアイテムです。  
+-   [`HandoffOutputItem`][agents.items.HandoffOutputItem]   handoff が発生したことを示します。raw アイテムは handoff ツール呼び出しへのツール応答です。このアイテムから source/target エージェントにもアクセスできます。  
+-   [`ToolCallItem`][agents.items.ToolCallItem]   LLM がツールを呼び出したことを示します。  
+-   [`ToolCallOutputItem`][agents.items.ToolCallOutputItem]   ツールが呼び出されたことを示します。raw アイテムはツール応答です。このアイテムからツール出力にもアクセスできます。  
+-   [`ReasoningItem`][agents.items.ReasoningItem]   LLM からの reasoning アイテムを示します。raw アイテムは生成された reasoning です。  
 
 ## その他の情報
 
 ### ガードレール結果
 
-[`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 レスポンス
 
-[`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 f88ede3f7..03e542f12 100644
--- a/docs/ja/running_agents.md
+++ b/docs/ja/running_agents.md
@@ -4,14 +4,14 @@ search:
 ---
 # エージェントの実行
 
-エージェントは [`Runner`][agents.run.Runner] クラスを介して実行できます。方法は次の 3 つです。
+エージェントは [`Runner`][agents.run.Runner] クラスを通じて実行できます。方法は 3 つあります:
 
 1. [`Runner.run()`][agents.run.Runner.run]  
-   非同期で実行し、[`RunResult`][agents.result.RunResult] を返します。  
+   非同期 ( async ) で実行され、[`RunResult`][agents.result.RunResult] を返します。  
 2. [`Runner.run_sync()`][agents.run.Runner.run_sync]  
    同期メソッドで、内部的には `.run()` を呼び出します。  
 3. [`Runner.run_streamed()`][agents.run.Runner.run_streamed]  
-   非同期で実行し、[`RunResultStreaming`][agents.result.RunResultStreaming] を返します。ストリーミング モードで LLM を呼び出し、受信イベントを逐次ストリームします。
+   非同期 ( async ) で実行され、[`RunResultStreaming`][agents.result.RunResultStreaming] を返します。ストリーミング モードで LLM を呼び出し、受信したイベントをそのままストリームします。
 
 ```python
 from agents import Agent, Runner
@@ -26,58 +26,55 @@ async def main():
     # Infinite loop's dance
 ```
 
-詳細は [results ガイド](results.md) を参照してください。
+詳細は [結果ガイド](results.md) を参照してください。
 
 ## エージェントループ
 
-`Runner` の run メソッドを使う際、開始エージェントと入力を渡します。入力は文字列（ユーザー メッセージと見なされます）または入力アイテムのリスト（OpenAI Responses API のアイテム）です。
+`Runner` の run メソッドを使用する際、開始エージェントと入力を渡します。入力は文字列 (ユーザー メッセージと見なされます) か、OpenAI Responses API のアイテムのリストのいずれかです。
 
-Runner は次のループを実行します。
+ Runner  は次のループを実行します:
 
-1. 現在のエージェントと入力で LLM を呼び出します。  
+1. 現在のエージェントに対して現在の入力で LLM を呼び出します。  
 2. LLM が出力を生成します。  
-    1. `final_output` が返された場合、ループを終了し結果を返します。  
-    2. ハンドオフが行われた場合、現在のエージェントと入力を更新してループを再実行します。  
-    3. ツール呼び出しが生成された場合、それらを実行し結果を追加してループを再実行します。  
-3. 渡した `max_turns` を超えた場合、[`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded] 例外を送出します。
+    1. LLM が `final_output` を返した場合、ループを終了して結果を返します。  
+    2. LLM がハンドオフを行った場合、現在のエージェントと入力を更新し、ループを再実行します。  
+    3. LLM がツール呼び出しを生成した場合、それらを実行して結果を追加し、ループを再実行します。  
+3. 渡された `max_turns` を超えた場合、[`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded] 例外を送出します。
 
 !!! note
 
-    出力が「final output」と見なされる条件は、望ましい型でのテキスト出力があり、ツール呼び出しが存在しないことです。
+    LLM の出力が「最終出力」と見なされる条件は、望ましい型のテキストを生成し、かつツール呼び出しがないことです。
 
 ## ストリーミング
 
-ストリーミングを利用すると、LLM 実行中にストリーミング イベントを受け取れます。ストリーム完了後、[`RunResultStreaming`][agents.result.RunResultStreaming] には実行に関する完全な情報（生成されたすべての新しい出力を含む）が格納されます。`.stream_events()` を呼び出してイベントを取得できます。詳細は [ストリーミング ガイド](streaming.md) を参照してください。
+ストリーミングを使用すると、 LLM 実行中にイベントを逐次受け取れます。ストリーム完了後、[`RunResultStreaming`][agents.result.RunResultStreaming] には実行に関する完全な情報 (生成されたすべての新しい出力を含む) が格納されます。`.stream_events()` を呼び出してストリーミング イベントを取得できます。詳細は [ストリーミング ガイド](streaming.md) をご覧ください。
 
-## Run config
+## 実行設定
 
-`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.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]: トレーシング用のワークフロー名、トレース ID、グループ ID を設定します。少なくとも `workflow_name` の設定を推奨します。グループ ID は複数実行に跨るトレースを関連付ける任意フィールドです。  
-- [`trace_metadata`][agents.run.RunConfig.trace_metadata]: すべてのトレースに含めるメタデータ。  
+- [`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.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]: トレースのワークフロー名、トレース ID、トレース グループ ID を設定します。少なくとも `workflow_name` を設定することを推奨します。グループ ID は複数実行間でトレースを紐付ける際に使用できます。  
+- [`trace_metadata`][agents.run.RunConfig.trace_metadata]: すべてのトレースに付与するメタデータ。  
 
-## 会話／チャットスレッド
+## 会話 / チャットスレッド
 
-いずれの run メソッドを呼び出しても、1 つ以上のエージェント（ひいては 1 つ以上の LLM 呼び出し）が実行されますが、チャット会話における 1 つの論理的ターンを表します。例:
+いずれかの run メソッドを呼び出すと、1 つ以上のエージェント (つまり 1 つ以上の LLM 呼び出し) が実行されますが、チャット会話における 1 つの論理ターンを表します。例:
 
-1. ユーザー ターン: ユーザーがテキストを入力  
-2. Runner 実行:  
-   - 第 1 エージェントが LLM を呼び出し、ツールを実行  
-   - 第 2 エージェントへハンドオフ  
-   - 第 2 エージェントがさらにツールを実行し、出力を生成  
+1. ユーザーのターン: ユーザーがテキストを入力  
+2. Runner の実行: 第 1 エージェントが LLM を呼び出し、ツールを実行し、第 2 エージェントへハンドオフ。第 2 エージェントがさらにツールを実行し、出力を生成。  
 
-エージェント実行の最後にユーザーへ何を表示するかは自由です。すべての新しいアイテムを表示しても、最終出力だけを表示しても構いません。ユーザーがフォローアップ質問をしたら、再度 run メソッドを呼び出します。
+エージェント実行の最後に、ユーザーへ何を表示するかを選択できます。例として、エージェントが生成したすべての新しいアイテムを表示する、または最終出力だけを表示する、といった方法があります。いずれにせよ、ユーザーがフォローアップ質問をすれば、再度 run メソッドを呼び出せます。
 
-### 手動での会話管理
+### 手動の会話管理
 
-[`RunResultBase.to_input_list()`][agents.result.RunResultBase.to_input_list] メソッドで、次のターン用の入力を取得し会話履歴を手動管理できます。
+[`RunResultBase.to_input_list()`][agents.result.RunResultBase.to_input_list] メソッドを使用して次のターンの入力を取得し、会話履歴を手動で管理できます。
 
 ```python
 async def main():
@@ -99,7 +96,7 @@ async def main():
 
 ### Sessions による自動会話管理
 
-より簡単な方法として、[Sessions](sessions.md) を使用して `.to_input_list()` を呼び出すことなく会話履歴を自動処理できます。
+より簡単な方法として、[Sessions](sessions.md) を使用して `.to_input_list()` を手動で呼び出すことなく会話履歴を自動管理できます。
 
 ```python
 from agents import Agent, Runner, SQLiteSession
@@ -122,31 +119,26 @@ async def main():
         # California
 ```
 
-Sessions は自動で以下を行います。
+Sessions は自動的に以下を行います:
 
-- 各実行前に会話履歴を取得  
-- 各実行後に新しいメッセージを保存  
-- セッション ID ごとに個別の会話を維持  
+- 実行前に会話履歴を取得  
+- 実行後に新しいメッセージを保存  
+- 異なる session ID ごとに個別の会話を維持  
 
 詳細は [Sessions ドキュメント](sessions.md) を参照してください。
 
-## 長時間実行エージェントと Human-in-the-Loop
+## 長時間実行エージェントと Human-in-the-loop
 
-Agents SDK は [Temporal](https://temporal.io/) との連携により、Human-in-the-Loop を含む耐久性のある長時間実行ワークフローを実行できます。Temporal と Agents SDK が連携して長時間タスクを完了するデモは[この動画](https://www.youtube.com/watch?v=fFBZqzT4DD8)で視聴でき、[ドキュメントはこちら](https://github.com/temporalio/sdk-python/tree/main/temporalio/contrib/openai_agents)にあります。
+Agents SDK は [Temporal](https://temporal.io/) との統合により、 Human-in-the-loop タスクを含む耐久性のある長時間実行ワークフローを実行できます。Temporal と Agents SDK が連携して長時間タスクを完了するデモは [こちらの動画](https://www.youtube.com/watch?v=fFBZqzT4DD8) を、ドキュメントは [こちら](https://github.com/temporalio/sdk-python/tree/main/temporalio/contrib/openai_agents) をご覧ください。
 
 ## 例外
 
-SDK は特定の場合に例外を送出します。完全な一覧は [`agents.exceptions`][] にあります。概要は次のとおりです。
-
-- [`AgentsException`][agents.exceptions.AgentsException]  
-  SDK 内で送出されるすべての例外の基底クラスです。  
-- [`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded]  
-  `Runner.run`、`Runner.run_sync`、`Runner.run_streamed` のいずれかで `max_turns` 制限を超えた場合に送出されます。指定されたターン数内でタスクを完了できなかったことを示します。  
-- [`ModelBehaviorError`][agents.exceptions.ModelBehaviorError]  
-  基盤モデル (LLM) が予期しない、または無効な出力を生成した場合に発生します。例:  
-    - 不正な JSON: ツール呼び出しや `output_type` が指定されている場合の直接出力で JSON が壊れている。  
-    - ツールに関する予期しない失敗。  
-- [`UserError`][agents.exceptions.UserError]  
-  SDK を使用する際の実装ミス、無効な設定、API の誤用など、ユーザー (コード作成者) 側のエラー時に送出されます。  
-- [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered], [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered]  
-  それぞれ入力ガードレール、出力ガードレールの条件を満たした場合に送出されます。入力ガードレールは処理前のメッセージを、出力ガードレールはエージェントの最終応答をチェックします。
\ No newline at end of file
+SDK は特定のケースで例外を送出します。完全な一覧は [`agents.exceptions`][] にあります。概要を示します:
+
+- [`AgentsException`][agents.exceptions.AgentsException]: SDK 内で送出されるすべての例外の基底クラスです。ほかの特定例外はすべてこれを継承します。  
+- [`MaxTurnsExceeded`][agents.exceptions.MaxTurnsExceeded]: `Runner.run`, `Runner.run_sync`, `Runner.run_streamed` の `max_turns` 制限を超えた際に送出されます。指定されたターン数内にタスクを完了できなかったことを示します。  
+- [`ModelBehaviorError`][agents.exceptions.ModelBehaviorError]: 基盤モデル ( LLM ) が予期しない、または無効な出力を生成した際に発生します。例:  
+    - 不正な JSON: ツール呼び出しや `output_type` が定義された場合の直出力で、不正な JSON 構造を返した。  
+    - 予期しないツール関連の失敗: モデルが想定どおりにツールを使用できなかった。  
+- [`UserError`][agents.exceptions.UserError]: SDK を使用する際の実装ミス、無効な設定、API の誤用など、ユーザーが原因のエラーで送出されます。  
+- [`InputGuardrailTripwireTriggered`][agents.exceptions.InputGuardrailTripwireTriggered], [`OutputGuardrailTripwireTriggered`][agents.exceptions.OutputGuardrailTripwireTriggered]: 入力ガードレールまたは出力ガードレールの条件を満たした場合に送出されます。入力ガードレールは処理前のメッセージを、出力ガードレールはエージェントの最終応答をチェックします。
\ No newline at end of file
diff --git a/docs/ja/sessions.md b/docs/ja/sessions.md
index 6da492e05..3819159d3 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 は特定のセッションの会話履歴を保存し、明示的なメモリ管理なしでエージェントがコンテキストを維持できるようにします。これは、チャットアプリケーションやマルチターンの会話でエージェントに前回の対話内容を覚えさせたい場合に特に便利です。
 
 ## クイックスタート
 
@@ -49,19 +49,19 @@ print(result.final_output)  # "Approximately 39 million"
 
 ## 仕組み
 
-セッションメモリーを有効にすると、以下のように動作します。
+セッションメモリを有効にすると、次のように動作します。
 
-1. **各実行前**: ランナーがセッションの会話履歴を自動的に取得し、入力アイテムの先頭に追加します。  
-2. **各実行後**: 実行中に生成されたすべての新しいアイテム（ユーザー入力、アシスタントの応答、ツール呼び出しなど）が自動的にセッションに保存されます。  
-3. **コンテキスト保持**: 同じセッションでの後続の実行には完全な会話履歴が含まれるため、エージェントはコンテキストを維持できます。
+1.  **各実行前** : ランナーが自動的にそのセッションの会話履歴を取得し、入力アイテムの先頭に追加します。  
+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
@@ -216,17 +216,17 @@ result = await Runner.run(
 
 ### セッション ID の命名
 
-会話を整理しやすい意味のあるセッション ID を使用してください。
+管理しやすいセッション ID を使用してください。
 
-- User-based: `"user_12345"`
-- Thread-based: `"thread_abc123"`
-- Context-based: `"support_ticket_456"`
+-   ユーザーベース: `"user_12345"`  
+-   スレッドベース: `"thread_abc123"`  
+-   コンテキストベース: `"support_ticket_456"`
 
-### メモリー永続化
+### メモリの永続化
 
-- 一時的な会話にはインメモリー SQLite (`SQLiteSession("session_id")`) を使用  
-- 永続的な会話にはファイルベース SQLite (`SQLiteSession("session_id", "path/to/db.sqlite")`) を使用  
-- 本番環境では独自のセッションバックエンド（Redis、PostgreSQL など）の実装を検討してください
+-   一時的な会話にはインメモリ SQLite (`SQLiteSession("session_id")`) を使用  
+-   永続的な会話にはファイルベース SQLite (`SQLiteSession("session_id", "path/to/db.sqlite")`) を使用  
+-   本番システムでは Redis や PostgreSQL など、カスタムセッションバックエンドの実装を検討してください。
 
 ### セッション管理
 
@@ -252,9 +252,9 @@ result2 = await Runner.run(
 )
 ```
 
-## 完全なコード例
+## 完全な例
 
-以下は、セッションメモリーが実際に動作する完全なコード例です。
+以下はセッションメモリが動作する完全な例です。
 
 ```python
 import asyncio
@@ -316,9 +316,9 @@ if __name__ == "__main__":
     asyncio.run(main())
 ```
 
-## API リファレンス
+## API 参照
 
 詳細な API ドキュメントは以下を参照してください。
 
-- [`Session`][agents.memory.Session] - プロトコルインターフェース
-- [`SQLiteSession`][agents.memory.SQLiteSession] - SQLite 実装
\ No newline at end of file
+-   [`Session`][agents.memory.Session] - プロトコルインターフェース  
+-   [`SQLiteSession`][agents.memory.SQLiteSession] - SQLite 実装
\ No newline at end of file
diff --git a/docs/ja/streaming.md b/docs/ja/streaming.md
index 548ba1662..a95cf7cfc 100644
--- a/docs/ja/streaming.md
+++ b/docs/ja/streaming.md
@@ -4,15 +4,15 @@ search:
 ---
 # ストリーミング
 
-ストリーミングを使用すると、エージェントの実行が進行するにつれて更新を購読できます。これはエンドユーザーに進行状況の更新や部分的なレスポンスを表示する際に便利です。
+Streaming を使用すると、エージェント の実行が進行するにつれて送られてくる更新を購読できます。これはエンドユーザー に進捗更新や部分的な応答を表示する際に役立ちます。
 
-ストリーミングを行うには、 `Runner.run_streamed()` を呼び出します。これにより `RunResultStreaming` が返されます。続いて `result.stream_events()` を呼び出すと、下記で説明する `StreamEvent` オブジェクトの非同期ストリームを取得できます。
+ストリーミングを行うには、[`Runner.run_streamed()`][agents.run.Runner.run_streamed] を呼び出します。これにより [`RunResultStreaming`][agents.result.RunResultStreaming] が返されます。`result.stream_events()` を呼び出すと、下記で説明する [`StreamEvent`][agents.stream_events.StreamEvent] オブジェクトの非同期ストリームを受け取れます。
 
-## raw レスポンスイベント
+## raw response イベント
 
-`RawResponsesStreamEvent` は、LLM から直接渡される raw イベントです。OpenAI Responses API 形式で提供されるため、各イベントには `response.created` や `response.output_text.delta` などの type とデータが含まれます。生成されたレスポンスメッセージを即座にユーザーへストリーミングしたい場合に便利です。
+[`RawResponsesStreamEvent`][agents.stream_events.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`][agents.stream_events.RunItemStreamEvent] は、より高レベルのイベントであり、アイテムが完全に生成されたときに通知します。これにより、トークン単位ではなく「メッセージが生成された」「ツールが実行された」といったレベルで進捗をプッシュできます。同様に、[`AgentUpdatedStreamEvent`][agents.stream_events.AgentUpdatedStreamEvent] は、ハンドオフ の結果などで現在のエージェント が変更されたときに更新を提供します。
 
-例えば、次のコードは raw イベントを無視し、ユーザーへ更新をストリーミングします。
+以下の例では raw イベントを無視し、ユーザー に更新のみをストリーム配信します。
 
 ```python
 import asyncio
diff --git a/docs/ja/tools.md b/docs/ja/tools.md
index 5ac3a43ae..f7e90d885 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 検索、コンピュータ操作をホスト型ツールとして提供しています。
--   関数ツール: 任意の Python 関数をツールとして利用できます。
--   ツールとしてのエージェント: エージェントをツールとして扱い、ハンドオフせずに他のエージェントを呼び出せます。
+-   Hosted ツール: これらは LLM サーバー上で AI モデルと並列に実行されます。OpenAI は retrieval、Web 検索、コンピュータ操作を Hosted ツールとして提供しています。  
+-   Function Calling: 任意の Python 関数をツールとして利用できます。  
+-   ツールとしての エージェント: エージェント をツールとして扱い、ハンドオフせずに他の エージェント を呼び出せます。  
 
-## ホスト型ツール
+## Hosted ツール
 
 [`OpenAIResponsesModel`][agents.models.openai_responses.OpenAIResponsesModel] を使用する場合、OpenAI はいくつかの組み込みツールを提供しています。
 
--   [`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] はローカルマシン上でシェルコマンドを実行します。
+-   [`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 ツール
 
-任意の 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,12 +102,12 @@ for tool in agent.tools:
 
 ```
 
-1.  関数の引数には任意の Python 型を使用でき、同期関数・非同期関数のどちらでも構いません。  
-2.  docstring が存在する場合、ツールおよび引数の説明として利用されます。  
-3.  関数は任意で `context`（先頭の引数）を受け取れます。また、ツール名や説明、docstring スタイルなどの上書き設定も可能です。  
-4.  デコレート済みの関数をツール一覧に渡すだけで使用できます。  
+1.  引数には任意の Python 型を使用でき、関数は sync / async のいずれでも構いません。  
+2.  docstring が存在する場合、説明および引数の説明を取得します。  
+3.  関数は任意で `context` を最初の引数として受け取れます。また、ツール名や説明、docstring スタイルなどのオーバーライドも設定できます。  
+4.  装飾済み関数をツールのリストに渡すだけで利用可能です。  
 
-??? note "出力を表示するには展開"
+??? note "出力を表示"
 
     ```
     fetch_weather
@@ -177,14 +177,14 @@ for tool in agent.tools:
     }
     ```
 
-### カスタム関数ツール
+### カスタム Function ツール
 
-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 文字列形式の引数を受け取り、ツール出力を文字列で返す非同期関数
+-   `name`  
+-   `description`  
+-   `params_json_schema` : 引数用の JSON schema  
+-   `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` を使用します。対応フォーマットは `google`、`sphinx`、`numpy` です。フォーマットは自動推定しますが、`function_tool` 呼び出し時に明示的に指定もできます。`use_docstring_info` を `False` に設定すれば解析を無効化できます。  
+1.  シグネチャ解析は `inspect` モジュールで行います。型アノテーションを用いて引数の型を把握し、Pydantic モデルを動的に構築します。Python の基本型、Pydantic モデル、TypedDict など大半の型をサポートします。  
+2.  docstring 解析には `griffe` を使用します。対応フォーマットは `google`, `sphinx`, `numpy` です。フォーマットは自動検出を試みますが、`function_tool` 呼び出し時に明示設定も可能です。`use_docstring_info` を `False` にすると docstring 解析を無効化できます。  
 
 スキーマ抽出のコードは [`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 ツールのエラー処理
 
-`@function_tool` で関数ツールを作成する際、`failure_error_function` を渡せます。これはツール呼び出しがクラッシュした場合に LLM へ返されるエラー応答を生成する関数です。
+`@function_tool` で Function ツールを作成する際、`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 f958494df..0f7399f9e 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 ダッシュボード](https://platform.openai.com/traces) を使用すると、開発中および本番環境でワークフローをデバッグ・可視化・監視できます。
 
 !!!note
 
-    トレーシングはデフォルトで有効になっています。無効にする方法は 2 つあります。
+    トレーシングはデフォルトで有効になっています。無効化する方法は 2 つあります。
 
-    1. 環境変数 `OPENAI_AGENTS_DISABLE_TRACING=1` を設定して、グローバルにトレーシングを無効化する  
-    2. [`agents.run.RunConfig.tracing_disabled`][] を `True` に設定して、単一の実行でトレーシングを無効化する
+    1. 環境変数 `OPENAI_AGENTS_DISABLE_TRACING=1` を設定してグローバルに無効化する  
+    2. 1 回の実行のみ無効化する場合は [`agents.run.RunConfig.tracing_disabled`][] を `True` に設定する
 
-***OpenAI の API を Zero Data Retention (ZDR) ポリシーで運用している組織では、トレーシングを利用できません。***
+***OpenAI の API を ZDR (Zero Data Retention) ポリシーで利用している組織では、トレーシングは利用できません。***
 
 ## トレースとスパン
 
-- **トレース** は「ワークフロー」の単一のエンドツーエンド操作を表します。トレースはスパンで構成されます。トレースには以下のプロパティがあります。  
-    - `workflow_name`：論理的なワークフローまたはアプリ名。例： "Code generation" や "Customer service"  
-    - `trace_id`：トレースの一意 ID。指定しない場合は自動生成されます。形式は `trace_<32_alphanumeric>` である必要があります。  
-    - `group_id`：任意のグループ ID。同じ会話からの複数トレースを関連付けるために使用します。例としてチャットスレッド ID など。  
-    - `disabled`：`True` の場合、トレースは記録されません。  
-    - `metadata`：トレースの任意メタデータ。  
-- **スパン** は開始時刻と終了時刻を持つ操作を表します。スパンには以下があります。  
+- **トレース**: 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 生成情報など。  
+    - 属するトレースを示す `trace_id`  
+    - 親スパンを指す `parent_id` (存在する場合)  
+    - スパン情報を含む `span_data`。例えば `AgentSpanData` はエージェント情報、`GenerationSpanData` は LLM 生成情報など  
 
 ## デフォルトのトレーシング
 
 デフォルトでは、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()` にラップされる  
+- 音声入力 (speech-to-text) は `transcription_span()` にラップされる  
+- 音声出力 (text-to-speech) は `speech_span()` にラップされる  
+- 関連する音声スパンは `speech_group_span()` 配下に配置される場合がある  
 
-トレース名はデフォルトで "Agent workflow" です。`trace` を使用して名前を設定するか、 [`RunConfig`][agents.run.RunConfig] で名前やその他のプロパティを構成できます。
+デフォルトのトレース名は "Agent workflow" です。`trace` を使用して名前を設定するか、[`RunConfig`][agents.run.RunConfig] で名前やその他のプロパティを設定できます。
 
-さらに、[カスタムトレーシングプロセッサー](#custom-tracing-processors) を設定して、別の送信先にトレースをプッシュする（置き換えまたは追加送信先として）ことも可能です。
+さらに、[カスタムトレースプロセッサ](#custom-tracing-processors) を設定して、別の送信先へトレースをプッシュする (置き換えまたは追加) こともできます。
 
-## 高レベルのトレース
+## 上位レベルのトレース
 
-複数回の `run()` 呼び出しを 1 つのトレースにまとめたい場合は、コード全体を `trace()` でラップします。
+複数回の `run()` 呼び出しを 1 つのトレースにまとめたい場合があります。その場合、コード全体を `trace()` でラップしてください。
 
 ```python
 from agents import Agent, Runner, trace
@@ -64,46 +64,46 @@ async def main():
         print(f"Rating: {second_result.final_output}")
 ```
 
-1. `with trace()` で 2 回の `Runner.run` 呼び出しをラップしているため、個々の実行は 2 つのトレースを作成せず、全体トレースの一部になります。
+1. 2 回の `Runner.run` 呼び出しが `with trace()` にラップされているため、個別に 2 つのトレースが作成されるのではなく、両方の実行が 1 つのトレースに含まれます。
 
 ## トレースの作成
 
 [`trace()`][agents.tracing.trace] 関数を使用してトレースを作成できます。トレースは開始と終了が必要で、方法は 2 つあります。
 
-1. **推奨**：コンテキストマネージャとしてトレースを使用する（例： `with trace(...) as my_trace`）。これにより適切なタイミングで自動的に開始・終了します。  
+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` を渡して現在のトレースを更新する必要があります。
+現在のトレースは Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) により追跡されるため、自動的に並行処理と連携します。手動で開始終了する場合は、`start()`/`finish()` に `mark_as_current` と `reset_current` を渡して現在のトレースを更新してください。
 
 ## スパンの作成
 
-各種 [`*_span()`][agents.tracing.create] メソッドでスパンを作成できますが、通常は手動で作成する必要はありません。カスタムスパン情報を追跡するために [`custom_span()`][agents.tracing.custom_span] が用意されています。
+各種 [`*_span()`][agents.tracing.create] メソッドでスパンを作成できますが、通常は手動で作成する必要はありません。カスタムスパン情報を追跡するための [`custom_span()`][agents.tracing.custom_span] も用意されています。
 
-スパンは自動的に現在のトレースの一部となり、Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) で追跡される最も近い現在のスパンの下にネストされます。
+スパンは自動的に現在のトレースに属し、Python の [`contextvar`](https://docs.python.org/3/library/contextvars.html) で追跡される最も近い現在のスパンの下にネストされます。
 
 ## 機微データ
 
-一部のスパンは機微データを取得する可能性があります。
+一部のスパンは機微なデータを含む可能性があります。
 
-`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] を設定して無効化できます。
+同様に、オーディオスパンはデフォルトで入力・出力音声の 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 バックエンドへスパンとトレースをエクスポートします。  
+- 初期化時にグローバル [`TraceProvider`][agents.tracing.setup.TraceProvider] を作成し、トレース生成を担当させる  
+- `TraceProvider` に [`BatchTraceProcessor`][agents.tracing.processors.BatchTraceProcessor] を設定し、トレース/スパンをバッチで [`BackendSpanExporter`][agents.tracing.processors.BackendSpanExporter] へ送信し、OpenAI バックエンドにエクスポートする  
 
-デフォルト設定をカスタマイズし、別のバックエンドへ送信したり、エクスポーター動作を変更したりするには 2 つの方法があります。
+デフォルト設定をカスタマイズして、別のバックエンドへ送信したりエクスポーターの動作を変更したりするには 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] を使用して **追加** のトレースプロセッサを登録する。OpenAI バックエンドへの送信に加えて独自処理を行えます。  
+2. [`set_trace_processors()`][agents.tracing.set_trace_processors] を使用してデフォルトプロセッサを **置き換え** る。OpenAI バックエンドへ送信したい場合は、その処理を行う `TracingProcessor` を含める必要があります。  
 
 ## 非 OpenAI モデルでのトレーシング
 
-OpenAI API キーを使用して非 OpenAI モデルでもトレーシングを有効にでき、トレーシングを無効化する必要なく OpenAI Traces ダッシュボードで無料トレースを利用できます。
+OpenAI API キーを使用して非 OpenAI モデルのトレーシングを有効にすると、トレーシングを無効化せずに OpenAI Traces ダッシュボードで無料のトレースを確認できます。
 
 ```python
 import os
@@ -125,26 +125,26 @@ agent = Agent(
 ```
 
 ## 備考
-- 無料トレースは OpenAI Traces ダッシュボードで確認できます。
-
-## 外部トレーシングプロセッサー一覧
-
-- [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)  
+- 無料のトレースは OpenAI Traces ダッシュボードで確認できます。
+
+## 外部トレースプロセッサ一覧
+
+- [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)
 - [LangDB AI](https://docs.langdb.ai/getting-started/working-with-agent-frameworks/working-with-openai-agents-sdk)
\ No newline at end of file
diff --git a/docs/ja/visualization.md b/docs/ja/visualization.md
index 71f13c745..8f4cf10c2 100644
--- a/docs/ja/visualization.md
+++ b/docs/ja/visualization.md
@@ -2,13 +2,13 @@
 search:
   exclude: true
 ---
-# エージェントの可視化
+# エージェント可視化
 
-エージェントの可視化では、 ** Graphviz ** を用いてエージェントとその関係を構造化されたグラフィカル表現として生成できます。これは、アプリケーション内でエージェント、ツール、ハンドオフがどのように相互作用するかを理解するのに役立ちます。
+エージェント可視化では、 **Graphviz** を使用してエージェントおよびその関係を構造化されたグラフィカル表現として生成できます。これにより、アプリケーション内でエージェント、ツール、ハンドオフがどのように相互作用するかを理解しやすくなります。
 
 ## インストール
 
-省略可能な `viz` 依存グループをインストールします:
+オプションの `viz` 依存関係グループをインストールします:
 
 ```bash
 pip install "openai-agents[viz]"
@@ -16,16 +16,20 @@ pip install "openai-agents[viz]"
 
 ## グラフの生成
 
-`draw_graph` 関数を使用してエージェントの可視化を生成できます。この関数は、次のような有向グラフを作成します:
+`draw_graph` 関数を使用してエージェントの可視化を生成できます。この関数は有向グラフを作成し、以下のように表現します:
 
-- **エージェント** は黄色のボックスで表されます。  
-- **ツール** は緑色の楕円で表されます。  
-- **ハンドオフ** はエージェント間の有向エッジで表されます。
+- **エージェント** は黄色のボックス。  
+- **MCP サーバー** は灰色のボックス。  
+- **ツール** は緑色の楕円。  
+- **ハンドオフ** はあるエージェントから別のエージェントへの向き付きエッジ。
 
-### 使い方の例
+### 使用例
 
 ```python
+import os
+
 from agents import Agent, function_tool
+from agents.mcp.server import MCPServerStdio
 from agents.extensions.visualization import draw_graph
 
 @function_tool
@@ -42,11 +46,22 @@ english_agent = Agent(
     instructions="You only speak English",
 )
 
+current_dir = os.path.dirname(os.path.abspath(__file__))
+samples_dir = os.path.join(current_dir, "sample_files")
+mcp_server = MCPServerStdio(
+    name="Filesystem Server, via npx",
+    params={
+        "command": "npx",
+        "args": ["-y", "@modelcontextprotocol/server-filesystem", samples_dir],
+    },
+)
+
 triage_agent = Agent(
     name="Triage agent",
     instructions="Handoff to the appropriate agent based on the language of the request.",
     handoffs=[spanish_agent, english_agent],
     tools=[get_weather],
+    mcp_servers=[mcp_server],
 )
 
 draw_graph(triage_agent)
@@ -54,33 +69,33 @@ draw_graph(triage_agent)
 
 ![Agent Graph](../assets/images/graph.png)
 
-これにより、 **triage agent** の構造とサブエージェントやツールとの接続を視覚的に表したグラフが生成されます。
+これにより、 **triage エージェント** の構造とサブエージェントおよびツールとの接続を視覚的に表現したグラフが生成されます。
 
 ## 可視化の理解
 
-生成されたグラフには次の要素が含まれます:
+生成されたグラフには以下が含まれます:
 
-- エントリーポイントを示す  **start node** (`__start__`)。  
-- エージェントは黄色で塗りつぶされた **長方形** として表されます。  
-- ツールは緑色で塗りつぶされた  **楕円**  で表されます。  
-- 相互作用を示す有向エッジ:  
-  - エージェント間のハンドオフには  **実線の矢印**。  
-  - ツール呼び出しには  **点線の矢印**。  
-- 実行の終了地点を示す  **end node** (`__end__`)。
+- エントリーポイントを示す **start ノード** (`__start__`)。  
+- 黄色で塗りつぶされた **長方形** で表されるエージェント。  
+- 緑で塗りつぶされた **楕円** で表されるツール。  
+- 灰色で塗りつぶされた **長方形** で表される MCP サーバー。  
+- 相互作用を示す向き付きエッジ:  
+  - エージェント間ハンドオフを示す **実線矢印**。  
+  - ツール呼び出しを示す **点線矢印**。  
+  - MCP サーバー呼び出しを示す **破線矢印**。  
+- 実行が終了する場所を示す **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 78eb392e8..fa7efa88a 100644
--- a/docs/ja/voice/pipeline.md
+++ b/docs/ja/voice/pipeline.md
@@ -4,7 +4,7 @@ search:
 ---
 # パイプラインとワークフロー
 
-[`VoicePipeline`][agents.voice.pipeline.VoicePipeline] は、エージェントのワークフローを音声アプリへ簡単に変換できるクラスです。実行したいワークフローを渡すだけで、入力音声の文字起こし、音声終了の検出、適切なタイミングでのワークフロー呼び出し、そしてワークフロー出力を再び音声へ変換する処理をパイプラインが自動で行います。
+`VoicePipeline` は、エージェントのワークフローを音声アプリへ簡単に変換できるクラスです。ワークフローを渡すだけで、パイプラインが入力音声の文字起こし、音声終了の検出、適切なタイミングでのワークフロー呼び出し、そしてワークフロー出力を音声へ変換する処理を行います。
 
 ```mermaid
 graph LR
@@ -32,30 +32,32 @@ graph LR
 
 ```
 
-## パイプラインの構成
+## パイプラインの設定
 
-パイプラインを作成する際には、次の項目を設定できます。
+パイプラインを作成する際には、次の項目を設定できます:
 
 1. [`workflow`][agents.voice.workflow.VoiceWorkflowBase]  
-   新しい音声が書き起こされるたびに実行されるコードです。  
-2. 使用する [`speech-to-text`][agents.voice.model.STTModel] と [`text-to-speech`][agents.voice.model.TTSModel] のモデル  
+   新しい音声が文字起こしされるたびに実行されるコードです。
+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 モデルに関する設定  
+   以下のような設定を行えます:
+   - モデルプロバイダー: モデル名をモデルにマッピングします  
+   - トレーシング: トレーシングの有効 / 無効、音声ファイルのアップロード可否、ワークフロー名、トレース 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]  
-   ユーザーが話し終えたタイミングを検出する必要がある場合に使用します。検出された音声チャンクを逐次プッシュでき、パイプラインが「アクティビティ検出」と呼ばれる処理で適切なタイミングにワークフローを自動実行します。  
+   発話終了を検出する必要がある場合に使用します。音声チャンクを検出次第プッシュでき、パイプラインが「アクティビティ検出」により適切なタイミングでワークフローを自動実行します。
 
 ## 結果
 
-音声パイプライン実行の結果は [`StreamedAudioResult`][agents.voice.result.StreamedAudioResult] です。これはイベントを逐次ストリーミングできるオブジェクトで、いくつかの [`VoiceStreamEvent`][agents.voice.events.VoiceStreamEvent] が含まれます。
+音声パイプラインの実行結果は [`StreamedAudioResult`][agents.voice.result.StreamedAudioResult] です。これは、イベントをストリーミングで受け取れるオブジェクトで、いくつかの [`VoiceStreamEvent`][agents.voice.events.VoiceStreamEvent] が含まれます:
 
 1. [`VoiceStreamEventAudio`][agents.voice.events.VoiceStreamEventAudio] — 音声チャンクを含みます。  
 2. [`VoiceStreamEventLifecycle`][agents.voice.events.VoiceStreamEventLifecycle] — ターン開始・終了などのライフサイクルイベントを通知します。  
@@ -79,5 +81,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 3ea6de139..3e3c8c44a 100644
--- a/docs/ja/voice/quickstart.md
+++ b/docs/ja/voice/quickstart.md
@@ -6,19 +6,19 @@ search:
 
 ## 前提条件
 
- Agents SDK の [クイックスタート手順](../quickstart.md) に従い、仮想環境をセットアップしていることを確認してください。その後、 SDK から音声オプションの依存関係をインストールします:
+まず、ベースとなる [Quickstart の手順](../quickstart.md) に従って  Agents SDK  をセットアップし、仮想環境を作成してください。その後、SDK の音声関連のオプション依存関係をインストールします。
 
 ```bash
 pip install 'openai-agents[voice]'
 ```
 
-## 概念
+## コンセプト
 
-理解しておくべき主な概念は [`VoicePipeline`][agents.voice.pipeline.VoicePipeline] です。これは 3 段階のプロセスになっています:
+ここで押さえておくべき主要な概念は [`VoicePipeline`][agents.voice.pipeline.VoicePipeline] です。これは次の 3 ステップから成ります。
 
-1. 音声をテキストに変換する speech-to-text モデルを実行する  
-2. 通常はエージェント的なワークフローであるご自身のコードを実行して、結果を生成する  
-3. 結果のテキストを再び音声に変換する text-to-speech モデルを実行する
+1. 音声をテキストに変換する  speech-to-text  モデルを実行する  
+2. 通常はエージェント的ワークフローとなるあなたのコードを実行し、実行結果を生成する  
+3. その結果テキストを再び音声に変換する  text-to-speech  モデルを実行する  
 
 ```mermaid
 graph LR
@@ -48,7 +48,7 @@ graph LR
 
 ## エージェント
 
-まず、いくつかのエージェントをセットアップしましょう。この SDK でエージェントを構築したことがあれば、見覚えがあるはずです。ここでは複数のエージェント、ハンドオフ、そしてツールを用意します。
+まずはエージェントをいくつか設定しましょう。すでにこの SDK でエージェントを構築したことがあれば、馴染みのある流れのはずです。ここでは複数のエージェント、ハンドオフ、そしてツールを用意します。
 
 ```python
 import asyncio
@@ -92,7 +92,7 @@ agent = Agent(
 
 ## 音声パイプライン
 
-[`SingleAgentVoiceWorkflow`][agents.voice.workflow.SingleAgentVoiceWorkflow] をワークフローとして使用し、シンプルな音声パイプラインを構築します。
+[`SingleAgentVoiceWorkflow`][agents.voice.workflow.SingleAgentVoiceWorkflow] をワークフローとして用いた、シンプルな音声パイプラインを設定します。
 
 ```python
 from agents.voice import SingleAgentVoiceWorkflow, VoicePipeline
@@ -124,7 +124,7 @@ async for event in result.stream():
 
 ```
 
-## まとめ
+## 統合
 
 ```python
 import asyncio
@@ -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 d670a4ad3..c475f4398 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_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]: トレース ワークフロー の名前です。
--   [`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
+-   [`workflow_name`][agents.voice.pipeline_config.VoicePipelineConfig.workflow_name]: トレースワークフローの名前です。
+-   [`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