モデルが三つに分かれた週に、先に決めるのは性能比較ではない

新しいモデルが出ると、現場の会話はだいたい同じ形になります。

「前より強いのか。」 「うちも切り替えたほうがいいのか。」 「いちばん上を使ったほうが安心ではないか。」

2026年7月9日、OpenAIの発表では、GPT-5.6ファミリーとしてSol、Terra、Lunaという階層が示されました。価格帯も階層ごとに分かれ、提供は段階的に広がる、と書かれています。

ここで起きやすい失敗は、性能比較から入ることです。

表を見る。 順位を追う。 いちばん上を標準にする。

その順番だと、仕事の分け方が後回しになります。

モデルが三つに分かれた週に、先に決めるのは性能比較ではありません。

どの仕事にどの階層を使い、誰が承認するかを先に決めることです。

階層が分かれたとき、現場で増えるのは選択肢ではなく迷い

モデルが一つしかないと、迷い方は単純です。

使うか、使わないか。

階層が三つになると、迷い方が増えます。

日常の短い返信に、いちばん上を使うのか。 長い調査に、安い階層を使うのか。 社内メモと顧客向け資料を、同じ設定で出すのか。

選択肢が増えたように見えて、実際に増えるのは迷いです。

現場では、こんなことが起きます。

Aさんは、迷うたびに上の階層を選ぶ。 Bさんは、コストを気にして下の階層を選ぶ。 Cさんは、昨日うまくいった設定をそのまま使い回す。

同じチームなのに、同じ種類の仕事で、使う階層がバラバラになります。

問題は、誰かが間違っていることではありません。

仕事の分け方が、まだないことです。

OpenAIの発表では、Solは旗艦、Terraは日常寄りのバランス、Lunaはコスト効率寄り、という位置づけが示されています。これは提供者側の説明です。

自社の標準にするには、その説明をそのまま採用するだけでは足りません。

自社の仕事を、どの箱に入れるかを決める必要があります。

先に分解するのは、モデル名ではなく仕事

ここでやるべき分解は、モデル名の比較ではありません。

仕事の分解です。

たとえば、次のように分けます。

1. 下書き・要約・言い換えなど、あとで人が直せる作業
2. 社内向けの整理・候補出しなど、影響が社内で止まる作業
3. 顧客向け・契約・金額・公開文など、外に出る作業
4. 長時間の調査や複数手順の作業など、途中確認が必要な作業

この四つは、必要な確認の厚さが違います。

1は、出力を見て直せば足りることが多いです。 2は、社内の前提が合っているかの確認が要ります。 3は、誰が最終文責を持つかが先に要ります。 4は、途中で止める条件がないと、進んだあとに戻せなくなります。

モデル階層の話は、この分解のあとに来ます。

安い階層を使うか、上の階層を使うかは、仕事の箱が決まってから決める。

順番が逆だと、「強いモデルを使ったのに、なぜか事故る」が起きます。

強い設定を使っても、外に出る文の承認者がいなければ、責任の置き場は変わりません。

AIに任せてよい範囲を責任で分ける考え方は、責任が残るかで境界を決めると同じ軸です。

本稿で足すのは、その境界を、モデル階層の選択にも接続することです。

性能表より先に残す四行

切替会議で最初に出すのは、ベンチ表ではありません。

次の四行です。

1. この仕事は、上の四つのどの箱か
2. 使う階層の候補はどれか
3. 出力を見てよい人と、外に出してよい人は同じか
4. 失敗したら何をもって止めるか

この四行がないまま「上の階層へ統一」とすると、切替ではなく乗り換えです。

OpenAIの発表では、階層ごとに価格帯があり、提供は段階的に広がる、と書かれています。ここで急がなくてよい判断があります。

自社の画面に全部の階層が見えない段階で、社内標準を決め切らないことです。

見えないものを標準にすると、決めたつもりが運用できません。 見える範囲で試験し、広がってから標準を更新する。

そのほうが、現場は動きやすいです。

価格帯の存在は比較の入口です。採否の結論ではありません。

