Opus 4.8に難問を解かせてeffortとコンテキスト使用率を確かめてみた
こんにちは。サービス開発室の武田です。
Opus 4.8が出たので、新しいモデルが「自分の頭で考える」タスクでどう振る舞うのか、手元で少し試してみました。題材に選んだのは、Project Eulerの後半にある超高難度問題のひとつです。素朴に総当たりすると計算が終わらない規模で、ある構造に気付かないと現実的な時間では解けない、という種類の問題です。
Claude Codeで、モデルとeffort（思考の深さ）を変えながら、同じ問題を解かせてみました。結果、いくつか予想と違うことが見えてきました。特に「effortを上げれば結果が良くなる」わけではなかった点と、「画面に出るコンテキスト使用率はコストではない」点は、書き残しておきます。
念のためお伝えすると、これは他社モデルとの優劣やベンチマークの順位を論じる記事ではありません。新しいモデルの「手触り」を、ひとつの難しいタスクで確かめてみた記録です。Opus 4.8のスペックや公式の位置付けは、すでに弊社ブログでまとまっているので、そちらをどうぞ。
先にお断り（公開ルールと、厳密さについて）
2点、先に断っておきます。
1つ目は公開ルールです。Project Eulerには「100番より後の問題は、答えや解法を公開しないでほしい」という要請があります。自力で解く楽しみを他の人から奪わないためです。今回扱ったのはそれよりずっと後ろの問題なので、この記事では 問題番号・最終的な答え・解法の核心は伏せます。問題番号がわかると検索で答えに辿り着けてしまうため、番号も出しません。問題文の引用もしません（Project Eulerの問題文は非商用ライセンスのため）。なので以降は「ある難問」とだけ書きます。
2つ目は厳密さです。これは 各条件1回ずつの試行であって、厳密なベンチマークではありません。LLMは実行ごとにぶれるので、ここに出す数字は「ある日の1回」の記録だと思ってください。
試した設定
- 環境: Claude Code（コンテキストウィンドウは1M設定）
- 渡したもの: 問題文だけ。「解法はカンニングせず、基本的には自力で解いて」と指示
- 振った条件: モデル（Opus 4.7 / 4.8）と、effort（
high/xhigh/max）、それにultracode設定。highは4.8のデフォルト値 - 測ったもの: 所要時間（画面のアクティブタイマー）、コンテキスト使用率（ステータスバーの右の数字）、そして後からログで数えた出力トークン量
ultracodeはそれ自体がeffortレベルではなく、Claude Code側の設定です。モデルにはxhigh相当の推論を送りつつ、動的にワークフローを組んで、サブエージェントに仕事を分担させます。
ひとつ注意点があります。複数のセッションを同じ作業ディレクトリで動かすと、明示的に指示しないと別セッションが残したファイルを読んでしまうことがあります。今回はそれを避けるため、「他のセッションのファイルは見ないで、あくまで自力で」と明示しました。
結果1: 4.7は独力で解けず、4.8は独力で解けた
まず結論から。Opus 4.7はxhighでも、最後の高速化アルゴリズムには到達できませんでした。 自力では答えを出せなかった、という結果です。途中まで（問題を幾何の問題に言い換えるところまで）はたどり着くのですが、現実的な時間で計算しきるための核心に、独力では届きませんでした。
一方 Opus 4.8は、いずれのeffortでも独力で解ききりました。。
解く過程も良かったです。問題文だけを渡された状態から、小さくて答えがわかっている値で自分の式を検証し、構造を見つけ、本番サイズの計算まで自力で持っていきました。
ブラックボックス的な「1回解けた／解けなかった」ではなく、独立した複数回で再現したので、ここは安心して「4.8は独力で解けた」と言えます。
結果2: effortを上げても、この問題では良くならなかった
effort別の記録がこれです。
| モデル / effort | 独力で解けたか | 時間 | コンテキスト使用率 | 出力トークン |
|---|---|---|---|---|
4.7 / xhigh |
✗（独力では未到達） | — | — | — |
4.8 / high |
✓ | 13分29秒 | 約11% | 約17万 |
4.8 / xhigh |
✓ | 35分38秒 | 約25% | 約1,120万 |
4.8 / max |
✓ | 35分56秒 | 約25% | 約50万 |
4.8 / ultracode |
✓ | 28分10秒 | 約19% | 約35万 |
目を引くのは、一番軽いhighが、一番速く・一番少ないリソースで解けている ことです。xhighやmaxに上げても時間は増え、コンテキストも食い、それで答えが良くなるわけではありません（答えはどれも同じ）。「思考予算を増やすほど良くなる」という直感は、少なくともこの問題では成り立ちませんでした。
理由を後でログで追うと、highは早めに効率のよい筋を見つけて一直線に解いていたのに対し、xhighは「とりあえず力で押す」方向に長く粘る場面がありました。深く考えさせること＝うまく解くこと、とは限らないようです。公式でも、adaptive thinkingを有効にすると、同じeffortでもOpus 4.7より無駄な思考トークンを減らせるケースがある、と説明されています。highで十分だったのは、モデルが必要な思考量を自分で見積もっているからでしょう（ここはあくまで推測です）。
念のため繰り返すと、これは1回ずつの試行です。「effortは低い方がいい」と一般化するつもりはありません。タスクによって向き不向きがある、というのがフェアな読み方でしょう。
コンテキスト%はコストではない（67倍の落とし穴）
ここが個人的に一番の学びでした。上の表の「コンテキスト使用率」を見ると、highは11%で、xhighが25%。倍くらいの差に見えます。
ところが、後からセッションのログを見て、各応答の 出力トークン量（thinkingを含む）を合算すると、景色が変わります。
| 4.8 / effort | コンテキスト使用率 | 実際の出力トークン |
|---|---|---|
high |
約11% | 約17万 |
xhigh |
約25% | 約1,120万 |
highとxhighで、出力トークンは約67倍 違いました。同じ問題・同じ正しい答えに対してです。コンテキスト使用率（11%対25%）は、この67倍の差をまったく映していません。
ステータスバーの%は「いま会話のウィンドウがどれだけ埋まっているか」であって、「これまで処理した総量」ではありません。xhighはコードの書き直しと実行を延々と繰り返したので、処理した総量は膨大なのに、ウィンドウ自体はそこまで膨らまなかった、ということです。
同じ落とし穴は、xhighとmaxの比較でも見えます。結果2の表のとおり、この2つは所要時間（35分台）とコンテキスト使用率（約25%）がほぼ同じでした。ところが後からログで数えた出力トークンは、xhighが約1,120万に対してmaxは約50万。見た目の数字がそろっていても、実際に処理した量は 約22倍 違いました。さらに、最上位のmaxのほうがこの問題ではhigh寄りの動きで、早めに筋を見つけて解いていました。xhighのような長い力押しはしていません。「時間が同じならコストも同じ」とは限らない、ということです。もちろんたまたまxhighのとき、落とし穴にハマっただけの可能性も否定できませんが。
ultracodeは本来、動的にワークフローを組んでサブエージェントへ仕事を分担させる設定です。サブエージェントを使うと、その途中経過はコンテキストに残らず最終結果だけが本体へ戻るため、本体の使用率にはサブエージェント側のトークンが反映されず、表面の%だけ見ると実際より安く見えます。ただし今回のログを後から確認すると、この回ではサブエージェントが一度も起動されず、本体だけで解いていました（出力トークンは約35万）。ultracodeをオンにしても、タスク次第ではワークフローを組まずに本体だけで解くことがある、ということですね。
教訓として、ステータスバーの%を「コスト」や「使った量」と読むと、桁を間違えます。 コストを見たいなら、別の指標（実際のトークン課金など）を見る必要があります。
4.8の「進め方」で良かった点
答えの中身には触れませんが、解くまでの作法には感心しました。
いきなり本番を解こうとせず、小さくて答えがわかっている値で自分の式を検証してから、徐々に規模を上げる、という順序を自分で踏んでいました。テストファーストに近い進め方です。
そして、一発で完璧だったわけではありません。ある回では、定数の打ち間違いというバグを自分で埋め込みました。けれど、C言語版とPython版という独立した2つの実装を突き合わせて食い違いに気付き、原因を特定して直す、という自己検証までやりきっています。間違えないのではなく、間違えても自分で気付いて直す。実務で使う道具としては、こちらの方が安心できます。
まとめ
ある超高難度の問題を題材に、Opus 4.8を軽く試した記録でした。1回ずつの試行という前提で、見えたことはこのあたりです。
- 4.7は独力で解けなかった難問を、4.8は独力で、しかも複数回再現して解いた。少なくとも今回の問題では、4.8のほうが粘り強く正答まで届いた手応えがあった
- effortを上げても、この問題では良くならなかった。一番軽い
highが最速・最小だった。タスクによって向き不向きがありそう - コンテキスト使用率はコストではない。
highとxhighで出力トークンは67倍違ったのに、%は2倍程度にしか見えなかった - 4.8は段階的に自己検証し、自分のバグも自分で直した。間違えても気付いて直せるのは実務向き
新しいモデルの「賢さ」は、ベンチマークの数字だけでなく、こういう手触りでも確かめておくと納得感がありますね。
