投稿者アーカイブ

CSS疑似クラスでJavaScript代用、状態監視の全貌とevent-triggerの将来像

CSS疑似クラスでJavaScript代用、状態監視の全貌とevent-triggerの将来像

CSSは状態を追跡するための仕組みを着実に増やしている。かつてはJavaScriptでしか扱えなかったUIの変化を、疑似クラスだけで表現できる場面が広がっているのだ。

:hoverや:focusといった基本的なものから、:autofillや:volume-lockedのような新しい疑似クラスまで、その数は増え続けている。これらをJavaScriptイベントリスナーと比較しながら整理すると、CSSの設計思想がより明確に見えてくる。

ポインター系疑似クラス、UI反応の基本

ポインター系疑似クラス、UI反応の基本

マウスやタッチ操作に反応する疑似クラスは、ウェブデザインの基本だ。:hoverはpointerenterからpointerleaveまでの継続的な状態を表し、:activeは押下中の瞬間を捉える。これらは単なる一時的な出来事ではなく、ブラウザが認識する「状態」として設計されている。

:hoverと:activeの本質

CSS-Tricksの著者Carlo Daniele氏は、疑似クラスが「イベントではなく状態を追跡する」点を強調している。:hoverはpointerenterとpointerleaveという2つのJavaScriptイベントの間を継続的に監視する状態であり、:activeはpointerdownとpointerupの間の押下状態だ。この違いを理解すると、CSSとJavaScriptの適切な役割分担が明確になる。

通常状態(Before)
ボタン
↓
ホバー状態(After)
ボタン
■ 通常時 ■ ホバー時

上記のデモは静的な比較だが、実際の:hoverはカーソルが要素に乗っている間だけ継続する。JavaScriptではpointerenterとpointerleaveを個別に監視する必要があるが、CSSなら1行のセレクタで完結する。この簡潔さがCSSの強みだ。

pointer-eventsプロパティで反応を制御する

pointer-events: noneを指定すると、その要素はポインター関連のイベントを一切発火しなくなる。CSSで直接イベントの発生を抑制できる点は、JavaScriptでpreventDefaultを行うのとは異なる設計思想だ。装飾的なオーバーレイや無効化されたボタンなど、視覚的に存在するが操作対象ではない要素に有効な手法である。

フォーカス系疑似クラス、アクセシビリティの根幹

フォーカス系疑似クラス、アクセシビリティの根幹

フォーカス管理はユーザビリティとアクセシビリティの両面で重要だ。CSSの疑似クラスは、JavaScriptのfocus/blurイベントよりも直感的にフォーカス状態をスタイリングできる。

:focusと:focus-visibleの使い分け

:focusは要素がフォーカスを受け取った瞬間に発動するが、マウス操作でもキーボード操作でも一律に適用される。一方、:focus-visibleはブラウザのヒューリスティック(経験則)に基づき、フォーカスインジケーターを表示すべきかどうかを判断する。キーボード操作時にはアウトラインを表示し、マウスクリック時には非表示にする、といった制御がCSSだけで可能だ。

JavaScriptで同等の処理を書く場合、:focus-visible疑似クラスをmatchMediaで問い合わせる必要があるが、CSSならセレクタに:focus-visibleを追加するだけで済む。コード量の差は一目瞭然である。

:focus-withinと:has()の比較

:focus-withinは子孫要素がフォーカスを持っている場合に、親要素をスタイリングできる。フォーム全体をハイライトしたいときに便利だ。:has(:focus)も機能的には同等だが、:has()はより汎用的な「条件付き親セレクタ」として設計されており、フォーカス以外の条件にも対応できる。どちらを使うかは文脈次第だが、フォーカス特化の:focus-withinのほうが意図は明確になる。

フォームコンテナ(:focus-within未適用)
お名前
入力欄(未フォーカス)
↓
フォームコンテナ(:focus-within適用)
お名前
入力欄(フォーカス中)

このように、子要素のフォーカス状態を親要素のスタイルに反映させる仕組みは、JavaScriptでDOMトラバーサルを書くよりも圧倒的にシンプルだ。

フォーム系疑似クラス、バリデーションをCSSで扱う

フォーム系疑似クラス、バリデーションをCSSで扱う

フォームの入力チェックはウェブ開発の定番だが、CSSの疑似クラスを使えば、視覚的なフィードバックの大部分をJavaScriptなしで実装できる。:validや:invalidはもちろん、:user-validや:autofillといった新しい疑似クラスも登場している。

:checkedで切り替えUIを実装する

:checkedはチェックボックスやラジオボタンの選択状態を追跡する。JavaScriptのchangeイベントと異なり、CSSセレクタとしてスタイルに直接結びつく。CSS-Tricksの著者Carlo Daniele氏も指摘しているように、CSS疑似クラスは多くの場合、2つのJavaScriptイベントの間の状態を表現するが、時には条件分岐ロジックそのものを代替する。

未チェック状態
□
同意する
送信ボタンは無効
↓
チェック状態
✓
同意する
送信可能

この切り替えはJavaScriptのchangeイベントでcheckedプロパティを判定するのと同等だが、CSSではスタイルシート内のセレクタで完結する。コードの見通しが良くなる点が大きな利点だ。

:user-validと:autofill、ユーザー体験を高める新しい疑似クラス

:validや:invalidはページ読み込み直後から評価されるため、未入力の必須フィールドが即座に赤く表示される問題があった。:user-validと:user-invalidは、ユーザーが実際に値を入力しフォーカスを外すまで評価を遅延させる。JavaScriptのchangeイベントに近い挙動だ。

:autofillはブラウザの自動入力機能を検出するJavaScriptイベントが存在しない中で、CSSだけで自動入力されたフィールドをスタイリングできる貴重な手段である。パスワードマネージャーによる自動入力を視覚的に識別したい場合に実用的だ。

バリデーション状態の比較
:invalid 読み込み直後に即時評価(未入力でも赤くなる)
:user-invalid ユーザー操作後まで評価を遅延(実用的)
:autofill ブラウザ自動入力を検出(JSイベント無し)
■ 即時評価 ■ 遅延評価 ■ 自動入力検出

JavaScriptで同等の処理を実装する場合、checkValidity()メソッドやValidityStateオブジェクトを使うことになる。フォーム送信時に全体を検証するケースではJavaScriptが適しているが、入力中のリアルタイムフィードバックはCSSの疑似クラスに任せるほうが合理的だ。

メディア要素疑似クラス、動画と音声の状態をスタイリングする

メディア要素疑似クラス、動画と音声の状態をスタイリングする

HTML5の<audio>要素や<video>要素は、これまでJavaScriptで状態を監視しなければカスタムコントロールを作成できなかった。しかし、CSSのメディア要素疑似クラスが整備されつつあり、状況は変わりつつある。これらの疑似クラスはInterop 2026の対象にもなっており、ブラウザ間の相互運用性の向上が期待されている。

メディア疑似クラスとJSイベントの対応
CSS :buffering → JS waiting
CSS :muted → JS volumechange
CSS :playing → JS playing (playではない)
CSS :stalled → JS stalled
CSS :volume-locked → JS 専用イベントなし(要ダミー要素)
■ CSS疑似クラス ■ 対応するJavaScriptイベント

:volume-lockedは特に興味深い。JavaScriptで音量ロックを検出するには、ダミーのvideo要素を生成してvolumeを設定し、その値が反映されたかどうかを確認するという回りくどい方法が必要になる。CSSなら:volume-locked疑似クラスひとつで完結する。ブラウザ側の制約をCSSが抽象化してくれる好例だ。

インタラクティブ要素疑似クラス、ポップオーバーとダイアログの制御

インタラクティブ要素疑似クラス、ポップオーバーとダイアログの制御

近年HTMLに追加された<dialog>要素やポップオーバー機能は、CSSの疑似クラスと組み合わせることで真価を発揮する。:popover-open、:open、:modal、:fullscreenといった疑似クラスは、JavaScriptのtoggleイベントに頼らずにUIの状態をスタイリングできる。

閉じた状態(:open非該当)
ダイアログ(非表示)
開くボタン
↓
開いた状態(:open該当)
ダイアログ(表示中)
閉じるボタン
■ 非表示 ■ 表示中

JavaScriptで同様の処理を書く場合、toggleイベントを監視してから要素のopenプロパティをチェックする2段階の処理が必要になる。CSSの疑似クラスなら、スタイルシート内で直感的に記述できる。モーダルダイアログが開いているときに背景を暗くする処理も、:modal疑似クラスと::backdrop疑似要素の組み合わせで表現可能だ。

event-trigger、CSSに真のイベントリスナーが到来する未来

event-trigger、CSSに真のイベントリスナーが到来する未来

CSS-Tricksの著者Carlo Daniele氏が紹介しているAnimation Triggers仕様のevent-triggerは、現時点ではどのブラウザも未実装だが、CSSの状態監視を次の段階に引き上げる提案だ。これは従来の疑似クラスとは異なり、JavaScriptのイベントリスナーに近い働きをする。

event-triggerの基本構文

event-triggerは、CSSアニメーションを特定のイベントに結びつける仕組みである。event-trigger-nameでアニメーションの識別子を定義し、event-trigger-sourceで発火条件となるイベント(click、touch、dblclick、keypressなど)を指定する。アニメーションは通常その場で再生されるのではなく、イベントが発生するまで待機する。

@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

button {    
  /* クリック時に --event アニメーションを発火 */
  event-trigger: --event click;
}

div {
  /* --event が発火したらアニメーションを前方再生 */
  animation-trigger: --event play-forwards;
  animation: fade-in 300ms both;
}
STEP 1 ボタンに event-trigger を設定
↓
STEP 2 クリックイベントで –event が発火
↓
STEP 3 animation-trigger がアニメーションを再生
↓
STEP 4 対象要素がフェードインアニメーションを実行

この流れは、従来のCSS疑似クラスが「状態」を追跡していたのに対し、明らかに「イベント」の発生をトリガーとしている点が新しい。clickイベントは元に戻せない不可逆的な出来事だが、interestイベントのように出入りがあるイベントの場合は、ステートフルな双方向トリガーも定義できる。

ステートレスとステートフルの2種類のトリガー

event-triggerには2つのモードが想定されている。ステートレストリガーはclickのような一度きりのイベント向けで、アニメーションは一方向にのみ再生される。ステートフルトリガーはinterestのような持続的な関心を表すイベント向けで、イベントの開始と終了に応じてアニメーションを前後に再生できる。

/* ステートフルトリガーの例 */
button {    
  event-trigger: --event interest / interest;
}

div {
  animation-trigger: --event play-forwards play-backwards;
  animation: fade-in 300ms both;
}

