layer-quality

レイヤー品質レビュー

概要

生成は納品ではありません。バッチが戻ってきたら、その中で何が使用可能かを、ブリーフとスタジオですでに定めている基準に照らして判断する必要があります。Layer はそれらの基準を出力スコアリングルールとして記録し、次の 3 つのツールを提供します。

ツール	目的
list_output_scoring_rules	ワークスペースに適用されているルール。プロジェクトの指定も可能です
score_files	スコアリングの実行をキューに追加します。非同期で、料金が発生します
get_file_scores	1 つのファイルについて記録された判定を読み取ります

生成の仕組みについては、layer スキルを参照してください。ここで名前が挙がっている別のスキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください（npx skills add layerai/skills --skill <name>）。無人で処理を進める場合は、ツールのスキーマを参照し、不足していることを明示してください。

基準を独自に作る前に、ルールを確認する

目視で判断する前に、list_output_scoring_rules を呼び出してください。各ルールはスタジオが明文化した基準であり、ルールに反する納品物は、どれほど見栄えがよくても不適切です。ルールはワークスペースだけでなくプロジェクト単位でも設定できるため、作業が特定のプロジェクトに属する場合は、そのプロジェクトを指定してください。

ルールがある場合、score_files でバッチをキューに追加し、get_file_scores で判定結果を読み取ります。

この処理の契約には、間違えやすく、間違えた場合のコストが高い点が 3 つあります。

• score_files は非同期です。 結果を返すのではなく、実行がキューに追加されるとすぐに戻ります。その後、get_file_scores をポーリングしてください。リクエストが大規模な場合は数分かかります。
• 空の scores リストは、まだ判定されていないという意味であり、スコアがゼロという意味ではありません。 キューへの受付確認を判定結果として扱ったり、空のリストを不合格スコアとして扱ったりすることは、この契約が招く不具合です。
• 料金が発生し、見積もりツールはありません。 ファイルとルールの各ペアでビジョンモデルが呼び出され、Creative Units が消費されます。また、どの estimate_* ツールも料金を見積もることはできません。同じファイルを再度スコアリングすることは可能ですが、古い判定結果が置き換えられるのではなく、新しい結果が追加されます。そのため、最初の呼び出しが「何も返さなかった」からと再スコアリングすると、実際に二重に課金されます。まず get_file_scores を確認してください。

ルールがない場合は、そのことを明示してください。適用されていない基準を通過したかのように示してはいけません。そのうえで、ブリーフに照らしてレビューしてください。

好みではなく、ブリーフに照らしてレビューする

問うべきなのは「これは良いか」ではありません。「依頼されたとおりのものになっているか」です。ブリーフの各項目を順に確認してください。

• 明示された制約：アスペクト比、ピクセルサイズ、背景の透明度、パレット、ポリゴン数の上限、クリップの長さ。これらは合格か不合格かが明確で、画像の見た目に問題がないため、最も見落とされやすい項目です。
• 想定される用途：目標サイズで評価するアイコン、3x3 でタイル表示して評価するテクスチャ、継ぎ目をまたいで評価するループ、キャラクターを配置して評価する背景などです。アセットを文脈から切り離して評価すると、欠陥が納品に混入します。
• 個々の成果物ではなく、セット全体：グループに属するものは、候補をまとめて並べてください。個別に見るとわからない同種の成果物間のばらつきも、並べて見ると明白になります。

バッチから選ぶ

batch_size はバリエーションを返します。最も目を引くものを選びたくなりますが、代わりにブリーフに最も近いものを選んでください。目を引くのは、セットの他の成果物には繰り返されない理由があることが多いためです。

ブリーフに近い候補がない場合、修正すべきなのはプロンプトであり、バッチを追加することではありません。同じ結果が連続して 2 回生成された場合、プロンプトの指定が不十分ということです。同じ文字列に再び費用をかけるのではなく、プロンプトで指定できていなかった要素（構図、照明、背景の処理など）を見直してください。

正直に報告する

納品するものに問題があれば、その内容を伝えてください。使用できるアセットが3つ、手が崩れたアセットが1つ生成された場合は、アセットが4つできたとはせず、正確にそのとおり報告します。参照セットが劣化していた場合は、その名前（layer-reference-sets）を明記します。制約を満たせなかった場合は、その制約を明記します。

いずれにしても Creative Units は消費されています。何も報告せずに通すと、不備のあるアセットを使った作業がすでに進んだあとで、ユーザーが改めて問題を発見することになります。

手順の例

「この8つのアイコンは出荷できる状態ですか？」

1. ワークスペースとプロジェクトの list_output_scoring_rules を実行します。ルールは2つあり、背景が透明であることと、最低限の視認性基準です。
2. 以前のセッションですでに評価されている可能性があるため、まず8つの file_id 値に対して get_file_scores を実行します。スコアがないものについては、評価を価格設定する見積もりツールがないため、Creative Units を消費することをユーザーに伝えたうえで、score_files を実行して処理をキューに追加します。
3. スコアが表示されるまで get_file_scores をポーリングします。空のリストはまだ評価されていないことを意味するため、再評価するのではなく、ポーリングを続けます。
4. 2つが透明度ルールに違反しています。これは判断の余地がないため、background_removal（layer-image-editing）に戻します。
5. 残りの6つは、フル解像度ではなく実際に使うサイズでまとめて表示し、ストロークの太さとパレットを、以前承認された2つのアイコンと比べて確認します。
6. 1つだけ、セットのほかのアイコンより太くなっています。承認済みのアイコンを参照画像として指定し、そのアイコンだけ再生成します。
7. 状態を明記して納品します。基準を満たしたものが6つ、再生成したものが1つ、透明度を修正したものが2つです。

よくある間違い

• スコアリングルールがあるかどうかを確認せず、目視だけで判断する。
• ルールが一度も適用されていないのに、出力が基準を満たしたと報告する。
• score_files はキューに追加された処理を受け付けたことを示すだけなのに、判定結果を返すものとして扱う。
• 空の scores リストを「0」と解釈し、「まだ評価されていない」と解釈しない。
• 最初の呼び出しで「何も返ってこなかった」として再評価し、再びコストをかけて2つ目の判定を追加する。
• get_file_scores にすでに判定結果があるファイルを再評価する。
• 実際に使われる状況を踏まえずに、アイコン、テクスチャ、ループを評価する。
• セット内の各要素を1つずつ確認するため、ばらつきを見逃す。
• 指示に合うものではなく、最も目を引く候補を選ぶ。
• 指示が不十分なプロンプトを修正せず、3回目の再生成を行う。
• 既知の不備を黙ってそのまま納品する。