既知の問題

このページには、Sensitive Data Protection の既知の問題とともに、以下の問題を回避する方法や問題から復旧する方法が記載されています。

BigQuery に結果を保存する

ジョブまたは検出スキャンの結果が BigQuery に保存されているときに、Already exists エラーがログに記録されます。このエラーは、問題があることを示すものではありません。結果は予期したとおりに保存されます。

BigQuery のスキャン

このセクションでは、BigQuery データを検査またはプロファイリングを実施する際に発生する可能性のある問題について説明します。

検査とプロファイリングのオペレーションに共通の問題

次の問題は、BigQuery の検査オペレーションとプロファイリング オペレーションの両方に当てはまります。

行レベルのセキュリティが適用される行はスキャン不能

行レベルのセキュリティ ポリシーを使用すると、Sensitive Data Protection が、保護されている BigQuery テーブルを検査してプロファイリングするのを回避できます。行レベルのセキュリティ ポリシーを BigQuery テーブルに適用している場合は、TRUE フィルタを設定し、譲受人リストにサービス エージェントを含めることをおすすめします。

重複する行

BigQuery テーブルにデータを書き込む場合、Sensitive Data Protection によって重複する行が書き込まれることがあります。

最近ストリーミングされたデータ

Sensitive Data Protection は、最近ストリーミングされたデータ（旧称ストリーミング バッファ）をスキャンしません。詳細については、BigQuery ドキュメントのストリーミング データの可用性をご覧ください。

BigQuery の検査に関する問題

次の問題は、BigQuery データに対する検査オペレーションにのみ適用されます。データ プロファイルには影響しません。

エクスポートされた検出結果に row_number フィールドの値がない

Sensitive Data Protection を構成して検出結果を BigQuery に保存すると、入力テーブルのスキャン時に、生成された BigQuery テーブルの location.content_locations.record_location.record_key.big_query_key.row_number フィールドが推定されます。この値は非決定的であり、クエリされません。また、検査ジョブの場合は null になる場合があります。

結果が存在する特定の行を識別する必要がある場合は、ジョブの作成時に inspectJob.storageConfig.bigQueryOptions.identifyingFields を指定します。

識別するフィールドは、生成された BigQuery テーブルの location.content_locations.record_location.record_key.id_values フィールドで確認できます。

スキャンを新しい BigQuery コンテンツに制限する

スキャンを新しいコンテンツのみに制限し、BigQuery Storage Write API（gRPC） を使用して入力テーブルに入力している場合、Sensitive Data Protection が一部の行のスキャンをスキップする可能性があります。

この問題を軽減するには、検査ジョブで、TimespanConfig オブジェクトの timestampField が、BigQuery が自動生成する commit タイムスタンプであることを確認してください。 ただし、Sensitive Data Protection が最近ストリーミングされたデータから読み取ることはないため、行がスキップされないという保証はありません。

列の commit タイムスタンプを自動生成し、以前のストリーミング API を使用して入力テーブルにデータを入力する場合は、次の操作を行います。

  1. 入力テーブルのスキーマで、タイムスタンプ列の型が TIMESTAMP であることを確認します。

    サンプル スキーマ

    次の例では、commit_time_stamp フィールドを定義し、そのタイプを TIMESTAMP に設定しています。

    ...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...

  2. tabledata.insertAll メソッドの rows[].json フィールドで、タイムスタンプ列の値が AUTO に設定されていることを確認します。

    JSON の例

    次の例では、commit_time_stamp フィールドの値を AUTO に設定しています。

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}

最大割合または行数を設定してスキャンを制限する

テーブル行の合計数（rowsLimitPercent）に対する割合に基づいてサンプリング制限を設定すると、Sensitive Data Protection によって予想よりも多くの行を検査できます。スキャンする行数にハードリミットが必要な場合は、代わりに最大行数（rowsLimit）を設定することをおすすめします。

BigQuery プロファイリングに関する問題

次の問題は、BigQuery データに対するプロファイリング オペレーションにのみ適用されます。詳細については、BigQuery データのデータ プロファイルをご覧ください。

5 億テーブルを超える組織またはプロジェクト

5 億を超えるテーブルを含む組織またはプロジェクトをプロファイリングしようとすると、Sensitive Data Protection はエラーを返します。このエラーが発生した場合は、エラー メッセージの手順に沿って操作してください。

組織のテーブル数が 5 億を超え、テーブル数が少ないプロジェクトがある場合は、プロジェクト レベルのスキャンを実行します。

テーブルと列の上限については、データ プロファイリングの上限をご覧ください。

検査テンプレート

