pingcap · qiancai · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026
diff --git a/ai/examples/image-search-with-pytidb.md b/ai/examples/image-search-with-pytidb.md
@@ -61,7 +61,7 @@ EOF
 
 ### ステップ4．データセットをダウンロードして解凍する {#step-4-download-and-extract-the-dataset}
 
-[オックスフォード・ペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。
+[オックスフォードペットデータセット](https://www.robots.ox.ac.uk/~vgg/data/pets/)を使用して、ペット画像をデータベースに読み込んで検索するデモです。
 
 *Linux/macOSの場合：*
 
@@ -86,7 +86,7 @@ streamlit run app.py
 
 サンプルアプリでは、 **Load Sample Data**ボタンをクリックすると、サンプルデータがデータベースに読み込まれます。
 
-または、オックスフォード・ペット・データセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。
+または、オックスフォードペットデータセットのすべてのデータを読み込みたい場合は、 **Load All Data**ボタンをクリックしてください。
 
 ### ステップ7. 検索 {#step-7-search}
 

diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md
@@ -1,13 +1,13 @@
 ---
 title: Checkpoint Backup
-summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイント・バックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。
+summary: TiDB v6.5.0では、中断されたバックアップを再開するためのチェックポイントバックアップ機能が導入され、最初からやり直す必要性が軽減されます。この機能はバックアップ済みのシャードを記録してバックアップを再開しますが、GCメカニズムに依存するため、一部のデータの再バックアップが必要になる場合があります。br`ツールは、データのガベージコレクションを回避するために定期的に`gc-safepoint`を更新し、必要に応じて保持期間を延長できます。
 ---
 
 # チェックポイントバックアップ {#checkpoint-backup}
 
 スナップショットバックアップは、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v6.5.0より前のバージョンでは、中断前にバックアップされたデータはエラーが解決された後でも無効となり、最初からバックアップをやり直す必要がありました。大規模クラスターの場合、これはかなりのコスト増加につながります。
 
-TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイント・バックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。
+TiDB v6.5.0では、バックアップとリストア（BR）にチェックポイントバックアップ機能が導入され、中断されたバックアップを続行できるようになりました。この機能により、中断されたバックアップのほとんどのデータを保持できます。
 
 ## アプリケーションシナリオ {#application-scenarios}
 
@@ -17,13 +17,13 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを
 
 スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。
 
-`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。
+`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイントバックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。
 
 `br`バックアップを再試行する際、外部ストレージからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 `br`チェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。
 
 ## 使用制限 {#usage-limitations}
 
-チェックポイント・バックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。
+チェックポイントバックアップはGCメカニズムに依存しており、バックアップされたすべてのデータを復元できるわけではありません。詳細については、以下のセクションで説明します。
 
 ### バックアップの再試行はGCの前に行う必要があります {#backup-retry-must-be-prior-to-gc}
 

diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md
@@ -7,7 +7,7 @@ summary: TiDB v7.1.0ではチェックポイント復元が導入され、中断
 
 スナップショットの復元やログの復元は、ディスク枯渇やノードクラッシュなどの回復可能なエラーにより中断される可能性があります。TiDB v7.1.0より前のバージョンでは、エラーに対処した後でも中断前の復元の進行状況が無効になり、復元を最初からやり直す必要がありました。大規模クラスターでは、これはかなりの追加コストが発生します。
 
-TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイント・リストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。
+TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポイントリストア機能が導入され、中断されたリストアを再開できるようになりました。この機能により、中断されたリストアのリカバリ進行状況の大部分を保持できます。
 
 ## アプリケーションシナリオ {#application-scenarios}
 

diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md
@@ -152,7 +152,7 @@ JDBC API の使用方法については、 [JDBC公式チュートリアル](htt
 
 #### Prepare APIを使用する {#use-prepare-api}
 
-OLTP（オンライン・トランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。
+OLTP（オンライントランザクション処理）シナリオでは、プログラムからデータベースに送信されるSQL文は、パラメータ変更を除けば、複数のタイプが存在します。そのため、通常の[テキストファイルからの実行](https://docs.oracle.com/javase/tutorial/jdbc/basics/processingsqlstatements.html#executing_queries)ではなく[プリペアドステートメント](https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html)を使用し、プリペアドステートメントを再利用して直接実行することをお勧めします。これにより、TiDBでSQL実行計画を繰り返し解析および生成するオーバーヘッドを回避できます。
 
 現在、ほとんどの上位フレームワークはSQL実行のためにPrepare APIを呼び出しています。開発でJDBC APIを直接使用する場合は、Prepare APIを選択するように注意してください。
 

diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md
@@ -234,9 +234,9 @@ CREATE TABLE `bookshop`.`users` (
 
 `bookshop`アプリケーションを使用して`ratings`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合、 `ratings`テーブル全体の`score`フィールドと`rated_at`フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。
 
-このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。
+このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（Hybrid Transactional and Analytical Processing）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。
 
-TiDBでは、オンライン・トランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。
+TiDBでは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。
 
 ### 列ベースのデータを複製する {#replicate-column-based-data}
 

diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md
@@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-hybrid-oltp-and-olap-queries/','/ja/tidbclo
 
 # HTAPクエリ {#htap-queries}
 
-HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。
+HTAPは、Hybrid Transactional and Analytical Processingの略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。
 
 TiDBは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向ストレージエンジンであるTiFlashを使用します。HTAPでは、行ベースのストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのストレージエンジンはOLTPのパフォーマンスを最適化し、列指向ストレージエンジンはOLAPのパフォーマンスを最適化します。
 

diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md
@@ -1,15 +1,15 @@
 ---
 title: DR Solution Based on Primary and Secondary Clusters
-summary: TiCDCに基づいたプライマリ・セカンダリディザスタリカバリの実装方法を学びましょう。
+summary: TiCDCに基づいたプライマリセカンダリディザスタリカバリの実装方法を学びましょう。
 ---
 
 # プライマリクラスタとセカンダリクラスタに基づく災害復旧ソリューション {#dr-solution-based-on-primary-and-secondary-clusters}
 
 プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスタとセカンダリクラスタで構成されます。プライマリクラスタはユーザーからのリクエストを処理し、セカンダリクラスタはプライマリクラスタからデータをバックアップします。プライマリクラスタに障害が発生した場合、セカンダリクラスタがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。
 
-プライマリ・セカンダリ型災害復旧ソリューションには、以下の利点があります。
+プライマリセカンダリ型災害復旧ソリューションには、以下の利点があります。
 
-- 高可用性：プライマリ・セカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。
+- 高可用性：プライマリセカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。
 - 高速切り替え：プライマリクラスタに障害が発生した場合、システムはセカンダリクラスタに迅速に切り替えてサービスの提供を継続できます。
 - データの一貫性：セカンダリクラスタは、プライマリクラスタのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスタに切り替わった場合でも、データは基本的に最新の状態に保たれます。
 
@@ -408,7 +408,7 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht
 
 > **Note:**
 >
-> プライマリ・セカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。
+> プライマリセカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。
 
 ### プライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する {#perform-bidirectional-replication-between-the-primary-and-secondary-clusters}
 

diff --git a/explore-htap.md b/explore-htap.md
@@ -39,7 +39,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技
 
 - ハイブリッドワークロードの分離
 
-    高負荷なオンライン・トランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。
+    高負荷なオンライントランザクション処理（OLTP）ワークロードを処理する際、システムは同時にOLAPワークロードも処理する必要が生じる場合があります。システム全体の安定性を確保するため、OLAPクエリがOLTPのパフォーマンスに与える影響を回避することが求められます。
 
 - ETLテクノロジースタックを簡素化する
 
@@ -51,7 +51,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技
 
 ## アーキテクチャ {#architecture}
 
-TiDBでは、オンライン・トランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。
+TiDBでは、オンライントランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列指向のストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。
 
 アーキテクチャの詳細については、 [TiDB HTAPのアーキテクチャ](/tiflash/tiflash-overview.md#architecture)を参照してください。