Preflight QC

Preflight QC は、プロフェッショナルなリリース品質管理（QC）を提供するプレミアムアドオンです。リリースを送信すると、Preflight QC がメタデータ、リリース日、音声、アートワーク、AI コンテンツ、カタログ識別子、過去の配信、ライセンス書類まで、隅々まで分析します。明確で対応しやすい品質レポートが届きます。指摘された点を自分のペースで修正し、納得できたらリリースをレビューに確定してください。

レーベルや API 連携の開発者にとって、Preflight QC は組み込み部品として機能します。品質レポートをプログラムから取得し、独自の QA パイプラインに組み込み、社内の承認プロセスの判定条件にして、リリースを自動でレビューに確定できます。品質基準を決めるのはあなたのチーム、分析を担うのは Preflight QC です。

きれいな状態で届いたリリースは、レビューを速く通過します。Preflight QC は、送信する前にその状態まで導きます。

Preflight QC とは

アカウントで Preflight QC を有効にすると、配信のために送信したリリースはレビューキューに直接入りません。代わりに レビュー前の保留（「あなたの確認待ち」）に入り、その間に Preflight QC が品質分析を実行します。対象はメタデータ、リリース日、音声、アートワーク、AI コンテンツ、カタログ識別子、過去の配信、ライセンス書類です。その結果が 品質レポート です。これを何に使うかはあなた次第です。

独自の QA ワークフロー（API）。 カタログを品質分析に通し、レポートをプログラムから取得して独自の QA パイプラインで処理し、その結果を社内の承認プロセスの判定条件にして、自分の基準を満たしたリリースだけをレビューに確定します。詳しくは連携のための API の使用を参照してください。
アプリでのワークフロー。 リリースページでレポートを読み、指摘された点を修正し、納得したら確定します。

いずれの場合も、リリースを通常のレビューキューに移すのは確定の操作です。あなたが承認するまで、何もレビューには入りません。

Preflight QC はレビューの前に品質ステージを追加するものです。レビュー後の流れは変わりません。確定すると、あなたのリリースは他のリリースと同じ検証とレビューのプロセスを通ります。

Preflight QC の入手方法

Preflight QC は、当社チームがアカウントごとに有効化するプレミアムアドオンです。あなたのアカウントで有効にするには、当社の営業チームにお問い合わせいただき、Preflight QC を希望する旨をお伝えください。

有効化されると、次にリリースを配信のために送信するときに、新しい保留と確定のステップが表示されます。

Preflight QC のワークフロー

Preflight QC を有効にしたリリースの、送信からレビューまでの全体の流れは次のとおりです。

1. リリースを配信のために送信する

いつもどおりリリースを作成して仕上げ、配信のために送信します。Preflight QC が有効な場合、これはリリースをすぐにレビューキューに入れることは ありません。代わりに、リリースは レビュー前の保留 に移り、あなたの確認待ち としてマークされます。

2. 品質分析が実行される

リリースが保留になっている間、Preflight QC はそのリリースを隅々まで分析します。対象は次のとおりです。

メタデータ：タイトル、アーティスト、クレジット、その他のリリースおよびトラックの詳細
リリース日：リリース日の設定とバージョン
音声：アップロードした音声ファイル
アートワーク：カバー画像
AI コンテンツ：AI の使用が申告されているか、および当社が検出した AI 生成の楽曲やアートワーク
カタログ識別子：ISRC が有効かどうか、およびその録音がすでに他の権利者に申し立てられていないか
過去の配信：そのリリースやトラックが過去に他のディストリビューターから配信されていないか
ライセンス：カバー、サンプル、または類似のものが裏付け書類を必要とする場合

分析は通常、アップロードとトランスコードの完了後、数分で終わります。まだ実行中の間、品質レポートはチェックが進行中であることを示し、問題はまだ一覧に表示されません。

3. 品質レポートを読む

分析が終わったら、リリースの 品質レポート を開き、対応が必要な点があるかどうかを確認します。レポートは 2 か所で読めます。

パブリック API 経由（独自の QA パイプライン用）。下記の API の使用を参照してください。
アプリ内 の、リリースページ。

レポートは各問題を、わかりやすいタイトルと、何を修正すべきかを説明するメッセージとともに一覧表示します。各フィールドの読み方については、品質レポートを理解するを参照してください。

4. 指摘された点を修正する

レポートの問題を順に対応します。

