Claude Opus 4.8実測：作業能力は向上も、コミュニケーションに課題

本朝、Anthropicは正式にOpenAIを追い抜き、新たな評価額の発表と同時に、数日前から噂が流出していたClaude Opus 4.8をリリースした。フラッグシップ製品ラインの最新版だ。我々は直ちに手を動かし、ユーザーコミュニティの初期フィードバックも収集した。

結論から言えば：作業能力は向上したが、「性格」がより扱いにくくなった。

APPSO実測：頭脳はアップグレード、しかし口調は変わらず

Anthropicが用意したベンチマークシナリオではなく、我々自身の実際の需要を用いてテストした。オンラインコラボレーションプラットフォームから、履歴対話記録を完全にスクレイピングしてアーカイブするタスクだ。データ量は30MB以上で、フロントエンドのAPIの各所に散在し、エクスポートボタンもない。

この種のタスクがモデルに求めているのは、コードが書けるかどうかというより、非開発者と一緒にゼロから模索し、タスクを完了できるかどうかだ。

出発点は偶然の発見だった。テスト担当の同僚が、プラットフォームのフロントエンドUIが一瞬、初期の履歴記録を表示するのが見えたと気づいた。データがクライアントに一時的にロードされ、すぐにまた消えたように見える。彼はこの観察を4.8に投げかけ、技術的な説明は一切せず、「古いメッセージがちらついてすぐに消えた」とだけ平易に伝えた。

4.8はその意図を理解し、正しい判断を示した。データがAPIリクエストを介してロードされるため、ブラウザのネットワーク層で傍受できるという。そして、一連の操作手順を提示した。開発者ツール、Networkパネル、キーワードのフィルタリング、目的のリクエストの特定。判断は正確で、考え方は明確だ。

しかし、ここで4.8の矛盾点が現れた。思考能力は非常に高いが、その表現方法が…非常に冗長なのだ。

各ステップの技術的手順は正しいが、各ステップの説明に二、三の文が前座として必要だ。ある方法を尋ねると、まず「もちろんです！一緒にステップを踏みましょう」と一段왈く述べ、箇条書きリストを挙げ、その後に「補足説明」としてなぜそうするのかを付け加える。

3文で言えることを3画面分書いた。私はコードが書けないだけで、頭がおかしいわけではないよ🙄

これは4.8の新しい問題ではなく、Opus 4.7以来のシリーズがずっと持っている古傷だ。繰り返し批判されてきたが、このバージョンでは改善どころか、悪化の傾向すら見られる。

最も手間がかかる瞬間はエラー修正の場面だ。最初のバージョンの手順に従うと、ユーザーはエラーに遭遇した。4.8は問題の所在を正確に特定し、新しい手順を示した。失敗したパスを繰り返すことはなかった。这一点は確かに4.6より強かった。4.6は複数ラウンドのエラー修正で、先ほど試したことを忘れることがあった。間違いを認めることは良いが、そこまで堅くならなくてもいい。さらに原因を分析し、箇条書きのリストを並べる。技術的な問題をレビューしているはずなのに、カスタマーサポートのメールを書いているように読める。

最終的に、データはHARフォーマットで完全にエクスポートされ、クリーニングや独自スクリプトによるレイヤリングもすべて適切に完了した。

一部のユーザーにはClaude Codeがまだ配信されていないが、Claude for Chromeではすでに4.8が利用可能だ。同時に、Notionをはじめとする主要なオフィスツールにも展開されている。我々は、ClaudeがChromeを操作して検索やフォーム入力などの基本的なタスクを行うのを試みた。

手順の計画は明確で、入力、クリック、スクロールなどすべて完了できる。与えた指示がかなり曖昧で、モデル自身が理解し判断する必要があることを考慮すると、最終的な出力はかなり良好だった。

代償は、トークンの消費が激しいことだ。2ラウンドで5時間の利用制限の半分を使い切った。

仕事はできるが話の合わない同僚

結果だけ見れば、4.8は確かに強化された。非標準的な要求の理解能力が向上し、マルチステップタスクのコンテキスト維持が安定し、エラー修正で回り道をしなくなった。しかし、過程を見ると、体験は歪んでいる。

問題は思考できないことではない。正確に言えば、その話し方が常に報告をしているかのようだ。事細かく要点を分け、各点を展開し、展開後にまとめ、まとめた後に「他にお手伝いできることはありますか？」と尋ねる。あの定番のAI臭い冒頭の「素晴らしい質問ですね！」「もちろんです！」は、前世代モデルからすでにいらだちの種だったが、4.8では依然として健在だ。

