サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

GPT-5登場時の主要LLM比較　ベンチマークに振り回されない選び方と評価手順

greeden
blue spiral neon light

Photo by Frank Cone on Pexels.com

2025年8月にGPT-5が発表されたころ、大規模言語モデルの比較では、コード修正、長い文書の処理、画像を含む入力、推論コストなどが主な争点になりました。

大規模言語モデル（LLM）とは、大量のデータから言葉の関係を学び、質問への回答や文章、コードなどを生成するモデルです。
本稿は当時の主要モデルを振り返りながら、モデル名が変わっても使える選定方法を整理します。

最初に決めるのはモデル名ではなく評価条件

LLM選定で先に決めたいのは、「どのモデルが最強か」ではなく、「どの業務を、どの条件で、どの水準まで任せるか」です。
同じモデルでも、入力文、参照資料、利用できるツール、推論設定によって結果は変わります。

候補を比べるときは、少なくとも次の五つを分けて評価します。

業務への組み込み方から検討したい場合は、サイト内の生成AIを業務に入れる前に決めるべきことも参考になります。

GPT-5登場時に比較されたモデル

当時の比較対象は、一つの尺度で並べられる製品群ではありませんでした。
APIで利用するモデル、クラウドに統合されたモデル、重みを取得して運用できるモデルでは、選定理由も必要な体制も異なります。

2025年当時の主要モデルと、実務で確かめたい点
モデル 各社が示した位置付け 自社評価で確かめたい点
GPT-5 コード生成とエージェント型の作業を主な用途として発表されました。 実際のリポジトリでの修正成功率、差分の安全性、ツール呼び出しの失敗時処理。
Claude Opus 4.1 エージェント型の作業、実務的なコード修正、推論の改善が示されました。 複数ファイルの変更精度、長い指示への追従、不要な変更の少なさ。
Gemini 2.5 Pro 画像なども扱うマルチモーダル入力と、100万トークンのコンテキストが特徴でした。 長い資料から必要箇所を探す精度、根拠位置の提示、画像と文章をまたぐ理解。
Grok 3 推論に時間を使うモードと、軽量なGrok 3 miniがベータ版として紹介されました。 出力の再現性、利用環境での速度、リスクのある依頼に対する制御。
Llama 4 Scout、Maverick 重みを利用できる、マルチモーダル対応のMoEモデルとして公開されました。 ライセンス条件、必要な計算資源、更新と監視を担う社内体制。
Qwen 2.5 複数規模のモデルに加え、コードと数学向けの派生モデルが用意されました。 日本語と構造化出力の精度、実行環境、業務データを使う場合の管理方法。
DeepSeek R1 推論向けモデルと蒸留モデルが、技術資料や重みとともに公開されました。 配置先の安全性、推論時間、利用するコードと重みごとのライセンス確認。
Amazon Nova Amazon Bedrockで利用するモデル群として、長い入力や複数形式のデータへの対応が示されました。 AWS上の既存構成との統合、利用地域、アクセス制御、監視のしやすさ。
Mistral Large 2 多言語とコードに対応する128kコンテキストのモデルとして発表されました。 公式資料ではすでに退役モデルとされているため、後継モデルと移行条件の確認。
Command R+ 企業向けのRAGとツール利用に重点を置き、128kコンテキストを備えていました。 検索結果と回答の対応、引用の正確さ、現行モデルへの移行可否。
DBRX Databricksが提供するMoE方式のオープンモデルとして、Model Servingにも追加されました。 推論基盤の費用、モデル管理、データ基盤との権限分離。

マルチモーダルは、文章だけでなく画像や音声など複数形式の入力を扱うことです。
コンテキストは、一度の処理で参照できる入力範囲を指します。
範囲が広くても、必要な情報を正しく見つけて使えるとは限らないため、長さと検索精度は分けて試します。

MoE（Mixture of Experts）は、入力に応じてモデル内部の一部を選んで動かす方式です。
計算効率を狙える一方、実際の速度や費用は提供環境によって変わります。

ベンチマークの数字を直接比較できない理由

元の記事は、GPT-5のSWE-bench Verified 74.9％とClaude Opus 4.1の74.5％を近い成績として紹介していました。
しかし、この0.4ポイントだけで優劣は決められません。

SWE-bench Verifiedは、実在するソフトウェアの課題説明を読み、リポジトリに修正を加える能力を測る評価です。
OpenAIの発表は、環境上で安定して実行できなかった23問を除く477問で74.9％と報告しています。
一方、Anthropicの発表は、500問全体で74.5％と説明しています。

