AIアプリを作ったら，次は安全に公開して運用する番だ．APIキーの扱い・コスト管理・レート制限── ここを外すと一晩で破産しかねない．
対象はLLMを使ったアプリを作る個人開発者．読み終えたとき，AIサービスをVPSで安全・安価に運用する設計の勘所が掴めます．
なぜAIアプリこそ運用設計が重要か
AIアプリは1リクエストの単価が高い．悪用やバグで呼び出しが暴走すると，従量課金が一気に膨らむ．
またAPIキーは超高価な鍵だ．フロントに埋め込めば即座に盗まれ，悪用される．運用設計が品質と存続を直接左右する．
方式1：API型 ― VPSをバックエンドの盾にする
最も現実的なのが外部LLM APIをVPS上のバックエンド経由で呼ぶ構成だ．APIキーをサーバー側に隠し，フロントには絶対に出さない．
VPSのバックエンドが認証・レート制限・ログを担い，APIキーは環境変数で管理する．これがAIアプリ運用の基本形だ．
方式2：自前推論 ― 軽量モデルをVPSで動かす
小さめのモデルなら，VPS上で推論を自前ホスティングする選択肢もある．従量課金から解放され，固定費で運用できる．
ただしメモリ・CPU(場合によりGPU)要件が上がる．用途に対してスペックが足りるか，事前に見積もる．
ステップ：APIキーをサーバー側に隠す
キーは.envに置き，バックエンドからのみ参照する．フロントのコードやリポジトリには絶対に入れない．
サーバー側でのみキーを使う（イメージ）
# .env （Gitには入れない）
LLM_API_KEY=sk-xxxxxxxx
# サーバー側コードから参照
const key = process.env.LLM_API_KEY; // フロントには渡さないステップ：レート制限とコスト上限を必ず置く
暴走対策は必須だ．IP/ユーザー単位のレート制限と，1日あたりの呼び出し上限を設ける．
Nginxで簡易レート制限
limit_req_zone $binary_remote_addr zone=ai:10m rate=10r/m;
location /api/chat {
limit_req zone=ai burst=5 nodelay;
proxy_pass http://127.0.0.1:3000;
}ステップ：ストリーミングとタイムアウトを設定
LLMの応答は遅く長い．ストリーミングでUXを保ちつつ，リバースプロキシのタイムアウトを延ばす必要がある．
タイムアウトが短いと長文生成が途中で切れる．プロキシとアプリ双方の設定を合わせるのが詰まりやすいポイントだ．
補論：AI運用は「固定費の予測可能性」が効く
AIアプリの怖さはコストの予測不能性だ．サーバー側だけでも固定費で確定できれば，価格設計と収支の見通しが立てやすくなる．
高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ は固定料金でNVMe SSD＋十分なメモリを確保でき，バックエンドの盾・レート制限・ログ集約を1台に集約できる．軽量モデルの自前推論を試す検証環境としても，後からメモリを増やせるので拡張に強い．
AIサービスを独自ブランドで公開するなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ のドメイン＋HTTPSで信頼感のある入り口を整えよう．
よくある質問
Q1：APIキーをフロントに置くと何が起きる？
即座に抜かれて悪用される．ブラウザのコードは誰でも見られる．キーは必ずサーバー側に隠し，フロントはバックエンド経由で呼ぶ．
Q2：自前推論とAPI型どちらが安い？
呼び出し量による．少量ならAPI型，大量かつ軽量モデルで足りるなら自前推論の固定費が有利になりやすい．用途で判断する．
Q3：コスト暴走を防ぐには？
レート制限＋1日あたりの上限＋アラートの三段構えだ．加えて認証を必須にし，匿名の無制限呼び出しを作らないこと．
まとめ ― AIアプリは「鍵を隠し・上限を置く」が運用の核
AIアプリ運用の核心は，APIキーをサーバー側に隠し，レート制限とコスト上限を必ず置くこと．これだけで破産事故の大半は防げる．
まずはVPSにバックエンドを1つ立て，キーを隠してフロントから安全に呼ぶ構成を組もう．そこからレート制限・監視へ広げれば，AIサービスは安心して育てられる．