AIモデルは本当に「高い方が良い」のか？——Claude・GPT-5.6・Geminiを実タスクで比べた結果

新しいAIモデルが発表されるたび、私たちはつい「最上位の、いちばん高いモデルを選んでおけば間違いない」と考えてしまう。クライアントのAI活用支援と自社の業務自動化基盤を運用している私自身、その誘惑はよくわかる。高いモデルは安心を買う——そう思っていた。

ところが、実際に手を動かして測ってみると、その前提は崩れた。しかも興味深いことに、「記事の本文を書かせる」仕事と「記事に添える画像を作る」仕事とで、手を入れるべき場所が逆になった。正確に言うと、比べたのは長文の記事生成と、画像を描くための短い指示文（プロンプト）の生成である。前者は使うモデルの格が結果を決め、後者はモデルよりも指示文の書き方が結果を決めた。同じ「モデル比べ」でも、効くレバーが反対側にあったわけだ。

今回は、2026年7月時点で私たちが社内で回したAIモデル選定の実測を、そのまま共有する。品質の比較には「ブラインドA/B」という方法を使った。同じお題を複数のモデルに書かせ、どれがどのモデルの原稿かを伏せたまま、AI自身に複数の観点で相互採点させて点数化する——人間の贔屓や先入観を抜きにして、出力そのものだけで優劣を測るやり方だ。あわせて、記事1本あたりのLLM利用コストも実測した。比較対象は Anthropic の Claude（Sonnet 5 / Opus 4.8）、OpenAI の GPT-5.6 系（Sol / Terra / Luna）、Google の Gemini（3.1 Pro / 3.5 Flash）である。

全部を高いモデルに任せない——用途ごとにモデルを使い分けている

新しいモデルの登場ペースは、明らかに速くなっている。数か月ごとに各社が新型を出し、そのたびに「乗り換えるべきか」を判断しなければならない。AIを組み込んだシステムを運用する側にとって、この「短いサイクルで新モデルを検証し、必要なら切り替える」作業は、もはや避けて通れない定常業務になった。

だからこそ私たちは、ひとつの高級モデルに全部を任せる作りにしていない。MIMIR（私たちのAI基盤）では、記事の下書き、議事録の整理、画像の生成といった処理ごとに、使うモデルを変えている。これを実現しているのが、自動化ツール n8n で組んだ各ワークフローの中に置いた「gateway（ゲートウェイ）」と呼ぶ中継ノードだ。後段の処理がどのモデルを使うかは、このノードの設定を変えるだけで柔軟に切り替えられる。新しいモデルを試したいときも、処理を一つひとつ書き換える必要はなく、この一点を差し替えれば済む。

この作りには実利がある。新モデルの評価（実測）も切り替えも、機能を一つひとつ書き換えて回らずに済むので、検証そのもののコストが下がる。乗り換え判断が定常業務になった今、この「切り替えの安さ」は、そのまま運用コストの差になる。

そのうえで大事にしているのが、コスト効率の考え方だ。私は「高いモデルが常に良い」とは思っていない。事業計画を練る、複雑な設計をするといった重い仕事なら上位モデルの格が効くが、単純な仕事なら下位モデルでも十分な出力が得られる——これを日々の運用の前提にしている。厄介なのは、その「格が効く／効かない」の境目が、値段表や、各社が発表するベンチマークの数値を眺めているだけでは見えないことだ。実際に同じ仕事を複数のモデルにやらせて、出力を並べて採点しないと分からない。今回の実測は、まさにその境目を確かめる作業だった。

記事執筆では、最上位モデルと単価4割弱のモデルが区別できなかった

最初に測ったのは、ブログ記事の本文執筆だ。ここで先に断っておくと、記事執筆は「重い仕事」ではない。私は、軽い調べものから1時間以上かかる処理まで、日々さまざまな仕事にAIを使っているが、その実感でいうと、記事の下書きはむしろ比較的単純なタスクに入る。本当に重いのは、事業計画を練る、システム全体の設計図や設計書を書く、複雑なコーディングそのものを進める——そういう仕事だ。記事執筆はその手前にある、ある程度型の決まった作業だと考えている。

