Gemini APIを組み込んだAIチャット機能の実装記
Mark4「吾輩はXXXである」を生成する — 会話プロンプトのDB管理化とMagic Link認証への移行
キャラクターとの会話をどう実現するか
wagahiアプリの核心機能は、AI生成キャラクターとの自然な会話です。ユーザーがスマホのカメラで撮影した自販機がキャラクターに変身し、そのキャラクターと対話できる。この体験を実現するために選んだのが、Google のGemini APIでした。
今回は、Gemini APIの組み込みからMagic Link認証への全面移行まで、MVP_02からMVP_03にかけての技術的挑戦についてお伝えします。
Gemini API連携の設計
Gemini APIの選定理由は、前回の記事でも触れた通り、wagahiの世界観に直結しています。キャラクターが「吾輩はXXXである」と語り出す独特の口調を生成するために、プロンプト設計には特に注力しました。
実装のポイントは会話プロンプトのDB管理化です。
- システムプロンプト: キャラクターの性格、口調、地域性を定義するプロンプトをデータベースに格納
- 会話コンテキスト: 直近の会話履歴をプロンプトに含め、文脈を維持した応答を生成
- 暗号化保存: ユーザーの会話内容はAES暗号化してデータベースに保存（encrypted_initial_greetingカラム等）
プロンプトをハードコーディングせずDB管理とすることで、キャラクターの性格設定やプロンプトの調整をコード変更なしで行えるようにしました。運用開始後のチューニングを見据えた設計です。
QuotaExhaustedException — API制限との戦い
Gemini APIの組み込みで最も苦労したのは、API利用制限（Quota）への対応です。
開発中にGemini APIのRPM（Requests Per Minute）やTPM（Tokens Per Minute）の制限に頻繁に到達し、QuotaExhaustedExceptionが発生しました。特に結合試験で多数のテストケースを連続実行すると、すぐに制限に引っかかります。
対応策として、以下の3層防御を実装しました。
- フロントエンド: 連続送信の抑制（デバウンス処理、送信ボタンの無効化）
- バックエンド: Redisキューイングによるリクエストの順序制御
- リトライ制御: 指数バックオフリトライ（1秒→2秒→4秒→8秒…と待機時間を増加）
さらに、ユーザーに対してトークン使用量を可視化する機能を実装しました。「あとどれくらい会話できるか」をユーザーが把握できることで、APIエラーによる唐突な体験の中断を防ぎます。
MVP_03 — 6日間でMagic Link認証に全面移行
MVP_02のチャット機能強化が完了した直後、認証方式の全面刷新に着手しました。これがMVP_03（2025年11月18日〜23日）です。
従来のパスワード認証を完全に廃止し、Magic Link認証に移行する決断をしました。
Magic Linkとは、ユーザーがメールアドレスを入力すると、ワンタイムの認証URLがメールで届き、そのリンクをクリックするだけでログインできる方式です。パスワードの記憶も管理も不要になります。
移行の判断理由は以下の通りです。
- セキュリティ向上: パスワード漏洩のリスクが根本的に排除される
- UX改善: 位置情報ゲームのユーザーに、パスワード管理の負担を強いたくない
- 実装コスト: Spring Security + JWT + Magic Linkの組み合わせで、堅牢な認証基盤を短期間で構築可能
reCAPTCHA v3統合
Magic Link認証では、メール送信エンドポイントがbot攻撃の標的になるリスクがあります。このリスクを軽減するため、Google reCAPTCHA v3を統合しました。
reCAPTCHA v3の特徴は、ユーザーに画像認証などの操作を求めず、バックグラウンドでbot判定を行う点です。ユーザー体験を損なわずにセキュリティを確保できます。
実装はフロントエンド・バックエンドの両面で行いました。
- フロントエンド: reCAPTCHAトークンを取得し、Magic Linkリクエストに添付
- バックエンド: Google reCAPTCHA APIでトークンを検証し、スコアが閾値以下の場合はリクエストを拒否
法務対応 — 利用規約とプライバシーポリシー
MVP_03では技術的な実装だけでなく、法務対応も並行して進めました。
wagahiアプリは位置情報とカメラ画像を扱うため、プライバシーポリシーと利用規約の整備は必須です。サインアップフローに利用規約・プライバシーポリシーへの同意チェックボックスを組み込み、同意なしではアカウント作成ができない設計としました。
また、同意履歴をデータベースに記録することで、後からの監査対応も可能にしています。
アジャイルなスコープ管理
MVP_03で特筆すべきは、スコープ管理のアジャイルさです。
当初はMVP_04として8機能を一括で実装する計画でしたが、認証方式の移行が想定以上に重要だと判断し、急遽MVP_03として切り出しました。結果的に、MVP_04は4機能に縮小され、それぞれのMVPが集中的に1つのテーマに取り組む形になりました。
この判断が功を奏し、MVP_03はわずか6日間で認証方式の全面移行を完了。システムテスト（ST-001: 8/8合格、ST-007完了）も問題なく通過しました。
AI駆動開発においても、アジャイルの基本原則——早期フィードバック、小さなリリース、変化への適応——は健在です。むしろ、AIが高速にコードを生成できる分、スコープの見直しと集中の判断がより重要になると実感しました。
次回予告
次回は、AWS EC2にステージング環境を構築した話をお伝えします。Docker + Nginx + Let's Encryptによるインフラ構築、AI自動命名機能の実装、そしてTCGカード風UIの実現。開発環境からステージング環境への移行で見えた課題と解決策について記録します。
本記事は2025年11月時点の情報に基づいています。
著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。
関連記事:
投稿者プロフィール
