pingcap · qiancai · Sep 8, 2026 · Sep 7, 2026 · Sep 7, 2026 · Sep 7, 2026
diff --git a/ai/examples/memory-with-pytidb.md b/ai/examples/memory-with-pytidb.md
@@ -94,7 +94,7 @@ python main.py
 1. デフォルトのチャットセッションで自己紹介をしてください。例えば、「こんにちは、ジョンです。ソフトウェアエンジニアとして働いていて、ギターが大好きです。」など。
 2. 入力された情報はメモリビューアで確認できます。
 3. 新しいチャットセッションを開始するには、サイドバーの**New chat**をクリックしてください。
-4. 新しいチャットセッションで「私は誰ですか？」と質問してください。AIが過去の会話からあなたの情報を記憶します。
+4. 新しいチャットセッションで"Who am I?"と質問してください。AIが過去の会話からあなたの情報を記憶します。
 
 ## コマンドラインアプリケーションでメモリを操作する {#interact-with-memory-in-command-line-application}
 
@@ -116,7 +116,7 @@ Goodbye!
 
 最初の会話の後、AIアシスタントはあなたが提供した情報を記憶し、今後の質問に答える際にそれを使用します。
 
-これで、新しいチャットセッションを開始して、AIアシスタントに「私は誰ですか？」と尋ねることができます。
+これで、新しいチャットセッションを開始して、AIアシスタントに"Who am I?"と尋ねることができます。
 
 **別のチャットセッションでの会話例：**
 

