AIサービスの工程ごとにモデルを分けるか：合計費用ではなく失敗の見え方で決める

A&Aの考え方

自社サービスの工程ごとにモデルを分けるかどうかは、合計費用の大きい工程から順に替えるのではなく、工程ごとに二つを先に答えて決めます。一つ目は「その工程の失敗が、その工程の中で検知できるか」。二つ目は「検知できないまま後段へ流れていくか」。中で検知でき、後段へ伝播しない工程だけを安いモデルへ寄せ、どちらかを満たさない工程は、それが請求額の最大費目であっても据え置きます。

A&Aの考え方

この順番にする理由は単純です。費用から入ると、必ずいちばん高い工程から触ることになります。ところが高い工程とは、たいてい長い文脈を読んで判断を出している工程であり、その出力が正しいかどうかはその工程の中では判定できません。品質が落ちたことに気づくのは、後段を通って顧客に届いたあとです。費用の順番は、失敗が見えにくい順番とほぼ一致します。

A&Aの考え方

請求書に出てくるのは、月あたりいくら使ったかという一つの数字か、せいぜいモデル別の内訳です。そこには「どの工程が何回呼ばれたか」「そのうち何回が失敗したか」「失敗はどこで見つかったか」が入っていません。つまり合計費用は、替えてよい工程と替えてはいけない工程をまったく区別しません。この状態で安いモデルを試すのは、どの工程が壊れたか分からないまま全体を壊す試し方です。

A&Aの考え方

一つのモデルで全工程を動かしていると、この区別がない状態が普通になります。工程という単位で品質を見たことがないので、品質は「サービス全体の品質」という一つの塊でしか語れません。塊のままでは、下げてよい部分も分かりません。だから最初の作業はモデルの比較ではなく、工程を数え上げて、工程ごとに失敗の見え方を書くことです。

A&Aの考え方

ここで「工程」とは、入力と出力がはっきりしていて、途中で止めても次に何を渡すか言える単位です。受付の分類、必要情報の抽出、記録の検索、原因の推定、返信の下書き、送信。これくらいの粒度まで割ると、どの工程が自分の中で完結しているかが見えます。逆に「問い合わせ対応」という一つの工程しか書けないなら、分ける判断はまだできません。

A&Aの考え方

ただし、ここから持ち帰るのは割り当ての結果ではなく、割り当ての軸です。記事に出てくるモデル名と対応は2026年2月時点の同社の構成であり、推奨配合ではありません。版も価格も変わります。そして同社は「どういう条件を満たした工程を軽い側に寄せたのか」という判定条件までは書いていません。その条件をこちらで言語化したのが、次の二条件です。

A&Aの考え方

一つ目の条件は、失敗がその工程の中で検知できることです。検知できるとは、出力を見れば合否が言える、ということです。出力の形が決まっている工程はこれを満たします。分類なら決められた区分のどれかに入っているか、抽出なら必要な項目が埋まっていて型が合っているか。合否は次の工程を待たずに、その場で言えます。

A&Aの考え方

二つ目の条件は、検知できなかった失敗が後段へ伝播しないことです。伝播するとは、その工程の誤りが後の工程の入力になり、後の工程がその誤りを前提として正しく動いてしまうことです。要約して次へ渡す工程が危ないのはここです。要約から事実が一つ落ちても、要約としては読めてしまう。後段はその欠けた要約を正しい入力として扱い、整った誤りを出力します。誤りが整っているほど、見つかるのは遅くなります。

A&Aの考え方

二条件は順番に使います。一つ目を満たせば、二つ目は実質的に問題になりません。その工程で止められるからです。一つ目を満たさない工程について、二つ目を見ます。検知できず、しかも後段へ流れるなら据え置き。検知できないが、後段へ流れる前に人が必ず読むなら、人の確認がその工程の検査として働くので、寄せられます。Gumloopの監視の例のように、人に上がる条件が工程の側に書かれていることが前提です。

A&Aの考え方

この二条件の効果は、費用の順番を壊すことです。いちばん高い工程が据え置きになり、安くて回数の多い工程が移動対象になることは普通に起こります。節約額としては物足りなく見えますが、品質を落とさずに下げられるのはその範囲だという答えが出ているので、それ以上は別の手段、つまり工程の設計を変える話になります。

A&Aの考え方

二条件で分けると決めても、分けたあとに見る数字がなければ、品質が落ちたかどうかは顧客からの指摘でしか分かりません。工程単位で決めた以上、記録も工程単位で持つ必要があります。何を記録するかについては、道具の評価という近い文脈に一次記述があります。

A&Aの考え方

