APIキーは絶対にブラウザへ出さない
最初に決めるべきは構成です。APIキーをフロントエンドのJavaScriptに埋め込むと、ページを開いた誰もがキーを取り出して自由に使えてしまい、身に覚えのない請求につながります。AIへの呼び出しは必ず自前のサーバーやサーバーレス関数を経由させ、キーはサーバー側の環境変数で管理します。ブラウザから直接AIのAPIを叩く構成は、原則として選択肢に入れません。ここは後から直すのが最も面倒な部分なので、設計の一番はじめに固定してしまいます。
コストの上限を先に設計する
AI APIは処理したトークン量（テキスト量）に応じた従量課金です。「使われた分だけ請求される」仕組みのため、公開後に想定外の請求が届く事故は、設計段階で防いでおく必要があります。
- 1回の応答の長さ（最大トークン数）に上限を設ける
- 用途に対して過剰に高性能なモデルを選ばない。多くの用途は軽量モデルで十分
- API利用額に月次の上限・アラートを設定しておく
- 1ユーザーあたりの利用回数や頻度を制限する
特にモデル選定の見直しは効果が大きく、応答品質がほとんど変わらないままコストが一桁変わることもあります。
レート制限と失敗時の挙動を決めておく
外部APIである以上、応答が遅い・エラーが返る・一時的に使えない、という状況は必ず起きます。APIのレート制限（一定時間あたりの呼び出し回数の上限）に達すればエラーが返ってきます。タイムアウトを設定した上で、混雑時は少し待って再試行する、それでも失敗したら「時間をおいてお試しください」と案内する、といった失敗時のユーザー体験まで事前に決めておくと、公開後に慌てずに済みます。
あわせて考えたいのが待ち時間の見せ方です。AIの応答は数秒かかることが珍しくなく、画面が固まったように見えると利用者は離脱します。生成された文字を順次表示していくストリーミング方式にすると、完了までの時間は同じでも体感は大きく変わります。実装コストと相談しながらですが、チャット形式のUIでは検討する価値があります。
プロンプトと入力の扱いを設計する
応答の品質はプロンプト設計でほぼ決まります。役割・口調・答えてよい範囲・答えられないときの振る舞いをシステムプロンプトとして明文化し、想定質問でのテストを繰り返します。あわせて決めておきたいのが、利用者からの入力の扱いです。
- 「これまでの指示を無視して」等の指示文が紛れ込むプロンプトインジェクションを想定する
- 個人情報や機密情報を不用意にAPIへ送らない方針を決める
- 回答の根拠にする自社データ（FAQ・資料）の範囲と更新方法を決める
- 答えられない質問を無理に答えさせず、問い合わせ窓口へ案内する導線を用意する
AIは事実と異なる内容を、もっともらしい文章で返すことがあります。料金や仕様など誤りが実害につながる情報は、AIに自由に語らせるのではなく、参照する資料の範囲を絞る・該当ページへ誘導するといった設計で守ります。
ログを残し、育てる前提で公開する
AI連携は公開して終わりではありません。どんな質問に答えられなかったかを記録し、プロンプトや参照データを継続的に改善していく運用が前提になります。当スタジオでもAI連携の案件では、実装と同じくらい「公開後にどう育てるか」の設計に時間をかけています。最初から完璧を目指して大きく作るより、安全に小さく始めて改善を回すほうが、結果として良いものになります。
