AI分析15分で読めます

Jevが写真を読む:返品確認から損傷箇所の特定まで

Jevの実験的な画像対応により、写真から型付きの判断やバウンディングボックスを得られます。マグの返品ワークフロー、対象の存在確認、安全な初回プロトタイプを解説します。

K
Ken Jo

マグの返品写真から対象の存在確認、損傷候補の領域、人による確認へ進み、自動返金は行わない流れ

オリジナルの解説図:写真を入力し、判断と座標を別々に出力して、損傷候補を人が確認します。記録されたモデル実行結果ではなく、ワークフローを示しています。

顧客が欠けたマグの写真を送ってきました。サポートツールには、マグが写っているか、写真が損傷を示しているか、確認担当者がどこを見ればよいか、という3つの異なる問いへの答えが必要です。陶器について流暢な段落を書くことは、最も役立つ中間成果ではありません。

2026年10月14日、TypeSafe AIは、Jev 1.14.0と新しいbox出力型にあわせ、Jevの実験的な画像対応を発表しました。画像はJev 1.13と1.14の両方で使えますが、Boxには1.14が必要です。TypeSafeはこれらの機能を実験的と位置づけ、本番の自動化にはまだ推奨しないと明記しています。公式発表

有用な変化は、何でもこなすマルチモーダルアシスタントより限定的です。写真を、型付きの判断やプログラム内の位置情報に変換できます。返品ワークフローがどう変わるか、インターフェースが受け付けるものは何か、長方形を証拠と取り違えず慎重なプロトタイプをどう作るかを見ていきます。

要点:

  • Jevには静止画を理解する実験的な経路が加わりました。画像生成ではありません。
  • 対象が存在するか確認してから、提案された位置を信頼してください。
  • 元の写真と人による確認を残し、座標、権限、結果の検証はコードに任せましょう。

写真から説明ではなく判断を得られる

Jevの元来の強みは、選択肢から選ぶ、説明された段階で評価する、はい/いいえの命題を判定するといった、範囲の定まった回答でした。Jevの判断モデルに関する以前のガイドで、その基礎を説明しています。今回の新機能は、そうした問いに視覚的な根拠を加え、空間座標を返す方法も備えました。

返品対応では、役割分担が変わります。モデルは損傷が見えると提案し、アプリケーションコードはその提案を送信画像の横に表示できます。しかし、どちらの処理も、損傷がいつ発生したか、写真がこの注文のものか、返金が承認されるかを証明しません。それぞれ別の根拠が必要な問いです。

入力または出力ドキュメント上のインターフェースが対応することアプリケーション側で用意すること
写真入力実験的なPNG/JPEG静止画画像を処理する許可と、アップロード前の準備
音声入力ネイティブ音声入力なし別の方法で作成した文字起こしや構造化フィールド
動画入力動画ファイルのネイティブ入力なし選択した静止フレームや抽出テキスト。動画ファイルのアップロードではない
文書入力テキスト/JSON。スキャンページは画像として扱えるJevの外でのPDF/DOCX解析またはページ画像化
出力定義済みラベル、スコア、確率、Box座標描画、切り抜き、文書作成、業務上のアクション

これらの境界は、モデルリファレンス、APIリクエスト仕様、画像対応SDKに記載されています。PDFのページに画像が含まれているからといって、PDFのフォルダーが文書処理パイプラインになるわけではありません。同様に、フレームをいくつか抽出しても、動画をネイティブに理解したり、クリップの音声トラックにアクセスしたりできることにはなりません。

私たちの見解では、興味深い単位は、根拠にひも付いた、小さく検査可能な判断です。それによって、後続処理すべてを自動化する許可が新たに得られるわけではありません。

公式の3例は、同じ写真を別々の仕事に変える

TypeSafeのJavaScriptドキュメントには、具体的な出発点が3つあります。公開済みのコード例であり、実顧客への導入や測定結果の報告ではありません。自分の写真での精度を保証するものではなく、プロトタイプのパターンとして参考にしてください。

1つ目は、マグが破損したという申告と商品写真を組み合わせ、損傷についてNoulに問い、程度をScoreで評価します。サポートキューでは、疑わしい損傷を優先して確認する用途に応用できます。それでも担当者が全体写真と顧客の説明を見て、提案を却下できるようにします。

2つ目は、販売者がアップロードした写真とカタログ画像を比較します。同じ商品が写っているかを問い、ぼけ、切れ、商品以外の内容など、写真としての使いやすさを分類します。マーケットプレイスでは、商品同定と写真品質を別の承認判断に分けられます。違う商品が鮮明に写っていても、プロらしく見えるという理由だけで合格させてはいけません。

