pingcap · hfxsd · Apr 17, 2026 · Apr 14, 2026
diff --git a/_docHome.md b/_docHome.md
@@ -3,7 +3,7 @@
 hide_sidebar: true
 hide_commit: true
 hide_leftNav: true
-summary: TiDBドキュメントでは、データ移行やアプリケーション構築など、 TiDB CloudとTiDB Self-Managedの使用方法に関するガイドとリファレンスを提供しています。TiDB TiDB Cloudは、クラウドネイティブな分散SQLデータベースのパワーに簡単にアクセスできる、フルマネージドのDatabase-as-a-Service（DaaS）です。TiDBは、MySQLとの互換性、水平スケーラビリティ、高可用性を備えたオープンソースの分散SQLデータベースです。開発者は、アプリケーション開発に関するドキュメントにアクセスしたり、TiDB Playground、PingCAP Education、コミュニティ参加の機会などの追加リソースを活用したりできます。
+summary: TiDBドキュメントでは、データ移行やアプリケーション構築など、 TiDB CloudとTiDB Self-Managedの使用方法に関するガイドとリファレンスを提供しています。TiDB Cloudは、クラウドネイティブな分散SQLデータベースのパワーに簡単にアクセスできる、フルマネージドのDatabase-as-a-Service（DaaS）です。TiDBは、MySQLとの互換性、水平スケーラビリティ、高可用性を備えたオープンソースの分散SQLデータベースです。開発者は、アプリケーション開発に関するドキュメントにアクセスしたり、TiDB Playground、PingCAP Education、コミュニティ参加の機会などの追加リソースを活用したりできます。
 ---
 
 <DocHomeContainer title="TiDB Documentation" subTitle="Explore the how-to guides and references you need to use TiDB Cloud Starter, TiDB Cloud Dedicated and TiDB Self-Managed, migrate data, and build your applications on the database." ctaLabel="Start TiDB Cloud Starter for Free" ctaLink="https://tidbcloud.com/free-trial">

diff --git a/ai/integrations/vector-search-auto-embedding-overview.md b/ai/integrations/vector-search-auto-embedding-overview.md
@@ -125,7 +125,7 @@
 
 <sup>1.</sup>ホスト型モデルはTiDB Cloudによってホストされており、APIキーは必要ありません。現在、これらのホスト型モデルは無料で利用できますが、すべてのユーザーが利用できるようにするために、一定の利用制限が適用される場合があります。
 
-<sup>2</sup> BYOK（Bring Your Own Key）モデルでは、対応する埋め込みプロバイダーから独自のAPIキーを提供する必要があります。TiDB TiDB CloudはBYOKモデルの使用料を請求しません。これらのモデルの使用に伴うコストの管理と監視はお客様の責任となります。
+<sup>2</sup> BYOK（Bring Your Own Key）モデルでは、対応する埋め込みプロバイダーから独自のAPIキーを提供する必要があります。TiDB CloudはBYOKモデルの使用料を請求しません。これらのモデルの使用に伴うコストの管理と監視はお客様の責任となります。
 
 ## 自動埋め込みの仕組み {#how-auto-embedding-works}
 
@@ -192,7 +192,7 @@
 
 -   `api_base` *(オプション)* : 埋め込みAPIサービスのベースURL。
 
--   `use_server` *(オプション)* : TiDB Cloud のホスト型埋め込みサービスを使用するかどうか。TiDB TiDB Cloud Starterの場合は、デフォルトで`True`になります。
+-   `use_server` *(オプション)* : TiDB Cloud のホスト型埋め込みサービスを使用するかどうか。TiDB Cloud Starterの場合は、デフォルトで`True`になります。
 
 -   `multimodal` *(オプション)* : マルチモーダル埋め込みモデルを使用するかどうか。有効にすると、 `use_server`は自動的に`False`に設定され、埋め込みサービスがクライアント側で呼び出されます。
 

diff --git a/api/tidb-operator-api-overview.md b/api/tidb-operator-api-overview.md
@@ -5,7 +5,7 @@
 
 # TiDB OperatorAPI の概要 {#tidb-operator-api-overview}
 
-[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)は、Kubernetes上のTiDBクラスタの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスタ内でTiDBをシームレスに実行できます。
+[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)は、Kubernetes上のTiDBクラスタの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスタ内でTiDBをシームレスに実行できます。
 
 Kubernetes 上で TiDB クラスターを管理するには、次のTiDB OperatorAPI を使用できます。
 

diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md
@@ -31,7 +31,7 @@
 
 ## リソース要件 {#resource-requirements}
 
