今週（8/10〜8/16）はWordPress 7.1のリリース直前週でした。本日8月16日からWordCamp US 2026がフェニックスで開幕し、最終日にあたる8月19日（水）に7.1が公開されます。AI側では8月12日にGrok 4.6が登場し、Metaもコーディングエージェントに参入。Googleでは Search Console の生成AI関連レポートが広がってきています。
読む章の目安です。WordPressサイトを運用しているなら1章、AIコーディングツールを選び直すなら2章、メディアやSEOを見ているなら3章。4章と5章は今週の出来事ではありませんが、7.1で進む「CSSを書かなくて済む」流れと地続きなのでまとめました。
前号で取り上げたChrome 152は、8月25日（火）に安定版が出る予定です。
WordPress 7.1 が8月19日リリース — カスタムCSSが減る
WordPress 7.1が8月19日にリリースされます。WordCamp US 2026（フェニックス、8/16〜8/19）の最終日にあたる日程です。7.0で打ち出したAIと共同編集の路線を仕上げる位置づけで、公式には「finish what we started」と表現されています。
出典: WordPress Developer Blog — What’s new for developers (August 2026) / SmartWP — WordPress 7.1: What to Expect
制作・運用側でいちばん大きいのは、レスポンシブ指定とインタラクティブ状態がエディタのコントロールになることです。 これまで :hover や :focus の色替え、画面幅ごとの余白調整のために書いていた追加CSSが、GUIから指定できるようになります。
その他の主な変更:
- メディア機能の刷新: HEICとAVIFに対応。クロップ・回転のモーダルが追加され、通信が切れたときはアップロードを自動で再試行
- ノート機能の強化: インラインノート、@メンション、リッチテキスト書式に対応
- 新ブロック2種: Playlist と Tabs（Gutenberg 23.6で安定化済み）
- React 19 が Core に: Gutenberg基盤のバージョンが前進
- Abilities API（新規）: プラグインの機能を「AIから呼べる形」で宣言する仕組み。AI連携の土台になる
- SVG Icon API / DataViews・DataForm API: アイコン登録と管理画面の一覧・フォームを標準化
hover や focus の指定がGUIに乗るのは、納品後の小さな修正依頼が減るという意味で地味に効きます。 「ボタンの色をマウスオーバーで変えたい」に毎回CSSを追記していた作業がなくなるからです。
一方で、追加CSSでゴリ押ししているブロックテーマは、エディタ側の指定と競合して表示が変わる可能性があります。 本番更新の前にステージングで主要ページを見るのは、今回はやっておいた方がいい回だと思います。
💡 今すぐ試せる: 自動更新をオンにしているサイトを洗い出し、案件で納品したものだけ手動更新に切り替えて8/19を待つ。あわせて追加CSSの量が多いサイトをリストアップしておく
AIコーディングエージェント競争が新局面（8/12前後）
今週はAIコーディングツールの動きが集中しました。8月12日にSpaceXAI（旧xAI）がGrok 4.6を公開。Metaは初の自社コーディングエージェント「Muse Code」を投入し、OpenAIはCodexをChatGPT内のコーディング司令塔として作り直しています。
出典: 9to5Mac — SpaceXAI releases Grok 4.6 / Unite.AI — SpaceXAI Launches Grok 4.6 for Long-Running Agents / DevOps.com — Meta Launches AI Coding Agent
Grok 4.6（8/12）の主な仕様:
- 価格: 入力 $2・出力 $6（100万トークンあたり。Grok 4.5から据え置き）
- コンテキスト: 50万トークン（こちらも4.5から据え置き）
- 性能: Artificial Analysis Intelligence Index で61点。GPT-5.6 Sol と同水準で、4.5から5点上昇
- 使える場所: Cursor、Grok Build、SpaceXAI API のほか、OpenRouter・Vercel・Cloudflare 経由でも同日から利用可能
Metaの「Muse Code」は同社初のコーディングエージェントで、OpenAI・Anthropicへの対抗と位置づけられています。現時点では提供範囲の詳細が公表されておらず、すぐ試せる段階ではありません。OpenAIのCodexは、worktree、クラウド実行環境、スケジュール実行、IDE連携、CLIワークフローを備え、機能追加・リファクタ・移行・テスト・レビュー・保守といった実務そのものを対象に据え直されました。
注目したいのは、競争の軸がベンチマークのスコアから離れてきたことです。 今週の3つはいずれも「長時間動くか」「作業を任せられるか」「いくらか」で語られていて、モデルの賢さ自慢ではありません。Grok 4.6が価格もコンテキストも据え置いたまま、長時間エージェント向けの最適化だけを打ち出したのが象徴的です。エージェントを長く走らせるほど、賢さより「途中で失速しないこと」と単価が効いてきます。
個人や小規模で使う立場なら、ツールを増やすより1つを深く使う方が結果は出ます。 乗り換えを検討するときも、賢さではなく自分のワークフロー（ターミナル中心か、IDE中心か、ブラウザ中心か）に合うかで選ぶのが現実的です。
💡 今すぐ試せる: 今使っているAIツールで「長めのタスクを投げて放置する」使い方を1回試す。途中で止まるか最後まで走るかで、エージェント系に移行する価値があるか判断できる
Search Console の生成AIレポートが広がってきた
Googleが Search Console の生成AI関連レポートを、対象サイトを広げながら展開しています。あわせて、自サイトを AI Mode や AI Overviews に出すかどうかを指定できるコントロールも提供されています。
出典: Search Engine Watch — Google Algorithm update in August 2026? / Google — Search Console ヘルプ
押さえておきたい動き:
- 生成AIパフォーマンスレポート: AI検索経由の表示・クリックを確認できるレポートが、テスト対象を広げながら順次開放
- 生成AIコントロール: AI Mode や AI Overviews への表示可否を指定できる
- プラットフォームプロパティ（7月導入）: Instagram・TikTok・X・YouTube 上の自社アカウントが、Google検索やDiscoverでどう見られているかを追跡できる
- 順位変動: 公式のコアアップデート発表がないまま、8月1〜3日、5〜6日、12〜13日に変動の波が観測されています
AI経由の流入がどれだけあるかを、推測ではなく数字で見られるようになるのが大きい。 これまで「AI Overviewsに出たら流入が減る」という話は体感で語られがちでしたが、レポートが開けば自分のサイトで実際どうなのかを確認できます。
AI表示のオプトアウトについては、慌てて切らない方がいいと思っています。 表示されなくなれば引用元としての露出も消えるので、まずはレポートで自分のサイトの数字を見てから決めるべき判断です。8月中旬の変動についても、公式発表がない以上は一時的な揺れの可能性があります。順位の上下だけで施策を大きく変えるのは早計です。
💡 今すぐ試せる: Search Console を開いて生成AI関連のレポートが自分のプロパティに来ているか確認。来ていれば、AI経由の表示回数と通常検索の比率を1度だけ記録しておく（後で比較できる基準になる）
Next.js 16.3 の Instant Navigations（8/3・8/6）
8月3日にNext.js 16.3が公開され、8月6日にはその追補としてナビゲーション検証用のツールが追加されました。
出典: Next.js Blog — Next.js 16.3
16.3の主な内容:
- 開発時のメモリ使用量を最大90%削減: ビルドとレンダリングも高速化
- Instant Navigations: ストリーミング・キャッシュ・ブロッキングを組み合わせ、クライアント主導のSPAに近い応答性を目指す仕組み
instant()テストヘルパー（8/6追加）: 「そのナビゲーションが本当に即時か」をテストで検証できる
遷移速度を「体感」ではなくテストで担保できるようにしたのが面白い点です。 速度改善は入れた直後は速くても、機能追加のたびに少しずつ劣化していきます。テストに書けるなら回帰を検知できるので、仕組みにしたのは理にかなっています。開発時のメモリ90%削減も、大きめのプロジェクトを扱っている人ほど効くはずです。
💡 今すぐ試せる: Next.jsプロジェクトがあれば next dev を起動してメモリ使用量を測っておく。16.3未満なら更新して比較、更新済みなら次の肥大化を検知する基準値になる
CSS field-sizing が全ブラウザで使えるようになっている
7.1の「CSSを書かなくて済む」流れと同じ方向の話です。field-sizing プロパティは6月16日のFirefox 152で全エンジン対応となり、Baseline Newly available になっています。
出典: MDN — field-sizing / Web Platform Features Explorer — field-sizing
field-sizing: content を指定すると、textarea や input、select が中身の量に応じて伸縮します。これまでJavaScriptで scrollHeight を測って高さを再設定していた、あの定番処理が不要になります。
See the Pen CSS field-sizing: content — 入力欄が中身に合わせて伸縮する by BaseKENT (@basekent) on CodePen.
textarea,
input,
select {
field-sizing: content;
min-width: 6ch; /* 縮みすぎの歯止め */
max-width: 100%;
}
textarea { min-height: 2.6em; }お問い合わせフォームのtextareaに入れるだけで体験が変わります。 入力量が少ないうちは小さく、書くほど伸びるので、長文を書くときにスクロールバーの中で書き続ける窮屈さがなくなります。注意点は min-width と max-width を必ず併記すること。指定しないと、空のときに極端に小さくなったり、長い入力で親要素をはみ出したりします。
なお、flexコンテナの中で使うときは align-self の指定が要ります。 flexの子は既定で交差軸方向に引き伸ばされるため、width: auto にしても幅が縮みません。実際にデモを作ったときにここで詰まりました。
💡 今すぐ試せる: 自サイトのお問い合わせフォームのtextareaに field-sizing: content; min-height: 2.6em; を追加。既存のJS高さ調整コードがあれば、それを消せるか確認する
今週のひとこと
WordPress 7.1でhoverや画面幅の指定がGUIに移り、CSSには入力欄を自動で伸縮させるプロパティが揃う。今週見ていたのは、これまで手で書いていたコードが、少しずつ標準機能に吸収されていく流れでした。書かなくて済むようになった分、どこに時間を使うかという話になります。来週水曜のWordPress 7.1更新から、まずは目の前の作業として片付けていきましょう。