メタデータの問題：リリースまたはトラックの詳細を編集します。
音声またはアートワークの問題：該当するファイルを差し替えます。
フィードバックを求める問題：問題のメモスレッドで返信するか、要求された書類（たとえばカバーやサンプルのライセンス）をアップロードします。

保留中にリリースを編集すると、現在のレポートは stale（内容が古い状態）としてマークされます。指摘内容はリリースの最新の状態を反映しなくなります。必要なだけ編集したうえで、アプリのリリースページから、または連携の場合はリフレッシュエンドポイントから、最新の分析をリクエスト してください。分析が再実行され、レポートは新しい結果で更新されます。このループは必要なだけ繰り返せますが、1 つのリリースにつき 1 時間あたりに開始できる最新の分析の回数には、公正利用の上限があります。

5. リリースを確定する

レポートがクリーンになったら、または必要な対応をすべて終えたら、リリースを確定します。アプリではリリース上の確定ボタン、連携では確定エンドポイントです。

確定すると、リリースは保留から外れて 通常のレビューキュー に移ります。確定には、完了した最新の分析が必要です。最後の実行後にリリースを編集した場合、レポートは stale になっているため、最新の分析をリクエストし、それが完了してから確定してください。

6. 通常のレビュー

確定後、あなたのリリースは他のリリースとまったく同じようにレビューされます。レビュー中に何が起こるか、所要時間、想定される結果については、検証とレビューを参照してください。

品質レポートを理解する

品質レポートは 2 つの部分で構成されます。問題の一覧と、分析の実行に関する小さな レポート 詳細ブロックです。

問題

レポート内の各問題は、確認すべき点を 1 つずつ説明します。あなたが扱うフィールドは次のとおりです。

フィールド	何を示すか
タイトル	問題の短くわかりやすい名前。
メッセージ	問題の内容と、それに対して何をすべきか。
重大度	問題の重要度。優先順位付けに役立ちます。
ブロッキング	確定する前に問題を解決する必要があるかどうか（下記参照）。
フィードバックが必要	問題にあなたからの書面での回答またはアップロードした書類が必要かどうか。
カスタム説明	利用可能な場合の、あなたのリリースに固有の追加の詳細。
対象トラック	問題が適用されるトラック。リリースレベルの問題は特定のトラックを列挙しません。
証拠	日付・重複・過去の配信に関する問題で、一致が見つかったリリースを示します。競合をご自身で確認できます（下記参照）。

ブロッキングと情報提供

ブロッキングの問題 は、リリースをレビューに確定する前に解決する必要があります。説明どおりに修正し、最新の分析を実行すると、レポートから消えます。
情報提供の問題 は、一見の価値がある点を知らせるためのものですが、確定を妨げるものではありません。目を通したうえで、準備ができたら確定してください。

フィードバックが必要な問題

一部の問題は編集だけでは解決できず、書面での説明や裏付け書類（たとえばカバーやサンプルのライセンス）など、あなたから何かを必要とします。これらは フィードバックが必要 としてマークされます。解決するには、確定する前に、問題のメモスレッドで返信するか、要求された書類をアップロードしてください。

問題に付随する証拠

一部の問題には、フラグを当て推量なしで確認できるよう、証拠が含まれます。これは、当社があなたのリリースと照合した既存のリリースです。日付、重複、過去の配信に関する問題で表示されます。各一致は、一致したトラックのタイトルとアーティスト、そのリリースタイトル、リリース日、ISRC、そのリリースが配信中のストアへのリンク、そして影響を受けるあなたのトラックを示します。1 トラックにつき最大 3 件の一致が表示されます。どう対応するかを決める前に、証拠を使って競合が本物かどうか（たとえば、あなた自身による以前のアップロードかどうか）を確認してください。

レポートの詳細

問題とあわせて、レポートには分析の実行に関するいくつかの詳細が含まれます。

フィールド	何を示すか
generated_at	現在のレポートが生成された時刻。最初の分析がまだ実行中の間は空です。
checks_in_progress	分析がまだ実行中の間は `true`。終わるまで問題の一覧は空です。
stale	最後に完了した分析の後にリリース（またはそのトラックのいずれか）を編集すると `true` になり、指摘内容が現在の状態を反映しなくなります。どんな編集でも対象になります。レポートを更新するには、最新の分析をリクエストしてください。
hold	リリースが現在レビュー前の保留にあるかどうか。
review_status	リリースの現在のレビューステータス。
release_status	レビュー専用のステータスとあわせて示される、リリース自体の全体的なステータス。
profile	このリリースに適用された品質プロファイル。その名前とバージョンを含みます。

