> 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/gaido/developer-guide/execution-engine-changelog.md).

# 実行エンジンの変更履歴

以下にExecution Engineの変更履歴があります。

## 未リリース

**変更内容**

ユーザー向けのコンパイルまたは実行動作の変更をここに追加してください。メンテナーはリリース時にこの見出しをExecution Engineおよびinferenceのバージョンに置き換えます。

* ローカルのワークフローモデルを読み込む際に発生したモデルアクセス失敗は、一般的なHTTP 500エラーとして表面化するのではなく、HTTP 402、403、423のステータスを保持するようになりました。

***

## Execution Engine `v1.12.0` | inference `v1.3.2`

**変更内容**

**Future解決** - 一部のステップは現在、 `Future` クライアントが出力を必要とするまで出力の解決を遅らせるオブジェクトです。下流ブロックでは、これらのFutureは [step\_input\_assembler](https://github.com/roboflow/inference/blob/main/inference/core/workflows/execution_engine/v1/executor/execution_data_manager/step_input_assembler.py) 一方、出力構築では [output\_constructor](https://github.com/roboflow/inference/blob/main/inference/core/workflows/execution_engine/v1/executor/output_constructor.py) 座標変換とともに処理されます。

## Execution Engine `v1.11.0` | inference `v1.3.1`

**変更内容**

* **dictステップセレクタのケースごとの実行分岐** - フロー制御ブロックが、次の中にステップセレクタを宣言すると `Dict[str, StepSelector]` プロパティ（次のものではなく） `List[StepSelector]`）、コンパイラは辞書キーごとに個別の実行分岐を作成するようになりました。以前は1つのプロパティ内のすべてのセレクタが1つの分岐を共有していたため、ブロックはターゲットへ独立してルーティングできませんでした。分岐名には辞書キーが含まれるようになりました（例： `Branch[$steps.switch -> cases[red]]`）。リスト型プロパティ（たとえば `next_steps`）に保持されたセレクタは従来の共有分岐動作のままで、既存のブロックには影響しません。この変更により、新しい `roboflow_core/switch_case@v1` ブロック（`graph_constructor.establish_control_flow_edge`).
* **修正: 分岐名が重複する非SIMDフロー制御マスク** - 単一のリスト型プロパティを通じて複数のターゲットを選択する非SIMDフロー制御ステップでは、 `実行分岐用のマスクを再登録しようとしました`。分岐マスクの登録は、登録前に分岐名を重複排除するようになり、クラッシュを修正しました（影響例: `ContinueIf` 複数の `next_steps`; `execution_data_manager.manager._register_control_flow_output_for_non_simd_step`).

## Execution Engine `v1.10.1` | inference `v1.2.12`

**変更内容**

* **ネストされた内部ワークフロー内の動的ブロック** - コンパイラは現在、次を収集します `dynamic_blocks_definitions` ルートワークフローと、すべてのネストされた `inner_workflow` 子（深さ優先）から収集し、次で重複排除します `manifest.block_type` （最初の出現が優先され、重複がスキップされると警告がログに記録されます）、そしてマージされたリストをルート定義へ持ち上げてから `compile_dynamic_blocks` とインライン化を行います。ネストされたワークフロー仕様上でのみ定義されたカスタムPythonブロック型を使用する子ステップは、インライン化後に正しくコンパイルされ、実行されます。

## Execution Engine `v1.10.0` | inference `v1.2.10`

**変更内容**

* 静的値とセレクタが混在する値を持つ辞書を認識する機能を追加しました。以前のバージョンでは、キーからセレクタへの対応を持つdictのみが認識されていたため、一部のブロックが実行時に参照値へ正しく接続されませんでした。この変更は互換性を壊しませんが、以前壊れていた特定のブロックを修正します。

## Execution Engine `v1.9.0` | inference `v1.2.0`

{% hint style="info" %}
**新機能: コンパイル時のインライン化によるネストされたワークフロー**

このリリースでは、 **`roboflow_core/inner_workflow@v1`** ブロックを追加し、ワークフローが別のワークフロー定義（インラインJSON、または `workflow_workspace_id` / `workflow_id` / 任意の `workflow_version_id`）から解決されたもの）を埋め込めるようになりました。子入力は親から次で配線されます **`parameter_bindings`** （子 `inputs[].name` → 親セレクタ）。コンパイル時にエンジンは **インライン展開し、** ネストされたステップを親グラフへ組み込みます。実行は通常のステップと同じ経路を使います（別個のネスト実行時環境はありません）。
{% endhint %}

**変更内容**

