自社で AI proxy を運用してわかったこと

私たちは、アプリから大規模言語モデル（LLM）を安全に使うために、自社で AI proxy サーバを構築・運用しています。本番で動かす中で見えてきた設計の勘所を、技術ブログとして共有します。

なぜアプリから直接 LLM を呼ばないのか

LLM の API キーをアプリに埋め込んで直接呼び出す、というのは避けるべき設計です。アプリのバイナリは解析され得るため、鍵が漏れれば誰でも課金を悪用できてしまうからです。

そこで、アプリと LLM のあいだに自社の proxy を挟みます。鍵は proxy サーバ側だけが持ち、アプリは proxy に話しかける。これだけで、鍵の保護・利用制御・ログ管理を一元化できます。

「正規利用かどうか」を入口で確かめる

proxy を置く最大の利点は、リクエストを受ける入口で検証できることです。私たちの構成では、Apple が発行する購入レシート（JWS 署名）を proxy 側で検証し、正規にサブスクリプションを購入したユーザーのリクエストにのみ応答します。

これにより、

• 不正なクライアントからの呼び出しを入口で遮断
• 課金していないユーザーがプレミアム機能を使う「迂回」を防止
• モデルの切り替えや利用上限の管理を proxy 側で完結

といった制御が、アプリを更新しなくても行えるようになります。

実装したものだけを語る

AI を扱ううえで私たちが徹底しているのは、実際に動いているものだけを訴求するという姿勢です。「AI が補足説明します」とうたうなら、本物の LLM が裏で動いていなければならない。テンプレートを返すだけの“なんちゃって AI”を AI と称することはしません。

医療に近い領域では、この線引きはとりわけ重要です。誇張のない実装と、正直な説明。AI proxy の運用は、その原則を技術として体現する取り組みでもあります。