GPT-5.6で​AIエージェントの​費用を​下げる​方​法 ──OpenAI公式ガイドを​解説、​同じ​精度が​25分の​1に​なった​条件

OpenAIが2026年8月13日、「The builder's guide to GPT‑5.6」という公式ガイドを公開した。スタートアップが本番環境でGPT-5.6を動かして分かったことを、OpenAI自身がまとめたものだ。

書かれている結論は、一つに絞れる。AIエージェントの費用は、モデルを変えるより「使い方」を変えたほうが下がる。 同じ検索タスクで精度をほぼ落とさないまま、費用が33.27ドルから1.33ドルになった実例が載っている。約25分の1だ。

この記事では、ガイド本文と公式ドキュメントを突き合わせて4点を整理する。①なぜ「最上位モデル×最高設定」が最適解でなくなったのか ②同じ文脈を作り直させない設定 ③判断をモデル、集計をコードに分ける仕組み ④手分けして進めさせる仕組み。最後に、ガイドが触れていないのに請求額へ直結する「キャッシュの課金変更」を取り上げる。

01 何が​公開されたのか──製品発表ではなく、​運用の​知見

公開日は2026年8月13日。OpenAIの「Applied AI」チームが、GPT-5.6を早期テストから本番運用まで持っていったスタートアップと並走して得た知見をまとめている。新しいモデルの発表ではなく、すでに出ているモデルを安く・速く動かすための実践ガイドという位置づけだ。

主張は3つに整理できる。1つ目は、世代を追うごとに少ないトークンで長い仕事をこなせるようになっていること。2つ目は、小さいモデルと低い思考設定でも前世代の最上位に並ぶ場面が増えたこと。3つ目は、API側に新しい部品が入り、組み方しだいで結果が変わることだ。

つまり費用の話でありながら、設計の話になっている。ここが7月末の価格改定（同じGPT-5.6の値下げ）と違う点だ。あちらは単価が下がった知らせで、こちらは同じ単価のまま請求を下げる方法にあたる。

02 ​「最上位モデル×最高設定」は、​もう​最適解ではない

これまでAIエージェントを組むときの定石は、いちばん賢いモデルを選び、思考の深さ（reasoning effort）をいちばん高くすることだった。長い文脈やツール操作を安定してこなせるのが上位モデルだけだったからだ。

ガイドは、この前提が崩れたと書いている。挙がっている実例は3つ。

1つ目はAgents' Last Examという評価で、GPT-5.6 Sol を「low（低い思考設定）」で動かしたほうが、前世代のGPT-5.5を「high」で動かすより成績が良かった。周辺の仕組みは同じ条件での比較だ。2つ目はBrowseComp（見つけにくい事実を検索させる評価）で、3か月前はGPT-5.5（Extra High）が84.36%・33.27ドルだったのに対し、GPT-5.6 Luna（Extra High）は84.04%・1.33ドルだった。3つ目は、文書からの情報抽出を担うHypha社の証言だ。

LunaはGPT-5.5の抽出精度の98%を、18分の1のコストで維持している。これで、高品質な文書理解を、はるかに多くの業務で現実的な価格で使えるようになった。

思考の深さは none / low / medium / high / xhigh / max の6段階から選べる。既定はmediumで、上げれば良くなるとは限らない——今回いちばん実務に効くのはこの一行だ。深く考えさせるほど出力トークンが増え、費用も待ち時間も伸びる。

現在のAPI料金（100万トークンあたり）を並べると、モデル選択の重みが分かる。

モデル	入力	キャッシュ入力	出力	位置づけ
GPT-5.6 Sol	$5.00	$0.50	$30.00	複雑な推論・コーディング向けの最上位
GPT-5.6 Terra	$2.00	$0.20	$12.00	知能とコストのバランス型
GPT-5.6 Luna	$0.20	$0.02	$1.20	大量処理・コスト重視

