media-asset-management

メディアアセット管理

画像、動画、ダウンロード可能なファイルの保存、処理、整理、配信方法を設計します。特定の技術スタックに依存しません。カスタムパイプラインを運用する場合でも、ホステッドサービスを利用する場合でも、これらの原則を適用できます。

---

使用する場面

• 画像・メディアパイプラインを設計または再設計するとき
• メディア CDN や画像サービスを選ぶとき
• レスポンシブ画像の配信を設定するとき
• デジタルアセット管理（DAM）システムを計画するとき
• メディアのパフォーマンス問題を監査するとき
• 動画のホスティングや埋め込み方法を選ぶとき
• デザイナーやライターがアセットをアップロードするワークフローを設定するとき
• メディアを別のプラットフォームに移行するとき

使用しない場面

• メディア以外のパフォーマンス最適化（performance-optimization を使用）
• ブランドアイデンティティや写真の方向性（brand-identity、art-direction を使用）
• コンテンツ制作戦略（content-strategy を使用）
• 単一画像の最適化（performance-optimization で対応）

---

必要な入力

• 現在のメディアインベントリ：アセットの保存場所と形式
• 規模：アセット数、ストレージ容量、トラフィック量
• ソース：メディアを作成・アップロードする人（デザイナー、ライター、自動化ツール）
• プラットフォーム：メディアの利用先（Web、メール、アプリ、パートナー）
• パフォーマンスのベースライン：現在の画像サイズ、読み込み時間
• 予算の実情：ホステッドサービスには月額費用がかかります

---

フレームワーク：4 つのステージ

メディアパイプラインは 4 つのステージで構成されます。それぞれに固有の判断事項があります。

ステージ 1：ソース

アセットがシステムに取り込まれる場所です。

ソース：

• デザイナー（Figma の書き出し、Photoshop、Illustrator）
• 写真家（カメラの RAW または JPEG）
• ストックフォトライブラリ
• AI 生成画像
• ユーザー生成コンテンツ（アップロード）
• 自動化システム（例：スクリーンショット、生成されたサムネイル）

ソース段階で決めること：

• 受け入れるファイル形式（RAW、TIFF、PSD、AI と配信用形式）
• 命名規則
• 必須メタデータ（代替テキスト、キャプション、クレジット、権利情報）
• ソースの最大解像度（あらゆるサイズを生成できる十分な高さを確保しつつ、無駄に大きくしない）
• ソースファイルの保存場所（配信用アセットとは分ける）

アンチパターン： ソースと配信用アセットを同じ場所に保存することです。マスターファイルが見つけにくくなり、再生成も難しく、使用状況の監査も困難になります。

ステージ 2：処理

ソースファイルを配信用形式に変換します。

処理に関する判断事項：

• 標準サイズにリサイズする（例：320、640、960、1280、1920、2560 など、幅を固定セットにする）
• 圧縮する（非可逆または可逆。品質目標を設定）
• 形式を変換する（ラスター画像には JPEG、WebP、AVIF、ベクター画像には SVG）
• サムネイルとプレビューを生成する
• 意図的に保持する場合を除き、メタデータ（EXIF、GPS）を削除する
• カラープロファイルを管理する（Web 用には sRGB）

処理方法：

• ビルド時： デプロイ中に静的アセットを処理します。挙動を予測しやすく、実行時は高速ですが、柔軟な調整は困難です。
• オンデマンド： リクエストに応じてサービスが適切な形式・サイズを生成します。柔軟ですが、処理レイヤーが必要です。
• ハイブリッド： 静的な処理済みサイズを用意し、特殊なケースにはオンデマンドで対応します。

画像のバリエーションが多く、継続的に変更されるサイトではオンデマンドが適しています。厳密に管理されたマーケティングサイトでは、ビルド時の処理のほうがシンプルな場合があります。

ステージ 3：配信

アセットを効率よくユーザーに届けます。

配信に関する判断事項：

• CDN：ある程度の量を扱う場合は必須です。エッジキャッシュとグローバル配信を利用できます。
• 形式のネゴシエーション：対応ブラウザーには AVIF、それ以外には WebP、フォールバックとして JPEG を配信します。<picture> 要素またはコンテンツネゴシエーションを使用します。
• レスポンシブ画像：srcset 属性と sizes 属性を指定し、ブラウザーがビューポートに合ったサイズを選べるようにします。
• 遅延読み込み：ファーストビューより下の画像には loading="lazy" を指定します。
• 非同期デコード：重要でない画像には decoding="async" を指定します。
• 幅と高さの属性：必ず設定します。レイアウトシフトを防げます。

最新の HTML パターン：

<img 
  src="/image-1280.jpg" 
  srcset="/image-640.jpg 640w, /image-960.jpg 960w, /image-1280.jpg 1280w, /image-1920.jpg 1920w" 
  sizes="(max-width: 768px) 100vw, 50vw"
  width="1280"
  height="720"
  loading="lazy"
  decoding="async"
  alt="Descriptive alt text">

