投稿者 global-ai-media 
Google Mapsなどで使用されていたクライアントサイドのAPIキーが、設定不備によりGemini APIへのアクセス経路となるリスクが報じられました。本稿では、この事例を単なるプラットフォーム固有の問題としてではなく、日本企業が既存システムに生成AIを組み込む際に陥りやすい「権限管理の死角」として解説します。
「無害」だったはずの鍵が、生成AIへの通用口に
Bleeping Computerをはじめとするセキュリティメディアが報じたところによると、かつてGoogle MapsなどのサービスをWebサイトに埋め込むために使用されていたGoogle APIキーが、適切な制限（スコープ設定）がなされていない場合、Googleの生成AIモデル「Gemini」へのアクセスに使用できる可能性があることが指摘されています。
従来、地図表示などのフロントエンド（利用者のブラウザ側）で動作する機能のために、JavaScriptコード内にAPIキーをハードコーディングすることは、キーに対して「Maps APIのみ利用可能」といった制限をかけている限り、許容されるリスクとして扱われてきました。しかし、同じGoogle Cloudプロジェクト内で新たにGemini APIを有効化し、かつ古いAPIキーの権限範囲を再確認せずに放置していた場合、そのキーは外部からGeminiを利用するための「通用口」となってしまいます。
なぜこれが日本企業にとってのリスクとなるのか
この問題は、単にGoogle Cloudの設定ミスの話にとどまりません。多くの日本企業において、長年運用されているWebサービスや社内システム（レガシー資産）と、近年急ピッチで進められているDX・AI推進プロジェクトが、技術的にも組織的にも複雑に交差している現状を浮き彫りにしています。
例えば、広報部門が管理するWebサイト（地図埋め込みあり）のクラウド環境を、情報システム部門やDX推進室が「既存のリソースがあるから」という理由で生成AIのPoC（概念実証）環境として相乗り利用するケースです。ここで「とりあえず動かす」ことを優先し、古いAPIキーの権限を見直さないままAIサービスを有効化すると、Webサイトのソースコードを見れば誰でも会社のクレジット（費用）でLLM（大規模言語モデル）を実行できる状態になりかねません。
生成AI、特にLLMのAPIコールは、従来のAPIに比べて1リクエストあたりのコストが高額になりがちです。攻撃者にキーを盗用され、踏み台として大量の推論を実行されれば、数日で莫大なクラウド破産（Denial of Wallet）を招くリスクがあります。
フロントエンドとAIの境界線
技術的な観点から見ると、これは「AI機能の実装場所」に関する原則の再確認を迫るものです。Google Mapsのようなサービスはクライアントサイドでの直接実行が前提でしたが、OpenAIやGeminiなどのLLM APIは、原則としてサーバーサイド（バックエンド）から呼び出すべきものです。
APIキーをフロントエンドに露出させないためには、BFF（Backend for Frontend）パターンを採用し、サーバー側で認証とAPIコールを行い、クライアントには結果だけを返す構成が推奨されます。日本国内でもAIチャットボットなどを内製する動きが活発ですが、Web開発の経験が浅いデータサイエンスチームが主導する場合、このあたりのWebセキュリティの基本（APIキーの隠蔽と権限分離）が疎かになるケースが散見されます。
日本企業のAI活用への示唆
今回の事例を踏まえ、AI活用を進める日本企業のリーダーやエンジニアは、以下の3点について改めて点検を行うべきです。
1. 「ついで使い」の廃止と環境分離
既存のクラウドプロジェクトにAI機能を追加するのではなく、AI開発専用のプロジェクトを新規に払い出し、課金枠や権限を完全に分離することを推奨します。これにより、レガシーシステムの脆弱性がAIプロジェクトに波及するリスクを遮断できます。
2. 最小権限の原則（Least Privilege）の徹底
APIキーには必ず「特定のAPIのみ利用可能」「特定のリファラー（URL）からのみ利用可能」といった制限（Restriction）を明示的に設定してください。「全てのAPIを許可」というデフォルト設定は、開発中であっても避けるべきです。
3. ガバナンスにおける「棚卸し」の実施
AI導入を急ぐあまり、新規開発ばかりに目が行きがちですが、既存の公開資産（Webサイトやアプリ）に含まれるクレデンシャル（認証情報）が、現在のAI環境に対してどのような権限を持っているか、セキュリティチームと連携して棚卸しを行う必要があります。