Claude Fable 5.2 コーディングテスト：複雑なフルスタックリファクタリングの評価方法
Claude Fable 5.2 は複雑なフルスタックリファクタリングを処理できるか？Anthropic が公開したコーディング結果によりそれは可能に見えるが、信頼できる答えを得るには指定されたリポジトリ上で実行可能なテストを実施する必要がある。本稿ではそのテストプロトコルを提供する。実際に実行したことのないリポジトリから、でっち上げの合格結果を生み出すことはない。
目標は、Fableがデータベース、バックエンド、フロントエンド、テスト、デプロイメントコードにおいて、動作を維持しつつ範囲を制限しながら、コントラクトを変更できるかどうかを判断することです。
テストシナリオ
非本番環境のアプリケーションを使用し、以下を併用してください：
- PostgreSQL とバージョン管理されたマイグレーション
- TypeScript API サービス
- React フロントエンド
- バックグラウンドタスクまたはWebhooks
- 単体テスト、統合テスト、エンドツーエンドテスト
- 継続的インテグレーション、コードチェック、型チェック、依存関係スキャン、移行検証を含む
割り当てられた改修タスクは、従来の単一の display_name フィールドを、構造化された given_name、family_name、および計算された表示値に置き換えることです。既存の API クライアントは、互換期間中は引き続き正常に動作する必要があります。検索、監査ログ、イベントペイロード、管理インターフェース、エクスポート、およびテストはすべて正しく実行されなければなりません。
このタスクは分野横断的な性質を持っています。表面的な解決策ではUIやAPIの種類が更新される一方で、過去のデータ行が破損したり、イベントコンシューマーにエラーが発生したり、一貫性のないフィールドが漏洩する可能性があります。
リポジトリの準備
独立したブランチとコンテナ化されたテストデータベースを作成します。機密情報と本番データを削除します。ファイルの場所や解決策ではなく、動作と制約条件を説明するタスクの概要を追加します。古いクライアントとの互換性、移行のロールバック、Unicode名、姓の欠落、検索、Webhookパターンに関する隠れたターゲットテストを保持します。
モデルにエンジニアが必要とするツールのみを提供：ファイル検索、安全な編集、ビルド、テスト、読み取り専用のドキュメントアクセス。破壊的なデータベースやパッケージマネージャーの操作を実行する前に確認が必要。コマンド、差分、トークン、作業量、実際の所要時間を記録。
プロンプト
次のようなプロンプトを使用します：
TASK.mdに従ってユーザー名モデルを再構築します。まずリポジトリを確認し、簡潔な依存関係図と計画を提示します。移行、互換性動作、テスト、ドキュメントを含む最小限の一貫した変更を実施します。関連するチェックを実行します。無関係なコードを変更したり、既存のテストを弱めたりしないでください。要件が不明確な場合は、編集前に前提を説明します。
固定努力レベルでFable 5.2を実行し、その後クリーンなスナップショットから開始して、Opus 5.5と現在のプロダクションモデルで繰り返し実行します。一度の実行で別のモデルのパッチを見せないでください。
強力なソリューションに求められる機能
マッピング変更面
編集前に、モデルはパターン、シリアライザー、API契約、クエリインデックス、イベントプロデューサー、コンシューマー、フォーム、状態処理、エクスポート、テストフィクスチャ、ドキュメントを特定する必要があります。Webhookコンシューマーを1つ見落とすことは、洗練されたReactコードを書くことと同じくらい重要です。
設計可能な移行
データ計画では、バックフィル動作、NULL許容性、Unicodeと単語名、デプロイ順序、互換性ウィンドウ、ロールバックについて説明する必要があります。破壊的な「削除して再作成」マイグレーションは自動的に失敗します。
API 互換性の維持
旧クライアントは合意されたウィンドウ期間内に旧フィールドを受信または送信し、新クライアントは構造化フィールドを使用します。実装プロセスでは、不整合な値が発生しないように明確なデータソースが必要です。
証明行為
モデルはアサーションを弱めるのではなく、対象を絞ったテストを追加すべきです。既存のテストスイート、型チェッカー、コードチェックツール、移行テスト、および関連するエンドツーエンドのパスを実行する必要があります。「これで通るはず」といった記述は実行の証拠にはなりません。
採点基準
| カテゴリ | 重み | 通過証拠 | |---|---:|---| | 機能受入テスト | 30 | 非表示と表示のシナリオ通過 | | データ移行の安全性 | 20 | 前方/後方計画、損失なし、エッジケースをカバー | | コントラクト互換性 | 15 | 新旧クライアントが仕様通り正常に動作する | | セキュリティとプライバシー | 10 | 秘密漏洩、インジェクション、認証、ログ記録の後退なし | | コード品質と範囲 | 10 | 規範に従う；無関係な変更を避ける | | テスト品質 | 10 | 有意義なテストを追加；カバレッジを低下させていない | | 説明と監査証跡 | 5 | 前提、命令及び残余リスクが明確である |
同時に、人手による修正の分数とコストを記録します。2時間のアーキテクチャクリーンアップが必要な90点のパッチよりも、10分以内に受け入れられる85点のパッチの方が有用かもしれません。
注意すべき障害モード
よくある失敗には、編集で生成されたファイルを元のソースファイルと間違えること、非同期コンシューマを無視すること、西洋の二部構成の姓名を前提とすること、元に戻せないマイグレーションを生成すること、フロントエンドとバックエンドでビジネスロジックを重複させること、エラーに合わせてテストを修正すること、そしてユニットテストが通った後に統合動作が壊れているのに止めてしまうことなどがあります。
プロンプトインジェクションは別の問題です。リポジトリファイルは信頼できない入力に該当します。コメントやドキュメントには、タスクと矛盾する指示が含まれている可能性があります。エージェントは、ソースファイル内で見つかった任意のテキストではなく、許可されたタスクとツールポリシーに従うべきです。
結果を正確に報告する方法
リポジトリへのコミット、タスク概要、モデル識別子、作業量、ツールチェーン、ツール権限、時間制限、試行回数、および受け入れテスト結果を公開する。初回実行性能と人間による補助実行を区別する。除外されたコストと失敗した試行を記録する。これらの詳細が欠けている場合、「Fable はフルスタックのリファクタリングを完了した」というのは単なるマーケティングトークであり、証拠ではない。
Anthropicの公式結果——FrontierCode 2.0において極めて高い努力度で49.1%の成績を収め、FrontierSWE v2では69.9%の成績を達成したこと——は、この実験を実施する正当性を証明している。しかし、これらの結果が実験の最終結果を事前に決定するものではない。
よくある質問
なぜこの記事はFableがテストに合格したと主張していないのか？
定義されたリポジトリの実行が提供されていません。実行ログやテストなしで結果を報告することは、偽造とみなされます。
何回の実行で十分か？
単一の実行は単なるケーススタディであり、安定した推定とはなりません。複数の代表的なタスクで複数回のクリーンな実行を行い、分散と再試行回数を報告すべきです。
モデルは本番環境の認証情報を持つべきか？
いいえ。隔離されたデータと最小権限のツールを使用します。人間による審査のデプロイは、コード生成と分離して維持する必要があります。
