i18n(ja): address gemini-code-assist review comments on PR #23036

Fixes:
- migrate-large-mysql-to-tidb.md: storage時間→保存期間, storage容量→ストレージ容量
- pd-recover.md: 存続している→生存している
- architecture-concepts.md: remove spaces around Premium/RCU
- essential-changefeed-sink-to-kafka.md: remove spaces around Kafka
- essential-changefeed-sink-to-mysql.md: fix spacing and add missing particle
- tidb-cloud-auditing-premium.md: 監査フィルタルール→監査フィルタールール
- tidb-cloud-release-notes.md: クロス AZ→クロスAZ
- serverless-private-link-connection-to-aws-rds.md: remove spaces around AWS
- tidb-cloud-glossary.md: storage構成→ストレージ構成
- tidb-lightning-prechecks.md: fix spacing and terminology inconsistencies

Author: yahonda

migrate-large-mysql-to-tidb.md

@@ -27,7 +27,7 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を
 
 -   Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。SSD推奨です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。
 -   インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。
--   データ総量が大きい場合は、上流側のbinlogのstorage時間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。
+-   データ総量が大きい場合は、上流側のbinlogの保存期間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。
 
 **注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。
 
@@ -62,7 +62,7 @@ LIMIT
 
 ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster}
 
-ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのstorage容量は**、データソースのサイズ × <a href="/faq/manage-cluster-faq.md#is-the-number-of-replicas-in-each-region-configurable-if-yes-how-to-configure-it">レプリカ数</a>× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなstorage容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。
+ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × <a href="/faq/manage-cluster-faq.md#is-the-number-of-replicas-in-each-region-configurable-if-yes-how-to-configure-it">レプリカ数</a>× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。
 
 -   インデックスには余分な容量が必要になる場合があります。
 -   RocksDBには空間増幅がある。

pd-recover.md

@@ -42,7 +42,7 @@ PD Recover インストール パッケージは、 TiDB Toolkitに含まれて
 
 > **注記：**
 >
-> -   コマンドラインで`--data-dir`が指定されていない場合は、 `conf/pd.toml`内の`data-dir`が、存続しているPDノードの元のデータディレクトリを正しく指していることを確認してください。そうでない場合、`pd-recover`は後続の操作で失敗する可能性があります。
+> -   コマンドラインで`--data-dir`が指定されていない場合は、 `conf/pd.toml`内の`data-dir`が、生存しているPDノードの元のデータディレクトリを正しく指していることを確認してください。そうでない場合、`pd-recover`は後続の操作で失敗する可能性があります。
 > -   `conf/pd.toml`とコマンドライン引数の両方で`data-dir`が指定されている場合、 `conf/pd.toml`の`data-dir`設定が優先されます。
 
 ### ステップ3： <code>pd-recover</code>を使用してメタデータを修復する {#step-3-repair-metadata-using-code-pd-recover-code}

tidb-cloud/architecture-concepts.md

@@ -180,7 +180,7 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、
 
 ### RCUの自動スケーリング {#rcu-auto-scaling}
 
-TiDB Cloud Premium インスタンスを構成する際に、ワークロードに必要な最大 RCU 数 ( `RCU_max` ) を指定します。TiDB Cloudは`0.25 * RCU_max`から`RCU_max`までの範囲で自動的にスケーリングします。
+TiDB Cloud Premiumインスタンスを構成する際に、ワークロードに必要な最大RCU数 ( `RCU_max` ) を指定します。TiDB Cloudは`0.25 * RCU_max`から`RCU_max`までの範囲で自動的にスケーリングします。
 
 例えば、最大容量を20,000 RCUに設定した場合、 TiDB Cloudはリアルタイムの需要に基づいて、容量を5,000 RCUから20,000 RCUの間で動的にスケーリングします。このスケーリングは自動的かつ瞬時に行われるため、手動操作や遅延なしに、いつでも最大数のRCUを消費できます。
 

tidb-cloud/branch-overview.md

@@ -5,7 +5,7 @@ summary: TiDB Cloudのブランチの概念を学びましょう。
 
 # TiDB Cloudブランチング（ベータ版）の概要 {#tidb-cloud-branching-beta-overview}
 
-TiDB Cloud、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。
+TiDB Cloudでは、TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。
 
 ブランチ機能を使用することで、開発者は並行して作業を進め、新機能を迅速に反復開発し、本番データベースに影響を与えることなく問題をトラブルシューティングし、必要に応じて変更を簡単に元に戻すことができます。この機能は、開発およびデプロイプロセスを効率化すると同時に、本番データベースの高い安定性と信頼性を確保します。
 

