Claude Opus 5.5は何がすごい？
Xの実例6件で見る
強みと限界

「Opus 5.5でゲームを作った」。Xには目を引く投稿が並びます。

ただ、動画がきれいなことと、自分の仕事でも正確に使えることは別です。

この記事ではXの元投稿6件を確認し、実際に示されたこと／まだ分からないことを分けます。

料金と性能についてはAnthropicの公式発表を確認しました。

編集部によるOpus 5.5のAPI実行テストではありません。

投稿者の自己申告や提供元の試験結果は、その出所を明記して扱います。

この記事は、Xで新モデルの作品を見て「自分の会社でも使えるのか」と考えた人に向けています。

Web制作、資料の確認、コード改修では、合格の条件が違います。

どの投稿が自分の仕事に近いかを見つけ、次に試す一つの作業を決めてください。

料金や提供条件は変わるため、判断前に公式情報も確認してください。

まず結論：コードで作る仕事の幅が広い

Web表現をコードで作る例が複数あります。

コード移行の時間・費用や、企業内の資料処理での使用量が減ったという報告もあります。

一方、完成した画面だけで再現性や正確さは判断できません。

画像素材を別のAIが作った例もあります。

ここで比較できるのは、投稿者が明示した条件と結果だけです。

制作動画と業務の成績を一つの「すごさ」にまとめると、導入判断を誤ります。

Xの実例6件を、元投稿から読む

投稿者の発言を短く整理しました。数値がある場合は投稿者の報告であり、編集部の実測ではありません。

画像生成が上手くなった、と言ってよい？

今回のX投稿だけで、Opus 5.5の画像生成能力は評価できません。

Jake Eaton氏の例は、プログラムがピクセルを描いています。

ゲームの例では、画像素材をGPT-6 Solが担当しています。

Three.jsの動画も、コードで画面を描く仕事です。

コードを通じて視覚表現を作る力と、画像モデルへ同じ文章を渡したときの画質は、別の比較です。

Web画面のスクリーンショットも、見た目だけでは制作経路を特定できません。

コードを生成したモデルと、画像素材を作ったモデルを確かめてから比較します。

画像生成モデルは、指示文、サイズ、試行回数をそろえて比べます。

Xの完成品だけを並べても条件が違います。

画像生成とコード生成を混ぜずに比べる考え方は、GPT-6 Solの比較記事にもつながります。

料金は安くなった？APIの公表額を確認

Opus 5.5の標準API料金は入力100万トークンあたり4ドルです。

出力は100万トークンあたり20ドルです。

Opus 5の5ドル／25ドルから、それぞれ20％下がりました。

Anthropicは、標準設定での典型的な仕事では総費用が約40％下がると説明しています。

これは提供元の試験結果で、すべての仕事にそのまま当てはまる値ではありません。

Claudeの月額プラン料金とAPIの従量料金も別です。

利用形態を決めずに「1件あたりいくら」と計算するのは避けてください。

同じ仕事を比べるなら、入力・出力トークンだけでなく、やり直し回数と人が確認した時間も記録します。

安く出力できても、手直しが増えれば業務全体は安くなりません。

「単価20％減」と「仕事の費用40％減」は違う

入力・出力の単価がそれぞれ20％下がっても、実際の費用は使ったトークン数で変わります。

40％という値は、Anthropicが典型的な仕事を標準設定で試したときの総費用の説明です。

少ない手順で終わる仕事では、単価の差以上に総費用が下がる可能性があります。

一方、長い文章を何度も出し直す仕事なら、その差は小さくなるかもしれません。

キャッシュ読み込みの単価も下がっていますが、実際にキャッシュを使えるかは呼び出し方次第です。

表の0.20ドルだけを見て、すべての入力がその価格になると考えないでください。

ベンチマークの順位だけで選ばない

Anthropicの表で、Opus 5.5は66.4％でした。

対象はTerminal-Bench 4.0です。

同じ表のFable 5.1は55.8％でした。

しかしこれは、対象の課題、思考量、実行環境が決まった試験です。

同社自身も、上位モデル間の点数差は実際の仕事の差を予測しにくくなったと説明しています。