測り方はこうだ。同じ一つのお題（今回は「AIに引用・比較される文章の書き方」をテーマにした）を、7通りのモデル設定に書かせた。内訳は、Claude Sonnet 5 と、GPT-5.6 の Sol／Terra／Luna をそれぞれ「よく考えさせる（high）／あまり考えさせない（low）」に振り分けた組み合わせである。そのうえで、どれがどのモデルの原稿かを伏せたまま、AI自身に7つの観点で相互採点させた。観点は、①事実の裏付け、②出典の正確さ、③構成、④文体・トーンの一貫性、⑤読みやすさ、⑥行動喚起（CTA）、⑦SEO（検索での見つけやすさ）の7つだ。以下に出てくるスコアと単価は、いずれも私たちが2026年7月時点で社内実測した値で、外部の第三者検証を経たものではない点は先に断っておく。

結果、7通りの総合スコアは 87.3〜91.7 の4.4点幅にぎゅっと密集した。最上位の Claude Sonnet 5 が 91.7、いっぽう GPT-5.6 系でいちばん安い Luna（high 設定）が 90.6。両者の差は採点のばらつきに埋もれる程度で、正直どちらが書いたか見分けがつかなかった。そこにコストを重ねると、判断はもっとはっきりする。記事1本ぶん（入力5,000・出力2,500トークンを想定）を2026年7月時点の各社の公開料金で試算し、品質と並べたのが次の表だ。

モデル（設定）	稿あたり概算	Sonnet 5 比	ブラインド品質（単発・7観点）
Claude Sonnet 5	約8.5円	1.00倍	91.7
GPT-5.6 Luna（high）	約3.2円	0.38倍	90.6
GPT-5.6 Luna（low）	約3.2円	0.38倍	87.3

記事の生成では、費用の大半を「出力トークン（AIが書き出す文章の量）」が占める。Luna は出力の単価が Sonnet 5 のおよそ4割なので、その差がそのまま1本あたりのコストに効いて、約0.38倍（4割弱）に収まった。品質は見分けがつかず、コストは4割弱。この事実を前に、「高い方が安心」という感覚は根拠を失った。

ここまでは、各モデルに1回ずつ書かせた「単発1パス」の比較だ。ただ、MIMIRの本番の記事執筆は、1つのモデルに丸投げしているわけではない。まず記事の構成・骨子を考えるエージェント、次にその骨子をもとに本文を書くエージェントを2名（A・B）、続いてその2本を評価しながら一本にまとめる編集長エージェント、最後に仕上がりを推敲するエージェント——この多段の連携で1本を仕上げている。そこで、この本番と同じ構成と、安いモデルの単発とを突き合わせて確かめた。

この検証については、APIで課金しながら動く本番環境ではなく、手元のPC（Claude Code／Codex のサブスク環境）で同じワークフローを再現して測った。本番のデータもコストも汚さずに、実際の入力で品質だけを比べられる。2つの別テーマで測った平均が、次の表である。

条件	構成	平均スコア（2テーマ）
本番と同じ多段構成（Sonnet 5）	4エージェントの連携	78.0
GPT-5.6 Luna（high）	単発1パス	81.5
Claude Opus 4.8	単発1パス	85.7

驚いたのは、安いモデルの単発（Luna 81.5）が、現行の作り込んだ多段構成（78.0）を上回ったことだ。もっとも、これは母数2テーマの速報値で、多段構成側がたまたま1本で文体の崩れを引いた影響もあり、そのまま鵜呑みにはできない。それでも、「凝った構成にすれば必ず上」とは限らないことははっきりした。なお、コストパフォーマンスの都合で本番採用していない Claude の最上位 Opus 4.8 も、検証のために単発で回すと85.7で最も高く、格が効く場面では上位モデルがやはり伸びる、という裏返しも同時に見えている。

