
CSS writing-mode完全ガイド、縦書きと横書きを自在に操る方法
writing-modeとは? 基本構文と初期値

writing-modeプロパティは、テキストの行を水平方向に配置するか垂直方向に配置するか、そしてブロックと行がどの方向に進むかを設定する。主に日本語や中国語、韓国語など、縦書きが使われる言語で役立つプロパティだ。英語圏では、見出しをブロックテキストの中に縦に配置するような、美的な理由で使われることが多い。
基本的な構文
.element {
writing-mode: vertical-rl;
}writing-modeプロパティは、以下の5つのキーワード値を受け取る。
writing-mode: horizontal-tb | vertical-rl | vertical-lr | sideways-rl | sideways-lr;- 初期値: horizontal-tb
- 適用対象: テーブル行グループ、テーブル列グループ、テーブル行、テーブル列、ルビベースコンテナ、ルビ注釈コンテナを除くすべての要素
- 継承: あり
- アニメーションの種類: アニメーション不可
各値は2つの部分から成り立っている。最初の部分はテキストが水平(horizontal)か垂直(vertical)かを示し、2番目の部分は行とブロックが進む方向を示す。tbは上から下(top-to-bottom)、rlは右から左(right-to-left)、lrは左から右(left-to-right)を意味する。
初期値と継承のポイント
writing-modeの初期値はhorizontal-tbだ。つまり、明示的に指定しない限り、Webページのテキストは水平方向に左から右へ流れ、行は上から下へ積み重なる。このプロパティは継承されるため、親要素に設定すれば子要素にも自動的に適用される。ただし、table関連の要素やrubyコンテナには直接適用されない点に注意が必要だ。
プロパティがアニメーション不可であることも覚えておきたい。writing-modeを動的に切り替えると、レイアウト全体が再計算されるため、スムーズなトランジションは期待できない。状態の切り替えは即座に行われる。
各値の詳細と使用例

writing-modeプロパティには5つの値が存在する。それぞれの挙動を詳しく見ていこう。
horizontal-tb(デフォルト)
テキストは水平方向に左から右へ流れる。行とブロックは上から下へ進行する。これがWebページの標準的な表示だ。
.default-text {
writing-mode: horizontal-tb;
}この値は、特に指定しなくてもブラウザが適用する初期値であるため、通常は明示的に書く必要はない。ただし、上位の要素で別のwriting-modeが設定されている場合に、意図的に水平書きに戻す目的で使われることがある。
vertical-rl(縦書き右から左)
テキストは垂直方向に配置され、行やブロックは右から左へ進む。新しい行は前の行の左側に配置される。主に日本語の縦書きで使われる値だ。
.vertical-text {
writing-mode: vertical-rl;
}上のデモでは、右側のボックスから左へテキストが進むvertical-rlの特徴が分かる。日本の書籍や新聞の縦書きと同じ方向だ。
vertical-lr(縦書き左から右)
テキストは垂直方向に配置されるが、行は左から右へ進む。新しい行は前の行の右側に追加される。モンゴル語の縦書きなどで使われる。
.vertical-left-right {
writing-mode: vertical-lr;
}vertical-rlと比べると、左側の行から読み始め、徐々に右へ進む点が異なる。日本ではあまり馴染みがないが、国際的なWebサイトを構築する際に考慮すべき書字方向だ。
sideways-rl と sideways-lr
sideways-rlとsideways-lrは、テキストを縦書きにしつつ、文字の方向を水平書きの慣習に沿って回転させる。sideways-rlでは文字が右を向き、sideways-lrでは左を向く。
これらの値は、主に表の見出しや、狭いスペースに横向きの文字を縦に並べたい場合に使われる。ただし、ブラウザの実装状況にばらつきがあり、すべての環境で意図した表示になるとは限らない。使用前にブラウザの対応状況を確認する必要がある。
論理軸とCSSレイアウトの関係

writing-modeプロパティは、単にテキストの向きを変えるだけではない。より根本的に、CSSがコンテンツをレイアウトする際に使う「ブロック方向」と「インライン方向」の軸を確立する。
インライン軸とブロック軸
インライン軸は、行の中でコンテンツが流れる方向だ。水平書きでは横方向、縦書きでは縦方向になる。ブロック軸は、ブロックや行が積み重なる方向で、水平書きでは縦方向、縦書きでは横方向になる。
行が積み重なる
↓
テキストの流れ
↓
writing-modeが変わると、これらの軸の物理的な方向が入れ替わる。デフォルトのhorizontal-tbではインライン軸は水平、ブロック軸は垂直だが、vertical-rlではインライン軸が垂直に、ブロック軸が水平になる。
論理プロパティの活用
CSSのモダンレイアウトであるFlexboxやGrid、位置調整のプロパティは、この論理軸の考え方に基づいている。物理的な方向(top, right, bottom, left)に縛られず、start, end, block, inlineといった論理的方向で記述するため、writing-modeが変わってもレイアウトが適応できる。
.element {
inline-size: 20rem;
block-size: 10rem;
margin-inline-start: 1rem;
padding-block-end: 0.5rem;
}inline-sizeは、インライン軸に沿った要素のサイズ(横書きではwidth、縦書きではheightに相当)block-sizeは、ブロック軸に沿ったサイズ(横書きではheight、縦書きではwidthに相当)margin-inline-startは、インライン軸の開始側のマージン(横書きではmargin-left、縦書きではmargin-topに相当)padding-block-endは、ブロック軸の終了側のパディング(横書きではpadding-bottom、縦書きではpadding-leftに相当)
これらの論理プロパティを使うことで、writing-modeを変更してもCSSを書き直す必要がなくなる。複数言語に対応するWebサイトを構築する際に、特に強力な武器となる。
FlexboxとGridへの影響
Flexboxでは、flex-direction: row がインライン軸に沿ってアイテムを配置する。writing-modeがhorizontal-tbなら横並び、vertical-rlなら縦並びになる。同様に、flex-direction: column はブロック軸に沿って積み重ねる。
Gridもwriting-modeに従う。グリッドの行と列は、物理的な上下左右に固定されているわけではなく、インライン軸とブロック軸に応じて自動的に方向が変わる。そのため、縦書きレイアウトでグリッドを使用する際も、特別な指定は不要だ。
位置調整プロパティ(align-items や justify-items など)も同様に、ブロック軸とインライン軸を基準に動作する。このモデルを理解しておけば、縦書きレイアウトを作成しない場合でも、FlexboxやGridの挙動をより深く理解できる。物理的な方向に依存しない、柔軟なレイアウト設計が可能になる。
実践的なデモとブラウザ対応

writing-modeを使いこなすには、実際の挙動を確認するのが一番だ。ここでは言語や方向の設定を切り替えられるデモを用意した。ブラウザの対応状況も合わせて解説する。
インタラクティブなデモ
以下のデモでは、ドロップダウンから言語やwriting-modeの値、テキストの方向(directionプロパティ)を変更できる。テキストの表示だけでなく、コンテナとインライン・ブロック軸のインジケーターがどのように変化するかを観察してほしい。
言語セレクターは各スクリプトの典型的な値を設定するが、自由に上書きして実験できる。writing-modeがテキストの向きだけでなく、コンテナ全体とその内容物のフローにどう影響するかを確認しよう。
writing-modeを変更すると、単に文字の向きが変わるだけではない。テキストのフロー全体、ブロックの進行方向、インライン要素の並び方までもが再構成される。縦書きを導入する際は、レイアウト全体への影響を考慮する必要がある。
ブラウザの対応状況
writing-modeプロパティは、CSS Writing Modes Level 4 仕様で定義されており、主要なモダンブラウザで広く利用可能だ。Chrome、Firefox、Safari、Edgeのいずれも基本的な値をサポートしている。
ただし、sideways-rl と sideways-lr は実装状況にやや差がある。Firefoxではサポートされているが、Chrome系では部分的または未サポートの場合がある。使用する際は、Can I use などで最新の対応状況を確認することをおすすめする。
関連プロパティと注意点

writing-modeと密接に関連するプロパティがいくつかある。縦書きレイアウトを正確に制御するために、これらも合わせて理解しておきたい。
direction
.element { direction: rtl; }テキストの書字方向(左から右か、右から左か)を指定する。writing-modeがhorizontal-tbの場合、direction: rtl を指定すると、テキストは右から左へ流れる。アラビア語やヘブライ語など、右横書きの言語で使用される。writing-modeと組み合わせることで、より多様な言語に対応できる。
text-orientation
.element { text-orientation: mixed; }縦書きモードのときに、文字の向きを制御するプロパティだ。mixed(横文字は横向き、縦文字は縦向き)、upright(すべての文字を縦向き)、sideways(すべての文字を横向きに回転)などの値を取る。縦書きの中に英数字が混ざる場合の見た目を調整するのに役立つ。
unicode-bidi
.element { unicode-bidi: embed; }双方向テキスト(右から左と左から右の文字が混在する場合)の埋め込みレベルを制御する。directionプロパティの効果を適切に反映させるために、一緒に使われることが多い。
text-combine-upright
span { text-combine-upright: all; }縦書きの中で、複数の文字(主に2桁の数字など)を1文字分のスペースに水平に組み合わせて表示する。縦中横(たてちゅうよこ)と呼ばれる組版技法を実現するために使われる。
この記事のポイント
- writing-modeプロパティは、テキストの水平・垂直配置とブロックの進行方向を制御する
- 5つのキーワード値(horizontal-tb, vertical-rl, vertical-lr, sideways-rl, sideways-lr)があり、それぞれ異なる書字方向を実現する
- インライン軸とブロック軸の概念を理解することで、FlexboxやGridといったモダンレイアウトをより深く扱える
- 論理プロパティ(inline-size, block-size, margin-inline-start など)を使用すると、writing-modeの変更に強い柔軟なCSSを書ける
- 縦書きレイアウトは、日本語などの言語対応だけでなく、デザインのアクセントとしても活用できる

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

