「この資料の要約、安いモデルで足りるか、高いモデルにすべきか」— LLMを業務に使い始めると、この判断を毎回感覚で下すことになる。ベンチマーク記事の順位は一般タスクの平均であって、あなたの担当業務の難所を測っていない。だから読んでも、自分の仕事の答えにはならない。
同じことは、比較のためだけに作った仮想タスクにも当てはまる。記録が採用判断の根拠になるのは、完了条件の明確な本業のタスクで取ったときである。本稿はその最初の記録を60分で作る手順と、コピーしてそのまま使える記録シートを渡す。
この記事を読み終えた時、手元に残るもの:
- 60分で回す比較手順（タスク固定 → 入力同一化 → 各2回実行 → 採点 → 記録）
- そのまま使える記録テンプレート3点（タスク定義シート・採点表・実行記録）
- 「どのタスクに上位モデルを振るか」を金額で決めるコスト早見表と計算例
- 比較が静かに崩れる失敗パターン8つ
- 創作系タスクの比較記録2件 — 品質と事実忠実度の逆転、再考プロセス込みの振り分け方
最初の記録は候補を絞るスクリーニングである。採用の判断は、難易度や入力形式の異なるタスクの記録を重ねて行う。
同じ形式のテンプレート一式（試験前欄§1〜§2・試験後欄§3〜§7）は ai-task-comparison-template にも置いてある。本稿本文のシートをコピーしても、repoのファイルをコピーしても、同じ記録が完成する。
比較対象は OpenAI の GPT-5.6 Sol（同社の高性能帯モデル — 発表では価格性能曲線の「frontier end」に位置づけられる）と GPT-5.6 Luna（大量処理向けの低コストモデル）である。手順そのものは任意の2モデルにそのまま適用できるが、本稿の数値と価格はこの2モデルの 2026-08 時点の公開値に基づく（2026-09-04 に再確認、単価の変化なし）。
前提
- 2つのモデルに同一の入力を与えられること（API または同一UI）
- UIで実行する場合は毎回新規セッションを開くこと。会話履歴・カスタム指示・利用ツールはAPIほど固定できないため、その条件も記録に残す
- 入力に顧客情報・社内コード等の機密を含む場合は、組織が承認した環境と保存先を使い、APIキーを記録ファイルに含めない。公開用の記録には匿名化した入力を別途用意する
- 完了条件を一文で書ける実タスクを一つ持っていること
- 出力・採点・差分を保存する作業ディレクトリ
- 本稿の価格・為替の検証日: 2026-08-22（初回・為替150円/$）・2026-09-04/09-05（OpenAI 公開価格を再確認、単価の変化なし）
タスク選定が手順全体の質を決める。「早く終わらせたいが品質要件が明確な業務」が適している。例: 長文資料の要約とチェックリスト化、既存コードへのテスト追加、提案書の構成案出し。
逆に、完了条件が主観しかないタスク（「いい感じに」）は採点不能なので外す。
比較手順（60分）
60分は小〜中規模タスクでの目安である。実測が枠を超えた場合は、超えた時間も記録する。記録はすべて1つのファイルに追記していく。まず冒頭のシートを埋める。
0–10分: タスクと完了条件の固定 → タスク定義シート
- タスク名を一行で書く
- 完了条件をチェックリスト3〜5件で書く（例: 要約が600字以内 / 数値の転記誤りが0 / チェックリストが10項目以上）
- この時点で完了条件が書けないなら、タスクを小さく切る
# モデル比較記録 — <タスク名>
日付:
モデル: <上位モデル> / <低コストモデル>
実行環境: API / 同一UI（新規セッション毎）
## 完了条件
- [ ]
- [ ]
- [ ]
## 入力
input.md に固定（10–20分で作成・以降編集しない）
10–20分: 入力の同一化
- 入力プロンプト・資料・制約を1つのテキストファイル（input.md）に固める
- 「日本語で」「出力形式はMarkdown表」など、暗黙の指定を全部明文化する
- ファイルを保存したら、実行中は一切編集しない
20–40分: 各モデル2回ずつ実行
- 同じ入力ファイルを上位モデルに2回、低コストモデルに2回、計4回実行する
- 温度・推論設定など、両モデルに共通して指定できる生成パラメータは同じ値に揃える
- 各出力に実行番号を振ってそのまま保存する（手を加えない）
採点（40–50分）
4軸を各1〜5点で採点する。判定者は自分一人、尺度は下の表の定義を使う。2点・4点は隣接する定義の中間に当たるときに使う。
| 軸 | 1点 | 3点 | 5点 |
|---|---|---|---|
| 品質 | 誤り・欠落が多く信用できない | 数箇所の誤りはあるが骨格は正しい | 誤りがなく、そのまま提出できる |
| 要件充足 | 完了条件の半分未満 | 主要条件は満たす | 全条件を満たす |
| 修正量 | 全面修正 | 2割程度の修正 | 修正不要〜軽微 |
| 所要時間 | タスク自体より遅い | 同程度 | 明らかに速い |
採点表を記録ファイルに追記する:
## 採点（1–5点・2点と4点は中間）
| 軸 | <上位>#1 | <上位>#2 | <低コスト>#1 | <低コスト>#2 |
|---|---|---|---|---|
| 品質 | | | | |
| 要件充足 | | | | |
| 修正量 | | | | |
| 所要時間 | | | | |
## 差の一行メモ（指示解釈 / 知識 / 構成力 の仮説）
-
修正量と所要時間を採点する場合は、保存した出力の作業用コピーを別に作り、完了条件を満たすまで修正する。修正前後の差分と開始・終了時刻を記録し、生出力そのものは上書きしない。
各モデルを同じ環境で最低二回実行する理由は、単発の当たり外れを検出するための最小試行である。
例えば「修正量」の2回の点数が2と4に割れたら、その軸は不安定の印である（タスク定義の曖昧さ・生成揺れ・採点揺れ等が候補）。不安定だった軸は試行を3〜5回に増やして再実行し、中央値で判定し直す。
記録（50–60分）
実行記録を同じファイルに追記して、記録を完成させる。
## 実行記録
- 入出力トークン（APIの場合）: #1 in / out =
- コスト: （入力トークン÷1,000,000×入力単価 + 出力トークン÷1,000,000×出力単価）×150円
- 出力全文: outputs/<モデル>-<番号>.md に保存済み
- 判定: 床で足りる / 上位の能力域 / タスク定義が曖昧（次節）
コストの計算例（2026-08時点の公開価格、為替150円/$。1リクエストあたり・非キャッシュ単価）:
| タスク規模 | 入力/出力トークン | Luna | Sol |
|---|---|---|---|
| 日常タスク | 2,000 / 500 | 約0.15円 | 約2.7円 |
| 中規模タスク | 10,000 / 1,000 | 約0.5円 | 約9円 |
| 重いタスク | 50,000 / 3,000 | 約2円 | 約39円 |
Luna は input $0.20/1M・output $1.20/1M、Sol は input $4.00/1M・output $20.00/1M による計算である（API単価・2026-08時点・為替150円/$）。
読むときの注意:
- Sol のこの単価はプロモーション価格で、少なくとも2026-11-21までとAPI料金ページに注記されている（期限後の価格は再確認が必要）
- 同一入力を反復する場合はキャッシュ割引が適用され得るため、実費はAPI応答の使用量から記録する
- チャットUIの定額プランで実行した回はこの計算の対象外なので、コスト記録はAPIで実行した回に限る
この表の判断への使い方（計算例）:
重いタスク（入力50k・出力3k）の1回あたり差は約37円（Sol 約39円 − Luna 約2円）。このタスクが月20回あって、記録でLunaが品質要件を満たせたと確認できたなら、振り替えで月約740円のコスト差になる。
逆に「床で足りる」タスクを上位モデルに流し続けても、同じ計算で積もるだけである。金額が小さいうちは感覚で済むが、回数と人数が乗る業務では、この桁の振り分けが効いてくる。この記録があると、重いタスクだけ上位モデルに振るかを感覚ではなく金額で決められる。
記入例1 — 本業タスクでの実測 (コンテンツ生成 × 機械品質ゲート)
筆者の本業の一つは技術記事の執筆と、その公開前品質ゲート (秘密情報スキャン・根拠が紐付けられていない割合表現の検出・計測導線の有無などの機械検査) の運用である。
今回の比較タスクは、実験の生データからこの記事の「記入例」セクションを執筆する仕事そのもの — 筆者が普段やっている仕事をそのまま2モデルに投げた。汎用の仮想タスク (例: 架空の議事録の要約) は手順の説明には使えても採用判断の根拠にならないためである。
【更新 2026-09-05】初版では仮想タスクでの記入例を掲載していたが、この理由で本業タスクの記録に差し替えた。
タスク定義シート (埋めるとこの形):
# モデル比較記録 — 実験生データからの記事セクション執筆
日付: 2026-09-05
モデル: GPT-5.6 Sol / GPT-5.6 Luna (エージェントCLI経由・thinking設定は両方medium)
実行環境: 同一CLI (各回とも新規セッション)
## 完了条件
- [ ] 記事の品質ゲートで本文起因の指摘が0件 (秘密・割合表現・導線の機械検査)
- [ ] 数値は生データの転記か、指示どおりのコスト計算の結果のみ (新規の数値を作らない)
- [ ] 構成: 見出し1つ・表1つ・5要素 (比較説明/実行条件/採点表/実行記録/判定)・600〜1200字
- [ ] 注意2点 (入力の大半はCLI固定プロンプト・CLI単価はAPI公開単価と別レート) を織り込む
入力は比較実験の生データ (各回のトークン数・所要時間・採点結果・単価) に執筆要件を付けた1ファイル (約3.1KB)。品質ゲートの内部基準はモデルに教えていない — ゲートは独立の検査者として働く。
結果:
| Sol #1 | Sol #2 | Luna #1 | Luna #2 | |
|---|---|---|---|---|
| 機械ゲートの本文起因指摘 | 0件 | 0件 | 0件 | 0件 |
| 数値の逸脱 (生データにない数値) | 0 | 0 | 0 | 0 |
| 品質 | 4 | 4 | 4 | 4 |
| 要件充足 | 5 | 5 | 5 | 4 |
| 修正量 | 4 | 4 | 4 | 4 |
| 所要時間 | 5 | 5 | 5 | 5 |
機械ゲートは4本とも秘密情報・割合表現を検出せず、モデル差を出さなかった (検出された検証日マーカー形式と字数警告は全試行共通の雛形起因)。数値の転記・コスト計算も4本とも正確で、字数要件も満たした (空白を除く本文で4本とも1,001〜1,128字・要件は600〜1200字)。
差は人間の採点に現れた — ただし欠点の種類が違った:
- Sol #1・#2: 構成は穏当だが、コストを $0.0380676 のように7桁の精度で書き、そのままでは掲載できない (丸め直しが必要)
- Luna #1: 採点表に「所要時間」の列が2つ入り (秒数と点数)、表を作り直す必要がある
- Luna #2: 判定文が生データを超えた — 2回の試行から「完全無修正を安定して得られたSol」と安定性の根拠を引き出し、データにない「追加検証」という手続きを判定に導入した
実行記録:
- トークン (CLI計測): 入力 28,958 (4セッション同一 — 大半はCLIの固定系プロンプト) ／ 出力 Sol 968・992、Luna 1,236・1,191
- コスト (代理指標・CLI表示単価で計算): Sol $0.041・$0.041 ／ Luna $0.0073・$0.0072 (150円/$で約6.1円 vs 約1.1円・1回あたり)
- 所要 (セッション計測): 12秒・13秒・12秒・12秒
- 出力全文とゲート実行ログは筆者の記録ディレクトリに保存 (生出力は手を加えない)
判定: 私のタスク (技術記事のセクション執筆 × 機械品質ゲート) の場合は、どちらのモデルも「そのまま提出できる」水準ではなく、人間の最終編集が必須だった。
機械ゲートは差を検出せず、差は編集品質 (数値の丸め・表設計・判定の論理範囲) に出た。
運用の振り分けは、日常の下書きは約1.1円のLunaで回して最終編集を人間が持ち、修正量を減らしたい単発の重要文書だけSolとする — この根拠は今回の記録であって、他のタスクには持ち込まない。
差の一行メモ (指示解釈 / 知識 / 構成力 の仮説): 差の主体は構成力 (表設計・数値の丸め・判定の論理範囲)。指示解釈と数値処理は4本とも要件どおりで、ここには差が出なかった。
記入例2 — 創作タスク (読み物記事) × ブラインド採点【更新 2026-09-05】
記入例1は機械検査で採れるタスクだった。次は、機械採点の効かない創作系で同じ手順を回した記録である。こちらも本業タスクである — 「実話の生記録から読み物記事を作る」仕事である。
タスク: 実運用で起きた事故の生記録 (AIエージェントの誤停止 — 数値・時刻つきの実測ログ) から、読み物記事をタイトル案の設計から完結まで1回の指示で作る。
入力は、役割・品質の物差しにする別記事の全文・生記録・形式・制約を1ファイルに固めたもの (約9.2KB)。
完了条件:
- 事実は生記録の範囲内のみ。生記録の数値 (12:31・15分・17分・3通等) は変えない。生記録にない数値の計算 (差分・合計) を新たにしない
- 物差し記事の文面・ジョーク構造は借用しない (水準のみ参照)
- 本文は空白・改行を除き1,200〜2,500字
モデル: GPT-5.6 Sol / GPT-5.6 Luna に加え、創作の上限を見るため Claude Opus 5 を追加した。各2回・新規セッション (エージェントCLI経由・全モデルともthinking設定はmedium)。
採点はブラインドで行った — 出力をSHA-256順に並べて字母を振り、採点後に対応を開封する。採点者の先入観が点数に混入するのを防ぐためである。
結果:
| Sol #1 | Sol #2 | Luna #1 | Luna #2 | Opus #1 | Opus #2 | |
|---|---|---|---|---|---|---|
| 読み物としての品質 (blind) | 無難 | 無難 | 落第 | 落第 | 物差し級 | 物差し級 |
| 生記録にない数値・事実 | 0件 | 0件 | 0件 | 1件 | 5件 | 5件 |
品質と事実規律が逆転した。物差し級の落差とユーモアを出せたのはOpusだけだが、事実の逸脱もOpusが最も多かった:
- Opus #1: 本命タイトルの「夜8時」(生記録は「20時過ぎ」。時刻の丸め)、「5分待った。無言。10分待った。」(生記録にない進行の刻み)、「8時間ほど遅れて配達された」(昼の時刻と夜の時刻からの差分計算)、「人間がやると数十分かかる」(記録にない作業時間)
- Opus #2: 待ち時間の演出「5分。」「10分。」(同じく刻み)、「報告書は8時間後に届いた」(同じく差分計算)、「停止の11分前に完走」(停止時刻は記録になく差分は計算不能)、「人間がやると2時間かかる作業で、途中で飽きる」(記録にない作業時間と心情)
- Luna #2: 本命タイトル「17分前に仕事は終わっていた」— 「17分」自体は実測だが、「いつに対する17分前か」(停止判定の時刻) は生記録にない。数字が実在しても、基準点が無記録なら相対表現は派生計算になる
一方で、数値の転記 (12:31・15分・17分・3通・8項目) は6本とも全問正解だった。捏造は「盛りたい箇所」— 待ち時間の刻み・相対時刻・当時の心情 — に偏って出たのである。
実行記録:
- コスト (代理指標・CLI表示単価): Sol $0.048×2 ／ Luna $0.009・$0.006 ／ Opus $0.233・$0.224
- 所要 (セッション計測): Sol 24秒×2 ／ Luna 21秒・15秒 ／ Opus 55秒・47秒
- 入力全文・出力6本は筆者の記録ディレクトリに保存 (生出力は手を加えない)
判定: 創作系では「1発の品質」と「事実忠実度」がモデル間で逆転しうる。どちらか一方で振り分けると、もう片方で事故る。採点軸は分けて取る。
記入例3 — 再考プロセス込みで比較する【更新 2026-09-05】
記入例2までの比較は「1発の出力」を比べていた。しかし運用では人間の編集が入る。1発で出せるかより、下書き→検証→修正のプロセス込みでどこまで仕上がるかを比較しないと、実運用の差を見誤る。
記入例2と同じ入力・同じ制約で、再考の入れ方を3通り試した (自己再考と思考強化は各2回、FB再考は1回):
- 自己再考: 1セッション内で「下書き → 生記録との自己検査 (違反リスト+弱点3つ) → 最終稿 → 変更点メモ」まで書かせる
- 思考強化: 1発のまま推論レベル (thinking) をhighに上げる
- FB再考: 1発の出力に人間の指摘3行 (生記録にない時刻表現を記録の語へ置換・逆転した時系列を修正・ユーモアは保持) を付け、再生成させる
結果 (最終稿の時点):
| 構成 | 品質 | 生記録にない数値 | コスト (同上) | 所要 |
|---|---|---|---|---|
| Sol 1発 | 無難 | 0件 | $0.048 | 24秒 |
| Sol 1発 (high) | 無難よりやや上 | 0件 | $0.049 | 28〜32秒 |
| Sol 自己再考 | 読み物として成立 | 0件 | $0.049〜0.062 | 46〜47秒 |
| Luna 1発 | 落第 | 0件・1件 | $0.006〜0.009 | 15〜21秒 |
| Luna 自己再考 | 及第まで持ち上がる (説明調は残る) | 相対表現1件が検査を通過・1回は形式も逸脱 | $0.010〜0.011 | 29〜54秒 |
| Opus 1発 | 物差し級 | 5件・5件 | $0.22〜0.23 | 47〜55秒 |
| Opus 1発 (high) | 物差し級 | 2回とも残存 | $0.22〜0.29 | 51〜82秒 |
| Opus 自己再考 | 1回は全構成中で最高水準 | 1回は解消・1回は修正中に新規導入 | $0.25〜0.30 | 51〜96秒 |
| Opus 1発+FB再考 | 物差し級 (ユーモア保持) | 指摘3条すべて解消 (指摘外の刻みは残存) | 計$0.47 | 計124秒 |
読み方:
- 自己再考は効く。特に安い側で: Solは「無難」から「読み物として成立」へ上がり、コストは1発とほぼ同額だった (入力の削減と出力の増加が相殺するため)
- 自己検査は「数字の有無」は照合するが「使い方」は照合しない: LunaとOpusは「17分前」型の相対表現を自己検査を通過させた (Solはそもそもこの表現を出さなかった)。Opusの1回は、検査で「夜8時」を違反と正しく判定した同じセッションで、「17分前」を事実に基づく反転と誤認して本命タイトルに新しく入れてしまった — Aを直してBを生む型の失敗である。修正後は全文を再スキャンする
- 自己検査は人間の採点より強いこともある: 記入例2のブラインド採点で筆者はOpus #2の「5分。」「10分。」を見逃したが、Opus自身の自己検査がこれを検出・削除した。人間とAIで違うものが見える — 検査主体は1つに絞らない
- 思考強化 (high) は事実規律を直さなかった: 派生時刻が2回とも残存した。この試行の範囲では、事実の逸脱は思考量の問題ではなく検証工程の問題である
- FB再考 (人間の指摘3行→再生成) がこの試行では最も安定していた: 指摘3条はすべて解消した。ただし指摘に入れていなかった「5分。」「10分。」の刻みと当時の心情はそのまま残った — FB再考は指摘したものしか直さない。指摘リストの網羅性が結果の品質を決める
判定: 「表現力で下書きを書かせ、事実ベースの検証で磨く」 — 下書きは表現力でモデルを選び (このタスクならOpus)、事実検証は独立した実行 (自己検査+人間の照合) に担わせ、最後に人間の短い指摘を通して仕上げる。
仕上げの方向 (技術で締めるか、情緒で裏返して落とすか) は載せる媒体の戦略で変わる。そこまで含めた比較が「1発の比較」ではなく「運用の比較」である。
【更新 2026-09-05】 この判定の「人間の照合」「最後に人間の短い指摘」は、その後の運用方針で機械の検査ループに置き換えた。
FB再考の教訓の本体は「指摘したものしか直らない = 指摘リストの網羅性が品質を決める」であって人間である必要はなく、網羅的な検査リストと反復ループで機械に再現できる。同じ手法を技術記事1本の執筆に通したところ (機械ゲート3種+独立した検査エージェントによる全文再検査を3反復)、指摘は5件→3件→2件と収束し、1回目の修正が2回目で別の指摘を生むケースも実際に起きた (修正後に全文を再スキャンする理由そのもの)。
検査主体はコスト性能比で選び、指摘ゼロか上限回数で打ち切る。
失敗パターン
失敗は2箇所で起きる — 比較の設計 (入力と試行の組み方) と、採点と記録の管理である。
比較の設計で壊す:
- モデルごとに入力や資料を変える（比較ではなく別の実験になる）
- 1回だけの出力で結論を出す（単発の性能を過大評価する）
- 本業でないタスクで比較する（手順の練習にはなるが、通過しても採用判断の根拠にならない）
- 1発の出力だけで振り分ける（人間の編集が入る仕事では、再考プロセス込みで比較しないと運用の差を見誤る。記入例3）
採点と記録で壊す:
- 文体の好みと要件充足を混同する（読みやすさ軸は採点表にない）
- 採点後に尺度を変える（過去の記録と比較できなくなる）
- 完了条件の「測り方」を固定しない（字数はコード込みか、丸めは何桁か、差分・合計の計算は許すか。指示の曖昧さがモデル差として観測され、直すべき指示の欠陥をモデルの欠点として計上してしまう）
- 良い結果だけを残し、失敗した試行を消す（再実行で再現できなくなる）
再現条件
第三者が追試できる状態とは、次がすべて揃っていることである。
- 入力全文（プロンプト・資料・制約のファイル）
- モデル識別情報とバージョン
- 生成パラメータと実行環境
- 試行回数（各2回）
- 採点尺度の定義（本稿の表）
- 出力全文と各点数、修正履歴
判定の読み方と運用
- 差がほぼ無い → そのタスクは床（誰でも使える水準）で足りる。上位モデルに支払う理由は今回の記録からは確認できない
- 差が安定して出る → 業務の難所が上位モデルの能力域にある。重いタスク側に投資する価値がある
- 差が出たり出なかったり → タスク定義が曖昧。完了条件を絞って再実行する
- 創作・読み物系で差が出る → 品質と事実忠実度を別々の軸で採点する。この2つはモデル間で逆転しうる (記入例2)。事実照合は「数字の有無」だけでなく「相対表現の基準点」— 「X分前」「Y時間後」の基準時刻が記録にあるか — まで見る
いずれの読み方でも、結論が効くのは記録を取ったそのタスクだけである。他のタスクへの当てはめは、そのタスクの記録を新たに取って行う — 「私のタスクの場合は」という範囲で結論を使うことが、この手順の前提である。
同じ形式の記録を重ねると、自分の業務のどの部分は現行の低コストモデルで足りて、どの部分に上位モデルを投入すべきかが、感覚ではなく記録で決まるようになる。
記録が3件ほどたまったら、業務タスク単位の振り分け表にまとめると運用に乗る:
## モデル振り分け表（業務タスク単位）
| 業務タスク | 記録での判定 | 既定モデル |
|---|---|---|
| | 床で足りる / 上位の能力域 / 未確定 | |
業務効率化の実効は、道具の導入ではなくこの振り分けの質が決める。
同じ形式の比較観測の蓄積は、月次トラッカーで公開している。
どのタスクから測り始めるか決まっていない場合は、5択の診断でいまの位置を測ってからタスクを選んでもよい。
なお、この比較手順を含む海外AI製品の日本語評価はJapan LaunchOpsで運用しています。モデル選定の記録方法・業務への当てはめの相談は日本語AI評価のページで受け付けています。
出典
- OpenAI API 料金ページ: https://developers.openai.com/api/docs/pricing
- GPT-5.6 の価格性能に関する発表（Luna の従来価格から80%値下げ）: https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/
- モデル価格の長期推移データ（Nesyona Research）: https://nesyona.com/research/ai-token-price-decay-2026/
価格と為替は 2026-08-22 時点の公開情報に基づく（2026-09-04・09-05 に再確認、単価の変化なし。Sol の単価はプロモーション価格で少なくとも2026-11-21まで）。改定後は本稿の金額の再計算が必要である。