pingcap · yahonda · Jul 24, 2026
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -121,7 +121,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ
 ### ステップ8: プルリクエストを作成する {#step-8-create-a-pull-request}
 
 1.  [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます)
-2.  `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。5 [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)参照してください。
+2.  `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。
 
 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。
 

diff --git a/agg-distinct-optimization.md b/agg-distinct-optimization.md
@@ -39,7 +39,7 @@ TiDB の[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distin
 
 </CustomContent>
 
-この最適化の例として、以下のクエリを見てみましょう。1 `tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。
+この最適化の例として、以下のクエリを見てみましょう。`tidb_opt_distinct_agg_push_down`デフォルトで無効になっており、集計関数はTiDBレイヤーで実行されます。この最適化を有効にするために値を`1`に設定すると、 `count(distinct a)`の`distinct a`部分が TiKV またはTiFlashコプロセッサーにプッシュされます。TiKVコプロセッサーには、列 a の重複値を削除する HashAgg_5 があります。これにより、TiDBレイヤーにおける`HashAgg_8`の計算オーバーヘッドが削減される可能性があります。
 
 ```sql
 mysql> desc select count(distinct a) from test.t;

diff --git a/ai/guides/image-search.md b/ai/guides/image-search.md
@@ -36,7 +36,7 @@ image_embed = EmbeddingFunction(
 
 ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-vector-field}
 
-`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。3 `source_field`画像のURLを格納するフィールドを指定するためのパラメータです。
+`VectorField()`画像の埋め込みを格納するためのベクトルフィールドを定義します。`source_field`画像のURLを格納するフィールドを指定するためのパラメータです。
 
 ```python
 from pytidb.schema import TableModel, Field

diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md
@@ -323,7 +323,7 @@ results = (
 
 > **Note:**
 >
-> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。3 `.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。
+> ベクトルインデックスを使用する場合、最後の`limit`が非常に小さいと結果の精度が低下する可能性があります。`.num_candidate()`の方法を使用すると、ベクトル検索フェーズでベクトルインデックスから取得する候補の数を、 `limit`番目のパラメータを変更せずに制御できます。
 
 > `num_candidate`値を大きくすると、一般的に再現率は向上しますが、クエリのパフォーマンスが低下する可能性があります。データセットと精度要件に応じてこの値を調整してください。
 

diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md
@@ -212,7 +212,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し
 1 row in set (0.01 sec)
 ```
 
-ベクトルを明示的に文字列表現にキャストすることもできます。1関数`VEC_AS_TEXT()`例に挙げましょう。
+ベクトルを明示的に文字列表現にキャストすることもできます。`VEC_AS_TEXT()`関数の使用を例に挙げましょう。
 
 ```sql
 -- The string is first implicitly cast to a vector, and then the vector is explicitly cast to a string, thus returning a string in the normalized format:

diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md
@@ -130,7 +130,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+
 ```
 
--   インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。5 `ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。
+-   インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED` 0になると、インデックス構築が完了します。
 
     参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。
 
@@ -148,7 +148,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 
 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used}
 
-クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。9 `TableFullScan`キュータの`operator info`列に`annIndex:`表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。
+クエリがベクトルインデックスを使用しているかどうかを確認するには、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md)または[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md)ステートメントを使用します。`TableFullScan`エグゼキュータの`operator info`列に`annIndex:`が表示されている場合、このテーブルスキャンはベクトルインデックスを使用していることを意味します。
 
 **例: ベクトルインデックスが使用される**
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -406,7 +406,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
 -   説明：
 
-    低速TiKVノードがあります。1 `raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)参照してください。
+    低速TiKVノードがあります。`raftstore.inspect-interval` TiKV低速ノードの検出を制御します。詳細については[`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)を参照してください。
 
 -   解決：
 
@@ -467,7 +467,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     1.  ネットワークがクリアかどうかを確認してください。
     2.  リモート TiKV がダウンしていないかどうかを確認します。
-    3.  リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total)
+    3.  リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。
 
 #### `TiKV_channel_full_total` {#tikv-channel-full-total}
 
