GEMINI LABEN
FLASH — Gemini 3.5 Flashが一般提供(GA)に。エージェントやコーディングで持続的なフロンティア性能をうたいますAGENTS — Gemini APIにManaged Agentsがパブリックプレビュー。Googleホストの隔離Linuxサンドボックスで自律エージェントを実行できますWEBHOOK — イベント駆動のWebhooksが追加され、Batch APIや長時間処理のポーリングを置き換えられますSEARCH — File Searchがマルチモーダル対応に。gemini-embedding-2で画像も埋め込んで検索できますSUNSET — gemini-3.1-flash-image-preview・3-pro-image-previewは6/25に停止予定ですANTIGRAVITY — Antigravity Agentのマネージドエージェント(antigravity-preview-05-2026)がプレビュー提供されていますFLASH — Gemini 3.5 Flashが一般提供(GA)に。エージェントやコーディングで持続的なフロンティア性能をうたいますAGENTS — Gemini APIにManaged Agentsがパブリックプレビュー。Googleホストの隔離Linuxサンドボックスで自律エージェントを実行できますWEBHOOK — イベント駆動のWebhooksが追加され、Batch APIや長時間処理のポーリングを置き換えられますSEARCH — File Searchがマルチモーダル対応に。gemini-embedding-2で画像も埋め込んで検索できますSUNSET — gemini-3.1-flash-image-preview・3-pro-image-previewは6/25に停止予定ですANTIGRAVITY — Antigravity Agentのマネージドエージェント(antigravity-preview-05-2026)がプレビュー提供されています
記事一覧/高度な活用
高度な活用/2026-06-14上級

Gemini の構造化出力を本番で信用するために — スキーマ設計・二重検証・抑制つきリトライの実装メモ

Gemini の構造化出力は「パースできるJSON」は保証しても「正しい値」までは保証しません。@google/genai での新しいスキーマ設計、propertyOrdering の効き目、Zod による二重検証、MAX_TOKENS 切れの扱い、抑制つきリトライの実装をまとめました。

gemini86structured-output16json-schemazod3production90

プレミアム記事

請求書の自動仕分けを動かしていたとき、月に数件だけ「合計金額が明細の足し算と合わない」レコードが混ざることに気づきました。JSON のパースは通っていますし、スキーマのバリデーションも緑です。それでも値が間違っている。

構造化出力を本番に載せると、多くの人がここでつまずきます。responseMimeType: "application/json" を付ければ確かに毎回パース可能な JSON が返ります。けれど「パースできる」ことと「業務的に正しい」ことは別の話です。この境界を最初に引いておかないと、静かに壊れたデータが下流へ流れていきます。

ここでは @google/genai の現行スキーマ設計から、二層検証、失敗の見分け方、回収の実装まで、運用で実際に効いた順に整理します。2026 年 6 月時点で既定モデルは Gemini 3.5 Flash に上がり、Structured Outputs も GA になりました。挙動が安定した今こそ、設計を固め直す良い時期だと考えています。

「構造化出力=安全」が成り立たない理由

構造化出力が保証してくれるのは、おおむね次の三つです。出力が指定した JSON 型に従うこと、required のフィールドが欠けないこと、enum で列挙した値の範囲を外れないこと。これは大きな前進で、自由形式テキストを正規表現で剥がしていた頃に比べれば段違いに堅牢です。

一方で、保証してくれないものもはっきりしています。数値が業務的に妥当か(明細合計と総額が一致するか)、日付が実在するか(2026-02-30 を弾けるか)、複数フィールド間の整合性(payment_status: paid なのに paid_date が空でないか)。これらはスキーマの外側にあります。

つまり構造化出力は「形」を保証する層であって、「意味」を保証する層ではありません。本番パイプラインでは、この二つを別々のコードとして持つのが結局いちばん壊れにくい、というのが個人開発で数か月運用して出した結論です。本番運用では、形のエラーと意味のずれを同じ対処で握りつぶさないことが効きます。

スキーマ設計 — モデルに「形」を教える

