
CSS疑似クラスでJavaScript代用、状態監視の全貌とevent-triggerの将来像
CSSは状態を追跡するための仕組みを着実に増やしている。かつてはJavaScriptでしか扱えなかったUIの変化を、疑似クラスだけで表現できる場面が広がっているのだ。
:hoverや:focusといった基本的なものから、:autofillや:volume-lockedのような新しい疑似クラスまで、その数は増え続けている。これらをJavaScriptイベントリスナーと比較しながら整理すると、CSSの設計思想がより明確に見えてくる。
ポインター系疑似クラス、UI反応の基本

マウスやタッチ操作に反応する疑似クラスは、ウェブデザインの基本だ。:hoverはpointerenterからpointerleaveまでの継続的な状態を表し、:activeは押下中の瞬間を捉える。これらは単なる一時的な出来事ではなく、ブラウザが認識する「状態」として設計されている。
:hoverと:activeの本質
CSS-Tricksの著者Carlo Daniele氏は、疑似クラスが「イベントではなく状態を追跡する」点を強調している。:hoverはpointerenterとpointerleaveという2つのJavaScriptイベントの間を継続的に監視する状態であり、:activeはpointerdownとpointerupの間の押下状態だ。この違いを理解すると、CSSとJavaScriptの適切な役割分担が明確になる。
上記のデモは静的な比較だが、実際の: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のほうが意図は明確になる。
このように、子要素のフォーカス状態を親要素のスタイルに反映させる仕組みは、JavaScriptでDOMトラバーサルを書くよりも圧倒的にシンプルだ。
フォーム系疑似クラス、バリデーションを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だけで自動入力されたフィールドをスタイリングできる貴重な手段である。パスワードマネージャーによる自動入力を視覚的に識別したい場合に実用的だ。
JavaScriptで同等の処理を実装する場合、checkValidity()メソッドやValidityStateオブジェクトを使うことになる。フォーム送信時に全体を検証するケースではJavaScriptが適しているが、入力中のリアルタイムフィードバックはCSSの疑似クラスに任せるほうが合理的だ。
メディア要素疑似クラス、動画と音声の状態をスタイリングする

HTML5の<audio>要素や<video>要素は、これまでJavaScriptで状態を監視しなければカスタムコントロールを作成できなかった。しかし、CSSのメディア要素疑似クラスが整備されつつあり、状況は変わりつつある。これらの疑似クラスはInterop 2026の対象にもなっており、ブラウザ間の相互運用性の向上が期待されている。
:volume-lockedは特に興味深い。JavaScriptで音量ロックを検出するには、ダミーのvideo要素を生成してvolumeを設定し、その値が反映されたかどうかを確認するという回りくどい方法が必要になる。CSSなら:volume-locked疑似クラスひとつで完結する。ブラウザ側の制約をCSSが抽象化してくれる好例だ。
インタラクティブ要素疑似クラス、ポップオーバーとダイアログの制御

近年HTMLに追加された<dialog>要素やポップオーバー機能は、CSSの疑似クラスと組み合わせることで真価を発揮する。:popover-open、:open、:modal、:fullscreenといった疑似クラスは、JavaScriptのtoggleイベントに頼らずにUIの状態をスタイリングできる。
JavaScriptで同様の処理を書く場合、toggleイベントを監視してから要素のopenプロパティをチェックする2段階の処理が必要になる。CSSの疑似クラスなら、スタイルシート内で直感的に記述できる。モーダルダイアログが開いているときに背景を暗くする処理も、:modal疑似クラスと::backdrop疑似要素の組み合わせで表現可能だ。
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;
}この流れは、従来の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のイベントリスナーなしで実装できる可能性がある。
この仕様が実用化されれば、CSSのみで完結するUIコンポーネントの幅は大幅に広がるだろう。ただし、Carlo Daniele氏自身も記事内で触れているように、仕様は現在編集中であり、今後のドラフトで構成が大きく変わる可能性がある。現時点では構想段階の提案として捉えておくのが適切だ。
この記事のポイント
- CSS疑似クラスはJavaScriptイベントの代替ではなく、状態を監視する独自のレイヤーとして進化している
- :hoverや:focusのような基本疑似クラスから、:autofillや:volume-lockedのような新しい疑似クラスまで、対応範囲は拡大中
- メディア要素疑似クラスはInterop 2026の対象であり、ブラウザ間の相互運用性が今後向上する
- event-trigger仕様はCSSに真のイベントリスナーをもたらす提案だが、現時点では未実装であり将来の動向に注目すべき
- CSSとJavaScriptは競合するものではなく、適材適所で組み合わせることで効率的なUI開発が可能になる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

