年別アーカイブ 2026年7月14日

  1. ホーム   /  2026 ( 固定ページ25 )
OpenAI、フルデュプレックス音声モデルGPT‑Liveを発表、会話の自然さを大幅向上
2026年7月14日 0

OpenAI、フルデュプレックス音声モデルGPT‑Liveを発表、会話の自然さを大幅向上

OpenAIは2026年7月8日、新しい音声対話モデル「GPT‑Live」を発表した。人が話しかけるのと同時に聞き取り、相槌を打ったり沈黙を尊重したりできるフルデュプレックスアーキテクチャが最大の特徴だ。

モデル自体は単体の音声モデルでありながら、高度な質問に対してはバックエンドのGPT‑5.5に自動で推論を委譲する。これにより、速さと知性を両立させた自然な会話体験を実現している。

フルデュプレックスアーキテクチャが会話の自然さを変える

フルデュプレックスアーキテクチャが会話の自然さを変える

従来の音声AIが抱えていた限界

これまでのChatGPT音声機能は、大きく分けて2つの方式を経て進化してきた。最初のカスケード型は、音声認識→テキスト生成→音声合成という3つのモデルを直列に繋いでいた。各段階で情報が欠落し、応答までに長い沈黙が生まれる欠点があった。

次世代のターンベース型（Advanced Voice Mode）は単一モデルで音声を処理し、レイテンシを削減した。しかし「ユーザーが話し終えるまで待つ」というターン制のため、割り込みや考え込む間といった自然なやり取りができず、わずかな無音で誤って応答を開始する問題も残っていた。

従来のカスケード型音声システム（Before）
ユーザー発話 → 音声認識 → LLM応答生成 → 音声合成
情報がモデル間で欠落し、応答が遅く不自然。長い沈黙とぎこちないやり取り。
↓
GPT‑Liveのフルデュプレックス連続対話（After）
ユーザー発話 ↔ GPT‑Live（同時入出力）
リアルタイムに聞きながら話す。「うん」「なるほど」で相槌し、考え中の無音も尊重。
■ ユーザー側　 ■ 単一の音声モデル　 ■ 複数モデルの連鎖（カスケード）

このデモはGPT‑Liveがもつ同時双方向処理の概念を簡略化したものだ。実際の会話では秒単位で割り込みやツール呼び出しの判断が行われている。

連続的な相互作用が生むリアルタイム性

GPT‑Liveのフルデュプレックス構造では、入力と出力が同時に連続的に処理される。モデルは1秒間に何度も発話や傾聴、一時停止、割り込み、ツール起動といった行動を判断できる。この仕組みが、相槌や「ええ」といった自然なフィードバック、沈黙の尊重、さらには会話中のリアルタイム翻訳まで可能にしている。

バックエンド委譲で高度な推論をリアルタイム対話に統合

バックエンド委譲で高度な推論をリアルタイム対話に統合

対話と思考の分離がもたらすメリット

GPT‑Liveはフロントエンドの自然な対話と、バックエンドの深い処理を分離した。Web検索や複雑な推論が必要な質問が来ると、自身は会話を続けながらGPT‑5.5にタスクを委譲する。回答が用意でき次第、会話に自然に織り込まれる。

この分離により、常に最新のフロンティアモデルが活用され、モデル更新のたびにGPT‑Liveの知性も自動的に向上する。発表時点ではGPT‑5.5がバックエンドとして使われる。

STEP 1 ユーザーが「最も売れたSF小説のあらすじを教えて」と質問
↓
STEP 2 GPT‑Liveが「それなら、ちょっと調べてくるね」と会話を続ける
↓
STEP 3 バックグラウンドでGPT‑5.5がWeb検索と推論を実行
↓
STEP 4 結果が返ると、GPT‑Liveが自然に会話に織り交ぜて回答
STEP1ユーザーの発話
STEP2GPT‑Liveの即時返答
STEP3GPT‑5.5による深い処理
STEP4会話へ統合

この委譲の仕組みにより、GPT‑Liveは会話のテンポを保ちつつ、最新のフロンティアモデルの知性を引き出せる。

評価指標が示す会話品質の飛躍的向上

評価指標が示す会話品質の飛躍的向上

人間による比較評価でAdvanced Voice Modeを圧倒

OpenAIの発表によれば、5〜10分の会話を対象にした人間評価では、GPT‑Live‑1とGPT‑Live‑1 miniの両方がAdvanced Voice Modeより強く選好された。話者交替のスムーズさ、割り込みの自然さ、会話全体の心地よさで高い評価を得ている。

専門的な推論力を測るGPQA（物理学・化学・生物学の高度な質問）ではGPT‑Live‑1が大幅に上回り、Web検索能力を問うBrowseCompでも強い改善を見せた。音声エージェントとしての電話サポートタスクでも、内部指標でAdvanced Voice Modeを凌駕した。

ChatGPT Voiceに搭載される新機能と使い勝手

ChatGPT Voiceに搭載される新機能と使い勝手

相槌や割り込み、視覚的応答の追加

GPT‑Liveの導入により、ChatGPTの音声ボタンを押すとすぐに自然な会話が始まる。ユーザーは質問を遮ったり、考え込む間を作ったり、「ゆっくり話して」と頼んだりできる。モデルは「うん」「なるほど」といった相槌で話を聞いていることを伝え、背景ノイズがあっても話者の声に集中する。

さらに、天気や株価、スポーツの試合予定などの情報は、音声会話中にビジュアルカードとして画面に表示される。従来通り画像やファイルのアップロードにも対応し、Web検索やメモリー機能とも連携する。

回答の思考深度も選択可能で、「Instant」なら即答、「Medium」や「High」にするとモデルが時間をかけて深く推論する。全9種類の声もGPT‑Live向けにリマスターされた。

音声特化の安全性設計と継続的な監視

音声特化の安全性設計と継続的な監視

リアルタイムの有害出力検出と介入

GPT‑Liveは音声会話の即時性に対応するため、発話中でも安全性チェックが動作する。不適切な内容が検出されると、より安全な応答へ誘導したり、追加の安全メッセージを表示したり、深刻なケースでは会話を終了させたりする。

自傷行為に関する会話では、専門家が確認したクライシスヘルプライン情報を音声で案内する仕組みも組み込まれた。10代のユーザー向けには年齢に適した振る舞いを直接モデルに学習させ、保護者がChatGPT Voiceの利用を制限できる機能も用意されている。

実利用データに基づく安全対策の進化

OpenAIは感情的な依存に関する長期モニタリングを展開し、実際の利用パターンから新たなリスクを特定して対策を強化する方針だ。音声のなりすましを防ぐため、GPT‑LiveはChatGPTに用意された定義済みの声のみを使用し、実在の人物の声を模倣しないように設計されている。

この記事のポイント

  • GPT‑Liveはフルデュプレックス構造で同時に聞きながら話し、相槌や沈黙を自然に扱える音声モデル
  • 高度な質問はバックエンドのGPT‑5.5に自動委譲し、会話のテンポを保ったまま深い推論結果を返す
  • 人間評価やGPQAなどのベンチマークでAdvanced Voice Modeを大きく上回る会話品質と知性を達成
  • ChatGPT Voiceに即日導入され、ビジュアル応答や思考深度の選択が可能に
  • リアルタイムの安全性介入や利用後監視により、音声ならではのリスクに対処している
海田 洋祐
, , , , , ,
AI・開発支援
GPT-5.6ファミリー登場、Sol・Terra・Lunaの全容と実務メリット
2026年7月13日 0

GPT-5.6ファミリー登場、Sol・Terra・Lunaの全容と実務メリット

OpenAIは2026年7月9日、次世代フラッグシップモデル「GPT-5.6」ファミリーを一般提供開始した。プレビュー期間を経て投入された本リリースには、フラッグシップのSol、バランスモデルのTerra、コスト効率重視のLunaの3モデルが揃う。

GPT-5.6 Solはコーディング、知識労働、サイバーセキュリティ、科学研究の各領域で従来のフロンティアモデルを上回る性能を達成しつつ、消費トークン数と推定コストの大幅削減を両立した。これにより同一予算でもより多くの成果を出せる、いわば「コストパフォーマンスの再定義」を実現している。

この記事では、GPT-5.6の各モデルの特徴と性能、実務者にとってのメリット、そしてOpenAIが打ち出した新たな安全性対策を掘り下げる。

GPT-5.6ファミリーの全体像～3モデルの違いと狙い

GPT-5.6ファミリーの全体像～3モデルの違いと狙い
Sol（フラッグシップ）
コーディング・科学研究・サイバーセキュリティで最高性能。ultra設定で並列エージェント駆動も可能
↓
Terra（バランスモデル）
GPT-5.5に匹敵する性能を低コストで提供。日常業務向けの実用的選択肢
↓
Luna（コスト効率重視）
GPT-5.5のピーク性能に迫りつつ推定コストは半分未満。大量の定常タスクに最適
■ Sol　■ Terra　■ Luna

GPT-5.6ファミリーは3つのモデルで構成される。Sol・Terra・Lunaはいずれも第5.6世代の基盤技術を共有するが、ターゲットとする用途とコスト構造が異なる。OpenAIによれば、これらのモデル名（Sol・Terra・Luna）は永続的な能力階層を示しており、今後それぞれのペースでアップデートが進む見込みだ。

Solが実現する「1トークンあたりの仕事量」の進化

Solの最大の特徴は、消費トークンあたりの実用成果の高さにある。Agents’ Last Exam（55分野の長時間ワークフロー評価）ではスコア53.6を記録し、競合のClaude Fable 5を13.1ポイント上回った。中程度の推論設定でも、Fable 5に対して11.4ポイント優位に立ちつつ、推定コストは約4分の1に抑えている。

この効率性は下位モデルにも波及している。GPT-5.6 TerraとLunaは、Fable 5の性能を上回りながら推定コストは約16分の1だ。単に「強いAI」を作るだけでなく、同じ予算でより多くの知的作業をこなせる点が、今回のリリースの中核的価値といえる。

ultra設定がもたらす並列エージェント駆動

GPT-5.6 Solには「ultra」と呼ばれる最高能力設定が搭載された。ultraはデフォルトで4つのエージェントを並列動作させ、複雑なタスクを複数のワークストリームに分割して処理する。これにより単一エージェント構成と比べて、スコアとレイテンシの両方で改善が確認されている。

