pingcap · yahonda · Jul 15, 2026 · Jul 21, 2026
diff --git a/ai/guides/auto-embedding.md b/ai/guides/auto-embedding.md
@@ -29,7 +29,7 @@ embed_func = EmbeddingFunction(
 
 ### ステップ2. テーブルとベクトルフィールドを作成する {#step-2-create-a-table-and-a-vector-field}
 
-テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`使用します。
+テーブル スキーマにベクトル フィールドを作成するには、 `embed_func.VectorField()`を使用します。
 
 自動埋め込みを有効にするには、埋め込みたいフィールドに`source_field`設定します。
 

diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md
@@ -13,7 +13,7 @@ summary: アプリケーションでフィルタリングを使用する方法
 
 [`pytidb`](https://github.com/pingcap/pytidb)は、開発者が AI アプリケーションを効率的に構築できるように設計されています。
 
-`pytidb`使用する場合、 `table.query()` 、 `table.delete()` 、 `table.update()` 、および`table.search()`メソッドに**filters**パラメータを渡すことでフィルタリングを適用できます。
+`pytidb`を使用する場合、 `table.query()` 、 `table.delete()` 、 `table.update()` 、および`table.search()`メソッドに**filters**パラメータを渡すことでフィルタリングを適用できます。
 
 **フィルター**パラメータは、 [辞書フィルター](#dictionary-filters)と[SQL文字列フィルター](#sql-string-filters) 2 つの形式をサポートします。
 

diff --git a/ai/guides/raw-queries.md b/ai/guides/raw-queries.md
@@ -43,7 +43,7 @@ client.execute(
 -   `to_rows()`
 -   `scalar()`
 
-#### ピダンティックモデルとして {#as-pydantic-model}
+#### Pydantic モデルとして {#as-pydantic-model}
 
 `to_pydantic()`メソッドは、Pydantic モデルのリストを返します。
 

diff --git a/ai/guides/tables.md b/ai/guides/tables.md
@@ -11,7 +11,7 @@ TiDBは、関連するデータのコレクションを整理して保存する
 
 このドキュメントでは、 [`pytidb`](https://github.com/pingcap/pytidb)を使用してテーブルを操作する方法を説明します。
 
-`pytidb`は、開発者が AI アプリケーションを効率的に構築できるように設計されています。
+`pytidb`は、TiDB 向けの公式 Python SDK であり、開発者が AI アプリケーションを効率的に構築できるように設計されています。
 
 > **Note:**
 >
@@ -21,7 +21,7 @@ TiDBは、関連するデータのコレクションを整理して保存する
 
 ### TableModelの使用 {#using-tablemodel}
 
-`pytidb` 、テーブルのスキーマを表す`TableModel`クラスを提供します。このクラスは[ピダンティックモデル](https://docs.pydantic.dev/latest/concepts/models/)と互換性があり、宣言的にテーブルを定義できます。
+`pytidb`は、テーブルのスキーマを表す`TableModel`クラスを提供します。このクラスは[Pydantic モデル](https://docs.pydantic.dev/latest/concepts/models/)と互換性があり、宣言的にテーブルを定義できます。
 
 次の例では、次の列を持つ`items`という名前のテーブルを作成します。
 
@@ -33,7 +33,7 @@ TiDBは、関連するデータのコレクションを整理して保存する
 <SimpleTab groupId="language">
 <div label="Python" value="python">
 
-[データベースに接続する](/ai/guides/connect.md)を使用して`pytidb`インスタンスを取得したら、 `client`メソッドを`create_table`してテーブルを作成できます。
+[データベースに接続する](/ai/guides/connect.md)で`pytidb`を使用して`client`インスタンスを取得したら、 `create_table`メソッドを使用してテーブルを作成できます。
 
 ```python hl_lines="12"
 from pytidb.schema import TableModel, Field, VectorField
@@ -153,9 +153,9 @@ VALUES
 </div>
 </SimpleTab>
 
-### ディクト付き {#with-dict}
+### dict を使用 {#with-dict}
 
-`dict`使って行を表し、それをテーブルに挿入することもできます。この方法はより柔軟で、データを挿入するために`TableModel`使用する必要がありません。
+`dict`を使って行を表し、それをテーブルに挿入することもできます。この方法はより柔軟で、データを挿入するために`TableModel`を使用する必要がありません。
 
 単一のレコードを挿入するには:
 
@@ -192,7 +192,7 @@ VALUES (1, 'TiDB is a distributed SQL database', '[0.1, 0.2, 0.3]', '{"category"
 
 > **Note:**
 >
-> テーブル内にレコードIDが既に存在する場合、 `table.save()`レコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`使用します。
+> テーブル内にレコードIDが既に存在する場合、 `table.save()`はレコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`を使用します。
 
 <SimpleTab groupId="language">
 <div label="Python" value="python">
@@ -353,7 +353,7 @@ WHERE
 
 [フィルター](/ai/guides/filtering.md)のレコードを削除するには、 `table.delete()`メソッドを使用します。
 
-**例: `id` 2のレコードを削除する**
+**例: `id`が2のレコードを削除する**
 
 ```python
 table.delete(
@@ -368,7 +368,7 @@ table.delete(
 
 `DELETE`ステートメントを使用して、 [フィルター](/ai/guides/filtering.md)のレコードを削除します。
 
-**例: `id` 2のレコードを削除する**
+**例: `id`が2のレコードを削除する**
 
 ```sql
 DELETE FROM items WHERE id = 2;

diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md
@@ -20,7 +20,7 @@ summary: アプリケーションでベクトル検索を使用する方法を
 <SimpleTab groupId="language">
 <div label="Python" value="python">
 
-`client.create_table()`使用してテーブルを作成し、 `VectorField`使用してベクトル フィールドを定義できます。
+`client.create_table()`を使用してテーブルを作成し、 `VectorField`を使用してベクトル フィールドを定義できます。
 
 次の例では、4 つの列を持つ`documents`テーブルを作成します。
 

diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md
@@ -33,7 +33,7 @@ OpenAI `text-embedding-3-large`などの特定の埋め込みモデルは[埋め
 
 ベクトル埋め込みデータは通常サイズが大きく、検索プロセスでのみ使用されます。クエリ結果からベクトル列を除外することで、TiDBサーバーとSQLクライアント間で転送されるデータ量を大幅に削減し、クエリパフォーマンスを向上させることができます。
 
-ベクトル列を除外するには、 `SELECT *`使用してすべての列を取得するのではなく、 `SELECT`句で取得する列を明示的にリストします。
+ベクトル列を除外するには、 `SELECT *`を使用してすべての列を取得するのではなく、 `SELECT`句で取得する列を明示的にリストします。
 
 ## インデックスをウォームアップする {#warm-up-the-index}
 

diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md
@@ -144,7 +144,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES;
 
     詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)参照してください。
 
-さらに、 `ADMIN SHOW DDL JOBS;`実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全に正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。
+さらに、 `ADMIN SHOW DDL JOBS;`を実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`の値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全には正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。
 
 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used}
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -168,7 +168,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
 -   解決：
 
-    `admin show ddl`実行して、時間のかかる`add index`操作が実行されているかどうかを確認します。
+    `admin show ddl`を実行して、時間のかかる`add index`操作が実行されているかどうかを確認します。
 
 ## PDアラートルール {#pd-alert-rules}
 
@@ -447,7 +447,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
 -   解決：
 
-    1.  `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。
+    1.  `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`を実行して、GC リーダーに対応する`tidb-server`を見つけます。
     2.  `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。
     3.  この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。
 
@@ -768,7 +768,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
 -   解決：
 
-    リージョン分割の速度は書き込み速度よりも遅いです。この問題を軽減するには、TiDBをバッチ分割をサポートするバージョン（2.1.0-rc1以上）にアップデートすることをお勧めします。一時的にアップデートできない場合は、 `pd-ctl operator add split-region <region_id> --policy=approximate`使用して手動でリージョンを分割できます。
+    リージョン分割の速度は書き込み速度よりも遅いです。この問題を軽減するには、TiDBをバッチ分割をサポートするバージョン（2.1.0-rc1以上）にアップデートすることをお勧めします。一時的にアップデートできない場合は、 `pd-ctl operator add split-region <region_id> --policy=approximate`を使用して手動でリージョンを分割できます。
 
 ## TiFlashアラートルール {#tiflash-alert-rules}
 
@@ -844,7 +844,7 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー
 -   解決：
 
     -   Grafana Node Exporter ダッシュボードでホストのメモリ パネルを確認し、使用済みメモリが多すぎるかどうか、使用可能なメモリが少なすぎるかどうかを確認します。
-    -   マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。
+    -   マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`を実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。
 
 ### 警告レベルのアラート {#warning-level-alerts}
 
@@ -890,8 +890,8 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー
 
 -   解決：
 
-    -   マシンにログインし、 `ss -s`実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。
-    -   `netstat`実行して異常なリンクがないか確認します。
+    -   マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。
+    -   `netstat`を実行して異常なリンクがないか確認します。
 
 #### `NODE_disk_read_latency_more_than_32ms` {#node-disk-read-latency-more-than-32ms}
 

diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md
@@ -41,7 +41,7 @@ summary: スロークエリを見つけて分析する方法を学びます。
 上記の方法は、以下の点で異なります。
 
 -   スロー ログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスロー ログを直感的にクエリおよび分析できます)。
--   `EXPLAIN ANALYZE`実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。
+-   `EXPLAIN ANALYZE`を実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。
 
 まとめると、スローログと`EXPLAIN ANALYZE`ステートメントは、SQLクエリの実行がどのコンポーネント（TiDBまたはTiKV）でどの段階で遅いのかを判断するのに役立ちます。これにより、クエリのパフォーマンスボトルネックを正確に特定できます。
 
@@ -102,7 +102,7 @@ SQL文の実行中に、TiDBは複数のTiKVインスタンスからデータを
 
 TiKV上に古いMVCCバージョンが多すぎる場合、またはGCのMVCC履歴データの保持期間が長い場合、過剰なMVCCバージョンが蓄積される可能性があります。これらの不要なMVCCバージョンを処理すると、スキャンのパフォーマンスに影響する可能性があります。
 
-`Total_keys`と`Processed_keys`確認してください。大きく異なる場合は、TiKVインスタンスに古いバージョンのキーが多すぎます。
+`Total_keys`と`Processed_keys`を確認してください。大きく異なる場合は、TiKVインスタンスに古いバージョンのキーが多すぎます。
 
     ...
     # Total_keys: 2215187529 Processed_keys: 1108056368

diff --git a/as-of-timestamp.md b/as-of-timestamp.md
@@ -23,7 +23,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 
 正確な時刻を指定したい場合は、 `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`のような式を使用することを**お勧めします**。
 
-時間範囲を指定する場合は、句内で[`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`句の例をいくつか示します。
 
@@ -42,7 +42,7 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標
 
 ## 使用例 {#usage-examples}
 
-このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`句の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`使用する方法を示します。
+このセクションでは、いくつかの例を用いて、 `AS OF TIMESTAMP`句の様々な使用方法を説明します。まず、リカバリ用のデータの準備方法を紹介し、次に`SELECT` 、 `START TRANSACTION READ ONLY AS OF TIMESTAMP` 、 `SET TRANSACTION READ ONLY AS OF TIMESTAMP`でそれぞれ`AS OF TIMESTAMP`を使用する方法を示します。
 
 ### データサンプルを準備する {#prepare-data-sample}