高度な設定

Source Details ページでは、現在のソースのステータスおよび追加で設定可能な項目を確認できます。Status フィールドは、ソース作成後数秒以内に「Queued」から「Deployed」に変更されます。これが完了すると、ソースは使用可能になります。

このページの設定を変更する場合は、Edit ボタンをクリックし、変更したい項目を編集してから Review and Deploy をクリックしてソース構成を更新してください。ほとんどの項目は直感的に理解できますが、(?) アイコンにカーソルを合わせると詳細が表示されます。

ソースタイプの変更

すでに作成済みのソースは、いつでも別のソースタイプへ変更できます。ドメイン、デフォルトパラメータ、デフォルト画像、キャッシュ TTL 設定などの構成はそのまま維持されますが、新しいソースタイプに応じて Imgix とオリジンアセットの接続方法を再設定する必要があります。

1. Source Details ページで Edit をクリックします。
2. Source Type の横にあるドロップダウンメニューを開きます。
3. 切り替えたいソースタイプを選択します。
4. 必要な設定（アクセスキー、ベース URL など）を確認し、新しいタイプで正常に再デプロイできるよう構成します。
5. 設定が完了したら Review & Deploy ボタンをクリックし、新しいソースタイプでソースを再デプロイします。

ドメイン

Imgix サブドメイン

Imgix で使用するサブドメインを指定します。サブドメインは .imgix.net の前に付く URL の最初の部分で、ソースのベース URL を作成するために使用されます。たとえば、サブドメインを example に設定した場合、ソースのベース URL は https://example.imgix.net になります。

カスタムドメイン

カスタムドメインをソースのベース URL として追加できます。標準サブドメインとカスタムサブドメインの両方が、同じオリジン画像に解決されます。

1. Source Details ページで Edit をクリックします。
2. 「Domains」セクションで Custom Domain をクリックします（モバイルデバイスでは、先に Add Domain をクリックします）。
3. 使用したいカスタムサブドメインを入力し、Review & Deploy ボタンをクリックして新しいカスタムドメインでソースを再デプロイします。
4. DNS レジストラに移動し、CNAME が新しい *.imgix.net ホスト名を指すように DNS 設定を行います（* は Imgix で使用しているソースのサブドメインです）。Google Domains での CNAME レコード設定例は以下を参照してください。
5. DNS の変更が反映されるまで待ちます。DNS プロバイダーによっては、最大 24 時間かかる場合があります。

Imgix が提供する標準ホスト名（例: subdomain.imgix.net）は、すべて自動的に SSL/TLS による保護された通信をサポートします。

Note: カスタムサブドメインは、デフォルトでは HTTP でのみ使用できます。HTTPS を使用するには、CDN パートナー経由の SSL 証明書が必要です。 設定については、アカウントマネージャーにお問い合わせいただくか、サポートにお問い合わせください。詳細については、SSL に関するドキュメントを参照してください。

Asset Manager 処理ルール

Asset Manager のクロールが有効な場合、Asset Manager Asset Rule で、Asset Manager に含める、または除外するフォルダを指定できます。これにより、Asset Manager に表示されるアセットを制御できます。

デフォルトの動作では、ソースのベースパスプレフィックス配下にあるすべてのメディアとサブディレクトリがクロールされます。

アセットのデフォルト

ソースには基本的なエラー対応機能が備わっており、アセットが見つからない場合やエラーが発生した場合に代わりに表示する画像を設定できます。これにより、アセットに問題があっても画面が空白のまま表示されることを防げます。Rendering API で画像を配信する場合、元のリクエストのパラメータをデフォルト画像やエラー画像に適用することもできます。

デフォルト画像またはエラー画像を追加する方法:

1. Source Details ページで Edit をクリックします。
2. 「Image Defaults」で該当するフィールドをクリックし、画像の URL を入力します。
3. 元の画像リクエストのデフォルト値を適用したい場合は、画像フィールド下のチェックボックスをクリックします。
4. Review & Deploy ボタンをクリックし、新しい設定でソースを再デプロイします。

Default Image と Error Image の設定は、それぞれ使用量クォータに異なる影響を与える可能性があります。詳細は以下をご覧ください。

デフォルトアセット

Default Image が設定されている場合、ソースの 404 の挙動が変わります。これが有効な場合、通常は 404 を返すリクエストが、代わりに指定した画像とともに 200 レスポンスを返すようになります。

これは、アセットの存在有無に関わらず、常に 200 レスポンスとデフォルト画像を受け取りたい場合に便利です。

Default Image と Error Image の両方が設定されている場合、リクエストが 404 エラーになる場面では常に Default Image が Error Image を上書きします。

