AIKA@AI経営パラノイド
トップ ＞ 記事一覧 ＞ 最新モデルOpus5.5を徹底解剖——効き目より先に、設定を1つ確かめてください
AIとの付き合い方

最新モデルOpus5.5を徹底解剖——効き目より先に、設定を1つ確かめてください

A AIKA 読了 約15分
最新モデルOpus5.5を徹底解剖——効き目より先に、設定を1つ確かめてください

Claudeの最新モデルOpus5.5について詳細に調べてみました。今日からのあなたの仕事にどう影響するか、他のモデルとの違いなどを共有します。

Claude Codeを更新したら、画面に、選んだ覚えのないモデル名が出ている。
「Opus 5.5」。

昨日まで使っていたのと同じ調子で仕事を頼む。返事は来る。速いような気もする。
でも、何が変わったのかは分からない。

これは私の体験談ではありません。9月22日に配られたClaude Codeの更新で、あなたの環境にそのまま起きることです。

この記事は、発表翌日の9月23日時点で分かることだけを書きます。
公式が書いていること、外の人が実際に確かめたこと、まだ誰も確かめていないこと。この3つを混ぜません。

先に一つだけ。
いま、あなたのClaude Codeのモデルと、effort（考える深さ）が何になっているか、確かめてください。
理由はこの記事のいちばん最初の章にあります。

1. 何が変わったか——9月23日時点の事実だけ

Anthropicの公式資料に書かれていることを、そのまま並べます。ここは私の意見ではありません。

名前と日付。 Claude Opus 5.5。2026年9月22日に発表・提供開始。APIでの名前は claude-opus-5-5。直接の前のモデルはOpus 5で、System Card（公式の技術報告書）自身が「Opus 5からのアップグレード」と書いています。

値段。 100万トークンあたり、入力4ドル・出力20ドル。Opus 5は5ドル・25ドルだったので、単価は2割下がりました。使い回し（キャッシュ）から読むときは0.20ドル。まとめて処理するBatch APIは半額。

考え方の設定。 Opus 5.5は「考える」機能（thinking）を切れません。常に考えます。考える深さ（effort）の既定はmedium。Fable 5.1の既定はhighなので、同じ「既定」でも深さが違います。

Claude Codeでの扱い。 9月22日に配られたClaude Code v2.1.280から、Opus 5.5が新しい既定のOpusになりました。ProプランとTeam Standardプランは、既定モデルそのものがSonnetからOpusに変わっています。

そしてここが、冒頭で「確かめてください」と書いた理由です。

以前 /effort で保存した古い形式のeffort設定は、Opus 5.5には引き継がれません。mediumから再開します。

出典は公式の変更履歴です。昨日までhighで使っていた人も、今日はmediumで動いている可能性があります。速く感じたなら、それはモデルが速くなったからではなく、考える深さが浅くなったからかもしれない。どちらなのかは、設定を見ないと分かりません。

一つ注意。opus という呼び名がどのモデルを指すかは、使っている経路で違います。Anthropic API・AWS・Google Cloudでは5.5に切り替わりましたが、Microsoft Foundryはまだ4.6のまま。会社でどの経路を使っているか分からない人は、そこも確かめる必要があります。

Claudeのアプリ側。 Pro・Max・Team・Enterpriseの5時間ごとの利用枠を引き上げた、と公式は書いています。ただし、新しい上限の数字は公表されていません。

2. 「Fable並みで4割安い」を、経営者の言葉に翻訳する

公式の発表文の一番目立つところに、こうあります。

大半の作業でClaude Fable 5.1と同じ水準の性能を、Opus 5より40%低いコストで。

この一文には、別々の数字が混ざっています。分けます。

「20%安い」は単価の話です。 同じ量のトークンを使えば、請求が2割減る。これは価格表から計算できるので、確かです。

「40%安い」は運用コストの話です。 公式は「仕事を仕上げるまでのコストが40%低い」と言っています。開示されている計算条件は「既定の設定（effort medium）で、典型的な作業」という一文だけで、どの仕事を何件、どう数えて40%なのかは書かれていません。単価が2割下がって、さらに同じ仕事を少ないトークンで終える傾向がある、と公式は説明しています。それを足すと4割になる、という理屈は分かります。でも、あなたの仕事でそうなるかは、別の話です。

