設備モデルのトレーニングと管理
設備モデルは管理されたライフサイクルで運用します。トレーニングで作成されるのはレビュー対象の候補です。現在設備を保護している本番判定が自動的に置き換わることはありません。
2 種類のモデル成果物を区別する
| モデル系統 | 用途 | 現在のトレーニング入口 | 本番制御 |
|---|---|---|---|
設備ベースライン分布 (PDM_BASELINE_DISTRIBUTION) | 観測された設備の運転分布を記述し、ベースライン比較に使用します。 | 予知保全 > モデルコンソール | モデルコンソールのベースライン昇格ゲート |
実行可能な異常検知モデル (PDM_ANOMALY_MODEL) | 特定の設備と target に対して異常スコアリング artifact を実行します。 | モデルコンソール > 検知を最適化、設備詳細、または管理者 API | 検証済みの不変 artifact を参照する ACTIVE assignment |
ベースライン分布は実行可能な異常検知モデルではありません。ベースライン計算の成功はモデル実行を証明せず、異常スコアも故障確率ではありません。
入口と権限
| タスク | 入口 | 必要な権限 |
|---|---|---|
| モデルコンソールを表示 | /pdm/model-console | mlops.model.read または system.config |
| モデル使用詳細を表示 | /ai-models/registry/:registryId | mlops.model.read または system.config |
| ベースラインをトレーニングまたは昇格 | モデルコンソール | pdm:write |
| 異常検知の最適化を開始またはキャンセル | モデルコンソール、設備詳細、または Platform AutoML API | mlops.model.write、pdm:write、または system.config |
| 最適化の進捗と結果を表示 | 最適化ドロワーまたは Platform AutoML API | mlops.model.read、pdm:read、または system.config |
| 実行可能な異常検知候補を 1 件直接トレーニング | 管理者 API | pdm:write |
| 実行可能 assignment を昇格またはロールバック | 管理者 API | pdm:write |
| 設備 Finding を確認 | /pdm/anomalies と Finding 詳細 | pdm:read |
標準のモデル使用詳細ページは読み取り専用です。assignment の昇格またはロールバックボタンは現在ありません。
ライフサイクル
SHADOW は比較だけを行い、alert、health score、advisory、Finding を変更しません。ACTIVE は assignment に本番選択権がある状態ですが、新しく成功した runtime evidence が現れるまで本番利用は確認できません。
統計的な設備ベースラインをトレーニングする
- 予知保全 > モデルコンソールを開きます。
- 対象設備を選択し、tenant、設備、target、単位を確認します。
- readiness 結果と未達条件をすべて確認します。
- 運転状態履歴とトレーニング期間が正しいことを確認します。
- 条件を満たし
pdm:writeがある場合にトレーニングを開始します。 - 更新後のバージョンとトレーニング時刻を確認します。
| Readiness | 意味 | 次の操作 |
|---|---|---|
| Eligible | 必要なデータ条件を満たしています。 | トレーニング後、SHADOW 候補をレビューします。 |
| Missing criteria | 1 つ以上の測定可能な条件を満たしていません。 | 有効な運転履歴を追加するか、必要な信号を修復します。 |
| Cannot determine | サービスが判定できません。 | 表示された identity、data、service の問題を解決します。履歴不足とは報告しません。 |
| Caveat | トレーニングできますが期間に既知の制限があります。 | 制限を記録してリリースレビューに含めます。 |
ベースラインのトレーニングは比較用候補を作成するだけで、既存の本番判定は維持されます。
異常検知を最適化する
最適化ワークフローは、管理された説明可能な候補手法を、ジョブ開始時に有効だった判定パスと比較します。次の 2 か所から開けます。
- 予知保全 > モデルコンソール > 検知を最適化。
- 設備詳細 > 検知を最適化。
ドロワーは、対象設備、測定項目と単位、推奨トレーニング期間、データ基準時刻、現在の判定根拠を最初に固定します。開始前に各項目を確認してください。これらは表示情報だけでなく、ジョブの証跡です。
検索前に準備状態を解決する
各準備条件には実績値と必要値が表示されます。ブロックされたジョブはモデル失敗ではなく、そのように報告してはいけません。
| ブロック理由 | 対応 |
|---|---|
| 有効な振動データソースがない、または一致するバインドが複数ある | データ統合で設備とデータソースのバインドを修正します。 |
| 測定単位がない | データソースのバインドに単位を追加します。最適化ドロワーで推測や変換をしません。 |
| ISO 比較帯を判定できない | 設備プロファイルを完成を選び、定格出力と軸受/支持方式を追加してから戻ります。 |
| 運転中サンプル、週数、期間、連続性が不足 | 有効な運転状態履歴を収集し続けるか、データソースを修復します。停止期間で代用しません。 |
| 時系列証跡を利用できない | 管理対象のデータサービスを復旧し、準備状態を更新します。 |
| Runner がない、または tenant キューが満杯 | 容量を待つか、管理者に private/staging Runner pool の確認を依頼します。繰り返しクリックしても有効な証跡は増えません。 |
管理された検索予算を選択する
| 予算 | 用途 |
|---|---|
クイック (QUICK) | 通常の設備レビュー向けの制限付き初回検索。 |
標準 (STANDARD) | エンジニアリングレビュー向けの広い候補比較。 |
詳細 (DEEP) | より多くの時間と計算容量を承認された専門調査。 |
利用可能な予算は tenant policy と Runner 容量で決まります。予算が表示されないことはブラウザー障害ではありません。大きな予算を選んでも、勝者や精度向上は保証されません。
対象と準備証跡が正しいことを確認して 最適化を開始を選択します。ドロワーを閉じてもジョブは永続化されます。同じ設備を再度開くと最新ジョブを復元できます。停止する場合は ジョブをキャンセルを使用します。完了済みの証跡は保持されます。
ジョブの成果を理解する
進捗は、管理対象スナップショットの準備、候補手法の比較、期間検証、artifact 検証を行い、候補が条件を満たした場合だけ SHADOW 候補を登録します。現在の管理対象検索は Isolation Forest と統計ベースライン候補を比較でき、任意のユーザーコードは実行しません。
| 結果 | 意味 | 次の操作 |
|---|---|---|
NO_WINNER / 現在の判定パスを維持 | 実行可能性と実質改善の両ゲートを通過した候補がなく、SHADOW モデルは作成されません。 | 現在のパスを維持します。データ制限があれば修正し、証跡または承認済み予算が変わった場合だけ再実行します。 |
| SHADOW 候補の準備完了 | 候補がゲートを通過し、不変の SHADOW assignment として登録されました。 | モデル証跡を開いてレビューします。顧客向け alert、health score、advisory、Finding はまだ変更できません。 |
| 失敗またはタイムアウト | Runner 不可、依存関係の失敗、タイムアウト、無効な artifact など、安全な理由が表示されます。 | 原因を解消し、部分的な trial をモデル結果として扱いません。 |
4 層でトレーニング結果を読む
完了したドロワーを次の順序で確認します。
- 結論：現在の本番判定基準を維持するか、SHADOW 候補が作成されたかを確認します。
- 影響：現時点で変わり得る範囲を確認します。SHADOW は顧客向けアラート、健康指標、保全提案、Finding を変更できません。
- 証拠：固定された現在の本番判定基準、評価方法、条件ごとの結果、証拠期間、サンプル数、データ締切を確認します。
- 行動：現在の経路を維持する、データ不足を修正する、根拠がある場合のみ予算を変えて再実行する、または登録済み SHADOW モデルの証拠を確認します。
比較表には 現在の本番判定基準 行が表示されることがあります。この行と比較候補は、同じ評価期間、指標の意味、単位、観測数を使用します。候補ごとに実績値と要件が表示されます。例：カバレッジ：実績 68%、要件 70% 以上。値がない場合はゼロではなく 未評価 と表示されます。
| 証拠 | 運用上の意味 |
|---|---|
| カバレッジ | 過去の運転期間で利用可能な証拠が存在する割合。高いほどデータ欠損が少ないことを示します。 |
| 安定性 | 過去の複数期間でアラート負荷がどの程度一貫しているか。モデル精度ではありません。 |
| アラート負荷 | 運転サンプルのうち確認対象として検出される割合。1 日当たりのアラート数ではありません。 |
| ドリフト | トレーニング期間と検証期間の分布変化。 |
| SHADOW 不一致 | 候補と現在の判定基準で判断が異なったサンプルの割合。誤り率ではありません。 |
| 計算コスト | 制限されたサンプル量当たりの処理時間。リソース需要だけを表します。 |
選択結果は次の 3 種類を区別します。
- 実行可能な候補なし：すべての条件を満たした候補がありません。各候補の未達条件を表示し、いずれかを「最良候補」とは表示しません。
- 実行可能だが実質改善なし：固定された本番判定基準と実際に比較された候補を表示します。本番経路は変わりません。
- 候補を選択：候補は SHADOW 確認用にのみ登録され、自動的に昇格しません。
条件ごとの証拠を導入する前に作成された過去タスクも読み取れます。ブラウザーで条件や比較候補を推測せず、集約説明と旧形式の証拠であることを示す注記を表示します。
確認済み故障ラベルがない場合に比較できるのは、coverage、stability、alert burden、drift、SHADOW disagreement、compute cost です。これらは動作と運用負荷を示しますが、accuracy、precision、recall、故障確率を証明しません。NO_WINNER も有効で価値のある結果です。
API 境界
UI は永続的な Platform AutoML ジョブ契約を使用します。
| Method | Endpoint | 用途 |
|---|---|---|
POST | /api/v1/platform/automl/jobs | 管理された候補検索ジョブを作成します。 |
GET | /api/v1/platform/automl/jobs/{jobId} | 永続化された進捗を取得します。 |
GET | /api/v1/platform/automl/jobs/{jobId}/outcome | trial、選択証跡、次の操作を取得します。 |
POST | /api/v1/platform/automl/jobs/{jobId}:cancel | 証跡を削除せずにキャンセルを要求します。 |
POST /api/v1/pdm/model-console/{equipmentId}/train-anomaly-model は、実行可能候補を 1 件直接作成する管理者向け統合として残ります。複数候補の最適化フローではありません。
SHADOW 候補が作成されたら、正しい registry record を開き、設備と target のバインド、不変 artifact の検証、実行比較証跡を確認してからリリースを判断します。すべての UI と API 操作は対象 tenant 内で実行し、別の tenant や環境からコピーした assignment、job、registry ID は再利用しないでください。
SHADOW 動作をレビューする
モデル使用詳細で、設備と target のバインド、artifact の種類と検証状態、トレーニング期間、実行結果件数、SHADOW disagreement を確認します。
Disagreement は比較期間内の結果が現在のパスと異なったことだけを表し、どちらが正しいかを証明しません。alert が少ない候補は重要な状態を見逃している可能性もあります。現場 Finding、保全結果、運転状況、データ品質を合わせて判断します。
意図的に昇格する
UI で設備ベースラインを昇格
条件を満たす SHADOW ベースラインでは、pdm:write を持つユーザーに昇格操作が表示されます。バックエンドゲートは現在の判定との比較可否を検査しますが、候補の精度が高いとは主張しません。
API で実行可能 assignment を昇格
| Method | Endpoint |
|---|---|
POST | /api/v1/pdm/model-console/assignments/{assignmentId}/promote |
成功後、対象 assignment が ACTIVE、registry version が PRODUCTION、以前の設備単位の本番 assignment が無効、artifact が検証済みであることを確認し、新しい ACTIVE runtime evidence を待ちます。
ACTIVE_AWAITING_EVIDENCE、STALE、FALLBACK、CONFLICT、ARTIFACT_UNAVAILABLE の場合、本番で実行中と説明しないでください。
実行可能 assignment をロールバックする
ロールバックは現在、管理者 API のワークフローです。
| Method | Endpoint |
|---|---|
POST | /api/v1/pdm/model-console/assignments/{assignmentId}/rollback |
tenant scope のモデル API が返す assignmentId を使用します。URL、モデル名、別環境から推測しないでください。処理後、復元先 assignment が ACTIVE、履歴状態が正しい、新しい実行証跡がある、ロールバック対象 artifact を live assignment が参照していないことを確認します。
ロールバックしても、過去の assignment、ライフサイクルイベント、runtime evidence、Finding、feedback は削除されません。
主な状態
| 状態 | 証明すること | 証明しないこと |
|---|---|---|
STAGING | Registry version は候補です。 | ユーザー向け結果に影響できること。 |
SHADOW | Assignment は非書き込み比較に使用できます。 | 本番モデルであること。 |
ACTIVE | Assignment に本番選択権があります。 | 最近の実行が成功したこと。 |
PRODUCTION | Registry version は管理対象 scope の本番版です。 | すべての設備評価で使用されたこと。 |
RETIRED / ROLLED_BACK | Version または assignment は履歴です。 | 監査証跡が削除されたこと。 |
トラブルシューティングと確認
| 症状 | 確認項目 |
|---|---|
| トレーニング操作がない | pdm:write、readiness、assignment 状態、API-only の異常モデルフローかどうか。 |
| トレーニングが拒否される | 設備 identity、target、運転履歴、期間 coverage、返された理由。 |
| 候補が SHADOW のまま | リリース判断前の正常な安全状態です。 |
| 昇格後も本番利用と表示されない | 新しい runtime evidence、fallback、artifact verification。 |
| ロールバックボタンがない | Assignment のロールバックは管理者 API で行います。 |
完了前に、設備と target、2 種類の成果物、SHADOW の非書き込み性を確認し、昇格またはロールバック後に新しい ACTIVE runtime evidence があることを確認します。