SolとLunaは入力・出力とも25倍の開きがある。ガイドが勧めるのは、全工程を最上位でまかなうのをやめること。たとえば手書きメモを読み取ってから分析する業務なら、読み取りだけをLunaやTerraに寄せる。それだけで請求は目に見えて変わる。

もう一つ、単価表に出てこない条件がある。3モデルとも扱える文脈の上限は105万トークンだが、入力が27.2万トークンを超えたリクエストは、そのリクエスト全体が入力2倍・出力1.5倍で課金される（公式モデルページに明記）。長い履歴をそのまま投げ続ける設計は、単価表の見た目より高くつく。

03 同じ​文脈を、​毎回​作り直させない​──推論の​持ち越しと​compaction

長く続く作業ほど、AIは「これまでの経緯」を持ち回る必要がある。ここで無駄が出る。会話が伸びるたびに全部を読み直させれば、入力トークンは膨らみ続ける。

GPT-5.6では、この対策として2つの仕組みがResponses API（OpenAIのAPIのうち、対話や道具の呼び出しを扱う窓口）に入った。推論の持ち越し——考えた内容をターンをまたいで保持する仕組みと、compaction——長くなった会話を圧縮する仕組みだ。後者は context_management の compact_threshold に閾値を設定しておくと、トークン数がその値を超えた時点でサーバー側が自動で畳む。別途の呼び出しは要らない。

ガイドが挙げる実例は、ARC-AGI-3（AIの汎用的な問題解決力を測る評価）だ。標準構成のGPT-5.6 Solが13.3%だったのに対し、推論の持ち越しとcompactionを有効にすると38.3%まで上がり、しかも出力トークンは約6分の1になったという。モデルは同じで、周辺の設定だけを変えた結果だ。

ただしこの38.3%には注釈が要る。ARC-AGI-3を運営する側の検証では同じ構成の結果が30.2%と報告されており、OpenAI側の数値は自社が回した公開セットに基づく。土俵の違う数字が並んでいる状態で、その経緯は別記事で扱った。

関連記事 ｜ 同じ38.3%をめぐる検証ARC-AGI-3のスコアが設定2つで3倍になった ──OpenAIの検証と、ARC側の反論を解説 →

04 判断は​モデルに、​集計は​コードに​──Programmatic Tool Calling

エージェントの仕事は、大きく2種類に分かれる。判断が要る仕事と、データを運んで並べ替えるだけの仕事だ。

100件の書類を取得して日付で絞り込み、該当する取引を拾う。この過程をすべてモデルに読ませると、中間結果が文脈を食いつぶす。Programmatic Tool Calling は、この部分をモデル自身に書かせたJavaScriptで処理させる仕組みだ。道具の呼び出しを並列に走らせ、結果の加工は文脈の外で行い、モデルには判断だけを残す。

金融リサーチのRogo社は、この仕組みを使って同じ品質基準を満たしながら入力トークンが21%減ったと述べている。

「モデルにコードを書かせて実行させる」と聞くと身構えるが、実行環境は先に閉じてある。公式ドキュメントによれば、生成されたプログラムは毎回まっさらな隔離V8ランタイムで動き、Node.jsもパッケージ導入も直接のネットワークアクセスもない。ファイルシステムもサブプロセスもコンソールもなく、実行と実行のあいだで状態は残らない。外部とやり取りできるのは、そのリクエストで許可した道具の経由だけだ。

逆に言えば、使いどころは限られる。公式は「1回の呼び出しで済む」「結果ごとに新しい判断が要る」「承認や引用の保持が必要」な場面では、従来どおり直接呼び出すほうがよいと明記している。絞り込み・突き合わせ・重複除去のように、手順が読めていて結果を小さくできる工程に向く。

05 手分けして​進めさせる​──Multi-agentは​まだ​ベータ

分割できる仕事では、親のエージェントが子（サブエージェント）に割り振り、並行して進めさせて最後に統合したほうが速い。GPT-5.6のResponses APIは、この分業を標準の機能として持つようになった。ChatGPTの「ultra」設定も、内部的には同じ仕組みだという。

