Ctrlk
ResourcesDocsSign InBook a DemoGet Started
For the complete documentation index, see llms.txt. This page is also available as Markdown.

サポート依頼に含める内容

問題を再現できるほど、修正も早くなります。以下の各カテゴリには、調査を加速し、やり取りを減らすための具体的な情報が記載されています。

Roboflow サポートチームは、問題を再現できるだけの十分な詳細がリクエストに含まれていると、より迅速に問題を解決できます。以下から該当する状況を見つけ、問い合わせ時に記載されている情報を含めてください。

必ず含めるべき項目

問題の種類にかかわらず、次の5つを含めると、どのサポートケースも早く進みます。

  1. プロジェクトとワークスペース: ワークスペース ID、または影響を受けているプロジェクトもしくはワークスペースへの直接リンク。（メールで送信する場合に必要です。そうでなければ、通常は自動的に把握できます。）

  2. ワークスペースへのアクセス: Roboflow サポートチームにワークスペースへのアクセスを付与してください.

  3. 正確なエラー: 言い換えではなく、エラーメッセージやレスポンスボディをそのまま記載してください。

  4. 時間帯: 「昨日」ではなく、UTC の具体的なタイムスタンプ。

  5. 試したこと: 各試行とその結果。

Inference API のエラー

本番アプリケーションが、次から HTTP 4xx または 5xx の応答を受け取り始めます。 serverless.roboflow.com。エラーメッセージには「Internal error」「Model is temporarily not ready - retry request」「Could not acquire model manager lock」、または30秒後のタイムアウトが含まれることがあります。失敗率は急激に上昇し、しばしば狭い時間帯に集中します。

これらのエラーは、プラットフォーム側のインフラ障害、負荷時にメモリからモデルが追い出されること、またはキャパシティを圧迫するクライアント側のリクエストパターンに起因する可能性があります。時間帯とリクエストログがなければ、特定の問題に絞り込むのは困難です。

最も役立つ情報:

  • 失敗が起きた正確な時間帯。タイムゾーンまたは UTC オフセットを含めてください。（「2026-05-22 12:30–12:40 UTC」は「今朝」よりもはるかに対応しやすいです。）

  • 完全な推論エンドポイント URL（例: https://serverless.roboflow.com/test-endpoint/11 の Serverless Cloud API、または name.deployment@roboflow.com の 専用デプロイメント).

  • HTTP ステータスコード、レスポンスボディ、タイムスタンプが分かる、エラーレスポンスのスクリーンショットまたはログのエクスポート。アプリケーションや監視ダッシュボードでイベントが表示されているスクリーンショットが理想的です。

  • その時間帯のおおよそのリクエスト量：送信した総リクエスト数、失敗数、送信パターン（バーストか、一定か）。

  • 失敗がまだ継続しているか、すでに解消したか。

  • 失敗したリクエストに対してクレジットが消費されたか。

記入例:

「2026-05-22 の UTC 11:20〜11:35 の間に、 https://serverless.roboflow.com/test-endpoint/11 に対して約90%の失敗率が発生しました。その時点では、おおよそ1時間あたり150リクエストを送信していました。エラーは HTTP 503 で、本文は {"message":"Internal error."} でした。アプリケーションログのスクリーンショットを添付しています。失敗は 11:40 AM ごろに自然解消したようです。ワークスペース ID は fleet-pulse です。失敗したリクエストに対して課金されましたか？」

Inference のパフォーマンス問題

推論サーバーは正常に動作しているものの、想定より多くのメモリを消費する、時間とともに増加する、負荷時に遅くなる、または用途に対して許容できないほど高いレイテンシを生じる場合です。よくある例としては、Jetson デバイス上で数時間かけてメモリが無制限に増える、大きなモデルの最初のリクエスト時の読み込みが長すぎる、並列バッチリクエストでスループットが低下する、などがあります。

メモリとレイテンシは、モデルのアーキテクチャ、バッチサイズ、同時実行設定、画像サイズ、ハードウェア、そして 推論サーバー のバージョンに依存します。ほぼすべての変数が重要です。

