Gemini 3.5 Flash は本当にダメなのか?英単語の覚え方ヒント生成ベンチしてみた
今朝(2026-05-20)リリースされた Gemini 3.5 Flash が、コーディング界隈を中心にさんざんな評判だった。Xを眺める限り「3.0系より明確に悪化した」「ハルシネーションが増えた」「指示追従が弱い」といった声が目立つ。
ただ、自分が手を動かしているプロダクト「えいたんごクイズ」では Gemini を コーディング用途ではなく、英単語の覚え方ヒント文の生成 に使っている。コーディングのベンチで悪い結果が出たからといって、自然言語生成の質まで悪化しているとは限らない。むしろ Flash 系は安価でレイテンシも短いから、品質が許容範囲なら継続採用する価値はある。
ということで、自分のプロダクトで実用するタスクで実際に評価してみた。同時にせっかくなので、最近 OpenRouter に出揃った主要 LLM を一斉に並べて、品質・コスト・レイテンシを比較する盲検ベンチに仕立てた。
結果から言うと、Gemini 3.5 Flash は失格モデル群を除いた8モデル中で最下位(タイ) だった。コーディングで悪評の Gemini 3.5 Flash は、コーディング以外でも厳しかった。
なお、ここで「最下位」と言っているのは 13モデル全体ではなく、完走できた8モデル中での最下位 という意味である。今回のベンチでは reasoning が長すぎて本文出力に至らなかった5モデル(Qwen3.6-27b、GLM-4.7、Kimi K2.6、DeepSeek V4 Pro、Claude Haiku 4.5)を品質ランキングから除外している。これら失格組のスコアは構造的に最下位帯に沈むため、絶対値で言えば Gemini より下のモデルはいくつも存在する。ただし「同じ max_tokens 設定で実運用に乗せられる」という条件で並べたとき、Gemini 3.5 Flash は最下位タイになる、という整理である。
ただし、これは「3.5 Flash がゴミ」という単純な話ではない。トップとの差は1.86点(満点25中)に過ぎず、3位以下はほぼ団子状態だった。詳細を以下にまとめる。
ベンチ設計
タスク
英単語に対する「覚え方ヒント文」を 1〜3 文(100〜250字)で日本語生成させる。例:
roll back: rollは「転がす」、backは「後ろへ・元へ」。いったん前に進めた政策や命令を、ころころと元の位置まで戻して取り消すイメージで、政府や会社が発表を「撤回する」ときに使う。
この種の文章は単なる訳語の言い換えではなく、語形・語源・比喩・場面といった想起トリガーを盛り込む必要がある。コーディングと違って正解が一意に決まらない、創造的だが構造のある自然言語タスクで、LLM の地力が出やすい。
評価対象モデル(13機種)
| カテゴリ | モデル | $/M tokens (prompt/completion) |
|---|---|---|
| OpenAI フラッグシップ | openai/gpt-5.5 |
5 / 30 |
| OpenAI 主力 | openai/gpt-5.4 |
2.5 / 15 |
| OpenAI 中位 | openai/gpt-5.4-mini |
0.75 / 4.5 |
| OpenAI 最安 | openai/gpt-5.4-nano |
0.2 / 1.25 |
google/gemini-3.5-flash |
1.5 / 9 | |
| Google OSS | google/gemma-4-31b-it |
0.12 / 0.37 |
| Anthropic | anthropic/claude-haiku-4.5 |
1 / 5 |
| DeepSeek 上位 | deepseek/deepseek-v4-pro |
0.44 / 0.87 |
| DeepSeek 最安 | deepseek/deepseek-v4-flash |
0.11 / 0.22 |
| Moonshot | moonshotai/kimi-k2.6 |
0.73 / 3.49 |
| Z.ai | z-ai/glm-4.7 |
0.4 / 1.75 |
| Qwen フラッグシップ | qwen/qwen3.6-max-preview |
1.04 / 6.24 |
| Qwen 中位 | qwen/qwen3.6-27b |
0.32 / 3.2 |
全モデルを OpenRouter 経由で同一プロンプト・同一パラメータ(temperature=0.7、max_tokens=1200、reasoning effort=medium)で叩いた。生成側にコーディング寄りのバイアスが混入しないよう、ローカル CLI(Codex CLI、Claude Code sub-agent など)は使わず、生 API 直叩きにしている。
評価軸(5軸)
mnemonic生成タスクに合わせて、以下の5軸を 1〜5 の整数で採点する。
| # | 軸 | 評価ポイント |
|---|---|---|
| 1 | 想起しやすさ | 後で単語を見たときに「覚え方」を思い出せるフックがあるか |
| 2 | 語形/語源との結び付き | 訳の言い換えでなく、語形・語源・派生語・成り立ちに触れているか |
| 3 | 具体性 | 「印象的」「覚えやすい」などの汎用表現で逃げず、具体的な像・場面・対比を提示しているか |
| 4 | 学習者レベル適合 | 説明に使われる日本語語彙・概念が学習者レベルに合っているか |
| 5 | 簡潔性 | 冗長な前置きや無駄な強調を避け、100〜250字程度に必要十分に収まっているか |
ジャッジ(2名、盲検)
LLM の出力を別の LLM に採点させる以上、ジャッジが自社系列を贔屓する可能性を最初から疑ってかかる必要がある。これを抑えるために設計上いくつかの工夫を入れた。
ジャッジ構成:
- J1: Codex GPT-5.5 — Codex CLI 経由で 10 並列
- J2: Claude Opus 4.7 — Claude Code sub-agent 10 並列
OpenAI 系(J1)と Anthropic 系(J2)の異なる系列のモデルを並べたのは、片方が自社贔屓したらもう一方の判定との差分で検出できるようにするため。
盲検のために講じた工夫:
-
モデル名の匿名化
各モデルを A〜M(13文字)にマッピング。ジャッジにはAB... としてしか見せず、どの候補がどの会社のどのモデルかを推定する手がかりを与えない。マッピングは乱数シードで固定し、生成・採点・集計の全工程で同じ対応を維持。 -
提示順のランダム化(per word)
13候補の提示順は 単語ごとに毎回シャッフル。Aが常に先頭、Mが常に末尾という配置だと、ジャッジが「最初の候補は基準点として高めに振る」「末尾は疲れて低くなる」といった位置バイアスに染まる可能性がある。それを潰すため、ある単語ではH F D B E A C G、別の単語ではA G H C E B D Fのように、毎回 letter のシャッフル順を変えた。 -
参照(gold)一切なし、完全blind
ジャッジには英単語・品詞・主要訳・学習者レベルだけを渡す。既存運用中の mnemonic や「お手本回答」は意図的に見せない。ジャッジが「既存のお手本に近いものに高得点」を付けるリスクを排除した。 -
採点軸を構造化(フリーコメント不可)
1〜5 の整数 × 5 軸を JSON 形式で返させ、定性コメントは「30字以内」に制約。長文の自由記述だと、ジャッジが特定候補を擁護する文章を書きながら自分のスコアを正当化する余地がある。これを潰した。 -
生成と採点でツールを使い分け
生成側は OpenRouter の生 API 直叩き のみ(Codex CLI や Claude Code sub-agent は使わない)。CLI 経由だとどうしてもコーディング寄りのシステムプロンプトが混入して、特定モデルが有利になる可能性がある。一方、採点側は同じ CLI 経由でも、全候補に同じバイアスがかかるので相対比較には影響しない。
入力データ
DB から 20語を層化抽選し、最後に 30語を追加して計50語で本評価とした。
層化条件:
- 4 レベル帯(basic / intermediate / upper / advanced、L5〜L32)× 各5語
- 各帯に句動詞・多義語・通常を必ず含める
-
quiz_only_excluded = 0 AND excluded_reason IS NULLで「変な語」を排除
選ばれた語の例: outer, dreadful, the last straw, creed, progressiveness, iconoclast, primogeniture, discrimination, swoop ...
結果
出力失敗率(最初の警鐘)
まず生成段階で気になったのが、reasoning が max_tokens=1200 を全消費して本文不到達 になるケース。finish_reason=length で本文が空になる。
| モデル | empty | finish=length |
|---|---|---|
qwen/qwen3.6-27b |
18/20 | 18/20 |
z-ai/glm-4.7 |
12/20 | 13/20 |
moonshotai/kimi-k2.6 |
11/20 | 13/20 |
deepseek/deepseek-v4-pro |
6/20 | 6/20 |
anthropic/claude-haiku-4.5 |
0/20 | 3/20 |
「reasoning付きモデル」の中でも、思考トークンの長さが推論モデル次第で大きく変わる。Qwen3.6-27b に至っては 9割で本文に到達できない。本ベンチの設計上、max_tokens=1200 で完走できないモデルは そもそも実運用に乗らないので、以降の品質ランキングからは除外する。
注: これらのモデルの実力が低いという意味ではなく、「同じ max_tokens 設定でフェアに比較する」ベンチの設計上、reasoning が長すぎるモデルが構造的に不利になっている。max_tokens を 2000 以上にすれば完走するモデルもあるはず。
これで残ったのが Anthropic を含めても 9モデルだが、Claude Haiku 4.5 にも finish=length が 3件あったので、厳格に「failure ゼロ」のモデル 8機種で本評価を進める。
重要な点として、「除外=最下位より下」を意味するわけではない。失格モデル群はそもそも本文を生成できなかったケースが多く、空応答に対して採点をかければ全軸 1点になる構造的な底打ちが発生する。よって、「Gemini 3.5 Flash が8位(最下位タイ)」というのは 完走できた8モデル中での話であり、本来全13モデルで並べれば失格組がさらに下に来るはず、という前提で読んでいただきたい。
50語・Opus単独ランキング(厳格版)
ジャッジ自社贔屓の発見と、Opus を採用する判断について先に述べる。
2ジャッジの合計スコア(Codex + Opus)でランキングを組む方が一般にロバストだが、本ベンチでは Codex GPT-5.5 が OpenAI 系モデル群を顕著に高く評価する 自社贔屓が観測された。「Codex - Opus」のスコア差を取ると:
- OpenAI 系の差分: 平均 +1.25(OpenAI モデルを Opus より1.25点高く採点)
- 非 OpenAI 系の差分: 平均 +0.70
Codex が全体に Opus より甘いベースライン (+0.70) を差し引いても、OpenAI 系には +0.55 の上振れがある(詳細は後述「自社贔屓の検証」セクション)。
一方、Opus 4.7 は Anthropic 系(Claude Haiku 4.5、20語版で検証済み)に対して同様の贔屓を示さなかった。これは Anthropic モデルが評価軸で必ずしも有利でなかったことも一因と思われるが、ともあれ Opus の方が中立的なジャッジとして機能していることが確認できた。
そこで本記事のメインランキングには Opus 4.7 単独スコアを採用する。Codex + Opus 平均は後ほど参考として併記する。
Opus 4.7 単独ランキング
総合スコアとコスト・レイテンシ:
| rank | model | total | cost/件 | latency |
|---|---|---|---|---|
| 1 | openai/gpt-5.5 |
21.86 | $0.00830 | 6.7s |
| 2 | openai/gpt-5.4 |
21.58 | $0.00706 | 8.7s |
| 3 | openai/gpt-5.4-mini |
20.68 | $0.00130 | 4.5s |
| 4 | openai/gpt-5.4-nano |
20.62 | $0.00036 | 4.5s |
| 5 | qwen/qwen3.6-max-preview |
20.50 | $0.01457 | 65.6s |
| 6 | deepseek/deepseek-v4-flash |
20.44 | $0.00017 | 13.3s |
| 7 | google/gemma-4-31b-it |
20.02 | $0.00036 | 54.9s |
| 8 | google/gemini-3.5-flash |
20.00 | $0.00635 | 4.5s |
軸別スコア(各1〜5、太字は軸内トップ):
| model | 想起 | 語源 | 具体 | レベル | 簡潔 |
|---|---|---|---|---|---|
openai/gpt-5.5 |
4.38 | 4.10 | 4.02 | 4.62 | 4.74 |
openai/gpt-5.4 |
4.44 | 4.08 | 4.30 | 4.42 | 4.34 |
openai/gpt-5.4-mini |
3.84 | 3.60 | 3.66 | 4.60 | 4.98 |
openai/gpt-5.4-nano |
4.02 | 3.90 | 3.60 | 4.44 | 4.66 |
qwen/qwen3.6-max-preview |
4.30 | 4.26 | 4.24 | 3.98 | 3.72 |
deepseek/deepseek-v4-flash |
3.90 | 3.90 | 3.64 | 4.38 | 4.62 |
google/gemma-4-31b-it |
4.16 | 4.02 | 4.06 | 4.14 | 3.64 |
google/gemini-3.5-flash |
4.26 | 4.06 | 4.36 | 4.12 | 3.20 |
観察事項
(1) GPT-5.5 が1位、ただし GPT-5.4 と僅差
Total 21.86 vs 21.58。差は0.28点。GPT-5.5 の単価は GPT-5.4 の約2倍なので、「実用上は GPT-5.4 で十分」と言える程度の差。
(2) GPT-5.5 / GPT-5.4 と他の差は明確
トップ2が21点台、3位以下は20.00〜20.68の団子。OpenAI 系の上位2モデルは本タスクで頭一つ抜けている。
(3) Gemini 3.5 Flash は8位(最下位タイ)
20.00で Gemma 4 31b-it(20.02)と事実上同点で最下位。ただし内訳を見ると:
- 具体性 4.36(全モデル中1位)— 場面描写は得意
- 想起しやすさ 4.26 — 比喩・連想は強い
- 簡潔性 3.20(最下位)— 冗長で「100〜250字」の制約を守れない
つまり「内容は悪くないが、長く書きすぎる」傾向。Qiita の試走で確認した限り、Gemini Flash は丁寧に説明しようとしすぎて文字数が膨らみ、結果として簡潔性で大きく失点していた。
(4) コーディング不評の文脈と一致するか?
完全には一致しない。コーディング界隈の不評は「指示追従の弱さ」「ハルシネーション」が中心だったが、本タスクでは指示追従の精度(軸 4=レベル適合)は4.12で平均以上だった。一方で「簡潔に」という分量制約への追従は弱かった。
「指示追従が弱い」は当たっていそうだが、「mnemonic 生成自体が下手」というよりは、**「制約条件付きの文章生成における枠の守り方が下手」**という方が実感に近い。
(5) Qwen3.6 Max preview の隠れた強み
5位(20.50)だが、軸別では:
- 想起 4.30(2位)
- 語源 4.26(1位)
- 具体 4.24(3位)
説明の中身は非常に強い。ただし簡潔性 3.72 と、何より レイテンシ 65.6秒・コスト $0.0146/件 が実用上厳しい。
コスパランキング
| rank | model | total | cost/件 | score / $ |
|---|---|---|---|---|
| 1 | deepseek/deepseek-v4-flash |
20.44 | $0.00017 | 118,894 |
| 2 | openai/gpt-5.4-nano |
20.62 | $0.00036 | 56,544 |
| 3 | google/gemma-4-31b-it |
20.02 | $0.00036 | 55,864 |
| 4 | openai/gpt-5.4-mini |
20.68 | $0.00130 | 15,915 |
| 5 | google/gemini-3.5-flash |
20.00 | $0.00635 | 3,152 |
| 6 | openai/gpt-5.4 |
21.58 | $0.00706 | 3,056 |
| 7 | openai/gpt-5.5 |
21.86 | $0.00830 | 2,632 |
| 8 | qwen/qwen3.6-max-preview |
20.50 | $0.01457 | 1,407 |
DeepSeek V4 Flash が桁違いのコスパ。品質は GPT-5.4 nano / Gemma 4 31b と同水準(20点台前半)で、コストは1/2〜1/40。大量生成のバッチ用途には現状これがベスト。
OpenAI の gpt-5.4-nano は品質も20.62と健闘し、レイテンシも 4.5s と速い。実運用バランスでは強い。
逆に Gemini 3.5 Flash は品質最下位なのにコストは中位。コスパランキングでも5位と、立ち位置が中途半端。
自社贔屓の検証
ジャッジ2名(Codex GPT-5.5 と Opus 4.7)の系列違いが結果に影響していないか。各モデルについて「Codex - Opus」スコア差を出した:
| model | codex_avg | opus_avg | c-o | family |
|---|---|---|---|---|
openai/gpt-5.4 |
23.30 | 21.58 | +1.72 | openai |
openai/gpt-5.5 |
23.36 | 21.86 | +1.50 | openai |
openai/gpt-5.4-mini |
22.00 | 20.68 | +1.32 | openai |
google/gemini-3.5-flash |
20.88 | 20.00 | +0.88 | other |
deepseek/deepseek-v4-flash |
21.24 | 20.44 | +0.80 | other |
google/gemma-4-31b-it |
20.78 | 20.02 | +0.76 | other |
openai/gpt-5.4-nano |
21.08 | 20.62 | +0.46 | openai |
qwen/qwen3.6-max-preview |
20.86 | 20.50 | +0.36 | other |
ファミリー平均 (Codex − Opus):
- OpenAI: +1.25
- Other: +0.70 ← ベースライン
Codex GPT-5.5 は全モデルに対して「Opus より甘め」だが、OpenAI 系には ベースラインより 0.55 上振れして甘い。これは Codex GPT-5.5(つまり OpenAI モデル)が自社製品を贔屓している証拠と見られる。
逆に Opus 4.7 は Claude Haiku 4.5 を含む50語データではフラットだったため(Haiku は失格除外したが、20語版では既に検証済み)、Opus 単独スコアの方が公平と判断し、本記事のメインランキングはそちらに依拠している。
Judge一致度
400組(50語 × 8モデル)の (word, model) ペアで Codex と Opus を比較すると、|合計差|≥4 のサンプルは33組(8.2%)。同一ペアに対する2ジャッジの評価は概ね揃っており、ベンチの信頼性は高い。
結論と実用的な示唆
えいたんごクイズ的な採用判断
| 用途 | 推奨モデル | 理由 |
|---|---|---|
| 品質最優先のバッチ生成(一度きり) |
openai/gpt-5.5 または openai/gpt-5.4
|
品質21点台、Opus採点で頭一つ抜けている |
| コスト最優先の大量生成 | deepseek/deepseek-v4-flash |
品質20.44を $0.00017/件で実現、桁違いコスパ |
| 速度最優先(ユーザー応答系) |
openai/gpt-5.4-mini または gpt-5.4-nano
|
4〜5秒で20点台 |
| OSS縛り(自社ホスティング検討) | google/gemma-4-31b-it |
OSSで20.02、上位クローズドと張り合える |
※ 実際には原則GPT-5.5を使っています。簡単なスクリーニングではGPT-5.4-miniを使うこともありますが、文章は基本的にGPT-5.5で生成しています。
Gemini 3.5 Flash の採用可否
本タスクに限れば、現時点での採用見送りが妥当。
- 品質は最下位タイ(20.00)
- コスパも中位(5位)
- レイテンシ 4.5秒は速いが、それなら同帯のGPT-5.4-mini(4.5s、20.68)の方が優れる
「Gemini 系の安価・高速」という Flash 系の利点は、3.5世代では他社モデルに取って代わられたと言える状況。コーディング界隈の悪評は、コーディング以外のタスクでも一定程度妥当だった。
ただし軸別では 具体性で全モデル中1位、想起しやすさでも上位群。「文字数制約を緩めれば化ける」可能性は残るので、自由記述型のタスク(例: 解説記事生成、ストーリー生成)では再評価の余地があるかもしれない。
全体的な所感
- GPT-5.x ファミリーは品質トップ集団を維持。GPT-5.5 と GPT-5.4 の差は実用上ほぼ無視できるレベル
- OSS と DeepSeek が驚異的にコスパ良い。Gemma 4 31b-it が GPT-5.4 系と肉薄したのは収穫
- Qwen3.6 Max preview は説明品質では1位、ただし速度・コスト・簡潔性で実用厳しい
-
reasoning モデルは max_tokens 設定にシビア。
mediumreasoning で 1200 トークン制約だと、Qwen3.6-27b / GLM-4.7 / Kimi K2.6 / DeepSeek V4 Pro が本文に到達できない
総コスト
- 合計 OpenRouter 課金: 約 $2.30
- 採点側(Codex / Opus)は別の月額枠で消化、追加課金なし
OpenRouter で複数モデルを比較したい人にとって、現実的な選択肢だと思う。
おわりに
今回のベンチはClaude Opus 4.7 にベンチマークの仕組みを作ってもらった。観点の指定やバイアスを排除する工夫は指示してやる必要があるが、あとは勝手にやってくれる。LLMのベンチ、思ったより簡単なのでやってみよー!!