Gemini 3.1 Flash-LiteとOpenRouter — AIアプリのモデル更新戦略

2026年3月4日 2026年3月4日 Mark4

Mark4

廃止期限2026年6月17日 — AIモデル移行とマルチプロバイダー対応の実務

AIモデルの廃止期限が迫っている

wagahiアプリのキャラクター会話機能は、Google Gemini APIを使用しています。現在使用しているGemini 2.5系モデルの廃止期限は2026年6月17日。それまでに、新しいモデルへの移行を完了させる必要があります。

AIアプリを開発・運用する上で避けて通れないのが、AIモデルのライフサイクル管理です。モデルは定期的に更新・廃止され、APIの仕様も変わります。本記事では、wagahiアプリでのモデル移行調査と、マルチモデル戦略について共有します。

Gemini 2.5系から3.1系への移行調査

APIの破壊的変更

Gemini 3.1系への移行で最も影響が大きいのは、APIパラメータの変更です。

thinkingBudget → thinkingLevel: 思考トークン数を数値で指定する方式から、レベル（LOW/MEDIUM/HIGH）で指定する方式に変更
システムプロンプトの仕様変更: プロンプトの構造と処理方法が変更され、既存のプロンプトテンプレートの調整が必要
レスポンス形式の微調整: JSON出力モードの一部仕様が変更

Gemini 3.1 Flash-Liteの性能

移行先の有力候補であるGemini 3.1 Flash-Liteは、以下の特徴を持ちます。

IFEval 85%: 指示追従性が従来比+20%向上。wagahiアプリのようにプロンプトで細かく指示を出すケースに最適
出力速度+64%: レスポンスタイムが大幅に改善。チャットの応答速度向上に直結
Google Maps Grounding: Google Mapsのデータを参照した応答が可能。位置情報ゲームとの親和性が高い
コスト効率: Flash-Liteは最軽量モデルであり、APIコストが最も低い

Google Search Groundingの課金体系

wagahiアプリでは、キャラクターの会話にリアルタイムの情報を反映するためにGoogle Search Groundingの利用を検討しています。ただし、課金体系には注意が必要です。

Search Groundingは有料機能（RPMベースの課金）
すべてのリクエストでSearch Groundingを有効にすると、コストが急増する
地域情報に関する会話のみSearch Groundingを有効にするなど、選択的な利用が現実的

OpenRouter経由のマルチモデル戦略

OpenRouterとは

OpenRouterは、複数のAIモデルプロバイダーのAPIを統一的なインターフェースで利用できるルーティングサービスです。OpenAI、Anthropic、Google、Metaなど、主要なAIモデルに1つのAPIキーでアクセスできます。

wagahiアプリでの活用

wagahiアプリでは、以下の用途でOpenRouterの活用を検討しています。

画像生成モデルの切り替え: Nano Banana 2（Google画像生成モデル）への移行を、OpenRouter経由で実現
フォールバック戦略: メインモデルが応答不能の場合、自動的に代替モデルにフォールバック
コスト最適化: 用途に応じて最もコスト効率の良いモデルを選択

Nano Banana 2への画像生成移行

キャラクターの擬人化画像生成について、Nano Banana 2への移行を調査しました。Nano Banana 2はPro品質の画像をFlash速度で生成できるモデルです。

品質: 従来の画像生成モデルと同等以上の品質
速度: 生成時間が大幅に短縮
コスト: OpenRouter経由でのコストが比較的低い

スポット検索連携 — 3層データソースモデル

Ver2_03のもう一つの大きな実装が、スポット検索連携の3層データソースモデルです。

ユーザーの位置情報に基づいてスポット情報を提供する際、以下の3つのデータソースを階層的に参照します。

ローカルDB: wagahiアプリのPostgreSQLに格納された地域特性データ（47都道府県プロフィール、ユーザー登録スポット）
外部API: Google Maps APIやPlaces APIから取得するリアルタイムのスポット情報
AI生成: Gemini APIのSearch Groundingで取得する、DBや外部APIでカバーできない情報

この3層モデルにより、データの鮮度と網羅性を両立しながら、APIコストを最小化できます。ローカルDBで解決できるリクエストは外部APIを呼ばず、外部APIで解決できるリクエストはAI生成に頼らない。必要最小限の外部アクセスで最大限の情報を提供する設計です。

AIモデル更新の教訓

今回の移行調査を通じて得た教訓をまとめます。

API抽象化層は必須: AIモデルのAPIを直接呼ぶのではなく、抽象化層を挟むことで、モデル切り替えの影響を局所化できる
廃止期限の監視: 使用中のモデルの廃止スケジュールを定期的に確認し、移行計画を早めに立てる
マルチモデル対応: 単一モデルへの依存はリスク。用途に応じて複数モデルを使い分ける設計が望ましい
段階的移行: 一気に切り替えるのではなく、テスト環境→ステージング→本番の段階的移行が安全

本記事は2026年3月時点の開発状況に基づいています。

著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。

関連記事:

投稿者プロフィール

Mark4