まずは現行 SDK での最小構成です。旧 @google/generative-ai から @google/genai へ移ったことで、呼び出しは ai.models.generateContent に集約され、設定は config に入ります。

// structured-review.ts
import { GoogleGenAI, Type } from "@google/genai";
 
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
 
// description はモデルへの指示として効く。型名だけでなく「何を入れるか」を書く
const reviewSchema = {
  type: Type.OBJECT,
  properties: {
    productName: { type: Type.STRING, description: "レビュー対象の製品名" },
    rating: {
      type: Type.INTEGER,
      description: "1〜5 の整数。小数や範囲外は許容しない",
    },
    pros: {
      type: Type.ARRAY,
      items: { type: Type.STRING },
      description: "良い点。本文に根拠がある項目だけ",
    },
    cons: {
      type: Type.ARRAY,
      items: { type: Type.STRING },
      description: "改善点。本文に根拠がある項目だけ",
    },
    sentiment: {
      type: Type.STRING,
      enum: ["positive", "neutral", "negative"],
      description: "全体の論調",
    },
  },
  // propertyOrdering でモデルが生成する順序を固定する
  propertyOrdering: ["productName", "rating", "pros", "cons", "sentiment"],
  required: ["productName", "rating", "sentiment"],
};
 
export async function analyzeReview(reviewText: string) {
  const res = await ai.models.generateContent({
    model: "gemini-3.5-flash",
    contents: `次のレビューを分析してください:\n\n${reviewText}`,
    config: {
      responseMimeType: "application/json",
      responseSchema: reviewSchema,
    },
  });
  return JSON.parse(res.text);
}

ここで地味に効くのが三点あります。

description は飾りではなく、実質的な指示として読まれます。「1〜5 の整数」とだけ書くより「小数や範囲外は許容しない」と添えるほうが、境界値の暴れが目に見えて減りました。型の説明ではなく、現場のルールを書く場所だと捉えると質が上がります。

propertyOrdering は見落とされがちですが、生成順を固定すると出力の安定度が上がります。モデルは前のフィールドを文脈にして次を埋めるため、たとえば ratingpros/cons より先に置くと、評点と理由がちぐはぐになりにくくなります。逆に重要な判断フィールドを末尾に置くと、手前の冗長な配列に引きずられることがあります。

required は最小限にとどめます。すべてを必須にすると、モデルは埋められない欄を無理やり捏造します。「無ければ省略してよい」とスキーマで許すほうが、結果的にハルシネーションが減ります。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
responseSchema が保証する範囲と、ビジネス整合性検証を分離する二層設計の具体コード
propertyOrdering・enum・description を使ってモデルの出力品質を上げるスキーマの書き方
MAX_TOKENS による途中切れ・空応答を finish_reason で見分け、抑制つきリトライで回収する実装
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Gemini Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

高度な活用2026-06-13
Gemini の GA 画像モデルは端末解像度ちょうどに出力できない — 縦横比とセーフエリアを揃える壁紙パイプライン
GA 版の画像モデルに切り替えたら壁紙が端末画面に収まらない。1枚のマスターから全デバイス分を正確に切り出し、生成回数を台数分の1に抑える壁紙パイプラインの実装を、Pillow のコードとともにまとめます。
高度な活用2026-04-27
Gemini Computer Use の自己修復アーキテクチャ — 失敗するブラウザ自動化を本番で安定稼働させる設計パターン
Gemini Computer Use のブラウザ自動化を本番で運用すると、要素消失・モーダル割り込み・ネットワーク遅延で頻繁に失敗します。失敗を「自己修復」させる回復戦略を、検出・分類・リトライ・人間介入のレイヤーに分けて、Pythonの動くコードで設計します。
高度な活用2026-04-25
Gemini API で『自己批判するエージェント』を実装する — Reflection × Critic × Refiner で本番品質を継続的に上げる実装
Gemini 3 Pro と 2.5 Flash を組み合わせて自己批判するエージェントを構築する設計と本番運用ノウハウ。Reflection / Critic-Refiner パターンの実装、コスト上限、過剰修正の防ぎ方まで踏み込んで解説します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →