かつてフロントエンドのコードに直接埋め込んでも安全とされていた Google API キーが、意図せず Gemini API へのアクセス権限を持ってしまい、不正利用の対象になるリスクがセキュリティ企業 Truffle Security によって報告されました。
この問題について、Google はすでに対策に乗り出しており、新規 API キーの仕様変更や流出キーのブロックなどを進めています。
しかし、Google Cloud を利用して Google Maps や Firebase などを組み込んでいるプロジェクトで Gemini API を有効化している場合、過去に作成した公開状態の API キーを悪用される可能性があるため、管理者側での確認が推奨されています。
なぜ過去の API キーで Gemini が操作できてしまうのか
Google Cloud の API キー（「AIza」から始まる文字列）は、もともとプロジェクトの識別や課金管理のために設計されたものでした。
そのため、以前は Google マップの JavaScript API などを利用する際、HTML やクライアント側のコードにキーを直接貼り付けることが公式ドキュメントでも推奨されていました。
しかし、プロジェクト内で新たに「Generative Language API（Gemini API）」を有効にした場合、Google Cloud で新しく API キーを作成すると、デフォルトではすべての API にアクセスできる「制限なし」の状態になります。
そのため、昔の仕様に従って Web サイトに公開されている API キーが、自動的に Gemini API への認証情報として機能するようになってしまいます。
過去の仕様に従って適切に実装されたキーが、新しい AI サービスの導入によって意図せず強力な権限を持ってしまう点は、管理者にとって運用上の大きな落とし穴になり得ます。
不正利用によるリスクと被害の規模
Truffle Security によると、2025 年 11 月の時点でインターネット上に公開されているソースコードをスキャンした結果、金融機関やセキュリティ企業、さらには Google 自身の製品サイトも含め、2,800 以上の有効な API キーがこの権限拡大の対象になっていたことが確認されています。
もし悪意のある第三者がこの公開された API キーを取得した場合、開発者のインフラに直接侵入することなく、外部から Gemini API を実行することが可能になります。
これにより、プロジェクトオーナーが Gemini API 経由で保存したプライベートなデータやキャッシュにアクセスされたり、API の利用枠を使い果たされたりする危険があります。
Gemini の API 呼び出しはモデルやコンテキストウィンドウのサイズによって課金されるため、最悪の場合は 1 日に数千ドルの請求が発生する恐れもあります。
Google 側の対応と管理者側で必要な確認手順
この報告を受けて Google はすでに対策を実施しており、Google AI Studio 経由で新規作成される API キーは、デフォルトで Gemini 専用にスコープが限定されるようになったほか、流出が確認された API キーのブロックや、管理者へのプロアクティブな通知機能の実装が進められています。
とはいえ、Google Cloud や Firebase を利用している管理者としては、Google 側の対応を待つだけでなく、自身の環境をすぐに確認することをおすすめします。
まずは Google Cloud コンソールの「API とサービス」から、組織内の各プロジェクトで Generative Language API が有効になっているかを確認してください。もし有効になっている場合は、登録されている API キーの設定を見直す必要があります。
特に「制限なし」になっているキーや、許可された API に Generative Language API が含まれているキーが、JavaScript のコード内や公開リポジトリなどで外部に露出していないかチェックしてください。万が一公開されているキーを発見した場合は、直ちにキーを再発行して制限をかける必要があります。
まとめ
Gemini など AI 機能を手軽に既存のプラットフォームへ組み込めるようになった一方で、レガシーな認証情報の扱いが思わぬセキュリティホールを生む事例となっています。
API キーの権限やスコープについても定期的な監査を実施し、意図しないアクセス権が付与されていないか確認しておくことが重要です。
