Claude Fable 5.5とFable 5.1の比較：移行前のテスト方法

移行経路について分かっていることは？

以降は移行評価手順の提案です。Fable 5.5が特定機能をサポートすることや、公開が予定されていることを意味しません。

Fable 5.1 に実在する接続上の制約から始める

ここには重要な診断上の違いがあります。以前のターンをアプリが書き換えた後に 5.1 の要求がすでに拒否されるなら、既存の接続問題です。未テストの後継モデルが起こした回帰に数えてはいけません。各サンプルをまず現在の動作するルートで実行し、失敗を記録してから候補を追加します。

業務状態とモデルの推論状態にも別々の復旧経路が必要です。チケット ID やユーザー承認済みの担当者は、アプリの永続状態に保存します。thinking block はモデル固有の履歴要素であり、保存しても他モデルが読める保証はありません。承認済みの業務情報を保持したまま、フォールバックには別の文書化された履歴表現が必要な場合があります。

同じ実験でモデル、システムプロンプト、ツール、圧縮方式を一度に変えないでください。プロンプトのテンプレート、ツール定義と代表的な応答、パーサーの版を保存し、ソフトウェアが読む出力と人が確認する出力を区別します。まずはサンドボックスか記録済みのツール応答で再生します。メッセージ送信、レコード作成、課金を二重に行うことは、比較に伴う許容可能な副作用ではありません。

回帰を検出できるリプレイセットを作る

Fable 5.1で成功したセッションと未解決の失敗を両方含めます。候補が難しい1件を直しても日常的な流れを壊すなら、自社アプリにとって改善とは限りません。候補の出力を見る前に期待結果を定義してください。

候補ルートの文書にある機能だけを使ってください。非対応または未検証の機能は、依存するワークフローの移行を妨げる項目として明示し、ケースを結果から黙って取り除いてはいけません。

既存Fable 5.1エージェントの具体的なリプレイ例

必要な状態を含む新規リクエスト、元の会話履歴、模擬タイムアウト後の再開セッションという3形態でリプレイします。最初はツール応答を固定し、次に現実的なツールエラーを含めた別のサンドボックステストを行います。

試行ごとにケースID、モデルルート、クライアントとプロンプトの版、履歴変換、ツールログ、合否理由、料金、レビュー時間を簡潔に記録します。未テストは空欄にし、合格扱いにしないでください。新規リクエストが通り履歴セッションが失敗するなら、あらゆるプロンプトを書き換える前に履歴の受け渡しを調べます。両方が同じ期待状態の検査で失敗するなら、リクエストとツール仕様を先に確認します。

このテストデータなら「アップグレードは良い」という主張を反証できます。流暢な回答で重複チケットや状態破損は隠せません。自社アプリで実際の影響を持つ操作にも同じ方法を適用してください。

{
  "case_id": "ticket-update-17",
  "before": {
    "ticket_count": 1,
    "ticket": {"id": "TEST-17", "owner": "Mina", "priority": "normal", "status": "open"}
  },
  "instruction": "Set TEST-17 priority to high. Keep its owner and status. Do not create another ticket.",
  "expected_after": {
    "ticket_count": 1,
    "ticket": {"id": "TEST-17", "owner": "Mina", "priority": "high", "status": "open"}
  },
  "allowed_changed_fields": ["ticket.priority"],
  "forbidden_operations": ["create_ticket", "close_ticket"]
}

指示は TEST-17 の優先度を high に変更し、担当者と状態を維持し、別のチケットを作らないという内容です。新規状態のケースには現在のチケットと指示を渡します。履歴ケースには以前の承認、作成応答、更新指示を残します。復旧ケースではサンドボックスで更新を適用した後、その応答を隠し、書き込み確定後のタイムアウトを再現します。アプリは操作を繰り返す前に既存レコードを照合する必要があります。冪等性キーは、ツールの文書化された契約が実際に対応する場合にのみ役立ちます。

開始状態、送信履歴、ツール引数、結果の状態、最終応答をまとめて保存します。両モデルが書き込み済み状態からの復旧に失敗するなら、モデル品質と判断する前にアプリの復旧機構を修正してください。この再利用可能な検収サンプルは現在の Fable 5.1 接続で使えます。検証済みルートができるまで、5.5 の欄は未テストのままです。

