はじめに

こんにちは。DX開発事業部の鹿嶋です。ねこ、吸ってますか?

現在、Google が提供する生成AIである Gemini は、バージョン 2.5 が提供開始されています(※プレビュー版)。

上記のバージョンには、Gemini が回答を導き出すまでの思考プロセスを可視化する機能、Thinking 機能が実装されていますが、つい先日、Gemini 2.0 Flash においても、この機能のプレビュー版が利用できるようになりました。

Gemini 2.0 Flash Thinking

今回はこちらの Thinking 機能の解説と、簡単なサンプルを用いて使用してみた結果についてお話しできればと思います。

Thinking 機能とは

Gemini が複雑な問題を解決する際に、その思考プロセスや推論過程を可視化する機能となります。

従来の Gemini とのやりとりの中で、与えたプロンプトがなぜその結果になって返却されたのか、という部分は、基本的にはブラックボックスとなっていました。

Thinking 機能は、Gemini に高度な推論を行わせることで、その結果だけでなく「なぜその結論に至ったのか」という思考のステップを理解することが可能となりました。これにより、回答のブラックボックス性を低減し、説明性や信頼性の向上に繋げることができます。

Gemini は他の生成AIと同じく、何か質問をされたりタスクを与えられたりすると、人間のように頭の中で様々な思考や推論を行います。

  • この質問に答えるには、まずこの情報を検索しよう
  • 検索結果の中から、このキーワードに注目しよう
  • その情報とこの情報を組み合わせて、結論を導き出そう
  • 最終的な答えを出す前に、この選択肢も検討してみよう

などといった、生成AIの頭の中で行われた一連の思考ステップを、短い分析情報として要約を行った上で、私たちに提示してくれます。

この機能のメリットは、Gemini が導き出した答えが正しいかどうかだけでなく、どのような論理や手順でその答えにたどり着いたかを検証できるということにあります。

例えば、Gemini が明らかに誤った回答や、ハルシネーション(事実に基づかない情報をあたかも正しいかのように生成してしまう現象)を起こした場合、思考プロセスを見ることで、情報の誤認や推論飛躍といった問題点がどのステップで発生したのかを特定することが可能となります。

これらの情報を通じて、プロンプトエンジニアリングの効率化であったり、Gemini の挙動理解を深めることにつながります。

内部的な話にはなりますが、Gemini が回答を出すために思考や推論を行う際、このプロセスにおいて「トークン」という値を消費します。thinkingBudget パラメータ は、Gemini が思考プロセスの中で消費するトークンの量を設定するためのパラメータになります。

トークンは Gemini が情報を処理する際の基本的な単位で、例として単語の一部や句読点などに相当します。thinkingBudget を設定することで、Gemini に「このタスクを考えるのに、これくらいの思考リソース(トークン数)を使ってもいいですよ!」という上限を与えることができます。

一般的には、利用できるトークン数が多ければ多いほど、思考プロセスの中で使用できる文字数が増えるため、より詳細な推論が可能になり、複雑な問題や深い洞察が必要なタスクに対して、より正確で質の高い回答を生成できる可能性が高くなります。

ということであれば、常に最大設定にしておいた方がよいのかといえば、必ずしもそうではありません。

利用できるトークン数が増えることで、思考プロセスの増加や利用コストの増加が見込まれます。また、より多くの思考・推論を行うことによって、不必要に多くの情報を探索、誤った概念との結びつきを発生させ、結果的にハルシネーションを引き起こすリスクが高まる可能性も考えられます。

thinkingBudget は、ユーザが明示的に設定しない場合は、プロンプトの複雑さに応じてモデルが動的に調整を行います。これにより、シンプルな質問には少ない思考リソースで素早い回答を行い、複雑な質問には十分な思考リソースを使ってじっくりと思考する、といった柔軟な対応を行うことが可能になります。

Function Calling

Thinking 機能は、単に複雑な問いに答えるだけでなく、Gemini が外部のツールやサービスを連携させる「関数呼び出し(Function Calling)」の場面においても、その真価を発揮します。

Gemini が関数を呼び出す際も、Thought summaries で紹介したような思考や推論を行なっています。

  • ユーザーの意図を正確に理解し、どの API や関数などのツールが必要かを判断する
  • 選んだツールに対して、どのような情報を、どの形式で渡すべきかを決定する
  • 判断の結果によっては、複数のツールの中から最適な選択肢を効率的に選択する

例えば、「今日の天気を教えて」というプロンプトを与えた場合、Gemini はただ回答を生成するだけではなく、「この質問に正確に答えるには、『天気予報のサービスを参照する必要がある』と判断します。
それだけではなく、「どの地域の天気が必要か?」と考えて、絞り込むために必要な情報を質問したり、自ら推測したりするなどして、最終的にツールに渡す情報を決定します。

この思考の結果が、最終的にはユーザにとって最適化された「今日の天気」という形になって返却されることになります。

つまりは、Gemini が単に指示に従うだけではなく、自分で現状を整理・理解した上で最適なツールを選択し、自律的に問題を解消していくことができるようになります。

利用方法について

Google Cloud Console にログインし、メニューから Vertex AI Studio > プロンプトを作成 を選択します。

現在 Thinking 機能がデフォルトで有効化されているのは以下のバージョンになりますので、いずれかを選択してください。

  • gemini-2.5 flash-preview
  • gemini-2.5 pro-preview

今回は Thinking 機能の有無でどのように回答が変化するのかを確かめるべく、gemini-2.0 flash-001 と比較を行ってみます。
双方に以下のプロンプトを与えて、動作を確認します。どのような違いが現れるでしょうか?

