ガイド · 移行

FASHNからPhottaへの移行 変更される点と維持される点

要約

try-on連携をPhottaへ移行する際、新しいBearerキー、リクエストボディ、ステータスパスへの切り替えが必要になります。連携の基本構造 — submit、poll、ダウンロード、保存 — に変更はありません。

APIキーを取得ドキュメントを見る
  • 所要時間の目安: 1.5–4 min
  • Credits: 2Kで5 credits · 4Kで6 credits
  • 処理方式: 非同期、ポーリング

このページに記載されている数値はすべて以下に基づきます: Photta APIドキュメント · 確認済み

結論の要約

try-on APIを切り替える理由は合理的です。出力結果が自社カタログのトーンに適している、取り扱い規模における画像単価の採算が合う、あるいは既存ベンダーが提供していない機能 — バッチゴーストマネキン、ディテールのクローズアップ、シーズンを通して再利用可能な生成モデルなど — が必要となった場合です。

変更点は3点です：認証情報、リクエストボディ、ステータスパスです。PhottaはすべてのコールでBearerキーによる認証を行い、独自のフィールド名を採用し、機能ごとのstatusEndpointでジョブの状態を返します。コードから送信するすべての値は、enumまたは事前にリスト取得可能なIDとして定義されています。

アーキテクチャ自体は変わりません。どちらもsubmitしてpollする非同期APIであるため、既存のキュー、ワーカー、リトライポリシー、ストレージはそのまま機能します。実際の移行作業は、新しいクライアントモジュールの作成とフィールド名のマッピングであり、パイプライン全体の再構築は不要です。

移行先のエンドポイント

Photta APIドキュメントから自動生成された仕様であり、手動記述ではありません。

概要

エンドポイント
POST /api/v1/tryon/apparel
認証
Bearer APIキー
処理方式
非同期 — ステータスエンドポイントをポーリング
所要時間の目安
1.5–4 min
Credits
2Kで5 credits · 4Kで6 credits
アスペクト比
3:4 · 1:1 · 4:3 · 9:16 · 16:9
入力制限
1画像あたり最大10 MB、JPEG, PNG, WebP
冪等性
なし

実際に変更が必要な4つの項目

  • 認証

    Phottaダッシュボードで作成した単一のBearerキーをすべてのendpointで使用します。endpointごとのスコープやトークン交換のステップはありません。

  • リクエストボディ

    Phottaはドキュメント化されたenumを含むsnake_caseフィールドを受け取ります。model、pose、backgroundの各idは、リソースendpointから一覧取得してキャッシュします。

  • ポーリング

    completedまたはfailedが返されるまで、3秒ごとに機能のステータスendpointをポーリングします。Webhookはないため、新たに外部公開が必要なものはありません。

  • 課金方式

    コールあたりのcredits制です（アパレルtry-onの場合、2Kで5 credits、4Kで6 credits）。ジョブ開始時に差し引かれ、失敗した場合は自動的に返金されます。

新しいリクエスト仕様

cURL、Node.js、Pythonによる同一のリクエスト実装例。

RESPONSE=$(curl -s -X POST https://api.photta.app/api/v1/tryon/apparel \
  -H "Authorization: Bearer $PHOTTA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "product_type": "top",
  "product_images": [
    "https://cdn.yourstore.com/products/shirt-front.jpg"
  ],
  "product_back_image": "https://cdn.yourstore.com/products/shirt-back.jpg",
  "product_category": "t_shirt",
  "mannequin_id": "mnk_f3a9b1",
  "pose_id": "pose_c2d4e5",
  "background": "https://cdn.yourstore.com/backgrounds/studio-loft.jpg",
  "lock_background": true,
  "resolution": "2K",
  "aspect_ratio": "3:4",
  "body_size": "M",
  "expression": "neutral",
  "user_instruction": "Keep the collar pattern crisp and centered."
}')
ID=$(echo "$RESPONSE" | jq -r '.data.id')

移行に関するFAQ

移行にはどれくらいの時間がかかりますか？

クライアントモジュール1つ分です。新しいキー、新しいフィールド名、新しいステータスパスに対応するだけです。ワーカーがすでに送信とポーリングを行っている構成なら、周辺のコードを変更する必要はありません。

キューの仕組みを変更する必要はありますか？

いいえ。どちらのAPIも非同期であるため、Celery、BullMQ、Inngest、cronテーブルなど、現在使用している構成をそのまま維持できます。変更が必要なのはタスク内の呼び出し処理のみです。

生成済みの画像はどうなりますか？

自社のストレージ内にあるファイルであるため、変更されることは一切ありません。移行の影響を受けるのは今後新しくレンダリングするものだけであり、すでに公開済みの画像には影響しません。

価格の比較はどうなっていますか？

比較ページでは、Phottaのコールあたりのcreditコストと、FASHNが自社の価格ページで公開している数値を並べ、各figureを取得した日付とともに掲載しています。どちらが有利になるかは、実際の利用ボリュームによって決まります。

両方を同時に並行運用できますか？

はい、それが最も安全な切り替え方法です。カタログの一部を新しいendpointで処理し、実プロダクトで出力を比較した上で、残りを移行してください。

次のステップ

このページに記載されている数値はすべて以下に基づきます: Photta APIドキュメント · 確認済み

並行稼働による検証と切り替え

キューのコピーを新しいエンドポイントへ送信し、実際の出力を直接比較してください。

アカウントを作成してAPIキーを取得エンドポイントを見る
  • 1.5–4 min
  • 2Kで5 credits · 4Kで6 credits
  • 非同期、ポーリング