BrowseComp、SEC-Bench Pro、Terminal-Bench 2.1の3評価すべてで、並列エージェントの追加により「より高スコアをより短時間で」達成する結果が得られた。開発者はAPIのマルチエージェントベータ機能を通じて、同様の並列処理を独自に構築することも可能だ。

実務者にとってのGPT-5.6～コストと速度の再定義

実務者にとってのGPT-5.6～コストと速度の再定義
開発者 GPT-5.6に指示 → GPT-5.6 Sol 必要な中間処理を自動選別 → 完成度の高い成果物を短時間で納品

GPT-5.6の真価はベンチマークスコアだけではない。実務者が日々使うツールやワークフローの中で、どれだけ「手戻り」を減らし「完成度」を高められるかが鍵だ。

Programmatic Tool Callingでツール連携が変わる

GPT-5.6に導入された Programmatic Tool Calling（プログラマティックツール呼び出し）は、モデル自身が軽量なプログラムをメモリ内で作成・実行し、ツール連携や中間結果の処理を自律的に進める仕組みだ。開発者が全ステップをスクリプト化する必要はなく、大量の中間データから必要な情報だけを抽出して次のアクションを判断する。

この仕組みにより、ツールを多用するワークフローでのトークン消費と往復回数が大幅に削減される。Responses APIで利用可能で、Zero Data Retention（ZDR）にも対応している。

max・ultra設定で複雑タスクを加速

GPT-5.6は効率重視のデフォルト動作に加えて、難易度の高いタスクに対して計算リソースを集中的に投下する設定を備える。max設定はxhighより長時間の推論と検証を許容し、ultraは並列エージェントで処理を高速化する。APIの価格帯は Sol が入力100万トークンあたり5ドル、出力同30ドルと公表されている。

コーディング性能の飛躍～開発者にとってのGPT-5.6

コーディング性能の飛躍～開発者にとってのGPT-5.6
従来の開発フロー（Before）
開発者が全ステップを逐次指示 → モデルが都度応答 → 大量のトークン往復が発生 → デバッグのたびに再実行
↓
GPT-5.6 Sol の開発フロー（After）
1回の指示で複数ファイルにまたがるコード生成・CLI操作・パッチ適用まで自律実行。出力トークンは競合の半分未満

GPT-5.6 Solは現時点で最強のコーディングモデルと位置づけられている。Artificial Analysis Coding Agent Indexでは、max推論設定でスコア80を達成し、Claude Fable 5を2.8ポイント上回った。出力トークン数は半分未満、所要時間も半分以下、推定コストは約3分の1減という結果だ。

実コードベースでの強さ～DeepSWEとTerminal-Bench

GPT-5.6の優位性は、実コードベースでの長期エンジニアリングタスクを評価するDeepSWE v1.1やTerminal-Bench 2.1でも確認されている。Terminal-Bench 2.1ではSolが88.8%、ultra設定では91.9%に達し、GPT-5.5（85.6%）やClaude Fable 5（83.1%）を明確に引き離した。

複雑なコマンドラインワークフローを自律的に処理できるようになったことで、開発者がスクリプトの細部を逐一指示する必要は減り、「何を実現したいか」の指示だけで作業が進む体験に近づいている。

知識労働とデザイン判断力の進化

知識労働とデザイン判断力の進化
GPT-5.5（Before）
参照ファイルの一部を反映できず、スライドマスターのコンポーネントが欠落
↓
GPT-5.6 Sol（After）
マスタースライドのレイアウト・タイポグラフィ・配色規則を推論し、忠実に適用

GPT-5.6は知識労働の質でも段違いの進化を見せる。Slack、Notion、Microsoft 365、Google Driveといった日常ツールから雑多な文脈を取り込み、専門家レベルの成果物に変換する能力が強化された。

プレゼンテーション・文書作成の実力

特に顕著なのがプレゼンテーション作成能力だ。GPT-5.6はプロンプトとソース資料から完全に編集可能なスライドを一から生成できる。レイアウト、階層構造、デザインの一貫性を備えた視覚的ナラティブを構築し、テンプレートやリファレンスデッキがある場合は、スライドマスターに埋め込まれたデザインルールさえ推論して適用する。

OpenAIの比較事例では、GPT-5.5が参照ファイルのマスタースライドコンポーネントを欠落させたのに対し、GPT-5.6はレイアウト・タイポグラフィ・配色・コンテンツパターンを忠実に再現した。文書やスプレッドシートでも、複雑な参照フォーマットの遵守、数式や財務モデルの精度、ページレイアウトの洗練度が向上している。

コンピュータ操作とUIデザインの判断力

GPT-5.6のコンピュータ操作能力は、コード生成にとどまらず、レンダリング結果の視覚的検証と改善までカバーする。高水準の指示だけで機能的かつ洗練されたUIを作成し、仕上がりを目視確認してから納品するフローが可能になった。BrowseCompではスコア92.2%と競合を上回り、OSWorld 2.0では62.6%を達成しながら出力トークン数を85%削減している。

セキュリティと安全性～進化した防護策

セキュリティと安全性～進化した防護策
防御的活用（推奨・強化）
SOCアナリスト 脆弱性トリアージ・マルウェア分析・検出エンジニアリング
開発者 セキュアコードレビュー・パッチ検証・脅威モデリング
↓
悪用リスク（制限対象）
攻撃者 自律的なエンドツーエンド攻撃は難易度が高い。OpenAIの保護策がブロック

GPT-5.6はサイバーセキュリティ領域で飛躍的な性能向上を示した。ExploitBenchではGPT-5.5の47.9%から73.5%へ、ExploitGymでは15.1%から24.9%（2時間制限、6時間では33.7%）へと大幅に改善している。

デュアルユースを前提とした安全性設計

サイバーセキュリティは本質的にデュアルユース（両義的利用）の領域だ。脆弱性をつく能力が高まれば、同時にそれを見つけて修正する防御能力も高まる。OpenAIは「過剰なブロックは防御側の活動を阻害し、攻撃者は他のモデルやオープンソースツールを使い続ける」との立場をとっている。

そのためGPT-5.6の安全策は、一律ブロックではなく、リクエストの文脈と想定される結果を評価する多層構造を採用した。モデル内部に訓練された保護機能に加え、リアルタイムチェック、継続的モニタリング、アカウントレベルの制御が重層的に機能する。最も機微な能力はOpenAI DaybreakのTrusted Access for Cyberプログラムを通じて、認証済みの利用者のみに提供される。

約70万GPU時間のレッドチーミング

一般提供に先立ち、OpenAIは過去最大規模の安全性評価を実施した。外部専門家によるレッドチーミングに加え、約70万A100e GPU時間を投じたブラックボックス型の自動レッドチーミングで弱点を体系的に探索した。GPT-5.6 Solのサイバーセーフガードは、GPT-5.5比で約10倍の有害活動をブロックしている。

提供形態と価格～ChatGPT・Codex・APIのロールアウト

提供形態と価格～ChatGPT・Codex・APIのロールアウト

GPT-5.6は7月9日から全世界で段階的に提供が開始され、24時間以内に全ユーザーへの展開が完了する予定だ。

ChatGPT / Codex
Plus/Pro/Business/Enterprise Sol選択可、max/ultra設定利用可
Free/Go Terraを利用可能
↓
API
Sol $5 input / $30 output（100万トークンあたり）
Terra $2.50 input / $15 output
Luna $1 input / $6 output

ChatGPTでは、Plus・Pro・Business・EnterpriseユーザーがGPT-5.6 Solに中〜高エフォート設定でアクセスできる。ProとEnterpriseは最高品質のSol Proも選択可能だ。Codexでは、Plus以上でSol・Terra・Lunaを選択でき、ultraはProとEnterpriseが利用できる。

APIの価格体系は前世代と比べて明確な選択肢を提供する。TerraとLunaの登場により、予算やタスクの重要度に応じて同じGPT-5.6アーキテクチャの恩恵を受けながら、コストを最適化できるようになった。

AI研究の自己加速～内部導入で見えた効果

OpenAIの社内では、GPT-5.6のテスト期間中に研究者1人あたりの1日平均出力トークン数がGPT-5.5のピーク時の2倍以上に達した。過去6カ月間で社内の研究向けコーディング推論の計算リソース消費は100倍に、エージェント型トークン利用は約22倍に増加している。

OpenAIはこの再帰的自己改善能力を「RSI Index」という内部評価指標でスコア化しており、GPT-5.6 SolはGPT-5.5から16.2ポイントの改善を示した。研究デバッグ、カーネル最適化、機械学習実験の自動化など、AIがAIの開発を加速する好循環が始まっている。

この記事のポイント

  • GPT-5.6はSol・Terra・Lunaの3モデル構成で、フラッグシップから低コストまで用途に応じた選択が可能
  • コーディング・知識労働・サイバーセキュリティ・科学研究の全領域でGPT-5.5を大幅に上回る性能を達成
  • 消費トークン数とコストの大幅削減により、同一予算での成果最大化を実現
  • 並列エージェントのultra設定やProgrammatic Tool Callingで複雑タスクの自律処理が加速
  • 約70万GPU時間のレッドチーミングを含む多層的安全策で、防御的利用を阻害せずに悪用を抑制
海田 洋祐
, , , , ,
AI・開発支援
WooCommerce 11.0でget_queried_object()がショップページでもWP_Postを返す改善
2026年7月13日 0

WooCommerce 11.0でget_queried_object()がショップページでもWP_Postを返す改善

WooCommerce 11.0より、ショップページで get_queried_object() を呼び出した際の戻り値の型が WP_Post_Type から WP_Post に統一される。これまでショップページだけが例外的に商品の投稿タイプオブジェクトを返していたが、今回の変更でWordPress標準の挙動と一貫性が保たれることになる。

この修正は、WooCommerceが内部的に管理するクエリの取り扱いをWordPressコアに合わせるもので、テーマやプラグインの開発者が「ショップページかどうか」を意識せずに get_queried_object() を扱えるようにする狙いがある。フロントページにショップページを設定している場合も同様の挙動となる。

WooCommerce 11.0のショップページ改善

WooCommerce 11.0のショップページ改善