最も役立つ情報:

  • 推論サーバーのバージョン: 正確な Docker イメージタグ（例: roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6).

  • ハードウェア仕様: GPU モデル、総 RAM、Jetson を使用しているかどうか、またその JetPack バージョン。

  • 読み込んでいる全モデルのモデル ID と種類（例: object-detection-5gavt/16、YOLOv8-s、ViT 224×224）、さらにデバイス向けの TRT パッケージの有無。

  • クライアント設定: max_concurrent_requests, max_batch_size、およびクライアント側でバッチをどのように構成しているか。

  • 劣化のパターンが分かる、時間経過に伴うメモリまたは CPU 使用率のグラフ（例: jtop, htopのスクリーンショット、または約1時間分のメモリを示す監視ツール）。

  • 一般的な画像サイズ（KB）または、分かる場合は正確なピクセル寸法。

  • 使用中の環境変数の上書き（例: USE_INFERENCE_MODELS=True/False).

  • すでに試した手順（バージョンのロールバックやフラグ変更を含む）と、それぞれの影響。

記入例:

「NVIDIA Jetson AGX Orin（JetPack 5.1.1）上で roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6 を実行しています。7個のモデルを同時に読み込んでおり、2つは YOLOv8-s の物体検出、5つは ViT の分類モデルです。本番負荷下で約2時間後（max_concurrent_requests=10、max_batch_size=100、画像サイズ約50KB）、メモリが 8GB から約15GB まで上昇します。jtop のグラフを添付しています。USE_INFERENCE_MODELS=False を設定してみたところ、メモリはおおむね半減しましたが、精度も低下しました。」

Serverless Workflow のエラー

Roboflow の Workflow （Workflows UI または serverless.roboflow.com/infer/workflows/...経由でアクセス）がエラーを返す、タイムアウトする、または予期しない結果を生成する場合です。エラーは HTTP 500 の「Internal error」、502 の「Bad gateway」、またはジョブは実行されたように見えるのにデータが返らない静かな失敗のことがあります。これは単純なモデル推論の失敗とは異なり、通常は複数ステップのパイプライン、カスタム Python ブロック、または複雑なブロック連鎖が関係します。

Workflow はパイプラインのどの段階でも失敗し得ます。どのブロックに問題があるのか、どれだけのリクエストがどのようなパターンで送信されたのか、そして正確な Workflow 定義が分かると、根本原因を絞り込めます。

最も役立つ情報:

  • 完全な Workflow URL（例: https://serverless.roboflow.com/infer/workflows/test/test-workflow).

  • 失敗がいつ発生したかの内訳。タイムスタンプと、時間帯ごとのおおよそのリクエスト数を含めてください。

  • 失敗したリクエストの HTTP ステータスコードと完全なレスポンスボディ。「500 Internal Error」だけよりも、完全なレスポンスボディの方がはるかに有用です。

  • 失敗が完全に起きているか（すべてのリクエストが失敗）、部分的に起きているか（一部は成功）.

  • Roboflow サポートチームへのワークスペースアクセス、これにより Workflow 定義とサーバー側ログを確認できます。

  • 失敗が始まる前に Workflow に最近加えた変更（新しいブロックの追加、モデルの差し替え、画像入力の変更など）。

  • バッチジョブの場合: バッチジョブ 「Activity」セクションにある ID、期待値と実際の出力レコード数、そしてジョブの所要時間。

記入例:

「私たちの Workflow は https://serverless.roboflow.com/infer/workflows/my-workspace/classifier-pipeline で、2026-05-25 の UTC 12:33〜12:40 の間に 195 件中 170 件の HTTP 500 応答が返りました。リクエストは 1 回あたり約15件のバーストで到着しました。すべての失敗についてレスポンスボディは {"message":"Internal error."} でした。Workflow は約10分後に自力で復旧しました。最近 Workflow は変更していません。support@roboflow.com にワークスペースアクセスを付与済みです。」

モデル学習の問題

ある 学習 ジョブが完全に失敗する、停止したままになる、詳細のない一般的なエラーポップアップが出る、学習済みモデルを生成せずにクレジットだけ消費する、または学習後にモデルが予想外の振る舞いをする場合です（例: 検出上限が想定より低い、あるいは大きなデータセットでの学習がバージョン生成中にハングする）。

学習の失敗は、データセットの特性（破損画像、ラベル形式の問題、クラス不均衡）、リソース制約、またはプラットフォームの不具合が原因で起こり得ます。サポートチームは、あなたの特定のプロジェクトとデータセットを確認する必要があります。

最も役立つ情報:

  • 学習しようとしたモデルの種類とサイズ（例: RF-DETR Nano、YOLOv8-L、SAM3）。

  • モデル名、または影響を受けているモデルへの直接リンク（例: app.roboflow.com/my-workspace/my-project/models/my-model).

  • 学習に使用したデータセットのバージョン番号。

  • エラーメッセージは言い換えずに、全文をそのままコピー＆ペーストしてください。ポップアップに表示される場合はスクリーンショットを撮ってください。

  • UI に表示されている場合は、学習ジョブ ID。

  • 失敗した試行に対してクレジットが請求されたか。

  • データセットバージョン内の画像数とクラス数。

  • 失敗前にデータセットへ最近加えた変更（新しい画像の追加、クラス名の変更、前処理設定の変更など）。

  • 基盤モデルのファインチューニング（例: SAM）の場合: データセットサイズ、使用したプロンプトの種類、どの段階でクラッシュしたか。