または、形式のネゴシエーションには次を使用します。

<picture>
  <source type="image/avif" srcset="/image.avif">
  <source type="image/webp" srcset="/image.webp">
  <img src="/image.jpg" alt="Descriptive alt text" width="1280" height="720">
</picture>

ステージ 4：管理

システムを長期にわたって整理し、役立つ状態に保ちます。

管理に関する判断：

• アセットライブラリまたは DAM（デジタルアセット管理）：チームがアセットを見つけるための一元化された場所
• タグ付けと検索
• バージョン管理（デザイナーがアセットを更新しても、古いバージョンが引き続き使われている場合など）
• 権利とライセンスの追跡
• 監査と整理（もう使われていないものは何か）
• 権限（誰がアップロード、編集、削除できるか）

規模が小さい場合は、シンプルな共有フォルダーで十分です。アセットが数千点を超える場合や複数のチームが使う場合は、本格的な DAM が必要です。

---

フォーマットのリファレンス

一般的なウェブ用途の場合：

フォーマット	用途	避ける用途
AVIF	写真、複雑な画像。最も圧縮率に優れています。	ブラウザーのサポートに関する例外的なケース（2026 年現在ではまれで、今では広く普及しています）
WebP	写真、イラスト。圧縮率が高く、幅広くサポートされています。	印刷、アーカイブ
JPEG	写真（フォールバック）。あらゆる環境でサポートされています。	輪郭がはっきりしたグラフィック、透明な背景
PNG	輪郭がはっきりしたグラフィック、透明な背景、スクリーンショット。可逆圧縮です。	写真（ファイルサイズが大きくなります）
SVG	ロゴ、アイコン、シンプルなイラスト。拡大縮小できます。	写真、複雑なアート
GIF	実質的に廃れています。アニメーションには動画フォーマットを使ってください。	現代的な用途全般
MP4 (H.264)	動画、あらゆる環境でサポートされています。	静的コンテンツ
WebM (VP9 / AV1)	動画、より高い圧縮率。	古いブラウザー

ほとんどのサイトでは、モダンブラウザー向けに AVIF/WebP を配信し、フォールバックとして JPEG/PNG を使います。ベクターには SVG、動画には MP4 を使います。

---

ワークフロー

ステップ 1：棚卸し

どのアセットが、どこに、どのような状態で存在しているでしょうか？

• 画像の数と合計ストレージ容量
• フォーマットごとの平均サイズ（KB）
• 画像関連のパフォーマンス指標
• 画像が壊れている、または見つからないページの数
• ソースファイルと配信用ファイル

ステップ 2：パフォーマンスを監査する

ページをいくつか選んで確認します。

• ページあたりの画像容量（目標：マーケティングページ全体で 500KB 未満）
• 画像リクエストの数
• レスポンシブ画像が使われているか
• モダンフォーマットが配信されているか
• 寸法が未指定の画像によるレイアウトシフトが発生しているか

ツール：Lighthouse、WebPageTest、利用している CDN のアナリティクス。

ステップ 3：パイプラインを選ぶ

妥当なパターンは 3 つあります。

パターン A：静的、ビルド時

• リポジトリまたはストレージバケットにアセットを保存
• ビルドプロセスでサイズとフォーマットを生成
• CDN 経由で配信
• 適しているケース：静的サイト、アセットの変更が少ない場合、パフォーマンスを厳密に管理したい場合

パターン B：オンデマンドの画像 CDN

• ソースをバケットまたはサービスにアップロード
• 画像 CDN（Cloudinary、imgix、Cloudflare Images、Bunny など）が URL パラメーターを使ってオンデマンドで処理
• 適しているケース：中規模から大規模のサイト、アセットが頻繁に変更される場合、複数のバリエーションが必要な場合

パターン C：画像 API を内蔵したヘッドレス CMS

• CMS にソースアセットを保存
• CMS がリサイズやフォーマット変換のための画像 API を提供
• 適しているケース：コンテンツが多いサイト、技術に詳しくないコンテンツ投稿者がいる場合、CMS がすでに選定されている場合

これらのパターンは相互に排他的ではありません。大規模なサイトでは、デザインアセットにパターン A、コンテンツ画像にパターン B を使うことがよくあります。

ステップ 4：標準を定める

以下を文書化します。

• 命名規則
• 必須のメタデータ（代替テキスト、クレジット表記）
• ソースの最大寸法
• 用途ごとのソースの最小寸法
• 承認済みフォーマット
• ファイルサイズの目標値

可能な場合は、ツールを使ってこれらを強制できるようにします（ファイルサイズに関する CI チェック、CMS での代替テキストの必須化など）。

ステップ 5：ワークフローを設定する

ソースの種類ごとに設定します。