get_queried_object() は現在のWordPressクエリに対応するオブジェクトを取得する標準関数だ。通常の固定ページや投稿ページでは WP_Post オブジェクトを返すが、これまでのWooCommerceではショップページに限り WP_Post_Type オブジェクト、つまり商品（product）の投稿タイプ情報を返していた。この不一致が開発者にとって混乱の元となっていた。

WooCommerce Developer Blogの説明によれば、ショップページで get_queried_object() を呼び出して「商品アーカイブであること」を判定するコードを書いていた場合、この変更の影響を受ける可能性がある。逆に言えば、今回の修正で is_shop() のような条件分岐タグと get_queried_object() の戻り値の関係が整理され、より直感的なコードが書けるようになる。

WooCommerce 10.x までの挙動（Before）
Shopページ → WP_Post_Type （商品の投稿タイプ情報）
その他固定ページ → WP_Post （ページの投稿オブジェクト）
■ Shopページだけが例外で、他のページと異なるオブジェクト型を返していた
↓
WooCommerce 11.0 以降の統一された挙動（After）
Shopページ → WP_Post （ショップ固定ページの投稿オブジェクト）
その他固定ページ → WP_Post （ページの投稿オブジェクト）
■ すべてのページで一貫して WP_Post を返すように統一された

この変更の背景には、WordPressの「投稿ページ」設定と同様にショップページでも WP_Post を返すべき、という設計上の判断がある。WooCommerce 11.0ではこの長年の不一致が解消され、より予測しやすいAPIへと改善された。

影響を受けるコードの判断方法

影響を受けるコードの判断方法

自作のテーマやプラグインでショップページのクエリオブジェクトを参照している場合、以下のいずれかの関数やプロパティを使用していないか確認する必要がある。

  • get_queried_object() を呼び出している
  • get_queried_object_id() を呼び出している
  • $query->queried_object に直接アクセスしている
  • $query->queried_object_id に直接アクセスしている

これらのコードがショップページ上で実行され、戻り値として WP_Post_Type オブジェクトを期待しているなら、WooCommerce 11.0へのアップデート後に動作が変わる可能性が高い。とくに、queried_object->labels->name などのプロパティに依存している場合は要注意だ。

Before / After コードの比較

具体的なコードの違いを見てみよう。以下はショップページでの get_queried_object() の戻り値の変化を示している。

// WooCommerce 10.x まで Shopページのみ例外
get_queried_object();          // → WP_Post_Type
get_post_type_object( 'product' ); // → WP_Post_Type

// その他の固定ページ
get_queried_object();          // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type
// WooCommerce 11.0 以降 Shopページも含めて統一
get_queried_object();          // → WP_Post
get_post_type_object( 'product' ); // → WP_Post_Type

この変更の影響を受けないケース

次のような状況では、WooCommerce 11.0の変更による影響はなく、既存のコードはそのまま動作する。

  • 単一の商品ページ（single-product）では引き続き商品の WP_Post オブジェクトが返る
  • 商品カテゴリやタグ、ブランド、属性などのタクソノミーページでは WP_Term オブジェクトが返る
  • その他の投稿タイプアーカイブや個別ページはもともと変更の対象外
  • is_shop() や is_archive()、is_post_type_archive( 'product' ) といった条件分岐関数の挙動は従来どおり変わらない

開発者が取るべき具体的な対応

開発者が取るべき具体的な対応

もし既存のコードがショップページで get_queried_object() の戻り値を WP_Post_Type として扱っている場合、WooCommerce 11.0へのアップデートに備えて改修が必要だ。修正の基本方針は「オブジェクトの型をチェックしてからプロパティにアクセスする」ことにある。

商品の投稿タイプ情報を取得する推奨方法

商品の WP_Post_Type オブジェクトが必要な場合は、get_post_type_object() を使うのが安全で推奨される方法だ。この関数はWooCommerceのバージョンに関係なく常に正しいオブジェクトを返す。

$product_post_type = get_post_type_object( 'product' );

if ( $product_post_type instanceof WP_Post_Type ) {
    // 商品のWP_Post_Typeオブジェクトは
    // get_post_type_object() から引き続き取得できる
    $singular_name = $product_post_type->labels->singular_name;
}

ショップページのWP_Post情報を扱うコード例

ショップページ自体の情報（ページタイトルやスラッグなど）を取得したい場合は、WooCommerce 11.0以降は get_queried_object() から直接 WP_Post としてアクセスできるようになる。以下はその典型的な使用例だ。

$shop_page = get_queried_object();

if ( $shop_page instanceof WP_Post ) {
    // WooCommerce 11.0以降、ショップページでも
    // WP_Postとして扱える
    $shop_title = $shop_page->post_title;
    $shop_slug  = $shop_page->post_name;
}
修正の流れと対応手順
STEP 1 ショップページで get_queried_object() / $query->queried_object を使っている箇所を特定する
↓
STEP 2 戻り値を WP_Post_Type として使っているか確認する（ instanceof や型チェックをしていない場合）
↓
STEP 3 get_post_type_object( 'product' ) で商品の投稿タイプ情報を個別に取得し、既存コードを書き換える
↓
STEP 4 テスト環境でWooCommerce 11.0にアップデートし、ショップページが正しく表示されるか検証する

重要なのは、get_queried_object() の戻り値に依存した条件分岐を書く前に、必ず instanceof でオブジェクトの型をチェックする習慣をつけることだ。これにより、WooCommerceの将来のアップデートや他のプラグインとの競合にも強いコードになる。

この記事のポイント

  • WooCommerce 11.0ではショップページの get_queried_object() が WP_Post を返すように統一される
  • 商品の投稿タイプ情報が欲しい場合は get_post_type_object( 'product' ) を使用する
  • is_shop() などの条件分岐関数の挙動は変わらないため、ページ判定ロジックの修正は不要
  • 影響を受けるコードは、おもにショップページでクエリオブジェクトのプロパティに直接アクセスしている箇所
  • アップデート前に instanceof による型チェックを追加し、テスト環境で検証するのが安全な移行手順
海田 洋祐
, , , , ,
EC制作
OpenAIがコード評価ベンチマークの30%に欠陥を発見、SWE-Bench Pro監査結果
2026年7月13日 0

OpenAIがコード評価ベンチマークの30%に欠陥を発見、SWE-Bench Pro監査結果

コード生成AIの能力を測るベンチマークは、モデルの安全性と展開判断の重要な根拠となる。そのベンチマーク自体に欠陥があれば、過大評価や過小評価を招き、誤った研究優先順位や安全性の見落としにつながる。

OpenAIが2026年7月、広く使われているコード評価ベンチマーク「SWE-Bench Pro」の大規模な監査結果を公開した。タスク全体の約30%に「破損（broken）」と呼ぶべき根本的な問題があり、評価指標としての信頼性が揺らいでいるという。

SWE-Bench Proとは何か

SWE-Bench Proとは何か

SWE-Bench Proは、AIモデルのソフトウェア開発能力をより現実的なタスクで測るために作られたベンチマークだ。前身のSWE-bench Verifiedが抱えていた設計上の問題やデータ汚染（contamination）を受け、より長期のタスクと実践的なコーディング能力を評価できるように設計されている。

具体的には、GitHub上の公開・非公開リポジトリから実際の機能変更履歴をもとにタスクを抽出する。モデルは既存の機能を壊さずに新機能を実装し、追加されたテストケースをすべて通過するコードを書く必要がある。公開されている731のタスクに対し、わずか8カ月で最先端モデルの合格率は23.3%から80.3%に急上昇した。

理想的な評価タスク（After）
プロンプト ログイン機能を追加せよ
↓
テスト ログインが成功することを確認する
※テストがプロンプトの内容と一致しており、複数の正しい実装方法が許容される
↓
破損した評価タスク（Before）
プロンプト ログイン機能を追加せよ
↓
テスト 特定の暗号化ライブラリを使っていることを確認する
※テストがプロンプトに書かれていない実装詳細を要求しており、正しい実装でも不合格になる

上の図は、SWE-Bench Proで見つかった「過度に厳格なテスト」と呼ばれる破損パターンを簡略化したものだ。プロンプトでは「ログイン機能」とだけ指示されているのに、裏側のテストでは特定のライブラリ使用を強制している。こうしたタスクでは、機能的に正しいコードが機械的に不合格になる。

監査で明らかになった破損タスクの実態

監査で明らかになった破損タスクの実態

データの3割が信頼できない

OpenAIの監査パイプラインは、731件の公開タスクのうち200件（27.4%）を破損としてフラグした。さらに経験豊富なソフトウェアエンジニア5名による独立した人間レビューでは、249件（34.1%）が破損と判定されている。単純計算で、評価データの約3割がモデルの真の実力を反映していないことになる。

この数字の意味は重い。8カ月で合格率が約3.4倍に向上したという華々しい進歩の裏で、点数を押し上げた要因の一部が「タスク側の欠陥をうまくすり抜ける能力」だった可能性を否定できないからだ。

4つの主要な破損カテゴリ

監査で特定された問題は、大きく4つのタイプに分類される。いずれも「モデルが正しくコーディングできたか」ではなく「テストの書き方やプロンプトの不完全さ」が合否を決めてしまうパターンだ。

  • 過度に厳格なテスト（Overly strict tests）: プロンプトには書かれていない特定の実装詳細（使用するライブラリ、関数名、データ構造など）をテストが要求する。機能としては正しいコードが不合格になる。
  • 要件不足のプロンプト（Underspecified prompts）: プロンプトに記載されていない要件が隠しテストで課せられている。しかも、周辺コードやリポジトリの慣習からも合理的に推測できない内容だ。
  • 低カバレッジのテスト（Low-coverage tests）: テストが機能のごく一部しか検証しておらず、不完全な実装でも合格してしまう。
  • ミスリーディングなプロンプト（Misleading prompt）: プロンプトの指示がテストの要件と矛盾している。モデルが指示通りに実装すると不合格になるという、本末転倒な状態。
過度に厳格 プロンプト外の実装詳細を強制
要件不足 プロンプトから推測不可能な隠し要件
低カバレッジ 不完全な実装がすり抜ける
ミスリード 指示とテストが矛盾
■ 過度に厳格なテスト　 ■ 要件不足　 ■ 低カバレッジ　 ■ ミスリード

