LLM比較｜決まった処理は、賢さより毎回同じ答えかで選ぶ

三年ほど前に、よく切れる包丁を1本だけ買いました。（僕が学生時代にアルバイトをしていた先輩が研師になって僕のために見繕ってくれました。）それまで台所にあった刃物は、ぜんぶ引き出しの奥にしまいました。1本あれば足りると思ったからです。

トマトも、鶏肉も、食パンも、その1本で切りました。トマトと鶏肉は、驚くほどきれいに切れます。

ところが食パンだけは、切るたびに断面が潰れパンの厚みがわかりづらくなり均等な厚みに切れなくなりました。

結局、パン用のギザギザした包丁を、あとから買い足しています。よく切れることと、パンがいつも同じ厚さで切れることは、別のことでした。

ここ数年、大規模言語モデル（LLM）の新しい型番が、数か月おきに出るようになりました。どれを選ぶかで結果が変わると言われ、LLMの比較表もたくさん公開されています。表を読むと、たいてい賢い順にモデルが並んでいます。

僕も、その表の一番上を選びました。そして、文章を書かせるところにも、決まった形で値を取り出すところにも、同じ1つのモデルを当てて、外しています。

先に一行だけ置きます。LLMを比較するとき、賢さの順位だけで選ぶと外します。 順位が効くのは書きぶりと判断の部分だけで、決まった形で返してほしいところは、毎回同じ答えが返るかで選ぶからです。

今日は、LLMを比較する軸を、賢さから何に変えたのか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

この話に出てくる事業

大企業と僕の会社で組んで、最小構成で試すところまで立ち上げた事業がいくつかあります。そのひとつが、医療機関向けに白衣とリネンをレンタルする事業の、問い合わせ受付です。病院とクリニックに白衣・シーツ・バスタオルを貸し出し、週2回、汚れたものを回収して洗って納品します。

問い合わせは、看護部長や事務長からメールで届きます。「白衣のサイズをMからLに交換したい」。「今週の回収を木曜から金曜にずらしてほしい」。「大判のバスタオルが3枚足りない」。受付に届くメールは、1日に40件前後あります。

受けているのは、営業事務の担当者が2名です。担当者は、届いたメールを読んで、社内の管理表に品目と枚数と日付を打ち込み、それから返信を書きます。

この問い合わせの一次返信を、LLMに任せることにしました。やらせたのは3件です。返信の文面を書くこと。メールから「どの施設の、どの品目を、何枚、いつ」を決まった形で抜き出すこと。そして送り主が書いた品名を、社内の品目名に寄せることです。

3件目だけ、少し説明が要ります。同じ品物が、送り主によって「大判のバスタオル」とも「浴用タオル」とも「BT」とも書かれてきます。この表記のゆれを、社内で使っている1つの品目名に寄せる処理です。

① 教科書どおりに、比較表の一番上のモデルを選んだ

モデルの選び方は、素直に教科書どおりにしました。

公開されているLLMの比較表を3件ならべて、共通して上位にいるモデルを1つ選びます。そして、返信の文面も、項目の抽出も、品名を寄せる処理も、全部そのモデルに投げました。1つの賢いモデルで足りるなら、切り替えの手間もかかりません。

最初の返信が出たのは、着手から3週間後です。

試しに「今週の回収は金曜でお願いします」というメールを流してみました。返ってきたのは、日付の変更を承知した旨の2段落の文面と、その下に並んだ抽出の結果です。施設名、回収日、変更前の曜日。3つとも合っていました。

担当者の2名に見せたときの反応も良く、うち1名は「これなら来週から使えますね」と言っています。

教科書が間違っていたわけではありません。 この時点では、モデルの選び方を外したという感覚はまったくありませんでした。

② 同じメールを3回投げると、3回とも違う形で返ってきた

ところが、抽出の結果を検証しはじめると、様子がおかしくなってきました。

