同じ週にモデルが並んでも、先に決めるのは一つの仕事
- 同じ週に複数の新モデル発表を見て、どれから試すか止まっている人
- 全員の標準モデルを一度に切り替えようとしている責任者
- 性能表より、現場の一業務にモデルを当てはめたい人
火曜の朝、社内チャットにリンクが三つ並びます。
Anthropicの新しいOpus。 GoogleのFlash系の更新。 前の週の発表の続きの記事。
誰かが「そろそろ切り替えたほうがいいのでは」と書く。 別の誰かが「まだ前の設定で回っている」と返す。
会議の前の十分間、画面は開いているのに、手は動きません。
同じ週にモデルが並んでも、先に決めるのは性能比較でも、全員の全面切替でもありません。
一つの仕事と、その仕事に使うモデルです。
同じ週に並ぶと、会話は「どれが上か」から始まる
2026年7月24日、Anthropicは Claude Opus 5 を発表しました。全プラットフォームで利用可能、Maxではデフォルト、Proでは最上位、API名は claude-opus-5、入出力の単価は Opus 4.8 と同じ水準、と説明されています。
その数日前の7月21日、Googleは Gemini 3.6 Flash と 3.5 Flash-Lite を API・Enterprise・アプリ向けに出した、と発表しています。
発表が近いと、現場の入口はだいたい同じ形になります。
表を開く。 名前を並べる。 「いちばん新しいほうを標準にするか」を議論する。
その入口だと、一週間がモデル選びで終わります。
初回メールの下書き。 見積のたたき台。 問い合わせの一次整理。
どれも「新しいモデルが来たから試す」対象になり、どれも中途半端に終わります。
全面切替の前に、一つの仕事を選ぶ
全面切替は、きれいに見えます。
全員同じ設定。 説明も一つ。 管理も一つ。
ただ、仕事の種類は一つではありません。
顧客名が見える問い合わせの整理。 社内だけの議事録要約。 金額が入る見積のたたき台。
同じモデルを当てはめると、安全な仕事まで重い設定になり、軽い仕事まで迷いが残ります。
先に決めるのは、モデル名ではありません。
来週、一つだけ試す仕事です。
たとえば「初回返信の下書きだけ、新しいFlash系で出す。送る前は必ず人が直す。」
これだけで、会議の論点が変わります。
「全員切り替えるか」ではなく、「この仕事で足りるか」になります。
モデルの階層や性能比較の話は、モデルが三つに分かれた週に、先に決めるのは性能比較ではないに任せます。 こちらは、同じ週に発表が並んだときの入口の話です。
一つの仕事に当てはめるとき、残すのは三行
仕事を一つ選んだら、次に残すのは三行です。
- 何を頼むか（例：初回メールの下書き）
- どのモデルか（例：Gemini 3.6 Flash、API経由）
- 人が見る地点（例：送信前に担当者が一文直す）
長いルールは不要です。
三行が書けない仕事は、まだ試す順番が来ていません。
Opus 5 は全プラットフォームで触れますが、すべての仕事の標準にする必要はありません。 Flash-Lite は軽い作業向け、Opus は影響が大きい下書き向け、と分ける判断は、仕事を一つ決めてからで十分です。
Google側には Flash Cyber のような限定提供もありますが、一般向けの選択肢として並べる話ではありません。 自社の一業務に使えるモデルだけを選びます。
発表が続く週ほど、「前より良い」の基準が後回しになる
新モデルが続くと、「前より良いか」が先に来がちです。
ベンチの数字。 提供者の説明。 他社の切替事例。
数字は、自社の仕事の良し悪しをそのまま示しません。
見積のたたき台で困っているのは、モデルの順位ではなく、数字の根拠が抜けていないか、納期の言い回しが自社の約束とズレていないか、です。
「前より良い」の中身を先に決める話は、モデルを上げる前に決める、「前より良い」の判定基準側へ回します。
同じ週に並んだ発表を、全部試す必要はありません。
一つの仕事で、「前より楽になった」「前より直す回数が減った」のどちらかが言えれば、次の仕事へ進めます。
現場で起きる三つの寄り道
ひとつめは、管理画面の設定を全員分いじることです。
設定は揃います。 でも、どの仕事で使うかが決まっていなければ、月曜の迷いは残ります。
ふたつめは、デモ用のプロンプトを増やすことです。
うまくいった例が増えると、試したくなります。 試す場所が増えると、本番の仕事の改善が見えにくくなります。
みっつめは、競合他社の切替ニュースを根拠にすることです。
他社が切り替えたから自社も、では、自社の初回メールが本当に楽になったかは分かりません。
火曜の朝、15分で終わる決め方
会議の前に、紙かメモアプリに書きます。
- 来週一つだけ試す仕事：問い合わせの初回返信下書き
- 使うモデル：Claude Opus 5（API）、または Gemini 3.6 Flash（API）
- 人が見る地点：送信前に担当者が顧客名・金額・約束を確認
それ以外の仕事は、今の設定のまま触らない。
触らない、と書くことが大事です。
触らない仕事があるから、試した一つが評価できます。
評価できた一つが、次の仕事の順番を決めます。
同じ週の発表は、選択肢の増加ではなく順番の問題
AnthropicもGoogleも、それぞれの説明でモデルの位置づけを示しています。 それは提供者側の地図です。
自社の地図は、仕事から描きます。
初回メール。 見積。 問い合わせ。 社内共有。
並んでいる仕事から、一つだけ新しいモデルを当てる。
当てた一つで、直す回数・迷う回数・送るまでの時間のどれかが変わったかを見る。
変わらなければ、モデルではなく依頼の書き方を直す。 変われば、次の仕事を一つ足す。
全面切替は、そのあとで十分です。
問い合わせの初回返信で試す理由
初回返信は、試しやすい仕事です。
影響範囲が読みやすい。 送信前に人が必ず通る。 うまくいかなくても、顧客へ出す前に止められる。
たとえば、Gemini 3.6 Flash で下書きを出し、Opus 5 は金額が絡む段落だけ別途見る、といった分け方もできます。
同じ週にモデルが並んだからといって、両方を同時に標準にする必要はありません。
一つの仕事の中でも、段落単位でモデルを分ける、は次の段階です。
まずは一業務・一モデル・一確認地点から始めてください。
社内共有で起きる「みんな別モデル」問題
同じ週の発表後、社内共有の場でこうなることがあります。
Aさんは新しいOpusを試している。 BさんはFlash-Liteで要約している。 Cさんは前の設定のまま。
議事録の要約が三種類並び、「どれが正」かの会議が始まる。
先に一つの仕事を決めていれば、共有のルールも一行で済みます。
「社内議事録の要約は Flash-Lite。顧客向け資料の要約は触らない。」
モデルの多さを減らすのではなく、仕事の入口を一つに絞る。
絞った入口だけ、来週評価する。
見積のたたき台——試すなら「出すまで」で止める
見積は、試す仕事として人気です。
ただ、金額が絡むほど、モデルより確認地点が重要です。
新モデルでたたき台を出すなら、三行目は必ずこうします。
「顧客へは出さない。営業が単価表と照合するまで。」
Opus 5 も Flash も、数字の正しさを保証する道具ではありません。
同じ週に並んだモデルの比較より、止める地点のほうが先です。
同じ週にモデルが並んでも、先に決めるのは一つの仕事です。 発表の多さに負けず、一業務とモデルを三行で残してください。 それだけで、火曜の会議は短くなります。 来週の評価は、切替の成否ではなく、その一業務が楽になったかで十分です。
試した一業務の結果が残っていれば、同じ週の発表は順番表として機能します。 性能の話は、一業務を試したあとで十分です。 全面切替の会議は、その評価が終わってからで構いません。
新モデルが並んだ週に、先に試す一業務と三行の決め方を、一緒に短く整理できます。
