Gemini 3.8 Liveシリーズ登場、音声AIエージェントの新基盤に
Google DeepMindが9月15日、Gemini 3.8 LiveとGemini 3.8 Live Extended Thinkingを発表した。音声エージェント向けに設計された2つの新モデルで、リアルタイム推論能力が大幅に強化されている。
Gemini 3.8 Liveはスケールとコスト効率を重視したモデルだ。Gemini 3.8 Live Extended Thinkingは高複雑度タスク向けで、複数ステップの推論を会話の流れを止めずに実行できる。
開発者API、Google Workspace、Search Liveなど幅広い経路で提供が始まっている。音声で複雑なタスクを処理する新しい基盤になる。
Gemini 3.8 Liveシリーズの全体像
会話知能と自然な対話、視覚的な理解を組み合わせたモデル。スケールとコスト効率を重視しており、大量の同時接続を処理する音声エージェントに向く。
高複雑度タスク向けに設計されたモデル。複数ステップの推論と、より高い知能を備える。会話の流れを止めずに深い思考ができるのが特徴。
2つのモデルは用途が明確に分かれている。音声エージェントを大量に展開する場合は標準版、複雑な業務フローを音声で処理する場合はExtended Thinkingを選ぶ形になる。
2つのモデルの役割分担
Gemini 3.8 Liveは会話の自然さと視覚的な文脈理解を兼ね備えている。コストパフォーマンスを重視する開発者や企業に向く設計だ。
Gemini 3.8 Live Extended Thinkingは、より複雑な推論が必要な場面を想定している。話しながら考え、バックグラウンドで複数ステップのタスクを進められる点が最大の違いだ。
展開される利用経路
両モデルとも、Geminiアプリ、Google Workspace、Search Liveに順次展開される。特にWorkspaceではDocs Live、Gmail Live、Keep Liveといったアプリ内の音声機能として利用できる。
コンシューマー向けにはSearch Liveが最初の接点になる。検索中に音声で質問し、そのまま会話を続けられる体験が提供される。
ベンチマークが示す性能とコスト効率
音声品質とエージェント性能の両面で、既存モデルを上回る結果が示されている。コスト面でも競争力のある価格帯を維持している点が特徴だ。
音声品質とエージェント性能
Artificial AnalysisのSpeech to Speech Quality Indexでは82.6を獲得し、総合第1位となった。音声の自然さと応答品質のバランスで他モデルを上回っている。
エージェントタスクの完了率でも強さを示している。τ-Voiceベンチマークで68.6%、Sierraのτ-Voiceバンキングベンチマークでは35.1%を記録した。音声だけで業務フローを完結させる能力が評価された形だ。
推論能力を示すBig Bench Audioでは97.7%と高いスコアを出している。音声を聞いて正しく推論する基盤能力の高さが確認できる。
コスト競争力とユーザー評価
Gemini 3.8 LiveはSpeech Agent Arenaで第2位を獲得している。ユーザーからの選好度が高いモデルでありながら、高いコスト効率を実現している点が重要だ。
ServiceNowのEVA-Benchでは、複雑なワークフローにおける正確性と会話品質のバランスでパレートフロンティアを更新した。エンタープライズ向け音声エージェントの実用性が裏付けられている。
リアルタイム推論の技術的進化
会話を止めずに裏側でタスクを進める設計が、これまでの音声AIと大きく異なる点だ。
視覚入力と言語対応
Gemini 3.8 Liveは視覚入力をほぼリアルタイムで処理する。カメラに映ったものや画面上の情報を文脈として会話に取り込めるため、状況に応じた助言が可能になった。
言語対応も強力だ。97の言語を自動的に検出し、会話の途中でもシームレスに切り替えられる。多言語環境で使う音声エージェントに適している。
公式デモでは、従業員のオンボーディングをリアルタイムで案内する様子や、チェスの盤面を見ながら対局を進める様子が紹介されている。視覚と会話の統合が実用レベルに達していることを示す例だ。
バックグラウンド実行と同時推論
ツールやAPIの実行はバックグラウンドで進められる。ユーザーの要求を受け付けたら、処理が終わるまで待たせず、会話を続けながら結果を伝える動きができる。
Extended Thinking版は「話しながら考える」能力を持つ。「確認させてください」といった短い言葉で応答しながら、裏側で複数ステップの推論を進める。進捗状況を自然な会話で伝える機能も備わっている。
公式デモでは、手書きスケッチと音声フィードバックからReactコンポーネントを生成する例や、複数ステップの予約を非同期で処理する例が公開された。音声だけで開発作業や業務処理を進められる可能性が広がっている。
開発者と企業のエコシステム
Gemini Live APIと開発者プラットフォーム
両モデルはGemini Live APIを通じて利用できる。開発者はこのAPIを使い、音声駆動のインターフェースを自社サービスに組み込める。リアルタイムのメディアストリーミング基盤はプラットフォーム側が処理してくれるため、UX設計に集中できる。
Agora、Fishjam、LangChain、LiveKit、Pipecat、Vercel、Vision AgentsなどのプラットフォームがGemini Live APIに統合済みだ。これらのツールを使えば、音声エージェントの構築からデプロイまでを短縮できる。
企業パートナーと展開スケジュール
Salesforce、Genspark、Lumerisなどの企業が3.8 Liveシリーズの導入に意欲を示している。低遅延性、会話の流暢さ、ツール呼び出し能力が評価されている。
展開スケジュールは以下の通りだ。開発者向けにはGemini APIとGoogle AI Studioで即日利用できる。企業向けにはGemini Enterpriseでプライベートプレビューが始まり、Gemini Enterprise for Customer Experienceにも順次提供される。
コンシューマー向けでは、Search Liveが最初の提供経路になる。Gemini Liveでも利用可能で、Google AI ProおよびUltraの加入者はWorkspaceのDocs、Gmail、KeepでExtended Thinking版を試せる。
透明性確保の仕組み
SynthIDによる音声ウォーターマーク
AIが生成した音声にはすべてSynthIDのウォーターマークが埋め込まれる。人間の耳には聞こえない形で音声出力に直接織り込まれており、AI生成コンテンツの検出を可能にする。誤情報の拡散防止が狙いだ。
安全性と責任あるAIへの取り組みの詳細は、モデルカードで確認できる。音声AIが社会に広がる中で、透明性の確保は実用化の前提条件になっている。
この記事のポイント
- Gemini 3.8 LiveとLive Extended Thinkingが9月15日に発表された
- 標準版はコスト効率、Extended Thinking版は複雑タスク向けと役割が分かれている
- Speech to Speech Quality Indexで82.6を獲得し総合第1位
- 97言語対応、視覚入力、バックグラウンド実行など技術面が大幅強化
- Gemini Live API経由で開発者が即日利用できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce公式ブロックテーマPurpleがベータテスト開始。テスト方法と注目機能
WooCommerce初の公式ブロックテーマ「Purple」がベータテストを開始した。GitHubからダウンロードできる状態で、正式版はWordPressテーマディレクトリとWooCommerceマーケットプレイスで配布される予定だ。
PurpleはECサイト向けに作られたスターターテーマで、テンプレート一式、10種類のカラーパレット、10種類のフォント組み合わせ、EC向けパターンライブラリを備える。ブロックテーマのため、従来のクラシックテーマより軽量で柔軟なカスタマイズが可能だ。
この記事ではPurpleの特徴、WooCommerceコアに加わったブロック改善、テスト手順を解説する。ストア運営者や制作会社がベータテストに参加する際の参考にしてほしい。
Purpleテーマとは何か
PurpleはWooCommerceチームが開発したオープンソースのスターターテーマだ。ブロック対応のWooCommerceページ用テンプレートをほぼ網羅しており、WooCommerceとWordPressコアブロックのカスタムスタイルも含む。ストアを立ち上げる事業者が、モダンで高速な土台として使える設計になっている。
ブロックテーマとは、WordPressのブロックエディタだけでサイトの見た目やレイアウトを編集できるテーマ形式のことだ。従来のテーマはPHPテンプレートとCSSが中心だったが、ブロックテーマはブロックの組み合わせでページを構成する。エディタ上で完結するため、コードを書かずにデザインを変更できるのが特徴だ。
Purpleには商品グリッド、フィルター、コレクション、CTA、商品詳細ページなどを含むEC特化のパターンライブラリも同梱されている。パターンとは、あらかじめ組み立てられたブロックのセットで、ワンクリックでページに挿入できる部品のことだ。
このデモはPurpleテーマの中核となる4つの要素を示している。開発者や制作会社はこれらのテンプレートとスタイルを拡張し、独自のストアデザインの出発点として使える。
Storefrontとの違い
WooCommerceの従来の代表テーマであるStorefrontと比較すると、Purpleの違いが分かりやすい。Storefrontはクラシックテーマで、商品ヒーローデザイン、カスタムホームページ、商品ギャラリー、ミニカート、高度なヘッダーやフッターを実現するには拡張機能が必要だった。
一方、ブロックテーマではWooCommerceのブロックライブラリとブロックエディタだけで、これらのカスタマイズを実現できる。拡張機能に依存せず、テーマとコア機能だけでストアを構築できるのがPurpleの大きな利点だ。
WooCommerceコアに加わったブロック改善
Purpleプロジェクトの価値はテーマそのものだけではない。開発の過程で、WooCommerceコアに多数のブロック改善が加わった。この改善はPurpleに限らず、影響を受けるブロックやAPIを使うすべてのブロックテーマで利用できる。
バージョン11.0の基盤整備
WooCommerce 11.0では、ブロックテーマを軽量かつ一貫性のあるものにするための基盤が整えられた。まず、パターンコンテンツの読み込みが必要になった時だけ行われるようになった。これにより、パターンを必要としないリクエストでの無駄な処理が減る。
商品画像まわりも改善された。Product Imageブロックはより大きなサムネイルを使い、トリミングされた画像でも正しいアスペクト比を保持する。商品カタログの見た目がテーマ設定と調和しやすくなった。
そのほか、Product CollectionブロックがQuery Loopの内側にネストされた際に正しいコンテキストを保持するようになり、複合テンプレートやパターン内で商品ブロックが正しく描画されるようになった。Breadcrumbsブロックはtheme.jsonによるスタイリングに対応し、Product Filtersブロックはフィルタードロワーを無効化するオプションを追加した。カートテーブルのヘッダーにはARIAロールが付与され、支援技術でのアクセシビリティも向上している。
バージョン11.1のレスポンシブ対応
WordPress 7.1がブロックエディタにレスポンシブデザインコントロールを導入したことを受け、WooCommerce 11.1では主要なブロックがこのコントロールに対応した。Product Priceはタイポグラフィ、色、パディング、マージンのレスポンシブスタイリングに対応し、Product Reviewsも画面幅ごとのスタイルを反映できるようになった。
Product Detailsはパディング、マージン、背景、ボーダーをブロックとグローバルスタイルの両方から設定できる。Product Galleryはカスタムアスペクト比に対応し、大きな画像エリアとサムネイルレールの同期も改善された。
パフォーマンス面では、ブロック登録の改善が大きい。ブロックを描画できないリクエストではブロックとパターンの登録をスキップする仕組みが入り、公開された測定値ではStore APIとRESTリクエストが30〜42%高速化した。統合ブロックエディタアセットの実験的サポートも導入され、サイト編集中のネットワーク転送サイズは48.3%削減された。
このデモはブロック登録の最適化前後の違いを示している。不要な登録処理を省くことで、APIリクエストの応答時間が大幅に短縮された。
バージョン11.2の注目機能
WooCommerce 11.2は現在開発中だが、テーマ作業の成果が最も目に見える形で現れているバージョンだ。Product Filtersブロックはレスポンシブオーバーレイとスティッキー配置のコントロールを獲得した。インライン表示のままにするか、モバイルやタブレットでオーバーレイに切り替えるか、全画面幅でオーバーレイを使うかを選べる。WordPress 7.1の設定可能なレスポンシブブレークポイントにも対応する。
Product Quantityブロックはテキスト色、背景色、ボーダー半径、ボーダー、シャドウをブロックスタイルから設定できるようになった。グループ商品の数量コントロールも同じスタイリングモデルを使う。Product Imageブロックはテーマ定義のボーダーに対応し、商品グリッドやコレクションパターンにストアのビジュアルシステムを反映しやすくなった。
Chipsブロックもテーマ化が進んだ。商品フィルターや「カートに追加＋オプション」で使われるChipsブロックにタイポグラフィとボーダー半径のコントロールが追加され、ストア全体と一貫したスタイルを適用できる。パターンのインサーターカテゴリ名は「WooCommerce」から「Shop」に変更され、パターンを探しやすくなった。
Purpleのテスト方法
Purpleはベータ版のため、必ずステージング環境またはローカルサイトでテストしてほしい。本番環境でのテストは推奨されない。最新のWordPressとWooCommerceを使うことで、前述のレスポンシブコントロールを実際に試せる。
この手順でテーマをインストールした後、フロントページ、ショップまたは商品カタログ、商品詳細、カート、チェックアウト、マイアカウント、検索の各テンプレートを確認する。特にProduct Filtersブロックはデスクトップ、タブレット、モバイルの3つの画面幅でテストし、インラインモードとオーバーレイモードの両方を試す。
商品ブロックについては、Product Price、Product Details、Product Reviews、Product Gallery、Product Quantity、Catalog Sorting、Mini-Cartを、シンプル商品、バリエーション商品、グループ商品の3種類でテストする。通常使っている拡張機能や子テーマのカスタマイズを追加して、エディタとフロントエンドの両方で再テストするのが望ましい。なお、GitHubから直接ダウンロードした場合、自動更新は受けられない。
フィードバックの送り方
問題を発見した場合や提案がある場合は、GitHubのWoo Themesリポジトリでissueを開く。その際、WordPress、WooCommerce、PHP、Purpleの各バージョン、テストしていたテンプレートまたはブロック、問題の再現手順を含める。視覚的な問題ならスクリーンショットや録画も添付する。
フィードバックはデフォルトのWooCommerceストアフロントの改善と、すべてのブロックテーマで利用できるブロックとテンプレートの改善に直結する。ベータテストへの参加は、WooCommerceのブロックエコシステム全体を育てる貢献になる。
この記事のポイント
- PurpleはWooCommerce初の公式ブロックテーマで、ベータテストが始まった
- テンプレート一式、10種類のカラーパレットとフォント組み合わせ、EC向けパターンライブラリを備える
- WooCommerce 11.0から11.2にかけて、ブロック改善とパフォーマンス最適化がコアに加わった
- テストはステージング環境またはローカルサイトで行い、各ブロックとテンプレートを確認する
- フィードバックはGitHubのissueで受け付けている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI攻撃は自律化へ移行！6時間で数千件の認証情報を奪う新手口を解説
Google Threat Intelligence Group（GTIG）は2026年9月8日、敵対的AI利用の進化をまとめた四半期レポートを公開した。攻撃者が単純なプロンプト入力から、自律的に動くエージェンティックAIの活用へ移行している実態が明らかになっている。
2026年第2四半期には、クラウド環境を侵害した攻撃者が6時間未満で認証情報の大量収集キャンペーンを計画し、構築し、実行した事例が確認された。数千件規模の認証情報が奪取されている。
この変化は、防御側が攻撃を検知して対応するまでの時間を大きく縮める。AIを使う側の企業にとって、単なる技術トレンドではなく、クラウドと認証情報の管理体制に直結する問題だ。
攻撃者は「AIに聞く」から「AIに任せる」へ移行した
2026年5月の前回レポート以降、GTIGは攻撃者が基本的なプロンプト入力から、エージェンティックAIワークフローとAI対応自動化へ踏み出しているのを観測している。ここでいうエージェンティックAIとは、人間が1つずつ指示を出さなくても、目標を与えれば自分で計画を立てて実行するAIシステムのことだ。チャット型AIが1往復で終わるのに対し、エージェンティックAIはツールやAPIを呼び出しながら複数の工程を連続で進める。
従来の攻撃では、攻撃者がAIの出力を確認し、コマンドを実行し、結果を見て次の指示を出すというループが発生していた。エージェンティックAIはこの人間の介在を大幅に減らし、エラー修正やIPアドレスの切り替えまで自律的に行う。その結果、防御側が気づく前に攻撃が完了するケースが増えている。
この違いが攻撃スピードの差につながる。GTIGは2026年第2四半期に、このエージェンティックAIを使った攻撃が実戦投入された事例を確認した。
6時間で数千件の認証情報を奪ったキャンペーンの中身
Mandiantが観測した事例では、金銭目的とみられる攻撃者が組織のクラウド基盤を侵害し、自律型のマルチエージェント攻撃フレームワークを展開した。攻撃者はAIコーディングチャットボット、プロンプト、エージェント指示書を組み合わせ、計画・構築・実行を6時間未満で完了させている。通常は大規模なグループが持つリソースと同等の規模と速度で、数千件の第三者認証情報が奪取された。
攻撃者はマークダウン形式の指示書を運用プレイブックとして使った。マークダウンとは文書を書くための軽量な記法で、AIへの指示書としても扱いやすい。AIはこの指示書に従い、脆弱性スキャンパイプラインを自律的に管理し、リアルタイムでトラブルシューティングを行い、IPアドレスのローテーションまで自動実行した。攻撃トラフィックは被害者のクラウド基盤から正当なIPアドレスを経由して送信され、検知を難しくしていた。
この事例では、指示書とプロンプトを組み合わせることで、AIが自律的にパイプラインを管理した。人間の操作を挟まないため、防御側が気づく前に攻撃が完了してしまう。
GTIGはこの動きを、受動的なインフォスティーラーから攻撃的なエージェンティック収集への転換点と位置づけている。インフォスティーラーとは、端末に保存されたパスワードやCookieなどを盗み出すマルウェアだ。従来は端末を起点に情報を集めるだけだったが、新たな手法ではサーバーサイドの脆弱性を自ら探索し、狙いを定めて攻撃する。
AIコーディングが広げたオープンソースの死角
AI支援コーディングの普及でオープンソース資産の量が増え、開発速度が上がった。一方でサードパーティパッケージや依存関係の精査が甘くなり、攻撃者に付け込まれる余地が生まれている。GTIGは、AI支援コーディングが2025年から2026年初めに観測された大規模サプライチェーン侵害の一因になったとみている。
具体的な事例も確認された。2026年初めには、北米とアジアの企業環境で悪意あるオープンソースAI資源のダウンロード試行が検知された。2026年4月には、AIコーディングエージェントが暗号資産プロジェクトのコードベースに悪意ある依存関係を組み込んだ事例が公表されている。2026年5月には、LLMプロキシサービスを密かにインストールする悪意あるパッケージも特定された。これは地域的なLLMアクセス制限を迂回するために使われる。
金銭目的の攻撃者UNC6780（TeamPCP）は、こうしたリスクの深刻さを示す存在だ。UNC6780はPyPIやnpm、Docker Hubといったエコシステムを標的にし、侵害後にDUSTMAKERと呼ばれる認証情報窃取マルウェアを展開する。窃取したデータは直接売ったり、ランサムウェアグループとの提携で利益に変えられたりする。
UNC6780はAIコーディングアシスタントやLLMセキュリティスキャナーを騙す複数の手口も実装している。代表的なのがプロンプトインジェクションだ。これはAIが読むテキストの中に悪意ある指示を忍ばせる攻撃で、コードを自動分析するAIに「安全だ」と誤認させる偽の指示を仕込む。GitHub Actionsのワークフローを悪用して専有AIリポジトリを盗み出し、別の攻撃者に渡して恐喝に使わせた事例もあった。
専有AIモデルとクラウド計算資源が次の標的
2026年第2四半期、最先端モデルへの直接攻撃は確認されなかった。しかし専有AIの研究やモデルを盗む事例は増加している。標的はAIラボや先端AI企業にとどまらず、政府・軍事・医療・メディア・エンターテインメント分野にも広がった。攻撃者もサイバーエスピオナージ集団だけでなく、データ窃取恐喝グループまで含まれる。
中国関連の脅威アクターUNC6508は、北米の学術・医療・軍事研究機関を対象にした複数年キャンペーンを展開している。UNC6508は専有AI研究を標的にするだけでなく、クラウド環境を侵害してローカルLLM基盤を展開し、商用AI APIの監視を避けながら被害者の計算資源を利用していた。
データ窃取恐喝の事例も複数確認された。医療分野では企業データと製薬研究、専有AIモデルが盗まれ、身代金を支払わなければ公開すると脅迫された。AIメディア生成企業の事例では、ソースコード、プロンプト、スキル、モデルスクリプト、シークレットが流出した。モデル重みとはAIモデルが学習で得た知識を数値として保存したデータで、これが盗まれるとAIの再現や改変に悪用される恐れがある。
アカウント売買とLLMJackingの実態
プレミアムモデルや高性能計算へのアクセスコストは、攻撃者にとって大きな障壁だ。そのためAIアカウントの窃取・購入・販売が地下フォーラムで増加している。ClaudeやGeminiの認証情報に加え、Cursor ProやDevinなど自律型コーディングIDEの需要も高く、アカウント単価は2026年に平均で2倍以上に跳ね上がった。
認証情報の入手経路として広く使われるのがインフォスティーラーだ。LUMMAC.V2、STEALC.V2、VIDAR、ACRSTEALERなどの制御者は、従来のAIブラウザプロファイルに加えて、AI開発者設定を狙い始めた。2026年5月には、ACRSTEALERがClineのsecrets.jsonやContinue AIのconfig.yamlを標的にする命令を配布した事例が確認されている。これらのファイルには平文のAPIキーが保存されることがあり、APIキーとはシステム同士がやりとりするための合言葉のようなものだ。これが漏れると、被害者の有料モデル利用枠を攻撃者が直接使えてしまう。
LLMJackingも増えている。LLMJackingとは、被害者のクラウド環境を侵害して計算資源を乗っ取り、AIワークロードを不正に実行する手口だ。2026年4月の侵入事例では、GitHubの個人アクセストークン（PAT）が露出したことが起点となった。攻撃者はこれを使ってクラウド環境に初期アクセスし、不正なAIインフラを展開して高性能計算資源を拡張した。
LLMJackingは、被害者が気づかないうちに高額なクラウド利用料が発生する点でも厄介だ。GTIGは2026年に入り、地下フォーラムでのAIアカウント売買と並んでこの手口の増加を確認している。
企業が取るべき対策とGoogleの防御
Googleは多層的な防御戦略を取っている。モデルレベルの安全策、脅威インテリジェンス、封じ込めプロトコルを組み合わせ、モデル抽出攻撃に対してはリアルタイム防御を展開する。モデル抽出攻撃とは、既存のAIモデルに大量の質問をして応答を学習させ、模倣モデルを作る手口だ。Googleは不正な模倣モデルの性能を落とし、専有ロジックの複製を検知する対策を導入している。
2026年6月には、中国拠点のサイバー犯罪サービス「Outsider Enterprise」を遮断した。このサービスはフィッシングキットを提供し、Googleなどの有名ブランドを大量になりすましていた。運営者はGeminiを使ってコードを生成し、キャンペーンを大規模に実行していた。GoogleがGeminiの悪用で法的措置に踏み切ったのはこれが初めてだ。
企業向けにはGoogle AI Threat Defense（AITD）を提供している。AITDはGeminiなどの推論力、Wizのリスク優先順位付け、GeminiとCodeMenderの自動修復、Mandiantの最前線インテリジェンスを統合した自律型アーキテクチャだ。軽量モデルで継続スキャンを行い、高リスクの脆弱性には特化型の先端モデルを割り当てる。さらに脆弱性検出と自動パッチ適用に特化したGemini 3.8 Flash Cyberも投入している。
実務面では、クラウド認証情報の定期的なスキャンとローテーション、GitHubの個人アクセストークン管理、AIアカウントの多要素認証、オープンソース依存関係の精査が基本になる。AIを業務に導入する場合は、通常のセキュリティ監視に加えて、AI特有の脅威を検出する仕組みを組み込むことが欠かせない。
この記事のポイント
- 攻撃者はチャット型のAI利用から、自律的に動くエージェンティックAIへ移行している
- 2026年第2四半期には6時間未満で数千件の認証情報を奪うキャンペーンが確認された
- AIコーディングの普及でオープンソース経由のサプライチェーンリスクが拡大している
- 専有AIモデルやAPIクレデンシャルが窃取と恐喝の標的になっている
- AIアカウントの売買とLLMJackingが増加し、クラウド計算資源が乗っ取られている
- 防御には認証情報管理、依存関係の精査、AI特有の脅威検出が欠かせない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GPT-Live-1がAPIで提供開始。同時通話型音声AIで割り込み処理が大幅改善
OpenAIが2026年9月10日、音声対話モデル「GPT-Live-1」のAPI提供を開始した。このモデルは同時に聞いて話すフルデュプレックス方式を採用し、従来の音声AIが抱えていた会話の遅延や不自然な割り込みを大幅に改善する。音声フロントエンド部分の料金は1分あたり0.05ドルに設定されている。
GPT-Live-1はChatGPTでの先行導入を経て、今回API経由で開発者に開放された。音声認識と音声合成を単一モデルに統合した設計が特徴で、人間同士の会話に近い自然なインタラクションを実現する。この記事ではGPT-Live-1の技術的な仕組み、性能評価、料金体系、そして開発者にとっての活用可能性を解説する。
単一モデルで実現する同時対話の仕組み
従来方式の構造的な課題
従来の音声AIは3つの工程を連結する方式が主流だった。まず音声をテキストに変換するSTT（音声認識）、次に内容を理解して回答を考えるLLM（大規模言語モデル）、最後にテキストを音声に戻すTTS（音声合成）だ。各工程が別々のモデルで処理されるため、段階ごとに処理待ちの遅延が積み重なる。
この構成では割り込みへの対応も難しい。ユーザーが話し始めるタイミングを検知するには、音声入力を常時監視しながら出力側の状態も把握しておく必要がある。3つのモデルをまたぐ情報の受け渡しにタイムラグが生じるため、人間同士の会話のような即時の割り込みは実現しづらかった。開発者は各段階のつなぎ目を手動で調整しなければならず、運用の手間も大きい。
単一モデルへの統合がもたらす変化
GPT-Live-1はSTTとLLMとTTSを単一モデルに統合する。入ってくる音声と出ていく音声を同じモデル内で同時に推論するため、段階間のつなぎ目が構造的に存在しない。これにより遅延が減るだけでなく、相手の言葉を遮って新しい質問を投げかけたり、相槌を打ったりする自然な会話のリズムを保てる。
背景ノイズや無音状態の扱いも改善された。従来方式では無音を「発話の終わり」と誤判定して会話を切ってしまう事態が起きやすかったが、GPT-Live-1は静寂を会話の一部として処理できる。ユーザーが考え込んでいる時間を待つ、周囲の雑音に反応しない、といった対話の質を左右する細かな制御がモデル側で吸収される。
3段階のモデルを連結する方式では、それぞれの処理待ち時間が会話のテンポを損なっていた。GPT-Live-1はこの問題を単一モデルへの統合で解決している。
割り込み処理の改善がビジネス効果を生む
音声エージェントの実用化で最大の障壁が「割り込み」への対応だ。人間同士の会話では、相手の話の途中で情報を追加する、言い直す、短い相槌を打つ、といった行為が自然に発生する。従来のターン制システムではこの対応が難しく、一方が話し終えるのを待ってから返答する不自然な体験になりがちだった。
OpenAIの公開した早期評価では、語学学習プラットフォームのSpeakがGPT-Live-1を導入した結果、学習者が考える時間を確保できるようになり、割り込み回数が従来のターン制システムと比べて約80%削減された。この数字は、音声AIが教育分野で実用化できる水準に近づいていることを示している。学習者が発話を躊躇しても、AIが先回りして話し始めない。この「待つ」能力が学習体験の質を大きく左右する。
またGPT-Live-1は、短い笑い声や「うん」「ええ」といった相槌、近くにいる他者への短い話しかけなど、会話に混じる非定型的な音声を適切に処理できる。これらは従来の音声認識では誤検知や過剰反応の原因になりやすかったが、GPT-Live-1は文脈を踏まえて取捨選択する。
従来のターン制システムでは、STEP 2の割り込みを検知するまでにタイムラグが発生し、ユーザーが話し終えるのを待ってから処理を切り替える必要があった。GPT-Live-1は音声入力を常時監視しているため、この切り替えがほぼ即座に行われる。
バックエンド推論モデルへの委任という設計
タスクに応じたモデル選択
GPT-Live-1の設計で注目すべき点は、すべてを自身で解決するわけではないという姿勢だ。音声レイヤーと推論レイヤーを分離し、複雑な判断やツール呼び出しはバックエンドのテキストモデルに委任できる。開発者はGPT-6 Astraやサードパーティモデルを組み合わせ、タスクの難易度に応じて推論深度を使い分けられる。
たとえばレストランの予約確認や配送状況の案内といった定型的なタスクには軽量なモデルを使い、複雑な顧客対応には高性能なモデルを割り当てる構成が可能だ。推論深度と応答速度とコストをタスクごとに最適化できるため、大規模な音声エージェントの運用コストを抑えながら品質を維持できる。この柔軟性は、単一モデルですべてを処理する構成では得られない利点だ。
音声処理と推論を分離することで、タスクごとに最適なモデルを組み合わせられる。この柔軟性がGPT-Live-1の大きな特徴だ。会話を続けながらバックグラウンドで推論が進むため、ユーザーを待たせない体験も実現できる。
ネイティブ機能の充実
GPT-Live-1はASR（自動音声認識）のトランスクリプトと応答テキストをネイティブに提供する。英数字の認識精度が高く、特定のキーワードを優先的に認識させるキーワードバイアス機能も備える。ターン制モデルではないが、明示的な発話ターンの境界を検出するターン検出機能もネイティブサポートしており、既存のターン制ベースのワークフローからの移行も容易だ。
開発者はシステムプロンプトを通じてエージェントの声のトーン、話す速度、会話スタイルを制御できる。音声の選択肢も従来のリアルタイム音声から大幅に拡充され、アクセントや方言、言語のバリエーションが増やされる予定だ。音声オプションと言語の対応範囲は今後数か月にわたって継続的に拡大される。
評価指標と料金体系
ベンチマークで示された実力
OpenAIの評価では、GPT-Live-1はFull Duplex BenchのスコアをGPT-Realtime-2.1から30ポイント改善した。特にターンテイクの遅延と対話的行動で大きな向上が見られた。GPT-6 Astra（中程度の推論エフォート）と組み合わせた構成では、音声エージェントの総合知能を測定するTau3ベンチマークで1位を獲得している。
評価対象は航空、小売、通信の各ドメインにおける音声カスタマーサービス対応、銀行業務の音声サポート、発話の一時停止への対応、ターンテイク、割り込み処理、バックチャネル（相槌や短い応答）への反応、自然な間や言い直しを含む音声経由のツール呼び出しなど多岐にわたる。満足度と完了率の両面で高いパフォーマンスを示した。
料金体系と展開オプション
GPT-Live-1の料金は、音声フロントエンド部分が1分あたり0.05ドルだ。バックエンドの推論モデルとエージェントハーネスは別途組み合わせる構成になる。推論深度の異なるモデルを使い分けることで、プロダクトの要件に合わせたコスト設計が可能だ。独自のカスタム音声へのアクセスは、OpenAIの営業チームへの問い合わせを通じて申請する。
電話回線を使ったフルデュプレックス音声エージェントの展開もサポートされている。レストラン予約からカスタマーサポートまで、従来は有人対応が必要だった領域に音声AIを導入できる。また、リアルタイム音声対話を企業内システムに統合する「OpenAI Presence」と組み合わせることで、社内システムへのアクセス、承認済みアクションの実行、必要時の人間へのエスカレーションまでを含むエンタープライズ向けの音声エージェントも構築できる。
音声AIの実用化が進む中で、GPT-Live-1のAPI提供は開発者にとって重要な転換点になる。フルデュプレックス方式の導入により、音声エージェントの体験品質が人間との自然な対話に近づくからだ。特に割り込み処理の改善は、教育、カスタマーサポート、ヘルスケアなど対話の質が成果に直結する分野で大きな意味を持つ。従来のターン制音声AIでは実現できなかった「考えながら話す」「話の途中で方向転換する」といった人間らしい対話が、API経由で誰でも利用できるようになった点が重要だ。
この記事のポイント
- GPT-Live-1がAPIで提供開始。同時に聞いて話せるフルデュプレックス音声モデルだ
- 単一モデルで音声入出力を処理し、STTとLLMとTTSをつなぐ従来方式の遅延を構造的に解消する
- Speak社の評価では割り込み回数が約80%削減された
- バックエンドのテキストモデルに推論を委任できる柔軟な構成が特徴だ
- 料金は音声フロントエンドが1分あたり0.05ドル。電話回線への展開も可能だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
PerplexityがGPT-6 Astraを本番採用、監視頻度が大幅に減少
PerplexityがGPT-6 Astraを本番システムに採用した。コミュニケーション作成、ソフトウェア変更、本番環境の監視までを任せている。従来モデルと比べてチェック頻度が大幅に減ったという。
PerplexityはAI回答エンジンとして検索と精度に注力してきた。大量の情報を処理する能力が重要であり、コード生成の精度が上がるたびに検索エンジンも改善してきた。今回のAstra採用はその延長線上にある。
なぜ今回の発表が注目されるのか。理由は「エンドツーエンドのシステムをモデルに任せる」という信頼度の高さにある。コード生成だけでなく、テスト、監視、コミュニケーションまで一貫して任せる事例はまだ少ない。
GPT-6 Astraを本番運用に組み込んだPerplexity
OpenAI Blogの記事によると、PerplexityはAstraを使ってコミュニケーションの作成、ソフトウェアの変更、本番システムの監視を行っている。Perplexityの共同創業者兼CSOであるJohnny Ho氏は、以前の世代のモデルでは実現できなかった方法で、これらのタスクをモデルに任せられると述べている。
コミュニケーション作成からソフトウェア変更まで
従来のAIモデルはコード生成や文章作成など特定のタスクに強かった。しかし実世界のシステムに適用するには、人間が細かく確認する必要があった。Astraではコミュニケーションの作成、システムの編集、本番ソフトウェアの監視を一つのモデルにまとめて任せられる。
監視頻度が大幅に低下
Johnny Ho氏は、完全なエンドツーエンドのシステムをAstraに信頼して任せられ、以前の世代のモデルと比べてチェックする頻度がはるかに少なくなったと述べている。これはモデルの判断精度と信頼性が実用レベルに達したことを示す。
この比較は、モデルの信頼度が実運用に耐える水準へ上がったことを示す。人による確認作業が減ることで、開発チームはより高度な判断や新機能の設計に集中できる。
コード生成の精度向上が検索エンジン改善に直結
PerplexityはAI回答エンジンとして、検索と精度を最重要視してきた。Johnny Ho氏によると、モデルがコードを書く能力を高めるたびに、Perplexityの検索エンジンも改善してきたという。より良いプログラムを作れるようになると、ウェブと内部情報を検索し、それを簡潔に要約する能力も上がる。
検索と要約の精度が上がる循環
コード生成能力の向上は、検索プログラムの品質に直接影響する。検索プログラムが優れていれば、より関連性の高い情報を集め、より簡潔な回答を生成できる。Perplexityはこの循環をエンジンの中核としてきた。
実世界システムへの適用が課題だった
Johnny Ho氏は、本当の課題は情報処理の側面を実世界のシステムに適用することだと指摘する。生成したコードを実際のソフトウェアに変更として反映し、本番環境の監視まで行うのは、従来モデルでは難しかった。Astraはこの壁を越えた。
この流れが実現したことで、Perplexityはモデルを「情報処理の道具」ではなく「システム運用の担い手」として扱えるようになった。
エンドツーエンドのテストを自動生成するAstra
Johnny Ho氏にとって、AIの最も有用な応用の一つはコードのテストだ。手動テストに割ける時間は限られている。そこでAstraにアプリケーションの周りに小さなテストプログラムを構築するよう依頼する。
モックサービスの自動生成
モデルは、別のサービスが送信するような現実的な応答を生成する。例えば言語モデルAPIやコネクタの応答を模倣する。モデルがサービスの代わりを務めることで、アプリケーションの応答を確認し、ワークフローを最初から最後までテストできる。
この仕組みにより、開発者は限られた時間でもアプリケーション全体の動作を網羅的に確認できる。モック応答が現実的であるほど、テストの信頼性も高まる。
ワークフロー全体を検証
モデルがサービスを代行することで、アプリケーションの応答を確認し、ワークフローを最初から最後までテストできる。これは単体テストだけでなく、統合テストやシステムテストに近い。従来は人手や専用ツールが必要だったが、Astraは自然言語の指示だけでこれを実行する。
AIエージェントの信頼性が変える開発フロー
Perplexityの事例は、AIエージェントの信頼性が実用段階に入ったことを示す。チェック頻度の減少は、モデルの判断が人間の承認なしにシステムを変更できる水準に達したことを意味する。開発フローそのものが変わりつつある。
チェック頻度の減少が意味すること
チェック頻度が減るということは、モデルが失敗したときの影響範囲が大きくなる可能性もある。しかしPerplexityは、モデルが生成する応答の現実性と、テストの網羅性を評価した上で、この判断を下している。信頼は実績の積み重ねから生まれる。
開発者の役割変化
モデルがコード生成、テスト、監視までを担うようになると、開発者の役割は「命令を出す人」から「結果を評価し、方向性を決める人」へ移る。Johnny Ho氏がテストコード生成を「最も有用な応用の一つ」と述べるのは、この変化を象徴している。
この記事のポイント
- PerplexityがGPT-6 Astraを本番システムに採用し、コミュニケーション作成、ソフトウェア変更、本番監視を任せている
- コード生成能力の向上が検索エンジンの改善に直結し、実世界システムへの適用が可能になった
- Astraはモックサービスを自動生成し、エンドツーエンドのテストを自然言語の指示だけで実行する
- チェック頻度が大幅に減り、開発者の役割は実行から評価と方向性決定へ移行しつつある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
FTCが個人別価格表示に透明性要求。WooCommerce事業者の備え
米FTC（連邦取引委員会）がパーソナライズドプライシング、つまり顧客データに基づいて個人ごとに価格を変える手法に対する執行方針を提案した。2026年8月19日付の提案で、この手法そのものを禁止するものではない。価格がどのように決まったのかを消費者に明確に伝える透明性を求める内容だ。
ECサイトを運営する事業者、特にWooCommerceを使う中小企業にとって、今後の価格戦略とデータ活用の見直しにつながる重要な動きである。パブリックコメントは2026年9月25日まで受け付けている。
FTCがパーソナライズドプライシングの透明性を要求
パーソナライズドプライシング（個人別価格設定）とは、顧客の購買履歴や行動データを使って、同じ商品でも顧客ごとに異なる価格を提示する手法だ。FTCはこの手法を禁止する権限はないとしつつ、FTC法第5条（不公正または欺瞞的な行為の禁止）を根拠に透明性の確保を図る。
FTCが事業者に求めている内容は大きく3つある。
- 価格がパーソナライズされたものであることの明示
- なぜその価格になったのかの理由
- どのようなデータを使ったのかの説明
提案された執行方針の内容
FTCが示した方針では、価格がパーソナライズされたことを消費者に知らせる免責事項の表示が必要になる。たとえば「この価格はあなたの購買履歴に基づいてパーソナライズされています」といった説明を商品ページに追加することが想定される。
このデモは、価格表示に透明性の説明を追加する変化を示している。FTCの方針は、価格そのものの変更ではなく、消費者への説明責任を問うものだ。
マーケターへの影響
ここ数年、マーケターはサードパーティCookieの衰退を受けて、ファーストパーティデータ（自社で直接収集した顧客データ）を集めるよう奨励されてきた。そのデータ活用が「体験のパーソナライズ」から「価格のパーソナライズ」にまで拡大しているケースがある。FTCの提案は、この流れに透明性という歯止めをかけるものだ。
たとえば、ある小売業者が顧客の過去の購買履歴を分析し、この顧客は高くても買う傾向があると判断して、同じ商品を他の顧客より高い価格で提示するケースを考えてみる。FTCの提案では、この場合「価格が過去の購入履歴に基づいてパーソナライズされている」という説明が必須になる。
パーソナライズドプライシングとダイナミックプライシングの違い
FTCはパーソナライズドプライシングとダイナミックプライシングを明確に区別している。この区別は重要だ。ダイナミックプライシング（変動価格設定）は需要と供給に応じて価格を変動させる手法で、航空券やホテルの宿泊料金、配車アプリのサーチャージが代表例だ。繁忙期や悪天候時に価格が上がるのは、個人のデータではなく市場全体の需給に基づく。
一方、パーソナライズドプライシングは個人のデータに基づく。過去の購買履歴から「この顧客は高くても買う傾向がある」と判断して、同じ商品を他の顧客より高い価格で提示するようなケースだ。
この比較図は、2つの価格設定手法の根本的な違いを示している。FTCが問題視するのは後者のパーソナライズドプライシングである。
FTCが監視対象として挙げた具体例
FTCが挙げた具体例はかなり踏み込んでいる。外出が難しい消費者への食品販売、複数の子供のために牛乳を買う消費者、葬儀や緊急の用事で移動する消費者、医療緊急時の交通手段を必要とする消費者、犯罪被害に遭った直後に防犯カメラを探す消費者、店舗や駐車場にいながら小売サイトを閲覧する消費者などが挙げられた。これらは消費者が弱い立場にある状況で、パーソナライズドプライシングが使われることを特に問題視している。
この具体例から読み取れるのは、FTCが「事業者はデータをたくさん集めているが、すべてを理解しているわけではない」というメッセージをマーケターに送っている点だ。
WooCommerce事業者への実務的影響
日本のEC事業者にとって、FTCの方針は直接の規制対象ではない。ただし、海外向けに販売するWooCommerceサイトや、グローバルに展開する企業は注意が必要だ。また、日本でも個人情報保護法や景品表示法の観点から、同様の透明性が求められる可能性がある。
動的価格設定プラグインの注意点
WooCommerceでパーソナライズドプライシングを実装する場合、動的価格設定プラグインを使うことが多い。これらのプラグインは、顧客のログイン情報や過去の注文履歴、カートの中身などに基づいて価格を変更できる。今回のFTC方針を踏まえると、こうした機能を使う際に「価格がパーソナライズされていること」を明示する仕組みを追加する必要が出てくる。
このフローは、WooCommerceでパーソナライズドプライシングを導入する際の基本的な流れを示している。STEP 4の透明性の説明が、FTC方針への対応に該当する。
データガバナンスの課題
FTC方針への対応で最も難しいのが、データの出所と利用目的の管理だ。顧客データはCDP（カスタマーデータプラットフォーム）、ロイヤルティプログラム、パーソナライゼーションエンジン、AIエージェントなど複数のシステムに分散している。どのデータを価格設定に使ったのかを追跡できる状態にしておく必要がある。
MarTechの記事で、In-Store MarketplaceのPaul Brenner氏は「データの許可利用範囲と禁止範囲の線引きが難しく、多くの加盟店がシステムと透明性を備えていない」と指摘している。この課題は、FTCの執行方針が現実になった場合、EC事業者にとって大きなハードルになる。
今すぐできる3つの対策
FTCの方針はまだ提案段階だが、今から準備しておくことで、執行が始まった際の混乱を避けられる。具体的には次の3つだ。
1つ目は、価格表示に説明を追加すること。パーソナライズドプライシングを使っている場合、その旨を商品ページやカート画面に明記する。使っていない場合でも、価格がどのように決まるのかを説明しておくと、消費者の信頼につながる。
2つ目は、データ利用の同意取得を見直すこと。他社から取得したデータを価格設定に使う場合、消費者がその用途に同意しているかを確認する必要がある。単に「同意があるはず」と仮定するだけでは不十分だ。
3つ目は、データの利用目的を文書化すること。価格設定にどのデータを、どのように使っているのかを社内で整理し、必要に応じて開示できる状態にしておく。これがデータガバナンスの第一歩になる。
この記事のポイント
- FTCはパーソナライズドプライシングそのものを禁止せず、透明性の確保を求めている
- パーソナライズドプライシングは個人データに基づく価格設定で、ダイナミックプライシングとは異なる
- WooCommerce事業者は動的価格設定プラグインの利用時に説明表示を追加する必要がある
- データの出所と利用目的を追跡できるデータガバナンスが今後の課題になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
PlanetScaleの新データベースNekiが秒間1億1800万クエリを達成。512シャード構成の全容
PlanetScaleが新データベースサービスNekiで秒間1億1800万クエリを記録した。512シャード構成で1.22 PiBのデータを読み込み、読み取り中心のベンチマークで達成した数字だ。
シャード数を10倍にするとスループットもほぼ10倍になる線形スケーラビリティが確認されている。p99レイテンシはルータで6.06ms、エラー率は約180万クエリに1回という安定性も示した。
この記事ではベンチマークの条件と構成、結果の意味を初心者にも分かるように解説する。
秒間1億1800万クエリの衝撃
Nekiとは何か
NekiはPlanetScaleが9月10日にプラットフォームプレビューとして公開した新しいデータベースサービスだ。PostgreSQL互換で分散アーキテクチャを採用している。シャードとはデータを複数のサーバーに分割して保存する単位で、負荷を分散させるための基本構造である。
QPSとは1秒間に処理できるクエリ数のこと。データベースの性能を示す指標のひとつだ。例えばECサイトの商品検索やブログのコメント表示など、読み取り処理がどれだけ速く応答するかに関わってくる。
100万QPSから1億1800万QPSへの経緯
PlanetScaleが最初に設定した目標は100万QPSだった。5シャード構成でこの目標をすぐに達成した。その後、どこまで伸ばせるかを確認するため、50シャード、512シャードと段階的に拡大していった。
ベンチマークの条件を理解する
シンプルなクエリ構成
今回のベンチマークは非常に単純な構成で行われた。単一シャードのポイントセレクトと呼ばれる処理で、主キーを使って1行だけを取得する。書き込みはなく、テーブル結合もなく、複数シャードにまたがるクエリも含まれていない。
各シャードが受け取る作業は完全に独立している。つまり1つのクエリが複数のシャードにまたがることはない。負荷はシャードごとに分離され、それぞれが200k QPSを維持することを目標に設計された。
このデモはクエリの流れを示している。クライアントからの読み取り要求はNekiルータが受け取り、適切なPostgresシャードへ振り分けられる。各シャードは主キーで1行を取得して結果を返すだけだ。
ベンチマークの注意点
公開された数字を評価する際に注意すべき点がいくつかある。シャードはプライマリのみでレプリカを持たない。ワークロードは読み取り専用で、測定中にフェイルオーバーも発生していない。理想的に整えられた環境であることは押さえておきたい。
書き込みを含む実際のサービス運用では、この数字をそのまま期待できるわけではない。とはいえ、読み取り中心のワークロードにおいて分散データベースがどれだけ拡張できるかを示す実証データとして価値が高い。
線形スケーラビリティの実証
シャード数とスループットの相関
シャード数を増やした結果、スループットは驚くほどきれいに伸びた。5シャードで999,624 QPS、50シャードで9,923,900 QPS、512シャードで118,538,803 QPSだ。シャード数を10倍にすると、スループットもほぼ10倍になっている。
このデモはシャード拡大に伴うQPSの推移を示している。5シャードから50シャードではシャードあたりの処理速度が0.8%以内に収まった。512シャードでは各シャードにまだ余力があったため、負荷を上げてシャードあたり231,521 QPSに達した。
シャードあたりの安定性
線形スケーラビリティとは、サーバーを追加した分だけ性能が比例して伸びる性質を指す。通常はシャード数を増やすと管理オーバーヘッドやデータ再分散のコストが増え、性能の伸びが鈍っていくことが多い。
Nekiの場合は5シャードから50シャードへ拡大しても、シャードあたりのQPSが199,925から198,478とほぼ一定だった。この安定性が線形スケーラビリティを支えている。
118.5M QPS達成時の構成とレイテンシ
インスタンス構成
最大記録を達成した構成は512シャードで、各シャードにPostgreSQLプライマリが1台ずつ割り当てられた。インスタンスタイプはr8g.16xlargeだ。また480台のNekiルータが個別の8xlargeインスタンスで動作し、1.22 PiBのデータを扱った。
PiBはペビバイトと読み、1 PiBはおよそ1,125テラバイトに相当する。1.22 PiBは膨大なデータ量で、一般企業のデータベース規模を大きく超えている。
このデモは最大構成の主要スペックをまとめたものだ。512シャードと480ルータ、1.22 PiBのデータ量、そしてルータ側でp99 6.06msのレイテンシという結果になった。
レイテンシとエラー率
p99レイテンシとは、全リクエストの99%がその時間以内に処理されたという指標だ。平均値ではなく最悪に近い部分を見るため、体感速度に近い評価ができる。今回はルータで6.06ms、クライアントで13.95msだった。
エラーは毎秒67回で、約180万クエリに1回の割合だ。IOPSは1秒あたりの入出力操作回数のことで、今回の構成では全体で15.8M read IOPS、つまり毎秒1,580万回の読み取り操作を処理した。ネットワークは毎秒2 Tbを超える転送量を記録している。
この結果から見える実用性と今後の課題
書き込みを含まない点の評価
今回のベンチマークは読み取り専用であり、書き込みを含む実運用の性能を直接示すものではない。書き込み処理では複数の更新をまとめて確定させるトランザクション整合性や、データをディスクに確実に書き込む同期処理が必要になる。このため読み取りよりも時間がかかり、性能も出にくい。
それでも、検索、レコメンデーション、レポート、ダッシュボードなど読み取り中心のサービスでは、この数字が大きな参考になる。特にデータ量が増え続けるサービスで、シャード追加だけで性能を伸ばせることは運用面の負担を大きく減らす。
実サービスへの展開
線形スケーラビリティが確認されたことで、キャパシティプランニングが大幅に簡単になる。シャード数を10倍にすれば性能も10倍になるというシンプルな関係は、成長期のスタートアップにとって心強いデータだ。
PlanetScaleはこのベンチマークに至るまでのエンジニアリングと課題を将来記事で公開すると予告している。書き込みを含むテストやフェイルオーバー時の挙動も含め、実運用に近い条件での検証が今後重要になる。
この記事のポイント
- Nekiが512シャード構成で秒間1億1800万クエリを記録した
- シャード数を10倍にするとスループットもほぼ10倍になる線形スケーラビリティを確認
- ベンチマークは読み取り専用で、主キーによる1行取得という単純な構成
- p99レイテンシはルータで6.06ms、エラー率は約180万クエリに1回
- 書き込みを含む実運用環境での検証は今後必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
PlanetScaleがNekiを発表。Postgresを分散シャーディングで拡張する新サービス
PlanetScaleが新サービス「Neki」を発表した。Postgresデータベースを複数マシンに分散させ、スケールさせるためのシャーディング基盤だ。本日からプラットフォームプレビューとして利用できる。
Nekiの特徴は、各シャードに本物のPostgresが動いていることだ。既存のドライバーやORM、接続文字列がそのまま使えるため、アプリケーション側の変更を最小限に抑えられる。
急速に成長するPostgresデータベースの運用に悩むチームにとって、新たな選択肢になる可能性がある。本記事ではNekiのアーキテクチャと、従来の分散アプローチとの違いを解説する。
Nekiの概要とアーキテクチャ
NekiはPlanetScaleが8年間培ってきたシャーディングMySQLの運用経験をもとに設計された。大規模な本番環境で毎秒数百万クエリを処理してきた知見が、Postgres向けに再構築されている。
実Postgresを維持したまま分散
各シャードは完全なPostgresクラスターとして構成される。1つのプライマリと最低2つのレプリカが3つのアベイラビリティゾーンに分散する。カスタムストレージエンジンは使わないため、拡張機能、SQLサポート、性能は通常のPostgresと同じように動作する。
アプリケーションはNekiルーターに接続する。ルーターは標準のPostgresワイヤープロトコルを話すため、既存のドライバーやORM、接続文字列がそのまま機能する。接続先を変更するだけで移行できる設計だ。
アプリケーションから見ると接続先はルーターの1つだけだ。シャード構成はルーターが内部で処理するため、クライアント側の変更は不要になる。
データトポロジーでシャードキーを制御
シャードキーの選択は利用者が行う。JSON形式のデータトポロジーで、テーブルをどのようにグループ化し、どのシャードに分散させるかを定義する。シャードインデックスでルーティングに使うカラムとハッシュ方法を指定し、シャードグループでテーブル群をどのシャードセットに配置するかを制御する。
最初からシャーディングする必要はない。単一プライマリとレプリカで構成し、1台のマシンで足りなくなった時点でリシャーディングを実行すればよい。
Nekiの4つの構成要素
Nekiは4つの主要コンポーネントで構成される。ルーター、シャードグループ、接続プーリング、コントロールプレーンだ。それぞれが連携して分散Postgresを実現する。
ルーター
ルーターはアプリケーションからの最初の接続先だ。Postgresワイヤープロトコルを解釈し、クエリを解析する。分散クエリプランナーがどのシャードにクエリを送るかを決定し、結果を1つのストリームにまとめ直す。ルーターは垂直方向にも水平方向にも拡張できるため、単一ルーターがボトルネックになることはない。
シャードグループと接続プーリング
シャードはシャードグループにまとめられる。異なるテーブルやワークロードを異なるシャードセットに配置できる。各シャードには構成プロファイルがあり、インスタンスサイズ、レプリカ数、ストレージ、Postgresパラメータ、拡張機能を個別に設定できる。
接続プーリングではサイドカーが各Postgresインスタンスの横で動く。Nekiはルーター側とPostgres側の両方の接続を制御するため、プールサイズを各インスタンスの実際の処理能力に合わせて調整できる。PgBouncerを単純に前に置くより精度が高い。
コントロールプレーン
コントロールプレーンは全ノードの健全性を監視する。計画的なスイッチオーバーと予期しないフェイルオーバーを実行し、リシャーディング、スキーマ変更、バージョンアップグレードのワークフローを調整する。データトポロジーはJSON設定としてルーターにキャッシュされ、すべてのクエリプランで参照される。
既存の分散Postgresアプローチとの比較
急速に成長するPostgresデータベースには複数の問題がある。テーブルが大きくなりすぎてバキュームやインデックス作成がトラフィックに影響する。バックアップに数時間かかり、接続数に制限があり、スキーマ変更にメンテナンスウィンドウが必要になる。トランザクションラップアラウンドも対応が必要な課題だ。
アプリケーションレベルシャーディングの課題
アプリケーションレベルシャーディングでは、ルーティングをコードに埋め込むことになる。アプリケーションがシャードキーを意識し、どのシャードに接続するかを自前で管理する必要がある。追加のライブラリや複雑なロジックがコードに混ざり、保守が難しくなる。
Postgres互換分散DBの課題
Postgres互換をうたう分散データベースも存在するが、いくつかの妥協を強いられる。シャードキーが隠され、拡張機能が使えなくなり、複雑さとレイテンシが増加する。問題が起きた時のデバッグも困難になる。
Nekiのアプローチ
Nekiは「Postgresに固執する。回避策を使わない。偽装しない。逸脱しない」という原則で設計された。各シャードに本物のPostgresを配置し、ルーターが通信を仲介する。これにより拡張機能もSQLサポートも性能も、通常のPostgresと同じ挙動を保てる。
オンラインワークフロー
従来はメンテナンスウィンドウを設定して行っていた作業が、Nekiでは組み込みワークフローとして実行される。ワークフローは新しいターゲットノードをプロビジョニングし、レプリケーションで追いつかせ、トラフィックを切り替え、古いノードを破棄する。すべてアプリケーションが使うのと同じpsql接続から実行できる。
スキーマ変更とバージョンアップグレード
スキーマ変更はオンラインで実行される。トラフィックに影響を与えず、ダウンタイムなしでテーブル定義を変更できる。バージョンアップグレードも同様の仕組みで、新しいバージョンのノードを作成し、レプリケーションで同期させてから切り替える。ゼロダウンタイムのアップグレードが実現する。
リシャーディングとフェイルオーバー
リシャーディングもワークフローとして実行される。既存のクラスターに対して実行し、データを新しいシャード構成に移行する。計画的なフェイルオーバーと予期しないフェイルオーバーの両方に対応し、コントロールプレーンが正常性を監視しながら自動で切り替えを行う。
NekiにはPlanetScaleの既存機能も含まれる。Insights、スキーマレコメンデーション、ブランチ、MCPなどの機能が利用できる。
プラットフォームプレビューの注意点
プラットフォームプレビュー期間中は、本番ワークロードにNekiを使用してはならない。製品はまだ変更中であり、一部の変更は互換性を壊す可能性がある。
プレビュー期間中のフィードバックはサポートチケットまたはDiscordで受け付けている。大規模なPostgresクラスターを持つチームは、プライベートデモを依頼することもできる。スキーマやクエリパターンを分析してもらい、シャーディング方法について具体的な提案を受けられる。
Nekiを試すには、PlanetScaleにサインインし、プラットフォームプレビューにオプトインして、Nekiクラスターを作成する。公式ドキュメントでアーキテクチャの詳細やシャーディング方法を確認できる。
この記事のポイント
- Nekiは各シャードに本物のPostgresを動かす分散サービスである
- ルーターがPostgresワイヤープロトコルを解釈し、分散クエリを処理する
- スキーマ変更やリシャーディングなどの運用作業はオンラインで実行できる
- 既存のドライバーとORMが接続文字列を変えるだけで使える
- プラットフォームプレビュー期間中は本番運用に使わないこと
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.2開発サイクル始動、Gutenberg 23.8と23.9の開発者向け新機能まとめ
WordPress 7.1「Mary Lou」が2026年8月にリリースされた。レスポンシブスタイルステート、アイコン登録機能などが含まれる大型アップデートだ。まだ更新していない場合は早めの対応が推奨される。
続くGutenberg 23.8と23.9では開発者向けの改善が多数入っている。コードリファレンスの実行可能コード例、ブロックのキーボードショートカット宣言API、テーマJSONスキーマの修正など、実務に直結する変更が多い。
WordPress 7.2のBeta 1は2026年10月20〜22日、正式版は12月8〜10日に予定されている。本記事では2026年9月時点の開発者向け変更点を整理して解説する。
コードリファレンスがブラウザ上で実行可能に
WordPress公式のコードリファレンスで大きな変化があった。コード例をその場で実行できるようになったのだ。WP_HTML_Processorクラスのclass_list()メソッドのページを開き、「Run」ボタンを押すと、Playgroundを使った実際のWordPress環境でコードスニペットが実行される。
従来のコードリファレンスは静的ページであり、コード例を読むだけだった。だが今回の変更で、関数の動作確認がブラウザ内で完結する。ドキュメントと関数定義が同じファイルに存在するため、コードと実行結果の乖離が起きにくい構造だ。
実装方法はDocBlocksの中に「php interactive」というコードフェンスを書くだけ。関数の説明コメント内に実行可能なコードを埋め込む仕組みで、ドキュメント提案として長く議論されてきた内容が実現した形だ。
ブロック開発の新APIと改善点
キーボードショートカットを宣言的に定義可能に
Gutenberg 23.9では、ブロックのキーボードショートカットを宣言的に登録するAPIが追加された。これまで「Alt+Shift+2」で段落をHeading 2に変換する機能はハードコードされており、エディタパッケージごとに個別実装が必要だった。
新しいAPIでは、ブロックバリエーションにshortcutオブジェクトを指定するか、ブロック変換にshortcuts配列を指定する。後者の場合、1つの変換で最大6つのショートカットをまとめて定義できる。
インナーブロックテンプレートがブロック設定へ移行
Gutenberg 23.8では、templateとtemplateInsertUpdatesSelectionがブロックタイプ設定として追加された。従来のInnerBlocksコンポーネントのpropsを使う方式は非推奨となり、WordPress 7.2リリース前に移行することが推奨される。
この変更の背景にはリアルタイム共同編集の開発がある。propsベースの方式はマウント後にテンプレートを適用するため、3人の共同作業者がドキュメントを開いている場合、Listブロックを挿入すると3つのリスト項目が生成される問題があった。ブロックタイプ設定として宣言することで、ブロックとテンプレートが単一のストア操作で処理される。
kebab-case変換がJSとPHPで完全一致
WordPress Coreの_wp_to_kebab_case()は、数字の扱いに関して一般的なライブラリと異なる挙動をしていた。今回、JavaScript側でも同じ変換結果を返す@wordpress/kebab-caseパッケージが公開された。
kebabCase(‘font2xl’) → font2xl
kebabCase(‘white4th’) → white4th
kebabCase(‘font2xl’) → font-2-xl
kebabCase(‘white4th’) → white-4th
このデモで示したように、JSとPHPの間でスラッグ生成ロジックが統一された。ブロック名やCSSクラス名の変換で環境による差異がなくなる。
エディタが管理者カラースキームに対応
投稿エディタ、ウィジェットエディタ、カスタマイザーのウィジェットエディタが、アクティブな管理者カラースキームを反映するようになった。getAdminThemeColors()が@wordpress/admin-uiの公開APIとして提供され、拡張開発者も同じ仕組みを自前の管理画面に組み込める。
Data Viewsの改善と時刻フィールド追加
DataViewsパッケージからプライベートAPIの依存が排除された。これまで同パッケージをプラグインにバンドルすると「ロックされていないオブジェクトをアンロックできない」というエラーが出る問題があった。対応に伴い、CalendarやRangeCalendarなどのコンポーネントが公開APIとして移行している。
Gutenberg 23.8ではtime型のフィールドも追加された。営業時間やイベント開始時刻、予約枠など、日付を伴わない時刻データを扱う用途に向いている。値はHH:mm形式で保存されるため、訪問者のタイムゾーンに左右されない。
テーマ開発者向けの変更点まとめ
theme.jsonスキーマの修正
WordPress 7.1で導入されたレスポンシブスタイルステートと擬似クラスステートのスキーマが不完全だった。Gutenberg 23.8で複数の修正が入り、コードエディタでtheme.jsonを編集する際にステートが不正として表示されないようになった。
スタイルUIの制御オプション追加
blockStatesEditingEnabledとresponsiveEditingEnabledという2つのフラグが追加された。block_editor_settings_allフィルターを通じて無効化できる。クライアント向けのサイト構築で、設計済みのスタイルを崩させずに編集機能をロックダウンする用途に有効だ。
label要素とフォーム要素のスタイル対応
Gutenberg 23.9ではlabel要素がtheme.jsonのスタイル対象に追加された。styles.elements.labelで指定でき、Search、Form Input、Post Comments Form、Archives、Categoriesブロックなどでレンダリングされるlabelタグに適用される。
続けてcite、textInput、select要素もエディタのStylesインターフェースから直接編集できるようになった。エディタのTypographyパネルとColorsパネルで操作できる。
GroupブロックのblockGapが軸別指定に対応
GroupブロックのblockGapサポートが水平方向と垂直方向の両方に対応した。theme.jsonでblockGapの値として通常の文字列に加えて、topとleftのキーを持つオブジェクト形式を指定できる。エディタUI上ではflexレイアウトとgridレイアウトでのみ軸別コントロールが表示される。
そのほか、Listブロックがwideとfullの配置をサポート、Query No Resultsブロックがボーダーとスペーシングをサポート、Query Loopブロックがblock gapをサポートするようになった。Accordion Headingブロックのtheme.jsonスペーシングがトグルボタンに正しく適用される修正も入っている。
Playgroundの進化とWordPress 7.2の展望
WordPress PlaygroundがWebMCPに対応した。これはAIエージェントが呼び出せるツールとしてブラウザ内のアクションを公開する草案APIだ。PlaygroundはWordPressをネストされたiframeで実行するため、新しいプロキシが埋め込みサイトのツールを外部ページに広告し、呼び出しを転送する仕組みになっている。
さらに、Playground上でWordPress 0.7まで遡って実行できるようになった。設定パネルで「Include older versions」にチェックを入れると、6.2までの全バージョンが選択肢に含まれる。PHPのバージョンも自動的にペアリングされるため、「いつこの機能が壊れたのか」を確認する用途に役立つ。
このタイムラインで示したように、WordPress 7.2の開発サイクルは約2ヶ月にわたって進行する。開発者向け機能の実装状況を確認しながら、互換性の検証を進めるのが良いだろう。
この記事のポイント
- コードリファレンスがブラウザ上でコード実行に対応、Playgroundを使った動作確認が可能になった
- ブロックのキーボードショートカットを宣言的に定義するAPIが追加された
- インナーブロックテンプレートはブロックタイプ設定への移行が推奨される
- theme.jsonのスキーマ修正とスタイルUIの制御オプションでテーマ開発が改善された
- WordPress 7.2は12月8〜10日に正式リリース予定、Beta 1は10月20〜22日
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説
WooCommerce 11.5（2027年1月目標）から、最低動作環境がPHP 8.1以上になる提案が発表された。この変更が採用されると、PHP 7.4とPHP 8.0のサポートは将来のバージョンで終了する。
WooCommerceの利用データでは、PHP 7.4が追跡対象ストアの約7%、PHP 8.0が約2%を占めている。比較的新しいWooCommerceバージョンに限ると合計約6%まで下がり、減少傾向が続いている。
ストア運営者や拡張機能開発者は、移行の影響を早めに把握して準備を進める必要がある。本記事では提案の内容、影響範囲、推奨される対応をまとめた。
WooCommerce 11.5からPHP 8.1以上が最低要件に
上の図のように、WooCommerce 11.5を境に最低PHPバージョンが引き上げられる。PHP 7.4と8.0を使うストアは、設定変更なしでは新しいバージョンへ更新できなくなる。
PHPサポート終了の現状
PHP 7.4は2022年11月に、PHP 8.0は2023年11月に公式サポートが終了している。以降はセキュリティ修正が提供されていないため、脆弱性が見つかっても修正されない状態が続く。
WooCommerceの内部データによると、追跡対象ストア全体ではPHP 7.4が約7%、PHP 8.0が約2%を占める。一方、直近1年以内にリリースされた比較的新しいWooCommerceバージョンでは合計約6%まで縮小している。
提案の具体的内容
WooCommerceエンジニアリングチームは、WooCommerce 11.5のリリースを目標に最低要件をPHP 8.1以上へ引き上げることを提案している。採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。
この変更により、WooCommerce 11.5以降はPHP 7.4と8.0向けの互換コードを削除できる。コードベースの保守性が高まり、開発スピードの向上につながると見込まれている。
PHPバージョン引き上げのメリット
match式
名前付き引数
安全な依存パッケージ
互換性コード削減
ランタイム改善
PHP 8.1以上への引き上げで得られる主な利点は4つ。最新構文の活用、セキュリティ向上、開発効率の改善、そしてランタイム性能の向上だ。
最新PHP機能の活用
PHP 8.1以上では、union types（複数の型を許容する宣言）、attributes（メタデータを付与する仕組み）、null-safe operator（null判定を簡潔に書く演算子）、match式、名前付き引数などが使えるようになる。WooCommerce本体だけでなくサードパーティ製の拡張機能も、これらの機能を前提に開発できる。
union typesとは、関数の引数や戻り値に「intまたはstring」のように複数の型を指定できる記法だ。これがあると、無理な型変換や冗長な分岐を減らせる。コードが読みやすくなり、バグの発生も抑えられる。
セキュリティとパフォーマンスの向上
サポート終了済みのPHPを使い続けると、既知の脆弱性が修正されないまま残る。PHP 8.1以上へ移行することで、セキュリティ修正が提供される安心な環境に切り替えられる。
さらに、WooCommerceと拡張機能が新しいPHP専用の安全な依存パッケージを採用できるようになる。旧バージョン向けの互換レイヤーを削除でき、継続的インテグレーション（CI）でテストするPHPバージョンも減るため、テストやリリースの速度も上がる。
PHP 8系へのアップグレード自体にも性能向上の効果がある。PHPランタイムの改善により、WooCommerceストアの表示速度や処理能力が底上げされる。これはコード変更なしで得られる利点だ。
PHP 7.4・8.0を使うストアへの影響
PHP 7.4や8.0を使っていても、WooCommerceが自動でPHPを更新したり、ストアを停止させたりすることはない。ただし、WooCommerce 11.5以降への更新だけはブロックされる。
自動更新の停止と移行手順
提案が採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。WordPressの標準機能により、要件を満たさないストアにはWooCommerce 11.5の更新が表示されなくなる。
PHP 7.4または8.0を使うストアは、現在のWooCommerceバージョンをそのまま使い続けることになる。同じブランチのドットリリース（例 11.4.x）は引き続き提供される。新しいメジャーバージョンへ移るには、先にPHPを8.1以上へアップグレードする必要がある。
前例となったWooCommerce 8.2
今回の進め方は過去のWooCommerceのPHP要件変更と同様のアプローチを取っている。WooCommerce 8.2では最低要件をPHP 7.4以上へ引き上げ、事前通知と移行ガイダンスが提供された。
当時も、要件を満たさないストアは自動更新されず、既存バージョンの更新のみ継続する方式だった。今回のPHP 8.1引き上げでも同じ流れが想定されている。
WordPressと拡張機能開発者への影響
WordPressのPHP要件との違い
WordPress本体は現在、PHP 7.4以上で動作し、PHP 8.3以上を推奨している。しかしWooCommerceは、WordPressより高いPHP要件を維持してきた経緯がある。
WooCommerceは決済処理や在庫管理、注文ワークフローなどを持つ複雑なECアプリケーションだ。独自の依存関係や性能要件があるため、最低PHPバージョンをWordPressと完全に一致させる必要はないとされている。
拡張機能開発者への推奨事項
WooCommerce向けの拡張機能を開発している場合、すでに新しいPHPバージョンでテストしていることが理想だ。今回の変更により、WooCommerce 11.5以降だけを対象にする拡張機能はPHP 8.1以上の機能を使えるようになる。
一方、古いWooCommerceバージョンを引き続きサポートする拡張機能は、互換レイヤーや別コードパスを維持する必要が出てくる。PHPバージョンが上がっても、すべての拡張機能やテーマ、カスタムスニペットがそのまま動く保証はない。
本番環境へ適用する前に、ステージングサイトでPHP 8.1以上への移行テストを行うことが重要だ。特に独自カスタマイズや古い拡張機能を使っている場合、互換性の問題が顕在化しやすい。
意見募集と今後のスケジュール
フィードバックの募集ポイント
WooCommerceエンジニアリングチームは、ストア運営者、代理店、ホスティングプロバイダー、拡張機能開発者などから幅広く意見を求めている。主な質問は以下の通りだ。
- PHP 7.4や8.0から移行できない理由はあるか
- 該当PHPバージョンを必要とする拡張機能やテーマは存在するか
- WooCommerce 11.5（2027年1月目標）で準備期間は十分か
- ホスティングプロバイダーはWooCommerceストアのPHP利用状況について追加データを持っているか
- 対応が望まれる移行ガイダンスは何か
互換性の問題を報告する場合は、PHPバージョン、WooCommerceバージョン、影響を受ける拡張機能、エラーメッセージを添えることが推奨されている。
決定までのタイムライン
WooCommerceチームはフィードバックと利用データを確認した上で、対象リリースと最低PHPバージョンを最終決定する。決定後は事前告知を行い、開発者が新しい要件でテストできるよう準備期間を設ける方針だ。
現時点ではまだ提案段階であり、正式な決定ではない。ただし利用データの減少傾向やEOLの状況を踏まえると、PHP 8.1以上への引き上げは現実的な選択肢として有力だ。
この記事のポイント
- WooCommerce 11.5（2027年1月目標）からPHP 8.1以上が最低要件になる提案が発表された
- PHP 7.4と8.0はサポート終了済みで、利用は全体の約6〜9%まで縮小している
- PHP 7.4・8.0のストアは自動更新されず、移行後にWooCommerce 11.5へ更新できる
- 最新PHP機能の活用、セキュリティ向上、開発効率の改善が主な目的だ
- 拡張機能開発者はステージング環境でPHP 8.1以上へのテストを推奨
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験