競合どうしが同じAI基盤を奪い合う時代が、容量不足で一気に現実味を帯びました。
この記事では、GoogleがMetaのGemini利用を制限した報道の内容と、AIトークン節約がプロダクト運用に直結する理由を整理します。
この記事でわかること
- GoogleがMetaのGemini利用を制限した背景と時期
- Metaが社内でトークン効率化を求めている理由
- 開発者・AI運用担当が押さえるべき制限の仕組み
何が起きたか
2026年6月28日、英紙Financial Times（FT）は、GoogleがMetaのGemini利用に上限を設けたと報じました。CNBCも同内容を伝えています（参考）。
FTの関係者複数への取材によると、Metaが求めた計算容量の全量をGoogleが供給できず、2026年3月頃にMetaへ制限を伝えたとのことです。制限はMetaの社内AIプロジェクトの遅延や中断につながったと報じられています。Googleの他の顧客にも影響は及んでいますが、Gemini需要が特に大きかったMetaへの打撃が最も深刻だったとFTは述べています。
GoogleとMetaはCNBCの取材に対し、営業時間外のためコメントを控えたと報じられています。
なぜ容量不足が表面化したか
AIの処理単位であるトークン（入力テキストや画像をモデルが扱う最小単位）の需要は、社内ツールの普及と同時に急増しています。Metaは有害コンテンツの除去や詐欺検知など、安全性関連の処理にGeminiを使っていたとThe Next Webが報じています（参考）。自社のオープンソースモデルLlamaよりGeminiの精度が高かったため、外部モデルへの依存が進んでいた背景があります。
一方、Google側も供給能力に限界が見え始めています。2026年第1四半期の決算説明会で、CEOのSundar Pichaiは計算資源の制約がGoogle Cloudの成長を抑え、受注残高が前四半期比でほぼ倍増したと述べました。CNBCの報道でも同趣旨が触れられています。
さらにGoogleは、Gemini Enterpriseの需要増に対応するため、SpaceXに月額9億2,000万ドルで約11万台のNvidia GPUを借りる契約を結びました。Google Cloudの広報は、自社データセンターの建設だけでは間に合わない「橋渡し容量」だとCNBCに説明しています（参考）。年間1,800億ドル超の設備投資を計画する企業が、競合のインフラを借りる事態は、供給不足の深刻さを示しています。
Metaがトークン節約を求める理由
FTの報道では、制限を受けたMetaが社員にAIトークンの効率的な利用を促しているとされています。これは単なる社内ルールではなく、コストと開発速度の両方に直結する経営判断です。
トークン消費は、プロンプトの長さ、会話の往復回数、出力の分量に比例します。社内でAIを全社展開すると、モデル1回の呼び出しは小さく見えても、日次・月次で膨大な請求額になります。外部クラウドの上限に達すれば、新機能の検証やモデル評価が止まり、プロダクトのリリース計画そのものが遅れます。
Metaはこの制約を受けて、Superintelligence Labsが開発する自社モデルMuse Sparkへ業務を移す動きを加速させています。Muse Sparkは2026年4月にMetaが公式発表した推論モデルで、Meta AIアプリやmeta.aiで提供開始済みです（参考）。外部モデル依存を減らし、安全性やモデレーションなど重要ワークロードを自社基盤に載せ替える方針は、今回の制限以前から進んでいましたが、供給上限はその移行を前倒しする圧力になっています。
Geminiの利用制限はどう設計されているか
Googleの公式ドキュメントでは、Gemini APIの制限はプロジェクト単位で、主に次の3軸で管理されます。
- RPM（Requests Per Minute）: 1分あたりのリクエスト数
- TPM（Tokens Per Minute）: 1分あたりの入力トークン数
- RPD（Requests Per Day）: 1日あたりのリクエスト数
いずれか1つでも上限を超えると、APIは429 RESOURCE_EXHAUSTEDエラーを返します。APIキーを複数作っても、クォータはプロジェクトで共有されるため、キーを増やしても上限は広がりません。課金ティアが上がると制限は緩和されますが、公式ドキュメントは「記載された制限は保証されず、実際の容量は変動し得る」と明記しています。
今回のMetaへの制限は、公開されているAPIレート制限とは別レイヤーで、エンタープライズ顧客向けの計算容量配分に関する話です。ただし、一般の開発者にとっても教訓は同じです。AI機能をプロダクトに組み込む際は、レート制限・コスト上限・フォールバック先を設計段階から組み込む必要があります。
AI運用担当が今すぐ見直すべき点
大企業同士の話題に見えても、中小規模のプロダクトでも同型の問題は起きます。クラウドAIの契約枠は無制限ではなく、需要の急増は突然の429エラーや請求額の跳ね上がりとして現れます。
まず、利用ログでトークン消費の内訳を把握します。どの機能が最もコストを食っているかを数字で見ない限り、削減余地は見えません。次に、長いコンテキストの丸ごと投入を避け、要約やキャッシュで入力トークンを抑えます。出力長の上限設定や、バッチAPIの活用も有効です。Googleの公式ドキュメントでも、コンテキストウィンドウの縮小や短い出力でコストを抑えることが推奨されています。
複数モデルを使う場合は、精度が必要な処理と軽量モデルで足りる処理を分けます。MetaがGeminiからMuse Sparkへ移行しようとしているのと同じ発想で、単一モデルへの依存を避けることが、供給制限時の耐性になります。
業界全体に意味すること
FTの報道が示すのは、モデルの性能競争だけでなく、計算資源の配分競争が本番になったという事実です。チップ、データセンター、電力への巨額投資が続く一方で、AI需要の伸びが供給を上回っている状況は、Google Cloudの受注残高増やSpaceXとのGPU借り上げ契約からも裏付けられます。
広告で競合するMetaとGoogleが、AI基盤の顧客と供給者の両方の関係を持つ点も注目に値します。企業は自社モデル開発と外部API利用を併用しつつ、どちらか一方に過度に依存すると、今回のように開発計画が外部の容量判断に左右されます。AIプロダクトの企画段階では、モデル選定と同じくらい、トークン単価・レート制限・代替モデルの切り替え手順を要件に含めるべき局面です。