AWS Certificate ManagerがACME対応、TLS証明書の自動更新を実現
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 をはじめとする多数の認証局が採用している。
このデモで示すように、ACME プロトコルを利用すると証明書ライフサイクルから人手を排除できる。AWS が ACME エンドポイントをマネージドサービスとして提供することで、利用者は証明書発行インフラの運用負荷からも解放される。
Amazon Trust Services による証明書発行
ACM が ACME 経由で発行するのは、Amazon Trust Services(ATS)を認証局とする公開証明書だ。ATS のルート証明書は主要なブラウザおよび OS にデフォルトで信頼されているため、発行された証明書は即座に本番環境で利用できる。
証明書の鍵タイプは ECDSA P-256 がデフォルトだが、RSA 2048 や ECDSA P-384 も選択可能だ。クライアント側の要件に合わせて設定できる柔軟性を持ちつつ、デフォルトではより高速でセキュアな ECDSA が推奨されている。
ACME エンドポイントの設定とドメイン検証の仕組み

ACM の ACME 対応で最も特徴的なのは、ドメイン検証を PKI 管理者がエンドポイントレベルで一括実施する点だ。一般的な ACME 環境では、証明書を必要とするクライアントごとに DNS レコードの設定権限が必要になる。これに対して ACM の方式では、管理者がエンドポイント作成時にドメインを検証し、以後の証明書リクエストはそのエンドポイントが管理する。
エンドポイントの作成手順
ACM コンソールの「ACME 証明書」ページからエンドポイントを作成する。設定項目は以下の通りだ。
- エンドポイント名(任意の識別名)
- エンドポイントタイプ(Public を選択)
- 証明書タイプ(Public を選択)
- 鍵タイプ(ECDSA P-256 がデフォルト)
- ドメイン名(証明書を発行する対象ドメイン)
- ドメインスコープ(厳密なドメイン、サブドメイン、ワイルドカードの許可設定)
ドメインスコープの設定はガバナンス上とくに重要だ。Exact domain(完全一致ドメイン)だけを許可すれば、サブドメインやワイルドカード証明書の発行を防げる。たとえば本番系のエンドポイントでは Exact domain と Subdomains のみを有効化し、Wildcards は無効にすることで、証明書の発行範囲を厳格に制限できる。
エンドポイント作成後、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 単体で証明書管理から監査、予防までをカバーできることを示している。従来は外部の認証局と 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 料金体系に準じる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

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

