fix: adopted the review comments

content/ja/docs/concepts/signals/baggage.md

@@ -12,7 +12,7 @@ OpenTelemetryでは、バゲッジ（Baggage）はコンテキストの隣にあ
 
 ## 例 {#example}
 
-バゲッジは、サービス間で追加データを伝播するためにトレースでよく使用されます。
+バゲッジは、トレースで、サービス間で追加データを伝播するためによく使用されます。
 
 たとえば、リクエストの最初に `clientId` があるとします。
 しかし、そのIDをトレース内のすべてのスパン、別のサービスのいくつかのメトリクス、そして途中のいくつかのログで利用できるようにしたいとします。

content/ja/docs/concepts/signals/metrics.md

@@ -1,7 +1,7 @@
 ---
 title: メトリクス
 weight: 2
-description: 実行時に取得された測定値。
+description: 実行時に取得された測定値
 default_lang_commit: 9b5e318
 ---
 
@@ -10,14 +10,14 @@ default_lang_commit: 9b5e318
 
 アプリケーションとリクエストのメトリクスは、可用性とパフォーマンスの重要な指標です。
 カスタムメトリクスは、可用性指標がユーザー体験やビジネスにどのような影響を与えるかについての洞察を提供できます。
-収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガしたりできます。
+収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガーしたりできます。
 
 OpenTelemetryのメトリクスがどのように機能するのかを理解するために、コードの計装の一部を担うコンポーネントのリストを見てみましょう。
 
 ## メータープロバイダー {#meter-provider}
 
-メータープロバイダー（`MeterProvider` と呼ばれることもあります）は、`メーター`のファクトリーです。
-ほとんどのアプリケーションでは、メータープロバイダは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。
+メータープロバイダー（`MeterProvider` と呼ばれることもあります）は、`Meter`のファクトリーです。
+ほとんどのアプリケーションでは、メータープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。
 メータープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。
 これは通常、OpenTelemetryを使った計測の最初のステップです。
 いくつかの言語SDKでは、グローバルなメータープロバイダーがすでに初期化されています。

content/ja/docs/concepts/signals/traces.md

@@ -17,7 +17,7 @@ default_lang_commit: 9b5e318
 
 {{% /alert %}}
 
-`hello` スパン
+`hello` スパンは次のとおりです。
 
 ```json
 {
@@ -48,7 +48,7 @@ default_lang_commit: 9b5e318
 トレースを示す `trace_id` フィールドがありますが、`parent_id` がないことに注意してください。
 これがルートスパンであることを示します。
 
-`hello-greetings` スパン
+`hello-greetings` スパンは次のとおりです。
 
 ```json
 {
@@ -82,11 +82,11 @@ default_lang_commit: 9b5e318
 }
 ```
 
-このスパンは、挨拶のような特定のタスクをカプセル化していて、その親は `hello` スパンです。
+このスパンは、挨拶（`greetings`）のような特定のタスクをカプセル化していて、その親は `hello` スパンです。
 このスパンはルートスパンと同じ `trace_id` を共有していて、同じトレースの一部であることを示しています。
 さらに、 `hello` スパンの `span_id` と一致する `parent_id` を持っています。
 
-`hello-salutations` スパン
+`hello-salutations` スパンは次のとおりです。
 
 ```json
 {
@@ -117,7 +117,7 @@ default_lang_commit: 9b5e318
 また、`hello-greetings`スパンの兄弟でもあります。
 
 これらの3つのJSONブロックはすべて同じ `trace_id` を共有していて、`parent_id` フィールドは階層を表しています。
-これはトレースになる！
+これは1つのトレースになります！
 
 もうひとつ、各スパンが構造化されたログのように見えることにお気づきでしょう。
 それはその通りだからです！トレースについて考える一つの方法は、トレースはコンテキスト、相関関係、階層構造などを持つ構造化されたログの集まりであるということです。
@@ -128,9 +128,9 @@ OpenTelemetryでのトレースがどのように機能するかを理解する
 
 ## トレーサープロバイダー {#tracer-provider}
 
-トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `トレーサー` のファクトリーです。
-ほとんどのアプリケーションでは、トレーサープロバイダーは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。
-トレーサープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。
+トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `Tracer` のファクトリーです。
+ほとんどのアプリケーションでは、トレーサープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。
+トレーサープロバイダーの初期化には、リソースとエクスポーターの初期化も含まれます。
 これは通常、OpenTelemetry によるトレースの最初のステップです。
 いくつかの言語SDKでは、グローバルなトレーサープロバイダーがすでに初期化されています。