3つ目はBoxで損傷箇所を特定します。結果をオーバーレイや、担当者向けの切り抜き候補に使えます。トリミング前の元画像も一緒に保存してください。注目箇所を絞ると申告の確認に役立つ一方、意味を変えてしまう文脈を隠すこともあります。

損傷の評価、カタログとの比較、損傷箇所の特定については、公式例を参照してください。私たちが提案する返品フローでは、そのパターンの周囲にアプリケーション側の安全策を加えています。実地試験の報告ではありません。

ボックスだけでは、対象が存在しないとは判定できない

TypeSafeのBox仕様で重要なのは、対象が存在しない場合の出力がないことです。指定した対象がなくても、Boxの質問は四辺の座標を返します。したがって、無傷のマグを囲む長方形だけでは、損傷があると判断できません。

指定対象の有無を、別途Noulに尋ねます。このワークフローでは、マグが見えることと、損傷が見えることを区別します。マグがあるという肯定回答だけで、損傷のオーバーレイを表示してはいけません。検証済みルールに照らし、関連する存在確認が通った場合だけ損傷候補のボックスを使います。

この存在確認のゲートも、誤りを解消する魔法ではありません。2つの判断が同時に間違うこともあります。強い反射が欠けに見えたり、模様のある釉薬の上の本物のひびが見えなくなったりします。マグが写っていない写真、無傷のマグ、紛らわしい反射、複数の商品、損傷がはっきり見える写真をテストしてから、しきい値を選びます。

対象の存在確認と損傷の可視性チェックに通った場合だけ提案ボックスを使う。根拠不足、不確実性、無効な座標ではオーバーレイを出さず、人が元写真を確認する。

オリジナルの判断図:有効な長方形も対象存在確認に通った場合だけ使えます。確認に失敗したり不確実だったりすると元写真を人が確認し、自動却下にはつなげません。

長方形は判決ではなく、指し示すポインターと考えてください。

座標を幾何情報として扱い、意味も検証する

Boxは画像の左上を原点とし、left、right、top、bottomを画像寸法に対する比率で返します。値は0から1の範囲で、left < rightかつtop < bottomです。1つの質問で返るのは1つのボックスで、物体検出リストではありません。Boxの応答仕様

例として、準備済み画像が1200 x 900で、左0.20、上0.30、右0.60、下0.70なら、ピクセル座標の辺は240、270、720、630になります。算術の例であり、Jevから実際に返された値ではありません。切り抜きAPIでは一般に左、上、右、下の順を求めます。JSONのプロパティ順に頼らず、名前に基づいて意図どおり対応づけてください。

描画する前に有限数、範囲、順序を検証します。その後、その領域が本当に損傷を示しているか確認します。写真をリサイズ、回転、パディング、タイル分割した場合は、座標を元に対応づけるための変換情報を保持します。そうしないと、もっともらしいボックスでも違う画素を指すことがあります。

エラーが出てからではなく、リクエスト前に画像を準備する

公式の画像制限は明確で、境界値も含みます。範囲外の画像は自動リサイズされず拒否され、1枚でも拒否されればリクエスト全体が失敗します。

制約公開されている上限・条件
形式PNGまたはJPEGの静止画。アニメーションPNGは不可
1ファイル16 MiB。該当する場合、base64デコード後に計測
各辺の寸法280~1568ピクセル
総画素数78,400~2,458,624
リクエスト本文JSONとアップロードのフレーミングを含め32 MiB
処理する画像の合計32 MiB
展開後のリクエスト画像参照を置換した後で32 MiB

参照画像を繰り返し使うと、展開後のリクエストではその分も再計上されます。ファイルサイズ、寸法、コンテキスト長はそれぞれ別の確認項目です。画像制限

PNGまたはJPEG、各辺280~1568ピクセル、画像1枚16 MiB、リクエスト単位の個別の32 MiB制限3種類を確認する画像準備フロー

TypeSafeの画像ドキュメントを基にしたオリジナルの制約図。2026年10月18日確認。ファイル単位、処理画像、展開後リクエスト、リクエスト本文の各上限は独立して適用されます。

TypeSafeは送信前に画素を正しい向きへ回転するよう案内しています。APIはメタデータを削除し、EXIFの向きを適用しません。未対応形式は先に変換してください。画像準備のガイダンス

プロトタイプでは、自分が所有する写真のコピーを明確な名前で準備し、元画像は変更せずに残します。寸法をローカルで確認し、実際に送信するコピーをプレビューしてください。細長い切り抜きが最小寸法に届かず余白を追加する場合は、座標を解釈できるよう、そのパディング量を記録します。

1.14を固定し、実験機能のスイッチを明示する

