A&A INSIGHTS
AI SaaSのモデル更新を決める条件：ベンチマークではなく顧客の失敗例で判断する
新しいモデルへ切り替えていいかは、公開ベンチマークではなく、顧客が実際に出す代表タスクで前より確実に終わるかで決めます。過去の失敗から代表タスクを作り、採用・部分採用・保留・戻すの四つを更新前に条件として書く手順を、LovableとAnthropicの公開記録から整理します。
Read in English
この記事の要点
AI SaaSのモデル更新は、公開ベンチマークの順位ではなく、顧客が実際に出す依頼を写した代表タスク群で、いまより確実に終わるかどうかで決めます。過去の失敗と手作業の確認から代表タスクを集め、合否を顧客が受け取る状態で書き、採用・部分採用・保留・戻すの四つを更新作業の前に観測条件として文章にしておきます。
モデル更新の可否は、顧客の代表タスクの合格数で決める
A&Aの考え方
新しいモデルへ切り替えてよいかは、公開ベンチマークの順位でも、自分で触った感触でもなく、顧客が実際に出す依頼を写した代表タスク群で、いまより確実に終わるかどうかだけで決めます。手順は三つです。第一に、過去の失敗と、リリース前に毎回手で確かめている動作から代表タスクを集める。第二に、合否を出力の良否ではなく顧客が受け取る状態で書く。第三に、採用・部分採用・保留・戻すの四つを、更新作業を始める前に観測条件として文章にしておく。これがこの記事の答えで、以下はその根拠と、更新前に埋める四行の判断表です。判断が止まるのは情報が足りないからではなく、合否の定義が手元にないからだ、というのがこの記事の立場です。
出典に基づく事実
AnthropicのサイトにあるLovableの導入記録には、同社が新しいClaudeのリリースごとに、最初から走らせている同じ評価を通していると書かれています。原文は「Every new Claude release goes through the same evaluation Lovable has run from the start」で、測っているのは「how often the system hits a wall and produces an app that’s broken or isn’t what the user asked for」、つまり系が行き詰まる頻度と、生成されたアプリが壊れているか依頼と違っている頻度です。同ページはその関門が重要な理由を「Lovable’s users often can’t read the code themselves, so they’re trusting the output to work」と説明しています。利用者が自分ではコードを読めないので、動くことを信じて使っている、という記述です。
A&Aの考え方
ここから一人・少人数の開発者が持ち帰れるのは件数や体制ではなく、評価を「毎回同じものを通す関門」として固定する、という形だけです。Lovableの規模や運用条件は同社のもので、他社の見込みにはなりません。一方で「顧客は出力を自分で検算できないまま信じている」という条件は、規模に関係なく、生成物を売っている小さな会社にそのまま当てはまります。顧客が自分で品質を確かめられないなら、確かめる役は売り手側の固定した評価しかありません。なお同ページには評価の件数・合格基準・実行頻度は書かれていないため、この記事で示す件数や条件はA&Aの設計案として読んでください。
ベンチマークが上がっても、売っている仕事が終わるとは限らない
出典に基づく事実
Anthropicが2026年1月9日に公開した評価の解説（著者はMikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe）は、評価スイートを「An evaluation suite is a collection of tasks designed to measure specific capabilities or behaviors」と定義し、続けて「Tasks in a suite typically share a broad goal」と述べています。挙げられている例は、カスタマーサポートの評価スイートなら「refunds, cancellations, and escalations」を試すというものです。つまり評価の単位は、モデル一般の優劣ではなく、特定の能力や振る舞いを測るために選んだタスクの集まりです。
A&Aの考え方
この定義をモデル更新の判断に持ち込むと、比べるべき対象がはっきりします。公開ベンチマークは他人が選んだタスクの集まりで、その共有された広い目標はあなたが売っている仕事ではありません。自社の代表タスク群は、あなたの顧客が実際に出す依頼から作った集まりで、広い目標は「売っている仕事が終わること」です。二つは別の物差しなので、前者が上がっても後者が上がる保証はありません。逆に、後者が下がっていないなら、前者の順位が振るわなくても切り替えて構いません。これはA&Aの読み方で、出典はモデル更新の可否判断そのものについて述べたものではありません。
出典に基づく事実
Lovableが測っていたものも公開ベンチマークではなく、自社のタスクでの不一致でした。同じページには、特定のリリースが利用者に作れるものを変えた転換点として、同社でプロダクトを率いるAlexandre Pesantの言葉で「Claude Sonnet 3.5 was the first model that made agents work」、そしてClaude Opus 4.5が「the next big step change in reliability on long-horizon tasks」だったという記述があります。ただしこれは同社が自社のプロダクトで観測した体験談であり、モデルの一般的な性能を測った結果として示されているわけではありません。
| 出口 | 代表タスクで観測すること | そのとき取る行動 |
|---|---|---|
| 採用 | 既存の合格項目が一つも減らず、これまで落ちていた項目のいくつかが通る | 全顧客へ切り替える。同じ代表タスク群を次の更新まで固定して残す |
| 部分採用 | 一部の工程だけ改善し、別の工程では合格していた項目が落ちる | 工程ごとにモデルを分ける。落ちた工程は旧モデルのまま残す |
| 保留 | 合格数は変わらず、費用または所要時間だけが動く | 切り替えない。次のリリースか次のモデル更新のどちらで見直すかを書く |
| 戻す | 既存の合格項目が落ちる、または顧客の記録と出力の不一致が出る | 旧モデルへ戻す。落ちた項目を代表タスク群へ追加して固定し直す |
代表タスクは、過去の失敗から集める
出典に基づく事実
同じ解説は、評価を作り始めるときの規模について「We see teams delay building evals because they think they need hundreds of tasks」と書き、実際には「20-50 simple tasks drawn from real failures is a great start」だとしています。その理由として、初期のエージェント開発では一つの変更の影響がはっきり見えるため「this large effect size means small sample sizes suffice」と説明しています。同時に「More mature agents may need larger, more difficult evals to detect smaller effects」とも述べ、成熟した系ではより大きく難しい評価が必要になることを断っています。
出典に基づく事実
材料の出どころも指定されています。「Begin with the manual checks you run during development」、つまりリリース前に毎回確かめている動作と、利用者がよく試す作業から始める。すでに本番があるなら「look at your bug tracker and support queue」を見る。そして「Converting user-reported failures into test cases」によって、評価が実際の使われ方を反映するようにする、という順序です。先延ばしの費用についても「Evals get harder to build the longer you wait」と書かれ、待ちすぎると「reverse-engineering success criteria from a live system」になると述べています。
A&Aの考え方
一人の会社に整ったbug trackerやsupport queueがないことはよくあります。その場合の等価物は、問い合わせの文面、同じ依頼をやり直した記録、検収でもらった指摘、値引きや無償対応で収めた経緯です。体裁が整っていないだけで、実際の失敗としては十分な材料です。A&Aの提案は、この四つを出どころにして代表タスクを集め、顧客ごとに一件以上、過去に苦情や再作業が出た型は必ず含めることです。件数は出典の20〜50件をそのまま持ち込むのではなく、自社の依頼が何種類の型に分かれるかで決めます。型が五種類しかないなら、一種類あたり何件そろえるかで総数が決まります。
仮想例
架空の例で形を示します。会議の録音から議事要旨と宿題一覧を作る、三人のSaaSだとします。代表タスクは30件。うち12件は過去に苦情が出た型で、二人が同時に話している録音、社内略語が多い録音、途中で議題が変わる録音などです。残り18件は毎リリース前に手で確かめている通常の型です。この30件は固定し、モデルを替えるときは必ず同じ30件を通します。新しく苦情が出たら、その録音を31件目として足し、以後は31件で固定します。これは実在の顧客の記録ではなく、形を示すための仮の例です。
合否は、顧客が受け取る状態で書く
A&Aの考え方
代表タスクを集めても、合否の書き方が「出力が良いか」だと判断は進みません。良し悪しは人によって揺れるので、更新のたびに議論が振り出しに戻ります。A&Aの提案は、合否を顧客が受け取る状態で書くことです。議事要旨なら「決まったことが漏れていない」ではなく「録音に出てくる決定事項のうち、一覧に載っていないものがない」。宿題一覧なら「担当者が書かれている」ではなく「担当者名が録音中の発言と一致している」。どちらも、別の人が同じ録音を聞いて同じ判定に至れる形です。判定が人によって変わる項目は、合否ではなく参考として別の欄に置きます。納品済みの仕組みで一件の完了をどう確かめるかという隣の論点は、既存記事の「AIが「完了」と言ったあと、業務の成果をどう確かめるか」で扱っています。
出典に基づく事実
出典も同じ方向を指しています。良いタスクの条件として「A good task is one where two domain experts would independently reach the same pass/fail verdict」と述べ、仕様の曖昧さは指標の雑音になると書いています。採点をモデルに任せる場合は、作り物の判定を避けるために「give the LLM a way out」、つまり情報が足りないときにUnknownを返させる指示を入れることを勧めています。
仮想例
先の架空のSaaSで、合否の書き方を三行だけ示します。一行目、決定事項の網羅：録音中に「これで進めます」等の合意が成立した箇所すべてが、要旨の決定事項欄に一件以上対応している。二行目、担当者の一致：宿題一覧の担当者名が、録音中でその作業を引き受けた発言者と一致している。三行目、作り話がない：要旨と一覧に、録音に根拠のない固有名詞・日付・数値が含まれていない。三行はいずれも録音を聞けば別の人が同じ判定を出せます。これは仮の例で、実在の顧客の基準ではありません。
採用・部分採用・保留・戻すの四つを、更新前に条件として書く
A&Aの考え方
更新作業を始める前に、出口を四つ書いておきます。採用、部分採用、保留、戻すです。このうち小さなチームで最も不足しているのは保留で、条件を書いていないと「まだ判断していない」状態が無期限に続きます。保留とは、代表タスクの合格数が変わらず、費用や所要時間だけが動いた場合の出口です。切り替えずに次の更新まで持ち越す、と決めてしまえば、その週に別の仕事へ戻れます。保留には必ず期限ではなく「次に見直す機会」を書きます。次のリリース、あるいは次のモデル更新のどちらかです。
出典に基づく事実
費用や所要時間で判断できるのは、評価がすでにあるからです。出典は「you get baselines and regression tests for free」と述べ、静的なタスク群の上で追える指標として「latency, token usage, cost per task, and error rates」を挙げています。同じ解説は、評価が初期の開発でも期待する振る舞いを明文化する点で有用だと述べ、「Two engineers reading the same initial spec could come away with different interpretations」、つまり同じ初期仕様を読んだ二人の技術者が、AIが例外的な場合をどう扱うべきかについて別々の解釈に至りうるとし、「An eval suite resolves this ambiguity」と書いています。
A&Aの考え方
表の読み方はひとつだけです。左から右へ、観測したことに対して取る行動が一意に決まっていること。合格数が減っていないのに議論が続くなら、それは表の書き方が甘いということです。四つの出口のうち二つ以上に当てはまる観測が出たら、代表タスクの分け方が粗すぎます。工程ごとに分け直してから、もう一度通します。この表とその四つの区分はA&Aの設計案で、出典に書かれているものではありません。
戻せる形にしてから試す
A&Aの考え方
戻すという出口は、条件を書くだけでは使えません。実際に戻せる状態にしてから試します。最低限そろえるのは三つです。旧モデルを呼べる経路を消さずに残すこと、切り替えが設定の一箇所で済むこと、いつ何を切り替えたかを記録に残すことです。三つ目が抜けていると、顧客から苦情が来たときに、原因がモデルの変更なのか別の修正なのかを切り分けられません。切り替えの記録は、顧客ごとの問い合わせ記録と同じ時刻の物差しで並べられる形にしておきます。
出典に基づく事実
Lovableの記録には、工程ごとにモデルを選ぶ構成も書かれています。Pesantの言葉では「We have a harness around a main agent that can use subagents to orchestrate tasks effectively, with the right models at each step」で、主となるエージェントが組み立てを考え、小さな仕事を副エージェントへ渡し、各段の仕事に最も適したモデルを割り当てる、という説明です。
A&Aの考え方
この構成があるので、部分採用という出口は形として成り立ちます。ただし小規模事業への当てはめはA&Aの仮説です。工程の数が少ないほど分けやすい一方で、工程ごとにモデルが違えば、検証すべき組み合わせは工程の数だけ増えます。代表タスクを工程単位で分けていないなら、部分採用を選ばず、採用か保留のどちらかに寄せたほうが手戻りが少ないと考えます。工程を分けるかどうかは、確認にかけられる人の時間の話でもあります。その見積もりは既存記事の「AI受託を増やす前に、人の確認で詰まる量を見積もる」で扱っています。
評価があれば更新の判断は数日で済む、と出典は述べている
出典に基づく事実
出典は、評価の有無がモデル採用の速さを決めると明記しています。より強力なモデルが出たとき「teams without evals face weeks of testing」であるのに対し、評価があるチームはモデルの強みをすぐ見極め、プロンプトを調整し、「tune their prompts, and upgrade in days」できるという記述です。評価は回帰の追跡だけでなく、開発を速めるためにも有用だと書かれています。
A&Aの考え方
この「数週間」は、一人や三人の会社では創業者自身の数週間です。その間、営業も納品も止まります。だから代表タスク群を作る手間は、品質管理の費用ではなく、更新判断を自分の手元に取り戻すための費用だと考えます。「新しいモデルはたいてい良くなるのだから、評価を作る手間より早く乗り換えたほうが得だ」という反対の立場には、条件つきで同意します。既存顧客がまだ日常的に使っていない段階なら、そのとおりです。顧客が毎日使っている段階では、切り替えて苦情が出たときの説明と手戻りが、乗り換えの速さで得た分を上回りやすいと考えます。
出典に基づく事実
先延ばしの費用は積み上がります。出典は「Evals get harder to build the longer you wait」と書き、初期は製品の要件がそのまま試験項目になるのに対し、待ちすぎると「reverse-engineering success criteria from a live system」になると述べています。稼働している系から成功の基準を逆算する作業になる、という指摘です。
この決め方が成り立たない場合
A&Aの考え方
限界を三つ書きます。第一に、Lovableの記録はAnthropic自身のサイトに載る顧客事例で、独立した監査ではありません。同ページ冒頭には売上や累計プロジェクト数の数字が掲げられていますが、これは同社が自社について公表した記述で、他のチームの見込みにはならないため、この記事では使っていません。「一人でも同じ形の固定した評価を関門にできる」という接続もA&Aの解釈で、同社の体制とは別の話です。
A&Aの考え方
第二に、Anthropicの評価解説はAIエージェントの品質評価を主題にした技術文書で、モデル更新の商売上の可否をどう決めるかを述べたものではありません。20〜50件という規模も、初期のエージェント評価についての目安として書かれたもので、あらゆる規模・領域の基準ではありません。採用・部分採用・保留・戻すの四つの区分と判断表は、出典の記述ではなくA&Aの設計案です。
A&Aの考え方
第三に、代表タスクの合格は本番のすべてを代替しません。評価を通っても本番で落ちる経路は残り、通らなかった項目が実際には問題にならないこともあります。この記事はA&Aの受注率、成約率、顧客の成果、検索順位を一切示していません。次の一歩は、いま出している出力の型を数えて、過去に苦情が出た型がいくつあるかを書き出すことです。顧客獲得から継続利用までの中でこの判断がどこに位置するかを確かめたい場合は、「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」が全体の地図になります。合否の定義が顧客ごとに揺れていて自社だけで決め切れないなら助言型の相談が向いていますし、代表タスク群と切り替え経路をどう実装するかが課題であれば、範囲を切った開発として進めるほうが早く終わります。
モデル更新の可否は、新しさでも自分の感触でもなく、顧客が実際に出す依頼を写した代表タスク群で、売っている仕事が前より確実に終わるかどうかで決まります。代表タスクは過去の失敗と手作業の確認から集め、合否は別の人が同じ判定に至れる形で書き、採用・部分採用・保留・戻すの四つを更新前に観測条件として文章にします。戻せる経路と切り替えの記録は、試す前に用意します。ここに挙げた四つの出口と判断表はA&Aの設計案で、出典はモデル更新の可否判断を述べたものではありません。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Lovable helps anyone create software 20x faster with Claude
Anthropic · n.d.
確認日 2026-09-25 - Demystifying Evals for AI Agents
Anthropic · 2026-01-09
確認日 2026-09-25
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-25