検査テンプレートは、プロファイリングするデータと同じリージョンに存在する必要があります。複数のリージョンにデータがある場合は、複数の検査テンプレートを使用します。データがあるリージョンごとに 1 つずつ使用します。global リージョンに保存されている検査テンプレートを使用することもできます。global リージョンにテンプレートを含めると、Sensitive Data Protection はリージョン固有のテンプレートのないデータにそれを使用します。詳細については、データ所在地に関する検討事項をご覧ください。

格納される infoType

検査テンプレートで参照される格納される infoType（格納されるカスタム辞書検出器とも呼ばれる）は、次のいずれかに格納する必要があります。

  • global リージョン。
  • 検査テンプレートと同じリージョン。

そうしないと、プロファイリング オペレーションはエラーResource not foundで失敗します。

リソースの可視性

テーブルのデータ プロファイルでは、BigQuery テーブルに付与されるリソースの可視性分類は、テーブルの可視性ではなく、テーブルを含むデータセットの可視性によって異なります。したがって、テーブルの IAM 権限がデータセットの IAM 権限と異なる場合、データ プロファイルに示されるテーブルのリソースの可視性が正しくない可能性があります。この問題は、BigQuery の検出と Vertex AI の検出に影響します。

Google Cloud コンソールでは、リソースの公開設定はテーブル データ プロファイルの [公開] フィールドに表示されます。Cloud Data Loss Prevention API では、リソースの公開設定は TableDataProfile の resourceVisibility フィールドに示されます。

有効期限のないテーブルの有効期限タイムスタンプが正しくない

2025 年 7 月から 2026 年 6 月までの間に BigQuery に保存された一部のテーブルデータ プロファイルには、有効期限のないテーブルの expiration_time に NULL ではなく、誤った 1970-01-01 タイムスタンプが含まれていました。

Cloud Storage のスキャン

このセクションでは、データの検査または匿名化を実施する際に発生する可能性のある問題について説明します。

Strict XLSX ファイルの検査はサポートされていません

拡張子が .xlsx のファイルには、2 つのタイプがあります。1 つは Strict Office Open XML スプレッドシートで、これは Sensitive Data Protection ではサポートされていません。もう 1 つのタイプは、デフォルトの Microsoft Excel ワークブックです。これはサポートされています。

バイナリモードでスキャンされる構造化ファイル

一般的に構造化解析モードでスキャンされるファイルがバイナリモードでスキャンされる場合がありますが、これには構造化解析モードの拡張機能は含まれてません。詳細については、構造化解析モードで構造化ファイルをスキャンするをご覧ください。

区切りファイルの匿名化

検査ジョブで区切り文字で区切られたファイル（CSV ファイルなど）を匿名化すると、出力の一部の行に空のセルが追加されることがあります。これらの余分なセルを回避する回避策は、代わりに content.deidentify メソッドを使用してデータを匿名化することです。

Cloud SQL の検出

Security Command Center の重複する検出結果

Cloud SQL データ プロファイリングは、Security Command Center への検出結果の公開をサポートしています。

2024 年 4 月 25 日より前に、Security Command Center で Cloud SQL インスタンスの重複する検出結果が Sensitive Data Protection によって生成されるバグが発生していました。これらの検出結果は一意の検出結果 ID で生成されましたが、同じ Cloud SQL インスタンスに関連しています。問題は解決されましたが、重複する検出結果がまだ存在します。重複をミュートして、Security Command Center の [検出結果] ページで非表示にできます。

Amazon S3 の検出

Sensitive Data Protection が Security Command Center に送信する Amazon S3 の検出結果には、影響を受けるリソースの AWS アカウント ID または表示名に関する情報が含まれていない場合があります。通常、これは次のような場合に発生します。

  • 検出結果が Security Command Center に送信される時点で、AWS コネクタが有効になってから約 24 時間しか経過していなかった。
  • 検出結果が Security Command Center に送信されるまでに、AWS アカウントが AWS コネクタに含まれていたのは約 24 時間のみでした。

この問題を解決するには、約 24 時間後に、削除するか、プロファイリング スケジュールを設定して、データ プロファイルを再生成します。検出結果の詳細は Security Command Center に送信されます。

インテリジェントなドキュメント解析

このセクションでは、ドキュメントの解析に関連する既知の問題について説明します。

DocumentLocation オブジェクトにデータが入力されていない

インテリジェント ドキュメント解析スキャンモードでは、location.content_locations.document_location.file_offset フィールドに値が入力されません。

検出

次の既知の問題は、実行しているオペレーション（検査、匿名化、検出）に関係なく、検出に関する問題を示しています。

辞書に載っている単語

Unicode 標準の補助多言語面の文字を含む辞書の単語は、予期しない結果になる可能性があります。そのような文字の例には、絵文字、科学記号、歴史的な文字があります。