10月18日時点で、公開エイリアス表ではjev-latestが**jev-1.13.0、jev-previewがjev-1.14.0**を指しています。Boxの例では、latestが最も新しいプレビューだと思い込まず、jev-1.14.0を固定して使います。モデルエイリアス

以下の手順では、ローカルで確認するためだけの例を作成します。最後のコマンドを実行すると課金対象の推論リクエストが送信され、SDKが再試行する場合もあります。返品を承認したり、アカウントを変更したりすることはありません。人物、配送ラベル、住所、非公開文書が写っていない、自分が所有するテスト用写真を使ってください。

  1. アクセス権を取得し、適切な組織を選ぶ。 TypeSafeによると、現在はウェイトリスト承認なしで登録できます。コンソールでAPIキーを作成し、テスト前に組織のクレジットを確認します。アカウントアクセス、クレジット設定

  2. Node.js 22以降を使う。 画像対応JavaScript SDKのリリースは、10月14日付の0.7.0です。この例が依存するクライアントを明示するため、バージョンを固定します。SDK変更履歴

Bashターミナルで実行
node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]

  1. セッション中だけ使うキーを設定する。 Windows PowerShellでは1つ目、macOSまたはLinuxのBash/Zshでは2つ目のブロックを使います。プレースホルダーは自分の環境内で置き換え、実際のキーをコミットしないでください。
PowerShellPowerShellで実行
$env:TYPESAFE_API_KEY = "your-api-key"

Bashターミナルで実行
export TYPESAFE_API_KEY="your-api-key"

  1. owned-mug.jpgを準備し、inspect-return.mjsを作成する。 以下は、ドキュメント記載のSDKヘルパーを使った独自の応用例です。画像リクエストを送る前に、実験機能用ヘッダーを設定します。下の確率しきい値は説明用のアプリケーションルールであり、TypeSafeの推奨値ではありません。すべての結果を人が確認します。SDKの使い方
JavaScript
import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";

if (!process.env.TYPESAFE_API_KEY) {
  throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}

const client = new TypeSafeClient({
  defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
  model: "jev-1.14.0",
  state: { photo },
  questions: {
    mugVisible: noul("Is a mug clearly visible in `photo`?"),
    damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
    damageRegion: box("The physically damaged area of the mug in `photo`"),
  },
});

