Elanorya

Jewelry AI・モデルカタログ

空のモデル一覧は不具合ではなく、照合の結果です

設定したフィルターは一つずつリクエストの条件になり、それぞれがモデルの登録データの項目と完全一致で照合されます。項目が空のままのモデルはどの値とも一致できません。そしてカタログで一度もタグ付けされていない組み合わせには、メッセージではなく空の一覧が返ります。

絞り込んだリクエストが返すもの

モデルカタログを絞り込むと、アプリはサーバーに一覧を求め、サーバーは一覧を返します。何も一致しなければ、その一覧は空です。空の答えはエラーではなく、理由も持ちません。レスポンスから見れば、モデルが1件だけの一覧も、1件もない一覧も同じ種類の結果です。

設定したフィルターはそれぞれリクエストの条件一つになり、設定しなかったフィルターは何も追加しません。フィルターなしの一覧が最も広い表示になるのは、まさにこのためです。条件は登録データを減らすだけで、戻すことはありません。単独ではモデルが返る二つのフィルターでも、重ねると何も返さないことがあります。

Elanorya APIのapps/api/src/models/models.service.tsとapps/api/src/models/models.controller.tsで確認しました（2026年8月に確認）。フィルターの句は、値を渡したときにだけ条件が存在する形で書かれています（`...(filter.gender ? { gender: filter.gender } : {})`）。

フィルターが比べているもの

照合の四つの性質が、空の結果の意味を決めます。

照合は完全一致です。
選んだ値は、モデルの登録データに保存された値と比較されます。部分一致も、近い値への読み替えもありません。登録データは求めたとおりの値を持っているか、答えに含まれないかのどちらかです。
登録データの空の項目は、何とも一致しません。
カテゴリー、性別、フレーミングは、モデルの登録データに存在しないことがあります（apps/api/src/models/models.service.ts:9-11）。そのいずれかが空の登録データは、その項目に設定したどの値とも等しくならないため、そのフィルターを外しているあいだしか表示されません。これは照合の規則の性質であり、その状態の登録データが何件あるかはコードに含まれないデータです。
フィルターどうしを比べる規則はありません。
各項目はリクエストのスキーマで別々に検証され（フレーミングは接写または全身・引きに限定された任意の値として受け付けられます。apps/api/src/models/models.controller.ts）、選んだ値どうしを確認する処理はありません。したがって、カタログで一度もタグ付けされていない組み合わせは、拒否されたリクエストではなく、形式として正しいリクエストです。
着用部位は登録データとともに送られますが、フィルターではありません。
モデルの登録データはそれぞれ着用部位の値を保持してアプリに送りますが（`bodyRegion: string | null;`、apps/api/src/models/models.service.ts）、サーバーは着用部位のフィルターを提供していません。そのため、特定の着用部位だけを求めるリクエストは送れません。アプリがその値を表示するかどうかは、このページでは確認していません。

項目ごとのフィルターの挙動

三列目は、ほかの点はすべて揃っているのに一覧から外れる登録データについての説明です。

設定する項目サーバーの照合の仕方その項目が空の登録データに起きること
カテゴリー条件が一つ。登録データのカテゴリーと完全一致で比較されますカテゴリーのフィルターを適用しているあいだ、一覧から外れます
性別条件が一つ。登録データの性別と完全一致で比較されます性別のフィルターを適用しているあいだ、一覧から外れます
フレーミング条件が一つ。接写または全身・引きだけを受け付け、完全一致で比較されますフレーミングのフィルターを適用しているあいだ、一覧から外れます
着用部位フィルターとしては受け付けられません。値は登録データとともに送られます何も起きません。この項目でリクエストを絞り込むことはできないためです
何も設定しないリクエストに条件は追加されません一覧に残ります

思ったとおりでない結果の読み方

画面が示す手がかりは一覧の件数だけです。読み取りは、自分が何を変えたかから始めるほかありません。

