WooCommerce 10.9 Beta公開、決済フローの改善と管理画面刷新の全容
WooCommerce 10.9 のベータ版が公開された。正式リリースは2026年6月23日の予定だ。今回のアップデートでは、決済フローのデータベース負荷を下げる施策と管理画面の UI 刷新、そしてコアへのメールログ機能の統合という 3 つの柱に加え、多数の実験的機能が同梱されている。
中でも決済の「離脱」を減らす設計変更は、100 を超える細かなデータベース処理の整理とともに、ストア運営者にとって直接的なパフォーマンス向上をもたらす。また、長年要望の多かったバリエーション画像ギャラリーやカラースウォッチが機能フラグとしてコアに組み込まれ、開発者向けの新 API 群も登場する。本記事では、EC サイト運営者が知っておくべき変更点を中心に、WooCommerce 10.9 の内容をわかりやすく解説する。
決済フローの最適化とデータベース負荷低減
WooCommerce では従来、ユーザーが商品をカートに入れて決済画面を開いた時点で「下書きの注文（draft order）」というレコードを作成していた。この下書きは、購入を完了しなかった訪問者でもそのままデータベースに残り、時間が経つと大量の孤立レコードとなってストアのパフォーマンスを圧迫する原因になっていた。
10.9 ではこの処理が見直され、注文確定の直前まで下書きの作成を遅延させる設計に切り替わる。具体的には、Store API が新規セッションの GET リクエストや PATCH リクエストを受けても、すぐに下書き注文を永続化しない。結果として、購入が成立しなかったユーザーによる不要なレコードが大幅に減少し、データベースへの書き込み負荷が軽減される仕組みだ。
これに付随し、決済処理の保存回数やルックアップの最適化、商品フィルタの SQL 挙動の改善、管理画面と店舗側の商品ページにおけるクエリ数の抑制も同時に行われる。全体として、特に商品数が多いストアでは、管理画面やチェックアウト時の体感スピードが段違いに変わるだろう。
上図は旧来のやり方と 10.9 の改善点を概念的に示したものだ。実際の実装では Store API と内部の注文管理の細かい連携が組み合わさり、データベースへの影響はより精密にコントロールされる。
WooCommerce管理画面のUIが刷新
店舗の管理画面にアクセスしたときに「すっきりした」と感じるようであれば、それは錯覚ではない。10.9 では WooCommerce の管理ヘッダーが WordPress のデザインシステムに合わせて洗練され、全体的な見た目が統一される。
加えて、小さな画面サイズで表示が崩れていた管理画面の各ビューには個別の修正が行われ、管理画面全体で利用されるモーダル（ポップアップ）も一貫性のあるスタイルに揃えられた。これまで各ページでちらばっていた「タスクリストのリマインダーバー」は大部分の管理画面から削除されるが、初期設定の案内自体は WooCommerce ダッシュボードやアクティビティパネルから引き続き確認できる。
この UI 調整は、一見すると小さな変更に見えるが、日常的に管理画面を操作する運営者にとっては、不要な情報を減らし、必要な操作に集中しやすくなる利点がある。パフォーマンス面でも、画面描画に使われる余分な JS や CSS が整理されているため、軽量化にもつながっている。
トランザクションメールのログ機能がコアに実装
これまで WooCommerce で送信される注文確認メールやステータス更新のメールが「届いていない」というトラブルに遭遇した場合、原因を特定するには別途メールログ用のプラグインをインストールするか、テストメールを手動で送信するしかなかった。
10.9 からは、こうしたトランザクションメールの送信状況が WooCommerce コア内で直接記録されるようになる。ログは WooCommerce → ステータス → ログ の画面から確認でき、送信結果（成功・失敗）や、利用可能な場合は失敗理由も表示される。新たにプラグインを追加する必要はない。
この機能により、店舗運営者はメール不達の調査がはるかにスムーズになる。ログには日時やトリガーとなったアクションも含まれるため、顧客から「メールが届かない」という問い合わせがあった際、迅速に状況を確認できるようになるだろう。
実験的機能の最新情報
WooCommerce 10.9 は Automattic の「Radical Speed Month」の勢いもあり、数多くの実験的・ベータ機能が盛り込まれている。いずれもオプトインまたは機能フラグで有効化するタイプだが、将来の標準機能を見据えた重要な布石だ。
Canonical WooCommerce abilities 〜商品と注文の操作を抽象化〜
WooCommerce 10.9 では、商品や注文を操作するための最初の「カノニカル（標準的）な abilities」が導入される。abilities は、REST API のエンドポイントを 1 対 1 でラップするのではなく、スキーマで定義されたビジネス操作（商品の問い合わせ、作成・更新、注文の検索、ステータス変更、注文メモの追加など）を、権限チェックやメタデータを伴って提供する仕組みだ。
これにより、WooCommerce は WordPress Abilities API や MCP、管理ツール、CLI、自動化処理、そして将来のあらゆる「エージェント」インターフェースに対して、トランスポートに依存しない共通の契約を持つことになる。最初に商品と注文の abilities が提供され、既存の WooCommerce 専用 MCP エンドポイントは猶予期間として残される。さらに、同じパターンがサブスクリプションや決済口座、配送ルール、商品アドオン、ギフトカードといった拡張機能の領域にも展開される予定だ。
商品管理エディタの移行と製品エディタ v2 の廃止予定
実験的な商品カタログエディタは 10.9 でも成熟を続けており、クラッシュリカバリ、ドロワーや URL 状態の処理改善、よりタイプを認識したクイック編集フィールド、バリエーション編集の強化などが含まれる。一方で、ブロックベースの製品エディタ（Product Editor）ベータとその拡張 API は、WooCommerce 11.0 での削除を前に非推奨となる。
拡張機能の開発者はこの API を利用しているかを今すぐ監査し、移行パスを計画する必要がある。ただし、この廃止は WooCommerce 内の商品データやコンテンツには一切の影響を及ぼさないため、商品情報そのものが消える心配はない。
バリエーション画像ギャラリーとカラースウォッチ
同じ商品の色違いやサイズ違いに対して、画像ギャラリーを切り替える「バリエーション画像ギャラリー」がネイティブ機能として WooCommerce に追加される（デフォルトではオフ）。WooCommerce → 設定 → 詳細 → 機能 の「Variation gallery」トグルから有効化できる。
さらに、ビジュアル属性とカラースウォッチも機能フラグ制御で試験的に導入される。属性の各項目（例えば「赤」「青」）に色データや画像データを持たせ、商品フィルターやバリエーションセレクターのブロックでスウォッチを表示できるようになる。ストア API のレスポンスも、ビジュアル属性が必要な場合にだけ関連フィールドを返すよう配慮されているため、既存の連携に影響は少ない。
この他にも、買い物客向けのコレクション機能（ウィッシュリストや後で買う）、ブロックベースのメールエディタのテンプレート更新検知と部分適用、在庫復活通知、顧客レビューリクエストメール、実験的なデュアル API と GraphQL 基盤など、多岐にわたるベータ機能が同時に公開されている。いずれも開発者フィードバックを受け付けながら、今後のバージョンで徐々に本格導入される見込みだ。
この記事のポイント
- WooCommerce 10.9 では、決済前の下書き注文作成が遅延され、データベース負荷が大幅に軽減される
- 管理画面のヘッダーやモーダル、タスクリストの表示が整理され、よりスッキリした UI に
- メール送信の成否を WooCommerce の管理画面内でログ確認できるようになった
- 商品と注文の操作を抽象化する abilities や、バリエーション画像ギャラリーなど実験的機能が多数追加
スクロール駆動アニメーションとスクロール状態、ビュー遷移の違いを整理
CSSのスクロール系アニメーションは混同しやすい概念が多い。スクロール駆動アニメーション、スクロールトリガーアニメーション、コンテナクエリのスクロール状態、そしてビュー遷移。いずれも「動き」を伴う機能だが、仕組みは大きく異なる。それぞれの動作を整理し、いつどの技術を使うべきかを明確にする。
CSS-Tricksの著者Geoff Graham氏も自身の記事で「言いたいことと意味することが違っていたり、必要な場面で別のものを選んでしまったりする」と述べており、開発者であれば誰もが直面する混乱だ。この記事では、4つの技術の本質的な違いをデモとともに確認していく。
スクロール駆動アニメーションとは
スクロール駆動アニメーション（Scroll-Driven Animations）は、スクロールの進行状況とアニメーションの進行が直接連動する仕組みだ。ユーザーがスクロールバーを動かすとアニメーションが同じ比率で動き、スクロールを止めればアニメーションも止まる。逆方向にスクロールすれば、アニメーションも逆再生される。
これはつまり、スクロール位置がアニメーションのタイムラインを完全にコントロールすることを意味する。アニメーションの各フレームがスクロールの各ピクセルに紐づいているイメージだ。
このデモで示すように、スクロール駆動アニメーションはスクロールという入力装置がそのままアニメーションの進行度を決める。ユーザーが任意の位置で停止できるし、前後にも動かせる。パララックス効果やプログレスバーなど、スクロールに完全に同期した視覚効果を作るのに向いている。
基本的なCSSの書き方
.element {
animation: grow-progress linear forwards;
animation-timeline: scroll();
}animation-timeline: scroll() がキモだ。通常のアニメーションは時間ベースのタイムラインで動くが、これをscroll()にすることで、スクロール位置をタイムラインとして使えるようになる。これにより、スクロール量に応じて要素の透明度・サイズ・位置などを段階的に変化させられる。
スクロールトリガーアニメーションとは
スクロールトリガーアニメーション（Scroll-Triggered Animations）は、スクロール駆動と名前が似ているが、動作原理はまったく異なる。こちらはスクロール位置とアニメーション進行が連動しない。ある要素が特定のしきい値（トリガー活性化範囲）を越えた瞬間にアニメーションが発火し、最後まで一気に実行される。
トリガーは要素がスクロールポートに「入った」「出た」といったイベントだ。アニメーションが走り出してしまえば、その後のスクロール操作は関係ない。スクロール駆動アニメーションが「巻き戻せるビデオテープ」だとすれば、スクロールトリガーアニメーションは「一度押したら最後まで流れる再生ボタン」だ。
どんな場面で使うか
画面に要素が現れた瞬間にフェードインさせたり、スライドインさせたりするUI演出が代表的な用途だ。一度表示された後にスクロールで逆再生する必要がなければ、トリガー方式のほうがシンプルで意図が明確になる。逆にパララックスやプログレスインジケーターのように常時追従が必要な場合は、スクロール駆動を使う。
コンテナクエリのスクロール状態
コンテナクエリのスクロール状態（Container Query Scroll State）は、CSS Conditional Rules Module Level 5のワーキングドラフトに含まれる比較的新しい概念だ。一言でいうと、コンテナが特定のスクロール条件に達したときにスタイルを更新する仕組みである。
スクロール駆動とスクロールトリガーの中間のような動きをする。スクロール位置に応じて何かが変わる点では駆動に近いが、アニメーションではなく「状態の切り替え」を扱う点が異なる。
.sticky-nav {
container-type: scroll-state;
position: sticky;
top: 0;
@container scroll-state(stuck: top) {
background: orangered;
border-radius: 0;
flex-direction: row;
width: 100%;
a {
text-decoration: none;
}
}
}この例では、position: stickyのナビゲーションがビューポート上部に張り付いた瞬間にレイアウトや配色が切り替わる。JavaScriptなしでスクロールに応じた状態管理をCSSだけで行える点が強力だ。ただし、2026年6月時点ではまだワーキングドラフト段階であり、ブラウザの対応状況を確認してから使う必要がある。
ビュー遷移（View Transitions）
ビュー遷移は、ここまでの3つとは根本的に異なる。スクロールとは関係がない。CSSとJavaScriptが連携する完全なAPIで、ページ遷移や同一ページ内の状態変化をアニメーションさせる仕組みである。
同一ドキュメント遷移
同一ドキュメント遷移（Same-document transitions）は、ユーザー操作によって同一ページ上の要素がある状態から別の状態へ変化する際に使う。たとえばラジオボタンの選択状態が別の項目に移動するアニメーションや、グリッドビューからリストビューへの切り替えアニメーションなどが該当する。
クロスドキュメント遷移
クロスドキュメント遷移（Cross-document transitions）は、ページAからページBへ移動する際のアニメーションを実現する。デフォルトではクロスフェード（ページAが徐々に消え、ページBが徐々に現れる）で、実装も比較的簡単だ。複雑なエフェクトも可能で、たとえば円形のclip-pathで最初のページをワイプアウトしながら次のページを表示する、といった演出もできる。
ビュー遷移の大きな利点は、MPA（マルチページアプリケーション）でもSPA（シングルページアプリケーション）のようなスムーズなページ遷移を実現できることだ。ChromeチームのBramus氏が多数の美しいデモを公開しており、実践的な実装例も増えている。
4つの技術をどう使い分けるか
ここまでの整理を踏まえて、実務での使い分けを考える。選択の基準は「スクロールとアニメーションがどう関係するか」に尽きる。
スクロール駆動はスクロール量に完全同期させたい場合、スクロールトリガーは「画面に入ったらポン」と動かしたい場合、スクロール状態は「ある条件下で見た目をパッと切り替えたい」場合、ビュー遷移は「ページ間や状態間をなめらかにつなぎたい」場合に選ぶ。
技術選定でよくある失敗は、スクロール駆動で十分な場面でトリガーを使ってしまったり、逆にトリガーで済む場面で複雑な駆動ロジックを書いてしまうことだ。要件に対してシンプルなほうを選ぶのが鉄則である。また、ビュー遷移をスクロール系の技術と混同しないことも重要だ。ビュー遷移はスクロールとは独立したレイヤーで動作するため、併用も可能だが別物として扱う必要がある。
この記事のポイント
- スクロール駆動アニメーションはスクロール位置とアニメーション進行が双方向に連動する
- スクロールトリガーアニメーションはしきい値で発火し、最後まで一気に実行される
- コンテナクエリのスクロール状態は特定のスクロール条件でスタイルを切り替える（ドラフト段階）
- ビュー遷移はスクロールとは無関係で、ページ遷移や状態変化をアニメーションさせるAPI
- 実装前に「スクロールとどう関係するか」を明確にし、最もシンプルな技術を選ぶ
Redditが生成AIの表示順位を左右する。実データが示す影響力と企業が取るべき対策
生成AIが回答の情報源として最も参照するプラットフォームがRedditだ。SEO対策から「AI最適化」へと重心が移りつつある今、Redditでの立ち振る舞いを無視することはビジネス上のリスクになりつつある。
AI最適化プラットフォームProfoundが2026年5月に公開した分析によれば、ChatGPTがユーザーの質問に回答する際、訓練データとリアルタイム検索の双方でRedditの情報を最大の情報源として利用しているという。Redditはもはや単なる掲示板ではない。大規模言語モデル（LLM）があなたのブランドについて「知っていること」そのものを形成する場になっている。
この記事では、Redditの投稿がどのように生成AIの回答を左右するのか、その具体的なデータを示すとともに、企業が取るべき具体的な対策を解説する。
ChatGPTがRedditを最重要視する理由
実務者の間では「Redditの影響力が増している」という肌感覚が広がっていた。だが、AIリサーチ企業Profoundの分析は、それを単なるトレンドではなく確固たるデータとして裏付けた。同社が2026年1月から5月にかけてChatGPTの引用と「ファンアウト」データを解析した結果、Redditは引用回数でトップに立った。
ファンアウトとは、AIが1つの質問に対してどれだけ多角的に情報源を展開したかを示す指標だ。Redditはこのファンアウト数においても他を圧倒していた。つまり、ChatGPTは単にRedditを引用するだけでなく、1つのスレッドから複数の関連情報を芋づる式に収集し、回答の骨格を作っている。
検索クエリへの「reddit」自動付与
この解析で興味深いのは、ChatGPTがリアルタイム検索を実行する際、クエリの末尾に「reddit」というキーワードを自発的に追加する挙動が確認された点だ。人間が「商品名 レビュー Reddit」と検索するのと同じ行動を、AIが自律的に行っている。生成AIが「実体験に基づく生の声」を求めている証左といえる。
従来の検索エンジン最適化が「アルゴリズムに評価される公式情報」を重視していたのに対し、AI最適化では「訓練データとライブ検索の両方で参照される草の根の評判」が問われる。Redditがその中心にある。
安易な口コミ操作が通用しない構造的理由
ここで多くの企業が「ならばRedditに肯定的な投稿を大量にすればいい」と短絡的に考える。だが、生成AI時代のReddit戦略は、そうした「やらせレビュー」的な手法とは根本的に相性が悪い。構造的な理由が2つある。
訓練データに刻まれたネガティブ情報は消せない
1つ目は、LLMの訓練データの問題だ。仮にReddit上の自社に不都合なスレッドをModeratorに削除してもらえたとしても、その情報はすでにGPT-4やClaudeといったモデルの訓練データに組み込まれている。モデルの重みの中にネガティブな文脈が残り続けるため、単純な「投稿削除」ではAIの感情分析（センチメント）を覆せない。
Redditのコミュニティは作為を見抜く
2つ目は、サブレディット（コミュニティ単位の掲示板）の自主管理能力の高さだ。各サブレディットには人間のModeratorが存在し、不自然なプロモーション投稿や作為的なポジティブレビューは極めて高い精度で検知される。露骨なステマが削除されるだけでなく、アカウントがスパム判定を受ければドメイン単位でブランドの信用が失墜するリスクもある。
重要なのは、AIは情報の「出所」よりも「文脈」と「一貫性」を評価する傾向がある点だ。作為的なポジティブキャンペーンは、むしろAIによる評価を歪ませ、長期的にはブランド毀損につながりかねない。
RedditでAI表示を味方につける3段階のプロセス
では、企業は具体的に何をすればいいのか。短期的なハックではなく、AIとアルゴリズムの両方に評価される正攻法のプロセスを3段階に分けて解説する。
STEP 1. 観察に徹してコミュニティの文法を学ぶ
Redditビジネスアカウントを作成したら、すぐに投稿やコメントを始めてはいけない。少なくとも数週間は「ROM（Read Only Member）」として、ターゲットとするサブレディットの文化を観察する期間を設ける。
各サブレディットには明文化されたルールに加え、暗黙の行動規範がある。企業アカウントがそれを無視して宣伝めいた投稿をすれば、即座にアカウント停止（BAN）の対象となる。Redditのアカウント停止は異議申し立てが極めて困難なことで知られており、一度BANされるとブランド名で再登録すること自体が難しくなる。
STEP 2. Reddit Proで自社の立ち位置を可視化する
観察期間と並行して、Reddit Pro（無料のビジネス向け分析ツール）の導入をお勧めする。このツールを使うと、以下の情報がダッシュボードで把握できる。
- ユーザーが自社ブランドについてどのような文脈で言及しているか
- 競合ブランドと比較した際のセンチメント（肯定的・否定的感情）の差異
- 自社の製品カテゴリに関連して今活発に議論されているスレッド
闇雲に投稿する前に、データに基づいて「どのサブレディットで、どんなトピックなら、企業として価値を提供できるか」を特定することが先決だ。
STEP 3. ブランド認知より「権威構築」を優先する
初期の投稿やコメントでは、自社製品の宣伝を一切排除し、純粋に専門知識を提供することに集中する。たとえば、ECプラットフォームを提供する企業なら「物流のボトルネックを解消するパッキングの工夫」、マーケティングツール企業なら「GA4で離脱率を下げるレポートの読み方」といった具合だ。
この段階でブランド名を出すことは、コミュニティから「売り込み」と見なされるリスクが高い。まずは個人としての信頼を積み上げ、その後に「そういえば、この分野のプロダクトを開発している」と自然に言及できる流れを作る。
ブランド専用サブレディットという選択肢
自社ブランドへの言及が一定数を超えてきた段階で、ブランド専用のサブレディットを開設することも有効な一手だ。すでに多くのテック企業がこの手法を取り入れている。
専用サブレディットの利点は、分散していた自社関連の会話を一箇所に集約できる点にある。ユーザー同士のQAやトラブルシューティングが活発になれば、それはそのままLLMが参照する「構造化されたナレッジベース」として機能する。サポートコストの削減とAI表示の最適化を同時に実現できるわけだ。
ただし、ここでも運営姿勢が問われる。企業が一方的に情報を発信する場ではなく、ユーザーが自由に意見を交わせる「公共広場」としての設計が不可欠だ。Moderatorが批判的な投稿を削除するような運営は、Reddit全体からの強い反発を招く。
この記事のポイント
- RedditはChatGPTが回答を生成する際の最重要情報源であり、訓練データとリアルタイム検索の双方で参照される
- ネガティブスレッドの削除や偽のポジティブ投稿は、LLMの訓練データに残る情報を覆せず、コミュニティからも排除されるリスクが高い
- アカウント作成後はまず観察に徹し、Reddit Proでデータを分析した上で、ブランド宣伝ではなく専門知識の提供による権威構築を優先する
- 長期的な視点でコミュニティに貢献し、AIに「信頼できる情報源」として学習させることが、生成AI時代のブランド防衛につながる
法務事務所を狙うデータ恐喝の新手口、遠隔操作から「直接訪問」へ進化
機密文書を扱う法務事務所や士業が、新種のデータ恐喝集団「UNC3753」の標的になっている。Google傘下の脅威分析チーム「Mandiant」が2026年6月5日に公開した報告によると、2026年1月から5月にかけて、全米の法律・金融サービス企業数十社が被害に遭った。攻撃者は電話で偽のITサポートを装い、社内の誰もが持つ画面共有ソフトを悪用してネットワークに侵入する。この手口はテクニカルなハッキングというより、巧みな会話術と信用の悪用で成立する。1営業日以内に情報窃取から恐喝までを完了するスピード感も特徴だ。
さらに深刻なのが、遠隔操作が失敗した場合には「直接オフィスを訪問する」物理的な侵入へのエスカレーションが確認されている点だ。FBIも注意喚起を出したこの事案は、大企業だけの問題ではない。顧客情報や契約書類を抱える士業や制作会社も、十分な対策が求められる。
法務事務所を狙う「偽のITサポート」電話が増加している
この攻撃キャンペーンの主体は、Mandiantが「UNC3753」と呼ぶ経済動機の脅威クラスターだ。2022年3月から活動が確認されており、別名として「Luna Moth（ルナ・モス）」「Silent Ransom Group（サイレントランサムグループ）」とも呼ばれる。元々は請求書を装ったPDFファイルをメールに添付し、偽のコールセンターに電話させる手口を使っていた。しかし2025年3月頃から戦術を変更し、企業内部のITヘルプデスクを名乗る「Vishing（音声フィッシング）」へと完全にシフトした。
この変化には明確な理由がある。メールフィルタやアンチウイルスが高性能化し、マルウェア付き添付ファイルは検知されやすくなった。しかし電話での指示を疑うセキュリティソフトは存在しない。音声フィッシングは防御側の「技術で壁を作る」前提を完全にすり抜ける。
メールは「呼び水」、本番は電話で始まる
攻撃は次の2段階で進む。まず一般消費者向けメールアドレスから「hello, here is the invcoie we talked about yesterday（昨日話した送り状です）」といった短いメールを送りつける。リンクも添付ファイルもなく、セキュリティ検査を素通りする。だがタイプミスを含む不自然な文面は受信者に「怪しい」と思わせる効果があり、まさにそれが狙いだ。標的が警戒したタイミングで、社内IT担当を名乗る電話がかかってくる。「不審なメールが届いていませんか」と切り出すことで信頼を獲得し、画面共有に誘導する。
偽のITサポートが社内ネットワークに侵入する流れ
UNC3753の侵入フローは、技術的には「正規ツールの悪用」で構成される。マルウェアの注入も、脆弱性攻撃も行われない。このため、侵入検知システムやアンチウイルスに記録が残らず、事後の調査を困難にしている。
Mandiantの調査では、この一連の流れがわずか1時間足らずで完了したケースも確認されている。攻撃者はiManageのような文書管理システムを熟知しており、W-2（給与税務申告書）や監査ファイルといった「人質として価値の高い文書」を狙い撃ちする。
個人所有のPCを経由してVDI環境に侵入する抜け穴
もう一つの特徴的な手口が、VDI（仮想デスクトップ環境 / Virtual Desktop Infrastructure）の悪用だ。在宅勤務の社員が私物のPC（BYOD / Bring Your Own Device）で業務システムにアクセスする構成を、攻撃者が逆手に取る。画面共有を仕掛けた社員の個人PCを経由し、VDIクライアント（Windows 365やCitrix）を介して企業の内部ネットワークに自由にアクセスする。会社支給の端末にセキュリティソフトが導入されていても、私物PCの画面共有からは検知できない。
データの送信方法も巧妙化している
窃取したファイルの送信には以下の3つのルートが使い分けられる。1つ目はWinSCPやRcloneといったコマンドラインベースの同期ツールを使った大量転送だ。Mandiantの報告によると、ある被害者ではローカルのOneDriveフォルダから1.7ギガバイト、VDIセッションから追加で14.4ギガバイトが一気に流出した。2つ目はPrivnoteのような「開封後に消えるメモサービス」を使った遠隔指示の中継だ。攻撃者はインストール先URLやコマンドをPrivnote経由で渡し、社内のブラウザ履歴やチャットログに痕跡を残さない。3つ目はごく単純に、被害者のブラウザで直接Googleドライブにログインさせる手口だ。標的企業の名前を付けたフォルダにデータをドラッグ＆ドロップさせ、事後に消去を指示する。
「直接訪問」に進化する物理的な脅威
Mandiantの報告で特に目を引くのが、遠隔操作が通用しなかった場合の物理侵入だ。これは単なる仮説ではなく、FBIが2026年5月に発出した「Cyber FLASH Alert」で具体的に警告されている。IT技術者を装った第三者が実際のオフィスを訪れ、「デバイスのイメージ取得が必要」「セキュリティ上の緊急対応」と言ってPCにUSBメモリを差し込ませ、直接データを吸い出す手口が確認された。
技術的な防御が高度化するほど、それを迂回する「人間」を狙う攻撃は増える。物理セキュリティはサイバーセキュリティの一部であり、切り離して考えてはならない。
不正送金より深刻な「データ人質」の手口
UNC3753の最終目的はファイルを暗号化して身代金を要求する「ランサムウェア」ではない。窃取した機密情報を人質に取り、「3日以内に交渉を始めなければ顧客や取引先に直接リークを通報する」と脅して金銭を要求する「データ恐喝」だ。法務事務所や会計事務所にとって、顧客データの流出はビジネスそのものを揺るがす致命的な事態になる。恐喝メールでは「顧客の信頼は失墜し、多額の規制当局による罰金が発生し、データ管理責任を問われて顧客から訴訟を起こされる」と明記される。心理的圧力を最大限に高める文面だ。
要求に応じなければ、実際に「LEAKEDDATA」というデータリークサイトで情報を公開する。支払ったとしてもデータが確実に削除される保証はなく、沈黙の代償が更なる恐喝を呼ぶリスクもある。この種の「身代金を支払わない」方針を事前に決め、防御にリソースを振ることが重要だ。
今日から始める中小企業の防御策
UNC3753の手口は大手向けに見えるが、個人情報を扱う税理士事務所やWeb制作会社でも全く同じ被害構造が成立する。Google Threat Intelligence Groupの推奨事項を元に、中小企業向けの実践的な対策を示す。
社内教育を最優先に設計する
不審な電話がかかってきた場合の対応手順を社内で標準化しておくべきだ。「社内ヘルプデスクを名乗っても、まず上司や情報システム担当に転送する」というシンプルなルールを周知するだけで、初期侵入の大半を防げる。特に「データ移行プロジェクト」や「セキュリティ上の緊急対応」と言われたら、一度電話を切り、会社に登録されている正規の内線番号にかけ直す習慣を徹底させたい。
VDIとBYODの認証を強化する
個人のPCやタブレットから社内の仮想デスクトップ（VDI）に接続する構成は、多要素認証（MFA）の強化が不可欠だ。さらに「会社支給端末以外からのVDI接続を禁止する」という条件付きアクセスポリシーを設定できれば、私物端末を経由した遠隔操作のリスクを大幅に下げられる。
正規のリモート管理ツールも制限する
AnyDeskやZoho Assistが攻撃に使われる現実を踏まえ、会社で業務利用するリモート管理ツールを限定し、それ以外のインストールをAppLockerやWindows Defender Application Controlで制限する構成が有効だ。ZoomやTeamsの画面共有機能についても、社内ポリシーで利用ガイドラインを定めておくべきだ。
USBメモリの物理的な対策
会社の全PCでUSBストレージの書き込みを無効化する設定は、グループポリシー（GPO）を使えば比較的簡単に実装できる。外部メディアを業務で使う場合も、必ず情報システム担当者が解錠する運用にすることで、なりすましの技術者がUSBメモリでデータを抜く物理攻撃を封じられる。
ネットワーク監視とログ設定
ファイアウォールで外部ファイル共有サービスへの接続を監視し、一定時間内に大量のSSHトラフィック（WinSCPやRcloneの転送に使われる）が発生した際にアラートを出すようにしておくと、データの一括送信を早い段階で検知できる。社内の文書管理システムでも、キーワード検索の急増や大量ダウンロードを監視対象に加えておくべきだ。
この記事のポイント
- 法務事務所を狙うUNC3753は、音声フィッシングで画面共有に誘導し正規ツールを悪用する
- メールは呼び水に過ぎず、マルウェアを使わないため従来の防御策では検知が難しい
- 遠隔操作が失敗すると、IT業者を装った直接訪問でUSBメモリを使った窃取に切り替える
- VDI環境と個人端末の認証強化、USB書き込み禁止設定が即効性の高い対策となる
- 攻撃の最終目的はデータ恐喝であり、要求に応じる前に防御と教育の強化を優先すべき
AIだけでは企業変革できない、カギは実行基盤（Azureブログ発表）
AIが企業のあらゆるワークフローに浸透し始めている。だが、本当の変革をもたらすのは最先端のAIモデルそのものではなく、それを動かすシステムの設計だという指摘が、マイクロソフトの公式ブログで発表された。同社はエージェントを中心とした統合プラットフォームを打ち出し、開発から運用、ガバナンスまでを一貫して支える環境を構築している。
発表の背景には、個別のAIチャットボットや単発のツール導入に終始する企業では、大規模な業務変革が進まないという現実がある。Azure Blogの記事では、複数のAIエージェントが部門を横断して長期間にわたり作業を実行し、しかも統制の取れた形で運用できる仕組みこそが次世代の競争力を決めると述べられている。
なぜAI単体では不十分なのか
エージェントがもたらす真の変革
Azure Blogによれば、現在の企業AI活用で話題になるのはチャットボットのような対話型インターフェースだ。だが、そうしたエクスペリエンスは便利ではあるものの、組織全体のオペレーションを根本から変えるものではない。真に価値があるのは、ソフトウェア開発、サポート、財務、人事、運用といった複数の業務領域で、複数のAIエージェントが連携し、長期にわたって作業を自律的に遂行することである。
エージェントが本格稼働するには、単に強力なAIモデルやスケーラブルな計算資源が手に入れば良いわけではない。エージェントを「誰が」「どのデータを使って」「どう安全に」動かすかという企業コンテキスト、ポリシー、人的監視の枠組みが不可欠だ。Azure Blogの記事では、これらを欠いた状態では、AIの導入は断片的で脆弱、大規模に信頼するのが難しいと指摘している。
個別ツールの寄せ集めではリスクが高まる
多くの企業は、コード生成ツール、データ連携基盤、実行環境、監視システムをそれぞれ別々に導入し、後付けで連携させる方法を取りがちだ。だがAzure Blogの記事は、こうしたばらばらのツールを寄せ集めただけの環境では、開発速度が落ち、不必要なリスクを招くと警告している。たとえば、エージェントに意図しないアクセス権が渡ったり、部門間でガバナンスが効かなくなったりする問題が起こり得る。
このデモで示したように、断片化したツール群ではエージェントの挙動を一貫して管理できない。マイクロソフトの新たなアプローチは、これらの要素を統合した単一のプラットフォームでエージェントを動かす点にある。
Microsoftの統合エージェントプラットフォームとは
Azure Blogの発表では、同社が「包括的エージェントプラットフォーム」を構築していると説明されている。このプラットフォームは、多様なAIモデルをサポートしながら、開発者を中心に据えた柔軟な設計になっている。そして何より、実際の本番ワークロードを動かし、組織の複雑さとビジネス責任を扱える水準を目指している。
3つの設計原則
このプラットフォームは、以下の3つの基本原則に基づいて設計されている。
- 単一の統合システムで多様なモデルをサポートする：Azure、GitHub、Microsoft IQ、Fabric、Foundry、Windows、Microsoft 365、Microsoft Securityを一つのシステムとして連携させる。これにより、構築から改善までをバラバラのツールなしで行える。さらに、マイクロソフト自社モデルだけでなくパートナーモデルやオープンモデルも自由に選べる。
- セキュリティとガバナンスが設計に組み込まれている：Entra、Purview、Defender、Agent 365といったセキュリティスタックを開発段階から本番まで一貫して適用する。後付けではなく、システムにネイティブに統合されたガバナンスを実現する。
- 継続的に改善する：エージェントの動作結果や人間からのフィードバックをシステムに還元し、時間とともに安全に改善させる。モデルやワークフローが企業固有の業務プロセスに適合し、使い続けるほど価値が複利的に高まる仕組みを目指す。
これらの原則は今や「あると良い」ものではなく、競争力を左右する必須条件になるとAzure Blogの記事は強調している。四半期単位で差がつくという見立てだ。
エージェントライフサイクルの全体像
では、このプラットフォーム上でエージェントはどのように構築され、動いていくのか。Azure Blogの発表に沿って、主要な段階を順を追って見ていく。
構築〜GitHubで開発する
エージェントの開発は、すでに多くの開発者が日常的に使うGitHubを起点とする。コードベース、ワークアイテム、スキル、ツールなど重要なアセットを同じ場所に集約し、本番ソフトウェアと同じライフサイクル（ソース管理、テスト、デプロイ、監視、改善）をエージェントにも適用する。
GitHub Copilotを活用してコード作成を加速し、評価（eval）や可観測性（observability）のアセットもバージョン管理下に置く。これにより、最初から適切なガードレールを備えたエージェント開発が可能になる。発表では、このために新しいGitHubアプリが提供されることも述べられている。
企業データの文脈化〜Microsoft IQ
コードだけでは、エージェントは汎用的なAIにとどまる。真に役立つには、顧客情報、製品データ、契約書、業務プロセスといった企業特有の文脈を理解しなければならない。Azure Blogの記事では、いくら高性能なモデルを使っても、企業文脈なしでは推測に過ぎないと指摘している。
Microsoft IQは、Microsoft 365や基幹業務システム、ナレッジベース、自社ウェブサイトなど、社内外のデータソースにエージェントを接続する。さらに、Web IQによってウェブ上の情報も適切に取り込める。単にデータにアクセスさせるのではなく、情報を整理し、エージェントが扱いやすい形で安全に提供する点が重要だ。
さらに、Frontier Tuningと呼ばれる仕組みによって、実際の業務データとワークフローからモデルを改善できる。今回発表された音声、画像、コーディング、推論向けの7つの新しいMAIモデルを含め、モデルが企業のプロセスを学習し、その企業に特化した知能として機能するようになる。学習結果は企業の環境内に保持されるため、知的財産は外部に出ない。
実行環境〜Foundry
構築し文脈化したエージェントは、本番環境で実行されなければならない。Foundryは、エージェント特有の要求（推論、ツール呼び出し、他のエージェントとの連携、時間経過による適応）に応えるランタイムだ。
Foundryでは、タスクやコストに応じて最適なモデルを選択できるルーター機能を備え、Fireworks AIによる高速な推論も統合している。Microsoft Agent Frameworkはもちろん、LangGraph、GitHub Copilot SDK、Claude Agent SDKなど多様なエージェントフレームワークもサポートする。ツールやアクションはMCP、コネクター、API、ワークフロー経由で安全に実行され、評価とトレースによってエージェントの振る舞いを計測可能にしている。
ガバナンス〜Agent 365
ひとたび企業全体で何百、何千ものエージェントが稼働し始めると、全体を把握し制御するガバナンスが不可欠になる。Agent 365は、組織内の全エージェントを単一のカタログに表示し、誰がデプロイしたか、どのデータやツールにアクセスできるか、どのように動作しているか、コストはいくらかをIT管理者が一元的に確認できる仕組みだ。
Entra、Purview、Defenderと連携し、必要に応じてポリシーを強制したりアクションを取ったりできる。これにより、設計の良いエージェントもそうでないエージェントも、組織として統制下に置かれる。Azure Blogでは、ガバナンスの基盤が最初から組み込まれている点が後付けとの大きな違いだと強調されている。
継続的改善ループ
エージェントシステムは静的なままではない。すべての動作結果やフィードバックがシグナルとして蓄積され、評価、改善、安全なロールアウトが繰り返される。この学習ループは本番環境で連続的に動作し、プロンプトの調整からモデルルーティング、ファインチューニング、強化学習まで、段階的に高度化していく。
Azure Blogの記事は、このプロセスを「hill-climbingモデル」と表現し、システムを稼働させながら価値を複利で高める考え方を示している。重要なのは、改善ループが完全な自動化ではなく、人間の監査と修正のもとで制御されることだ。
業務現場への提供〜TeamsとAzure
エージェントの価値は、実際に業務を行う人々の手元に届いて初めて発揮される。このプラットフォームでは、TeamsやMicrosoft 365、自社アプリケーションの中にエージェントが自然に表面化する。アイデンティティ、セキュリティ、コンプライアンスは最初から組み込まれており、日常業務で使うツールと同じ信頼モデルを継承する。
また、Windows環境での最適化されたエージェント実行、クラウドとローカルの両方でのモデル稼働、サンドボックス技術による常駐型エージェントの安全な動作もサポートされる。大規模なAIワークロードやグローバルな展開が必要な場合は、Azureが基盤として全体をスケールさせる。
システムが価値を複利で増幅させる仕組み
Azure Blogの発表は、結局のところ、AI活用で先行する企業は「中央のAIプラットフォーム」を中心に業務を再編し、データ、モデル、エージェント、人間の判断を一つの継続的に改善する安全なシステムへと収斂させていくと述べている。システムが稼働し続けるほどその価値は複利的に増大し、ボトルネックは作業量から人間の創造性と調整へと移行する。
このビジョンでは、個々の担当者が共有された文脈のもとで自律的に仕事を進められるようになり、引き継ぎや摩擦は減り、ビジネス全体のスピードが上がる。マイクロソフトのエージェントプラットフォームは、まさにその「統合されたオペレーティングシステム」として機能することを目指している。
この記事のポイント
- Azure Blogの最新発表では、企業AIの成否はモデル単体ではなく、エージェントを動かすシステム設計にかかっていると指摘されている。
- 個別ツールの寄せ集めはリスクを高めるため、GitHub、Microsoft IQ、Foundry、Agent 365などによる統合アプローチが提唱されている。
- エージェントライフサイクル全体（構築、文脈化、実行、ガバナンス、継続改善）を単一システムで回すことで、信頼性とビジネス価値が複利的に高まる。
- セキュリティとガバナンスは設計段階から組み込まれ、人的監視のもとでAIが安全に改善し続ける仕組みが特徴。
Codexが全職種向けに進化、役割別プラグインとサイト作成機能を発表
OpenAIは2026年6月2日、AIアシスタント「Codex」の大幅な機能拡張を発表した。毎週500万人以上が利用するCodexに、特定の職種向けに最適化された6つのプラグイン、成果物を直感的に修正できるアノテーション機能、そしてチーム内で共有可能なインタラクティブサイトを生成する「Sites」機能が追加された。
このアップデートの核心は、Codexが単なる開発支援ツールから、営業やマーケティング、投資調査といった幅広い知識労働の現場に浸透し始めたことにある。非開発者のユーザーは全体の約20%を占め、その成長率は開発者の3倍以上だ。今回の新機能は、まさにそうした多様な職種のワークフローをCodex上で完結させるための布石といえる。
実際にOpenAI社内では、非技術部門がCodexで社内アプリの構築や役員向け資料の準備、ダッシュボード作成などを行っている。Zapierではインシデント対応計画の立案に、NVIDIAでは機械学習の実験ワークフロー高速化にCodexを活用しているという。
Codexの利用シフト、開発者以外が急増する背景
Codexのユーザー層は、この1年で明確に変化した。従来、開発者のコーディング支援に特化していたが、直近ではアナリスト、マーケター、デザイナー、投資家など非開発者の利用が急伸している。この変化を支えるのが、自然言語による指示だけで複雑なデータ分析や資料作成が可能になったという技術的な進歩だ。
たとえば、売上データの異常値を「なぜ先月のコンバージョン率が低下したのか？」と質問するだけで、Codexが関連する複数のデータソースを横断し、原因の仮説と視覚的なレポートを生成できる。専門的なSQLやPythonの知識がなくても、ビジネス判断に必要な情報を引き出せるようになった点が、非開発者層の拡大を後押ししている。
6つの役割別プラグイン、各職種のツールと直接連携
今回発表された中核は、特定の職種向けに設計された以下の6つのプラグインだ。それぞれが業務で使われる主要なSaaSツールと連携し、Codexの能力を専門業務にチューニングする。合計で62の人気アプリと110のスキルが含まれている。
データ分析プラグイン
アナリストやビジネスチーム向け。Snowflake、Databricks Genie、Hex、Tableauといったプラットフォームと接続し、製品データやビジネス指標の探索、主要KPIの変動理由の説明、レポートやダッシュボードの自動生成を行う。コードを書かずに自然言語で「先月のMAU低下要因を分析して」と指示するだけで、複数のデータソースを横断したインサイトを得られる。
クリエイティブ制作プラグイン
マーケティングチームやクリエイティブチーム向け。Figma、Canva、Shutterstock、Picsart、Falなどのツールと連携し、企画概要からキャンペーンボードの作成、ディスプレイ広告のバリエーション展開、Eコマース向け画像セットや商品ライフスタイルショットの生成までを一貫して支援する。
セールスプラグイン
営業チーム向け。Salesforce、HubSpot、Slack、Outreach、Clay、Rox、Activelyといったツールと統合され、優先アカウントの特定、商談準備、フォローアップの自動化、顧客レコードの更新、クローズプランの策定、リスクのある取引のレビューをCodex上で完結させる。営業担当者が顧客情報を複数システムで探し回る手間を大幅に減らせる設計だ。
プロダクトデザインプラグイン
プロダクトチーム向け。初期アイデアからレビュー可能なプロトタイプへと素早く変換する。製品方向性の探索、ユーザーフローの監査、ライブURLからのプロトタイプ生成、静的スクリーンショットのインタラクティブ化などがFigmaやCanvaとの連携で可能になる。
株式投資（パブリックエクイティ）プラグイン
投資家向け。Moody’s、Daloopa、Datasite、FactSet、LSEG、S&P、PitchBook、Hebbiaといった金融情報源と接続し、決算レビュー、企業比較、シグナル追跡、投資テーマの妥当性評価を支援する。市場データを横断的に分析し、投資判断の根拠をCodex上で組み立てられる。
投資銀行プラグイン
投資銀行業務向け。調査やデューデリジェンスの結果をもとに、クライアント提出用のピッチ資料作成、類似企業や取引の分析、推奨案の策定を行う。信頼性の高いデータソースと連携しており、資料作成のリードタイムを短縮する。
これらのプラグインはすぐに利用可能で、チームのワークフローに合わせたカスタマイズもできる。さらに、企業固有のシステム向けにカスタムプラグインを構築して共有することも可能だ。今後はコーポレートファイナンス、プライベートエクイティ、マーケティング戦略、戦略コンサルティング、法務向けのプラグインも順次追加される予定で、パートナー企業が直接CodexやChatGPT上でプラグインを開発・展開できるオープンなエコシステムの構築を目指している。
アノテーション機能、完成後の修正を直感的に
Codex上で生成したドキュメント、スプレッドシート、スライド、Webサイトなどに対して、特定の箇所を指し示しながら修正を指示できる「アノテーション（注釈）」機能も追加された。開発者向けには以前からコードやMarkdownファイルで提供されていたが、一般ユーザーが扱うコンテンツにも拡張された形だ。
例えば、生成されたサイトのナビゲーションバーを選択して「フォントを変更して」と指示したり、投資レポートの特定の主張をマークして「この情報の出典はどこか？」と問い合わせたりできる。Codexは選択された部分にのみ修正を集中させるため、気に入っている他の部分を壊すことなく、反復的なブラッシュアップが可能になる。初稿ができたあとのフィードバックや判断が必要な工程で、この機能の真価が発揮されるだろう。
Sites機能、チームで共有できる対話型サイトを生成
ビジネスおよびエンタープライズ向けにプレビュー提供が始まった「Sites」は、Codexに指示するだけでインタラクティブなWebサイトやアプリを生成し、ワークスペース内のメンバーにURLで共有できる機能だ。ダッシュボード、プランナー、レビューワークスペース、プロジェクトボード、ギャラリー、ライトなツールなど、ユーザーのアイデアや分析結果を形にする新しいキャンバスとなる。
たとえば、Codexに「次回の顧客レビュー用サイトを作成して」と依頼すると、製品アップデート情報や未解決の課題、使用傾向、次のアクションプランを含む対話型のWebページが即座に生成される。財務モデルからシナリオプランナーを構築すれば、リーダー層はドキュメントのタブを読み比べる代わりに、仮定を切り替えながら結果を比較できる。立ち上げ資料を常に最新の状態に保つハブとして運用することも可能で、チームメンバーは常に最新のメッセージ、マイルストーン、担当者、意思決定を確認できる。
Sitesは静的ではない。大規模プロジェクトの進捗管理や、カスタマーサービス担当者向けのガイド、チームのクリエイティブブリーフ集約リポジトリとしても機能する。現在、Vercel、Wix、Base44、Replit、Lovable、Figma、Webflow、Emergentなどのパートナーとともに、Sitesのパートナーエコシステム構築が進められている。
Codexが変える業務の意思決定プロセス
これらの新機能を俯瞰すると、Codexの方向性は明確だ。単一のツールやファイルの制約に人間が合わせるのではなく、業務の流れやチームの文脈にCodexが適応する世界を目指している。役割別プラグインで専門ツールの壁を取り払い、アノテーションで反復作業のストレスを減らし、Sitesで静的なドキュメントを対話型の意思決定の場に変える。
日本企業においても、たとえば営業部門がSalesforceとCodexを連携させ、商談準備からフォローアップまでを自然言語で完結させるといった活用が現実味を帯びてきた。データ分析の民主化が進むことで、専門のデータサイエンティストを介さずに現場担当者が直接インサイトを得られるようになれば、意思決定のスピードは大幅に向上するだろう。
この記事のポイント
- OpenAIがCodexに6つの役割別プラグインを導入、非開発者層の業務を直接支援する体制が整った
- アノテーション機能により、成果物の特定部分をピンポイントで修正でき、反復作業が効率化する
- Sites機能で、チーム共有可能な対話型のWebサイトやダッシュボードをその場で生成できる
- 非開発者のCodex利用は全体の約20%に達し、成長率は開発者の3倍以上と急拡大している
- プラグインはカスタマイズ可能で、企業固有のシステム向けに拡張する道も開かれている
WCEU 2026クラクフ開催。CERN基調講演とWordPress 7.0全容
# フロントマター
— title: “WCEU 2026クラクフ開催。CERN基調講演とWordPress 7.0全容” meta_description: “WordCamp Europe 2026がポーランド・クラクフで開催。CERNのWordPress移行基調講演、WordPress 7.0のAI機能、ビジネスセッションなど主要トピックを解説。WCUS 2026は8月フェニックスで。” tags: [“WordPress”, “WordCamp”, “WordCamp Europe”, “WCEU 2026”, “WordPress 7.0”, “CERN”, “AI”, “オープンソース”] slug: “wceu-2026-krakow-recap” scrape_method: “trafilatura” image_prompt: “Upper portion: the CERN logo (a stylized double-ring emblem with intertwining loops) prominently displayed in photorealistic 3D with subtle metallic reflections. Lower portion: the ICE Kraków Congress Centre with a vibrant WordCamp Europe banner outside, attendees networking in the plaza. Composition: split-screen style with key visual elements positioned in the upper and lower portions of the frame, with a natural atmospheric transition in between, no horizontal bands or strips across the frame. 16:9 aspect ratio. If UI screens, dashboards, code editors, or admin panels appear, all text within them must be in English. If laptops or monitors appear, use ultra-thin bezel modern design. No visible year numbers on calendars, screens, or documents.” featured_text: “WCEU 2026 全容\nCERNが語るWP採用理由”
— —
WordCamp Europe 2026が6月4日から6日まで、ポーランド・クラクフのICE Kraków Congress Centreで開催された。81カ国から2,458人のチケット保有者が集まり、うち約4人に1人が初参加という大規模なイベントとなった。
基調講演にはCERN（欧州原子核研究機構）のウェブチームが登壇し、世界初のウェブサイトを公開した研究機関がWordPressを採用した理由と具体的な移行手法を明かした。WordPress 7.0のAI機能も多数のセッションで取り上げられ、コアに組み込まれたAIクライアントやAbilities APIの実用性が議論されている。
ここでは3日間の主要セッションと、今後のWordPressを取り巻く技術潮流を整理する。
基調講演は大手企業や著名開発者が中心。新機能の発表が主目的。
CERNによる研究機関視点の採用根拠、AIとオープンソースの本質的議論、教育プログラムの具体的成果が前面に。
—
Contributor Dayが作り出す協働の場
本編開始前日の6月3日、会場にはContributor Day（コントリビューターデー）が設けられた。これはWordPress本体の改善に直接取り組む実務作業日であり、講演を聞くのではなく実際に手を動かす場だ。午前中に登録と歓迎セッションが行われ、参加者はPolyglots（翻訳）、Documentation（文書）、Support（フォーラム回答）、Core（本体開発）、Performance（パフォーマンス）、Testing（テスト）、Themes（テーマ）、Plugins（プラグイン審査）などの各テーブルに分散した。
経験者が新規参加者を一人ずつ引き受け、初めてのパッチや翻訳文字列、サポートチケット対応を手ほどきする仕組みが整えられていた点が特徴的だ。会場に行けなかった参加者も、Make WordPress Slackの #contributor-day チャンネルを通じてリモート参加できた。
ここで注目すべきは、プラグイン審査チームの存在感だ。同チームはディレクトリに登録される全てのプラグインを審査する役割を担っており、初期参加者にとっては「誰がどのような基準で審査しているのか」を直接知る貴重な機会となった。
—
CERN基調講演。世界初のウェブサイトがWordPressを選んだ理由
開幕基調講演に立ったのはCERNのウェブマネージャー、Joachim Valdemar Yde氏とWordPressインフラ責任者のFrancisco Borges Aurindo Barros氏だ。CERNは30年以上前にティム・バーナーズ＝リーがWorld Wide Webを発明した場所であり、その研究機関がなぜWordPressを次期ウェブ基盤に選定したのかが語られた。
CERNの設計思想は明確だった。研究者やスタッフはコンテンツ制作に集中し、ウェブチームが基盤全体を管理する。セルフサービスポータルから数クリックでサイトを申請でき、共通テーマとセキュリティ審査済みのプラグイン一式が自動適用される。初年度だけですでに数百のサイトが立ち上がったという。
Yde氏は会場にこう告げた。「本日より、CERNの旗艦サイト home.cern はWordPressで稼働している。自動移行を経て、すでに本番公開済みだ」
この発表が持つ象徴的な意味は大きい。Webを発明した機関が、いまWebの40%以上を動かすオープンソースソフトウェアを自ら選び、GPLライセンスの下で運用している。この対称性は、オープンソースコミュニティにとって強力な支持材料となるだろう。
—
WordPress 7.0とAI。コアに組み込まれたネイティブAIの実像
WCEU 2026を通じて最も多くのセッションを横断していたテーマが、WordPress 7.0とAIの融合だった。単なる機能アップデートではなく、WordPressが「どう変わるか」の方向性を示す議論が展開された。
AIクライアントとAbilities APIの設計思想
パネルセッション「Inside WordPress 7.0」には、Juan Manuel Garrido氏、Adam Silverstein氏、Benjamin Zekavica氏、Sarah Norris氏、Milana Cap氏らリリース貢献者が登壇した。ここで明らかにされたのは、WordPress 7.0に実装された3つの中核的変革だ。
- ネイティブAIクライアントのコア実装
- Abilities API。プラグインが自身の機能を宣言し、他のツールから発見可能にする仕組み
- Connectors画面。OpenAI、Anthropic、Google GeminiなどのAIプロバイダーを管理画面から接続できる管理インターフェース
パネルでは単なる機能一覧にとどまらず、大規模なリリースがオープンに進行する過程そのものが解説された。貢献ワークフロー、複数チーム間の調整、公開状態でソフトウェアを出荷する人間的側面までが議題に上った点は、これまでのリリース説明とは一線を画す。
実務者たちが示した具体的ユースケース
Anukasha Singh氏はAbilities APIに焦点を当て、プラグイン権限のチェックを従来のcapability（権限）方式よりクリーンかつ安全にできることを示した。Vito Peleg氏のワークショップでは、単発のAIプロンプトから一歩進み、ライブサイトを監査して構造化チケットを自動生成するツール活用ワークフローが実演された。
WP-CLIメンテナーのAlain Schlesser氏は、AIアシスタントやAI検索がオープンウェブに実トラフィックをもたらしている現状を数字で示した。2025年半ばまでに10億件以上の参照訪問が記録されており、WordPressはその流入を受け止める準備ができていると指摘する。氏のセッションは、サイトがAIに「発見され、読まれ、引用される」ための実践的チェックリストとして構成された。
Tammie Lister氏の「Human in the loop means something」は、AI導入が議論される中で「人間がループにいる」というフレーズを単なるチェックボックスではなく本物の責任として捉え直した。人間とAIは得意分野が異なり、優れたプロダクトはそれぞれの強みを活かす設計になるべきだ、という主張だ。
—
「つくる」現場の開発セッション
開発トラックでは、技術の深掘りが光った。Dennis Snell氏はHTML APIとブロックパーサーの設計に携わった立場から、HTML APIの内部構造と活用方法をワークショップ形式で解説した。Peter Wilson氏はパフォーマンスチームの長期コミッターとして、WP_Queryクラスのキャッシュ改善による高速化と、大規模サイトでの活用法を詳述している。
スケーリングに関するハンズオンセッションでは、12ドルの仮想サーバーでWordPressがどこまで耐えられるかをGrafanaでプロファイリングしながらチューニングする実演が行われ、GitHubリポジトリも公開された。Fellyph Cintra氏はWordPress Playgroundの最新状況を取り上げ、ブラウザベースのツール群とアーキテクチャ変更による高速化の成果を報告した。
Jessica Lyschik氏のセッションは、アクセシビリティ対応の要件が多くのテーマ開発者が想定するよりはるかに達成しやすいことを、ブロックテーマとクラシックテーマの実審査事例をもとに論じた。プラグイン審査チームのDavid Perez氏とFran Torres氏は、25,000件以上のプラグイン審査経験から、よくある回避可能な問題と審査待ち期間を短縮する具体的ノウハウを公開した。
—
ビジネスとオープンウェブをめぐる議論
ビジネストラックでは、感傷を排した実践的な内容が続いた。Debbie Levitt氏は3つのレイヤーで同時にプロダクトマーケットフィットを追求するモデルを提示し、「チームが一つの良い指標を祝った数ヶ月後、なぜユーザーが去ったのかわからなくなる」という問題に切り込んだ。Vassilena Valchanova氏は、仕事ができることと、それを周囲に知られていることは別物だという、スキルと認知のギャップをテーマに据えた。
クラクフを拠点とするフルスタック開発者Irfani Silviana氏は、Business Model Canvasを「開発者が機能出荷から事業価値の創出へ視点を移すための変換レイヤー」と位置づけ、地元での登壇にふさわしい内容を披露した。
—
クロージングセッション。教育、AI、オープンソースの交差点
最終日のクロージングでは、クラクフ工科大学の代表者が登壇し、WordPressエグゼクティブディレクターのMary Hubbard氏に情報数学部からの贈り物を手渡した。同大は2026年10月からWordPress専門コースを開講する。これはポーランド国内だけでなくWordPressコミュニティ全体にとっても先駆的な取り組みだ。
Hubbard氏はGutenbergプロジェクトリードのMatías Ventura氏と、WordPressデザイナー兼開発者のRich Tabor氏をステージに招き、WordPressの将来方向性を議論した。Ventura氏はWordPress 7.0のリリースリードを務めたばかりで、まず全貢献者にスタンディングオベーションを求めた。
- ● クラクフ工科大学のWordPress専門コース開講（2026年10月〜）
- ● WordPress Campus ConnectとWordPress Creditsの教育プログラム成果
- ● AIとWordPressの関係。デザインシステムの長期的投資がAI連携で成果を上げている
- ● WP-CLIをAIモデルが流暢に利用。Studio Codeエージェントベースのコーディングツール開発
- ● USパイロット版AIリテラシーマイクロクレデンシャル。WordPressを学習の場に活用
Hubbard氏はオープンソースとAIの関係について、明確な立場を示した。「オープンソースこそがWordPressの成長を支えてきた。同じ価値観がAIを形作るべきであり、コミュニティはもっと声高に主張すべきだ」
—
この記事のポイント
- WCEU 2026には81カ国から2,458名が参加。CERNがWordPress採用の基調講演を実施
- WordPress 7.0にネイティブAIクライアント、Abilities API、Connectors画面が実装された
- AI関連セッションでは「人間とAIの役割分担」「実務的な監査自動化」が具体的に語られた
- 開発トラックではWP_Queryキャッシュ改善、HTML API、アクセシビリティ対応の実審査事例が共有された
- クラクフ工科大学が2026年10月よりWordPress専門コースを開講。教育分野での広がりが加速している
—
AWS Bedrock刷新、OpenAIとAnthropic API互換コンソールが登場
AWSが2026年6月5日、Amazon Bedrockの管理コンソールを刷新した。この新体験は「bedrock-mantle」エンジン向けに設計されており、Anthropic Messages APIとOpenAI Responses APIに最適化されている。
従来のBedrockコンソールはマネージド機能（AgentsやKnowledge Basesなど）を中心に据えていたが、今回の刷新はAPI直接呼び出しを前提とする開発者向けに設計し直されている。モデル選定からプロダクション実装までの時間を大幅に短縮する狙いだ。
この記事では、新コンソールの主要機能と開発ワークフローへの影響を詳しく見ていく。API互換性を活かしたコードの簡略化や、複数モデルの並列評価がどのように実現されるのかを解説する。
Bedrockの新コンソールが生まれた背景
この図が示すように、新コンソールは「プロジェクト」を軸にした作りになっている。モデルの評価から実装、モニタリングまでをひとつの画面で完結させる狙いだ。
bedrock-mantleエンジンとは何か
bedrock-mantleは、Bedrockの第2世代推論エンジンとして位置づけられる。高速な処理性能と高い信頼性、そしてエンタープライズレベルのセキュリティを兼ね備えている。
最大の特徴はAnthropicとOpenAIのAPIプロトコルに互換性を提供することだ。ClaudeモデルにはAnthropic Messages API（メッセージAPI）を、GPTモデルにはOpenAI Responses API（レスポンスAPI）とOpenAI Chat Completions API（チャット補完API）を使える。これにより、既存のSDKコードをほぼ変更せずにBedrockへ移行できる。
従来のbedrock-runtimeエンドポイントを使う既存機能（InvokeModelやConverse API、Agentsなど）は、引き続き従来のBedrockコンソールから利用できる。両者は併存する設計で、急な移行は求められない。
新モデルカタログが提供する高速な比較体験
新コンソールの目玉のひとつが、刷新されたモデルカタログだ。従来は各モデルの仕様を調べるためにドキュメントや料金計算ツールを行き来する必要があったが、それが1画面で完結するようになった。
最大3モデルを並べて比較
カタログ上で最大3つのモデルを選択し、機能、モダリティの対応状況、コンテキストウィンドウの大きさ、利用可能なリージョン、料金体系を横並びで比較できる。
この比較機能は、チーム内でのモデル選定会議や、PoC（概念検証）フェーズでの迅速な意思決定に力を発揮する。料金と性能のトレードオフを視覚的に把握できるのが強みだ。
プロジェクト単位で完結する開発ワークフロー
新コンソールの中核は「プロジェクト」という概念だ。生成AIアプリケーションの開発ライフサイクルをプロジェクトとして管理し、モデルの割り当てからAPIキーの発行、推論リクエストの送信までを一気通貫で行える。
ダッシュボードでトークン消費を可視化
プロジェクトダッシュボードでは、直近の推論リクエスト数やエラー発生率を日付範囲でフィルタリングできる。さらに、総トークン消費量、1分あたりのトークン使用量、推論リクエストの回数、1リクエストあたりの平均トークン数がグラフ表示される。
このデータは、モデルの選択ミスや過剰なトークン消費を早期に発見する手がかりになる。チームの予算管理にも直結するため、プロダクション環境では特に価値が高い。
サイドバイサイド評価でプロンプトを最適化
プロジェクト内で最大3つのモデルを選択し、同じプロンプトに対する応答を横に並べて比較できる評価モードが用意されている。これにより、どのモデルが自社のユースケースに最適かを実データで判断できる。
評価結果はそのままプロダクション環境へ移行する際の根拠資料としても使える。カスタマーサポート用チャットボットであれば、回答の質と応答速度のバランスを定量的に比較できる。
コード生成とAIアシスタント連携の新機能
最も実務インパクトが大きいのが、プロジェクトに紐づいた「ライブドキュメント」機能だ。コードサンプルやSDKスニペット、APIリファレンスにプロジェクトの変数（モデルID、リージョン、エンドポイントURL、APIキー）が自動で埋め込まれる。
コピーするだけで動くコードスニペット
開発者はコンソール上で表示されたコードをそのままコピーし、ローカル環境のアプリケーションに貼り付けるだけで動作確認できる。環境変数の手動設定やエンドポイントURLの確認といった手間が省ける。
AWS_REGION=us-east-1
ENDPOINT=bedrock-mantle
API_KEY=sk-xxxxxx
client = boto3.client()
response = client.invoke(modelId=MODEL_ID)
この仕組みにより、環境構築のミスが大幅に減る。特に複数プロジェクトを抱えるチームでは、設定の食い違いによるトラブルシューティング時間を削減できる。
AIコーディングエージェントとの統合
新コンソールはAIコーディングエージェントとの連携もサポートする。Claude Code、Cline、Codex、Cursor、OpenCodeといった主要なAIアシスタントをBedrockのmantleエンジンにルーティングする手順がガイドされる。
具体的には、AWS IAM認証情報かBedrock APIキーを使い、環境変数を設定したうえで各エージェントからのリクエストをBedrock経由にする設定が案内される。これにより、AIアシスタントのバックエンドをOpenAIやAnthropicのクラウドからAWS環境に切り替えられる。企業ポリシーでデータの外部送信を制限しているケースで有効だ。
利用可能リージョンと今後の展開
新コンソール体験は、bedrock-mantleエンドポイントが提供されている全リージョンで利用可能だ。2026年6月時点での対象は以下の通り。
AWSのドキュメントにはリージョン互換性の一覧ページが用意されており、将来的な拡大があれば随時更新される見込みだ。フィードバックはAWS re:Post for Amazon Bedrock、または通常のAWSサポート窓口を通じて送ることができる。
新コンソールは既存のBedrockコンソールと並行して運用される。急な切り替えを迫られることはなく、チームの準備が整った段階で徐々に移行できる設計だ。
この記事のポイント
- Amazon BedrockにAPI互換性を重視した新コンソールが登場し、モデル評価から実装までの時間が大幅に短縮される
- bedrock-mantleエンジンはAnthropic Messages APIとOpenAI Responses APIに対応し、既存SDKコードの流用が容易
- 最大3モデルのサイドバイサイド比較と、プロジェクト単位のトークン消費可視化が組み込まれている
- コンソール上のコードスニペットはプロジェクト変数が自動プレフィルされ、コピー後即実行できる
- 東京リージョンを含む複数リージョンで利用可能、既存コンソールとの併存もサポートされる
WP.orgがProtect The Shire発表、プラグイン更新に24時間の猶予
2026年6月5日、WordPress.orgはセキュリティイニシアチブ「Protect The Shire」を正式に発表した。AIによるコード生成能力が急激に進化する中、78,000以上にのぼる公式プラグインとテーマをサプライチェーン攻撃から守るための大規模な取り組みだ。
この施策の中核は、すべてのプラグインとテーマのリリースに対して設けられる最大24時間の猶予期間である。開発者が新バージョンをプッシュしても、自動更新がユーザーサイトに配信されるまでにクールダウンが発生する仕組みに変わる。
Protect The Shire イニシアチブの全容
WordPress.org の共同創設者 Matt Mullenweg 氏は今回の発表で、2026年という年がソフトウェア開発において「緊張の年」になると指摘する。最新のセキュリティパッチを一秒でも早く適用する必要性と、悪意あるコードが更新に混入していないか慎重に見極める必要性が、かつてないほど対立しているためだ。
自動更新前の24時間クールダウン
従来のフローでは、開発者がプラグインやテーマの新バージョンをリポジトリにコミットすると、即座に世界の全サイトへ自動更新が配信されていた。これは利便性が高い一方で、ひとたび悪意のあるコードが混入すれば、被害が広範囲に瞬時に拡散するリスクを常にはらんでいた。
Protect The Shireの導入により、リリースから配信までの間に最大24時間の待機時間が挿入される。この時間を利用して、人間のレビューチームとAIがコードを精査する。
この変更により、悪意のあるコードを含むアップデートが即座に配信されるリスクが抑えられる。AIによる事前チェックと人間の確認が介在することで、サプライチェーンセキュリティが大幅に強化される仕組みだ。
AI「Gandalf」によるコード監視
24時間の猶予期間におけるレビュー作業を強力に支援するのが、新たに導入されるAIだ。Mullenweg氏はこれを「Gandalf」と名付けられたWapuuだと表現している。
人間のレビューチームは寝る必要があるが、AIにはそれがない。24時間体制でコミットの差分を分析し、不審なコードパターンや既知の脆弱性シグネチャを検出する。Mullenweg氏は、今回のAI技術の進歩がなければ実現しえなかったレビューの深さだと言及している。
なぜいまエコシステムの防御を固めるのか
昨年末から今年にかけて、AIのコーディング能力は飛躍的に向上した。Anthropicが2026年4月に公開したモデル「Mythos」は、その能力の高さと潜在的なリスクで開発者コミュニティに衝撃を与えている。また、Chromeブラウザの最新版が429件ものセキュリティ修正を含んでいたことも、各所のセキュリティ活動を加速させた。
拡大するサプライチェーン攻撃の脅威
ソフトウェアのサプライチェーンを標的とした攻撃は、もはや日常的だ。オープンソースエコシステムにおいても、マルウェアを仕込まれたパッケージが正規のアップデートとして配布される被害が後を絶たない。WordPressコミュニティ内でも、信頼されていたプラグインが悪意ある新しい所有者に売却され、バックドアを仕掛けられた「Essential Plugins」のような事件が発生している。
AIによる攻撃コードの生成能力が向上すれば、この種の脅威はさらに巧妙化し、頻度も増加する。WordPress.orgが今回、エコシステム全体の防衛に乗り出したのは必然だったといえる。
更新速度と安全性のジレンマ
WordPress 7.0のアップグレード率はリリース後わずか2週間で50%を超えた。これは数えきれないほどの開発者とホスティング事業者の協力による成果だ。素早いアップデートの適用は、脆弱性への露出時間を最小化するという点で極めて重要である。
しかし、Mullenweg氏は「2026年は、安全を確保するために可能な限り早く更新するのか、それとも安全を確保するために更新を保留するのか、その緊張が続く年になる」と述べている。急速なコード配布は、攻撃者にとっても好都合な環境になりうる。このジレンマを解消するのが、今回の24時間ルールというわけだ。
WordPressが目指す「透明性によるセキュリティ」
Mullenweg氏は発表の中で「自由とセキュリティはゼロサムではない」という考えを強調した。これは、セキュリティの名の下にパーミッションを厳格化しすぎて、ソフトウェアの自由な流通や改変を妨げることへのカウンターである。オープンソースは、曖昧さによるセキュリティではなく、透明性こそが強固なセキュリティをもたらすことを示してきた。
スケールするレビュープロセス
プラグインレビューチームは献身的に活動しているが、人間の処理能力には限界がある。Mullenweg氏は、現在の24時間という猶予が、AIモデルのさらなる進歩とともに「数分」にまで短縮される可能性に期待を示している。
ひとつのリリースを複数のAIエージェントが並列でレビューし、人間の承認プロセスと連携する。これにより、手動では不可能な精度と速度で、78,000以上のプロジェクトの安全性を担保しようという狙いだ。
4億インストールの重み
WordPress.orgのプラグインディレクトリには、累計で4億を超えるインストールが記録されている。69のプラグインは、100万件以上のサイトにインストールされている。その開発者の多くは個人であり、巨大なコミュニティを構成している。
WordPress.orgはこの多様なエコシステムを守るため、Star数などの表面的な評価だけでなく、実際のコードの安全性に焦点を当てた支援を強化する方針だ。そのための現実的な第一歩が、今回のProtect The Shireである。
この記事のポイント
- WordPress.orgがプラグインとテーマの自動更新に「最大24時間の猶予期間」を導入した
- AI Wapuu「Gandalf」を含む新たなレビューフローにより、サプライチェーン攻撃のリスクを低減する
- この施策は、AIによる高度なコード生成が一般化する時代におけるエコシステム防衛策である
- オープンソースの理念に沿い、透明性を保ったままセキュリティ水準を引き上げる試みだ
VS Code 1.124が公開、AIエージェントがさらに賢く進化しマルチチャット対応
“`md — — title: “VS Code 1.124が公開。AIエージェントがさらに賢く進化しマルチチャット対応” meta_description: “VS Code 1.124が2026年6月に公開。Agentsウィンドウのマルチチャット対応やバックグラウンド送信、WSL連携の強化、統合ブラウザの改善点を詳しく解説。” tags: [“VS Code”, “アップデート”, “AI”, “開発支援”, “エージェント”, “統合ブラウザ”, “WSL”] slug: “vscode-1-124-release” scrape_method: “trafilatura” image_prompt: “Upper portion: a wide monitor screen showing the Visual Studio Code editor with the Agents window open, displaying multiple chat sessions in a grid layout, all interface text in English. The VS Code logo (an angular blue ribbon mark) prominently displayed in photorealistic 3D with subtle reflections. Lower portion: a sleek server rack with glowing blue and purple fiber optic cables in a dark data center. Composition: split-screen style with key visual elements positioned in the upper and lower portions of the frame, with a natural atmospheric transition in between, no horizontal bands or strips across the frame. 16:9 aspect ratio. If UI screens, dashboards, code editors, or admin panels appear, all text within them must be in English. If laptops or monitors appear, use ultra-thin bezel modern design. No visible year numbers on calendars, screens, or documents.” featured_text: “VS Code 1.124\nAIエージェント進化” — —
VS Code 1.124が2026年6月に公開された。今回のアップデートの中核は、AIエージェント機能「Agents」ウィンドウの大幅な機能強化だ。マルチチャットやバックグラウンド送信といったワークフローを加速させる機能が追加され、開発者の作業効率は一段と向上する。
このリリースでは、WSL環境とのシームレスな接続や、統合ブラウザのカスタマイズ性向上も同時に実現された。大規模なリファクタリングや新規開発の伴走者として、VS CodeのAI機能はより実用的な段階に入ったといえる。
本記事では、VS Code 1.124の主要な変更点を3つの観点から掘り下げ、実際の開発現場でどう役立つのかを具体的に解説する。
Agentsウィンドウのマルチチャット対応
今回のアップデートで最も注目すべきは、Agentsウィンドウにおけるマルチチャット機能の正式な導入だ。これまで1つのセッション内で完結していた対話が、複数の並列セッションとして管理できるようになった。
具体的には、ローカルセッションにおいて複数のチャットを同時に立ち上げ、それぞれ異なるタスクを進行させられる。あるチャットでコードのリファクタリングを指示している間に、別のチャットで新しい機能の設計について相談する、といった使い方が可能だ。
上の図のように、開発者はエージェントの応答を待つことなく次の指示を出せる。これにより、思考の分断が減り、作業スピードが格段に上がる。マルチタスクが前提の現代の開発フローに、AIがようやく追いついた形だ。
バックグラウンド送信で考える時間を確保
マルチチャットをさらに快適にするのが、バックグラウンド送信機能だ。新しいセッションを開始する際、Alt+Enter（macOSではCmd+Enter）を押すか、送信ボタンをAltキーを押しながらクリックすることで、そのセッションにすぐに移動せずに次のメッセージを入力できる。
これにより、複数の質問や指示を立て続けにエージェントへ送り、応答をバックグラウンドで処理させながら、自分は次のタスクの構想を練るという働き方が実現する。まさに「ながら作業」の効率を最大限に引き出す設計だ。
セッション管理のキーボード操作が充実
増えたセッションを素早く操作するためのショートカットも整備された。Ctrl+1からCtrl+9（macOSではCmd+1〜Cmd+9）で、グリッド表示されたセッションを位置で直接フォーカスできる。さらに、Ctrl+K Ctrl+W（macOSではCmd+K Cmd+W）で全セッションを一括クローズすることも可能だ。
チャット入力の履歴も、現在のセッション内にスコープが限定されるようになった。上下の矢印キーで過去のプロンプトを呼び出す際、他のセッションの履歴が混ざることがなくなり、誤操作が減る。
統合ブラウザの使い勝手が向上
VS Codeに内蔵された統合ブラウザも、今回のリリースで実用性が高まった。ツールバーのアクションを個別に表示・非表示できるようになり、自分がよく使う機能だけを並べたミニマルなUIを構築できる。
コンテキストメニューから各アクションの表示を切り替えられるため、プレビュー用途ではナビゲーション系だけ、デバッグ用途では開発者ツール系だけ、といった使い分けが容易になった。
アドレスバーでのURL履歴ナビゲーション
統合ブラウザのアドレスバーでも、上下の矢印キーで過去に訪れたURLをたどれるようになった。これはデスクトップブラウザではおなじみの操作だが、VS Code内のブラウザでも同じ感覚で履歴を遡れるのは地味に大きい。ちょっとしたAPIドキュメントの巡回作業がよりスムーズになる。
エディタの細かな改良点
AI機能やブラウザだけでなく、エディタの基礎的な部分にも手が入っている。シンプルファイルダイアログでは、新しくフォルダをその場で作成できるようになった。ファイルを保存する際、わざわざOSのファイラーを開かずとも、ダイアログ内でフォルダを作ってすぐに格納できる。
もう1つ、エディタのカスタマイズに関わる変更として、折りたたみマーカーのパターンに正規表現のフラグが使えるようになった。language-configuration.jsonで{ pattern, flags }というオブジェクト形式を受け付けるようになり、大文字小文字を区別しないマッチングなどが可能になる。大規模な設定ファイルを管理する開発者には嬉しい拡張だ。
WSL環境との連携がさらに強化
Windows Subsystem for Linux（WSL）を利用する開発者にとって、今回のアップデートは実用的な価値が大きい。AgentsウィンドウがWSL接続を正式にサポートしたことで、Windows上のVS CodeからLinux環境のコードベースに対して直接AIエージェントを操作できるようになった。
WSLとは、Windows上でLinuxの実行環境をネイティブに近い形で動かす仕組みだ。Web開発やデータサイエンスの分野では、Linuxネイティブのツールチェーンを使うためにWSLを利用するケースが増えている。今回の対応により、WSL内のプロジェクトに対しても、エージェントがコンテキストを理解した上でコード生成やリファクタリングを行える。
これまでWSL上で作業する際、AI機能を使うためにWindows側へコードをコピーするといった一手間が必要だった。その手間がなくなるだけで、日々の開発効率は確実に改善される。
この記事のポイント
- Agentsウィンドウがマルチチャットに対応し、複数のタスクを並行してエージェントに依頼できる
- バックグラウンド送信でセッションを離れずに次の指示を入力可能。思考の連続性が保たれる
- キーボードショートカットでセッションのフォーカス移動や一括クローズができるようになった
- 統合ブラウザのツールバーがカスタマイズ可能になり、URL履歴の操作も改善
- WSL環境との連携がエージェント機能にまで拡大し、クロスプラットフォーム開発がより快適に