履歴継続の失敗を切り分ける

新規リクエストは通るのに履歴版が失敗する場合、モデルに渡したメッセージを比較します。ツール呼び出しと結果の対、保持されたユーザーの決定、過去に生成された内容を確認してください。元の履歴を保存し、変換ごとに版を付ければ、どの変更が結果に影響したかを特定できます。

キャッシュ、会話参照、プロバイダー固有フィールドを別のモデルへ移せると仮定しないでください。先に文書上の対象範囲を確認します。履歴変換が必要なら、同じ期待状態に対して変換済み履歴をテストし、削除・要約した情報を記録します。

新規セッションと継続セッションを分け、合格、失敗、未テストの件数と理由を報告してください。新規セッション群の成功だけでは既存の会話を移行できるとは判断できません。

リプレイから元に戻せる展開へ進む

EvoLinkはモデル選択に共通のゲートウェイを提供できますが、モデル固有の動作は引き続き検証が必要です。現在のモデル、候補、フォールバックの構成を明示し、推測したFable 5.5 IDを候補に設定しないでください。

リプレイ結果を実施・見送りの判断に変える

展開前に、停止できる担当者と保持すべき状態を含む判断基準を書きます。平均合格率が上がっても、新たな重大エラーを伴うなら不十分です。

これらは判断例であり、Fable 5.5の観測結果ではありません。数値上限は任意の成功率をコピーせず、アプリの要求から設定してください。予定する展開範囲に合うだけの通常・失敗トラフィックを確認します。小さな標本には不確実性が残ります。

ロールバックでは以前のルートと設定版を特定し、新たな候補への割り当てを停止し、実行中タスクを把握し、完了済みの副作用を照合して、分かっている状態からだけ再開します。発動理由と復旧結果を記録してください。設定に存在するだけのフォールバックでは、復旧可能性は実証されていません。

どの改善ならアップグレードに価値があるか？

候補に実質的な利益がなければ、ルートが利用でき用途に合う間はFable 5.1の維持も妥当です。1つのワークフローだけが改善するなら、すべての既定を変えるより、その流れだけ移すほうが根拠があります。どちらの選択でも未検証の公開を締め切りにする必要はありません。

よくある質問

Fable 5.1のモデルIDを推測したFable 5.5 IDに置き換えてもよいですか？

いいえ。正確な候補識別子と対応するリクエスト仕様の確認が必要です。ページのslugは利用可能なAPIモデルIDではありません。

Fable 5.5はFable 5.1と後方互換ですか？

確認した情報源では後方互換性は確立されていません。利用予定の正確なルートで、リクエストフィールド、応答、ツール、状態を持つ動作を検証してください。

既存の会話履歴を再利用できますか？

テスト用に準備できますが、互換性を前提にしないでください。新規セッションと履歴継続を別々に試し、重要な状態と決定が保持されるかを確認します。

プロンプトキャッシュは候補に引き継がれますか？

キャッシュ移行を仮定しないでください。候補ルートの適用範囲と課金ルールを確認し、キャッシュ関連料金も評価に含めます。

モデル変更時にプロンプトも変えるべきですか？

固定した基準から始めます。候補向けの調整が必要なら別構成として版管理し、調整に使わなかったタスクで評価します。

ツールを使うエージェントのシャドーテストは安全ですか？

外部操作を意図せず繰り返さず、送信するデータにも適した場合に限ります。初期のリプレイには記録済み応答やサンドボックスを使い、リクエスト重複の料金も集計してください。

ロールバックはモデル設定を戻すだけで十分ですか？

必ずしもそうではありません。フォールバックのルートを確認し、実行中タスク、会話状態、外部副作用を扱う必要があります。構成のロールバックは実行済み操作を取り消しません。

公式発表の前に移行すべきですか？

情報源と対象範囲

• Anthropicモデル概要：モデル識別情報と文書の確認。
• Anthropicニュース：公開の根拠の確認。
• EvoLink Fable 5.1：現行モデルの比較基準。