URLに特定の単語を含むリンクを一括でホームページに置換する方法
URL に特定の単語(例 sandwich)を含む全リンクを一括でホームページに置換するには、Search Regex プラグインか phpMyAdmin の正規表現置換を使う。単純な完全一致検索しかできないツールでは対処できないため、部分一致の条件を指定できる方法が必須になる。
なぜ通常の「Better Search Replace」では置換できないのか

「Better Search Replace」のような一般的なプラグインは、検索文字列とまったく同じ URL しか見つけられない。旧サイトから移管した際に「sandwich-f07abf」や「sandwich/xyz」のように末尾にランダムな文字列が付与されたリンクが数百件ある場合、完全一致で一つひとつ指定するのは現実的ではない。今回のように「URL の一部が特定のキーワードで、あとは異なる」パターンには、正規表現によるパターンマッチが必要になる。
Search Regex プラグインで部分一致 URL を一括置換する

Search Regex は、正規表現を使ってデータベース内の投稿やカスタムフィールド、オプションなどを検索・置換できるプラグインだ。ドライラン(事前確認)機能がなく直接置換が走るため、必ず事前にデータベース全体のバックアップを取る必要がある。
設定手順
http[^\s]*sandwich[^\s]* を入力/ を入力Search Regex では、検索対象のカラム(post_content、post_excerpt、guid など)やテーブルを選択できる。すべてにチェックを入れると想定外のレコードまで置換されることがあるため、最初は post_content だけに絞って実行し、結果を確認するのが安全だ。置換に成功した場合、変更の取り消しは手動で行う必要がある点を覚えておく。
検索パターンの正規表現解説
http[^\s]*sandwich[^\s]* は「http で始まり sandwich を含み空白文字が出るまでの連続した URL」を意味する。[^\s]* の部分で、sandwich の前後にどんな文字が並んでいても対象に含めることができる。これにより sandwich-f07abf も sandwich/xyz もすべて拾える。もしホームページではなく完全に削除したい場合は、置換後文字列を空欄にすればよいが、リンク切れを起こすよりもホームページへ誘導するほうが SEO 上も望ましい。
https://example.com/sandwich/xyz → 404
https://example.com/sandwich-f07abf → 404
https://example.com/ → ホームページ
https://example.com/ → ホームページ
phpMyAdmin でデータベースから直接置換する方法

より高度な操作として、phpMyAdmin を使う方法もある。phpMyAdmin はレンタルサーバーの管理画面からアクセスできる MySQL データベース操作ツールだ。検索機能で該当するレコードを洗い出したあと、SQL の UPDATE 文で一括置換する。
特定のキーワードを含むレコードを検索する
phpMyAdmin にログインし、WordPress のデータベースを選択する。「検索」タブでキーワード「sandwich」を入力し、全テーブルを対象に検索をかける。該当行が表示されるので、どのテーブルのどのカラムに URL が含まれているかを特定できる。
SQL で一括置換をかける
影響範囲を特定したら、次のような UPDATE 文を実行する。ここでも誤操作を防ぐため、必ず事前にバックアップを取る。
UPDATE wp_posts SET post_content =
REPLACE(post_content,
'https://example.com/sandwich-f07abf',
'/')
WHERE post_content LIKE '%sandwich%';ただし、この方法は完全一致の REPLACE 関数を使うため、ランダム文字列が多様な場合は検索文字列を動的に扱えない。代わりに REGEXP_REPLACE が使える MySQL 8.0 以降の環境、または MariaDB 10.0.5 以降なら、正規表現による置換が行える。
UPDATE wp_posts SET post_content =
REGEXP_REPLACE(post_content,
'https?://[^\s]*sandwich[^\s]*',
'/')
WHERE post_content REGEXP 'https?://[^\s]*sandwich[^\s]*';この SQL は、http または https で始まり sandwich を含み空白が出るまでの URL をすべて抜き出し、ホームページ(/)に置換する。データベース全体にわたって同様の処理が必要なら、postmeta や options テーブルなどにも同じ UPDATE 文を適用する。
置換前に必ず取るべき安全策