連携のための API の使用

LabelGrid パブリック API 上に構築する場合、Preflight QC を独自のパイプラインに組み込めます。各リリースを品質分析に通し、レポートを独自の QA ワークフローに取り込み、社内の承認プロセスの判定条件にして、自分のツールからレビューへ確定します。Preflight QC はそのために 3 つのエンドポイントを提供し、いずれもパブリック API の他の部分と同じ Bearer トークン認証を使用します。完全で常に最新のリクエストおよびレスポンスのスキーマについては、API リファレンスを参照してください。

Webhook：レポートの準備ができたら通知を受け取る

結果をポーリングする代わりに、レポートの準備ができた瞬間に LabelGrid から知らせを受け取ることができます。release.preflight.report_ready の webhook イベントを購読してください。このイベントは、Preflight QC がレビュー前の保留にあるリリースの分析を完了するとすぐに発火し、あなたがリクエストした再分析が完了するたびにも発火します。分析サイクルごとにちょうど 1 件のイベントが届きます。

LabelGrid の他のリリース関連 webhook イベントと同じ方法で、アプリの webhook 設定から、または API 経由で購読します。各イベントは、実行結果のコンパクトな要約を含み、問題そのものは含みません。

リリース識別子：release_id、label_id、release_cat、release_title。
generated_at：このレポートが生成された時刻。レポート自体の generated_at と一致します。
profile：カウントの算出に使われた品質プロファイル。{name, version} の形式です。
counts：blocking、informational、requires_feedback の合計。requires_feedback のカウントは他の 2 つと重複します。

カウントを見て対応が必要かどうかを判断し、詳細はレポート本体を取得して確認します。推奨される連携パターンは次のとおりです。

release.preflight.report_ready を購読します。
各イベントを受け取ったら、品質レポートを取得するを呼び出して、問題の全体を読み取ります。
修正して再実行：保留中のリリースを編集した後、リフレッシュエンドポイントを呼び出して最新の分析を開始します。完了すると webhook が再び発火します。
リリースがあなたの基準を満たしたら、自分のツールから 判断して確定 します。

完全なペイロードのリファレンスと webhook の仕組み（署名、リトライ、エンベロープ）については、Webhooks を参照してください。

品質レポートを取得する

GET /api/public/releases/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

リリースの現在の品質レポートを返します。レスポンスには次が含まれます。

issues[]：問題ごとに 1 エントリ。それぞれに id、code（安定した文字列。問題コードの扱い方を参照）、title、message、status、severity、is_blocking、requires_feedback、custom_description、affected_tracks を含みます。日付、重複、過去の配信に関する問題では、エントリに evidence 配列も含まれます（下記参照）。
report：generated_at、checks_in_progress、stale、hold、review_status、release_status、profile（name と version を持つオブジェクト）。stale は、最後に完了した分析の後にリリースまたはそのトラックのいずれかが編集された場合に true になります。確定する前に、リフレッシュエンドポイントで分析を再実行してください。

分析がまだ実行中の間、レポートは空の issues 一覧とともに checks_in_progress: true を返します。webhook を使いたくない場合は、generated_at が設定されるまでこのエンドポイントをポーリングしてください。通常、アップロードとトランスコードの完了後、数分で設定されます。その後で問題を読みます。代わりにレポートの準備ができた瞬間に知らせを受け取るには、レポート準備完了 webhook を使用してください。

分析完了後のレスポンス例:

{
  "issues": [
    {
      "id": "12345",
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "status": "confirmed",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456],
      "evidence": [
        {
          "affected_track_id": 456,
          "track_title": "Matched track title",
          "artist": "Matched artist",
          "release_title": "Matched release",
          "release_date": "2024-03-01",
          "isrc": "USRC12345678",
          "store_url": "https://…"
        }
      ]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "stale": false,
    "hold": true,
    "review_status": "…",
    "release_status": "…",
    "profile": { "name": "quality_report", "version": 2 }
  }
}

各 evidence 項目は、あなたのリリースと一致した既存のリリースを 1 つ記述します。affected_track_id（一致が適用されるあなたのトラック）、一致した track_title、artist、release_title、release_date、isrc、そして一致が配信中のストアページを指す store_url を含みます。1 トラックにつき最大 3 件の一致が列挙され、このキーは上記の種類の問題にのみ存在します。