@@ -555,7 +555,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     1.  TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。
     2.  ホットスポットがあるかどうかを確認します。
-    3.  コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。7 `over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。
+    3.  コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`あるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。
 
 #### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv-raftstore-thread-cpu-seconds-total}
 
@@ -567,7 +567,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     このルールは、 Raftstoreによる CPU 使用率を監視します。値が高い場合、 Raftstoreスレッドへの負荷が高いことを示します。
 
-    アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。3 `raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。
+    アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。`raftstore.store-pool-size`デフォルトで 2 なので、アラートしきい値は 1.6 になります。
 
 -   解決：
 

diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md
@@ -59,7 +59,7 @@ summary: スロークエリを見つけて分析する方法を学びます。
 
 ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing}
 
-TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
+TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
 
 ```sql
 +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+

diff --git a/as-of-timestamp.md b/as-of-timestamp.md
@@ -21,9 +21,9 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 -   [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md)
 -   [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md)
 
-正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。3 関数を使用して、現在時刻を`NOW(3)`秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
+正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。
 
-時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`使用する必要があります。5 と`t2` `t1`範囲の両端であり、datetime 値または時間関数を使用して指定できます。
+時間範囲を指定する場合は、句内で[`TIDB_BOUNDED_STALENESS()`](/functions-and-operators/tidb-functions.md#tidb_bounded_staleness)関数を使用できます。この関数を使用すると、TiDB は指定された時間範囲内で適切なタイムスタンプを選択します。「適切」とは、このタイムスタンプより前に開始され、アクセス先のレプリカにコミットされていないトランザクションがないことを意味します。つまり、TiDB はアクセス先のレプリカに対して読み取り操作を実行でき、読み取り操作がブロックされていないことを意味します。この関数を呼び出すには`TIDB_BOUNDED_STALENESS(t1, t2)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。
 
 `AS OF TIMESTAMP`句の例をいくつか示します。
 

diff --git a/auto-increment.md b/auto-increment.md
@@ -27,7 +27,7 @@ summary: TiDB の AUTO_INCREMENT` 列属性について学習します。
 
 ## コンセプト {#concept}
 
-`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。2 `INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
+`AUTO_INCREMENT` 、デフォルトの列値を自動的に入力するために使用される列属性です。`INSERT`ステートメントで`AUTO_INCREMENT`番目の列の値が指定されていない場合、システムは自動的にこの列に値を割り当てます。
 
 パフォーマンス上の理由から、各TiDBサーバーには、 `AUTO_INCREMENT`個の数値が一括で割り当てられます（デフォルトでは3万個）。つまり、 `AUTO_INCREMENT`数値は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調なものになります。
 
@@ -94,7 +94,7 @@ TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装しま
 CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int);
 ```
 
-クラスター内に2つのTiDBインスタンス（ `A`と`B`があるとします。7テーブルに対してそれぞれ`t`と`B` `A` `INSERT`ステートメントを実行すると、次のようになります。
+クラスター内に2つのTiDBインスタンス（ `A`と`B` ）があるとします。`A`と`B`でそれぞれ`t`テーブルに対して`INSERT`ステートメントを実行すると、次のようになります。
 
 ```sql
 INSERT INTO t (c) VALUES (1)

diff --git a/auto-random.md b/auto-random.md
@@ -177,7 +177,7 @@ TiDBインスタンスが1つの場合、ノードは明示的な挿入を処理
 ALTER TABLE t AUTO_RANDOM_BASE=0;
 ```
 
-このステートメントは適切な基数を自動的に決定します。1 `Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。
+このステートメントは適切な基数を自動的に決定します。`Can't reset AUTO_INCREMENT to 0 without FORCE option, using XXX instead`ような警告メッセージが表示されますが、基数は変更さ**れる**ため、この警告は無視しても問題ありません。
 
 > **Note:**
 >
-Original file line number
+Diff line change
@@ Expand Up @@
     ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing}
-    TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
+    TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
     ```sql
     +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+
@@ Expand Down @@