-**オペレーティングシステム**：このドキュメントの例では、新規のCentOS 7インスタンスを使用しています。仮想マシンはローカルホストまたはクラウドにデプロイできます。TiDB TiDB Lightningはデフォルトで必要なCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント（例えば`tikv-server` ）と共に単一のサーバーにデプロイし、 TiDB LightningからのCPU使用量を制限するために`region-concurrency`を設定することができます。通常、サイズは論理CPUの75%に設定できます。
+**オペレーティングシステム**：このドキュメントの例では、新規のCentOS 7インスタンスを使用しています。仮想マシンはローカルホストまたはクラウドにデプロイできます。TiDB Lightningはデフォルトで必要なCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント（例えば`tikv-server` ）と共に単一のサーバーにデプロイし、 TiDB LightningからのCPU使用量を制限するために`region-concurrency`を設定することができます。通常、サイズは論理CPUの75%に設定できます。
 
 **メモリとCPU** ： TiDB Lightningは多くのリソースを消費するため、64GiB以上のメモリと32個以上のCPUコアを割り当てることをお勧めします。最高のパフォーマンスを得るには、CPUコアとメモリ（GiB）の比率が1:2以上であることを確認してください。
 

diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md
@@ -48,7 +48,7 @@ BRの使用方法は、TiDBの導入方法によって異なります。この
 
 この機能を他の展開シナリオで使用する方法については、次のドキュメントを参照してください。
 
--   [TiDB CloudにデプロイされたTiDBのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore) : [TiDB Cloud](https://www.pingcap.com/tidb-cloud/?from=en)に TiDB クラスターを作成することをお勧めします。TiDB TiDB Cloud は、アプリケーションに集中できるように、完全に管理されたデータベースを提供します。
+-   [TiDB CloudにデプロイされたTiDBのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore) : [TiDB Cloud](https://www.pingcap.com/tidb-cloud/?from=en)に TiDB クラスターを作成することをお勧めします。TiDB Cloud は、アプリケーションに集中できるように、完全に管理されたデータベースを提供します。
 -   [TiDB Operatorを使用したデータのバックアップと復元](https://docs.pingcap.com/tidb-in-kubernetes/stable/backup-restore-overview) : Kubernetes 上でTiDB Operatorを使用して TiDB クラスターをデプロイする場合は、Kubernetes CustomResourceDefinition (CRD) を使用してデータをバックアップおよび復元することをお勧めします。
 
 ## BR機能 {#br-features}

diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md
@@ -208,7 +208,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを
 
     -   **システム割り当てマネージド ID** :
 
-        システム割り当てマネージド ID を使用する場合、Azure 関連の環境変数を構成する必要はありません。BRBRコマンドを直接実行できます。
+        システム割り当てマネージド ID を使用する場合、Azure 関連の環境変数を構成する必要はありません。BRコマンドを直接実行できます。
 
         ```shell
         tiup br backup full -u "${PD_IP}:2379" \

diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md
@@ -68,7 +68,7 @@ tiup br validate decode --field="end-version" \
 >
 > -   BR v7.5.0 以前のバージョンでは、TiKV ノードあたりのスナップショット復元速度は約 100 MiB/秒です。
 > -   BR v7.6.0以降、大規模リージョンのシナリオにおける潜在的なリストアボトルネックに対処するため、粗粒度のリージョン分散アルゴリズム（実験的）によるリストアの高速化がBRでサポートされます。この機能は、コマンドラインパラメータ`--granularity="coarse-grained"`を指定することで有効化できます。
-> -   BR v8.0.0 以降では、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供 (GA) され、デフォルトで有効になっています。BRBR、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SST ファイルのダウンロードと取り込み操作の相互影響の低減、テーブル統計の復元の高速化など、さまざまな最適化を実装することで、スナップショットの復元速度が大幅に向上しています。実際のケースでのテスト結果によると、スナップショット復元の SST ファイルのダウンロード速度は最大約 10 倍向上し、TiKV ノードあたりのデータ復元速度は 1.2 GiB/s で安定し、エンドツーエンドの復元速度は約 1.5～3 倍向上し、100 TiB のデータを 1 時間以内に復元できます。
+> -   BR v8.0.0 以降では、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供 (GA) され、デフォルトで有効になっています。BR、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SST ファイルのダウンロードと取り込み操作の相互影響の低減、テーブル統計の復元の高速化など、さまざまな最適化を実装することで、スナップショットの復元速度が大幅に向上しています。実際のケースでのテスト結果によると、スナップショット復元の SST ファイルのダウンロード速度は最大約 10 倍向上し、TiKV ノードあたりのデータ復元速度は 1.2 GiB/s で安定し、エンドツーエンドの復元速度は約 1.5～3 倍向上し、100 TiB のデータを 1 時間以内に復元できます。
 > -   BR v8.2.0 以降では、コマンド ライン パラメータ`--granularity`は非推奨となり、粗粒度リージョン散乱アルゴリズムがデフォルトで有効になります。
 > -   BR v8.3.0 以降、スナップショット復元タスクでは、TiKV およびTiFlashの使用可能なディスク容量チェックが導入されています。タスクの開始時に、 BR は復元する SST ファイルのサイズに基づいて、TiKV およびTiFlashに十分なディスク容量があるかどうかを確認します。TiKV v8.3.0 以降のバージョンでは、TiKV は各 SST ファイルをダウンロードする前に十分なディスク容量があるかどうかを確認します。これらのチェックのいずれかで容量が不足している場合、復元タスクはエラーで失敗します。1 `--check-requirements=false`設定することで復元タスクの開始時のチェックをスキップできますが、TiKV が各 SST ファイルをダウンロードする前のディスク容量チェックはスキップできません。
 

diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md
@@ -1,6 +1,6 @@
 ---
 title: TiDB Snapshot Backup and Restore Command Manual
-summary: TiDBスナップショットのバックアップと復元コマンドマニュアルでは、クラスタースナップショット、データベース、およびテーブルのバックアップと復元に使用するコマンドについて説明しています。また、バックアップデータの暗号化と暗号化されたスナップショットの復元についても説明しています。BRBRはGCへの自己適応をサポートし、統計情報のバックアップと復元に--ignore-statsパラメータを導入しています。さらに、バックアップデータの暗号化と、指定されたデータベースまたはテーブルの部分的なデータ復元もサポートしています。
+summary: TiDBスナップショットのバックアップと復元コマンドマニュアルでは、クラスタースナップショット、データベース、およびテーブルのバックアップと復元に使用するコマンドについて説明しています。また、バックアップデータの暗号化と暗号化されたスナップショットの復元についても説明しています。BRはGCへの自己適応をサポートし、統計情報のバックアップと復元に--ignore-statsパラメータを導入しています。さらに、バックアップデータの暗号化と、指定されたデータベースまたはテーブルの部分的なデータ復元もサポートしています。
 ---
 
 # TiDB スナップショットのバックアップと復元コマンドマニュアル {#tidb-snapshot-backup-and-restore-command-manual}

diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md
@@ -9,7 +9,7 @@ TiDBダッシュボードにアクセスするには、ブラウザから[http:/
 
 > **注記：**
 >
-> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイできます。TiDB TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。詳細は[TiDB ダッシュボードをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。
+> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降では、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイできます。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。詳細は[TiDB ダッシュボードをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。
 
 ## 複数のPDインスタンスがデプロイされている場合にTiDBダッシュボードにアクセスする {#access-tidb-dashboard-when-multiple-pd-instances-are-deployed}
 

diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md
@@ -56,7 +56,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き
 
 ### <code>required component NgMonitoring is not started</code>というエラーが表示されます {#a-code-required-component-ngmonitoring-is-not-started-code-error-is-shown}
 
-NgMonitoringは、TiDB v5.4.0以降のバージョンに組み込まれた高度な監視コンポーネントで、**継続的プロファイリング**や**Top SQL**などのTiDBダッシュボード機能をサポートします。TiUPの新しいバージョンを使用してクラスターをデプロイまたはアップグレードすると、NgMonitoringが自動的にデプロイされます。TiDB TiDB Operatorを使用してデプロイされたクラスターの場合は、 [継続的なプロファイリングを有効にする](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/access-dashboard/#enable-continuous-profiling)を参照してTiUPを手動でデプロイできます。
+NgMonitoringは、TiDB v5.4.0以降のバージョンに組み込まれた高度な監視コンポーネントで、**継続的プロファイリング**や**Top SQL**などのTiDBダッシュボード機能をサポートします。TiUPの新しいバージョンを使用してクラスターをデプロイまたはアップグレードすると、NgMonitoringが自動的にデプロイされます。TiDB Operatorを使用してデプロイされたクラスターの場合は、 [継続的なプロファイリングを有効にする](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/access-dashboard/#enable-continuous-profiling)を参照してTiUPを手動でデプロイできます。
 
 Web ページに`required component NgMonitoring is not started`が表示されている場合は、次のようにしてデプロイメントの問題をトラブルシューティングできます。
 

diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md
@@ -25,7 +25,7 @@ TiDBダッシュボードにアクセスしてサインインするには、最
 
 > **注記：**
 >
-> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降は、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイすることをサポートしています。TiDB TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。このポートはPDの他の特権インターフェースとは通信しないため、外部から提供される場合は追加のファイアウォールは必要ありません。詳細については、 [TiDB ダッシュボードをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。
+> TiDB v6.5.0以降およびTiDB Operator v1.4.0以降は、Kubernetes上にTiDB Dashboardを独立したPodとしてデプロイすることをサポートしています。TiDB Operatorを使用すると、このPodのIPアドレスにアクセスしてTiDB Dashboardを起動できます。このポートはPDの他の特権インターフェースとは通信しないため、外部から提供される場合は追加のファイアウォールは必要ありません。詳細については、 [TiDB ダッシュボードをTiDB Operatorで独立してデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/get-started#deploy-tidb-dashboard-independently)参照してください。
 
 TiDBダッシュボードはPDクライアントポート（デフォルトは[http://IP:2379/ダッシュボード/](http://IP:2379/dashboard/) ）を介してサービスを提供します。TiDBダッシュボードはID認証を必要としますが、PDクライアントポート上のPD内の他の特権インターフェース（例： [http://IP:2379/pd/api/v1/members](http://IP:2379/pd/api/v1/members) ）はID認証を必要とせず、特権操作を実行できます。したがって、PDクライアントポートを外部ネットワークに直接公開することは非常に危険です。