Googleドライブのメタデータを削除する方法：完全ガイドと特殊なケース

Informatec Digital »クラウド» Googleドライブでメタデータを削除する方法：完全ガイドと特殊なケース

Eliminarメタデータ Googleドライブで

クラウド上のファイルに付随する追加情報が気になる場合、目に見えないデータをどのように削除または制御すればよいのか疑問に思ったことがあるでしょう。Google ドライブでは、メタデータにはタグやインデックス可能なテキストからサムネイルやファイルプロパティまで、さまざまな種類があります。重要なのは、削除できるもの、更新のみ可能なもの、変更できないものを理解することです。そうすることで、何も壊さずに正確に操作できます。

このガイドでは、Googleの公式ドキュメントやヘルプ記事に散在する情報を一箇所にまとめています。ファイルからタグメタデータを削除する方法、インデックス可能なテキストとサムネイルを管理する方法、制限事項と例外事項について学ぶことができます。また、Google Cloudをご利用の場合に混乱を避けるため、類似のシナリオ（Cloud Storageの転送やCompute EngineのVMメタデータなど）についても解説しています。

ドライブのメタデータとは何ですか? また、この用語の範囲はどこまでですか?

Google ドライブでは、メタデータには、ファイル名、MIME タイプ、推測される拡張子、ラベル、インデックス可能なテキスト、および関連するサムネイルなどの情報が含まれます。一部の要素は編集または削除可能（例：ラベル）ですが、その他は間接的に更新されます（インデックス可能なテキストとサムネイル）。また、システムの一部であるため削除できない要素もあります（例：ファイルサイズ、内部作成日、更新日）。

Cloud Storage や Compute Engine など、他の Google Cloud プロダクトのメタデータへの参照も表示されます。 Cloud Storage 内の VM またはオブジェクトのメタデータとドライブ ファイルのメタデータを混同しないでください。; 概念は同じですが、管理方法や制限が異なります。
メタデータを管理する enドライブ

ドライブで実際に削除できるもの

実用的な観点から言うと、Driveで「メタデータの削除」と一般的に考えられているのは、ファイルに適用されたラベルの削除です。ラベルにはフィールド（テキスト、ユーザーなど）が含まれることがあり、それらを削除すると、そのファイルから関連情報が削除されます。この削除は、アトミック操作を使用したAPIを介して実行されます。

インデックス可能なテキスト（contentHints.indexableText）は、ボタンで単純に「削除」されるのではなく、ファイルリソースを更新する際に上書きされるか、空になります。これは、Googleドライブがネイティブにインデックスを作成しないファイルタイプの検索性を向上させるために設計されています。

カスタムサムネイルも同様に扱われます。別のサムネイル画像をアップロードするか、サムネイルの提供を停止することができます。Googleドライブが標準のサムネイルを生成できる場合は、独自のサムネイルを使用します。生成できない場合は、ユーザーが指定したサムネイルを使用します。

ファイルサイズや内部タイムスタンプなど、Drive の一部のメタデータは削除できません。これらのシステムプロパティはサービス自体によって更新されるため、直接削除することはできません。

Google ドライブのファイルからラベルを削除する

Drive APIでは、メソッドを使用してラベルを変更または削除できます。 files.modifyLabels. リクエストには、アトミックに適用される 1 つ以上の変更を含む ModifyLabelsRequest タイプのオブジェクトが含まれます。 (いずれかが有効でない場合は、何も適用されません)。

ファイルからタグを完全に削除するには、 LabelModification ラベル識別子と消去命令を使用します。 このプロセスにより、ファイル内のそのタグからすべてのフィールドが削除されます。特定のフィールドのみを無効にする必要がある場合は、タグ全体を削除せずに、そのフィールドを「設定解除」することができます。

特定のファイルからタグを削除するための概念的な手順: 1) ファイル内に存在するラベルのlabelIdを識別する （リストするには files.listLabels), 2) RemoveLabel を有効にして変更を送信します3) 応答に更新されたラベルの最終状態が含まれていることを検証します。

インデックス可能なテキスト：制御、制限、および優れた実践

アプリが、ドライブだけではインデックスされないファイル形式（描画、動画、ショートカットなど）を保存する場合は、次の情報を入力すると検索性を高めることができます。 contentHints.indexableText. このテキストは HTML として処理され、インデックス化され、結果の概要に表示される場合があります。 より多くの検索サーフェスで。

重要な推奨事項と制限事項：インデックス可能なテキストの最大サイズは 128 KB です。コンテンツを真に説明する用語と概念をキャプチャします。関連性に基づいてテキストを並べ替えようとしないでください。インデクサーは既に優先順位を付けています。保存するたびにテキストを更新します。無関係なキーワードで「埋める」ことは避けてください（ユーザーの不満を招き、削除を促す可能性があります）。

HTMLとして扱われるため、属性ではなくテキストコンテンツがインデックス化されることに注意してください。たとえば、文字列に属性を持つタグが含まれている場合、それらの属性の値ではなく、表示されるテキストがインデックス化されます。

サムネイル: アップロード、置き換え、回復