この夏、東京在住の友人が新潟に観光に来る予定です。
おすすめの観光スポットを3件あげて欲しいです。
行動範囲は新潟市内がメインです。バス・電車での移動を予定しています。

まずは、gemini-2.0 flash-001 の結果です。

次に、gemini-2.5 flash-preview の結果です。

結果に対する総評は以下のようになりました。

◼︎ 全体的な回答の構造や類似点

  • ユーザーの要望通り「新潟市内」で「公共交通機関でアクセスしやすい」観光スポットを3つ紹介しようとしている
  • 各スポットについて、「魅力」「アクセス」「おすすめポイント」という類似した構成で情報を提供している
  • ユーザへの親しみをこめた結びの言葉を添えて締めている

◼︎ おすすめスポットの内容

  • gemini-2.0 flash-001: 比較的地元の定番かつ幅広い層に人気がありそうな観光地を選定した
  • gemini-2.5 flash-preview: こちらも定番どころですが、上記と異なるスポット(ばかうけ展望室、旧齋藤家別邸)を選定した

違いが顕著に現れたのは、おすすめスポットです。なぜこの違いが発生しているのか、Thinking 機能を通じて思考プロセスを確認してみます。
※原文は英語ですが以下、機械翻訳の内容を見やすく整形したものです

◼︎ 旅程の特定
・最適なスポットに焦点を絞り始めています。
・新潟市内でのバスや電車によるアクセスのしやすさが重要です。また、夏の時期も考慮し、東京からの観光客に合うようにしたいと考えています。

◼︎ 目的地の優先順位付け
・最初のリストを見直し、現在、核となる要件に焦点を当てています。
・友人の所在地、交通手段の好み、時期を考慮し、バスや電車でアクセスしやすい場所を優先しています。
・3つの主要なスポットに絞って検討しています。現在、大きな可能性を秘めた選択肢の順位付けを行っています。

◼︎ 選択肢の評価
・潜在的な目的地のリストを評価し、アクセシビリティ、「新潟らしさ」の要素、多様性、夏にふさわしいかという基準を検討しました。
・現在、3つの場所に傾倒しています。
・朱鷺メッセ展望室、ピアBandai、そして旧齋藤家別邸、または新潟県立近代美術館のいずれかで、さらなる評価を待っています。

◼︎ 最終計画の策定
・旅程を最終決定し、そのバランスに非常に満足しています。
・私のおすすめの3つのスポットは、眺望のための朱鷺メッセ展望室、食事のためのピアBandai、そして歴史と文化のための旧齋藤家別邸です。
・アクセスのしやすさ、夏にぴったりの雰囲気、そして新潟の本質を示すことに焦点を当て、友人のニーズに合わせて選択肢を調整しました。
・次に、より詳細な説明を作成する必要があります。

◼︎ 詳細な説明の起草
・現在、各場所の詳細な説明を作成しており、アクセス詳細、主な特徴、夏に特化したハイライトを含めています。
・主な選択肢は朱鷺メッセ展望室(眺望)、ピアBandai(食事)、旧齋藤家別邸(文化)に決定しました。
・次に、公共交通機関でのアクセスのしやすさと夏の魅力を強調します。

◼︎ 詳細な旅程の作成
・現在、朱鷺メッセ、ピアBandai、旧齋藤家別邸という3つの主要な場所を強調した具体的な計画を立案しました。
・次に、交通機関の詳細を強調した説明を作成しています。
・この旅程は観光、食事、歴史のバランスが取れており、夏の旅行に完璧に合致していると確信しています。
・現在、説明のための枠組みを構築しています。

◼︎ 詳細の微調整
・作成した旅程を見直し、各場所の説明を微調整しました。
・バスと電車での利便性に焦点を当てた3つのスポットの計画を確認しました。
・次に焦点を当てるのは、言葉遣いの洗練と、説明に主要なアトラクションと夏に特化したハイライトを含めることです。

今回の例では、以下の思考プロセスを経由したことがわかりました。

  1. 旅程の特定と優先順位付け(交通機関でのアクセス、夏の時期という条件で最適なスポットを絞り込み〜優先順位づけ)
  2. 上記に合わせて選択肢の検討・評価と絞り込み(選択肢を検討→上記の基準にマッチするかを評価→選択肢の最終決定)
  3. 最終的な計画と説明の作成(選定した3つのスポットそれぞれの特徴と、交通機関を考慮した旅程への強調、計画の説明)

このように、単純な情報提供ではなく、条件整理→選択肢評価→最適解の提案という段階的な思考プロセスを経ることで、より実用的で説得力のある回答が生成されることがわかります。これは我々ユーザが Gemini を活用する際に、あらかじめこうした思考の流れを意識してプロンプトの設計を行うことで、質の高いアウトプットを得られるカギになるかもしれません。

おわりに

いかがでしたでしょうか。Gemini が単なるキーワードマッチングや統計的な関連性だけで回答を生成しているのではなく、ユーザーの要望を理解し、条件を考慮し、複数の選択肢を比較評価し、最適なものを選択するという、まるで人間が行うような複雑な思考プロセスを実際に経ていることが明確になったかと思います。これにより、Gemini に対する理解と回答の信頼を深めることが可能になり、もし期待と異なる回答を出した場合でも、どの思考ステップで認識のズレや情報不足が発生したのかをピンポイントで特定できるため、プロンプトの調整やモデルの改善に直結させることもできるようになります。

私自身も、単に便利なツールとして生成AIを利用するだけでなく、その思考を理解し、共に問題を解決していくという観点が、生成AI活用において重要になっていくのではないかという学びを得られたと思っています。

今度は実際の開発目線でも深掘りできればと思いますが、ぜひ Thinking 機能を活用し、Gemini の新たな可能性を体験してみてください!