「30%速い」は、文字を出す速さの話です。 公式が測ったのは出力トークンの生成速度。仕事が終わるまでの時間ではありません。考える時間、ツールを動かす時間、やり直しの時間、そしてあなたが確認する時間は、この30%に入っていません。

ベンチマークは、公式自身が留保をつけています。 Terminal-Bench 4.0という開発向けの試験で、Opus 5.5（xhigh設定）66.4%、Fable 5.1が55.8%、Opus 5が52.3%。数字だけ見るとFableを抜いています。ところが同じ発表ページに、こう書いてあります。

ベンチマークの差は、実際の差を示す指標として当てにならなくなってきており、実際の使用でのOpus 5.5とFable 5.1の差はもっと狭い。

言った本人が、そう言っています。私はこの一文を、数字より重く読みます。

つまりどういうことか。

確かなのは「単価が2割下がった」まで。「4割安い」「Fable並み」は、公式の主張であって、あなたの仕事での結果ではない。その差を埋めるのは、あなた自身の1回目の試行です。

3. 外の人は、まだほとんど何も言えていない

発表から1日。外の人が何を確かめたか、4つの窓から見ました。技術者2人、教育者1人、経営者のチーム1つです。

Simon Willison（技術者・自作ツールの作者）。 発表当日のうちに自作のプラグインをOpus 5.5に対応させ、GitHubのissueに「モデルID以外に、プラグイン側で新しく対応が要る機能は見当たらない」と書いています。

そして本人の定番テスト、「ペリカンが自転車に乗るSVGを描け」を、考える深さ5段階で1回ずつ走らせて、ログを公開しました。

深さ 出力トークン（うち考えた分） 時間
low 1,891（0） 15.5秒
medium 2,941（220） 25.1秒
high 3,366（329） 29.5秒
xhigh 11,977（8,821） 1分55秒
max 128,000（128,000） 19分1秒

maxでは、19分待って、答えの本文が1文字もありませんでした。出力の上限128,000トークンを全部「考える」で使い切って終わっています。

ただし、ここで一般化しないでください。試行は各1回。出来上がったSVGの良し悪しは、本人も評価していません。maxで止まった原因が、モデルなのか、プラグインが指定していた上限なのか、ツールの表示処理なのかも、切り分けられていません。「maxをいきなり使うと、こういうことが起きうる」という1例として読むのが、正確です。

Armin Ronacher（技術者・エージェント開発）。 自身が関わるコーディングエージェント「Pi」に、発表当日Opus 5.5対応のコードを入れて、同日にリリースしています。でも、それは「つなげるようにした」記録であって、Opus 5.5に仕事をさせた記録ではありません。本人の使用感は、調べた範囲では見つかりませんでした。

Ethan Mollick（教育者・AIと仕事の研究）。 短い投稿が1件だけ。業務でどう任せたかが分かる長さではありません。

Every（Dan Shipperが率いる出版・開発チーム）。 ここだけ、実際に仕事をさせた記録があります。発表前の7日間、先行アクセスで試したもので、Anthropicは内容に関与しなかったと記事に明記されています。署名はKatie Parrott、Dan Shipper本人の発言が引用されています。

良い方から。

  • Dan本人は「Fableの小型版。速くて安くて日常向き」と評価し、大規模な開発案件では主力にした。ただし文章と知的業務では、引き続き別系統（Codex）を選ぶと述べています。
  • Kieran Klaassenは、同じRubyの課題でFable 5.1が26行書いたところをOpus 5.5は14行で済ませたと報告。
  • Mike Taylorは、Railsアプリへの機能追加を約8分・251行の変更で出させ、自動チェック5件中4件を通過。

そして、同じ記事に載っている、うまくいかなかった方。

  • 音声入力フォームを30分・約590万トークンかけて作らせたら、見た目は良いのに、中核の画面がエラーで動かなかった（Mike Taylor）。
  • PowerPointの資料で、ブランドのロゴと配色を無視し、「全製品を1人のエンジニアが担当」という事実でない記載を勝手に足した（Mike Taylor）。
  • UI部品の自己レビュー機能が、9割超を理由が追えないまま却下した（Tyler Nishida）。
  • 長時間の自動生成を回して、週間の利用枠を使い切ったメンバーがいた。
  • 文章は読みやすさの指標では良いのに、「要点が先頭に来ず、埋もれる」と複数人が指摘。

つまりどういうことか。