例えば見積書の確認に強いかは、この端末操作の点数だけでは分かりません。

モデル比較では「誰が測ったか」「何の仕事で測ったか」「同じ条件か」を先に見ます。

Xの投稿、提供元の試験、自分の仕事での実測は、証拠の種類が違います。

出典：Anthropic「Claude Opus 5.5」公式発表（2026年9月22日）。

料金は2026年9月29日に確認しました。

仕事で試すなら、何を比べればよい？

派手な作品を再現するより、今の仕事で毎回発生する一つの課題を選びます。

例えば、会議メモから決定事項を抜く仕事を選べます。

見積の条件差を探す仕事や、表から報告文を作る仕事も候補です。

機密情報を入力してよいか、社内規程を先に確認してください。

例：契約更新日の確認を試す場合

契約更新日を探す仕事なら、短い架空契約書を用意します。

会社名などは架空のものに置き換えます。

更新日、解約通知の期限、自動更新の条件を明記したものです。

AIには更新日だけでなく、根拠の文も示すよう頼みます。

解約通知の期限は別に出させます。

日付が本文と別紙で食い違うなら、勝手に一つへ決めずに相違を報告させます。

人は、出力された日付と根拠の文を元資料で照らします。

ここで一つでも期限を取り違えたら、実契約を自動で処理する段階には進めません。

正しく答えた場合も、判断の根拠になった文を残します。

担当者が変わっても、答えを検証できるようにします。

この例は試し方の提案です。Opus 5.5で実行した結果ではありません。

比較相手は、現在の方法で十分です。

モデルの順位より、自分の仕事で結果が良くなり、確認できるかを優先します。

うまくいった一件だけで採用を決めない

同じ種類の資料でも、書き方が異なれば結果は変わります。

更新日が一か所だけの契約書、別紙を参照する契約書、更新条件が未確定の契約書を分けて試します。

正解が分からない資料を最初から渡すと、AIの回答を採点できません。

先に人が根拠を確認できる少数の例を選び、どこで間違えたかを記録します。

未確定のものに「不明」と答えるなら、無理に答えを作るより安全です。

仕事で役立つのは、どんな質問にも答えることではなく、判断できないときに止まれることです。

その後、担当者が確認にかかる時間まで含めて比べます。

AIが早く答えても、根拠探しに時間がかかれば、現在の方法より楽とは言えません。

資料の場所や作業手順が曖昧なら、先に業務棚卸し表で整理します。

そのほうが、試す課題を絞れます。

実演動画では分からない三つの条件

完成品を見ても、失敗時の扱いまでは分かりません。

一つ目は、どの情報にアクセスしたかです。

社内資料を読む仕事では、モデルの性能以前に、閲覧権限と入力してよい情報の範囲を決めます。

二つ目は、間違えたときに止められるかです。

契約の日付を読み違えた場合、回答をそのまま予定表へ登録する仕組みでは訂正が難しくなります。

最初は回答を下書きにとどめ、人が元資料と照らしてから反映します。

三つ目は、運用を続けられるかです。

担当者が変わっても、同じ資料を探し、出力の根拠を確認できる手順が必要です。

作品の動画は、その場で動いたことを示します。

長く使えるか、誰が直すか、費用が見合うかは、別に確かめる必要があります。

編集部の見方：作品より「確認できる成果」を見る

Opus 5.5の投稿では、コードを書きながら長い作業を進める様子が目を引きます。

細かく分けていた仕事を、まとめて任せやすくなる可能性があります。

「最後まで作れる」と「安心して渡せる」は別です。

画面の動作、コードのテスト、資料の出典は、それぞれ人が確認します。

Xの成功例を、導入の証拠ではなく「試してみたい課題を見つける材料」として使うのがよいと考えます。

業務では、最初からシステム全体を任せません。

元の記録を見れば正誤を判断できる、一つの工程から試してください。

Xのデモは、作れそうなものを考える入口には向いています。

導入判断には、失敗例、修正の手間、結果を確かめる方法も必要です。

大きな仕事を一度で終わらせることだけが、Opus 5.5の価値ではありません。

任せる部分と人が止める場所を決めてこそ、仕事で安心して使えます。