GPT-5.6 API料金改定、Lunaは80%値下げでTerraも20%減。Fastモード登場
OpenAIは2026年7月30日、大規模言語モデル「GPT-5.6」シリーズのAPI料金を大幅に引き下げた。最速かつ最安価なモデル「Luna」は80%値下げされ、バランス型の「Terra」も20%安くなる。あわせて最上位「Sol」向けにFastモードも導入され、標準処理の最大2.5倍の速度を提供する。
これらの改定は、OpenAIが掲げる「高度な知能をより豊富で手頃なものにする」という目標の実践だ。企業はコストと処理速度をワークフローごとに最適化できるため、AI利用の幅が大きく広がる。
GPT-5.6 LunaとTerraの大幅値下げ
今回の値下げの中心は、高速処理向けのLunaだ。LunaはAPI料金が80%引き下げられ、100万入力トークンあたり0.20ドル、同出力トークンあたり1.20ドルという破格の水準になった。一方、日常的な業務全般に使えるTerraは20%値下げされ、入力トークン100万あたり2ドル、出力は12ドルとなっている。
この値下げによって、Lunaは1タスクあたりのコストが非常に低くなり、大量処理に適したモデルへと進化した。OpenAIのブログによれば、専門的な作業指標で測った場合、同社の旧モデルFable 5と比べてLunaの推定タスク単価は99%近く低いという。小規模事業者が高度なAIを日常的に使うハードルが格段に下がったと言える。
FastモードでSolが最大2.5倍高速化
最上位モデルのGPT-5.6 Solには、新たにFastモードが追加された。これは従来の優先処理（Priority Processing）を置き換えるもので、APIでFastモードを有効にすると、標準処理の最大2.5倍の速度で応答が得られる。価格は標準の2倍だが、知能の質はまったく変わらない。既存の優先処理指定リクエストは自動的にFastモードに移行するため、コードの修正は不要だ。
応答速度が重要な場面、たとえばユーザー向けのリアルタイムチャットボットや緊急度の高い意思決定支援などで効果を発揮する。一方で、コストが2倍になるため、処理の内容に応じて標準モードとの使い分けが鍵になる。OpenAIはこの仕組みによって、企業が「結果に対して適正な価格を払う」バランスを取りやすくしたとしている。
効率化を支えるモデル自身の最適化ループ
今回の値下げを支えているのは、GPT-5.6シリーズの稼働効率の劇的な向上だ。OpenAIはモデルそのもの、推論システム、そしてツールやコンテキストを扱うエージェント機構のあらゆる層で改良を重ねた。より直接的な処理経路の選択、ハードウェア生産性を維持するルーティング、トークン生成の最適化、重複作業を避ける賢いコンテキスト管理などが組み合わさり、同じ計算資源でより多くの有用な成果を出せるようになっている。
とりわけ注目されるのが、Sol自身が効率改善のプロセスに貢献した点だ。人間の管理のもと、Solは本番カーネルを自律的に書き換えて最適化し、トークン生成効率を高める数百の実験を設計・実行した。この取り組みによって、モデル提供にかかるエンドツーエンドのコストが20%削減され、トークン生成効率は15%以上向上した。AIがAIの運用コストを下げるフィードバックループが動き始めている。
こうした自己最適化のループは、OpenAIが目指す「インテリジェンスの価格性能比を継続的に向上させる」戦略の中核をなす。モデルが賢くなるほど、次の効率化のサイクルが加速するというわけだ。
企業がAI活用を進める際の新たな選択肢
LunaとTerraの値下げ、そしてSolのFastモードの登場によって、企業がワークフローごとに最適なモデルを選べる幅が大きく広がった。コストと速度、知能のバランスをタスク単位で調整できるようになったことで、AIの適用範囲を無理なく拡大できる。
たとえば、コード生成のワークフローを考えてみる。要件が曖昧で高度な判断が必要な設計段階ではSolを使い、確定した仕様に沿ったコード実装やテストの実行は低コストのLunaに任せる、といった割り振りが現実的になる。ドキュメントの大量分析や顧客対応の振り分けといった高頻度の業務も、Lunaを活用すれば予算内に収めやすい。
このように、単一のモデルですべてをこなすのではなく、処理の性質と求める品質に応じて使い分ける設計が、これからのAI戦略の基本になるだろう。SolのFastモードは、応答速度が収益に直結する顧客向けサービスなどで即効性が期待できる。
OpenAIのブログによれば、今回の改定によって、1年前に最先端とされたモデル並みのパフォーマンスをLunaで1タスク約6%のコストで実現できるという。AI活用が一部の専門領域から、あらゆる業務の日常ツールへと移行する大きな一歩だ。
この記事のポイント
- GPT-5.6 LunaのAPI料金が80%値下げされ、100万入力トークンあたり0.20ドルに。Terraも20%引き
- Sol向けFastモードが追加され、標準の最大2.5倍の速度を2倍の価格で提供
- 値下げの背景には、Sol自身がカーネル最適化などで推論コストを20%削減した成果がある
- 企業はタスクの難易度や処理量に応じてLuna、Terra、Solを柔軟に組み合わせ、コストと品質を両立できる
- ChatGPT WorkやCodexのサブスクリプション価格は据え置きのまま、LunaとTerraの消費クレジットが減少
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
OpenAI、推論保持とコンパクションでARC-AGI-3スコア3倍化
OpenAIの最新モデル「GPT-5.6 Sol」が、ARC-AGI-3ベンチマークで当初のスコアを約3倍に伸ばした。わずか2つのAPI設定を切り替えただけである。単にベンチマーク成績を上げただけでなく、出力トークン量も6分の1に削減した。
GPT-5.6 Solは数学の未解決問題を証明し、ポケモンなどのゲームをクリアする実力がある。それにもかかわらず、2Dパズルゲームで構成されるARC-AGI-3では開始直後ほぼ無力に見えた。スコアはわずか7.8%である。
問題はモデルそのものではなく、評価を実行する「ハーネス（テスト環境）」の設計にあった。OpenAIが本番環境で使っている推論保持とコンパクションを適用したところ、スコアは13.3%から38.3%へと跳ね上がった。これは人間の平均スコア（48%）に大きく近づく数字である。
なぜGPT-5.6 SolはARC-AGI-3で苦戦したのか
ARC-AGI-3ベンチマークの概要
ARC-AGI-3は、AIエージェントが未知の2Dゲームを探索しながらルールを推論し、自力で解く能力を測るベンチマークである。人間には直感的に分かるような簡単なパズルでも、AIにとっては説明なしに仕組みを理解するのが極めて難しい。
このベンチマークは、AIがどれだけ「学習し、推論できるか」を厳密に評価するために設計されており、特殊なツールや支援機能は一切与えられない。公式が用意するハーネスは、どのモデルでも同じ条件で比較できるよう、意図的に簡素な作りになっている。
公式ハーネスの2つの問題点
OpenAIの調査チームは、GPT-5.6 Solがゲーム内でひとつ行動するたびに「思考が真っ白に戻っている」ことに気づいた。公式ハーネスは、次の行動を起こす前に、モデルが直前に行った非公開の推論メッセージをすべて破棄していた。
一連の行動記録や簡単なメモは残るものの、その行動を導いた計画やひらめきは記憶に残らない。つまり、モデルは毎ターン、ゲームの仕組みを一から考え直さなければならなかった。
さらに、会話のコンテキストが長くなると「ローリング打ち切り」が発動し、古い行動履歴から順に削除されていく。推論が消えたうえに、過去の行動すら見えなくなるため、長期的な学習がほぼ不可能だった。この2つの設計が、GPT-5.6 Solの性能を著しく抑え込んでいたのである。
この図のように、ハーネスの設計ひとつで、同じモデルの振る舞いが大きく変わる。単純な推論保持と圧縮によって、アシスタントとしての性能が劇的に改善することをOpenAIは示した。
推論保持とコンパクションがもたらした改善
推論保持の効果
GPT-5.6は、ChatGPTやCodexでも使われている仕組みとして、返答やツール呼び出しの前に非公開の推論メッセージを生成する。通常、この推論は会話履歴の一部として保持される。公式ハーネスではこれが破棄されていたが、OpenAIのResponses APIを使うと、前のレスポンスIDを次に渡すだけで自動的に推論が引き継がれる。
推論が保持されると、2つの大きな変化が起きた。まず、毎回ゲームのルールを最初から解釈する必要がなくなり、1回の行動にかかる思考時間が短縮された。次に、過去の思考を思い出せるようになったことで、モデルは時間をかけて学習し、一貫した戦略を取れるようになった。
コンパクションの効果
公式ハーネスは、コンテキストが175,000文字を超えると古いメッセージを削除する「ローリング打ち切り」を採用していた。これに対し、Responses APIのコンパクションは、会話が長くなったときに内容を要約して保持する。これにより、過去の観察や行動を失うことなく、より少ないトークンで同じ情報を維持できる。
コンパクションを有効にした環境では、GPT-5.6 Solはゲーム内で学んだことを長いプレイ時間にわたって保持しやすくなり、スコアがさらに向上した。結果として、出力トークン数も大幅に削減された。
パフォーマンスの大幅向上とトークン削減
公開タスクセットにおいて、公式ハーネスでのGPT-5.6 Sol（max）のスコアは13.3%だった。推論保持とコンパクションを適用した結果、38.3%まで上昇した。これは約3倍の改善であり、出力トークンはおよそ6分の1に減少している。
スコアに用いられている「RHAE（Relative Human Action Efficiency）」は、人間のパフォーマンスを基準にした指標である。ARC-AGI-3の公式プレイヤーログから推定される人間の平均スコアは48%であり、GPT-5.6 Solはその80%近くに達した。この数字は、適切なハーネスがいかに重要かを雄弁に物語る。
実務開発者への示唆
Responses API の活用推奨
OpenAIは、API利用者に対して、旧来のChat Completions APIではなくResponses APIを使うこと、そして推論保持とコンパクションを有効にすることを強く推奨している。これらの設定は、ChatGPTやCodexなどのプロダクトで実際に使われている本番構成と同じである。
特に、エージェント的な挙動や長期的なタスクをAIに任せる場合、推論保持とコンパクションは必須に近い。実装上の手間は最小限であり、Responses APIを使えばレスポンスIDを引き継ぐだけで実現できる。
ベンチマーク比較の注意点
今回の事例は、ベンチマーク評価がモデル単体の能力だけでなく、API設定やハーネス設計といった目に見えない要素も測っていることを思い出させる。低いスコアが報告されても、それはモデルの本質的な限界ではなく、評価環境の不備かもしれない。
OpenAI自身、過去にも公開ベンチマークで成績が低く驚いた後に、評価ランナーが推論メッセージを捨てる汎用ハーネスを使っていたことに気づいたという経験がある。モデルを比較する際は、ChatGPTやCodexの実運用に近い設定で評価された結果を基準にすることが望ましい。
この記事のポイント
- GPT-5.6 SolはARC-AGI-3で当初7.8%のスコアだったが、API設定変更後は38.3%まで向上
- 推論保持を有効にすると、過去の思考を再利用でき学習効率が上がる
- コンパクションによって古い情報を要約し、少ないトークンで文脈を維持できる
- Responses API を用いることで、ChatGPTと同等のパフォーマンスを引き出せる
- ベンチマーク評価にはハーネス設計が大きく影響するため注意が必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Gemini 3.6 Flash登場、3.5 Flash-LiteとCyberも発表。AIエージェント開発の新定番へ
Google DeepMindは7月21日、AIエージェント開発の最前線を支える3つの新モデル、Gemini 3.6 Flash、3.5 Flash-Lite、3.5 Flash Cyberを発表した。今回のアップデートは、トークン効率の大幅な改善と、速度・コストの両立を追求した点が特徴だ。
3.6 Flashはコード生成や知識処理の精度を高めつつ、出力トークン数を最大65%削減するケースも報告されている。3.5 Flash-Liteは毎秒350トークンという爆速で、エージェントの大規模運用を想定した設計。そして3.5 Flash Cyberは、コードの脆弱性発見と修正に特化し、限定的な提供が始まる。
本記事では、それぞれのモデルの性能と実用面へのインパクトを、開発者視点で詳しく掘り下げる。AIエージェントのコスト構造やアーキテクチャ設計に直結する情報なので、Gemini API を扱うエンジニアは必見だ。
3.6 Flashで加速するトークン効率革命
出力トークン17%削減がもたらすコストインパクト
3.6 Flashの最大のセールスポイントは、3.5 Flash比で出力トークンを平均17%削減した点だ。Artificial Analysis Indexによる計測で明らかになったこの数字は、単なる省サイズ化を超えた意味を持つ。AIエージェントがマルチステップのワークフローを回す際、出力トークン量はAPI利用料金に直結するからだ。
具体的には、3.6 Flashの価格は入力100万トークンあたり1.50ドル、出力100万トークンあたり7.50ドル。3.5 Flashより安く、かつ出力が短くなったことで、1タスクあたりの実質コストが明確に下がった。エージェントが複数回の推論やツール呼び出しを繰り返すシナリオでは、コスト削減効果が累積的に効いてくる。
コード生成とナレッジワークでの明確なスコア向上
効率化と同時に、ベンチマークスコアも軒並み向上している。ソフトウェアエンジニアリングタスクを評価するDeepSWEでは、3.5 Flashの37%から49%へ向上。機械学習研究向けのMLE Benchでは49.7%から63.9%へと大幅に伸びた。不要なコード編集や実行ループの削減が、精度向上に寄与したと見られる。
また、OSWorld-Verifiedというコンピュータ操作タスクでは78.4%から83.0%へ改善。ドキュメント解析やチャート分析、レポート作成といった知識処理の指標GDPval-AA v2でもスコアを伸ばしている。企業ユーザーのFigmaやHarvey、Hebbiaからも「複雑なワークフローでのコストと品質の両立が進んだ」と高い評価が寄せられている。
上の図は、エージェントが1つのタスクを処理する際の出力トークン数の違いを模式化したものだ。実際のDeepSWEベンチマークでは最大65%のトークン削減が観測されており、コード生成のような長大な出力が求められる分野ほど恩恵が大きい。
3.5 Flash-Liteが切り開く高速エージェント運用
毎秒350トークン、低レイテンシと高スループットの両立
Gemini 3.5 Flash-Liteは、速度を極限まで追求したモデルだ。Artificial Analysisの計測では毎秒350トークンの出力を達成。前世代の3.1 Flash-Liteと比較してコーディングやエージェントタスクのスコアが大幅に向上し、実務に耐える品質を備えた。
価格は入力100万トークンあたり0.30ドル、出力100万トークンあたり2.50ドルと、3.6 Flashよりさらに安い。大規模なドキュメント処理やエージェント検索など、大量のリクエストをさばく必要があるシステムに最適だ。開発者は「思考レベル」を設定できるため、低レイテンシが求められる単純タスクでは最小限の推論に抑え、複雑なサブエージェント処理には高思考レベルを割り当てるといった柔軟な運用が可能になる。
3 Flashをも凌駕するエージェント性能
興味深いのは、3.5 Flash-Liteが先代の3 Flashを上回るベンチマーク結果を残している点だ。SWE-Bench Proでは54.2%（3 Flashは49.6%）、OSWorld-Verifiedでは74.0%（同65.1%）と、より高速でありながら高精度を実現している。長期コンテキストタスクのGDM-MRCR v2でも72.2%と、3.1 Flash-Liteの60.1%から大きく伸びた。
Google DeepMindの発表では、3.6 Flashをマスターエージェント、3.5 Flash-Liteをサブエージェントとして組み合わせるユースケースが紹介されている。マスターが全体の指示を出し、大量のサブタスクをLiteが高速に処理するアーキテクチャだ。これにより、Webデザインの複数案を瞬時に生成するといったワークフローが実用的な速度で回せるようになる。
この構成は、従来の「1つの大きなモデルに全部任せる」スタイルから、役割に応じたモデルを組み合わせるマルチエージェント設計への移行を象徴している。コストと速度のバランスを取る上で、3.5 Flash-Liteの存在は極めて重要になるだろう。
3.5 Flash Cyberがセキュアなコードを変える
脆弱性の発見と修正に特化したファインチューニング
3つ目の発表であるGemini 3.5 Flash Cyberは、3.5 Flashをベースにサイバーセキュリティ用途に特化して調整されたモデルだ。コードの脆弱性を高効率で検出し、修正パッチを生成する能力に優れている。単体で使うのではなく、Google DeepMindが開発したコードセキュリティエージェント「CodeMender」と組み合わせることで、複数のCyberエージェントが協調して1つの統合レポートを出力する。
ベンチマークCyberGymにおいて、CodeMender上の3.5 Flash Cyberは最前線クラスの競争力を持つことが示された。大規模モデルに頼らず、価格あたりのトークン単価を抑えつつ高い検出精度を実現している点がポイントだ。
限定的な提供と悪用防止の枠組み
この種の技術には悪用リスクがつきまとう。Google DeepMindは意図的に配布を制限し、政府機関と信頼できるパートナーに対してのみ、CodeMender経由の限定的なアクセスパイロットプログラムとして提供を開始する。フロントラインの防御側が脆弱性を早期に発見・修正できるようになる一方で、広範な悪用を防ぐ設計だ。
このアプローチは、セキュリティAIがいたずらに攻撃者の手に渡ることを防ぎつつ、本来の防御目的を達成する現実的な落とし所と言える。企業のセキュリティチームにとっては、コードレビューの自動化とパッチ生成の高速化が期待できるが、現時点では一般のAPIとしては利用できない点に注意が必要だ。
Gemini Flashシリーズが描くAIエージェントの次なる潮流
効率・速度・専門性の3軸で攻めるGoogleの戦略
今回の発表から読み取れるGoogleの戦略は明確だ。AIエージェントの実用化においてボトルネックとなる「コスト」「レイテンシ」「専門精度」の3つを、それぞれ最適化したモデルラインナップでカバーしようとしている。
- 3.6 Flashは汎用的な頭脳として、コストパフォーマンスと品質を高次元でバランス
- 3.5 Flash-Liteはスピードと低コストを武器に、大量のサブタスクや高スループット処理を担当
- 3.5 Flash Cyberはセキュリティという特定領域に深く特化し、専門エージェントとして機能
これは単なるモデルバリエーションの追加ではない。開発者がエージェントを設計する際に、「重いモデル1つで全てを処理する」のではなく、役割に応じたモデルを組み合わせるマルチエージェントアーキテクチャを標準化しようとする意図が感じられる。
競合との差別化と実務へのインパクト
OpenAIやAnthropicもエージェント向けの高速モデルを提供しているが、Googleはモデルのバリエーションと価格設定の粒度で一歩抜きん出た印象だ。特に3.5 Flash-Liteの「0.30ドル/1M入力トークン」という価格は、大量のAPIコールが発生するエージェント運用において強力な競争力になる。
さらに、3.6 Flashのトークン効率改善は、単にAPI利用料を下げるだけでなく、出力が短くなることで後続のコンテキストウィンドウ消費を抑え、長大な会話や複数ステップのタスクでも破綻しにくくなる。開発者体験としての「扱いやすさ」が向上している点も見逃せない。
上の図は、AIエージェントの設計思想の変化を模式化したものだ。Flashシリーズの充実により、開発者は「全部入り」の巨大モデルに頼らず、適材適所でモデルを組み合わせるアーキテクチャを選択しやすくなる。
この記事のポイント
- Gemini 3.6 Flashは出力トークンを平均17%削減、コードやナレッジ処理の精度も向上
- 3.5 Flash-Liteは毎秒350トークンの速度で、高スループットなエージェント処理に最適
- 3.5 Flash CyberはCodeMenderと連携し、コード脆弱性の検出と修正を効率化（限定提供）
- 3つのモデルは役割を分担するマルチエージェント設計を前提に開発されており、コストと速度の最適化を実現
- AIエージェント開発は「1つの巨大モデル」から「目的別モデルの組み合わせ」へと移行しつつある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Nano Banana 2 LiteとGemini Omni Flash登場、高速画像生成と動画編集がAPIで利用可能に
Google DeepMindは2026年6月30日、高速画像生成モデル「Nano Banana 2 Lite」と、動画生成・編集モデル「Gemini Omni Flash」を開発者向けに公開した。どちらもGoogle AI StudioとGemini APIから即日利用できる。
Nano Banana 2 Liteはテキストから画像をわずか4秒で生成し、1,000枚あたり0.034ドルという低コストが売りだ。Gemini Omni Flashは自然言語による動画編集と高品質な動画生成を両立し、1秒あたり0.10ドルで提供される。
この2つのモデルを組み合わせることで、画像を生成して即座に動画化するといったマルチメディア制作のワークフローが一気に加速する。本記事では各モデルの性能、活用シナリオ、連携方法を詳しく見ていく。
Nano Banana 2 Liteの概要と位置づけ
Nano Banana 2 Lite（モデル名 gemini-3.1-flash-lite-image）は、Nano Bananaファミリーの中で最も高速かつ低コストな画像生成モデルだ。主に短時間でのプロトタイピングや大量の画像生成が必要な開発パイプラインを想定している。
旧モデルであるNano Banana（gemini-2.5-flash-image）からの置き換えが推奨されており、差し替えるだけで速度・品質・コストのすべてで改善が見込める。
速度とコストの具体的な数値
- レイテンシ（処理時間） テキストから画像を出力するまでの時間は約4秒。対話的なプロトタイピングや下書き用途に向く。
- 料金 1,000枚あたり0.034ドル。大量生成や予算管理が求められるプロジェクトでコストを抑えやすい。
- 品質のバランス 速度優先ながら、プロンプトへの忠実度・キャラクターの一貫性・画像内テキストの可読性は確保されている。
Nano Bananaファミリー全体の比較
Nano Bananaシリーズには4つのモデルが存在し、用途に応じて使い分ける設計だ。以下が各モデルの位置づけである。
開発者は自分たちのプロジェクトが「速度」を求めるのか「品質」を求めるのかによって、Lite・標準・Proを切り替えられる。たとえば広告バナーの大量生成ならNano Banana 2 Lite、製品写真の精密な加工ならNano Banana Proといった使い分けが現実的だ。
Gemini Omni Flashがもたらす動画編集の変化
Gemini Omni Flash（gemini-omni-flash-preview）は、テキスト・画像・動画を組み合わせたマルチモーダル入力をネイティブに扱い、高品質な動画生成と会話型編集を実現するモデルだ。2026年5月のGoogle I/Oで発表され、今回初めてGemini APIとGoogle AI Studioに公開された。
料金は出力動画1秒あたり0.10ドル。Veo 3.1 Fastと同水準であり、動画生成AIとしては競争力のある価格設定だ。
4つの得意領域
従来の動画生成AIでは「1回のプロンプトで動画を出力して終わり」という単発的な使い方が多かった。Omni Flashは会話を重ねながら微調整できる点が大きく異なる。動画の一部だけを修正したり、複数回の編集を積み重ねたりするワークフローが自然に回せるようになる。
現在の制限事項
- 生成できる動画の長さは現時点で10秒まで。長時間の動画生成は今後対応予定。
- 音声参照のアップロードとシーン延長機能は、今回のAPIでは未サポート。
- APIの仕様上は3秒までの動画参照を受け付けるが、現時点では正しく処理されない。
- シーン切り替えやパン（カメラの横移動）時のキャラクター一貫性に制限あり。改善中。
「10秒制限」は短く感じるかもしれないが、SNS向けショート動画やeコマースの商品紹介動画であれば十分な長さだ。3秒の動画参照制限についても、短いクリップを下敷きにした編集という使い方であれば実用範囲内といえる。
2つのモデルを連携させた実践ワークフロー
Nano Banana 2 LiteとGemini Omni Flashの真価は、両者を組み合わせることで発揮される。具体的には次のような流れだ。
Interactions APIを使うことでセッション履歴とコンテキストが保持されるため、ユーザーは最大3回まで連続した編集を積み重ねられる。1回の生成で終わらない、試行錯誤を前提としたクリエイティブ制作に適した設計だ。
公式デモアプリに見る実用例
Google DeepMindは両モデルを組み合わせた3つのデモアプリを公開している。いずれもGoogle AI Studio上で動作し、ソースコードをリミックスして自社サービスに組み込める。
これらのデモは、画像生成と動画編集を別々のAIに任せるのではなく、一つのワークフローとして統合することで生まれる価値を示している。eコマース事業者であれば、商品写真のバリエーションを大量生成し、その中から選んだ数枚だけを動画化するといった効率的な運用が可能になる。
開発者が知っておくべき安全性とモデル情報
両モデルともGoogleのセキュアなインフラ上で動作し、SynthIDによる電子透かし（ウォーターマーク）が埋め込まれる。SynthIDはAI生成コンテンツであることを検証可能にする技術で、GeminiアプリやChrome、Google検索を通じてコンテンツの来歴を確認できる。
すでにNano Banana 2 Liteは検索のAI Mode、Geminiアプリ、NotebookLM、Google Photos、Stitch、Google Flow、Google Adsなど、Googleの一般向けサービスにも順次展開されている。
API経由での利用にあたっては、各モデルの詳細な機能やリージョン別の制限が公式ドキュメントにまとめられている。開発を始める前に、Google AI Studioのプレイグラウンドで実際の挙動を試すのが確実だ。
この記事のポイント
- Nano Banana 2 Liteは4秒で画像を生成し、1,000枚あたり0.034ドルの低コストで利用できる
- Gemini Omni Flashは自然言語による動画編集と高品質な動画生成を両立し、1秒あたり0.10ドルで提供される
- 両モデルを連携させると、画像生成から動画化・編集までを一貫したワークフローで回せる
- Google AI StudioとGemini APIから即日利用可能で、具体的なデモアプリも公開済み
- SynthIDによるAI生成コンテンツの検証機能が組み込まれており、商用利用にも配慮されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
MetaがInstagram埋め込みのトークン要件を撤回、WordPressで復活
Metaは2026年6月15日、約6年前に導入したoEmbed APIのアクセストークン要件を撤回した。Instagram、Facebook、Threadsの投稿URLをWordPressに貼り付けるだけで埋め込み表示が可能になる。2020年10月にそれまで動いていた機能が突然使えなくなって以降、多くのサイト運営者が埋め込み手段を模索してきたが、ようやく以前の手軽さが戻った格好だ。
今回の方針転換に合わせて、Metaは公式WordPressプラグイン「Meta Embeds」も公開している。トークン管理不要で動作し、コードはGitHubで公開されている。本記事では技術的な変更点と実務への影響、そしてこの変更がカバーしない領域についても整理する。
2026年6月15日の変更内容
今回の発表でトークン不要となったのは、以下の4つのエンドポイントだ。
- Threads oEmbed
- Instagram oEmbed
- Facebook oEmbed（投稿）
- Facebook oEmbed（動画）
従来は、これらのエンドポイントを呼び出すためにMetaの開発者アカウント登録、アプリ作成、App Review申請、そして毎回のアクセストークン付与が必要だった。2026年6月15日以降は、URLさえあれば直接APIを叩ける。レスポンスの形式自体は以前と同じで、埋め込みHTML、プロバイダ名、幅、コンテンツタイプが返ってくる。
ただし2つの注意点がある。1つ目はレート制限だ。トークンレスアクセスはトークン付きのルートよりも呼び出し回数が制限される可能性があり、高頻度で埋め込みを行うサイトでは影響が出るかもしれない。2つ目は、エンドポイントがパブリックな投稿にしか対応しない点だ。非公開アカウントや限定公開の投稿は対象外となる。
この比較図からもわかるように、開発者向けの複雑な手続きが不要になった。個人ブログの運営者でも迷わずにMetaの投稿を埋め込めるようになっている。
元の変更が起きた経緯
2020年10月の衝撃
2020年10月、Metaは同社のoEmbedエンドポイントにアクセストークンを必須とする変更を発表した。WordPressにとってInstagramやFacebookのURLを貼るだけで埋め込みが表示される機能は標準装備だったが、この発表で状況は一変する。WordPressのコアチームは、数千万ものサイト運営者にトークン管理を要求することは現実的ではないと判断し、FacebookとInstagramをoEmbedプロバイダーから削除した。
すでに埋め込まれていた投稿は、WordPressがoEmbedレスポンスをデータベースにキャッシュしていたため表示が維持された。しかし新規の埋め込みは一切動作しなくなった。影響はWordPressサイト全体に及び、埋め込み機能を前提にしていたコンテンツ戦略を大きく狂わせた。
プラグイン市場への波及
この混乱に対応するため、JetpackはAutomattic社が保有するトークン経由でリクエストをプロキシする仕組みを急遽導入した。oEmbed Plusのようなサードパーティ製プラグインも登場し、一般のサイト運営者が自前でFacebook App IDとシークレットキーを生成して設定する手順を案内していた。
しかし多くの運営者はこれらの対策を取らず、埋め込み自体を諦めるか、API接続を内部で処理する専用プラグインに移行した。WP Mayorの記事によれば、この一件だけで「壊れたInstagram埋め込みを修正する」ためのコンテンツやツール群が一つのカテゴリを形成するほどだったという。
6年ぶりの方針転換の背景
Metaが2020年に掲げていた理由はプライバシーとセキュリティの強化だった。しかし今回の発表では「パブリックなMetaコンテンツの埋め込みを容易にする」という簡潔な説明にとどまっている。WP Mayorの著者Mark Zahra氏は、このタイミングでの撤回について「各プラットフォームがユーザーの注意を奪い合い、AIによる回答がリファラルトラフィックを侵食する中で、Metaが自社コンテンツを再びオープンウェブ上で流通させたいという意図が透けて見える」と分析している。
Metaが公式WordPressプラグインを公開
APIの方針転換と同時に、Metaは公式のWordPressプラグイン「Meta Embeds」をリリースした。ソースコードはGitHubで公開されており、オープンソースで開発が進められている。
このプラグインは、Threads、Instagram、Facebookの投稿URLをエディタに貼り付けるだけでリッチな埋め込みを表示する。設定画面はなく、トークンも不要。ブロックエディタとクラシックエディタの両方に対応している。Metaが自社製のWordPressプラグインを公式リポジトリに直接公開するのは異例の動きだ。
プラグインのReadmeに含まれるFAQには、今後の展開をうかがわせる記述がある。このプラグインは、WordPressのバージョンがすでにThreadsのoEmbedプロバイダーを登録しているかどうかをチェックし、重複登録を回避する仕様になっている。WP Mayorの記事は、この実装を「Metaの埋め込み機能がWordPressコアに再統合される布石」と見ており、今後のWordPressリリースでInstagramとFacebookのネイティブ埋め込みが復活する可能性に注目すべきだと指摘している。
Meta Embedsプラグインを有効化するだけで、これまで埋め込みが動作しなかった環境でも即座に表示が改善する。WordPressコアへの統合が実現すれば、プラグインすら不要になる可能性もある。
今回の変更が影響しない領域
oEmbedは単一投稿のAPIである
「トークンレスになったならInstagramフィードプラグインは不要では」という見方が一部で出ているが、それは誤解だ。oEmbedはあくまで1つの公開投稿URLを受け取り、その1投稿の埋め込みコードを返すAPIに過ぎない。
アカウントの最新投稿一覧を取得する機能、ハッシュタグフィード、ストーリーズの表示、自動更新といった機能は、oEmbedでは提供されない。これらは従来通りInstagram Graph APIを使い、アクセストークンによる認証が必要となる。
ブログ記事の中に特定のInstagram投稿を1つだけ埋め込みたいケースでは、今回の無料ルートが再び使えるようになった。逆に、サイトのトップページに最新のInstagram投稿を自動表示したい場合、レイアウトやフィルタリング、モデレーション機能も含めて、Instagramフィード専用プラグインの出番は変わらない。
フロントエンドでのスクリプト読み込みとプライバシー
もう1つ理解しておくべき違いは、oEmbedから返される埋め込みHTMLの動作だ。MetaのoEmbedは、投稿をレンダリングするためにMetaのJavaScriptを訪問者のブラウザに読み込む。Meta EmbedsプラグインのReadmeにも、フロントエンドでのレンダリングはMetaのプライバシーポリシーに準拠すると明記されている。
これは、Metaのスクリプトを一切読み込まずにコンテンツをネイティブ表示するソリューションとは性質が異なる。EU圏のクライアント向けにサイトを構築している場合、GDPRの観点からこの違いは重要だ。埋め込みを有効にする前に、プライバシーポリシーとの整合性を確認しておく必要がある。
実務者への実践ガイド
ドキュメントとナレッジベースの更新
Instagram埋め込みにトークンやMetaアプリが必要だと説明しているコンテンツやドキュメントは、2026年6月15日以降は誤りとなった。WP Mayor自身も自社アーカイブの監査を進めていると述べており、チュートリアル記事や社内マニュアルを保有している場合は速やかな見直しが求められる。
クライアントサイトでの対応
クライアント向けにWordPressサイトを構築している場合、単発のMeta投稿埋め込みは開発者向けのセットアップなしで利用可能になった。Meta Embedsプラグインを導入すればすぐに動作する。WordPressコアへの統合が進めば、近い将来プラグインすら不要になる可能性も視野に入れておきたい。
Instagramフィードプラグインの利用者
既存のInstagramフィードプラグインを使用しているサイトには、今回の変更は一切影響しない。フィード機能はInstagram Graph APIに依存しており、oEmbedのトークン要件撤廃とは無関係だ。不安があればプラグインの開発元に確認するのが確実だが、WP Mayorの記事ではRebelCode社が開発するSpotlight Instagram Feeds（6万以上のアクティブインストールを誇る高評価プラグイン）を含め、APIベースのフィードソリューションはすべて影響を受けないと明言されている。
この記事のポイント
- Metaが2026年6月15日、oEmbed APIのトークン必須化を撤回。Instagram、Facebook、Threadsの埋め込みがURL貼り付けだけで動作する
- 併せて公式WordPressプラグイン「Meta Embeds」をリリース。コードはGitHubで公開され、WordPressコアへの統合も視野に入っている
- oEmbedは単一投稿APIであるため、アカウントの最新フィード表示やストーリーズ機能は従来通りAPIトークンが必要。Instagramフィードプラグインの役割は変わらない
- 埋め込み表示にはMetaのJavaScriptが読み込まれるため、GDPR対応が必要なサイトではプライバシーポリシーとの整合性確認が欠かせない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
GoogleとMicrosoftがAIエージェント共通仕様ARDを公開、11社が賛同
GoogleとMicrosoftを含む11社が、AIエージェントがウェブ上のツールやスキルを自動検出するための共通仕様「ARD（Agentic Resource Discovery）」を2026年6月17日に公開した。
GitHubやHugging Face、NVIDIA、Salesforceも名を連ねるこの仕様は、各社が公開するAIエージェント向け機能を、事前の手動接続なしに実行時に見つけ出せる仕組みだ。Apache 2.0ライセンスで公開され、同日に複数の参照実装もリリースされた。
この仕様が実用化されれば、AIエージェントは必要なツールを自ら探し出して接続できるようになる。開発者やサービス提供者にとっては、自社のAPIやエージェント機能をAIシステムに自動的に見つけてもらうための新たな方法が生まれることになる。
ARDとは何か
ARD（Agentic Resource Discovery）は、AIエージェントがウェブ上で「使えるツールや機能」を自動的に見つけ出すための共通ルールを定めた仕様だ。Linux Foundationのワーキンググループが管理するAI Catalogデータモデルを基盤に構築されている。
現在のAIエージェントは、あらかじめ各ツールやMCPサーバー、APIとの接続を手動で設定する必要がある。企業が公開する機能が増え続けるなか、この「事前配線」方式では拡張性に限界があった。ARDはこの問題に対処するために設計されている。
ARDの仕組みは、企業が自社ドメインに公開するカタログと、それを収集してインデックス化するレジストリの2層構造で成り立っている。人手による接続設定を実行時の検索に置き換えることで、AIエージェントが自律的に機能を発見できる世界を目指している。
ARDの技術的な仕組み
カタログとレジストリの2層構造
ARDの中核は「カタログ」と「レジストリ」という2つの要素だ。まず、ツールやエージェントを提供する企業は、自社ドメインの定められたパスにai-catalog.jsonというファイルを設置する。このファイルには、公開するツール、MCPサーバー、エージェント、APIの一覧が記述される。
次に「レジストリ」がこれらのカタログを巡回（クロール）してインデックス化する。AIエージェントが「この処理に使えるツールはないか」と自然言語で問い合わせると、レジストリが該当するカタログ情報を返す仕組みだ。
ai-catalog.json を設置カタログが公開者の自社ドメインに置かれることで、ドメイン所有権が公開者の検証手段として機能する。本番運用では、暗号化された信頼メタデータを付与し、接続前に公開者の身元を確認することも可能だ。ツールが選定された後は、ARDの役割は終了し、実際の接続は各ツール固有のプロトコルで直接行われる。
誰に向けた仕様なのか
ARDが主に対象とするのは、APIやMCPサーバー、エージェントといった「呼び出し可能な機能」を提供する企業だ。ツールを公開する企業には、AIエージェントに見つけてもらい、信頼してもらうための明確な方法が提供される。
一方、一般的なコンテンツサイトにとっては、現時点で直接的な活用方法は示されていない。Search Engine Journalの記事でも「典型的なコンテンツサイトに今日すぐ取るべきアクションはない」と指摘されている。
公開当日に登場した参照実装
ARDの草案公開と同日に、複数の参加企業が実際に動作するツールをリリースした。
- GitHub Copilot向けに「Agent Finder」を導入。選択したレジストリからMCPサーバー、スキル、ツール、エージェントを検出し、ユーザーが接続対象を制御できる仕組みだ。
- Hugging Face ARDサービス全体からスキルやMCPサーバーを検索する「Discover Tool」を公開した。
- Cisco Linux Foundation傘下のオープンソースプロジェクト「AGNTCY Agent Directory」にARDを統合した。
GitHubのAgent Finderは特に関心を集めている。Copilotのユーザーがレジストリから必要な機能を見つけ出し、自分の判断で接続を許可できる設計は、エージェントの自律性とユーザー制御のバランスを取る試みといえる。
この流れは、ウェブの「機械可読層」を整備する一連のオープン仕様の延長線上にある。GoogleはARD公開の2日前にも、AIシステム間で組織知識を共有するための「Open Knowledge Format」仕様を発表している。いずれも自社ドメインに構造化ファイルを設置するだけで、AIシステムが人手の配線なしに情報を利用できるようにする考え方だ。
Googleの立ち位置と今後の展開
GoogleはARDにおいて、Gemini Enterprise Agent Platformの一部である「Agent Registry」を中心的な役割として位置づけている。これはエージェント向けリソースのホスティングと検索、企業向けのガバナンス管理を担う基盤だ。
Search Engine Journalの記事によれば、Agent RegistryへのネイティブARD対応は数カ月以内に予定されている。これが実現すれば、組織は内部レジストリを広域ネットワークに接続できるようになる。
ただし現時点でこの対応は稼働しておらず、ARDはあくまで「仕様」であってGoogle検索の機能ではない。検索エンジンとしてのGoogleがARDカタログを直接検索結果に反映するわけではない点は、区別して理解しておく必要がある。
コンテンツ制作者が今考えるべきこと
ARDがもたらす影響は、ビジネスの性質によって大きく異なる。ツールやAPIを提供する企業には、AIエージェントに発見されるための具体的な手段が用意された。一方で、一般的なコンテンツサイト運営者にとっての即効性は限定的だ。
この仕様の価値については業界内でも議論がある。GoogleのJohn Mueller氏は、LLMシステムがllms.txtのようなファイルでサイトを区別することはできないと指摘し、将来のエージェント向け戦略よりも現在のニーズに注力するよう助言している。ARDが対象とするのはツールやエージェントであり、コンテンツではないという点は、こうした議論の背景として押さえておきたい。
仕様はまだv0.9草案であり、GitHubリポジトリで変更提案を受け付けている段階だ。実用性を左右するのは、カタログを大規模にクロールしてインデックス化できるレジストリのエコシステムだが、それもまだ初期段階にある。
エコシステムが成熟した場合に最も恩恵を受けるのは、他者が必要とするツールやエージェントを提供する企業だ。GoogleがUlrtaユーザー向けに展開し始めたエージェント主導の検索機能も、この方向性を示唆している。今すぐ取るべき現実的なアクションは、自社が使っているプラットフォームやツールがARDに対応するかどうか、そして対応時にどのような公開情報が求められるかを注視することだ。
この記事のポイント
- ARDはAIエージェントがツールやAPIを実行時に自動発見するためのオープン仕様である
- カタログ（ai-catalog.json）とレジストリの2層構造で、ドメイン所有権が信頼の基盤となる
- GitHubやHugging Faceが公開初日から参照実装を提供しており、実用化に向けた動きは速い
- 一般的なコンテンツサイトよりも、ツールやAPIを公開する企業に直接的な恩恵がある
- v0.9草案段階であり、レジストリのエコシステム構築が今後の鍵を握る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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モデルのサイドバイサイド比較と、プロジェクト単位のトークン消費可視化が組み込まれている
- コンソール上のコードスニペットはプロジェクト変数が自動プレフィルされ、コピー後即実行できる
- 東京リージョンを含む複数リージョンで利用可能、既存コンソールとの併存もサポートされる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 10.9でデュアルAPI登場、PHPコードからGraphQLを自動生成
WooCommerce 10.9で、PHPコードからGraphQL APIを自動生成する「デュアルAPI」が実験的に導入された。AutomatticのRadical Speed Monthイニシアチブの一環として開発されたこの機能は、開発者がPHPクラスに属性（アトリビュート）を付与するだけで、REST APIとGraphQL APIの両方を提供できるようにするものだ。
本記事では、デュアルAPIの技術的な仕組みと、プラグイン開発者にとっての具体的なメリット、現時点での制限と注意点を詳しく解説する。PHP 8.1以上が必須となるため、サーバー環境のバージョンアップを検討している運営者にも役立つ情報をまとめた。
WooCommerceデュアルAPIの概要と狙い
デュアルAPIの3つの構成要素
WooCommerce Developer Blogの記事によれば、デュアルAPIは大きく3つのパーツで成り立っている。1つ目は、PHP属性で装飾されたプレーンなPHPクラスで表現される「コードAPI」だ。これはコマンドパターンで実行可能なクラスか、データ転送オブジェクト（DTO）として定義される。2つ目は、そのコードAPIから自動生成される「GraphQL API」。そして3つ目が、開発時にコードからGraphQLパートを生成する「ビルドスクリプト」である。
なぜGraphQL APIを自動生成するのか
従来のWooCommerce REST APIは、決められたエンドポイントから必要なデータを取得する方式だった。一方、GraphQLはクライアントが必要なフィールドだけをリクエストできるため、オーバーフェッチやアンダーフェッチを防げる。モバイルアプリやヘッドレスコマース構成との相性も良い。しかし、APIを二重にメンテナンスする手間は大きい。そこで、PHPコードを信頼できる唯一の情報源（ソースオブトゥルース）とし、GraphQL側を自動生成することで、開発効率と一貫性を両立させる狙いがある。
コードからGraphQLを自動生成する仕組み
PHPクラスに定義した属性や型情報が、GraphQLスキーマのクエリ名、引数、返却型へと自動的にマッピングされる。開発者はPHPコードだけを書けば、対応するGraphQLエンドポイントが手に入る仕組みだ。
PHP属性によるメタデータの付与
この仕組みの中核が、PHP 8.0で導入された「属性（アトリビュート）」だ。クラスやメソッド、プロパティに #[Name('coupon')] や #[Description('...')] といった形でメタデータを埋め込める。このメタデータをビルドスクリプトが読み取り、GraphQLの型定義やドキュメントを自動構築する。PHPのコードベースがそのままAPIの仕様書になるわけだ。
コマンドクラスとDTOの変換ルール
実行可能なコマンドクラスはGraphQLのクエリやミューテーションに変換される。引数には #[Description] 属性付きで説明がつき、デフォルト値やnull許容もスキーマに反映される。DTOはGraphQLのインプットタイプやアウトプットタイプになる。PHPの列挙型（enum）や #[ArrayOf('int')] のようなカスタム属性を使えば、スカラー型の配列や独自型も正確に表現できる。
ビルドスクリプトの役割
ビルドスクリプトは開発時に一度だけ実行する。WooCommerceコアに同梱されており、プラグイン開発者も自分のコードに対して実行可能だ。スクリプトがコードAPIを解析し、GraphQLスキーマをファイルとして出力する。実行時にはそのスキーマに従ってリクエストが処理されるため、本番環境で毎回コードを解析する必要はない。
プラグイン開発におけるデュアルAPIの活用方法
独自のデュアルAPIを作成する手順
WooCommerce Developer Blogの記事では、プラグイン開発者がこのインフラを再利用して独自のデュアルAPIを構築できる点が強調されている。手順はシンプルだ。まず、プラグイン内にコマンドクラスとDTOを定義し、必要な属性を付与する。次に、WooCommerceのビルドスクリプトを開発時に走らせると、GraphQLパートが自動生成される。最後に rest_api_init フックを使い、ユーティリティメソッドで任意のエンドポイントURLにGraphQL APIを登録すれば完了する。
認証・認可のカスタマイズと拡張ポイント
コアのインフラは、クラスリゾルバ（デフォルトではWooCommerceのDIコンテナ）や、認証用のプリンシパルクラス、認可用の #[RequiredCapability] 属性を提供している。これらはそのまま使うことも、独自の認証・認可ロジックに置き換えることも可能だ。例えば、外部サービスと連携するプラグインであれば、カスタムのプリンシパルクラスを差し込んでAPIキー認証を実装できる。柔軟な拡張性が意識された設計である。
現時点での制限と実験的機能の注意点
後方互換性の保証がない理由
このデュアルAPIは実験的な機能であり、明示的に有効化しない限り動作しない。WooCommerce Developer Blogの記事でも、インフラ部分とコアAPIのいずれについても、将来のリリースで後方互換性のない変更が加えられる可能性があると明言されている。特に、より徹底したテストの過程で、属性の命名規則やクラス構成に破壊的変更が入るかもしれない。本番環境への導入は、安定版となるまで控えたほうが無難だ。
コアAPIのプルーフオブコンセプト
WooCommerce 10.9に同梱されるコアAPIは、製品とクーポンをカバーする限定的なものだ。記事では、これはあくまで「プルーフオブコンセプト（概念実証）」であり、今後のバージョンでクラスやクエリが大幅に変更されるか、まったく別のものに置き換わる可能性があるとされている。現時点では、開発環境やステージング環境でのテスト利用が推奨される。
PHP 7環境の安全性とバージョンアップの必要性
PHP 8.1依存の技術的理由
デュアルAPIはPHP 8.1以上を要求する。これは、PHP属性と列挙型（enum）に依存しているためだ。属性がなければGraphQLスキーマを自動生成できず、enumがなければDTOの厳密な型表現が難しくなる。WooCommerceとしても、公式にPHP 8.1以上を推奨しており、PHP 7.4や8.0のサポートは将来的に終了する方針が示されている。
PHP 7環境での影響と注意点
WooCommerce Developer Blogの記事によると、PHP 8.1固有のコードは、この機能が無効の場合やサーバーがPHP 7.4／8.0で動作している場合には一切実行されない設計になっている。したがって、機能を誤って有効化しようとしてもエラーは発生せず、GraphQLエンドポイントが機能しないだけだ。ただし、プラグインやカスタムコードから src/Api 配下のクラスを直接呼び出すと、PHP 7環境ではエラーになるため注意が必要である。
将来のPHPバージョンサポート計画
WooCommerceは過去にPHP 7.2／7.3のサポートを段階的に終了してきた。今回のデュアルAPI導入は、PHP 8.1移行を加速させる呼び水となるだろう。WordPress 7.0がPHP 7.2／7.3のサポートを打ち切り、PHP 8互換がベータを脱したことも追い風だ。ECサイト運営者は、セキュリティ面とパフォーマンス面からも、早めのPHPバージョンアップを検討すべき局面を迎えている。
この記事のポイント
- WooCommerce 10.9で実験的デュアルAPIが導入され、PHPコードからGraphQL APIを自動生成できるようになった
- PHP属性とDTOによってコードがAPI仕様を兼ね、プラグイン開発者も独自のデュアルAPIを構築可能
- 現時点では後方互換性が保証されない実験的機能であり、本番利用は避け、テスト環境での検証が推奨される
- PHP 8.1以上が必須で、PHP 7環境では機能が無効化されるが、安全面でのリスクは低い
- PHPバージョンアップの必要性が高まっており、ECサイトの将来的な安定稼働に向けて計画的な移行が望ましい
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce 10.8リリース！レビューメール自動化と各種高速化の全容
WooCommerce 10.8が2026年5月26日にリリースされた。今回のアップデートでは購入後のカスタマーレビュー依頼メールの自動化、カスタム配送業者の設定機能、クーポンコードの動的生成、そして管理画面のパフォーマンス改善が盛り込まれている。
動作条件としてWordPress 6.9以上が必要だ。WooCommerceを更新する前にWordPress本体を最新にしておく必要がある。管理画面の一貫性を保つWordPress 7.0への事前適合も含まれており、今後のスムーズな移行に向けた布石となるリリースだ。
WooCommerce 10.8の主な変更点
WordPress 7.0向けの管理画面スタイル調整
WooCommerce 10.8には約15件のプルリクエストが含まれ、WordPress 7.0の新しい管理画面デザインとの整合性を確保した。対象となったのはフォームコントロールのサイズ、Select2ドロップダウン、ボタンの角丸、通知の色、メタボックス周りのスタイルだ。
従来、WooCommerceの一部画面では青系の管理画面用色が直接ハードコーディングされていた。これがテーマカラー変数に置き換えられ、ユーザーが設定した配色スキームに沿って境界線やホバー状態が変化するようになった。WordPressとWooCommerceを同時に更新すれば、管理画面全体の見た目に統一感が出る。
管理画面の色が選んだテーマに合わせて変化するため、複数サイトを運営している場合でもサイトごとに配色を変えられ、管理ミスの防止にもつながる。
オフライン対応の管理画面
WooCommerceの管理画面がオフラインを検知するようになった。ブラウザのネットワーク接続が切れるとバナーが表示され、保存リクエストがネットワーク喪失で失敗した場合には明確な通知が表示される。
これまで接続の不安定な環境では保存失敗に気づかず、注文データや設定の消失につながるケースもあった。モバイル回線やカフェのWi-Fiなど、接続状態が変わりやすい場所で作業するストア運営者にとっては実用的な改善だ。
パフォーマンス改善の詳細
SQLクエリの削減と高速化
WooCommerce 10.7から続くクエリ削減の取り組みがさらに進んだ。取引IDルックアップ用の索引が wc_orders テーブルに追加され、販売ピーク時の在庫予約に使われる wc_reserved_stock テーブルの索引も改善された。
加えてキャッシュプライミングが商品アーカイブ、商品編集画面、クラシックカート、グループ化商品、Store APIの商品スキーマに拡張された。これにより各パスでデータを1行ずつ取得する代わりにバッチロードできるようになり、データベースへの負荷が大きく下がる。
クーポンの _used_by メタデータは遅延読み込み化された。何千回も使われたクーポンをロードする際に全使用履歴をメモリに展開しなくなり、クーポン読み込み時のパフォーマンスが飛躍的に改善する。レイヤードナビゲーションのフィルターキャッシュにはデフォルトで上限が設定され、wp_options テーブルが無制限に肥大化するのを防ぐ。
ベータ版からの修正点
10.8のベータテスト期間中に見つかった問題も解消された。 WC_Order::payment_complete() に追加予定だったチェックアウト証跡のバリデーション機能は最終版から差し戻され、このリリースには含まれない。
また wc_orders_meta テーブルの meta_key_value 索引から meta_value 列が誤って削除されたパフォーマンス回帰も修正された。注文メタデータの検索速度が低下する問題だったが、10.8で索引構成が復元されている。
新機能の詳細
カスタマーレビュー依頼メールの自動化
10.8の目玉機能の一つが、購入者に商品レビューを依頼する自動メール機能だ。WooCommerceの設定の「メール」タブから有効化でき、Action Schedulerを使って注文完了から設定した日数後に送信される仕組みだ。
注文がキャンセル、返金、削除された場合にはメールは自動キャンセルされる。全額返金された商品はレビュー対象から外されるため、購入者と商品の関係が切れた状態でのレビュー投稿を防げる。顧客はトークン付きの専用読み取り専用ページに誘導され、アクセシブルな5つ星評価のコントロールからレビューを投稿する。投稿されたレビューは「確認済み購入者」の商品レビューとして扱われる。
この仕組みで集まったレビューは確認済み購入者の証跡が残るため、レビュー全体の信頼性を高められる。商品ページの社会的証明を強化したいストアには有効な手段だ。
クーポンコードの自動生成機能
メールブロック内で使えるクーポンコード機能が自動生成に対応した。ストア運営者は割引額やクーポンタイプ、有効期限といったルールを設定し、メール送信時に受信者ごとのユニークなコードを動的に発行できる。
パーソナライズされたクーポンキャンペーンの運用が大幅に簡略化される。全員に同じコードを配布して拡散リスクを抱える必要がなくなり、1人1コードの安全な配布が可能だ。
メールテンプレートの同期とリセット
ブロックメールの投稿にバージョン、ソースハッシュ、同期日時といったメタデータが付与されるようになった。テンプレートが元の配布状態からどれだけ変更されたかを自動検知できる。さらに管理画面からワンクリックでメール本文をプラグイン配布時のオリジナル状態に戻せるリセット機能も追加された。
カスタマイズを重ねたメールテンプレートの管理は煩雑になりがちだが、変更箇所の可視化と即時リセットで運用負荷が下がる。
カスタム配送業者の設定
独自の配送業者を定義できるUIが追加された。業者名と追跡URLテンプレートを登録すれば、注文画面で業者ごとのフィルタリングや、カスタマイズされた追跡リンクを使って出荷状況を確認できる。
国内の小規模な配送業者や地域限定の物流サービスを使っているストアでも、統一された画面から追跡情報を管理しやすくなる。
APIの更新
REST APIとGraphQL
注文APIでは shop_order でないレコードの変換が拒否されるようになり、チェックアウトドラフト注文はデフォルトクエリから除外されるようになった。より明示的なデータ操作が求められる変更だが、意図しないデータ混入を防ぐ点でAPIの堅牢性が増した。
注目すべきはGraphQL APIの導入だ。デュアルコードとGraphQL APIがWooCommerceに組み込まれ、管理画面の「詳細設定」タブにGraphQL設定セクションが追加された。GETエンドポイントのトグル操作で有効にできる。ヘッドレス構成やモダンなフロントエンドスタックからWooCommerceのデータを柔軟に取得したい開発者にとって重要な布石となる。
そのほか商品公開時に発火する product.published ウェブフックトピックの追加や、商品管理権限のないユーザーに対する機密フィールド（ダウンロード、売上原価、仕入メモ）の除外など、セキュリティ面の強化も図られている。
データベースの更新と注意点
このリリースにはデータベース更新が含まれている。自動実行されるスケジュール更新の中では、ブロックメール投稿への同期メタデータ付与、WooCommerce 10.5で名称変更された分析データのインポート設定復元、meta_key_value 索引の調整、レビュー依頼用の専用ランディングページ作成などが行われる。
10.8の更新前には必ずサイト全体のバックアップを取得し、ステージング環境での事前テストを推奨する。またWordPress 6.9以上が必須条件となるため、WordPress本体のバージョンも事前に確認しておく必要がある。
この記事のポイント
- WooCommerce 10.8は購入後のレビュー依頼メールを自動化し、確認済み購入者のレビュー収集を効率化する
- 管理画面のオフライン検知機能が追加され、ネットワーク不安定環境でのデータ消失リスクが低減した
- クーポンコードの自動生成やメールテンプレートのリセット機能で運用負荷を下げられる
- SQLクエリの削減とキャッシュプライミングの拡大により、ストアフロントの応答速度が向上する
- GraphQL APIの導入はヘッドレス構成やモダンフロントエンド開発への対応を見据えた布石となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Google APIキーを守る3つの基本手順、悪用と高額請求のリスクを下げる
Google Geminiを含むAIサービスやGoogle Cloud APIを利用する上で、APIキーの安全な管理は避けて通れない課題だ。適切な対策を怠ると、キーの漏洩や悪用により、高額な請求やプロジェクト環境の侵害を引き起こす可能性がある。
APIキーは「使うのは簡単だが、安全でない方法で使うのも同じくらい簡単」とGoogle Cloud Blogの著者Leonid Yankulin氏は指摘する。この記事では、Googleが提供するAPIキーのリスクを大幅に下げるための、すぐに実践できる具体的な手順を解説する。
これらの対策の多くは、Googleに限らず他のサービスで発行されるAPIキーやプロダクトトークンにも応用可能だ。個人開発者から組織の管理者まで、キーの取り扱いを見直すきっかけにしてほしい。
Step 1. 新しいAPIキーは「隔離」と「制限」が大前提
APIキーを作成する際、最初からセキュリティを考慮しておくことで、後々のトラブルを未然に防げる。「とりあえず作成」して放置されている無制限のキーが、組織における最大のリスク要因の一つだ。
キーは専用プロジェクトで作成する
新しいAPIキーを生成する最初のルールは、他の目的に使っていない独立したGoogle Cloudプロジェクト内で作成すること。これにより、仮にキーが漏洩しても、被害がそのプロジェクトのリソースに限定される。
プロジェクトを分けることは、問題発生時の原因特定と影響範囲の調査を大幅に容易にする。本番環境と同じプロジェクトで実験用のAPIキーを発行するといった行為は避けるべきだ。
API制限で「できること」を絞る
APIキーを作成する際、デフォルトではAPI制限がかかっていない。これは、そのキーが有効化されているすべてのサービスにアクセスできる状態を意味する。Google Cloud Blogの著者は「制限のないキーを絶対に作るな」と強調する。
API制限を設定することで、キーがアクセスできるサービスを特定のAPIだけに絞り込める。たとえば、AI Studioで利用するなら「Gemini API」のみ、地図機能だけが必要なら「Maps API」だけに制限する。漏洩時の攻撃範囲を最小化する考え方だ。
注意すべき副次的なポイントとして、AI StudioやFirebaseなど間接的なUIからキーを作成した場合、意図しないAPI群が自動で許可されているケースがある。Firebase経由で作ったキーは24ものAPI（DatastoreやFirestore、Cloud SQLなど）へのアクセスが許可されるため、不要なものは手動で外す必要がある。
制限したいAPIが一覧に表示されない場合は、そのAPIが対象プロジェクトで有効化されていない可能性が高い。APIライブラリから事前に有効化しておく必要がある。
アプリケーション制限で「使う場所」を縛る
API制限が「どのサービスを使えるか」を制御するのに対し、アプリケーション制限は「どのアプリからキーを使えるか」を制御する。こちらも併用することで、セキュリティは飛躍的に高まる。
たとえばAI Studio専用のキーなら、許可するウェブサイトを aistudio.google.com に限定すれば、他のスクリプトや自動化ツールから大量のトークンを消費されるリスクを防げる。指定できる制限タイプは以下の4種類だ。
- ウェブサイト、許可するURLのリストを指定
- サービス（IPアドレス）、IPv4やIPv6アドレス、サブネットマスクで指定
- iOSアプリ、バンドルIDで指定
- Androidアプリ、パッケージ名と証明書フィンガープリントのペアで指定
注意点として、1つのキーに設定できるアプリケーション制限タイプは1種類だけ。複数のアプリ種別で利用する場合は、それぞれ専用のAPIキーを発行する。キーをアプリごとに分けておけば、利用状況の監視や侵害発生時の調査も容易になる。
ウェブサイト
https://aistudio.google.com自動化スクリプトからの呼び出し、不明なIPアドレスからのリクエスト、許可リストにないWebサイト
Step 2. APIキーは「誰でも使える」前提で保管する
APIキーの最大の特性は、特定の個人アカウントと紐づかない点にある。Google Cloud Blogの記事で「誰でも使える」と強調されているように、キー文字列を知っていれば誰でもその権限でAPIを呼び出せる。保管の安全性の重要性はAPI制限と同等だ。
「APIキーを絶対に、見えやすい場所に保存してはいけない」という基本ルールはシンプルだが、実際の開発現場ではしばしば破られている。ソースコードへのハードコードや、Gitリポジトリへの平文でのコミットは典型的なミスだ。
自社アプリケーションではSecret Managerを使う
Google Cloudを利用しているなら、Secret Manager（シークレットマネージャー）のような専用の機密情報管理サービスにキーを格納するのが鉄則だ。Secret Managerを使えば、APIキーをCloud RunやGKEの実行環境に安全に注入できる。
さらに保護レベルを上げたい場合は、キーを環境変数に渡すのではなく、アプリケーションコード内でSecret Managerから直接読み取る方式も選択肢になる。これによりランタイムメモリへの露出時間をさらに短縮できる。
外部アプリケーションではキーの取り扱いを事前調査する
サードパーティ製のツールやサービスにAPIキーを入力する場合、そのアプリケーションがキーをどのように保管し、通信しているかを確認する必要がある。
Webアプリケーションであれば、ブラウザの開発者ツールを使ってトラフィックを調査し、キーが暗号化されていない通信経路で送信されていないかを確認する。「Google AI Studioは暗号化されたローカルストレージを使用し、TLS暗号化チャネル経由でのみキーを送信する」とYankulin氏は具体例を挙げている。こうした設計を満たしていないツールへのキー提供は避けるべきだ。
異常を検知したら「即削除」、調査の手順も把握する
どんなに対策を施しても、キーが侵害される可能性はゼロにはできない。迅速な初動対応が被害を最小化する鍵を握る。Yankulin氏は「クレジットカードを無くしたときと同じように、まずキーを削除すること」と述べている。
Cloudコンソール、または gcloud services api-keys delete コマンドで即座にキーを無効化する。誤報だったと判明した場合でも、削除から30日以内であれば undelete コマンドで復元が可能だ。
侵害されたキーを特定する2段階調査
どのAPIキーが侵害されたか不明な場合は、以下の2段階で調査を進める。
第一段階、組織またはプロジェクト内のすべてのAPIキーを洗い出す。Cloudコンソールの「Asset Inventory」でリソースタイプを apikeys.Key に絞り込む方法と、gcloud services api-keys list コマンドを使う方法がある。組織全体を横断検索する場合は gcloud asset search-all-resources コマンドでJSON出力をフィルタリングする。
第二段階、API消費量のグラフを確認する。Cloud Monitoringの指標 serviceruntime.googleapis.com/api/request_count を使い、credential_id ラベルで特定のAPIキーIDに絞り込む。リクエスト数が異常に急増している場合、そのキーが悪用されている可能性が高い。
APIキーIDは、Cloudコンソールの「Credentials」ページでキーを選択した際のURL（/key/[KEY_ID] 部分）から、または gcloud services api-keys list --format='value(displayName,uid)' コマンドで確認できる。
1時間あたり数千リクエスト。日次グラフはなだらかで安定した波形
1時間あたり数十万リクエストに急増。短時間で不自然なスパイクが出現
Step 3. 日常的な「APIキー衛生管理」を習慣化する
エンジニアだけの話ではない。クラウドをかじり始めたばかりの個人ユーザーも、今すぐAPIキーの「衛生管理」を始めるべきだ。放置されたキーは、知らぬ間に悪用の温床となる。
Yankulin氏が推奨する即時実行すべきアクションは以下の5つだ。
- 自分が保有するすべてのAPIキーを洗い出す
- 使っていないキー、見覚えのないキーはすべて削除する（30日以内なら復元可能）
- 残すキーは、利用するAPIだけに制限し、可能ならクライアントも絞り込む
- 組織の管理者は
apikeys.googleapis.com/Keyの組織ポリシーを設定し、キーの乱立と制限設定の抜けを防ぐ - 定期的なキーのローテーション（再発行と差し替え）を検討する。ただし、既存キーを削除する前に、すべての利用箇所を特定して新しいキーに更新する周到さが必要だ
キーローテーションの際に「既存キーがどこで使われているのか把握しきれていない」という問題に直面するケースは多い。日頃からキーの利用箇所をドキュメント化しておくこと、そして新しいキーの発行時点から適切な制限をかけておくことが、結果的にローテーションのハードルを下げる。
この記事のポイント
- APIキーは「誰でも使える」クレデンシャル。見える場所に保管しないことが大前提
- 新規キー作成時は、API制限とアプリケーション制限を両方設定して攻撃の範囲を狭める
- 保管にはSecret Managerなど専用の機密情報管理サービスを使い、コードへのハードコードを避ける
- 使っていないキーや制限のないキーは即座に削除し、組織ポリシーで乱立を防ぐ
- 侵害が疑われる場合はクレジットカードと同じ感覚で「まず削除」。監視データで異常を検知する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験