リリースをレビューに確定する

POST /api/public/releases/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

リリースを保留から外し、通常のレビューキューに移します。アプリの確定ボタンに相当する API です。

確定には、完了した最新の 分析が必要です。処理すべき競合は 2 つあります。

409 checks_in_progress：分析がまだ実行中です。レポート準備完了 webhook を待って（または generated_at が設定されるまでポーリングして）から、再試行してください。
409 checks_stale：最後に完了した分析の後にリリースが編集されました（report.stale が true）。リフレッシュエンドポイントを呼び出し、最新のレポートを待ってから、確定を再試行してください。

問題コードの扱い方

品質レポートの上にロジックを構築する場合は、問題の code を基準にしてください。

code は安定した文字列です。 スラッグ形式（例: audio.trailing-silence）で、システム内でコードをマッピングし、その上にロジックを構築しても安全です。
タイトルとメッセージは人向けの文章です。 時間とともに改善されることがあるため、ロジックを文章に依存させず、表示のためだけに使用してください。
新しいコードが追加されることがあります。 Preflight QC の対象範囲の拡充にともない、新しいコードが登場します。認識できないコードは汎用的に処理し、エラーにするのではなく、レスポンスの title と message をそのまま表示してください。
重要なコードはレポートが教えてくれます。 リリースを Preflight QC に通していくうちに、あなたのカタログに関係するコードが自身の品質レポートに自然と現れてきます。
分析の対象範囲。 問題は次のカテゴリーに分類されます: リリースおよびトラックのメタデータ、リリース日とバージョン、音質、アートワーク、AI コンテンツ、カタログ識別子、過去の配信、ライセンスと書類。

問題カタログ

独自の QA ワークフローを構築する際に問題をマッピングするには、完全なカタログをプログラムから取得します。

GET /api/public/issue-definitions
Authorization: Bearer YOUR_API_TOKEN

品質レポートに現れる可能性のあるすべての問題を、安定した文字列コードをキーとして返します。各項目にはタイトル、メッセージテンプレート、重大度、ブロッキングフラグ、requires_feedback、そしてそのカテゴリー（type）が含まれます。レスポンスには、カタログの算出に使われた品質プロファイルも {name, version} の形式で含まれます。このエンドポイントは、Preflight QC アドオンを持つアカウントのみ利用できます。

よくある質問

分析がまだ実行中の場合はどうなりますか？

レポートには、まだ問題が一覧表示されないまま checks_in_progress: true が表示されます。これは送信直後には正常な状態です。アップロードとトランスコードの完了後、数分待ってから再度確認してください。アプリではレポートは自動的に更新されます。API では、準備ができた瞬間に通知を受け取るためにレポート準備完了 webhook を購読するか、generated_at が設定されるまでポーリングできます。

保留中にリリースを編集できますか？

はい、好きなだけ自由に編集できます。レビュー前の保留にあるリリースは、引き続き完全に編集可能です。編集はそれだけではチェックを再実行せず、現在のレポートを stale としてマークします。変更を終えたら、最新の分析をリクエストして（アプリのリリースページから、または連携の場合はリフレッシュエンドポイントから）、保留から出ることなく更新後の結果を確認できます。確定できるようになる前に、最新の分析が完了している必要があります。

確定した後はどうなりますか？

あなたのリリースは保留から出て通常のレビューキューに入り、他のリリースと同じようにレビューされます。レビューの仕組み、所要時間、想定される結果については、検証とレビューを参照してください。

リリースを下書きに戻せますか？

はい。リリースがレビュー前の保留にあり、まだ確定していない間は、レビューに入っていないため、引き続き編集したり、下書きのままにして後で戻ってきたりできます。リリースがレビューキューに入るのは、あなたが確定したときだけです。

確定する前にすべての問題を修正する必要がありますか？

確定できるようになる前に、ブロッキング の問題は解決する必要があります。情報提供 の問題は確定を妨げませんが、一見の価値はあります。レビュー前にできるだけ多くを片付けておくことが、承認への最も早い道です。

Preflight QC についてのご質問は、当社チームにお問い合わせください。喜んでお手伝いします。

LabelGridはまだお使いではありませんか？

いまお読みいただいた内容は、すべて当社のプラットフォームでご利用いただけます。

LabelGridでできることを見る →