Elanorya

モデルカタログ

カタログモデルは9つのフィールドとして端末に届き、そのどれも名前ではありません

カタログモデルを使って作成した画像を公開する前に、そのモデルについてアプリが何を持っているのかを出品者は確かめようとします。端末に届く内容に限れば、答えは短くなります。9つの説明フィールドがあり、そのうち1つはソース上で汎用と記され人物の名前ではないと明記されたコードで、人が読める名前のカラムはその中にありません。

カタログモデル1件が端末に運ぶもの

次の4つの記述は、2026年8月に、それぞれの横に記したファイルでAPIのソースから読み取ったものです。

9つのフィールドが送られ、名前のカラムはその中にありません。
カタログモデルのクライアント向けインターフェースには、識別子、カタログコード、カテゴリー、性別、フレーミング、着用部位、並び順の番号、サムネイル画像のアドレス、フルサイズ画像のアドレスが並びます。データベースが持つ人が読める名前のフィールドは、この一式に含まれていません(apps/api/src/models/models.service.ts)。
コードのフィールドは汎用と注記されています。
クライアント側でモデルを識別するコードはソース上で汎用と記され、人物の名前ではないという記述が文章で添えられています(apps/api/src/models/models.service.ts)。
一覧が作られる前にアカウントが必要です。
一覧のエンドポイントは認証ガードの後ろに置かれているため、未ログインの呼び出しはモデル一覧を受け取りません(apps/api/src/models/models.controller.ts)。
着用部位は運ばれますが、問い合わせには使えません。
このフィールドはレスポンスに現れ、絞り込み条件には現れないため、リクエストを着用部位で狭めることはできません(apps/api/src/models/models.service.ts)。

9つのフィールドを1行ずつ

apps/api/src/models/models.service.tsにあるクライアント向けインターフェースを、フィールドごとに示します。この一覧の外にあるものは、カタログモデルと一緒には送られません。

フィールドレスポンスが運ぶ内容
識別子カタログ内でのそのレコード自身の識別子
カタログコードクライアントに示されるコード。ソース上で人物の名前ではないと注記されています
カテゴリーそのモデルが属するカタログ上の分類
性別カタログ項目の説明的な属性
フレーミング接写か引きかの別
着用部位説明的な属性。レスポンスで運ばれ、絞り込み条件にはありません
並び順の番号レコードと一緒に運ばれる並び順の番号
サムネイル画像のアドレス小さい画像のアドレス
フルサイズ画像のアドレスフルサイズの画像のアドレス

この答えが支えない4つの読み方

いずれも、フィールドの対応関係とソースの注記が運べる範囲を超えています。

  • 通信についての事実を、人物の特定についての結論に変えること。

    定まっているのは、どのフィールドが送られるかと、1つの注記に何と書かれているかです。カタログ画像に誰が写っているのか、その項目がどう作られたのかは、この範囲の完全に外側にあります。

  • モデルが何件あるのか、カテゴリーにどう分かれているのかを推測すること。

    それらはコード上の事実ではなくデータベース上の値であり、このページはそれを述べません。

  • このフィールド一覧が、アプリがカードに表示する内容の説明だと考えること。

    この一覧はレスポンスの取り決めです。そのうちどのフィールドを画面がどう描くかは、ここでは定まりません。

  • 2つの画像アドレスを、保存しておける固定のリンクとして扱うこと。

    このページは2つのアドレスのフィールドを挙げるところで止まります。アドレスがどれだけの間使えるのかは、このページではなく画像アドレスについてのページで扱われます。

注記のあるコードが示すこと、示さないこと

ここで言える最も強い一文は、同時に最も狭い一文でもあります。クライアント側でモデルを識別するコードはカタログコードであり、ソースにはそれが人物の名前ではないと文章で書かれています(apps/api/src/models/models.service.ts)。これはフィールドの対応関係と、その横にある注記であり、2026年8月にAPIのソースに対して確認されたものです。

この記述は、データベースに入力された値にも、カタログ項目がどのように作られたかにも、画像に写っている可能性のある人々にも及びません。事前確認を行う出品者がこのページから得るものは1つです。カタログモデルごとにアプリが端末へ何を送っているかの、正確な記述です。

この答えが止まるところ

カタログモデルの読み取り経路は小さな範囲で、次の問いはその外側にあります。

  • カタログに何件のモデルがあり、カテゴリーにどう分かれているかは、この範囲からは読み取れません。
  • モデルのレコードがどのように作成、読み込み、編集されるかは、ここで説明した読み取り経路には含まれません。
  • 生成の実行中にモデルがどう選ばれ、どう確認されるかは、APIの別の部分に属します。
  • 画像アドレスがどれだけの間使えるのか、いつ再発行されるのかは、画像アドレスについてのページで扱われます。
  • モバイルの画面がどの絞り込みを提供し、どのように見せるかは、APIの範囲では定まりません。
  • 自分で用意したモデル写真を使う作業はこのページの外です。このフィールド一覧はシステムのカタログモデルだけを対象とします。

よくある質問

カタログモデルに名前はありますか？

端末でモデルを識別するコードはカタログコードで、ソース上では人物の名前ではないと注記されています。データベースの人が読める名前のカラムは、APIが返す9つのフィールドに含まれていません(apps/api/src/models/models.service.ts)。

手元のモデルだけをアプリに要求できますか？

できません。着用部位はレスポンスで運ばれ、絞り込み条件の一部ではないため、それでリクエストを狭めることはできません(apps/api/src/models/models.service.ts)。

モデルカタログを見るにはアカウントが必要ですか？

必要です。一覧のエンドポイントは認証ガードの後ろにあり、未ログインの呼び出しには一覧を作りません(apps/api/src/models/models.controller.ts)。

システムがモデルについて保存しているものは、すべて端末に届きますか？

届きません。データベースの行には、APIが返さないカラムがあります(packages/db/prisma/schema.prisma:394-410)。このページが説明するのは送られる9つのフィールドであって、保存されているレコードではありません。