文章としては意味が通っています。それでもアプリケーションはこれを引き継ぐことができません。数量が一度は「六」として、一度は6として、さらにもう一度はコメント内の文として現れるからです。構造化出力は、この受け渡しに契約を与えます。より興味深いのは、形式として正しいJSONが内容的には誤りうるという点から先です。
Mistralの Custom Structured Outputs では、そのためにあらかじめ定義されたJSONスキーマを使用します。フィールドとデータ型が明示的に記述されます。これはモデルとアプリケーションの間のインターフェースを整理するものであり、ある値が実際に元のテキストによって裏付けられているかどうかの確認に代わるものではありません。
「不明」はそれ自体が一つの状態です
私たちの架空のメモにはフォルダーについての記述はありますが、数量は書かれていません。出力はこの欠けている値をそのまま保持すべきです。代わりに既定の数量を入れてしまうと、データレコードはより完全に見えますが、その過程で重要な情報が失われます。
特定のベンダーに依存しない小さなスキーマは、たとえば次のようになります。特定のインターフェースがどのスキーマキーワードをサポートしているかは、使用前にその最新のドキュメントで確認する必要があります。
{
"type": "object",
"required": ["artikel", "menge", "klaerung"],
"additionalProperties": false,
"properties": {
"artikel": {"type": "string"},
"menge": {"type": ["integer", "null"], "minimum": 0},
"klaerung": {"type": "string"}
}
}required はフィールドが存在することを要求します。それでも null によって、明示的に不明な値を許容できます。下限は数値の数量に適用されます。ある数量が実際の発注プロセスで許容されるかどうかには、さらに業務ルールが必要になる場合があります。何よりもまず、スキーマは後続のアプリケーションがどのような形式を期待できるかに答えるものです。
モデルも発注もなしのプレビュー
固定のサンプルデータを使えば、処理の流れをすでに確認できます。私たちが作成した次のHTMLスニペットをローカルのサンプルファイルとして保存し、ブラウザで開いてください。データレコードを表示しますが、APIリクエストは行わず、注文も保存しません。
<!doctype html>
<meta charset="utf-8">
<p id="ausgabe"></p>
<script>
const daten = { artikel: "Folders", menge: null, klaerung: "Quantity missing" };
function pruefe(d) {
if (!d || typeof d !== "object" || Array.isArray(d)) throw Error("Object expected");
const keys = Object.keys(d).sort().join(",");
if (keys !== "artikel,klaerung,menge") throw Error("Check fields");
if (typeof d.artikel !== "string" || typeof d.klaerung !== "string")
throw Error("Text expected");
if (d.menge !== null && (!Number.isInteger(d.menge) || d.menge < 0))
throw Error("Check quantity");
}
pruefe(daten);
const menge = daten.menge === null ? "not yet known" : String(daten.menge);
document.querySelector("#ausgabe").textContent =
daten.artikel + ": " + menge + ". " + daten.klaerung;
</script>この関数は、まさにこの学習用スキーマ専用に私たちが作成した限定的なバリデーターであり、完全なJSON Schemaライブラリではありません。数量を順に6、-1、そして文字列「six」に変更してください。次に、想定外のフィールドを追加してください。そのたびに、表示または開発者ツールのエラーメッセージを確認してください。
これにより、モデルが関わる前に受け渡しをテストできます。アプリケーションが既知の値、不明な値、無効な値をどのように扱うかがわかります。後のモデルの回答も、同じルールを通過して初めてこのスニペットに到達できます。
形式と意味をそれぞれ独立して確認する
形式上は許容される6であっても、メモに四と書かれていれば誤りです。そのため実際のアプリケーションでは、必要に応じて出典への参照を追加し、重要な値を入力と照合してください。メモの内容が矛盾している場合、プロセスは任意の数を選ぶのではなく、確認事項を挙げるべきです。
出力には textContent を使用しています。これにより、外部のテキストは何のチェックもなくHTMLとして解釈されるのではなく、テキストとして挿入されます。このようなブラウザ用スニペットにプロバイダーのキーを含めてはいけません。モデルの呼び出しは、独自のアクセス権と独自のエラー処理を備えた別の処理ステップになります。
ウェブサイトでスニペットを実演する
既存のウェブサイトでまさにこの小さな表示を見せたい場合は、 KENJTEC WebSiteBuilder aiの開発者モード も、独自のHTML/JavaScriptコードを置ける場所の一つです。確認済みのスニペットは手作業で移します。コードプレビューと独自のコードバージョンが、その後のレビューを支援します。これによってMistralとのネイティブな連携が作られるわけではありません。
本質的な洞察は、どこで使うかに関係なく変わりません。モデルの形式、独自のバリデーター、安全な表示、そして内容に関する判断は、それぞれ異なる役割を担っています。これらを分けておけば、もっともらしい回答をいつの間にか行動に変えてしまうことなく、AIの出力を狙いどおりに引き継ぐことができます。
出典と情報の時点
出典は2026年十月25日時点のものです。 Custom Structured Outputs。