* **内部ワークフローブロック** - 新しいフロー制御ブロック型 `roboflow_core/inner_workflow@v1` に登録された `roboflow_core`。親の出力は、子ワークフローのJsonField出力を次のように参照できます `$steps.<inner_step_name>.<child_output_name>` インライン化がセレクタを書き換えるまで。
* **コンパイルパイプライン** - ルート定義を解析する前に、コンパイラは次を行います: (1) **正規化します** 参照（デフォルト: Roboflow API + `workflows_core.api_key`、またはカスタム `workflows_core.inner_workflow_spec_resolver`), (2) **構成を検証します** （非循環性、最大ネスト深さ、最大内部ワークフロー数）、(3) **インライン展開し、** すべての内部ワークフローステップを通常のステップへ変換し、その後、解析、ワークフロー仕様の検証、実行グラフの構築を続けます。
* **制限（環境変数）** - `WORKFLOWS_MAX_INNER_WORKFLOW_DEPTH` （デフォルト `4`）はルートからの包含深さを制限します。 `WORKFLOWS_MAX_INNER_WORKFLOW_COUNT` （デフォルト `32`）は次の総数を制限します `inner_workflow` ネストされた定義内のステップ。
* **ドキュメント** - 参照 [内部ワークフロー（ネストされた定義）](/workflows/ja/gaido/developer-guide/inner-workflows.md) 使用方法、バインド、制限、および例について。

## Execution Engine `v1.8.0` | inference `v1.1.1`

{% hint style="info" %}
**追加的な変更 + 最小限の影響が見込まれるバグ修正による1件の破壊的変更**

このリリースではExecution Engineを拡張し、フロー制御によってゲートされたステップ（例: 次の後の `ContinueIf` ブロック）でも、次を持たない場合に実行できるようにしました **データ由来のラインエージ** - つまり、上流ステップからバッチ指向の入力を受け取らない場合です。ラインエージと実行の次元は、フロー制御の前段ステップから導出できるようになりました。既存のワークフローには影響しません。

導入された破壊的変更が1つあります。これは次に影響するバグ修正によるものです `Batch.remove_by_indices` ネストされたバッチを伴う場合（下記参照）。影響は最小限と見込まれます。
{% endhint %}

**変更内容**

* **フロー制御のラインエージ** - コンパイラは現在、フロー制御ステップに由来するラインエージ（例: 次の後の分岐）を追跡します `ContinueIf`）。新たな概念である **フロー制御ラインエージサポート** は、ステップにバッチ指向のデータ入力がなく、フロー制御ステップが前にある場合に使われます。ステップの実行スライスとバッチ構造は、それらのフロー制御前段ステップから取得されます。
* **緩和された互換性チェック** - 以前は、 `verify_compatibility_of_input_data_lineage_with_control_flow_lineage` が `ControlFlowDefinitionError` フロー制御の前段を持つがデータ由来ラインエージを持たない任意のステップに対して発生し、そのためそのようなステップはコンパイルできませんでした。このチェックは現在緩和され、ステップに入力データラインエージがない場合は互換性を強制せず、代わりにステップのラインエージをフロー制御の前段ステップのラインエージから導出します。厳密なチェックは、ステップが *持っている場合には引き続き実行されます* データ由来ラインエージを持ち、フロー制御とデータラインエージの互換性を保つことを確認します。
* **新しいステップパターン** - フロー制御のみでトリガーされ、バッチデータを消費しないステップが正しく実行されるようになりました。たとえば、次の後にメール通知を送信したり（あるいは他の副作用ステップを実行したり）できます `ContinueIf` データを次のようなパラメータへ配線せずに `message_parameters`; ステップはフロー制御ブランチごとに1回実行され、ラインエージと次元は制御ステップから取得されます。
* **`Batch.remove_by_indices` ネストされたバッチを伴う場合（動作修正）** - 次を通じてインデックスを削除する場合 `Batch.remove_by_indices`、ネストされた `Batch` 要素は同じインデックス集合で再帰的にフィルタされるようになりました。その結果、削除されたインデックスのエントリ（ `None` の値を含む）もネストされたバッチから正しく削除されます。以前は最上位のバッチのみがフィルタされ、ネストされたバッチは変更されませんでした。

  デフォルトでは `WorkflowBlock`, `accepts_empty_values()`は `False`。これが回避されていた間、そのような入力を消費するブロックは、たとえば次のように単純に失敗していました `StitchDetectionsBatchBlock`:

  ```python
  def run(
      self,
      images: Batch[WorkflowImageData],
      images_predictions: Batch[Batch[sv.Detections]],
  ) -> BlockResult:
      result = []
      for image, image_predictions in zip(images, images_predictions):
          image_predictions = [deepcopy(p) for p in image_predictions if len(p)]
          for p in image_predictions:
              coords = p["parent_coordinates"][0]
      ...
  ```

  この変更の影響を受ける唯一のコアブロックは `DimensionCollapseBlockV1` ブロックです。これは、None値をフィルタせずに個々の入力をバッチで包んでいたためです。

  ```python
  class DimensionCollapseBlockV1(WorkflowBlock):

    @classmethod
    def get_manifest(cls) -> Type[WorkflowBlockManifest]:
        return BlockManifest

    def run(self, data: Batch[Any]) -> BlockResult:
        return {"output": [e for e in data]}
  ```

  このブロックの出力を使用すると、下流アプリケーションは単純に失敗するか、自身で値をフィルタしない限りNone値を静かに処理してしまう可能性がありました。

  上記を踏まえると、影響は最小限と考えます。