状況選択理由
フィルターを一つ追加した瞬間に一覧が空になった。そのフィルターだけを外し、ほかは残します。フィルターはそれぞれ独立した条件なので、登録データを取り除いたのは最後に追加したものです。
以前に使ったモデルが、絞り込んだ表示に見当たらない。使えなくなったと判断する前に、すべてのフィルターを外して探します。項目が空の登録データは、絞り込んだ一覧からは外れますが、フィルターなしの一覧には残っています。
フィルターなしの一覧にも、そのモデルがない。掲載されなくなったものとして扱い、別のモデルを選びます。無効にされた登録データは一覧にまったく返らず、代わりのものも送られません。
カテゴリーとフレーミングの組み合わせが、どの時点でも何も返さない。不具合を探すのではなく、二つのうち一方の値を変えます。二つの項目は互いに突き合わされないため、タグ付けされていない組み合わせは拒否ではなく空の一覧で返されます。
特定の着用部位のモデルだけが必要。存在するフィルターで絞り込み、答えが着用部位では限定されていないことを前提にします。サーバーは着用部位のフィルターを受け付けないため、この画面からその絞り込みを求めることはできません。

空の一覧にありがちな読み違い

いずれも、空の一覧を照合の結果ではなくカタログについてのメッセージだと考えることから生まれます。

  • 空の一覧をアプリの不具合と読み、同じリクエストを繰り返す。

    空の一覧は完了した答えです。同じリクエストを送り直すより、フィルターの値を一つ変えるほうが多くのことが分かります。

  • 絞り込んだ二つか三つの表示から、カタログの規模を判断する。

    フィルターなしの一覧と比べてください。どの条件も登録データを取り除くだけなので、絞り込んだ表示は常に小さい像です。

  • リクエストが実行される前に妥当性を確認されたと考える。

    フィルターの項目を比べる規則はありません。タグ付けされていない組み合わせも、項目が空の登録データも、同じ空の答えになります。

  • リクエストでは表現できない絞り込みを前提に工程を組む。

    着用部位はフィルターの組に含まれません。特定の着用部位を求めることに依存する計画は、存在するフィルターに合わせて組み直す必要があります。

このページで決着しないこと

このページの根拠は照合の仕組みだけを対象にしており、それ以上には及びません。

  • カテゴリー、性別、フレーミングのどの組み合わせが実際にカタログにあり、どれが何も返さないか。それはカタログのデータとプラットフォームの定数にあり、確認したコードにはありません。
  • モデルが何件あるか、カテゴリーごとにどう分布しているか。これらはデータベースの値であり、この画面からは読み取れません。
  • フィルターの操作がアプリでどう見えるか。どのフィルターが用意され、初期値が何で、一覧が空で返ったときに何が描かれるか。いずれもここでは確認していません。
  • 生成の実行中にモデルがどう選ばれ、検証され、あるいは拒否されるか。その処理はAPIの別の場所にあります。
  • モデルの登録データがどう作成・編集され、その画像がどこから来るか。確認したのは読み取り側の経路だけです。

よくある質問

フィルターの組み合わせに該当するモデルがないとき、アプリは知らせてくれますか。

何にも一致しないリクエストに、サーバーはエラーなしの空の一覧を返します。説明が付かないことは、警告が抜けているのではなく想定どおりの動作です。空の一覧の代わりにアプリが何を描くかは、このページでは確認していません。

少し前に見えていたモデルが、フィルターを追加すると消えるのはなぜですか。

フィルターは保存された項目との完全一致の照合です。その項目がモデルの登録データで空なら、設定したどの値とも等しくならないため、そのフィルターを外すまで一覧から外れ、外したあとはそのまま戻ります。

手元のモデルだけを指定できますか。

できません。モデルの登録データは着用部位の値を保持してアプリに送りますが、サーバーは着用部位をフィルターとして受け付けないため、その絞り込みは求められません（apps/api/src/models/models.service.ts）。

存在し得ない組み合わせは、実行される前に拒否されますか。

拒否されません。フィルターの各項目は単独で検証され、項目どうしを比べる処理はないため、カタログで一度もタグ付けされていない組み合わせも有効なリクエストとして受け付けられ、空の一覧が返ります。