Lecture 11LLMやデータベース操作をAPIレイヤーで行う理由
AIやデータベースをブラウザから直接扱わない理由を理解します。
前回、API Keyは 家の鍵と同じ だと整理しました。 では、その鍵を どこで使うか はもっと大事な話です。 結論から言うと、AI APIやデータベースは ブラウザから直接呼ばない。 必ずサーバー側の APIレイヤー を経由させます。
このレクチャーでは、なぜ直接呼んではいけないのか、APIレイヤーは何をしているのかを レストランのホールと厨房に例えながら整理します。
1ブラウザに置いた情報はユーザーに見える
まず大前提として、ブラウザで動くコードはユーザーが覗ける と思ってください。 開発者ツールを開けばJavaScriptはそのまま読めますし、通信内容も全部見えます。 つまりブラウザは お店のレジ裏が丸見えのカウンター のような場所です。
だから「ユーザーには見せたくないもの」（API Key、DBの接続情報、社内ロジックなど）を ブラウザのコードに書くのは、金庫の暗証番号をレジに貼る のと同じことになります。
2悪い例：ブラウザから直接LLM/DBを呼ぶ
初心者が一番やりがちなのが、ブラウザの画面コードから直接 OpenAI API や データベースを呼んでしまう構成です。 動くことは動くのですが、3つの被害 が一気に降りかかります。
- API Keyが漏れる：ブラウザに鍵を置いた瞬間、誰でもコピーできる状態になる。
- DBが危険にさらされる：秘密の接続情報や管理用の鍵が漏れると、知らない人にデータを読まれたり書き換えられたりする。
- 料金が爆発する：鍵を拾った誰かがAI APIを叩き続け、月末に高額請求が届く。
公開してよい鍵もあります
サービスによっては、ブラウザで使う前提の「公開用キー」があります。 ただし、OpenAIのAPI KeyやDBの管理用キーのような秘密の鍵とは別物です。 迷ったらCodexに 「これはブラウザに出してよい公開用キーですか？」 と確認しましょう。
3良い例：APIレイヤーが「ロビー」を務める
解決策はシンプルで、ブラウザとLLM/DBの間に サーバー側の窓口 をひとつ挟みます。 これがAPIレイヤーです。レストランで言えば、お客がいるホールと、料理人と火がある厨房を分けるイメージです。
- ブラウザ（ホール）：「この文章を要約してほしい」とAPIレイヤーへ依頼するだけ。
- APIレイヤー（厨房の入口）：依頼を受け取り、自分が持っているAPI KeyでLLMを呼び、結果を返す。
- LLM / DB（厨房）：APIレイヤー経由でしか呼ばれない。鍵もここの中にある。
Next.jsなら、サーバー側で動くコードも同じプロジェクトに書ける のが強みです。 実装方法の名前は気にしなくてOK（後で「Route Handler」「Server Action」という言葉が出てきますが、 要は サーバー側で走るコードを置く場所 です）。
4APIレイヤーが守ってくれること
APIレイヤーは単なる「中継」ではありません。 鍵を隠すついでに もう2つの仕事 をしてくれます。
- 権限のチェック：「このユーザーは本当にこの操作をしてよいのか？」をログイン状態で判定できる。
- 料金や回数の制御：1人が連続でAI APIを叩けないように制限したり、ログを残したりできる。
- データの整形：LLMの返答からブラウザに渡してよい部分だけ取り出して返せる。
Codexにフロント実装を頼むときの一言
「LLMを呼ぶ機能を作って」と頼むと、たまにブラウザ側に直接書こうとすることがあります。 依頼するときは 「LLMの呼び出しはサーバー側（APIレイヤー）で実装してください」 と場所を明示する一言 を添えるのが安全です。
クライアントとサーバーの分担をCodexに整理してもらう
実装に入る前に、Codexに 方針だけ を説明してもらいます。 コードが出てくる前にこの一手間を入れると、後の認識ズレが減ります。
- 次の依頼文をそのまま投げる：
LLM APIを使う機能を作りたいです。 API Keyを安全に扱うため、クライアントとサーバーで処理をどう分けるべきか、 Next.js前提で初心者向けに説明してください。
- 返答から「鍵をどこに置くか」「ブラウザは何を送るか」「サーバーは何を返すか」の3点をメモする。
- 分からない単語が出てきたら「○○を初心者向けに言い換えてください」と追撃する。
5理解確認チェックリスト
- ブラウザに置いた情報はユーザーに見えると理解している。
- LLMやDBはブラウザから直接呼ばず、APIレイヤーを経由させると説明できる。
- APIレイヤーは「鍵を隠す」だけでなく権限や料金も守ってくれると知っている。