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

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

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

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

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での試し方

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

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

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

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

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

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

つまずきやすい設定

空欄を許すには？

必須項目に含めても、値としてnullを許す型を指定できます。「キーが存在すること」と「値が分かっていること」を分けます。古い画面やモデルではスキーマの入力方式が違う場合があるため、現在のドキュメントを優先してください。

出力が形式通りなのに誤分類される

enumは選べる値を制限しますが、どれが正しいかの根拠は与えません。「交換」「返品」「その他」の定義と、曖昧なケースをその他にするルールを説明へ加え、実例で検証します。

そのままCSVにできますか？

JSONを表へ変換する処理は別に必要です。日時の形式、カンマや改行、文字コード、同一注文の重複を確認してから登録します。自動化では失敗行を隔離し、元の入力と結果を追跡できるようにします。

公式資料

• Google AI for Developers「構造化出力」：対応型、スキーマの制限、値の検証に関する説明。

スキーマは出力を整える道具です。人が判断すべき事実確認と、個人情報の扱いまで代わりに決めてくれるわけではありません。まず架空の10件で欠損・曖昧さ・重複を試し、業務の検査手順が固まってから実データへ広げましょう。

関連記事

Google連携や副業用途を含めて生成AIを選びたい場合は、ChatGPTとGeminiの比較も確認してください。