Search Regex も phpMyAdmin も、一度実行すると元に戻せない操作になる。必ず次の 3 つを行う。
- データベース全体のエクスポート(バックアップ)を取る
- 可能ならステージング環境で先にテストする
- 置換後はサイト全体を巡回し、表示崩れやリンク切れがないか確認する
ステージング環境が用意できない場合は、本番で実行する前に影響範囲を最小に絞る。Search Regex であれば、最初は post_content だけを対象にし、問題なければ他のカラムを追加していくと安全だ。
よくある質問
Search Regex と「Better Search Replace」はどう使い分ける?
完全に同じ文字列しか置換できないのが Better Search Replace で、部分一致や正規表現を使いたい場合は Search Regex になる。ただし Search Regex はドライランができないので、安全を重視するなら、まず Better Search Replace で置換できる部分を先に処理し、残った複雑なパターンだけを Search Regex で片付ける手順が堅実だ。
phpMyAdmin で誤って必要なデータまで置換してしまったら?
バックアップファイルをインポートして復元する。phpMyAdmin の「インポート」タブからエクスポートしておいた SQL ファイルを選択し実行すれば、置換前の状態に戻せる。バックアップを取らずに操作してしまった場合は、復元は極めて困難になるため、作業前のバックアップは必須だ。
置換後に画像や内部リンクが壊れていないか心配だ
リンクチェッカー系のプラグイン(Broken Link Checker など)を一時的に導入し、サイト全体のリンク切れをスキャンするとよい。置換してから数時間後に確認すれば、見落としがあっても早期に気づける。スキャン後は負荷を避けるため、プラグインを無効化しておく。
URL の一部に「sandwich」を含むが、それ以外の部分は維持したい場合は?
キャプチャグループ(丸括弧)を使う。たとえば sandwich より前のパスだけを残したいなら (https?://[^\s]*)sandwich[^\s]* とし、置換後文字列に $1 を指定する。置換の条件は柔軟に調整できるため、削除する範囲や残す範囲を細かく制御できる。
Search Regex の代わりに WP-CLI で置換できる?
WP-CLI が使える環境なら wp search-replace コマンドで正規表現を扱える。ただし部分一致のためには --regex オプションを使う必要があり、さらに複雑なパターンになる。コマンドラインに慣れている開発者向けの手段といえる。
この記事のポイント
- URL に特定の単語を含むリンクを一括置換するには正規表現が必須
- Search Regex プラグインで部分一致をパターン指定して置換できる
- phpMyAdmin の REGEXP_REPLACE でも同様の処理が可能
- いずれの方法でも事前のデータベースバックアップが最優先
- 置換後はリンク切れチェックでサイトの健全性を確認する

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Gemini 3.6 Flash登場、3.5 Flash-LiteとCyberも発表。AIエージェント開発の新定番へ
Google DeepMindは7月21日、AIエージェント開発の最前線を支える3つの新モデル、Gemini 3.6 Flash、3.5 Flash-Lite、3.5 Flash Cyberを発表した。今回のアップデートは、トークン効率の大幅な改善と、速度・コストの両立を追求した点が特徴だ。
3.6 Flashはコード生成や知識処理の精度を高めつつ、出力トークン数を最大65%削減するケースも報告されている。3.5 Flash-Liteは毎秒350トークンという爆速で、エージェントの大規模運用を想定した設計。そして3.5 Flash Cyberは、コードの脆弱性発見と修正に特化し、限定的な提供が始まる。
本記事では、それぞれのモデルの性能と実用面へのインパクトを、開発者視点で詳しく掘り下げる。AIエージェントのコスト構造やアーキテクチャ設計に直結する情報なので、Gemini API を扱うエンジニアは必見だ。
3.6 Flashで加速するトークン効率革命

出力トークン17%削減がもたらすコストインパクト
3.6 Flashの最大のセールスポイントは、3.5 Flash比で出力トークンを平均17%削減した点だ。Artificial Analysis Indexによる計測で明らかになったこの数字は、単なる省サイズ化を超えた意味を持つ。AIエージェントがマルチステップのワークフローを回す際、出力トークン量はAPI利用料金に直結するからだ。
具体的には、3.6 Flashの価格は入力100万トークンあたり1.50ドル、出力100万トークンあたり7.50ドル。3.5 Flashより安く、かつ出力が短くなったことで、1タスクあたりの実質コストが明確に下がった。エージェントが複数回の推論やツール呼び出しを繰り返すシナリオでは、コスト削減効果が累積的に効いてくる。
コード生成とナレッジワークでの明確なスコア向上
効率化と同時に、ベンチマークスコアも軒並み向上している。ソフトウェアエンジニアリングタスクを評価するDeepSWEでは、3.5 Flashの37%から49%へ向上。機械学習研究向けのMLE Benchでは49.7%から63.9%へと大幅に伸びた。不要なコード編集や実行ループの削減が、精度向上に寄与したと見られる。
また、OSWorld-Verifiedというコンピュータ操作タスクでは78.4%から83.0%へ改善。ドキュメント解析やチャート分析、レポート作成といった知識処理の指標GDPval-AA v2でもスコアを伸ばしている。企業ユーザーのFigmaやHarvey、Hebbiaからも「複雑なワークフローでのコストと品質の両立が進んだ」と高い評価が寄せられている。
上の図は、エージェントが1つのタスクを処理する際の出力トークン数の違いを模式化したものだ。実際のDeepSWEベンチマークでは最大65%のトークン削減が観測されており、コード生成のような長大な出力が求められる分野ほど恩恵が大きい。
3.5 Flash-Liteが切り開く高速エージェント運用

毎秒350トークン、低レイテンシと高スループットの両立
Gemini 3.5 Flash-Liteは、速度を極限まで追求したモデルだ。Artificial Analysisの計測では毎秒350トークンの出力を達成。前世代の3.1 Flash-Liteと比較してコーディングやエージェントタスクのスコアが大幅に向上し、実務に耐える品質を備えた。
価格は入力100万トークンあたり0.30ドル、出力100万トークンあたり2.50ドルと、3.6 Flashよりさらに安い。大規模なドキュメント処理やエージェント検索など、大量のリクエストをさばく必要があるシステムに最適だ。開発者は「思考レベル」を設定できるため、低レイテンシが求められる単純タスクでは最小限の推論に抑え、複雑なサブエージェント処理には高思考レベルを割り当てるといった柔軟な運用が可能になる。
3 Flashをも凌駕するエージェント性能
興味深いのは、3.5 Flash-Liteが先代の3 Flashを上回るベンチマーク結果を残している点だ。SWE-Bench Proでは54.2%(3 Flashは49.6%)、OSWorld-Verifiedでは74.0%(同65.1%)と、より高速でありながら高精度を実現している。長期コンテキストタスクのGDM-MRCR v2でも72.2%と、3.1 Flash-Liteの60.1%から大きく伸びた。
Google DeepMindの発表では、3.6 Flashをマスターエージェント、3.5 Flash-Liteをサブエージェントとして組み合わせるユースケースが紹介されている。マスターが全体の指示を出し、大量のサブタスクをLiteが高速に処理するアーキテクチャだ。これにより、Webデザインの複数案を瞬時に生成するといったワークフローが実用的な速度で回せるようになる。
この構成は、従来の「1つの大きなモデルに全部任せる」スタイルから、役割に応じたモデルを組み合わせるマルチエージェント設計への移行を象徴している。コストと速度のバランスを取る上で、3.5 Flash-Liteの存在は極めて重要になるだろう。
3.5 Flash Cyberがセキュアなコードを変える

脆弱性の発見と修正に特化したファインチューニング
3つ目の発表であるGemini 3.5 Flash Cyberは、3.5 Flashをベースにサイバーセキュリティ用途に特化して調整されたモデルだ。コードの脆弱性を高効率で検出し、修正パッチを生成する能力に優れている。単体で使うのではなく、Google DeepMindが開発したコードセキュリティエージェント「CodeMender」と組み合わせることで、複数のCyberエージェントが協調して1つの統合レポートを出力する。
ベンチマークCyberGymにおいて、CodeMender上の3.5 Flash Cyberは最前線クラスの競争力を持つことが示された。大規模モデルに頼らず、価格あたりのトークン単価を抑えつつ高い検出精度を実現している点がポイントだ。
限定的な提供と悪用防止の枠組み
この種の技術には悪用リスクがつきまとう。Google DeepMindは意図的に配布を制限し、政府機関と信頼できるパートナーに対してのみ、CodeMender経由の限定的なアクセスパイロットプログラムとして提供を開始する。フロントラインの防御側が脆弱性を早期に発見・修正できるようになる一方で、広範な悪用を防ぐ設計だ。
このアプローチは、セキュリティAIがいたずらに攻撃者の手に渡ることを防ぎつつ、本来の防御目的を達成する現実的な落とし所と言える。企業のセキュリティチームにとっては、コードレビューの自動化とパッチ生成の高速化が期待できるが、現時点では一般のAPIとしては利用できない点に注意が必要だ。
Gemini Flashシリーズが描くAIエージェントの次なる潮流

効率・速度・専門性の3軸で攻めるGoogleの戦略
今回の発表から読み取れるGoogleの戦略は明確だ。AIエージェントの実用化においてボトルネックとなる「コスト」「レイテンシ」「専門精度」の3つを、それぞれ最適化したモデルラインナップでカバーしようとしている。
- 3.6 Flashは汎用的な頭脳として、コストパフォーマンスと品質を高次元でバランス
- 3.5 Flash-Liteはスピードと低コストを武器に、大量のサブタスクや高スループット処理を担当
- 3.5 Flash Cyberはセキュリティという特定領域に深く特化し、専門エージェントとして機能
これは単なるモデルバリエーションの追加ではない。開発者がエージェントを設計する際に、「重いモデル1つで全てを処理する」のではなく、役割に応じたモデルを組み合わせるマルチエージェントアーキテクチャを標準化しようとする意図が感じられる。
競合との差別化と実務へのインパクト
OpenAIやAnthropicもエージェント向けの高速モデルを提供しているが、Googleはモデルのバリエーションと価格設定の粒度で一歩抜きん出た印象だ。特に3.5 Flash-Liteの「0.30ドル/1M入力トークン」という価格は、大量のAPIコールが発生するエージェント運用において強力な競争力になる。
さらに、3.6 Flashのトークン効率改善は、単にAPI利用料を下げるだけでなく、出力が短くなることで後続のコンテキストウィンドウ消費を抑え、長大な会話や複数ステップのタスクでも破綻しにくくなる。開発者体験としての「扱いやすさ」が向上している点も見逃せない。
上の図は、AIエージェントの設計思想の変化を模式化したものだ。Flashシリーズの充実により、開発者は「全部入り」の巨大モデルに頼らず、適材適所でモデルを組み合わせるアーキテクチャを選択しやすくなる。
この記事のポイント
- Gemini 3.6 Flashは出力トークンを平均17%削減、コードやナレッジ処理の精度も向上
- 3.5 Flash-Liteは毎秒350トークンの速度で、高スループットなエージェント処理に最適
- 3.5 Flash CyberはCodeMenderと連携し、コード脆弱性の検出と修正を効率化(限定提供)
- 3つのモデルは役割を分担するマルチエージェント設計を前提に開発されており、コストと速度の最適化を実現
- AIエージェント開発は「1つの巨大モデル」から「目的別モデルの組み合わせ」へと移行しつつある

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

WooCommerce Mollie決済プラグイン更新後の致命的エラー対処法
WooCommerce の Mollie 決済プラグイン(Mollie Payments for WooCommerce)をバージョン 8.1.8 から 8.1.9 に更新した直後、サイトに「このサイトで重大なエラーが発生しました」と表示されたり、WordPress から致命的エラーの通知メールが届いたりする場合は、プラグイン内部のコンストラクタが想定する引数の数と実際に渡される引数の数が一致しないことが直接の原因だ。バージョン 8.1.8 へのロールバックで即座に復旧できる。
Mollie プラグイン更新後に起きる致命的エラーの正体とは

今回のエラーは「ArgumentCountError(引数の数が一致しない)」に分類される。具体的には、プラグイン内部の RestApi.php というファイルの 26 行目に定義された __construct() メソッド(クラスの初期化時に呼び出される特別な関数)が 4 つの引数を必要としているにもかかわらず、呼び出し元の services.php 127 行目から 3 つしか渡されていない。
この種の不具合は、プラグインの開発過程でメソッドのシグネチャ(引数の数や型の定義)が変更されたにもかかわらず、すべての呼び出し箇所が追従しなかった場合に発生する。今回のケースでは 8.1.8 から 8.1.9 へのアップデートで RestApi クラスのコンストラクタに新しい依存オブジェクトが 1 つ追加されたが、サービスコンテナ側の定義が更新に追いつかず、3 つのまま残ってしまった可能性が高い。
このエラーは Mollie プラグインの開発元も再現できておらず、特定の環境(PHP バージョンや他のプラグインとの組み合わせ)でのみ発生する。そのため、原因の完全な特定と恒久的な修正には開発元の調査を待つ必要がある。
■ エラーログに「Too few arguments to function」のメッセージ
■ チェックアウトページが動作しない、または管理画面の一部が読み込めない
■ Mollie 決済機能が通常通り動作する
■ 致命的エラーの通知メールが停止する
上図のとおり、ロールバックによってサイトの全機能が即座に回復する。このエラーは PHP の実行を完全に停止させる E_ERROR レベルのため、チェックアウトページを含むサイト全体に影響が及ぶ点が深刻だ。
バージョン 8.1.8 へロールバックして即時復旧する手順

最も確実で安全な対処法は、プラグインを直前の安定バージョンである 8.1.8 に戻すことだ。管理画面にアクセスできる場合とできない場合で手順が異なる。
管理画面にアクセスできる場合のロールバック
管理画面にログインできる状態であれば、WP Rollback プラグインを使うのが最も簡単だ。このプラグインは、WordPress.org の公式プラグインディレクトリに登録された任意のプラグインを、過去の特定バージョンにワンクリックで戻せる。
WP Rollback を使わない場合は、プラグインを一度削除してから旧バージョンを手動でインストールする。削除しても Mollie の API キーや決済設定はデータベースに残るため再設定は不要だが、念のため作業前に WooCommerce のシステムレポートを控えておくと安心だ。
管理画面にもアクセスできない場合の復旧
エラーによって管理画面にも入れなくなっている場合は、FTP クライアントまたはレンタルサーバーのファイルマネージャーを使って対処する。手順は以下のとおりだ。
- FTP でサーバーに接続し、
/wp-content/plugins/ディレクトリに移動する mollie-payments-for-woocommerceフォルダの名前を「mollie-payments-for-woocommerce-broken」などに変更する(これでプラグインが無効化され、管理画面に入れるようになる)- 管理画面にログインしたら、WP Rollback をインストールする
- フォルダ名を元に戻してから、STEP 1〜4 を実行して 8.1.8 にロールバックする
フォルダ名の変更でプラグインを無効化するとサイトのフロントエンドも正常に表示されるようになるが、その間 Mollie 決済は利用できない点に注意する。
手動 ZIP アップロードで 8.1.9 を試す場合の注意点

フォーラムの一部ユーザーは、WordPress 管理画面の自動更新ではなく GitHub からダウンロードした ZIP ファイルを手動アップロードすることでエラーを回避できたと報告している。しかし別のユーザーは同じ手順でもエラーが再発しており、確実な回避策ではない。
手動 ZIP アップロードを試す場合は、以下の点に注意する必要がある。まず、GitHub のリリースページ(Mollie の公式 WooCommerce リポジトリ)から 8.1.9 の ZIP を入手する。プラグイン画面の「新規追加」→「プラグインのアップロード」から ZIP を選択し、「既存のプラグインと置き換える」を確認してアップロードする。
手動アップロード後はサイト全体をくまなく確認し、特に実際のテスト購入でチェックアウトフローが最後まで動作することを確かめる。エラーが再発した場合は速やかに 8.1.8 に戻す。
調査中の自動更新を止めて再発を防ぐ

開発元が修正版をリリースするまでの間、Mollie プラグインが勝手に 8.1.9 に再更新されるのを防ぐ必要がある。WordPress の自動更新設定ではプラグイン単位で自動更新のオンオフを切り替えられる。
「プラグイン」→「インストール済みプラグイン」で Mollie Payments for WooCommerce の行を見ると「自動更新を有効化」または「自動更新を無効化」のリンクがある。これをクリックして自動更新を無効にしておけば、8.1.8 のまま安全に運用を継続できる。修正版がリリースされたら、自動更新を再度有効にしてから手動で更新を実行する。
よくある質問
8.1.8 を使い続けてもセキュリティ上の問題はないか
8.1.8 と 8.1.9 の差分は軽微な機能追加やバグ修正が中心であり、8.1.8 に既知の重大な脆弱性は報告されていない。数週間程度の運用であれば実務上のリスクは低い。とはいえ、決済プラグインに限らず常に最新バージョンを使うのが基本のため、修正版がリリースされたら速やかに更新する。
手動 ZIP アップロードと管理画面からの自動更新で何が違うのか
一般的には同じ ZIP ファイルを使うため内容に差はないが、自動更新時には WordPress のアップデーターがファイルの置き換えを段階的に行うのに対し、手動アップロードでは一度に全ファイルが上書きされる。キャッシュやオートローダーの生成タイミングの違いが結果に影響している可能性がある。ただし本件では原因が完全に特定されていないため、効果には個体差がある。
PHP バージョンはエラーに関係するか
関係する可能性は高い。PHP 8.0 以降は引数の数の不一致に対して E_ERROR レベルの厳格なエラーを出すが、PHP 7.x では E_WARNING で済んでいたケースもある。Mollie プラグインのシステム要件を確認し、推奨される PHP バージョン(通常 7.4 以上)を使っているかどうかを WooCommerce のステータス画面で確認する。
エラーメールが大量に届いて困っている。どう止めればよいか
WordPress の致命的エラー通知はサイトにアクセスがあるたびに発生するため、更新直後は短時間で大量のメールが届くことがある。最も早い対処は前述のとおり FTP でプラグインフォルダの名前を変更して無効化することだ。メールが止まったら、すぐに 8.1.8 へのロールバックに取りかかる。
他の決済プラグインに切り替えるべきか
このエラーはバージョン 8.1.9 固有の一時的な不具合であり、Mollie プラグイン全体の品質に問題があるわけではない。8.1.8 で問題なく運用できていたのであれば、慌てて乗り換える必要はない。オランダ発の Mollie は欧州で高いシェアを持つ決済プロバイダーであり、プラグインも活発にメンテナンスされている。
この記事のポイント
- Mollie 8.1.9 の致命的エラーはコンストラクタ引数の数が一致しないことが原因
- 最も確実な対処は WP Rollback で 8.1.8 に戻すこと
- 管理画面に入れない場合は FTP でプラグインフォルダをリネームして無効化する
- 手動 ZIP アップロードは回避できる場合とできない場合があり確実性に欠ける
- 修正版が出るまで自動更新を無効にして 8.1.8 のまま運用する

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

AmazonとBolで108件の不当割引、EU規制違反が発覚
オランダの消費者団体Consumentenbondが2026年7月、AmazonとBolに対し、誤解を招く割引表示を即時停止するよう警告書を送付した。FIFAワールドカップに関連した値引きを2カ月にわたって追跡した結果、両プラットフォームで合計108件の「偽セール」が確認されたという。
この警告は単なる消費者トラブルの話題ではない。EUの価格表示規制(オムニバス指令)に違反する行為であり、是正されなければ法的措置に発展する可能性がある。日本国内でECを運営する事業者にとっても、今後の規制強化を占う重要な事例だ。
調査の概要と発覚した違反の実態

FIFAワールドカップ商戦を狙った追跡調査
Consumentenbondは2026年5月から2カ月間、AmazonとBolで販売される人気商品1,142点の価格変動を記録した。対象はFIFAワールドカップに関連する値引きが行われた商品だ。このうち323点が少なくとも1回の割引表示を伴って販売された。
割引表示とは、元の価格に打ち消し線を引いた上で「26%オフ」といった値引き率を示す手法を指す。EUのオムニバス指令では、この「元の価格」は過去30日間の最低販売価格でなければならないと定められている。
Amazonで46件、Bolで62件の不当表示
調査の結果、Amazonでは113件の割引表示のうち46件が、Bolでは210件中62件が規制違反と判定された。いずれも割引前の30日間において、表示された「通常価格」よりも実際の販売価格が低かった商品だ。つまり、割引前のほうが安かった、あるいは値引き後の価格と変わらなかったケースが大半を占める。
具体例として、Amazonで販売されていたBluetoothスピーカーは「通常価格199.99ユーロの26%オフ、147ユーロ」と表示されていた。しかし実際には、セール開始前の約1カ月間、この商品は133ユーロで販売されていた。割引どころか、セール価格のほうが高いという逆転現象が起きていたことになる。
なぜ「偽セール」は問題なのか

EUオムニバス指令が定める価格表示ルール
EUでは2022年に施行されたオムニバス指令(Omnibus Directive)により、値引き表示の基準が厳格化された。割引の基準となる「参照価格」は、値引き開始前の30日間にその商品が販売された最低価格でなければならない。このルールは消費者の誤認を防ぎ、公正な価格競争を促進する目的で設けられている。
参照価格とは、割引率を計算する際の分母となる価格だ。たとえば「通常1万円のところ5,000円、50%オフ」と表示する場合、この1万円が参照価格にあたる。過去30日間に一度でも8,000円で販売されていれば、参照価格は8,000円としなければならない。つまり割引率は37.5%オフにしかならない計算だ。
Bolのテレビ事例に見る巧妙な価格操作
Bolではテレビが「通常価格399ユーロの12%オフ、349ユーロ」と表示されていた。ところが調査期間の60日間で399ユーロで販売された日は一度もなかった。ほとんどの期間349ユーロで販売され、7月6日のみ329ユーロに下がっていた。つまり法定の30日ルールでいえば、参照価格は329ユーロでなければならず、349ユーロはむしろ値上げにあたる。
この事例は、意図的かどうかは別として、「セール」と見せかけて通常価格と変わらない、あるいはむしろ高い価格で販売する手法が横行している実態を浮き彫りにした。
EC事業者が知っておくべき法的リスク

消費者団体は訴訟も辞さない構え
Consumentenbondのディレクター、Sandra Molenaar氏は同団体の公式発表で「私たちは何年も偽の割引を調査し、ルールに従わない小売業者を指摘してきた。CoolblueやWehkampではすでに改善が見られた。しかしAmazonとBolはルールを把握しているにもかかわらず、こうしたオファーで顧客を誘引し続けている」と述べている。
同氏はさらに「私たちとしては、もう十分だ。AmazonとBolが価格表示規制を遵守し、オファーにおける節約額を正確に表示することを要求する。従わない場合は法的措置を取る」と警告している。具体的には、オランダの消費者法に基づく訴訟に発展する可能性がある。
EU圏外の事業者にも波及する規制の波
今回のケースはオランダ国内の話だが、EUオムニバス指令は域内で事業を行うすべてのECサイトに適用される。日本企業がEU向けに越境ECを展開している場合も対象となる。また日本国内でも、消費者庁が景品表示法に基づく二重価格表示の規制を強化しており、方向性は同じだ。
実際、日本では2023年に「定期購入の不当表示」で大手EC事業者が行政処分を受けた事例がある。海外の規制動向は国内の法改正や執行強化の先行指標となるため、注視しておく必要がある。
Black Fridayを前にした今後の展開

消費者団体は年末商戦を厳重監視
Consumentenbondは今回の警告をAmazonとBolに限定して行ったが、他のEC事業者にも注意を促している。Moleenaar氏は「私たちは継続的に価格を監視している。他の販売業者にも警告する。Black Fridayに向けて偽のセールを厳しく監視し、違反者に対しては措置を取る。消費者には不審なオファーを報告してほしい」と呼びかけた。
EC事業者がいますぐ取るべき3つの対策
今回の事例から、EC事業者が取るべき対策は次の3つに集約される。
- 価格履歴の記録と監査:過去30日間の販売価格を自動記録し、割引表示のたびに参照価格が適切かをチェックする仕組みを導入する。WooCommerceであれば価格履歴を追跡するプラグインが利用できる。
- 表示文言の見直し:「通常価格」や「定価」といった表現が実際の販売実績に基づいているか確認する。メーカー希望小売価格を「定価」として表示する行為も、販売実績がなければ不当表示になり得る。
- 社内ガイドラインの策定:マーケティング担当者と法務担当者が共通理解を持つための社内ルールを文書化する。特に大型セール前には全社的な確認プロセスを設ける。
この3ステップを回すことで、意図しない規制違反を防ぎ、消費者からの信頼を維持できる。偽セールの代償は行政処分だけではない。SNSで拡散されればブランド毀損につながり、長期的な売上減少を招くリスクもある。
この記事のポイント
- オランダ消費者団体がAmazonとBolに対し、FIFAワールドカップ商戦における偽の割引表示の即時停止を要求
- EUオムニバス指令では、値引きの参照価格は過去30日間の最低販売価格でなければならない
- 調査対象1,142点のうち323点に割引表示があり、Amazonで46件、Bolで62件が規制違反と判定
- 違反の具体例として、セール価格が割引前の価格より高いケースも確認された
- 日本国内のEC事業者も景品表示法の二重価格規制に注意し、価格履歴の記録と表示の自動チェック体制を整える必要がある

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

Events ManagerでGutenbergのイベントが公開できない時の直し方
Events ManagerをGutenberg編集モードで使っているときに新規イベントが公開できず、クラシックエディタでは問題なく動作する場合、プラグインのバージョンが7.3.1〜7.3.4のいずれかであることが主な原因だ。7.3.5以降へアップデートすると修正される。
どんな操作をしたときに発生するのか

Gutenbergモードを有効にしたEvents Managerで新規イベントを作成する。すべての項目を入力して「公開」ボタンを押しても、画面が再読み込みされステータスが「下書き」のままになり、公開状態に切り替わらない。一方でクラシックエディタに切り替えると、同じ内容でも問題なく公開できるという状況だ。
この現象は、WP標準テーマ(Twenty Twenty-FourやTwenty Twenty-Five)に切り替えても、他のプラグインをすべて無効化しても変わらない。Events Manager側のGutenberg統合部分にバージョン固有の不具合が存在しているために起きる。
公開ボタンが反応しない直接の原因は何か

Events Managerのバージョン7.3.1から7.3.4には、Gutenbergエディタ上でイベントを保存する際に走るバリデーション(検証)処理に問題がある。具体的には、イベントの必須項目が正しく入力されていても内部的な検証に失敗し、「公開」操作が受理されない状態になる。
とくに繰り返しイベント(定期的な開催設定)を扱う場合、「Main recurrence set times are required(メインの繰り返し時刻設定が必要です)」という趣旨の検証エラーが返され、公開をブロックされるケースが報告されている。このバリデーションエラーは管理画面の見た目には表示されず、ブラウザの開発者ツール上で確認できる。
このデモが示すように、エディタの見た目上は正常に操作しているのに、プラグイン内部のAPI応答が原因で公開処理が止まる。Events Manager 7.3.5でこのバリデーション不具合が修正されている。
Events Managerを最新版にアップデートして修正する

最も確実な解決策は、Events Managerをバージョン7.3.5以降にアップデートすることだ。管理画面から数ステップで完了する。
サイトの運用途中でアップデートをためらう場合は、まずステージング環境(テスト用の複製サイト)でアップデート後の動作を確認すると安全だ。近年の国内レンタルサーバーでは、管理パネルからワンクリックでステージング環境を作成できるものも多い。
すぐに公開したい場合の一時的な回避策

プラグインのアップデートが何らかの理由ですぐにできない場合、以下の回避策で公開できることがある。
- 公開ボタンを2回以上連続でクリックする。1回目でいったん下書きとして保存され、2回目以降のクリックで公開状態に切り替わるケースが報告されている。
- イベント編集画面の「Events Manager」設定パネルで、Gutenbergモードを無効にしてクラシックエディタを使う。クラシックエディタでは問題なく公開できる。
これらの回避策は、あくまでアップデート前の応急処置として使う。根本的には7.3.5以降へのアップデートが必要だ。
アップデート後も繰り返しイベントでエラーが出る場合の対処

7.3.5以降でも、繰り返しイベントの設定時にまれに「Main recurrence set times are required(メインの繰り返し時刻設定が必要です)」という趣旨のバリデーションエラーが表示されることがある。このエラーは、繰り返し設定の中核となる日時情報がバリデーションAPIに正しく渡っていない場合に発生する。
まず試すべきは、繰り返し設定を一度クリアして再入力することだ。とくに開始日時と終了日時、および繰り返しパターンの「初回の日時」が空欄になっていないか確認する。カスタムコードでGutenberg有効化を制御していた場合は、そのコードが完全に削除されているかも確認する。残留したコードがAPI通信に干渉している可能性がある。
よくある質問
Events ManagerのGutenbergモードはどこで切り替えられるか
管理画面の「Events」→「設定」→「管理画面」タブにある「イベントエディタの種類」で切り替えられる。ここで「Gutenberg」を選択するとブロックエディタが有効になり、「クラシックエディタ」を選ぶと従来の編集画面に戻る。
Gutenberg有効化のカスタムコードが原因になることはあるか
過去にfunctions.phpなどへ追加したGutenberg有効化コードが削除されずに残っていると、プラグインの設定と競合して予期しない動作を起こす可能性がある。コードが完全に削除されているか、もしくはコメントアウトされているか確認する。
公開ボタンを押しても何も反応しない場合はどうすればよいか
ブラウザの開発者ツール(F12キー)の「コンソール」タブにJavaScriptエラーが表示されていないか確認する。別のプラグインがGutenbergと競合してJavaScriptエラーを起こしている場合、それが原因で公開処理が止まることがある。
クラシックエディタでは問題ないのにGutenbergだけ不具合が出る理由は何か
GutenbergはREST APIを介してデータを保存する仕組みをとっている。Events Managerのバリデーション処理も、GutenbergモードではAPI経由で実行される。クラシックエディタの場合は異なる保存経路を使うため、API側の不具合の影響を受けずに公開できる。
7.3.5はいつリリースされたのか
Events Manager 7.3.5は2026年7月下旬にリリースされ、本件のGutenberg公開不具合が修正されている。管理画面の更新通知から適用できる。
この記事のポイント
- Events Manager 7.3.1〜7.3.4のGutenbergモードには公開できない不具合がある
- 7.3.5以降へアップデートすると修正される
- アップデートできない場合は公開ボタンの複数回クリックやクラシックエディタで一時回避できる
- 繰り返しイベントでの検証エラーは設定の再入力で直ることが多い
- 過去のカスタムコードが競合していないか確認することも大切だ

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressテーマのアクセシビリティ対応、思ったより簡単な理由
アクセシビリティ対応を難しく感じる本当の理由

WordPressテーマのアクセシビリティ対応に取り組もうとした開発者の多くが、最初の段階でつまずくポイントがある。WordPress.orgのテーマリポジトリで「accessibility-ready」タグを取得するための要件文書だ。WP TavernのポッドキャストでJessica Lyschik氏が指摘したように、この要件文書は初めて読む人にとって「暗号的」に映りがちだ。
問題の核心はドキュメントの書き方にある。要件には「こうあるべき」という達成目標と簡単なテスト手順は書かれているが、具体的にどのような技術的実装をすればよいのかが明示されていない。例えば「適切なHTML5タグを使用すること」という趣旨の要件があっても、header、footer、main、section、asideの各タグをどう配置すべきかまでは書かれていない。
Lyschik氏自身もこの問題を実感した一人だ。彼女が管理するテーマを新要件に合わせて見直した際、アクセシビリティの知識を何年も積んできた自分ですら「なるほど、こういう意味だったのか」と再確認する場面があったという。ましてやアクセシビリティに初めて触れる開発者にとっては、抽象的な要件と実際のコードを結びつけること自体が大きな障壁になる。アクセシビリティは「難しい」のではなく、「何をすればいいかが分かりにくい」分野なのだ。
Lyschik氏がWordCamp Europe 2026のセッションで伝えたかったのは、まさにこの点だ。要件文書の「行間」に埋もれた実装知識を言語化し、開発者が自信を持ってアクセシビリティに取り組めるようにすること。ドキュメント改善は現在進行形の課題だが、基本的なHTMLとCSSの知識があれば、大半の要件は想像よりはるかに簡単にクリアできる。
今日から実践できる3つの具体的な改善策

WP TavernのインタビューでLyschik氏は「ロー・ハンギング・フルーツ(手の届きやすい果実)」という表現を使った。大きな努力をしなくてもすぐに成果が出る、アクセシビリティ改善の第一歩が確かに存在する。以下は彼女が実際に推奨する3つの即効性のある施策だ。
画像の代替テキストを省略しない
最も基本的かつ効果が大きいのが代替テキスト(alt属性)の付与だ。WordPressのメディアライブラリには代替テキストを入力するフィールドが標準で用意されている。ブロックテーマなら画像ブロックを選択するだけで、サイドバーにaltテキスト入力欄が表示される。目の前にある入力欄を飛ばさずに埋めるだけの作業で、スクリーンリーダーユーザーやAIエージェントに画像の意味を伝えられる。
正しいHTMLタグの選択とスキップリンクの設定
ブロックテーマでは、HTMLタグの割り当てが驚くほど簡単になっている。コンテンツ全体をグループブロックで囲み、そのグループに「main」のHTMLタグを設定するだけで、WordPressがスキップリンク(Skip to Content)を自動生成する。このスキップリンクは、キーボード操作ユーザーが毎回ヘッダーメニューを通過せずに、直接本文へジャンプできる重要な導線だ。
クラシックテーマでは手動で実装する必要があったこの機能も、ブロックテーマなら数クリックで完了する。テンプレートパーツのheader/footerも適切に割り当てれば、Coreが自動で正しいHTML構造を出力してくれる。
本文中のリンクには下線を付ける
本文中のリンクテキストに下線を付けることは、CSS1行で実現できる変更だ。Lyschik氏は「text-decoration: underline; の1行を追加するだけ」と表現している。色だけに依存したリンク識別は、色覚特性のあるユーザーやコントラストが低下した環境で機能しなくなる。特にWCAG(Web Content Accessibility Guidelines)が要求するコントラスト比を満たす設計では、下線による補助表示が欠かせない。
Lyschik氏が強調するのは「最初から組み込む」ことの重要性だ。後から数百ページにわたってボタンのaria-labelを修正する作業を想像してみてほしい。彼女の同僚が実際に経験した「12箇所×2種類のボタン」修正は、事前に対応していれば5分で済んだはずの作業だった。あとから修正するコストは、最初に対応する手間と比べて指数関数的に増大する。
ブロックテーマが変えるアクセシビリティの常識

WordPressのテーマ開発はクラシックテーマからブロックテーマへと大きな転換点を迎えている。アクセシビリティの観点から見ると、この移行は単なるトレンドではなく、根本的な実装難易度の低下をもたらしている。
Coreが肩代わりするようになった処理群
ブロックテーマで最も大きな変化は、WordPress Core(コア)がアクセシビリティ対応の多くを自動処理するようになった点だ。Lyschik氏が具体的に挙げた例をいくつか紹介する。
特筆すべきは検索フォームとコメントフォームの扱いだ。クラシックテーマではフォームのラベル設定やエラー処理をテーマ開発者が実装する必要があったが、ブロックテーマではCoreがこれを完全に引き受けている。テーマ開発者はブロックを配置するだけで、自動的にアクセシブルなフォームが出力される。
既存テーマの構造をテンプレートとして再利用する
Lyschik氏が提案する効率的なアプローチは、アクセシビリティ対応済みのテーマからテンプレート構造をコピーすることだ。新しいテンプレートを作成する際、ゼロから設計するのではなく、すでに正しいHTML構造を持つ既存テンプレートを複製して色やレイアウトだけを変更する。これにより、header、main、footerのタグ割り当てが自動的に継承され、意図せずアクセシビリティを損なうリスクを回避できる。
この手法の前提として「どのテーマが正しくアクセシビリティ対応されているか」の知識が必要になるが、WordPress.orgテーマリポジトリで「accessibility-ready」タグを取得しているテーマ(現在約270テーマ、全体の1.5%程度)が信頼できる参照先となる。
AIエージェントが変えるアクセシビリティの優先順位

インタビューの中でLyschik氏が特に強調したのが、AIエージェントの台頭がアクセシビリティの重要性を根本的に変えつつあるという洞察だ。この視点は、従来の「障がい者支援」という枠組みを超えて、アクセシビリティをビジネス上の競争力として再定義する可能性を秘めている。
AIエージェントは「見た目」ではなく「構造」を読む
Lyschik氏がAnne-Mieke Bovelett氏から共有されたという資料では、AIエージェントとスクリーンリーダーの動作原理が本質的に同じであることが指摘されている。AIエージェントはWebサイトを人間のように「視覚的」に理解するわけではない。HTMLの構造、適切なタグ、正確なラベル付けに依存して情報を取得し、操作を実行する。
■ アクセシビリティ対応サイト:AIエージェントがスムーズに取引を完了
Googleが2026年6月に発表したドキュメントでも、AIエージェント向けのアクセシビリティに注力する方針が示されている。これは単なる技術的関心ではなく、ECサイトの将来像に直結する話だ。ユーザーが直接ブラウザを操作せず、AIエージェントに「コーヒー豆を購入して」と依頼する世界では、アクセシビリティ対応の有無が売上に直結する。
アクセシビリティは「コスト」ではなく「投資」になる
Lyschik氏が言及したAnne-Mieke Bovelett氏の事例では、ある企業がWebサイトのアクセシビリティ改善に取り組んだ結果、売上が実際に増加したという。この事例が示すのは、アクセシビリティ対応が単に「法的リスクの回避」や「道徳的義務」という枠を超えて、ビジネス成果に寄与するという事実だ。
AIエージェントの普及はこの傾向を加速させるだろう。適切に構造化されたHTML、明確なラベル付け、正しいフォーム処理を持つWebサイトは、AIエージェントによる自動操作の信頼性を高める。2025年以降、この「AIフレンドリー」な設計がECやサービスサイトの競争優位性を左右する可能性は高い。
最初から組み込むアクセシビリティの設計思想

Lyschik氏が一貫して訴えているのは「アクセシビリティは後付けの修正ではなく、設計段階から組み込むべきもの」という原則だ。彼女自身の経験と、同僚が直面した「24回のaria-label追加作業」のエピソードが、この主張を裏付けている。
ボタンのaria-label追加に見る「後付けの代償」
インタビューで紹介された実例がある。クライアントのアクセシビリティテストで、アイコンのみのボタン(電話アイコンなど)がスクリーンリーダーで機能しないと指摘された。アイコンだけでは「このボタンが何をするのか」を読み上げられないからだ。修正にはaria-label属性を追加するだけで済むが、問題はその数だった。12箇所×2種類のボタン、合計24回の手動修正が必要になった。
Lyschik氏はこの経験を「設計時にaria-labelを追加しておけば5分で終わっていた作業」と総括する。テーマやサイトの構築時にアクセシビリティを考慮していれば、後から数百ページにわたって同じ修正を繰り返す必要はなかったはずだ。
学際的な意識共有が不可欠
アクセシビリティは開発者だけの責任ではない。Lyschik氏は「interdisciplinary(学際的)」という言葉を使い、SEO担当者、コンテンツ制作者、デザイナーを含む全ての関係者が基本的な知識を持つべきだと指摘する。
見出しタグ(H1〜H6)の正しい階層構造は、その典型的な例だ。H1の下にH2、その下にH3という順序を守ることは、スクリーンリーダーユーザーの文書理解を助けるだけでなく、検索エンジンのコンテンツ解析精度にも影響する。SEOとアクセシビリティは、しばしば同じ方向を向いている。
この記事のポイント
- アクセシビリティ対応の難しさは「技術そのもの」ではなく「ドキュメントの分かりにくさ」に起因している
- 画像の代替テキスト入力、正しいHTMLタグ割り当て、リンク下線付与は今日から着手できる即効性の高い施策だ
- ブロックテーマではスキップリンクやフォームラベルなど、Coreがアクセシビリティ処理を大幅に肩代わりする
- AIエージェントの普及により、アクセシビリティ対応はECサイトの売上やビジネス成果に直結する要素になりつつある
- 設計段階からの組み込みが、後工程での膨大な修正作業を回避する最も効率的なアプローチだ

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

WooCommerce 11.0で失敗注文の在庫が自動復元へ、変更点と対応を解説
WooCommerce 11.0で、注文が「失敗」ステータスに移行した際の在庫処理に変更が入った。従来、注文が在庫を減らした後に「失敗」になると在庫が戻らなかったが、今後は自動で在庫が復元されるようになる。
この変更はほとんどのストアにとっては歓迎すべき改善だが、一部のカスタムフローでは注意が必要だ。ここでは変更の具体的な内容と、開発者が取るべき対応を整理する。
具体的に何が変わったのか

この変更の核心はシンプルだ。WooCommerce 11.0以降、注文ステータスが「失敗(failed)」に移行したとき、その注文が以前に在庫を減らしていた場合、自動的に在庫が復元されるようになる。
技術的には、woocommerce_order_status_failedフックにwc_maybe_increase_stock_levels()関数が登録された。この関数は、注文が以前に在庫を減らしていたかどうかを確認した上で在庫を戻す処理を行う。
上記の図で示したように、WooCommerce 11.0では「失敗(failed)」がキャンセルや保留中と同様に在庫復元の対象へと引き上げられた。
なぜこの変更が必要だったのか
この問題は非同期決済で顕在化しやすかった。たとえば、顧客が支払いを開始すると注文は「保留中(on-hold)」に移行し、その時点で在庫が減る。しかし、何らかの理由で決済が拒否され、注文が「失敗(failed)」になると、在庫だけが減ったまま戻らなかった。
結果として、実際には販売できていないにもかかわらず、在庫数だけが減った状態が続いていた。特に在庫が1点ものの商品を扱うストアでは、実害の大きい挙動だったと言える。今回の変更で、このギャップが解消される。
在庫の二重減算は起こらないのか
wc_maybe_increase_stock_levels()関数は、注文が実際に在庫を減らしたかどうかをフラグで確認してから在庫を戻す。そのため、在庫を減らしていない注文が「失敗」になった場合には在庫は変動しない。
また、管理者や拡張機能が「失敗」から再度「支払い済み」などのステータスに戻した場合、WooCommerceは以前の履歴を参照して二重に在庫を減らすことはないよう設計されている。
この変更はチェックアウト時の在庫予約機能には影響しない。あくまで在庫を実際に減らした注文が対象だ。
どのようなストアや拡張機能が影響を受けるか

大多数のストアや拡張機能にとっては、今回の変更はそのまま歓迎すべき改善だ。決済失敗時に在庫が正しく戻るようになることで、手動での在庫修正が不要になる。
しかし、一部のカスタムフローでは注意が必要だ。具体的には、「失敗(failed)」ステータスを支払い以外の目的で流用しているケースである。たとえば、配送失敗時に注文を「失敗」としてマークしつつ、商品はすでに発送済みで在庫を確保しておきたい、といったフローだ。
こうしたストアでは、WooCommerce 11.0にアップデートすると、注文が「失敗」に移行した瞬間に在庫が復元されてしまい、意図しない在庫の増加が発生する。
開発者が取るべき対応

基本的には対応不要
まず前提として、決済の失敗にのみ「失敗」ステータスを使っているストアや拡張機能では、何も対応する必要はない。アップデート後、自動的に在庫が正しく処理される。
意図的に在庫を減らしたままにしたい場合
もし拡張機能やストアが「失敗」ステータスを支払い以外の目的で使用しており、在庫を減らしたままにしておく必要があるなら、以下のコードで新しい在庫復元フックを削除すればよい。
remove_action( 'woocommerce_order_status_failed', 'wc_maybe_increase_stock_levels' );ただし、これはあくまで「旧来の挙動を維持する明確な理由がある場合」に限るべきだ。ほとんどのストアでは、在庫が自動で復元される新しい挙動のほうが望ましい。
アップデート前のテスト事項
アップデートを配信する前に、以下の項目を実環境に近いステージング環境でテストすることを強く推奨する。
- 「保留中」→「失敗」のフローで在庫が正しく復元されること
- 「失敗」→「処理中」→「完了」のフローで在庫が二重に減算されないこと
- カスタムフローで「失敗」ステータスを使っている場合、在庫数と注文メモが意図した通りになっていること
特に、非同期決済を利用しているストアでは、「保留中」で在庫が減った後、決済拒否で「失敗」に移行した際の挙動を重点的に確認しておくと安心できる。
この記事のポイント
- WooCommerce 11.0では、注文が「失敗(failed)」に移行した際に在庫が自動復元される
- 従来は「キャンセル」「保留中」のみが復元対象で、「失敗」は対象外だった
- ほとんどのストアは対応不要で、むしろ在庫管理が正確になるメリットがある
- 「失敗」ステータスを支払い以外で流用しているストアは、フック削除で旧来の挙動に戻せる
- アップデート前には必ずステージング環境で在庫の動きをテストすること

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

LiteSpeed Cacheでパージ成功してもキャッシュが残る原因と直し方
LiteSpeed Cacheで管理画面やWP-CLIから「Purge All(全キャッシュ削除)」を実行し成功メッセージが出ているにもかかわらず、公開ページがいつまでも古い内容のまま更新されない場合、プラグインのキャッシュ制御と実際に動作しているサーバーレベルのキャッシュ層との間に不整合が起きている可能性が高い。根本的には、LSCacheプラグインの設定最適化と、場合によってはプラグインを一時的に無効化しての強制リフレッシュが有効な解決策になる。
なぜ「全削除」に成功してもキャッシュが残り続けるのか

LiteSpeed Cacheのキャッシュ構造は多層的で、プラグインの管理画面と実際のキャッシュストレージが常に一対一で対応しているとは限らない。管理画面で「Purge All」を実行すると、プラグインは内部的にパージタグを生成し、LSWS(LiteSpeed Web Server)に対してキャッシュ削除の指示を出す。ここで成功メッセージが返ってくるのは、あくまで「指示が出せた」という意味であり、ディスクやメモリ上の実ファイルが完全に消えたことの保証にはならない。
まず試すべきプラグイン側の設定見直し

x-litespeed-cache:hit が返ってくる。x-litespeed-cache-control: no-cache
miss になり、サーバーが動的生成に切り替わった。キャッシュ有効期限とブラウザキャッシュ設定の確認
まず、LSCacheプラグインの「キャッシュ」タブでTTL(Time To Live、キャッシュの有効期限)が極端に長く設定されていないか確認する。デフォルトは604800秒(1週間)だが、公開ページの更新頻度が高いサイトでは3600秒(1時間)程度に短くすることで、パージ操作の効果が出やすくなる。また「ブラウザキャッシュ」タブで、ブラウザ側のキャッシュ保持期間が長すぎると、サーバーのパージ後もユーザーのローカルキャッシュが優先されて古い表示になる。短期間に設定するか、問題切分け中は一時的に無効化(オフ)にする。
オブジェクトキャッシュとRedisの影響を見極める
RedisやMemcachedといった外部オブジェクトキャッシュを使っている環境では、LSCacheがページキャッシュを削除しても、データベースクエリの結果がオブジェクトキャッシュに残り、結果として同じ古い情報でページが再生成される。Redisを使っているなら、管理画面の「LiteSpeed Cache」→「オブジェクトキャッシュ」でステータスを確認し、「Purge Object Cache」を手動で実行する。それでも直らない場合は、問題の切分けとしてredis-cacheやRedis Object Cacheプラグイン自体を一度無効化し、LSCacheだけの状態でパージを試す。
サーバーレベルで強制的にキャッシュを削除する手順
プラグインの操作で改善しない場合、LiteSpeed Web Serverが保持しているキャッシュをOSレベルで手動削除する。特に、LSCacheプラグインが生成したキャッシュ情報と、LSWSの内部キャッシュマップがずれてしまった場合に有効だ。
ディスクキャッシュの格納場所と削除コマンド
SSHでサーバーに接続し、まずLSWSのキャッシュパスを特定する。デフォルトでは /tmp/lshttpd/ または /usr/local/lsws/cachedata/ 以下にキャッシュが格納されている。LSCacheプラグインの「CDN/キャッシュ設定」にある「キャッシュルートパス」を確認すると確実だ。
次に、LSWSを完全に停止する。systemctl restart lsws や管理画面からのグレースフルリスタートではプロセスがクリアされず、内部のキャッシュマップが生き残る。以下の手順で、キャッシュディレクトリを物理的に空にしてから再起動する。
# LSWSを完全停止
/usr/local/lsws/bin/lswsctrl stop
# キャッシュディレクトリとスワップを完全に削除
rm -rf /tmp/lshttpd/swap/*
rm -rf /tmp/lshttpd/cache/*
# LSWSを起動
/usr/local/lsws/bin/lswsctrl start起動後、WordPress管理画面からLSCacheの「Purge All」を実行し、ブラウザのシークレットウィンドウ(または開発者ツールでキャッシュを無効化した状態)で動作を確認する。x-litespeed-cache ヘッダーが miss になっていれば成功だ。
どうしても治らない場合の一時的切り分け
上記の手順を実行しても、ベアURL(パラメータなしの通常アクセス)だけが古いキャッシュを返し続ける場合、LSCacheプラグイン自体がリクエスト段階でキャッシュの再取得を意図せず阻害している可能性が高い。この状況は、特定の条件下でLSCacheプラグインがブラウザやリバースプロキシに強力なCache-Controlヘッダーを設定し、サーバー側でミスになってもCDNやブラウザが古いデータを返し続けるケースだ。
最終的な切分けとして、LSCacheプラグインを5分〜10分間だけ完全に無効化する。無効化後に即座にキャッシュが更新されるなら、LSCacheプラグインの内部ロジックまたは設定が主因であると特定できる。プラグインを再有効化した後、デフォルト設定へのリセットや、問題を再現させた設定項目を一つずつ絞り込む。
よくある質問
クエリ文字列を付けるとキャッシュがバイパスされる理由は?
LiteSpeed Cacheは、URLにパラメータ(?=xxx)が付与されたリクエストを、デフォルトでキャッシュ対象外とみなす。そのためベアURLでは x-litespeed-cache:hit で古いキャッシュが返っているのに、/?v=2 のような文字列を付けると miss となり、動的に生成された最新ページが表示される。
サーバーを再起動できない共有サーバーではどう対処すればよいか
多くの共用サーバーではSSHやLSWSの制御権限が制限されている。この場合、LSCacheプラグインの「ツールボックス」→「Purge All」を実行し、即座にプラグインを無効化する。その後「LiteSpeed Cache」を再有効化し、デフォルト設定へのリセットを試す。サーバー側のキャッシュディレクトリに触れない環境では、この手順が最も確実な強制リセットになる。
パージ後のキャッシュ再生成を防ぎたい場合の設定は?
公開前のプレビューや検証でキャッシュを完全に止めたい場合、LSCacheプラグインの「キャッシュ」→「キャッシュを有効化」のトグルを一時的にオフにする方法が最も確実だ。ただしこの設定はサイト全体のパフォーマンスに影響するため、検証後は必ずオンに戻し、特定のページだけ除外したい場合は「URI 除外」機能を使う。
この記事のポイント
- LSCacheのパージ成功表示が実キャッシュ削除の保証にはならない
- サーバーレベルでディスクキャッシュを直接削除すると治るケースが多い
- Redisなどの外部オブジェクトキャッシュも同時に削除する必要がある
- クエリ文字列でバイパスされる現象はLSCacheの正常動作だが、ベアURLが古いのは異常
- どうしても治らなければ、プラグインの一時無効化で原因をLSCacheに特定できる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Google LSAがGoogle広告に統合、2026年8月から段階移行へ
GoogleがLSA(Local Services Ads / ローカルサービス広告)の管理画面をGoogle広告に統合する。2026年8月から一部の米国広告主を対象に移行が始まり、2027年にかけて段階的に拡大される予定だ。
移行後はGoogle広告内でキャンペーン管理やリード対応が完結する。ただし入札方式やレポートの扱いが変わるため、事前の準備が欠かせない。本記事では移行のスケジュールや変更点、広告主が取るべき対応を3つのポイントに絞って解説する。
LSAのGoogle広告統合で何が変わるのか

LSA(ローカルサービス広告)は、もともとGoogle検索やマップの上部に表示される問い合わせ獲得型の広告だ。ユーザーが「近くの電気工事業者」などと検索すると、電話やメッセージでのリード獲得を主目的とした事業者一覧が表示される仕組みである。
今回の統合により、LSAはGoogle広告の管理画面から操作する形へと一本化される。従来のLSA専用ダッシュボードは廃止され、キャンペーンの作成からリード対応までをGoogle広告内で処理できるようになる。
移行スケジュールは2026年8月から段階的に
Googleが公開したスケジュールによると、最初の移行対象は米国の一部広告主であり、ペットケアやホームサービス、ウェルネス、教育関連の業種が含まれる。2026年8月にこの第1陣の移行が始まり、同年後半に米国内の対象が拡大される見込みだ。
米国以外のアカウントや残りの業種については2027年に対応が進む。アカウント管理者には移行の14日前と7日前に通知が届き、移行完了時にも確認の連絡があるため、突然ダッシュボードが使えなくなる事態は避けられる。
管理フローの一元化によって作業負荷は減る一方で、従来のLSA専用画面に慣れた事業者や代理店には操作変更への対応が求められる。
新しいLSAキャンペーンの仕組み

統合後のLSAは、Google広告のP-MAX(Performance Max)キャンペーンとして配信される。ただし名称こそP-MAXだが、配信面や課金方式は従来のLSAと変わらない点に注意が必要だ。
配信面と課金方式は変更なし
LSAは今後もキーワードの入札なしで、Google検索とマップにのみ表示される。クリック課金ではなく、電話、メッセージ、予約といった有効リードに対して料金が発生する仕組みも維持される。P-MAXと聞くとディスプレイ広告や動画広告まで配信対象が広がるイメージがあるが、LSAの場合はあくまで検索とマップに限定される形だ。
Google広告内で完結するキャンペーン管理
広告主はGoogle広告の管理画面でLSAキャンペーンの設定、リードの確認、返信をすべて行えるようになる。従来のLSA専用ダッシュボードは移行後に利用できなくなるため、操作に不慣れな場合は早めにGoogle広告の画面構成を確認しておくとスムーズだ。
キャンペーン管理で変わる5つのポイント

統合に伴い、予算の考え方や入札、レポートの扱いが一部変更される。Search Engine Journalの記事で挙げられた主な変更点を整理する。
予算は週単位から日単位へ
従来のLSAは週平均の予算で運用されていたが、移行後はGoogle広告の他のキャンペーンと同様に日額予算での管理に変わる。1日あたりの支出上限が設定されるため、週単位のざっくりした予算配分からより細かい調整が必要になる。
手動入札が廃止され目標CPAがキャンペーン単位に
これまで一部の広告主は「リード1件あたりの上限単価」を手動で設定できたが、この機能は使えなくなる。代わりに、Googleが算出するキャンペーン単位の目標CPA(リード獲得単価の目標値)が適用される。
サービスカテゴリごとに異なる目標CPAを設定することもできなくなる。たとえば配管工事と空調工事の両方を1つのキャンペーンで広告している事業者の場合、双方のリードコスト差にかかわらず1つの目標CPAに統一される。この点は業種によって影響が大きいため、キャンペーン分割の要否を検討する必要がある。
ビジネス情報はGBPと自動同期
事業者名や住所、営業時間といった基本情報はGBP(Google Business Profile / グーグルビジネスプロフィール)から自動で同期される。これまではLSAとGBPで別々に情報を更新する手間があったが、統合により片方だけ変更するリスクは減る。ただし、大幅な名前や住所の変更を行うと24〜48時間の確認プロセスが入り、キャンペーンが一時停止する可能性がある。
レポートとリード管理の拠点が切り替わる
過去のパフォーマンスレポートはGoogle広告に引き継がれない。リードの履歴は移行されるものの、レポートデータへのアクセスは移行完了と同時に失われる。年度比較や顧客報告に必要なデータは事前にダウンロードしておくことが必須だ。リード対応についても、Google広告内のLead Manager(リード管理画面)に切り替わる。
広告主が移行前後に取るべき対策

移行をスムーズに進めるために、広告主や代理店が今から着手できる準備を整理する。移行の通知を受け取ってから慌てないよう、以下の2点を押さえておきたい。
履歴レポートのダウンロードを最優先に
最も重要なのは、LSAダッシュボードに保存されている過去のパフォーマンスデータをエクスポートすることだ。移行後はレポート画面自体がなくなるため、後から取り出すことはできない。
複数アカウントを管理する代理店は、通知を受け取る前にバックアップ作業を始めておくと安全だ。前年比較レポートを作る予定のある事業者も、今のうちに必要な期間のデータを保存しておくことを推奨する。
移行後の設定を丁寧に確認する
Googleがキャンペーン設定を自動で移行するが、広告主自身で以下の項目を再確認すべきである。
- 日額予算が事業計画と合っているか
- キャンペーン単位の目標CPAが過去のリード単価と大きく乖離していないか
- サービスカテゴリや配信地域が正しく設定されているか
- 広告スケジュールが想定通りか
- リード転送先の電話番号や写真、訴求文に誤りがないか
事業者名や住所に大きな変更があると、前述の通り審査が入りキャンペーンが止まる可能性がある。配信再開までに数日かかるケースもあるため、移行直後の大口変更は避けたほうが無難だ。
Googleは移行後すぐに広告が表示される場合もあるとしているが、パフォーマンスが安定するまで最大2週間をみておく必要がある。
統合がもたらす影響と今後の見通し

今回の統合の最大の焦点は、カテゴリ別の目標CPAが廃止される点にある。リード単価の大きく異なる複数サービスを1つのキャンペーンで運用してきた事業者は、キャンペーンを分割するか、まとめたまま自動入札に任せるかの判断を迫られる。
分割すれば入札のコントロールは細かくなるが、各キャンペーンのコンバージョンデータが少なくなり、Googleの自動最適化が働きにくくなる面もある。リード数の多い事業者は分割、まだボリュームの少ない事業者は統合したまま様子を見るという選択肢が現実的だ。
初期移行グループの状況を見ながら、Googleは追加のガイダンスを出すとみられる。とくに日本国内の広告主が対象となるのは2027年以降と見込まれるため、まずは米国の事例を参考にしつつ、自社のLSAデータを整理しておくのが賢明だろう。
この記事のポイント
- LSAの管理画面が2026年8月からGoogle広告に統合される
- 配信面とリード課金の仕組みは変わらないが、予算管理や入札方式が変更される
- カテゴリ別目標CPAの廃止が事業者に与える影響は大きく、キャンペーン分割の要否を検討する必要がある
- 過去レポートは移行前に必ずダウンロードしておくこと
- 日本国内の移行は2027年以降の見込みだが、今からデータ整理を始めておくとよい

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