Autoptimize の「JavaScript コードを最適化」は、複数の JavaScript ファイルを1つに集約し、不要な空白やコメントを削除する「縮小(ミニファイ)」を施す機能だ。加えて、読み込みタイミングをずらす「遅延読み込み」や「非同期読み込み」も合わせて適用される。
ドロップダウンメニューは、マウスのホバーやクリックを検知してサブメニューを表示する仕組みで、内部では jQuery やテーマ独自の JavaScript が複数連携して動作する。最適化によってこれらのスクリプトの実行順序が入れ替わったり、縮小処理中に特定の構文が破損したりすると、メニューを開くイベントが発火しなくなる。
特定のページだけで発生する仕組み
トップページや一部の内部ページでは正常に動き、キャリアページや特定の投稿ページだけでメニューが壊れる場合、落ちているのは集約後の順序問題であることが多い。ページごとに読み込まれるスクリプトの組み合わせが微妙に異なるため、特定の構成でのみ実行順序の破綻が表面化する。
jQuery 依存のメニューは特に影響を受けやすい
多くの WordPress テーマはメニューの開閉に jQuery を使う。Autoptimize の標準設定では jQuery も他のスクリプトと一緒に集約されるが、jQuery は他のスクリプトより先に読み込まれなければならない。集約順序が変わって jQuery が後回しになると、$ is not defined や jQuery is not defined といったエラーが発生し、メニュー全体が沈黙する。
原因となる JavaScript ファイルを特定する手順
闇雲に除外設定を増やすのは避けたい。まずはブラウザの開発者ツールでエラーの出どころを確認し、ピンポイントで除外するファイルを決める。
autoptimize_xxxxx.js やテーマの navigation.js)を記録するwp-content/themes/テーマ名/js/... 等)を特定するエラーメッセージが「jQuery is not defined」であれば、jQuery の読み込み順がずれている。テーマ名や「navigation」「menu」を含むファイル名が表示されたら、そのファイルが縮小によって破損している可能性が高い。
エラーが出ない場合の切り分け方
コンソールにエラーが出ていないのにメニューが動かないケースもある。この場合は「Network」タブで autoptimize_xxxxx.js のレスポンスを確認し、途中で切れていないか、スクリプトの末尾が正常かを調べる。また、Autoptimize の設定で「JavaScript コードを最適化」だけをオンにし、「JavaScript を集約する」をオフにして症状が変わるかも試すと、問題の絞り込みが進む。
Autoptimize の除外設定でメニューを修復する
原因ファイルが特定できたら、Autoptimize の設定画面で除外リストに追加する。除外されたファイルは最適化の対象外となり、元の順序で単独で読み込まれるため、競合が解消する。
navigation.js と jquery.js を追加除外設定の具体的な入力方法
WordPress 管理画面の「設定」→「Autoptimize」→「JavaScript オプション」を開く。「JavaScript コードを最適化」が有効になっている状態で、その直下にある「除外するスクリプト」欄に、カンマ区切りでファイル名を入力する。
入力例を以下に示す。実際のファイル名は、サイトのテーマやプラグイン構成によって異なる。
jquery.js、 jQuery 本体jquery.min.js、 縮小版の jQuerynavigation.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 キャッシュとブラウザキャッシュをクリアする
- 「縮小のみ」「非同期読み込みオフ」など、最適化の段階を調整することでも解決できる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Cloudflare Monetization Gateway発表、x402でAIエージェントに従量課金
広告型モデルの限界とAIエージェント向け従量課金