## Execution Engine `v1.7.0` | inference `v0.59.0`

{% hint style="warning" %}
**ワークフロー内のステップエラーに関する破壊的変更**

次の不正なHTTPレスポンスコードに関連するバグを修正するために `inference-server` Workflowsの実行リクエストを処理する際に、Execution Engineのエラー処理を担うデフォルト機構を変更する必要がありました。この変更の結果、Roboflow Hosted Platformおよび `inference>=0.59.0`、クライアント設定ミス（無効なRoboflow APIキー、無効なモデルIDなど）により失敗するRoboflowプラットフォームとやり取りするWorkflowブロックは、次を発生させる代わりに `StepExecutionError` （およびサーバーからのHTTP 500応答）を発生させます `ClientCausedStepExecutionError` （および400、401、403、404などの該当するHTTPレスポンスコード）を発生させます。
{% endhint %}

この変更の影響を受けるシナリオの一覧:

* Roboflowモデルを使用するブロックが無効なモデルIDを定義している場合、現在は次を発生させます `ClientCausedStepExecutionError` ステータスコード400で
* Roboflowモデルを使用するブロックが無効なAPIキーを定義している場合、現在は次を発生させます `ClientCausedStepExecutionError` ステータスコード401で
* Roboflowモデルを使用するブロックが、リソースにアクセスするスコープを持つ有効なキーがない、または無効なAPIキーを定義している場合、現在は次を発生させます `ClientCausedStepExecutionError` ステータスコード403で
* Roboflowモデルを使用するブロックが存在しないモデルを定義している場合、現在は次を発生させます `ClientCausedStepExecutionError` ステータスコード404で

{% hint style="info" %}
**復活させる `レガシー` エラー処理**

必要であればエラーハンドラーのレガシー動作を復活させることができ、移行期間に役立つ場合があります。必要なのは環境変数を設定することだけです `DEFAULT_WORKFLOWS_STEP_ERROR_HANDLER=legacy`.
{% endhint %}

## Execution Engine `v1.6.0` | inference `v0.53.0`

{% hint style="info" %}
**変更に注意が必要な場合があります**

このリリースでは、次を伴うアップグレードと新機能を導入します **変更不要** 既存のワークフローに対して。最新のExecution Engine機能を活用するには、一部のブロックのアップグレードが必要な場合があります。
{% endhint %}

以前のExecution Engineには、特定の種類のブロック、特にSingle Instruction, Multiple Data (SIMD)モードで動作するブロックとのやり取りに大きな制限がありました。これらのブロックは、入力バッチを一度に処理し、各要素に同じ操作を適用し、バッチ全体の結果を返すよう設計されています。

たとえば、 `run(...)` このようなブロックのメソッドは次のようになるかもしれません:

```python
def run(self, image: Batch[WorkflowImageData], confidence: float):
    pass
```

マニフェストでは、 `image` フィールドはバッチを受け入れるものとして宣言されています。

問題は、入力画像がバッチで動作しないブロックから来たときに発生しました。そのような場合、Execution Engineは個々の画像からバッチを構築できず、次のような苛立たしいコンパイルエラーにつながることがよくありました:

```
ステップ`$steps.model`のプロパティ`images`に不正な参照が差し込まれました - そのステッププロパティは 
バッチ指向の入力を厳密に必要としますが、入力セレクタは非バッチ指向の入力を保持しています - これは 
あなたのワークフロー構築に問題があることを示します。通常、この問題は非バッチ指向のステップ入力が 
非バッチ指向ステップの出力や非バッチ指向入力で埋められているときに発生します。
```

Execution Engineでは `v1.6.0`、この制限は削除され、次の動作が導入されました:

