Geminiの思考プロセスをリアルタイム表示！UX向上と透明性を実現するAIアプリ開発

私たちは皆、このような経験をしたことがあるでしょう。ユーザーが複雑なリクエスト（例えば、重いコーディングタスクや多段階のロジック問題）をアプリに送信すると、UIがまるでブラックホールに落ちたかのように反応しなくなります。一般的なローディングスピナーが表示され、数秒が経過する中で、ユーザーはアプリがクラッシュしたのか、それとも実際に動作しているのか疑問に感じてしまいます。

もし、この何もしない待機時間を、透明で魅力的なユーザーエクスペリエンスに変えることができたらどうでしょうか？Geminiモデルの思考プロセスを直接フロントエンドにストリーミングすることで、AIがユーザーの問題をリアルタイムでどのように分解しているかを正確にユーザーに示すことができます。

この記事では、FirebaseチームのRosario氏が、Geminiの思考プロセスを活用して透明性を高め、より良いユーザーエクスペリエンスを提供する方法について解説します。早速、詳細を見ていきましょう。

なぜGeminiの思考プロセスを可視化するのか？

Rosario氏のチームは、Firebase AI LogicとGeminiモデルを使用して、食材リストに基づいてレシピを生成する食事計画アプリを開発しています。以前のビデオでは、画像から料理を検出して栄養成分を生成する機能が実装されました。これはうまく機能しますが、数秒間のロード中にモデルが実際に何を行っているのかをユーザーが見ることができたらどうでしょうか？

今回のアップデートでは、ロードアニメーションに「思考要約」を追加することで、モデルの内部動作をユーザーに透過的に示せるようになりました。これにより、ユーザーは単なる待機画面ではなく、AIがどのように問題を解決しているかを視覚的に理解できるようになります。

Gemini思考プロセスを有効にする方法

Geminiモデルの思考プロセスをアプリに組み込むための主要なコード変更点は以下の通りです。

1. モデルの初期化と設定

モデルの初期化時にthinking configを含め、その中でinclude thoughtsをtrueに設定します。これにより、モデルは応答に思考を含めて返すようになります。

// モデルの初期化例（擬似コード）
const model = new GeminiModel({ /* ... */ });

model.init({ 
  thinkingConfig: {
    includeThoughts: true // 思考プロセスを含める設定
  },
  // ...その他の設定
});

2. レスポンスのストリーミングと表示

モデルからのレスポンスがストリーミングされる際に、思考と実際の最終的なレスポンスを分離し、これら両方をアプリのUIに表示します。これにより、ユーザーはリアルタイムでAIの思考と最終結果の両方を確認できます。

思考レベルの制御

Geminiはユーザーリクエストの複雑さに基づいて、推論に必要な努力量を自動的に調整します。しかし、特定のシナリオでは、この思考動作をより細かく制御したい場合があります。

例えば、レイテンシーを低く保ちたい場合や、非常に難しいコーディング問題にモデルに取り組ませたい場合などです。このような場合、thinking config内でthinking levelパラメータを指定することで、思考の動作を制御できます。利用可能なオプションは以下の通りです。

• minimal: 名前の通り、モデルの思考を最小限に抑えます。これは、思考機能を無効にするのに最も近いオプションです。
• low: レイテンシー（応答速度）とコストを最適化します。
• medium: ほとんどのタスクにおいてバランスの取れたオプションです。
• high: 推論の深さを最大化します。モデルの応答にはかなりの時間がかかる可能性がありますが、その分、出力はより慎重に推論されたものになります。

どのレベルを選択するかは、タスクの性質と、レイテンシーや応答品質の要件に応じて決定することが重要です。

Thought Signatures（思考シグネチャ）について

関数呼び出し（Function Calling）を使用する場合に遭遇する可能性のある概念として、「Thought Signatures（思考シグネチャ）」があります。

思考シグネチャは、モデルの内部思考プロセスを暗号化した表現であり、複数ステップの対話（マルチターン会話）において推論コンテキストを維持するために使用されます。

もし公式のFirebase AI Logic SDKを使用している場合、思考シグネチャについては心配する必要はありません。 SDKが思考シグネチャを自動的に処理してくれます。思考シグネチャを扱う必要があるのは、REST APIを使用している場合や、マルチターン会話でパーツ履歴を手動で抽出し、返す必要がある場合に限られます。詳細については公式ドキュメントを参照してください。

応答の料金体系

思考（Thinking）機能がオンになっている場合、応答の料金は出力トークンと思考トークンの合計によって決まります。総生成思考トークン数は、thoughts token countフィールドから取得できます。

ここで注意すべき重要な点があります。モデルは最終的な応答の品質を向上させるために完全な思考を生成しますが、APIから出力されるのはその要約のみです。したがって、料金はAPIから出力される要約ではなく、モデルが必要とする「完全な思考トークン」に基づいて計算されます。この点はコストを計画する上で考慮する必要があります。

実際の動作例

これまでの設定を適用したアプリを実際に実行してみましょう。

食事計画アプリでパルミジャーナの写真をアップロードすると、モデルがその画像を分析し、パルミジャーナのカロリーやマクロ栄養素を決定しようとする思考プロセスがリアルタイムでUIに表示されます。

このデモンストレーションにより、モデルがどのように画像を認識し、情報を処理しているかという内部の動きがユーザーに透明化され、待機時間が単なる空白ではなく、エンゲージングな体験へと変わる様子を確認できます。

まとめ

このように、ほんの数行のコードを追加するだけで、モデルの思考を制御し、ユーザーに対してそのプロセスを透明化することが可能になります。

モデルが回答を生成する前に許容する思考のレベルは、その回答の品質に直接的な影響を与えます。そのため、質問の複雑さを慎重に検討することが重要です。

比較的単純なタスクに対して寛大な思考予算を与えすぎると、モデルが「考えすぎる」結果になる可能性があります。もしどの思考レベルが適切か不明な場合は、デフォルト設定を使用し、モデルに最適な思考量を判断させるのが良いでしょう。

思考要約（Thought Summaries）は、モデルの思考プロセスに対する洞察をユーザーに提供する素晴らしい方法です。それだけでなく、ユーザーがモデルの最終的な回答を待つ間、ユーザーをアプリにエンゲージさせ続ける良い手段でもあります。

本記事のソースコードは、GitHubリポジトリで公開されています。ぜひ、Firebaseチャンネルを購読し、このビデオが役立ったと感じたら高評価をお願いします。

参考動画

• YouTube動画: Stream Gemini's Thinking Process Directly to Your Front End