i18n(ja): add missing object-marker particle (wo) before code-span transitive verbs

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`設定します。
 

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 つの形式をサポートします。
 

ai/guides/tables.md

@@ -155,7 +155,7 @@ VALUES
 
 ### ディクト付き {#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"
 
 > **注記：**
 >
-> テーブル内にレコードIDが既に存在する場合、 `table.save()`​​レコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`使用します。
+> テーブル内にレコードIDが既に存在する場合、 `table.save()`​​レコード全体を上書きします。レコードの一部のみを変更するには、 `table.update()`を使用します。
 
 <SimpleTab groupId="language">
 <div label="Python" value="python">

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`テーブルを作成します。
 

ai/quickstart-via-sql.md

@@ -143,7 +143,7 @@ SELECT * FROM embedded_documents;
 
 この例では、検索語は「泳ぐ動物」であり、それに対応するベクトル埋め込みは`[1,2,3]`であると想定されています。実際のアプリケーションでは、埋め込みモデルを使用して、ユーザーの検索語をベクトル埋め込みに変換する必要があります。
 
-次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。
+次の SQL ステートメントを実行すると、TiDB はテーブル内のベクトル埋め込み間のコサイン距離 ( `[1,2,3]`を計算してソートすることにより、 `vec_cosine_distance` } に最も近い上位 3 つのドキュメントを特定します。
 
 ```sql
 SELECT id, document, vec_cosine_distance(embedding, '[1,2,3]') AS distance

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}
 

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}
 

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}
 

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

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)`を使用する必要があります。5 と`t2` `t1`範囲の両端であり、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}
 

auto-increment.md

@@ -206,7 +206,7 @@ Query OK, 1 row affected (0.03 sec)
 4 rows in set (0.00 sec)
 ```
 
-初期TiDBサーバーに対する新たな`INSERT`操作は、 `AUTO_INCREMENT`の値`4`生成します。これは、初期TiDBサーバーの`AUTO_INCREMENT`キャッシュにまだ割り当て用のスペースが残っているためです。この場合、 `4`の値が`2000001`の後に挿入されるため、値のシーケンスはグローバルに単調であるとは考えられません。
+初期TiDBサーバーに対する新たな`INSERT`操作は、 `AUTO_INCREMENT`の値`4`を生成します。これは、初期TiDBサーバーの`AUTO_INCREMENT`キャッシュにまだ割り当て用のスペースが残っているためです。この場合、 `4`の値が`2000001`の後に挿入されるため、値のシーケンスはグローバルに単調であるとは考えられません。
 
 ```sql
 mysql> INSERT INTO t (a) VALUES (NULL);
@@ -284,7 +284,7 @@ mysql> SELECT * FROM t ORDER BY b;
 11 rows in set (0.00 sec)
 ```
 
-値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`取得しているためです。複数の TiDB サーバーが展開されている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
+値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーが展開されている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
 
 ### キャッシュサイズの制御 {#cache-size-control}
 
@@ -466,7 +466,7 @@ IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発
 -   TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。
 -   `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。
 -   `DEFAULT`列の値と同じ列には指定できません。
--   `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`使用することも含まれます。
--   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`使用して`AUTO_INCREMENT`番目の属性を削除することはできません。
+-   `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。
+-   `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`番目の属性を削除することはできません。
 -   `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。
 -   `AUTO_INCREMENT` `MAX(<auto_increment_column>)`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。