pingcap · qiancai · Aug 28, 2026 · Aug 27, 2026
diff --git a/ai/guides/vector-search-hybrid-search.md b/ai/guides/vector-search-hybrid-search.md
@@ -160,7 +160,7 @@ df = (
 
 詳細については、 [RRF論文](https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf)を参照してください。
 
-`method`メソッドで`"rrf"`パラメーター`.fusion()`有効にします。
+`.fusion()`メソッドで`method`パラメーターを`"rrf"`に指定することで、相互ランク融合を有効にします。
 
 ```python
 results = (
@@ -185,7 +185,7 @@ results = (
 final_score = vs_weight * vector_score + fts_weight * fulltext_score
 ```
 
-`method`メソッドで`"weighted"`パラメーター`.fusion()`有効にします。
+`.fusion()`メソッドで`method`パラメーターを`"weighted"`に指定することで、加重スコア融合を有効にします。
 
 例えば、ベクトル検索の重みを大きくするには、 `vs_weight`パラメータを 0.7 に、 `fts_weight`パラメータを 0.3 に設定します。
 

diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md
@@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de
 
 # Python を使って TiDB + AI を始めよう {#get-started-with-tidb-ai-via-python}
 
-このドキュメントでは、Python SDK を使用して TiDB で[ベクトル検索](/ai/concepts/vector-search-overview.md)開始する方法を説明します。手順に従って、TiDB で動作する最初の AI アプリケーションを構築します。
+このドキュメントでは、Python SDK を使用して TiDB で[ベクトル検索](/ai/concepts/vector-search-overview.md)を開始する方法を説明します。手順に従って、TiDB で動作する最初の AI アプリケーションを構築します。
 
 このドキュメントに従うことで、以下のことを学ぶことができます。
 

diff --git a/auto-increment.md b/auto-increment.md
@@ -33,7 +33,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。
 
 > **Note:**
 >
-> すべての TiDB サーバーで`AUTO_INCREMENT`数値を単調にしたい場合、TiDB バージョンが v6.5.0 以降であれば、 [MySQL互換モード](#mysql-compatibility-mode)有効にすることをお勧めします。
+> すべての TiDB サーバーで`AUTO_INCREMENT`数値を単調にしたい場合、TiDB バージョンが v6.5.0 以降であれば、 [MySQL互換モード](#mysql-compatibility-mode)を有効にすることをお勧めします。
 
 以下は`AUTO_INCREMENT`の基本的な例です。
 

diff --git a/auto-random.md b/auto-random.md
@@ -182,7 +182,7 @@ ALTER TABLE t AUTO_RANDOM_BASE=0;
 
 > **Note:**
 >
-> `FORCE`キーワードを使用して`AUTO_RANDOM_BASE`から`0`設定することはできません。これを試みるとエラーが発生します。
+> `FORCE`キーワードを使用して`AUTO_RANDOM_BASE`を`0`に設定することはできません。これを試みるとエラーが発生します。
 
 ### オプション2: 特定の基本値を手動で設定する {#option-2-manually-set-a-specific-base-value}
 

diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md
@@ -95,7 +95,7 @@ db-driver=mysql
 
 > **Note:**
 >
-> 楽観的トランザクションモデルを有効にすると（TiDBはデフォルトで悲観的トランザクションモードを使用します）、同時実行の競合が検出されるとTiDBはトランザクションをロールバックします。1～ `tidb_disable_txn_auto_retry` `off`設定すると、トランザクションの競合が発生した後に自動再試行メカニズムが有効になり、トランザクション競合エラーによってSysbenchが終了するのを防ぐことができます。
+> 楽観的トランザクションモデルを有効にすると（TiDBはデフォルトで悲観的トランザクションモードを使用します）、同時実行の競合が検出されるとTiDBはトランザクションをロールバックします。1～ `tidb_disable_txn_auto_retry`を`off`に設定すると、トランザクションの競合が発生した後に自動再試行メカニズムが有効になり、トランザクション競合エラーによってSysbenchが終了するのを防ぐことができます。
 
 データをインポートする前に、TiDBにいくつかの設定を行う必要があります。MySQLクライアントで以下のコマンドを実行してください。
 

diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
@@ -113,7 +113,7 @@ Azure 上のRaft Engineに専用の 32 GB [Ultra Disk](https://learn.microsoft.c
 
 ### 例 3: TiKV マニフェストのRaft Engine用に Google Cloud に専用の pd-ssd ディスクを接続する {#example-3-attach-a-dedicated-pd-ssd-disk-on-google-cloud-for-raft-engine-on-tikv-manifest}
 
-次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`構成する方法を示しています。
+次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`を構成する方法を示しています。
 
 ```
 tikv:

diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md
@@ -206,7 +206,7 @@ listen tidb-cluster                        # Database load balancing.
 
 > **Note:**
 >
-> PROXY プロトコルを使用する前に、TiDBサーバーの構成ファイルで[`proxy-protocol.networks`](/tidb-configuration-file.md#networks)構成する必要があります。
+> PROXY プロトコルを使用する前に、TiDBサーバーの構成ファイルで[`proxy-protocol.networks`](/tidb-configuration-file.md#networks)を構成する必要があります。
 
 ### HAProxyを起動する {#start-haproxy}
 

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
@@ -88,9 +88,9 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ
 >
 > TiDB v3.0 以降では`Region Merge`がデフォルトで有効になっています。
 
-`Region Merge`有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。
+`Region Merge`を有効にすることで、Regionの数を減らすこともできます。`Region Split`は異なり、 `Region Merge`スケジュール設定によって隣接する小さなRegionを結合するプロセスです。データを削除した後、または`Drop Table`もしくは`Truncate Table`ステートメントを実行した後、小さなRegion、あるいは空のRegionを結合することで、リソース消費を削減できます。
 
-次のパラメータを設定して`Region Merge`有効にします。
+次のパラメータを設定して`Region Merge`を有効にします。
 
 ```
 config set max-merge-region-size 54

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
@@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ
 
 > **Note:**
 >
-> **Leaderの排除は**、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果**、Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。
+> **Leaderの排除は**、PDがTiKVの低速ノードにスケジューリング要求を送信し、TiKVが受信したスケジューリング要求を順次実行することで実現されます。**低速I/O**などの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延した要求が処理されるまで**Leaderの排除**要求を処理できない場合があります。その結果**、Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。
diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -261,7 +261,7 @@ TTL パフォーマンスに関する調査結果は次のとおりです。
 - この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。
 - `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。
 
-#### TiDBでTTLと`DROP PARTITION`使用する {#use-ttl-and-drop-partition-in-tidb}
+#### TiDBでTTLと`DROP PARTITION`を使用する {#use-ttl-and-drop-partition-in-tidb}
 
 以下の例では匿名化されたテーブル構造を使用しています。TTLの詳細については、 [TTL（Time to Live）を使用して定期的にデータを削除する](/time-to-live.md)を参照してください。
 

diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md
@@ -62,7 +62,7 @@ PITR でアラート項目を構成するには、次の手順に従います。
 
 1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。
 2. Prometheus 構成ファイルの`rule_files`フィールドに、アラートルール ファイルのパスを追加します。
-3. Prometheusプロセスにシグナル`SIGHUP`送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。
+3. Prometheusプロセスにシグナル`SIGHUP`を送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。
 
 推奨されるアラート項目は次のとおりです。
 

diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md
@@ -5,7 +5,7 @@ summary: TiDB ログバックアップおよび PITR ガイドでは、br コマ
 
 # TiDB ログバックアップと PITR ガイド {#tidb-log-backup-and-pitr-guide}
 
-フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)選択できます。
+フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)ことができます。
 
 br コマンドラインツール (以下、 `br`と呼びます) を使用してデータをバックアップまたは復元する前に、まず[インストール`br`](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。
 

diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md
@@ -471,7 +471,7 @@ Restore KV Files <--------------------------------------------------------------
 >
 > - クラスターを初めて復元する際は、完全なスナップショットデータを指定する必要があります。そうしないと、テーブルIDルールの書き換えにより、新しく作成されたテーブルの一部のデータが正しくなくなる可能性があります。詳細については、GitHub の問題[＃54418](https://github.com/pingcap/tidb/issues/54418)をご覧ください。
 > - 特定の期間のログバックアップデータを繰り返しリストアすることはできません。範囲`[t1=10, t2=20)`のログバックアップデータを繰り返しリストアすると、リストアされたデータに不整合が生じる可能性があります。
-> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`復元した後、 `[t2, t3)`スキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。
+> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`を復元した後、 `[t2, t3)`をスキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。
 
 ### 暗号化されたログバックアップデータを復元する {#restore-encrypted-log-backup-data}
 

diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
@@ -119,7 +119,7 @@ tiup br restore db \
 --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"
 ```
 
-上記のコマンドでは、 `--db`復元するデータベースの名前を指定します。
+上記のコマンドでは、 `--db`は復元するデータベースの名前を指定します。
 
 **テーブルを復元する**
 
@@ -132,7 +132,7 @@ tiup br restore table --pd "${PD_IP}:2379" \
 --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"
 ```
 
-上記のコマンドでは、 `--db`復元するデータベースの名前を指定し、 `--table`復元するテーブルの名前を指定します。
+上記のコマンドでは、 `--db`は復元するデータベースの名前を指定し、 `--table`は復元するテーブルの名前を指定します。
 
 **テーブルフィルターを使用して複数のテーブルを復元します。**
 

diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md
@@ -57,7 +57,7 @@ tiup br backup full --pd "${PD_IP}:2379" \
 - `--cert` : PEM 形式の SSL 証明書へのパスを指定します。
 - `--key` : PEM 形式の SSL 証明書キーへのパスを指定します。
 - `--status-addr` : `br` Prometheus に統計を提供するリスニング アドレスを指定します。
-- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。
+- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整する必要があります。
 - `--pitr-concurrency` : ログ復元中の同時タスクの数。
 - `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。
 - `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。

diff --git a/certificate-authentication.md b/certificate-authentication.md
@@ -285,7 +285,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k
 
 ### ユーザー証明書情報を構成する {#configure-user-certificate-information}
 
-ユーザー証明書情報（ `REQUIRE SUBJECT` `REQUIRE CIPHER`を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報`REQUIRE SAN`検証されるように設定します。以下の文の`<replaceable>` `REQUIRE ISSUER`する情報に置き換えてください。
+ユーザー証明書情報（ `REQUIRE SUBJECT` 、 `REQUIRE ISSUER` 、 `REQUIRE SAN` 、 `REQUIRE CIPHER` ）を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報が検証されるように設定します。以下の文の`<replaceable>`を対応する情報に置き換えてください。
 
 スペースまたは`and`区切り文字として使用して、1つのオプションまたは複数のオプションを設定できます。
 

diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md
@@ -58,9 +58,9 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ
     > - データセキュリティのため、TiDBはトークン作成時にのみトークン情報を表示します。トークン情報を紛失した場合は、古いトークンを削除して新しいトークンを作成できます。
     > - トークンはデータのアップロードにのみ使用されます。
 
-5. Diag にトークンと`region`設定します。
+5. Diag にトークンと`region`を設定します。
 
-    - `clinic.token`設定するには、次のコマンドを実行します。
+    - `clinic.token`を設定するには、次のコマンドを実行します。
 
         ```bash
         tiup diag config clinic.token ${token-value}
-Original file line number
+Diff line change
@@ Expand Up @@
     ### 例 3: TiKV マニフェストのRaft Engine用に Google Cloud に専用の pd-ssd ディスクを接続する {#example-3-attach-a-dedicated-pd-ssd-disk-on-google-cloud-for-raft-engine-on-tikv-manifest}
-    次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`構成する方法を示しています。
+    次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`を構成する方法を示しています。
     ```
     tikv:
@@ Expand Down @@