ドライブは、ドキュメント、スプレッドシート、スライドなどの種類のサムネイルを自動的に生成します。 ファイルの種類によって標準サムネイルが生成されない場合は、サムネイルを提供できます。 構成 contentHints.thumbnail ファイルを作成または更新するとき。

カスタムサムネイルの要件: PNG、GIF、または JPG を使用します。 推奨幅 1600 ピクセル （最小220ピクセル）; 最大ファイルサイズ2MB; URLセーフなbase64エンコードされた画像と mimeType 正解。 サムネイルは保存するたびに更新する必要がありますファイルの内容が変更されると無効になるためです (メタデータの変更だけでは無効になりません)。

サムネイルを取得するには、フィールドをチェックしてください thumbnailLink リソースの files. これは短命のリンクであり、アプリがコンテンツにアクセスできる場合にのみ表示されます。ファイルが公開されていない場合は、そのリンクを使用するには資格情報が必要になります。

REST 経由でサムネイルを使用してメタデータをクエリする例:

GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=id,name,mimeType,thumbnailLink
GET https://www.googleapis.com/drive/v3/files?q=mimeType='application/vnd.google-apps.spreadsheet'&fields=files(id,name,mimeType,thumbnailLink)

ファイル名と拡張子：知っておくべきこと

API経由でファイルを挿入する場合は、プロパティで拡張子を指定することをお勧めします。 name (例: cat.jpg)。 ドライブはその拡張子を次のように伝播します fileExtension 後続の応答では読み取り専用ユーザーがファイルをダウンロードするかデスクトップ クライアントに同期すると、タイトルに基づいてフル ネームが生成されます。

拡張子を指定しない場合、Drive は MIME タイプから拡張子を判別しようとします。予期せぬ問題を避けるため、可能な限り拡張子を指定してください。

メタデータの削除とファイルの削除を混同しないでください。

メタデータの削除とファイルの削除は異なる操作です。自分がファイルの所有者で、そのファイルをごみ箱に移動した場合、メタデータは削除されません。ドライブからファイルが削除されるだけです。削除オプション（自分が所有者でない場合）は、単に自分からファイルを非表示にするだけであり、他のユーザーには引き続き表示されます。

ウェブ上でファイルをゴミ箱に移動するには、drive.google.com にアクセスし、右クリックして「ゴミ箱に移動」を選択します。ファイルの所有者が他のユーザーの場合は、「削除」が表示されます。ファイルを完全に削除するには、ゴミ箱を空にします。これらの手順では、保存されているファイルからメタデータは削除されません。メタデータは、ファイルを削除するか、説明されているオプションを使用して管理する必要があります。

Cloud Storage メタデータの転送と保持（データを移動する場合）

ストレージ転送サービスを使用してクラウドストレージとの間でデータ転送を行う場合、どのメタデータを保持するか、どのメタデータを保持しないかについてのルールがあります。これは、バケットを使用してドライブを使用する場合や、クラウド間でデータを移行する場合に特に重要です。

Amazon S3または互換製品からクラウドストレージへ

• それらは保存されている 固定キーのメタデータ フィールド (例: Cache-Control、Content-Disposition、Content-Type)。
• ユーザー定義のメタデータは、 カスタムメタデータ Cloud Storage 内（編集可能）。
• El ETag キーでパーソナライズされて保存されます x-goog-source-etag.
• オブジェクトのサイズは次のように保存されます size.
• S3 アクセス制御リストとオブジェクトタグ: 保存されない.
• S3 タイムスタンプ メタデータ: 保存されないクラウドストレージでは、 timeCreated y updated 宛先での作成/更新の瞬間を反映します。
• ストレージ クラス: 転送中に構成可能 (デフォルトでは、宛先バケットのストレージ クラス)。

Microsoft Azure Blob からクラウド ストレージへ

• 修正されたキー メタデータ フィールド: それらは保存されています.
• ユーザー定義のメタデータ: カスタムとして保存されます クラウド ストレージで。
• ETag それは次のように保存されます x-goog-source-etag.
• サイズ sizeADLS Gen2 POSIX 権限と特定のアクセス制御: 保存されない.
• Azure タイムスタンプ メタデータ: 保存されない. timeCreated/updated 目的地で再計算されます。
• ストレージ クラス: S3 の場合と同様に構成可能です。

Cloud Storage バケット間

• 固定およびカスタムキーメタデータ: それらは保存されています.
• オブジェクト生成: カスタムメタデータとして保存 x-goog-reserved-source-generation.
• 保持: 一時的な保持はデフォルトで保持されますが、イベント ベースの保持は保持されません。 LCAに注意: これらを保持することはできますが、アクセスできないオブジェクトを作成しないようにしてください。
• ストレージ クラス: 保持するか、新しいものを設定するか、宛先バケットのものを使用します。
• CMEK暗号化: 保存するかどうかは任意; デフォルトでは、宛先バケット方式が使用されます。
• timeCreated 保管できる customTime; updated いいえ。
• その他の編集不可能なメタデータ（例： etag, componentCount): いいえ.

