モデルを上げる前に決める、「前より良い」の判定基準

水曜の午後、チャットが止まります。

「新しいモデル、上げた？」 「まだ見比べてる。」 「どこまで見れば終わり？」

モデルが新しくなると、現場はだいたい同じ動きをします。

発表を見る。 デモを見る。 「上がったらしい」と話す。 試しに切り替える。

そのあとで、全体を見比べます。

画面が多いほど、見比べは終わりません。 終わらないまま、「とりあえず新モデル」が定着します。

Google Cloudは2026年7月17日、基盤モデル更新をエージェントワークフローへ移した知見を公開しています。評価やオーケストレーションを仕組みにする、という方向です。特定製品の手順解説をするつもりはありません。

先に決めるのは、業務側の「前より良い」です。

新しいは、前より良いではない

新しいモデルは、何かが変わります。

速くなることもある。 丁寧になることもある。 冗長になることもある。 得意な作業がずれることもある。

変わることと、自社の仕事が良くなることは別です。

別なのに、現場ではこう省略されます。

新しい＝良い。 良い＝上げる。 上げた＝改善した。

省略の途中で消えるのが、判定基準です。

判定基準がない更新は、改善ではなく移動です。 移動には、戻すコストがつきます。

「前より良い」は、誰かの感想ではない

感想は必要です。 ただし、判定にはしません。

判定にするのは、仕事の受け取り条件です。

一次回答が、個人情報を含まず、担当者が送信できる割合が下がらない。 社内要約が、決定事項と保留事項に分かれ、追記が2回以内で終わる。 コード変更の提案が、既存テストを落とさない。

数字は粗くて構いません。 必要なのは、誰が、何を見て、良いと言うかです。

AIが良い解を出したときに、何を良いとするかを誰が決めるか、という大きな話は、AIが良い解を出したとき、何を良いとする評価を誰が決めるかに任せます。

こちらは、モデル更新の現場に落とす一点です。

更新前に、業務側の回帰観点を三つまで書く。

全画面見比べが詰まる理由

全画面見比べは、誠実に見えます。 実際は、詰まりやすいです。

観点が増えすぎる。 責任者が「全部見た」と言えない。 差分のどれが許容かが決まっていない。

結果として、更新が数週間止まります。 止まるほど、現場は旧モデルのまま急ぎの仕事を回し、検証用の時間だけが削られます。

詰まりを外すのは、人も時間も増やすことではありません。

見る画面を減らすことです。

代表タスクを三つに絞る。 その三つだけで、前より良いかを判定する。

残りは、更新後の監視に回します。

自動採点を、最終判定者にしない

自動で採点する仕組みは便利です。 便利なまま最終判定者にすると、現場の受け取り条件が消えます。

自動評価が向くのは、形式が崩れていないか、必須項目が欠けていないか、以前落ちたケースが再発していないか、といった確認です。

向かないのは、顧客に出してよいか、社内の温度感として失礼でないか、例外対応を人が引き取るべきか、といった判断です。

自動は補助です。 最終は、完了を受け取れる人です。

完了の定義は、AIの価値を測る前に、その仕事の完了を一行で言えるかとつながります。更新判定も、同じ一行から始まります。

自動評価を増やす前に、人が見る三点を固定してください。

固定しないまま自動を増やすと、点数は出ても、現場は「で、使ってよいのか」に戻ります。 点数会議と、受け取り会議は別です。 水曜の詰まりを外すのは、点数の多さではなく、受け取り条件の短さです。

戻し方がない更新は、実験ではない

上げる前に、戻し方も一行で書きます。

いつ戻すか。 誰が戻すか。 戻したあとに残すログは何か。

戻し方がない切り替えは、実験ではなく賭けです。

賭けは、金曜の振り返りで説明できません。 説明できない更新は、次の更新も止めます。

「なんとなく成功」が始まるとき

判定基準が弱いと、成功の定義が後から動きます。

最初は「速さ」と言っていた。 途中で「文章の自然さ」に変わる。 最後は「とりあえず大きな事故がなかった」になる。

動く成功定義は、学習ではありません。 説明の逃げです。

逃げを防ぐには、更新前に基準を固定します。

固定した基準で失敗したら、戻す。 戻した事実を残す。 次の更新で、同じ失敗条件を最初に見る。

この繰り返しが、モデル更新の運用です。 発表を追うこと自体は、運用ではありません。

水曜にやるなら、この順番

更新対象の仕事を一つ選ぶ。 「前より良い」を三行で書く。 代表タスクを三つ固定する。 失敗したら戻す条件を一行で書く。 そのあとで、新モデルを試す。

順番を逆にしないでください。

試してから基準を作ると、基準は成功例に合わせて歪みます。

歪み方は、だいたい同じです。

うまくいった例だけが残る。 うまくいかなかった例は「使い方の問題」になる。 戻す判断が「雰囲気」になる。

雰囲気の更新を続けると、現場は新モデル疲れを起こします。 疲れの本体は、モデルではありません。 判定基準がないことです。

先にやることは、大きな評価基盤を作ることではありません。 代表タスク三つと、戻す条件一行です。

代表タスクは、派手なデモでなくていい

代表タスクは、派手なデモである必要はありません。

選ぶ基準は、単純です。

毎週発生する。 人が受け取れる／受け取れないが分かれる。 失敗したときの影響が説明できる。

逆に、避けるものです。

年に一度しかない特殊案件。 正解が人によって大きく違う創作作業だけ。 誰も責任を持たないお試し質問。

お試し質問で新モデルがうまくいっても、本番の詰まりは消えません。代表タスクは、毎週起きる仕事から選んでください。

現場で書くなら、この言い方

問い合わせ一次回答なら。

前より良いのは、送信可能な文になるまでの人修正が前回より増えないこと、個人情報が混ざる失敗が減ること。 前より良くないのは、文章は上手いが、確認項目が増えて担当が止まったまま、です。

社内議事の整理なら。

前より良いのは、決定と保留に分かれること、追記依頼が2回以内で終わること。 前より良くないのは、長い要約はできるが、誰が何を持つか消えること、です。

開発の補助なら。

前より良いのは、既存テストを落とさない変更提案の割合が維持されること。 前より良くないのは、提案は増えるが、戻し方がないまま本番ブランチへ寄ること、です。

この粒度があると、「なんとなく良い」会議が短くなります。

水の詰まりを外す一行

週の途中でモデル更新が止まっているなら、残す一行はこれです。

この仕事で、前より良いとは何か。

答えられないなら、更新作業を増やさないでください。 答えられるなら、見比べる画面を三つに減らしてください。

答えのあとに残すものも、多くありません。

代表タスク三つ。 失敗したら戻す条件一行。 確認者の名前一人。

確認者は、新モデルが好きな人である必要はありません。 仕事の受け取り可否を言える人です。名前を一人決めておくと、更新会議は感想大会になりにくいです。

好き嫌いと、受け取り可否を混ぜると、更新会議は感想大会になります。 感想大会のあとに残るのは、また全画面見比べです。水曜の詰まりを外す一行は、これだけです。

モデルを上げる前に決めるのは、評判ではありません。

「前より良い」の判定基準です。

基準がある更新は短く終わります。基準がない更新は、毎週同じ場所で詰まります。

検証が長い週ほど、基準が決まっていないことが多いです。代表タスク三つと、戻す条件一行を先に置いてから、更新会議に載せるのは合否と戻すかどうかだけにしてください。感想と合否を混ぜると、また全画面見比べに戻ります。戻る前に、確認者の名前を一人だけ固定しておくと、会議は短くなります。