はじめに
こんにちは、エンジニア5年目の嶋田です。
この記事を開いていただき、ありがとうございます！
前回、AIモデルを「IQ」というスケールで比較する AI IQ というプロジェクトについて書きました。
そのとき自分が伝えたかったのは、
AI IQは「採用判断の答え」ではなく、「候補を絞る入口」として使う
ということでした。
今回はその続きとして、用途別にどのモデルを選べばいいか を整理していこうと思います。
この記事は、
- まず 結論（用途別の早見表） を出します
- 次に なぜそう選べるのか（指標の読み方） をまとめます
- 最後に 自分で選び直すための手順 をまとめます
という順で進めます。
結論だけ知りたい人は最初の表だけ、根拠まで知りたい人は最後まで読めばOKです。
※この記事のスコアは、AI IQ Rankings API（https://www.aiiq.org/api/rankings ） が返す methodologyVersion: 2026-06-14-abstract-reorder-software-split（updatedAt: 2026-06-23）時点のものです。Webページではなく、APIレスポンス内のメタデータに基づきます。
目次
- 用途別おすすめモデル早見表 … 結論だけならここ
- 用途別の根拠
- 前提：次元が7つに再編された
- 自分で選び直すための4ステップ
- まとめ
細目を開く
用途別おすすめモデル早見表
先に結論です。
AI IQのデータ（methodologyVersion 2026-06-14）をもとに、用途別に選ぶとこうなります。
| 用途 | 第一候補 | コスパ候補 | 見る次元 |
|---|---|---|---|
| 本番コーディング | opus-4.8 | glm-5.1 | Production Engineering |
| アプリ試作・フロント | sonnet-4.6 | gemini-3.5-flash | App Building |
| 設計・アーキテクチャ | gpt-5.5 | gemini-3.1-pro | Scientific + Abstract |
| 文章作成 | opus-4.8 / sonnet-4.6 | gemini-3.1-pro | Reliability + EQ |
| 資料作成（調査込み） | gemini-3.1-pro | — | Scientific + Computer Use |
| エージェント・自動化 | gpt-5.5 | kimi-k2.6 | Computer Use |
※最上位の
fable-5（Composite IQ 130）は、輸出規制に伴いアクセスが一時停止中のため、実務候補からは除外しています。常用できるモデルから選んでいます。
ここまでが結論です。
以降は「なぜこう選べるのか」と「自分で選び直す方法」を説明します。
用途別の根拠
冒頭の早見表が、どのデータから出ているかを用途ごとに示します。
すべて AI IQ Rankings API（methodologyVersion 2026-06-14）の実データです。
1. 本番コーディング
見る次元：Production Engineering（リポジトリ修正・デバッグ・長期実装）
| 順位 | モデル | Production Eng IQ |
|---|---|---|
| 1位 | opus-4.8 | 138 |
| 2位 | gpt-5.5 | 133 |
| 3位 | opus-4.7 | 130 |
| 4位 | gpt-5.4 | 122 |
| コスパ枠 | glm-5.1 | 114（コスト $3.56） |
SWE-Bench Verified/Pro、SWE Marathonなど「リポジトリを直す」課題で構成される次元です。
第一候補は opus-4.8。コスト重視なら glm-5.1（実効コスト $3.56）が候補になります。
2. アプリ試作・フロントエンド
見る次元：App Building（UI・試作・プロトタイプ生成）
| 順位 | モデル | App Building IQ |
|---|---|---|
| 1位 | opus-4.7 | 142 |
| 2位 | opus-4.8 | 141 |
| 3位 | sonnet-4.6 | 131 |
| 4位 | gemini-3.5-flash | 130 |
| 5位 | kimi-k2.6 | 127 |
DesignArena、Arena.ai WebDev、Vibe Code Benchなど「作って動かす」課題で構成されます。
Anthropic系（Opus / Sonnet）がこの次元に明確に強いです。
コストと性能のバランスで sonnet-4.6（IQ 131・コスト $29.3）が実務向きです。
3. 設計・アーキテクチャ
見る次元：Scientific Reasoning + Abstract Reasoning
| 用途 | 重視次元 | 上位モデル |
|---|---|---|
| 技術判断・トレードオフ分析 | Scientific | gpt-5.5(142), gemini-3.1-pro(141), opus-4.8(140) |
| 未知の問題のモデル化 | Abstract | gpt-5.5(108), gemini-3.1-pro(106), opus-4.7(102) |
注意点があります。Abstract Reasoningは全モデルで天井が低い（最高108） です。
なので、
設計の壁打ちには使えても、新規性の高い設計判断を丸投げするのは危険
という前提で使います。
候補は、抽象推論で頭一つ抜けている gpt-5.5 か gemini-3.1-pro です。
4. 文章作成
見る次元：Reliability + EQ系
文章は、総合IQよりも「指示追従（Reliability）」と「自然さ（EQ系）」が効きます。
| 次元 | 上位モデル |
|---|---|
| Reliability IQ | gemini-3.1-pro(117), grok-4.3(113), gpt-5.5(111) |
| EQ-Bench 3 | opus-4.8, sonnet-4.6 |
| AttuneBench（対人配慮） | opus-4.8(54.6), gpt-5.5(53.7) |
フォーマット厳守なら gemini-3.1-pro（Reliability 1位）。
自然さ・トーン重視なら opus-4.8 / sonnet-4.6。
ただし日本語の自然さはこのベンチマークでは測れないので、最後は自分の評価セットで確認が必要です。
5. 資料作成
見る次元：Scientific Reasoning + Computer Use
| モデル | Scientific | Computer Use | 実効コスト |
|---|---|---|---|
| gpt-5.5 | 142 | 135 | $35.6 |
| opus-4.8 | 140 | 134 | $44.8 |
| gemini-3.1-pro | 141 | 131 | $10.4 |
両次元とも性能はほぼ横並びです。
それなのにコストは3〜4倍違うので、コスト効率で gemini-3.1-pro が際立ちます。
6. エージェント・自動化
見る次元：Computer Use（ターミナル・ブラウザ操作）
| 順位 | モデル | Computer Use IQ |
|---|---|---|
| 1位 | gpt-5.5 | 135 |
| 2位 | opus-4.8 | 134 |
| 3位 | gemini-3.1-pro | 131 |
| 4位 | gpt-5.4 | 131 |
| コスパ枠 | kimi-k2.6 | 123（コスト $5.08） |
Terminal-Bench、OSWorld、BrowseCompで構成されます。
第一候補は gpt-5.5 / opus-4.8。社内ツールで大量に回すなら kimi-k2.6 も候補です。
前提：次元が7つに再編された
ここまで「次元」という言葉を使ってきました。
その前提を補足します。
前回記事の時点では、AI IQの次元は5つでした。
いま見ると 7つに再編 されています。
特にSEにとって大きいのは、コーディングが2つの次元に分割された ことです。
| 前回（5次元） | 現在（7次元） |
|---|---|
| Fluid Abstraction | Abstract Reasoning |
| Mathematical Reasoning | Mathematical Reasoning |
| Programmatic Reasoning | App Building / Production Engineering に分割 |
| Critical Reasoning | Scientific Reasoning |
| Agentic Reasoning | Computer Use |
| （なし） | Reliability |
現在の7次元は以下の通りです。
| 次元 | 測っている能力 | 代表的なベンチマーク |
|---|---|---|
| Mathematical Reasoning | 数学的推論 | FrontierMath, AIME, ProofBench |
| Scientific Reasoning | 専門的・科学的推論 | Humanity's Last Exam, GPQA Diamond, SciCode |
| Abstract Reasoning | 初見パターンの抽象推論 | ARC-AGI-1/2/3 |
| App Building | UI・試作・プロトタイプ生成 | DesignArena, Arena.ai WebDev, Vibe Code Bench |
| Production Engineering | リポジトリ修正・デバッグ・長期実装 | SWE-Bench Verified/Pro, SWE Marathon, LiveCodeBench |
| Computer Use | ターミナル・ブラウザ操作 | Terminal-Bench, OSWorld, BrowseComp, MCP Atlas |
| Reliability | 指示追従・知らないことを知る | IFBench, AA Omniscience |
「コーディング能力」をひとつのスコアで見ていると、
- UIプロトタイプは強いが、本番コードのデバッグは弱い
といった差が隠れてしまいます。
前回記事で書いた「単一スコアはAIのジャギーさを隠す」が、まさにコーディング次元の中で起きていたわけです。
自分で選び直すための4ステップ
冒頭の早見表は「答え」ではなく「一例」です。
データが変われば結論も変わります。
そこで、自分で選び直すための手順 を残しておきます。
この4ステップさえ持っていれば、データが更新されても同じやり方で選べます。
ステップ1：用途を「次元」に翻訳する
最初にやるのは、「やりたいこと」を7次元のどれに当たるかへ翻訳することです。
ここが一番大事で、かつ一番間違えやすいところです。
| やりたいこと | 対応する次元 |
|---|---|
| 既存コードのバグ修正・機能追加 | Production Engineering |
| ゼロからの画面・試作品づくり | App Building |
| 技術選定・トレードオフ判断 | Scientific Reasoning |
| 前例のない問題の構造化 | Abstract Reasoning |
| フォーマット厳守の文章 | Reliability |
| ターミナル・ブラウザ自動操作 | Computer Use |
ここで一番伝えたいのは、
「コーディング」を1語で考えないこと
です。
バグ修正なら Production Engineering、UI試作なら App Building と、見るべき次元が違います。
ステップ2：スコアを「分布の中の位置」で読む
次元が決まったら、スコアを 絶対値ではなく「分布の中の位置」 で読みます。
AI IQのスコアは、人間のIQと同じく、平均100・標準偏差15の正規分布に見立てて設計されています。
| スコア帯 | 分布上の位置 | 実務での解釈 |
|---|---|---|
| 130以上 | 上位約2% | その次元で頭一つ抜けている |
| 115〜130 | 上位16%以内 | 実用上は十分強い |
| 100前後 | 平均 | 「できなくはない」レベル |
| 100未満 | 平均以下 | その用途には向かない |
さらに、その次元の「天井」がどこにあるか も併せて見ます。
たとえばAbstract Reasoningは全モデルが115未満（最高108）。
一方Production Engineeringは138まで伸びています。
同じ「IQ 120」でも、Abstract Reasoningの120とProduction Engineeringの120では意味が違う。
天井が低い次元での120は「ほぼトップ」、天井が高い次元での120は「上位だが一番ではない」になります。
ステップ3：IQとコストを同時に見る
候補が絞れたら、Effective Cost（実効コスト）を見ます。
やることはシンプルで、
用途に必要なIQの最低ラインを満たす中で、一番安いものを選ぶ
です。
資料作成の例（前述）では、3モデルの性能がほぼ横並びなのにコストは3〜4倍違いました。
この場合、
性能差はほぼ誤差。だからコストが1/4の gemini-3.1-pro を選ぶ。
という判断になります。
性能が拮抗しているときは、コストが決定打になる。
ステップ4：Rank Statusと「測れないもの」を確認する
最後に、数字の 信頼度と射程 を確認します。
確認1は imputed（補完）フラグ です。
APIの各スコアには imputed: true / false が付いており、true は実測ではなく推定値です。重要用途では補完値に頼らない方が安全です。
確認2は そもそもAI IQでは測れないもの です。
- 日本語の自然さ
- 敬体・常体の安定性
- 社内用語への強さ
- RAGで正しく根拠を拾えるか
- 長い指示を守れるか
- 出力フォーマットが安定するか
これらは公開ベンチマークでは分かりません。
なので前回記事と同じ結論になります。
AI IQで候補を絞り、最後は必ず自社タスクで実測する。
個人的に一番大事だと思ったこと
前回も書きましたが、今回さらに強く思いました。
ランキングを覚えることより、ランキングの読み方を持つこと。
実際、前回から今回までの間に、コーディング次元が2つに分割されました。
もし「総合1位はこれ」という結論だけを覚えていたら、この変更に対応できません。
でも、
用途を次元に翻訳して、分布の位置で読んで、コストと天秤にかけて、最後は自社で実測する
という 手順 を持っていれば、何が更新されても同じやり方で選べます。
結論は古くなります。
でも、判断プロセスは古くなりません。
だからこの記事は、結論を最初に出しつつ、その後ろに「なぜそう選べるのか」と「自分で選び直す手順」を置きました。
まとめ
用途別のモデル選定は、まず結論から。
| 用途 | 第一候補 | コスパ候補 |
|---|---|---|
| 本番コーディング | opus-4.8 | glm-5.1 |
| アプリ試作・フロント | sonnet-4.6 | gemini-3.5-flash |
| 設計・アーキテクチャ | gpt-5.5 | gemini-3.1-pro |
| 文章作成 | opus-4.8 / sonnet-4.6 | gemini-3.1-pro |
| 資料作成（調査込み） | gemini-3.1-pro | — |
| エージェント・自動化 | gpt-5.5 | kimi-k2.6 |
ただし、この表は「答え」ではなく「一例」です。
自分で選び直すための手順は、次の4ステップです。
- 用途を「次元」に翻訳する（コーディングを1語で考えない）
- スコアを「分布の位置」と「天井」で読む（同じ120でも意味が違う）
- IQとコストを同時に見る（拮抗時はコストが決定打）
- imputedと「測れないもの」を確認する（最後は自社タスクで実測）
AI IQは、ランキングの答えを見る場所ではなく、どこを掘るべきかを見つける入口として使う。
この距離感が、今のところ一番現実的だと思います。