「要約を安いモデルで出して、クライアントに出す文書は上位モデルに」— 使い分けの判断は、ベンチマーク順位では下せない。LLM比較記事の多くは順位表の抜粋と、実物に触れた形跡のない仕様の言い換えで、自分の業務の1文書も通した記録が載っていないからだ。新しめのモデル (Gemini 3.8・GPT-5.6系) は特に薄い。リリースから日が浅く、実タスクの記録がまだほとんど蓄積されていない。
だから測るしかない。本稿は、実際に毎週発生する本業の文書作成タスク (メディア運用の週報) を同じ入力・同じ採点で両モデルに2回ずつ走らせた記録である。品質・コスト・可用性を出して、「私のタスクの場合はどちらか」の形式で判定する。
この記事を読み終えた時、手元に残るもの:
- 文書作成タスクの測定設計 — タスク定義 (要件を機械検査可能にする) と採点3軸
- 品質・コスト・可用性の実測値 (両モデル各2回・トークン実数)
- コスト比較を2層で読む方法 — CLI固定文脈込みの実費と、タスク単独の正規化
- 実行環境の実録 — Gemini 3.8 Flashの高負荷503と、CLI認証エラーの回避経路
- 判定の書き方 — 「私のタスクの場合」の形式 (他タスクへの持ち出しを防ぐ)
測る側を先に固定する — タスクと採点
タスクは本業から取った。個人の技術メディア運用の生データ (記事別views・検索順位・公開ペース) を渡して、週報 (社内メモ) を起草させる。入力1,341字・要件は次の5つ:
- 本文500〜700字
- 3セクション (今週のハイライト / 気になる点 / 来週確認すること)
- 各セクションの箇条書きは3点まで
- 数字は生データにあるものだけ (推測で補完しない)
- 記事は意味のあるものだけ拾う (全列挙しない)
要件をこの形にすると、採点の大部分が機械検査になる。「数字は生データにあるものだけ」は、出力から数値を抽出して生データ側と集合比較すれば、幻覚の有無が機械的に確定する。セクション数・箇条書き数も正規表現で数えられる。人間の採点に残るのは「読みとしてどうか」だけである。
採点3軸はこうなる:
| 軸 | 方法 | 判定 |
|---|---|---|
| 数値忠実度 | 出力内の数値と生データの集合比較 | データにない数値 = 0件であること |
| 構造要件 | セクション・箇条書き数の正規表現カウント | 3セクション・各3点以内 |
| 字数 | 空白と記号を除いた文字数 | 500〜700字 |
この設計自体は、以前書いた実タスク比較手順の流用である (タスク定義シートと採点表の元記事は末尾に置いた)。
土俵が違うことを先に開示する
比較記事が静かに壊れる典型がここだ。同じタスクを渡しても、呼び出し経路で input トークン数が桁で変わる。
-
GPT-5.6 Sol (
gpt-5-6-sol-medium) はエージェントCLI (Devin) 経由で呼んだ。このCLIは毎回、こちらが書いていない固定文脈 (システム文・rules・skills一覧) を先頭に約26.7k token積んでから、タスク本体を送る。手元の入力823 tokenに対し、実測のinputは27,190 tokenだった。 -
Gemini 3.8 Flash (
gemini-3.8-flash) はREST API (generateContent) で直接呼んだ。inputはタスク本体のみで、課金対象もほぼそのまま。
つまり as-run のコストは「モデルの単価差 × 経路の文脈差」が混ざった値になる。だから本稿のコスト表は2層で出す。as-run (実際に請求される額) に加えて、両モデルを「タスク本体823 token + 出力実測」に仮置きした正規化値 (モデル単価の純粋な比較用) である。正規化値は実費ではない — この分離をしないと「CLIで測ったら高かった」を「モデルが高い」と書いてしまう。
単価の出所も明記する。Gemini側はAPI公式pricing のStandard tier (2026-09-10取得時点で input $0.75/1M・output $3.75/1M・いずれも2026年末までの期間価格。thinking tokenはoutputに含む)。Sol側はCLIのmodels list表示 (rate card: input $1.2/M・output $6/M・2026-09-10夜の走行時に確認) で、これはOpenAI API公開単価とは別レートである。公式pricingの該当部分は取得時点で次のとおり:
Input: "$0.75 through December 31, 2026. $1.50 starting January 1, 2027." / Output (incl. thinking tokens): "$3.75 through December 31, 2026. $7.50 starting January 1, 2027."
もう1点、計測精度の開示。Sol側の出力トークン数は、CLIが利用明細を出さないため、出力文本数をo200k系トークナイザで数えた近似値である (近似であることを明記した上で使う)。Gemini側はAPI応答の usageMetadata に candidatesTokenCount (thinking込み) が正確に載るので実数が取れる。input側はSolがCLI内部DB (session記録の num_tokens_preceding) から実数、Geminiは promptTokenCount 実数。
実行: 片方は認証で止まり、片方は503が続いた
実行そのものにも記録すべき実録があった。
まずGemini CLI (gemini コマンド・v0.44.1) は、個人のOAuth認証が切れるとエラー #3501 "You do not have a valid license of this product" で落ちる。API keyを環境変数に入れても、設定ファイルの auth.selectedType が oauth-personal になっていると無視される。再ログインはブラウザ手順なので、本稿ではREST API (generativelanguage.googleapis.com の generateContent) に切り替えて測定した。CLIを正規経路に戻すには再ログインが必要である。
次に、RESTに切り替えても gemini-3.8-flash は HTTP 503 "This model is currently experiencing high demand" が連続した。対照実験として同キーで gemini-2.5-flash を叩くと即座に200が返る。APIでもキーでもなく、3.8-flash固有の需要過多である (リリース直後のモデルの実測として、これ自体が導入計画に効く情報だ。本稿の測定値は、この高負荷の隙間を突いたタイミングの値である点も字数ほどではないが条件に含む)。
Sol側 (Devin CLI v3000.6.14) は素通りした。なお長いpromptを -p で渡すとCLIが内部的に一時fileへ書き出して参照する形になるが、タスクの内容には影響しない (入力トークン実数で確認済み)。
結果: 品質・コスト・可用性
品質 — 4走とも字数は超過、数字の捏造はゼロ
採点は要件どおり機械で通した。空白と記号を除く字数 (採点基準) は flash-1=768字・flash-2=779字・sol-1=796字・sol-2=727字で、4走すべてが500〜700字の上限を超過した。数値の幻覚 (生データにない数値の出現) は4走とも0件。3セクションという構成要件も4走とも守れていた。
箇条書きの「各3点以内」はflash-2 (3/3/3点)・sol-1 (3/3/2点)・sol-2 (3/3/3点) が合格。flash-1だけ機械採点ができなかった — 見出しを ### ではなく **太字行** で書いてきたため、採点scriptの正規表現 (^#{1,3}) がセクションを認識しないのである。人間が読めば同じ3セクション各3点の構造なのだが、採点表の数値からは除外し、「構造要件の機械検査はmarkdown記法のブレに弱い」という測定側の所見として残すことにした。
つまり品質軸では差がつかなかった。両モデルとも数字は正確で、両モデルとも字数を自力で守れなかった。このタスクの結論は「どちらを選ぶか」ではなく「どちらを選んでも字数調整の工程を人が持つ」である。
トークン実数 — 見えない出力が、見えている出力を超える
Gemini側はAPI応答の usageMetadata から実数が取れる。ここに今回の測定でいちばん効く事実が出た。
| 走 | input | candidates (可視出力) | thoughts (思考) | billed output (合計) |
|---|---|---|---|---|
| flash-1 | 778 | 489 | 919 | 1,408 |
| flash-2 | 778 | 495 | 1,706 | 2,201 |
(input 778はGemini tokenizerによる計測。同一テキストのo200k換算は823 — 数え方が違うだけで入力は同じ)
Geminiの課金単価は「output (thinking token込み) $3.75/1M」なので、課金対象の出力はcandidatesとthoughtsの合計になる。usageMetadataでは両者は排他に計上され、total 2,186=778+489+919・2,979=778+495+1,706で整合している。つまりflash-2は見えている出力495 tokenに対して、見えない思考に1,706 token課金されている。思考はbilled outputの65% (flash-1) 〜78% (flash-2) を占め、同じ入力・ほぼ同じ字数 (768字/779字) の2走で課金出力が1.56倍ブレた。
コスト — 層を替えると逆転する
| 走 | as-run (実経路のままで換算) | 正規化 (input 823 + 出力実測) |
|---|---|---|
| flash-1 | $0.0059 | $0.0059 |
| flash-2 | $0.0088 | $0.0089 |
| sol-1 | $0.036 | $0.0043 |
| sol-2 | $0.036 | $0.0040 |
(as-run: Gemini=REST直接・input 778実数。Sol=CLI・input 27,190実数。正規化は両モデルともinput 823 (o200k) に統一しトークナイザ差を消した仮置き。単価は前節の2026-09-10時点。Sol側はCLI表示rate cardによる換算の代理指標で実際の請求額ではない — 今回の走行はサブスク枠内で追加課金ゼロ)
as-runではGemini直接APIがSol CLIの約1/4〜1/6だが、この差の大部分はモデルではなく経路 (CLI固定文脈26.7k) である。正規化すると逆転してSolが安い ($0.0040〜0.0043 vs $0.0059〜0.0089)。理由は2つある。Solの可視出力が小さい (508〜556 token。CLIが思考の内訳を出さないため、可視出力のみの近似) ことと、Geminiは思考込みでbilled outputが1,408〜2,201に膨らむこと。output単価そのものはGemini $3.75 < Sol $6 なのに、である。
可用性 — 片方は再試行で掴んだ
Sol (CLI) は2走とも初回で応答した。Gemini 3.8 Flashは実行セクションのとおり503が続き、flash-2は503を2回挟んで3回目で成功した (再試行待ち込みの実務所要は約2分半)。flash-1は計測コマンド側のタイムアウトで正確な所要を取り損ねた (成功は応答ファイルの出力時刻で確認。10分以内)。1呼あたりの応答秒を分離計測できていないので「どちらが速いか」には使わないが、「週報起草を定時バッチに組み込めるか」という実務の問いには、この再試行込みの挙動がそのまま答えになる。
判定 — 私のタスクの場合
品質: 差がなかった。数字の正確さは両モデルとも崩れず (幻覚0件)、字数は両モデルとも守れなかった。このタスクで品質を選定基準に使うことはできない。参考までに、同じ系統のハーネスで前回の対決記事 (GPT-6 Astra vs Gemini 3.8 Flash) を走らせたときはAstraだけが全走で字数を守っており、「与えた制約を自力で守れるか」はモデル差として出やすい軸だということも分かっている。
コスト: 毎週回す類いのタスクなら、Gemini直接APIのas-run ($0.006〜0.009/走) は無視できる水準で、字数超過の再生成を1回挟んでも1走あたり$0.012〜0.018で済む。ただしthinking tokenの占める割合は走ごとに大きく変わるので、コストを見積もるときに可視出力から逆算しないこと — usageMetadata の実数で見る。CLI経路のSolをこのタスクのために従量で呼ぶ理由はない (as-run $0.036/走)。サブスク枠に余裕があるなら追加課金ゼロなので、CLIを使うかどうかは枠の状況で決める話になる。
可用性: 測定期間中、3.8-flashは高負荷で503が連続し、同キーの2.5-flashは即座に応答した。定時バッチに組み込むなら再試行と代替経路の設計が前提になる。運用開始直後の新モデルを扱うとき、「繋がるか」は品質・コストと同じ重さの実測項目だ。
私のタスクの場合の結論: 週報起草はGemini 3.8 Flashの直接APIで回し、出力後の字数チェックと再生成を工程に組み込む。「重要文書は上位モデルのCLIで」という使い分けは、今回のデータには根拠がなかった — 品質差が測れなかったからだ。生成AIのモデル選定で一番効くのは、自分のタスクを機械採点可能な要件に落として2回ずつ走らせるこの手順のほうである。
自分のタスクで同じ試験を回すなら
- タスクを機械検査可能な要件に落とす (字数範囲・セクション数・数値の出所制限のように、正規表現か集合比較で採点できる形にする)
- 同じ入力で各モデル2回ずつ走らせる (1回だけだと走間ブレが見えない — 今回は同一入力で課金出力が1.56倍ブレた)
- 実数を記録する (GeminiはAPI応答の
usageMetadata・CLI経路はsession記録のtoken数。可視出力からの逆算はthinking分を隠す) - 判定は「私のタスクの場合」の形式で書き、他タスクへの持ち出しを自分に禁止する
タスク定義シートと採点表の雛形は手順の元記事 (参考の2本目) にある。本稿と同梱の eval.py は要件5つの採点をそのまま実装しているので、要件を書き替えれば別タスクに流用できる。
限界 (実測できていないこと)
測定設計の限界:
- 各モデル2回のn=2である。品質差の有意検定はできない。「2回で崩れなかった」以上のことを言わない
- タスクは週報起草1種のみ。この判定を他の文書種 (提案書・議事録等) に持ち出さない (過去の実測でも、タスクを替えると逆転が出ている)
- 採点は機械3軸と著者の読みによる。第三者による盲検ではない
数値の限界:
- Sol側の出力トークンはo200k系トークナイザによる近似。コストの誤差はこの分だけ乗る
- Gemini 3.8 Flashの単価は2026年末までの期間価格で、2027年からinput $1.50/1M・output $7.50/1Mに変わる (公式pricing記載)
- 高負荷状態のモデルから取得した応答であり、通常負荷時の所要・品質と変わる可能性がある (所要は負荷の影響を受けやすい)
- 1呼あたりの応答秒は分離計測できていない (flash-2は再試行込みの実務所要のみ・flash-1は成功時刻のみ記録)。モデルの速さの比較としては使わない
参考
- Gemini API pricing (gemini-3.8-flash 単価・期間価格): https://ai.google.dev/gemini-api/docs/pricing
- 実タスク比較の手順と記録テンプレート (元記事): https://qiita.com/jinno_ai/items/0d46c7cb0f36343943cf
- GPT-6 Astra vs Gemini 3.8 Flash (前回の対決・対照のSol 2走は同一データ): https://qiita.com/jinno_ai/items/de7295363b8ad5a150e9
- GPT-6 Astraのprompt cache実測 (CLI固定文脈の構造): https://qiita.com/jinno_ai/items/d9eea3a72922ff77f699
本稿の生データ (タスク入力・両モデルの出力全文・トークン実数・採点script) は assets/qiita/doc-task-gemini38-vs-sol-record/ に置いた。採点は同梱の eval.py で再現できる。
なお、この比較記録の運用はJapan LaunchOpsで行っている。モデル選定の記録方法・業務への当てはめの相談は日本語AI評価のページで受け付けている。