実務で押さえる点は3つある。1つ目はまだベータであること。GPT-5.6の全モデルで使えるが、専用のヘッダを付ける必要があり、項目の形式は変わりうると公式が明記している。2つ目は同時に動く子の数が既定で3体で、max_concurrent_subagents で調整すること。APIは上限を設けておらず、木の深さや子の総数にも固定の上限がない。3つ目は、子を呼ぶ条件を指示で寄せられることだ。

上限がないということは、放っておけば請求が伸びる余地もあるということでもある。まずは既定の3体で始め、効果を測ってから広げるのが安全だ。

06 ガイドが​触れていない、​キャッシュの​課金変更

同じ前置き（共通の指示や社内ルールの説明）を毎回送るなら、キャッシュが効けば安くなる。ガイドはここを「保持時間が最低30分に延び、区切り位置を自分で指定できるようになった」と前向きに書いている。実例として、2万9,000トークンの共有プロンプトに区切りと作業空間ごとのキーを足し、キャッシュ未命中の入力を28%減らしたPloy社の証言も載る。

ただし公式ドキュメントを開くと、GPT-5.6以降でキャッシュの挙動そのものが変わっていることが分かる。ガイド本文には出てこない。

挙動	GPT-5.6以降	それ以前のモデル
一致の判定	指定した区切り位置での完全一致	一致する前置きを自動で最大限に再利用
区切り位置の明示指定	できる（暗黙の区切りも併用）	できない（自動のみ）
キャッシュ書き込みの課金	未キャッシュ入力の1.25倍	追加料金なし
保持時間	prompt_cache_options.ttl で30分	モデルごとの最大保持時間

読みどころは3行目と1行目だ。GPT-5.6以降は、区切りより手前にある「いちばん長く一致する部分」への自動フォールバックをしない。つまり旧世代と同じ書き方のまま乗り換えると、以前は当たっていたキャッシュが当たらなくなることがある。そのうえ書き込みには1.25倍の課金が乗る。値下げのつもりが逆に振れる筋道が、仕様として実在する。

対策は素直だ。①変わらない内容（指示・道具の定義・共通の文脈）を先頭にまとめる ②その末尾に区切りを明示する ③同じ前置きを共有するリクエストに同じ prompt_cache_key を付ける。キャッシュの対象になるのは区切りまでで1,024トークン以上のときだけ、という条件も付く。効いているかどうかは、応答に返る cached_tokens と cache_write_tokens で確認できる。

逆に、先頭に日付や利用者名のような毎回変わる文字を置いていると、その後ろ全部が毎回書き直しになる。よくある作りなので、乗り換え前に一度並び順を見ておく価値がある。

07 まとめ：効く​順に、​測りながら

やること	効き方	注意点
思考の深さを下げて試す	費用が下がり、精度が上がることもある	既定はmedium。自分の課題で評価が落ちないか測る
定型作業を小さいモデルへ	最大25倍の単価差	判断が要る工程まで落とさない
持ち越しとcompaction	長い作業でのトークン浪費が減る	効果は課題によって幅がある
集計・絞り込みをコードへ	入力トークンが減る（実例21%減）	実行環境に外部通信はない＝道具経由で設計する
分業させる	並行処理で速くなる	ベータ。同時数は既定3から広げる
キャッシュの区切りとキー	未キャッシュ入力が減る（実例28%減）	GPT-5.6以降は完全一致＋書き込み1.25倍

6つ並べたが、順番には意味がある。上の2つは設定を変えるだけで今日試せる。下の4つは作りに手を入れる話で、効果を測れる状態になっていないと判断できない。

費用を下げる作業は、モデル選びではなく測ることから始まる。どの工程にいくらかかっているかが見えていなければ、思考の深さを一段下げる判断も、モデルを一段下げる判断も下せないからだ。今回のガイドが示したのは、その判断材料が公式から出そろったということでもある。