記入例:

「ワークスペース baz-co のプロジェクト foo-bar のデータセットバージョン 3 に対する YOLOv8-L の学習ジョブは、一般的なポップアップエラーで毎回失敗し、それ以上の詳細は表示されません。データセットには 12 クラスにまたがる約2,400枚の画像があります。2回の失敗試行でクレジットが請求されました。ここにエラーポップアップのスクリーンショットがあります。ワークスペースアクセスはサポートに付与済みです。」

データセットと画像の可視性の問題

アップロードされた画像がデータセット表示に現れない（ヘッダーの件数と、閲覧時に実際に見える数が異なる）、ラベル付け後にデータセットへ追加した画像が消える、データセットバージョンの準備がいつまでも終わらない、あるいはバッチ ZIP アップロードは成功したように見えるのに画像にアクセスできない場合です。

これらの問題では、バックエンドログの確認が必要になることがよくあります。サポートチームには、正確なプロジェクト識別子と、できれば該当するアップロードイベントの記録が必要です。

最も役立つ情報:

  • 数の不一致: プラットフォームが表示する画像数と、データセットタブを閲覧したときに実際に見える画像数（例: 「ヘッダーでは 1,004 枚と表示されるのに、閲覧すると 368 枚しか表示されない」）。

  • アップロードが発生した時刻。プラットフォーム上のイベントとの対応付けに役立ちます。

  • 使用したアップロード方法: ブラウザのドラッグ＆ドロップ、Python SDK、REST API、ZIP アップロード、またはモバイルアプリ。

  • バッチまたは ZIP アップロードの場合: 利用可能であれば、「Activity」セクションのバッチジョブ ID。

  • 不一致（ヘッダー件数 vs. 閲覧表示）を示すスクリーンショット。

記入例:

「ワークスペース abc_def のプロジェクト foo_bar_2 では、プロジェクトヘッダーに 1,004 枚と表示されるのに、データセットタブを開くと 368 枚しか見えません。2026-05-25 の午前9時ごろ EST にドラッグ＆ドロップで画像をアップロードしました。ワークスペースアクセスは付与済みです。スクリーンショットを添付します。」

Roboflow アプリ UI のエラー

注釈エディタ以外の Roboflow Web アプリで何かが期待どおりに動作しない場合です。ページが読み込まれない、またはスピナーのまま止まる、データセットバージョンの削除などの操作は完了したように見えるが効果がない、設定パネルが開かない、アップロードがアクティビティキューで止まる、使用状況ダッシュボードが表示されない、またはボタンを押しても反応しない、などがあります。

UI の不具合は、裏で失敗または遅延しているネットワークリクエスト、または JavaScript エラーが原因であることが多く、見えているインターフェースには直接表示されません。ブラウザの開発者ツールを使うと、ネットワークと JavaScript のレベルで何が起きているかを確認できます。

最も役立つ情報:

  • 不具合を示す画面録画（Loom、動画、または GIF）。この種のケースでは、これが最も価値の高い資料です。

  • ブラウザのネットワークリクエストログのスクリーンショット。どのリクエストが失敗しているか、または長時間実行されているかが分かります。開き方は Chrome のネットワークパネルのドキュメント を参照してください。ほかのブラウザにも同様のツールがあります。

  • ブラウザのコンソールログにあるエラー。開き方は Chrome のコンソールドキュメント を参照してください。ほかのブラウザにも同様のツールがあります。

  • 使用しているブラウザ名とバージョン（例: macOS 14.4 上の Chrome 124）。

  • 再現手順をステップごとに: フレッシュなページ読み込みから始めて、何をどの順番でクリックしたか。

  • 最近この不具合が出るようになったか、また、それが気づいているプラットフォーム更新と一致しているか。

  • 期待される正確な挙動と、実際の挙動。

  • 問題が常に発生するか、断続的か。

記入例:

「プロジェクト test-project のデータセットタブで（ワークスペース test-workspace）、バージョン3の 'Delete version' をクリックすると成功トーストが表示されますが、バージョンは一覧に残ったままです。ネットワークログのスクリーンショットには、 DELETE リクエストが 500 Internal Server Errorを返しているのが表示されています。コンソールには Uncaught TypeError: Cannot read properties of undefinedと表示されます。ブラウザ: Ubuntu 22.04 上の Firefox 126。通常ウィンドウとプライベートウィンドウの両方で再現しました。画面録画を添付します。」