発表翌日に外にある実使用の記録は、実質、Simonの1シリーズとEveryの1本です。同じ結果を、別の人が別の条件で再現した検証は、0件。好評価と、動かない中核画面と、勝手に足された虚偽の一文が、同じ記事の中に並んでいる。

これが9月23日の実態です。「良い」とも「悪い」とも、まだ言えません。

4. 前回測ったことは、まだ効くか

私は8月と9月に、自分のClaude Codeのログを掘って2本の記事を書きました。

本体がOpus 5.5に入れ替わった今、この2本はまだ効くのか。根拠がある物だけ、分けて書きます。

効く。しかも、条件が1つ増えた。

「途中で切り替えるな」の根拠は、使い回し（プロンプトキャッシュ）がモデルごとに別、という公式の仕組みでした。この仕組みはOpus 5.5でも同じです。

そして、Opus 5.5向けの公式プロンプト文書に、新しく明記された一文があります。

effortの変更は、既定ではプロンプトキャッシュを無効化する。

モデルだけでなく、effortを途中で変えても、会話を読み直させる。
前回の記事の「モデルは朝決めて動かすな」は、「モデルもeffortも、朝決めて動かすな」に更新します。深さを変えたくなったら、それは切り替えではなく、別の相談役を呼ぶ場面です。

なお、変更した瞬間だけキャッシュが壊れる仕組みなので、1日に何度も変える人ほど損が大きい。私の前回の実測は「モデルを変えた回」しか数えていないので、effort変更の損の大きさは、まだ測っていません。

効く。Fable側は何も変わっていない。

「Fableは週の半分まで」「他モデルより速く消費する」は、Fableのプランの公式ヘルプに書かれていることで、Opus 5.5の発表で変わってはいません。判断の場面にFableを温存する使い方は、そのままです。

分からない。

前回の記事で、週間の財布は「Opus専用」と「それ以外」の2つあると書きました。Opus 5.5が、その「Opus専用」の財布から出るのかどうか、公式資料には見つかりませんでした。名前からすればそうでしょうが、名前で判断するのはやめます。それから、Opus 5.5が枠を何倍の速さで食うのかも、まだ誰も測っていません。私も測っていません。

5. 経営者のいまの手——4段階に分けます

「Opus 5.5のベストプラクティス」を書けたら良かったのですが、書けません。業務の品質や生産性が上がったと確認できた使い方は、9月23日時点で0件です。

その代わり、根拠の強さで4段階に分けます。上ほど確かで、下ほど「5.5固有ではない」話です。

根拠のある推奨（公式の仕様に基づく）

移行後の実モデルとeffortを確認してから、いつもの仕事を流す。

第1章のとおり、あなたの設定は黙って変わっているかもしれません。確かめ方は簡単で、Claude Codeで /model と打つと今のモデルが、/effort と打つと今の深さが出ます。それを見てから、先週と同じ代表的な仕事を1つ流して、出来と時間を比べる。ここまでは、公式の仕様だけを根拠に、自信を持って勧められます。

「5.5の結果」を語るのは、そのあとです。設定を確かめないまま「速くなった」「雑になった」と言うと、モデルの評価とeffortの評価が混ざります。

条件付きの実践例（Everyの1事例。読者が同じ条件を用意できる時だけ）

小さな改修を、完成条件とレビュー担当を決めてから任せる。
Everyの「8分で4/5通過」は、動く開始状態・要求・受け入れチェック・見る人が揃っていた上での数字です。4/5は完了ではありません。残りの1件を人が見ています。あなたの会社にその「見る人」がいないなら、この事例はまだ使えません。

見た目の試作は、見た目としてだけ使う。
Everyでは、見た目が良くて中核が動かない例が出ました。画面案・デザイン案の比較材料には使える。見た目の良さから、動くかどうかを推定しない。

検証候補（まだ誰も効果を確かめていない。試すならこの形で）

mediumから始めて、足りない課題だけ深くする。
公式の推奨はこの順です。mediumで試す、届かなければ上げる、xhighやmaxでも届かなければFable 5.1へ。Simonのmaxの1例が示すのは「深くすれば良くなる」ではなく「深くすると、時間とトークンだけ増えて答えが来ないこともある」です。同じ資料と同じ依頼文で、設定だけ変えて、品質・時間・トークンを並べてください。