* ある入力がバッチ指向でなければならないと検出された場合、次の手順が適用されます **Auto Batch Casting** が適用されます。これにより、入力は自動的に次のものへ変換されます `Batch[T]`。すべてのバッチモード入力はすでにマニフェストで明示されていたため、ほとんどのブロック（下記の例外を除く）は内部変更なしでこの改善の恩恵を受けます。
* auto-batch castパラメータの次元数（ネストのレベル）は、ワークフロー内の特定のブロックのコンテキストおよびそのマニフェストに基づいて、コンパイル時に決定されます。ほかのバッチ指向入力が存在する場合（次のように呼ばれます） *ラインエージサポート*）、Execution Engineは自動キャストされたバッチを構築する際にそれらを参照として使用します。これにより、各バッチ次元の要素数がそのステップに投入される他のデータと一致することが保証されます（実際のバッチ入力が与えられた場合にアサートされていたであろう内容を模擬します）。もし次がない場合 *ラインエージサポート*、またはブロックマニフェストがそれを要求する場合（例: 入力次元オフセットが設定されている）、不足している次元は次のように生成されます [`torch.unsqueeze(...)` 操作](https://docs.pytorch.org/docs/stable/generated/torch.unsqueeze.html).
* その後、ステップ出力はAuto Batch Castingコンテキストの有無に基づいて評価されます。評価結果に応じて、出力はバッチまたはスカラーのどちらかとして保存され、キャストの影響が局所的に留まるようになります。唯一の例外は、ブロック自体によって導入された出力次元の変化です。副作用として、現在は次が可能です:
  * **スカラーから出力バッチを作成する** （ステップが次元を増やす場合）、および
  * **バッチをスカラーに折りたたむ** （ブロックが次元を減らす場合）。
* 摩擦が生じる可能性のある点は2つあります。まず **バッチを受け付けないブロックが** （したがってバッチを受け付ける入力を明示しない） **出力次元を減らす場合**。以前のバージョンでは、Execution Engineはこれを次元ラッピングで処理していました。すべてのバッチ指向入力に追加の `Batch[T]` 次元が付与され、ブロックの `run(...)` メソッドがリスト次元全体に対してreduce操作を実行できるようにしていました。しかしAuto Batch Castingでは、そのようなブロックは特定の入力がスカラーかバッチかについてExecution Engineに明確なシグナルをもはや与えないため、キャストは非決定的になります。これに対処するため、新しいマニフェストメソッドが導入されました: `get_parameters_enforcing_auto_batch_casting(...)`。このメソッドは、次元が減るときにバッチキャストを強制すべきパラメータの一覧を返さなければなりません。ほかの文脈で使用されることは想定されていません。

{% hint style="warning" %}
**既存ブロックへの新メソッドの影響**

定義する要件 `get_parameters_enforcing_auto_batch_casting(...)` 上記の場合にAuto Batch Casting機能を完全に使うためのメソッドは必須ではありません。ブロックが変更されない場合、唯一の影響は、以前は **失敗していたワークフローが** コンパイルエラーで動作するか、あるいは失敗する可能性があることです **実行時エラー**、ブロックの詳細に依存します `run(...)` メソッド実装。
{% endhint %}

* 2つ目の摩擦点は、次を使ってバッチとスカラーをサポートする入力フィールドを宣言するブロックがある場合に生じます `get_parameters_accepting_batches_and_scalars(...)` - デフォルトでは、Execution Engineはそのようなパラメータの自動キャストをスキップします。なぜなら、そのメソッドは歴史的に **ブロック自体がスカラーをバッチへブロードキャストできる能力を持つことを宣言する方法だったからです** - 参照 [の実装 `roboflow_core/detections_transformation@v1`](https://github.com/roboflow/inference/blob/main/inference/core/workflows/core_steps/transformations/detections_transformation/v1.py) ブロックです。ある意味で、Auto Batch Castingは *冗長です* それらのブロックにとっては冗長なので、現状のまま残し、次を使うようにアップグレードすることを提案します `get_parameters_enforcing_auto_batch_casting(...)` ではなく `get_parameters_accepting_batches_and_scalars(...)` そのようなブロックの新しいバージョンで。
* 以前のバージョンでは、厳しい制約があり、次元の縮小はレベル2以上（つまりネストされたバッチ上のみ）でしか起こりませんでした。この制限は現在削除されました。次元縮小ブロックはスカラー上でも動作でき、出力次元はゼロの土台で「跳ね返る」ようになります。

1つあります **出力の構築方法における重要な変更が** 以前のExecution Errorでは、ブロックが次を生成することは許可されていませんでした `Batch[X]` を最初の次元レベルで直接 - その領域は入力バッチへのマッピング用に予約されていました。バージョン `v1.6.0`以降、この制限は削除されました。

以前は、出力は常に要素のリストとして返されていました:

* 入力バッチに対応したもの、または
* 入力がスカラーのみの場合は単一要素のリストとして。

ここで疑問が生じました。ブロックが最初の次元レベルでバッチを生成する場合、どうすべきか？単純に `zip(...)` それを入力ベースの出力と組み合わせることはできません。というのも、これら新しく生成されたバッチのサイズが入力要素数と一致しない可能性があり、操作が曖昧になるからです。

これを解決するため、次のルールを採用しました:

* その状況を、次のものがあるかのように扱います **サイズ1の「ダミー」入力バッチ**.
* スカラー入力から生成されたすべてのバッチは、見た目より1段深いものとして扱います。
* これはブロードキャストの原則に従っており、そのような出力が全要素にわたって一貫して拡張されるようにします。
* 実行の結果、入力バッチが消えることがありますが、その際に新しい第1レベルの次元が現れても、出力の一貫性を保つために仮想的にネストされたものとして扱われます。

**例:**

```
（入力なし）    IMAGE FETCHER BLOCK --> image --> OD MODEL --> predictons --> CROPS --> 出力は次のようになります: ["crops": [<crop>, <crop>, ...]] 
```

重要なのは **以前に作成された有効なワークフローから生成される結果は同じであることです** また、この変更は新しい機能を利用するために作成された新規ワークフローにのみ影響します。

### 移行ガイド

<details>

<summary>`get_parameters_enforcing_auto_batch_casting(...)`メソッドの追加</summary>

出力次元を減らし、バッチ指向入力を定義しないブロックは、実装が次のようにラップされることを想定するすべての入力を宣言する必要があります `Batch[T]` 次の名称のブロックマニフェストの新しいクラスメソッドで `get_parameters_enforcing_auto_batch_casting(...)`

```python
from typing import List, Literal, Type, Union

import supervision as sv

from inference.core.utils.drawing import create_tiles
from inference.core.workflows.execution_engine.entities.base import (
    Batch,
    OutputDefinition,
    WorkflowImageData,
)
from inference.core.workflows.execution_engine.entities.types import (
    IMAGE_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    Selector,
)
from inference.core.workflows.prototypes.block import (
    BlockResult,
    WorkflowBlock,
    WorkflowBlockManifest,
)

class BlockManifest(WorkflowBlockManifest):
    type: Literal["my_plugin/tile_detections@v1"]
    crops: Selector(kind=[IMAGE_KIND])
    crops_predictions: Selector(
        kind=[OBJECT_DETECTION_PREDICTION_KIND]
    )
    scalar_parameter: Union[float, Selector()]

    @classmethod
    def get_output_dimensionality_offset(cls) -> int:
        return -1

    @classmethod
    def get_parameters_enforcing_auto_batch_casting(cls) -> List[str]:
        return ["crops", "crops_predictions"]

    @classmethod
    def describe_outputs(cls) -> List[OutputDefinition]:
        return [
            OutputDefinition(name="visualisations", kind=[IMAGE_KIND]),
        ]

class TileDetectionsBlock(WorkflowBlock):

    @classmethod
    def get_manifest(cls) -> Type[WorkflowBlockManifest]:
        return BlockManifest

    def run(
        self,
        crops: Batch[WorkflowImageData],
        crops_predictions: Batch[sv.Detections],
        scalar_parameter: float,
    ) -> BlockResult:
        print("これは自動バッチキャストされないパラメータです!", scalar_parameter)
        annotator = sv.BoxAnnotator()
        visualisations = []
        for image, prediction in zip(crops, crops_predictions):
            annotated_image = annotator.annotate(
                image.numpy_image.copy(),
                prediction,
            )
            visualisations.append(annotated_image)
        tile = create_tiles(visualisations)
        return {"visualisations": tile}
```

* 行内で `34-36` 強制的な自動バッチキャストの対象となるフィールドの宣言を追加する必要があります
* 上記の結果、runメソッドの入力パラメータ（行 `53-54`）は次のようにラップされます `Batch[T]` Execution Engine によって。

</details>

## Execution Engine `v1.5.0` | inference `v0.38.0`

{% hint style="info" %}
**この変更に対して必要な対応はありません**

この変更は Workflows ユーザーに何の変更も要求しません。これは単なる性能最適化です。
{% endhint %}

* の init メソッドに新しいパラメータを公開しました `BaseExecutionEngine` クラス - `executor` Python のインスタンスを受け取ることができ `ThreadPoolExecutor` エグゼキューションエンジンで使用されます。この変更により、各 `BaseExecutionEngine.run(...)` は専用のインスタンスを必要としなくなります `ThreadPoolExecutor` これまでのように。さらに、スレッドの生成を大幅に制限しており、一部の環境ではこれも利点となる可能性があります。
* この変更にもかかわらず、Execution Engine は同時に実行されるステップ数の上限を維持します。これは、一度に executor を通過して実行されるステップ数を制限することで実現されます（Execution Engine はもはや `ThreadPoolExecutor` 生成を制御していないため、プールに利用可能なワーカーがより多く存在する可能性があるためです）。

<details>

<summary>ThreadPoolExecutor を Execution Engine に注入するには？</summary>

```python
from concurrent.futures import ThreadPoolExecutor
workflow_init_parameters = { ... }
with ThreadPoolExecutor(max_workers=...) as thread_pool_executor:
    execution_engine = ExecutionEngine.init(
        init_parameters=workflow_init_parameters,
        max_concurrent_steps=4,
        workflow_id="your-workflow-id",
        executor=thread_pool_executor,
    )
    runtime_parameters = {
      "image": cv2.imread("your-image-path")
    }
    results = execution_engine.run(runtime_parameters=runtime_parameters)
```

</details>

## Execution Engine `v1.4.0` | inference `v0.29.0`

* 新しい kind を追加しました - [`secret`](/workflows/ja/gaido/developer-guide/kinds/secret.md) 認証情報を表すためのものです。 **対応は不要です** 既存のブロックについては不要ですが、今後はブロック開発者が、ブロックがパラメータとして秘密値を受け取る場合にはこの kind を使うことが期待されます。
* で導入された結果のシリアライズに関する問題を修正しました `v1.3.0` - うっかり、Execution Engine がバッチ指向ではない出力をシリアライズしていませんでした。
* ステップ用の入力準備に関する Execution Engine のバグを修正しました。以前は非 SIMD ステップについて、実行時に入力を収集する際に、 `WorkflowBlockManifest.accepts_empty_input()` メソッドの結果が無視されており、そのため 1 つの非 SIMD ステップが下流のブロックに空の値を渡したときにバグが発生していました。さらに、で行われた変更を踏まえると `v1.3.0`、これにより非 SIMD ブロックが下流の SIMD ステップへの入力を容易に供給できるようになったため、上流の非 SIMD ブロックが空でない結果を返したかどうかを確認する必要があります（SIMD ブロックは空の結果を受け取れない場合があるため）。このチェックを追加しました。 **対応は不要です** 既存のブロックに対してですが、この修正によって以前壊れていた Workflows が修正される可能性があります。

## Execution Engine `v1.3.0` | inference `v0.27.0`

* 各 kind に serializer と deserializer を定義できるようにする変更を導入しました。この変更により Workflows プラグインと Execution Engine が分離され、ワイヤ経由のデータ転送を必要とする外部システムとエコシステムを統合できるようになります。 [ブロックのバンドリング](/workflows/ja/gaido/developer-guide/block-bundling.md) ページはその変更を反映するよう更新されました。
* *Kinds* で定義された `roboflow_core` プラグイン内のものには適切な serializer と deserializer が提供されました
* Workflows Compiler と Execution Engine は次のように拡張されました： **任意のバッチ指向入力をサポートするように&#x20;*****種類***、以前のバージョンとは対照的に `v1.3.0`、それは次のものしか取れませんでした `image` と `video_metadata` kind をバッチ指向入力として（kind と内部データ形式の不要かつ不幸な結合の結果として）受け取ることしかできませんでした **Execution Engine のレベルで**）。この変更の結果：
  * **新しい入力タイプが導入されました：** `WorkflowBatchInput` 今後はバッチ指向入力を示すために使用すべきです（そして、次のものと明確に区別します： `WorkflowParameters`). `WorkflowBatchInput` ユーザーが両方を定義できるようにし [*種類*](/workflows/ja/gaido/developer-guide/kinds.md) データのそしてその [*次元数*](/workflows/ja/gaido/developer-guide/workflow-execution.md#steps-interactions-with-data)。新しい入力タイプは、実質的にこれまでのすべてのバッチ指向入力のスーパーセットです： `WorkflowImage` と `WorkflowVideoMetadata`、これは **引き続きサポートされます**、しかし **Execution Engine から削除されます `v2`**。新しい入力形式への調整を推奨しますが、現時点では必須ではありません。というのも、Execution Engine は現在、入力データの明示的な定義を必要としているためです *種類* データのデシリアライザを適切に選択するためです。将来的にはそうでなくなる可能性があります。というのも、ほとんどの場合バッチ指向データは *種類* コンパイラによって推論される可能性があるためです（ただし、この機能は現時点では未実装です）。
  * **新しい selector 型注釈が導入されました**  - 単に `Selector(...)`. `Selector(...)` は置き換えることを意図しています `StepOutputSelector`, `WorkflowImageSelector`, `StepOutputImageSelector`, `WorkflowVideoMetadataSelector` と `WorkflowParameterSelector` ブロックマニフェストにおいて、特定のステップのマニフェストプロパティが特定の selector のいずれかを保持できることを開発者が表現できるようにします *種類*。言及した旧注釈型は **非推奨と見なすべきです**、私たちは次へ移行することを推奨します `Selector(...)`.
  * selector 型注釈の簡素化により、旧 selector はブロックのどのパラメータが `run(...)` メソッドは Execution Engine によって次のものに包まれて提供されます： [`Batch[X]` コンテナ](/workflows/ja/gaido/developer-guide/data-representations.md#batch)。旧 selector 型注釈および `block_manifest.accepts_batch_input()` メソッドの代わりに、バッチ指向データで入力されることが想定されるパラメータを明示的に定義する 2 つのメソッドへの切り替えを提案します（`block_manifest.get_parameters_accepting_batches()`）と、両方を受け取れるパラメータ *バッチ* と *スカラー* 値（`block_manifest.get_parameters_accepting_batches_and_scalars()`）。の戻り値は `block_manifest.accepts_batch_input()` 2 つの新しいメソッドの結果に基づいて構築されています。この変更は **破壊的変更ではありません**。なぜなら、バッチを処理できる既存のブロックはすでに `block_manifest.accepts_batch_input()` メソッドを実装しており、 `True` バッチ指向データを示す適切な selector 型注釈を使用しているはずだからです。
* これらの変更により、次のことが可能になりました **任意のワークフローを、ステップのサブセットを実行する複数のワークフローに分割すること**が可能になり、デバッガーのようなツールを構築できるようになります。

**破壊的変更の予定 - Execution Engine `v2.0.0`**

* `WorkflowImage` と `WorkflowVideoMetadata` 入力は Workflows エコシステムから削除されます。
* `StepOutputSelector,` WorkflowImageSelector`,` StepOutputImageSelector`,` WorkflowVideoMetadataSelector`と`ブロックマニフェストで使用される \`WorkflowParameterSelector\` 型注釈は Workflows エコシステムから削除されます。{% hint %}

### 移行ガイド

<details>

<summary>Kinds の serializer と deserializer</summary>

Workflows プラグインを作成する際に、Workflows のためのカスタム serializer と deserializer を導入できます *kinds*。そのためには、以下の辞書をプラグインのメインモジュール（同じ場所に置くところ）に配置するだけです `load_blocks(...)` 関数）：

```python
from typing import Any

def serialize_kind(value: Any) -> Any:
  # ここに、次の用途で使うコードを配置します
  # 内部の Workflows データ表現を次へ変換するための 
  # 外部の表現へ（JSON でワイヤ経由で送信できます。使用するのは
  # Python のデフォルト JSON エンコーダです）。
  pass

def deserialize_kind(parameter_name: str, value: Any) -> Any:
  # ここに、デコードに使うコードを配置します 
  # ワイヤ経由で送られたデータを Execution Engine に取り込み
  # そして、それを適切な内部 Workflows データ表現に変換する
  # ブロックが理解できる形式です。
  pass

KINDS_SERIALIZERS = {
    "name_of_the_kind": serialize_kind,
}
KINDS_DESERIALIZERS = {
    "name_of_the_kind": deserialize_kind,
}
```

</details>

<details>

<summary>selector の新しい型注釈 - `Batch[X]` 入力を持たないブロック</summary>

ブロックマニフェストは **任意で** 次のものを使うよう更新できます `Selector` 次のように：

```python
from typing import Union
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    WorkflowImageSelector,
    StepOutputImageSelector,
    StepOutputSelector,
    WorkflowParameterSelector,
)

class BlockManifest(WorkflowBlockManifest):

    reference_image: Union[WorkflowImageSelector, StepOutputImageSelector]
    predictions: StepOutputSelector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    confidence: WorkflowParameterSelector(kind=[FLOAT_KIND]) 
```

は単純に次のように変更すればよいです：

```python
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    IMAGE_KIND,
    Selector,
)

class BlockManifest(WorkflowBlockManifest):
    reference_image: Selector(kind=[IMAGE_KIND])
    predictions: Selector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    confidence: Selector(kind=[FLOAT_KIND]) 
```

</details>

<details>

<summary>selector の新しい型注釈 - `Batch[X]` 入力を持つブロック</summary>

ブロックマニフェストは **任意で** 次のものを使うよう更新できます `Selector` 次のように：

```python
from typing import Union
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    WorkflowImageSelector,
    StepOutputImageSelector,
    StepOutputSelector,
    WorkflowParameterSelector,
)