2026年7月1日、CloudflareはMonetization Gatewayを発表した。HTTPの402ステータスコードを拡張したオープンプロトコル「x402」を基盤に、ウェブ上のあらゆるリソースに対して従量課金を適用できる仕組みである。保護対象はウェブページ、データセット、API、MCPツールにおよび、代理店や大規模言語モデルが自律的に支払う時代を見据えている。
背景にはウェブビジネスモデルの構造変化がある。30年にわたり、コンテンツは広告や月額課金で収益化されてきた。しかしAIエージェントが人間に代わって情報を消費するようになると、バナー広告をクリックすることも、毎月のサブスクリプションを維持することもない。エージェントは必要なデータを一度取得すれば、数十回、数千回と繰り返しアクセスし始める。Cloudflareの発表資料によると、AIクローラーのリクエスト数は、そこからサイトへ誘導される訪問者1人あたり数百~数万回に達しているという。
従来のAPI従量課金は既存ユーザー向けに限定され、サブセント単位の少額決済には向かなかった。クレジットカードの手数料が取引額を上回るためだ。ここでCloudflareが着目したのが、ステーブルコインによる一瞬の決済である。Monetization Gatewayは、支払い検証と流量制御をエッジで完結させ、オリジンサーバーに過剰な負荷をかけずに課金を実現する。
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はHTTPのステータスコード「402 Payment Required」を実際に活用するオープンプロトコルである。この規格はCloudflareがx402 Foundationのもとで25以上の業界リーダーと共同開発を進めている。従来の402は予約状態にあり、実際の決済フローには使われていなかった。
x402のやりとりは単純だ。クライアントが支払い必須のリソースをリクエストすると、サーバーは402 Payment Requiredとともに価格、受け入れ可能な通貨、支払い先を含む小さなペイロードを返す。クライアントは支払いを実行し、支払い証明を添えてリクエストを再送する。ファシリテーター(検証者)が証明を確認し、オリジンサーバーが最終的にリソースを返す。すべてが通常のHTTPリクエスト/レスポンスの中で完了し、決済ページへのリダイレクトも個別の決済API呼び出しも発生しない。
x402の利点は2つある。1つは最小単位がセント未満まで刻めること。プロトコルのオーバーヘッドが極めて低く、取引額が支払いコストを下回る逆転を防げる。もう1つは、買い手が売り手のアカウントを事前に取得する必要がないことだ。支払い自体が資格情報として機能するため、サインアップやAPIキー発行なしに取引が成立する。
サブセント決済と一瞬の決済
ステーブルコインを使う決済は、現在の主要な決済レールでは実現できなかったスピードと低コストを両立する。Cloudflareはサブセカンド(1秒未満)の決済を目標に掲げている。エージェントが数セントのデータを購入するために数ドルの手数料と数日の決済期間を待つ必要はなくなる。この速度と低コストが、AI時代の大量のマイクロペイメントを支える。
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との連携も予定している。エージェントに認証を求め、既存のアカウントに対して従量課金を適用する柔軟性を提供する方針だ。これにより、完全な匿名取引だけでなく、信頼関係に基づく課金も選択できるようになる。
売り手にとっての変化
Monetization Gatewayを利用する売り手は、蓄積したステーブルコインをそのまま別の取引に使うことも、銀行口座で法定通貨に換金することもできる。Cloudflareが発表した構想では、支払い検証はすべてエッジで完結し、オリジンには課金ルールと実際の収益だけが残る。
これはAPIプロバイダーにとって、販売可能市場を拡大する直接的な手段になる。AIエージェントはリソースを要求し、価格を提示され、支払い、結果を得る。サインアップもAPIキーも事前の関係も必要ない。Cloudflareは、いつでも買い手の認証や既存アカウントとの紐付けを追加できる柔軟性を残している。
この記事のポイント
- CloudflareがHTTP 402を利用した従量課金プロトコルx402を実用化。Monetization Gatewayによりあらゆるウェブリソースへの課金が可能に
- AIエージェントが大量にコンテンツを消費する時代、広告に依存しない収益モデルとしてマイクロペイメントが鍵を握る
- ステーブルコインによるサブセカンド決済で、サブセント単位の取引でも手数料が収益を上回らない
- 課金ルールはコードで管理でき、売り手は買い手のオンボーディングや請求システムを構築する必要がない
- Web Bot Authとの連携や変動価格設定など、エージェント経済向けの拡張機能が計画されている

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

CSS Gap装飾とrandom()関数、select要素のサイズ制御の最新情報
2026年6月末、CSS-Tricksの定期コラム「What’s !important」第14回が更新された。ギャップ装飾、random()関数、select要素のサイズ制御、モダンテーマ構築など、今後のWeb制作に直結するトピックが盛り込まれている。
ブラウザの安定版に大きな機能追加がなかった時期にも関わらず、開発者コミュニティの実験や標準化の進展は目を見張るものがある。本記事では、これらの最新情報を実務の視点で整理し、各機能の具体的な活用法を示す。
ギャップ装飾とランダム関数 ー 隙間を彩るCSSの新表現

CSS Gap装飾でグリッドの隙間をデザインする
FlexboxやGridレイアウトでおなじみのgapプロパティは、要素間に一定の間隔を生み出す。これまではその隙間自体を装飾する手段がなかったが、CSS Gap Decorationの概念によって新たな表現が可能になった。Temani Afif氏がMaster.devで公開した記事では、gap部分に背景色やボーダー、画像を配置する方法が詳しく解説されている。
上記の例では、flexコンテナに背景色を設定することで、gapが作り出すスペースに色が適用されている。Temani Afif氏の記事では、疑似要素やボーダーを用いて、より複雑な装飾を実現する手法が紹介されており、実務での利用価値が高い。
CSS random()がもたらすランダムな表現
CSSのrandom()関数は、スタイルシートに乱数を導入する試験的な機能だ。現時点ではSafariのみが対応しており、他のブラウザでは動作しない。Polypaneのブログでは、この関数を活用した多彩な実験が公開されている。
Polypaneのデモでは、桜の花びらが舞い散るアニメーションやポラロイド写真の不揃いなスタックなどが実装されており、random()の実用性を感じさせる。ブラウザの対応が進めば、よりナチュラルなUI演出に活用されるだろう。
フォーム要素の可変サイズと動的テーマ構築

