> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/workflows/ja/burokku/blocks/advanced-blocks/model-monitoring-inference-aggregator.md).

# モデル監視推論アグリゲーター

推論予測の厳選サンプルを定期的に集約して Roboflow Model Monitoring に報告します。予測をメモリ内に収集し、クラスごとにグループ化し、各クラスで最も信頼度の高い予測を選択して、設定可能な間隔で集約結果を送信することで、最小限の性能オーバーヘッドで効率的な動画処理監視、運用分析、モデル性能追跡のワークフローを可能にします。

## このブロックの仕組み

このブロックは予測を時間経過とともに集約し、定期的な間隔で代表サンプルを Roboflow Model Monitoring に送信します。これにより API 呼び出しを削減し、動画処理のパフォーマンスを維持します。このブロックは次の処理を行います:

1. 予測と設定を受け取ります:
   * サポートされている任意のモデルタイプ（物体検出、インスタンスセグメンテーション、キーポイント検出、または分類）からの予測を受け取ります
   * Model Monitoring での識別用にモデル ID を受け取ります
   * 報告間隔を秒単位で指定する frequency パラメータを受け入れます
   * 実行モードフラグ（fire-and-forget）を受け取ります
2. Roboflow API キーを検証します:
   * 有効な Roboflow API キーが利用可能であることを確認します（API アクセスに必要）
   * API キーがない場合は、取得方法の案内とともにエラーを発生させます
3. 予測をメモリ内に収集します:
   * モデル ID ごとに整理されたインメモリ集約器に予測を保存します
   * 報告間隔の間に予測を蓄積します
   * ワークフロー実行セッション中に状態を保持します
4. 報告間隔を確認します:
   * 一意の集約器キーに基づいて、キャッシュを使用して前回の報告時刻を追跡します
   * 前回の報告からの経過時間を計算します
   * 経過時間を設定された頻度のしきい値と比較します
   * 間隔に達していない場合は報告をスキップします（ステータスメッセージを返します）
5. 報告時に予測を統合します:
   * 収集されたすべての予測を Model Monitoring 用に整形します
   * 収集されたすべてのデータをクラス名ごとに予測をグループ化します
   * 各クラスについて、信頼度で予測をソートします（高い順）
   * 各クラスで最も信頼度の高い予測を代表サンプルとして選択します
   * 厳選された予測セットを作成します（各クラスごとに最も信頼度の高い1件）
6. ワークスペース情報を取得します:
   * 提供された API キーを使用して Roboflow API からワークスペース ID を取得します
   * キャッシュ（15分の有効期限）を使用して、API 呼び出しの繰り返しを避けます
   * API キーの MD5 ハッシュをキャッシュキーとして使用してワークスペース名をキャッシュします
7. 集約データを Model Monitoring に送信します:
   * タイムスタンプ、ソース情報、デバイス ID、サーバーバージョンを含む推論データペイロードを構築します
   * 監視コンテキスト用に、利用可能な場合はシステム情報を含めます
   * 集約された予測（各クラス1件）を Roboflow Model Monitoring API に送信します
   * 送信後にインメモリ集約器をフラッシュします（新規収集を開始）
   * キャッシュ内の前回の報告時刻を更新します
8. 同期または非同期で実行します:
   * **非同期モード（fire\_and\_forget=True）**: タスクをバックグラウンドスレッドプールまたは FastAPI のバックグラウンドタスクに投入し、API 呼び出しの完了を待たずにワークフローを継続できるようにします
   * **同期モード（fire\_and\_forget=False）**: API 呼び出しの完了を待ち、即時のステータスを返します。デバッグやエラー処理に便利です
9. ステータス情報を返します:
   * 成功（False）または失敗（True）を示す error\_status を出力します
   * 報告ステータスまたはエラー詳細を含む message を出力します
   * 集約が送信されたかスキップされたかについてのフィードバックを提供します

このブロックは、すべての予測を送信すると過剰な API 呼び出しが発生し、性能に影響する動画処理ワークフロー向けに最適化されています。予測を集約し、代表サンプル（各クラスで最も信頼度が高いもの）を選択することで、オーバーヘッドを最小限に抑えながら有用な監視データを提供します。間隔ベースの報告により、継続的な API 呼び出しなしで Model Monitoring に定期的な更新を送れます。

## 一般的な使用例

#### 🔍 なぜこのブロックを使うのか？

このブロックは、Workflows で動画処理に依存するプロジェクトにとって画期的です。集約処理により、クラス全体で最も信頼度の高い予測を特定し、少量のメッセージとして定期的に Roboflow バックエンドへ送信することで、動画処理のパフォーマンスへの影響を最小限に抑えます。

こんな用途に最適です:

* 製造ラインのパフォーマンスをリアルタイムで監視する 🏭。
* モデルのパフォーマンスを時間とともにデバッグ・検証する ⏱️。
* 最小限のオーバーヘッドで推論ワークフローから実用的なインサイトを提供する 🔧。

#### 🚨 制限事項