注釈ツールのバグ

Roboflow の注釈エディタ内のツールが誤動作します。キーボードショートカットが効かなくなる、あるツールを選んでも別のツールに戻る、取り消し（Ctrl+Z）で想定以上に削除される、Label Assist がいつまでも読み込み中のままになる、または保存されるべき注釈が保存されない、などです。

注釈のバグは、ブラウザ固有、OS 固有、または最近のプラットフォームデプロイに起因することがよくあります。画面録画は、文章による説明よりもはるかに有益であることがほとんどです。

最も役立つ情報:

  • 不具合を示す画面録画（Loom、動画、または GIF）。注釈の挙動は言葉で説明しにくく、見せるのは簡単なので、この種のケースではこれが最も価値の高い資料です。

  • ブラウザのネットワークリクエストログのスクリーンショット。どのリクエストが失敗しているか、または長時間実行されているかが分かります。開き方は Chrome のネットワークパネルのドキュメント を参照してください。ほかのブラウザにも同様のツールがあります。

  • ブラウザのコンソールログにあるエラー。開き方は Chrome のコンソールドキュメント を参照してください。ほかのブラウザにも同様のツールがあります。

  • 使用しているブラウザ名とバージョン（例: macOS 14.4 上の Chrome 124）。

  • プロジェクトの種類（Object Detection、Instance Segmentation、Classification など）と、使用している具体的な注釈ツール（polygon、polyline、bounding box、smart polygon）。

  • 不具合を引き起こすキーボードショートカットまたは操作と、ステップごとの再現手順。

  • 問題がすべての画像に影響するか、特定の画像にのみ影響するか。特定の場合は、プロジェクトリンクと画像名または ID を共有してください。

  • 最近この不具合が出るようになったか、また、それが気づいているプラットフォーム更新と一致しているか。

  • 期待される正確な挙動と、実際に起こること。

  • 問題が常に発生するか、断続的か。

記入例:

「my-test-project と my-other-test-project（ワークスペース test-workspace）では、polyline ツールに最近導入された3つのバグがあります。(1) polyline ツール使用中に Ctrl+scroll でズームすると bounding box ツールに切り替わる。(2) Ctrl+Z で最後の点だけでなく注釈全体が削除されるようになった。(3) Esc を押すと注釈を破棄する代わりに保存される。こちらは各挙動を示す 2 本の Loom 録画です: [link 1], [link 2]。ブラウザ: Windows 11 上の Chrome 124。」

API 認証エラー

モデル推論エンドポイントへの API 呼び出し、Roboflow Python SDK、または HTTP API が、"Missing or insufficient permissions." のようなメッセージ付きで 403 Forbidden を返します。これは、プランをアップグレードした直後、非公開モデルにアクセスしようとしたとき、または API キーをローテーションした後に発生することがあります。

403 エラーは、API キーの誤りや期限切れ、プロジェクトレベルのキーの代わりにワークスペースレベルのキーを使っている（またはその逆）、その機能を含まないプランのモデルにアクセスしている、あるいはプランアップグレード後の権限伝播の遅延によって発生することがあります。

最も役立つ情報:

  • 完全なエラーレスポンス: ステータスコードだけでなく、HTTP ステータスコードとレスポンスボディ全体。SDK エラーの場合は、Python の完全なトレースバック。

  • 呼び出しているエンドポイントまたは SDK メソッド（例: serverless.roboflow.com/model-name/version, InferenceHTTPClient, CLIENT.infer()).

  • モデル ID とバージョン番号。

  • 使用している API キーの種類。ワークスペース用かプロジェクト用か。キー自体は共有せず、種類のみを指定してください。

  • キーを最近ローテーションしたか、またはプランを最近変更したか。

  • API 呼び出しをどのように構築しているかを示す、機密部分を削除したコードスニペット。実際のキーは次のようなプレースホルダーに置き換えてください。 YOUR_API_KEY.

  • 以前は動作していたか、そして何が変わったか。

記入例:

"https://serverless.roboflow.com/test-endpoint/1" を呼び出すと、 https://serverless.roboflow.com/test-endpoint/1 で、 Authorization: Bearer YOUR_API_KEY ヘッダーを使っています。ワークスペースレベルの API キーを使用しています。これは昨日 Free Plan から Core にアップグレードした後に始まりました。モデルは非公開です。こちらが完全な Python のトレースバックです: [paste]。ワークスペースは my-test-workspace です。ワークスペースアクセスは付与済みです。」

