「指示を削除すればいい」というアドバイスは、私には受け入れられない
Claude Opus 5 はより優れたモデルだが、私のシステムでは質の低い成果を生み出す。コンセンサスとなっている修正方法は、このシステムを価値あるものにしている要素を捨てるよう求めるものだ。
Claude Opus 5 は 7 月 24 日にリリースされた。重要なベンチマークのすべてで、Opus 4.8 を上回っている。SWE-bench Pro は 69.2% から 79.2% に向上した。Anthropic 独自のフロンティアコーディングベンチマークは 2 倍以上になった。
私はビジネス全体を Claude Code で運営している。6 つのドメインにまたがる数十のプロジェクト、約 30 のカスタムスキル、メモリシステム、スケジュールされたメンテナンスエージェント、そして何ヶ月にもわたって問題が発生したことで得られたハードルールがある。私が 1 文字も入力する前に、約 20,000 トークンのコンテキストが読み込まれる。
4 日間使ってみて、私はこのモデルでは仕事ができなかった。2 回の完全なセッション — クライアントサイトと SaaS プロダクト — で、私がリリースできない出力が生成された。
私は今、これについて書かれたもののほとんどを読んだ。そして、コンセンサスとなっている修正方法は驚くほど一貫している：指示の足場を削除しろ。Anthropic は Claude Code のシステムプロンプトの 80% を削減した。Every の CEO はスキルを削除し、「劇的に改善した」と報告した。
私はそのアドバイスが自分には通用しないと思う。そして、その理由を慎重に説明したい。なぜなら、多くの人が削除したことを後悔するだろうと思うからだ。
壊れた 3 つのこと
自信満々に間違える。 Anthropic 自身のシステムカードから：
「このモデルは、Opus 4.8 よりも全体的には正確であるにもかかわらず、事実に関する主張の幻覚をわずかに多く発生させる」
もう一度読んでほしい。全体的にはより正確で、幻覚はより多い。これらは矛盾していない — この 2 つが組み合わさって、まさに日常的な使用感を表している。同じ文書は、モデルが「実際には確信が持てない回答を自信満々に述べた」と指摘している。明らかに間違っているモデルはコストがかからない。確信を持って間違っているモデルはコストがかかる。なぜなら、チェックしなくなるからだ。
仕事が完了する前に止まる。 Kieran Klaassen 氏、自律的なフローを実行中：
「ユーザーにコントロールを返し続けた。自律的なフローなのに。これは非常に困る」
それは私が見たものと一致する。タスクが実行されるのではなく、形を変えられ、部分的な作業が完了として報告され、以前のモデルがただ実行していたことに抵抗する。
話しすぎる。 3 つのうち最もよく文書化されている問題で、Anthropic 自身の移行ガイドで繰り返し認められている：
「デフォルトの可視応答と作成された成果物は、Claude Opus 5 の方が以前の Opus モデルよりも長くなり、エフォートを下げると思考量は減るが、可視応答の長さが確実に短くなるわけではない」
後半に注目してほしい。エフォートパラメータはこの問題を解決しない。
誰もが同意するメカニズム
ここから、私の見方が変わった。Anthropic のエンジニアリングブログ記事（Opus 5 がリリースされた日に公開）から：
「私たちは Claude Code を過度に制約していた。システムプロンプトだけでなく、CLAUDE.md ファイルやスキルにおいても」
彼らはシステムプロンプトの約 80% を削減した。Dan Shipper 氏は、Opus 5 が「既存のスキルやプラグインとうまく連携しなかった」と報告し、それらのスキルを削除することで「劇的に改善した」と述べている。João Queirós 氏：「シンプルなプロンプトの方が、成熟した指示重視のワークフローよりも有望な結果を生み出した」。
4 つの独立した情報源とベンダー自身が、同じ変数を指し示している：蓄積した指示の足場が多ければ多いほど、このモデルのパフォーマンスは悪くなる。
これはまた、議論が全会一致ではなく意見が分かれているように見える理由も説明している。CLAUDE.md が 12 行なら、Opus 5 は間違いなく優れており、批判派は大げさに見える。しかし、システム構築に何ヶ月も費やしてきたなら、まったく異なる会話をしていることになる。
コンセンサスアドバイスが機能しない理由
では削除すればいい、と誰もが言う。問題はここにある：私の指示は単一のものではない。テキストファイルでは同じに見えても、本質的にまったく異なる 2 つのものがある。
補償。 モデルの弱点を打ち消すために存在する指示。「作業をダブルチェックする」「デフォルトで委任する」— これは以前のモデルが委任不足だったときに書いたものだ。「続行する前に要約する」。これらは文字通りの意味での足場である：建物の隙間を埋める一時的な構造物。
補償は削除しても安全であり、Opus 5 はそれらの多くを実際に不要にしている。プロンプトなしで自己検証する。積極的に委任する。問題ない。削除すればいい。
憲法。 他のどこにも存在しない事実と基準。グリーンビルドが過去に私を騙したことがあるので、証明とは本当の WebKit と HTML 内のマーカー文字列を意味し、HTTP 200 ではない。どのホストがどのプロジェクトの背後にあるか。どのクライアントがゲートされていて、どのクライアントがされていないか。このブランドのタイポグラフィに何が許されているか。どの障害クラスが私に最もコストをかけ、それに対して具体的に何が防御するか。
これは小言ではない。これは情報だ。 そして、モデルの品質がどんなに高くても推論できない。なぜなら、それは推論の問題ではなく、私のビジネスにのみ存在する知識だからだ。より賢いモデルがそれをよりよく推測するわけではない。より自信満々に推測するだけだ。
コンセンサスアドバイスはこれらを区別しない。「指示を削除しろ」と言い、人々は両方を削除するだろう。なぜなら、マークダウンファイルでは同じに見えるからだ。
私がそれをやったからわかる。移行ガイドに従って、done-gate から検証指示を削除した。「作業をチェックする」が今は冗長だというガイドの指摘は正しい。しかし、私は自分のスタックで何が証明となるのかという定義も削除した — そして、検証の錯覚は、はるかに私の最もコストのかかる繰り返しの失敗だ。私は、一般的な推奨事項に従ってトリミングするように言われたからといって、自分自身の最悪の失敗モードに対して特別に構築されたガードレールを削除したのだ。
さらに 2 回のセッションの後、私はすべてを元に戻した。
私が実際に主張したいこと
どこでも、Opus 5 はより少ない指示を必要とするという枠組みで語られている。私はそれが起きていることの誤った説明だと思う。
Opus 5 は指示のもとで動作するのが苦手だ。 そして、あるクラスのユーザーにとって、指示のもとで動作することはオーバーヘッドではなく、仕事のすべてだ。
私は良い汎用コードを書くモデルにお金を払っているわけではない。そんなものは今やどこでも手に入る。私がお金を払っているのは、慣習、コンプライアンス要件、ブランドルール、クライアント固有の制約、そしてここで過去に何がうまくいかなかったかの文書化された履歴を持つシステムに適合するコードを書くモデルだ。制約を取り除けば、私のアウトプットは向上しない。モデルがより快適になり、私のアウトプットがより汎用的になるだけだ。
だから、「スキルを削除すれば劇的に改善する」と読むとき — 何に対して改善するのか？制約のないコーディングの流暢さに対しては、おそらく。私のシステムに適合する成果を生み出すことに対しては違う。なぜなら、成果を私のシステムに適合させるものは、まさに削除されたものだからだ。
私は約 90% の確信を持って言える：Opus 5 に私の指示の足場がない状態では、私がそれを使って得られる品質には決して達しない。モデルが弱いからではなく、欠けている要素が知能ではないからだ。それは私のビジネスに関する知識であり、いかなる量の生の能力もそれに代わるものではない。
私がやっていること、そして提案したいこと
私は Opus 4.8 に戻し、以前のセットアップをバイト単位で完全に復元した。抗議としてではない — それが機能し、私には締切があるからだ。
Opus 5 がより劣ったモデルだと言っているわけではない。ベンチマークは現実的であり、私が尊敬する人々が実際の改善を報告している。そして私は 2 つの変数 — モデルとセットアップ — を同じ日に同時に変更したので、自分の結果をきれいに特定することはできない。それは私の証拠の実際の限界であり、レトリックのための逃げ道ではない。
私が主張しているのはもっと狭い範囲だ：より優れたモデルが成熟したシステムでより質の低い成果を生み出すことがあり、その失敗は沈黙している。 エラーは何も起きない。何も警告しない。あなたの指示が、以前とは異なる意味を持つようになるだけだ。
もしこれに直面しているなら、私が今使うであろう手順は次の通りだ：
- 削除する前に分類する。 指示をすべて見直し、それぞれにマークを付ける：これはモデルの弱点を補償しているのか、それとも私だけが知っていることなのか？この 1 回のパスが、どんなトリミングのヒューリスティックよりも価値がある。
- 補償は自由に削除する。 特に、モデルに検証、委任、要約を指示するもの。そのアドバイスは正しい。
- 憲法は守る。 ドメインの事実、証明の定義、ブランド基準、クライアントの制約。もし行を削除したら、有能な新入社員が間違った成果を生み出すことになるなら、それは残す。
- 一度に変更する変数は 1 つだけ。 モデルかセットアップか、両方ではない。私はこれを破り、何も特定できなくなった。
- ロールバック可能にする。 1 つのコミットで、ロールバックが大まかではなく正確になるようにする。
- 自分自身の文書化された失敗パターンは、どんなベンダーの一般的なアドバイスよりも優先される。 これはどこかに刺青したいくらいだ。
厄介なのは、補償と憲法は、自分で書いたときには同じように感じられることだ。私のシステムのすべてのルールは、何かが一度うまくいかなかったために存在する。後でそれらを区別することが実際の作業であり — 「ただ削除すればいい」というのは、誰もが保持する価値のあるものを持っていないと暗に仮定している。
出典：Claude Opus 5 システムカードおよび移行ガイド（Anthropic、2026 年 7 月）；Anthropic エンジニアリングブログ、2026 年 7 月 24 日；Dan Shipper 氏および Kieran Klaassen 氏（X 経由、2026 年 7 月）；João Queirós 氏、2026 年 7 月。
