個人開発の食生活管理アプリ：LLMコスト防御を3段階実装し、破産リスクから機能を保護した技術的工夫

本記事は、学生エンジニアが「Claude Code」を用いて開発している筋トレ管理Webアプリケーションにおける、AI食事入力機能の実装と、それに伴う高額なAPI利用料（LLMコスト）の防御策について詳細に解説しています。このアプリは、ユーザーが「鶏むね200gと白米茶碗1杯と卵2個」といった自然言語で食事を記述するだけで、AIが品目ごとのカロリーやPFC（タンパク質/脂質/炭水化物）を自動分解・記録する点が最大の特徴です。

しかし、LLMは従量課金制であるため、全ユーザーのAPI利用料を個人開発者が負担することになり、「悪意あるユーザーによる連打」などにより破産に至るリスクがあるという課題に直面しました。そこで筆者は「AIにどう投げるか」ではなく「いかに投げないか」を主眼に置いた3段構えのコスト防御システムを構築しました。

第一に、**入力文一致キャッシュ（lru-cache）**を導入し、同じ食事内容を再入力するユーザーに対しては課金を免除しています。第二に最も重要なのが、**ローカル食品DBによる事前解決機構**です。APIを呼び出す前に、手元の食品成分表やコミュニティ承認済みデータで解析を試み、ここで解決できればAPI消費をゼロにします。この際、「誤変換」を防ぐため、照合は完全一致または前方一致が保証される場合に限定し、曖昧な場合は必ずLLMに渡すという保守的な設計を採用しています。

さらに、複数品目の区切り文字（「と」など）の問題に対し、記号区切りでの試行後、「と」を含む食品名が壊れないよう工夫した2段構えの分割ロジックを適用しています。第三に、**1日あたりの利用上限（物理キルスイッチ）**としてUpstash Redisを用いて実装し、不正な過剰利用を防いでいます。

また、AI解析によって得られた食品データは自動的に共有DBに登録され、プロダクトの利用が進むほど平均API消費が低下するという「使われるほど安くなる」構造を実現しています。さらに、コミュニティからの食品投稿承認プロセスも、Supabase Webhookとメール内のボタンタップによる署名検証（HMAC）で自動化し、運用負荷を大幅に軽減させています。

---

背景

個人開発者がAI機能を搭載したWebアプリを公開する際、LLMの従量課金制は大きなリスクとなります。特にユーザーからの予期せぬ大量アクセスや悪意ある利用は、開発者個人の経済的破綻に直結するため、コスト管理と防御策が必須となります。

重要用語解説

• LLM: 大規模言語モデル（Large Language Model）の略称。自然言語を理解し、生成するAI技術全般を指します。本記事では、食事内容の構造化解析に使用されています。
• 従量課金: 利用した分だけ料金が発生する支払いシステムのこと。APIサービスにおいて、処理回数やデータ量に応じて費用が変動することを意味します。
• lru-cache: Least Recently Used Cache（最も最近使われていないもの）を指すキャッシュ機構。頻繁にアクセスされるデータを一時的に保存し、再利用することでAPI呼び出し回数を削減する技術です。

今後の影響

本手法は、個人開発者がAI機能を搭載したプロダクトを商業レベルで安定運用するための具体的なベストプラクティスを提供します。ローカル知識による事前解決と段階的な防御策の組み合わせにより、コスト効率が高く、持続可能なサービス設計が可能となります。