この構文では、interestの開始時にアニメーションを前方再生し、interestの終了時に逆再生する。ホバーでメニューがスライドインし、カーソルが離れるとスライドアウトするようなUIを、JavaScriptのイベントリスナーなしで実装できる可能性がある。

ステートレストリガー(click)
イベント クリック → アニメーション 前方再生のみ
ステートフルトリガー(interest)
開始イベント 関心を持つ → 前方再生
終了イベント 関心を失う → 逆再生
■ ステートレス ■ ステートフル

この仕様が実用化されれば、CSSのみで完結するUIコンポーネントの幅は大幅に広がるだろう。ただし、Carlo Daniele氏自身も記事内で触れているように、仕様は現在編集中であり、今後のドラフトで構成が大きく変わる可能性がある。現時点では構想段階の提案として捉えておくのが適切だ。

この記事のポイント

  • CSS疑似クラスはJavaScriptイベントの代替ではなく、状態を監視する独自のレイヤーとして進化している
  • :hoverや:focusのような基本疑似クラスから、:autofillや:volume-lockedのような新しい疑似クラスまで、対応範囲は拡大中
  • メディア要素疑似クラスはInterop 2026の対象であり、ブラウザ間の相互運用性が今後向上する
  • event-trigger仕様はCSSに真のイベントリスナーをもたらす提案だが、現時点では未実装であり将来の動向に注目すべき
  • CSSとJavaScriptは競合するものではなく、適材適所で組み合わせることで効率的なUI開発が可能になる
海田 洋祐
AWS Certificate ManagerがACME対応、TLS証明書の自動更新を実現

AWS Certificate ManagerがACME対応、TLS証明書の自動更新を実現

AWS Certificate Manager が ACME プロトコルに対応

AWS Certificate Manager が ACME プロトコルに対応

2026年6月30日、AWS Certificate Manager(ACM)が ACME(Automatic Certificate Management Environment)プロトコルに対応した。この機能追加により、AWS 上で稼働するアプリケーションの公開 TLS 証明書の取得・更新を、Certbot や cert-manager といった既存の ACME クライアントから自動化できるようになる。

証明書の有効期限は短縮の一途をたどっている。CA/Browser Forum の規定により、公開 TLS 証明書の最大有効期間は 2027 年 3 月に 100 日へ、さらに 2029 年までに 47 日へと段階的に引き下げられる見通しだ。手動での更新運用はもはや現実的ではなく、自動化が不可避の状況にある。

ACM の ACME 対応は、単なる証明書自動化の一手を超えて、組織全体の証明書ガバナンスを一元化する大きな転換点となる。PKI 管理者は DNS 管理権限をエンドポイントに集約しつつ、アプリケーション担当者には EAB(External Account Binding)認証情報だけを配布すればよく、DNS キーを組織内にばらまくリスクを排除できる。

短命化する証明書と自動化の必然性

従来の TLS 証明書は最大 1 年を超える有効期間が一般的だった。しかし、CA/Browser Forum は証明書のライフサイクル短縮を段階的に進めており、2027 年 3 月には最大 100 日、2029 年までには 47 日への短縮が義務付けられる。これは証明書の更新頻度が年 1 回から年 3〜4 回、最終的には年 7〜8 回に跳ね上がることを意味する。

手動による更新フローでは、この頻度に耐えられない。更新漏れによる証明書切れは顧客にエラー画面を表示させ、サービス自体の停止を招く。ACME プロトコルはこうした課題に対処するために策定されたオープン標準であり、Let’s Encrypt をはじめとする多数の認証局が採用している。

従来の手動更新フロー(Before)
証明書の期限を人が監視し、期限が近づくと手作業で更新していた
担当者 期限監視 → 手動更新 → 設定ミス・期限切れリスク大
※有効期間が 100 日未満になると、この運用は破綻する
↓
ACME 自動更新フロー(After)
ACME クライアントが期限前に自動で証明書を更新する
ACME クライアント → ACM エンドポイント → 証明書自動更新
※人が介在しないため、更新漏れや設定ミスが根本的に発生しない

このデモで示すように、ACME プロトコルを利用すると証明書ライフサイクルから人手を排除できる。AWS が ACME エンドポイントをマネージドサービスとして提供することで、利用者は証明書発行インフラの運用負荷からも解放される。

Amazon Trust Services による証明書発行

ACM が ACME 経由で発行するのは、Amazon Trust Services(ATS)を認証局とする公開証明書だ。ATS のルート証明書は主要なブラウザおよび OS にデフォルトで信頼されているため、発行された証明書は即座に本番環境で利用できる。

証明書の鍵タイプは ECDSA P-256 がデフォルトだが、RSA 2048 や ECDSA P-384 も選択可能だ。クライアント側の要件に合わせて設定できる柔軟性を持ちつつ、デフォルトではより高速でセキュアな ECDSA が推奨されている。

ACME エンドポイントの設定とドメイン検証の仕組み

ACME エンドポイントの設定とドメイン検証の仕組み

ACM の ACME 対応で最も特徴的なのは、ドメイン検証を PKI 管理者がエンドポイントレベルで一括実施する点だ。一般的な ACME 環境では、証明書を必要とするクライアントごとに DNS レコードの設定権限が必要になる。これに対して ACM の方式では、管理者がエンドポイント作成時にドメインを検証し、以後の証明書リクエストはそのエンドポイントが管理する。

エンドポイントの作成手順

ACM コンソールの「ACME 証明書」ページからエンドポイントを作成する。設定項目は以下の通りだ。

  • エンドポイント名(任意の識別名)
  • エンドポイントタイプ(Public を選択)
  • 証明書タイプ(Public を選択)
  • 鍵タイプ(ECDSA P-256 がデフォルト)
  • ドメイン名(証明書を発行する対象ドメイン)
  • ドメインスコープ(厳密なドメイン、サブドメイン、ワイルドカードの許可設定)

ドメインスコープの設定はガバナンス上とくに重要だ。Exact domain(完全一致ドメイン)だけを許可すれば、サブドメインやワイルドカード証明書の発行を防げる。たとえば本番系のエンドポイントでは Exact domain と Subdomains のみを有効化し、Wildcards は無効にすることで、証明書の発行範囲を厳格に制限できる。

ドメインスコープによる証明書発行範囲の制御
Exact domain のみ許可
example.com の証明書のみ発行可能。サブドメインやワイルドカードは不可
Exact domain + Subdomains 許可
example.com に加えて api.example.com や dev.example.com も発行可能
Wildcards を含む全許可
*.example.com のワイルドカード証明書も発行可能。広範囲の許可が必要な場合のみ使用
■ 厳格制御  ■ 標準  ■ 要審査

エンドポイント作成後、DNS 検証が実行される。Route 53 を利用していれば CNAME レコードが自動で作成されるため、手動での DNS 設定は不要だ。外部の DNS プロバイダーを使っている場合は、表示される CNAME レコードを手動で登録する必要がある。

EAB 認証情報によるクライアント登録

エンドポイントの準備が整ったら、EAB(External Account Binding)認証情報を発行する。EAB は Key ID と HMAC Key のペアで構成され、ACME クライアントがエンドポイントにアカウントを登録する際の初回認証に使われる。

一度クライアントが登録されれば、以降の証明書リクエストはクライアント自身が生成した非対称鍵ペアで認証される。EAB 認証情報はあくまで登録時のみの使い切りであり、有効期限を設定して不要な長期保管を防ぐのが望ましい。

この仕組みにより、PKI 管理者はドメイン検証という強力な権限をエンドポイントに閉じ込めつつ、アプリケーション担当者には EAB 認証情報だけを安全に配布できる。DNS キーを組織全体に配る必要がなくなる点が、従来の ACME 運用と決定的に異なる。

Certbot を使った証明書リクエストの実例

ACM コンソールには、Certbot と acme.sh 向けの CLI リファレンスが用意されている。以下は AWS News Blog の記事で紹介されている Certbot のコマンド例を再構成したものだ。

certbot certonly --standalone --non-interactive --agree-tos \
    --email <EMAIL> \
    --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory \
    --eab-kid <EAB_KID> \
    --eab-hmac-key <EAB_HMAC_KEY> \
    --issuance-timeout <ISSUANCE_TIMEOUT> \
    -d <DOMAIN>

--eab-kid と --eab-hmac-key に、先ほど発行した EAB 認証情報を指定する。各 ACME クライアントで引数名や設定ファイルの記法は異なるため、利用するクライアントのドキュメントを参照する必要がある。

コマンドが成功すると、Amazon Trust Services によって署名された有効な証明書が発行される。openssl コマンドで証明書の内容を確認したうえで、アプリケーションにインストールすればよい。発行された証明書は ACM コンソールの「ACME 証明書」タブにも表示され、コンソールや API 経由で発行した証明書と統合管理される。

一元管理がもたらす運用面の利点

一元管理がもたらす運用面の利点

ACM による ACME 対応は、単に証明書の自動発行を可能にするだけではない。最大の価値は、組織全体の証明書ライフサイクルを可視化し、ガバナンスを一元化できる点にある。

IAM ロールによるきめ細かなアクセス制御

ACM の ACME エンドポイントは IAM ロールと統合されている。ACME アカウントに対して IAM ロールをバインドすることで、どのクライアントがどのドメインの証明書をリクエストできるかを細かく制御できる。これにより、開発チームごとに発行可能なドメイン範囲を限定するといった運用が実現する。

監査ログとメトリクスの統合

すべての証明書リクエストは AWS CloudTrail に記録される。誰がいつどのドメインの証明書を要求したかを完全に追跡できるため、監査要件を満たすうえで強力な武器となる。また Amazon CloudWatch と連携することで、証明書の発行数やエラー率といった運用メトリクスもリアルタイムに把握できる。

ACM が標準で備える有効期限通知機能も ACME 経由で発行された証明書に適用される。更新が迫った証明書のアラートを一元管理でき、従来のように証明書管理ダッシュボードと ACME クライアントの管理画面を行き来する必要はなくなる。

ACM ACME の可視化・監査スタック
AWS CloudTrail
すべての証明書リクエストを API コール単位で記録。監査証跡として長期保管可能
Amazon CloudWatch
発行数・エラー率・レイテンシなどの運用メトリクスを可視化。異常検知にも活用
ACM 有効期限通知
証明書の有効期限が近づくと自動で通知。更新漏れを人的監視に頼らず防止
■ 監査  ■ モニタリング  ■ 予防

上記のスタックは、ACM 単体で証明書管理から監査、予防までをカバーできることを示している。従来は外部の認証局と ACM の間で証明書管理が分断されていたが、ACME 対応によってこの断絶が解消された。

利用可能リージョンと料金体系