class BlockManifest(WorkflowBlockManifest):

    reference_image: Union[WorkflowImageSelector, StepOutputImageSelector]
    predictions: StepOutputSelector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    data: Dict[str, Union[StepOutputSelector(), WorkflowParameterSelector()]]
    confidence: WorkflowParameterSelector(kind=[FLOAT_KIND]) 

    @classmethod
    def accepts_batch_input(cls) -> bool:
        return True
```

は次のように変更すべきです：

```python
from inference.core.workflows.prototypes.block import WorkflowBlockManifest
from inference.core.workflows.execution_engine.entities.types import (
    INSTANCE_SEGMENTATION_PREDICTION_KIND,
    OBJECT_DETECTION_PREDICTION_KIND,
    FLOAT_KIND,
    IMAGE_KIND,
    Selector,
)

class BlockManifest(WorkflowBlockManifest):
    reference_image: Selector(kind=[IMAGE_KIND])
    predictions: Selector(
        kind=[
            OBJECT_DETECTION_PREDICTION_KIND,
            INSTANCE_SEGMENTATION_PREDICTION_KIND,
        ]
    )
    data: Dict[str, Selector()]
    confidence: Selector(kind=[FLOAT_KIND]) 

    @classmethod
    def get_parameters_accepting_batches(cls)W -> List[str]:
        return ["predictions"]

    @classmethod
    def get_parameters_accepting_batches_and_scalars(cls) -> List[str]:
        return ["data"]
