Google AI Studioの構造化出力で資料を表にする方法｜JSONの形式と事実を別々に検証

※当サイトは広告・アフィリエイトプログラムを利用しています。

問い合わせメールやアンケートをAIに整理させると、文章の箇条書きは読めても、そのまま表計算へ入れるには項目の抜けや表記ゆれが困ります。Google AI Studioの構造化出力を使うと、項目名と型を先に決めたJSONを得やすくなります。ただし「形式が合う」と「元資料に書かれた事実が正しい」は別の検査です。この記事では、架空の問い合わせを使い、抽出項目の設計から検算までを一続きで説明します。

構造化出力が向く仕事と向かない仕事
最小のサンプルを先に決める
AI Studioでの試し方
表計算へ移す前の5つの検査
1. 少量テストでわざと欠損・訂正を混ぜる
つまずきやすい設定
公式資料
関連記事

構造化出力が向く仕事と向かない仕事

Googleの公式文書は、非構造化テキストから名前・日付等を抽出する作業、決まった分類、後続のワークフローに渡す入力を適例としています。議事録の「担当者・期限・決定事項」を並べる、問い合わせを種別ごとに分類する、商品説明から型番だけを拾う用途です。自由な発想のコピーや、根拠がない空欄を想像で埋める用途には向きません。

通常のプロンプトに「JSONで答えて」と書く方法でも成功することはありますが、余計な説明や項目名の揺れが混ざり得ます。Structured outputsではスキーマを指定して出力形式を制約します。一方、公式文書も構文が正しいJSONであっても値を検証するよう求めています。JSONとして読み込めても、購入日や数量の取り違えは残り得るため、業務判断を無検査で自動登録しないでください。

最小のサンプルを先に決める

架空の入力を「9月18日に山田さんから青いマグカップ2個の交換希望。注文番号A123。購入日不明」とします。欲しい列は「注文番号」「相談種別」「希望個数」「購入日」「確認メモ」。購入日は書かれていないため、空欄またはnullとするルールを先に決めます。実際の個人情報や社外秘資料ではなく、ダミー文で設定を試してください。

{"type":"object","properties":{"order_id":{"type":"string","description":"原文にある注文番号。なければ空文字"},"category":{"type":"string","enum":["交換","返品","その他"]},"quantity":{"type":["integer","null"],"description":"明記された個数。なければnull"},"purchase_date":{"type":["string","null"],"description":"原文にある購入日。推測しない"},"evidence":{"type":"string","description":"判断の根拠となった短い原文"}},"required":["order_id","category","quantity","purchase_date","evidence"]}

出力の例は{"order_id":"A123","category":"交換","quantity":2,"purchase_date":null,"evidence":"青いマグカップ2個の交換希望"}です。この例は説明用であり、実際の返答では原文と照合します。日付の「9月18日」は相談日であって購入日ではありません。混同を防ぐため、スキーマの説明に項目の意味と「推測しない」を書きました。

AI Studioでの試し方

Google AI StudioのPlaygroundで使用するモデルと入力先を確認し、ダミーテキストを用意します。
設定の「Structured outputs／構造化出力」を有効にし、Editから項目を定義します。画面の名称や配置は更新されるため現行UIを確認してください。
Visual Editorで項目と型を追加するか、Code Editorで対応するスキーマを入力します。まずは上記のような少数のキーで試します。
プロンプトに「原文にない日付・個数を補完しない。根拠をevidenceへ記録」と書き、入力を実行します。
返ったJSONのキー、型、必須項目と、原文に対する値の正しさを別々に照合します。

GoogleのAPI文書はJSON Schemaのサブセットをサポートすると説明しています。使える型にはstring、integer、number、boolean、object、array、nullがあり、enum、required、description等で制約できます。大きすぎる、深く入れ子にしたスキーマは拒否される場合があるため、いきなり全社共通の複雑な表を作らず、数項目から試します。

表計算へ移す前の5つの検査

検査	失敗例	対策
形式	JSONの外に説明文	JSONとして解析しスキーマに照合
値	相談日を購入日に転記	原文とevidenceを照合
型	個数が「二つ」という文字列	整数またはnullを指定
欠損	不明な日付を創作	nullの許可と例示
重複	同じ注文を二度登録	注文番号と元ファイルIDで照合

「AIが返したから正しい」は禁物です。複数行を一括で処理する場合は、行ごとに入力IDを付け、原文への戻り道を確保します。個人情報を扱う前に、組織のデータ取扱規程とGoogle側の現行プライバシー条件を確認してください。公開すべきでない氏名・連絡先はサンプルから取り除きます。

少量テストでわざと欠損・訂正を混ぜる

例えば「個数の記載なし」はquantityがnull、「2個から1個へ訂正」は最終希望が1、「同じ注文番号の追記メール」は新規注文として二重登録しない、という確認用の正解表を作ります。0は数量ゼロ、nullは不明なので置き換えません。訂正前後の文があって判断できない行は人の確認へ回します。モデル名・スキーマ・指示文を変更したときも同じサンプルを再検査すると、前にできていた抽出の崩れを見つけやすくなります。