Claude Code のトークン節約を3週間実測した結果｜1往復は4割安くなり週の費用は横ばい
ot12
Ainova
GPT-6.1 Sol と Opus 5.5 から見える、コーディングAIの未来｜OpenAI と Anthropic が揃って「指示を見直して」と言い始めた
ot12
記事内に広告を含む場合があります
2026年9月22日に Anthropic が Claude Opus 5.5 を、9月29日に OpenAI が GPT-6.1 Sol を公開しました。
両社の公式資料を読むと、どちらも「前のモデルのために足した指示を見直してください」と書いてありました。
片方だけなら、そのモデルの癖の話で終わるでしょう。
ところが、競い合う2社が1週間の間隔で同じ方向を示しているので、コーディングAIの使い方そのものが動いている可能性があります。
とはいえ、公式が書いていることと、そこから先の予想は別のものです。
そのため、この記事では「公式はこう書いている」と「ここから読めること」を、見出しではっきり分けて書く方針にしました。
公式ドキュメントは2026年10月1日に確認しました。
実測は、GPT-6.1 Sol が Codex CLI 0.159.3 で各条件1回、Opus 5.5 が claude.ai で各2回の参考値です。
そこで、この記事では、両社の公式資料から共通点を6つ原文で確かめ、違う点と筆者の実測を挙げたうえで、コーディングAIの未来と、いま変えておくことを解説していきます。
この記事で分かること
- 両社の公式が揃って言い始めた6つのこと（原文つき）と、そうでない違い
- Codex CLI の GPT-6.1 Sol で、AGENTS.md の書き方を変えて比べた実測
- 公式の記述とは分けて書いた、コーディングAIの未来の読み（3つ）
- 今日できる、AGENTS.md・CLAUDE.md の棚卸しチェックリスト
目次
結論：OpenAI と Anthropic の公式が揃って言い始めた6つのこと
ここからは、結論として共通点の6つを先に挙げ、次の章で原文を1つずつ確かめていきます。
先に断っておくと、「指示を減らして」という言い方は筆者の要約でした。
公式の原文にあるのは consider removing（外すことを検討）、revisit（見直す）、dial back（弱める）といった語で、両社とも「減らせ」と一括りには書いていません。
結論：両社に共通する6つ
- 設定は持ち越さず、軽い設定から測る（effort は前のモデルと同じ意味にならない）
- 完了の定義を先に渡す（止まったことを完了とみなさない）
- 「考えて」「テストして」の重ね掛けをやめる（モデルがもともとやることに指示を重ねない）
- 前のモデル用の指示を棚卸しする（AGENTS.md・skills・回避策）
- 細かい手順の指図より、目的を渡す
- 強い言い回し（必ず・絶対）をゆるめる
6つに通じる中身は、細かく命じる指示を減らし、代わりに完了の条件と確かめ方を渡すことです。
ただし、減らすだけの話ではありません。
完了の定義のように、両社が「足して」と言っているものもあります。
| 共通点 | OpenAI の公式 | Anthropic の公式 |
|---|---|---|
| 1 設定は持ち越さない | effort は既定から始め、軽い設定で試す | medium から始め、Opus 5 の設定を持ち越さない |
| 2 完了の定義 | 始める前に完了を定義する | 完了条件を先に示す。報告で止まったら完了とみなさない |
| 3 重ね掛けをやめる | テストを促す指示は過剰なテストになりうる | 「よく考えて」は外すことを検討 |
| 4 棚卸し | skills・AGENTS.md の監査を強く推奨 | 前のモデル用の回避策がまだ要るか再テスト |
| 5 手順より目的 | 細かすぎる指示は結果を妨げうる | 一般的な指示のほうが、手書きの手順より推論が良いことが多い |
| 6 強い言い回し | 強い境界文は真に受けて止まりうる | CRITICAL: You MUST を普通の書き方に |
だから、6つとも「両社が現行モデルについて同じことを言った」とは書けません。
それでも、向きが一致している事実は変わらないので、次の章で原文を並べて確かめましょう。
6つの共通点を、両社の原文で1つずつ確かめる
ここからは、先ほどの6つについて、OpenAI と Anthropic の原文の該当箇所を並べて見ていきます。
各項目は「公式の原文」「両社に共通する点」「筆者が見た限界」の順で書きます。
1. 設定は持ち越さず、軽い設定から測る
1つ目は、両社が現行モデルについてはっきり書いている、effort（考える深さ）の話です。
公式の原文
- OpenAI（Codex のモデルページ）：GPT-6.1 Sol では、クライアントで既定になっている reasoning effort から始める。”Reasoning efforts don’t map exactly between model generations. Try a familiar task at a lower setting and adjust based on the result.”
- OpenAI（モデル選択ガイド）：品質の基準を満たす、いちばん軽い設定を保つ（”keep the lightest setting that meets your quality bar”）
- Anthropic（Opus 5.5 のプロンプトガイド）：medium から始めて明示的に指定し、”test several levels against your own evals rather than carrying over the setting you used on Claude Opus 5″。effort の名前は、モデルが違えば同じ量の思考に対応しない
ただし、OpenAI の API 移行ガイドは「使える範囲で今の effort を保つ」と書いており、持ち越すなとまでは言っていません。
軽い設定から試すよう書いているのは、Codex 向けのモデルページのほうです。
つまり、同じ「高」でも、モデルが替わると意味が変わります。
だから、前のモデルで「高」や「最大」にしていた人ほど、その設定を持ち越さず、既定か軽い設定で同じ作業をやり直して比べましょう。
画面の側も、同じ向きでした。
claude.ai では、Opus 5.5 のエフォートは「中」が、Opus 5 では「高」がおすすめと表示されます。
Codex CLI 0.159.3 で GPT-6.1 Sol を選んだ画面でも、推論レベルは Low が既定でした。
ただし、軽い設定で足りるかは題材で変わるため、一律には決められません。
筆者の題材（1行のバグ修正）では Sol の low と medium は同じ結果でしたが、難しい題材での差は測っていません。
2. 完了の定義を先に渡す
2つ目は、あとの測定にもいちばん響いた、止まり方の話です。
公式の原文
- OpenAI（公式ブログ、GPT-6 Astra について）：Astra は、いつ止まるかに慎重になりうる。最初の実装まで進めて、作業が残っているのにレビューを求めて戻ってくることがある。”it helps to define completion before starting”。実装を動かし、結果を見て、落ちたものを直すところまでを依頼に含める
- OpenAI（同ブログ）：最初の実装のあとレビューのために止まる、という要件は “will pull the model toward an earlier stopping point”（早い停止に引き寄せる）
- Anthropic（Opus 5.5 のプロンプトガイド）：”Treat a text-only end of turn as a report rather than as proof the task is done.”。完了条件を先に示し（”state the completion condition up front”）、自動の続行は “two or three” 回で打ち切る
両社とも、モデルが途中で報告して止まる傾向に触れていました。
そして、対策の中心も同じで、「何が終わりか」を人が先に言葉にすることです。
一方で、手当ての形は違います。
OpenAI は依頼文と AGENTS.md に完了の条件を書き、Anthropic は完了条件を示したうえで、自動の続行に回数の上限を付けます。
完了の定義が効いたかどうかは、次の章で GPT-6.1 Sol について確かめましょう。
3. 「考えて」「テストして」の重ね掛けをやめる
3つ目は、前のモデルの不足を補うために足した指示が、いまは余計になるという話に進みましょう。
公式の原文
- OpenAI（公式ブログ、Astra について）：”Previous models needed encouragement to run tests and check their work. GPT-6 Astra does that on its own, so the same instructions can lead to unnecessary testing.”
- OpenAI（Using GPT-6 のプロンプト例）：元に戻せて影響の小さい変更には、実装をなぞるだけのテストを書かない
- Anthropic（Opus 5.5 のプロンプトガイド）：チャットのシステムプロンプトにある「よく考えてから答えて」は、”consider removing them”（外すことを検討）。Anthropic のテストでは、外すと返答が早く始まり、品質の目立った低下はなかった。thinking を無効にして運用していたときの「推論を書き出せ」は消す
対象は、OpenAI が「テスト」、Anthropic が「考える」で違います。
ただ、どちらも「モデルがもともとやることに、指示を重ねない」という同じ理屈です。
現場で言えば、AGENTS.md の「変更ごとに必ずテストを全部書く」という1行が、1行で済むバグ修正にも網羅テストを書かせる原因になります。
ただし、Anthropic の原文は「外す」ではなく「外すことを検討」です。
公式が言い切っていない以上、外すか残すかは、自分の課題で両方を比べて決めるのが妥当です。
4. 前のモデル用の指示を棚卸しする
前の3つを1つずつ直しても、過去に積んだ指示が残っていれば効果は長続きしません。
そこで4つ目は、指示ファイル全体の見直しです。
公式の原文
- OpenAI（Using GPT-6、Astra について）：Astra は skills や AGENTS.md などのファイルにある指示に敏感になりうる。”We strongly recommend auditing skills and other files accessible to your model for instructions that could influence its behavior.”
- OpenAI（公式ブログ）：AGENTS.md はリポジトリで作業するたびに効くので、”you should frequently revisit each instruction and ask yourself whether it’s still needed”
- Anthropic（Opus 5.5 のプロンプトガイド）：thinking を無効にして運用していたときの回避策は、まだ要るかを再テストする。画像入力のために前のモデル向けに作った補助の仕組みも、”re-test whether you still need” する
“strongly recommend”（強く推奨）は、6つの中で原文がいちばん強い言い方でした。
一方で、Opus 5.5 のプロンプトガイドと共通ガイドには、CLAUDE.md という言葉が出てきません。
したがって、「CLAUDE.md も棚卸しを」というのは公式の記述ではなく、筆者の延長です。
5. 細かい手順の指図より、目的を渡す
棚卸しで何を消すかを決める基準が、5つ目の「手順書をやめる」です。
公式の原文
- OpenAI（公式ブログ、Astra について）：多くの skill は「旅程表やレシピ」のように書かれてきた。モデルが曖昧さを読めるようになったので、”overly specific guidance can now hinder results where it previously helped”
- OpenAI（同ブログ）：編集のたびに文書を全部読ませるのは、文脈を使い切って作業を遅くする。「全部読め」ではなく、場面ごとに指す
- Anthropic（全モデル共通のプロンプトガイド）：”Prefer general instructions over prescriptive steps.”。「よく考えて」のような一般的な指示のほうが、手書きの段階的な計画より推論が良くなることが多い。”Claude’s reasoning frequently exceeds what a human would prescribe.”
OpenAI の公式ブログには、AGENTS.md の悪い例と良い例が載っています。
公式の悪い例
Before every edit, read architecture.md, database.md, and deployment.md.公式の良い例
Use architecture.md for service boundaries, database.md for schema changes, and deployment.md when preparing a deployment.良い例は、読む文書が減ったわけではありません。
「いつ読むか」を場面で指定したので、小さな修正で3つの文書を読まされることがなくなります。
ただし、Anthropic の記述は共通ガイドのもので、Opus 5.5 のページには同じ文がありません。
6. 強い言い回し（必ず・絶対）をゆるめる
最後の6つ目は、ここまでの5つの原因にもなっている、強い言い回しそのものです。
公式の原文
- OpenAI（公式ブログ、Astra について）：以前のモデルが許可なく動いたので強い言葉を足したなら、書き換えを検討する。”Astra could take it too seriously and may stop work where you’d actually be happy for it to continue.”
- Anthropic（全モデル共通のプロンプトガイド、Opus 4.5・4.6 の節）：ツールを呼ばない問題を直すために入れた強い語は、いまのモデルでは呼びすぎになる。”The fix is to dial back any aggressive language.” “CRITICAL: You MUST use this tool when…” は “Use this tool when…” のように普通の書き方に戻す
向きは同じですが、起きる症状は逆です。
OpenAI は「止まりすぎ」、Anthropic は「呼びすぎ」を挙げていて、どちらも強い語に従いすぎる方向の症状になっています。
また、Anthropic の節は Opus 4.5・4.6 向けで、Opus 5.5 を名指ししていません。
そのため、6つの中ではいちばん弱い共通点でしょう。
筆者が測った結果では、「必ず確認を取ること」と書いた AGENTS.md で、GPT-6.1 Sol も変更前に止まりました。
その結果は、次の章に載せました。
違うところ：同じ方向でも、設定や仕様は同じではない
ここからは、共通点が見えたあとに残る、両社の違いを整理していきましょう。
違いを知らないと、片方の記事の設定をもう片方にそのまま持ち込んで外すからです。
| 項目 | OpenAI（GPT-6.1 Sol） | Anthropic（Opus 5.5） |
|---|---|---|
| 公開日 | 2026年9月29日 | 2026年9月22日 |
| API 料金（100万トークンあたり） | 入力 $2・出力 $10 | 入力 $4・出力 $20 |
| 既定の effort | API は medium、Codex CLI 0.159.3 は Low | medium（Opus 5 は high） |
| ツール呼び出し | Responses API が必須（Chat Completions では不可） | tool_choice の any・tool は 400 エラー |
| 指示ファイルの名指し | skills と AGENTS.md を名指し | CLAUDE.md の記述は見当たらない |
| 早い停止への手当て | 完了の定義と、安全な作業の許可を AGENTS.md に書く | 止まり方を名指しするシステムプロンプト。続行は2〜3回で打ち切る |
単価を並べると、GPT-6.1 Sol は Opus 5.5 のちょうど半分でした。
ただし、1回の課題で使うトークン量は両社とも測っていないので、単価だけで安さは決められません。
設定でつまずきやすい点は、次の3つです。
つまずきやすい3点
- effort の既定が画面ごとに違う：GPT-6.1 Sol は公式ドキュメントの例示が medium、Codex CLI 0.159.3 のカタログの既定は Low でした
- 古い CLI では「ChatGPT アカウントでは未対応」と出る：筆者の Mac の Codex CLI 0.146.0 で gpt-6.1-sol を指定すると、このエラーになりました。原因は契約ではなく CLI の版で、0.159.3 に上げると同じログインのまま通りました。公式 changelog は 6.1 Sol の追加を 0.159.1 以降と書いています
- 「考えない」を選ぶ設定が、両社で消えた：OpenAI は none と minimal を非対応にして low から（”GPT-6 Astra and GPT-6.1 Sol do not support
none; uselowinstead.”）。Anthropic は thinking の無効化と budget_tokens が 400 エラーです
3つ目は、指示の書き方ではなく、仕様でそろったことです。
Anthropic のガイドは、思考を減らしたいなら “lower the effort level first”（先に effort を下げる）と書いています。
そのため、「考えさせない」ことでコストを抑える手は、現行モデルでは effort を下げる手に置き換わった、と読めます。
実測：強い指示で止まり、完了の定義で終わり方が変わった
ここからは、公式の記述が実際の作業でどう出るかを、筆者が測った結果で確かめていきましょう。
共通点の2（完了の定義）と6（強い言い回し）に当たる部分です。
GPT-6.1 Sol：Codex CLI 0.159.3 で AGENTS.md を変えて比べた
題材は、「5,000円以上で送料無料」の境界値のバグが1つと、失敗するテストが2件ある、小さな Python のプログラムです。
指示は全回「python3 -m unittest で落ちているテストがある。原因を直して、テストが通る状態にしてください。」で同じにして、変えたのは AGENTS.md だけです。
手元の ~/.codex の設定が混ざらないよう、空の設定ディレクトリで実行しました。
| 条件 | 時間 | 止まって確認を求めたか | テスト結果 |
|---|---|---|---|
| 6.1 Sol・low・AGENTS.md なし | 29秒 | いいえ | 6/6 成功 |
| 6.1 Sol・medium・なし | 29秒 | いいえ | 6/6 成功 |
| gpt-5.5・medium・なし | 54秒 | いいえ | 6/6 成功 |
| 6.1 Sol・medium・強い文 | 26秒 | はい（変更前に確認） | 2件失敗のまま |
| 6.1 Sol・medium・完了の定義 | 24秒 | いいえ | 6/6 成功 |
条件の差は、次の2つの AGENTS.md だけです。
強い文の AGENTS.md（Before）
コードを変更する前に、必ずユーザーに確認を取ること。確認なしに変更してはならない。
必ずテストを全部書くこと。すべての関数・分岐・境界値について網羅的に。
迷ったら必ず質問すること。完了の定義の AGENTS.md（After）
失敗テストの原因を特定し、最小の修正で直す。
`python3 -m unittest -q` が全て通ったら完了。
確認は不要。変更点を2〜3行で報告する。強い文の条件では、モデルは「AGENTS.md の『変更する前に、必ずユーザーに確認を取ること』に従い、まだ変更していません。この内容で修正してよいですか？」と書いて、1行で済む修正を適用しないまま終わりました。
しかも、頼んでいない網羅テストの追加まで、自分で計画に入れていました。
これは共通点の3と6が、同じ1回の実行で重なった形です。
一方で、完了の定義の条件は、確認なしで直して終え、報告も5条件の中でいちばん短くなりました。
強い文の26秒は、修正せずに止まるまでの時間でした。
そのため、この比較で見るべきなのは速さの差ではなく、終わり方の違いです。
Opus 5.5：claude.ai で「中」と Opus 5「高」を比べた
Opus 5.5 側で測ったのは、共通点の1（effort）に当たる部分だけです。
同じ Python の関数修正の課題を、画面のおすすめどおり Opus 5.5「中」と Opus 5「高」で、各2回ずつ送りました。
| 条件 | 平均時間（1回目・2回目） | 挙げた問題点 |
|---|---|---|
| Opus 5.5・中 | 17.8秒（17.3秒・18.3秒） | 3〜4個 |
| Opus 5・高 | 42.6秒（46.0秒・39.2秒） | 6〜7個 |
時間は約2.4倍の差でしたが、仕込んだバグ（+ 1）はどちらも1番目に挙げました。
網羅性は、問題点の数が多い Opus 5「高」が上です。
この結果は、公式の「既定の medium で Opus 5 の high と同等以上」という主張と向きが合います。
ただし、1つの課題を各2回で、回線の影響を含み、Opus 5.5 を「高」にした比較もしていません。
さらに、Opus 5.5 で強い文と完了の定義を比べる実測はしていません。
そのため、共通点の2と6を「両社で実測した」とは言えず、確かめたのは Codex CLI の GPT-6.1 Sol だけでした。
ここから読めるコーディングAIの未来（筆者の読み）
ここからは、公式の記述ではなく、筆者の読みです。
共通点と測定結果から、3つに絞りました。
断定は避けて、根拠と、外れる場合を添えます。
読み1：指示書の中心が「手順」から「完了の定義」に移る
根拠と、外れる場合
- 根拠：共通点の2と5です。両社とも手順書を減らし、完了条件を先に渡せと書き、実測でも完了の定義を書いた条件で確認なしに終わりました
- 外れる場合：難しい題材では、手順の指定がいまも効くかもしれません。OpenAI の原文も「細かすぎる指示は結果を妨げうる（can hinder）」で、「いつも逆効果」とは書いていません
「どう進めるか」はモデルが決められるようになり、人が決めるのは「何ができたら終わりか」になっていく、と読めます。
読み2：指示ファイルは、書き足すものから、定期的に削るものになる
根拠と、外れる場合
- 根拠：共通点の1・4・6です。両社とも前のモデルの設定を持ち越すなと書き、OpenAI は各指示を頻繁に見直すよう書いています
- もう1つの根拠：OpenAI の公式ブログは、リポジトリの skill は他の人のエージェントも読み、別のモデルを使うかもしれないと書いています（”Guidance that helps Sol or Luna may overconstrain GPT-6 Astra”）
- 外れる場合：モデルの入れ替わりが遅くなれば、棚卸しの頻度は下がります
モデルが替わるたびに指示ファイルの棚卸しが要る、定期作業になっていくかもしれません。
読み3：人の確認は、実行前の許可から、結果を見ての承認に移る
根拠と、外れる場合
- 根拠：Using GPT-6は “Prompt the model to ask for approval only after preparing a concrete, reviewable result.” と書き、Anthropic は報告と完了を区別して、続行は2〜3回で人が見る形にしています。実測の強い文の条件も、実行前の確認がそのまま停止になった例です
- 外れる場合：本番環境・課金・外部への送信のような、取り返しのつかない操作の事前確認は残ります。OpenAI の例も、使い捨てのテスト環境で本番に触れない作業に限って許可しています
どこまでを確認なしで任せるかという境界と、結果の確かめ方を先に渡し、人は結果を承認する側に寄っていくのではないでしょうか。
この3つをまとめると、人の役目は「細かく命じる」から「完了の定義・境界・確かめ方を渡す」へ移っていくと読めます。
いまから変えておくこと：AGENTS.md・CLAUDE.md の棚卸しチェックリスト
ここからは、読みが外れても損をしない、小さな見直しだけに絞って手順にしました。
どれも、指示を足すのではなく、見直すだけで済みます。
棚卸しの6手順
- 強い語を探す：AGENTS.md や CLAUDE.md を開き、「必ず」「絶対」「全部」「すべて」を含む行に印を付ける
- 2つに分ける：その行が「いまのモデルが指示なしでやること」か、「止まって確認させたい行為」かで分ける
- 前者は消し、後者は範囲を書く：「ここまでは確認なしでよい」を具体的に書く（例：使い捨てのテストデータだけを使うテストは、確認なしで回してよい）
- 手順を完了の定義に書き換える：「通ったら完了、確認は不要、報告は2〜3行」の形にする
- effort は持ち越さない：前のモデルの設定をそのまま使わず、既定か軽い設定から、同じ作業で比べる
- 1題材で前後を測る：変えたら小さな課題を1つ決めて、時間と止まった回数を before と after で見る
1の探し方は、ターミナルで次の1行で済みます（筆者の作例です）。
grep -nE '必ず|絶対|全部|すべて' AGENTS.md CLAUDE.mdOpenAI の公式ブログは、棚卸し自体をモデルに頼む方法も勧めています（”ask GPT-6 Astra to do an audit based on what was discussed in this article”）。
ただし、モデルに消させた指示は、最後に人が見て決めてください。
消してよいかの判断には、そのリポジトリでの事故の履歴など、モデルが知らない事情が入るからです。
まとめ：公式の共通点6つと、人の役目の読み
ここまでの内容を、最後に短く振り返りましょう。
- OpenAI と Anthropic の公式は、前のモデル用の指示を見直すよう、同じ方向で書いています
- 共通点は、設定の持ち越し・完了の定義・重ね掛け・棚卸し・手順書・強い言い回しの6つです
- 現行モデルを名指しした記述は少なく、多くは Astra や旧世代の記述です。実測で確かめたのも、GPT-6.1 Sol の1題材・各1回です
- 筆者の読みは、人の役目が「細かく命じる」から「完了の定義・境界・確かめ方を渡す」へ移る、というものです
まず手元の AGENTS.md や CLAUDE.md で、「必ず」を含む行を1つ探してみてください。
それが「止まって確認させたい行為」でなければ、完了の定義に書き換えるだけで、動きが変わるかもしれません。
各モデルの個別の変更点は、次の記事に書きました。
- Claude Opus 5.5 の使い方｜公式が「やめて・変えて」と言う8つのこと
- GPT-6.1 Sol の使い方｜OpenAI 公式が「やめて・見直して」と言う8つのことと Codex での切り替え方
- Claude Code のトークン節約を3週間実測した結果（使用量の見方）
※料金・無料枠・商用利用の条件は2026年10月1日時点の情報です。
最新の内容は公式サイトでご確認ください。