* Workflow を実行する際、このブロックに依存すべきではありません `inference` サーバー上、または Roboflow ホスティングプラットフォームへの HTTP リクエスト経由では、内部状態がサーバーの全リクエストからアクセス可能なメモリに保持されないため、集約が **単一リクエストの範囲にしかならない**ためです。この問題がクライアントにとって重大な制限であると確認された場合、将来のリリースで対応します。

## 他のブロックへの接続

このブロックは予測を受け取り、ステータス情報を出力します:

* **モデルブロックの後** （Object Detection Model、Instance Segmentation Model、Classification Model、Keypoint Detection Model）で予測を集約して Model Monitoring に報告します（例: 検出結果の集約、分類出力の報告、モデル予測の監視）。これにより、モデルから監視へのワークフローを実現します
* **フィルタリングまたは分析ブロックの後** （DetectionsFilter、ContinueIf、OverlapFilter）で、フィルタリングまたは分析した結果を監視用に集約します（例: フィルタ済み検出の集約、分析結果の報告、処理済み予測の監視）。これにより、分析から監視へのワークフローを実現します
* **動画処理ワークフローでは** 最小限の性能影響で動画分析を効率的に監視するために（例: 動画フレーム検出の集約、動画処理結果の報告、動画分析性能の監視）、動画監視ワークフローを実現します
* **前処理または変換ブロックの後** 変換された予測を監視するために（例: 変換済み検出の集約、処理結果の報告、変換出力の監視）、変換から監視へのワークフローを実現します
* **本番デプロイのワークフローで** 本番環境でモデル性能を追跡するために（例: 本番推論の監視、デプロイ性能の追跡、本番メトリクスの報告）、本番監視ワークフローを実現します
* **シンクブロックとして** ワークフローの実行をブロックせずに集約された監視データを送信するために（例: バックグラウンド監視報告、ノンブロッキング分析、効率的なデータ収集）、シンクから監視へのワークフローを実現します

## 要件

このブロックには、環境またはワークフロー設定で有効な Roboflow API キーが必要です。API キーは Roboflow API で認証し、Model Monitoring 機能にアクセスするために必要です。API キーの取得方法は <https://docs.roboflow.com/reference/authentication/authentication/find-your-roboflow-api-key> を参照してください。このブロックは集約のためにインメモリ状態を保持するため、長時間実行されるワークフロー（永続的な WebRTC セッションでの動画処理など）で最もよく機能します。インフェレンスサーバー上でワークフローを実行する場合や、Roboflow ホスティングプラットフォームへの HTTP リクエスト経由では、このブロックに依存すべきではありません。内部状態は単一リクエストでのみアクセス可能で、集約の範囲も単一リクエストの実行に制限されるためです。このブロックは 1 つの動画ワーカープロセスに接続されたすべての動画フィードのデータを集約します（動画フィードごとに集約を分けることはできません）。frequency パラメータは少なくとも 1 秒である必要があります。Roboflow の Model Monitoring の詳細は <https://docs.roboflow.com/deploy/model-monitoring> を参照してください。

### 型識別子

ステップで次の識別子を使用してください `"type"` フィールド： `roboflow_core/model_monitoring_inference_aggregator@v1` ワークフローにこのブロックをステップとして追加するには。

### プロパティ

| **名前**                  | **型**  | **説明**                                                                                                                                                                                                                                                                                    | 参照 |
| ----------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -- |
| `name`                  | `str`  | このステップの一意の識別子を入力してください。                                                                                                                                                                                                                                                                   | ❌  |
| `frequency`             | `整数`   | 秒単位の報告頻度。集約された予測を Roboflow Model Monitoring にどれくらいの頻度で送信するかを指定します。たとえば 5 に設定すると、このブロックは 5 秒間予測を収集し、その後、集約サンプル（各クラスで最も信頼度の高い予測を1件）を Model Monitoring に送信します。1 秒以上である必要があります。値が小さいほど更新頻度は高くなりますが、API 呼び出しは増えます。値が大きいほど API 呼び出しは減りますが、更新頻度は下がります。デフォルト: 5 秒。定期的だが過剰ではない報告を行いたい動画処理に適しています。. | ✅  |
| `unique_aggregator_key` | `str`  | 集約セッションを追跡し、前回の報告時刻をキャッシュするために内部で使用される一意のキーです。このキーは、ワークフロー内のこのブロックの各インスタンスごとに一意でなければなりません。このキーは、前回の報告がいつ送信されたかを追跡するキャッシュエントリを作成するために使用され、間隔ベースの報告を可能にします。このフィールドは自動生成され、UI では非表示です。.                                                                                                      | ❌  |
| `fire_and_forget`       | `bool` | 実行モードフラグ。True（デフォルト）の場合、ブロックはバックグラウンドで非同期実行され、API 呼び出しの完了を待たずにワークフローが処理を続行できます。これによりワークフロー実行は高速になりますが、エラーはすぐには取得できません。False の場合、ブロックは同期実行され、API 呼び出しの完了を待って、即時のステータスとエラー情報を返します。デバッグやエラー処理には False、本番ワークフローで性能を重視する場合は True を使用してください。.                                                   | ✅  |

