AIコーディングとエージェント

[バイブコーダー #2] APIとは何で、なぜAPIキーを隠すのか

前回はアプリをレストランにたとえました。ホール(フロントエンド)、厨房(バックエンド)、倉庫(DB)です。今回は、その構造の上でバイブコーディング中に最も事故が起きやすいAPIとAPIキーを扱います。「キーを絶対に公開しないでください」という警告はよく見ますが、そのキーが何で、どこにあり、漏れると何が起きるのかを説明する記事は多くありません。この記事でまとめて整理します。

読了 6 分
[バイブコーダー #2] APIとは何で、なぜAPIキーを隠すのかのカバー画像

前回はアプリをレストランにたとえました。ホール(フロントエンド)、厨房(バックエンド)、倉庫(DB)です。今回は、バイブコーディング中に最も事故が起きやすいテーマ、APIとAPIキーを扱います。「キーを絶対に公開しないでください」という警告は誰もが一度は見たことがあるでしょう。しかし、それが何で、どこにあり、漏れると何が起きるのかを説明する場は意外と少ないものです。今回は一度に整理します。

APIは注文カウンターです

APIはApplication Programming Interfaceの略ですが、正式名称は忘れても構いません。重要なのはこれです。APIはプログラム同士に仕事を依頼する注文カウンターです。

レストランのたとえに戻ると、お客さんは厨房に入れません。代わりに決められた形式で注文を出します。「キムチチゲを1つ、辛さ控えめで」。すると厨房が調理して提供します。APIはまさにこのカウンターです。決められたアドレスに決められた形式のリクエストを送ると、決められた形式のレスポンスが返ります。

バイブコーダーのアプリには、2方向のAPIがあります。

  • 自分のアプリのAPI:自分のフロントエンドが自分のバックエンドに仕事を依頼するカウンターです。前回登場したapp/api/フォルダーがこれに当たります。
  • 他社のAPI:自分のアプリが他社サービスに仕事を依頼するカウンターです。ChatGPTに文章を書かせる(OpenAI API)、地図を表示する(地図API)、決済を処理する(決済API)ことは、すべて他社のカウンターに注文を出す作業です。

バイブコーディングで作るアプリの多くは、この「他社のAPI」を組み合わせて動きます。そして他社のカウンターに注文するには、必ず必要なものが1つあります。

FRONTEND、MY BACKEND、EXTERNAL API間のリクエストの流れを示し、API KEYは.envとデプロイダッシュボードだけに置き、フロントエンドには絶対に置かない構成を描いた図
キーが通る道は、バックエンドから外部APIへ向かう1本だけです

APIキーは法人カードです

他社のAPIは無料のカウンターではありません。OpenAIへ1回リクエストするたびに費用が発生します。そこで各リクエストには「この注文の請求先は誰か」を示す身分証が付いています。それがAPIキーです。sk-proj-...のような、長くランダムな文字列です。

APIキーの性質は法人カードとまったく同じです。

  • 誰がカードを使っても、請求はカードの所有者に届きます。
  • カード番号さえ知っていれば使えます。顔認証も署名確認もありません。
  • だからカード番号を公開された場所に書くと、世界中の誰でも私のお金で決済できてしまいます。

「キーを隠せ」という警告が重い理由はここにあります。キーの漏えいはパスワードの漏えいとは違います。パスワードは変更すれば済みますが、キーは不正利用された時点から再発行までの料金がすべて自分の請求書に積み上がります。

漏れると実際に起きること

「自分の小さなアプリのキーを誰が見つけるんだ」と考えがちですが、これが最も危険な思い込みです。キーを探すのは人ではなくボットです。

「BOTS FIND LEAKED KEYS IN MINUTES」という文言とともに、公開コードリポジトリを巡回するボットがsk-キーを見つける場面のイラスト
キーを見つけるのは人ではなく、24時間動くボットです

GitHubのような公開コードリポジトリは、何千ものボットに24時間スキャンされています。誤ってキーを含むコードを公開リポジトリにpushすると、通常は数分以内にボットが収集します。収集されたキーはすぐに無料のAI呼び出し、暗号資産のマイニング料金、スパム送信などに使われます。一晩で数百万ウォンを請求された事例がコミュニティに絶えず投稿されるのはそのためです。

もう1つの漏えい経路は、前回扱ったものです。**フロントエンドにキーを入れること。**フロントエンドのコードはユーザーのブラウザーに送られるため、右クリックして「検証」を1回実行するだけで誰でもキーを取り出せます。AIに「OpenAIと連携して」と頼んだとき、AIが便宜上キーをフロントエンドに埋め込むことが実際にあるので、必ず自分で確認してください。

キーを置くべき場所

原則は前回すでに出てきました。**秘密情報はバックエンドに。**具体的には次のとおりです。

  • キーはプロジェクトの.envファイルに記述します。バックエンドだけが読み取る秘密の保管場所です。
  • .envファイルは.gitignoreに登録し、Gitが追跡しないようにします。これでGitHubにコードをpushしても、キーは自分のコンピューターにだけ残ります。AIが生成したプロジェクトでは通常登録されていますが、一度は自分で確認する価値があります。
  • デプロイしたアプリは自分のコンピューターの.envを読めないため、Vercelなどのデプロイサービスのダッシュボードにある「Environment Variables」メニューへキーを別途登録します。この話は第4回(デプロイ)で再び扱います。

Next.jsにはもう1つ落とし穴があります。環境変数名がNEXT_PUBLIC_で始まると、その値は**フロントエンドにも送信されます。**名前のとおりpublic、公開されるという意味です。地図表示用のキーのように公開してもよい設計のキーだけを置き、OpenAIなど料金が発生するキーには絶対にNEXT_PUBLIC_を付けてはいけません。AIが付けていたら、それ自体が危険信号です。

自分のアプリをセルフチェックする方法

今すぐ確認できるのは次の3つです。

  1. ブラウザー検証:デプロイ済みのサイトで右クリック → 検証を選び、上部のNetworkまたはSourcesタブでsk-keysecretなどの語を検索します。自分の秘密キーが見つかれば、漏えいしています。
  2. GitHub検査:リポジトリがPublicなら、リポジトリの検索欄でキーの先頭部分を検索します。過去のコミットに残っているだけでも漏えいです。
  3. AIに監査を依頼:「このプロジェクトでAPIキーや秘密の値がフロントエンドに送信される箇所をすべて探して」と依頼します。作成時にミスしたAIでも、探すときはうまく見つけてくれます。

すでに漏れてしまったら

漏れたキーは隠しても無意味です。ボットがすでにコピーしたと考える必要があります。手順は次のとおりです。

  1. 対象サービスのダッシュボードで、そのキーを**削除(無効化)**します。この瞬間から不正利用が止まります。
  2. 新しいキーを発行し、今度は.envとデプロイダッシュボードにだけ登録します。
  3. サービスの**使用量上限(spending limit)**を設定します。次の事故で受ける損害の上限になります。この話は第7回(料金爆発)で詳しく扱います。

まとめ

  • APIはプログラム同士の注文カウンターで、私のアプリは他社のAPIを組み合わせて動きます。
  • APIキーは法人カードです。誰が使っても請求は私に届きます。
  • キーはボットに数分で見つけられます。「自分のアプリは小さいから」は防御になりません。
  • キーを置く場所は、.env(ローカル)とデプロイダッシュボードの環境変数の、たった2か所です。NEXT_PUBLIC_が付いた従量課金キーは危険信号です。
  • 漏えいしたら隠さず、無効化 → 再発行 → 上限設定の順で対応します。

次回はGitです。AIがコードをすべて作ってくれるのに、なぜ皆がGitを使えと言うのか、そしてAIが正常なアプリを壊したときに1分で元に戻す方法を扱います。