翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 避けるべきタグ付けのプラクティス
<a name="tagging-practices-to-avoid"></a>

AWS でオブジェクトまたはインフラストラクチャにタグ付けするときは、実装すべきプラクティスがある一方で、避けるべきプラクティスもあります。

## 一貫性のないタグ付け
<a name="inconsistent"></a>

「[目的](objectives.md)」セクションで説明したように、タグ付けを行わなければ、高レベルの自動化、クリーンアップ、モニタリングを実現することはできません。同様に、タグが不完全な場合やタグに一貫性がない場合、自動化またはモニタリングに必要な情報が完全ではないため、信頼できない結果になります。

タグ付け戦略を使用してすべてのプロジェクトの合計コストを計算するシナリオを想像してみてください。戦略は概念実証フェーズ (PoC) から始まり、本番稼働フェーズで終了します。プロジェクト「売上予測」の P1、D1、Pr1 の例と、プロジェクト「販売後メンテナンス」の P2、D2、Pr2 の例のデータとリソースにタグが適用されている次のシナリオを検討してください。

**売上予測**

例 P1: PoC プロジェクト (ドメインとタイムスタンプがありません)。

```
env: "poc"
project: "sales forecasting"
```

例 D1: 開発フェーズ (ドメインがありません)。

```
env: "dev"
project: "sales forecasting"
timestamp: 20210505T12:34:55
```

例 Pr1: 本番稼働フェーズ (すべての値が存在します)。

```
env: "prod"
project: "sales forecasting"
domain: "machine learning"
timestamp: 20210505T12:34:55
```

プロジェクト「売上予測」の場合:
+ 例 P1 は、オブジェクトがどのドメインまたはタイムスタンプから来たかについては言及していません。
+ 例 D1 も、プロジェクトのドメインについて言及していません。
+ 例 Pr1 には、必要なデータがすべて含まれています。

例 P1 と D1 では、ドメインが定義されていないため、計画のレポートや見積もりが不正確になります。

**販売後メンテナンス**

例 P2: PoC プロジェクト (すべてのタグがありません)。

例 D2: 開発フェーズ (プロジェクトがありません)。

```
env: "dev"
domain: "machine learning"
timestamp: 20210505T12:34:55
```

例 Pr2: 本番稼働フェーズ (すべての値が存在します)。

```
env: "prod"
project: "post sales maintenance"
domain: "machine learning"
timestamp: 20210505T12:34:55
```

プロジェクト「販売後メンテナンス」の場合:
+ 例 P2 には情報がないため、追跡できません。
+ 例 D2 はプロジェクト名に言及していないため、追跡できません。
+ 例 Pr2 には、必要なデータがすべて含まれています。

例 P2 と D2 では、タグが欠落しているかタグに一貫性がないため、誤ったレポート、計画漏れ、または過小報告が発生します。

したがって、タグ付け戦略を一貫して実装することが重要です。

## タグ内の正しくないデータと機密データ
<a name="incorrect-sensitive"></a>

タグ付けは、正しくない情報、機密情報、または個人情報と共に使用すると、逆効果になる可能性があります。タグが正しくないと、誤解を招く結果が生じる可能性があります。個人を特定できる情報 (PII) などの機密データを含むタグを使用すると、顧客や従業員のセキュリティが危険にさらされる可能性があります。

**タグ内の正しくない情報**

タグ付け戦略を使用して各ドメインまたは部門の合計コストを計算するシナリオを想像してみてください。データインジェストフェーズが終了し、機械学習に移行しているところです。次の例には、プロジェクトの前のフェーズからコピーされたカスタムタグが含まれています。

```
env: "development"
project: "sales prediction"
domain: "data ingestion"
timestamp: 20210505T12:34:55
```

ドメインは、正しいドメインである `machine learning` ではなく、前のプロジェクトフェーズの `data ingestion` として誤ってラベル付けされています。そのため、`data ingestion` ドメインのレポートには、より高いコスト、時間範囲、リソース割り当てが表示されます。`machine learning` ドメインには、これらのレポートでより低い値が表示されます。これにより、計画、予算配分、および期限の見積もりが不正確になります。

適切なタグ付けは、機能するシステムにとって不可欠です。

**タグ内の機密情報**

AWS には、オブジェクト内の PII を識別するためのツールがいくつか用意されています。これらのツールには、個人を識別するために使用できるデータを見つけるための [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) と [AWS Glue 機密データ検出](https://docs.aws.amazon.com/glue/latest/ug/detect-PII.html)が含まれます。ただし、タグに PII や機密データを使用しないことが重要です。

PII が秘匿化または匿名化された Amazon S3 のファイルの次の例を考えてみましょう。

```
{
  firstName: "67A1790DCA55B8803AD024EE28F616A2",
  lastName: "DRG54654DFHJGDYYRD",
  age: 21,
  city : "Frankfurt",
  probability_of_purchase: 48.858093,
  veggieName: "broccoli",
  creditcard: false
}
```

顧客の名と姓がハッシュ化されていることを確認できます。ただし、この例では、レコードには次のカスタムタグがあります。

```
owner: "Company XYZ"
about: "John Doe"
contact: "johnthegreat@email.com"
timestamp: 20210505T12:34:55
```

この場合、ファイル自体には PII は含まれませんが、タグには機密情報が含まれます。これにより、ファイルまたはオブジェクトを共有または転送するときに、そのメタデータも共有または転送されるため、情報漏洩の可能性が高まります。これは、データベース、テーブル、ジョブ、関数などの他の AWS リソースにも当てはまります。

したがって、タグに個人情報を使用しないことが非常に重要です。同じ概念は、重要な情報や非公開情報にも当てはまります。