---
category: AIとの付き合い方
date: '2026-09-23'
description: 2026年9月22日にClaude Opus 5.5が出て、Claude Codeの既定モデルが本人の操作なしに入れ替わりました。effortもmediumに戻っています。公式が言う「Fable並みで4割安い」を経営者の言葉に翻訳し、発表翌日に外の人が確かめられたこと・まだ誰も確かめていないことを分けて、前回自分のログで測った「切り替えるな」「Fableは温存」がまだ効くかを読み直します。
draft: false
slug: opus55-tsukaikata
title: 最新モデル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本の記事を書きました。

- [Fableであなたは損してます！モデル切り替えのベストプラクティスの実態実験](/articles/model-switch-cache/) ── 会話の途中でモデルを切り替えると、それまでの会話の86%を読み直させていた。正解は切り替えずに「呼ぶ」こと。
- [claudeの週間制限17%減少! その効果的な対策の検証](/articles/weekly-limit-17-taisaku/) ── 定額プランの枠はドルとは別の物差し。Fableは週の半分までしか使えず、他モデルより速く枠を食う。だからOpusを本体に、判断のときだけFableを呼ぶ。

本体が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 公式**

- [Introducing Claude Opus 5.5](https://www.anthropic.com/claude-opus-5-5) ── 発表文。「Fable 5.1並み・Opus 5より40%低コスト」「ベンチマークの差は当てにならなくなってきた」の記述、Terminal-Bench等の数値
- [Claude Opus 5.5（モデル概要）](https://platform.claude.com/docs/en/models/opus-5-5/overview) ── モデルID、価格、コンテキスト窓1M、最大出力128K、thinking常時オン、既定effort medium
- [What's new in Claude Opus 5.5](https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5)／[Migrating to Claude Opus 5.5](https://platform.claude.com/docs/en/models/opus-5-5/migration-guide) ── Opus 5からの4つの変更点
- [Prompting Claude Opus 5.5](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5) ── 「effort変更は既定でプロンプトキャッシュを無効化」「出力生成が30%超速い」「熟考を促す定型指示は基本不要」「貼付資料を区切る」
- [Choosing a model](https://platform.claude.com/docs/en/about-claude/models/choosing-a-model)／[Models overview](https://platform.claude.com/docs/en/models/overview) ── 「まずOpus 5.5、届かなければFable 5.1」の推奨順、「Fable 5.1は広く提供する中で最も高性能」
- [Pricing](https://platform.claude.com/docs/en/about-claude/pricing) ── 単価、キャッシュ読取0.05倍、Batch 50%
- [System Card: Claude Opus 5.5](https://www.anthropic.com/claude-opus-5-5-system-card) ── 「Opus 5からのアップグレード」、貼付文中の指示への注入に直近モデルより弱いという開示
- [Claude Code CHANGELOG（v2.1.280）](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) ── 新しい既定Opus、Pro/Team Standardの既定変更、旧effort設定は引き継がれない
- [Claude Code「Model configuration」](https://code.claude.com/docs/en/model-config) ── `opus` の解決先が経路で違うこと
- [Claude Fable models on your plan](https://support.claude.com/en/articles/15424964-claude-fable-models-on-your-plan) ── Fableは週間枠の50%まで、他モデルより速く消費

**外の人の一次記録**

- Simon Willison ── [llm-anthropic Issue #91](https://github.com/simonw/llm-anthropic/issues/91)、[ペリカン5段階のログ（gist）](https://gist.github.com/simonw/61fd7c3683fffce9a3ab7c43d1180024)
- Armin Ronacher ── [Pi へのOpus 5.5対応コミット](https://github.com/earendil-works/pi/commit/b4588f26af2f74f7b1387b548e04a3c8d81da75b)
- Every（Katie Parrott署名、Dan Shipper・Kieran Klaassen・Mike Taylor・Tyler Nishida発言）── [Vibe Check: Opus 5.5 Is Pulling Our Codex Converts Back to Claude](https://every.to/vibe-check/vibe-check-opus-5-5-is-pulling-our-codex-converts-back-to-claude)

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

- [Fableであなたは損してます！モデル切り替えのベストプラクティスの実態実験](/articles/model-switch-cache/)（2026-08-07・自分のログ770セッション）
- [claudeの週間制限17%減少! その効果的な対策の検証](/articles/weekly-limit-17-taisaku/)（2026-09-16・自分のログ45日分・156,013件）

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