ただ、僅差で見分けがつかないなら、私は安い方を採る。そのとき守っているのは、「各社のベンチマーク数値を鵜呑みにしない」というポリシーだ。公開ページには性能の数値が並ぶが、その数字だけで盲目的に採用することは避け、自分たちの実タスクで実際に測り、納得できたものだけを採る——そう決めている。

ところが画像生成では、モデルを上げても直らなかった——効いたのはプロンプトだった

次に、まったく逆の結論が出たのが画像まわりだ。ここで扱うのは「画像そのものを描く工程」ではなく、その一歩手前、「画像を描くための短い指示文（プロンプト）を作る工程」である。しかも MIMIR では、この2つを別々のモデルに担当させている（これは一般的な作りではなく、私たちの構成の話だ）。混同しやすいので、先に切り分けておく。

全体像はこうだ。画像そのものの描画には OpenAI の GPT-Image2 を使っている。GPT-Image2 は、渡されたシーン説明文（どんな場面を描くかを言葉にしたもの）を、ほぼそのまま絵にする。その手前で、日本語の見出しと段落（セクションの文脈）を読み取り、このシーン説明文を書き起こすのが Gemini 3.5 Flash の役割だ。つまり「Flash が場面を描写する → GPT-Image2 がその描写を絵にする」という二段構えになっている。

ここで、前もって共有しておくべき事実がある。描画に渡すプロンプトには、もともと全体設定として「読める文字・数字は一切描かない」という禁止指示が入っている。にもかかわらず、画像に「85%」という数字が焼き込まれてしまう不具合が起きていた。禁止しているのに、なぜ数字が出るのか——ここが今回いちばん誤解されやすいところなので、事実を正確に押さえたい。

原因は、モデルでも、禁止指示の不足でもなかった。前段の Flash が書いたシーン説明文の中に、「85%という数字に下線を引いている手」という、文字を描くよう明示的に指示する一節が紛れ込んでいたのだ。実際に描画へ渡されたプロンプトは、次のような二層構造だった。

（全体設定）This image is a STRICTLY FLAT 2D vector editorial illustration … Absolutely no readable text, letters or numbers.（＝読める文字・数字は一切描かない）

（前段が書いたシーン）Scene: … a hand … is underlining a bold number “85%” written in clean script …（＝手が「85%」という数字に下線を引いている場面）

同じプロンプトの中で、「文字を描くな」という全体の禁止と、「85%という数字を描け」という具体的な指示がぶつかっている。こうなると描画モデルは、抽象的な禁止よりも、目の前の具体的な指示のほうに引きずられる。結果、禁止していたはずの数字がそのまま絵に出てしまう。モデルを GPT-5.6 に格上げしても直らなかったのは、前段が「文字を含んだ場面」を書いてしまう癖はモデルを替えても残り、この矛盾が消えなかったからだ。

効いた対策は、モデルの格上げでも、禁止指示の追加でもない。禁止の規律を、描画の段ではなく、その手前の「シーン説明文を書く段」へ移すことだった。前段の指示に「読める文字・数字・ラベルの類は場面に登場させない（例：『High Quality』と書かれた付箋ではなく、無地の付箋や記号で表す）」と明記したのだ。すると Flash が書く場面から文字要素そのものが消え、全体の禁止と衝突しなくなる。改良後のシーン説明文は、たとえば次のように変わった。

Scene: … placing a clear, bold orange numeral block onto a scale, balancing it against a blurry, gray cloud shape …（＝天秤にオレンジ色の「数字のかたまり」を置き、灰色の曖昧な雲と釣り合わせる。読める文字は無し）

同じ Flash のままで、文字の混入は消えた。要するに、品質を左右していたのは描画モデルの格ではなく、その手前で「場面をどう言葉にするか」という規律だった。全面刷新（モデル交換）に飛びつく前に、矛盾している一点を直す——ここでも部分最適が勝った。

コストは「どの工程が費用の本体か」で決まる——記事は文章量、画像は描画