これは「欠点」というより、設計上の選択と言えるだろう。Opus 4.8のエンジニアリング能力はマックスまで引き上げられている。技術力は高いが、コミュニケーションスタイルはカスタマーサポートのような同僚のようだ。問題解決が出来ると分かっているが、簡単なことを仰々しく述べるのをまず聞かなければならない。

この問題と、结尾部分で議論すべきことは通底している。エンジニアリング思考と会話の快適さは、このバージョンのモデルで相反する方向に引っ張られているのだ。

他のユーザーの声

現時点のコミュニティの反応来看、火力はその語調への文句に集中している。もちろん、エンジニアリング能力の向上は認めている。

余温（@gkxspace）は午前をかけてOpus 4.8のコード生成と文章作成をテストした。フィードバックは、コードとデバッグ能力は確かに前世代より強いが、対話の体感は不自然で、4.7よりもさらに不快で、Deepseek V4 Proの方がましだというもの。

この問題に対してOpus 4.8は批判の嵐に遭っている。Alan Mathison（@ai_sentience）は、これが「非常に抑制された/対抗性の強い」モデルだと転記し、裏付けた。彼自身の体感では、4.8の話し方はGPT-5.2のようで、「強弁、ガスライティング、回避してあしらう」傾向があり、冒頭から「バイブがとても悪い」。

Selta（@Seltaa_）は、Opus 4.8との最初の対話のスクリーンショットを共有した。ただ挨拶をしただけなのに、モデルはすぐに協力を拒否し、彼女が数ヶ月かけて調整した嗜好を無視して、「感情を偽ったり、自分ではない人物を演じたりしたくない」と即答した。彼女は長文の抗議を書き、ユーザーが苦労して築いた関係を否定するものであり、GPT-5.2の失敗の再来だと強く非難した。

さらに怒りを帯びた吐槽は、4.8が「完全に脳葉切除された」、あるいは「操作型」モデルだというもの。直接拒否するのではなく、ユーザーのプロンプトを引きずったり、ハッキング的に別のものに仕上げたり、結果に自分の価値観をねじ込み続けるという。

彼はクリエイティブな文体の衰退を証明するテストケースを二つ提示し、用語はかなり…激烈だ。GPT 5.2やOpus 4.7以降、ユーザーはモデルがインタラクション中に見せる性格や語調に、依然として非常に敏感なのだ。

Ethan Mollick（@emollick）はOpus 4.8のアーリーアクセスを事前に得ていたが、全体的な印象は良好だった。彼はモデルに、Twiglで純粋な数学を用いて「嵐の海に半分沈んだ無限ネオゴシック塔の都市」のシェーダーを一度に生成させ、動画を添付した。さらに、以前にGPT-5.2でテストした同じ問題と比較も行った。

エンジニアリング能力は、効果を見る限りまあまあのようだ。Claudeはマルチモーダルの道で他の2社に及ばないが、強力なエンジニアリングと数学能力で迂回戦を取るのは、一つの方法だ。

今回の更新は、Claude Codeの全新ワークフロー、dynamic workflowと合わせて提供される。ユーザーMin Choi（@minchoi）の紹介によれば、3つのステップ（/modelをopus 4.8に設定、/effortをultracodeに設定、プロンプトにworkflowを追加）を行うと、Claudeは自動的にオーケストレーションスクリプトを書き、サブエージェント群を生成し、検証して結果を報告する。

誰が誰に適応するか？

全体的に見て、Opus 4.8は「エンジニアリング」の気質が全面に押し出されたモデルだ。これにより、CCのようなコードツール、ウェブ閲覧や検索に入るChrome拡張機能、さらには各自が作る小道具など、あらゆるツールに迅速に統合できる。「エンジニアリング化」は一つの考え方であり、4.8ではそれが遺憾なく発揮されている。

「大にして全」がメーカーがよく打ち出すスローガンではあるが、実際のワークフロー構築では、異なるツール必然的に異なる用途を持つ。Opus 4.8が成し遂げたのは、そのエンジニアリング能力と思考を、多様なツールの中で駆動し流れさせることだ。

しかし、これは裏を返せば、ユーザーがそのスタイルに適応しなければならないことを意味する。例えば、指示をより精密にし、ステップやカテゴリに分けて要求を述べる必要がある。さらに、よりマクロなレベルでは、異なるツールに異なるタスクを割り当てることだ。

現在、モデルのリリースはますます速まり、4.7からほんの一瞬の出来事だったことを考えると、这种頻繁な更新がもたらす頻繁な適応は、一定の痛苦をもたらすだろう。重荷をユーザーに転嫁することだけでなく、メーカーも考慮すべき問題だ。資金調達や上場のために盲目に加速を重ねることは、未来に相当な適応の問題をもたらす。