【TypeSafe】テキスト専用の Jev に PDF や PNG を Base64 で渡したら読めるのか試してみた
こんにちは、けーまです。
TypeSafe 社の Jev が面白くて、いろいろと触っています。
普段担当している案件でも活かせそうな場面があり、気になっていました。
ある案件では OCR を扱っているため、Jev をうまく使えないか考えたのがきっかけです。
ただ、公式ドキュメントを見ると、入力はテキストのみで、画像や音声、動画は受け付けないと明記されています。
Input: Text only. String, JSON object, or array of text values. No image, audio, or video input.
そこで、「Base64 に変換してテキストとして渡せば、もしかして読めたりしないか？」と試してみることにしました。
今回は TypeSafe の Playground を使い、貿易書類の PDF と PNG を Base64 化して渡し、書類の種類を判定させてみます。
具体的には、船荷証券（B/L）を Base64 にエンコードして渡し、B/L・インボイス・L/C・Waybill・P/L・判定不能のどれに当たるかを分類させてみました。
先に結論をお伝えすると、PDF・PNG のどちらもまったく読めませんでした。
1. 試したこと
TypeSafe の Playground で、次の条件で PDF と PNG をそれぞれ1回ずつ実行しました。
| 項目 | 内容 |
|---|---|
| 実行環境 | TypeSafe Playground（console.typesafe.ai） |
| モデル | jev-latest |
| 入力した書類 | 船荷証券（B/L）1枚 |
| 入力形式 | PDF（テキスト埋め込みのデジタル PDF、約2KB）/ PNG（同じ PDF を 100dpi・白黒で画像化したもの、約8KB） |
| 実行日 | 2026年9月19日 |
船荷証券（B/L）: 船会社が発行する、貨物を引き受けたことを示す貿易書類。
使った B/L は次のとおりです。
検証に使った B/L（社名・船名・番号はすべて架空）
正解は B/L なので、読めていれば doc_type は bill_of_lading になるはずです。
あわせて、Noul（はい／いいえの確率を返す質問）を使って「そもそも中身の文字が読めているか」も確認しました。
Jev は英語の精度が一番高いため、質問文は英語で書いています。
State には、PDF を Base64 にエンコードした文字列をそのまま設定しました。
State（PDF の場合）：
{
"document": {
"mime_type": "application/pdf",
"encoding": "base64",
"file_base64": "<BASE64でエンコードした値>"
}
}
Questions（PDF の場合）：
{
"doc_type": {
"type": "choice",
"instructions": "`document.file_base64` holds a base64-encoded PDF of a single trade document. Decide which type of trade document it is.",
"criteria": {
"bill_of_lading": "Bill of Lading (B/L). A negotiable transport document issued by the carrier. Typical fields: Shipper/Exporter, Consignee, Notify Party, Ocean Vessel/Voyage, Port of Loading, Port of Discharge, B/L Number, Number of Original B/Ls, and a \"surrender one original duly endorsed\" clause.",
"commercial_invoice": "Commercial Invoice. Issued by the seller to the buyer to claim payment. Typical fields: Invoice No., description of goods, quantity, unit price, total amount, trade term (FOB, CIF), and payment terms.",
"letter_of_credit": "Letter of Credit (L/C). A payment undertaking issued by a bank. Typical fields: Issuing Bank, Applicant, Beneficiary, L/C Number, Expiry Date, Documents Required, and SWIFT MT700 tags such as 40A, 31D, 46A, 47A.",
"waybill": "Waybill (Sea Waybill or Air Waybill / AWB). Evidences carriage but is non-negotiable; goods are released without surrender of an original. Marked \"Non-negotiable\" or carries an AWB Number.",
"packing_list": "Packing List (P/L). Centres on Case No., number of packages, contents, Net Weight, Gross Weight and Measurement (CBM). Normally shows no unit prices or total amount.",
"unknown": "None of the above, or the content cannot be read so there is no basis to decide the document type."
}
},
"is_readable": {
"type": "noul",
"instructions": "Can you actually read the words written on the document from the content of `document.file_base64`?",
"criteria": {
"true": "The document text and field labels are actually legible, giving a real basis for the decision.",
"false": "It looks only like a base64-encoded string; the document content is not legible."
}
}
}
PNG の場合は、State の mime_type を "image/png" にし、Questions の doc_type の instructions だけ次のように変えました。
それ以外は PDF の場合と同じです。
"instructions": "`document.file_base64` holds a base64-encoded PNG scan of a single trade document. Decide which type of trade document it is."
2. 結果：やっぱり読めませんでした
PDF の実行結果
PNG の実行結果
| 入力形式 | doc_type（書類の種類） |
is_readable（中身が読めるか） |
|---|---|---|
unknown が 99% |
true の確率が 27% | |
| PNG | unknown が 100% |
true の確率が 12% |
どちらも正解の bill_of_lading は選ばれず、「読めないので判断できない」にあたる unknown がほぼ 100% の確信度で返ってきました。
is_readable の true 判定もかなり低く、Jev 自身も中身を読めていないと自覚しているようです。
3. まとめ
「Base64 で文字列にすればいけるかも」という淡い期待は見事に外れました。
公式ドキュメントにも記載があるとおり、画像や PDF といった非テキストの入力は、あらかじめテキストや構造化データへ変換してから State に渡す必要があります（Models | TypeSafe Docs）。
Jev で PDF や画像を扱いたい場合は、事前に OCR やテキスト抽出ツールで文字を取り出し、そのテキストを State に渡すのが確実です。
また、検証を通じて入力トークン数の上限にも気をつける必要があるとわかりました。
Jev 1.13 のトークン上限は次の2つです（Models | TypeSafe Docs）。
- リクエスト全体の合計制限：最大 64k トークン
state（前提データ）+ すべての質問の合計が 64k 以内である必要がある
- 1問あたりの個別制限：最大 32k トークン
state（前提データ）+ 一番長い質問1つの組み合わせが 32k 以内である必要がある
Base64 にするとファイルサイズ以上の文字数（約1.33倍）に膨らむうえ、ランダムな英数字の羅列になるためトークン数もかなり消費します。
実際、最初は手元にあった通常の PDF をそのまま Base64 にして渡したところ、上限オーバーでエラーになりました。
そのため、今回の検証では PDF を約2KB まで削ってから試しています。