クラウドストレージへの URL のリスト

• 修正されたキー メタデータ フィールド: 編集可能 目的地にて。
• Content-Length y MD5: 編集できません ソースが提供する場合は保存されます。
• ソースタイムスタンプ: いいえ. ストレージ クラス: 構成可能。

POSIX からクラウド ストレージへ（およびその逆）

• mtime カスタムメタデータとして保存 goog-reserved-file-mtime.
• サイズは次のように保存されます size. UID、GID、MODE、シンボリックリンク: オプション 、 metadataOptions.
• POSIX から POSIX では、ファイルとフォルダーの UID/GID/MODE を保持できます。 mtime ファイルの場合は保存されます (フォルダーの場合は保存先の作成時間が使用されます)。

サービス間でデータを移行する際には、これらの詳細が重要になります。あるシステムでメタデータを削除しても、別のシステムでも自動的に削除されるとは限りません。各転送におけるデータ保持ルールを遵守してください。

Compute Engine（VM）メタデータ：Google Cloud を使用する場合の制限と削除

Driveではありませんが、多くのチームがCompute EngineのVMメタデータにアクセスしています。これを管理するには、適切なIAM権限と、サイズおよびスコープの制限に関する知識が必要です。

まず、Google Cloud CLIをインストールして、初めて実行します。 gcloud init (外部 ID プロバイダーを使用する場合は、フェデレーションでログインします。) CLIを最新の状態に保つには gcloud components update スコープ エラーを回避するために、デフォルトのリージョンとゾーンを設定します。

一般的に必要な権限: VMがサービスアカウントを使用する場合、 必要とされている iam.serviceAccounts.actAsプロジェクトレベルのメタデータの場合: compute.projects.get y compute.projects.setCommonInstanceMetadata. ゾーンメタデータの場合: compute.instanceSettings.get y compute.instanceSettings.update特定のVMのメタデータの場合: compute.instances.get y compute.instances.setMetadata.

主な制限: VMごとに設定されたメタデータの合計最大値は 512 KB; 各キーは 128バイト そして各値は 256 KBSSHキーは以下に保存されます ssh-keys; 制限を超えた場合、 未使用のキーをクリーンアップする時間です起動/シャットダウンスクリプトを直接コンテンツとして配置すると、制限にカウントされます。代わりに、スクリプトをクラウドストレージに保存して URLのみ提供.

大文字/小文字: キーは大文字と小文字を区別します; ブール値を除く値も同様です。ゾーンメタデータの場合：gcloud または REST でのみ管理されます。 大文字と小文字を変更して同じテキストのキーを複製することはできません （例：zonal-metadata-keyが既に存在する場合はZONAL-METADATA-KEYを作成します）また、ゾーン値を定義することはできません。 ssh-keys.

ブール値は、大文字と小文字を区別せずに、TRUE/FALSEのような同値表現と、Y/Yes/1やN/No/0のような選択肢を受け入れます。

適用範囲と優先順位：同じキー名はプロジェクトレベルとゾーンレベルの両方に存在できますが、ゾーン内ではゾーン値が優先されます。ゾーン値を追加すると、プロジェクトレベルの値が存在する場合でも、そのゾーン内の仮想マシンにはゾーン値が使用されます。プロジェクト値を追加しても、既存のゾーン値は上書きされません。

一般的な操作：プロジェクトメタデータ（すべてのVMに適用）、ゾーンメタデータ（そのプロジェクト内のゾーン内のすべてのVMに影響）、およびインスタンスメタデータ（1つのVMのみに適用）を設定できます。メタデータを削除するには、gcloudまたはRESTを使用して、必要に応じてプロジェクト、ゾーン、またはインスタンスのメタデータを削除できます。

ローカル環境でのRESTの使用：REST APIのサンプルでは、​​gcloud CLIに指定した認証情報を使用します。環境を認証し、その認証情報を再利用して、ローカルマシンから呼び出しをテストしてください。

ドライブのメタデータ衛生を改善するための実用的なヒント

ドライブ内のデータ量を削減したい場合は、自分でコントロールできるものに焦点を当てましょう。ラベル（価値がない場合は削除）、インデックス可能なテキスト（不要な場合は調整または空にする）、サムネイル（置き換えるかアップロードしない）などです。システムプロパティは監査用であり、削除用ではありません。

ファイルが共有されていて、あなたがそのファイルの所有者でない場合、自分の画面からファイルを削除しても、他のユーザーの画面からは何も削除されないことに注意してください。関連するコンテンツやメタデータを完全に削除したい場合は、所有者と調整してください。

Driveをクラウドストレージのフローや仮想マシンと統合する場合は、期待される動作を文書化してください。多くのメタデータはシステム間で変更されたり、転送されなかったりするため、タイムスタンプや保持されないACLに依存する自動化は避けてください。

これらのガイドラインに従うことで、真に効果のある要素をコントロールできるようになります。タグを正確に管理し、インデックス登録可能な要素を制御し、サムネイルの使用タイミングと方法を決定することで、プライバシー、検索性、ユーザーエクスペリエンスのバランスを取ることができます。