自社のWebプロダクトに生成AI機能を組み込みたい。方針は決まったものの、「どんな構成で作るのが安全か」「どの順で進めればいいか」で手が止まる——生成AIのWeb実装では、最初の構成選びでつまずくとセキュリティやコストの問題を後から抱え込みます。

この記事では、生成AI機能をWebに組み込む実装を、構成の考え方からPoC・本番運用までのステップで解説します。手順を追えば、最低限の落とし穴を避けて進められます。組み込み前の全体像は生成AIのPoCが本番に上がらない理由、リリース後の品質維持は生成AI機能の評価・監視の始め方もあわせてご覧ください。

なお筆者・馬込は、生成AIを活用したWebアプリケーションをフロントからインフラまで一気通貫で構築してきました。本記事はその実務目線でまとめています。

結論：APIキーは「サーバー経由」で守る。まずここを外さない

生成AIのWeb実装で最初に押さえるべきは、構成です。LLMのAPI呼び出しは、必ず自社サーバー（バックエンド）を経由させます。ブラウザから直接APIを叩くと、APIキーが露出し、悪用と高額請求のリスクを負います。この原則を土台に、①サーバー経由の構成 → ②PoCで動かす → ③本番運用、と進めます。

手順1：サーバー経由の構成でAPIキーを隠す

まず、フロント（ブラウザ）→ 自社サーバー → LLM API という経路を作ります。APIキーはサーバー側の環境変数に持たせ、フロントには絶対に置きません。

  • APIキーは環境変数で管理し、リポジトリにコミットしない
  • フロントは自社サーバーのエンドポイントを呼び、サーバーがLLMへ中継する
  • サーバー側で入力の検証・利用制限（レート制限）をかける

この「サーバーで中継する」構成が、セキュリティとコスト管理の土台になります。ここを省いてブラウザから直接呼ぶ実装は、本番で必ず問題になります。

手順2：PoCで最小の一機能を動かす

構成が決まったら、いきなり作り込まず、最小の一機能をPoC（概念実証）として動かします。ここでの目的は、価値と実現性を早く確かめることです。

  • 一つのユースケース（例：要約、質問応答）に絞って動かす
  • プロンプト設計・出力の安定を先に確認する（プロンプト設計の基本参照）
  • この段階では作り込みより「使えるか」の見極めを優先する

PoCを飛ばして全機能を作り込むと、後から「そもそも精度が足りない」と分かったときの手戻りが大きくなります。小さく作って早く確かめます。

手順3：本番運用に必要な要素を足す

PoCで手応えが得られたら、本番に耐える要素を足していきます。PoCと本番の差は、主に安定性・コスト・品質維持です。

観点 本番で必要になること
応答体験 ストリーミング表示（生成の途中経過を順次表示）
コスト モデルの使い分け・トークン量の管理（コスト最適化）
品質維持 評価・監視の仕組み（評価・監視の始め方）
安定性 エラー時のフォールバック、タイムアウト処理

特にストリーミング表示は、生成に時間がかかる生成AIで体感速度を大きく左右します。PoCで割り切っていた部分を、本番では体験・コスト・品質の観点で埋めていきます。

手順4：暴走とコスト事故を防ぐ「止める仕組み」を入れる

サーバー経由にしてAPIキーを守っても、それだけでは足りません。使われすぎ・呼ばれすぎを止める仕組みがないと、想定外の利用やバグで請求が跳ね上がります。生成AIは1リクエストの単価が小さいぶん、異常に気づくのが遅れがちです。

最低限、次の3つを入れておきます。

仕組み 何を防ぐか
レート制限 短時間の大量リクエスト（いたずら・バグによる連打）
上限の設定 1リクエストあたりの最大トークン量・想定外の長文入力
利用量の監視 「いつの間にか請求が想定の何倍」の早期発見

特にレート制限は、公開サービスなら必須です。フォームやチャットの入口が誰でも叩ける状態だと、悪意がなくても連打やスクリプトで簡単にコストが膨らみます。ユーザー単位・IP単位で上限を設けます。

そして、異常に気づける状態を作ること。日次でも構わないので利用量を確認できるようにし、急増したら気づけるようにしておきます。生成AIのコスト事故は「一気に」ではなく「じわじわ」進むことが多く、気づいたときには1か月分が積み上がっているというのがよくある失敗です。仕組みで止め、数字で気づく。この2段構えが安全です。

よくある落とし穴

  • ブラウザから直接APIを叩く：APIキーが露出し悪用されます。必ずサーバー経由にします。
  • PoCを飛ばして作り込む：精度不足が後で判明し手戻りが大きくなります。最小機能で先に確かめます。
  • コスト設計を後回しにする：本番で請求が跳ねます。モデル使い分けとトークン管理を早めに。
  • エラー処理を用意しない：APIの遅延・失敗でUXが崩れます。フォールバックとタイムアウトを入れます。

よくある質問

Q. フロントエンドから直接LLMのAPIを呼んではいけないのですか？ A. 原則として避けます。APIキーがブラウザに露出し、第三者に悪用されて高額請求につながるためです。自社サーバーを経由させ、キーはサーバー側に隠します。これはコストと悪用の両面で重要な原則です。

Q. どのモデルを使えばいいですか？ A. 用途次第です。すべてを最上位モデルで処理するとコストが跳ねます。分類や要約は軽量モデル、最終生成は高精度モデル、といった使い分けを最初から設計に織り込むと、コストと品質のバランスが取れます。

Q. PoCから本番まで、どれくらいの期間がかかりますか？ A. 要件と品質要求によって大きく変わるため一概には言えません。重要なのは、PoCで価値と精度を先に確かめ、本番要素（安定性・コスト・品質維持）を段階的に足すことです。一気に本番品質を目指すより、段階を踏むほうが結果的に速いことが多いです。

生成AIのWeb実装は、①サーバー経由でAPIキーを守る ②最小機能をPoCで動かす ③本番要素を段階的に足す、という順で進めれば、セキュリティやコストの地雷を避けて本番まで通せます。まず構成、次に小さく動かす。これが遠回りしない進め方です。

自社プロダクトへの生成AIの組み込みや本番運用の伴走が必要な場合は、開発支援について相談するからお問い合わせください。