母集団のほか、指示文、利用できるツール、推論設定、試行回数も結果に影響します。
同じ名称のベンチマークでも、条件がそろっていなければ小さな点差を順位として読むことはできません。

公開ベンチマークは候補を絞る材料にはなります。
採用判断には、社内の過去案件や失敗例から作った評価セットを使い、同じ条件で比べる必要があります。

用途別に評価項目を変える

モデルの得意不得意は、業務の完了条件によって変わります。
次の表は、比較テストに入れたい代表的な項目です。

用途ごとの評価項目と失敗時の備え
用途 評価する内容 失敗に備える仕組み
コード修正 テスト通過、要件外の変更、セキュリティ上の問題、レビュー時間。 人によるレビュー、CIでの自動テスト、変更範囲の制限。
長い資料の整理 重要事項の抜け、根拠箇所との一致、表や注記の読み取り。 根拠ページの提示、原文との照合、判断を伴う箇所の承認。
社内検索とRAG 検索した資料の適切さ、回答と引用の一致、資料にない質問への応答。 参照権限の継承、根拠がない場合の回答停止、検索ログの保存。
エージェント 作業完了率、誤った操作、途中経過の記録、再試行時の挙動。 権限の最小化、実行前承認、回数と費用の上限、停止手段。
文書作成 事実の正確さ、読みやすさ、禁止情報の混入、修正にかかる時間。 出典確認、公開前レビュー、個人情報と機密情報の入力制限。

RAG（検索拡張生成）は、回答前に社内文書などを検索し、その結果を参照して文章を作る構成です。
モデルだけでなく、検索対象、文書の分割、アクセス権、引用表示まで含めて評価します。
仕組みを詳しく知りたい場合は、ベクトル検索と生成AI検索の違いを参照してください。

ルーティングとエージェントで増える運用責任

モデルルーティングは、依頼内容、費用、待ち時間などの条件に応じて、利用するモデルを切り替える仕組みです。
MicrosoftもGPT-5の提供時に、Azure AI Foundryのモデルルーターによる振り分けを紹介しました。

切り替えを自動化しても、判断責任までなくなるわけではありません。
少なくとも、使用したモデルと版、入力元、参照資料、ツールの実行、承認者、結果を追跡できるようにします。

エージェントは、目標を受け取り、検索や外部ツールを使いながら複数の手順を進める仕組みです。
回答文を作るだけの利用より影響範囲が広いため、閲覧と更新の権限を分け、外部送信や削除など戻しにくい操作には人の承認を置きます。

外部ツールとの接続方式を検討する場合は、MCPサーバーの仕組みと安全な導入手順もあわせて確認できます。

導入前に行う六つの手順

  1. 対象業務を一つに絞る：入力、処理、出力、利用者を一枚の流れにし、対象外の作業も書く。
  2. 合格条件を決める：正答だけでなく、許容できない誤り、確認時間、処理時間、費用を決める。
  3. 評価データを用意する：通常例に加え、入力不足、矛盾した資料、機密情報、失敗しやすい例を含める。
  4. 同じ条件で候補を比べる：指示文、参照資料、ツール、判定者をそろえ、モデルごとの差だけを見やすくする。
  5. 小さな範囲で試行する：権限と利用者を限定し、誤りの種類と人の修正量を記録する。
  6. 更新と撤退を設計する：版が変わったときの再評価、障害時の代替手順、データの削除方法を決める。

二つ目のモデルを用意することは、事業継続の助けになります。
ただし、APIの形式、参照データ、出力形式が一つの提供者に強く依存していれば、モデル名だけを差し替えても動きません。
代替経路は、定期的に同じ評価データで動かして確かめます。

モデル競争から運用設計へ

GPT-5登場時の競争は、コード、長文、マルチモーダル、推論、オープンな重みなど、比較軸がすでに複数あったことを示しています。
一つの総合順位で選ぶと、実際の業務に必要な条件を見失います。

導入判断では、候補を少数に絞り、自社の評価データで試し、誤りを誰が確認するかまで決めます。
モデルが更新されても、この手順は変わりません。

LLM選定は、性能表を読むだけでなく、実際の業務で比較し、確認手順まで決めて初めて運用につながります。株式会社greedenは、生成AIの社内勉強会を通じて、ツール選定から業務への定着までを支援しています。

株式会社greedenのAI、DX活用支援を見る

モバイルバージョンを終了