pingcap · qiancai · Aug 28, 2026 · Aug 27, 2026
diff --git a/TOC.md b/TOC.md
@@ -299,9 +299,9 @@
       - [オプティマイザー修正コントロール](/optimizer-fix-controls.md)
     - [インデックスアドバイザー](/index-advisor.md)
 - チュートリアル
-  - [1つのリージョンに複数の可用性ゾーンを展開](/multi-data-centers-in-one-city-deployment.md)
-  - [2つのリージョンに3つの可用性ゾーンを展開](/three-data-centers-in-two-cities-deployment.md)
-  - [1つのリージョン展開で2つの可用性ゾーンを実現](/two-data-centers-in-one-city-deployment.md)
+  - [1つのリージョンに複数のアベイラビリティゾーンを展開](/multi-data-centers-in-one-city-deployment.md)
+  - [2つのリージョンに3つのアベイラビリティゾーンを展開](/three-data-centers-in-two-cities-deployment.md)
+  - [1つのリージョン展開で2つのアベイラビリティゾーンを実現](/two-data-centers-in-one-city-deployment.md)
   - 履歴データを読む
     - ステイル読み取りを使用する（推奨）
       - [ステイル読み取りの使用シナリオ](/stale-read.md)

diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md
@@ -1,6 +1,6 @@
 ---
 title: Multiple Availability Zones in One Region Deployment
-summary: 1つのリージョン内の複数の可用性ゾーンへのデプロイメント ソリューションについて学習します。
+summary: 1つのリージョン内の複数のアベイラビリティゾーンへのデプロイメント ソリューションについて学習します。
 ---
 
 # 1つのリージョンに複数のアベイラビリティゾーンを展開 {#multiple-availability-zones-in-one-region-deployment}
