Qwen3.8 Flash Next の項目抽出：null と根拠を残す設計

最小 API サンプル

説明用の Python コードで、実行した回答ではありません。キーは環境変数から読み、自動再試行は無効です。切断時は結果と費用の両方が不明になり得るため、無条件に再送しないでください。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-qwen-3-8-flash-next",
    max_tokens=512,
    messages=[{"role": "user", "content": "私の課題の確認リストを作り、元の事実と仮定を分けてください。"}],
)
print(response.choices[0].message.content)

掲載情報と現在の利用条件を切り分ける

公開 ID を記事で扱う目的は、どの設定と作業を説明しているかを明確にすることです。今すぐ応答が成功するという案内ではありません。過去に料金が欠けたことは永久停止の証拠ではなく、古いカタログの値も現在の実行可能な見積もりを証明しません。

料金を確認できない場合は事前確認で停止し、似たモデルの単価を代用したり、保護を外したりしません。公開表の計算例も設定値に基づく算術であり、現在利用できるという保証ではありません。抽出規則やローカル検査は推論なしで作れるため、可用性を探る自動の有料呼び出しは不要です。

点検メモの項目と空値の意味を決める

架空の空調点検メモから設備番号、点検日、観測値、単位、異常の有無、次の対応を取り出すとします。観測値のゼロは測定結果ですが、測っていない場合は null です。異常への言及がないことも、異常なしという明記とは違います。下流の集計がこの区別を保てる定義を先に作ります。

日付に年がない、温度と圧力の単位が混ざるといった例も用意します。モデルに現在の日付や一般的な機器仕様から補わせず、原表記と確認待ちを残します。設備番号が似ていても同一設備と推定せず、資料側で対応が示されない限り別の記録として扱います。

一つの値に一つ以上の証拠を結び付ける

段落に自分で REPORT-A-01 のような番号を付け、抽出値、原文、位置、状態を返す規則にします。確定値なのに引用がない場合は取り込みを止めます。モデルの確信度ではなく、実際にその段落が値を支持しているかを判断基準にすることで、もっともらしい補完を見つけやすくなります。

追記に測定値の訂正がある場合は、元の値と訂正の両方を保持します。後ろに書かれているだけで上書きせず、訂正対象と承認を確認します。複数設備のメモは番号の接頭辞を変え、別の設備の点検日や対応者を組み合わせた一見整ったレコードにしないようにします。

構造の検査と内容の検査を二段階にする

まず手元で解析し、項目名、型、必須条件、許可する状態を調べます。JSON らしい文章が出たことは、文書化されていない厳格な出力モードの保証ではありません。未知の項目や文字列の数値をどう扱うかも定義し、都合のよい自動変換で誤りを隠さないようにします。

次に引用が該当箇所に存在するか、単位や設備の帰属が正しいかを確かめます。構造が正しくても圧力を温度として取り出す可能性は残ります。重要項目は人が承認し、既知の誤例でローカル検査が失敗を検出することを確認してから、対象範囲を広げます。

入力の形式と強度の選択を過信しない

この設定では low、high、max が宣言されていますが、どれも原文確認の代わりにはなりません。画像は別料金のテキストブリッジを通るため、小さな数字や表の列が保持されたかを先に確認します。コンテキスト、ブラウザーの入力、添付、出力上限もそれぞれ独立した制約です。

有料ブラウザーの明示的検索は背景の確認に使えても、今回の点検を実施した証拠にはなりません。公開 API に同じネット検索が自動で付くわけでもありません。料金確認ができない状態で、外部にモデル紹介が見つかったことを理由に前提条件を飛ばさず、ローカルの準備を続けます。

未送信と結果不明を同じ失敗にしない

作業記録は規則準備済み、前提未充足、明確な拒否、通信結果不明を分けます。料金未確認による停止を永久的な提供終了と書かず、応答を失った呼び出しを送信前停止と同一視しません。状態は実際に得られた証拠に限定し、すべてに再試行を勧める一文で済ませないようにします。

公式 Python SDK の説明に従って自動再試行を無効にし、出力予算も明示します。MDN の Fetch は HTTP 応答と通信エラーの違いを説明しますが、無課金の証拠にはなりません。記録を確認してから手動で判断し、公開 API に未記載の冪等性や再実行保証を作らないでください。

よくある質問

モデル一覧にあるので現在も必ず利用できますか？

一覧は設定上の識別情報であり、現在の提供、料金確認、アカウント権限とは別です。過去の欠落は永久終了を意味せず、古い価格も現在の見積もりではありません。確認できない場合は停止し、単価を推測せず、自動の有料呼び出しで可用性を探らないでください。

未記載を false やゼロにしても問題ありませんか？

項目定義で区別が必要なら問題になります。ゼロは値、false は明示的な否定、null は値が確定しない状態として設計します。異常の記載がないだけで異常なしとは判断しません。理由と原文位置も持たせ、下流の集計で未確認が正常扱いされないようにします。

有効な JSON が返れば設備台帳へ自動登録できますか？

解析可能な構造だけでは十分ではありません。項目の型、引用、設備番号、単位、訂正関係を確認し、高い影響のある値は人が承認します。モデルが返した形式を、未記載の厳格モードの保証とみなさず、未知の項目や型変換も自分の規則で扱います。

料金が再確認できたら過去の失敗を一括再送できますか？

まず送信前に止まったもの、明確に拒否されたもの、通信結果が不明なものを分けます。不明な呼び出しを未実行や無課金と断定できません。SDK の自動再試行を止め、既存記録と現在の権限を確認してから、必要な対象を人が選びます。

出典

AIの支援を受けて作成した記事です。例は説明用であり、実際のモデル回答や比較試験の記録ではありません。外部資料はサービスの利用条件に代わるものではありません。

• Dikaya 日本語ドキュメント：接続とリクエストの条件
  dikaya.cc
• Dikaya 日本語モデル一覧：公開識別子と対応内容
  dikaya.cc
• Dikaya 日本語料金案内：設定上の料金と利用条件
  dikaya.cc
• OpenAI Python SDK 公式資料：自動再試行の設定
  github.com
• MDN Fetch ガイド：HTTP 応答と通信エラーの区別
  developer.mozilla.org