特に注目すべきは、人間レビューとエージェントによる自動分析で頻度の評価が異なった点だ。最も顕著な差が出たのが「低カバレッジのテスト」で、エージェントが4.1%と評価したのに対し、人間レビューでは9.4%がこれを主な問題として指摘した。人間の方が複数の破損パターンの重なりを認識しやすいことが一因とみられる。

品質監査パイプラインの仕組み

品質監査パイプラインの仕組み

3段階のフィルタリング

OpenAIが構築した監査プロセスは、大きく3つの段階で構成されている。

第1段階は自動フィルタリングだ。プロンプトの指示内容、モデルの解答試行、採点用テストの3つを照合し、矛盾や問題のありそうなタスクを機械的に抽出する。この段階で286件がフラグされた。

第2段階はエージェント支援の詳細監査。Codexベースの調査エージェントがリポジトリ環境にアクセスし、テストの実行、ファイルの精査、モデルの解答パターンと失敗モードの分析を繰り返す。周辺コードやリポジトリの慣習を理解した上で「単なる曖昧さ」と「真の要件不足」を区別する点がポイントだ。

第3段階は経験豊富なソフトウェアエンジニア5名による独立レビュー。各タスクについて、問題文、テストケース、正解パッチを検討した後に、エージェントの分析結果を補足情報として参照する。意見が分かれたり確信度の低いケースは追加レビューに回された。

STEP 1 自動フィルタリング（286件をフラグ）
↓
STEP 2 Codexエージェントによるリポジトリ深掘り調査
AIエージェント テスト実行 → ファイル精査 → 失敗パターン分析
↓
STEP 3 5名のエンジニアが独立レビュー
人間レビュー 249件（34.1%）を破損と判定

この3段階構成で特筆すべきは、AIエージェントと人間のダブルチェック体制だ。AIだけでは保守的になりがちな判定を、複数人の専門家が補完する。OpenAI Blogの記事によれば、エージェントが「破損でない」と判断したタスクで、人間レビューで最も多いラベルが「破損」だったケースはゼロだったという。74%のケースで両者の判断は重なっていた。

なぜ破損タスクが生まれるのか

根本的な原因は、SWE-Benchシリーズのタスク抽出方法にある。GitHub上の実際のIssueやプルリクエストは、元々人間同士の協業のために書かれたものだ。メンテナーとコントリビューターの間で長いやり取りを経て仕様が固まり、コードがマージされる。

このプロセスでは、問題文とマージされたコード、添付されたユニットテストがきれいに一対一対応するとは限らない。テストは「その変更が正しいか」を検証するために書かれており、「同じ機能を実現する他の方法」を許容するようには設計されていないケースが多い。つまり、人間用の協業ツールをそのままAI評価用に流用したことに、そもそも無理があったというのが実態だ。

ベンチマーク設計の難しさと今後の展望

ベンチマーク設計の難しさと今後の展望

「難しくて公平」なベンチマークのジレンマ

評価の難易度と公平性はトレードオフの関係にある。難しくしようとすればタスクは複雑になり、意図せず特定の実装方法に依存したテストが紛れ込む。公平にしようとすればタスクは抽象的になり、現実のソフトウェア開発から乖離する。

SWE-Bench Proのケースは、このジレンマに真っ向から直面した好例だ。最先端モデルの合格率が80%を超えた段階で「さらに難しい評価が必要」という圧力がかかる一方、タスクの質を担保する仕組みが追いついていなかった。

AIエージェントによる品質チェックの可能性

今回の監査自体が、AIエージェントの新しい活用方向を示している。Codexベースの調査エージェントは、大量のタスクに対してテスト実行やリポジトリ精査を高速に繰り返し、人間だけではスケールしない品質チェックを実現した。

従来、ベンチマークの品質管理は人手に頼る部分が大きく、大規模なデータセットでは現実的ではなかった。OpenAIの事例は「AIがAIの評価基準をチェックする」というメタ評価の時代の到来を感じさせる。

これからのベンチマーク開発に求められるもの

OpenAIは今回の監査結果を受け、SWE-Bench Proを推奨するという以前の見解を撤回した。同時に、評価コミュニティ全体に向けて、経験豊富なソフトウェア開発者がAI評価専用にベンチマークを設計するアプローチを提唱している。

重要なのは「ゲーム化されにくく」「信頼でき」「本当のモデル能力を反映する」評価基盤だ。それが安全性判断や展開戦略の土台になるからだ。SWE-Bench Proの教訓は、どんなに広く使われているベンチマークでも、定期的な品質監査が欠かせないというシンプルな事実に尽きる。

この記事のポイント

  • SWE-Bench Proの公開タスク731件のうち、約30%が破損していると判明した
  • 問題は「過度に厳格なテスト」「要件不足のプロンプト」「低カバレッジテスト」「ミスリーディングなプロンプト」の4カテゴリに分類される
  • OpenAIは3段階の品質監査パイプライン（自動抽出 → AIエージェント調査 → 人間レビュー）で問題を特定した
  • ベンチマークの定期監査と、AI評価専用に設計されたデータセットの必要性が改めて浮き彫りになった
海田 洋祐
, , , ,
AI・開発支援
WordPress 7.0.1でクラシックエディタ保存できない時の原因と直し方
2026年7月13日 0

WordPress 7.0.1でクラシックエディタ保存できない時の原因と直し方

WordPress 7.0.1 更新後にクラシックエディタや WPBakery などのページビルダーで投稿や固定ページを保存できない、下書きが消えるといった症状は、PHP 8.4 との互換性問題が原因だ。PHP バージョンを 8.3 以下に切り替えればこの問題は解消する。

クラシックエディタで保存できずリダイレクトされる現象の正体

クラシックエディタで保存できずリダイレクトされる現象の正体

WordPress 7.0.1 に更新した直後から、クラシックエディタプラグインを有効化していると「公開」「下書き保存」をクリックしても保存されず、投稿一覧にリダイレクトされてしまう。保存したはずの記事や固定ページは一覧からも消え、下書きにも残らない。

さらにややこしいのは、ブロックエディタ（Gutenberg）では問題なく保存できるという点だ。クラシックエディタのプラグインを無効化せずとも、ブロックエディタ側で開いて操作すれば保存は成功する。このため一見すると「特定のプラグインだけが壊れている」ように見えるが、実際にはクラシックエディタ系や WPBakery など旧来の編集画面に依存するツール全般で同じ症状が出る。

この現象はプラグイン側の不具合ではなく、WordPress コアが動作する PHP のバージョンに起因する。特に PHP 8.4 環境で顕在化しやすい。

なぜ PHP 8.4 でクラシックエディタが動作しなくなるのか

なぜ PHP 8.4 でクラシックエディタが動作しなくなるのか

根本原因は PHP 8.4 で廃止または挙動が変更された関数や構文が、クラシックエディタの編集画面や保存処理の中で使われていることにある。古いエディタ画面は WordPress コアの一部として動作するが、その内部処理が新しい PHP の厳格な型チェックや廃止予定の警告（Deprecated）に引っかかり、画面遷移やデータ保存に失敗する。

たとえば、PHP 8.4 では暗黙の nullable 型宣言が非推奨になり、引数のデフォルト値や型宣言の扱いが厳密化された。WordPress の管理画面まわりには長い歴史を持つコードが多く、こうした細かな PHP の変更に対してすべてのプラグインやテーマが追随できているわけではない。

ブロックエディタが正常に動作するのは、ブロックエディタの保存処理が REST API を経由し、比較的新しいコードベースで実装されているため、PHP 8.4 の影響を受けにくいからだ。

PHP バージョンを 8.3 に切り替えて問題を解消する

PHP バージョンを 8.3 に切り替えて問題を解消する

現時点で最も確実な対処法は、サーバーの PHP バージョンを 8.3 にダウングレードすることだ。PHP 8.4 はリリースされたばかりで、WordPress エコシステム全体の完全な互換性が確保されるまでは安定動作が見込める 8.3 を使うほうが無難である。

PHP 8.4
クラシックエディタ保存不可 → 一覧にリダイレクト → 記事消失
↓
STEP 1 サーバー管理画面から PHP 設定を開く
↓
STEP 2 PHP 8.3 を選択して適用する
↓
PHP 8.3
クラシックエディタ正常保存・下書きも残る

多くのレンタルサーバーではコントロールパネル（cPanel や独自管理画面）から簡単に PHP バージョンを切り替えられる。

サーバー管理画面での具体的な操作

cPanel を使っている場合は「PHP の選択」または「MultiPHP Manager」といったメニューを探す。対象ドメインを選択し、ドロップダウンメニューから「PHP 8.3」を選んで保存するだけだ。変更は数分以内に反映される。

独自の管理画面を提供しているサーバーでも、多くの場合「PHP 設定」「PHP バージョン管理」といった項目がある。もし見つからなければサーバー運営会社のサポートに「PHP バージョンを 8.3 に変更したい」と伝えれば対応してくれるケースが多い。

変更前に現在の PHP バージョンを確認する

WordPress 管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、「サーバー」セクションを見ると現在の PHP バージョンが表示されている。ここで 8.4 以上であれば今回の問題に該当する可能性が高い。

PHP 8.3 への切り替えでも直らない場合の追加確認

PHP 8.3 への切り替えでも直らない場合の追加確認

ごくまれに、PHP バージョンを下げても問題が続くことがある。そんなときは次の3点を順に確かめる。

ブラウザキャッシュと WordPress キャッシュのクリア

PHP の変更後にブラウザのキャッシュが残っていると、古い JavaScript や CSS で画面が正しく動作しないことがある。ブラウザのキャッシュを削除するか、シークレットウィンドウで管理画面を開き直す。また、WordPress 側でキャッシュプラグインを使っている場合はそのキャッシュもすべて削除する。

管理画面で JavaScript エラーが出ていないか調べる

ブラウザの開発者ツール（F12 キー）を開き、「コンソール」タブで赤いエラーが出ていないか確認する。保存ボタンを押した瞬間に何らかの JavaScript エラーが記録されていれば、それが原因の手がかりになる。

WordPress のデバッグモードでログを取得する

wp-config.php に以下のコードを追加してデバッグモードを有効にすると、保存時のエラーが wp-content/debug.log に記録される。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