404 の場合にエラーレスポンスの代わりにデフォルト画像が返されるため、404 になるリクエストで帯域幅を大量に消費しないよう、ファイルサイズの小さいデフォルト画像を使用することを推奨します。

エラーアセット

Error Image が有効になっている場合、Imgix は一般的にエラーとなるアセット（4xx、5xx など）について、適切なエラーコードを返しつつ、Error Image で設定した画像を返すようになります。

Default Images とは異なり、この場合エラーレスポンスは保持されます。エラー画像が表示されるトリガーとなったアセットは、404 を含め、クォータの対象にはなりません。

Default Image が有効になっている場合、リクエストが 404 エラーになる場面では常に Error Image の設定を上書きします。このシナリオでは、レスポンスが 200 に変換され、月間の使用量クォータの対象となります。

Note: エラー画像を設定済みで、変更または削除が必要な場合、反映されるまで最大 6 時間かかることがあります。より早く反映させたい場合は、support@imgix.com までご連絡ください。

パラメータのデフォルト

すべての画像に適用したいベースラインの最適化設定がある場合、ソースレベルでデフォルトパラメータを指定できます。

Note: ch は、キャッシュの仕組みとの相性の問題により、デフォルトパラメータとして設定できません。

Note: dpr に 1 以外のデフォルト値（例：dpr=2）を設定した場合、URL 経由で 1（または 0）に戻すことはできません。dpr=1 と dpr=0 は無効な値として扱われ、Imgix のレンダリングサービスに到達する前に破棄されるため、ソースのデフォルト値がそのまま適用されます。1 以外の値（例：dpr=3）のみがデフォルトを上書きします。リクエストごとに dpr を制御したい場合は、ソースレベルで 1 以外のデフォルト値を設定しないようにしてください。

1. Source Details ページで Edit をクリックします。
2. Image Defaults で、ドロップダウンメニューからパラメータを選択し、値を入力します。デフォルトとして設定したいパラメータと値の組み合わせを、必要な数だけ追加できます。
3. Review & Deploy ボタンをクリックし、新しい設定でソースを再デプロイします。

デフォルトパラメータを設定すると、ソース内のすべての画像が Imgix のレンダリングサービスを経由するようになります。これにより、画像をパススルーとして配信するデフォルトの動作が無効になります。ソースで PDF を配信していたり、パラメータを指定せずに元の品質・サイズで画像を配信している場合、デフォルトパラメータを適用するとそれらのアセットのデフォルトの動作に影響します。

デフォルトパラメータの詳細、上書き方法、推奨される使い方については、こちらのブログ記事をご覧ください。

アセットキャッシュ設定

キャッシュ設定は、Imgix によって生成されたアセットおよび派生画像が、エンドユーザーのブラウザキャッシュにどのくらいの期間保持されるかを決定します。オリジン画像が変更される可能性は低いため、TTL（「time-to-live」）の値は少なくとも 1 年に設定することを推奨します。これにより、アセットがオリジン画像から再生成されたり、Imgix システム内の中間キャッシュから配信されたりするのではなく、ユーザーのローカルキャッシュから配信される可能性が高くなり、ページの読み込みが速くなり、帯域幅コストも削減されます。

Default Cache TTL の最大値は 1 年です。最小値は 30 分です。

TTL の詳細については、Wikipedia を参照してください。

Cache TTL Behavior ドロップダウンでは、オリジン画像に設定された Cache-Control: max-age ヘッダーに対して Imgix がどのように動作するかを決定します。3 つのオプションがあり、それぞれ対応する TTL の値があります。

• Respect origin: Cache-Control: max-age ヘッダーが存在する場合はそれを尊重し、存在しない場合は Default Cache TTL の値を適用します。
• Override origin: ヘッダーが存在する場合は Override Cache TTL の値で上書きし、存在しない場合はその値を適用します。
• Enforce minimum（デフォルト）: ヘッダーが存在しない場合は Minimum Cache TTL の値で Cache-Control: max-age ヘッダーを適用し、既存のヘッダー値が Minimum Cache TTL の値より低い場合はその値で上書きします。

アセットキャッシュのデフォルトの動作と値の設定に加えて、デフォルトエラー画像（設定している場合）についても Cache-Control: max-age ヘッダーを設定できます。この値は短く設定することを推奨します。これは、エラーが解消された後もエラー画像が表示され続けることを防ぐためです。

TTL の値を設定する方法は以下の通りです。

1. Source Details ページで Edit をクリックします。
2. 「Cache Settings」で、希望する Cache TTL Behavior をドロップダウンから選択します。
3. 変更したい TTL の時間値を入力し、ドロップダウンメニューから時間の単位を選択します。
4. Review & Deploy ボタンをクリックし、新しいキャッシュ設定でソースを再デプロイします。