```

次の点に注意してください：

* 以内であること、 `データ` 元の例のプロパティは両方を受け取ることができました **バッチ** のデータと **スカラー** 値を、バッチ指向データの selector（`StepOutputSelector`）および *スカラー* データ（`WorkflowParameterSelector`）。現在は同じことが次で表現されます `Selector(...)` 型注釈と、次のメソッドの戻り値によって `get_parameters_accepting_batches_and_scalars(...)` メソッド。

</details>

<details>

<summary>Workflows 定義における新しい入力</summary>

次のいずれかを使用していた人は `WorkflowImage` または `WorkflowVideoMetadata` 自身の Workflows 定義での入力を **任意で** 次へ移行できます `WorkflowBatchInput`。移行は以下に示します：

```json
{
  "inputs": [
    {"type": "WorkflowImage", "name": "image"},
    {"type": "WorkflowVideoMetadata", "name": "video_metadata"}
  ]
}
```

は次のように変更すべきです：

```json
{
  "inputs": [
    {
      "type": "WorkflowBatchInput",
      "name": "image",
      "kind": ["image"]
    },
    {
      "type": "WorkflowBatchInput",
      "name": "video_metadata",
      "kind": ["video_metadata"]
    }
  ]
}
```

**空欄のままにすると `種類` フィールドが空だと、画像のような一部のデータが正しくデシリアライズされない可能性があります。**

**注記**

でデータがシリアライズされる方法が気に入らない場合は `roboflow_core` プラグイン内で、次のためのシリアライズメソッドを自由に変更してください *kinds*、プラグインに関数を登録して Execution Engine に読み込むだけです。最後に定義された serializer/deserializer が使用されます。

</details>

## Execution Engine `v1.2.0` | inference `v0.23.0`

* この [`video_metadata` 種類](/workflows/ja/gaido/developer-guide/kinds/video-metadata.md) は非推奨となり、私たちは **今後ブロックを構築するためにその使用をやめることを強く推奨します**。代替として、 [`image` 種類](/workflows/ja/gaido/developer-guide/kinds/image.md) は、次と同じメタデータをサポートするよう拡張されました [`video_metadata` 種類](/workflows/ja/gaido/developer-guide/kinds/video-metadata.md)。これは任意で指定できるようになりました。この更新は **破壊的変更ではありません** 既存のブロックに対しては、しかし **一部の古いブロックは** 画像を出力する **互換性がなくなる可能性があります** と **将来の** 動画処理ブロック。

<details>

<summary>ブロックの潜在的な非互換性</summary>

前述のとおり、次を追加すると `video_metadata` の内部表現に任意フィールドとして [`image` 種類](/workflows/ja/gaido/developer-guide/kinds/image.md) (`WorkflowImageData` クラス）に追加すると、を出力する既存ブロックと [`image` 種類](/workflows/ja/gaido/developer-guide/kinds/image.md) および次に依存する将来の動画処理ブロックとの間で、いくらかの摩擦が生じる可能性があります `video_metadata` が一部であること `image` 表現。

この問題は、提供はできるものの、 **デフォルト** の値を `video_metadata` で `image` 入力から明示的にコピーしなくても、上流で追加された任意の非デフォルトメタデータが失われる可能性があるためです。これにより、次に依存する下流ブロックが `video_metadata` 期待どおりに動作しなくなる可能性があります。

既存のすべての `roboflow_core` ブロックはこれを考慮するよう更新しましたが、外部リポジトリでこの変更以前に作成されたブロックは、その出力画像が動画処理ブロックで使用されるワークフローにおいて問題を引き起こす可能性があります。

</details>

* 非推奨の [`video_metadata` 種類](/workflows/ja/gaido/developer-guide/kinds/video-metadata.md) はまだ使用できますが、Execution Engine バージョンで完全に削除されます `v2.0.0`.

{% hint style="warning" %}
**破壊的変更の予定 - Execution Engine `v2.0.0`**

[`video_metadata` 種類](/workflows/ja/gaido/developer-guide/kinds/video-metadata.md) は非推奨となり、次で削除されます `v2.0.0`
{% endhint %}

* 上記の変更の結果、の内部表現は [`image` 種類](/workflows/ja/gaido/developer-guide/kinds/image.md) 新しいものを含むよう更新されました `video_metadata` プロパティ。このプロパティはコンストラクタで任意に設定できます。指定しない場合は、妥当なデフォルト値を持つ既定値が使用されます。ブロック内でのメタデータ操作を簡単にするために、2 つの新しいクラスメソッドを導入しました： `WorkflowImageData.copy_and_replace(...)` と `WorkflowImageData.create_crop(...)`。詳細は、更新された [`WoorkflowImageData` 使用ガイド](/workflows/ja/gaido/developer-guide/data-representations.md#workflowimagedata).