モデル比較の観点 — 何を基準に選ぶか
生成AIのモデルは更新が速く、名称・性能・料金は頻繁に変わります。そこで本ページでは、**時間が経っても変わりにくい「比較の観点（基準）」**を学びます。個別モデルの最新の数値そのものは扱いません。
注: 具体的なモデル名・コンテキスト長・料金・ベンチマーク値などの変化が速い事実は、本サイトでは
data/models.yamlに確認日つきで集約し、モデル比較表はそこから生成します（整備は今後）。本文には固有の数値を書きません。最新値は各社の公式ドキュメントを参照してください。
なぜ「観点」を学ぶのか ★★
モデルそのものを覚えても、すぐに新しい版に置き換わります。一方で「何を基準に選ぶか」という観点は長く使えます。観点を持っていれば、新しいモデルが出ても同じ物差しで素早く評価できます。
主要な比較の観点 ★★
各社の公式ドキュメントは、おおむね次のような項目でモデルの仕様を公開しています。選定ではこれらを自分のユースケースに照らして比べます。
- 能力・モダリティ: テキストだけか、画像・音声なども扱えるか。コード生成やツール使用（関数呼び出し）に対応するか。
- コンテキスト長: 一度に入力できる量。長い文書やコードベースを扱うほど重要になる。
- コスト: 利用料金（多くはトークン単価で、入力と出力で異なる）。
- レイテンシ・スループット: 応答の速さと処理量。対話用途とバッチ用途で重視点が変わる。
- 提供形態・ライセンス: API提供か、オープンウェイトで自前運用できるか。データの取り扱い方針。
- 安全性・ガバナンス機能: 有害出力の抑制やポリシー、監査のしやすさ。
選び方の考え方 ★★
- ユースケース起点で選ぶ: 「最高性能」ではなく「その用途に十分か」を基準にする。要件（精度・速度・コスト・扱うデータ）を先に決める。
- ベンチマーク値だけで決めない: 公表スコアは参考程度に。自分のタスクで小さく試して評価する。
- 1つに固定しすぎない: 用途ごとに使い分ける、将来の乗り換えを見込んで設計する、といった柔軟性も大切。
鮮度の扱い ★★
比較で使う具体的な数値（料金・コンテキスト長・性能）は必ず日付とともに扱い、公式ドキュメントで裏取りします。本サイトではこれらを data/models.yaml に確認日つきで集約し、記述の陳腐化を防ぎます。
まとめ
- 変わりやすい数値ではなく、変わりにくい「比較の観点」を身につける。
- 能力・コンテキスト長・コスト・速度・提供形態・安全性を、用途に照らして比べる。
- ベンチマークだけで決めず、自分のタスクで小さく試して選ぶ。
確認問題
問1. モデルを比較する際に「観点（基準）」を重視する理由として最も適切なものはどれか。
- モデル名を暗記するため
- 個別モデルは更新が速く、観点のほうが長く使えるため
- 料金を無視できるため
- ベンチマークだけで選べるようになるため
正解: 2 解説: 個別モデルはすぐ新版に置き換わりますが、「何を基準に選ぶか」という観点は長く使えます。新しいモデルも同じ物差しで評価できます。
問2. モデル選定の考え方として適切なものはどれか。
- 常に最高性能のモデルを選ぶ
- 公表ベンチマーク値だけで決める
- ユースケースの要件に照らし、小さく試して評価する
- コストは考慮しない
正解: 3 解説: 「その用途に十分か」を基準に、要件（精度・速度・コスト・データ）を決めて小さく試すのが実務的です。ベンチマークは参考にとどめます。
問3. 変化の速い事実（料金・コンテキスト長など）の扱いとして適切なものはどれか。
- 教材本文に固有の数値を直接書き、更新しない
- 日付とともに公式ドキュメントで裏取りし、データとして集約する
- モデルの知識だけで補う
- 出典を書かずに記載する
正解: 2
解説: 変化の速い数値は日付つきで一次情報を裏取りし、データ（data/models.yaml）に集約して管理します。本文に固有値を埋め込むと陳腐化しやすくなります。
参考にした考え方の出典
比較で用いる仕様項目は、各社が公開するモデルドキュメント（例として Anthropic の Models overview）を参考に、特定ベンダーに依存しない観点として自分の言葉で整理しました（末尾の参考文献を参照）。