GPT 6.1 Terraの料金とコンテキスト：信頼性の高いJSON抽出ガイド

GPT 6.1 Terra：API料金を見積もり、JSON抽出エージェントに上限を設定する

構造化抽出で重要なのは、GPT 6.1 Terraが請求書やフォームを読めるかどうかだけではありません。各試行のコンテキストサイズ、出力上限、リトライ方針、検証ステップを予測可能にできるかどうかが重要です。これにより、ワークフローの予算を立てやすくなり、安全に運用できます。

ローンチ時の説明では、Terraは画面の読み取り、アプリケーションの操作、フォームへの入力、受信請求書の処理など、定型的なコンピューター作業向けのモデルとされています。また、画像理解の改善と、前世代モデルより低いとされる料金も報告されています。これらはOpenAI自身の報告による主張であり、独立した評価ではありません。提供されたローンチの詳細については、The New Stackのソースレポートを参照してください。

このガイドでは、より限定された実装に焦点を当てます。文書または画面からフィールドを抽出し、スキーマに適合するJSONを返し、アプリケーション内で検証し、リトライが有効な場合にのみ再試行する方法です。

判断：上限付きの抽出が重要な場合にTerraを使う

GPT 6.1 Terraは、定型的な視覚・テキスト解釈と、その後の構造化された処理を組み合わせるワークロードに適した候補です。たとえば、請求書番号や合計金額の抽出、フォーム項目の読み取り、文書から会計・サポートシステム向けのレコードへの変換などが該当します。

ソースでは、Terraが画面を読み取り、アプリケーションを操作できるとされています。また、OpenAIのテストでは、最低設定での事実誤り率が前世代モデルより低く、コマンドラインでのコーディング性能も前世代モデルより高かったと報告されています。これらの結果は請求書抽出を保証するものではなく、ソースはJSON Schemaの検証スコアを示していません。アプリケーションには、決定論的な検証、可観測性、障害時の処理が引き続き必要です。

より難しいタスクについて、提供されたソースでは、最も難しいコーディング作業にはSolまたはAstraを推奨するとOpenAIが述べています。この比較はコーディング能力に関するものであり、構造化抽出に関するものではありません。そのため、文書ワークフローの順位付けとして使用すべきではありません。

OneMux経由のGPT 6.1 Terra料金

以下は、2026-10-30 09:00:04.984Zに取得した公開OneMux料金スナップショットです。料金の請求単位はカタログの表記どおり、トークン1百万あたりのドルです。これは公開スナップショットであり、リアルタイムのベンチマークではありません。

Terraには1Mトークンのコンテキストウィンドウが記載されており、272Kトークンを超える場合は別の料金階層が適用されます。文書化された階層の境界を超えるリクエストに、≤272Kの料金を適用しないでください。キャッシュ料金も階層とキャッシュ操作によって異なります。≤272K階層では、カタログに記載されたOneMuxのキャッシュ読み取り料金はトークン1百万あたり$0.0078、キャッシュ書き込み料金はトークン1百万あたり$0.195、12時間キャッシュ書き込み料金はトークン1百万あたり$0.39です。キャッシュ料金は入力が無料であることを意味せず、不明な値をゼロとして扱ってはいけません。

ワークロード見積もりの例

1回の抽出試行で入力トークンを100,000、出力トークンを2,000使用するとします。どちらも≤272K階層の範囲内です。計算は次のとおりです。

• 入力：0.1 million × $0.156 = $0.0156
• 出力：0.002 million × $0.78 = $0.00156
• 1回の試行の合計：$0.01716

10,000件の文書をそれぞれ1回ずつ試行する場合、すべてのリクエストが同じトークン構成で、キャッシュや階層の変更がないと仮定すると、見積もりは**$171.60です。文書の5%で有料の追加試行が1回発生する場合、試行回数は10,500回となり、見積もりは$180.18**になります。これは算術上の見積もりであり、実際の使用量を保証するものではありません。

より大きなリクエストでは結果が変わる可能性があります。入力トークンが300,000、出力トークンが3,000の場合は、>272Kの料金が適用されます。

• 入力：0.3 million × $0.312 = $0.0936
• 出力：0.003 million × $1.17 = $0.00351
• 合計：$0.09711 per attempt

実務上のコスト管理では、不要な文書履歴を削減し、抽出に必要でない場合は大きなエージェントのトランスクリプトを送信しないことが重要です。

コンテキスト、リトライ、出力トークンに上限を設定する

信頼性の高い抽出ワーカーでは、次の4つの上限を個別に適用します。