tidb-cloud/connect-via-standard-connection-serverless.md

@@ -42,7 +42,7 @@ summary: パブリックエンドポイントを介して、 TiDB Cloud Starter
 
     </CustomContent>
 
-4.  TiDB Cloud、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用に[支店](/tidb-cloud/branch-overview.md)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウン リストからブランチに接続できます。 `main` TiDB Cloud StarterまたはEssentialインスタンス自体を表します。
+4.  TiDB Cloudでは、TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用に[支店](/tidb-cloud/branch-overview.md)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウン リストからブランチに接続できます。 `main` TiDB Cloud StarterまたはEssentialインスタンス自体を表します。
 
 5.  まだパスワードを設定していない場合は、 **「パスワードを生成」をクリックしてランダムなパスワード**を生成してください。生成されたパスワードは二度と表示されませんので、安全な場所に保存してください。
 

tidb-cloud/essential-changefeed-sink-to-kafka.md

@@ -186,11 +186,11 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト
 
         変更フィードで全ての変更ログに対して1つのKafkaトピックを作成する場合は、このモードを選択してください。そうすると、変更フィード内のすべてのKafkaメッセージが1つのKafkaトピックに送信されます。トピック名は**「トピック名」**フィールドで指定できます。
 
-8.  **パーティション分散**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。
+8.  **パーティション分散**領域では、Kafkaメッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。
 
     -   **プライマリキーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。**
 
-        変更フィードでテーブルの Kafka メッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **「インデックス名」**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。
+        変更フィードでテーブルのKafkaメッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **「インデックス名」**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。
 
     -   **変更ログをテーブルごとにKafkaパーティションに分散する**
 

tidb-cloud/essential-changefeed-sink-to-mysql.md

@@ -60,7 +60,7 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき
 
 既存のデータを読み込むには：
 
-1.  [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、この期間中の履歴データが TiDB によってガベージ コレクションされないようにします。
+1.  [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)を以下の2つの操作の合計時間よりも長く設定することで、この期間中の履歴データがTiDBによってガベージ コレクションされないようにします。
 
     -   既存データのエクスポートとインポートにかかる時間
     -   **Sink to MySQL**を作成する時間

tidb-cloud/premium/tidb-cloud-auditing-premium.md

@@ -9,7 +9,7 @@ TiDB Cloudは、実行されたSQLステートメントなど、データベー
 
 組織のユーザーアクセスポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティ上のベストプラクティスです。
 
-監査ログ機能は**デフォルトでは無効になっています**。TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタルールを設定する必要があります。
+監査ログ機能は**デフォルトでは無効になっています**。TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタールールを設定する必要があります。
 
 > **注記：**
 >

tidb-cloud/releases/tidb-cloud-release-notes.md

@@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes']
 
     -   2026年6月9日以降に新たに作成される[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスは、単一のアベイラビリティゾーンにデプロイされ、リージョンごとの高可用性はサポートされません。
 
-        リージョンの高可用性とクロス AZ フェイルオーバーが必要な場合は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)を選択することを検討してください。
+        リージョンの高可用性とクロスAZフェイルオーバーが必要な場合は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)を選択することを検討してください。
 
         この変更は、2026年6月9日より前に作成されたTiDB Cloud Essentialインスタンスには影響しません。
 

tidb-cloud/serverless-private-link-connection-to-aws-rds.md

@@ -106,7 +106,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー
 
 2.  エンドポイントサービスの詳細ページに移動し、 `com.amazonaws.vpce.<region>.vpce-svc-xxxxxxxxxxxxxxxxx`の形式でエンドポイントサービス名をコピーしてください。この名前をTiDB Cloudに提供する必要があります。
 
-3.  エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得した AWS アカウント ID を許可リストに追加します。例えば、 `arn:aws:iam::<account_id>:root`のように追加します。
+3.  エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得したAWSアカウントIDを許可リストに追加します。例えば、 `arn:aws:iam::<account_id>:root`のように追加します。
 
 ## ステップ3. TiDB CloudでAWSエンドポイントサービスのプライベートリンク接続を作成します。 {#step-3-create-an-aws-endpoint-service-private-link-connection-in-tidb-cloud}