Claude Opus 5.5とOpus 5の違い｜ChatGPT・Gemini・Codexとの役割分担【2026年版】
更新日：9月24日
Anthropicは2026年9月22日、Claude Opus 5.5を発表しました。結論から言うと、Opus 5.5はOpus 5よりAPI入力・出力単価が20%低く、キャッシュ読み込み単価は$0.50から$0.20へ低下しています。一方で、adaptive thinkingの常時有効化、forced tool useの変更、computer useのtoolset変更など、APIや独自インテグレーションでは移行前に確認すべき差分があります。
通常のClaude Code利用者は、まず現在のモデル表示・Claude Codeのversion・契約プラン・providerを確認してください。HSのiMac環境では2026年9月23日時点でOpus 5.5が既定となり、Opus 5はモデル選択欄から消えていましたが、これはHS環境での観測です。全ユーザーへの一般化や性能比較を意味しません。
この記事では、まずClaude Opus 5.5とOpus 5の違いを料金・仕様・移行の観点で整理し、そのうえでChatGPT・Gemini・Codexとどう役割分担するかを中小企業の実務目線で解説します。
なお本記事は、2026年4月のOpus 4.7比較記事をOpus 5公開時に全面更新し、2026年9月23日にOpus 5.5の現行仕様へ再更新したものです。URLは既存の検索資産を維持しています。
1. Claude Opus 5.5とは｜Opus 5との違い
Claude Opus 5.5は、Anthropicが長時間のagentic codingとknowledge work向けに案内している現行Opusモデルです。Claude APIのモデルIDは claude-opus-5-5。コンテキストウィンドウは1M、最大出力は128Kで、Opus 5の大容量仕様を維持しながら価格と移行仕様が変わりました。
Opus 5.5とOpus 5の早見表
項目 | Claude Opus 5 | Claude Opus 5.5 | 実務判断 |
API入力 | $5 / MTok | $4 / MTok | 入力単価は20%低下 |
API出力 | $25 / MTok | $20 / MTok | 出力単価は20%低下 |
Cache read | $0.50 / MTok | $0.20 / MTok | 長時間agent/反復処理で影響 |
Context | 1M | 1M | 容量差で選ぶモデルではない |
Max output | 128K | 128K | 同じ |
Default effort | high | medium | 移行後の挙動を確認 |
Thinking | Opus 5の既存設定 | Adaptive（always on） | API実装は移行確認が必要 |
Anthropicは、標準設定の典型的なワークロードでOpus 5比およそ40%のコスト削減、出力生成は30%以上高速と説明しています。これはAnthropic側の想定・計測であり、HSの課金実績や独自性能比較ではありません。
Claude Code通常利用者とAPI利用者で対応が違う
Claude Code通常利用：現在のmodel picker、version、plan、providerを確認。『全員が自動移行済み』とは扱いません。
Claude API／独自インテグレーション：モデルIDの変更だけでなく、breaking changesを確認してから本番適用します。
HSのiMac環境：2026年9月23日時点でOpus 5.5が既定、Opus 5はmodel pickerから消えていました。HS環境固有の観測です。
Opus 5からの移行で確認する4点
thinkingはAdaptiveが常時有効となり、無効化できません。effortで推論量を調整します。
tool_choiceのany/toolによるforced tool useは非対応です。autoやstrict tool use等への見直しが必要です。
thinking blockはモデルと会話に紐づくため、会話履歴や保存処理を確認します。
Claude API／Google Cloudのcomputer useでは旧computer_20251124ではなく新toolsetへの移行が必要です。利用providerごとの差分も確認してください。
Opus 5はAnthropicのdeprecation tableでActiveのままで、tentative retirementは2027年7月24日より前には予定されていません。これは確定した終了日を意味しません。既存のOpus 5処理が安定している場合、新しいという理由だけで全面移行するのではなく、同じ代表タスクで挙動を確認してから切り替える方が安全です。
以下の役割分担セクションは、既存記事の検索資産と実務比較を維持しつつ、Opus 5.5の現行仕様を入口に読み直せるよう構成しています。過去のOpus 5時点の評価をOpus 5.5の独自性能評価へ読み替えることはしていません。
2. Opus 4.7・4.8から何が変わったか
この記事を以前読んでいただいた方向けに、実務で影響が大きい変更点を整理します。
（1）thinkingが既定でオンになった
Opus 4.8では、指定しない限り思考なしで動いていました。Opus 5では同じリクエストが思考ありで動きます。モデル自身が、そのターンでどれだけ考えるかを決めます。
（2）思考を切る条件に制限がついた（破壊的変更）
Opus 5では thinking を disabled に指定できるのは、effort が high 以下のときだけです。effort が xhigh または max の状態で思考を切ろうとすると、400エラーが返ります。Opus 4.8では effort と独立に切れていたので、既存の実装をそのまま持ち込むと止まります。
（3）max_tokens の見直しが必要
max_tokens は思考と応答テキストを合わせた出力全体の上限です。思考なしで動いていた処理をOpus 5に載せ替えると、同じ max_tokens では足りなくなることがあります。
もう1つ、地味ですが効くのは「検証しろ」という指示を消すことです。Opus 5は言われなくても自分の作業を検証します。以前のモデル向けに書いた「最後に検証ステップを入れてください」といった指示を残したままにすると、過剰に検証してトークンを消費します。
プロンプトキャッシュの最小長は、Opus 4.8の1,024トークンから512トークンに下がっています。
3. ChatGPT・Gemini・Codexとの比較
スペックの一覧ではなく、業務の軸ごとに、どれを置くかで整理します。他社の細かなモデル番号は変動が早いため、ここではChatGPTの現行提供モデル、Geminiの現行提供モデル、Codex、Claude Opus 5という単位で書きます。
人による承認の必要性：どのモデルでも必要。いちばん重要な軸です。承認者を決めていない業務にAIを入れると、精度に関係なく事故ります
経営判断の整理：Claude Opus 5。前提条件が多く、結論を保留すべき場面を保留できるかが差になります
長文の整理・要約：Claude Opus 5。100万トークンのコンテキストを既定で使えます
調査・情報収集：ChatGPT / Gemini。検索連携とエコシステムの広さ
コーディング：Claude Opus 5 / Codex。Opus 5は複数ファイルにまたがる作業、Codexは既存リポジトリでの反復
リポジトリ作業：Codex。既存コードの文脈に沿った修正
Googleサービス連携：Gemini。Workspace系の定常業務
文章制作：Claude Opus 5。ただし既定の出力が長くなる傾向があるため、字数指定が必須
レビュー・バグ検出：Claude Opus 5。自分で検証しにいく挙動が効きます
長時間タスク：Claude Opus 5。エージェント型の長い作業で途中で脱線しにくい
コスト：用途による。Opus 5は入力5ドル・出力25ドル。常時稼働させる定型処理には重いことがあります
速度：Fast mode または軽量モデル。Opus 5のFast modeは約2.5倍速ですが価格も2倍です
導入難易度：ChatGPT / Gemini。現場に配るならUIとアカウント管理の手軽さが効きます
読み方：一番上に「人による承認の必要性」を置いているのは意図的です。ここを設計していない状態では、下の12軸をどれだけ最適化しても業務は回りません。
どのAIが優れているかより、どの業務を任せて、どこで人に戻すかを先に決めたほうが早く動きます。
4. 業務別にどれを選ぶべきか
経営判断の材料づくり：Claude Opus 5。前提と制約が多く、結論を断定しない出力が要る
議事録・長文資料の整理：Claude Opus 5。長文を一度に扱える
市場・競合の調査：ChatGPT / Gemini。情報の広さ
定型の社内文書・スプレッドシート：Gemini（Workspace運用の場合）。既存業務に接続しやすい
実装・改修：Claude Opus 5 / Codex。規模で使い分け
出力のレビュー：実装と別のモデル。同じモデルに書かせて同じモデルに検証させても、同じ見落としをします
顧客対応の一次受け：どれでも可。ただし必ず人の承認を挟む。誤答の外部露出コストが最も高い
5. 中小企業がOpus 5を導入する際の注意点
コストが読みにくくなる。thinkingが既定でオンなので、同じ処理でも消費トークンが増えることがあります。まず小さい範囲で実測してください。
出力が長くなる。既定の応答や成果物が長くなる傾向があります。字数や形式の指定を運用ルールにしてください。
Fast modeは万能ではない。約2.5倍速ですが価格は2倍で、Amazon Bedrock・Google Cloud・Microsoft Foundryでは使えません（2026年7月時点、Claude APIのみ）。
旧モデル向けの指示を持ち込まない。「検証ステップを入れて」といった指示は、Opus 5では過剰検証の原因になります。
全面移行を急がない。Opus 4.8は引き続き提供されています。安定して動いている処理を、性能が上がったという理由だけで載せ替える必要はありません。
6. AIを1体導入しても業務が回らない理由
最新モデルを入れたのに社内の作業が減らない、という相談が増えています。原因はほぼ次の4つで、いずれもモデルの性能では解けません。
業務が切り出されていない。「経理を効率化したい」は業務ではありません。「月末の請求書PDFから金額と取引先を抜き出して一覧にする」まで割らないと、AIは担当できません。
入力データが整っていない。手元の情報が紙・画像・個人のメール受信箱に散っていると、モデルを上げても入り口で止まります。
出力を検証する人が決まっていない。誰が確認して、どこまでなら通してよいのかが決まっていない状態では、結局全部を人が読み直すことになります。
止まったときの手順がない。AIを業務に接続すると、必ずどこかで止まります。止まったときに誰が何を戻すのかが決まっていないと、一度の障害で運用ごと放棄されます。
この4つは、モデルを乗り換えても消えません。だからこそ「どのAIが最強か」より先に、業務の分け方を決める必要があります。
7. HSビルのAI役割分担
HSビルワーキングスペースでは、業務ごとに担当するAIを分けて運用しています。ここでは、実際の構成と、Claude Opus 5が出たときに何をして、何をしなかったかを書きます。
役割を分けて運用している
経営判断と優先順位の決定、技術実装と障害対応、導線改善とCV設計。この3つは別々の役割として分けています。1つのAIに全部を任せていません。判断する側と実装する側を分けないと、間違った方針をそのまま高速に実行してしまうためです。
業務ごとの割り当ては次のようにしています。
経営判断・優先順位の決定：ChatGPT
複数ファイルにまたがる設計、障害の深掘り、難所の実装：Claude Code
軽〜中規模の修正、Markdown編集、ログ確認：Codex CLI（一次対応）
LINEの顧客対応・問い合わせ分類、予約案内の定型処理、週次のトレンド配信、ブログ候補の分析：軽量モデル
重い作業から先にClaude Codeへ渡すのではなく、まずCodex CLIで済むかを判定してから渡すというルールにしています。
Claude Opus 5が出たときに何をしたか
Opus 5は、複雑な設計・長時間の処理・難所の対応で価値を検証する限定採用としました。全業務の標準モデルにはしていません。
載せ替えなかったものは次のとおりです。
LINE上の顧客対応・問い合わせ分類
予約案内に関係する定型処理
週次のAIトレンド配信
ブログ候補・分析系の反復処理
ログ確認や軽微なファイル修正
すでに正常稼働している売上直結の導線
理由は、新しいモデルの性能が高いことと、既存の本番業務を載せ替えることは別の問題だと考えているからです。いま正常に動いている顧客導線を変更すると、分類結果・出力形式・応答時間・ツール連携に予期しない差分が出ます。
コスト面でも、定型処理や大量の反復処理に高コストのモデルを常用すると、品質が上がる分より運用費が増える影響のほうが大きくなります。HSビルでは、売上・CV・工数・エラー率のいずれかを数値で改善できる場合に限り、高コストのAIを採用すると決めています。
品質・安定性の面でも、モデルを変えるとJSONの長さ、分類結果、応答速度、ツール実行の挙動が変わることがあります。実際の業務プロンプトで本番同等のテストを通していない状態で、顧客接点や予約導線を載せ替えることはしません。
次のすべてを満たしたときに、載せ替えを再検討します。
実業務のプロンプトで既存モデルを明確に上回る
エラー率・分類精度・作業時間のいずれかが数値で改善する
コスト上限内に収まる
回帰テストに合格する
問題が起きたときのロールバック手順がある
顧客向け導線に影響を出さずに段階導入できる
実際に止まったときの話（2026年7月16日）
AIを業務に接続すると、必ずどこかで止まります。実例を1つ書きます。
何が起きたか：LINEからの個室ブース・会議室の空き確認で、本来は予約候補として案内すべき時間帯に「空きなし」と回答する事象が発生しました。あわせて、日付の扱いがUTC基準になっていた箇所があり、日本時間では翌日の早朝枠が前日の候補として混入する可能性も確認されました。
影響：予約できる可能性のある時間帯を、予約できないと案内する可能性がありました。個人情報の漏えいや決済の事故は確認されていませんが、予約機会の損失につながるため、売上直結の障害として扱いました。
原因は次の3点です。
2時間プランのサービスIDと内部の逆引き情報が不足していた
空き枠の取得処理の一部がUTC暦日を基準にしていた
予約情報とLINE側の回答を照合するガードが不足していた
どこで人に戻したか：AIの回答をそのまま確定案内として扱うのをやめ、予約ルールと予約システム側の情報を優先する運用に戻しました。検索結果が空になる場合、時間帯が一致しない場合、予約ルールと矛盾する場合は、人の確認へ戻す方針にしています。
修正したことは次のとおりです。
2時間プランのサービスID・逆引き・カタログ情報を追加
空き枠の取得を日本時間の暦日に合わせて修正
返却する枠に日付一致のガードを追加
毎週の契約利用による予約不可ルールを明示的に実装
予約ルールの判定状態をログに残すよう変更
代表ケースでの回帰テストを実施
再発防止として、次を運用に組み込みました。
AIの自由判断だけで予約可否を確定しない
予約システム側の情報と固定ルールを正本として扱う
検索結果が空、または日付が一致しないときは確定回答を止める
予約時間・日付・プラン別の回帰テストを維持する
顧客向けの回答と内部ログを分けて監視する
本番反映後はLINEの実機で確認する
現在の状態：誤案内を防ぐ一次対応と予約ルールの追加は完了しています。根本修正については検証環境で確認し、本番への段階反映を進めました。
この2つ、つまり最新モデルが出ても載せ替えなかった判断と、実際に止まったときの対応が、AIを業務に入れるときに本当に必要になる部分です。モデルの性能表には出てきません。
8. 導入前に整理すべき業務
次の項目が埋まらないうちは、モデルを選ぶ段階ではありません。
AIに任せたい作業を1つ、工程レベルまで分解して書き出せているか
その作業に必要な情報は、どこに、どの形式で置かれているか
出力を確認するのは誰か
どこまでなら確認なしで通してよいか
間違ったまま外に出た場合、何が起きるか
止まったときに戻す手順は決まっているか
月にいくらまで使ってよいか
3か月後に何が減っていれば成功と言えるか
担当者が1人に偏っていないか
やめる判断は誰がするか
9. よくある質問
Q. Claude Opus 5とFable 5はどちらを使うべきですか。
日常の業務と開発はOpus 5、最も難易度の高い長時間タスクだけFable 5、という使い分けが基本です。Opus 5はFable 5の半額です。
Q. Opus 4.8から移行するときに気をつけることはありますか。
thinkingが既定でオンになった点と、effortが xhigh・max のときに思考を切ると400エラーになる点です。max_tokens の見直しもあわせて必要です。
Q. コストはどれくらいかかりますか。
API価格は入力5ドル・出力25ドル（100万トークンあたり）です。ただし実際の請求額は使い方で大きく変わるため、小さい範囲で実測してから広げてください。
Q. 中小企業でも使えますか。
使えます。ただし、性能よりも「どの業務を任せて、誰が確認するか」を決めるほうが効果に直結します。
10. AI導入相談
HSビルワーキングスペースでは、自社で複数のAIを業務に接続して運用しています。うまくいった部分だけでなく、止まった箇所と、そのとき何を人に戻したかも記録しています。同じ判断を自社でするための整理からお手伝いできます。
著者・運営者
三宅悠生（HSビルワーキングスペース / FULMiRA Japan 合同会社）
複数のAIを業務ごとに分けて運用する体制を自ら構築・運用しており、本記事の内容はその実運用に基づいています。
更新履歴
Claude Opus 5の公開にあわせて全面更新。比較対象をClaude Opus 5・ChatGPT・Gemini・Codexに刷新し、業務別の役割分担と導入前の整理項目を追加。
2026年4月17日：初出
コメント