本番導入の準備

DeepFrame API で確認できる内容、導入前のチェック項目、別途確認が必要な企業向け要件を整理します。

このページは、連携機能が管理された本番評価に進める状態かを判断するためのものです。このポータルでは DeepFrame API の技術的な動作を説明していますが、商用・企業向けのすべての約束を公開しているわけではありません。

Alpha は本番運用の保証ではありません

/api/v1alpha1 には互換性の保証がありません。このポータルでは、SLA、サポートの応答時間、提供リージョン、商用利用条件を公開していません。本番で利用する前に、必要な条件を個別に確認してください。

現在の仕様で確認できること

項目	公開されている動作
アクセス	ワークスペースの opt-in、Public API Alpha キー、操作単位の権限。
ワークスペース分離	ワークスペースはキーから特定されます。別ワークスペースのリソースは、存在しないリソースと同じ 404 を返します。
安全な書き込み	対応している状態変更の `POST` 操作では `Idempotency-Key` を使えます。同じ内容の再試行では最初の応答が返ります。ただし、Webhook 作成の完了後の再試行は署名 secret を再返却せず、409 `conflict` となります。
利用量の通知	応答に利用上限を示すヘッダーが含まれます。429 応答には `Retry-After` が含まれます。
長時間処理	動画、質問、分析ランには確認可能な状態があります。完了時の event は Webhook でも受け取れます。
エラー処理	RFC 9457 形式の error に安定した `type` と `request_id` が含まれます。非同期処理の失敗には構造化された `error` があります。
根拠と不確実性	検出結果と回答は、状態、制約、確認可能な根拠を保持します。不確実な結果を合格として扱いません。
変更の確認	alpha の安定性ポリシー、廃止予定 header、変更履歴から仕様変更を確認できます。

正確な動作は、認証、規約、エラー、Webhook、ポリシーを参照してください。

API キーをサーバー側の secret manager に保存し、ブラウザのコードへ渡さない。
連携に必要な権限だけを持つ専用キーを使う。
対象ワークスペースで Public API Alpha の opt-in が有効であることを確認する。
対応している状態変更の POST リクエストを再試行するときは、同じ idempotency key とリクエスト本文を使う。
再試行回数に上限を設ける。429 では Retry-After に従い、再試行可能な 503 では待機時間を徐々に延ばして揺らぎを加える。
completed、failed、canceled を別の終了状態として扱う。動画検索では、分析を実行する前に status=completed を確認する。
Webhook の署名を未加工の request body で検証し、古い通知や再送された通知を拒否する。
secret や機密情報を記録せず、自社の追跡 ID とともに request_id を記録する。
found、not_found、uncertain、not_checked と、制約、根拠を後続の判断まで保持する。
本番導入前に、正常終了、入力エラー、権限エラー、利用上限、非同期処理の失敗を各 1 件以上テストする。

次の項目は、現在のポータルに回答がありません。自社に必要な項目ごとに、明示的な回答を記録してください。

HTTP 応答や評価環境で観察した動作だけから、企業向けの約束を推測しないでください。

上記の未確認事項は、DeepFrame の評価で合意した連絡先へ確認してください。既存の連絡先がない場合は、deepframe.cloud で現在の問い合わせ方法を確認してください。ワークスペース、想定する処理量、必要なリージョン、導入予定日を伝え、API キーや顧客データは送らないでください。

必要な回答を記録したら、非本番ワークスペースでクイックスタートを実行し、連携で使うすべての操作をAPI リファレンスで確認してください。