const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
  (value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;

const presencePasses = [mugVisible.noul, damageVisible.noul].every(
  (value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);

console.log({
  model: response.model,
  usage: response.usage,
  humanReviewRequired: true,
  suggestedBox: presencePasses && validBox ? edges : null,
});

  1. 画像を送信して利用料金が発生してもよい段階でのみ実行する。 3つのOSすべてでコマンドはnode inspect-return.mjsです。例外が発生したりsuggestedBox: nullになったりしたら、元画像を確認できる状態に保ち、自動で繰り返し送信しないでください。

質問は1つのリクエストにまとめていますが、アプリケーションのゲートを通らない限りBoxは使いません。使わないBoxを計算した費用は節約できません。後の設計では、存在確認の後に位置特定を別リクエストにでき、追加の往復と引き換えに不要な位置特定呼び出しを避けられます。

小さなトークン単価は、写真1枚あたりの料金ではない

公開料金では、両バージョンとも入力100万トークンあたり**$0.042で、出力トークンは無料です。つまり、課金対象の入力1,000万トークンは公表料金で$0.42**です。写真1,000万枚がその料金という意味ではありません。公開料金

画像には別料金が設定されておらず、テキストと同じ単価で入力トークンとして課金されます。TypeSafeのドキュメントには、画像トークンを見積もる計算式がまだありません。利用を承認された評価では、写真1枚あたりの架空の料金を作らず、応答のusage.input_tokensを予算計算に使ってください。画像の課金

予算には失敗した試行、再試行、前処理、保存、レビュー担当者の時間を含めます。費用と品質を一緒に測定しましょう。数セント節約しても、切り抜きが狭すぎて毎回元画像を開き直すなら意味がありません。レビュー工程全体を、単純な手作業の基準と比較します。

不確実性、プライバシー、混雑したサービスを考慮して設計する

Noulは、独立したconfidenceフィールドを持たずに確率を返します。ChoiceとScoreは分布とそこから導出した確信度を含みます。値が表すのはモデルの不確実性であり、正しさを一律に保証する証明書ではありません。確信度のドキュメント

マグのワークフローでは、合意したラベル付きの保留写真を使ってゲートを検証します。似た出力をグループ化し、自分のタスクで確率が実測の正確さと対応しているか確かめます。損傷の見逃しと誤警報を別々に測り、オーバーレイの位置違いと返金判断の誤りも区別してください。モデル、照明、商品カテゴリ、撮影工程を変えたら、しきい値を再評価します。

不合格になった画像をすべて、顧客に不利な根拠として扱わないでください。カメラの品質が低い、物体が反射する、別角度の撮影が必要など、写真が不十分な理由はさまざまです。モデルの不確実性を顧客の責任にせず、別の写真を依頼する経路や人による確認を用意します。

TypeSafeによると、顧客のリクエストと応答はJevの学習には使われません。またヘルプセンターでは、サービス提供、請求、不正利用対策、テレメトリーを含む処理があり得ると説明しています。保持条件はデータ、契約、ゼロデータ保持の取り決めによって異なります。学習に使わないことと、保持しないことは同じではありません。データの取り扱いポリシー

公開されているサービス稼働状況ページには、米国の地域とus-east-1、us-east-2、us-west-2が掲載されています。地域内データ保存要件があるチームは、顧客写真をアップロードする前に処理場所を確認してください。コンソールに接続できることは、データ保存地域に関する契約ではありません。

アップロード前にデータを最小化します。準備用コピーでは、不要な住所ラベルを切り取ります。元画像へのアクセスを制限し、通常のログに画像や秘密情報を入れないようにします。プロバイダーのポリシーとは別に、自社の確認記録の保持期間も決めてください。

組織ごとの制限は、秒あたりのリクエスト数やトークン数に適用されます。APIではレート制限が429、過負荷が529と記載されています。不正形式やサイズ超過の入力は修正が必要で、同じ内容の再試行では解決しません。レート制限、APIエラー

JavaScript SDKの再試行ポリシーは既定で2回再試行し、対応するRetry-Afterヘッダーに従います。上限のない外側の再試行ループを追加しないでください。時間予算を設定し、対処可能なエラー状態を保ち、将来の業務アクションは分離します。推論の再試行で返金が重複実行されてはいけません。再試行ポリシー

初めて写真を使うワークフローの前に確認すること

Jevは返品写真を編集または生成しますか?

いいえ。画像は判断や領域候補の根拠になります。オーバーレイの描画や切り抜きは、通常の画像処理コードでアプリケーションが行います。未加工の元画像は別に保管してください。便利な長方形が、元の根拠の代わりにはなりません。

例でlatestではなく1.14を固定するのはなぜですか?

公開エイリアス表では現在jev-latestが1.13を指していますが、Boxには1.14が必要です。jev-1.14.0を固定すれば依存関係が明確になります。エイリアスが更新されても動作が保たれると思い込まず、バージョンを変える前にリリースノートとテストセットを見直してください。

損傷確率が高ければ返金を実行できますか?

それだけを根拠に安全に実行することはできません。確率が答えるのは送信画像について尋ねた内容であり、注文を認証したり、責任の所在を確定したり、返金ポリシーを適用したりするものではありません。まずレビュー支援として使い、代表例で検証し、重大な結果を伴う判断には人を残します。

出力が無料なら画像リクエストに費用はかかりませんか?

いいえ。画像トークンを含む入力トークンに料金が発生します。画像トークンの見積もり式がまだ公開されていないため、公表単価は写真1枚あたりの料金ではありません。承認された試験運用で使用量を確認し、再試行とレビュー時間も総額に含めます。

商品動画やPDFをそのまま送れますか?

ドキュメント記載の静止画インターフェースではできません。処理する許可を得たうえで、アプリケーション側が適切なフレーム、テキスト、レンダリング済みページを先に抽出する必要があります。フレーム化すると時間情報や音声が失われるので、渡した根拠から答えられる質問だけをしてください。

要点:権限を委ねる前に、注目箇所を示す

Jevの画像プレビューが示す実用的な考え方は、視覚的な根拠をソフトウェアが検査できる小さな回答に変えることです。マグの返品ツールなら、存在、損傷、位置、確認を分けて検証できます。最初に価値ある成果は自動返金ではなく、担当者が探し回る時間を減らし、より十分な根拠で判断できることです。

測るべき基準はこれです。提案された領域は、モデルが間違えた場合も含めて、人が元の根拠を理解する助けになるでしょうか?

出典と対象範囲

一次情報は2026年10月18日に確認しました。TypeSafeの10月14日の発表、モデルと料金、画像制限と課金、Box仕様、JavaScriptの例、SDKリリースノートを参照しています。追加のポリシーや信頼性に関する情報源は、該当する説明の近くにリンクしました。手順と図は説明のための応用例であり、実機ベンチマークではありません。本記事のための有料モデル呼び出しは行っていません。図はオリジナルで、ベンダーメディアの転載ではありません。

結論のそばに情報源を残す

自分でモデルを調査するときは、元の情報源をそこから導いた結論と分けて保管します。Telli.shアカウントを作成し、情報源の文脈を保ちながら調査資料と派生メモを整理できます。


← ブログに戻る