1. コンテキスト上限： 可能な場合は、文書と指示を合わせたサイズの最大値を料金階層の境界より下に設定します。ファイルが大きい場合は、境界を超えるようにそのまま処理するのではなく、分割、要約、または別のワークフローに振り分けます。
2. 出力上限： スキーマに適したレスポンストークンの上限を設定します。請求書レコードに必要なトークン数は、長い説明文より大幅に少ない場合があります。上限は有効なJSONを収められる程度にしつつ、意図しない長文の生成を許可しないようにします。
3. リトライ上限： 不正なJSONや一時的な通信エラーには、まずリトライを0回または1回に設定します。すべての業務ルール違反をリトライしないでください。請求書番号の欠落には、再試行よりも確認や、より適切な抽出プロンプトが必要な場合があります。
4. 試行予算： 文書単位およびバッチ単位で総試行回数を追跡します。予算を使い切ったら停止し、対象を確認キューに入れます。

有効な方針は、返されたオブジェクトをローカルで検証し、エラーを分類し、復旧可能な分類にのみリトライすることです。診断のために元のレスポンスは保存しますが、失敗したレスポンスをすべて次のプロンプトに自動追加しないでください。これによりコンテキストとコストが増加する可能性があります。

JSON Schema抽出パターン

構造化出力の正確なパラメーター名とエンドポイントの挙動は、文書化されたOpenAI互換インターフェースによって異なります。デプロイ前に、OneMuxクイックスタートとAPIドキュメントでサポートされるパラメーターを確認してください。以下のPythonパターンはワークフローを示すもので、エンドポイントのプレースホルダーは文書化された値に置き換える必要があります。

import json
from jsonschema import validate, ValidationError
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_ONEMUX_API_KEY",
    base_url="YOUR_DOCUMENTED_ONEMUX_ENDPOINT",
)

schema = {
    "type": "object",
    "required": ["invoice_number", "invoice_date", "total", "currency"],
    "additionalProperties": False,
    "properties": {
        "invoice_number": {"type": "string"},
        "invoice_date": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "minLength": 3, "maxLength": 3}
    }
}

response = client.chat.completions.create(
    model="GPT 6.1 Terra",
    messages=[
        {"role": "system", "content": "Extract only the requested invoice fields."},
        {"role": "user", "content": document_text}
    ],
    response_format={"type": "json_schema", "json_schema": {
        "name": "invoice",
        "strict": True,
        "schema": schema
    }},
    max_tokens=300
)

record = json.loads(response.choices[0].message.content)
validate(instance=record, schema=schema)

この例では、エンドポイントが示されている構造化出力形式とmax_tokensパラメーターをサポートしていることを前提としています。文書化されたインターフェースで別のパラメーター名が使われている場合や、JSON Schemaによるレスポンス強制をサポートしていない場合でも、ローカルの解析とjsonschema検証は維持してください。また、サポートされていない構造化出力パラメーターは、モデルの失敗ではなく設定上の問題として扱います。

よくある障害のトラブルシューティング

リクエストが272K階層を超える。 指示、文書テキスト、画像または画像表現、保持された会話コンテキストを含むリクエスト全体を計測します。不要な履歴を削除するか、リトライ前に文書を分割してください。

レスポンスは有効なJSONだが、スキーマに適合しない。 構文エラーと意味上のエラーを分けて扱います。有効なJSONオブジェクトでも、必須フィールドの欠落、型の誤り、想定外のプロパティが存在する可能性があります。簡潔な修正メッセージを付けて1回リトライし、それでも失敗が続く場合は確認に回します。

モデルが数値をテキストとして返す。 会計ルール上、型変換を許容するかどうかを決めます。財務記録では、すべての値を暗黙に変換するのではなく、通貨と数値範囲を明示的に検証してください。

リトライによって予想外にコストが増える。 文書ごとの試行回数を記録し、実際の入力・出力トークン数を使って料金を計算します。以前のトランスクリプト全体を含むリトライは、短く整理したリトライより高コストになる可能性があります。

まとめ

GPT 6.1 Terraは、実装でコンテキスト、出力、検証、リトライを別々の制御として扱えば、コストに上限を設けた抽出パイプラインを支援できます。まず小さなスキーマから始め、レスポンスに上限を設け、実際のトークン使用量を計測し、リトライ方針を限定してください。OneMuxはTerraへの実用的なOpenAI互換ルートを提供し、関連する入力、出力、キャッシュ、コンテキスト階層の料金を公開しているため、大規模なバッチに移行する前にワークロードのコストをモデル化できます。

現在のモデル提供状況については、GPT 6.1 Terraモデルページを確認し、ワークロードの前提をOneMuxモデルカタログと比較してください。

ソース

• The Next Web：OpenAIがGPT-6.1 Terraを発表 — 提供されたローンチ情報とモデルに関する主張。
• OneMux上のGPT 6.1 Terra — 公開されているモデルおよび階層別料金。
• OneMux料金 — 上記で参照した公開料金スナップショット。

公開料金スナップショット

OneMuxの公開カタログから2026-10-30T09:00:04.989Zに取得。料金の請求単位はウェブサイトの表記どおりです。これはリアルタイムのベンチマークではありません。階層別、キャッシュ、時間ベースの請求は異なる場合があります。不明な値はゼロではありません。

現在のOneMux料金。入力・出力および請求単位が一致する場合にのみワークロードコストを比較してください。階層条件については各モデルページを参照してください。