この **参照** 列は、で利用可能な動的値を使ってプロパティをパラメータ化できる可能性を示します `ワークフロー` 実行時。参照 *バインディング* 詳細は。

### ランタイム互換性

`requires_internet` - エアギャップ／オフライン環境: このブロックは、完全にオフライン／エアギャップ環境から到達できないサービスに依存しています。

`soft` - ランタイム `hosted_serverless`, `dedicated_deployment`；実行 `リモート`; 入力 `動画` : 集約バッファはプロセスメモリに保存され、報告間隔はキャッシュで追跡されます。ステートレスまたは複数レプリカの HTTP ランタイムでリモートステップ実行を行うと、予測が別々のワーカープロセスによって収集される可能性があり、報告が一部しか集約されない、または集約ウィンドウの一部がフラッシュされることがあります。安定した動画集約には、永続的な WebRTC セッションでローカルステップ実行を使用してください。

`soft` - 入力 `image` このブロックは、動画または繰り返しフレームのワークフローからの時間的コンテキストに依存します。静止画像／写真では、追跡、比較、集計、可視化に使える意味のある履歴がないため、このブロックの利点はほとんど、またはまったくありません。

### 入力と出力のバインディング

利用可能な接続は、そのバインディング種別によって異なります。どのバインディング種別が `モデル監視推論アグリゲーター` のバージョン `v1` あるか確認してください。

<details>

<summary>入力と出力のバインディング</summary>

* 入力
  * `predictions` (*Union\[*[*`object_detection_prediction`*](/workflows/ja/gaido/developer-guide/kinds/object-detection-prediction.md)*,* [*`classification_prediction`*](/workflows/ja/gaido/developer-guide/kinds/classification-prediction.md)*,* [*`instance_segmentation_prediction`*](/workflows/ja/gaido/developer-guide/kinds/instance-segmentation-prediction.md)*,* [*`keypoint_detection_prediction`*](/workflows/ja/gaido/developer-guide/kinds/keypoint-detection-prediction.md)*]*): Roboflow Model Monitoring に集約して報告するためのモデル予測（物体検出、インスタンスセグメンテーション、キーポイント検出、または分類）。予測はメモリ内で収集され、クラス名ごとにグループ化され、各クラスで最も信頼度の高い予測が代表サンプルとして選択されます。予測は frequency 設定に基づいて報告間隔の間に蓄積されます。サポートされる予測タイプ: supervision の Detections オブジェクトまたは分類予測辞書。.
  * `model_id` ([*`roboflow_model_id`*](/workflows/ja/gaido/developer-guide/kinds/roboflow-model-id.md)): 関連付けるための Roboflow モデル ID（形式: 'project/version'）。Model Monitoring 内で予測に紐づけます。これは、報告される予測を生成したモデルを識別します。モデル ID は Roboflow に送信される監視データに含まれ、Model Monitoring ダッシュボードでモデルごとの性能を追跡できます。.
  * `frequency` ([*`string`*](/workflows/ja/gaido/developer-guide/kinds/string.md)): 秒単位の報告頻度。集約された予測を Roboflow Model Monitoring にどれくらいの頻度で送信するかを指定します。たとえば 5 に設定すると、このブロックは 5 秒間予測を収集し、その後、集約サンプル（各クラスで最も信頼度の高い予測を1件）を Model Monitoring に送信します。1 秒以上である必要があります。値が小さいほど更新頻度は高くなりますが、API 呼び出しは増えます。値が大きいほど API 呼び出しは減りますが、更新頻度は下がります。デフォルト: 5 秒。定期的だが過剰ではない報告を行いたい動画処理に適しています。.
  * `fire_and_forget` ([*`boolean`*](/workflows/ja/gaido/developer-guide/kinds/boolean.md)): 実行モードフラグ。True（デフォルト）の場合、ブロックはバックグラウンドで非同期実行され、API 呼び出しの完了を待たずにワークフローが処理を続行できます。これによりワークフロー実行は高速になりますが、エラーはすぐには取得できません。False の場合、ブロックは同期実行され、API 呼び出しの完了を待って、即時のステータスとエラー情報を返します。デバッグやエラー処理には False、本番ワークフローで性能を重視する場合は True を使用してください。.
* 出力
  * `error_status` ([`boolean`](/workflows/ja/gaido/developer-guide/kinds/boolean.md)) : ブールフラグ。
  * `message` ([`string`](/workflows/ja/gaido/developer-guide/kinds/string.md)) : 文字列値。

</details>

<details>

<summary>JSON 定義の例</summary>

```json
{
	    "name": "<your_step_name_here>",
	    "type": "roboflow_core/model_monitoring_inference_aggregator@v1",
	    "predictions": "$steps.object_detection.predictions",
	    "model_id": "my_project/3",
	    "frequency": 3,
	    "unique_aggregator_key": "session-1v73kdhfse",
	    "fire_and_forget": true
	}
```

</details>