利用可能リージョンと料金体系

ACM の ACME 対応は、発表時点で全商用 AWS リージョンで利用可能だ。AWS GovCloud(US)および中国リージョン、AWS European Sovereign Cloud パーティションについては、後日の対応が予定されている。

料金は証明書発行時に含まれるドメインごとに課金される方式で、完全修飾ドメイン名(FQDN)とワイルドカードで単価が異なる。ボリュームティアは AWS アカウント単位で月間の全証明書における総ドメイン出現数に基づいて計算される。具体的な価格は ACM の公式料金ページで確認できる。

この課金体系は、ACME 経由で発行される証明書も従来の ACM 証明書と同じ仕組みでカウントされるため、新たなコスト管理の複雑さは生じない。

この記事のポイント

  • ACM が ACME プロトコルに対応し、Certbot や cert-manager など既存クライアントからの証明書自動発行が可能になった
  • PKI 管理者はエンドポイントレベルでドメイン検証とスコープ制御を一括管理でき、DNS キーを組織内に配布する必要がなくなる
  • CloudTrail・CloudWatch・有効期限通知により、証明書ライフサイクル全体を単一ダッシュボードで可視化・監査できる
  • 証明書の有効期間短縮が進む中、手動運用からの脱却と自動化基盤の構築が急務となっている
  • 全商用リージョンで即日利用可能。費用はドメイン数ベースで、従来の ACM 料金体系に準じる
海田 洋祐
AutoptimizeのJavaScript最適化でドロップダウンメニューが動かない時の除外設定

AutoptimizeのJavaScript最適化でドロップダウンメニューが動かない時の除外設定

Autoptimize の「JavaScript コードを最適化」を有効にすると、ヘッダーのドロップダウンメニューが開かなくなる問題は、最適化処理がメニューを動かす JavaScript と競合するために起こる。ブラウザの開発者ツールで原因となるスクリプトを特定し、Autoptimize の「除外するスクリプト」欄にファイル名を追加すれば、最適化を維持したままメニューを正常に動作させられる。

なぜ JavaScript 最適化でメニューが動かなくなるのか

なぜ JavaScript 最適化でメニューが動かなくなるのか

Autoptimize の「JavaScript コードを最適化」は、複数の JavaScript ファイルを1つに集約し、不要な空白やコメントを削除する「縮小(ミニファイ)」を施す機能だ。加えて、読み込みタイミングをずらす「遅延読み込み」や「非同期読み込み」も合わせて適用される。

ドロップダウンメニューは、マウスのホバーやクリックを検知してサブメニューを表示する仕組みで、内部では jQuery やテーマ独自の JavaScript が複数連携して動作する。最適化によってこれらのスクリプトの実行順序が入れ替わったり、縮小処理中に特定の構文が破損したりすると、メニューを開くイベントが発火しなくなる。

特定のページだけで発生する仕組み

トップページや一部の内部ページでは正常に動き、キャリアページや特定の投稿ページだけでメニューが壊れる場合、落ちているのは集約後の順序問題であることが多い。ページごとに読み込まれるスクリプトの組み合わせが微妙に異なるため、特定の構成でのみ実行順序の破綻が表面化する。

jQuery 依存のメニューは特に影響を受けやすい

多くの WordPress テーマはメニューの開閉に jQuery を使う。Autoptimize の標準設定では jQuery も他のスクリプトと一緒に集約されるが、jQuery は他のスクリプトより先に読み込まれなければならない。集約順序が変わって jQuery が後回しになると、$ is not defined や jQuery is not defined といったエラーが発生し、メニュー全体が沈黙する。

原因となる JavaScript ファイルを特定する手順

闇雲に除外設定を増やすのは避けたい。まずはブラウザの開発者ツールでエラーの出どころを確認し、ピンポイントで除外するファイルを決める。

STEP 1 Chrome で問題のページを開き、F12 キーを押す
↓
STEP 2 「Console」タブをクリックし、赤いエラーを確認する
↓
STEP 3 エラーが示すファイル名(例: autoptimize_xxxxx.js やテーマの navigation.js)を記録する
↓
STEP 4 原因ファイルの元のパス(wp-content/themes/テーマ名/js/... 等)を特定する

エラーメッセージが「jQuery is not defined」であれば、jQuery の読み込み順がずれている。テーマ名や「navigation」「menu」を含むファイル名が表示されたら、そのファイルが縮小によって破損している可能性が高い。

エラーが出ない場合の切り分け方

コンソールにエラーが出ていないのにメニューが動かないケースもある。この場合は「Network」タブで autoptimize_xxxxx.js のレスポンスを確認し、途中で切れていないか、スクリプトの末尾が正常かを調べる。また、Autoptimize の設定で「JavaScript コードを最適化」だけをオンにし、「JavaScript を集約する」をオフにして症状が変わるかも試すと、問題の絞り込みが進む。

Autoptimize の除外設定でメニューを修復する

原因ファイルが特定できたら、Autoptimize の設定画面で除外リストに追加する。除外されたファイルは最適化の対象外となり、元の順序で単独で読み込まれるため、競合が解消する。

【Before エラー状態】
「JavaScript コードを最適化」オン
除外設定なし
→ ヘッダードロップダウンメニューが開かない
↓
【After 修正後】
「JavaScript コードを最適化」オン
除外リストに navigation.js と jquery.js を追加
→ 全ページでメニューが正常動作
■ エラー状態 ■ 修正後

除外設定の具体的な入力方法

WordPress 管理画面の「設定」→「Autoptimize」→「JavaScript オプション」を開く。「JavaScript コードを最適化」が有効になっている状態で、その直下にある「除外するスクリプト」欄に、カンマ区切りでファイル名を入力する。

入力例を以下に示す。実際のファイル名は、サイトのテーマやプラグイン構成によって異なる。

  • jquery.js 、 jQuery 本体
  • jquery.min.js 、 縮小版の jQuery
  • navigation.js 、 テーマのメニュー制御スクリプト
  • theme-menu.min.js 、 テーマが提供する縮小済みメニュー制御
  • js_composer_front 、 WPBakery 等のビルダーが出力するスクリプト

部分一致で指定できるため、jquery とだけ書けば、ファイル名に「jquery」を含むすべてのスクリプトが除外される。同様に navigation や menu といったキーワードでもよい。

「jQuery を集約しない」オプションの活用

Autoptimize の「JavaScript オプション」内には「jQuery を集約しない」というチェックボックスも用意されている。jQuery 依存のエラーが出ている場合は、個別のファイル名を書く前にまずこのチェックを入れてみると、まとめて解決することが多い。

どうしても直らない時の応用設定

除外設定を丁寧に行ってもメニューが復活しない場合、最適化モードそのものを調整する手がある。「JavaScript コードを最適化」の中には「縮小のみ(集約しない)」といった選択肢もあり、集約をやめて縮小だけに留めれば、多くの競合が回避される。

スクリプトの読み込み位置を変える

「JavaScript をフッターに移動する」や「Async(非同期)にする」といった項目も、メニューの動作に影響を与えうる。メニューはページの初期表示時に即座に動作する必要があるため、非同期読み込みにしてしまうと DOM 構築が完了する前にメニューのイベント登録が走ってしまい、動作しなくなる。まずはこれらのチェックを外して試す。

プラグイン単位での競合を疑う

まれに、Autoptimize と特定のキャッシュ系プラグインやテーマ付属の最適化機能が二重に働いて競合することがある。W3 Total Cache や WP Rocket に組み込まれた最適化と同時に使わず、いずれか一方に統一する。また、テーマの「パフォーマンス」設定内に JavaScript の最適化機能がある場合は、そちらを無効にして Autoptimize に一本化する。

よくある質問

除外設定を追加したのにメニューが直らない

Autoptimize のキャッシュが残っていると、除外設定が反映されずに古い最適化済みスクリプトが使われ続ける。管理画面の Autoptimize 設定画面で「キャッシュをクリア」ボタンを押し、さらにブラウザのキャッシュもスーパーリロード(Ctrl+F5)で破棄する。サーバーによっては CDN やサーバー側キャッシュもクリアする必要がある。

ファイル名がわからない時はどうするのか

ブラウザの開発者ツール「Network」タブで、JS ファイルの一覧を名前順に並べ、「theme」「menu」「nav」「dropdown」を含むファイルを探す。該当ファイルが見つからない場合は、テーマの開発者に「メニュー制御に使っている JavaScript ファイル名」を問い合わせるか、Autoptimize の「縮小のみ(集約しない)」モードで一旦回避する。

一部のページだけメニューが壊れるのはなぜか

ページによって読み込まれるプラグインやウィジェットのスクリプトが異なるため、集約後のファイルの構成が変わる。特定のページにだけ表示される「お問い合わせフォーム」や「求人一覧」のスクリプトが混ざると、集約後の全体の実行順序が崩れて、たまたまメニュー制御に影響が出ることがある。

Autoptimize を無効にするとサイトが遅くなるのが心配だ

JavaScript 最適化を完全に切る必要はない。問題のスクリプトだけをピンポイントで除外すれば、大部分のスクリプトは最適化されたまま配信される。PageSpeed Insights 等でスコアを確認しながら除外範囲を最小限に絞れば、速度と機能の両立は十分に可能だ。

この記事のポイント

  • JavaScript 最適化によるドロップダウンメニュー不具合は、スクリプトの順序破綻や縮小破損が原因
  • 開発者ツールの「Console」でエラーを特定し、原因ファイルを Autoptimize の除外リストに追加する
  • 「jQuery を集約しない」オプションが有効なケースも多い
  • 除外設定後は必ず Autoptimize キャッシュとブラウザキャッシュをクリアする
  • 「縮小のみ」「非同期読み込みオフ」など、最適化の段階を調整することでも解決できる
海田 洋祐
Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金

広告型モデルの限界とAIエージェント向け従量課金

広告型モデルの限界とAIエージェント向け従量課金

2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。

背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百~数万回に達しているという。

従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。

従来の広告モデル(Before)
人間の訪問者 ページ閲覧 → 広告クリック → 収益発生
※AIエージェントは広告をクリックしないため収益化できない
↓
従量課金モデル(After)
AIエージェント リクエスト → 自動支払い → リソース取得
※1リクエスト単位の少額決済で収益化が成立
人間 = 広告・サブスクリプション  AIエージェント = 従量課金・自動決済

CloudflareはすでにContent Independence DayでAIクローラーの制御機能を提供し、Pay Per Crawlでクローラーに課金する仕組みを導入していた。Monetization Gatewayはその延長線上にあり、クローラー以外の任意の呼び出し元に対して課金できる点が新しい。

エージェントが変える支払いの単位