なぜ画像ではモデル差が「誤差」で済むのか。前段のモデルを替えても、画像の仕上がりも費用もほとんど動かなかった——その答えは費用の内訳にある。さきほどの「二段構え」と合わせて割合で見ると、すっきり腑に落ちる。

くり返すと、画像は「①LLMが英語のシーン説明文を書く → ②画像モデルがそれを絵にする」の二段構えだ。①のシーン説明文は、記事本文と同じく“文章を書き出す”仕事なので、費用は出力トークン（書き出す文章の量）で決まる。ただし、その文章はせいぜい数十語ととても短いので、①にかかる費用はごくわずかだ。

いっぽう②の描画は、文章量では決まらない。GPT-Image2 の描画コストは、出力する画像の解像度（今回は1024×1024）・品質設定・枚数（見出し画像＋各セクションの画像）で決まり、記事1本あたり数十円規模になる。つまり画像の費用は、ほぼこの②が握っている。

ここが今回の肝だった。モデルを Flash から GPT-5.6 に替えて動くのは、費用のごく一部でしかない①の部分だけ。②の描画はまったく変わらない。画質を決めているのも②と、①の“書き方の規律”のほうなので、前段のモデルを替えても、画像の仕上がりは変わらず、費用の総額もほとんど動かなかった。品質も財布も動かないのだから、替える理由がない——それが結論だ。

記事はこれと事情が違う。記事の費用は、①にあたる“文章の書き出し”がそのまま本体で、しかも量が多い。だから出力単価の安いモデルを選ぶと、その差がまるごと効いてくる。同じ「モデルを替える」でも、記事では費用の本体を直接動かし、画像ではごく一部しか動かさない——どこが費用の本体かが、記事と画像で逆なのだ。

ここから得た実務則はシンプルだ。最適化に手を付ける前に、「費用の本体がどの工程にあるか」を先に見ること。本体でない工程をいくら磨いても、財布にも品質にも響かない。

私たちが得た指針：モデルを選ぶ前に、タスクの型を見る

モデル選定を「新しさ」や「勘」で決めると、望んだ結果が得られないことがよくある。ベンチマークの数字が高い最新モデルに飛びついても、そのタスクでは前のモデルと見分けがつかなかったり、逆に効くのはモデルではなく指示文の書き方だったり——今回の検証は、まさにその連続だった。だから私たちは毎回、実タスクで測る。今回の実測から持ち帰った指針は、次の三つだ。

• 長文推論（記事・提案・要約の一部）はモデルの格が効く。ここは品質側に寄せる。ただし僅差で見分けがつかないなら、安い候補へ寄せる。
• 短い定型生成（分類・抽出・画像のシーン文）は、モデルより指示が効く。安いモデルに良いプロンプトを添えるほうが、格上げより確実で、しかも安い。
• 費用の割合が大きい工程を先に見る。記事は出力トークン、画像は描画。効かない軸を磨かない。

私はAIを単なる道具ではなく、業務の相棒として設計に組み込んでいる。相棒だからこそ、「どの仕事を誰に任せるか」という配役がすべてだ。高いモデルをあらゆる工程に一律で使うのは、名優に端役まで演じさせて予算を溶かすのに似ている。

新しいモデルが出たら、まず一番安い候補を、実タスクで並べて測る。冒頭で触れた gateway の作りは、この「まず測る」を安く回すための土台でもある。AIを業務システムに組み込んでいる中小・零細の経営者も、実装を担うフリーランスのエンジニアも、次に新モデルが出たときはベンチマークの数字で飛びつく前に、自社の実タスクをまず1本、測ってみてほしい。値段表の上下ではなく、目の前の仕事の型を見ること——それが、私たちがこの夏の検証で確かめた結論だ。

参考：本記事の単価・スコアは2026年7月時点で私たちが社内検証した際のスナップショットである。最新の料金は各社（OpenAI / Anthropic / Google AI）の公開料金ページで確認してほしい。