pingcap · yahonda · Jul 15, 2026 · Jul 15, 2026 · Jul 15, 2026 · Jul 15, 2026
diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md
@@ -14,7 +14,7 @@ summary: アプリケーションで複数のテーブル結合を使用する
 <SimpleTab groupId="language">
 <div label="Python" value="python">
 
-すでに[TiDBに接続](/ai/guides/connect.md)使用して`TiDBClient`あると仮定します。
+すでに[TiDBに接続](/ai/guides/connect.md)し、`TiDBClient`インスタンスがあるものと仮定します。
 
 `documents`テーブルを作成し、いくつかのサンプル データを挿入します。
 

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}
 

diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -365,7 +365,7 @@ TiDBは新しい行とインデックスエントリを「右端」のリージ
 >
 > このセクションでは、読み取りおよび書き込みホットスポットを軽減するための例として、パーティションテーブルを使用します。TiDB は、 [`AUTO_INCREMENT`](/auto-increment.md)や[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)などのホットスポット軽減のための追加機能も提供しています。
 >
-> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)参照してください。
+> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`を設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)を参照してください。
 
 ### パーティショニングの仕組み {#how-partitioning-works}
 

diff --git a/best-practices/uuid.md b/best-practices/uuid.md
@@ -22,7 +22,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment.
 
 ### バイナリとして保存 {#store-as-binary}
 
-テキスト形式のUUID形式は次のようになります`ab06f63e-8fe7-11ec-a514-5405db7aad56`は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。
+テキスト形式のUUID（例えば`ab06f63e-8fe7-11ec-a514-5405db7aad56`）は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。
 
 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys}
 

diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md
@@ -77,7 +77,7 @@ Global Flags:
 -   `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。
 -   `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。
 -   `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。
--   `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
+-   `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
 
 使用例:
 
@@ -349,7 +349,7 @@ Global Flags:
 
 -   `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。
 -   `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。
--   `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
+-   `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
 
 使用例:
 
@@ -390,7 +390,7 @@ Global Flags:
 
 このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。
 
-`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
+`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
 
 使用例:
 
@@ -441,15 +441,15 @@ Global Flags:
 
 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。
 
--   `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
+-   `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
 -   `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。
 -   `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。
 -   `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。
 -   `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。
 -   `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。
 -   `--pd` : 復元クラスターの PD アドレス。
 -   `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。
--   `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
+-   `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。
 
 使用例:
 

diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md
@@ -160,7 +160,7 @@ sequenceDiagram
 ### SSTファイルの保存形式 {#storage-format-of-sst-files}
 
 -   SST ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。
--   SST ファイルのバックアップ データのエンコード形式の詳細については、「テーブルデータ[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)参照してください。
+-   SST ファイルのバックアップ データのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。
 
 ### バックアップファイルの構造 {#structure-of-backup-files}
 

diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md
@@ -182,7 +182,7 @@ tiup br restore full \
 
 上記のコマンドでは、次のようになります。
 
--   `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。
+-   `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。
 -   `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。
 -   `--log-file` : `br`ログが書き込まれる対象ファイル。
 

diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md
@@ -125,7 +125,7 @@ TIMESTAMP[(fsp)]
 
 #### タイムゾーンの処理 {#timezone-handling}
 
-`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。5 `TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。
+`TIMESTAMP`保存する場合、TiDB は`TIMESTAMP`値を現在のタイムゾーンから UTC タイムゾーンに変換します。`TIMESTAMP`取得する場合、TiDB は保存されている`TIMESTAMP`値を UTC タイムゾーンから現在のタイムゾーンに変換します（注: `DATETIME`この方法では処理されません）。各接続のデフォルトのタイムゾーンはサーバーのローカルタイムゾーンですが、環境変数`time_zone`で変更できます。
 
 > **警告：**
 >

diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md
@@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-aws-appflow-integration/','/ja/tidb/dev/dev
 
 # TiDBとAmazon AppFlowを統合する {#integrate-tidb-with-amazon-appflow}
 
-[Amazon AppFlow](https://aws.amazon.com/appflow/) Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。
+[Amazon AppFlow](https://aws.amazon.com/appflow/)は、Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。
 
 このドキュメントでは、TiDBをAmazon AppFlowと統合する方法について説明し、 TiDB Cloud Starterインスタンスの統合を例として取り上げます。
 

diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md
@@ -93,7 +93,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67
 
 > **注記：**
 >
-> -   現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。
+> -   現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)。
 >
 > -   TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。
 

diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md
@@ -325,7 +325,7 @@ TiDBで`CHECK`制約の適用を有効にするには、次のシステム変数
 SET GLOBAL tidb_enable_check_constraint=ON;
 ```
 
-この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)参照してください。 。
+この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)を参照してください。
 
 ## 次のステップ {#next-steps}
 

diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md
@@ -24,7 +24,7 @@ TiDB ベクトル検索を開始するには、次のチュートリアルを参
 
 開発を加速させるために、TiDBベクトル検索を一般的なAIフレームワーク（LlamaIndexやLangChainなど）、埋め込みサービス（Jina AIなど）、ORMライブラリ（SQLAlchemy、Peewee、Django ORMなど）と統合できます。ニーズに最適なものを選択できます。
 
-詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)参照してください.
+詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)を参照してください。
 
 ## テキスト検索 {#text-search}