ソース	ワークフロー
デザイナー	Figma からエクスポートしてバケットに入れ、あとは自動処理に任せます
ライター	CMS からアップロードし、CMS のプロンプトに従って代替テキストを入力します
写真家	RAW をソースバケットに入れ、デザイナーまたは自動処理でウェブ用のバリエーションを作成します
ユーザーによるアップロード	画像サービスを通し、該当する場合は自動モデレーションを行います

誰が何をするかを文書化します。文書化されていないワークフローは破綻します。

Step 6: アセットライブラリを構築する

最小規模のサイトを除くすべてのサイトでは、次の対応を行います。

• DAM を一元化するか、共有ライブラリを用意する
• タグの分類体系を作成する（テーマ、スタイル、ブランド、キャンペーンなど）
• タグとメタデータを横断して検索できるようにする
• 各アセットの権利を文書化する（ストック素材のライセンス、カスタム制作の依頼、職務著作など）
• 利用終了のワークフローを設ける（権利の期限切れ、アセットの廃止）

Step 7: 監視と監査を行う

• 画像の多いページのパフォーマンス指標
• ストレージコスト
• CDN コスト
• 画像の破損アラート（参照先メディアの 404）
• 未使用アセットのクリーンアップ（ストレージコストは蓄積します）

Step 8: パイプラインを文書化する

パイプラインの文書には、次の内容を含めます。

• ソース → 処理 → 配信 → 管理の図
• 各段階で使用するツール
• 標準と命名規則
• 一般的なケースのワークフロー
• 問題発生時のエスカレーション手順

---

よくある失敗パターン

配信用バケットにソースファイルを置く。 50MB の RAW ファイルがユーザーに配信されます。対策：ソースと配信用ファイルを分けます。

すべてのブラウザーで単一の画像形式を使う。 AVIF なら 30～50％小さくできるのに JPEG のみを使っています。形式ネゴシエーションを使います。

幅と高さの属性がない。 レイアウトシフトが発生し、CLS 指標に悪影響を及ぼします。常に設定します。

ヒーロー画像を遅延読み込みする。 ファーストビューの画像は遅延読み込みにしないでください。ファーストビューより下の画像を遅延読み込みします。

すべてを先行読み込みする。 ページ読み込み時にすべての画像が読み込まれます。ファーストビューより下の画像には loading="lazy" を使います。

レスポンシブ画像がない。 モバイルにもデスクトップ用の画像が配信されます。非効率で、読み込みも遅くなります。srcset と sizes を使います。

ソースの解像度が 1 種類だけ。 ソースが配信時の解像度になっています。Retina 用や、それより大きなサイズを生成できません。ソースは、配信する最大サイズの 2～3 倍にします。

メタデータをすべて削除する。 代替テキストやクレジット情報も削除されます。GPS 情報と個人情報を含む EXIF は削除し、意味的なメタデータは残します。

ランダムな名前を付ける。 IMG_4823.jpg、Screenshot 2024-03-15.png のような名前では、後から見つけるのが困難です。命名規則を使います。

代替テキストがない。 アクセシビリティと SEO の要件を満たせません。アップロード時に代替テキストを必須にします。

ストレージが無制限に増える。 古くて使われていないアセットがたまります。四半期ごとにクリーンアップするか、自動ライフサイクルポリシーを設定します。

パイプラインを把握しているのが 1 人だけ。 その人が不在だと、問題を修正したり、新しいソースをオンボーディングしたりできる人がいません。文書化します。

---

出力形式

メディアパイプラインの文書には、次の内容を含めます。

• インベントリ： 現在のアセット数、形式、ストレージ。または、データ利用可否ルールに従って不足情報を明示する
• パイプライン図： ソース → 処理 → 配信 → 管理と、各段階で使用するツール
• 形式とサイズの標準： 何を、いつ生成するか
• 命名とメタデータの規則： 例を含める
• ソースの種類ごとのワークフロー： デザイナー、ライター、写真家、ユーザー
• パフォーマンスのベースラインと目標： ページあたりの容量、形式の採用率など
• アセットライブラリ： ツール、分類体系、検索、権利の追跡
• 監視： パフォーマンス、コスト、アセットの破損
• ロードマップ： 今後 1～2 四半期の改善

---

必要なデータが利用できない場合

このスキルの出力は、自力では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合に認められる出力は、不足情報を明示した成果物です。つまり、何が必要だったか、実際に何を取得または検証できたか、出力のどの部分に影響するかを明記します。成果物を完成させるために、必要な数値を捏造、推定、または補間することは認められません。不足情報を明示すれば、それで回答として完結します。

---

参考ファイル

• references/responsive-image-patterns.md：一般的なレスポンシブ画像の使用例（ヒーロー、コンテンツ、アートディレクション、形式ネゴシエーション）に対応する、コピーして使える HTML パターンと説明。