まったく同じメールを3回投げます。「白衣のサイズをMからLに交換したい」という、品目が1件しか出てこないメールです。返信の文面は、3回とも表現が違いました。文面については、それでかまいません。むしろ毎回おなじ挨拶文が返るほうが不自然です。

問題は、その下の抽出のほうでした。 品目は1件しかないのに、3回のうち1回は2件になり、1回は3件になります。枚数の入っていない回もありました。

言い方を変えたメールを並べて、検証セットを作りました。「金曜にずらして」「金曜でお願いします」「木曜は無理になりました」のように、依頼の中身は同じで言い回しだけを変えたものです。全部で42件あります。通してみると、抽出の失敗は42件のうち十数件で出ました。

品名を寄せる処理では、別の壊れ方をしました。10件をまとめて投げると、返ってくるまでに1回あたり26秒かかります。担当者は返信の下書きが出るまで画面の前で待つので、26秒は長すぎました。そのうえ、カタカナが記号に化けることがありました。「ガーゼケット」が「〒〳ゼケット」になって返ってきています。

もうひとつ、返す形の指定にも穴がありました。枚数にも日付にも当てはまらない数字用に、何を入れてもよい数値欄を1つ空けておいたところ、そこに桁の大きな数が入って返ってきます。

③ 気づいたのは、壊れる場所が片側に偏っていたときでした

最初に疑ったのは、指示文の書き方です。長い指示文を短く書き直しました。抽出の失敗は減りましたが、消えませんでした。

次に疑ったのは、返す形の指定です。何を入れてもよい数値欄を削り、選べる値をあらかじめ列挙しました。桁の大きな数は出なくなりましたが、品目の件数はまだ揺れます。

そこで、失敗した回を検証セットの上で分類してみました。すると、はっきり偏っていました。返信の文面で困った回は0件で、失敗はすべて抽出と品名寄せに集まっていました。

同じモデルに、同じ設定で、正反対のことを頼んでいたわけです。文面には毎回ちがう表現を期待し、抽出には毎回おなじ形を期待していました。

ここで、「モデルが弱いのではなく、1つのモデルに逆の要求をしていた」という見方に変わりました。

④ 原因を1件に絞る

思い当たることは、いくつもあります。指示文が長かったこと、返す形の指定が緩かったこと、出力のばらつき幅を決める温度の設定を、既定の0.7のまま動かしていなかったこと。

ただ、原因を絞ると1件でした。

LLMを賢さの順位で比較して、業務の名前ごとに割り当てていたこと。

役割の分け方が、はじめから業務の名前になっていました。返信を書く、項目を抜き出す、品名を寄せる。3件に分けてはいたのですが、どれも「届いたメールを読んで何かを返す仕事」なので、賢いモデル1つに寄せても筋が通ってしまいます。

実際、いちど3件を2件に減らしています。項目を抜き出す処理と品名を寄せる処理は、どちらもメールから値を取り出す仕事なので、まとめてよいと判断したからです。減らしても、抽出のゆれは直りませんでした。

業務の名前は、モデルに何を期待しているかを言っていません。分け方の軸そのものが、比較の役に立たない軸でした。

⑤ 直したのは、軸1本だけ

やったことは、役割の分け方を「業務の名前」から「出力が毎回おなじでなければ困るか」に変えることだけです。

その軸で見ると、別のモデルに切り出すべき役割は1件でした。品名を社内の品目名に寄せる処理です。ここは、同じ品名を投げたら同じ品目に寄ってくれないと、管理表が壊れます。

切り出した役割にだけ、次の4件を当てました。一世代前の軽い型番を指定すること。温度を0にすること。モデルには答えを出す前に考えを書き出させる手順があるので、その分量をゼロにすること。そして返す形を、選べる値まで含めて固定することです。

賢いモデルは、返信の文面のほうに残しました。

