Deep Think という製品機能名と、API の思考レベルは、名前が似ていても同じものとは限りません。ここでは、特定モードへのアクセスを前提にせず、Gemini 3 を使った推論タスクを検証する方法を紹介します。

まず、利用中の画面で選べるモデル、ツール、設定を確認します。第三者のチャットで「Pro」を選ぶだけでは、Google の別の製品機能を有効にしたことにはなりません。

製品機能と技術的な設定を分ける

Gemini の思考機能ドキュメントは、モデルと API に応じた推論制御を説明しています。この資料だけで MidassAI の Deep Think スイッチの存在を確認することはできません。各サービスの条件や制限は別に調べる必要があります。

モデルの表示名、説明されている設定、添付方法、利用可能なツールを記録してください。存在しない設定を想定して起動コマンドを作るのではなく、入力の整理と出力の確認から始められます。

合格条件のある問題を選ぶ

推論を評価するには、入力、制約、誤りの見つけ方が必要です。二つの要件書の比較、表の矛盾の発見、範囲を限定したコード修正などが例になります。「よく考えて最善の案を出して」だけでは完了条件が明確ではありません。

文書比較なら各差分に根拠となる箇所を付けます。コードなら、どの不具合を直すかと確認方法を示します。説明が長いことや、断言する文体は、この証拠の代わりにはなりません。

期待する挙動、最小の失敗例、関連する関数、維持すべき条件を渡します。ログから秘密情報を除き、リポジトリにアクセスできない画面では必要な抜粋を提供してください。

添付したコードとエラーから、公開インターフェースを維持する最小の修正を提案してください。推定原因と、この資料では確認できない点を分けてください。修正前に失敗し、修正後に通るテストを提案し、実行済みとは書かないでください。

パッチを確認し、自分の環境でテストを実行します。不足する依存関係の情報があれば、設定を強めるより先に補います。提案されたテストと、実行ログのあるテストは区別してください。

正常な入力と境界条件も確認し、エラーを握りつぶすだけの変更になっていないか調べましょう。

資料に A と B のラベル、作成日を付けます。優先する版が決まっていなければ、モデルに勝手に正解を選ばせず、未解決のまま残すよう求めます。

提供した A と B だけを使い、一致点、矛盾、情報不足を分けてください。矛盾ごとに両方の根拠箇所を示し、解決に必要な質問を一つ書いてください。優先順位の規則がない限り、片方が正しいと決めないでください。

引用を原文と照合します。条件に言及していないことと、その条件を否定していることは異なります。日付の適用範囲が違うだけなら、矛盾と分類しないよう確認します。

普段の設定と、実際に使える説明付きの別設定で、同じケースを試します。資料と出力形式を固定し、正確さ、抜け、制約違反、全体の時間、修正の手間を比較します。

ケース、モデルのバージョン、日付、設定、結果、失敗の根拠を自分で保存してください。一回の成功から改善率を算出せず、判断に関わるケースを繰り返し、失敗した試行も残します。

事実が足りなければ資料を追加し、形式が違えば出力条件を明確にして外部で検証します。制約を忘れるなら指示を整理し、同じ失敗を検出するケースを作ります。比較条件をそろえられるときに別設定を試してください。

内部の思考過程を要求することを信頼性の証明にせず、短い理由、出典、独立したチェックを求めましょう。自己批評も確認作業を補助するもので、代行するものではありません。

目的、使える資料、制約、合格条件を自分の文書に保存し、新しい会話で必要な内容を渡します。セッションをまたぐ記憶やバックグラウンド実行を仮定しないことで、モデルや画面が変わっても同じ作業を比較できます。