土曜の朝、運営しているアプリの次期アップデートの仕様を詰めようと Gemini アプリを開いたとき、モードの選択肢を前にしばらく手が止まりました。じっくり考えさせるなら Deep Think、資料を集めるなら Deep Research、音声でやり取りするなら Live、動画や混合メディアを作るなら Omni。2026年6月のアップデートで「考える・調べる・話す・作る」の4つが一通り揃ったのは喜ばしいことなのですが、いざ目の前の作業を前にすると、どれに投げるのが正解なのか即答できない自分がいました。
そこで先週、個人開発の定常作業を棚卸しして、4つのモードに明示的に割り当て直してみました。結論から言うと、割り当ての判断は3つの質問に集約できました。この記録が、同じように「モードが増えて、かえって迷うようになった」と感じている方の参考になればと思います。
迷いの原因はモードの数ではなく、判断軸がないことでした
最初に気づいたのは、迷いの正体です。モードが4つあること自体は問題ではありません。問題は、作業を前にしたときに参照できる判断軸を自分が持っていなかったことでした。
実際、割り当てを始める前の私は「重要な検討だから Deep Think」「情報が欲しいから Deep Research」という曖昧な基準で選んでいました。この基準の弱点は、ほとんどの作業が「重要で、かつ情報も欲しい」ことです。たとえばアプリの新機能の仕様検討は、競合の動向も知りたいし、設計の整合性も考えたい。どちらの理由でも選べてしまうので、毎回その場の気分で決めることになります。
そこで、過去2週間に Gemini へ投げた依頼を見返して、満足した結果と期待外れだった結果を分類しました。すると、モードの得手不得手は「作業の重要度」とはほぼ無関係で、別の3つの条件で説明できることが見えてきました。
判断軸1: 材料が手元に揃っているか — Deep Think と Deep Research の分かれ目
最も迷いやすいのが Deep Think と Deep Research の使い分けです。どちらも「時間をかけて深い答えを返す」モードなので、表面的には役割が重なって見えます。
私の結論は、材料が手元に揃っているなら Deep Think、材料集めから必要なら Deep Research というシンプルな線引きです。
Deep Think が力を発揮したのは、判断材料をこちらが全部提示できる問題でした。たとえば、アプリ内課金の価格改定案を3パターン用意し、過去の売上傾向と一緒に渡して「それぞれの弱点を挙げてほしい」と頼んだケースです。材料が閉じているので、推論の深さがそのまま答えの質になります。逆に、材料を渡さずに「価格戦略を考えて」と投げたときは、一般論の丁寧な言い換えが返ってきて、待ち時間に見合いませんでした。
Deep Research はその逆で、「何を知らないかさえ分かっていない」段階に向いています。新しい分野の調査では、出典付きで網羅的に集めてくれる価値が際立ちます。ただし手元の材料で答えが出る問題に使うと、調査時間だけが長くなります。このあたりの体感はGemini ディープリサーチを半年使って分かったこと — 期待と現実のギャップを正直に語りますに書いた印象から大きく変わっていません。
この軸で割り当てると、迷いはかなり減りました。仕様検討のような作業は「前半は Deep Research で材料集め、材料が揃ったら Deep Think で詰める」という2段構えに自然に分解できます。
判断軸2: 途中で前提を変えたくなるか — Live は入力手段ではなく検討の場
Gemini Live を「キーボードの代わりに声で入力する手段」と捉えていた頃は、正直なところ出番がありませんでした。テキストの方が正確ですし、コードや URL を音声で伝えるのは無理があります。
見方が変わったのは、前提が固まっていない検討に使ったときです。散歩をしながら、次のアップデートで直すべき不具合の優先順位を Live と話していたところ、会話の途中で「そもそもこの不具合は次の OS アップデートで挙動が変わる部分では」と気づき、その場で前提を訂正して話を続けられました。テキストのチャットでも同じことはできますが、書き直しのコストがないぶん、前提の訂正を躊躇しなくなるのが大きな違いです。
そこで Live には「前提が流動的な、検討の初期段階」を割り当てました。具体的には週の頭に行う、その週のタスクの洗い出しと優先順位づけです。逆に、前提が固まったあとの作業（実装方針の確定や文章の推敲）には使いません。固まった前提を音声で改めて説明するのは、ただの二度手間になるからです。
判断軸3: 成果物の形は何か — Omni に任せた作業と、まだ任せない作業
Gemini Omni Flash が AI Plus を含む全サブスクライバーに開放され、動画や混合メディアの生成が手元でも気軽に試せるようになりました。「作る」の選択肢が増えたこと自体は歓迎なのですが、ここは意識的に割り当てを絞っています。
任せることにしたのは、成果物が短い説明メディアで、失敗してもやり直しが効くものです。具体的には、アプリの新機能を説明する15秒ほどの紹介クリップの試作です。これまで静止画とテキストで作っていた説明を、プロンプト一発の動画で置き換えられるかの実験として、週に1本だけ枠を設けました。
一方で、App Store に実際に掲載する素材の本番制作は、まだ割り当てていません。理由は品質ではなく、再現性です。同じプロンプトから安定して同じトーンの動画を得る手順が自分の中で確立できておらず、本番素材のように「シリーズで統一感が要る」成果物には時期尚早だと判断しました。試作で手順が固まってから移す予定です。
なお、テキスト中心の定常作業（リリースノートの下書きなど)は、引き続き通常のチャットと API 側の Gemini 3.5 Flash に残しています。どの作業を API 側へ寄せるかはGemini 3.5 Flash GA をどこから差し替えるか — ワークロード別の置き換え判定とモデルルーターによる段階導入の記録で書いた判定をそのまま使っています。
1週間運用して見直した2箇所
この割り当てで1週間回してみて、2箇所だけ修正しました。
1つ目は、Deep Think に割り当てる問題の粒度です。当初は「仕様検討」のような大きな単位で投げていましたが、論点が複数混ざった依頼では、推論が論点の間で薄く分散する感触がありました。今は「価格案3つの弱点比較」のように論点を1つに絞って投げ、複数論点は依頼を分けています。Deep Think が期待通りに動かないと感じたときの切り分けは、Gemini 3 の Deep Think が期待通りに動かない——よくある5つの問題と対処法も参考になるはずです。
2つ目は、Deep Research の実行タイミングです。完了まで時間がかかることがあるため、作業の合間に思いつきで投げると、結果が返ってきた頃には別の作業に頭が切り替わっていて、読み込みが雑になりました。今は夜に投げて翌朝読む運用に固定しています。「調べる」を夜間に寄せて朝に受け取る流れは、自動投稿のオフピーク運用と発想が同じで、個人開発のリズムには合っていると感じます。
まとめ: まず直近2週間の依頼履歴を分類するところから
モードの使い分けに迷っている方に最初の一歩としておすすめしたいのは、新しい割り当て表を作ることではなく、直近2週間に自分が Gemini へ投げた依頼を見返して、満足だったものと期待外れだったものを分けてみることです。私の場合、その分類から「材料が揃っていたか」「前提が動いたか」「成果物の形は何か」という3つの軸が浮かび上がり、割り当ては後から自然に決まりました。
機能の数だけ見ると複雑になった Gemini ですが、軸さえ持てば、選択はむしろ速くなります。私自身まだ調整の途中ですが、同じように作業の割り当てを見直す方の参考になれば幸いです。お読みいただきありがとうございました。