Preflight QC

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

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

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

Preflight QC とは

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

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

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

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

Preflight QC の入手方法

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

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

Preflight QC のワークフロー

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

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

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

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

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

メタデータ：タイトル、アーティスト、クレジット、その他のリリースおよびトラックの詳細
リリース日：リリース日の設定とバージョン
音声：アップロードした音声ファイル
アートワーク：カバー画像
ライセンス：カバー、サンプル、または類似のものが裏付け書類を必要とする場合

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

3. 品質レポートを読む

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

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

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

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

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

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

保留中にリリースを編集すると、分析の関連する部分が再実行され、レポートは新しい結果で更新されます。このループは必要なだけ繰り返せます。

5. リリースを確定する

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

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

6. 通常のレビュー

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

品質レポートを理解する

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

問題

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

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

ブロッキングと情報提供

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

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

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

レポートの詳細

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

フィールド	何を示すか
generated_at	現在のレポートが生成された時刻。最初の分析がまだ実行中の間は空です。
checks_in_progress	分析がまだ実行中の間は `true`。終わるまで問題の一覧は空です。
hold	リリースが現在レビュー前の保留にあるかどうか。
review_status	リリースの現在のレビューステータス。
profile	このリリースに適用された品質プロファイル。

連携のための API の使用

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

品質レポートを取得する

GET /v4/public/リリース/{id}/quality-report
Authorization: Bearer YOUR_API_TOKEN

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

issues[]：問題ごとに 1 エントリ。それぞれに code（安定した文字列。問題コードの扱い方を参照）、title、message、severity、is_blocking、requires_feedback、custom_description、affected_tracks を含みます。
report：generated_at、checks_in_progress、hold、review_status、profile。

分析がまだ実行中の間、レポートは空の issues 一覧とともに checks_in_progress: true を返します。generated_at が設定されるまで エンドポイントをポーリング してください。通常、アップロードとトランスコードの完了後、数分で設定されます。その後で問題を読みます。

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

{
  "issues": [
    {
      "code": "example.issue-code",
      "title": "Short issue title",
      "message": "What to fix and how.",
      "severity": "…",
      "is_blocking": true,
      "requires_feedback": false,
      "custom_description": null,
      "affected_tracks": [456]
    }
  ],
  "report": {
    "generated_at": "2026-07-07T12:00:00Z",
    "checks_in_progress": false,
    "hold": true,
    "review_status": "…",
    "profile": "…"
  }
}

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

POST /v4/public/リリース/{id}/confirm-review
Authorization: Bearer YOUR_API_TOKEN

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

確定には分析が完了している必要があります。最後の分析実行後にリリースが編集された場合、レポートは再生成中であり、エンドポイントは 競合（conflict） を返します。その場合は品質レポートを再取得し、generated_at が再び設定されるまで待ってから、確定を再試行してください。

問題コードの扱い方

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

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

問題カタログ

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

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

品質レポートに現れる可能性のあるすべての問題を、安定した文字列コードをキーとして返します。各項目にはタイトル、メッセージテンプレート、重大度、ブロッキングフラグ、requires_feedback が含まれます。このエンドポイントは、Preflight QC アドオンを持つアカウントのみ利用できます。

よくある質問

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

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

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

はい。レビュー前の保留にあるリリースを編集すると、分析の関連する部分が再実行され、レポートが更新されます。そのため、保留から出ることなく問題を修正し、更新後の結果を確認できます。ただし、編集後は確定できるようになる前に、更新後のレポートを待つ必要がある点にご注意ください。

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

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

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

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

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

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

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

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

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

LabelGridでできることを見る →