アンソロピックがOpus5.5の公式ガイドを公開し、claude code経由での開発自動化が一段進んだ。ハッカーニュースで81ポイントを集め、現場は沸いている。だが、仕様書を書けば勝てるという物語の裏側で、企業が見落としている構造的リスクを指摘しておきたい。熱狂の前に、冷水を一杯。
何が起きたか
本日、アンソロピックが「Getting the most out of Opus 5.5 in Claude and Claude Code」と題した公式ガイドを公開した。Opus5.5は仕様書を与えればコードを生成し、テストまで自走する上位モデルで、開発者向けツールclaude codeから直接呼び出せる。ガイドの核心は3点。第一に、要件を曖昧に投げず仕様書として渡すこと。第二に、大きな指示を分割し小タスクに刻むと成功率が3倍に跳ね上がること。第三に、スターエンジニア依存から脱却できる平準化効果。ハッカーニュースでは81ポイント、39コメントが集まり、使い方論争が勃発。同時に「ユーザーの絶賛が広がると、アンソロピックが性能を弱体化させるのでは」というお馴染みの懸念も噴出した。
なぜこのニュースが重要か
重要なのは、モデルの性能向上そのものではない。「仕様書を書ける組織が勝つ」という前提が、ほとんどの日本企業にとって致命的だということだ。要件定義を外注SIerに丸投げしてきた発注体質の企業が、いきなり精密な仕様書を自前で書けるようになるわけがない。claude codeは月間検索24万回という巨大な注目を集めているが、ツールが強くなればなるほど、使う側の「仕様記述力」という旧来のボトルネックが可視化される。つまり、Opus5.5は救世主ではなく、組織のドキュメント文化の貧弱さを白日の下に晒す「診断装置」だ。さらに、小タスク分割で成功率3倍という数字は裏を返せば、分割せずに投げれば従来通り失敗するということ。トークン消費量も比例して増えるため、「生産性は上がったがAPI請求書が3倍になった」という笑えない事態は推定で確実に起きる。
過剰評価への反論
「スターエンジニアが不要になる」という3つ目のメッセージは、特に危険な誤読を招く。現実はむしろ逆だ。Opus5.5が出力するコードをレビューし、仕様書の粒度を設計し、分割タスクのアーキテクチャを決める人間が必要になる。これは中堅エンジニアの仕事ではなく、まさにスターエンジニアの仕事だ。採用戦略の見直しとは「ジュニアを増やせる」ではなく「上位1割の設計者により高い報酬を払わねばならない」という意味に反転する。平準化されるのは実装工程だけで、設計工程の属人性はむしろ強化される。
もう一点、現場から出ている「性能弱体化懸念」は陰謀論ではなく構造的必然だと見ている。推論コストの高いOpus級モデルは、ユーザー数が増えれば増えるほど単位コストが経営を圧迫する。アンソロピックはAWSから巨額出資を受けているとはいえ、無限に赤字垂れ流しはできない。リリース直後が性能ピークで、半年後には静かにレスポンス品質が落ちる——これはGPT-4でも観測された現象で、Opus5.5も推定で同じ道を辿る。「今日動いたプロンプトが3ヶ月後に動かない」という前提で業務設計すべきだ。公式ガイドは今日のベストプラクティスであって、明日の保証ではない。
経営者として次に取るべき動き
第一に、claude code導入より先に「社内の仕様書を書ける人間」を棚卸しせよ。モデルを契約する前に、要件を言語化できる人材が何人いるか数えるのが先だ。ゼロなら、ツール導入は金をドブに捨てる行為になる。第二に、API利用料の上限アラートを必ず設定し、月次でトークン消費と成果物の相関を測定する体制を組め。小タスク分割推奨は、そのままコスト膨張リスクでもある。第三に、Opus5.5への依存度を意図的に50%以下に抑え、GPTやGeminiとのマルチモデル運用を前提にせよ。単一ベンダー依存は、価格改定一発で事業が傾く。熱狂は無料だが、依存は高くつく。