指定された期間、アセットや派生画像をできる限りキャッシュするよう努めますが、Imgix で生成可能な画像の組み合わせは非常に多いため、理想的にはすべての派生画像を永久にキャッシュすることは不可能です。

場合によっては、キャッシュから画像の派生版を削除し、必要に応じて再レンダリングすることがあります。派生画像が、意図されたキャッシュの有効期限または 30 日のいずれか短い方より前に削除・再レンダリングされた場合、その分の課金は発生しません。

また、アセットストレージにファイルを追加する際は、すべてのアセットに Cache-Control: max-age=86400 ヘッダーを設定することを推奨します。これにより、Imgix が処理しないファイル（CSS など）のキャッシュミスを減らし、Imgix が処理するアセットをオリジンから再取得することも防げます。すでに配置済みのファイルを更新する必要がある場合は、アップロード後にヘッダーを設定するスクリプト（Amazon S3 の場合は s3cmd など）を実行できます。

一般的なキャッシュ戦略と Imgix との連携については、Fingerprinting Images guide を参照してください。

Preserve Origin Cache Age

デフォルトでは、オリジンから取得された画像は Imgix で新しいキャッシュ有効期間を開始します。レスポンスには Age: 0 が付与されるため、下流のキャッシュ（CDN、ブラウザ、デバイスのキャッシュ）は、オリジン側のコピーがすでに有効期間の大半をキャッシュされていた場合でも、max-age 全体の期間にわたって画像を新しいものとして扱います。

Preserve origin cache age を有効にすると、Imgix はオリジンのキャッシュ経過時間をレスポンスに引き継ぎます。

• Age ヘッダーは、オリジンが返した Age に、画像が Imgix のキャッシュ内に存在していた時間を加えた値になります。
• Imgix のキャッシュは、max-age 全体をやり直すのではなく、オリジン側に残っている有効期間（max-age から Age を引いた値）だけ画像を保持します。
• 下流のキャッシュは Age ヘッダーを尊重するため、すべてのキャッシュ層がオリジンのコピーと同時に期限切れになります。

例えば、オリジンが Cache-Control: max-age=3600 と Age: 3000 を返した場合、下流のキャッシュは画像を新たに 3600 秒ではなく、残り 600 秒間だけ新しいものとして扱います。オリジンの Age がすでに max-age 以上の場合、Imgix は画像をキャッシュせずに配信します。

この設定は、オリジンのキャッシュヘッダーで鮮度を管理している場合に役立ちます。例えば、予定されたコンテンツ変更の前に max-age を短くし、パージを行わずにその変更を予定通りエンドユーザーに反映させたい場合などです。

この設定はデフォルトでオフになっています。有効にする方法は以下の通りです。

1. Source Details ページで Edit をクリックします。
2. 「Cache Settings」で Preserve origin cache age にチェックを入れます。
3. Review & Deploy ボタンをクリックし、ソースを再デプロイします。

この設定を有効にする場合は、以下の点に注意してください。

• Cache TTL Behavior: Respect origin でオリジンが max-age を返す場合、オリジンの値が使用され、Imgix の TTL の値は適用されません。Override origin または Enforce minimum の場合は、Imgix の TTL 設定が引き続き適用されます。
• 対象外のレスポンス: エラーレスポンス、デフォルト画像およびエラー画像、AI で変換された画像には、オリジンの Age が付与されず、現在のキャッシュ動作が維持されます。
• キャッシュ済みの画像: 設定を有効にする前にキャッシュされた画像は、期限切れになるまで現在の有効期間が維持されます。これには最大で 1 TTL 分かかります。その後は、すべての画像が新しい動作に従います。

Video Cache TTL

Video Cache TTL は、HLS マニフェスト、トランスコードされた MP4 ファイル、生成された VTT 字幕ファイルなど、処理済み動画アセットのキャッシュ保持期間を制御します。これは画像のキャッシュ TTL とは独立した設定で、動画出力にのみ適用されます。

画像の Minimum Cache TTL と同じ enforce-minimum の動作を使用します。オリジンアセットに Cache-Control ヘッダーがない場合は設定された TTL が適用され、既存のヘッダー値が設定値より低い場合は上書きされます。

Origin Cache Retention

Origin Cache Retention 設定は、オリジンファイルがアクセスされない状態でどのくらいの期間が経過すると Imgix の オリジンキャッシュ から削除されるかを制御します。ファイルが最初にキャッシュされた時点から一定のスケジュールで期限切れになるわけではなく、設定した日数の間オリジンキャッシュへのアクセスがなかった場合に削除されます。アクセスがあるたびに、このカウントダウンはリセットされます。これは、上記の Cache-Control ヘッダーの動作（ブラウザやシールドキャッシュ・エッジキャッシュといった下流でのキャッシュ保持期間を制御するもの）とは別の設定です。

