社内イベント向けにRAG（Retrieval Augmented Generation、検索した文書をもとにLLMが回答を生成する仕組み）を個人開発し、100人超が同時利用する規模まで無償で運用した事例が話題になっています。インフラ予算ゼロ、ノートPCを本番サーバー代わりにするという構成です。バックエンドの工夫が中心の内容ですが、フロントエンドやWeb技術の観点から見ても、同時接続数の制御やAPIゲートウェイの設計は他人事ではありません。
同時多接続のWebアプリを個人や小規模チームで作ろうとしている方、あるいは無料枠のLLM APIを使ってプロトタイプを本番運用に近づけたい方に向けて、この事例が示す技術的なポイントを整理します。
何が起きていたか
発端は単純でした。社内の企業研究資料をイベント参加者に配布する代わりに、AIに質問できるシステムを作ろうという発想です。
PDFを取り込み、チャンク（文書を検索しやすい単位に分割する処理）に分け、埋め込みベクトル化し、質問に応じて関連箇所を検索してLLMに渡す。RAGの基本構成自体は目新しくありません。問題は「同時に100人以上が使う」という要件でした。
有料APIを使う予算がなかったため、GoogleのGeminiを主モデル、OpenRouter経由のNemotronをフォールバック（主系が失敗したときの代替経路）として採用しています。無料枠のAPIには当然レート制限があり、1人のリクエストなら問題にならなくても、100人が同時に叩けば即座に詰まります。
APIレーン分割という工夫
ここで採られた対策が、単一のAPIキーに依存しない「レーン分割」です。Gemini用に10本、OpenRouter/Nemotron用に10本、合計20本のAPIキーを用意し、それぞれ独立したクォータ（利用上限）と同時実行数の制御を持たせています。
リクエストが来ると、LLMゲートウェイと呼べる中間層がどのレーンに振り分けるかを判断する構成です。1本のキーが枯渇しても、他の19本が生きていれば処理を続けられます。
これは技術的には目新しい発明ではありません。APIゲートウェイでの負荷分散やロードバランシング（負荷分散）は、Webサービスのバックエンドでは一般的な考え方です。ただし個人開発のRAGシステムでここまで意識的に実装している例は珍しく、無料枠APIの制約を前提にした現実的な工夫として参考になります。
複数ユーザーが同時にアクセスする状況を制御するため、PostgreSQLのロック機構（同時アクセス時にデータの整合性を保つ仕組み）も併用しています。これはリクエストの順序制御や重複処理防止に使われる典型的な手法です。
インフラとフロントエンドの接点
クラウドの料金を見て、結局ノートPCをそのまま「本番環境」にしてしまった点も特徴的です。ローカルで動かしたアプリケーションをngrok（ローカル環境を外部からアクセス可能にするトンネリングツール）で外部公開する構成を採っています。
フロントエンド開発者にとって、この構成が意味するのは「バックエンドの応答が不安定になりやすい」という前提です。ネットワーク経路がトンネル経由になるため、レイテンシ（応答遅延）のばらつきや、接続断のリスクは通常のクラウドデプロイより高くなります。
こうした環境では、フロントエンド側でのリトライ処理やタイムアウト設計、ローディング状態の丁寧な表示が普段以上に効いてきます。たとえばfetchのタイムアウトをAbortControllerで明示的に設定し、失敗時にユーザーへ「再試行してください」と分かりやすく伝えるUIを用意するだけで、体感の安定感は変わります。
チーム単位で1人あたり10問という質問数の上限も設けています。これはAPIコスト対策であると同時に、イベント終了後にプロンプトのログを分析して利用傾向を振り返る狙いもありました。フロントエンド側では、残り質問数をリアルタイムに表示するUIがあれば、ユーザーの体験として不満が出にくくなります。
二段階検索という設計思想
技術的に興味深いのは、単純な「関連しそうなチャンクを渡す」だけの検索から一歩進んだ点です。まず質問を解釈して検索計画を立てる段階、その後に実際に企業の知識ベースを検索する段階という二段階構成にしています。
さらに、システム内部の指示情報と、参加者に見せてよい企業文書を明確に分離する権限境界も設けています。これはRAGの実装でしばしば見落とされがちな設計で、検索対象のインデックスを用途ごとに分けておくと、意図しない情報漏えいを防ぎやすくなります。
フロントエンドの観点では、この二段階検索の存在をUI側にどう反映するかも論点になります。たとえば検索計画の中間結果を「今、こういう観点で調べています」とストリーミング表示できれば、LLMの応答待ち時間中の体感速度は大きく改善します。Server-Sent Eventsやfetchのストリーミングレスポンスを使い、中間ステップの進捗を段階的に返すAPI設計は、近年のAIチャットUIで広く採用されている手法です。
今日確認できること
同じような小規模構成を検討している場合、まず確認すべきは利用予定のLLM APIの無料枠の仕様です。Gemini APIやOpenRouterの公式ドキュメントで、1分あたり・1日あたりのリクエスト上限とモデルごとの違いを確認しておくと、レーン分割が必要かどうかの判断材料になります。
- 無料枠のレート制限（RPM/RPD）をAPI提供元のドキュメントで確認する
- 同時接続数の見積もりを立て、1本のキーで足りるか複数キーが必要か判断する
ngrokのようなトンネリングを使う場合、無料プランの帯域・接続数上限も合わせて確認する- フロントエンド側でタイムアウト・リトライ・ローディング表示を用意しているか点検する
- ユーザー単位・チーム単位の利用回数制限をUIに反映できているか確認する
複数APIキーを使ったレーン分割は、LiteLLMのようなオープンソースのLLMゲートウェイライブラリを使えば、自前実装より少ない工数で近い構成を組めます。個人開発で予算ゼロという制約があっても、既存のOSSを組み合わせることで実装コストを抑える選択肢がある点は覚えておいて損はありません。
まとめ
無料APIキーの制約とゼロ予算という条件下で、RAGシステムを100人規模で運用した設計は、APIゲートウェイによる負荷分散という一般的な技術を個人開発の文脈に落とし込んだ実例といえます。
フロントエンド開発者としては、バックエンドの不安定さを前提にしたUI設計、たとえばタイムアウト処理やストリーミング表示の工夫が、こうした構成では体感品質を大きく左右します。
まずは自分が使っているLLM APIの無料枠の制限値を確認し、同時接続数の見積もりと照らし合わせるところから始めてみてください。