[AEM Assets]{class="badge positive" title="AEM Assetsに適用）。"}
Adobe Experience Manager as a Cloud Service Assets へのデジタルアセットの追加 add-assets-to-experience-manager
Adobe Experience Manager Assets は、様々な種類のデジタルアセットを様々なソースから受け取ります。 元のバイナリと生成されたレンディションを保存し、ワークフローとAdobe AI サービスを使用してアセットを処理し、多くのチャネルとサーフェスにコンテンツを配信します。
Adobe Experience Managerは、アップロードされたデジタルファイルのバイナリコンテンツを自動的に強化し、アセットをより検索しやすく、再利用しやすく、配信の準備ができるようにします。 Experience Manager様は、これらのファイルをリッチメタデータ、スマートタグ、レンディションおよびその他デジタルアセット管理（DAM） サービスで強化します。 画像、ドキュメント、生の画像ファイルなど、様々な種類のファイルを、ローカルフォルダーまたはネットワークドライブから Experience Manager Assets にアップロードできます。
リポジトリにアセットを追加する方法
最も一般的に使用されるブラウザーのアップロードに加えて、Experience Manager リポジトリにアセットを追加する他の方法も存在します。 その他の方法には、Adobe Asset LinkまたはExperience Manager個のデスクトップアプリなどのデスクトップクライアント、顧客が作成するアップロードおよび取り込みスクリプト、自動取り込み統合がExperience Manager個の拡張機能として追加されています。
その他のサービスと処理
Experience Managerで任意のバイナリファイルをアップロードおよび管理できますが、最も一般的に使用されるファイル形式は、メタデータ抽出やプレビュー/レンディション生成などの追加サービスをサポートしています。 詳しくは、サポートされているファイル形式を参照してください。
アップロードしたアセットに対して追加の処理を行うように選択することもできます。 アセットをアップロードするフォルダーに複数のアセット処理プロファイルを設定して、特定のメタデータ、レンディション、画像処理サービスを自動的に追加できるため、アセットが手動で介入することなく配信要件を満たすことができます。 アップロード時のアセットの処理を参照してください。
アップロード方法の概要
Assets では、次のアップロード方法を提供しています。 Adobeでは、ボリューム、ワークフロー、関連するペルソナによって適切な方法が異なるため、使用する前に、ユースケースと各アップロードオプションの適用性を理解することをお勧めします。
アセットのアップロード upload-assets
Adobe Experience Manager Assetsは、1つのファイルまたは複数のファイルをアップロードする2つの方法をサポートしています。 デスクトップから直接Assets ユーザーインターフェイス （web ブラウザー）にファイルを ドラッグ&ドロップして保存先フォルダーに移動するか、作成メニューを使用してAssets ユーザーインターフェイス内からアップロードを開始します。 どちらの方法も、選択したフォルダーの場所にデジタルアセットを追加します。
-
Assets ユーザーインターフェイスで、デジタルアセットを追加する場所に移動します。
-
アセットをアップロードするには、次のいずれかの方法を使用します。
- ツールバーで、作成／ファイルをクリックします。 表示されたダイアログで、必要に応じてファイル名を変更できます。
- HTML5をサポートしているブラウザーで、アセットをAssets ユーザーインターフェイスに直接ドラッグします。 この方法では、ファイル名を変更ダイアログは表示されません。
複数のファイルを選択するには、
Ctrlキー（Windows）またはCommandキー（macOS）を押しながら、ファイルピッカーダイアログでアセットを選択します。 iPad を使用している場合、一度に選択できるファイルは 1 つだけです。 -
進行中のアップロードをキャンセルするには、進行状況バーの横にある閉じるボタン（「
X」）をクリックします。 キャンセルすると、処理中の転送が停止するため、Assetsは現在のアセットの部分的にアップロードされた部分を削除して、不完全なファイルを残さないようにします。 すべてのファイルをアップロードする前にアップロード操作をキャンセルすると、Assetsは現在のファイルのアップロードを停止し、コンテンツを更新します。 ただし、アップロードが完了したファイルは削除されず、保存先フォルダーに残ります。 -
Assetsのアップロードの進捗状況ダイアログには、正常にアップロードされたファイルの数とアップロードに失敗したファイルが表示され、バッチの明確なステータスが表示されます。 さらに、Assets ユーザーインターフェイスには、アップロードした最新のアセットまたは最初に作成したフォルダーが表示されます。
既存のアセットのアップロードの処理 handling-upload-existing-file
同じパス（同じ名前と場所）を持つアセットを既存のアセットトリガーとしてアップロードすると、3つの解決策オプションが表示される警告ダイアログが表示されます。既存のアセットの置き換え、別のバージョンを作成、または両方を維持。 各オプションは、重複を異なる方法で処理します。
-
既存のアセットを置き換える：既存のアセットを置き換えると、そのアセットが完全に上書きされるため、既存のアセットに適用されたメタデータと以前の変更（注釈や切り抜きなど）は完全に削除されます。 これは、置き換えが履歴を保持するのではなく、保存されたアセットを書き込むために発生します。
note NOTE アセットを置き換えるオプションは、アセットがロックされているかチェックアウトされている場合は使用できません。 -
別のバージョンを作成：既存のアセットの新しいバージョンがリポジトリに作成され、以前の状態が保持されるため、作業が失われることはありません。 タイムラインに 2 つのバージョンを表示することができ、必要に応じて、以前の既存バージョンに戻すことができます。
-
両方を保持：両方のアセットを保持することを選択した場合、新しいアセットの名前が変更され、元のアセットと新しくアップロードされたアセットの両方が共存します。
Assets で重複アセットを保持するには、「保持」をクリックします。 アップロードした重複アセットを削除するには、「削除」をクリックします。
ファイル名の処理と禁止文字 filename-handling
Adobe Experience Manager（AEM） Assetsは、ファイル名に禁止された文字が含まれているアセットのアップロードをブロックします。 ファイル名に1つ以上の許可されていない文字が含まれている場合、Assetsは警告メッセージを表示し、許可されていない文字が削除されるか、ファイル名が許可された名前に変更されるまで、アップロードをブロックします。 このセーフガードはアップロード時に実行されるため、問題のあるファイル名はアセットがリポジトリに入る前に検出されます。
これらの制限が存在する理由
ファイル名の文字制限により、アセット名とフォルダー名がファイルシステム、ストレージレイヤー、web URLをまたいで互換性を保つことができます。 スラッシュ、コロン、およびその他の予約済みシンボルなどの文字は、ファイルパスおよびURLに特別な意味を持つため、これらの文字を制限すると、名前の競合、リンクの破損、および配信エラーがダウンストリームで発生するのを防ぐことができます。
組織の特定のファイル命名規則に合わせて、Assetsをアップロード ダイアログを使用すると、アップロード時に長いファイル名を指定できます。 以下の文字（スペース区切りリスト）はサポートされません。
- アセット名の無効な文字：
* / : [ \\ ] | # % { } ? &または;=（セミコロンの後に等号が続く） - アセットフォルダー名に無効な文字：
* / : [ \\ ] | # % { } ? \" . ^ ; + & \t
無効なファイル名の例：
JPG_JD_small file ~!)$@;(-_=+^',..jpgJPG_JD_small file ~!)$@;=(-_+^',..jpg
上記のリストの予約文字が含まれているため、両方の例は拒否されます。 アップロードを正常に行うには、アップロードを再試行する前に、禁止されている文字を削除するか、許可されている代替文字に置き換えます。
アセットの一括アップロード bulk-upload
一括アセット取り込み機能は、大量のアセットを効率的に処理します。 大規模な取り込みは、広範囲のファイルダンプや一時的な移行ではありません。 大規模な取り込みを、ビジネスの目的を効率的に果たす有意義なプロジェクトにするには、移行を計画し、アセット組織を慎重にキュレーションします。 取り込み方法は一つひとつ異なるため、一般的なルールを適用するのではなく、特定のリポジトリ構成とビジネスニーズを考慮する必要があります。 一括取り込みの計画と実行には、次のベストプラクティスが役立ちます。
- アセットのキュレート: デジタルアセット管理（DAM）リポジトリで必要のないアセットを削除します。 未使用、未サポート、または重複するアセットの削除を検討してください。 これにより、転送されるデータと取り込まれるアセットの数が減少し、より迅速で信頼性の高い取り込みが可能になります。
- アセットの整理：ファイルサイズ、ファイル形式、ユースケース、優先度など、定義された論理的な順序でコンテンツを整理することを検討します。 大規模で複雑なファイルでは、より多くの処理時間とシステムリソースが必要なため、ファイルを分離することで処理のボトルネックを防ぐことができます。 サイズの大きいファイルは、ファイルサイズフィルターオプション（以下で説明）を使用して個別に取得することも検討できます。
- Stagger ingestions：複数の一括取り込みプロジェクトへの取り込みを分割することを検討してください。 時間差取り込みでは、コンテンツをより早く確認し、必要に応じて取り込みを調整できます。 例えば、処理負荷の高いアセットをピーク以外の時間帯に取得したり、複数のチャンクに分けて徐々に取得したりすることができます。 ただし、それほど処理を行う必要のない、小さくシンプルなアセットは一度に取得することができます。
より多くのファイルをアップロードするには、次のいずれかの方法を使用します。 使用例とメソッドも参照してください。
- アセットアップロード API：必要に応じて、API を活用したカスタムアップロードスクリプトまたはツールを使用して、アセットの処理（メタデータの翻訳やファイル名の変更など）を追加します。
- Experience Manager デスクトップアプリ ：ローカルファイルシステムからアセットをアップロードするクリエイターやマーケターに役立ちます。 ローカルで使用可能なネストされたフォルダーをアップロードするために使用します。
- 一括取り込みツール：大量のアセットを取り込む場合、不定期に取り込むためや Experience Manager をデプロイ時に最初に取り込むために使用します。
アセット一括読み込みツール asset-bulk-ingestor
アセット一括読み込みツールは、Microsoft Azure Blob StorageまたはAmazon Simple Storage Service （S3） データストアからアセットを大規模に取り込む 管理者グループ のみが使用できます。 一括取り込みは、多数のアセットを直接リポジトリに移動する特権付きの大規模な操作であり、安全に設定するには高度な権限が必要なため、管理者にアクセスは制限されます。 設定と取り込みの手順を紹介するビデオを参照してください。
次の画像は、管理者がデータストアからAdobe Experience Managerにアセットを取り込む際の様々なステージを示しています。 取り込みは、ステージングされたパイプラインを通じて進行します。このパイプラインでは、接続されたオブジェクトストレージからアセットが読み取られ、転送され、Experience Managerに処理されます。これにより、大量のバッチが確実に処理されます。
前提条件
この機能を使用するには、Microsoft Azureまたは Amazon Web Services （AWS） の外部ストレージアカウントまたはバケットが必要です。 一括読み込みプロセスでは、この外部アカウントからソースアセットを直接読み込むため、適切に設定されたAzureまたはAWSのストレージの場所が必須の前提条件となります。
一括読み込みツールを設定 configure-bulk-ingestor-tool
Adobe Experience Managerで一括読み込みツールを設定するには、次の手順に従います。
-
ツール／Assets／一括取得に移動します。 「作成」オプションを選択します。
-
「タイトル」フィールドで一括読み込み設定のタイトルを指定します。
-
「ソースを読み込み」ドロップダウンリストからデータソースのタイプを選択します。
-
データソースとの接続を作成するための値を指定します。 例えば、データソースとして Azure Blob Storage を選択した場合は、Azure ストレージアカウント、Azure BLOB コンテナ、Azure アクセスキーの値を指定します。
-
ドロップダウンリストから必要な認証モードを選択します。 2つのモードは、付与するアクセスのレベルが異なります。Azure アクセスキーは、Azure ストレージアカウントへの完全で無制限のアクセスを提供しますが、Azure SAS トークンは、管理者が権限ポリシーと有効期限ポリシーを使用してトークンの機能を制限することを許可します。 その結果、Azure SAS トークンは、より制限の厳しいオプションであり、範囲が限定された期限付きアクセスのみを許可します。
-
「ソースフォルダー」フィールドでデータソースのアセットを含むルートフォルダーの名前を指定します。
-
（オプション）アセットの最小ファイルサイズを MB 単位で指定して、「最小サイズでフィルター」フィールドの取り込みプロセスにアセットを含めます。
-
（オプション）アセットの最大ファイルサイズを MB 単位で指定して、「最大サイズでフィルター」フィールドの取り込みプロセスにアセットを含めます。
-
（オプション）「MIME タイプを除外」フィールドで、取り込みから除外するMIME タイプのコンマ区切りリストを指定します。 MIME タイプは各アセットのファイル形式を識別するので、このフィルターを使用すると、読み込みたくない形式をスキップできます。 （例：
image/jpeg, image/.*, video/mp4）。 サポートされるすべてのファイル形式を参照してください。 -
取り込みに含めるMIME タイプのコンマ区切りリストをMIME タイプを含める フィールドに指定します。 サポートされるすべてのファイル形式を参照してください。
-
ファイルが Experience Manager に読み込まれた後、ソースデータストアから元のファイルを削除するには、「読み込み後にソースファイルを削除」オプションを選択します。 これにより、ソースデータストア内のストレージが再利用され、同じファイルが後の実行で再インポートされるのを防ぐことができます。
-
「読み込みモード」を選択します。 「スキップ」、「置換」または「バージョンを作成」を選択します。 スキップ モードがデフォルトです。一致するアセットが既にターゲットに存在するため、インジェスターは読み込みをスキップし、既存のコンテンツを上書きしないようにします。 「置換してバージョンを作成」オプションの意味を参照してください。
-
Experience Managerがアセットを読み込むデジタルアセット管理（DAM）の場所を定義するには、Assets Target Folder フィールドにパスを指定します。 例：
/content/dam/imported_assets -
（オプション）「メタデータファイル」フィールドに、CSV 形式で読み込むメタデータファイルを指定します。 ソース BLOBの場所でCSV ファイルを指定し、一括読み込みツールの設定時にパスを参照します。 このフィールドで参照されるCSV ファイル形式は、 アセットメタデータを一括でインポートおよびエクスポートする際に使用するCSV ファイル形式と同じです。 「インポート後にソースファイルを削除」オプションを選択した場合は、メタデータ CSV自体がアセットとして削除または取り込まれることを防ぐため、除外またはMIME タイプを含める フィールドまたはパス/ファイルでフィルター フィールドのいずれかを使用してCSV ファイルをフィルタリングします。 正規表現を使用して、これらのフィールドの CSV ファイルをフィルタリングできます。
-
「保存」をクリックして、設定を保存します。
一括読み込みツールの設定を管理 manage-bulk-import-configuration
一括読み込みツール設定を作成した後、アセットをExperience Manager インスタンスに一括取り込む前に、設定を検証および評価できます。 この段階で設定を管理すると、設定を確認し、アセットソースへの接続を確認して、設定をテストできます。 これにより、設定が期待どおりに動作し、アセットを大規模に読み込む前に取り込みエラーを防ぐことができます。
設定管理オプションへのアクセス access-configuration-management-options
一括読み込みツールの設定を管理するための使用可能なオプションを表示するには、ツール > Assets > 一括読み込みに移動し、管理する設定を選択します。 設定を選択すると、その特定の設定で使用可能な管理アクションが表示され、フルバルク読み込みを開始する前に設定を検査、評価、調整できます。 取り込みの前に評価を行うため、構成の問題を早期に特定して解決でき、アセットの読み込みが失敗したり不完全になったりするリスクを軽減できます。
設定を編集します。 edit-configuration
設定の詳細を編集するには、次の手順に従います。
- 変更する設定を選択します。
- 編集をクリックして、編集モードで設定を開きます。
- 必要に応じて編集可能な設定の詳細を更新し、変更を保存します。
2つのフィールドは修正されたままであり、編集操作中に変更できません。設定の タイトル とデータソースの読み込み。 これらの値は、設定のIDとインポートされたデータの出所を定義するため、ロックされ、作成後に変更すると、設定が最初に設定されたときに確立された参照が壊れます。 その他のすべての設定の詳細は引き続き編集可能であり、設定をゼロから再作成することなく設定を調整できます。
設定を削除 delete-configuration
一括読み込み設定を削除すると、使用可能な設定のリストから完全に削除されます。 設定が不要になった場合、エラーで作成された場合、または更新された設定で置き換える場合は、設定を削除します。
一括読み込み設定を削除するには、次の手順に従います。
- 一括読み込み設定のリストから削除する設定を選択します。
- 「削除」をクリックします。
このアクションは、選択した一括読み込み設定を削除します。 設定を削除すると保存された設定が削除されるため、選択した設定を慎重に確認してから削除を確認し、まだ使用されている設定を削除しないようにします。
データソースへの接続を検証 validate-connection
接続を検証すると、Experience Managerがデータソースに到達できること、および指定された資格情報と接続パラメーターが正しいことを確認してから設定を使用できます。 このチェックを最初に実行すると、到達不能なエンドポイントまたは無効な認証によって引き起こされるダウンストリームエラーが防止されます。
データソースへの接続を検証するには、次の手順に従います。
- 検証する設定を選択します。
- 「check」をクリックします。
接続が成功すると、データソースへの接続が確立されたことを示す確認メッセージがExperience Managerに表示されます。 このメッセージは、設定が有効であり、使用する準備ができていることを確認します。
失敗した接続のトラブルシューティング troubleshoot-connection
検証が成功しない場合、Experience Managerは成功確認の代わりにエラーメッセージを表示します。 失敗した接続を解決するには、次の点を確認します。
- 接続の詳細：構成内のホスト、ポート、およびエンドポイントの値が正しく入力されていることを確認します。
- 資格情報： データソースに指定されたユーザー名、パスワード、または認証トークンが有効で最新であることを確認します。
- ネットワークアクセス： Experience Managerがネットワーク経由でデータソースにアクセスでき、ファイアウォールまたはセキュリティルールが接続をブロックしていないことを確認します。
設定を修正した後、checkをもう一度クリックして、検証を再実行します。 成功メッセージで接続が確立されたことを確認するまで、このプロセスを繰り返します。
一括読み込みジョブのテスト実行を呼び出す invoke-test-run-bulk-import
設定を選択し、「ドライラン」をクリックして、一括読み込みジョブのテスト実行を呼び出します。 ドライランは、選択した一括読み込み設定とそのソース接続 をアセット を読み込まずに検証します。これにより、完全な読み込みにコミットする前に、設定が正しいことを確認できます。 最初にテストを実行すると、実際のジョブ中ではなく事前に設定や接続性の問題が表示されるため、インポートが失敗または部分的に発生するリスクが軽減されます。
テスト実行が完了すると、Experience Managerには一括読み込みジョブに関する次の詳細が表示されます。
- 接続ステータス – 指定された資格情報を使用して、設定されたソースの場所にExperience Managerが正常に接続したかどうかを示します。
- Assetsが検出されました — インポート条件に一致するソースパスで見つかったアセットの数。
- 推定インポート スコープ — インポートされるコンテンツの概要。目的のファイルを対象とした設定を確認できます。
- 警告またはエラー – 到達できないパス、無効な資格情報、サポートされていないアセットなど、インポートが成功しない問題。
これらの詳細を確認して、設定が正しいことを確認します。 ドライランでエラーまたは警告が報告された場合は、それらを解決し、実際の一括読み込みジョブを開始する前にテストを再度実行します。
一括読み込み時のファイル名の処理 filename-handling-bulkimport
アセットやフォルダーを一括で読み込む場合、Experience Manager Assets は、インポートソースに存在する情報の構造全体を読み込みます。 Experience Managerは、アセット名とフォルダー名の特殊文字に対する組み込みのルールに従うため、これらのファイル名にはサニタイズが必要です。 これにより、読み込まれた名前がリポジトリルールに準拠し、アセットのパスを壊さないようにすることができます。 フォルダー名とアセット名の両方について、ユーザーが定義したタイトルは変更されず、Java コンテンツリポジトリ （JCR） プロパティ jcr:titleに保存されます。このプロパティは、消去済みの技術名とは独立して、人間が読み取れるタイトルを保持します。
一括読み込み中に、Experience Managerは既存のフォルダーを検索して、アセットとフォルダーの再インポートを回避します。また、読み込みが行われる親フォルダーに適用されるサニタイゼーションルールも検証します。 親フォルダーにサニタイズルールが適用される場合、インポートソースにも同じルールが適用されます。 新規読み込みの場合、アセットやフォルダーのファイル名を管理するために、次のサニタイズルールが適用されます。
一括読み込みで使用できない名前
次の文字は、ファイル名とフォルダー名に使用できません:
- コントロールおよびプライベート使用文字 （0x00 ～ 0x1F、\u0081、\uE000）
- ファイル名またはフォルダー名末尾にドット （。）
その結果、これらの条件に一致する名前を持つファイルまたはフォルダーは、インポートプロセス中にスキップされ、失敗としてマークされます。
一括読み込みでのアセット名の処理
アセットファイル名の場合、Experience ManagerはJCR名とパスをAPI JcrUtil.escapeIllegalJcrCharsを使用してサニタイズします。
-
Unicode 文字は変更されません。
-
特殊文字を URL エスケープコードに置き換えます。例えば、
new%asset.pngはnew%25asset.pngに更新されます。code language-none URL escape code " %22 % %25 ' %27 * %2A / %2F : %3A [ %5B \n %0A \r %0D \t %09 ] %5D | %7C
一括読み込みでのフォルダー名の処理
フォルダー名の場合、Experience ManagerはJCR名とパスをAPI DamUtil.getSanitizedFolderNameを使用してサニタイズします。
-
大文字は小文字に変換されます。
-
Unicode 文字は変更されません。
-
特殊文字をダッシュ（「-」）に置き換えます。例えば、
new folderはnew-folderに更新されます。code language-none " # % & * + . : ; ? [ ] ^ { } | / It is used for split folder in cloud storage and is pre-handled, no conversion here. \ Not allowed in Azure, allowed in AWS. \t space It is the space character.
1 回限りの一括読み込みまたは繰り返しの一括読み込みのスケジュール設定 schedule-bulk-import
1 回限りの一括読み込みまたは繰り返しの一括読み込みをスケジュール設定するには、次の手順に従います。
-
一括読み込み設定を作成します。
-
設定を選択し、ツールバーの「スケジュール」を選択します。
-
1 回限りの取り込みを設定するか、1 時間ごと、1 日ごと、または 1 週間ごとのスケジュールを設定します。 「送信」をクリックします。 繰り返しスケジュールを使用すると、手動で再実行することなく、定義された間隔でインポートソース内の新しいアセットが自動的に取り込まれます。
Assets ターゲットフォルダーの表示 view-assets-target-folder
一括読み込みジョブの実行後にアセットが読み込まれるAssets ターゲットの場所を表示するには、設定を選択し、Assetsを表示をクリックします。
一括読み込みツールの実行 run-bulk-import-tool
一括読み込みツールの設定と、オプションで一括読み込みツールの設定の管理の後、管理者は構成ジョブを実行してアセットの一括取り込みを開始できます。
一括読み込みプロセスを開始するには、ツール／Assets／一括読み込みに移動し、「一括読み込み設定」を選択して、「実行」をクリックします。 もう一度「実行」をクリックして確認します。
Experience Managerは、ジョブが正常に完了すると、ジョブのステータスを 処理中 および 成功 に更新します。 読み込んだアセットをExperience Managerで表示するには、表示Assetsをクリックします。
ジョブが進行中の間、取り込みプロセスは次のように制御できます。
- 停止 – 設定を選択し、停止をクリックして、一括取り込みプロセスを停止します。
- 実行 — 実行をもう一度クリックして、停止した場所からプロセスを再開します。
- ドライ実行 – 「ドライ実行」をクリックすると、取り込みを確定せずに、まだ読み込みが保留中のアセットの詳細を表示できます。 これにより、管理者はインポートが完了する前に、インポートの範囲を検証できます。
実行後のジョブの管理 manage-jobs-after-execution
Experience Managerを使用すると、一括読み込みジョブの履歴を表示できます。 ジョブ履歴は、ジョブ、ジョブ作成者、ログのステータスと、開始日時、作成日時、完了日時などのその他の詳細で構成されます。 この履歴により、監査証跡が完全に表示され、管理者は各一括読み込み操作を追跡、トラブルシューティング、検証できます。
一括読み込み設定のジョブ履歴の表示 viewing-job-history
ジョブ履歴 ビューでは、特定の一括読み込み設定の実行レコードを確認し、過去の読み込み実行とその結果を可視化できます。 設定のジョブ履歴にアクセスするには：
- 履歴を確認する設定を選択します。
- 「ジョブ履歴」をクリックします。
- リストから特定のジョブを選択します。
- 「開く」をクリックすると、そのジョブの詳細が表示されます。
Adobe Experience Managerにはジョブ履歴が表示され、記録された各一括読み込みジョブのステータスと結果を確認できます。 この履歴を確認すると、インポートが正常に完了したことを確認したり、期待どおりに完了しなかったジョブをトラブルシューティングしたりするのに役立ちます。
一括読み込みジョブ履歴ページで、削除をクリックして、特定の一括読み込みジョブを設定から削除することもできます。 ジョブを削除すると、一括読み込み設定のジョブ履歴からそのレコードが削除され、履歴リストをクリーンに保ち、関連する実行に集中させることができます。
デスクトップクライアントを使用したアセットのアップロード upload-assets-desktop-clients
Adobe Experience Managerは、web ブラウザーのユーザーインターフェイス （UI）に加えて、アセットのアップロード用に Adobe Asset Link と Experience Managerデスクトップアプリ の2つのデスクトップクライアントをサポートしています。 どちらのデスクトップクライアントも、web ブラウザーを開かずにアセットを直接アップロードできます。
- Adobe Asset Linkは、Adobe InDesign、Adobe Photoshop、Adobe Illustrator デスクトップアプリケーション内からExperience Manager個のアセットに直接アクセスできます。 現在開いているドキュメントをAdobe Asset Link インターフェイスから直接Experience Managerにアップロードします。Photoshop、Illustrator、またはInDesignから移動する必要はありません。
- Experience Manager デスクトップアプリ は、各アセットを処理するファイルの種類やネイティブアプリケーションに関係なく、デスクトップ上のアセット管理を合理化します。 デスクトップアプリは、ローカルファイルシステムから ネストされたフォルダー階層 にファイルをアップロードする場合に優先クライアントです。ブラウザーのアップロードではフラットファイルリストのみがサポートされます。 その結果、フォルダー構造を保持する場合、Experience Manager デスクトップアプリは1回の操作で階層全体をアップロードしますが、ブラウザーでは最初にファイルを統合する必要があります。
アップロード時にアセットを処理 process-when-uploaded
アップロードフォルダーに 処理プロファイル を適用して、アップロードされたアセットに対して追加の処理を実行します。 これらのプロファイルは、Assetsのフォルダーのプロパティ ページで利用でき、各アセットがフォルダーに追加された後にどのように変換されるかを管理します。
拡張機能のないデジタルアセット、または誤った拡張機能を持つデジタルアセットは、必要に応じて処理されません。 その結果、そのようなアセットをアップロードする際には、システムは正しいプロファイルを選択するためにファイル拡張子に依存しているため、何も起こらない、または誤った処理プロファイルが適用される可能性があります。 ユーザーは、正しいプロファイルが自動的に実行されない場合でも、バイナリファイルをデジタルアセット管理（DAM）リポジトリに保存できます。
次のタブがあります。
- メタデータプロファイル は、そのフォルダーにアップロードされたアセットにデフォルトの メタデータプロパティ を適用し、フォルダー全体で一貫性のある検索可能なメタデータを確保します。
- 処理プロファイル は、各ソースアセットから生成された派生バージョンのセットを拡張して、デフォルトで可能な以上の レンディション を生成します。
また、Dynamic Mediaがデプロイメントで有効になっている場合は、次の追加タブを使用できます。
- Dynamic Media画像プロファイル は、特定の切り抜き（スマート切り抜きとピクセル切り抜き）とシャープ化設定をアップロードされたアセットに適用します。
- Dynamic Media ビデオプロファイル は、解像度、形式、パラメーターなど、特定のビデオエンコーディングプロファイルを適用します。
処理プロファイルが割り当てられているフォルダーの場合、プロファイル名がカード表示のサムネールに表示されます。 リスト表示では、プロファイル名が「処理プロファイル」に表示されます。
API を使用したアセットのアップロードまたは取り込み upload-using-apis
開発者向けリファレンスのasset upload セクションには、アップロード APIとプロトコルの完全な技術的な詳細と、オープンソースのSoftware Development Kit （SDK）およびサンプル クライアントへのリンクが記載されています。 これらのAPI （アプリケーションプログラミングインターフェイス）を利用すれば、開発者はアセットをプログラムでアップロードまたは取り込むことができ、手作業によるアップロードではなく、自動化された反復可能なワークフローを構築できます。 オープンソースのSDKとサンプルクライアントは、アップロードプロトコルが実際にどのように機能するかを示す、すぐに使用できるリファレンス実装を提供することで、統合を高速化します。
アセットアップロードのセキュリティとベストプラクティス asset-upload-security-and-best-practices
アセットアップロードセキュリティは、ユーザーやシステムが送信したファイルの検証、スキャン、保存、提供の方法を管理し、アプリケーションを悪意のあるコンテンツ、データ破損、ストレージや帯域幅の不正使用から保護します。 アップロードパイプラインの保護は広く不可欠と見なされています。なぜなら、無制限または不十分に検証されたアップロードは、マルウェアの注入、不正コードの実行、サーバーリソースの枯渇の最も一般的なベクターの1つだからです。
コアアップロードセキュリティ制御 core-upload-security-controls
効果的なアセットアップロードのセキュリティは、アップロードライフサイクルの各段階で適用される階層化された制御に依存します。 主要なコントロールは次のとおりです。
- ファイルタイプの検証 – 各アップロードを、形式ではなく許可された明示的なフォーマット許可リストに加えるに照らし合わせて検証します。これは、許可リストに加えるブロックリストをバイパスし、偽装された実行可能コンテンツが滑り落ちるのを防ぐことが非常に難しいためです。
- ファイルサイズの制限 – 最大サイズのしきい値を適用して、ディスク容量やメモリを使い果たす可能性のあるサイズの大きすぎるアップロードによるサービス拒否の状態を防ぎます。
- コンテンツ検査 – 攻撃者が日常的に拡張機能を偽装して有害なファイルを偽装するため、ファイル拡張子やクライアントが提供するMIME （多目的インターネットメール拡張機能）タイプを信頼するのではなく、実際のファイル署名（マジックバイト）を検査します。
- マルウェア スキャン — アップロードされたアセットは、ウイルス対策スキャンまたはマルウェア スキャンで実行してから利用できるようにし、感染ファイルが他のユーザーに配布されるのではなく隔離されるようにします。
- ファイル名のサニタイズ — パスのトラバーサルとディレクトリエスケープ攻撃を防ぐために、特殊文字、パス区切り記号、およびコントロールシーケンスをファイル名から取り除くか正規化します。
ベストプラクティス recommended-best-practices
アップロードワークフローを強化するには、次のベストプラクティスを順番に適用します。
- サーバーで検証 – クライアントサイドの検証はすべてアドバイザリーとしてのみ扱い、クライアントサイドの制御は悪意のあるアクターによって回避できるため、サーバーサイドのすべてのチェックを適用します。
- Web ルート以外のアセットを保存 — アップロードされたファイルを、Web サーバーが直接実行できない場所に保存します。これにより、攻撃者はアップロードされたスクリプトをコードとして実行できなくなります。
- アップロードされたファイルの名前を変更 – 既存のアセットの上書きを避け、保存されたコンテンツの列挙を防ぐために、サーバー生成の予測不可能な識別子を保存されたファイルに割り当てます。
- 権限の制限 — アップロードされたファイルに必要な最小の読み取り権限と書き込み権限を付与し、それらを実行可能ファイルとしてマークしないでください。これにより、侵害されたファイルを実行できません。
- アップロードの認証と承認 – 要求するユーザーにアップロードの権限があることを確認します。これにより、匿名の不正使用や不正な送信が発生する可能性を制限できます。
- レート制限とスロットル — ユーザーまたはセッションごとにアップロード率の制限を適用して、自動悪用やリソースの疲労のリスクを低減します。
アップロード後の処理とストレージ handling-and-storage-after-upload
ファイルが承認された後も、セキュリティの責任は継続されます。 保管および配信中にアセットを保護するには：
- 暗号化された接続を介してアセットを提供 — アップロードされたコンテンツをHTTPS （Hypertext Transfer Protocol Secure）経由で配信し、ファイルを傍受したり、転送中に改ざんしたりできないようにします。
- ユーザー生成コンテンツを分離 – このコンテンツを分離すると、クロスサイトスクリプティングとCookie盗難攻撃の影響が制限されるため、別のドメインまたは専用の コンテンツ配信ネットワーク（CDN） から信頼できないアップロードを提供します。
- 正しい応答ヘッダーを設定 – 正確な
Content-Typeヘッダーを返し、必要に応じてダウンロードを強制します。これにより、ブラウザーが保存ファイルを誤って解釈して実行しないようにします。 - アップロードのログと監査 — アップロード メタデータとアクセス イベントを記録します。これにより、インシデント調査がサポートされ、不正パターンを早期に検出できます。
これらの制御とベストプラクティスに従うことで、アセットのアップロードに対する防御の詳細なアプローチが確立され、1回のチェック漏れが完全な侵害につながるリスクを軽減できます。
事前に署名されたURLを使用した直接バイナリアップロード direct-binary-upload
Adobe Experience Manager （AEM） as a Cloud ServiceがDirect Binary Upload フローを通じてアセットをアップロードし、3段階のシーケンスを実行します：（1） クライアントが 事前署名されたURL をリクエストし、（2）そのURLを使用してバイナリがストレージに直接アップロードされ、（3）認証されたAPI呼び出しでアセットが最終処理されます。 この設計により、アセット登録を認証済みの制御下に保ちながら、大規模なバイナリ転送をストレージに直接オフロードできます。
URLの有効期間と再利用 url-lifetime-and-reuse
- 事前に署名されたURLは短期間有効で、約1時間有効です。 ただし、正確な Time to Live （TTL） は、公開または保証されたService level agreement （SLA）ではありません。 期間は変更できる実装詳細として扱い、値を統合にハードコーディングしないでください。
- 事前に署名されたURLは、1回のアップロードセッションの一部として即座に使用する必要があります。 後で保存して再利用するように設計されておらず、複数のアップロードで再利用できるように設計されていません。 各アップロードセッションは、独自のURLを取得します。
事前署名済みURLのセキュリティ security-of-presigned-urls
- 事前に署名されたURLのみを漏洩すると、アセットを作成するには不十分です。アセットの作成と最終処理は、有効な資格情報と
uploadTokenを使用する別の認証済みAPI呼び出しに依存するからです。 アクターが事前署名されたURLのみを取得した場合、そのアクターは有効な認証と関連するアップロードトークンなしではアセット登録を完了できません。 - この認証要件は、漏洩したURLの実際の影響を制限します。必要な資格情報と
uploadTokenは2番目の制御として機能するため、URLの露出だけでは不正なアセットの登録を許可しません。 - 独自の統合では、事前署名済みURLを機密値として扱います。 ログ作成を避け、常に HTTPS を使用し、アップロードセッションを超えて永続化しないでください。
プログラマティックアップロードの認証 authentication-for-programmatic-uploads
Adobe Experience Manager （AEM）へのプログラマティック アセットのアップロードをサポートしているのは、サービス資格情報（JWT）のみです。 AEM API アクセス用に2つの認証メカニズムが存在し、アセットのアップロード操作に対しては互換性がありません。 間違った資格情報タイプを選択することは、アップロード統合が失敗する最も一般的な原因です。
APIのアップロードに使用するテクニカルアカウントには、明示的なリポジトリーレベル アクセス制御リスト （ACL）がパスレベルで付与されている必要があります。 次の2つのACL権限が必要です。
/content/damのjcr:read— デジタルアセット管理（DAM）コンテンツルートへの読み取りアクセス権を付与します。- 特定のターゲットサブフォルダーの
rep:write（またはjcr:all） – アセットがアップロードされる宛先パスへの書き込みアクセス権を付与します。
これらのパスレベルのACLは、正しい資格情報タイプと正しい管理者コンソール製品プロファイルまたはグループメンバーシップ に加えて必要です。
テクニカルアカウントは正しくライセンスされ、グループ化しても、403 Forbidden個のエラーが表示されます。 これは、製品プロファイルまたはグループの割り当ておよびリポジトリ ACLが独立したコントロールであり、どちらも必須であるため発生します。 その結果、パスレベルのACLが付与されていない場合、資格情報の種類と製品プロファイルが正しく設定されていても、アカウントはアクセスを拒否されます。
マルウェアの検出と隔離 malware-detection-and-quarantine
Adobe Experience Manager（AEM）の マルウェア検出 は、アップロードされたすべてのファイルをスキャンし、感染したファイルを専用の強制隔離 エリアに移動し、疑わしいアセットをリポジトリの残りの部分から分離します。 マルウェア検出が有効になっている場合、システムは到達時に各アップロードをスキャンし、感染を検出すると、ファイルを自動的に隔離します。 これにより、アクティブなワークフローから脅威を分離し、感染したアセットが公開、ダウンロード、他のユーザーに配布されるのを防ぎます。
強制隔離されたアセットへのアクセスは、専用の強制隔離の管理者 グループを通じて適用される 標準Adobe Experience Manager （AEM）権限 によって管理されます。 強制隔離の可視化は単一の固定された役割に関連付けられていないので、アクセスは柔軟に拡張できます。
- 強制隔離された管理者 グループメンバーは、デフォルトで強制隔離されたアセットへのアクセス権を保持します。
- 運用要件またはセキュリティ要件により、より広範な監視が必要な場合、追加のカスタムグループに強制隔離エリアへのアクセスを許可できます。
- したがって、複数のグループは、機能を1つの役割に制限するのではなく、強制隔離の可視性を同時に保持できます。
この権限モデルは、許可されたユーザーのみが隔離されたコンテンツを検査、リリース、削除でき、有害な可能性のあるファイルの管理されたレビュープロセスを維持します。
マルウェアの検出と強制隔離について詳しくは、 マルウェアの検出を参照してください。
ファイルタイプの処理とアップロードの制限 file-type-handling-and-upload-restrictions
- Adobe Experience Manager （AEM）では、アップロードにデフォルトのファイルタイプ制限は適用されません。 実行可能な拡張機能 （例：.exeまたは.exe.pdf）を含むファイルをアセットレンディションとしてアップロードできます。
- これは期待される動作であり、脆弱性ではありません。 AEMは、アップロードされた アクティブコンテンツまたはスクリプト をブラウザーまたはサーバー上でレンダリングまたは実行しません。 アップロードされたファイルは保存され、コードとして実行されるのではなく、不活性アセットレンディションとしてのみ機能するため、実行ファイルをアップロードしても、AEMのデフォルトのセキュリティモデルで remote-code-execution （RCE） のリスクが生じることはありません。 コンプライアンス要件が厳しい企業は、AEMがこのポリシーをネイティブに適用せず、その管理はデプロイ企業に任せるので、必要に応じて独自のアップロード検証または 許可リスト を適用する必要があります。
- アセット処理でサポートされるファイル形式とMIME （多目的インターネットメール拡張機能）タイプについては、別に説明します。 サポートされていないタイプは完全に処理されないため、サポートされていないファイルが期待されるレンディションを生成しない可能性があります。
信頼性のベストプラクティスのアップロード upload-reliability-best-practices
アップロード前にアセットを最適化 optimize-assets-before-upload
- video、PDF、GIFなどの大規模または特殊なアセットタイプの場合は、推奨されるファイルサイズの制限、エンコード設定、および推奨される形式に従います。 これらの仕様に準拠することで、オーバーサイズまたは非標準のファイルはトランスコードやサムネール生成のステップに最も大きな負荷がかかるため、アップロード、処理、プレビューの生成時にプラットフォームのパフォーマンスに影響を与えるのを防ぐことができます。
ビジネスに不可欠なファイルにサポートされているアップロードパスを使用 use-supported-upload-paths
- アドホックフォルダーレベルの一括アップロードではなく、ビジネスに不可欠なファイルに対して、サポートされているアップロード APIまたはUI フローを使用します。 サポートされているパスには、一貫した検証、エンコード、エラー処理が適用されるため、破損や損失に耐えられないファイルに対して、より信頼性の高い選択肢になります。
- フォルダーレベルのドラッグ&ドロップによるアップロードでは、報告されたケースごとに ファイルが破損 することがあります。 そのため、重要なアセットには推奨されません。
フォルダーレベルのアップロードが失敗した場合、またはファイルが破損した場合 folder-level-upload-fails
根本的な原因が環境固有またはファイル固有であることが多く、証拠が失われると、その事実の後に診断が困難になるため、すぐに証拠を収集します。
- エラーメッセージまたは観察された動作が発生するとすぐに正確に記録します。
- エラー状態とエラーダイアログの スクリーンショット を撮影します。
- HTTP アーカイブ （HAR） ファイルまたは ネットワークログ をブラウザーセッションから保存します。これらは、障害をトレースするために必要なリクエスト/応答の詳細をキャプチャするためです。
- 影響を受けるファイルを保存して、サポートされているアップロードパスに対して再テストできるようにします。
そうした証拠を即座に収集することで、サポート部門やエンジニアリング部門は、問題を再現して解決するために必要な環境やファイルに関する詳細情報を入手できますが、実際にログや元のエラーを残さずに破損を診断することは、多くの場合、現実的ではありません。
アップロードエラーのチェックリストのトラブルシューティング troubleshooting-checklist-for-upload-failures
-
403 Forbidden on API （Application Programming Interface） upload：最初に資格情報の種類を確認してください。 Adobe Developer ConsoleのOAuth S2S （サーバー間）資格情報は、アセットアップロード APIでサポートされていません。 代わりに、Adobe Experience Manager （AEM）開発者コンソールから発行された サービス資格情報（JSON Web トークン、またはJWT） を使用します。 2つの資格情報タイプは、異なるコンソールを通じてプロビジョニングされ、異なるスコープを付与します。そのため、アカウントが有効であると表示される場合でも、一方を他方に置き換えると 403 Forbidden が生成されます。
-
403は、正しい資格情報およびグループメンバーシップにもかかわらず禁止されています：テクニカルアカウントが特定のターゲットフォルダーの
/content/damおよびrep:write/jcr:allにjcr:readを明示的に保持していることを確認してください。 AEMは、アセットの書き込みをロールのみではなくリポジトリノードレベルで許可するため、グループまたはプロファイルメンバーシップは、フォルダーレベルのアクセス制御リスト（ACL）に代わるものではありません。 その結果、アカウントは正しいグループに属することができますが、ノードレベルのACLが正確な宛先フォルダーに設定されるまで、引き続き拒否されます。 -
アップロードは成功しましたが、アセットが表示されないか、バイナリが破損しているように見えます：取り込み方法としてフォルダーレベルのバルクアップロードを除外します。 標準のアップロード APIまたはユーザーインターフェイス（UI）で再試行し、問題が再発した場合はログをキャプチャします。 一括取り込みパスは、標準APIとは異なるバイナリを扱うため、取り込みメソッドを分離することで、破損がアップロードパス自体から発生しているかどうかを判断する最も高速な方法です。
-
セキュリティレビューフラグが制限のないファイルのアップロードを示します: AEMでは、アップロードされたアクティブなコンテンツがサーバーサイドまたはブラウザー内でデフォルトで実行されないことを明確にします。 コンテンツは実行されないため、無制限のファイルのアップロードは、欠陥ではなくプラットフォームの動作として期待されます。コンテンツを実行できない場合、アクティブコンテンツが保存される主なリスクは中和されます。 組織が追加のアップロード時間検証を必要とする場合を除き、この検証は保持されます。この場合、その検証はデフォルトの動作の上にポリシーコントロールとして追加する必要があります。
-
事前に署名されたURLの公開に関する懸念：事前に署名されたURLは、バイナリをストレージに直接転送するために使用される、時間制限のある事前承認済みのリンクです。 URLが短い有効期間内に使用されたこと、およびアセットの最終処理に有効な
uploadTokenを含む別の認証済み呼び出しが引き続き必要であることを確認します。 この2段階のデザインでは、URLを所有するだけでは、有効で個別に認証されたuploadTokenを使用せずにアセットを確定できないため、漏洩した事前署名済みURL （Uniform Resource Locator）の公開範囲が制限されます。 したがって、有効なウィンドウが閉じた後にリークするURLには、実用的な書き込み機能はありません。
ヒント、ベストプラクティス、制限事項 tips-limitations
-
直接バイナリアップロードは、アセットをアップロードする新しい方法です。 Experience Manager ユーザーインターフェイス、Adobe Asset LinkおよびExperience Manager デスクトップアプリなどの製品機能とクライアントで、デフォルトでサポートされています。 顧客の技術チームによってカスタマイズまたは拡張されたカスタムコードは、新しいアップロードアプリケーションプログラミングインターフェイス（API）とプロトコルを使用する必要があります。
-
大きなフォルダー処理： Experience Manager Assetsは、1,000個を超える直接子 （アセットまたはサブフォルダー）を含むフォルダーをサポートしています。 フォルダーがこの 1000項目のしきい値 を超えると、管理者UIは非同期更新インデックスに切り替えてフォルダーの内容を一覧表示します。 このインデックスは非同期で更新されるので、新しく作成されたフォルダーとアセットは短い遅延（通常は数秒）後に表示されます。 このようなフォルダーを管理ビューで開くと、バナーはこの動作をエンドユーザーに通知し、次のように表示します。「このディレクトリには1000以上の項目が含まれています。 アップロードや新しいフォルダーの作成が遅れる場合があります。」
-
置換とアセット IDの再生成： 名前の競合 ダイアログで 置換 を選択すると、新しいアセットのアセット IDが再生成されます。 このIDは、前のアセットのIDとは異なります。 Assets インサイト でAdobe Analyticsのインプレッション数またはクリック数を追跡することが有効になっている場合、Analyticsがインプレッション数とクリック数を元のアセット IDに対して追跡し、新しいIDを以前のレコードと照合できないため、再生成されたアセット IDはAnalyticsにアセットに対して取得されたデータを無効にします。
-
ファイル名に 禁止された文字： 一部のアップロード方法では、ファイル名に禁止された文字を含むアセットをアップロードできない場合があります。 これらの場合、禁止されている文字は
-記号に置き換えられます。 -
ブラウザーのアップロード制限： ブラウザーを使用したアセットのアップロードでは、フラットファイルリストのみがサポートされ、ネストされたフォルダー階層はサポートされません。 ネストされたフォルダー内のすべてのアセットをアップロードするには、 デスクトップアプリ を使用します。このアプリは、転送時にフォルダー構造を保持します。
-
一括読み込みフォルダー構造：一括読み込みメソッドは、データソースに存在するフォルダー構造全体を読み込みます。 ただし、Experience Managerには空でないフォルダーのみが作成されます。つまり、ソース上の空のフォルダーは読み込まれた階層から除外されます。
関連情報