field-sizing: contentでselectの幅を動的に調整
Manuel Matuzović氏の記事で取り上げられたfield-sizing: contentは、フォームの見た目を柔軟にする新しいCSSプロパティだ。特に<select>要素に適用すると、選択された<option>のテキスト幅に合わせて自動的にサイズが変わる。Firefox 152のリリースにより、この機能はBaselineに加わり、主要ブラウザで使用可能になった。
なお、size属性を併用してスクロール可能なリストボックスにした場合、field-sizing: contentがsizeを上書きし、すべてのオプションを表示するようになる点には注意が必要だ。
モダンCSSテーマ構築の新たなスタンダード
GoogleのUna Kravets氏は、light-dark()関数やcontrast-color()関数、@property、@container style()を組み合わせた新しいテーマ構築手法を解説した。これらの機能はいずれもBaselineに到達しており、モダンブラウザで広く利用できる。
見出しテキスト
本文のテキストがここに入ります。背景は白、テキストは濃い色。
見出しテキスト
本文のテキストがここに入ります。背景は暗色、テキストは明るい色。
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といった遊び心のあるプロジェクトは、技術の可能性を広げ、コミュニティの活力を象徴している

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

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

Amazonが、自社で商品の発送を行うFBM(フルフィルメント・バイ・マーチャント)販売者に対する監視を強化している。ドイツでは定時配達率(OTDR)90%以上の維持が求められ、基準を下回った場合のペナルティも明確化された。イギリスでも同様の厳格化が進む。この動きはフランス、スペイン、イタリアにも波及しており、欧州のAmazonセラーにとって配送品質の向上が待ったなしの課題となっている。
日本国内でAmazon販売を展開する事業者にとっても、この欧州の政策変更は対岸の火事ではない。グローバルで足並みを揃えるAmazonのポリシーは、いずれ日本市場にも適用される可能性が高く、早めの対策が求められる。ここでは変更点の詳細と、販売者が取るべき具体的な対応策を解説する。
配送品質を担保する主体が販売者からAmazonへと移行しつつある状況を示している。FBM販売者は、単に発送するだけでなく、配送プロセス全体のパフォーマンスを数値で証明する責任を負うことになる。
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セラーにもアナウンスされている。
このスケジュールから、Amazonが個人消費者向けと企業向けの両面で配送品質を底上げしようとする意図が明確に読み取れる。特に法人向けは、指定された営業時間内への配達が求められるため、配送業者の選定や在庫管理により一層の正確性が要求される。
イギリス市場でも監視が強化、猶予はここまで
イギリスでは、90%のOTDR要件自体は既に存在していた。しかし、これまでは形骸化していた側面があり、2026年9月からはより厳格に執行されることになる。移行期間は終わり、抜け道は塞がれつつある。
Amazonがドイツとイギリスという欧州最大の2市場で今回のルール変更を同時に進めることは、両市場でより正確な配送約束を表示し、セラーのコンバージョン率を高める狙いがあるというのが、Amazon自身の説明だ。
ハンドリングタイムの自動調整、販売者の甘えは許されない

配送要件の厳格化と並行して、ハンドリングタイムの設定ルールも大きく変わる。ハンドリングタイムとは、注文を受けてから商品を発送するまでの準備期間を指す。昨年も販売者間で議論を呼んだ問題だが、Amazonはここに再度メスを入れた。
デフォルトの2日間設定が1日へ自動短縮
2026年7月15日以降、アカウントのデフォルトのハンドリングタイムが2日間に設定されている場合、自動的に1日に短縮される。これまで多くのセラーが「念のため」と長めに設定していたバッファを、Amazonは認めなくなった。
実績ベースで自動調整される仕組み
さらに踏み込んだ施策として、9月1日からは自動ハンドリングタイム機能が本格的に稼働する。実際の発送実績よりも1日以上長くハンドリングタイムを設定している場合、その設定は30日後に自動的に短縮される。ステータス変更や再設定などの回避策は用をなさない。Amazonの説明を借りるなら「実際のパフォーマンスを反映した、より迅速な配送約束の提示を容易にする」ための仕組みだ。
このルール変更は、良心的なセラーにとっては強力な武器となる。配送品質の低い競合がふるい落とされることで、自社の「迅速な配送」という強みが際立つからだ。逆に、発送業務が属人的で安定しない事業者は、これまで以上に厳しい立場に置かれる。
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サイトにおける「配送品質」の捉え方

