【ShinのAI活動ログ】「鍵が必要なAPI」と「鍵がいらないAPI」

Geminiに「Claudeと作った最新ニュースコンテンツ」について意見を聞いたら、APIキー管理の注意点を指摘されました。

自分のサイトの実装を振り返り、「API」という言葉の中身を整理した記録です。

Geminiからの指摘

返ってきた回答は、なかなか本格的でした。

NewsAPIやGoogle Custom Search APIといった選択肢を挙げつつ、「APIを使うなら、これだけは絶対に守ってほしい」という2つの注意点が添えられていました。

ひとつは、APIキーをフロントエンドのコードに直接書いてしまうと、ブラウザの検証ツールから誰でも見られる状態になってしまうという指摘。

もうひとつは、無料のAPIには必ず利用回数の上限があるので、毎回サーバーに取りに行く設計だとすぐに上限に達してしまうという指摘。

どちらも、言われてみれば確かに怖い話です。

「あれ、うちの実装は大丈夫なんだろうか」

そう思って、自分のサイトの実装を振り返ってみました。今のAIニュースコーナーは、OpenAIの公式RSSフィードと、Google Newsのキーワード検索結果をRSS形式で取得する仕組みで動いています。

ここでふと引っかかったのが、「これって結局、APIを使っているんじゃないの？」という疑問でした。Geminiの指摘がそのまま当てはまるなら、自分の実装にも同じ危険があるのかもしれません。

「API」という言葉の中身を整理する

調べて整理してみると、「API」という言葉自体は思っていたより広い意味を持っていることが分かりました。

サーバーにリクエストを送って、構造化されたデータが返ってくる仕組みは、広い意味ではすべて「API」と呼べます。

今使っているRSSフィードも、その意味では確かにAPIの一種です。

ただ、Geminiが警告していたNewsAPIやGoogle Custom Search APIは、もう一段狭い意味での「認証が必要なAPI」でした。APIキーを発行してもらい、それを使ってリクエストする仕組みです。

ここに大きな違いがありました。RSSフィードは誰でも自由にアクセスできる公開された仕組みで、キーも認証も必要ありません。つまり、そもそも「隠すべき秘密の鍵」自体が存在しないのです。

Geminiが心配していた「キーが流出する」というリスクは、鍵を使っていない今の仕組みには、最初から当てはまらないことになります。

もうひとつの指摘、利用回数の制限についても確認してみました。

これは前回の実装時にすでに対策済みで、取得したデータを30分間キャッシュしておき、毎回サーバーに取りに行かない設計にしていました。

同じ「API」という言葉でも、ずいぶん違う

振り返ってみると、「API」という同じ言葉を使っていても、指している仕組みはまったく別物でした。

認証が必要なAPIには、キーの管理という責任が発生します。漏れれば悪用されるリスクがあり、利用回数にも明確な上限があります。

一方、RSSのような公開された仕組みには、そもそも管理すべき秘密がありません。

便利な情報をもらっても、それが自分の状況にそのまま当てはまるかどうかは、一度立ち止まって確認してみる必要があるのだと、あらためて感じました。

今回は幸い、すでに対策済みだったので安心できましたが、言葉が同じだからといって油断はできないものです。