ApidogでClaude Fable 5.2 APIをテストする：回帰テストの方法

Claude Fable 5.2 API の連携をテストするには、認証、Messages リクエストボディ、型付きレスポンスブロック、そして予測可能な失敗パターンを検証します。その上で、これらのチェックを再実行可能な Apidog テストケースとして保存し、コーディングエージェントに CLI 経由で実行させましょう。HTTP レスポンスの成功が使いものにならない回答を隠してしまわないよう、トランスポートの検証とタスク品質のチェックは分けて管理してください。

Anthropic の発表によると、Claude Platform におけるモデル ID は claude-fable-5-2 です。このガイドでは、1 回の成功レスポンスで終わらせるのではなく、このモデルを中心にリグレッションワークフローを構築します。Apidog があれば、エンドポイント、テストケース、実行レポートを一元的に管理できるため、エージェントの作業場所として共有できます。

Claude Fable 5.2 API のテストでは何を検証すべきか？

テストは 3 つのレイヤーで構成します。トランスポートチェックはリクエストがサービスに到達したかを確認し、コントラクトチェックはレスポンス構造を検証し、動作チェックはその結果をアプリケーションが利用できるかを確認します。最初の 2 つはすべてのフィクスチャに対して実行します。動作の合否基準はタスクごとに定義し、生成された回答全体をバイト単位で比較するようなことは避けましょう。

まずは小さくて無害なフィクスチャから始めましょう：「2 + 2 は何ですか？数字のみで回答してください。」これにより、ファイル、ツール、会話履歴を絡めずに、合否ルールを明確に確認できます。基本のコントラクトが正しく動作することを確認したら、アプリケーションを代表するフィクスチャを追加していきます。

このフィクスチャを推論能力のベンチマークとして扱わないでください。目的は、思考ブロックをユーザー向けテキストとして抽出してしまう、途中で切れたレスポンスを受け入れてしまう、といった連携上のリグレッションを検出することです。

テスト前に認証とリクエスト設定を固定する

Claude API に直接アクセスする場合は、Messages エンドポイント、ワークスペーススコープの API 認証情報、明示的な API バージョン、固定したリクエストボディを使用します。これらの入力は実行間で一定に保ってください。API の概要には、Bearer 認証、ワークスペースの選択、バージョンヘッダーが記載されています。これらの設定はクラウドプロバイダーの IAM 認証とは異なります。

Claude Console の API キーは、ローカルのシークレット環境を通じて供給してください。Apidog のアクセストークンは CLI が Apidog に対して認証するためのものであり、Anthropic へのリクエストを認証するものではありません。2 つの認証情報は混同しないようにしましょう。

以下のリクエストは、2026 年 11 月 10 日時点で確認した最新の Messages ドキュメントに沿っています。この JSON を request.json として保存してください：

{
  "model": "claude-fable-5-2",
  "max_tokens": 1024,
  "stream": false,
  "thinking": { "type": "adaptive" },
  "messages": [
    {
      "role": "user",
      "content": "What is 2 + 2? Reply with the numeral only."
    }
  ]
}

次に、ターミナルから送信するか、コーディングエージェントに実行させます：

curl https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2026-10-21' \
  -H 'Content-Type: application/json' \
  --max-time 600 \
  --dump-header response.headers \
  --output response.json \
  --write-out '%{http_code}\n' \
  --data-binary @request.json

キーがワークスペーススコープでない場合は、対象ワークスペース用の anthropic-workspace-id ヘッダーをドキュメントに従って含めてください。認証情報をリテラルのままフィクスチャや生成されたレポートに含めないでください。

Create a Message リファレンスでは、model、messages、max_tokens に加え、返されるメッセージの各フィールドが定義されています。ここでの 1,024 は選択した出力予算であり、ドキュメント上の最小値でも、すべてのタスクが収まるとの保証でもありません。フィクスチャがより多くの容量を必要とする場合は、意図的に引き上げてください。

