モデルの価格が下がると、つい「今まで使っていた最上位モデルをそのまま使えばよい」と考えたくなります。
しかし、費用が下がっても利用枠は有限であり、処理時間や人の確認工数も消えません。
企画の方向を決める仕事と、決まった形式へ100件を整える仕事を同じモデルへ任せれば、どちらかで過剰品質か手戻りが生じます。
そこで見るべきなのが、モデル1回の価格ではなく、使える成果物が1件できるまでの総費用です。
初回の生成が安くても、やり直しが増え、担当者が細部を直し続けるなら節約になりません。
反対に、検査条件が明確な仕事なら、下位モデルへ移しても品質を維持しながら処理量を増やせます。
本稿では、2026年8月6日に確認したOpenAI公式のAPI価格を基準に、Sol・Terra・Lunaの配分を組み直します。
ChatGPT WorkやCodexの利用枠はAPIのトークン課金と同一ではないため、画面上の消費量や契約条件は別に確認してください。
OpenAIのモデル比較ページでは、100万トークン当たりの入力／出力価格はSolが5ドル／30ドル、Terraが2.50ドル／15ドル、Lunaが1ドル／6ドルです。
キャッシュ入力は順に0.50ドル、0.25ドル、0.10ドル。
3モデルとも105万トークンのコンテキスト、最大12万8,000トークンの出力、テキストと画像の入力、推論強度の指定に対応すると案内されています。
つまり同程度の入出力量なら、TerraはSolの約半分、LunaはSolの約5分の1です。
ただし、長い入力が27万2,000トークンを超える場合は追加の価格条件があるため、大量資料をそのまま投入する仕事では単純な比率になりません。
検索やコンピューター操作など、ツール呼び出しに別料金がかかる場合もあります。
価格差が意味を持つのは、モデルを替えても成功率が大きく落ちない仕事です。
10回中9回使える仕事をLunaへ移せば削減効果が出ますが、10回中5回しか使えず、毎回担当者が20分直すならSolの方が安い場合があります。
以下の比較表は、価格と初期配分を一度に確認するためのものです。
Solは「難しい仕事なら何でも」ではなく、判断を外したときの損失が大きい場面へ置きます。
新規事業の仮説、システム全体の設計、複数の一次資料が食い違う調査、既存コードへ広い影響を及ぼす変更などです。
出力の一文を直すのでは済まず、方向を誤ると後工程までやり直す仕事が該当します。
Terraは日常業務の基準にしやすい層です。
要件がある程度整理された記事構成、データ分析の初稿、既存設計に沿った機能実装、複数資料の比較といった仕事から始めます。
結果が不安定ならSolへ戻し、余裕があればLunaへ下げる「中継点」にすると運用が単純になります。
Lunaは、正解条件を機械的に確かめられる仕事から使います。
CSVの項目統一、文章の表記揺れ修正、問い合わせ分類、テストケース生成、決められた形式のコード修正などです。
自由度を下げ、入力例、禁止事項、出力形式、検査条件をそろえるほど成功率が上がります。
一つの成果物でモデルを固定する必要もありません。
企画と危険箇所の設計はSol、通常実装はTerra、リネームやテスト補助はLunaという分担ができます。
モデル選択を担当者の好みから工程のルールへ変えるのが狙いです。
配分を決める際は、難易度、失敗コスト、処理量、再試行率の4軸を各1〜5点で採点します。
難易度は前提の曖昧さと推論の深さ、失敗コストは誤りが公開・顧客・本番環境へ及ぼす影響、処理量は同じ種類を繰り返す件数、再試行率は現状のモデルでやり直しが必要な割合です。
企画判断は難易度5、失敗コスト5、処理量1になりやすく、Solから始めるのが無難です。
調査は出典が明確ならTerra、一次資料が衝突したり規制・投資判断へ関わったりするならSol。
定型実装はテストがあればLuna候補ですが、権限や決済に触れる変更はTerra以上へ上げます。
整形はLunaと相性がよいものの、要約によって意味を削る仕事は別です。
列名変換や表記統一は検査できますが、経営会議の議事録から論点を選ぶ処理には判断が含まれます。
評価も同様で、形式違反の検出はLuna、採用候補の判断や法的リスクの最終判定は人と上位モデルが担います。
4軸を合計して自動的にモデルを決めるのではなく、失敗コストだけは独立した停止条件にします。
合計点が低くても、誤送信や情報漏えいにつながる操作なら下位モデルへ任せません。
業務別に見ると、記事制作ではテーマ選定と論点設計をSolまたはTerra、見出し案の展開と既存原稿の整形をTerraまたはLuna、公開前の表記検査をLunaへ分けられます。
最新情報の確認はモデル名だけで決めず、公式資料を検索し、出典をたどれる工程を必須にします。
Lunaが出典付きの形を整えられても、出典が主張を本当に支えているかは別の検査です。
調査業務では、検索語の展開や資料の分類はLuna、複数資料の要約はTerra、相反する数値の原因分析や重要な判断はSolが初期案になります。
ここで「調査はすべてSol」と決めると、ファイル名整理や重複除去まで高いモデルで処理することになります。
作業を、集める、整える、比べる、判断するに分けると下げられる工程が見つかります。
実装では、要件の曖昧さと変更範囲で分けます。
新機能の設計や複数サービスをまたぐ不具合はSol、既存パターンに沿った実装はTerra、名称変更、テストデータ作成、静的な形式修正はLunaが候補です。
ただし、生成したコードを実行できる環境、テスト、差分レビューがなければ、下位モデルへ移した費用より確認工数が増えます。
評価業務では、採点基準を先に固定します。
文字数、必須項目、リンク切れ、構文エラーのような機械判定はLunaへ寄せられます。
ブランドとの一致、説明責任、例外を許容する判断はTerraやSol、人の承認を残します。
評価モデルを下げるときは、見逃し率だけでなく、問題のない成果物を誤って落とす率も記録してください。
成功タスク単価は、AI利用費、再試行費、人の確認時間、失敗による修正費を、採用できた成果物の数で割って求めます。
成功タスク単価＝（AI利用費＋再試行費＋確認時間の人件費＋失敗修正費）÷採用件数
例として、100件の定型処理をSolで行い、AI利用費が3,000円、確認に100分、採用率が98％だったとします。
担当者の時間単価を3,000円とすれば、確認費は5,000円。成功タスク単価は約82円です。
Lunaへ移してAI利用費が600円になっても、採用率が85％へ下がり、確認と修正に300分かかれば、人件費は1万5,000円になります。
成功タスク単価は約184円となり、モデル料金は安くても全体では高くなります。
逆に検査を自動化して確認を120分へ抑えられれば、約78円まで下がります。
節約の主役はモデル変更だけでなく、合格条件と検査方法の整備です。
ChatGPT WorkやCodexでは、APIのように毎回のトークン費用が表示されないことがあります。
その場合は、利用枠の消費、処理時間、再試行回数、担当者の確認時間を記録し、1週間の相対比較に使います。
金額へ無理に換算できなくても、同じ成果物当たりの消費量が下がったかは判断できます。
比較条件はそろえます。
同じ入力、同じツール、同じ推論強度、同じ制限時間で実行し、成果物を匿名化して採点します。
モデルごとにプロンプトを極端に作り込むと、モデル差と運用差が混ざります。
最初は共通条件で基準値を取り、その後に下位モデルだけ入力例や構造化出力を追加し、改善に必要な準備工数も総費用へ入れます。
最初の月から精密なルーターを作る必要はありません。
月曜に代表業務を5つ選び、現行モデルで10件ずつ実行します。
火曜から木曜に、品質下限を満たした仕事だけ一段下げます。
公開前、送信前、本番反映前の人の承認は残してください。
記録するのは、モデル、入力条件、処理時間、再試行回数、採否、確認時間、失敗理由です。
「文章が気に入らない」では比較できないため、事実誤認、指示漏れ、形式違反、テスト失敗、ブランド不一致のように分類します。
金曜には失敗した種類だけを上位へ戻します。
全件をSolへ戻すのではなく、「複数資料の矛盾処理」「権限周りの実装」「例外の多い顧客回答」など、失敗条件をルール化します。
同時に、Lunaで安定した処理はテンプレート化し、入力と検査を固定します。
この週次運用なら、モデル更新や価格変更があっても配分を再評価できます。
OpenAIの公式価格、契約プラン、利用画面の表示は公開前と月次レビューで確認し、記事や社内ルールに固定値を残しすぎないことも大切です。
配分表には例外の理由も残します。
「難しいからSol」ではなく、「誤った前提が後工程へ波及するためSol」のように書けば、業務が変わったときに再判断できます。
担当者が替わっても同じ条件でモデルを選べることが、継続的な削減につながります。
GPT-5.6の価格差を生かすには、最安モデルを探すのではなく、判断と処理を分けます。
Solは失敗コストが高い判断、Terraは日常業務の基準、Lunaは検査可能な大量処理という初期配分が扱いやすいでしょう。
効果は、AI利用費だけでなく、再試行と確認時間を含めた成功タスク単価で確認します。
1週間の小規模テストを行い、失敗した条件だけ上位へ戻せば、品質を落とさず費用と利用枠を調整できます。
.png){kind=logo}