ただ、同じ軸で見ると、抽出も「毎回おなじが要る」側に入ります。抽出には、「今週の金曜」という書き方から実際の日付を割り出す判断が残るので、モデルは賢いほうに置いたままにしました。モデルを替えたのは1件ですが、温度と返す形を締めたのは2件です。

抽出で最初に動かしたのは、温度です。既定の0.7から0.2に下げました。0.7のままだと、指定した形から外れた出力と、投げるたびに変わる出力の、両方が出ていたからです。品名寄せは0まで下げましたが、抽出は0.2で止めています。

次に、抜き出した値の受け皿を足しました。検証セットの失敗を1件ずつ見ていくと、モデルのゆれではない回が混じっていたからです。「この品目だけ最後に届けてほしい」。「来月から別の病棟に回してほしい」。「今回は本館の分だけでいい」。この3つには、受け皿になる項目がありませんでした。 近い項目に無理やり入るか、丸ごと落ちます。項目を3つ足しました。

もうひとつ、「今回は変更ありません」という返事を、失敗として数えていたことも分かりました。抽出が空で返るのが正しい場面なのに、読み取れなかった扱いにしていたからです。空の結果を、正当な「変更なし」として通すように直しました。

書き足したのは、役割の名前を渡すと型番が返るだけの関数です。45行しかなく、それを確かめるテストのほうが49行と長くなりました。新しく作った画面は1つもありません。

⑥ あとで知った ── 「仕事が終わる一番小さいモデルを選ぶ」

しばらくして、LLMで実際に作ってきた1年ぶんの知見を、6名の実務者が共著でまとめた文書を読み、手が止まりました。applied-llms.org という文書で、書いたのは Eugene Yan、Bryan Bischof、Charles Frye、Hamel Husain、Jason Liu、Shreya Shankar の6名です。

そこに、そのままの見出しがありました。「Choose the smallest model that gets the job done」。仕事が終わる一番小さいモデルを選ぶ、という意味です。

書き出しは、こうです。「When working on a new application, it's tempting to use the biggest, most powerful model available」。新しく作るときは一番大きく強いモデルを使いたくなる、と最初に認めています。

そのうえで、こう続きます。「A carefully crafted workflow using a smaller model can often match, or even surpass, the output quality of a single large model, while being faster and cheaper」。小さいモデルで丁寧に組んだ手順は、大きいモデル1つの出力品質に並ぶか、上回ることがある、という主旨です。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わって、何を代償に払ったか

切り出した役割で、数字が2件動きました。10件をまとめて投げたときの時間が、1回あたり26秒から5秒になっています。考えを書き出させる手順をゼロにしたぶんです。そして同じ入力を3回投げると、3回とも完全に同じ出力が返るようになりました。品名寄せ用に用意した30件は、30件とも通っています。

抽出のほうも、言い回しを変えた42件で測り直しました。42件が42件とも通っています。 依頼の中身は同じで言い方だけを散らした検証セットなので、書きぶりが変わっても落ちなくなりました。

最後まで残った抜けは1件です。「今週は無理なんですが、白衣とシーツとバスタオルと枕カバーをまとめてお願いします」というメールでした。日付の話と品目の列挙が同じ文に入ると、品目が4つとも消えます。指示文に、この形の例を1件だけ足しました。そのうえで同じメールを3回続けて投げて、3回とも品目が4つ揃っています。

ただ、代償があります。4件書いておきます。

1件目。文字化けは消えませんでした。 記号への化けは頻度が下がっただけで、ゼロにはなっていません。仕方がないので、返ってきた品目名に記号らしい文字が混じっていないかを見て、混じっていたら投げ直す処理を12行足しました。

2件目。型番が2つになり、片方の検証が漏れるようになりました。 管理画面には切り替えの欄がなく、軽いほうの型番はコードに埋まったままです。新しい型番が出たとき、賢いほうだけ差し替えて、軽いほうを試し忘れます。