これはドキュメントで検証済みのテンプレートです。合格となるベースラインを記録する前に、必ず自身の認証済み API アカウントで実行してください。ここでは実際の Fable レスポンスやレイテンシの計測結果は示していません。

生成の揺らぎに耐えるレスポンスアサーションを追加する

まずレスポンスのエンベロープを検証し、ブロックタイプを確認し、テキストを抽出してから、フィクスチャの合否ルールを適用します。Messages のレスポンスには content 配列が含まれるため、content[0].text に回答が入っていると決めつけてはいけません。アプリケーションが後続の会話ターンで元のメッセージを送り返す場合は、完全な元メッセージを別途保持しておいてください。

計算フィクスチャについては、エージェントに次のポストレスポンススクリプトを Apidog テストケースにアタッチさせます：

pm.test("HTTP success", function () {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Assistant message contract", function () {
  pm.expect(body.type).to.eql("message");
  pm.expect(body.role).to.eql("assistant");
  pm.expect(body.id).to.be.a("string");
  pm.expect(body.model).to.be.a("string");
  pm.expect(body.content).to.be.an("array");
});

const text = body.content
  .filter(block => block.type === "text")
  .map(block => block.text)
  .join("\n").trim();

pm.test("Arithmetic fixture is complete", function () {
  pm.expect(body.stop_reason).to.eql("end_turn");
  pm.expect(text).to.eql("4");
});

この意図的に制約された数字の例では、完全一致が理にかなっています。要約タスクであれば、必須の事実、根拠のない主張の禁止、文字数の上下限といった基準を使用します。表現のわずかな違いで、有用な要約テストが失敗するようであってはなりません。

診断のために usage とレスポンスの request-id ヘッダーを記録してください。返されたモデル識別子は、選択した識別子に関するドキュメント上の動作と照合します。フォールバックレスポンスを黙って Fable の結果として再ラベル付けしてはいけません。

max_tokens による停止理由は、回答が出力上限に達したことを意味します。この計算フィクスチャでは失敗とし、トークン予算を確認してください。ツールリクエストを含む他のタスクでは、別の停止理由が正当に返される可能性があるため、ケースごとに独自の完了ルールを設けてください。

Claude Fable 5.2 API のネガティブケースをテストする

無効な入力ごとに個別のケースを作成し、一度に 1 つのフィールドだけを変更します。人間が読める完全なエラーメッセージを照合するのではなく、HTTP ステータスと構造化されたエラータイプを確認してください。有効なベースラインは変更しないことで、ネガティブフィクスチャが次のポジティブ実行を汚染しないようにします。

公式のエラーガイドには、次のような有用なケースが記載されています：

Fable 5.2 は常にオンの思考を使用します。思考を無効化したり拡張思考の予算を設定したりする、古い Claude チュートリアルをコピーしないでください。思考の無効化ケースは、共有リクエスト構築コードをアップグレードする際に特に役立ちます。

各エラーケースでは、body.type === "error" であること、期待される body.error.type であること、そして空でないエラーメッセージがあることをアサートします。可能であればリクエスト ID を保持してください。DNS 障害やクライアント側のタイムアウトは、Claude の JSON エラーを一切返さない可能性があるため、別個の結果として扱ってください。

レート制限やサービス障害に対するアプリケーションの挙動は、制御されたフィクスチャまたはモックでテストしてください。429 を意図的に発生させるために実 API に大量のリクエストを送らないこと。再試行可能なキャパシティ問題と、認証・バリデーションエラーを区別し、アプリケーションのリトライロジックには有限のリトライ予算を設けましょう。

コーディングエージェントに Apidog のリグレッションケースを作らせる

エージェントには、エンドポイント、フィクスチャ、アサーション、対象プロジェクトを与えます。エージェントは最新の CLI スキーマを調べ、各ペイロードを検証し、テストケースを作成して実行できます。あなたは生成されたケースと失敗サマリーをレビューします。これにより、再実行可能なワークフローを Apidog CLI 上に維持できます。

CLI をインストールし、Apidog トークンで認証します：

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_APIDOG_TOKEN>