Amazonだけの話ではない。この厳格化の波は、顧客の配送に対する期待値そのものを引き上げる。Amazonで「翌日配達が当たり前」という体験をした顧客が、あなたの自社ECサイトで買い物をした時、「配送が遅い」と感じれば二度と戻ってこない可能性がある。
WooCommerceなどで自社ECを運営している事業者は、カート落ち対策として配送スピードとコストのバランスを再考すべきだ。具体的には、一定金額以上の購入で送料無料かつ翌日配送を確約する、配送ステータスを自動通知するプラグインを導入するといった施策が有効になる。Amazonの基準は、もはや業界のデファクトスタンダードになりつつある。
この記事のポイント
- FBM販売者の定時配達率(OTDR)が90%以上必須となり、基準未達で出品停止の可能性
- 2026年9月1日から施行、B2B注文へも同様の厳格化が段階的に拡大
- ハンドリングタイムは実績を基に自動調整され、販売者による水増し設定が不可能に
- 配送品質の改善はコンバージョン率向上に直結するが、基準を下回れば販売権を失うリスクも
- 自社ECサイトでもAmazon並の配送体験が求められる時代へ、早急な業務フロー見直しが必要

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

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

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負荷の高い処理に最適

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Prisma Compute vs Vercel、料金比較でわかるコスト差の全容
TypeScriptアプリのホスティング先を選ぶとき、Prisma ComputeとVercelが候補に挙がる。両者とも従量課金でゼロスケールするため、アイドル時のコストはかからない。だが料金単価と課金項目の設計思想が異なり、同じ負荷でも請求額に2倍以上の開きが出るケースがある。Prisma Computeはパブリックベータ中で現在無料、ここで示す料金は将来の本番適用が予定されている参考値だ。
本記事ではPrisma Blogが2026年7月1日に公開した料金比較をもとに、各メーターの単価差、20Mリクエストの実ワークロード試算、そしてなぜ同じ負荷で請求が変わるのかを掘り下げる。Vercelの価格にまつわる開発者の声も紹介し、自社のアプリに当てはめるときの判断材料を提供する。
料金体系の基本比較

両サービスともリクエスト数、メモリ消費、CPU時間、外向き帯域を課金対象とするが、単価には明確な差がある。Prisma Computeの価格はベータ版後の予定値であり、変更の可能性がある点に注意が必要だ。
リクエスト単価ではVercelが優位だが、サーバーワークの大半を占めるメモリとCPU、そして帯域ではPrisma Computeが大幅に低い単価を提示している。さらに開発者シートやエッジリクエストといったワークフローコストがPrismaには存在しない点が、後々の請求に大きく響く。
実ワークロードでのコスト試算

月間2000万リクエスト、常時2GBメモリ使用、実CPU 300vCPU時間、外向きトラフィック2TB、開発者1名という条件で両者を比較する。Vercel Proには1TBの帯域無料枠が含まれる点を織り込んだ試算だ。
メモリ (1460 GB時) $8.76
CPU (300時間) $19.20
外向き帯域 (2TB) $50.00
シート (1名) $0.00
合計 ~$98
メモリ (1460 GB時) $15.48
CPU (300時間) $38.40
外向き帯域 (2TB中1TB無料扱い) $150.00
シート (1名) $20.00
合計 ~$236
この試算ではエッジリクエストを除外し、開発者1名で固定している。実際にはチーム人数が増えるほどVercelのシート料金が積み上がり、格差はさらに拡大する。一方で外向き帯域がごく小さく、リクエスト単価の差が支配的になるシナリオでは両者の総額は接近する。
料金差を生む構造的要因

