---
title: "Amazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界を実装者目線で解説"
url: "https://www.issoh.co.jp/tech/details/15886/"
published: 2026-07-30
updated: 2026-10-12
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Amazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界を実装者目線で解説

Amazon Macieは、Amazon S3に置かれたオブジェクトの中身を読み、クレジットカード番号やAPIキーのような機密データがどのバケットに眠っているかを検出するマネージドサービスです。バケットの公開設定を監視するだけでなく、ファイルを展開して本文を解析する点が他のAWSセキュリティサービスとの差になります。

この記事では、自動機密データ検出と検出ジョブという2つの動かし方、感度スコアの意味、日本の氏名や住所やマイナンバーが標準では検出されない前提とその回避策、バケット数・オブジェクト数・分析GBで積み上がる料金構造を実装の解像度で整理します。AWS CLIで有効化から除外設定・カスタムデータ識別子の検証・EventBridgeへの配信までを通す手順も、そのまま貼って動かせる形で置きました。最後に、受託開発でMacieを採用すべき条件と見送ってよい場面を条件付きで示します。

## まとめ：Amazon Macieの検出範囲と日本語データの限界・費用設計の結論

先に結論を置きます。Macieは「S3に限定された機密データの棚卸しツール」であり、日本の個人情報を検出したいなら自分で識別子を書く前提のサービスです。

- **対象はS3汎用バケットだけ**：RDSやDynamoDBの中身は直接読めず、S3へエクスポートしてから当てる形になります。
- **日本向けの組み込み識別子は無い**：マイナンバー・日本の運転免許証番号・日本の銀行口座番号に対応する識別子は提供されていません。氏名の検出もラテン文字が前提です。
- **まず自動機密データ検出から始める**：全バケットをサンプリングして感度スコアを付けるため、どこに機密データがありそうかの当たりが48時間ほどで付きます。
- **費用は分析GB単価で決まる**：1GBあたり1USDという単価は、ログバケットを含めた瞬間に効きます。除外設計を先に決めてから有効化してください。
- **暗号化の許可を先に通す**：カスタマー管理のKMSキーで暗号化したオブジェクトは、キーポリシーにMacieのサービスリンクロールを書くまで読めません。

## Amazon Macieの定義と検出対象｜S3の機密データを見つける仕組み

Macieの機能は、バケットの状態監視とオブジェクト本文の解析の2層に分かれます。混同すると料金の見積もりが合いません。

### Amazon Macieの定義｜S3オブジェクトを読み解く検出エンジン

Macieは、S3汎用バケットのインベントリを日次で更新し、公開設定・暗号化設定・外部共有といったセキュリティ状態を評価します。この部分は中身を読まずに動き、設定が緩む変更を検知するとpolicy findingsを生成します。