エージェントのセットアップについては、Claude Code または Codex の最新ガイドに従ってください。そのうえで、エージェントに次の 1 つのプロンプトを与えます：

In Apidog project <PROJECT_ID>, define POST /v1/messages for the
Claude API. Use model claude-fable-5-2 and version 2026-10-21.
Keep the Anthropic credential in a private runtime variable.
Create the arithmetic success case and four negative cases above.
Read CLI help and input schemas before generating payloads.
Discover valid endpoint and category IDs; validate every payload.
Attach the response assertions, then run each case against
<ENVIRONMENT_ID>. Report failures, request IDs, and token usage.
Do not print credentials or claim unexecuted cases passed.

以下のコマンドは、インストール済みの CLI 2.2.12 に対して確認済みです。エージェントには実際のエンドポイント ID とカテゴリ ID が必要です。test-case-create はエンドポイントから派生したケースを扱うため、無関係なスタンドアロンの JSON リクエストを作るだけでは不十分です。

apidog test-case category --project <PROJECT_ID>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <PROJECT_ID> --file case.json
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json

エンドポイントが存在しない場合は、エンドポイントコマンドのヘルプとスキーマをエージェントに確認させてください。別のプロジェクトからコピーした例示用の数字ではなく、返された ID を使用します。case.json は書き込む前に検証し、その後作成されたケースを読み戻して、意図したヘッダー、ボディ、アサーションが保存されていることを確認してください。

Claude API のリグレッションテストを CI で実行する

認証、メッセージのシリアライズ、ブロックのパース、リトライ処理に変更を加えた後は、同じケースを実行します。機械可読なレポートをエクスポートし、フィクスチャのバージョンをアプリケーションの変更とともに記録してください。比較の前に合格ベースラインを確立し、そのうえで失敗を一件ずつ調査します。ビルドがたまたま通るまで再実行を繰り返すようなことは避けましょう。

Apidog に既に作成済みのケースについては、CI 向けの実行コマンドは次のようになります：

apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json,junit \
  --out-dir ./apidog-reports

他のケース ID についても同様に実行するか、エージェントに最新のスイートスキーマに従ってケースをテストスイートへ整理させてもよいでしょう。パイプラインへの組み込みについては Apidog の CI/CD ガイドを参照してください。

実行記録には、モデル、API バージョン、リクエストボディ、出力予算、フィクスチャのリビジョン、CLI バージョンを残してください。認証情報は CI のシークレット機構を通じて管理します。レポートを共有する前に、機密性の高いリクエストデータが含まれていないか確認しましょう。

日常的な変更には小規模なライブスモークセットを、リリース前にはより広範な動作セットを使用します。支出と実行時間の予算は自身で設定してください。API コントラクトの合格は連携の互換性を保証するものであり、出力が有用かどうかはアプリケーション固有の受け入れテストで判断します。

FAQ

どのモデル ID をテストすべきですか？

この Claude Platform に直接アクセスするワークフローでは、claude-fable-5-2 を使用してください。ベースラインを保存する前に、アカウントで利用可能か確認しましょう。

HTTP 200 だけで合格といえますか？

いいえ。メッセージのエンベロープ、型付きコンテンツ、完了理由、フィクスチャの合否基準を確認してください。ストリーミングでは、レスポンスヘッダー受信後に障害が発生しうるため、イベントレベルの追加チェックが必要です。

Fable 5.2 の思考を無効化できますか？

いいえ。Anthropic はこのモデルについて、常にオンの思考をドキュメントに記載しています。思考の無効化は、バリデーションエラーを期待するネガティブケースとして残してください。

すべての回答が完全一致するべきですか？

数字の例のような制約されたフィクスチャには完全一致を使用します。オープンエンドなタスクでは、正当な表現の揺らぎを許容する、事実面・構造面の基準を定義してください。

修正後にエージェントへテストの再実行を任せられますか？

はい。保存済みのケース ID と環境を渡し、同じ CLI コマンドを実行させてレポートを要約させてください。エージェントのセットアップが必要な場合は、Claude Code CLI ワークフローから始めましょう。