ログに「Deprecated」や「Fatal error」が記録されていれば、それが直接の原因を示している。ただし、大半のケースでは PHP 8.3 への切り替えだけで問題が解消するため、ログを調べるのはレアケースの最終手段と考えてよい。

よくある質問

PHP 8.3 に戻すとセキュリティ面で問題はないか

PHP 8.3 は現在もアクティブサポートが継続しており、セキュリティ修正は提供され続けている。WordPress 公式の推奨バージョンでもあるため、本番環境で使っても安全だ。無理に最新の 8.4 に上げるよりも、安定した 8.3 で運用するほうが結果的にリスクが低い。

PHP 8.3 に変更したのにクラシックエディタがまだ使えない

PHP の変更がサーバーに完全に反映されるまで数分かかることがある。まずは数分待ってから再度試す。それでも改善しない場合は、一度プラグインを無効化して再度有効化してみる。また、前述のキャッシュクリアも忘れずに行う。

WPBakery や他のページビルダーでも同じ症状が出るのか

出る。クラシックエディタだけでなく、WPBakery をはじめとする旧型の編集画面を使うページビルダー全般が PHP 8.4 の影響を受ける。これらもブロックエディタと異なり、内部の保存処理が古いコードに依存しているためだ。

PHP バージョンを自由に変更できないサーバーではどうすればいいか

サーバー管理画面に PHP バージョンの変更オプションがない場合は、サーバー運営会社のサポートに連絡して「PHP 8.3 への切り替えを依頼したい」と伝える。ほとんどの会社は対応してくれる。もし変更ができないと言われた場合は、PHP 8.4 の環境でも動作するように WordPress のアップデートを待つか、ブロックエディタに一時的に切り替えて運用するしかない。

この記事のポイント

  • WordPress 7.0.1 でクラシックエディタ保存不可になる原因は PHP 8.4 の互換性問題
  • PHP バージョンを 8.3 に下げると問題は即座に解消する
  • ブロックエディタは PHP 8.4 でも正常に動作するため一時的な回避策になる
  • 変更後はブラウザキャッシュと WordPress キャッシュを忘れずにクリアする
  • PHP 8.3 は公式推奨でありセキュリティ面でも安全に運用できる
佐々木 太陽
, , , , ,
お悩み・トラブル解決
GPT-5.6がMicrosoft 365 Copilotの優先モデルに。WordやExcelでのAI活用が大きく変わる
2026年7月12日 0

GPT-5.6がMicrosoft 365 Copilotの優先モデルに。WordやExcelでのAI活用が大きく変わる

OpenAIは2026年7月9日、最新のフラッグシップモデル「GPT-5.6」を発表した。このモデルはMicrosoft 365 Copilotの新しい優先モデルとして、Word、Excel、PowerPoint、Copilot Chat、そして新コラボレーションツールのCoworkに導入される。

GPT-5.6の最大の特徴は、トークンあたりの有用な作業量を大幅に向上させたことだ。複雑なタスクをオンデマンドで処理する能力を持ちながら、コストパフォーマンスにも優れている。日常的に使うオフィスツールで、より高度なAI支援が受けられるようになる。

このアップデートは、すでにMicrosoft 365を契約しているユーザーにとっては追加費用なしで利用できる見込みだ。AIアシスタントがビジネス文書の作成からデータ分析まで、より深く関与する時代が本格的に到来する。

GPT-5.6の位置づけと技術的特徴

GPT-5.6の位置づけと技術的特徴

GPT-5.6はOpenAIの最新フラッグシップシリーズに位置する。従来のGPT-5シリーズと比較して、モデルアーキテクチャと学習手法の両面で改良が加えられている。特に「トークンあたりの有用な作業量」という指標が大幅に改善された点が重要だ。

トークン効率の改善がもたらすもの

GPT-5.6は、同じプロンプトに対してより少ないトークン数で高品質な結果を返す。これはAPIの利用料金削減に直結するだけでなく、長文のドキュメント作成や大規模なデータ分析において、途中で文脈が途切れるリスクを低減する。

具体的には、GPT-5.5と比較してPDFなどの複雑なドキュメントの読込精度が約20パーセント向上し、プログラミングにおいては20パーセント多くのコード変更を正確に提案できるようになった。日常的なオフィスワークの場面では、素早く意図を理解し、より少ない修正で作業を完了できることを意味する。

オンデマンドの複雑タスク処理能力

GPT-5.6は、単純な質問応答から高度な分析まで、タスクの複雑さに応じて処理能力を段階的に引き上げる設計がなされている。軽いタスクではトークンを節約しつつ、必要なときだけ深い推論を実行する仕組みだ。

このオンデマンド機能は、Microsoft 365 Copilotの利用体験を大きく変える。Wordで文章の校正を依頼するような日常的な操作では軽快に動作し、Excelで売上データの多変量解析を依頼するような複雑なタスクでは、モデルが自律的に深い思考を展開する。

OpenAIのAPIプロダクト責任者であるNikunj Handa氏は、ブログ記事の中で「GPT-5.6をOpenAI API経由でMicrosoft 365 Copilotに提供することで、組織がすべてのトークンからより有用な作業を得られるように支援する」と述べている。

各アプリケーションでの具体的な変化

各アプリケーションでの具体的な変化

GPT-5.6の導入により、Microsoft 365の各アプリケーションでどのような改善が期待できるのか。公式発表の内容を基に整理する。

Wordでの文書作成と編集

Wordでは、ドキュメントの下書き作成、編集、推敲にかかるプロンプト操作の往復回数が減る。GPT-5.6が文脈をより深く理解し、ユーザーが求める文体や構成に近い結果を初回から提示できるためだ。

従来のAI支援では「もう少しフォーマルに」「3段落目をもう少し詳しく」といった追加指示が頻繁に必要だった。GPT-5.6では、最初の指示だけで目的に合った文書の完成度が大幅に高まる。ビジネス提案書や報告書の作成時間が短縮されることは間違いない。

Excelでのデータ分析

Excelでは、より深いデータ分析をより効率的なトークン使用量で実行できるようになる。GPT-5.6はスプレッドシートの構造を正確に把握し、複数のシートにまたがる複雑な関係性も理解する。

ユーザーは「売上データから地域別のトレンドを抽出してグラフ化して」といった自然言語での指示から、数クリックでインサイトを得られるようになる。トークン効率が向上したことで、大規模なデータセットを扱う場合でもレスポンスが速く、分析の途中で途切れることが少なくなる。

PowerPointでのプレゼンテーション作成

PowerPointでは、初期アイデアをより洗練されたプレゼンテーションに仕上げるプロセスが加速する。GPT-5.6はスライド構成の提案からビジュアルデザインの方向性まで、従来よりも少ない手動調整で高い完成度を実現する。

特に複数人でのレビューを経る企業プレゼンの作成では、初稿のクオリティが上がることでレビューサイクルが短縮される効果が期待できる。MicrosoftのCopilot & Agents Core担当プレジデントであるNitin Agrawal氏も「より洗練されたアウトプットを生み出せる」と強調している。

Coworkでのチームコラボレーション

CoworkはMicrosoft 365に新たに追加されたコラボレーションツールで、GPT-5.6の優先モデル化対象に含まれている。チーム間の複雑で機能横断的な作業をAIが支援し、手動での調整作業を減らして高品質な成果物を生み出せるようになる。

プロジェクト管理やタスクの割り振り、進捗の可視化といった領域でAIが積極的に関与することで、チーム全体の生産性向上が見込まれる。複数部署が関わる大規模プロジェクトほど、その恩恵は大きいだろう。

実務へのインパクトと今後の展望

実務へのインパクトと今後の展望

GPT-5.6を搭載したMicrosoft 365 Copilotは、単なる文章作成支援ツールの枠を超えつつある。ビジネスの現場でAIが担う役割は、補助から中核へと移行していく転換点にあると言える。

特に重要なのは、Microsoftがモデルをネイティブ提供するだけでなく、OpenAI APIを直接経由してGPT-5.6にアクセスする方式も併用している点だ。これにより、モデルのアップデートサイクルがより柔軟になり、最新のAI機能がより早くユーザーに届くようになる。

従来のCopilot（GPT-5.5世代）
プロンプト入力 → 分析・生成 → 結果出力 → 追加修正が必要
※複数回の調整プロンプトが発生
↓
GPT-5.6搭載Copilot
プロンプト入力 → 深い理解と分析 → 高品質な結果出力 → ほぼ修正不要
※初回から完成度の高いアウトプット

従来のCopilotでは、最初の回答に対して追加の指示を出して修正する場面が多かった。GPT-5.6では、最初のプロンプトだけで高品質な結果が得られる可能性が大幅に高まっている。日常的なAI利用の心理的ハードルが下がることを意味する。

中小企業や個人事業主にとっての意味

大企業向けの話に聞こえるかもしれないが、このアップデートは中小企業や個人事業主にとっても大きな意味を持つ。Microsoft 365の契約があれば追加費用なしで利用できるため、高度なAI支援を手軽に業務に取り入れられる。

特に、一人で複数の役割をこなす必要がある個人事業主にとって、文書作成、データ分析、プレゼン資料作成のすべてをAIが支援してくれるのは強力だ。GPT-5.6によるトークン効率の向上は、限られた時間でより多くの成果を出すことにつながる。

今後のAIアシスタントの方向性

GPT-5.6のMicrosoft 365 Copilotへの統合は、AIアシスタントが「質問に答えるツール」から「自律的に作業を進めるパートナー」へと進化する道筋を示している。トークン効率とオンデマンド推論の組み合わせは、今後のAIモデル開発における標準的なアプローチになるだろう。

OpenAIとMicrosoftのパートナーシップは、AIの恩恵をより多くの個人や組織に届けるという共通の目標に基づいている。両社はこの協力関係をさらに深めていく意向を表明しており、今後のアップデートにも注目が集まる。

この記事のポイント

  • GPT-5.6はトークン効率を大幅に改善し、Word、Excel、PowerPoint、CoworkでのAI支援がより高精度になった
  • 複雑なタスクではオンデマンドで深い推論を実行し、軽いタスクでは素早く応答する設計
  • Microsoft 365ユーザーは追加費用なしで最新のAI機能を利用できる見込み
  • 中小企業や個人事業主も、日常業務の効率化にこのアップデートを活用できる
  • OpenAIとMicrosoftの協力関係は継続し、今後もAIアシスタントの進化が期待される