3件目。管理画面で選んだ型番が、一度も効いていなかったと分かりました。 初期化の処理が、管理画面の設定を読まずに固定の型番を使っていたからです。画面上は選べていたので、誰も気づきません。モデルを選ぶ処理を1か所にまとめたときに、はじめて見える形になりました。払った代償は、それまで画面でモデルを選び直していた時間です。先に軸を決めていれば、払わずに済みました。

4件目。抽出で受け付けない依頼の種類を、決めて残しました。 「午前だけ回収して、午後は入れないでほしい」のような、途中を空ける依頼です。ここに応えさせると、ほかの項目の精度が落ちるので、受け付けないほうを選びました。代わりに確かめたのは、勝手に時間を書き換えないことだけです。3回投げて、3回とも回収の時間帯は元のまま返りました。担当者が手で埋める欄が、1つ残った形です。

⑧ 現場でLLMを比較するなら、この4つの問い

処理ごとにモデルを比較するとき、使っているのはこの表だけです。

問い	はい	いいえ
同じ入力に、毎回おなじ出力が要るか	温度を下げる＋形を固定する＋受け皿を用意する	賢い側でよい
返す形が決まっているか	選べる値まで列挙して余白を消す	文章のまま返してよい
まとめて処理できるか	10件ずつ束ね、考えを書き出させる手順を切る	1件ずつ投げる
間違えたら人の目に触れるか	人の確認を残す	任せてよい

いちばん効くのは1行目です。同じ入力に毎回おなじ出力が返ることは、賢さでは買えません。 決まるのは温度と、返す形の指定と、考えを書き出させる手順の有無だからです。モデルを小さいほうに替えるかどうかは、そのあとの話です。

逆に、文章を書かせる処理では、この3つを締めるほど文面が硬くなります。同じ設定を全部の処理に配ると、どちらかが必ず割を食います。

この見方は、扱っている品物には依存しません。白衣でも、部品でも、注文書でも同じです。

同じ軸は、コードを書かせる道具を選ぶときにも当てはまります。使い分けている3つを、性能の順位ではなく手の入り方で並べます。ここに挙げるのは、普段使っているものだけです。

その前に、3つが自分をどう説明しているかを見ておきます。公式サイトの一番上に出てくる一文が、そのまま各社の名乗りです。

Claude Code は、使える場所を並べています。ターミナル、IDE、Slack、ウェブ。

Claude Code の公式サイト。ターミナル・IDE・Slack・ウェブから使えると書かれている

Codex は、置き場所を1つに絞っています。ChatGPT の中で使える、という言い方です。

Codex の公式サイト。ChatGPT で使えるコーディングエージェントと書かれている

Antigravity は、道具ではなく基盤だと名乗っています。複数のエージェントを並べて動かす司令台、という説明です。

Google Antigravity の公式サイト。次世代のエージェント基盤と書かれている

（画面は各社の公式サイト。上から Claude Code、Codex、Google Antigravity。2026年8月10日時点のものです）

3つとも、答えているのはどこから使えるかです。指示から外れたときにどう振る舞うかは、どのサイトにも書いてありません。選ぶときに効いたのは、後者のほうでした。

そこで、公表されている説明と、使ってみた印象を、並べて置きます。

	公式サイトの説明	使ってみた印象	向く段
Claude Code	ターミナル・IDE・Slack・ウェブから、コードベース上で直接作業できる	指示どおりに動かないと分かると、別の手を足してでも動く状態を守ろうとする	まだ形が決まっていないもの。企画を形にしていく段
Codex	ChatGPT の中で使えるコーディングエージェント	仕様に書いていないことはしない。余計な補いが出ない	形が決まっているもの。決めた仕様どおりに落とす段
Antigravity	複数のエージェントを並べて動かす、次世代のエージェント基盤	コードと文書を見比べながら進められる。簡単な直しも、仕様を書いた文書の手入れも、その場で自分の手で入る	見た目を起こす段。そして、考え方を決めて仕様の文書に落としていく段