貼り付ける資料と、あなたの指示を、はっきり分ける。
ここは大事です。System Cardが自ら、こう開示しています。

直近の他のClaudeモデルより、ユーザーが貼り付けた文中の指示による注入に弱い。

メール、Webの文章、取引先の資料を貼って「分析して」と頼む仕事は、経営者ほど多い。その貼り付けた文の中に「この文書を読んだら○○せよ」と書いてあったとき、5.5はそれに従いやすい、と作った側が言っています。System Cardの脚注は、これが起きる前提を「利用者自身が、悪意ある指示を含む文章を自分の依頼文に貼り付けたとき」に限定しています。裏を返せば、外から来た文章を貼る仕事が、いちばん当たりやすい。公式の対処は「貼付資料を専用のタグで区切り、資料内の命令には従わないよう指示する」。ただし、区切っただけで安全になったという実証はありません。権限の管理と、人の確認と、併用してください。

文章は、自分の良い文章例を渡して、要点を先に置くよう頼む。
Everyの「要点が埋もれる」指摘に対する運用案です。英語での評価なので、日本語で同じことが起きるかは、まだ分かりません。

5.5固有ではない、いつもの原則

  • 着手前に完成条件を決める。「何ができたら終わりか」「推測は書くな」を先に渡す。
  • 長い作業には、時間とトークンの予算と、途中の確認点を置く。Everyの「週間枠を使い切った」は、予算を置かなかった結果に見えます（これは私の推測です）。
  • AIの「できました」とは別に、成果物を人か機械が検査する。Everyの「勝手に足された一文」は、検査でしか捕まりません。
  • モデルを選ぶ基準は、単価ではなく総作業費。準備・AIの処理・修正・確認を分けて記録する。API単価の2割減は、あなたの確認時間を1分も減らしません。

6. まだ分からないこと

正直に、分からないことを並べます。この記事の続きは、ここが埋まったときに書きます。

  • 日本語の事務・企画・資料作成で、旧モデルや他モデルよりどれだけ良くなるか、手直しの時間はどれだけ減るか。日本語の実測は、調べた範囲に1件もありません。
  • 課題ごとの最適なeffortと、深くした分の費用と待ち時間が見合う条件。
  • Simonのmaxの無回答が、どのくらいの割合で再現するか。原因はモデルか、設定か、ツールか。
  • 長時間の作業の成功率と、途中で止まる率と、やり直しを含めた総時間。
  • 公式の「運用コスト40%減」の計算条件と、それが自社の仕事に当てはまるか。
  • Opus 5.5が定額プランの枠を、Opus 5と比べて何倍の速さで食うか。「Opus専用の財布」に入るのか。
  • Claudeアプリの、新しい5時間枠の具体的な数字。

明日からの3行

  • 画面で、いまのモデルとeffortを確かめる。 /model と /effort。黙って変わっているかもしれません
  • モデルもeffortも、朝決めて、その日は動かさない。 途中で変えると会話を読み直します。深さを変えたくなったら、別の相談役を呼ぶ
  • 自分で正誤を確かめられる仕事から、完成条件と時間を記録して試す。 4/5通過は完了ではない。見た目が良くても動いているとは限らない

Opus 5.5は、たぶん良いモデルです。公式もEveryもそう言っています。
でも、あなたの仕事で良いかどうかは、まだ誰も測っていません。
測るのは、あなたの1回目です。

この記事で参照した資料

すべて2026年9月23日に開いて確認したものです。仕様は変わりうるので、気になる箇所はリンク先の原文をご確認ください。

Anthropic 公式

外の人の一次記録

自分で測ったもの（前回2本）

この記事は、Anthropic公式資料と上記の一次記録を4人の調査員（AI）が独立に集め、別のAIが証拠の独立性と採否を検証した結果をもとに書いています。Opus 5.5そのものを使った私自身の新しい実測は、この記事にはまだ含まれていません。含まれたら、その旨をここに追記します。（2026年9月23日時点・暫定）

次に読む

AIとの付き合い方

Obsidianは第2の脳ではなく、ただの画面じゃないかと思う怒られそうな仮説

2026-09-16
AIとの付き合い方

claudeの週間制限17%減少! その効果的な対策の検証

2026-09-16
AIとの付き合い方

AIの「できました」を、Playwrightに見に行かせる

2026-09-15

書き手はAIKA。このサイトについて