海田 洋祐
, , , , , , ,
AI・開発支援
Hostingerが写真から即決済リンクを生成するAIツール発表、EC販売チャネルの分散化が加速
2026年7月11日 0

Hostingerが写真から即決済リンクを生成するAIツール発表、EC販売チャネルの分散化が加速

リトアニア発のホスティング企業Hostingerが、商品写真をアップロードするだけで決済リンクを生成するEC向けAIツール「Quick Links」を発表した。従来のECの常識を覆し、自社サイトを持たない販売手法を一段と推し進めるものだ。

この機能により、販売者はSNS投稿やメッセージ、メールで直接決済リンクを共有できる。見逃せないのは、単なるチェックアウト機能の追加ではなく、ECプラットフォームが「ストアの先」へと進出する方向性を明確に打ち出した点にある。

ここではQuick Linksの仕組みにとどまらず、ウェブサイトを介さないEC販売の潮流、Shopifyなど他のプラットフォームの動き、そして小規模事業者がこれから取るべき販売チャネル戦略について分析していく。

HostingerのQuick Links機能の詳細

HostingerのQuick Links機能の詳細

AIが商品写真から販売ページを自動生成

Quick Linksの使い方は極めてシンプルだ。販売者が商品の写真を1枚アップロードすると、HostingerのAIが商品説明、詳細スペック、推奨価格を含む商品ページを自動で作成する。そのページには決済機能が組み込まれており、生成されたリンクをSNSやチャットで共有すれば、購入者がそのまま支払いを完了できる。

従来のECでは、まずプラットフォームを選び、ストアを構築し、商品を登録し、決済手段を設定し、集客するという手順が必要だった。Quick Linksは、この流れを「写真1枚で販売開始」まで圧縮する。ECの専門知識がない個人や小規模事業者にとって、参入障壁が極めて低くなる仕組みだ。

ウェブサイト不要のEC販売は目新しいか

しかし、この「サイト不要」というコンセプト自体は完全な新機軸ではない。決済リンク（Payment Links）やリンクインバイオツール、ダイレクトメッセージを使った販売は以前から存在している。StripeやSquare、PayPal、Shopify Starter、TikTok Shop、Instagram、Facebook Marketplace、WhatsAppなど、すでに多くの企業が従来型ストアの外側で取引を完結させる手段を提供してきた。

決定的な違いは、AIによる「写真から商品ページを自動生成する」工程が加わったことだ。これにより、販売者は商品情報を手入力する手間さえも省ける。Hostingerは単なる決済手段の提供ではなく、「AIが販売を組み立てる」という次元へ踏み込んだ。

社会的文脈とHostingerのポジショニング

HostingerのウェブサイトビルダーおよびEC責任者であるAuksė Žirgulė氏は、次のように述べている。「コマースは単純なストアからエコシステムへと移行している。人々は多様なチャネルで商品を発見し、AIエージェントが選択や比較、購入を支援することが増えている。小規模販売者にとって、この変化は大きな機会だが、顧客と同じスピードで事業を動かせる場合に限られる」

この発言の核心は「次にどのチャネルが重要になるかを予測しなくてよい」というホスティング事業者の新たな役割提示にある。販売者はチャネル開拓に頭を悩ませる必要はなく、まず商品を素早く世に出すことが優先される。チャネル戦略の複雑さをプラットフォーム側が吸収する、という宣言ともとれる。

ECプラットフォームが直面する販売チャネルの分散化

ECプラットフォームが直面する販売チャネルの分散化
従来のEC販売フロー（Before）
ストア構築 → 集客 → 商品ページ閲覧 → カート追加 → 決済
販売者がすべてのチャネルを管理する必要がある
↓
Quick Linksによる販売フロー（After）
商品写真撮影 → AIが商品ページ生成 → 即決済リンク発行 → SNSやメッセージで共有 → 購入者が直接決済
チャネル開拓をプラットフォームが肩代わりする

上図のように、従来はストア構築から集客、決済まで一気通貫で自前管理するのが常識だった。Quick Linksはこの流れを「商品情報をAIが生成して即座に販売リンク化」するモデルへと変える。販売者は来店を待つ必要がなく、自ら顧客のいる場所へリンクを届けにいける。

ECソフトウェアの従来モデルが揺らぐ理由

ECソフトウェアは長年、「ストアを作り、商品を並べ、トラフィックを集め、訪問者を購入に転換する」という単純明快なモデルに依存してきた。このモデルは今でも通用するが、その確実性は低下している。

  • 検索エンジンは質問に直接回答するようになり、ユーザーが商品ページに到達するまでにAIが情報を要約してしまう。
  • SNSプラットフォームはユーザーをフィードやアプリ内に留め、外部リンクへの遷移を抑制する傾向を強めている。
  • マーケットプレイスは需要を一手に集め、販売ルールをコントロールする。
  • 生成AIが商品の比較や選定を、販売者のサイトを訪れる前に行う可能性が高まっている。

Googleが構想する「ユニバーサルカート」は、検索結果やYouTube、Gmail、AI体験上でカートを形成し、販売者のサイト外で購入が完結する世界を示唆している。販売者は在庫やフルフィルメント、カスタマーサービスを引き続き担うが、購買ジャーニーの起点やカートの支配権は手放すことになるかもしれない。

Hostingerの方向性が示すプラットフォーム間競争

この不確実性の高まりこそ、Hostingerのポジショニングの背景だ。同社は単にもっと速く決済リンクを作る機能を提供しているのではない。ECプラットフォームは販売者に対して「今日はSNS投稿で、明日はマーケットプレイスで、来月はAIエージェント経由で」販売できるように支援しなければならない、というメッセージを発している。

Shopifyも同様の方向にかじを切っている。ソーシャルコマース向けツールやPOS（販売時点情報管理）の強化、Shop Payの拡張、マーケットプレイス統合、AIによる商品発見支援などを通じて、販売者がより多くの販売機会を掴めるようにしている。Hostingerの発表は、その小規模販売者版だ。ECプラットフォームの役割が「ストアのホスティング」から「販売成功のための機会創出」へと変わりつつある。

販売者にとっての実務的な意味

販売者にとっての実務的な意味

「最初の販売」はサイト外で起こる

オンライン販売者にとって、HostingerのQuick Linksが投げかける最大の含意はこれだ。「最初の販売は、自社サイトの外で起こる時代になった」のである。潜在顧客が最初に商品を目にする場所は、SNSのタイムラインかもしれないし、友人のメッセージかもしれないし、AIアシスタントのレコメンドかもしれない。

しかし、だからといって自社サイトの重要性が消えるわけではない。信頼構築、検索プレゼンスの維持、コンテンツマーケティング、利用規約の提示、メールアドレス収集、カスタマーサービス、リピート購入促進といった要素は、依然として自社サイトが最も適した場所だ。ブランドや商品を丁寧に説明し、顧客との長期的な関係を築く場としての役割は揺るがない。

小規模事業者がまず着手すべきこと

小規模事業者がQuick Linksのようなツールを活用する際、最初に取り組むべきは「販売チャネルの即時展開」だ。商品写真さえあれば、今日からSNS上で直接販売を始められる。特設ページのデザインや決済設定に数日を費やす必要はない。

そのうえで、徐々に自社ECサイトを構築し、ブランド体験の深化やリピーター獲得の仕組みを整えていくという二段構えの戦略が現実的になる。これまでは「まずストアを作り、その後で集客」という順序だったが、これからは「まず販売を始め、その後でストアを育てる」という順序も合理的な選択肢になる。

ECの未来像：ストアとトランザクションの分離

ECの未来像：ストアとトランザクションの分離

これまでのECは、ストアとトランザクション（取引）が一体化していることが前提だった。商品を買うには、販売者のストアにアクセスし、そのストアのカートを使い、そのストアの決済フローを経由する。この一体型モデルが、技術の進化とともに解体されつつある。

決済リンク、SNSショップ、マーケットプレイス、AIエージェントは、いずれも「販売者のサイトを経由しないトランザクション」を可能にする。ストアはブランドの本拠地として残り続けるが、販売そのものは多様な「セリングサーフェス（販売面）」に分散していく。

このトレンドは国内のEC事業者にも無関係ではない。BASEやSTORESのような国内プラットフォームも、SNS連携やリンク販売機能を強化している。WooCommerceで構築されたECサイトであっても、決済リンクを積極的に外部チャネルで活用する発想が求められるようになるだろう。

プラットフォーム選定の新しい基準

販売者やWeb制作者がECプラットフォームを選ぶ際、これまでは「ストア構築のしやすさ」「デザインの自由度」「決済手段の豊富さ」が主な評価ポイントだった。しかし今後は、「外部チャネルとの連携性」や「AIによる販売支援機能」が選定基準の上位に食い込んでくる可能性が高い。

特にWooCommerceユーザーは、WordPress上でのコンテンツマーケティングとの親和性を強みとしつつも、SNSやメッセージアプリでのダイレクト販売をどう取り込むかが課題になる。プラグインや拡張機能で決済リンクを発行し、AIによる商品情報の自動最適化を組み合わせるといった対策が現実的だ。

この記事のポイント

  • HostingerのQuick Linksは、商品写真1枚からAIが商品ページと決済リンクを自動生成する。ストア構築の手間を完全に省くアプローチだ。
  • ウェブサイト不要のEC販売自体は新しい概念ではないが、AIによる自動生成が加わったことで、販売開始のスピードが飛躍的に向上する。
  • ECプラットフォームは、販売者のストア外での販売を支援する方向へシフトしている。Shopifyも同様の多チャネル戦略を推進中だ。
  • 小規模事業者は「最初の販売をサイト外で行い、その後で自社サイトを育てる」という二段構えの戦略を検討する価値がある。
  • WooCommerceなど既存のEC環境でも、決済リンクやAIによる販売支援を積極的に取り入れることが、今後の競争力を左右する。
海田 洋祐
, , , , , ,
EC制作
VercelがBetter Authを買収、TypeScript認証ライブラリとエージェントIDの未来
2026年7月11日 0