@@ -159,7 +159,7 @@ tikv_servers:
       server.labels: { zone: "z3", az: "az3", rack: "r2", host: "41" }
 ```
 
-上記の例では、 `zone`レプリカの分離を制御する論理可用性ゾーンレイヤーです (サンプル クラスターには 3つのレプリカがあります)。
+上記の例では、 `zone`レプリカの分離を制御する論理アベイラビリティゾーンレイヤーです (サンプル クラスターには 3つのレプリカがあります)。
 
 将来的に AZ がスケールアウトされる可能性があることを考慮し、3階層ラベル構造（ `az` 、 `rack` 、 `host` ）はそのまま採用しません。 `AZ2` 、 `AZ3` 、 `AZ4`をスケールアウトすると仮定した場合、対応するアベイラビリティゾーン内の AZ とラックをスケールアウトするだけで済みます。
 

diff --git a/overview.md b/overview.md
@@ -37,7 +37,7 @@ TiDB Self-Managedは、TiDBの製品オプションの一つであり、ユー
 
 - **クラウドネイティブ分散データベース**
 
-    TiDB はクラウド向けに設計された分散データベースで、クラウド プラットフォーム上で柔軟なスケーラビリティ、信頼性、セキュリティを提供します。ユーザーは、変化するワークロードの要件に合わせて TiDB を柔軟に拡張できます。TiDB では、各データに少なくとも 3つのレプリカがあり、異なるクラウド可用性ゾーンにスケジュールすることで、データセンター全体の停止にも対応できます。TiDB [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview) Kubernetes 上での TiDB の管理を支援し、TiDB クラスターの運用に関連するタスクを自動化することで、マネージド Kubernetes を提供するあらゆるクラウドへの TiDB のデプロイを容易にします。フル マネージド TiDB サービスである[TiDB Cloud](https://pingcap.com/tidb-cloud/) 、[クラウド上のTiDB](https://docs.pingcap.com/tidbcloud/)の真の力を引き出す最も簡単で経済的かつ堅牢な方法であり、数回のクリックだけで TiDB クラスターをデプロイして実行できます。
+    TiDB はクラウド向けに設計された分散データベースで、クラウド プラットフォーム上で柔軟なスケーラビリティ、信頼性、セキュリティを提供します。ユーザーは、変化するワークロードの要件に合わせて TiDB を柔軟に拡張できます。TiDB では、各データに少なくとも 3つのレプリカがあり、異なるクラウドアベイラビリティゾーンにスケジュールすることで、データセンター全体の停止にも対応できます。TiDB [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview) Kubernetes 上での TiDB の管理を支援し、TiDB クラスターの運用に関連するタスクを自動化することで、マネージド Kubernetes を提供するあらゆるクラウドへの TiDB のデプロイを容易にします。フル マネージド TiDB サービスである[TiDB Cloud](https://pingcap.com/tidb-cloud/) 、[クラウド上のTiDB](https://docs.pingcap.com/tidbcloud/)の真の力を引き出す最も簡単で経済的かつ堅牢な方法であり、数回のクリックだけで TiDB クラスターをデプロイして実行できます。
 
 - **MySQLプロトコルおよびMySQLエコシステムと互換性があります。**
 

diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md
@@ -315,7 +315,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では
 | [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630)     | 変更     | 6.5.0以降で有効になります。`INSERT` 、 `DELETE` 、 `UPDATE`を含むSQL文の読み取り操作をTiFlashにプッシュダウンできるかどうかを制御します。デフォルト値は`OFF`です。                                                                                                                                                                                                                                              |
 | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)                               | 変更     | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。つまり、 `ADD INDEX`と`CREATE INDEX`の加速はデフォルトで有効になります。                                                                                                                                                                                                                                                                 |
 | [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)                                                       | 変更     | TiDB v6.5.0より前のバージョンでは、この変数はクエリのメモリクォータのしきい値を設定するために使用されます。TiDB v6.5.0以降のバージョンでは、DMLステートメントのメモリをより正確に制御するために、この変数はセッションのメモリクォータのしきい値を設定するために使用されます。                                                                                                                                                                                                    |
-| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)                                                  | 変更     | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティーゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティーゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 |
+| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)                                                  | 変更     | v6.5.0 以降では、 TiDB ノード間の負荷分散を最適化するために、この変数が`closest-adaptive`に設定され、読み取り要求の推定結果が[`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630)以上の場合、 `closest-adaptive`構成が有効になる TiDB ノードの数が各アベイラビリティゾーンで制限されます。これは常に、 TiDB ノードが最も少ないアベイラビリティゾーンの TiDB ノードの数と同じになり、その他の TiDB ノードは自動的にリーダーレプリカから読み取ります。 |
 | [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)                                   | 変更     | デフォルト値を`0`から`80%`に変更します。TiDB グローバルメモリ制御が GA になったため、このデフォルト値の変更により、メモリ制御がデフォルトで有効になり、TiDB インスタンスのメモリ制限がデフォルトで合計メモリの 80% に設定されます。                                                                                                                                                                                                                        |
 | [`default_password_lifetime`](/system-variables.md#default_password_lifetime-new-in-v650)                                 | 新しく追加された | パスワードの自動有効期限に関するグローバルポリシーを設定し、ユーザーに定期的なパスワード変更を義務付けます。デフォルト値`0` 、パスワードの有効期限が切れないことを示します。                                                                                                                                                                                                                                                               |
 | [`disconnect_on_expired_password`](/system-variables.md#disconnect_on_expired_password-new-in-v650)                       | 新しく追加された | パスワードの有効期限が切れたときにTiDBがクライアント接続を切断するかどうかを示します。この変数は読み取り専用です。                                                                                                                                                                                                                                                                                            |

diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md
@@ -118,7 +118,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone
     `SURVIVAL_PREFERENCES` 、データの災害時における耐障害性を高めるためのデータ耐障害性設定を提供します。 `SURVIVAL_PREFERENCE`を指定することで、以下の項目を制御できます。
 
     - クラウドリージョンをまたいでデプロイされたTiDBクラスタの場合、あるクラウドリージョンで障害が発生しても、指定されたデータベースまたはテーブルは別のクラウドリージョンで存続できます。
-    - 単一のクラウドリージョンにデプロイされたTiDBクラスタの場合、可用性ゾーンに障害が発生した場合でも、指定されたデータベースまたはテーブルは別の可用性ゾーンで存続できます。
+    - 単一のクラウドリージョンにデプロイされたTiDBクラスタの場合、アベイラビリティゾーンに障害が発生した場合でも、指定されたデータベースまたはテーブルは別のアベイラビリティゾーンで存続できます。
 
     詳細については、 [ドキュメント](/placement-rules-in-sql.md#specify-survival-preferences)を参照してください。
 

diff --git a/system-variables.md b/system-variables.md
@@ -1050,7 +1050,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count';
 - デフォルト値: `4096`
 - 範囲: `[0, 9223372036854775807]`
 - 単位：バイト
-- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じ可用性ゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取り要求を同じ可用性ゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取り要求を送信します。
+- この変数は、 [`tidb_replica_read`](#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じアベイラビリティゾーン内のレプリカに送信することを優先するしきい値を制御するために使用されます。推定結果がこのしきい値以上の場合、TiDB は読み取り要求を同じアベイラビリティゾーン内のレプリカに送信することを優先します。それ以外の場合は、TiDB はリーダーレプリカに読み取り要求を送信します。
 
 ### tidb_advancer_check_point_lag_limit <span class="version-mark">New in v8.5.5</span>
 

diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md
@@ -1,11 +1,11 @@
 ---
 title: Three Availability Zones in Two Regions Deployment
-summary: 2つのリージョンにある 3つのアベイラビリティーゾーンへのデプロイメント ソリューションを学習します。
+summary: 2つのリージョンにある 3つのアベイラビリティゾーンへのデプロイメント ソリューションを学習します。
 ---
 
 # 2つのリージョンに3つのアベイラビリティゾーンを展開 {#three-availability-zones-in-two-regions-deployment}
 
-このドキュメントでは、2つのリージョン展開における 3つの可用性ゾーン (AZ) のアーキテクチャと構成について説明します。
+このドキュメントでは、2つのリージョン展開における 3つのアベイラビリティゾーン (AZ) のアーキテクチャと構成について説明します。
 
 このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。
 

diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md
@@ -58,7 +58,7 @@ Starterプランは、 TiDB Cloudを初めて利用する方に最適です。
 - **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、ストレージとコンピューティングリソースを自動的に調整します。
 - **予測可能な料金体系**：コンピューティングリソースのストレージとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。
 
-TiDB Cloud Essentialは、ゾーン型高可用性を提供します。これは、すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。
+TiDB Cloud Essentialは、ゾーン型高可用性を提供します。これは、すべてのコンポーネントを同じアベイラビリティゾーン内に配置することで、ネットワークレイテンシーを低減します。詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。
 
 </CustomContent>
 
@@ -71,8 +71,8 @@ TiDB Cloud Essentialは、ゾーン型高可用性を提供します。これは
 
 TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2種類の高可用性機能を提供します。
 
-- ゾーン高可用性：すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。
-- 地域別高可用性：ノードを複数の可用性ゾーンに分散させることで、インフラストラクチャの最大限の分離性と冗長性を実現します。
+- ゾーン高可用性：すべてのコンポーネントを同じアベイラビリティゾーン内に配置することで、ネットワークレイテンシーを低減します。
+- 地域別高可用性：ノードを複数のアベイラビリティゾーンに分散させることで、インフラストラクチャの最大限の分離性と冗長性を実現します。
 
 詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。
 

diff --git a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md
@@ -30,7 +30,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb-
 
 変更フィードのダウンストリームサービスがAWS上でホストされている場合は、接続タイプに応じて以下の情報を収集してください。
 
-- **AWS Endpoint Service**: ダウンストリームサービスのエンドポイントサービス名と、ダウンストリームサービスがデプロイされている可用性ゾーン（AZ）。
+- **AWS Endpoint Service**: ダウンストリームサービスのエンドポイントサービス名と、ダウンストリームサービスがデプロイされているアベイラビリティゾーン（AZ）。
 
     ダウンストリーム サービスでプライベートエンドポイントサービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスを設定します。
 
@@ -45,7 +45,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb-
 変更フィードのダウンストリームサービスがAlibaba Cloudでホストされている場合は、以下の情報を収集してください。
 
 - ダウンストリームサービスのプライベートエンドポイントサービスの名前
-- ダウンストリームサービスがデプロイされている可用性ゾーン（AZ）
+- ダウンストリームサービスがデプロイされているアベイラビリティゾーン（AZ）
 
 TiDB Cloud VPCへのアクセスを許可するには、エンドポイントサービスの許可リストにTiDB CloudのAlibaba CloudアカウントIDを追加する必要があります。