diff --git a/ai/guides/filtering.md b/ai/guides/filtering.md
@@ -174,7 +174,7 @@ results = table.query(
 ).to_list()
 ```
 
-**例: JSONフィールド`meta.category`が「tech」に等しいレコードをフィルタリングする**
+**例: JSONフィールド`meta.category`が'tech'に等しいレコードをフィルタリングする**
 
 ```python
 results = table.query(

diff --git a/ai/guides/tables.md b/ai/guides/tables.md
@@ -293,7 +293,7 @@ result = table.query(
 
 レコードをフィルタリングするには、 `WHERE`句を使用します。
 
-**例: カテゴリ「データベース」のレコードを10件取得する**
+**例: カテゴリ"database"のレコードを10件取得する**
 
 ```sql
 SELECT * FROM items WHERE meta->>'$.category' = 'database' LIMIT 10;

diff --git a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md
@@ -261,7 +261,7 @@ def save_entities_with_embedding(session, contents):
 
 ### ステップ8．アプリケーションを実行する {#step-8-run-the-application}
 
-1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 (「TiDB とは何ですか？」など) を尋ね、モデルから結果を生成するための以下のコードを追加します。
+1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 ("What is TiDB?"など) を尋ね、モデルから結果を生成するための以下のコードを追加します。
 
     ```python
     if __name__ == "__main__":

diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-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}
 
-このチュートリアルでは、**セマンティック検索**機能を提供するシンプルなAIアプリケーションの開発方法を説明します。従来のキーワード検索とは異なり、セマンティック検索はクエリの背後にある意味をインテリジェントに理解し、最も関連性の高い結果を返します。たとえば、「犬」「魚」「木」というタイトルの文書があり、「泳ぐ動物」を検索すると、アプリケーションは「魚」を最も関連性の高い結果として識別します。
+このチュートリアルでは、**セマンティック検索**機能を提供するシンプルなAIアプリケーションの開発方法を説明します。従来のキーワード検索とは異なり、セマンティック検索はクエリの背後にある意味をインテリジェントに理解し、最も関連性の高い結果を返します。たとえば、"dog"、"fish"、"tree"というタイトルの文書があり、"a swimming animal"を検索すると、アプリケーションは"fish"を最も関連性の高い結果として識別します。
 
 このチュートリアルでは、 [TiDB ベクトル検索](/ai/concepts/vector-search-overview.md)、Python、 [TiDB Vector SDK for Python](https://github.com/pingcap/tidb-vector-python) 、および AI モデルを使用して、この AI アプリケーションを開発します。
 
@@ -167,7 +167,7 @@ vector_store = TiDBVectorClient(
 
 ### ステップ6．テキストデータを埋め込み、ベクトルを保存する {#step-6-embed-text-data-and-store-the-vectors}
 
-このステップでは、「dog」、「fish」、「tree」などの単語を含むサンプル文書を準備します。以下のコードは`text_to_embedding()`関数を使用してこれらのテキスト文書をベクトル埋め込みに変換し、ベクトルストアに挿入します。
+このステップでは、"dog"、"fish"、"tree"などの単語を含むサンプル文書を準備します。以下のコードは`text_to_embedding()`関数を使用してこれらのテキスト文書をベクトル埋め込みに変換し、ベクトルストアに挿入します。
 
 ```python
 documents = [
@@ -201,7 +201,7 @@ vector_store.insert(
 
 ### ステップ7．意味検索を実行する {#step-7-perform-semantic-search}
 
-このステップでは、「泳ぐ動物」という単語を検索しますが、既存の文書にはこの単語と直接一致するものはありません。
+このステップでは、"a swimming animal"という単語を検索しますが、既存の文書にはこの単語と直接一致するものはありません。
 
 以下のコードは`text_to_embedding()`関数を再度使用してクエリテキストをベクトル埋め込みに変換し、その埋め込みを使用してクエリを実行して、最も近い上位 3つの一致を見つけます。
 

diff --git a/alert-rules.md b/alert-rules.md
@@ -449,7 +449,7 @@ summary: TiDB クラスターのアラートルールについて学習します
 
     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)ください。
+    3. この時間中にGCワーカーがロックを解決中（最後のログは"start resolve locks"）または範囲を削除中（最後のログは"start delete {number} ranges"）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受けて](/support.md)ください。
 
 ### 重大レベルのアラート {#critical-level-alerts-3}
 
@@ -886,11 +886,11 @@ TiCDC アラートルールの詳細な説明については、 [TiCDCアラー
 
 - 説明：
 
-    マシン上には「確立」ステータスの TCP リンクが 50,000 個以上あります。
+    マシン上には"establish"ステータスの TCP リンクが 50,000 個以上あります。
 
 - 解決：
 
-    - マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。
+    - マシンにログインし、 `ss -s`を実行して、現在のシステムで"estab"ステータスにある TCP リンクの数を確認します。
     - `netstat`を実行して異常なリンクがないか確認します。
 
 #### `NODE_disk_read_latency_more_than_32ms` {#node_disk_read_latency_more_than_32ms}

diff --git a/as-of-timestamp.md b/as-of-timestamp.md
@@ -21,7 +21,7 @@ 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」のように秒単位で十分です。`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)`を使用する必要があります。`t1`と`t2`は範囲の両端であり、datetime 値または時間関数を使用して指定できます。
 

diff --git a/benchmark/benchmark-sysbench-v3.md b/benchmark/benchmark-sysbench-v3.md
@@ -1,6 +1,6 @@
 ---
 title: TiDB Sysbench Performance Test Report -- v2.1 vs. v2.0
-summary: TiDB 2.1は「Point Select」テストにおいてTiDB 2.0を上回り、クエリパフォーマンスが50%向上しました。ただし、「Update Non-Index」テストと「Update Index」テストでは、両バージョンのパフォーマンスはほぼ同等でした。このテストは、2018年9月に中国北京で、特定のテスト環境と構成を使用して実施されました。
+summary: TiDB 2.1は`Point Select`テストにおいてTiDB 2.0を上回り、クエリパフォーマンスが50%向上しました。ただし、`Update Non-Index`テストと`Update Index`テストでは、両バージョンのパフォーマンスはほぼ同等でした。このテストは、2018年9月に中国北京で、特定のテスト環境と構成を使用して実施されました。
 ---
 
 # TiDB Sysbench パフォーマンス テスト レポート - v2.1 と v2.0 の比較 {#tidb-sysbench-performance-test-report-v2-1-vs-v2-0}

diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md
@@ -75,9 +75,9 @@ report-interval=10
 db-driver=mysql
 ```
 
-上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST`はTiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`はテストにおける同時接続数で、「8、16、32、64、128、256」の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。
+上記のパラメータは、実際のニーズに合わせて調整できます。`TIDB_HOST`はTiDBサーバーのIPアドレス（設定ファイルに複数のアドレスを含めることはできないため）、 `threads`はテストにおける同時接続数で、"8, 16, 32, 64, 128, 256"の範囲で調整できます。データをインポートする際は、threads = 8または16に設定することをお勧めします`threads`を調整したら、 **config**というファイルを保存します。
 
-サンプル**設定**ファイルとして以下を参照してください。
+サンプル**config**ファイルとして以下を参照してください。
 
 ```txt
 mysql-host=172.16.30.33

diff --git a/benchmark/benchmark-tpch.md b/benchmark/benchmark-tpch.md
@@ -103,6 +103,6 @@ TiDB 2.0:
 以下の点に注意してください。
 
 - 上の図では、オレンジ色のバーはリリース1.0のクエリ結果、青色のバーはリリース2.0のクエリ結果を表しています。Y軸はクエリの処理時間（秒）を表しており、短いほど高速です。
-- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、「NaN」タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。
-- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、「NaN」タグが付けられています。
-- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、「OOM」タグが付けられています。
+- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、"NaN"タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。
+- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、"NaN"タグが付けられています。
+- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、"OOM"タグが付けられています。
diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md
@@ -22,13 +22,13 @@ TiDBはオンラインDDLをサポートしています。つまり、データ
 
 - **論理 DDL文**: 論理 DDL文は通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベースオブジェクトのメタデータのみを変更します。
 
-    TiDBでは、論理DDL文は「汎用DDL」とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。
+    TiDBでは、論理DDL文は"general DDL"（汎用DDL）とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。
 
 - **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。
 
-    TiDBでは、物理DDL文は「reorg DDL」（再編成）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。
+    TiDBでは、物理DDL文は"reorg DDL"（再編成DDL）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と損失のある列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。
 
-    物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノードが、**対応する計算を実行するためにTiDBのCPUリソースを消費することです。
+    物理DDL文の実行は、2つの理由からアプリケーションのワークロードに影響を与える可能性があります。1つは、データの読み取りと新規データの書き込みにTiKVのCPUリソースとI/Oリソースを消費することです。もう1つは、 **DDLオーナーとして機能するTiDBノード**、または**TiDB分散実行フレームワーク（DXF）によって`ADD INDEX`タスクを実行するようにスケジュールされたTiDBノード**が、対応する計算を実行するためにTiDBのCPUリソースを消費することです。
 
     > **Note:**
     >