本文へスキップ
KNOWLEDGE — AI NEWS
OpenAI｜AIの費用対効果はモデルより仕組み
OpenAIが2026年7月31日、AIの価格と成果の捉え方をまとめた文章を公式サイトで公開しました。モデルを変えずに周辺の仕組みだけを改善したところ、ARC-AGI-3という公開課題での得点が13.3%から38.3%へ上がったと記載されています。上位モデルへの乗り換えに手をつける前に、自社のAI運用のどこに無駄があるかを確かめる手順を整理します。
Summary
この記事の要点
今回の文章は事業戦略の説明が中心ですが、AIを業務に使う側にとって実務的な指摘が3つ含まれています。値下げそのものの読み方はGPT-5.6の値下げに関する記事で扱っているため、本記事では扱いを分けます。
成果はトークン単価ではなく「成功1件あたりのコスト」で測る
OpenAIは、顧客が買っているのはトークンではなく成果であり、正しい尺度は「成功した成果あたりのコスト」だと記載しています。そこには所要時間、やり直し、人による監督、誤りの分も含まれます。単価表だけを見比べても、実際にかかる費用は分かりません。
モデルを据え置いたまま、周辺の仕組みで得点が約3倍になった例が示された
ARC-AGI-3の公開課題で、GPT-5.6 Solの得点が13.3%から38.3%へ上がり、出力トークンは6分の1になったとOpenAI公式サイトに記載されています。変わったのはモデルではなく、推論の保持とコンテキスト管理という周辺の仕組みです。
「安いモデルに落とす」「上位モデルに上げる」以外の打ち手がある
精度が足りないときの対処はモデルの変更だけではありません。何を渡すか、どこで区切るか、どの工程に振り分けるかという設計が成果を左右します。これは自社側で手を入れられる範囲です。
Basics
前提：「モデル」と「モデルの周りの仕組み」は別物
今回の話を読むには、AIの出力が何によって決まるかを分けて考える必要があります。多くの現場では「どのモデルを使うか」だけが検討されますが、実際には次の4つが結果を左右します。
| 要素 | 意味 | 実務での意味合い |
|---|---|---|
| トークン | モデルが文章を処理するときの最小単位。単語より細かく区切られる | API利用料はトークン数で決まる。渡す量・返る量がそのまま費用になる |
| モデル | 文章を生成する本体。GPT-5.6 Luna／Terra／Solのような単位で選ぶ | ベンダーが決める。利用側は選ぶことしかできない |
| コンテキスト管理 | 1回のやり取りで何をモデルに渡し、何を渡さないかの設計 | 利用側が決められる。渡す量がそのまま入力の課金になる |
| 推論の保持 | 複数回のやり取りにまたがって、前に考えた内容を持ち越す仕組み | 同じ検討を毎回やり直させると、出力トークンと待ち時間が増える |
| ルーティング | どの作業をどのモデル・どの設定に振り分けるかの割り当て | 利用側が決められる。全部を上位モデルで回すと費用が膨らむ |
このうち利用側が手を入れられるのは下の3つです。つまり「うちのAIは精度が低い」という状態の原因は、モデルではなく渡し方や振り分けにあることが珍しくありません。生成AIを業務へ組み込む全体像は生成AIのEC活用で整理しています。
Announcement
公式発表の要点
OpenAIは2026年7月31日、公式サイトに「Building abundant intelligence」と題した文章を公開しました（出典: OpenAI公式サイト）。インフラ投資とモデル提供の考え方を説明したもので、業務利用に関係する記載は次のとおりです。
| 項目 | 公式に記載されている内容 |
|---|---|
| 公開日・主体 | 2026年7月31日、OpenAI（同社CFOのSarah Friar名義） |
| 評価の尺度 | 顧客はトークンを買っているのではない。正しい尺度は「成功した成果あたりのコスト」で、所要時間・やり直し・監督・誤りを含む |
| 周辺の仕組みによる改善 | ARC-AGI-3の公開課題で、推論の保持とコンテキスト管理の改善によりGPT-5.6 Solの得点が13.3%から38.3%へ向上し、出力トークンは6分の1になった。モデル自体は変えていない |
| 自社基盤の効率化 | GPT-5.6 Solが技術チームとともにモデル提供用の本番ソフトの最適化を支援し、提供にかかる全体の費用が20%減少。生成の内部処理（投機的デコーディング）の改善でトークン生成効率が15%以上向上 |
| 社内のエージェント利用 | OpenAI社内では、同社の開発支援ツールCodexを通じたエージェントによる作業が週あたりの出力トークンの99.8%を占める |
なお、同じ文章にはGPT-5.6の値下げについての記載もありますが、単価の読み方はGPT-5.6の値下げに関する記事で扱っているため本記事では繰り返しません。あわせて、モデルと工程の関係についても記載があります。問うべきは「どのモデルがどの作業に属するか」ではありません。その成果にどれだけの知能が必要か、どれだけ速く必要か、いくらで実現すべきかである、という整理です。その配分は同じ業務の中でも何度か変わりうる、とも書かれています。強いモデルが一度で正しく終えるほうが、安いモデルで何度もやり直すより結果的に安くつく場合がある、とも書かれています。
Analysis
セルフプラスの見解 — 「精度が出ない＝モデルが弱い」ではない
ここからは公式発表を踏まえたセルフプラスの分析で、事実の要約とは分けて記載します。今回の文章はOpenAIの投資戦略の説明が主目的です。ただしEC事業者や社内のWeb担当者にとっては、AIがうまく動かないときの原因の切り分け方として読む価値があると考えています。
1. 「モデルを上げる」の前に確認すべき打ち手がある
AIの出力が期待に届かないとき、現場でまず出る案は「上位モデルに変える」です。しかし上位モデルへの変更は費用が増える一方で、原因がモデルになければ結果は変わりません。今回示されたARC-AGI-3の例は、モデルを固定したまま周辺の仕組みだけで得点が上がった事例です。同じ考え方は自社でも使えます。
EC実務でよくある不満と、その原因がどちらにありやすいかを整理すると次のようになります。
| よくある不満 | 原因がモデル側にある場合 | 原因が仕組み側にある場合 |
|---|---|---|
| 商品説明文に事実と違う仕様が混ざる | 推論そのものを誤っている | 商品マスタを渡しておらず、モデルが一般知識で補っている |
| 返答のトーンが毎回ぶれる | 指示への追従性が低い | トーンの基準を口頭で伝えており、渡す資料に含めていない |
| 長い問い合わせ履歴で前半を無視する | 長文の扱いが不得手 | 履歴を要約せずに渡し、判断に不要な部分が大半を占めている |
| 同じ質問に毎回ゼロから答え直す | — | 前回の検討結果を持ち越す設計になっていない |
右列に当てはまるなら、モデルを変えても改善しません。生成AI業務効率化の現場でも、精度の相談の多くはこの切り分けから始まります。
2. 「成功1件あたりのコスト」を出すと、判断が変わる
OpenAIが示した尺度をEC実務に落とすと、比べるべきは単価ではなく「使える成果物が1つできるまでにかかった総額」になります。ここには人の確認時間も入ります。日本のEC事業者では、担当者の人件費がAPI費用を上回る例もあり、この違いは無視できません。
| 比較の仕方 | 見えるもの | 見落とすもの |
|---|---|---|
| トークン単価で比べる | モデルごとの料金表の差 | やり直しの回数、人の確認時間、公開後の修正 |
| 成功1件あたりで比べる | 使える成果物1件までの総額と所要時間 | —（ただし計測の手間はかかる） |
例えば商品説明文の生成で、安いモデルなら1件あたりのAPI費用は下がっても、3回書き直して担当者が15分確認しているなら、成功1件あたりでは高い可能性があります。逆に、公開前に人が全件読む前提の下書きなら、多少粗くても安いモデルで数を出すほうが合理的です。どちらが正しいかは工程ごとに違います。
3. コンテキスト管理は、EC事業者にとっては「渡す資料の設計」
コンテキスト管理という言葉は技術的に聞こえますが、実態は「AIに毎回何を見せるかを決めること」です。APIを直接使っていない事業者でも、指示文の中に何を書くかという形で同じことをしています。
| 場面 | 避けたい渡し方 | 望ましい渡し方 |
|---|---|---|
| 商品説明文の生成 | 「この商品の説明文を書いて」とだけ指示し、商品名だけ渡す | 素材・サイズ・使用シーン・禁止表現・既存商品の文例を、毎回同じ順序と項目で渡す |
| 問い合わせの一次返信 | 過去のやり取り全文をそのまま貼る | 顧客の要望・注文番号・対応履歴の要点だけを抜き出して渡す |
| レビューの要約 | 1件ずつ個別に依頼し、前の分析結果は渡さない | 分類の基準を固定し、前回までの分類結果を添えて一貫性を保つ |
右列は特別なツールを必要としません。多くはテンプレートの整備で足ります。AIエージェントとして業務へ組み込む段階の進め方はAIエージェント一括支援で扱っています。
カート別に見ると、渡す情報の置き場所はすでに手元にあります。Shopifyであれば商品メタフィールド、ecforceであれば商品マスタの各項目が、そのまま「毎回同じ形で渡す項目」になります。新しいツールを導入する前に、いま商品データのどの欄に何が入っていて、どこが空のままかを確認するほうが先です。カート別の進め方はShopifyのAIコマース対応支援とecforceのAIコマース・AI活用支援で扱っています。
4. 「社内の99.8%」は、そのまま自社の目標にはならない
OpenAI社内でCodex経由のエージェント作業が週あたり出力トークンの99.8%を占めるという数字は、AI企業がソフトウェア開発を中心に業務を行っている環境での値です。EC事業者の業務は、仕入れ交渉、撮影、梱包、電話対応など、AIに渡せない工程が相当量を占めます。この数字を社内の目標値として掲げると、達成しようがない前提で人を動かすことになります。
参考にすべきは比率ではなく、「1つの工程で成果が出たら隣の工程へ広げる」という進み方のほうです。
示された数値はOpenAIが自社で測ったものです
ARC-AGI-3での13.3%から38.3%への向上、出力トークン6分の1、提供コスト20%減、トークン生成効率15%以上向上。これらの数値は、いずれもOpenAIが自社の環境で測定し、自社の文章で公表したものです。第三者による検証結果ではありません。また、ARC-AGI-3で測られる課題と、日本語の商品データを扱う作業や薬機法・景品表示法の観点での表現判断とは、性質が異なります。「仕組みを直せば3倍になる」と自社に当てはめるのではなく、「モデル以外にも成果を動かす余地がある」という方向性として読むのが妥当だと考えています。
Action
明日から何をすべきか
新しいモデルへの乗り換えは急ぎません。やるべきは、自社のAI利用のどこに無駄があるかを見える形にすることです。3つとも、使っているツールやモデルが変わっても使えます。
いちばん回数の多いAI作業を1つ選び、成功1件あたりのコストを出す
商品説明文の生成でも、問い合わせの下書きでも構いません。1週間分について「何件依頼したか」「使えた成果物は何件か」「担当者が確認と修正に何分かけたか」を記録します。API費用に人件費を足して使えた件数で割れば、成功1件あたりのコストが出ます。これが以降すべての判断の基準になります。
失敗した出力を、モデルのせいと仕組みのせいに仕分ける
使えなかった成果物を10件集め、「そもそもAIに渡していない情報が原因か」「渡しているのに誤ったのか」で分けます。前者が多ければ渡す資料の整備が先です。後者が多ければモデルや設定の見直しが要ります。この仕分けをせずにモデルを変えても、費用だけが増えます。
指示文をテンプレート化し、渡す項目を固定する
担当者ごとに書き方が違う状態では、結果のばらつきがモデルのせいなのか指示のせいなのか判別できません。渡す項目と順序を決めた雛形を1つ作り、全員がそれを使う状態にします。作るのに数時間で、以降は結果の比較ができるようになります。
同じ7月31日に出たxAIの発表はGrok Imagineの参照機能に関する記事で、同じ時期のモデル側の動きはClaude Opus 5の記事で扱っています。AI経由の購買が広がる流れ全体はAIコマースにまとめています。
FAQ
この発表に関するよくあるご質問
「成功1件あたりのコスト」はどうやって測ればよいですか。
1週間分について、依頼した件数、実際に使えた成果物の件数、担当者が確認と修正に使った時間を記録します。API費用に人件費を足し、使えた件数で割れば求められます。工程ごとに出すと、どこに無駄があるかが見えます。
モデルを最新のものに変えれば精度は上がりますか。
上がる場合もありますが、それだけとは限りません。OpenAIはARC-AGI-3の公開課題で、モデルを変えずに周辺の仕組みを改善して得点が13.3%から38.3%へ上がった例を挙げています。まず失敗の原因がどちらにあるかを切り分けてください。
コンテキスト管理は専門知識がないと取り組めませんか。
APIを直接使っていない事業者でも取り組めます。AIに渡している資料や指示文を洗い出し、判断に不要なものを外して、必要な情報を毎回同じ形で渡すだけでも結果は変わります。最初は担当者1人・作業1つから始めて構いません。