もう一方の柱が、オブジェクトを取得して本文を解析する機密データ検出です。機械学習とパターンマッチングを組み合わせ、クレジットカード番号・秘密鍵・パスポート番号といった定義済みの型に当てはまるテキストを探します（[AWS公式のマネージドデータ識別子の説明](https://docs.aws.amazon.com/macie/latest/user/managed-data-identifiers.html)・2026年9月時点）。前提知識は[Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/)にまとめてあります。

### 検出対象のストレージクラスと形式｜画像と圧縮階層10段までの制約

解析されるのは、対応ストレージクラスかつ対応形式のオブジェクトに限られます。対応クラスは Standard、Standard-IA、One Zone-IA、Intelligent-Tiering、Glacier Instant Retrieval、RRS。S3 Glacier Deep Archive と S3 Express One Zone は対象外で、ディレクトリバケットそのものが分析されません（[対応ストレージクラスと形式の一覧](https://docs.aws.amazon.com/macie/latest/user/discovery-supported-storage.html)）。

形式は、Avro・Parquet、gz・tar・zipの圧縮アーカイブ、PDF・Excel・Word、eml形式のメール、CSVやJSONを含む非バイナリテキストが対象です。画像・音声・動画は分析されません。対象外は分類不能オブジェクトとして黙って飛ばされるため、「検出ゼロ＝安全」と読み違えないでください。分類不能の件数とサイズはバケットのインベントリ側で数えられるので、有効化直後にそこを見ると解析の網羅率が分かります。

圧縮ファイルは中身まで展開されますが、ネスト10階層・抽出ファイル数100万件・抽出バイト数合計10GBが上限です。抽出後の1ファイルあたりも3GBで打ち切られます。単一ファイルの上限も形式ごとに決まっており、PDFは1,024MB、Excelとwordは512MB、Avro・Parquet・zip・gzは8GB、テキストやtarとemlは20GB。分析時間は1ファイル10時間で終了します。

## Amazon Macieを有効化して最初の棚卸し結果を出すまでの作業手順

ここからは実際に手を動かす部分です。コンソールでも同じことができますが、環境を再現したいならCLIで残すほうが早く済みます（コマンドの一覧は[AWS CLIのmacie2リファレンス](https://docs.aws.amazon.com/cli/latest/reference/macie2/index.html)で確認できます）。

### AWS CLIでMacieを有効化し自動機密データ検出を始める作業

有効化は2コマンドで終わります。`enable-macie` の `--finding-publishing-frequency` は、既存のpolicy findingの更新をEventBridgeへ再送する周期で、FIFTEEN\_MINUTES・ONE\_HOUR・SIX\_HOURSから選びます。機密データ検出の結果は常に新規扱いで即時に配信されるため、この設定の影響を受けません。

```
# 1) Macieを有効化する（policy findingsの更新公開は15分周期）
aws macie2 enable-macie \
  --status ENABLED \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --region ap-northeast-1

# 2) 自動機密データ検出を開始する
aws macie2 update-automated-discovery-configuration \
  --status ENABLED \
  --region ap-northeast-1

# 3) 開始状態と分類スコープIDを確認する
aws macie2 get-automated-discovery-configuration --region ap-northeast-1
```

3番目のコマンドが返す classificationScopeId は、次の除外設定で使う値です。firstEnabledAt に時刻が入っていれば分析が走り始めた状態です。組織で使う場合は、委任管理者アカウントがメンバーアカウントのバケットまで一括で可視化します。招待による参加は1,000アカウント、AWS Organizations経由なら10,000アカウントまでが上限で、権限委任の考え方そのものは[AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)で整理しています。

### ログ用バケットを除外リストへ登録して分析対象を絞り込む設定作業

有効化したら、請求が立ち上がる前に除外を入れます。自動機密データ検出から外せるバケットはアカウントあたり1,000個までで、組織の管理者アカウントの場合は組織全体でこの数になります。

```
# 1) 分類スコープIDだけを取り出す
aws macie2 get-automated-discovery-configuration \
  --query "classificationScopeId" --output text \
  --region ap-northeast-1

# 2) ログ用バケットを自動検出の除外リストへ追加する
aws macie2 update-classification-scope \
  --id 5cb1b0f8example00000000000000000 \
  --s3 '{"excludes":{"bucketNames":["my-cloudtrail-logs","my-alb-access-logs"],"operation":"ADD"}}' \
  --region ap-northeast-1

# 3) 感度スコアの高い順にバケットを並べて棚卸しの起点を決める
aws macie2 describe-buckets \
  --sort-criteria '{"attributeName":"sensitivityScore","orderBy":"DESC"}' \
  --max-items 20 \
  --query 'buckets[].[bucketName,sensitivityScore,classifiableObjectCount,unclassifiableObjectCount.total]' \
  --output table
```

operation には ADD・REMOVE・REPLACE を指定でき、REPLACE は現在のリストを丸ごと差し替えます。運用に載せるなら ADD と REMOVE で差分を当てるほうが事故が起きにくいでしょう。3番目のコマンドが出す表がそのまま棚卸しの作業リストになり、右端の分類不能オブジェクト数が多いバケットは、スコアが低くても安心材料にはなりません。

## 自動機密データ検出と検出ジョブの違い｜感度スコアの読み方と使い分け

機密データを探す経路は2つあります。どちらを先に回すかで初期費用も変わります。

### 自動機密データ検出の動き方｜48時間で結果が出始めるサンプリング

自動機密データ検出は、有効化すると全ての汎用バケットを対象に日次で動き続けます。代表的なオブジェクトをサンプリングして解析するため全件スキャンではなく、結果は有効化から48時間以内に出始めます（[自動機密データ検出の公式解説](https://docs.aws.amazon.com/macie/latest/user/discovery-asdd.html)）。

分析に使われるのは、既定ではAWSが推奨するマネージドデータ識別子のセットです。ここに自作のカスタムデータ識別子や許可リストを足したり、ログを溜めているバケットを除外したりできます。許可リストはアカウントあたり10件までで、定義済みテキスト型が1〜5件、正規表現型が1〜5件という内訳。テキスト型の1リストは10万エントリ・35MBが上限になります。

### 感度スコア-1から100の読み方｜50は未分析でありゼロ検出ではない

自動検出が有効なバケットには感度スコアが付きます。読み方を外すと運用の初動を間違えます。

| スコア   | ラベル                  | 実際に起きていること     |
| ----- | -------------------- | -------------- |
| \-1   | Classification error | 分類エラーで解析できていない |
| 1〜49  | Not sensitive        | 解析済みで検出が少ない    |
| 50    | Not yet analyzed     | 未着手か権限で読めない    |
| 51〜99 | Sensitive            | 機密データを検出済み     |
| 100   | Sensitive            | 手動で割り当てた固定値    |

厄介なのが50です。有効化直後の初期値でありながら、バケットポリシーがMacieのアクセスを拒否している場合も50のまま止まります。数日たっても50が並ぶバケットは、安全なのではなく読めていない可能性を先に疑ってください。-1も同様で、鍵を参照できないオブジェクトが原因になります。暗号化まわりの権限は[AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15884/)で扱ったキーポリシー側の設定に依存します。

1〜49の幅も直感と逆で、49に近いほど解析したオブジェクトが少なく、1に近いほど多数を解析した結果として検出が少ない状態を示します。数値が低いほど安心材料が厚い、と読んでください。ただし空のバケットにも1が付くため、オブジェクト数がゼロの行は別枠で扱います。自動検出を組織全体または単独アカウントで無効化すると、スコアとラベルは30日間だけ残り、その後は50（空なら1）へ戻る点も覚えておくと、途中で止めた環境の数字を誤読しません（[感度スコアの公式定義](https://docs.aws.amazon.com/macie/latest/user/discovery-scoring-s3.html)）。

### 検出ジョブを併用する場面｜対象を絞った深い分析と定期実行の設計

機密データ検出ジョブは、対象バケットと識別子を明示して走らせる全件寄りの分析です。1ジョブで指定できるバケットは1,000、カスタムデータ識別子は30まで。1回限りの実行と日次・週次・月次の定期実行を選べます。

実務では役割を分けます。自動検出で感度スコアの高いバケットを洗い出し、監査対象となるバケットだけをジョブで深掘りする流れです。最初から全バケットにジョブを当てると、分析GBがそのまま請求に乗ります。なお感度スコアはジョブの結果を反映しません。ジョブの作成APIには毎秒0.1リクエストという制限もあるため、パイプラインから大量のジョブを一度に作る設計は取れません。

## マネージドデータ識別子と日本の個人情報｜マイナンバーが出ない理由

ここが日本の案件で最初に詰まる部分です。カタログを見ずに導入すると、検出ゼロという結果を誤読します。

### マネージドデータ識別子の3カテゴリ｜認証情報・金融・個人情報の別

組み込みの識別子は、認証情報（Credentials）、金融情報（Financial information）、個人情報（PHIとPII）の3カテゴリに整理されています。認証情報にはAWSシークレットアクセスキー、OpenSSH秘密鍵、PGP秘密鍵、PuTTY秘密鍵、JWT、HTTP Basic認証ヘッダ、Stripe APIキー、Google Cloud APIキーなどが並びます。

金融情報はクレジットカード番号・有効期限・セキュリティコード、各国の銀行口座番号やIBANが対象です。個人情報側は運転免許証番号・パスポート番号・納税者番号などが国ごとに用意されています。多くの識別子は、値の近くにキーワードが存在することを検出条件に含みます。IBANのように数字の構造だけで判定できるものはキーワード不要です。

### 日本向け識別子が存在しない前提｜氏名と住所の検出が届かない範囲

公開されている識別子一覧に、日本を対象国とするものは含まれていません（[機密データ型別のクイックリファレンス](https://docs.aws.amazon.com/macie/latest/user/mdis-reference-quick.html)・2026年9月時点）。マイナンバー（個人番号）、日本の運転免許証番号、日本のパスポート番号、日本の銀行口座番号のいずれも、専用のマネージドデータ識別子が無い状態です。

汎用の識別子も日本語には届きません。氏名を検出するNAMEはラテン文字が前提で、漢字氏名は検出対象外です。住所のADDRESSは豪州・ブラジル・カナダ・フランス・ドイツ・イタリア・スペイン・英国・米国が対象で、日本の住所表記は含まれません。電話番号もブラジル・カナダ・フランス・ドイツ・イタリア・スペイン・英国・米国だけで、日本は対象外です。国民識別番号にあたる識別子もアルゼンチン・ブラジル・チリ・コロンビア・フランス・ドイツ・インド・イタリア・メキシコ・スペインの10か国にとどまります。

つまり日本語の顧客名簿を読ませても、クレジットカード番号や認証情報は拾える一方、氏名・住所・電話番号・マイナンバーはほぼ素通りします。国内案件でPIIの棚卸しを目的にするなら、カスタムデータ識別子の作成が実質的な必須作業です。概念そのものの整理は[PII（個人を特定できる情報）とは？piiデータの定義・種類と個人情報の違い](https://www.issoh.co.jp/column/details/5207/)を参照してください。検出後にデータを二次利用する前提なら、[匿名加工情報とは？加工基準と第三者提供の義務をデータ提供の設計要件に翻訳](https://www.issoh.co.jp/column/details/17446/)で扱った加工基準まで含めて設計すると手戻りが減ります。

## カスタムデータ識別子の設計｜正規表現とキーワード近接の実装指針

日本語データを扱う以上、カスタムデータ識別子の設計が成果を決めます。制約が独特なので、書く前に押さえる値があります。

### 正規表現の制約｜後方参照とキャプチャ非対応・512文字までの上限

Macieが解釈するのはPCREのサブセットです。後方参照、キャプチャグループ、条件パターン、埋め込みコード、再帰パターン、グローバルフラグ、先読みと後読みのゼロ幅アサーションは使えません。正規表現の長さは512文字まで（[カスタムデータ識別子の設定オプション](https://docs.aws.amazon.com/macie/latest/user/cdis-options.html)）。

性能面の制限にも注意が必要です。`\d{100,1000}` のような範囲指定の繰り返しはコンパイルが通らず、`\d{100,}` のような開放型へ書き換える対応が必要になります。`a*b*a*` のようにワイルドカードの繰り返しを並べた式も、同じ理由でコンパイルが通らない式です。大文字小文字を無視したい箇所には、フラグの代わりに `(?i)` を使います。アンカーが行頭行末ではなくファイル全体の先頭末尾に効く点も、書式チェック用の正規表現を流用するときに引っかかる部分でしょう。なお作成時にはサンプルテキストへの自動テストが走り、問題があればエラーが返ります。

### キーワードと最大一致距離｜既定50文字を日本語データで見直す観点

正規表現だけでは誤検出が増えます。そこで、一致テキストの近くに存在すべきキーワードを最大50個まで指定できます。各キーワードは3〜90文字で大文字小文字を区別しません。逆に、含まれていたら除外する無視ワードは最大10個・4〜90文字で、こちらは区別します。

近接の判定を握るのが最大一致距離です。キーワードの末尾から一致テキストの末尾までの文字数で、1〜300の範囲を指定でき、既定は50文字となっています。判定の仕方は、データの形に応じた3通りです。ExcelやCSV・TSVのような列指向データは列名かセル内の先行キーワードで判定し、Avro・Parquet・JSON・JSON Linesのようなレコード指向データは要素名や同一値の中のキーワードを見ます。PDF・Word・メール・プレーンテキストは純粋な文字数距離です。説明文が値の前に挟まる帳票では、既定の50文字では届きません。

### 重大度しきい値と作成後の不変性｜先にテストを回す運用ルールの決め方

検出結果の重大度は既定ではすべてMediumです。出現回数に応じてLow・Medium・Highのしきい値を最大3段階で設定でき、最小しきい値未満なら結果自体を作らない抑制もかけられます。1件の混入と1万件の混入を同じ扱いにしないための設定です。

注意すべきは、カスタムデータ識別子が作成後に変更できない点。監査の履歴を不変に保つための仕様であり、修正したければ新規作成して古いものを外す運用になります。アカウントあたり10,000個まで作れるので枠は足りますが、使わない識別子が積み上がる前提で命名規則を決めておくほうがよいでしょう。

### マイナンバー向けの識別子をAWS CLIで検証してから作成する手順

作る前の検証はコンソールの評価欄でもできますが、サンプルを変えながら繰り返すならCLIが速く済みます。期待どおりの箇所だけが当たることを確認してから、同じ条件で作成に進みます。

```
# 1) 作成前にサンプルテキストで当たり方を確かめる
aws macie2 test-custom-data-identifier \
  --regex "[0-9]{12}" \
  --keywords "マイナンバー" "個人番号" \
  --maximum-match-distance 100 \
  --sample-text "個人番号 123456789012 は要配慮の扱いとする" \
  --region ap-northeast-1

# 2) 期待どおりなら作成する（作成後は変更できない）
aws macie2 create-custom-data-identifier \
  --name "jp-my-number" \
  --description "12桁の個人番号。キーワード近接100文字で判定" \
  --regex "[0-9]{12}" \
  --keywords "マイナンバー" "個人番号" \
  --ignore-words "サンプル" "テストデータ" \
  --maximum-match-distance 100 \
  --severity-levels '[{"occurrencesThreshold":1,"severity":"LOW"},{"occurrencesThreshold":50,"severity":"MEDIUM"},{"occurrencesThreshold":100,"severity":"HIGH"}]' \
  --region ap-northeast-1
```

1番目のコマンドは一致件数と位置を返すので、注文番号や管理IDを巻き込んでいないかをここで潰します。12桁の数字だけを条件にすると誤検出が大量に出るため、キーワードと距離の調整が、精度の大半を決める要因です。帳票の見出しが値より前に長く入る様式では、100文字でも足りずに300へ寄せる判断になる場合もあります。

## 暗号化されたS3オブジェクトを分析させるKMSキーポリシーの設定作業

感度スコアが-1で止まる原因の多くはここです。暗号化方式によって、追加作業が要るものと要らないものが分かれます。

### 暗号化方式ごとの分析可否｜SSE-KMSとSSE-Cで結果が分かれる

SSE-S3で暗号化したオブジェクトは、Macieのサービスリンクロールがそのまま復号できます。SSE-KMSとDSSE-KMSも、AWSマネージドキーを使っているなら追加設定は不要です。手当てが要るのはカスタマー管理のKMSキーを使っている場合で、キーポリシー側でMacieに `kms:Decrypt` を許可するまで読めません（[暗号化S3オブジェクトの分析条件](https://docs.aws.amazon.com/macie/latest/user/discovery-supported-encryption-types.html)）。

SSE-Cとクライアントサイド暗号化は、どう設定しても復号できません。この2つに該当するオブジェクトについては、Macieはサイズやタグといったメタデータだけを記録します。バケットインベントリの暗号化種別フィルタで件数を数えられるので、有効化前に「そもそも読めない領域」がどれだけあるかを把握しておくと、検出ゼロの解釈を誤りません。

### キーポリシーへMacieのサービスリンクロールを追記する作業手順

キーとバケットが同一アカウントなら、キーポリシーに次の文を足すだけで済みます。Principalに指定するのは `AWSServiceRoleForAmazonMacie` のARNで、オプトインリージョンのアカウントではサービスプリンシパル部分にリージョンコードが入ります。

```
{
    "Sid": "Allow the Macie service-linked role to use the key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/aws-service-role/macie.amazonaws.com/AWSServiceRoleForAmazonMacie"
    },
    "Action": [
        "kms:Decrypt"
    ],
    "Resource": "*"
}
```

キーの所有者とバケットの所有者が別アカウントの場合は、キー側で `kms:Decrypt` と `kms:CreateGrant` を相手アカウントへ許可し、バケット所有者が自分のサービスリンクロールを被付与者とするグラントを作ります。対象キーが多い環境では、AWSが公開している[amazon-macie-scriptsリポジトリ](https://github.com/aws-samples/amazon-macie-scripts)のKMS Permission Analyzerで、許可が必要なキーの一覧と修正用のCLIコマンドをまとめて生成できます。

## Amazon Macieの料金体系と分析対象外｜費用が跳ねる条件を先に潰す

Macieの請求は3つの要素に分かれます。どこで膨らむかが分かっていれば、有効化前に手が打てます。

### 3つの課金要素｜バケット評価とオブジェクト監視と分析GB単価の別

us-east-1の公開価格（2026年9月時点）では、S3バケットの評価が1バケットあたり月0.10USDで、課金対象は最大10,000バケット。オブジェクトの監視は10万オブジェクトあたり月0.01USD。機密データの検出は自動検出・ジョブのいずれも1GBあたり1USDです（[Amazon Macieの公式料金ページ](https://aws.amazon.com/macie/pricing/)）。自動機密データ検出には毎月1GBの無料枠が付き、初回は30日間のトライアルでアカウントあたり最大150GBまで検査できます。単価はリージョンで異なるため、東京リージョンでの見積もりは料金計算ツールで確認してください。

比率を見ると構造が分かります。バケット1,000個の評価は月100USD、オブジェクト1億件の監視は月10USD程度ですが、1TBを解析すれば約1,000USD。費用のほぼ全部が分析容量から来ます。

### 費用が跳ねる典型パターン｜ログバケットと巨大ファイルの除外設計

請求が想定を超える原因は、ほぼ次の3つです。

- **ログバケットを対象に含める**：CloudTrailやALBのアクセスログは容量が大きく、検出価値は低い部類です。自動検出の除外リストへ先に入れておきます。監査証跡そのものの設計は[AWS CloudTrailとは？監査とセキュリティを強化する仕組み](/tech/details/17649/)の側で扱います。
- **大容量アーカイブを展開させる**：zipやtarは中身まで展開されるため、圧縮後のサイズと分析対象バイト数が乖離します。バックアップ置き場は除外候補です。
- **ジョブを日次で全件に当てる**：定期実行ジョブは実行のたびに課金されます。差分だけ見たいなら、作成日時や接頭辞、タグで対象を絞り込みます。

### クォータの実数で見る上限｜月5TBと抽出10GBの打ち切り条件

費用と並んで設計に効くのがクォータです。よく引っかかる値を実数で並べます（[Macieのクォータ一覧](https://docs.aws.amazon.com/macie/latest/user/macie-quotas.html)・2026年9月時点）。

| 対象          | 既定値         | 引き上げ       |
| ----------- | ----------- | ---------- |
| ジョブの月間分析量   | 5TB         | 1,000TBまで可 |
| 監視対象バケット数   | 10,000      | 不可         |
| 自動検出の除外バケット | 1,000       | 不可         |
| 1ジョブのバケット数  | 1,000       | 不可         |
| 1ジョブの識別子数   | 30          | 不可         |
| 1回のジョブの結果件数 | 10万件＋超過分の5% | 不可         |
| サンプル開示の回数   | 1日100回      | 不可         |

見落としやすいのが最初の行です。月5TBという上限は検出ジョブだけに適用され、自動機密データ検出はこの枠の外で動きます。「5TBで頭打ちになるはず」という前提で自動検出を回すと、想定より請求が伸びます。JSONの入れ子は256階層まで、氏名と住所の検出は1ファイルあたり1,000件で計上が止まる点も、網羅性を約束する資料を作るときには注記が要る条件でしょう。

## 検出結果の後続処理｜EventBridgeとSecurity Hubへ流す実装の型

検出しただけでは運用になりません。findingsをどこへ流し、どこまで自動化するかを設計します。

### 検出結果の2系統｜findingsと詳細な検出結果ログの保持期間の差

Macieが出力する結果は2系統。1つはfindingsで、バケット設定の劣化を示すpolicy findingsと、機密データの検出を示すsensitive data findingsに分かれます。後者は認証情報、金融情報、個人情報、カスタム識別子一致、複数該当の5タイプです。

findingsの保持期間はいずれも90日で、監査で過去1年分を求められると手元に残りません。もう1系統の[検出結果ログ](https://docs.aws.amazon.com/macie/latest/user/discovery-results-repository-s3.html)には解析した個々のオブジェクトの詳細が記録されますが、こちらは出力先のS3バケットとKMSキーを自分で設定します。長期保存が要件なら、有効化と同時にこのリポジトリ設定まで済ませてください。1件のfindingに載る検出箇所は15、検出結果ログ側は検出タイプごとに1,000箇所までという上限もあるため、件数の突き合わせをするときは両系統の数字がずれる前提で読みます。

### EventBridge連携の実装｜通知と自動遮断を分ける設計の勘どころ

findingsはEventBridgeへ配信されるため、イベントパターンで重大度やfindingタイプを絞り、Lambdaや通知へつなげる形が定番です。イベント駆動側の仕組みは[Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断を解説](https://www.issoh.co.jp/tech/details/15513/)で整理しています。

実装で分けるべきは、通知と自動遮断です。公開設定が変わったというpolicy findingsには、パブリックアクセスブロックを再適用する自動修復が成立します。ブロック設定の効き方そのものは[ブロックパブリックアクセス（VPC BPA）の設定手順とモード選択｜除外・遮断範囲・S3版との違い](https://www.issoh.co.jp/tech/details/4396/)で比較しました。一方、機密データを検出したというfindingsでオブジェクトを自動削除する実装は事故を招きます。誤検出があり得る以上、こちらは隔離バケットへの移動か通知に留めてください。Security Hub CSPMを使っているなら、[Macie.1（Macieの有効化・重要度Medium）とMacie.2（自動機密データ検出の有効化・重要度High）](https://docs.aws.amazon.com/securityhub/latest/userguide/macie-controls.html)のコントロールで有効化状態そのものを監視できます。誰がどの設定を変えたかの追跡は[AWS CloudTrail](/tech/details/17649/)の側で押さえます。

### EventBridgeルールをCLIで作成し公開頻度を決める作業

イベントの形は決まっていて、source は aws.macie、detail-type は Macie Finding です。重大度は detail.severity.description に Low・Medium・High のいずれかで入るので、Highだけを拾うルールはそのまま書けます。

```
# 重大度Highの検出だけをLambdaへ流す
aws events put-rule \
  --name MacieHighSeverityFindings \
  --event-pattern '{"source":["aws.macie"],"detail-type":["Macie Finding"],"detail":{"severity":{"description":["High"]}}}' \
  --region ap-northeast-1

aws events put-targets \
  --rule MacieHighSeverityFindings \
  --targets Id=1,Arn=arn:aws:lambda:ap-northeast-1:123456789012:function:macie-finding-handler \
  --region ap-northeast-1

aws lambda add-permission \
  --function-name macie-finding-handler \
  --statement-id AllowMacieFindingsRule \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-northeast-1:123456789012:rule:MacieHighSeverityFindings \
  --region ap-northeast-1
```

detail.category で POLICY と CLASSIFICATION を振り分ければ、自動修復系と通知系を別のターゲットへ送れます。抑制ルールで自動アーカイブされたfindingは配信されないため、ノイズはEventBridge側ではなくMacie側で先に落とすほうが素直です（[findingsの公開設定](https://docs.aws.amazon.com/macie/latest/user/findings-publish-frequency.html)）。Security Hub CSPMへは既定でpolicy findingsだけが送られる設定なので、機密データ検出も集約したい場合は公開先の設定を変える必要があります。SIEMへ集約する構成を先に決めているなら、[SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】](/tech/details/13310/)で整理した取り込み設計と合わせて経路を1本化すると運用が軽くなります。

## 受託開発でAmazon Macieを採用する条件と見送る場面の判断基準

論点はMacieを使うかどうかではなく、どこまで作り込むかにあります。

### Amazon Macieを採用する3つの条件｜監査要件とデータ棚卸しの必要

次のいずれかに当てはまるなら、Macieの導入価値があります。

- **どこに何があるか分からないS3が既にある**：長年運用したバケット群を人手で確認するのは現実的ではありません。自動検出でスコアを付け、優先順位を決める使い方が最も費用対効果に見合います。
- **認証情報の混入を継続的に見張りたい**：秘密鍵やAPIキーの検出は日本語の壁が無く、組み込みの識別子だけで機能します。デプロイ資材に鍵が混ざる事故の検出手段になります。
- **監査で保管データの分類を求められる**：機密データの所在を把握していると示す証跡が要る場合、findingsと感度スコアが客観的な資料になります。制度側の要件は[個人情報保護法改正とは？2026年7月公布の令和8年改正で企業対応はこう変わる](https://www.issoh.co.jp/column/details/13787/)で確認できます。

### 採用を見送ってよい場面｜対象がS3外や日本語主体のときの代替案

逆に見送ってよいのは、守りたいデータがS3の外にある場合です。RDSやDynamoDBに個人情報が入っているなら、Macieは直接読めません。ParquetでS3へエクスポートしてジョブを当てる回避策はありますが、エクスポート運用とストレージ費用が増えます。データベース側の暗号化とアクセス制御を先に固めるほうが投資対効果は高くなります。

もう1つは、検出したいのが日本語の氏名・住所だけというケースです。組み込みの識別子が役に立たず、カスタムデータ識別子で漢字氏名を安定して拾うのも簡単ではありません。漢字2〜4文字を拾えば誤検出が大量に出ますし、姓名リストとの突き合わせは守備範囲外です。アプリケーション側でデータ分類のメタデータを付与する設計へ寄せるほうが確実に回ります。メタデータ運用の型は[データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説](https://www.issoh.co.jp/column/details/13792/)にまとめました。バケットが少数で、格納するデータの種類を開発側が把握している小規模案件も、棚卸しする対象がありません。

### 機密データ保護の基盤構築を外部委託する際に確認する要件と成果物

Macieの導入は、有効化するだけなら数分で終わります。工数が乗るのは、除外バケットの選定、日本語データ向けカスタムデータ識別子の設計とテスト、findingsの通知経路、検出後の是正フローの整備です。外部へ委託するなら、対象バケットの範囲と除外基準、識別子の一覧と誤検出率の測定方法、findingsの保管先と保持期間、検出時の対応手順の4点を要件として明示しておくと、引き渡し後に運用が止まりません。

一創ではAWS上の設計・構築を受託し、S3のデータ配置からIAM・KMS・Macieを含むデータ保護の構成をIaCのコードとして納品しています。[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)では、既存環境の棚卸しから移行まで相談いただけます。

## よくある質問

導入検討でよく出る7つの質問に答えます。

### Amazon MacieとGuardDutyはどう使い分けますか？

見ているものが違います。GuardDutyはCloudTrailやVPCフローログから不審な挙動を検出する脅威検出サービスで、S3への異常なアクセスには反応しますが、オブジェクトの中身は読みません。「攻撃されているか」を見るのがGuardDuty、「漏れたら困るデータがどこにあるか」を見るのがMacieです。詳細は[Amazon GuardDutyとは？AWS環境の脅威検出サービスの基本的な概要と特徴を初心者向けに解説](/tech/details/17313/)で比較できます。両方を有効化しても機能は重複しません。

### Macieはマイナンバーを検出できますか？

標準では検出できません。日本を対象国とするマネージドデータ識別子が無いためです。検出するには、12桁の数字を拾う正規表現に「マイナンバー」「個人番号」といったキーワードと最大一致距離を組み合わせたカスタムデータ識別子を自作します。数字だけを条件にすると注文番号や管理IDを大量に拾うため、キーワード近接の設定が精度を左右します。本記事の作業手順に、テストから作成までのCLIコマンドを置きました。

### KMSで暗号化したS3オブジェクトも分析できますか？

AWSマネージドキーで暗号化したSSE-KMS・DSSE-KMSのオブジェクトは、追加設定なしで分析されます。カスタマー管理キーの場合は、キーポリシーでMacieのサービスリンクロールに `kms:Decrypt` を許可した範囲だけが対象です。許可されていないバケットの感度スコアは-1（分類エラー）になります。スコアが-1で止まるバケットを見つけたら、カバレッジ画面でエラー内容を確認し、キーポリシー側にサービスリンクロールを追加してください。SSE-Cとクライアントサイド暗号化は、どちらの設定でも復号できません。

### Macieを有効化するとS3のリクエスト料金も増えますか？

はい、増加の対象です。Macieは分析対象をS3から取得するため、その分のGETリクエスト料金が別途発生し、分析料金1USD／GBとは別勘定になります。加えて、Intelligent-Tieringの低頻度アクセス階層やGlacier Instant Retrievalのオブジェクトを読むと取り出し料金も乗ります。アーカイブ層に大量のデータを置く環境では、この間接費用まで含めて試算してください。

### 検出結果は90日を過ぎると消えてしまいますか？

findingsそのものは90日で参照できなくなります。長期に残す経路は2つ。検出結果ログの出力先S3バケットを設定して解析の詳細を蓄積するか、[EventBridge経由](https://docs.aws.amazon.com/macie/latest/user/findings-monitor-events-eventbridge.html)でfindingsをS3やデータストアへ転送するかです。監査で年単位の保管が要るなら、有効化と同時に組んでおいてください。

### 自動機密データ検出だけを止めて、バケットの監視は続けられますか？

できます。update-automated-discovery-configuration を DISABLED にすれば機密データ検出は止まり、バケット評価とpolicy findingsの生成は続きます。分析GBの課金が消える一方、バケット単価とオブジェクト監視の課金は残る形です。ただし組織全体または単独アカウントで無効化した場合、既存の感度スコアは30日で初期値へ戻ります。一時停止のつもりでも、30日を超えると棚卸しの結果は失われると考えてください。

### Macieの検出結果をそのまま社内の報告資料に使ってよいですか？

そのまま出すには早いでしょう。自動機密データ検出はサンプリングであり、全件を読んだ結果ではありません。分類不能オブジェクトは黙って除外され、氏名と住所の検出は1ファイル1,000件で計上が止まります。報告に載せるなら、対象バケット、除外したバケット、分類不能の件数、使った識別子の一覧を併記して、どこまでを見た数字なのかを明示するのが筋です。責任範囲の考え方は[クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方](https://www.issoh.co.jp/column/details/13266/)で整理しています。

## 関連記事

- [AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15884/)：暗号化オブジェクトを解析させる鍵の設計。
- [Amazon S3とは？オブジェクトストレージの仕組み・ストレージクラスと料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15433/)：検出対象となるストレージクラスの前提知識。
- [AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)：Macieのサービスロールと権限委任の基礎。
- [SIEMとは？仕組み・機能とEDR/XDR/SOARの違い・製品選定を実装視点で解説【2026年時点】](/tech/details/13310/)：findingsの集約先を決めるときの比較軸。
- [匿名加工情報とは？加工基準と第三者提供の義務をデータ提供の設計要件に翻訳](https://www.issoh.co.jp/column/details/17446/)：検出したデータを二次利用する際の加工基準。
- [データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説](https://www.issoh.co.jp/column/details/13792/)：検出に頼らずメタデータで分類する設計。
- [個人情報保護法とは？その定義と基本的な概念を解説](https://www.issoh.co.jp/column/details/5869/)：検出対象を決める上流の法的要件。
- [クラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方](https://www.issoh.co.jp/column/details/13266/)：責任共有モデルにおけるデータ保護の位置。

---

出典: [Amazon Macieとは？S3の機密データ検出の仕組み・料金と日本語データの限界を実装者目線で解説](<https://www.issoh.co.jp/tech/details/15886/>)（株式会社一創）