AIエージェントが自律的に行動するようになれば、サービスの課金単位も座席数や月額から「リクエスト数」「トークン数」「成果物」へと移行する。Cloudflareが例示したのは、1回のウェブ検索あたり数セント、アップロードエンドポイントで0.001ドルの基本料金+1MBあたり0.01ドル、サポートエスカレーション解決時に0.99ドルといった単位である。

これまで実現が難しかったサブセントの決済を、x402プロトコルとステーブルコインが可能にする。ステーブルコイン(Open USDやUSDC)は1秒未満で決済が完了し、手数料が無視できるほど小さい。従来の決済手段では、手数料が支払い額を上回る逆転現象が起きていたが、それが解消される。

Cloudflareが提供する課金インフラ

Cloudflareの強みは、すでに自社の課金システムや顧客向けアナリティクスで従量課金の会計基盤を構築してきたことにある。Monetization Gatewayでは、売り手と買い手の間に入り、支払い証跡をHTTPリクエストに埋め込む形で検証パスを統合する。メータリング、支払い交換、決済はすべてオリジンサーバーの外で完結し、サイト運営者は課金ルールと価格だけを定義すればよい。買い手のオンボーディングや請求システムの構築は不要だ。

x402プロトコルとは

x402プロトコルとは

x402はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。

x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター(検証者)が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。

STEP 1 AIエージェント がリソースをリクエスト
↓
STEP 2 APIサーバー が 402 Payment Required と価格を返す
↓
STEP 3 エージェントが ブロックチェーン で支払いを実行
↓
STEP 4 支払い証明付きで再リクエスト → リソース取得
AIエージェント = 利用者  APIサーバー = 提供者  ブロックチェーン = 決済基盤

x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。

サブセント決済と一瞬の決済

ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド(1秒未満)の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。

Monetization Gatewayの機能

Monetization Gatewayの機能

Monetization GatewayはCloudflareのエッジネットワーク上で動作し、330以上の都市でリクエストを処理する。x402ハンドシェイクが買い手の近くで実行されるため、レイテンシが小さくなり、オリジンサーバーへの負荷も軽減される。

