Amazonが欧州で一括保管サービスAWDを開始 5カ国で8月20日から
Amazonが欧州で一括保管サービスAWD（Amazon Warehousing & Distribution）を開始する。8月20日からドイツ、フランス、イタリア、スペイン、英国の5カ国で利用可能になる。同サービスはAmazonセラーが大量の在庫を長期保管し、需要に応じてFBAフルフィルメントセンターへ自動補充する仕組みだ。
欧州でAmazonの販売を手がける中小事業者にとって、このサービスは物流面の大きな変化になる。特に繁忙期の在庫管理に悩むセラーには有効な選択肢となり得る。本記事ではAWDの仕組みと利点、そして物流チェーンへの影響を解説する。
AWDとは何か
AWD（Amazon Warehousing & Distribution）は、Amazonセラーが商品を一括でAmazonの配送センターに預け、長期間保管できるサービスだ。保管された在庫は、需要に応じてFBA（Fulfilment by Amazon）フルフィルメントセンターへ自動的に補充される。FBAとは、Amazonが商品の保管、梱包、発送、カスタマーサービスまでを代行する仕組みである。
一括保管と自動補充の仕組み
従来のFBAでは、セラーは商品をフルフィルメントセンターに直接納入する。しかしFBAには保管容量の制限があり、大量の在庫を一度に預けることは難しかった。AWDはAmazonの配送センターで長期の一括保管を行い、FBA側の在庫が減ると自動で補充する。これによりセラーは在庫を手動で移動させる手間から解放される。
AWDは物流の上流に位置する保管拠点の役割を果たし、FBAは注文に応じた出荷を担う。この2つの層をAmazonが一括管理することで、セラーの在庫管理業務が簡素化される。
AWDの料金体系
AWDの料金は、保管料に加えてFBAセンターへの処理費と輸送費が発生する。Amazonはセラー向けの説明で「定額制の長期一括保管」と表現しており、保管コストを予測しやすい設計になっている。ただし処理費と輸送費が別途かかるため、導入前に自社の物流コストと比較する必要がある。
欧州5カ国での提供開始
8月20日からAWDはドイツ、フランス、イタリア、スペイン、英国で利用可能になる。これらは欧州最大のEC市場であり、Amazonが各市場でトップの地位を築いている。欧州のセラーにとって、AWDの開始は物流インフラの選択肢が増えることを意味する。
対象市場とAmazonの地位
欧州のEC市場は国ごとに商慣行や物流網が異なる。しかしAmazonは5カ国すべてで市場リーダーであり、多数の中小セラーが出店している。これらのセラーがAWDをどう活用するかが、今後の普及を左右するだろう。
セラーにとっての3つのメリット
AWDの導入により、セラーは主に3つのメリットを得られる。FBA容量制約からの解放、自動補充による品切れ防止、繁忙期の在庫管理の容易化だ。いずれも売上機会の損失を減らす効果が期待できる。
FBA容量制約からの解放
FBAには保管容量の制限があり、セラーは在庫を増やしたくても受け入れ枠の問題で制約を受けることがあった。AWDを利用すれば、Amazonの配送センターで大量の在庫を長期保管できるため、FBAの容量制約に縛られずに商品を仕入れることが可能になる。
AWDを利用する前と後では、在庫管理の自由度に大きな差が出る。容量制約に縛られずに仕入れができる点は、売れ筋商品の取り扱い数を増やしたいセラーに特に有効だ。
自動補充で品切れを防ぐ
Amazonの説明によると、AWDの自動補充機能は手動での在庫補充作業を不要にし、品切れリスクを低減する。売れ筋商品の在庫が減れば、Amazonが需要を判断してFBAへ補充する。これによりセラーは商品管理から発注業務に時間を割かずに済む。
繁忙期の在庫管理が容易になる
Prime DayやBlack Fridayなどの繁忙期は、短期間で需要が急増する。こうした時期に在庫切れを起こすと、大きな売上機会を失う。AWDなら事前に大量の在庫を保管しておき、需要の高まりに応じて自動でFBAへ補充できる。繁忙期特有の在庫不足を防ぐ手段として、特に中小セラーには実用性が高い。
物流チェーンの支配強化とセラー依存
AWDはセラーの在庫とFBAネットワークの間に、新たな物流の段階を追加する。これは利便性の向上と同時に、Amazonが物流チェーン全体を掌握する動きとも読み取れる。
物流チェーンにAWDが加わることで、商品の保管から出荷までの工程がAmazonの管理下に置かれる。セラーにとっては手間が減る一方、Amazonへの依存度が高まる構造になる。
Amazonの物流支配が強まる
AWDは、Amazonがセラーの在庫保管から配送までを一貫して担う流れを加速させる。Amazonは昨年、欧州でセラー向け手数料を引き下げる施策を実施している。物流サービスを拡充する一方で手数料を調整し、より多くのセラーを自社物流網に取り込む戦略が見える。
セラーの依存度増加
欧州には10万を超えるサードパーティセラーが存在し、Amazonの欧州店舗における売上の大部分はこれらのセラーによって生み出されている。特に中小企業が多い。AWDによって業務が簡素化される一方で、在庫保管から配送までAmazonに委ねる割合が増えれば、プラットフォームへの依存はさらに深まる。Amazonは自社を欧州の中小企業の「味方」と位置づけているが、その関係性は常に緊張をはらんでいる。
米国での展開と今後の可能性
AWDは米国で4年前にサービスを開始しており、すでに一定の実績がある。欧州への展開はその成功を踏まえたものだ。ただし欧州版には現時点で含まれない機能もある。
米国では外部販売チャネルにも供給可能
米国ではAWDに預けた在庫を、Amazonの販売チャネル以外にも供給できるオプションが提供されている。つまりセラーは自社のオンラインストアや他社のECモールへ商品を供給する際にも、Amazonの保管拠点を利用できる。しかし欧州版のローンチ時点では、この外部チャネルへの供給オプションは含まれていない。
欧州の今後の展開は未定
現時点で、AWDが欧州の5カ国以外に展開されるかどうかは明らかになっていない。ただ欧州のEC市場規模を考えると、今後対象国を拡大する可能性は十分にある。外部販売チャネルへの供給機能が欧州でも提供されれば、AWDの価値はさらに高まるだろう。
この記事のポイント
- Amazonが欧州5カ国で一括保管サービスAWDを8月20日から開始する
- AWDは長期の一括保管とFBAへの自動補充が特徴だ
- セラーはFBA容量制約なしで在庫を保管でき、品切れリスクを抑えられる
- 一方でAmazonへの物流依存度が高まる側面もある
- 米国では外部販売チャネルへの供給も可能だが、欧州版では未対応だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflare DDoS脅威レポート2026年上半期、1Tbps攻撃が935件に急増
Cloudflareが2026年8月11日、DDoS脅威レポートの2026年上半期版を公開した。今回で通算25回目の発行となる。四半期ごとの発表を統合し、1月から6月までを単一のレポートにまとめた形式だ。
レポートによれば、Cloudflareは上半期で2,320万件のネットワーク層DDoS攻撃と29兆6,400億件のHTTP DDoSリクエストを軽減した。1時間あたり約5,343件、1日あたり約12万8,000件の攻撃に相当する。
なかでも1Tbps（テラビット毎秒）を超える超大規模攻撃の急増が目を引く。攻撃ベクトルはボットネット直撃型から反射・増幅型へ移行しつつあり、防御側の自動化がこれまで以上に重要になっている。
2026年上半期のDDoS攻撃概況
4月にピーク、国際摘発作戦で減少へ
4月は攻撃のピーク月だった。攻撃リクエストは6兆4,600億件、通信量は165PB（ペタバイト）に達した。この量は大手動画プラットフォームが1日で処理するデータ量に匹敵する規模だ。
その後、攻撃件数と通信量は減少に転じた。同時期に実施された国際法執行作戦「Operation PowerOFF」が影響したとみられる。21カ国が参加し、DDoS攻撃代行サービスの利用者7万5,000人超を標的に、53のドメインを停止、25件の家宅捜索、4人の逮捕という成果を上げた。
法執行の直接的な抑止効果は計測しにくい。ただし摘発の直後に攻撃数が減少した事実は、DDoS攻撃代行サービス（いわゆるブートストレスサービス）の利用層がインターネット全体の攻撃量に与える影響の大きさを示している。個人が安価に攻撃を「注文」できる構造が、この規模の攻撃増加を支えている構図だ。
1Tbps超の攻撃が6倍以上に急増
1Tbps超の超大規模攻撃は第2四半期だけで805件に達した。前期比で6倍以上の増加だ。上半期全体では935件の1Tbps超ネットワーク層攻撃を軽減している。
DDoS対策の世界では「ハイパーボリュメトリック攻撃」という分類がある。1Tbps以上、または毎秒10億パケット（Bpps）以上、または毎秒100万リクエスト（Mrps）以上のいずれかを満たす攻撃だ。2026年はこの分類に入る攻撃が順調に増えている。
ただし攻撃の中央値は小規模だ。ネットワーク層攻撃の96.62%が500Mbps未満、90.60%が10分未満で終了している。「小規模」といっても相対的な話だ。100Mbpsの攻撃だけで一般的なサーバーやWebサイトは十分にダウンし得る。100Gbpsなら無保護のデータセンターを停止させる威力がある。
攻撃者は帯域とパケットレートの組み合わせも工夫する。高パケットレート（Mpps単位）と低帯域幅（Gbps単位）を組み合わせ、ネットワーク機器の処理限界と回線容量の限界という異なる弱点を同時に狙う手口が観測されている。
攻撃ベクトルの変化とCLDAP急増
DNS系攻撃がネットワーク層の3分の1を占める
攻撃の中心はボットネット直撃型から反射・増幅型へ移っている。DNS系攻撃が上半期のネットワーク層攻撃全体の34.3%を占めた。第2四半期にはDNSフラッドの割合が25.7%から40.0%へ急拡大している。
DNSフラッドは、ボットネットが被害者の権威DNSサーバーへ大量のクエリを直接送りつける攻撃だ。このドメインの「電話帳」に当たるDNSサーバーが応答不能になると、そのドメインに依存するサービスはすべて機能を失う。
DNSアンプリフィケーションは別の仕組みだ。攻撃者は送信元IPを偽装した小さなクエリを公開DNSリゾルバへ送る。リゾルバは元のクエリよりはるかに大きな応答を、偽装されたIP（つまり被害者）へ返す。少ない帯域で大きな攻撃を生み出せるため、攻撃者にとって効率がよい。
上の図は3つの攻撃ベクトルの違いを整理したものだ。直撃型は攻撃者自身の帯域がそのまま攻撃力になる。反射・増幅型は第三者のサーバーを踏み台にするため、攻撃者側の帯域が少なくても大きな打撃を与えられる。
CLDAPフラッドが580%増
CLDAPフラッドの伸びは顕著だ。前期比580%増となり、第2四半期だけで第3位の攻撃ベクトルに浮上した。
CLDAP（Connectionless Lightweight Directory Access Protocol）はLDAPのUDP版だ。UDPはTCPと違いハンドシェイクが不要で、送信元IPの偽装が容易になる。攻撃者はUDPポート389で公開されたドメインコントローラーへ偽装クエリを送り、元の数十倍から数百倍の応答を被害者へ反射させる。
CLDAPの急増が示すのは、公開されたUDPサービスの危険性だ。ポート389が外部に開いている組織は、自覚のないまま攻撃者の踏み台にされている可能性がある。インフラ管理者にとっての実務的な教訓は「UDPポートの露出を監査し、不要なら閉じる」という基本対策の重要性が再確認されたことにある。
標的産業と地域の動向
メディア産業が最大の標的に
メディア・制作・出版産業が両四半期で最も攻撃された産業になった。全HTTP DDoSリクエストの14.2%を占め、2位の約4倍に相当する。イランとウクライナの戦況報道、そしてワールドカップ関連の報道が攻撃対象になったとみられる。
報道機関へのDDoS攻撃は、単なる金銭目的や愉快犯ではなく、情報の流れを止める意図を持つことが多い。特定の報道を続けるメディアのサイトを落とすことで、世論に影響を与えようとする動機が背景にある。
この図が示すように、標的と攻撃元の分布は対称ではない。標的は中国・米国など経済規模の大きい国に集中し、攻撃元はブラジル・インドネシアなどボットネット感染端末が多いとされる国に偏る。
政府部門が29位から9位へ急浮上
政府部門の動きは今年最大のトピックだ。2026年2月28日にイスラエルと米国が「Operation Epic Fury」を開始。その72時間以内に、16カ国110組織に対する149件のハクティビストDDoS攻撃が記録された。標的組織の47.8%が政府部門だった。
この結果、政府部門のシェアは第1四半期の29位から第2四半期には9位へ急上昇した。単一セクターの移動幅としては2026年最大だ。地政学的な緊張がDDoS攻撃の規模と方向性に直接影響を与える構図が、データとして明確に現れた。
国別では中国が最多の標的になった。第2四半期に全世界のHTTP DDoSリクエストの22.4%を吸収した。米国は18.8%で2位を維持している。トルコは攻撃シェアが倍増し、第3位に浮上した。6月から7月にかけてのアンカラNATOサミット準備期間中、治安当局が209人以上を逮捕する大規模な事前摘発を行った時期と重なる。
攻撃元の国ではブラジルが米国を逆転して1位になった。上半期のシェアはブラジル14.9%に対して米国13.4%だ。ブラジルは第2四半期に21.4%まで急伸した。インドネシアは両四半期とも3位を維持し、複数四半期連続で上位3カ国に入る常連になっている。
短時間攻撃と自動防御の重要性
90%以上が10分未満で終了
DDoS攻撃の大半は驚くほど短い。上位の超大規模攻撃ですら秒単位で終了する。過去には開始から終了までわずか35秒という記録的な攻撃も観測されている。
攻撃が30秒でも10分でも、人間が介入する実質的な時間窓は存在しない。セキュリティ担当者にアラートが届いた時点で、攻撃はすでに完了しているからだ。手動での軽減策やオンデマンド型の防御はこの現実に対して遅すぎる。
この図のとおり、攻撃の持続時間と人手による対応時間は圧倒的に乖離している。従来型の「監視して手動で対応する」運用モデルは、DDoS対策においては成立しない。
自動防御が唯一の実効策
さらに、短い攻撃の余波は長引く。ルーティングの不安定化、TCP再送、アプリケーションのタイムアウト、下流サービスの劣化などが数時間から数日続くことがある。サービス停止や品質低下は攻撃の終了後も継続するのだ。
この環境では、常時稼働する自動防御が「あったほうがよい」ものではなく必須の要件になる。Cloudflareは330以上の都市に分散したネットワーク全体で、人間の介入なしに攻撃を検知・軽減する仕組みを運用している。ネットワーク容量は500Tbps規模だ。
同社はさらに、DDoS攻撃を仕掛けるIPアドレスやアカウントを特定する無料のフィードをホスティング事業者やISP向けに提供している。世界800以上のネットワークが登録しており、ボットネットノードの撤去に一定の成果を上げている。
日本の事業者にとっての示唆は明確だ。自社サイトが直接の標的でなくても、反射型攻撃の踏み台にされたり、同じホスティング上の他サイトへの攻撃に巻き込まれたりするリスクは常にある。小規模サイトでも「攻撃を受けたら止まる」前提ではなく、自動防御を標準装備する発想が必要になる。
この記事のポイント
- 1Tbps超のネットワーク層DDoS攻撃が上半期で935件に達した
- DNS系攻撃がネットワーク層全体の34.3%を占め、反射・増幅型への移行が進む
- CLDAPフラッドが前期比580%増で第3位の攻撃ベクトルに浮上
- メディア・制作・出版が最も攻撃され、政府部門は29位から9位へ急上昇
- 攻撃の90.60%が10分未満で終了し、自動防御が実質唯一の対策になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google Cloudが2029年までに耐量子暗号へ完全移行。PQCロードマップの全容と企業が取るべき3ステップ
Google Cloudが2026年8月11日、2029年までに耐量子暗号（PQC / Post-Quantum Cryptography）へ完全移行するためのロードマップを公開した。量子コンピュータによる将来の暗号解読リスクに備え、APIエンドポイントやロードバランサーの対応はすでに始まっている。
今回の発表では、移行戦略の3つの重点領域、2026年に完了した基盤整備、2027年から2028年にかけてのドメイン別計画が示された。企業が今すぐ着手すべき3つのステップも提示されている。
量子コンピュータが実用化されれば、現在広く使われているRSAやECDSAなどの公開鍵暗号は解読可能になる。その影響はクラウドサービス全体に及ぶ。本記事では、Google CloudのPQCロードマップの全容と、企業に求められる対応を整理する。
PQC移行の全体像と2029年目標
Google CloudのPQC移行戦略は「セキュアバイデザイン」を基本方針とする。設計段階から量子安全を組み込むアプローチであり、単なる後付けの対策ではない。Google Quantum Threat Modelという独自の脅威モデルを土台に、3つの重点領域で保護を進める。
SNDLリスクとは何か
SNDL（Store Now, Decrypt Later）は「今保存して後で復号する」攻撃だ。攻撃者が現在の暗号化通信を傍受してデータを蓄積しておき、量子コンピュータが実用化された時点で一括して復号する。今日の暗号化データが将来の量子コンピュータで解読されるリスクは、すでに現実のものとなっている。
これがPQC移行を急ぐ最大の理由だ。機密データの保存期間が数十年に及ぶ場合、現在の暗号化方式のままでは将来の解読リスクを抱え続けることになる。特に金融機関や政府機関、医療機関では、このリスクへの対応が喫緊の課題だ。
このデモはSNDL攻撃のリスクとPQCによる防御の違いを示している。攻撃者がどれだけデータを蓄積しても、量子安全な鍵交換を使っていれば将来の解読は不可能になる。
Googleが定める3つの重点領域
Google CloudがPQC移行戦略で優先するのは、以下の3領域である。
- SNDLリスクの緩和。現在の暗号化データが将来の量子コンピュータで解読されることを防ぐ。
- 偽造に対する完全性の確保。デジタル署名を強化し、データやIDの偽造を防ぐ。
- 暗号アジリティの基盤強化。暗号標準の進化に合わせて、新しい方式を最小限の工数で採用できる柔軟なシステムを構築する。
3番目の「暗号アジリティ」は特に重要だ。暗号標準は今後も進化し続ける。特定のアルゴリズムに依存せず、新しい標準が出たら容易に切り替えられる仕組みがあれば、将来の移行コストを大幅に抑えられる。Googleはこの基盤への投資を戦略の中核に置く。
Google Cloudは規制期限を待たずに、内部インフラと顧客向けサービスのPQC移行を前倒しで進めている。2029年の完全対応を目標に、Sovereign Cloudの取り組み（Google Cloud DedicatedやGoogle Distributed Cloud）にもPQCソリューションを展開中だ。
2026年に完了した基盤整備
2026年時点で、すでに複数の基盤的マイルストーンが達成されている。これらは顧客に対して即座の保護を提供するものだ。
APIエンドポイントとロードバランサーの対応
Google CloudのAPIエンドポイントは、量子安全な鍵交換に対応した。google.comと*.googleapis.comの両方が、NIST標準化済みのML-KEM（FIPS 203）をハイブリッドモードで実装している。ハイブリッドモードとは、従来の暗号とPQCを併用する方式だ。互換性を保ちながら量子安全性を確保できる。
アプリケーションロードバランサーとプロキシロードバランサーも、TLS 1.3における量子安全ハイブリッド鍵交換（X25519MLKEM768）をサポートする。当初はオプトイン方式で提供され、顧客は既存アプリケーションへの影響を最小限に抑えながら検証を進められる。
さらに、ChromeとCloudflareが進めるMerkle Tree Certificatesの実験にも参画している。PQC署名をWebPKIに適用する際の課題（署名サイズの肥大化など）に対処する取り組みだ。
Cloud KMSのPQCアルゴリズム一般提供
Cloud KMSでは、NIST標準化済みのPQCアルゴリズム（ML-KEM、ML-DSA、SLH-DSA）が一般提供（GA）に達した。暗号化鍵と署名鍵の両方で量子安全なアルゴリズムを利用できる。
これは企業にとって大きな意味を持つ。既存のCloud KMS利用者は、新しいPQCアルゴリズムを試すために特別な準備をする必要がない。すでに一般提供されているため、本番環境での利用も可能だ。
ドメイン別ロードマップ（2027〜2028年）
Google Cloudは2029年の完全対応に向けて、リスクベースのアプローチで3つのドメインを定義した。各ドメインには目標完了時期が設定されている。サービスによって個別のタイムラインは調整される可能性があるが、大多数のサービスは目標時期に合わせて移行を完了する見込みだ。
このタイムラインは、Google CloudのPQC移行が段階的に進むことを示している。2026年の基盤整備から始まり、2027年には通信経路の保護、2028年には署名と鍵管理、2029年に全体の収束を目指す。
ドメイン1 SNDL対策（2027年目標）
ドメイン1は非対称暗号の脆弱性に対処する。将来の量子コンピュータが今日の暗号化データを復号するリスクを防ぐのが目的だ。対象となるのは以下の3つの経路である。
- 顧客ワークロードの保護。Google Cloudサービスとロードバランサーに量子機密TLS 1.3ハンドシェイクを提供する。
- 管理者・開発者フローの保護。Cloud VPNやInterconnectを含む管理者経路をSNDLから守る。開発者向けにはクライアントライブラリ、SDK、オープンソース暗号ライブラリのTinkを対応させる。
- データパイプラインの保護。分析・ストレージプラットフォームのデータ転送を保護し、機密情報が傍受・蓄積されても将来復号されないようにする。
このドメインの特徴は、通信経路の保護に焦点を当てている点だ。特にTinkの対応は重要である。TinkはGoogleが開発したオープンソース暗号ライブラリで、多くの開発者が利用している。TinkがPQCに対応することで、開発者はアプリケーションレベルで量子安全な暗号を容易に導入できる。
ドメイン2 完全性と否認防止（2028年目標）
ドメイン2はデジタル署名と証明の量子対応を扱う。量子コンピュータによる偽造攻撃からデータの完全性と信頼性を守る。3つの主要分野がある。
1つ目はソフトウェアサプライチェーンの保護だ。Binary Authorization、Cloud Build、Assured Open Source Softwareなどのサービスで、量子耐性のある証明（アテステーション）を導入する。信頼できる変更されていないイメージだけが本番環境で実行されることを保証する。
2つ目は量子安全な証明書の発行だ。内部および外部の認証局（CA）をML-DSA証明書に対応させる。状況に応じてSLH-DSA証明書もサポートする。IETF（Internet Engineering Task Force）の標準化に積極的に貢献しており、大規模な署名サイズ問題にはMerkle Tree Certificatesなどの新しいアプローチを検証中だ。
3つ目はIDとアクセスの保護である。サービスアカウントキーやトークン（JWT / OAuth）を量子偽造に対して耐性のある方式に移行する。
ドメイン3 基盤と鍵管理（2028年目標）
ドメイン3はPQC移行の土台となる暗号アジリティを扱う。ここでの投資が、ドメイン1と2の実現を支える。
基盤となる鍵管理とライブラリでは、Cloud KMSとBoringSSL、Tinkを通じてNIST承認アルゴリズムを有効にする。Cloud KMSはすでにML-KEM、ML-DSA、SLH-DSAの一般提供を開始しており、量子安全な鍵のインポートも準備中だ。
ハードウェアが関わる部分では、Confidential ComputingとCloud HSMにPQCを組み込む。量子的なルートオブトラストを確立し、物理的な基盤を保護する。OpenTitanやCaliptra v2.1、TPM 2.0 v185などのオープンソースシリコン基盤もPQC対応を進めている。
Google Workspaceのクライアントサイド暗号化（CSE）と外部鍵マネージャー（EKM）にもPQCオーケストレーションを導入する。オンプレミスの鍵プロバイダーとの連携も進める計画だ。
量子安全における共有責任モデル
量子安全はGoogle Cloudと顧客の共同作業である。クラウドセキュリティの共有責任モデルがPQCにもそのまま適用される。
この図は責任の境界を明確にしている。重要なのは、Google Cloud側のPQC対応が完了しても、顧客がクライアントソフトウェアを更新しなければ量子安全な接続は確立しない点だ。
Google側の責任範囲
Googleはサーバー、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTSプロトコルのPQC移行を一括して管理する。ハードウェアの移行は、積極的な交換と自然な機器更新サイクルを組み合わせて段階的に進める。物理コンポーネントの中には2029年を超えて移行が続くものもあるが、安定性を優先したフェーズドアプローチを取る。
顧客側の責任範囲
顧客は自社アプリケーションの管理に責任を持つ。クライアントソフトウェアをPQCハンドシェイク対応に更新すること、非対称鍵のライフサイクル管理、Google Cloudサービスの設定変更が含まれる。
ここが最も見落とされやすいポイントだ。インフラ側がPQC対応しても、クライアント側が古い暗号方式で接続すれば、量子安全性は確保されない。企業のセキュリティチームは、自社のクライアントソフトウェアがPQC対応済みかどうかを確認する必要がある。
企業が今すぐ着手すべき3つのステップ
Google CloudはPQC移行の第一歩として、企業が即座に着手できる3つのステップを提示している。どれも実務に直結する具体的なアクションだ。
- 棚卸し（Inventory）。Cloud Asset InventoryやWizなどのツールを使って、鍵や証明書などの暗号資産を特定する。組織全体の暗号リソースをマッピングし、移行バックログの優先順位を定義する。
- 更新（Update）。開発チームとSREチームが使うソフトウェアが、BoringSSL、Chrome、SDKなどPQCアルゴリズムに対応していることを確認する。エッジで量子安全接続が有効化された際に、社内ワークフローが準備できている状態を作る。
- 検証（Validate）。Google Cloudの量子安全APIとロードバランサーを使って既存アプリケーションの挙動をテストする。本番環境に影響が出る前に、アーキテクチャ上のボトルネックを特定できる。
この3ステップは、PQC移行を「待つ」のではなく「準備する」アプローチだ。特に検証は重要である。量子安全なTLS接続は従来よりオーバーヘッドが大きい場合があり、アプリケーションのパフォーマンスに影響を与える可能性がある。事前のテストで課題を洗い出しておけば、本番移行時のリスクを大幅に減らせる。
この記事のポイント
- Google Cloudは2029年までにPQC完全対応を目指し、ロードマップを公開した
- SNDLリスク（今保存して後で復号）は企業にとって喫緊の課題である
- 2026年時点でAPIエンドポイント、ロードバランサー、Cloud KMSのPQC対応が完了している
- 3つのドメイン（SNDL対策、完全性確保、鍵管理基盤）で2027〜2028年に移行を進める
- 企業は棚卸し、更新、検証の3ステップで今すぐ準備を開始できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Gemini 3.7 Flash登場。エージェント向け性能向上と半額価格の全容
Google DeepMindは8月13日、新しいAIモデル「Gemini 3.7 Flash」を発表した。コーディングとエージェント用途に特化したFlashシリーズの最新版で、わずか3週間前に登場したGemini 3.6 Flashから大幅な性能向上を実現している。
特に注目したいのは価格だ。導入価格として入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格の半額にあたる。
本記事では、ソフトウェアエンジニアリング、Web開発、知識処理の各ベンチマークを掘り下げつつ、エージェント開発者にとって何が変わるのかを具体的に解説する。
Gemini 3.7 Flashの概要と位置付け
Gemini 3.7 Flashは「Flashシリーズ史上もっとも知的な作業用モデル」という位置付けで投入された。3.6 Flashの発表からわずか3週間という短期間での後継モデル登場は異例の速さだが、Google DeepMindによればこれは開発者からのフィードバックとアルゴリズムの革新的な改善によるものだという。
モデル名の「Flash」は、大規模モデルと比べて応答速度を重視した軽量版という意味を持つ。処理速度を保ちながら推論能力を高めるのがFlashシリーズの設計思想で、3.7 Flashはそのバランスを一段階引き上げている。
改善領域はソフトウェアエンジニアリング、ナレッジワーク、Web開発ワークフローの3つに大別される。単にベンチマーク数値が上がっただけでなく、実務のワークフローに組み込んだ際の体感品質が向上している点が特徴的だ。
コーディング性能の飛躍的向上
ソフトウェアエンジニアリングのベンチマーク
デバッグやイシュー解決などのコーディングタスクで、3.7 Flashは3.6 Flashに対して明確な差をつけた。フロンティアコードと呼ばれる本番品質のコード生成ベンチマークでは43.6%を記録し、3.6 Flashの34.4%から約9ポイント向上している。
長期にわたるソフトウェアエンジニアリングタスクを測るDeepSWE v1.1でも、65.3%と3.6 Flashの49.0%から16ポイント以上の伸びを示した。初回のコード精度が上がったことで、修正のための再試行が減り、開発サイクル全体の効率が改善する。
このデモでは2つのベンチマークを比較している。FrontierCodeとDeepSWEのいずれも、3.7 Flashは3.6 Flashを大きく上回る結果を示している。
Web開発とUI生成の実力
Web開発では、より機能的なレイアウトと完成度の高いアプリを少ないプロンプト数で生成できるようになった。UI生成では、スクリーンショット、画像、デザインシステムのいずれを参照として与えた場合でも、高いデザイン忠実度を発揮する。
Arena.aiのWebDev Arenaというベンチマークでは、Eloスコア1588を記録し、3.6 Flashの1538から50ポイント上回った。Eloスコアとはチェスなどで使われる相対評価の指標で、数値が高いほど他のプレイヤーとの対戦で勝率が高いことを意味する。
実際のユースケースとしては、シンプルなテキストプロンプトからプレイ可能な3Dゲームを動的生成するデモや、パララックス効果を使ったインタラクティブなランディングページを一発生成するデモが紹介されている。副次的なエージェントをオーケストレーションする能力も備えており、複数コンポーネントを連携させたUI構築が可能になった。
知識集約分野での大幅改善
複雑文書処理の進化
金融、法律、バイオサイエンスなど、専門知識が求められる分野でも3.7 Flashは大幅な改善を見せた。複雑なPDF文書を処理する能力を測るGDP.pdfベンチマークでは34.0%を記録し、3.6 Flashの22.0%から12ポイント向上している。
この改善は、静的なPDFをインタラクティブなデータストーリーに変換するというデモで具体的に示されている。複雑な年次報告書を、ライブチャートや集計済みの洞察を含むWeb体験に変換できるというものだ。単なるテキスト抽出を超え、文書構造の理解と再構築が可能になっている。
業務自動化ワークフロー
実世界のビジネスワークフローを完遂する能力を測るAutomationBenchでは、30.4%を記録し、3.6 Flashの17.0%を大きく上回った。この数値は、複数のアプリケーションやデータソースをまたいだ業務フローを、どれだけ正確に遂行できるかを示す指標だ。
このステップ図は、3.7 Flashが複数ツールを連携させて実業務を自動化する流れを示している。分解したタスクを順番に実行し、最終成果物までまとめ上げる自律性が向上した。
価格改定と開発者体験の改善
導入価格の詳細
3.7 Flashの導入価格は、入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格と比較して半額である。年内いっぱいこの価格が適用される。
価格が半額になったことと性能向上が組み合わさることで、本番環境でのエージェントを大規模に展開する際のコスト効率が大きく改善する。特に出力トークンの価格引き下げは、長い推論を必要とするエージェント用途で効果を発揮する。
エージェントワークフローへの適合
3.7 Flashは開発者体験の面でも改善されている。障害に遭遇した際の適応力が高まり、必要に応じて意図を明確化するための質問を行う。指示への忠実度も向上した。複数ステップの計画立案とツール呼び出しに、より多くの推論リソースを費やすようになったことで、手動の監視や再試行が減る。
この「規律のある実行」は、エージェントワークフローにおいて重要な意味を持つ。エージェントが途中で誤った判断をして軌道修正が必要になる回数が減れば、開発者の介入コストが削減され、自動化の信頼性が高まるからだ。
Gemini Sparkとの統合と安全性
Sparkへの適用
Google AI ProおよびUltraプランの加入者が利用できるパーソナルAIエージェント「Gemini Spark」は、8月13日からGemini 3.7 Flashを基盤モデルとして使用するようになった。SparkはGoogle I/Oで発表された24時間稼働の個人向けエージェントで、ユーザーの指示のもとで自律的にタスクを実行する。
今回のモデル更新により、Sparkはファイルの整理、メールの下書き、ステータス文書の更新などの知識作業をより効率的にこなせるようになった。Google Workspaceアプリとの連携も改善され、複数のスキルを組み合わせた複雑なワークフローの精度が向上している。
安全対策の強化
3.7 Flashは、化学・生物・放射線・核（CBRN）分野およびサイバー攻撃分野における悪用を防ぐための最新の安全対策を備えて出荷される。Google DeepMindのフロンティアセーフティの枠組みに基づき、有益なユースケースを維持しながら悪用リスクを低減する設計になっている。
モデルの詳細な安全性情報や性能データは、公開されているモデルカードで確認できる。エンタープライズ環境で導入を検討する際には、このモデルカードを確認しておくとよい。
利用方法と提供チャネル
3.7 Flashはすでに複数の経路で利用可能だ。開発者はGoogle Antigravityでエージェントファーストのワークフローを試せるほか、Google AI StudioからGemini APIを直接呼び出すことができる。Androidアプリ開発者はAndroid Studioからもアクセス可能だ。
エンタープライズ向けには、Gemini Enterprise Agent PlatformとGemini Enterpriseアプリで提供される。個人ユーザーはGeminiアプリ内のSparkを通じて利用できる。対応国や地域の詳細はGoogleのサポートページに掲載されている。
この記事のポイント
- Gemini 3.7 Flashは3.6 Flashからわずか3週間で登場した後継モデル
- コーディングの初回精度が大幅に向上し、再試行コストを削減できる
- Web開発では少ないプロンプト数で機能的なUIを生成可能
- 導入価格は3.6 Flash当初価格の半額に設定され、年内いっぱい適用
- Gemini Sparkの基盤モデルとしても即日採用された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1正式版が8月19日リリース。レスポンシブスタイルと疑似状態の全容
WordPress 7.1の正式版が2026年8月19日にリリースされる。WordCamp US最終日と重なるタイミングで、すでにRC1とRC2が公開され、機能セットは確定済みだ。先月にはセキュリティリリース2件も出ており、影響を受けるサイトは自動更新が強制された。
今回のアップデートで注目が大きいのは、レスポンシブブロックスタイルと疑似状態スタイルのコア導入だ。テーマ開発者はモバイルとタブレットの表示をtheme.jsonだけで制御できるようになる。プラグイン開発者もリストテーブルの構造変更に注意が必要だ。正式版まで残り数日、互換性確認のポイントを解説する。
WordPress 7.1は8月19日リリース、RC2まで公開済み
正式版はWordCamp US最終日に到着
WordPress 7.1は8月19日にリリース予定だ。ちょうど8月16日から19日にかけて米国フェニックスで開催されるWordCamp USの最終日と重なる。年次フラッグシップイベントの最終日に正式版が出るのは珍しいスケジュールで、現地参加者はその瞬間をライブで目撃できる。
先週までにRC1とRC2が立て続けに公開された。RC（Release Candidate / リリース候補版）とは、正式版の一歩手前の段階だ。ここまで来ると新機能の追加は終了し、バグ修正だけが行われる。Field Guideも公開済みで、全機能の開発者向け詳細がまとまっている。
セキュリティリリース2件、強制自動更新も発動
先月はセキュリティリリースが2件公開された。7月17日に出たWordPress 7.0.2は、重大な脆弱性1件と高深刻度の脆弱性1件に対処したものだ。深刻度が高かったため、影響を受けるバージョンのサイトには強制自動更新が適用された。続いて8月6日には7.0.3が公開され、十数件の追加修正が入っている。
管理しているサイトが両方の自動更新を何らかの理由で逃していた場合、先にそちらの更新を済ませることが最優先になる。7.1のテストはその後でかまわない。
レスポンシブスタイルがコアに登場
上記の図は、theme.jsonでデスクトップ・タブレット・モバイルのパディングを切り替える様子を視覚化したものだ。実際には端末の画面幅に応じて、この3つの状態が自動的に切り替わる。
theme.jsonでモバイルとタブレットのスタイルを定義
春先から開発が進められていたレスポンシブスタイルが、WordPress 7.1で正式にコアに導入された。ブロックのスタイルをタブレットとモバイルのビューポートごとに定義できる。Global Styles（グローバルスタイル）ではブロックタイプ単位で、個別のブロック単位でも設定可能だ。theme.jsonでは@mobileと@tabletというキーの中にネストして記述する。
ここで押さえておきたいのは、@desktopキーが存在しない点だ。ブロックのデフォルトスタイルがそのままデスクトップスタイルになる。モバイルやタブレットで上書きしなかったプロパティは、すべてのビューポートでデフォルト値が適用される。
さらにテーマ側でブレークポイントを設定できる。theme.jsonのトップレベルにsettings.viewportプロパティを追加する仕組みだ。デフォルトはモバイルが480px、タブレットが782px。値はpx、em、remの非負の長さのみ許可され、CSS関数やパーセント、単位なしの値は無視される。タブレット値がモバイル値と同じか小さい場合は、モバイルのみが使われる。
標準ブロックサポートを使っているブロックは、タイポグラフィ、カラー、背景、ボーダー、寸法、スペーシング、レイアウトが自動的に対応する。逆に独自のスタイルコントロールを持つブロックは対象外だ。自作ブロックがある場合、この線引きで対応有無を確認してほしい。
疑似状態スタイルでホバーやフォーカスを制御
ホバーやフォーカスは実際の操作で状態が変わるため、上記は4つの状態を並べて示したものだ。実際の編集画面では「Hover」タブを選んでスタイルを設定する。
かねてから要望の多かった疑似状態スタイルも7.1で実装された。:hover、:focus、:focus-visible、:activeをtheme.jsonとエディタで定義できる。現時点ではButtonブロックとNavigation Linkブロックに限定されている。
さらに初期段階のカスタムステート機能も入った。現状はtheme.jsonのみで、管理画面のUIはまだない。Navigation Linkブロックが現在のメニュー項目をスタイルするために-currentプロパティを使う仕組みだ。カスタムステートは-接頭辞を使い、ブロックのblock.jsonにあるselectors.statesプロパティで宣言したクラス名をターゲットにCSSを生成する。現時点では限定的だが、今後の拡張に向けた重要な布石だ。
新しいデザインツール3点
テーマ開発者が長年待っていた変更を含む、デザインツールの追加が3つある。グラデーションと背景画像を同時に使えるようになるのは特に大きい。
背景グラデーションと背景画像を併用可能に
新しいbackground.gradientは既存のcolor.gradientとは別のサポートとして追加された。違いはCSSの出力先にある。従来のサポートはbackgroundショートハンドを通じて描画されるため、background-imageを含むすべてのbackground関連プロパティをリセットしてしまっていた。ブロックにグラデーションか画像のどちらか一方しか使えなかった理由だ。
新しいサポートはbackground-imageロングハンドで描画される。スタイルエンジンが1つの宣言内にグラデーションと画像をカンマ区切りで出力できるようになった。7.1ではGroup、Accordion、Pullquote、Post Content、Quoteがコアで対応する。値はstyle.background.gradientに保存される。
最小幅とテキストシャドウ
dimensions.minWidthは既存のminHeightと同じパターンで、CSSのmin-widthとして適用される。テーマがdimensionSizesプリセットを提供していれば、それを活用できる。1点注意があり、この設定はデフォルトではブロックインスペクターに表示されない。ブロック側で__experimentalDefaultControlsを通じてopt-inした場合のみ表示される。Global Stylesではデフォルトで表示される。
テキストシャドウもGlobal Stylesでサポートされた。これまでは個別ブロックやCSSでしか指定できなかったが、theme.jsonからサイト全体またはブロックタイプ単位で制御できる。
SVG Icon APIが正式公開
アイコン名の衝突を防ぐため、コレクション名が名前空間の接頭辞になる。プラグイン独自のアイコンを登録しても、コアのアイコンと混同される心配がない。
WordPress 7.0でエディタとIconブロック向けにSVGアイコンのセットが同梱された。7.1ではこれが正式な公開APIになり、プラグインやテーマから登録できるようになった。wp_register_icon_collection()でコレクションを登録し、wp_register_icon()でアイコンを追加する。PHPの任意の場所でwp_get_icon()を使えば、サイズやクラス、ラベルを指定してアイコンを表示できる。
計画時に意識したい制限が2つある。登録したSVGはwp_ksesによって保守的な許可リストでサニタイズされる。許可されるのは<svg>、<path>、<polygon>のみ。許可リストの拡大作業は進行中だ。fillは図形部分にのみ許可され、外側の<svg>には付けられない。またwp_get_icon()単体で呼び出すとSVG自身のfill（黒）で描画される。周囲のテキスト色に合わせたい場合は、渡したクラスに対して自前でCSSを指定するのが推奨される。
エディタのiframe化とプラグインへの影響
投稿エディタは常時iframe表示へ
テンプレートエディタがiframe化されたのはWordPress 5.8からだ。それ以来、投稿エディタも段階的に移行してきたが、7.1で最終段階に入った。テーマの種類や登録ブロックのAPIバージョン、コンテンツ内のブロックのAPIバージョンに関係なく、投稿エディタは常にiframeで表示される。レガシーメタボックスを登録しているサイトも同様だ。
7.0では投稿ごとに挿入されたブロックに基づいて判断されていた。つまりコンテンツによってiframedモードと非iframedモードが切り替わり得た。この条件付き動作がなくなり、挙動が単純化された。
大半のブロックは変更なしで動作する。問題が起きる場合、ほとんどは1つの根本原因にたどり着く。iframeは管理者ページとは別のdocumentとwindowを持つ。エディタスクリプトが実行される管理者ページからグローバルのdocumentやwindowにアクセスしてキャンバスを操作しようとすると、間違ったドキュメントを見ていることになる。対処としては、キャンバス内の要素からownerDocumentとdefaultViewでドキュメントを取得するか、useRefEffectでキャンバス要素にリスナーをアタッチ・クリーンアップするのが一般的だ。
リストテーブルの行ヘッダーが移動
カスタムCSSやJavaScriptを書いているプラグインにとって、静かに何かを壊す可能性が高いのがリストテーブルの変更だ。投稿一覧テーブルで、プライマリのth scope="row"がチェックボックス列からタイトル列に移動した。チェックボックスセルはtdになり、タイトルセルがthとして投稿タイトルを含むaria-labelを持つ。レスポンシブ表示で折りたたまれるセルはflexレイアウトを使うようになった。
これはアクセシビリティの大きな改善だ。スクリーンリーダーは各行を、場合によっては存在しないチェックボックスではなく投稿名で認識できるようになる。ただしこのマークアップは2010年以降ほぼ安定していたため、多くの拡張が暗黙的に依存している。th.check-columnを選択するCSSやJavaScript、td内の行アクションや投稿タイトルを期待するコードがある場合は確認が必要だ。
この記事のポイント
- WordPress 7.1は8月19日リリース予定、RC2まで公開済みで機能セットは確定
- セキュリティリリース7.0.2と7.0.3が先月公開され、強制自動更新も適用された
- レスポンシブスタイルがコアに入り、モバイルとタブレットのスタイルをtheme.jsonで定義可能に
- 疑似状態スタイルでホバー、フォーカス、アクティブをテーマから制御できる
- SVG Icon APIが公開され、プラグインが名前空間付きでアイコンを登録可能に
- 投稿エディタは常時iframe化され、リストテーブルの行ヘッダー移動も要確認
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google広告が検索キャンペーンの言語ターゲティング設定を廃止。9月下旬から順次適用
Google広告が2026年9月下旬から、検索キャンペーンとP-MAX（パフォーマンスマックス）の検索枠におけるキャンペーンレベルの言語ターゲティング設定を廃止する。広告文とランディングページの言語が配信判断の主な基準となり、GoogleのAIによる言語理解がより大きな役割を担う。
この変更により、多言語キャンペーンの運用方法が変わる。既存キャンペーンの再構築は不要だが、規制業界の広告主には配信実績の文書化という未解決の課題が残る。
本記事では、言語ターゲティング廃止の具体的な内容、Googleの判定ロジック、広告主が取るべき対応を解説する。
言語ターゲティングで何が変わるのか
現行の仕組みと変更後
現在のGoogle広告では、キャンペーン設定で広告主が1つ以上の言語を選択する仕組みだ。同時にGoogleは検索クエリ、ユーザー設定、その他のAI由来のシグナルを基に、ユーザーが理解する言語を独自に判定している。この2つの条件が重なったときにだけ検索広告が配信される。
9月下旬以降、キャンペーンレベルの言語設定が検索キャンペーンから削除される。代わりにGoogleは広告クリエイティブとランディングページの言語、およびユーザーの理解言語に関する既存のAI判断を組み合わせて配信を決定する。
この変更により、キャンペーン設定で言語を指定する手間がなくなる。広告文とランディングページの言語がそのまま配信基準として機能するようになるのだ。
P-MAXへの影響範囲
P-MAX（パフォーマンスマックス）では、この変更の影響を受けるのは検索枠のみ。検索以外のチャネルではキャンペーンレベルの言語設定が引き続き使用される。つまりP-MAX全体が変わるわけではなく、Google検索に表示される部分だけが対象になる。
複数言語ユーザーへの広告配信ロジック
変更後の大きなポイントは、複数言語を理解するユーザーへの配信方法だ。英語とスペイン語の両方を理解するユーザーには、どちらの言語の広告も配信される可能性がある。GoogleのAIが広告グループ単位で優先順位付けを行い、検索に対して最適な言語を選ぶ。
検索クエリに明確な言語がある場合は、その言語の広告とランディングページが優先される。たとえばスペイン語で検索したユーザーには、スペイン語の広告が優先的に表示される仕組みだ。
Googleはクエリの言語だけでなく、ユーザー設定や過去の行動など複数のシグナルを組み合わせて最適な言語を選ぶ。複数言語を理解するユーザーに対しては、AIが広告グループ単位でより適切な言語を優先する仕組みだ。
ブランド検索における言語判断
ブランド検索では状況が少し複雑になる。ブランド名が複数言語で同一であることが多く、クエリ自体から言語を判断する手がかりが少ないからだ。たとえば「Nike」というブランド名は英語でもスペイン語でも同じ表記になる。
このような場合、Googleはクエリ以外の言語シグナルに依存し、ユーザーの優先言語を重視する。日常的に英語とスペイン語の両方で検索するユーザーには、どちらの言語の広告も配信対象になり得る。
Googleはこの変更が、キャンペーン設定による意図しないトラフィック制限を減らすとも説明している。たとえば英語でターゲティングしたキャンペーンにスペイン語の広告文やランディングページが含まれる場合、従来はキャンペーン設定がブロック役を果たしていた。今後はGoogleの言語理解に委ねられ、関連トラフィックを取りこぼしにくくなる見込みだ。
広告主が懸念する規制対応とAI生成クリエイティブ
規制業界の配信実績の文書化
発表前に行われたバーチャルラウンドテーブルでは、広告主からいくつかの質問が寄せられた。特に規制対象業界の広告主は、コンプライアンスに関する懸念を示した。
保険業界の広告主を例にとると、英語話者とスペイン語話者の両方に広告が公平に届いていることを文書で示さなければならない場合がある。Googleは両言語で広告を提供していれば、両方のグループにリーチする意図があると判断されると説明した。
ただし、ラウンドテーブルで出た質問は意図の話だけにとどまらなかった。キャンペーン設定ではなくGoogleの自動判定が言語ごとの配信を決めるようになった場合、広告主がどのように配信実績を証明するかという点は未解決のままだ。Googleは言語別の配信状況やパフォーマンスの差を確認できる追加のレポート機能を発表していない。
AI Maxと自動生成クリエイティブ
P-MAXと自動生成クリエイティブに関しても質問があった。ケベック州をターゲットにしたAI Maxキャンペーンで、AIがフランス語のクリエイティブを生成した場合、英語で検索するユーザーにそのフランス語広告が表示される可能性はあるのか。Googleは「可能性がある」と回答した。
クリエイティブの生成が先に行われ、その後Googleが利用可能な広告とランディングページをユーザーが理解できるかをチェックする。クエリの言語と広告の言語が一致していなくても、ユーザーが理解できると判断されれば配信される仕組みだ。
検索クエリの言語と広告の言語は必ずしも一致する必要がない。Googleがユーザーの理解言語を判断し、優先順位付けシステムが最適なクリエイティブを選ぶためだ。
広告主が取るべき具体的な対応
既存キャンペーン構造の扱い
大多数の広告主にとって、この変更は大きな影響を及ぼさない。Googleも既存キャンペーンの再構築は不要だと明言している。言語別にキャンペーンを分けている場合も、そのままの構造を維持してよい。言語設定が検索からなくなったからといって、キャンペーンを統合する必要はない。
注意が必要なのは、言語ターゲティングを本来の目的以外に使っていたケースだ。旅行、国際展開、規制対象などの業界では、言語設定がオーディエンスの絞り込みやコンプライアンス要件に影響していることがある。
Google広告APIを利用する広告主は、検索キャンペーンの作成・更新時に言語条件を送信するのをやめることが推奨されている。既存の言語条件は残っても構わないが、検索ターゲティングには影響しなくなる。
適用後に監視すべき指標
具体的には、広告文とランディングページが意図した言語で書かれているか確認するべきだ。特に多言語キャンペーンやAI生成アセットを利用する場合は注意が必要。Googleが広告文とランディングページの言語を基準にするため、これらの言語が正確に設定されていないと配信に影響する。
変更が適用された後は、検索語句や地理的トラフィックの変化、流入ユーザーの言語属性などを確認し、パフォーマンスを監視する。国際展開や多言語運用を行う広告主は、特にこれらの指標に注意を払う必要がある。
パフォーマンスと流入ユーザーの構成がおおむね安定していれば、Googleの主張どおり言語設定が実質的に重複していたと言える。一方、言語設定を追加のオーディエンス制御層として使っていたケースでは、適用後の変化を見極めるのに時間がかかるかもしれない。
この記事のポイント
- Google広告が検索キャンペーンとP-MAXの検索枠からキャンペーンレベルの言語ターゲティング設定を廃止する
- 変更は2026年9月下旬から順次適用され、広告文とランディングページの言語が配信判断の主な基準になる
- 既存キャンペーンの再構築は不要で、言語別に分けている場合もそのまま維持できる
- 規制業界では配信実績の文書化について未解決の課題が残る
- P-MAXでは検索以外のチャネルでキャンペーンレベルの言語設定が引き続き使われる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPT広告に製品カルーセルとAppsFlyer統合、EC向けパフォーマンス広告の基盤が加速
OpenAIがChatGPT上の広告に製品カルーセルを導入し、モバイルアプリ向けの計測基盤としてAppsFlyerとの連携を発表した。8月10日、マーケティングテクノロジー専門メディアMarTechが報じた内容だ。
小規模ECや個人事業主にもなじみ深いWooCommerceを使ったサイト運営をする事業者にとって、これらのアップデートはChatGPTをパフォーマンス広告のチャネルとして考えるきっかけになる。製品フィードから自動生成されるカルーセル、アプリインストールや購入のコンバージョンを計測できる仕組みがいよいよ揃ってきたからだ。
製品フィードがカルーセル広告に進化
ChatGPT広告はこれまで、会話の下に1つの商品が表示されるだけのシンプルな形式だった。しかしOpenAIは約3カ月前にリリースした自動製品フィード機能を拡張し、同一広告内に複数の商品をカルーセル形式で並べる表示パターンを加えた。広告主が商品カタログを提供すると、OpenAIのシステムが単品表示かカルーセルかを自動で判断して表示する。
広告表示の自動最適化
広告のフォーマットは広告主が選べず、OpenAIが会話の文脈やユーザーの傾向を見て決める。カルーセルには現在、同一店舗・ブランドの商品が並ぶ仕様だ。広告主がコントロールできるのは、製品フィードに載せるデータの質と量だけという設計になっている。
これは一見すると広告主にとって不自由に映る。しかし、AIが最適な表示を選ぶことで、ユーザー体験を損なわずに商品訴求のバリエーションを増やせる利点がある。たとえば初めてそのブランドを知るユーザーには複数商品を見せるほうが有効だし、具体的な商品を質問してきたユーザーには1点に絞るような制御が期待される。
ChatGPT会話の下部に表示される広告エリアで、こうしたカルーセルがスワイプ操作によって商品を切り替えられるイメージだ。実際の表示は広告枠のサイズや文脈に応じて変化し、1商品の場合もある。
WooCommerceとの親和性
OpenAIの製品フィードは、Google Merchant CenterやFacebookカタログに似た仕組みで、オンラインストアの商品データを取り込む。WooCommerceを使うEC事業者なら、既存の商品フィード作成プラグイン（Google Product Feed、CTX Feedなど）を活用し、ChatGPT用にデータを整形するルートが考えられる。
現時点では公式のWooCommerce専用プラグインは存在しないものの、商品名・画像・価格・在庫状況を含むCSVやAPI経由でのアップロードが可能になれば、Shopifyストアと同様に少ない手間で連携できる見込みだ。広告フォーマットの自動選択をOpenAIに任せるため、広告主の運用負荷を下げつつ、商品露出の機会を増やすことができる。
AppsFlyer統合でアプリコンバージョン計測が可能に
OpenAIはモバイル計測プラットフォームのAppsFlyerと提携し、ChatGPT広告経由のアプリインストール、アプリ内課金、サブスクリプション契約を計測できるようにした。Adweekの報道によると、Grubhubを含む約40ブランドがテストに参加している。
アプリマーケターに新たな計測チャネル
アプリプロモーションを行う企業は、ChatGPTを他の有料チャネルと同じ指標で比較できるようになった。AppsFlyerのダッシュボード上で「ChatGPT」というメディアソースが追加され、クリックからインストール、初回購入までのアトリビューションデータが取得できる。これまで実験的な位置づけだったChatGPT広告が、ROAS（広告費用対効果）を測定できる本格的なパフォーマンスチャネルに近づいたといえる。
EC事業者への波及効果はこれから
この統合は現時点でアプリ内のコンバージョンに特化しており、Webストアの購入や会員登録を直接計測する機能は含まれていない。WooCommerceを中心に据えた純粋なWeb EC事業者にとっては、すぐに使えるソリューションとは言い難い。
しかし、OpenAIがアドテクノロジーへの投資を加速させている流れからすると、将来的にWebピクセルやサーバー間連携によるウェブコンバージョン計測が追加される可能性は高い。アプリとWebの両方を持つビジネスであれば、ChatGPT広告をアプリ向けの獲得経路として試験的に活用しつつ、今後の拡張に備えるのが現実的な一手だ。
パフォーマンス広告システムとしての基盤が整う
製品フィード、自動カルーセル表示、サードパーティによるアトリビューション。この3要素が揃ったことで、ChatGPT広告は「何を表示し、どんな成果があったか」を一気通貫で管理できるパフォーマンス広告のインフラを手にした。MarTechの記事は、OpenAIが第4四半期とホリデー商戦に向けて、フィードベースのキャンペーンに関する広告主向けガイダンスを強化しているとも伝えている。
広告主のコントロール不足が課題
カルーセル表示の可否をOpenAIが決める設計は、広告主にとって不確実性を生む。どのような条件で単品と複数品を使い分けるのか、各フォーマットのパフォーマンスに差があるのか、透明性はまだ十分とは言えない。
広告テストを進める段階で、自分たちの商品が適切に露出されているかを検証しづらいのは痛手だ。OpenAIが今後、キャンペーン管理画面で表示ロジックの詳細を開示するかどうかが、広告主の予算拡大を左右するポイントになる。
スケール面の未知数
カルーセルや計測が整備されたことは、ChatGPT広告のテストを容易にする。しかし、それが「競争力のあるCPA（顧客獲得単価）で十分なコンバージョン量を継続的に生み出せるか」は別の問題だ。
ChatGPTのユーザー数は巨大だが、検索連動型広告やソーシャルメディア広告と比較した場合、購買意欲の高いユーザーにリーチできるかは未知数だ。WooCommerceサイトの運営者は、他の広告チャネルと同様に、CPAと獲得数のバランスを見ながらChatGPT広告の出稿判断を下すことになる。
この記事のポイント
- ChatGPT広告に製品カルーセルが導入され、1広告で複数商品を表示できるようになった。
- AppsFlyerとの提携により、アプリインストールやアプリ内購入のアトリビューションが可能になった。
- 製品フィード、自動表示、計測というパフォーマンス広告の基本インフラが揃ったが、広告主の表示制御やスケール面の課題は残る。
- WooCommerceなどのECプラットフォームでも、商品フィード連携を通じてChatGPT広告を活用する道が開かれている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WPForms Liteにバックドア疑惑、セットアップウィザードが管理者権限を外部に渡す仕組み
WordPressプラグイン「WPForms Lite」にバックドアが仕込まれているという疑惑が、2026年8月にX（旧Twitter）上で提起された。発端はSEOプラグイン「The SEO Framework」の開発者Sybre Waaijer氏の投稿だ。同氏はWPForms Liteのバージョン2.0.0に含まれるセットアップウィザードが、1時間有効の管理者トークンを外部に渡し、ユーザーのサイトにプラグインをインストールできる状態を作り出していると指摘した。
Search Engine Journalの著者Roger Montti氏が実際にWPForms Liteをインストールしてテストしたところ、セットアップウィザードがユーザーを外部サイトに誘導し、気づかぬうちに追加プラグインのインストールを強制するという実態が明らかになった。この記事では疑惑の内容、テスト結果、そしてこれが本当にバックドアと呼べるのかを検証する。
WPForms Liteにバックドア疑惑、発端はThe SEO Framework開発者の投稿
2026年8月、Sybre Waaijer氏がX上でWPForms Liteにバックドアが仕込まれていると投稿した。WPForms LiteはAwesome Motive社が開発する無料のフォーム作成プラグインで、500万以上のサイトにインストールされている。Waaijer氏は、バージョン2.0.0で追加されたセットアップウィザードが、管理者権限を持つ1時間有効のトークンを発行し、Awesome Motiveのサーバーに渡す仕組みになっていると指摘した。
問題となったコードは「wpforms-lite/src/SetupWizard/Bridge.php」というファイルに含まれているという。セットアップウィザードを起動すると、ユーザーのブラウザはWPFormsの外部サイトにリダイレクトされ、そこで管理者トークンが発行される。このトークンを使ってAwesome Motive側は、ユーザーに代わってプラグインのインストールや有効化、さらにはフォームの送信データを自社サーバーに送る設定の有効化まで可能になるとされる。
この概念図はWaaijer氏の主張を簡略化したものだ。ユーザーがセットアップを進めると、知らないうちに自サイトの管理者権限が外部に渡り、プラグインが追加される流れになる。
インストール可能なプラグインの一覧
Waaijer氏の投稿によると、この仕組みでインストール可能なプラグインは以下の13種類だ。驚くべきことに、競合するコンタクトフォームプラグインであるContact Form 7やNinja Forms、Pirate Formsも含まれており、同氏はこれを「おそらくバグ」と指摘している。
- WP Mail SMTP
- WPConsent
- Uncanny Automator
- AIOSEO（All In One SEO）
- Universally
- Duplicator
- Reviews Feed
- OptinMonster
- MonsterInsights
- ActiveLayer
- Contact Form 7（競合プラグイン、バグの可能性）
- Ninja Forms（競合プラグイン、バグの可能性）
- Pirate Forms（競合プラグイン、バグの可能性）
また、WPFormsのアドオンやPro版を自社サーバーから直接プルすることも可能で、これらのサーバーはWordPress.orgのモデレーションを受けないため、悪意あるコードをプッシュするリスクもあるとWaaijer氏は警告している。
コミュニティからの反論とWaaijer氏の立場
Waaijer氏の投稿に対して、WordPressコミュニティからは「Awesome Motiveは10年にわたり信頼されてきたプラグイン開発者であり、公に非難するのは不公平だ」という意見が上がった。ユーザー@BuildInBitsは「これは非公開で議論すべき内容であり、公開で非難するのは行き過ぎだ」と投稿している。
しかしWaaijer氏は、Awesome Motiveが自らの競合であると明かした。同氏が開発するThe SEO Frameworkは、Awesome Motiveが提供するAll In One SEO（AIOSEO）と直接競合するSEOプラグインだ。Waaijer氏は「彼らは意図的に管理者権限の第二チャネルを構築し、オープンソースに見せかけている。WPBeginnerは10年以上にわたり、チュートリアルの最終着地点が常に自社スタックに誘導するファネルだった」と批判している。
本当にバックドアなのか、異論も
一方で、Waaijer氏の「バックドア」という表現に対しては異論も出ている。Xユーザー@marckranatは「これは従来の意味でのバックドアではない。ベンダーが自発的にアクセスを開始する経路はなく、認証バイパスも隠しリスナーも存在しない。ログインした管理者がウィザードを起動する必要がある」と指摘した。
米国立標準技術研究所（NIST）の定義によれば、バックドアとは「コンピューターシステムにアクセスするための文書化されていない手段」であり、セキュリティリスクになり得るものだ。しかしWPForms Liteのケースでは、管理者が自らセットアップウィザードを起動しなければ外部からの操作は始まらない。つまり、外部から一方的に侵入される経路が存在するわけではないという視点も成り立つ。
この比較からわかるように、WPForms Liteの仕組みは厳密な意味でのバックドアとは異なる。しかし管理者が認識しないまま外部に権限を渡す点は、透明性の観点で問題があると指摘されている。
Search Engine Journal著者が実際にテスト、セットアップウィザードの実態
Search Engine JournalのRoger Montti氏は、この疑惑を検証するためWPForms Liteを実際にインストールした。Montti氏はすでに別のサイトで同プラグインを使用していたが、テスト用のサイトに新規インストールしたところ、セットアップウィザードが表示されたという。
注目すべきは、セットアップウィザードの最初の画面がすでにWPFormsの外部サイト（wpformsapi.com）に切り替わっていた点だ。Montti氏は「自分のサイトにいると思っていたが、すでに別のサイトに移動していた」と述べている。URLバーを注意深く見ていなければ、気づかないレベルの遷移だったという。
Montti氏が実際に体験したセットアップの流れは上図のとおりだ。同氏は「Install and Continue」をクリックしてしまったが、これが自サイト内の操作だと信じていたと振り返っている。
2つのプラグインが強制インストール、オプトアウト不可
セットアップウィザードの途中には「Select Your Features」という画面が表示され、「AI Form Generation」と「Privacy Compliance」のチェックボックスが最初からオンになっており、外せない状態だった。さらに画面下部には、無料の「WPConsent」プラグインがインストールされる旨の通知があり、これも拒否できなかった。
結果として、Montti氏のテストサイトにはWP Mail SMTP、WPConsent、そしてWPForms Liteの3つのプラグインがインストールされた。同氏はその後プラグインをアンインストールし、同じワークフローを再現しようとしたが、2回目以降は発生しなかったという。
バックドア疑惑の本質とWordPressサイト運営者が取るべき対応
WPForms Liteのセットアップウィザードが外部サイトに誘導し、管理者トークンを発行して他プラグインをインストールする仕組みは、Montti氏のテストでも確認された。これは「密かに不正アクセスを可能にする」典型的なバックドアとは異なるが、管理者が認識しないままサイトの変更を許す点で、透明性に問題がある。
NISTの定義に照らせば「文書化されていない手段」には該当し得る。しかし実際にはセットアップウィザードの一部として動作し、管理者がトリガーを引く必要があるため、「バックドア」という表現は強すぎるという見方もある。とはいえ、ユーザーが外部サイトに移動したことに気づかないまま、プラグインが追加される体験は、セキュリティ意識の高いサイト運営者にとって懸念材料だ。
この問題の核心は「バックドアかどうか」の定義論争よりも、プラグインのセットアッププロセスにおける透明性の欠如にある。500万以上のサイトに影響を与え得る仕様だけに、開発者側の説明責任が問われている。
この記事のポイント
- WPForms Lite 2.0.0のセットアップウィザードが、外部サイトで管理者トークンを発行し、ユーザーに無断でプラグインをインストールできる状態を作る
- Search Engine Journalのテストで、WP Mail SMTPとWPConsentが強制インストールされ、AI機能もオプトアウト不可だった
- 「バックドア」という表現には異論もあるが、管理者が気づかないまま外部サイトに誘導される点は透明性に問題がある
- サイト運営者はプラグインインストール時のURL確認と、定期的なプラグイン一覧のチェックを習慣化すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ChatGPTが商業クエリの26%に広告表示、関連性に課題も浮上
ChatGPTが商業目的のクエリの約4回に1回の割合で広告を表示していることが、SEOツール企業SE Rankingの調査で明らかになった。表示頻度はGoogleのAIモードに迫る水準だが、広告の関連性や広告主の可視性に課題が残る。
今回の調査は20分野にわたる5万件以上の商業クエリを分析したもので、会話型AI上での広告配信の実態が初めて大規模に可視化された。AI検索時代の新たな広告チャネルとして注目されるChatGPT Adsだが、その仕組みにはGoogle検索とは異なる独自の難しさがある。
商業クエリの約26%で広告が出現、Google AIモードに肉薄
SE Rankingの調査によると、ChatGPTは商業クエリの25.94%でスポンサードプレースメント（広告）を表示した。これは同社が以前調査したGoogle AIモードの29.45%にかなり近い数字だ。AIチャットボットの広告表示率が、従来型検索エンジンのAIモードと肩を並べつつある状況が浮かび上がった。
表示スタイルはシンプル、1クエリに単一広告
広告の表示スタイルは現在のところ非常にクリーンだ。調査で観測されたすべての広告は、生成された回答の下部に表示され、他の広告主と並んで競合することはなかった。1つの回答に対して常に1つのスポンサーオファーのみが表示される。
Googleの検索結果画面とは異なり、ユーザー体験を大きく阻害しない形で広告が統合されている点は注目に値する。ただし、このシンプルさは広告枠の稀少性を意味しており、将来的に入札競争が激化した際にどう変化するかは未知数だ。
広告の関連性に課題、約14%が的外れな表示
ChatGPT Adsの大きな課題として浮上したのが、広告の関連性だ。SE Rankingのセマンティック分析によると、表示された広告の約14.35%が、ユーザーのプロンプトと実質的な関連性を持たなかった。これは7件に1件の割合で、的外れな広告が表示されている計算になる。
カテゴリによるばらつきが顕著
ミスマッチの発生率はカテゴリによって大きく異なる。ペット分野ではわずか2.6%だったのに対し、人間関係やニュース・政治分野では半数以上が無関係な広告だった。特定のトピックでは、会話の文脈を正しく解釈して適切な広告を選ぶことが依然として難しいことがわかる。
実際のミスマッチ例
調査で観測された例では、デートアプリに関するプロンプトに衣料品小売店の広告が表示されたり、新聞の購読を尋ねるクエリに電力会社の広告が出たりといったケースがあった。ユーザーの意図と広告の内容が明らかにずれている。
このようなミスマッチは、広告主にとって広告費の無駄遣いになるだけでなく、ユーザーのAI体験の質を下げる要因にもなる。ChatGPTが広告プラットフォームとして成熟するためには、文脈理解の精度向上が不可欠だ。
従来のキーワードターゲティングとは根本的に異なる仕組み
ミスマッチが起きる背景には、ChatGPT Ads特有のターゲティング方式がある。広告主はキーワードリストではなく、自然言語で書かれた「コンテキストヒント」を提供する。これは「自社の広告を表示したい会話の文脈」を説明するテキストで、厳密なマッチングルールではなく、AIによるゆるやかなマッチングのガイドとして使われる。
加えて、広告主は現在のところ、実際にどのクエリや会話が自社の広告表示をトリガーしたのかを確認できない。これでは不適切なプレースメントが起きても原因を特定しづらく、改善のためのフィードバックループを回すのが難しい。
広告出稿とAI回答でのブランド露出はほぼ無関係
調査の中で特に注目すべき知見は、ChatGPT上で広告を出稿しても、それが生成AIの回答本文にブランドとして登場する確率はほとんど上がらないという点だ。
広告が表示されたクエリのうち、同じブランドが回答の情報源として引用されたケースはわずか3.63%だった。さらに、広告のURLがそのまま引用に現れたのは0.09%にすぎない。ブランド名の言及も4.44%にとどまる。
つまり、ChatGPTに広告費を投下しても、AIが生成するオーガニックな情報として認識される可能性は極めて低い。有料プレースメントとオーガニックなAI可視性は、今のところ完全に分離していると考えてよい。
YMYL分野で目立つ広告表示、Google AIモードとの違い
ChatGPT Adsは、健康やニュースといったYMYL（Your Money or Your Life）分野で、Google AIモードに比べて顕著に多くの広告を表示している。
調査によると、ヘルスケア関連のプロンプトでは28.69%で広告が表示されたのに対し、Google AIモードではわずか2.64%だった。ニュース・政治カテゴリでも同様に、ChatGPTが28.76%、AIモードは6.8%と大きな開きがある。
この差は、ChatGPTの広告セーフガードが緩いことを必ずしも意味しない。むしろ、2つのAIプラットフォームが広告表示に対して異なるポリシーやマッチングモデルを採用している証拠と見るべきだ。広告主は、AI検索チャネルごとにまったく異なる配信傾向があることを前提に戦略を立てる必要がある。
広告主が今おさえておくべきポイントと今後の展望
ChatGPT Adsは急速に成長する有料メディアチャネルだが、Google検索広告と同じ感覚で運用すると期待はずれに終わる可能性が高い。会話型AI上の広告は、キーワードではなくコンテキストに依存するため、精度の高いコンテキストヒントの設計と継続的な実験が欠かせない。
また、どのような会話で広告が表示されたかというレポートの不足は、最適化の足かせとなる。OpenAIが今後、広告主向けにより詳細な分析ダッシュボードを提供するかどうかが、チャネルとしての成熟度を左右するだろう。
さらに、AI検索の世界では、有料広告とオーガニックなブランド認知が直接リンクしない構造が鮮明になった。SEOにおけるブランド構築や被リンク獲得といった従来手法は、AIが回答を生成する時代にも強みを発揮する。広告だけでAI上の可視性を買おうとする発想は現実的ではない。
この記事のポイント
- ChatGPTは商業クエリの約26%で広告を表示し、Google AIモードと同等の水準に達している
- 広告の約14%がクエリと無関係で、会話ターゲティングの精度に課題が残る
- 広告出稿しても、ブランドがAI回答内で情報源として引用される確率は3%程度と低い
- 健康やニュース分野では、ChatGPTの広告表示率がGoogle AIモードより顕著に高い
- 会話型AI広告の最適化には、精密なコンテキストヒント設計と、広告表示ログの透明性が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング
AWSは2026年8月6日、Amazon Bedrock AgentCoreに新たな計算オプション「ランタイムインスタンス」を追加した。AIエージェントのプロトタイプを本番環境に移行する際、長時間の状態維持やマルチエージェント協調、GPUアクセスといった要求に応える、永続的なマネージドインフラだ。
従来のAgentCore Runtimeでは、マイクロVM上で最大8時間のステートフルな呼び出しが可能だったが、日をまたぐワークフローやOSレベルへの直接アクセスが必要なシナリオには限界があった。ランタイムインスタンスは、14日間のセッション永続化とEC2ベースのフルマネージド環境を提供し、本格的なエージェント運用基盤を実現する。
ランタイムインスタンスが解決する本番運用の3つの課題
AIエージェントをプロダクションに投入するとき、開発者はインフラの壁にぶつかる。ランタイムインスタンスはその3つの主要な課題を解消する。
長時間の状態維持とセッション永続化
通常のサーバーレス実行環境では、処理が終わるとメモリやストレージが破棄される。エージェントが数時間〜数日にわたる複数ステップのワークフローを扱う場合、途中結果を外部ストレージに退避させるなどの手間が生まれる。ランタイムインスタンスでは、最大14日間の共有セッションストレージが標準で提供される。セッションは停止・再開が可能で、アイドル期間のコストを抑えながら、必要なときに前回の状態から処理を再開できる。
マルチエージェントの同一ホスト協調
現実の複雑なタスクは、コード生成・レビュー・テスト・デプロイといった複数の専門エージェントが連携して初めて完結する。ランタイムインスタンスでは、複数のエージェントを同一のEC2ホストにデプロイし、共有ファイルシステムを介して直接データをやり取りできる。API呼び出しやネットワーク越しのストレージを挟むオーバーヘッドがなく、シームレスな協調が可能だ。
GPUとOSへの直接アクセス
画像認識や動画解析、重い数値計算を伴うエージェントはGPUを必要とする。ランタイムインスタンスはGPUアクセラレーテッドなインスタンスタイプに対応し、OSレベルへのアクセスも提供する。コードのコンパイル、セキュリティスキャン、GUI自動操作など、コンテナだけでは実現しにくいタスクをエージェントに任せられる。
コードライターとレビュアーの連携を実際に見る
公式デモでは、自然言語でPythonコードを生成する「コードライターエージェント」と、生成されたコードのバグやスタイルをレビューする「コードレビュアーエージェント」を同じランタイムインスタンス上にデプロイし、協調動作させる手順が紹介された。
このデモのポイントは、2つのエージェントが完全に独立したアプリケーションでありながら、セッションIDで紐づく共有ディレクトリを経由してファイルをやり取りする点にある。外部APIを呼び出すことなく、同一ホストのファイルシステム上で完結するため、レイテンシが極めて小さい。
/tmp/agentcore-session/{session_id}/code.py に書き込む各エージェントはStrands Agentsフレームワークと好みのモデル（デモではClaude Sonnet）を使い、単一のPythonファイルに @app.entrypoint デコレータを付けるだけで実装できる。パッケージングもzipまたはコンテナイメージで済み、インフラ管理の負担は大きく軽減される。
セットアップから初回実行までの流れ
ランタイムインスタンスの利用は、大きく3つのステップで完了する。AWSマネジメントコンソールを使う場合の手順を簡潔にまとめた。
- 容量プロバイダの作成 、 エージェントが稼働するEC2インスタンスのスペックとネットワークを定義する。OS（ARM64またはx86_64）、インスタンスタイプ、VPC、サブネット、セキュリティグループを設定。ストレージはgp3ボリュームがデフォルトで用意される。
- ランタイムの作成とエージェントのデプロイ 、 コンピュートタイプに「Instances」を選び、先ほど作成した容量プロバイダを紐づける。エージェントのコードをzipでアップロードし、ランタイム（Python 3.11〜3.14）とエントリポイントを指定。IAMロールもコンソールが自動生成する。
- エージェントの呼び出しと協調 、 デプロイ完了後、コンソールの「Runtime playground」からテスト用のJSONペイロードを送信できる。セッションIDを明示的に指定し、同じIDで別のエージェントを呼び出せば、両者が同一の共有ストレージを使ってシームレスに連携する。
容量プロバイダは一度作成するとOSやインスタンスタイプの変更ができない。本番用と検証用を分けるなど、事前の設計が求められる。
主要スペックと料金モデル
- 対応OS 、 Linux（ARM64、x86_64）。Windowsは現時点ではサポート外
- セッション持続 、 最大14日間。停止・再開が可能で、アイドル中のコスト削減に有効
- ランタイム 、 Python 3.11〜3.14（ネイティブコードに対応）。コンテナイメージのデプロイもサポート
- GPU 、 対応インスタンスタイプを選択すれば、GPUを使った推論や計算が可能
- 統合 、 既存のAgentCore API、IAM、監視機能と完全互換。マイクロVMとのハイブリッド構成も取れる
- 料金 、 使用したEC2インスタンスの標準料金に、AgentCoreオーケストレーションの管理手数料が加算される
- リージョン 、 米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ムンバイ、シンガポール、シドニー、東京）、欧州（フランクフルト、アイルランド）
マイクロVMベースの従来のAgentCore Runtimeとランタイムインスタンスは、同じAPIセットで併用できる。軽量なオーケストレーターエージェントをマイクロVM側に置き、重い処理や永続状態が必要なワーカーエージェントをインスタンス側に委譲するハイブリッド構成が、現実的なアーキテクチャパターンとして紹介されている。
始め方と最初の一歩
ランタイムインスタンスを試すには、Amazon Bedrock AgentCoreのドキュメントに掲載されているランタイムインスタンスの公式ガイドを参照し、容量プロバイダの作成から始めるのが近道だ。コンソールの左ナビゲーションから「Runtime」→「Capacity providers」を選び、今回紹介した手順に沿って設定すれば、最初のエージェントデプロイまで数分で到達できる。
この記事のポイント
- ランタイムインスタンスは、最大14日間のセッション永続化とEC2ベースのマネージド環境を提供するAgentCore新オプション
- 同一ホスト上でのマルチエージェントファイル共有により、APIを介さないシームレスな協調が可能
- GPUインスタンスやOS直接アクセスが必要な高度なエージェントワークロードに対応
- 従来のマイクロVMと組み合わせたハイブリッド構成で、軽量なオーケストレーションと重いバックエンド処理を分離できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験