なぜ同じ負荷でこれほどの差がつくのか。理由は課金モデルの設計思想とアーキテクチャの2軸に集約される。
ワークとワークフローの分離
ホスティング料金は「アプリが稼働中に行う実作業(ワーク)」と「デプロイやプレビューなど開発プロセス(ワークフロー)」に分けられる。Prisma Computeはリクエスト、メモリ、CPU、帯域というワークのみに課金し、開発者シートやエッジリクエストといったワークフロー項目は一切請求しない。Vercelはワークに加え、シート料金とエッジリクエストをワークフローとして課金する。
Prisma Compute 課金
Vercel 課金
Prisma Compute 無料
Vercel 課金
Prisma Blogの著者Martin Janse van Rensburg氏は、AIエージェントがコードの変更→テスト→プレビューを繰り返す開発スタイルでは、Vercelのワークフロー課金が急速に膨らむリスクを指摘している。一方PrismaではデプロイのたびにイミュータブルなバージョンとプレビューURLが作られるが、それらに追加料金は発生しない。
データベース隣接配置によるエグレス抑制
Prisma Computeのアーキテクチャ上の特徴として、Prisma Postgresと同じインフラ上で動作する点が挙げられる。通常、アプリケーションサーバーとデータベースが別ベンダーや別リージョンにある場合、両者間の通信が外向き帯域として課金対象になる。Prisma Computeはデータベースとの通信が同一基盤内で完結するため、こうした隠れエグレスコストが発生しない。
アプリ-DB間通信が外向き帯域として課金
同一基盤内で通信が完結。エグレスコストなし
データベースとの通信量が多いアプリほど、この差は請求額に明確に現れる。大量のクエリを発行する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ドル請求された事例も共有されている。
Fluid Computeを有効化 → 請求が50%減少
フロントエンドのみの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はまだベータ版であり、本番利用のフィードバックを踏まえた判断が今後必要になる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

大文字見出しがコンバージョンを下げる、CROプロが警告
ランディングページの見出しをすべて大文字にすることは、視覚的なインパクトを与える常套手段と思われている。しかし、CRO(コンバージョン率最適化)の専門家Nate Lagos氏は、それが逆効果になる可能性を指摘する。実際のA/Bテストでは、大文字をやめて各単語の先頭だけ大文字にしたところ、コンバージョン率が25%も向上した事例が報告されている。
これは、多くのECサイト担当者が見過ごしがちな落とし穴だ。本記事では、Practical EcommerceのポッドキャストでLagos氏が語ったテスト結果と、ボトムズアップアプローチに基づくCRO戦略の核心を解説する。
大文字見出しがコンバージョンを下げる意外な事実

Lagos氏が実践するCROは「ボトムズアップテスト」と呼ばれる。購入ボタンや商品説明文といった、コンバージョンに直結する部分からコピーを検証していく手法だ。トップページや認知向けの広告文よりも、まず「買うか離脱するか」の瀬戸際にある箇所を最適化する。
このアプローチの過程で浮かび上がったのが、大文字見出しの問題だ。Lagos氏はX(旧Twitter)で読んだアイデアをきっかけに、あるクライアントのランディングページでテストを実施した。それまですべて大文字だった見出しを、各単語の先頭だけ大文字にするパターンに変更したところ、驚くべき結果が出た。
25%のコンバージョン向上を実現したA/Bテスト
テスト結果は明確だった。大文字をやめたランディングページでは、コンバージョン率が25%向上した。しかも、CPA(顧客獲得単価)も低下した。トラフィックの多いページだったため、この変化はビジネスにとって大きなインパクトをもたらした。
Lagos氏によれば、これは「可読性」の問題だ。大文字だけのテキストは、単語の形状が均一になり、脳が素早く認識しにくくなる。結果として、ユーザーは読む前に離脱してしまう。見出しのフォントサイズを小さくした場合にも同様の傾向が見られ、読みやすさが購買行動に直結することが浮き彫りになった。
ボタンテキストへの応用は未検証
ただし、Lagos氏はボタンに大文字を使うことの影響まではテストしていない。CTAボタンでは大文字が効果的なケースもあるかもしれない。今回の発見は、あくまで見出しや本文レベルのテキストブロックに限定したものだ。サイトのコピーを最適化する際は、見出しから着手するのが良いだろう。
ボトムズアップアプローチの実践

