LWP | Codexのモデル選択を実践検証する
LWP TECHNICAL ARTICLE | 186
Codexのモデル選択を実践検証する
難しい記事にはTerra Highか、Sol Highか――記事186の同一入力比較から考える
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
AIで記事を書くとき、モデル名だけを見て「高性能な方を使えばよい」と決めても、品質・時間・利用量の釣り合いは取れない。重要なのは、記事が難しい理由を分解し、どの基礎能力が必要かを先に定義することである。
本記事では、その基礎能力を運用上の「推論力のファンデーション」と呼び、①問題表現、②分解、③関係統合、④制約整合、⑤不確実性管理、⑥根拠追跡・検証、⑦自己点検の七つに分ける。これはOpenAIが公開したモデル内部の構造ではなく、記事制作を比較可能にするための評価枠組みである。
この枠組みで、原価計算・製造原価報告書・複式簿記の関係を扱う記事186の Terra / high 版と Sol / high 版を再検証した。従来の比較指標は、関係統合、不確実性管理、根拠追跡をよく捉えていた。一方で、読みやすさ、シリーズとの接続、DOCX品質が推論指標に混在し、問題表現、分解、制約整合、自己点検が明示されていなかった。
結論は二段階である。品質優先の初回構成ではSol Highを基準にできる。ただし今回の実験は、同じ high でモデルだけを変えた一例であり、Sol HighがSol Mediumより優れることまでは実証していない。実運用の標準を決めるには、次にSol Mediumを同じ入力・同じ評価表で比較し、合格条件を満たせるかを確認する必要がある。
本記事の対象とゴール
想定読者
Codexで記事、仕様書、技術解説を作成している人
Terra、Sol、Lunaと推論レベルの使い分けを実測で決めたい人
モデルの印象ではなく、壊れやすい推論工程から設定を選びたい人
本記事で得られること
記事制作に必要な「推論力のファンデーション」の運用上の定義
10の比較観点ごとに、Terra High版とSol High版で何が確認できたか
モデル、推論レベル、編集・組版工程を混同しない判定方法
Sol HighからSol Mediumへ下げるときの再現可能な検証手順
第1章 なぜモデル比較を実際の記事で行うのか
1.1 一般的な説明だけでは、自分の仕事に必要な設定は決まらない
モデルの説明には、「Solは複雑な専門業務向け」「Terraは性能とコストのバランス」「Lunaは大量処理向け」といった分類がある。これは出発点として有用である。
しかし、実際の仕事では「難しい」という言葉だけでは足りない。例えば、長いが論点が一つの記事と、短いが定義・例外・数値・制度上の注意を同時に扱う記事では、必要な能力が異なる。自分の原稿で比較しなければ、どこで品質が下がるかは分からない。
そこで、同じ原案、同じ読者向けの目的、同じ記事番号という条件を固定し、モデルと推論レベルを記録して比較した。
1.2 今回の題材は、単なる会計用語の説明ではない
比較に使ったのは、原価計算、製造原価報告書、仕掛品、製品、売上原価、複式簿記の関係を検討した長いMarkdown原案である。この題材の難しさは、知識量よりも、複数の正しい説明を混同せずに一つの記事へ並べる点にある。
例えば、次の言葉は似て見えるが同じではない。
現金を払ったという支出
製造へ使った資源を測る原価
将来へ繰り越す棚卸資産
当期の利益計算へ反映する費用
製品へ直接結び付ける賦課と、共通費を規則で分ける配賦
これらを一つの言葉で済ませると、読者は「製造に使った人件費は、いつ費用になるのか」「当期製品製造原価と売上原価はなぜ別なのか」を理解できない。正確さと読みやすさを同時に求めるため、モデル比較の題材として適している。
第2章 推論力のファンデーションを定義する
2.1 これはモデル内部の公式分類ではなく、仕事を測るための枠組みである
「推論力」という言葉だけでは、何が良くなったのかを説明しにくい。本記事では、記事制作に必要な推論を七つの基礎能力に分ける。
OpenAIの公式資料は、モデルの位置づけや利用可能な推論レベル、代表タスクによる比較の考え方を示している。一方、モデル内部の思考を本記事の七分類として公式定義しているわけではない。したがって、ここでいうファンデーションは、観察可能な成果物を評価するためのLWPの運用上の定義である。
2.2 七つの基礎能力
| 記号 | 基礎能力 | 記事制作で確認すること |
|---|---|---|
| F1 | 問題表現 | 原案が本当に答えるべき問い、読者、到達点を正しく捉える |
| F2 | 分解 | 長い原案を、定義、流れ、例外、実務判断などへ分ける |
| F3 | 関係統合 | 分けた概念を、因果、順序、数値の受け渡しとしてつなぐ |
| F4 | 制約整合 | 定義、数式、前提、章をまたぐ説明が互いに矛盾しない |
| F5 | 不確実性管理 | 比喩、一般化、例外、未検証事項の境界を残す |
| F6 | 根拠追跡・検証 | 読者が数値、主張、出典をたどり、検算できる |
| F7 | 自己点検 | 漏れ、二重計上、反例、別解釈を見直して補正する |
この七つは独立しているわけではない。例えば、問題を正しく表現できても、分解後の項目を再統合できなければ記事は断片化する。数式が正しくても、前提条件を残さなければ適用範囲を誤らせる。したがって、合計点だけでなく、どこが欠けたかを見る必要がある。
2.3 推論品質と、文章・組版・運用品質を分ける
完成記事の品質には、推論以外の要素も含まれる。そこで評価を三層に分ける。
| 評価層 | 主な確認対象 | 例 |
|---|---|---|
| 推論品質 | F1からF7 | 概念分離、数値整合、境界条件、自己点検 |
| 編集品質 | 読者への伝わり方 | 読みやすさ、章立て、用語の導入、シリーズ接続 |
| 運用品質 | 制作工程と成果物 | DOCX組版、リンク、改ページ、所要時間、利用量、修正回数 |
読みやすい記事は価値が高い。しかし、読みやすさだけでは推論が正しいとは言えない。逆に、推論が正しくても、表が崩れていれば公開記事としては不合格である。三層を分けることで、失敗時にモデルを変えるべきか、プロンプトを直すべきか、変換・検査工程を直すべきかを判断できる。
第3章 比較の設計――何をそろえ、何を比べたか
3.1 固定した条件
比較では、次の条件をそろえた。
| 項目 | 内容 |
|---|---|
| 入力 | 同一の原価計算に関するMarkdown原案 |
| 成果物 | 読者向けの記事186のMarkdownとDOCX |
| 比較設定 | Terra / high と Sol / high |
| 主な確認対象 | 記事構成、概念の正確さ、数値例、注意書き、実務への接続、DOCXの読戻し |
ここでの目的は、どちらが抽象的に「賢いか」を決めることではない。難しい概念記事を一回で作るとき、どちらが少ない補正で読者向けの原稿に近づくかを観察することである。
3.2 従来の評価軸は、ファンデーションをどこまで捉えていたか
最初の比較では、次の六軸を用いた。これを七つの基礎能力へ対応させると、反映の程度が見える。
| 従来の評価軸 | 主に対応する基礎能力 | 判定 | 問題点 |
|---|---|---|---|
| 概念の階層分離 | F2分解、F3関係統合、F4制約整合 | 反映あり | 三つの能力が一項目に集約されていた |
| 数値の追跡性 | F3関係統合、F4制約整合、F6根拠追跡・検証 | 強く反映 | 数式以外の根拠追跡は明示されていなかった |
| 境界条件 | F5不確実性管理 | 強く反映 | 未検証事項と例外の区別をさらに明示できる |
| 実務への接続 | F1問題表現、編集品質 | 部分的 | 推論と読者価値が混在していた |
| 読みやすさ | 編集品質 | 推論指標ではない | 独立した編集ゲートへ移すべきだった |
| シリーズとの接続 | 編集品質 | 推論指標ではない | 記事群の設計品質として別に測るべきだった |
従来指標は、今回の題材で最も重要なF3、F5、F6をよく見ていた。その意味で方向は正しい。しかし、F1問題表現、F2分解、F4制約整合、F7自己点検が独立項目になっておらず、推論以外の品質が混在していた。したがって、「反映されているが、ファンデーション全体を測る指標としては不足」というのが再検証の結論である。
3.3 今回の比較で確認できたこと、確認できなかったこと
今回の比較は、統計的なモデル評価ではない。一つの原案と一回の制作過程を使った実務上のケーススタディである。
| 区分 | 内容 |
|---|---|
| 確認できたこと | 同じ high でモデルを変えたとき、この一例でどの種類の差が現れたか |
| 確認できないこと | high と medium または low の差、繰り返し時の再現性、平均所要時間、平均利用量 |
| 交絡要因 | Sol High版は後から作成され、品質確認の工程も改善されていた |
| 言える範囲 | この題材ではSol High版の方が数値追跡と判断条件を厚くした |
| 言えない範囲 | Sol Highが常に優れる、またはSol Mediumでは不足するという一般結論 |
特に重要なのは、Terra / high 対 Sol / high はモデル差の観察であり、推論レベル差の実験ではないことである。Sol Mediumを次候補にする判断は妥当な仮説だが、今回の結果そのものではない。
第4章 記事186で観察できた違い
4.1 Terra Highは、概念を圧縮して読みやすくした
Terra High版は、原価計算を「資源消費を、製品・工程・期間へ関係付ける仕組み」として短くまとめた。章ごとの密度が高すぎず、初学者が全体像をつかみやすい。既存の簿記記事との接続も明示されており、シリーズとして読む読者には親切である。
特に、次のような注意は適切に入っていた。
製造原価報告書は仕掛品の相手勘定ではなく、計算過程を示す資料である。
原価は価値や販売価格そのものではない。
詳細な原価計算制度がないことと、在庫評価が不要なことは違う。
「工場版の複式簿記」は教育上の比喩であり、歴史的な発生順序を断定する表現ではない。
ファンデーションで見ると、F1問題表現とF5不確実性管理は十分に機能していた。一方、F3関係統合とF6根拠追跡は、読みやすさを優先した分だけ簡潔であった。
4.2 Sol Highは、途中の論理を数値で検証可能にした
Sol High版の違いは、同じ概念をより多く説明したことではない。原価の流れを二つの在庫計算へ分け、読者が数字を追える形にした点にある。
> 期首仕掛品10 + 当期製造費用120 - 期末仕掛品30 = 当期製品製造原価100
> 期首製品15 + 当期製品製造原価100 - 期末製品25 = 売上原価90
この二つを連続させると、当期製品製造原価100は二重に発生した費用ではなく、仕掛品から製品へ移る中継額だと確認できる。さらに、売上高150から売上原価90を引けば、売上総利益60までつながる。
これは会計上の数式を増やすための説明ではない。「数字がどの状態にあるか」を読者自身が検算できるようにする説明である。ファンデーションでは、F2分解、F3関係統合、F4制約整合、F6根拠追跡・検証が表れている。
4.3 実務上の判断条件にも差が出た
Sol High版では、簡易な原価計算方法を採る場合に、少なくとも次の四点を決めるべきだと整理した。
何を簡略化するのか
どの目的に使う数値なのか
どの程度の誤差を許容するのか
どの変化が起きたら見直すのか
また、製品構成や工程の変化、共通費の増加、在庫額の重要性、製品別採算との乖離などを、簡易法を見直す兆候として示した。これはF1問題表現を「説明する」から「判断に使う」へ拡張し、F5不確実性管理を実務条件へ落としたものと評価できる。
反対に、Terra High版は説明を簡潔に保つ分、数値の連続性や見直し条件は薄くなった。これは誤りではなく、読みやすさと説明の深さの配分の違いである。
4.4 10観点の比較マトリックス
個別の説明だけでは全体差を見渡しにくいため、F1からF7までの推論品質に、実務への接続、初学者向けの読みやすさ、既存シリーズとの接続を加えた10観点で整理する。各欄は実際の二つの記事に書かれた内容を比較した結果であり、モデル一般の能力順位を示すものではない。
| 比較観点 | Terra High版の結果 | Sol High版の結果 | 今回の比較判断 |
|---|---|---|---|
| 1. F1 問題表現 | 原価計算を、支出を原価対象・期間損益・棚卸資産へ測定・配分する仕組みと定義し、読者の主要な疑問を明確にした | 同じ問題設定に加え、測定規則、利用目的、会計の解像度まで中心課題へ含めた | 両者とも十分。実務判断まで問題へ含めた点でSol Highがやや広い |
| 2. F2 概念分解 | 支出、原価、棚卸資産、費用、報告書を分け、出来事・測定・帰属・表示の四つの質問へ整理した | 支出、原価、資産、費用、価値を分け、事実・評価・帰属・配賦、さらに五つの確認質問へ分解した | Terra Highは簡潔。Sol Highは分解の粒度が一段細かい |
| 3. F3 関係統合 | 資源消費から仕掛品、製品、売上原価への流れと、製造原価報告書・B/S・P/Lの役割を概念的につないだ | 仕掛品と製品の二つの在庫計算を、当期製品製造原価100という同一中継額で接続した | Sol Highの方が、概念間の接続を数値でも確認しやすい |
| 4. F4 数値・制約整合 | 当期製品製造原価1,000万円、期末製品200万円、売上原価800万円という簡潔な例を、期首製品等を省く前提付きで示した | 期首仕掛品10から売上原価90、売上総利益60まで一つの数値例を通し、二重計上でないことも説明した | 両者とも矛盾はない。検算可能性はSol Highが強い |
| 5. F5 境界条件・不確実性 | 原価と価値、制度の有無と在庫評価、比喩と歴史的事実、個社適用の限界を明確にした | 同じ境界に加え、売価評価の思考実験、異なる測定規則、簡易法の見直し条件まで示した | 両者とも強い。Sol Highは適用条件と例外の範囲が広い |
| 6. F6 根拠追跡・検証 | 原価計算基準と棚卸資産会計基準を示し、基本例と記事177〜179への接続から説明を追える | 同じ一次資料に加え、会計史研究と連続数値例を示し、主張と計算の両方を追える | 出典と数値を一緒に検証できる点でSol Highが強い |
| 7. F7 自己点検 | 断定回避や前提の明示は確認できるが、生成途中の反例確認や修正記録は記事本文からは判定できない | 反例、適用外、簡易法の限界は多いが、生成途中の自己点検記録は記事本文からは判定できない | 両者とも成果物上は一部確認。自己点検能力そのものは判定保留 |
| 8. 実務への接続 | 出来事・測定・帰属・表示の四質問と、財務報告・価格・改善の利用目的を示した | 簡略化範囲、利用目的、許容誤差、見直し条件に加え、制度を見直す五つの兆候を示した | 日常の読み方はTerra Highで十分。制度見直しまで使うならSol Highが強い |
| 9. 初学者向けの読みやすさ | 説明を圧縮し、章ごとの問いと一段階の数値例で全体像を追いやすくした | 二段階計算、測定規則、思考実験、見直し兆候まで含むため情報量が多い | 初読の負担はTerra Highが小さい。深く検証する読者にはSol Highが向く |
| 10. 既存シリーズとの接続 | 想定読者、本文、参考資料で記事177〜179を明示し、本記事が加える「目的の層」を説明した | 勘定連絡図との関係は本文にあるが、記事177〜179との明示的な接続は置いていない | シリーズ記事としてはTerra Highが明確。Sol Highは単独記事としての完結性が高い |
この表から、Sol HighはF2からF6と実務判断で説明を深くし、Terra Highは初読のしやすさとシリーズ内の位置付けで優れていたと読める。どちらも記事の中心命題を外しておらず、用途によって強みが異なる。
F7自己点検は、完成原稿だけから断定しにくい。最終文に誤りが少ないことと、生成途中で反例や漏れを能動的に点検したことは同じではない。次回は、確認表への回答や修正履歴を残して評価する必要がある。
なお、DOCXの番号、リンク、改ページなどはこの比較表へ入れていない。Sol High版は後から作成され、品質確認工程も改善されていたため、組版差をモデル差として扱うと比較が不公平になるからである。DOCX品質は第8章の運用品質ゲートで別に確認する。
第5章 この記事を難しいと判断した理由
5.1 難しさは、専門用語の数ではない
記事186は、LWPの記事群の中でも難易度5段階の4、すなわち最も難しい部類と判断した。ただし、唯一の正解を数学的に証明する問題ではなく、単一の原案から作る記事であるため、最上位の5とは区別した。
難易度を上げたのは、次の作業が同時に必要だったからである。
長い検討記録から、重複、仮説、修正を整理する。
支出、資源消費、棚卸資産、費用、測定、配賦、表示を分ける。
仕掛品と製品という二段階の在庫計算を矛盾なくつなぐ。
原価と価値、詳細制度と最低限の評価を区別する。
財務報告と価格・管理・改善という複数の利用目的を接続する。
複式簿記との比喩を、歴史的因果の断定にしない。
既存の簿記記事と重複させず、シリーズ内の位置を決める。
これは、F1からF6までを同時に要求する仕事である。一つひとつは説明できても、順序を誤ると全体が崩れる。長文だから難しいのではなく、依存関係の多い説明を、矛盾なく再構成するから難しい。
5.2 タスク自体の難しさと、モデルにとっての難しさは同じではない
同じ題材でも、入力の状態によって必要な設定は変わる。
| 入力の状態 | 主な負荷 |
|---|---|
| 章立て、主張、数値例、注意事項が確定 | 文章化と編集が中心 |
| 論点はあるが、順序と関係が未整理 | F2分解とF3関係統合が中心 |
| 仮説、反論、未確認事項が混在 | F1問題表現、F4制約整合、F5不確実性管理が中心 |
| 数値やコードを検算する必要がある | F4制約整合、F6根拠追跡、F7自己点検が中心 |
したがって、「会計記事だからSol High」と決めるのではない。入力が整理され、合格条件が明確なら、同じ会計記事でもTerra MediumやSol Mediumで足りる可能性がある。
第6章 モデル、推論レベル、工程のどこを変えるか
6.1 失敗を三種類に分ける
現行版では、モデルを上げる失敗と推論レベルを上げる失敗を二分していた。しかし、実務では第三の選択肢として、プロンプトや検査工程を直す必要がある。
| 観察された失敗 | 最初に変える候補 | 理由 |
|---|---|---|
| 問い、読者、複数資料の関係を取り違える | より強いモデル | F1・F3の把握と統合が不足している可能性がある |
| 大筋は正しいが、例外、検算、反例確認が浅い | 推論レベルを一段上げる | F5・F6・F7へ使う探索量が不足している可能性がある |
| 指示が曖昧で、モデルごとに章立てが変わる | 入力とプロンプトを固定する | 比較条件がそろっていない |
| リンク、番号、改ページ、表の分断が壊れる | 変換・検査工程を直す | 推論能力ではなく運用品質の問題である |
| 読みやすいが論点が欠ける | 評価表と合格条件を追加する | 編集品質だけで合格させている |
モデルを上げる前に、どの層で失敗したかを特定する。そうしないと、組版の不具合に高性能モデルを投入するような、効果の薄い対応になる。
6.2 モデルと推論レベルを、内部構造の断定として説明しない
「モデルは理解力、推論レベルは考える長さ」と単純化すると分かりやすいが、厳密な内部説明ではない。外部から確認できるのは、設定を変えたときに成果物の成功率、完全性、根拠、所要量などがどう変わったかである。
したがって、実務では次のように扱う。
モデルは、同じ課題に対する能力・速度・コスト特性の異なる候補として比較する。
推論レベルは、同じモデル内で品質と計算量の釣り合いを調整する設定として比較する。
どちらも名称や印象で決めず、代表タスクの合格率と運用コストで決める。
第7章 実務で使う選定手順
7.1 最初の候補を決める
日常の入口は、次のように置ける。
| 仕事の性質 | 最初の候補 | 判定の考え方 |
|---|---|---|
| 大量・定型・機械的に確認可能 | Luna / low | 失敗を自動検出しやすい |
| 通常の作成・調査・修正 | Terra / medium | 品質と利用量の均衡を取る |
| 難しく重要で、初回失敗の修正費用が大きい | Sol / high | まず品質上限を確認する |
これは固定ルールではなく、比較を始めるための候補である。OpenAIのモデル案内では、medium はバランスの取れた開始点とされ、high 以上は代表タスクで品質向上を測れた場合に使う考え方が示されている。そのため、Sol Highを永続的な標準にするには、Sol Mediumとの差を測る必要がある。
7.2 記事186に対する現時点の判断
今回の記事186については、二つの判断を分ける。
| 判断の目的 | 現時点の候補 | 根拠 |
|---|---|---|
| 品質優先で最初の基準稿を作る | Sol / high | 今回の一例で、数値追跡と判断条件が最も厚かった |
| 日常運用の標準を決める | Sol / mediumを次に試す | Highの上積みが必要かは未検証 |
| 文章化工程を安価にする | Sol / lowまたはTerra / mediumを後で試す | 構成・数値・合格条件を固定した後なら候補になる |
したがって、「難しい記事だから常にSol High」ではない。Sol Highは品質上限を作る基準であり、運用標準はSol Mediumが同じ合格条件を通過するかで決める。
7.3 次の検証はSol Mediumから始める
次回は、Sol High版とSol Medium版を次の条件で比較する。
同じ入力Markdownを使う。
同じプロンプト、文字数目安、読者、記事様式を使う。
利用できる資料とツールをそろえる。
生成順の影響を減らすため、可能なら順序を入れ替える。
各設定を複数回試し、偶然の一例で決めない。
モデル名を伏せて成果物を評価できるなら、先入観を減らす。
本文評価とDOCX評価を分ける。
OpenAIの案内でも、現在の設定と一段低い推論レベルを代表タスクで比較し、タスク成功、回答の完全性、必要な根拠、利用量、待ち時間、コストなどを測る考え方が示されている。記事制作では、さらに修正回数と編集時間を加える。
7.4 合格表を先に固定する
比較後に都合よく評価軸を変えないよう、次の合格条件を生成前に固定する。
| 区分 | 合格条件 |
|---|---|
| F1 問題表現 | 原価計算を単なる集計ではなく、資源消費と利用目的の関係として説明する |
| F2 分解 | 支出、原価、資産、費用、賦課、配賦を区別する |
| F3 関係統合 | 仕掛品から製品、売上原価までを一つの流れとしてつなぐ |
| F4 制約整合 | 二段階の在庫計算に二重計上や数値矛盾がない |
| F5 不確実性管理 | 比喩、簡易法、一般化の限界を明示する |
| F6 根拠追跡・検証 | 読者が数値例を再計算でき、出典を確認できる |
| F7 自己点検 | 論点漏れ、反例、適用外を確認した記録がある |
| 編集品質 | 初学者向けの順序、用語導入、シリーズ接続がある |
| 運用品質 | DOCXに番号崩れ、リンク残骸、表切れ、文字化けがない |
合計点が高くても、F4の数値矛盾やF5の重大な断定があれば不合格とする。記事の目的上、重大項目は平均点で相殺しない。
第8章 比較を再利用できる運用に変える
8.1 一回の比較で終わらせない
一つの成功例だけで「常にSol High」と決めるのは早い。比較対象を三種類ほどに増やすと、選定基準が安定する。
長い検討メモから概念記事を作る仕事
複数資料を統合して仕様書を作る仕事
数式・コード・データ検証を含む技術記事を作る仕事
各題材で、F1からF7、編集品質、運用品質、修正回数、作業時間、利用量を記録する。モデル名や推論レベルだけでなく、入力の整理度と品質確認の工程も残すことが重要である。
8.2 品質確認はモデル比較とは別に固定する
今回、DOCXの仕上がりには、モデルだけでなく品質確認の順序も影響した。番号付きリストが独立した節をまたいで連番になる、Markdown形式のリンクがそのまま表示される、といった問題は、本文の推論品質とは別の工程で検出できる。
したがって、モデルを変えても次の検査は共通にする。
Markdownの見出し階層、表、リンク、文字化けを確認する。
DOCXのタイトル、ライセンス、主要見出し、参照リンクを読戻す。
全ページを見て、番号、改ページ、表の分断、Markdown残骸を確認する。
本文の論点確認と、組版・表示確認を別のゲートにする。
高性能モデルを使っても検査工程を省略できるわけではない。モデル選定は品質管理の代替ではなく、品質管理で直す量を減らす手段である。
まとめ 指標は推論・編集・運用の三層に分けて使う
従来の記事186比較は、推論力のファンデーションを全く見ていなかったわけではない。概念の階層分離、数値の追跡性、境界条件は、F2からF6を測る有効な指標だった。
一方で、問題表現、分解、制約整合、自己点検が独立しておらず、読みやすさ、シリーズ接続、DOCX品質が同じ表に混在していた。このままでは、結果が良かった理由と、失敗時に変えるべき場所を特定しにくい。
再構成後の判断は、次のとおりである。
推論品質は、F1問題表現からF7自己点検までで評価する。
読みやすさとシリーズ接続は、編集品質として別に評価する。
DOCX、リンク、所要時間、利用量、修正回数は、運用品質として別に評価する。
今回確認できたのは、同じ high におけるTerraとSolの一例の差である。
品質優先の基準稿にはSol Highが有力だが、運用標準はSol Mediumとの比較後に決める。
Sol LowやTerra Mediumは、構成・数値・合格条件を固定した文章化工程で検証する。
モデル選択の目的は、最も強いモデルを常に使うことではない。仕事のどの基礎能力が壊れやすいかを特定し、その箇所へ必要なモデル能力、推論レベル、検査工程を配分することである。
参考資料
OpenAI, [Model guidance](https://developers.openai.com/api/docs/guides/latest-model)（2026年8月22日確認）
OpenAI, [Models](https://developers.openai.com/api/docs/models)（2026年8月22日確認）
出典メモ
本記事は、同一の原価計算に関するMarkdown原案から作成した記事186のTerra High版とSol High版、および両者を比較した検証記録を素材としている。比較対象は単一ケースであり、全ての題材・指示・作業環境に一般化できる統計的評価ではない。
モデルの位置づけと推論レベルの比較方針は、OpenAIの公式ドキュメントを2026年8月22日に確認した。本記事の七つの「推論力のファンデーション」と、Sol Highを品質優先の基準稿に使う判断は、OpenAIが公開したモデル内部の公式分類ではなく、今回の実測結果とLWP記事作成の品質要件を踏まえた運用上の枠組みである。