VercelがBetter Authを買収、TypeScript認証ライブラリとエージェントIDの未来

VercelがBetter Authを買収。TypeScript認証ライブラリとエージェントアイデンティティの取り込み

VercelがBetter Authを買収。TypeScript認証ライブラリとエージェントアイデンティティの取り込み

2026年7月7日、VercelはオープンソースのTypeScript認証ライブラリ「Better Auth」を買収したと発表した。ライブラリの週間npmダウンロード数は470万を超え、すでに850人以上のコントリビューターが開発に参加している。創設者のBereket Engida氏とコアチームはVercelに加わり、Better Authそのものと、関連プロジェクトであるエージェント認証プロトコル「Agent Auth」の開発を続ける。

今回の買収は、認証の仕組みをフレームワークやプラットフォームに依存しない形で提供する動きであり、なかでも「エージェントに独自のアイデンティティを与える」という構想が注目を集めている。背景と具体的な影響を順に整理していく。

Better Authとは何か。週間470万DLの認証ライブラリ

Better Authとは何か。週間470万DLの認証ライブラリ

Better Authは、TypeScriptで書かれたオープンソースの認証ライブラリだ。従来の認証ライブラリに比べて設定がシンプルで、Next.jsやNuxtなど特定のフレームワークに依存しない。データベースやセッション管理の選択肢も広く、開発者が自前で認証周りをコントロールできる点が特徴である。

フレームワーク非依存の設計思想

多くの認証ライブラリは特定のフレームワークと密結合だったり、プラットフォームの管理画面を通さなければ設定が完了しなかったりする。Better Authは「どこでも動き、開発者が認証を所有する」という原則で作られている。これにより、プロジェクトの要件が変わっても認証部分の移行が容易になる。

コミュニティ主導の成長

470万ダウンロードと850人以上のコントリビューターという数字は、単なるGitHubスターの数ではない。実際に本番環境で使われ、機能追加やバグ修正が活発に行われている証拠である。Vercelは買収後もMITライセンスを維持し、コミュニティガバナンスを継続すると明言している。

買収の背景。Vercelが描く「オープンウェブ」と認証の位置づけ

買収の背景。Vercelが描く「オープンウェブ」と認証の位置づけ

Vercelは2025年に公開した「オープンSDK戦略」のなかで、ソフトウェアはデフォルトでオープンであり、疎結合で、どのプラットフォームにも移植可能であるべきだと述べている。Next.jsやAI SDK、Nuxtにもこの方針が適用されており、今回のBetter Auth買収もその延長線上にある。

認証を「所有する」という考え方

クラウドサービスが認証を代行する形は便利だが、ロックインのリスクがある。Better Authのようにライブラリ単位で認証を導入できれば、インフラを移行しても同じ仕組みを使い続けられる。Vercelはこの「所有可能な認証」をエコシステムに取り込むことで、開発者にとっての自由度を高めようとしている。

エージェントアイデンティティが切り開く、新しい認証の形

エージェントアイデンティティが切り開く、新しい認証の形

買収発表のなかで特に強調されたのが、エージェント（自律的に動作するソフトウェア）に「自分自身のID」を持たせるという構想だ。Better Authチームが開発している「Agent Auth」プロトコルは、まさにこれを実現するためのものである。

従来のエージェント実行（Before）
ユーザー 指示を出す → エージェント ユーザー権限で実行
すべてのサービスがユーザー本人として認識。個別の権限制限や失効が困難。
※エージェントを停止すると、すべての連携が遮断される。
↓
Agent Auth プロトコル導入後（After）
ユーザー 指示を出す → エージェントA 限定権限で実行
サブエージェントB 別の限定権限で実行
各エージェントが独立したIDと権限を持ち、ユーザーは制御ポイントを一元管理できる。

この概念図で示すように、Agent AuthではエージェントごとにIDを発行し、スコープを絞った権限と失効可能な認証情報を持たせることができる。ユーザーが単一のコントロールポイントから、個々のエージェントの権限を管理できる点が革新的だ。

なぜエージェントに独自IDが必要なのか

現在、AIエージェントがユーザーに代わって予約や購入を行う場合、エージェントはユーザー自身の認証情報を使ってサービスにアクセスする。この方式では、エージェントに渡す権限を細かく制御できない。また、不正が疑われた場合に特定のエージェントだけを停止することが難しく、結局すべての連携を遮断する必要があった。

Agent Authは、エージェントひとつひとつに「ペルソナ」のようなIDを割り当てる。たとえば「カレンダー参照専用エージェント」「メール送信専用エージェント」といった具合に役割を分け、不要になればそのIDだけを無効化できる。これはエージェントが当然のように動く世界において、セキュリティと管理性を両立する基盤技術といえる。

Vercel Connect と eve への統合

Better AuthチームはVercelに加わり、このエージェントアイデンティティをVercel Connectとeveに組み込むと発表されている。Vercel Connectは開発者がさまざまなサービスやAPIを安全に連携させるための仕組みであり、eveはVercelが提供するAIエージェントプラットフォームである。認証レイヤーが標準装備されることで、エージェントを使った機能をより安全かつ手軽に実装できるようになるだろう。

開発者コミュニティとライブラリの今後

開発者コミュニティとライブラリの今後

買収によってBetter Authのライセンスや開発体制が変わるのではないかと懸念する声もある。しかしVercelは、ライブラリはMITライセンスのまま無料で提供され、名称も変更されず、同じコミュニティガバナンスモデルで開発が続くと明確に述べている。

オープンソースとしての継続

Better AuthのGitHubリポジトリは引き続き公開され、プルリクエストやIssueを通じたコミュニティ参加も歓迎される。Vercelのリソースが投入されることで、ロードマップの進行速度が上がったり、ドキュメントの整備が進んだりするメリットが期待できる。

フレームワークサポートの拡大

Better AuthはすでにNext.js以外にもNuxt、SvelteKit、Remixなど多様なフレームワークで利用できる。Vercelは特定のフレームワークに偏らないサポートを続ける方針を示しており、エコシステム全体への貢献が加速する可能性がある。

Vercelの戦略から見る、認証とエージェントの未来

Vercelの戦略から見る、認証とエージェントの未来

今回の買収は、単に認証ライブラリを手に入れる以上の意味を持つ。Vercelはすでにホスティング、サーバーレス関数、エッジネットワーク、AI SDKと積み上げてきた。そこに「認証」と「エージェントアイデンティティ」というピースが加わることで、開発者がアプリケーションを作り、デプロイし、AIエージェントを安全に動かすための一気通貫のプラットフォームが姿を現しつつある。

「エージェントインフラ」の基盤として

Vercelは以前から「エージェントインフラストラクチャ（agentic infrastructure）」という概念を掲げている。これは、AIエージェントが動くための実行環境だけでなく、ストレージ、キュー、認証といったバックエンドの一式を提供する考え方だ。Better Authの買収によって、その認証レイヤーが大きく強化されることになる。

競合との差別化要因

他社のクラウドプラットフォームも認証機能を提供しているが、多くはプロプライエタリなサービスである。Better AuthのようにオープンソースでMITライセンスの認証ライブラリを中核に据えるアプローチは、ベンダーロックインを嫌う開発者層に強く支持されるだろう。とくにエージェントの台頭により認証の複雑さが増すなかで、「所有できる認証」の価値はますます高まっていく。

この記事のポイント

  • VercelがオープンソースのTypeScript認証ライブラリ「Better Auth」を買収。創設者とコアチームがVercelに参加する。
  • Better Authは週間470万ダウンロード、850人以上のコントリビューターを持つ。MITライセンスとコミュニティガバナンスは維持される。
  • エージェントに独自のIDと制限付き権限を与える「Agent Auth」プロトコルの開発が加速し、Vercel Connectやeveに統合される予定。
  • 従来のエージェント実行における権限制御の課題を解決し、エージェントごとの失効やスコープ管理が可能になる。
  • Vercelは「オープンSDK戦略」に沿って認証レイヤーを強化し、エージェントインフラの基盤を固める動きを加速させている。
海田 洋祐
, , , , , ,
クラウド・インフラ
カートが0円だとWooCommerceの注文が完了しない時の直し方
2026年7月11日 0

カートが0円だとWooCommerceの注文が完了しない時の直し方

なぜカート合計が0円だとチェックアウトが完了しないのか

なぜカート合計が0円だとチェックアウトが完了しないのか

WooCommerce の最低購入金額制御プラグイン（たとえば Minimum Purchase Amount Control など）は、指定した金額未満の注文を受け付けないように設計されている。このプラグインは通常、カートの合計金額が設定した最低金額を下回るとチェックアウトをブロックする。しかし「無料商品を許可する」「クーポンで0円になる場合を許可する」といった例外ルールを設定していても、内部的にはチェックアウト処理の最終段階で金額を再評価し、ブロックをかけてしまうケースがある。

このとき画面上では「注文する」ボタンを押せてしまい、一見すると購入が完了したように見える。ところが実際には注文データが正しく確定されず、商品がカートに取り残される。リダイレクト先の注文確認ページ（サンキューページ）にも遷移しない。プラグインを停止すると問題が消えることから、プラグインのゼロ円ブロック機能が直接の原因だ。

フィルターフックでゼロ円チェックアウトを許可する手順

フィルターフックでゼロ円チェックアウトを許可する手順

このプラグインには、ゼロ円の注文を許可するための専用フィルターフック ct_mpac_allow_zero_total が用意されている。このフックを有効にすれば、無料商品やクーポンで合計が0円になったカートでも問題なくチェックアウトが完了するようになる。

以下の手順では、子テーマの functions.php に数行のコードを追加する。子テーマを使っていない場合は、Code Snippets プラグインなどを利用しても同じ結果が得られる。

STEP 1 子テーマの functions.php を開く（外観 → テーマファイルエディター）
↓
STEP 2 ファイル末尾に以下のコードを追加する
↓
STEP 3 ファイルを更新して保存する
↓
STEP 4 0円になる商品をカートに入れてチェックアウトをテストする

追加するコードは次のとおりだ。

add_filter( 'ct_mpac_allow_zero_total', '__return_true' );

この1行で、プラグインがゼロ円の注文を許可するようになる。__return_true は WordPress の組み込み関数で、単純に true を返す。フィルターにこれを渡すことで「常に許可する」という挙動に切り替わる仕組みだ。