具体的な課金ルールの適用方法として、以下のような機能が計画されている。

  • 特定のRESTメソッドへの課金。/api/premium/* へのGETやPOSTに0.01ドルを設定できる
  • タスクの複雑さに応じた変動価格。画像生成などの処理負荷に応じて最大2ドルまでの課金が可能
  • 認証されていない発信者への402 Payment Requiredの返却。オリジンが401を返した際に、自動で402と価格情報に置き換える

ルールはCloudflareのダッシュボードから設定するほか、Cloudflare APIやTerraformを通じてコードとして管理できる。課金エンドポイントの追加が、単なる別のインフラ設定として扱えるようになる設計だ。

Cloudflareはまた、Web Bot Authとの連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。

ルール定義
サイト運営者 ダッシュボード / API / Terraform で設定
↓
エッジで検証
Monetization Gateway 支払いを確認しオリジンを保護
↓
決済完了
ステーブルコイン 売り手のウォレットに直接入金
運営者 = ルール設定  Gateway = 検証  決済 = 即時着金

売り手にとっての変化

Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。

これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。

この記事のポイント

  • CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
  • AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
  • ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
  • 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
  • Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている
海田 洋祐
CSS Gap装飾とrandom()関数、select要素のサイズ制御の最新情報

CSS Gap装飾とrandom()関数、select要素のサイズ制御の最新情報

2026年6月末、CSS-Tricksの定期コラム「What’s !important」第14回が更新された。ギャップ装飾、random()関数、select要素のサイズ制御、モダンテーマ構築など、今後のWeb制作に直結するトピックが盛り込まれている。

ブラウザの安定版に大きな機能追加がなかった時期にも関わらず、開発者コミュニティの実験や標準化の進展は目を見張るものがある。本記事では、これらの最新情報を実務の視点で整理し、各機能の具体的な活用法を示す。

ギャップ装飾とランダム関数 ー 隙間を彩るCSSの新表現

ギャップ装飾とランダム関数 ー 隙間を彩るCSSの新表現

CSS Gap装飾でグリッドの隙間をデザインする

FlexboxやGridレイアウトでおなじみのgapプロパティは、要素間に一定の間隔を生み出す。これまではその隙間自体を装飾する手段がなかったが、CSS Gap Decorationの概念によって新たな表現が可能になった。Temani Afif氏がMaster.devで公開した記事では、gap部分に背景色やボーダー、画像を配置する方法が詳しく解説されている。

従来のレイアウト(Before)
項目A
項目B
項目C
要素同士が密着し、隙間がない。
↓
Gap装飾を適用したレイアウト(After)
項目A
項目B
項目C
コンテナ背景が gap の隙間を彩る(赤系のアクセント)。
■ gap=0(要素が密着)  ■ gap装飾あり(背景色で隙間を強調)

上記の例では、flexコンテナに背景色を設定することで、gapが作り出すスペースに色が適用されている。Temani Afif氏の記事では、疑似要素やボーダーを用いて、より複雑な装飾を実現する手法が紹介されており、実務での利用価値が高い。

CSS random()がもたらすランダムな表現

CSSのrandom()関数は、スタイルシートに乱数を導入する試験的な機能だ。現時点ではSafariのみが対応しており、他のブラウザでは動作しない。Polypaneのブログでは、この関数を活用した多彩な実験が公開されている。

random() を使わない均一な配置
↓
random() でランダム性を加えたイメージ
※このデモはCSS random()の概念を視覚化したイメージです。実際の動作はSafariで確認してください。
■ 均一な大きさ・透明度  ■ バラつきのある表現

Polypaneのデモでは、桜の花びらが舞い散るアニメーションやポラロイド写真の不揃いなスタックなどが実装されており、random()の実用性を感じさせる。ブラウザの対応が進めば、よりナチュラルなUI演出に活用されるだろう。

フォーム要素の可変サイズと動的テーマ構築

フォーム要素の可変サイズと動的テーマ構築

field-sizing: contentでselectの幅を動的に調整

Manuel Matuzović氏の記事で取り上げられたfield-sizing: contentは、フォームの見た目を柔軟にする新しいCSSプロパティだ。特に<select>要素に適用すると、選択された<option>のテキスト幅に合わせて自動的にサイズが変わる。Firefox 152のリリースにより、この機能はBaselineに加わり、主要ブラウザで使用可能になった。

従来の固定幅select(Before)
幅が固定されているため、長いテキストは切り捨てられて見える。
↓
field-sizing: content 適用後(After)
選択したオプションのテキストに合わせて幅が自動調整される。
■ 固定幅(切り捨て)  ■ 可変幅(テキストにフィット)

なお、size属性を併用してスクロール可能なリストボックスにした場合、field-sizing: contentがsizeを上書きし、すべてのオプションを表示するようになる点には注意が必要だ。

モダンCSSテーマ構築の新たなスタンダード

GoogleのUna Kravets氏は、light-dark()関数やcontrast-color()関数、@property、@container style()を組み合わせた新しいテーマ構築手法を解説した。これらの機能はいずれもBaselineに到達しており、モダンブラウザで広く利用できる。

ライトモード

見出しテキスト

本文のテキストがここに入ります。背景は白、テキストは濃い色。

↓
ダークモード

見出しテキスト

本文のテキストがここに入ります。背景は暗色、テキストは明るい色。

■ ライトモード (light-dark() で動的切替)  ■ ダークモード

contrast-color()を用いれば、背景色に応じて最適な文字色を自動選択でき、アクセシビリティを確保しつつテーマ構築が容易になる。Una氏の記事は、これらの機能を組み合わせた実装パターンとして参考になる。

プラットフォームの多様性を受け入れたウェブデザイン

プラットフォームの多様性を受け入れたウェブデザイン

Bramus氏がブログで提唱した「ウェブサイトはすべてのプラットフォームで同一に動作する必要はない」という考え方は、レスポンシブデザインを超えた新たな視点だ。入力デバイスの違いや、OSごとのAPIの特性を無理に統一せず、それぞれに適した体験を提供することが重要だと説く。

入力モダリティの多様性に対応する

デスクトップではマウスとキーボード、モバイルではタッチが主要な入力手段だが、ユーザーはスタイラスやゲームパッド、音声入力を併用することもある。すべての操作を全デバイスで同一に再現しようとすると、かえって使い勝手が損なわれるケースがある。Bramus氏は、プラットフォーム固有のインタラクションを許容することで、より自然な操作感を実現できると指摘している。

プラットフォーム依存のAPIと設計

同氏は具体例として、interest invokers(興味を示すUI)やoverscroll actions(スクロールオーバー時の挙動)、Document Picture-in-Picture APIなどを挙げた。これらはOSやブラウザによってふるまいが異なるのが自然であり、無理にクロスプラットフォームで統一するよりも、各環境での最適化を優先すべきだという。

🖥️ デスクトップ マウス&キーボード操作が中心
↓
📱 モバイル タッチ、スワイプが主体
↓
📺 テレビ リモコン操作、フォーカス移動
プラットフォームごとに最適な操作体系を想定する。

この考え方は、Webアプリの設計においても、無理に同一のUIを強制するのではなく、各環境が持つ強みを活かしたコンテキスト適応の重要性を示している。

クリエイティブな実験とコミュニティの熱

クリエイティブな実験とコミュニティの熱

CSSの進化は技術仕様だけでなく、開発者コミュニティの創造的な取り組みによっても加速している。今回の!important #14では、いくつかの目を引くプロジェクトとイベントが紹介された。

CSS QuakeとHyperblam ー コードで遊ぶ

Layoutitが公開したCSS Quakeは、1996年の名作FPSゲーム「Quake」をCSSで再現したプロジェクトだ。PolyCSSを活用し、HTMLとCSSだけで3Dグラフィックス風の表現を実現している。この流れは、先日話題になったCSS DOOMに続くもので、CSSの表現力の高さを改めて示している。

また、Heydon Pickering氏が制作したHyperblamは、HTMLのWeb Componentsを用いて音楽を作るというユニークな試みだ。JavaScriptを一切使わず、HTMLタグだけでWeb Audio APIを操作する。CSSとの直接的な関係は薄いが、ウェブ技術の可能性を広げる実験として注目される。

Web Engines Hackfest 2026の熱気

6月にスペインのガリシア地方で開催されたWeb Engines Hackfestでは、ブラウザエンジンやウェブ標準の未来について活発な議論が交わされた。CSS-Tricksの!important #14では、参加者であるMarina Aísa氏のレポートが紹介されており、初日のハイキングから始まり、二日間にわたるトークやクライミング、アクセシビリティ改善に向けたディスカッションの様子が伝えられている。

こうした草の根の開発者会議は、標準仕様の策定やブラウザ実装に直接影響を与える場でもある。Marina Aísa氏のノートは、今後のWeb制作に携わる者にとって貴重な情報源となるだろう。

この記事のポイント

  • CSS Gap装飾は、gapプロパティで生じた隙間に背景色やボーダーを適用し、レイアウトに新たなアクセントを加えられる
  • random()関数はSafariのみの対応だが、ランダムな表現を実現する強力なツールであり、今後の普及が期待される
  • field-sizing: contentにより、select要素の幅を選択肢に応じて動的に変更可能。すでにBaseline入りしており実務利用が進む
  • light-dark()やcontrast-color()、@container style()を組み合わせたテーマ構築は、アクセシビリティと効率を両立する
  • プラットフォームごとに異なる操作体系やAPIを尊重し、同一性ではなく最適性を追求する設計が重要視されている
  • CSS QuakeやHyperblamといった遊び心のあるプロジェクトは、技術の可能性を広げ、コミュニティの活力を象徴している
海田 洋祐
Amazon FBM配送要件が厳格化、定時配達率90%維持が必須に

Amazon FBM配送要件が厳格化、定時配達率90%維持が必須に

Amazon FBM販売者の配送要件が厳格化、定時配達率90%維持が必須に

Amazon FBM販売者の配送要件が厳格化、定時配達率90%維持が必須に

Amazonが、自社で商品の発送を行うFBM(フルフィルメント・バイ・マーチャント)販売者に対する監視を強化している。ドイツでは定時配達率(OTDR)90%以上の維持が求められ、基準を下回った場合のペナルティも明確化された。イギリスでも同様の厳格化が進む。この動きはフランス、スペイン、イタリアにも波及しており、欧州のAmazonセラーにとって配送品質の向上が待ったなしの課題となっている。

日本国内でAmazon販売を展開する事業者にとっても、この欧州の政策変更は対岸の火事ではない。グローバルで足並みを揃えるAmazonのポリシーは、いずれ日本市場にも適用される可能性が高く、早めの対策が求められる。ここでは変更点の詳細と、販売者が取るべき具体的な対応策を解説する。

従来のFBM配送管理(Before)
販売者 商品の受注と梱包 → 配送業者 配送を委託 → 顧客
販売者は配送業者に委託後、配送の品質をコントロールしにくい。Amazon側の監視も緩やかで、遅延が発生してもペナルティは限定的だった。
↓
新FBM配送管理の要件(After)
販売者 発送とOTDR 90%以上の維持 → Amazon 配送品質を監視し厳格に評価 → 顧客
Amazonが定時配達率を厳格に監視。基準を下回ると販売権の停止や新規出品制限のペナルティが課される。ハンドリングタイムも自動調整の対象となる。
■ 販売者  ■ Amazon(プラットフォーム)  ■ エンドユーザー

配送品質を担保する主体が販売者からAmazonへと移行しつつある状況を示している。FBM販売者は、単に発送するだけでなく、配送プロセス全体のパフォーマンスを数値で証明する責任を負うことになる。

OTDR 90%維持の義務化、その基準とペナルティの詳細

OTDR 90%維持の義務化、その基準とペナルティの詳細

ドイツのAmazonセラー向け公式フォーラムで発表されたポリシー更新によると、FBM販売者は消費者向け注文において、定時配達率を90%以上に保つことが求められる。このOTDR(On-Time Delivery Rate)とは、顧客に約束した配達日までに商品が到着した注文の割合を指す。

消費者向け配送からB2B配送まで、段階的に強化

この要件は2026年9月1日から施行され、基準を満たせない場合、対象となる商品の出品が停止される可能性がある。さらに、FBM商品の新規出品自体ができなくなるリスクも示唆されている。

B2B取引、つまりAmazon Businessの注文についても同様の厳格化が予定されている。9月30日からは、企業向け配送の90%以上が、顧客の営業時間内に時間通り到着することが必須となる。このB2B配送指標が新たに導入され、10月30日からは基準未達の場合、企業向け出品の停止措置が取られる。この変更はイギリスのAmazon.co.ukセラーにもアナウンスされている。

STEP 1 2026年9月1日、消費者向けFBM注文でOTDR 90%以上が必須化
↓
STEP 2 9月30日、B2B注文にもOTDR 90%要件を拡大。営業時間内配達が条件に
↓
STEP 3 10月30日、B2B基準未達で出品停止ペナルティが発動

このスケジュールから、Amazonが個人消費者向けと企業向けの両面で配送品質を底上げしようとする意図が明確に読み取れる。特に法人向けは、指定された営業時間内への配達が求められるため、配送業者の選定や在庫管理により一層の正確性が要求される。

イギリス市場でも監視が強化、猶予はここまで

イギリスでは、90%のOTDR要件自体は既に存在していた。しかし、これまでは形骸化していた側面があり、2026年9月からはより厳格に執行されることになる。移行期間は終わり、抜け道は塞がれつつある。

Amazonがドイツとイギリスという欧州最大の2市場で今回のルール変更を同時に進めることは、両市場でより正確な配送約束を表示し、セラーのコンバージョン率を高める狙いがあるというのが、Amazon自身の説明だ。

ハンドリングタイムの自動調整、販売者の甘えは許されない

ハンドリングタイムの自動調整、販売者の甘えは許されない

配送要件の厳格化と並行して、ハンドリングタイムの設定ルールも大きく変わる。ハンドリングタイムとは、注文を受けてから商品を発送するまでの準備期間を指す。昨年も販売者間で議論を呼んだ問題だが、Amazonはここに再度メスを入れた。

デフォルトの2日間設定が1日へ自動短縮

2026年7月15日以降、アカウントのデフォルトのハンドリングタイムが2日間に設定されている場合、自動的に1日に短縮される。これまで多くのセラーが「念のため」と長めに設定していたバッファを、Amazonは認めなくなった。

実績ベースで自動調整される仕組み

さらに踏み込んだ施策として、9月1日からは自動ハンドリングタイム機能が本格的に稼働する。実際の発送実績よりも1日以上長くハンドリングタイムを設定している場合、その設定は30日後に自動的に短縮される。ステータス変更や再設定などの回避策は用をなさない。Amazonの説明を借りるなら「実際のパフォーマンスを反映した、より迅速な配送約束の提示を容易にする」ための仕組みだ。

従来のハンドリングタイム運用(問題点)
多くの販売者は、急な注文増加や在庫切れを恐れ、実際の作業時間よりも長めのハンドリングタイムをデフォルト設定していた。これは「安全マージン」として機能する一方で、顧客に表示される配送約束が不必要に長くなり、購買意欲を削ぐ原因にもなっていた。
⚠️ 実態より長い配送見込み → コンバージョン機会の損失
↓
今後の自動調整ロジック(改善効果)
過去30日間の実績 → Amazonが分析 → ハンドリングタイムを自動で短縮
✅ 実際より短い配送見込みが表示され、購入率(CVR)の向上が期待できる

このルール変更は、良心的なセラーにとっては強力な武器となる。配送品質の低い競合がふるい落とされることで、自社の「迅速な配送」という強みが際立つからだ。逆に、発送業務が属人的で安定しない事業者は、これまで以上に厳しい立場に置かれる。

FBM Ship+ との連動で配送体験はどう変わるか

FBM Ship+ との連動で配送体験はどう変わるか

これらのパフォーマンス要件の厳格化は、Amazonが昨年後半にドイツ、イギリス、フランス、スペイン、イタリアの5カ国で導入したFBM Ship+プログラムと密接に連動している。FBM Ship+は販売者がより迅速な配送オプションを提供するためのプログラムで、高速配送にかかるコストの一部をキャッシュバックする仕組みを備えている。Amazonはこのプログラムを「史上最も速く、かつ手頃な配送」と謳っている。

表面的には「配送の改善」だが、実態はAmazonプライムや企業購買担当者の期待値にFBM販売者を近づけるための構造改革だ。FBA(フルフィルメント・バイ・Amazon)に匹敵する配送スピードと信頼性を、自社発送でも実現せよというプラットフォームからの強い要求と解釈できる。

FBM Ship+のキャッシュバック制度は、こうした厳しい要求に対する飴として機能する。しかし、OTDR 90%維持という厳格な基準をクリアできなければ、そもそもプログラムの恩恵を受ける土台にも乗れない。

販売者が今すぐ取るべき3つの対策

欧州のルール変更を踏まえ、日本のAmazonセラーが準備すべきことを整理する。今のうちに対応を進めておけば、ポリシー変更が日本に上陸した際にスムーズに対応できる。

  • 配送キャリアのパフォーマンスを可視化する。OTDR 90%を下回る原因の多くは、配送業者の遅延だ。複数キャリアの配達実績を比較し、信頼性の高いパートナーに絞り込む必要がある。
  • ハンドリングタイムの実態を把握し、1日発送を標準化する。現在2日以上に設定している場合、自動調整の対象となる。在庫管理と出荷業務のフローを見直し、遅くとも翌営業日には発送できる体制を整える。
  • 自社ECサイトとの二重管理を避ける。Amazonの在庫連動アプリやマルチチャネル管理ツールを活用し、販売機会を逃さず、かつオーバーセリングによる配送遅延を防ぐ仕組みを構築する。

自社ECサイトにおける「配送品質」の捉え方

自社ECサイトにおける「配送品質」の捉え方

Amazonだけの話ではない。この厳格化の波は、顧客の配送に対する期待値そのものを引き上げる。Amazonで「翌日配達が当たり前」という体験をした顧客が、あなたの自社ECサイトで買い物をした時、「配送が遅い」と感じれば二度と戻ってこない可能性がある。

WooCommerceなどで自社ECを運営している事業者は、カート落ち対策として配送スピードとコストのバランスを再考すべきだ。具体的には、一定金額以上の購入で送料無料かつ翌日配送を確約する、配送ステータスを自動通知するプラグインを導入するといった施策が有効になる。Amazonの基準は、もはや業界のデファクトスタンダードになりつつある。

この記事のポイント

  • FBM販売者の定時配達率(OTDR)が90%以上必須となり、基準未達で出品停止の可能性
  • 2026年9月1日から施行、B2B注文へも同様の厳格化が段階的に拡大
  • ハンドリングタイムは実績を基に自動調整され、販売者による水増し設定が不可能に
  • 配送品質の改善はコンバージョン率向上に直結するが、基準を下回れば販売権を失うリスクも
  • 自社ECサイトでもAmazon並の配送体験が求められる時代へ、早急な業務フロー見直しが必要
海田 洋祐
MetaがInstagram埋め込みのトークン要件を撤回、WordPressで復活

MetaがInstagram埋め込みのトークン要件を撤回、WordPressで復活

Metaは2026年6月15日、約6年前に導入したoEmbed APIのアクセストークン要件を撤回した。Instagram、Facebook、Threadsの投稿URLをWordPressに貼り付けるだけで埋め込み表示が可能になる。2020年10月にそれまで動いていた機能が突然使えなくなって以降、多くのサイト運営者が埋め込み手段を模索してきたが、ようやく以前の手軽さが戻った格好だ。

今回の方針転換に合わせて、Metaは公式WordPressプラグイン「Meta Embeds」も公開している。トークン管理不要で動作し、コードはGitHubで公開されている。本記事では技術的な変更点と実務への影響、そしてこの変更がカバーしない領域についても整理する。

2026年6月15日の変更内容

今回の発表でトークン不要となったのは、以下の4つのエンドポイントだ。

  • Threads oEmbed
  • Instagram oEmbed
  • Facebook oEmbed(投稿)
  • Facebook oEmbed(動画)

従来は、これらのエンドポイントを呼び出すためにMetaの開発者アカウント登録、アプリ作成、App Review申請、そして毎回のアクセストークン付与が必要だった。2026年6月15日以降は、URLさえあれば直接APIを叩ける。レスポンスの形式自体は以前と同じで、埋め込みHTML、プロバイダ名、幅、コンテンツタイプが返ってくる。

ただし2つの注意点がある。1つ目はレート制限だ。トークンレスアクセスはトークン付きのルートよりも呼び出し回数が制限される可能性があり、高頻度で埋め込みを行うサイトでは影響が出るかもしれない。2つ目は、エンドポイントがパブリックな投稿にしか対応しない点だ。非公開アカウントや限定公開の投稿は対象外となる。

従来の埋め込みフロー(Before)
開発者アカウント登録 → アプリ作成 → App Review申請 → アクセストークン発行 → API呼び出し
↓
現在の埋め込みフロー(After)
URLを貼り付け → 埋め込み表示

この比較図からもわかるように、開発者向けの複雑な手続きが不要になった。個人ブログの運営者でも迷わずにMetaの投稿を埋め込めるようになっている。

元の変更が起きた経緯

元の変更が起きた経緯

2020年10月の衝撃

2020年10月、Metaは同社のoEmbedエンドポイントにアクセストークンを必須とする変更を発表した。WordPressにとってInstagramやFacebookのURLを貼るだけで埋め込みが表示される機能は標準装備だったが、この発表で状況は一変する。WordPressのコアチームは、数千万ものサイト運営者にトークン管理を要求することは現実的ではないと判断し、FacebookとInstagramをoEmbedプロバイダーから削除した。

すでに埋め込まれていた投稿は、WordPressがoEmbedレスポンスをデータベースにキャッシュしていたため表示が維持された。しかし新規の埋め込みは一切動作しなくなった。影響はWordPressサイト全体に及び、埋め込み機能を前提にしていたコンテンツ戦略を大きく狂わせた。

プラグイン市場への波及

この混乱に対応するため、JetpackはAutomattic社が保有するトークン経由でリクエストをプロキシする仕組みを急遽導入した。oEmbed Plusのようなサードパーティ製プラグインも登場し、一般のサイト運営者が自前でFacebook App IDとシークレットキーを生成して設定する手順を案内していた。

しかし多くの運営者はこれらの対策を取らず、埋め込み自体を諦めるか、API接続を内部で処理する専用プラグインに移行した。WP Mayorの記事によれば、この一件だけで「壊れたInstagram埋め込みを修正する」ためのコンテンツやツール群が一つのカテゴリを形成するほどだったという。

6年ぶりの方針転換の背景

Metaが2020年に掲げていた理由はプライバシーとセキュリティの強化だった。しかし今回の発表では「パブリックなMetaコンテンツの埋め込みを容易にする」という簡潔な説明にとどまっている。WP Mayorの著者Mark Zahra氏は、このタイミングでの撤回について「各プラットフォームがユーザーの注意を奪い合い、AIによる回答がリファラルトラフィックを侵食する中で、Metaが自社コンテンツを再びオープンウェブ上で流通させたいという意図が透けて見える」と分析している。

Metaが公式WordPressプラグインを公開

Metaが公式WordPressプラグインを公開

APIの方針転換と同時に、Metaは公式のWordPressプラグイン「Meta Embeds」をリリースした。ソースコードはGitHubで公開されており、オープンソースで開発が進められている。

このプラグインは、Threads、Instagram、Facebookの投稿URLをエディタに貼り付けるだけでリッチな埋め込みを表示する。設定画面はなく、トークンも不要。ブロックエディタとクラシックエディタの両方に対応している。Metaが自社製のWordPressプラグインを公式リポジトリに直接公開するのは異例の動きだ。

プラグインのReadmeに含まれるFAQには、今後の展開をうかがわせる記述がある。このプラグインは、WordPressのバージョンがすでにThreadsのoEmbedプロバイダーを登録しているかどうかをチェックし、重複登録を回避する仕様になっている。WP Mayorの記事は、この実装を「Metaの埋め込み機能がWordPressコアに再統合される布石」と見ており、今後のWordPressリリースでInstagramとFacebookのネイティブ埋め込みが復活する可能性に注目すべきだと指摘している。

プラグインなし Instagram URLを貼り付けても、WordPressコアがoEmbedプロバイダー非対応のため素のURLが表示されるだけ
↓
Meta Embeds 有効 同じURLがリッチな埋め込み表示に変換される。写真、キャプション、投稿者名が自動で展開

Meta Embedsプラグインを有効化するだけで、これまで埋め込みが動作しなかった環境でも即座に表示が改善する。WordPressコアへの統合が実現すれば、プラグインすら不要になる可能性もある。

今回の変更が影響しない領域

今回の変更が影響しない領域

oEmbedは単一投稿のAPIである

「トークンレスになったならInstagramフィードプラグインは不要では」という見方が一部で出ているが、それは誤解だ。oEmbedはあくまで1つの公開投稿URLを受け取り、その1投稿の埋め込みコードを返すAPIに過ぎない。

アカウントの最新投稿一覧を取得する機能、ハッシュタグフィード、ストーリーズの表示、自動更新といった機能は、oEmbedでは提供されない。これらは従来通りInstagram Graph APIを使い、アクセストークンによる認証が必要となる。

ブログ記事の中に特定のInstagram投稿を1つだけ埋め込みたいケースでは、今回の無料ルートが再び使えるようになった。逆に、サイトのトップページに最新のInstagram投稿を自動表示したい場合、レイアウトやフィルタリング、モデレーション機能も含めて、Instagramフィード専用プラグインの出番は変わらない。

フロントエンドでのスクリプト読み込みとプライバシー

もう1つ理解しておくべき違いは、oEmbedから返される埋め込みHTMLの動作だ。MetaのoEmbedは、投稿をレンダリングするためにMetaのJavaScriptを訪問者のブラウザに読み込む。Meta EmbedsプラグインのReadmeにも、フロントエンドでのレンダリングはMetaのプライバシーポリシーに準拠すると明記されている。

これは、Metaのスクリプトを一切読み込まずにコンテンツをネイティブ表示するソリューションとは性質が異なる。EU圏のクライアント向けにサイトを構築している場合、GDPRの観点からこの違いは重要だ。埋め込みを有効にする前に、プライバシーポリシーとの整合性を確認しておく必要がある。

実務者への実践ガイド

実務者への実践ガイド

ドキュメントとナレッジベースの更新

Instagram埋め込みにトークンやMetaアプリが必要だと説明しているコンテンツやドキュメントは、2026年6月15日以降は誤りとなった。WP Mayor自身も自社アーカイブの監査を進めていると述べており、チュートリアル記事や社内マニュアルを保有している場合は速やかな見直しが求められる。

クライアントサイトでの対応

クライアント向けにWordPressサイトを構築している場合、単発のMeta投稿埋め込みは開発者向けのセットアップなしで利用可能になった。Meta Embedsプラグインを導入すればすぐに動作する。WordPressコアへの統合が進めば、近い将来プラグインすら不要になる可能性も視野に入れておきたい。

Instagramフィードプラグインの利用者

既存のInstagramフィードプラグインを使用しているサイトには、今回の変更は一切影響しない。フィード機能はInstagram Graph APIに依存しており、oEmbedのトークン要件撤廃とは無関係だ。不安があればプラグインの開発元に確認するのが確実だが、WP Mayorの記事ではRebelCode社が開発するSpotlight Instagram Feeds(6万以上のアクティブインストールを誇る高評価プラグイン)を含め、APIベースのフィードソリューションはすべて影響を受けないと明言されている。

この記事のポイント

  • Metaが2026年6月15日、oEmbed APIのトークン必須化を撤回。Instagram、Facebook、Threadsの埋め込みがURL貼り付けだけで動作する
  • 併せて公式WordPressプラグイン「Meta Embeds」をリリース。コードはGitHubで公開され、WordPressコアへの統合も視野に入っている
  • oEmbedは単一投稿APIであるため、アカウントの最新フィード表示やストーリーズ機能は従来通りAPIトークンが必要。Instagramフィードプラグインの役割は変わらない
  • 埋め込み表示にはMetaのJavaScriptが読み込まれるため、GDPR対応が必要なサイトではプライバシーポリシーとの整合性確認が欠かせない
海田 洋祐
AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始

AWS Graviton5搭載EC2 C9gインスタンスが一般提供開始

計算負荷の高いワークロードを扱う企業にとって、「もう少しだけ処理が速ければ」という場面は多い。AWSが6月30日に発表したEC2 C9g/C9gdインスタンスは、その不満を根本から解決する新世代の計算特化型インスタンスだ。Graviton5プロセッサの投入により、前世代からvCPUあたり最大25%の性能向上を実現した。今回の発表で特に注目すべきは、クラウド最速級となるDDR5-8800MT/sメモリの採用と、正式検証済みのハイパーバイザー分離エンジン「Nitro Isolation Engine」の搭載だ。本記事では、CPU負荷の高いバッチ処理や動画エンコーディングを中心に、新しいインスタンスがどのような場面で威力を発揮するのかを詳しく解説する。

C9g/C9gdインスタンスの位置づけを見極める

C9g/C9gdインスタンスの位置づけを見極める

AWSのEC2には多様なインスタンスファミリーが存在する。頭文字の「C」はCompute Optimized(計算最適化)を意味し、他のメモリ最適化(Rシリーズ)やストレージ最適化(Iシリーズ)とは設計思想が異なる。計算最適化インスタンスは、vCPUあたりの演算性能を最大化することに特化している。リアルタイム分析、機械学習の推論、動画エンコーディングなど、1秒でも短く計算を終えたい処理に適している。

今回発表されたC9g/C9gdは、2024年秋に登場したGraviton4搭載C8gの後継にあたる。AWS GravitonシリーズはArmベースの独自プロセッサで、x86系のIntel XeonやAMD EPYCと比較して、コストパフォーマンスに優れる点が強みだ。C9gの「g」はGravitonを示し、末尾に「d」がつくC9gdはNVMe SSDによる高速なローカルストレージを内蔵する。

Graviton5プロセッサの進化点を知る

Graviton5の最大の改良点は、メモリ帯域幅の拡張とレイテンシの低減にある。C9gインスタンスはDDR5-8800MT/sのDIMMを採用し、これは現在クラウド上で提供されているプロセッサインスタンスの中で最速のメモリ速度だ。数字だけでは実感しにくいが、これはメモリとCPU間のデータ転送速度が秒間8800メガトランスファー(MT/s)ということを意味する。前世代のC8gがDDR5-5600MT/sだったため、実に57%もの速度向上にあたる。

さらに、CPUのL3キャッシュ容量が5倍に拡張された。キャッシュはCPUとメインメモリの間に位置する超高速なデータ置き場で、容量が大きいほどメモリアクセスの待ち時間を減らせる。AWS News Blogの著者Seb氏によると、これらの改善により、インメモリ分析のスループット向上や、より応答性の高いエージェント型AIループが期待できるという。

ネットワーク面でも強化が施されている。パケット処理性能はGraviton4ベースのインスタンスと比較して最大3倍に向上し、インスタンスサイズ全体の平均でネットワーク帯域が約15%、EBS帯域が約20%増加した。

C9g/C9gdの主要スペック詳細と設計思想

C9g/C9gdの主要スペック詳細と設計思想

スペック表を見ると、C9g/C9gdは最小のmedium(1vCPU/2GBメモリ)から、最大のmetal-48xl(192vCPU/384GBメモリ)まで11サイズで展開される。48xlargeではネットワーク帯域が100Gbps、EBS帯域が72Gbpsに達し、これは前世代の2倍にあたる。大規模な分散処理やリアルタイム分析基盤において、ネットワークがボトルネックになる状況を回避しやすくなるだろう。

C9gdシリーズには、ローカルのNVMe SSDストレージが追加される。容量は最小のmediumで59GB、最大の48xlargeでは3台合計で11,400GB(3×3,800GB)に達する。NVMe SSDはEBSよりもレイテンシが低いため、以下のような用途に適している。

  • HPCシミュレーションのスクラッチスペース(一時的な作業領域)
  • 機械学習推論の一時キャッシュ
  • アドサーバーのローカルバッファ

ストレージ性能も向上しており、ローカルストレージのパフォーマンスは前世代比で約30%向上した。NVMe経由の詳細なI/Oパフォーマンス統計はCloudWatchやnvme-cli経由で取得可能で、I/Oサイズ別のレイテンシヒストグラムが1秒単位で確認できる。この機能は追加料金なしで利用できる。

Instance Bandwidth Configurationの実用性を測る

C9g/C9gdには、Instance Bandwidth Configuration(IBC)と呼ばれる帯域調整機能が搭載されている。これは、EBSとVPCネットワークの帯域配分を最大25%の範囲で調整できる仕組みだ。例えば、データベースやキャッシュ用途でEBSの帯域を優先したい場合、ネットワーク側を絞ってEBS側に割り当てを寄せることが可能になる。逆に、ネットワーク集約型の分散処理ではVPC側を優先すればよい。固定的な割り当てに縛られない柔軟性は、実運用のチューニングで大きな武器になる。

C9gとC9gdの使い分けフローを整理する

C9gとC9gdはスペックが似ているため、どちらを選ぶべきか迷う場面があるだろう。選択の決め手は「ローカルのNVMe SSDが必要かどうか」に尽きる。AWS News Blogでは、C9gを「バッチジョブ、動画エンコードパイプライン、分散分析」向け、C9gdを「HPCシミュレーションのスクラッチスペース、ML推論の一時キャッシュ、アドサーバーのローカルバッファ」向けとしている。EBSで十分な永続ストレージが足りるならC9g、一時的でも高速なローカルストレージが不可欠ならC9gdを選べばよい。

C9g を選ぶケース
EBS の永続ストレージで十分な場合
バッチジョブ 動画エンコード 分散分析
↓
C9gd を選ぶケース
高速なローカル NVMe SSD が必要な場合
HPC スクラッチ ML 推論キャッシュ アドサーバー
C9g と C9gd の選択フローは「ローカル NVMe SSD の要否」で分岐する

Graviton5がもたらすエージェント型AIへの適性を読み解く

Graviton5がもたらすエージェント型AIへの適性を読み解く

AWS News Blogの発表では、C9gのワークロード例として「エージェント型AI(agentic AI)」が明記されている。エージェント型AIとは、単なる質問応答を超えて、コードを実行し、複数ステップのタスクを自律的に組み立てて完了させるAIシステムを指す。OpenAIのOperatorやAnthropicのComputer Useが代表例だ。

この種のワークロードでは、大規模言語モデル(LLM)の推論そのものに加えて、Pythonコードの実行、API呼び出し、結果の検証といったCPUバウンドな処理が連続的に発生する。Graviton5のコア数向上と大容量キャッシュは、こうした「思考と行動のループ」を高速化する土台となる。AWSの著者Seb氏によれば、アプリケーションがデータを待つ時間を削減し、結果的にエージェントループの応答性が高まるとのことだ。

AI推論といえばGPUの印象が強いが、実際には前処理、後処理、オーケストレーションの多くがCPU上で動く。ArmベースのGraviton5は、これらの処理を低コストでさばける点が実務的な魅力となる。

Nitro Isolation Engineのセキュリティ強化を理解する

Nitro Isolation Engineのセキュリティ強化を理解する

C9g/C9gdは、計算最適化インスタンスとして初めて「Nitro Isolation Engine」を搭載した。これはAWS Nitro Systemの拡張機能で、仮想マシン間のメモリ空間、CPUレジスタ状態、I/Oデバイスへのアクセスを数学的正確さで強制的に分離する仕組みだ。

通常、ハイパーバイザーによる分離はソフトウェアの実装品質に依存する部分があるが、Nitro Isolation Engineは形式検証(formal verification)と呼ばれる数学的手法を用いて分離の正しさを証明している。形式検証とは、仕様を数理論理で記述し、実装がその仕様を厳密に満たすことを機械的に検証する手法だ。テストのように「見つかったバグがない」ではなく、「特定の前提条件下でバグが存在し得ない」ことを保証する。

AWSは2025年にこの技術を発表した際、ハイパーバイザーの分離を形式検証する取り組みについてホワイトペーパーを公開している。今回のC9g/C9gdで初めて、計算最適化インスタンスに実装されたことになる。

セキュリティ要件の厳しい金融サービスや医療データの分析をEC2上で行うケースでは、この正式検証済みの分離機構はインフラ選定の重要な判断材料になる。ソフトウェアレベルではなく、ハードウェア支援と形式検証の組み合わせで隔離を実現している点は、AWSの設計思想として特筆に値する。

利用可能リージョンと料金モデルを確認する

利用可能リージョンと料金モデルを確認する

2026年6月30日時点で、C9g/C9gdは米国東部(オハイオ、バージニア北部)、米国西部(オレゴン)、欧州(フランクフルト)の4リージョンで利用可能だ。AWSは追加リージョンへの展開も予定している。

料金モデルはSavings Plans、オンデマンド、スポットインスタンス、Dedicated Instances、Dedicated Hostsに対応する。常時稼働させるワークロードではSavings Plans、短期的なバッチ処理ではスポットインスタンスと使い分けられる。EBSボリュームは仮想インスタンス1台あたり最大128個までアタッチ可能で、大規模データの処理でもストレージ不足に悩むことは少ない。

インスタンスの起動はAWSマネジメントコンソール、AWS CLI、AWS SDKのいずれからでも可能だ。GravitonはArmアーキテクチャのため、AMIやコンテナイメージはArm向けにビルドされたものを選ぶ必要がある。公式のAmazon Linux 2023やUbuntuのArm版AMIはすでに提供されているため、新規導入時の障壁は低い。

この記事のポイント

  • C9g/C9gdはGraviton5搭載の計算最適化インスタンス、vCPUあたり25%の性能向上を達成
  • DDR5-8800MT/sメモリと5倍のL3キャッシュにより、メモリ待ち時間を大幅に削減
  • 48xlargeでは100Gbpsネットワーク帯域と72GbpsのEBS帯域、前世代比2倍に拡張
  • Nitro Isolation Engine搭載、形式検証による仮想マシン分離を実現
  • エージェント型AIやHPC、動画エンコードなどCPU負荷の高い処理に最適
海田 洋祐
Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

Prisma Compute vs Vercel、料金比較でわかるコスト差の全容

TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。

本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。

料金体系の基本比較

料金体系の基本比較

両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。

リクエスト単価(100万回あたり)
Prisma Compute $1.00 vs Vercel Pro $0.60
Vercelが約40%安い
メモリ単価(GB時間あたり)
Prisma Compute $0.006 vs Vercel Pro $0.0106
Prismaが約43%安い
CPU単価(vCPU時間あたり)
Prisma Compute $0.064 vs Vercel Pro $0.128
Prismaが半額
外向き帯域単価(GBあたり)
Prisma Compute $0.025 vs Vercel Pro $0.15
Prismaが1/6の価格
エッジリクエストとシート料金(ワークフロー)
Prisma Compute 無料 vs Vercel Pro エッジ $2.00/100万, シート $20/ユーザー/月
Prismaは開発者数やエッジ呼出に課金しない
■ Prisma Compute(予定価格)  ■ Vercel Pro  ■ Prismaが有利  ■ Vercelが有利

リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。

実ワークロードでのコスト試算

実ワークロードでのコスト試算

月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。

Prisma Compute(予定価格)
リクエスト (2000万) $20.00
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
↓
Vercel Pro(1シート)
リクエスト (2000万) $12.00
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
■ Prisma Compute ~$98  ■ Vercel Pro ~$236  差額は約2.4倍。メモリ、CPU、帯域の単価差が総額を押し上げている。

この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。

料金差を生む構造的要因

料金差を生む構造的要因

なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。

ワークとワークフローの分離

ホスティング料金は「アプリが稼働中に行う実作業(ワーク)」と「デプロイやプレビューなど開発プロセス(ワークフロー)」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。

ワーク(アプリ稼働)
リクエスト / メモリ / CPU / 帯域
Prisma Compute 課金
Vercel 課金
ワークフロー(開発プロセス)
開発者シート / エッジリクエスト / デプロイ / プレビュー
Prisma Compute 無料
Vercel 課金
■ Prisma Compute  ■ Vercel  差が生まれるのはワークフロー部分。特にシート料金は人数比例で拡大する。

Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。

データベース隣接配置によるエグレス抑制

Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。

一般的な構成(Before)
アプリ (Vercel等) → ネットワーク越し → DB (Supabase等)
アプリ-DB間通信が外向き帯域として課金
↓
Prisma Compute(After)
アプリ (Prisma Compute) + Prisma Postgres
同一基盤内で通信が完結。エグレスコストなし

データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行するAPIサーバーなどでは、Vercel+外部DB構成のエグレス費用が無視できなくなる。

開発者の声と注意点

開発者の声と注意点

VercelのFluid Computeは適合するワークロードでは大幅な削減効果を発揮する。リンク短縮サービスdub.coの創業者Steven Tey氏は、Xで「Vercelの利用タブが壊れたのかと思った」と述べ、Fluid有効化後に請求が50%減少したと報告している。

しかし、一部の開発者からは予想外の料金跳ね上がりに関する声も上がっている。Redditのr/nextjsスレッドでは、あるCTOがフロントエンドのみのNext.jsアプリの月額請求が「100ドル未満から800ドル超」に急増し、Cloudflare Workersへ移行後は「同じトラフィックで20ドル未満」になったと述べた。同スレッドでは「Vercelのフロントエンドは素晴らしく安いが、バックエンドは高すぎる」という見方や、Deployment Protection Exceptionsで150ドル請求された事例も共有されている。

好例
dub.coのSteven Tey氏
Fluid Computeを有効化 → 請求が50%減少
注意例
匿名CTO(Reddit)
フロントエンドのみのNext.jsアプリ → 月$100未満→$800超に急増
Cloudflare Workers移行後 → 同トラフィックで$20未満
開発者の不満は料金そのものより、請求の中身がワークフローの進行後に初めて可視化される点に集中している。

Prisma Computeはパブリックベータの段階であり、実際の課金が始まっていないため、利用者からの本格的なフィードバックはまだない。Prisma Blogの著者は、フィードバックが集まり次第、この比較記事を更新する意向を示している。

この記事のポイント

  • Vercelはリクエスト単価で優位だが、メモリ、CPU、帯域ではPrisma Computeが大幅に安い予定価格を提示している
  • 月間2000万リクエストの試算ではPrisma Computeが約98ドル、Vercel Proが約236ドルと2.4倍の開きがあった
  • 請求差の主因はワークフロー課金(シート料金、エッジリクエスト)とデータベース隣接によるエグレス抑制
  • VercelのFluid Computeは適切なワークロードで削減効果を発揮する一方、トラフィックに比例しない請求急増の事例も報告されている
  • Prisma Computeはまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる
海田 洋祐
大文字見出しがコンバージョンを下げる、CROプロが警告

大文字見出しがコンバージョンを下げる、CROプロが警告

ランディングページの見出しをすべて大文字にすることは、視覚的なインパクトを与える常套手段と思われている。しかし、CRO(コンバージョン率最適化)の専門家Nate Lagos氏は、それが逆効果になる可能性を指摘する。実際のA/Bテストでは、大文字をやめて各単語の先頭だけ大文字にしたところ、コンバージョン率が25%も向上した事例が報告されている。

これは、多くのECサイト担当者が見過ごしがちな落とし穴だ。本記事では、Practical EcommerceのポッドキャストでLagos氏が語ったテスト結果と、ボトムズアップアプローチに基づくCRO戦略の核心を解説する。

大文字見出しがコンバージョンを下げる意外な事実

大文字見出しがコンバージョンを下げる意外な事実

Lagos氏が実践するCROは「ボトムズアップテスト」と呼ばれる。購入ボタンや商品説明文といった、コンバージョンに直結する部分からコピーを検証していく手法だ。トップページや認知向けの広告文よりも、まず「買うか離脱するか」の瀬戸際にある箇所を最適化する。

このアプローチの過程で浮かび上がったのが、大文字見出しの問題だ。Lagos氏はX(旧Twitter)で読んだアイデアをきっかけに、あるクライアントのランディングページでテストを実施した。それまですべて大文字だった見出しを、各単語の先頭だけ大文字にするパターンに変更したところ、驚くべき結果が出た。

25%のコンバージョン向上を実現したA/Bテスト

テスト結果は明確だった。大文字をやめたランディングページでは、コンバージョン率が25%向上した。しかも、CPA(顧客獲得単価)も低下した。トラフィックの多いページだったため、この変化はビジネスにとって大きなインパクトをもたらした。

従来の大文字見出し(Before)
WHISKEY LOVERS HAT
↓
改善後の先頭大文字見出し(After)
Whiskey Lovers Hat
■ 大文字のみ(読みにくい) ■ 先頭大文字(可読性が高い)

Lagos氏によれば、これは「可読性」の問題だ。大文字だけのテキストは、単語の形状が均一になり、脳が素早く認識しにくくなる。結果として、ユーザーは読む前に離脱してしまう。見出しのフォントサイズを小さくした場合にも同様の傾向が見られ、読みやすさが購買行動に直結することが浮き彫りになった。

ボタンテキストへの応用は未検証

ただし、Lagos氏はボタンに大文字を使うことの影響まではテストしていない。CTAボタンでは大文字が効果的なケースもあるかもしれない。今回の発見は、あくまで見出しや本文レベルのテキストブロックに限定したものだ。サイトのコピーを最適化する際は、見出しから着手するのが良いだろう。

ボトムズアップアプローチの実践

ボトムズアップアプローチの実践

Lagos氏が提唱するボトムズアップテストは、従来の広告戦略の考え方をひっくり返す。多くのマーケターは、まず認知獲得のためのトップファネルから手を付ける。しかし、購入から遠い場所にあるメッセージは、実際の購買動機とは無関係なケースが多い。だからこそ、まずは購入ボタンの近くから最適化するのだ。

購入ボタン直近のコピーを最適化する

具体的には、商品詳細ページの見出し、説明文、価格表示、そしてCTAボタンの周辺テキストをテストする。Lagos氏はOriginal Grain在籍時代、この手法で5年間にわたり収益をほぼ5倍に伸ばした実績を持つ。腕時計という「実用性が低い」商材でこれだけの成果を出せたのは、買い手の感情に響くコピーを突き詰めたからだ。

ボトムズアップテストの流れ
STEP 1 購入ボタン・見出し・商品説明など、最も購入に近いテキストを特定
↓
STEP 2 A/Bテストを実施し、購買動機に直結するメッセージを発見
↓
STEP 3 そのメッセージをトップページや広告へ逆流させ、認知獲得にも反映
■ 発見フェーズ ■ 検証フェーズ ■ 展開フェーズ

このプロセスを経ることで、「顧客が本当に求めているもの」が明確になる。腕時計の例では、時刻を知るためではなく「地位や達成感の象徴」としての価値が見えてきた。こうした深層心理を突いたコピーが、結果的にコンバージョン率や平均注文単価を押し上げた。

市場飽和を打破するターゲット拡大戦略

市場飽和を打破するターゲット拡大戦略

コアオーディエンスへのリーチが頭打ちになったブランドが次に取るべき打ち手は、商品を軸にしたターゲットの拡大だ。Lagos氏は「常に『他に誰に売れるか』を問い続けろ」と語る。

男性向け商品を女性に売る方法

Original Grainでの実例が示唆に富む。当初、同ブランドは男性向けにメッセージを打っていた。しかし、顧客データを分析したところ、実は約半数の購入者が女性だった。そこでLagos氏は女性向けのコピーライティングに注力し、最終的に顧客の80%を女性が占めるまでに至った。

成功の鍵は「ギフト需要」の掘り起こしだった。Practical EcommerceのインタビューでLagos氏が明かしたところによると、女性顧客は「夫やボーイフレンドへの感謝を示したい」という動機で腕時計を購入していた。特に父の日やクリスマス前の30〜45日間は、ギフト向けのメッセージに全面切り替え、年間を通じてはメインサイトを男性向けに戻すという柔軟な運用を行った。

女性向けマーケティングを成功させる鉄則

Lagos氏が強調するのは「女性の顧客を理解するには女性を雇え」というシンプルな原則だ。彼自身、コピーライターのSarah Levinger氏を迎え入れ、女性視点のメッセージ構築を一から学んだ。自社にない視点を取り入れることは、新しい市場を開拓するための最短ルートになり得る。

従来のターゲティング(Before)
男性 のみを想定したコピー
顧客の半分を見落としていた
↓
ターゲット拡大後(After)
男性 向けサイト(通年) + 女性ギフト購入者 向けLP(季節限定)
女性顧客比率が50%から80%に向上
■ 男性 ■ 女性ギフト購入者

この事例は、商品そのものを変えずに、メッセージの受け手を変えるだけで大きな成長が可能なことを示している。自社のデータを見直し、思いがけない顧客層がいないかを探る価値は大きい。

CROテストを成功に導くツールと手法

CROテストを成功に導くツールと手法

Lagos氏がA/Bテストの実施に用いているのは、Intelligemsというツールだ。テストの信頼性を担保するため、統計的有意性は「対照群に勝つ確率が80%以上」を基準にしている。サイト訪問者数が数万から数十万、注文数が数千件に達するボリュームでなければ、意味のある結果は得られない。

ヒートマップで読者の行動を可視化

テストすべき箇所を特定するには、ヒートマップツールが有効だ。ユーザーが実際にどこを読んでいるのか、どこで離脱しているのかを可視化することで、コピー改善のインパクトが大きいエリアを見極められる。Lagos氏の経験では、ランディングページや商品ページの冒頭ブロックが最もレバレッジの効く領域だという。

A/Bテストは一度きりではなく、継続的な反復が前提となる。小さな改善を積み重ねることで、CVRやAOV(平均注文単価)、RPV(訪問単価)といった重要指標を持続的に押し上げていく。大文字見出しの回避は、その第一歩として取り組みやすい改善策と言えるだろう。

この記事のポイント

  • ランディングページの大文字見出しをやめ、各単語の先頭だけ大文字にすることでCVRが25%向上した事例がある
  • ボトムズアップテストでは、購入ボタン近くのコピーから最適化し、購買動機を明確にする
  • A/BテストはIntelligems等のツールを用い、統計的有意性を確保できる十分なボリュームで実施する
  • ターゲット拡大では、女性へのギフト訴求が男性向けブランドの顧客基盤を劇的に変える可能性がある
  • 改善は継続的な反復が鍵。大文字見出しの見直しは、今日から始められる施策の一つだ
海田 洋祐