LLM を使うアプリを公開する前に、必ず固めておきたいのが API キー管理・ユーザー認証・課金（使用量計測）の 3 点です。ここが甘いと、キー漏洩による不正利用や、トークン課金がそのまま跳ね返るコスト暴走に直結します。LLM アプリで本当に怖いのは「動かない」ことより、「動きすぎて事故になる」こと。本ガイドは、初めて本番運用に踏み出す人向けに、要所を図とともに整理します。
FIG.1 キーはクライアントに渡さず、自社サーバを必ず挟む。サーバが「誰が」「どれだけ」使ったかを記録する
01API キー管理が最優先
LLM API を呼ぶための鍵（API キー）は、流出すると第三者があなたの請求でモデルを呼び放題になります。OpenAI は公開リポジトリや公開ページ上でキーを検知すると自動的に無効化する仕組みを持っていますが、検知前に使われた分の請求は残ります。まず守るべきは次の原則です。
- キーはサーバー側の環境変数 / シークレットマネージャ（AWS Secrets Manager、Google Secret Manager など）で保持する
- クライアント（ブラウザ・モバイルアプリ）やリポジトリに絶対に置かない。フロントから直接 LLM API を叩く設計にしない
- 環境・用途ごとにキーを分け、漏洩時はそのキーだけを即ローテーション（再発行）できるようにする
- 使用上限とアラートを必ず設定する（コスト暴走の防止）
2026 年時点の OpenAI は、キーがプロジェクト単位に紐づく方式になっています。新しいキーは sk-proj- から始まり、特定プロジェクト内にスコープされます（旧来の sk- 形式は段階的に廃止）。キーごとに All / Restricted / Read Only の権限を設定でき、用途別に分けることで「どの機能がどれだけ使ったか」も把握しやすくなります。
02人のキーとシステムのキーを分ける
本番運用では、開発者個人に紐づくキーをそのまま使い続けないのが定石です。OpenAI / Anthropic などは、人ではなく仕組みに紐づくサービスアカウント用のキーを用意できます。担当者の退職や権限変更でアプリが止まらず、CI/CD・バックグラウンドワーカー・本番サービスに向いています。
| 個人キー（personal） | サービスアカウントキー |
|---|---|
| 個人アカウントに紐づく | 人ではなくプロジェクト / システムに紐づく |
| 手元の検証・試作に向く | 本番・CI/CD・常駐ワーカーに向く |
| 担当者が抜けると失効リスク | 担当者の異動・退職の影響を受けにくい |
運用の目安は「環境ごとに 1 プロジェクト（dev / staging / prod）」「連携先ごとに 1 サービスアカウント」。さらに未使用キーが放置されないよう、ラベル付けと有効期限・棚卸しのルールを決めておくと安全です。なお、キーの共有は禁止。チームに人を増やすときはメンバー招待し、各自が自分のキーを持つのが正しい運用です。
03認証：誰が呼んだかを必ず識別する
キーを守っても、自社サービスの入り口が誰でも自由に叩ける状態だと意味がありません。LLM のような1 リクエストごとにお金がかかる機能では、ユーザー認証で「誰が呼んだか」を必ず特定します。
本人確認（認証）
ログイン（セッション / JWT / OAuth など）で利用者を特定する。匿名でも使わせる場合はデバイス・IP 単位で識別子を持たせる。
権限確認（認可）
未認証・無料枠のリクエストに、高価なモデルや長文コンテキストを叩かせない。プランに応じて使えるモデルを出し分ける。
濫用検知
レート制限と異常検知を組み合わせ、短時間の大量リクエストや無料枠の使い回しをブロックする（次章）。
04課金設計：トークン従量原価を価格に織り込む
LLM の API は処理したトークン量で課金されます。同じ「1 リクエスト」でも、入力・出力の長さで原価が大きく変わるのが普通の Web API との決定的な違いです。料金は頻繁に改定されるため必ず公式の最新値を確認すべきですが、2026 年の相場感をつかむと設計しやすくなります（いずれも 100 万トークンあたりの目安）。
| 入力（input） | 出力（output） |
|---|---|
| 主力モデル：おおむね $2.5〜$5 前後 | 主力モデル：おおむね $15〜$25 前後 |
| 軽量モデル：$0.1〜$0.25 程度と桁違いに安い | 軽量モデル：$0.4〜$1.25 程度 |
| 高性能 / Pro 系：さらに数倍〜十数倍 | 推論（thinking）型は「考えるトークン」で実コストが膨らむ |
出力トークンは入力の数倍高いのが一般的で、推論モデルは見かけの単価に加えて内部の思考トークン分（実質 3〜9 倍になることもある）を見込む必要があります。だからこそ、この従量原価を価格に織り込み、ユーザー単位で計測・上限管理することが課金設計の核になります。
FIG.2 原価＝入力トークン＋出力トークン。出力は単価が高く、回答が長いほど跳ねる
具体的な課金モデルは大きく次の 3 列で考えると整理できます。
従量課金
使ったトークン / 回数に比例して請求。Stripe などはトークン使用量を取り込み、自社マークアップを乗せて自動計上できる。
クォータ制
プランごとに上限を決め、超過は停止または追加課金。無料枠＋有料枠の二段構えが定番。
BYOK
ユーザー自身の API キーを使わせる方式。原価は利用者負担になるが、キー預かりの責任が生じる点に注意。
いずれの方式でも、ユーザー単位の使用量計測がすべての土台です。「誰が・どのモデルを・何トークン使ったか」をリクエストごとに記録しておけば、課金・上限・異常検知のすべてに使い回せます。
05レート制限はトークン単位で考える
普通の API では「1 分あたり N 回」のようにリクエスト回数で制限しますが、LLM では 1 回あたりの重さが大きく違うため、トークン量（処理量）ベースの制限が効きます。回数だけ見ていると、長文を投げ続けるユーザーにコストを食い荒らされます。
- ユーザー単位のクォータ：認証済みユーザーごとに「一定時間あたりのリクエスト数 / トークン数」を割り当てる
- トークン単位レート制限：処理トークン量・コストで制限し、特定ユーザーの資源独占を防ぐ
- 無料枠の濫用対策：複数アカウント作成・短時間の大量実行を検知してブロック
LLM API の制限は回数ではなく 「処理したトークン量」で測るのが本質。
Cost & Leak Safety
一番怖いのは「キー漏洩」と「コスト暴走」
事故の典型は 2 つ。ひとつはキー漏洩（フロントに埋め込む / リポジトリにコミット）、もうひとつはコスト暴走（上限・アラート未設定で気付いたら高額請求）。どちらも「上限」と「監視」で被害を最小化できます。下図のように、サーバ側にコスト上限のゲートを置き、しきい値でアラートと自動停止を効かせます。
FIG.3 しきい値（例：上限の 80%）で通知、上限到達で自動停止。コスト枯渇攻撃も早期に検知できる
あわせて、キーは最小権限（Read Only / Restricted を使い分け）、重要操作は要承認、ログには誰が何を問い何が返ったかを残します。LLM は事実をそれらしく捏造する（ハルシネーション）ため、出力をそのまま信頼せず一次情報で検証する前提も忘れないでください。
06コストを賢く下げる
計測と上限を入れたら、次は原価そのものを下げる工夫です。設計段階で効くものから手を付けます。
- プロンプトキャッシュ：繰り返す前提文をキャッシュすると、その部分の入力単価が大きく下がる（再利用が多いほど効く）
- バッチ処理：即時性が不要な処理はバッチに回すと単価が下がる場合がある（提供元による）
- モデルの出し分け：簡単な処理は軽量モデル、難しい処理だけ高性能モデルへ。これだけで支出が大幅に減ることが多い
- 出力の抑制：最大出力トークンを絞り、不要な長文回答を防ぐ（出力は単価が高い）
「主力モデルで全部こなす」より、用途ごとに最小限のモデルへ振り分けるほうが、品質を保ったまま費用を抑えられます。
07本番前チェックリスト
公開前に、次の項目をひとつずつ確認しましょう。3 点（キー・認証・上限）が揃っていれば、よくある事故の大半は防げます。
- キーはサーバ側のシークレット管理に置き、フロント / リポジトリに無いか
- 環境・用途別にキーを分け、最小権限とローテーション手順があるか
- 本番はサービスアカウントキーで動かしているか
- すべての LLM 呼び出しに認証が必須で、未認証に高価なモデルを叩かせない設計か
- ユーザー単位で使用量を計測し、トークン量ベースのレート制限・クォータがあるか
- 使用額のしきい値アラートと上限（自動停止）が設定されているか
- 誰が何を問い何が返ったかのログがあり、出力は一次情報で検証する運用になっているか
08まとめ
LLM アプリの本番化は、機能の作り込み以上にキー・認証・課金（計測と上限）の地味な土台づくりが勝負です。キーはサーバに隠し、誰が呼んだかを必ず識別し、トークン量で計測して上限とアラートをかける——この 3 点を最初に固めるだけで、漏洩・コスト暴走という二大事故をぐっと遠ざけられます。まずは「上限とアラートの設定」から、今日できるところを 1 つ進めましょう。