アカウントアクセスの問題

Roboflow にログインできません。ログインページが読み込み続ける、Google SSO ログインがブロックされる、パスワードを忘れた場合のリセットが機能しない、または接続している Google アカウントが利用できずアカウントがロックされている、などです。

アクセスの問題は、使用している特定のメールアドレスや ID プロバイダーに関連していることが多いです。また、Google 側の OAuth スコープ変更や、ブラウザや拡張機能の干渉が原因になることもあります。

最も役立つ情報:

  • アクセスしようとしているアカウントに関連付けられたメールアドレス。

  • ログイン方法: メールとパスワード、Google SSO、または GitHub SSO。

  • 正確なエラーメッセージまたは挙動: 「ページが読み込み続ける」「無効な認証情報」「アカウントが見つからない」、または特定のエラーコード。

  • エラー状態のスクリーンショット。

  • ブラウザ名とバージョン、またシークレット/プライベートウィンドウや別のブラウザを試したかどうか。

  • これは新しい問題か、ずっとこの状態だったか（例: 新規作成アカウントか、以前は動作していた既存アカウントか）。

ワークスペースとプロジェクト管理の問題

できない ワークスペースを削除する またはプロジェクトを削除する（削除ボタンが何もしないように見える、またはエラーを返す）、ワークスペースが誤って別のプランにアップグレードされた、所有権が移転できない、課金失敗後にプロジェクトへアクセスできなくなる、画像アップロード上限に達する、または 公開プロジェクト が誤って非公開データを公開してしまう場合。

最も役立つ情報:

  • 失敗している具体的な操作と、観察されたエラーメッセージまたは挙動。

  • エラー状態または望ましくないプロジェクト状態のスクリーンショット。

  • 削除の問題の場合: すでにワークスペース内のすべてのプロジェクトと画像を削除済みであることの確認。これは一般的な前提条件です。

  • 誤ってアップグレードされた場合: アップグレードされたワークスペースと、本来意図していたワークスペースの両方のワークスペース ID、および変更のおおよその時刻。

  • 画像上限の問題の場合: 現在ワークスペースにある画像数と、表示されている上限。

クレジットと使用量の問題

クレジットの減少が想定より速い、失敗した学習ジョブや推論の失敗に対してクレジットが請求される、または 使用状況ダッシュボード が読み込まれない。

最も役立つ情報:

  • クレジットの問題が発生したワークスペース名。

  • 予期しないクレジット消費が起きたおおよその日時。

  • どの操作がクレジットを消費したか: 推論呼び出し、学習、またはバッチ処理。

  • 既知の プラットフォーム障害 が消費の急増と一致しているか、またその時にエラーを見たかどうか。

  • 消費の急増を示す使用状況ダッシュボードのスクリーンショット。

データプライバシーとアカウント削除

次の依頼: アカウントの削除 および関連するすべての個人データの削除（GDPR の消去要求）、アカウント削除後も画像が公開アクセス可能なまま残る不完全なデータ削除、または公開 Universe から特定のプロジェクトを削除する依頼。

最も役立つ情報:

  • 削除対象アカウントのメールアドレス。

  • アカウント削除を進める前に、まずそのアカウント内のすべてのプロジェクトとワークスペースが削除済みであることの確認。

  • GDPR 要求の場合: 要求の法的根拠の記載と、どのデータがまだアクセス可能だと考えているかの説明。

  • 削除すべき特定の公開 Universe リソースへのリンクと、その理由の説明。

セキュリティの問題

API キーが誤って公開された（例: 公開 GitHub リポジトリにコミットされた、またはチャットで共有された）、あるいはセキュリティ研究者が Roboflow プラットフォームの脆弱性を発見した。

キーが公開された場合は、直ちに Roboflow ワークスペース設定でローテーションしてください。ローテーションすると漏えいしたキーは無効になります。その後、許可されていない使用がないか監査できるよう、公開のおおよその時刻をサポートへ通知してください。

公開されたキーについては、次を含めてください:

  • キーがすでにローテーション済みであることの確認。

  • キーが公開されたおおよその日時と、公開経路。

  • 公開期間中に不正な API 使用があった証拠があるかどうか。

脆弱性報告については、脆弱性の明確な説明、再現手順、潜在的な影響を記載して security@roboflow.com にメールしてください。

前へ研究クレジットを申請する
次へRoboflow のステータスと稼働状況

最終更新

役に立ちましたか？