Jewelry AI

高画質化は、選んだ設定ではなくサーバーの値で動きます

デスクトップの高画質化ソフトから移ってきた出品者は、スライダーやプリセットが並ぶパネルを探し、どこかの画面を見落としたと考えます。見落としてはいません。ジョブを動かす値はサーバー側で書き込まれ、リクエストがたまたま運んできた値を上書きします。

リクエストが運ぶ値は、ジョブが動く値ではありません

アプリの外からは、3つのものが混同されやすくなります。必ず存在しなければならないフィールド、ジョブの動作を決める値、そして人が設定できる選択肢です。一つ目はリクエストの中に、二つ目はサーバー側にあり、三つ目は存在しません。

フィールドは必須です。: APIはそれを省いたリクエストを拒否し、決められた値の集合に含まれる値だけを受け付けます。存在することは強制されています。
受け取った値は、生成レコードには書き込まれません。: レコードが作られるとき、サービスはその代わりにサーバー自身の倍率を書き込みます（apps/api/src/generation/generation.service.ts）。
クライアントは意図的に定数を送ります。: モバイルアプリは、利用者から値を集めるのではなく、固定値でスキーマを満たすように書かれています（apps/jewelry-mobile/src/lib/api/client.ts:882）。
顔補正も同じ規則に従います。: 倍率の隣でサーバー側に固定されています。だからフローのどこにも、その切り替え項目がありません（apps/api/src/generation/generation.service.ts）。

設定パネルを探して来た場合

各行はソースが裏づける内容であり、結果についての助言ではありません。

状況	選択	理由
強度・レベル・品質の操作項目を画面上で探している。	探すのをやめる。	フローにそのような操作項目は存在せず、アプリから送った値はジョブのレコードが書かれる前にサーバーで置き換えられるためです。
難しい1枚に対して、ツールにもっと強く働いてほしい。	そのまま送り、返ってきたものを読む。	リクエストの中に、パラメーターとしてジョブに届くものはありません。その写真のために上げ下げできるものがないのは、そのためです。
2項目のプリセット一覧の記述を、どこかで見た。	完全に脇へ置く。	その一覧は宣言されているだけで参照されておらず、アプリが表示するプリセットは別の定数から来ているためです。
顧客から、どのエンジンが写真を高画質化したのか尋ねられた。	名前を挙げない。	ソースが固定しているのは一つのプロバイダー経路のモデル識別子だけであり、本番でどのプロバイダーが選ばれるかは、コードから読めない環境側の値に依存するためです。
すでに持っているデスクトップの高画質化ソフトと比べている。	設定ではなく、作業の流れを比べる。	こちら側に比べられる設定はなく、このページは出力がどう違うかについて何も主張しないためです。

固定された一つの構成と、コードが答えられない部分

高画質化の経路は、リクエストごとに組み立てられるものではありません。ワーカーのプロバイダーモジュールは、一つのモデル識別子と一つのバージョン識別子をまとめて固定し、まず新しい測定を行わない限りどちらも動かさない、という指示を書き添えています（apps/worker/src/upscale-provider.ts、2026年8月にソースを確認）。

この固定は、サーバー側で書き込まれる値と同じ姿勢に属します。リクエストごとに交渉するのではなく、一か所で一度だけ決めるという姿勢です。スキーマが今も必須とするフィールドは、リクエストが満たすべき形であって、ジョブへの入り口ではありません。

同じファイルは、説明を止めるべき地点も示しています。そこに書かれているのは、特定のプロバイダー経路が選ばれたときに何が呼ばれるかであり、その選択自体は、ソースからは明かせない環境側の値に依存します。したがってこのページは、プロバイダー名もモデル名も挙げず、そのいずれかが稼働中だとも述べず、出力が他と比べてどうかについては一切主張しません。指示が言及している測定はコードに記録されておらず、指示は結果ではありません。

ツールをありのままに読む

上で挙げたソースから導かれる、互いに矛盾しない記述です。

リクエストはフィールドを運ぶが、ジョブはそこから書かれない。
レベルも、強度も、品質の段階も、顔補正の切り替えも、利用者の手元にはない。
本番環境が公開するプリセットは一つで、アプリが表示するものは別の定数から来ている。
同じ写真をもう一度実行しても、同じサーバー側の値のもとで送られる。
アプリで設定できるもののうち、ワーカーが動かす構成を変えるものはない。

このページの根拠の外にあること

ここでのすべての記述は、2026年8月にリポジトリのソースファイルを読んで得たものです。ジョブは実行しておらず、ログも読んでおらず、データベースも観察していません。

返ってくる画像のピクセルサイズと、それに結びつく倍率。このページはどちらも述べません。
出力の品質と、他のツールや他の製品との比較。ソースに記録されているのは固定と指示であって、測定ではありません。
本番でどのプロバイダー、モデル、機能フラグが有効か。それは、ソースに含まれない環境側の値に依存します。
入力のサイズとピクセルの上限。別の作業で確認された内容であり、ここでは主張しません。
他のツールがどう振る舞うか。共通の骨格はありますが、それぞれに独自の条件があります。

よくある質問

写真をどのくらい強く高画質化するかを選べますか。

選べません。リクエストにはフィールドが含まれますが、ジョブが作られるときに生成サービスが自らの値をレコードへ書き込みます。そのため、アプリから送ったものがジョブの動きを変えることはありません（apps/api/src/generation/generation.service.ts）。

顔補正の切り替えは、どこかにありますか。

ありません。顔補正は倍率と同じ場所でサーバー側に固定されています。だからどの画面にも項目がなく、リクエストから有効・無効を切り替えることもできません（apps/api/src/generation/generation.service.ts）。

製品の中にプリセットの一覧を見つけました。有効にできますか。

その一覧はAPIの定数に宣言されていますが、リポジトリのどこからも参照されていません（apps/api/src/platform/constants.ts）。デッドコードです。隠された選択肢でも、今も動く古い経路でも、計画でもありません。アプリが表示するプリセットは別の定数から来ており、本番環境が公開するプリセットは一つです。

実際に写真を高画質化しているのは、どのエンジンですか。

このページでは述べません。ソースがそれを決めていないためです。ワーカーは一つのプロバイダー経路について、一つのモデル識別子と一つのバージョン識別子を固定していますが（apps/worker/src/upscale-provider.ts）、どのプロバイダーが選ばれるかは、コードから読めない環境側の値に依存します。名前を挙げれば、推測を事実として示すことになります。