このカウントダウンをリセットするのは、オリジンキャッシュに到達したリクエストのみです。シールドキャッシュまたはエッジキャッシュのみで処理され、オリジンキャッシュまで到達しなかったリクエストは、この設定上のアクセスとしてカウントされません。そのため、下流では引き続き正常に配信されていても、オリジンキャッシュからはファイルが削除される場合があります。

この設定を効果的に機能させるには、上記の Cache TTL Behavior の値より低く設定することを推奨します。Origin Cache Retention を Cache TTL と同じかそれより高く設定すると、派生画像を更新するために下流から発生するリクエストが Cache TTL の間隔と同程度の頻度でオリジンキャッシュにアクセスすることになり、カウントダウンが期限切れになる前にリセットされてしまいます。

オリジンキャッシュが Imgix の全体的なキャッシュアーキテクチャの中でどのような役割を果たすかについては、CDN ガイドライン を参照してください。

Render Settings

Render Settings セクションでは、Rendering API を使用する際にソースで有効化されるレンダリング機能を制御します。

レンダリング機能が無効になっている場合、その機能に関連するパラメータは Rendering API で使用しても無視されます。

アセットセキュリティ

Secure URLs

Secure URLs を有効にすると、期限付きトークンで画像 URL を署名できます。不正アクセスから画像を保護するための機能です。

Secure URLs を正しく機能させるには追加の設定が必要です。詳細は Securing Assets ガイドを参照してください。

クロスドメインポリシーファイル

Webサイトやアプリでアセットをドメイン間で正しく配信するために Cross-Domain Policy ファイルが必要な場合は、Security settings のチェックボックスをクリックしてダッシュボードで有効にできます。

有効にすると、Imgix はリクエストしてきたクライアントに対して以下のファイルを配信します。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <site-control permitted-cross-domain-policies="all" />
    <allow-access-from domain="*" secure="false"/>
</cross-domain-policy>

robots.txt

robots.txt ファイルは、Imgix ドメインのパス /robots.txt（例: yourimgixsubdomain.imgix.net/robots.txt）で確認できます。

このファイルは、検索エンジンのクローラーがアセットに対してどのようにアクセスするかを制御します。設定可能な値は以下の通りです。

• Origin: ソースに設定されたパスプレフィックスに基づき、オリジンの robots.txt ファイルをそのまま通過させます
• Allow All（デフォルト）: クローラーがすべてのアセットにアクセスできることを伝えます
• Disallow All: クローラーがアセットにアクセスしないよう伝えます

robots.txt ファイルは、robots.txt の標準に準拠したクローラーにのみ有効です。アセットへの不正アクセスを防ぐものではありません。

robots.txt への変更は、反映されるまで約 5 分かかります。

robots.txt について詳しくは、こちらの Google のリソース を参照してください。

ソースの無効化・有効化・削除

ソースが不要になった場合、一時的に無効化してアセットの配信を停止したり、いつでも再度有効化したりできます。ソースが完全に不要になった場合は、永久に削除することもできます。ソースビューページ上部の設定アイコンにカーソルを合わせることで、ソースを無効化・有効化・削除できます。現在のソースのステータスに応じて、無効化・有効化・削除のオプションが表示されます。

ソースの無効化

ソースを無効化すると、即座にアセットの配信が停止されます。そのソースに対する特定のアセットパスへのリクエストは、ソースが再度有効化されるまでエラーレスポンスを返します。

ソースの有効化

以前に無効化されたソースを再度有効化すると、割り当てられた Imgix ドメインでアセットを配信する機能が復元されます。

ソースの削除

ソースを削除すると、アカウントから完全に削除されます。一度削除すると、ソースの構成を復元することはできず、関連する Imgix ドメインはアセットの配信を停止します。

ルート Imgix URL

Root Imgix URL（例: https://your-source.imgix.net/）は、ソースが有効か無効かに関わらず常に応答します。ただし、ソースが無効化されている場合、特定のアセットパスへのリクエスト（例: https://your-source.imgix.net/image.jpg）はエラーレスポンスを返します。

つまり:

• ベースドメインは常に応答します。
• アセットの配信は、ソースの有効状態によって制御されます。
• ソースを再度有効化すると、ドメインを変更せずに通常の配信が復元されます。

配信トラブルのトラブルシューティングを行う際は、オリジン側の設定や URL のフォーマットを調査する前に、Imgix ダッシュボードでソースが有効になっていることを確認してください。