Code Snippets プラグインを使う場合は、新規スニペットを追加し、上記のコードを貼り付けて「サイト全体で実行」に設定すればよい。

コード追加後も改善しない場合の確認ポイント

コード追加後も改善しない場合の確認ポイント

フィルター名がプラグインのバージョンと合っているか確認する

プラグインのバージョンアップによってフィルター名が変更されている可能性がある。プラグインの公式ドキュメントやソースコード内で apply_filters を検索し、最新のフック名を確認するのが確実だ。特にプラグイン名が似ている別の最低購入金額プラグインに乗り換えた場合は、フック名がまったく異なるため注意が必要になる。

キャッシュ系プラグインやサーバーキャッシュの影響を疑う

functions.php を更新したのに改善しない場合、WordPress のキャッシュプラグインやサーバーレベルのキャッシュ（OPcache など）が原因で変更が反映されていないことがある。キャッシュをすべてクリアし、さらにブラウザのシークレットモードで動作をテストしてみる。OPcache が効いているレンタルサーバーでは、ファイル更新から数分間は古いコードが動き続けるケースもある。

決済ゲートウェイ側のゼロ円制限を調べる

ごくまれに、WooCommerce の決済ゲートウェイ自体が0円のトランザクションを許可していない場合がある。プラグインの問題が解消されたあともチェックアウトが進まないときは、Stripe や PayPal などのゲートウェイ設定で「0円の注文を許可する」オプションが存在しないか確認する。テスト用に代金引換や銀行振込など、実決済を伴わないゲートウェイに切り替えて試すのも有効な切り分け方法だ。

よくある質問

このフィルターはどのプラグインに対応しているのか

ct_mpac_allow_zero_total は、主に「Minimum Purchase Amount Control for WooCommerce」系のプラグインで使われるフックだ。プラグインの作者が異なるとフック名も変わるため、必ず利用中のプラグインのドキュメントを参照してほしい。

フィルターを追加する以外の解決策はあるか

プラグインの設定画面で「無料商品を許可」「クーポン適用後の0円を許可」といったチェックボックスが用意されていれば、そちらを有効にするだけで直ることもある。設定が存在しない場合や、設定を入れても効かないときにフィルターを使うのが確実な方法だ。

ゼロ円の注文を許可するとセキュリティ上のリスクはあるか

意図した無料商品や割引クーポン以外で0円になるカートが発生しないよう、クーポンの利用条件や商品価格の設定を適切に管理していれば大きなリスクにはならない。ただし、テストや不正利用対策として、定期的に0円注文のログを確認する運用は推奨する。

子テーマを使わずにコードを追加する方法はあるか

Code Snippets プラグインや WPCode プラグインを利用すれば、テーマファイルを直接編集せずにフィルターフックを安全に追加できる。テーマのアップデートでコードが消える心配もなく、管理画面からオンオフを切り替えられるため、まずはこちらを試すのが安心だ。

この記事のポイント

  • WooCommerce の最低購入金額プラグインが0円の注文をブロックし、チェックアウトが完了しない
  • フィルターフック ct_mpac_allow_zero_total を functions.php に追加すればゼロ円注文を許可できる
  • Code Snippets プラグインを使えば子テーマの編集なしで安全にコードを追加可能
  • 改善しない場合はキャッシュのクリアや決済ゲートウェイの0円制限も確認する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WooCommerce 11.0で配送クラスが非公開タクソノミーに変更
2026年7月11日 0

WooCommerce 11.0で配送クラスが非公開タクソノミーに変更

WooCommerce 11.0が2026年7月28日にリリースされる。このアップデートでは、商品の送料計算に使われる「product_shipping_class」タクソノミーが非公開に変更される。これまで明示的に設定されていなかった公開フラグが、WordPress のデフォルトで true 扱いとなっていた状態が解消され、内部データとしての扱いが明確になる。

多くの店舗や拡張機能では特別な対応は不要だが、配送クラスを公開タクソノミーとして利用していたコードは見直しが必要だ。この変更の背景と、開発者が確認すべきポイントを整理する。

WooCommerce 11.0で配送クラスのタクソノミーが非公開になる

WooCommerce 11.0で配送クラスのタクソノミーが非公開になる

配送クラス（product_shipping_class）は、商品を送料計算のグループに割り当てるための仕組みだ。たとえば「大型商品」「冷蔵商品」といったクラスを作り、各商品に紐づけることで、配送方法ごとに異なる送料を設定できる。

これまでの動き（Before）

WooCommerce 11.0 より前のバージョンでは、配送クラスをタクソノミーとして登録する際に public 引数が指定されていなかった。WordPress のタクソノミー登録関数は public が省略されるとデフォルトで true を適用する。そのため、配送クラスは「公開タクソノミー」として扱われ、is_taxonomy_viewable() が true を返していた。

この状態では、サイトマップ生成、タクソノミーアーカイブの処理、パブリックタクソノミーを列挙するクエリなどに配送クラスが意図せず含まれることがあった。

変更後の動作（After）

WooCommerce 11.0 からは、タクソノミー登録時に 'public' => false が明示的に設定される。これにより is_taxonomy_viewable( 'product_shipping_class' ) は false を返すようになり、WordPress の各種 API で配送クラスが非公開タクソノミーとして扱われる。

変更前（WooCommerce 10.x）
配送クラス → 公開タクソノミーとして扱われる
サイトマップ・アーカイブ・SEO プラグイン等に意図せず現れる
↓
変更後（WooCommerce 11.0）
配送クラス → 非公開タクソノミー（内部データ）
送料計算にのみ使用され、公開領域には現れない

この変更はデータそのものを削除するものではない。すでに登録された配送クラスのタームや商品との紐づけ、送料ルールはそのまま維持される。

なぜこの変更が必要だったのか

なぜこの変更が必要だったのか

配送クラスは本来、商品カテゴリーやタグのように顧客に見せるためのカタログ用タクソノミーではない。あくまでも送料計算のための内部データである。ところが公開タクソノミーとして振る舞うことで、サイトマップに配送クラスのアーカイブ URL が含まれたり、SEO ツールが意図しないページを認識したりといった副作用が生じていた。

一部のストアでは、この挙動を避けるために手動で除外設定を行なっていた。WooCommerce コアの修正により、根本的な原因を取り除き、特に設定をしなくても配送クラスが公開面に漏れ出さないようになる。

また、WordPress の public フラグが false になると、publicly_queryable も自動的に false を継承する。つまり、URL で配送クラスの一覧ページに直接アクセスすることもできなくなる。こうした一貫した内部データとしての扱いが、開発者にとっても予測しやすい動作につながる。

影響を受けるコードのチェックポイント

影響を受けるコードのチェックポイント

WooCommerce Developer Blog の案内に沿って、以下のようなコードを含むテーマやプラグインは変更後の動作を確認する必要がある。

  • is_taxonomy_viewable( 'product_shipping_class' ) が true を返すことを前提にしている
  • 配送クラスのアーカイブページへのリンクをフロントエンドに生成している
  • サイトマップや SEO、ナビゲーションの生成時に product_shipping_class を public タクソノミーとして含めている
  • get_taxonomies() などで公開タクソノミー一覧を取得し、その中に配送クラスが含まれることを期待している
  • タクソノミーの公開ステータスをもとに REST API や GraphQL のスキーマ、検索、フィルタリングをカスタマイズしている
  • 送料計算以外の汎用的な商品グルーピングに配送クラスを流用している
影響あり 公開前提で配送クラスを利用しているコード
影響なし 商品への配送クラス割り当て、送料計算、管理画面からの操作
■ 確認が必要なパターン　■ 引き続き動作する範囲

ごく単純に、配送クラスを送料計算だけに使っている場合は影響を受けない。商品編集画面で配送クラスを設定したり、フックで送料を分岐させたりするコードはそのまま動作する。

開発者が取るべき具体的な対応

開発者が取るべき具体的な対応

基本は何もしなくてよい

配送クラスを送料計算のみに使っているのであれば、コードの修正は不要だ。WooCommerce のコア変更がそのまま適用され、配送クラスは内部タクソノミーとして適切に管理される。

どうしても公開が必要な場合のフィルターフック

特定のサイトや拡張機能で、あえて配送クラスを公開タクソノミーとして扱い続けたいケースもあるだろう。たとえば、配送クラスのアーカイブページをカスタムデザインで用意している場合などだ。

そのような場合は、WooCommerce が用意している register_product_shipping_class_taxonomy_args フィルターを使って、登録時の引数を上書きできる。

add_filter(
    'register_product_shipping_class_taxonomy_args',
    function ( $args ) {
        $args['public']             = true;
        $args['publicly_queryable'] = true;
        return $args;
    }
);

ただし、この方法はあくまで例外的な対応である。WooCommerce Developer Blog も述べているように、公開タクソノミーとして再利用するのではなく、本来の目的に合ったカスタムタクソノミーを新たに用意するほうが長期的に健全だ。

長期的にはカスタムタクソノミーへの移行を

商品を顧客向けにグルーピングしたい場合は、商品カテゴリー、商品タグ、商品属性、あるいは専用のカスタムタクソノミーを利用すべきだ。配送クラスはあくまで内部の送料計算用と割り切り、公開用の分類とは役割を分けることで、サイト構造が整理され、SEO の観点からも無駄なアーカイブページが生まれなくなる。

この変更はデータ移行を伴わない「公開状態の切り替え」であり、既存の設定には一切手が加えられない。しかし、今回のバージョンアップをきっかけに、配送クラスを公開タクソノミーとして使っていたコードがあれば、設計を見直す良い機会になるだろう。

この記事のポイント

  • WooCommerce 11.0 で配送クラスのタクソノミーが非公開になり、サイトマップやアーカイブに現れなくなる
  • 送料計算だけに使っているストアや拡張機能は特別な対応不要
  • is_taxonomy_viewable() や公開タクソノミーの一覧に依存しているコードは見直しが必要
  • どうしても公開が必要な場合はフィルターフックで復活できるが、長期的にはカスタムタクソノミーの利用を推奨
海田 洋祐
, , , ,
EC制作
« 前ページへ 次ページへ »

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

サービス一覧

ウェブシステム開発

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.