For the complete documentation index, see llms.txt. This page is also available as Markdown.

モデル ID

モデル ID の構成と、従来の project/version ID がモデルにどのように解決されるか。

すべての学習済みモデルにはモデルIDがあり、デプロイ時、推論実行時、または Workflow のモデルブロックで選択するときにそれを識別します。このページでは、モデルIDの現在の構造と、以前の(レガシー)形式のIDがどのような場合に引き続きサポートされるかを説明します。

モデルIDの構造

A model ID has the form {workspace}/{model-slug}。最初の部分はワークスペースの URL スラッグです。2番目の部分であるモデルスラッグは、ワークスペース内でモデルを識別し、ハイフンでつないだ 4 つの部分から成ります:

{project}-{version}-{architecture}-t{n}
  • project:モデルが属するプロジェクトの URL スラッグ。例: construction-safety-xpv3w.

  • version:モデルが学習されたデータセットのバージョン番号。例: 12.

  • アーキテクチャ:学習に使用されたモデルアーキテクチャ。例: rfdetr-small.

  • t{n}:そのバージョンの学習回数カウンタです。あるバージョンで最初に開始された学習は t1、2回目は t2、その後も同様です。

たとえば、URL スラッグが construction-safety-xpv3w ワークスペース内の my-workspace モデルIDを生成します my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2.

モデルスラッグは学習開始時に割り当てられるため、学習中でもそのモデルのIDを確認できます。学習カウンタの接尾辞は再利用されません。学習が失敗またはキャンセルされた場合、その番号は飛ばされ、次にそのバージョンで行われる学習には次の番号が割り当てられます。

1つの Neural Architecture Search 学習では多数の候補モデルが生成されます。NAS の候補モデル ID は他のモデル ID と似ていますが、末尾にダブルハイフンと 6 文字のハッシュが追加されます(例: my-workspace/construction-safety-xpv3w-3-rfdetr-nas-t1--9589f2)。v2 の trainings エンドポイントでは、NAS 学習はその modelTyperfdetr-nas-parentを報告し、一方で各候補モデルは rfdetr-nas.

モデルIDを見つける

Web UI、REST API、または Roboflow MCP Server を使って、任意の学習済みモデルのIDを確認できます。

プロジェクトのサイドバーで「Models」をクリックして、 Models ページ。各モデルの「ID:」ラベルの横にIDが表示され、その横には「Copy Model ID」ボタンがあります。同じIDとコピー ボタンは、モデルの詳細ビューおよび各バージョンページのモデル一覧テーブルにも表示されます。

レスポンスの プロジェクトのモデルを一覧表示 エンドポイントは、プロジェクトで学習されたすべてのモデルを返します。各エントリの url フィールドがモデルIDです:

GET https://api.roboflow.com/{workspace}/{project}/models?api_key=YOUR_API_KEY
[
  {
    "url": "my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2",
    "version": "3",
    "modelType": "rfdetr-small",
    "train": { "status": "finished" },
    ...
  },
  ...
]

特定のバージョンで学習されたモデルを見つけるには、v2 trainings エンドポイントを使用します。あるバージョンの trainings を一覧表示すると、各学習が生成したモデルの ID がその modelIds フィールドに返されます。レガシーな単一モデルのバージョンでは、training の id は次の形式のパスです {workspaceId}/{version}/training/0 (下に示すハッシュではなく)、また modelIds そのバージョンの レガシーID が含まれます:

GET https://api.roboflow.com/{workspace}/{project}/{version}/v2/trainings?api_key=YOUR_API_KEY
{
  "trainings": [
    {
      "id": "0a1b2c3d4e5f67890abc",
      "versionId": "3",
      "status": "finished",
      "modelType": "rfdetr-small",
      "modelIds": ["my-workspace/construction-safety-xpv3w-3-rfdetr-small-t2"],
      ...
    },
    ...
  ]
}

単一の training を取得すると、モデルごとの詳細が返されます。その中には、 modelId その models リストに含まれます。省略できます trainingId バージョンに training が1つしかない場合は省略できますが、バージョンに複数の training がある場合、そのようなリクエストは 409 エラーで失敗します。

レスポンスの Roboflow MCP Server モデルIDを返すツールを提供します。 models_list 1つのプロジェクトの学習済みモデルを一覧表示します(ワークスペースは接続の認証情報から取得され、プロジェクトは project_idとして渡され)、各モデルのIDをその url フィールドに返します。必要に応じて、バージョンまたは NAS 実行で絞り込めます。 trainings_gettrainings_list 各 training が生成したモデルのIDを返します。エージェントはこれらのIDを、たとえば次のような他のツールに渡せます。 models_infer.

レガシーモデルID

以前は、Roboflow のデータセットバージョンには 1 回の training run しか持てなかったため、モデルは次の形式の ID によって一意に決まっていました {project}/{version}.

たとえば、 construction-site-safety/3 は、次を指していました その プロジェクトのバージョン 3 で学習されたモデルです。最初の部分はワークスペースではなくプロジェクトの URL スラッグで、2番目の部分はバージョン番号です。これは、古い SDK、コードスニペット、Inference のインストールで使用される形式です(例: model_id="construction-site-safety/3").

現在は次のことが可能になったため 1つのデータセットバージョンで複数回の training を実行できるようになったため、こうしたレガシー形式のIDはもはや推奨されません。2026年6月30日以降に開始された新しい training でそのようなIDを使用しようとすると、内部的には新しい形式のIDに解決されます。

レガシーIDの解決方法

レガシー形式のIDはエイリアスを通じて引き続き機能します。あるバージョンで最初に開始された training が正常に完了すると、Roboflow はそのバージョンのレガシー {project}/{version} ID を新しいモデルIDに紐付けます。レガシーIDを使用するリクエストは、古い Inference インストールからの weights ダウンロードを含め、自動的にそのモデルに解決されます。

エイリアスが作成されるのは 最初の そのバージョンでの training のみであり、その後変更されません:

  • 最初の training が正常に完了した場合、その後同じバージョンでさらにモデルを学習しても、レガシーIDはそのモデルを永続的に指します。後続のモデルは、それぞれのモデルIDで参照してください。

  • 最初の training が失敗またはキャンセルされた場合、エイリアスは作成されず、その後そのバージョンで行われる training でも作成されません。

エイリアスのないバージョンでも、含まれるモデルがちょうど1つである限り、そのレガシーIDで参照できます。複数のモデルを含み、かつエイリアスがない場合は、参照が曖昧になるためレガシーIDを使ったリクエストは失敗し、モデル自身のIDを使用する必要があります。

レガシーIDは後方互換性のために存在します。新しい統合では完全なモデルIDを使用することを推奨します。これらは曖昧さがなく、バージョン内のすべてのモデルで機能します。

最終更新

役に立ちましたか?