ここは出典の適用範囲をはっきりさせておきます。この記事は道具の評価について書かれたもので、モデルの使い分けについて書かれたものではありません。工程ごとの判断材料としてこの項目を使うのはA&Aの読み替えです。それでも読み替える価値があるのは、二条件が要求するものとこの項目が一致するからです。「工程内で検知できる」とは検証可能な合否があることで、エラーを工程ごとに数えられることとほぼ同じ意味になります。

A&Aの考え方

判断を一枚に落とします。工程を縦に並べ、横に四列を書きます。一列目は工程名。二列目は「失敗がこの工程の中で見えるか」で、見えるなら何を見れば合否が言えるかを具体的に書きます。三列目は「見えないまま後段へ流れるか」。四列目は結論で、寄せる／据え置くのどちらかと、その工程で記録する項目です。

A&Aの考え方

この一枚で大事なのは、据え置く工程も同じ表に残すことです。据え置いた理由が書かれていないと、数か月後に請求額を見た自分が、同じ工程をもう一度触りたくなります。「ここは検知できないので据え置き」と書いてあれば、次に考えるのは安いモデルではなく、検知できるように工程を割り直すことだと分かります。

A&Aの考え方

記録する項目は、工程ごとに同じ三つで足ります。呼び出し回数、消費したトークン量、その工程で合否が不合格になった回数です。寄せた工程は、三つ目が動かないことを確認するために見ます。据え置いた工程は、一つ目と二つ目を見て、そもそも寄せる価値のある規模なのかを確認します。

A&Aの考え方

据え置きと決まった工程を、そのまま放置する必要はありません。その工程でできるのは、モデルを替えることではなく、失敗が後段へ流れる前に止まる場所を作ることです。具体的には、人へ上げる条件をその工程の中に書きます。条件を書くとは、何が起きたら上げるかと、何も起きなければ上げないことを同時に決めることです。

A&Aの考え方

そして、条件を書いて人が必ず読む工程になったなら、その工程は二条件の二つ目を満たすようになります。つまり据え置きから寄せる側へ動く可能性が出てきます。順番は逆にできません。検査を作るのが先で、モデルを替えるのは後です。費用を下げる作業の実体は、モデルの選定ではなく検査の設置であることが多いです。

A&Aの考え方

この架空例で意図的に出していないのが、削減額です。価格は版によって変わり、工程ごとのトークン量も実装で変わるので、ここで金額を出すと前提の方が先に古くなります。出すべきなのは順番です。寄せられる工程を数え、その呼び出し回数とトークン量を自分の記録から読み、それからモデルの価格表を見る。価格表を先に見ると、また合計費用の話に戻ります。

A&Aの考え方

最初の限界は、分けること自体の維持費です。工程ごとにモデルを変えると、工程間の受け渡しと検証が増え、どの工程がどのモデルで動いているかを把握し続ける必要が出てきます。一人で維持する場合、この維持費が削減額を上回ることは普通にあります。寄せられる工程が二つしかなく、その二つの費用が小さいなら、分けないという判断が正しい判断です。二条件は分ける許可を出す道具であって、分けることを勧める道具ではありません。

A&Aの考え方

二つ目の限界は、工程をまだ割れていない場合です。実装が一つの長い指示で全部をやっているなら、工程単位の判断材料は存在しません。この場合に必要なのはモデルの比較ではなく、工程を割って、それぞれの入力と出力を決めることです。その作業は費用対策ではなく設計のやり直しなので、別の作業として見積もってください。

A&Aの考え方

加えて、Gumloopの記事は同社が自社の運用を書いたもの、Anthropicの記事は自社の知見を書いたものであり、どちらも第三者による監査ではありません。費用削減率や品質への影響を示す数値は、両記事にもこの記事にもありません。工程を分けること自体を勧める根拠は、ここにはないということです。

A&Aの考え方

今日の一歩は、価格表を開かないことから始まります。自分のサービスの工程を紙に書き出し、各行に「この工程の失敗は、この工程の中で何を見れば分かるか」を一文で書く。書けない行が、据え置く行です。書けた行の呼び出し回数とトークン量だけを記録から拾い、その合計が維持費を払う価値のある規模かを見る。ここまでやってから、モデルを比べてください。

A&Aの考え方

なお、ここまでの話は社内の工程にモデルを割り当てる判断です。顧客にモデルを選ばせるかどうかは判断主体が違う別の問題で、「顧客にモデルを選ばせるか、既定で固定するか：設定項目を増やす前に決める」で扱っています。社内の割り当てが先に決まっていないと、顧客に出す既定も決められません。