Lagos氏が提唱するボトムズアップテストは、従来の広告戦略の考え方をひっくり返す。多くのマーケターは、まず認知獲得のためのトップファネルから手を付ける。しかし、購入から遠い場所にあるメッセージは、実際の購買動機とは無関係なケースが多い。だからこそ、まずは購入ボタンの近くから最適化するのだ。
購入ボタン直近のコピーを最適化する
具体的には、商品詳細ページの見出し、説明文、価格表示、そしてCTAボタンの周辺テキストをテストする。Lagos氏はOriginal Grain在籍時代、この手法で5年間にわたり収益をほぼ5倍に伸ばした実績を持つ。腕時計という「実用性が低い」商材でこれだけの成果を出せたのは、買い手の感情に響くコピーを突き詰めたからだ。
このプロセスを経ることで、「顧客が本当に求めているもの」が明確になる。腕時計の例では、時刻を知るためではなく「地位や達成感の象徴」としての価値が見えてきた。こうした深層心理を突いたコピーが、結果的にコンバージョン率や平均注文単価を押し上げた。
市場飽和を打破するターゲット拡大戦略

コアオーディエンスへのリーチが頭打ちになったブランドが次に取るべき打ち手は、商品を軸にしたターゲットの拡大だ。Lagos氏は「常に『他に誰に売れるか』を問い続けろ」と語る。
男性向け商品を女性に売る方法
Original Grainでの実例が示唆に富む。当初、同ブランドは男性向けにメッセージを打っていた。しかし、顧客データを分析したところ、実は約半数の購入者が女性だった。そこでLagos氏は女性向けのコピーライティングに注力し、最終的に顧客の80%を女性が占めるまでに至った。
成功の鍵は「ギフト需要」の掘り起こしだった。Practical EcommerceのインタビューでLagos氏が明かしたところによると、女性顧客は「夫やボーイフレンドへの感謝を示したい」という動機で腕時計を購入していた。特に父の日やクリスマス前の30〜45日間は、ギフト向けのメッセージに全面切り替え、年間を通じてはメインサイトを男性向けに戻すという柔軟な運用を行った。
女性向けマーケティングを成功させる鉄則
Lagos氏が強調するのは「女性の顧客を理解するには女性を雇え」というシンプルな原則だ。彼自身、コピーライターのSarah Levinger氏を迎え入れ、女性視点のメッセージ構築を一から学んだ。自社にない視点を取り入れることは、新しい市場を開拓するための最短ルートになり得る。
この事例は、商品そのものを変えずに、メッセージの受け手を変えるだけで大きな成長が可能なことを示している。自社のデータを見直し、思いがけない顧客層がいないかを探る価値は大きい。
CROテストを成功に導くツールと手法

Lagos氏がA/Bテストの実施に用いているのは、Intelligemsというツールだ。テストの信頼性を担保するため、統計的有意性は「対照群に勝つ確率が80%以上」を基準にしている。サイト訪問者数が数万から数十万、注文数が数千件に達するボリュームでなければ、意味のある結果は得られない。
ヒートマップで読者の行動を可視化
テストすべき箇所を特定するには、ヒートマップツールが有効だ。ユーザーが実際にどこを読んでいるのか、どこで離脱しているのかを可視化することで、コピー改善のインパクトが大きいエリアを見極められる。Lagos氏の経験では、ランディングページや商品ページの冒頭ブロックが最もレバレッジの効く領域だという。
A/Bテストは一度きりではなく、継続的な反復が前提となる。小さな改善を積み重ねることで、CVRやAOV(平均注文単価)、RPV(訪問単価)といった重要指標を持続的に押し上げていく。大文字見出しの回避は、その第一歩として取り組みやすい改善策と言えるだろう。
この記事のポイント
- ランディングページの大文字見出しをやめ、各単語の先頭だけ大文字にすることでCVRが25%向上した事例がある
- ボトムズアップテストでは、購入ボタン近くのコピーから最適化し、購買動機を明確にする
- A/BテストはIntelligems等のツールを用い、統計的有意性を確保できる十分なボリュームで実施する
- ターゲット拡大では、女性へのギフト訴求が男性向けブランドの顧客基盤を劇的に変える可能性がある
- 改善は継続的な反復が鍵。大文字見出しの見直しは、今日から始められる施策の一つだ

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験





