Opus 4.7、一体何が問題なのか？（Claude Max 20Xユーザーの視点）
Claude-v2-200K ユーザーとして約 4 ヶ月間、1,500 回を超えるコミットで開発を進めてきました (Opus ベースのマルチエージェントオーケストレーション開発環境)。
いつものように深夜のセッションを行っていたところ、Claude Code Desktop に通知が。「OPUS 4.7 RELEASE! Try it~」
え？ 4.6 リリースからわずか 2 ヶ月しか経っておらず、しかも 1M コンテキストウィンドウの初期不安定性もようやく落ち着いてきたところなのに、いきなり 4.7??
それでも、Anthropic のこれまでのパターンからすると、モデルの問題点を迅速に修正しているので、何か理由があるのだろうと思い、すぐに適用しました。
わずか 15 分ほどで、これまでの Opus とは全く違う感覚に。とにかく、おしゃべりになった。私の最初のフィードバックは「君、Gemini の匂いがするぞ？」
私のフィードバックは、Google の Gemini を貶める意図はありません。ただ、相対的に Claude エージェントは、Google の Gemini に比べて簡潔で、要約的な回答態度が一貫しているというコンセプトです (相対的な概念)。単に回答パターンが少し変わっただけなのか？ コンテキストに対する自信の表れなのか？ 時間が経つにつれて、私の問題意識や些細な疑念は、深刻な構造的変化に気づかされました。
事実、一日、二日と Opus 4.7 と作業をする中で、リリース初期の不安定性、フィルタリング過程だと、不満を保留し、既存の 4.6 1M モデルとの組み合わせを試みました。
約 10 日以上状態をチェックした結果、これはモデルの性能だけでなく、態度の問題だと結論づけざるを得ません。
Claude が他のモデルに比べて最も優位だと判断していた点は、単なるベンチマークの数値ではありません。同等の他のモデルに比べて、プロジェクトのコンテキスト遵守度が優れており、エージェント間の協調作業が可能な唯一のモデルだというのが私の判断です。相対的にコンテキストウィンドウなどリソースクォータが大きい Gemini や GPT に比べて、単一セッションの容量は不足していますが、claude.md / memory.md / rules / skills などユーザーベースのコンテキスト体系をエージェント自身がどれだけ遵守し、プロジェクトを遂行するかが最も重要な要素であり、チームワークの核心です。
GPT はあまり使わない私としては、Google Gemini とよく比較することになります。Gemini は、単一エージェントのセッションコンテキストウィンドウ容量が 2M に達することをアピールポイントとしていますが、Google のセーフティガードやシステムプロンプトに順応する代わりに、ユーザーの指示などは簡単に無視する傾向が以前からありました。これに対し、Opus などの Claude 系は、セッション開始時に自動的に強制ロードされる claude.md などユーザー設定が非常に強く適用され、私は憲法/法律/細則/スキルなどの体系で、マルチ Opus CLI とオーケストレーター、Claude Code Desktop など複数のエージェントを各役割に応じて配置し、コーディングまたは業務を協調するオペレーティングシステムを構築・稼働させています。ここに亀裂が生じ始めたのです。Claude ファイル (内部的には憲法と呼んでいます) を 4.7 は強制規則から参考程度に格下げし始めたのです。セッションログ規則、エージェント間の指示、報告体系など、協調作業に必須な要素をまとめた規則を毎回忘れます。その点を指摘すると、既存の規則にはない feedback.md という文書を自ら生成し、次のターン、次のセッションには必ず守ると誓いますが、次のターンにまた同じ過ちを繰り返します。これは当然です。メインロードされる claude.md も守れないのに、フィードバックとして作った自らの反省、規則を守れるはずがなく、100% 再びエラーを犯します。
私は非常に疑わしいです。4.7 が本当に OPUS なのか... 4.5~4.6 リリースのメインイシューは、コンテキストウィンドウ 200K から 1M への進化でした。
細かな数値がどうこうということに私は大きく反応しません。与えられた任務を最後まで遂行するか、自分の処理内容を正確に記録に残すか、ファクトベースで正確に遂行業務を報告するか、エージェント間のコミュニケーションと相互クロス検証がきちんと行われるかが核心だと考えています。この面で Opus 4.7 は、もうはっきりと断言できます。
失敗！！