再試行が多い仕事、長い出力が多い仕事、途中確認が多い仕事では、見た目の単価と実際の負担はズレます。

だから、価格表だけで「安いから日常全部を下の階層へ」も危険です。

仕事の箱ごとに、試す単位を分ける必要があります。

段階展開の週にやりがちな失敗も、ここにあります。

画面に新しい階層が見えた瞬間に、全社の既定値を変える。 まだ見えない人には説明だけ先に出す。 試験条件がないまま「上に寄せよう」が会議の結論になる。

見えたことと、標準にできることは別です。

見えた範囲で一件試す。 失敗条件を見る。 そのあとで、箱ごとの既定を更新する。

この順番なら、段階展開は障害ではなく、試験の時間になります。

いちばん上を標準にしない

階層が分かれると、「いちばん上を標準にすれば安心」と思いやすくなります。

現場では、その安心が別の負荷になります。

短い修正まで上の階層で回す。 確認待ちが増える。 コストの話だけが先に立つ。 本来すぐ終わる作業が重くなる。

安心のつもりが、日常作業の渋滞になります。

逆に、全部を下の階層へ寄せるのも危険です。

外に出る文、金額、契約条件まで、確認の薄いルートで回すことになるからです。

必要なのは、中間のきれいな理論ではありません。

仕事の箱ごとに、使う階層と承認者を分けることです。

たとえば、次のような置き方です。

• 下書き・要約は、下または中の階層。確認は作成者
• 社内整理は、中の階層。確認は依頼者
• 顧客向け文は、階層より先に承認者を固定。出力は下書き扱い
• 長時間作業は、途中確認の点を先に置く。完了まで任せない

これは一例です。業種で中身は変わります。

変わらないのは順番です。

階層を選ぶ前に、仕事の箱と承認者を決める。

最初に試す一業務の選び方そのものは、最初に試す1業務の選び方へ任せます。

本稿で決めるのは、その前の設計です。

試す単位を「モデル名」だけにしない。 「どの箱の仕事を、どの階層で、誰が止めるか」を単位にする。

会議で使うなら、表は一枚で足ります。

左に仕事の箱。 右に使う階層の候補。 その横に承認者。 一番右に、止める条件。

この表がないまま「Solへ寄せる」「Terraで十分」と言い合うと、名前の好みの話になります。

名前の好みでは、月曜の運用は決まりません。

企業の順位主張を、自社の標準にしない

モデル発表では、提供者側の性能主張が並びます。

ここで混同してはいけないものがあります。

提供者の主張と、自社で確認済みの事実です。

OpenAIの発表では、階層の名前、価格帯の存在、段階的な提供が示されています。ここまでは発表として扱えます。

一方、どの階層が自社のどの仕事で十分かは、自社の代表タスクで見る必要があります。

SOTAである、他社より上である、という断定は、本稿では採否の材料にしません。

発表文の順位表を、社内標準の根拠にしないためです。

自社で残すのは、次の確認です。

• 代表タスクは何か
• 成功の定義は何か
• 失敗で止める定義は何か
• 確認者は誰か
• 日常作業用と重い作業用を分けるか

この確認がない切替は、ニュースへの反応です。運用ではありません。

出力を使うときの確認ルールは、一つの確認ルールを置くへ接続できます。

階層選びは、その確認ルールの前段です。

どの出力を、どの厚みの確認に乗せるかを、仕事の箱で先に分ける。

先に決めるのは、仕事の分け方

モデルが三つに分かれた週に必要なのは、いちばん強いものを追うことではありません。

仕事を分け、使う階層と承認者を先に決めることです。

性能比較は、そのあとに来ます。

分け方がないまま表を見ても、迷いが増えるだけです。

月曜の会議で残すなら、次の三行で足ります。

1. 日常の下書きと、外に出る文を分ける
2. 各箱の承認者を一名にする
3. 見えている階層の範囲で、一件だけ試す

モデル階層の発表は、道具の棚が増えた知らせです。

棚が増えたときに先にやるのは、いちばん高い棚へ全部を移すことではありません。

何をどの棚に置くかを決めることです。