生成AIの確認作業を減らす出力フォーマット設計のコツ

結論から言うと、生成AIを導入しても確認作業が減らないのは、AIの性能だけでなく「出力をどう検査するか」まで設計できていないからです。東雲商事の業務改善担当、三浦彩は、その落とし穴を身をもって知ることになりました。

「これで書類確認が終わる」と思っていた

東雲商事では、見積書や発注関連書類の確認に多くの時間がかかっていました。担当者は書類を開き、商品名、数量、単価、住所、納期、契約条件を目で追います。転記した内容を別の担当者が見直し、間違いがあれば、また元の書類に戻ります。

彩は、この流れを生成AIで効率化しようと考えました。AIに書類を読み込ませ、必要な情報を抜き出し、JSON形式で返すよう指示したのです。

JSONとは、情報を項目と値の組み合わせで表す、機械が読み取りやすいデータ形式です。

たとえば、商品名、数量、価格を決まった項目名で返せば、そのまま業務システムに渡せる。彩はそう期待していました。担当者が一件ずつ書類を読み込む仕事も、転記する仕事も減るはずでした。

ところが、導入後の画面を見て、彩の手が止まりました。

AIの出力を確認する仕事が増えた

最初に見つかったのは、JSONの形が壊れているケースです。カンマが抜けていたり、括弧が閉じていなかったりします。これでは後続のシステムが読み込めません。

次に、項目そのものの問題がありました。住所が抜けている、契約条件が空欄になっている、指示していないメモ欄が追加されている。必ず必要な項目と、なくてもよい項目の区別がついていません。

数量のような数字も厄介でした。ある出力では数値として返っているのに、別の出力では文字として返っています。人が見れば同じ「12」でも、システムにとっては別の扱いになることがあります。

さらに、「確認済み」「済」「OK」が混在していました。同じ意味のはずなのに表記が揺れるため、集計や検索の条件が安定しません。担当者は、出力を読むだけでなく、表記を直す作業まで背負うことになりました。

そして、もっと危険な例もありました。JSONの形は正しいのに、見積書の金額が違う。書かれていない契約条件を、AIが「問題なし」と判断している。形式が整っているため、かえって見落としやすい間違いです。

夕方の会議室で、担当者の一人がつぶやきました。

「AIに読ませる前より、AIの出力を確認する仕事のほうが大変になっていない？」

彩は、すぐに答えられませんでした。AIは確かに書類を読み、情報を整理しています。それでも、業務システムへ渡してよい状態かどうかを、人間が毎回確認しなければならなかったからです。

「AIの間違い」は一種類ではない

彩が調べると、問題は単なる読み取りミスではないことが分かりました。生成AIのJSON出力には、大きく三つの壁があります。

• 形式の誤り：JSONとして壊れていて、機械が読み込めない
• 項目の誤り：必須項目がない、データ型や項目名が決まりと違う
• 意味の誤り：形は正しいが、金額や数量、契約条件の内容が間違っている

JSON Schemaとは、JSONに必要な項目、データ型、必須かどうか、許可する値などを決める設計図です。

たとえば数量は数値、通貨は円、確認状態は「未確認」「確認済み」「要確認」のどれか。こうした決まりを先に設ければ、少なくとも「12」と文字列の「12」が混ざる問題や、勝手な項目の追加を見つけやすくなります。

一方で、決まりに沿っていても、価格が負の値になっていたり、数量が在庫を超えていたりすることはあります。つまり、形が正しいことと、業務上正しいことは別なのです。

技術解説の生成AIのJSON出力を信頼できる形にする方法【2026年版】でも、この三つを分けて考える重要性が説明されています。「JSONで出して」とプロンプトで指示するだけでは、キーの欠落、型の違い、項目名や構造のばらつきまでは保証できません。

確認担当者の前に、霧が広がっていく

彩が最も困ったのは、どこを見ればよいのかが毎回変わることでした。ある日は括弧の不足を直し、別の日は項目の抜けを探します。その後で、金額や契約条件が原本と一致するかを確認します。

本来なら、機械が得意な確認と、人が判断すべき確認を分けたいところです。しかし、すべてが一つの画面に混ざっているため、担当者は出力全体を最初から最後まで読み直します。AIが正しく処理できた案件も、判断が難しい案件も、同じ手間がかかります。

しかも、「判断できない」と返す代わりに、AIが空欄を埋めてしまうことがあります。書類に記載がない納期を推測したり、曖昧な契約条件を問題なしと扱ったりするのです。これは速さの問題ではありません。誤った情報が、そのまま発注や請求につながる可能性があります。

彩が気づいた、次に設計すべきこと

会議の終わりに、彩は「AIに正解を出させる」だけでは足りないと整理しました。必要なのは、最初から確認しやすい出力を作ることです。

まず、欲しいJSONの形をJSON Schemaで決める。次に、その決まりをAPIに渡して出力させる。APIとは、システム同士が決められた方法で情報を受け渡す窓口のことです。受け取った後は、jsonschemaやajvで形式を再確認し、在庫超過や金額の不一致といった業務ルールを別に検査する。エラーがあれば内容をAIに返して再生成し、それでも判断できなければ人へ戻します。

構造化出力とは、決められた項目や型に合わせて、AIの回答を返させる仕組みです。文章でお願いするだけでなく、API側の制約を使う点が特徴です。

彩が目指すのは、AIの出力を人が全部読み直す運用ではありません。形式の誤りは機械が止め、業務ルールの違反も機械が知らせる。そして、人は例外や判断が必要な案件だけを見る。霧のように増えた確認作業を減らすには、AIの導入より先に、この役割分担を決める必要があるのです。

原因はここにあります。「JSONで出して」という指示は、データの見た目をお願いしているだけで、項目名・データ型・値の正しさまで固定していないからです。生成AIの確認作業を減らすには、正しく出させることだけでなく、間違いを機械的に見つけやすい形にしておく必要があります。

JSONとは、システム同士がデータを受け渡すための、決まった書き方です。人間には文章のように読めても、システムは括弧やデータ型まで厳密に読み取ります。

たとえるなら、「箱に入れて送ってください」とだけ書いた配送依頼に似ています。箱には入っていても、宛先がなかったり、品名が手書きだったり、個数の単位がバラバラだったりすれば、受け取る側は困ります。JSONも同じです。形式らしく見えることと、業務システムが安全に使えることは別の話ですよね。

「正しいJSON」と「正しい仕事」は別です

まず押さえたいのは、出力の誤りには三つの層があることです。彩のチームが経験した失敗も、この三つに分けると原因が見えやすくなります。

1. 構文の誤り：括弧やカンマが足りず、JSONとして読み込めない状態です。
2. スキーマの誤り：スキーマとは、データの項目・型・必須条件を定める設計図です。必須キーがない、数値のはずが文字列になっている、想定外の項目が増えている、といった状態です。
3. 値や意味の誤り：JSONとしては読めても、金額や数量が資料と違う、在庫を超えている、契約条件がないのに「問題なし」と判定する状態です。

例えば、価格が 12000 なら数値ですが、"12000" なら文字列です。見た目は似ていますが、合計計算やデータベース登録で扱いが変わります。また、配列に商品を入れる設計なのに、AIが送料やメモまで商品として追加すれば、形式が正しくても後続処理は混乱します。

生成AIは、次に続きやすい言葉を選びながら文章を作ります。自然な文章をまとめることは得意でも、業務システムの細かな約束や、別資料との照合結果まで自動で保証するわけではありません。ここを「AIの能力不足」とだけ考えると、プロンプトの修正を繰り返すだけになってしまいます。

先に固定するのは、答えではなく入れ物です

解決の出発点は、プロンプトより先にJSON Schemaで出力の設計図を作ることです。

JSON Schemaとは、JSONに必要なキー、データ型、許可する値、値の範囲などを定義するルールです。AIの回答を採点するチェックリストのような役割を持ちます。

見積書なら、少なくとも次のように決めます。

金額は数値、数量は整数、通貨は許可したコードだけ、と決めておけば、単なる「JSONで出して」より具体的です。契約条件が見つからない場合も、AIに無理に二択を迫るのではなく、要確認を許可します。判断できないものを正直に戻せる選択肢が、確認作業を減らす安全弁になります。

「お願い」からAPIの制約へ変える

次に必要なのは、プロンプトだけでなくAPIにもスキーマを渡すことです。APIとは、システム同士がデータをやり取りする窓口のことです。

構造化出力とは、指定したスキーマに沿うよう、AIの出力形式をあらかじめ制約する仕組みです。API側で生成可能な形式を絞る「制約デコード」と組み合わせ、キーの欠落や型の揺れを減らします。

これは、自由に荷物を詰めてもらうのではなく、「この大きさの箱に、このラベルで入れてください」と受付側で条件を決めるイメージです。出典1でも、プロンプトによる依頼だけでなく、APIレベルの構造化出力を使う設計が紹介されています。生成AIのJSON出力を信頼できる形にする方法【2026年版】

ただし、構造化出力は値の真実性までは保証しません。見積書にない金額を、正しい型の数値で返すことはあり得ます。形式の問題を減らす仕組みと、内容を確かめる仕組みは分けて考えましょう。

検証は「形式」と「業務ルール」の二段階にする

確認を自動化する基本形は、機械的な検証を先に置き、人は例外だけを見る流れです。推奨される最小構成は次の五段階です。

1. 必須キー、型、許可値、範囲をJSON Schemaで定義する。
2. そのスキーマをAPIに渡し、構造化出力を生成する。
3. 受信後に jsonschema（Python用）や ajv（Node.js用）で再検証する。
4. コードで業務ルールを確認する。例えば、数量が在庫を超えていないか、明細合計と総額が一致するか、関連資料の番号が一致するかを調べます。
5. エラー内容を次の生成に伝えて再試行し、それでも解決しなければ人へ戻す。

三段階目までは、空港の手荷物検査でサイズや重量を測るようなものです。四段階目は、その荷物が本当に目的地向けか、宛先と中身を照合する作業です。両方を通して初めて、業務で使えるデータになります。

再試行では、単に「もう一度正しく出して」と頼むのでは不十分です。「totalが必須なのに欠落」「quantityは整数だが文字列」といった具体的なエラーを返します。回数には上限を設け、元の資料とエラー履歴を残しておくと、無限にAIへ聞き続ける事故を防げます。

最終的に人が見るのは、全件ではなく、要確認、資料間の不一致、検証を規定回数で通らなかったものです。彩が学んだのは、「AIに完璧に出力させる」ことではありません。出力を設計図に沿わせ、形式と意味を別々に検査し、判断できない案件だけを人へ戻すことでした。確認作業は、AIの回答を読む仕事から、例外を判断する仕事へ変えられます。

主な選び方は4つあります。①JSON Schemaで形を固定する、②APIの構造化出力を使う、③受け取った後に機械検証と業務ルール確認を分ける、④判断できないものだけ再生成または人へ戻す、という進め方です。大切なのは、AIに「正しく答えて」と頼むことではありません。書類を仕分けるベルトコンベアのように、最初から検査しやすい入れ物を用意することです。

転機になったのは、社内のデータ基盤を担当する西園寺蓮との出会いでした。蓮は、彩が集めた失敗例を見ながら、ホワイトボードに一つの言葉を書きました。JSON Schemaです。

JSON Schemaとは、JSONの項目名、データ型、必須項目、許可する値などを、機械が確認できるルールとして定義する仕様です。

「JSONで出して」と書くことは、AIへのお願いにすぎません。キーが抜けたり、金額が文字列になったり、同じ状態を「OK」「問題なし」など別の表記で返したりします。JSON Schemaなら、こうしたばらつきを検査できます。生成AIの出力には、形式、スキーマ、意味という3つの確認の壁があると整理されています。出典1

1. まずはJSON Schemaで「入れ物」を固定する

見積書の検査結果なら、document_id、item_count、prices、address、contract_start_date、required_items_check、cross_document_match、status、reasonのように、必要な項目を先に決めます。requiredで必須項目を指定し、金額や数量は数値、日付は決めた形式にします。

状態は自由入力にせず、enumでPASS、FAIL、REVIEWだけに限定します。enumとは、選択肢をあらかじめ絞る指定です。判断できない場合は、無理に合格にせず、REVIEWと理由を返します。additionalProperties: falseを使えば、依頼していない項目の追加も抑えられます。

いいところ

• 追加費用を抑えて始めやすい
• 欠落や型違いを機械的に見つけやすい

気をつけるところ

• 形が正しくても、価格の誤りや在庫超過までは見抜けない
• ルールが複雑になるほど、Schemaの設計と更新が必要になる

2. APIの構造化出力で「形を守らせる」

次の選択肢は、JSON SchemaをAPIに渡し、構造化出力で生成させる方法です。

構造化出力とは、AIの返答を指定したデータ構造に合わせるため、API側で出力を制約する仕組みです。

プロンプトだけでなく、APIの仕組みで出力形式を制約するため、キー名や構造の揺れを減らせます。すでにAIを業務システムへ組み込んでいる場合に向いています。

いいところ

• 毎回同じ形式で受け取りやすい
• 後続のプログラムへ渡しやすい

気をつけるところ

• 構造が正しいことと、内容が正しいことは別
• APIの対応機能や、使っているモデルの仕様確認が必要

3. 受信後の検証を「形式」と「意味」に分ける

蓮が強調したのは、AIにすべての確認を任せないことでした。受信後は、まずjsonschemaやajvでJSON Schemaに合っているかを確認します。その後、プログラムで「数量が在庫を超えていないか」「契約開始日が終了日より後になっていないか」「別書類の金額と一致するか」を確認します。

業務ルール確認とは、データの形ではなく、業務上あり得る内容かを検査することです。

いいところ

• 形式エラーと業務上の誤りを切り分けられる
• 人が読む前に、明らかな不備を落とせる

気をつけるところ

• 自社の業務ルールをコード化する作業が必要
• ルール変更時に、検証プログラムも見直す必要がある

4. REVIEWと再生成で「例外だけ」を人へ戻す

最後は、判断できない出力を人へ戻す設計です。検証エラーがあれば、どの項目で失敗したかを次の生成に伝えて再試行します。それでも直らない場合や、元の書類が不鮮明な場合は、REVIEWとして担当者へ渡します。確認作業をゼロにするのではなく、全件確認を例外確認へ変える考え方です。

いいところ

• 人は難しい案件だけを見ればよい
• AIが根拠なく「問題なし」と断定する事故を抑えやすい

気をつけるところ

• 再試行の回数上限と、担当者へ渡す条件が必要
• reasonに理由や参照箇所を残さないと、結局読み直しになる

長い資料は「必要な部分だけ」渡す

出力形式を固定しても、AIへ長大な仕様書を毎回すべて渡せば、確認しにくくなります。大分類、サブ分類、更新日、適用範囲などのメタデータを付け、関連する仕様だけを検索して渡します。

検索インデックスとは、必要な文書や情報をすばやく見つけるための整理棚です。

東雲商事では、見積書、契約条件、商品マスタ、社内用語集を検索できるよう、Elasticsearchを使う案を検討しました。Azure AI Searchも候補です。専門用語を検索しやすくしておくと、AIの判断材料を必要な分だけそろえられます。

まずは、①Schemaを定義、②構造化出力で生成、③jsonschemaまたはajvで再検証、④業務ルールを確認、⑤エラーを反映して再試行、という5段階から始めるとよいでしょう。出典1 形をそろえることは、AIを賢く見せるためではありません。人が本当に判断すべき例外を、見つけやすくするための設計なのです。

結論から言うと、確認作業を減らす近道は、生成AIの出力を「生成→形式検証→業務チェック→再生成または人の確認」という一本の流れにすることです。最初から完璧な回答を期待するのではなく、機械が直せるエラーと、人が判断すべき例外を分けます。

見積書を例にすると、資料を保存し、OCRで読み取り、必要な仕様を検索してAIへ渡します。その後、構造化されたJSONを受け取り、JSON Schemaで形を確認します。最後に金額や数量、関連書類との一致をコードで検査します。失敗したら具体的なエラーをAIへ返し、それでも判断できないものだけを担当者へ回します。

1. 入力資料を保存し、追跡できる状態にする

まず、見積書や契約書、仕様書を処理前に保存します。ファイル名だけでなく、受付番号、取引先、取得日時、元ファイルの保存場所も記録しましょう。

OCRとは、紙やPDFの画像から文字を読み取る技術です。

OCRの結果には、読み間違いや表の崩れが含まれることがあります。元のPDFと抽出テキストを両方残しておくと、後で担当者が原本を確認できます。AIへ渡す資料には、文書IDやページ番号も付けておくと、根拠をたどりやすくなります。

2. AIへ渡す情報を必要な範囲に絞る

次に、仕様書や社内ルールから、今回の判定に必要な情報だけを検索します。検索結果をAIへ渡す仕組みをRAGと呼びます。

RAGとは、社内文書などを検索し、その結果を生成AIの回答材料にする方法です。

たとえば「標準単価」「契約開始日の扱い」「数量の上限」を検索して渡します。関係のない文書まで大量に渡すと、AIが別の条件を拾うおそれがあります。検索結果には文書名、ページ、該当箇所を添え、根拠が見つからない場合はREVIEWにする、と先に決めておきます。

3. JSONの形をJSON Schemaで定義する

AIに「JSONで出してください」と頼むだけでは、キーの欠落や型の違いを防ぎきれません。先に、必要な項目と許可する値を定義します。

JSON Schemaとは、JSONに必要な項目、データ型、必須条件、許可する値を決める設計図です。

たとえば、次のように定義します。

{
  "type": "object",
  "required": ["quote_id", "total_amount", "status", "checks"],
  "properties": {
    "quote_id": {"type": "string"},
    "total_amount": {"type": "number", "minimum": 0},
    "status": {"enum": ["PASS", "FAIL", "REVIEW"]},
    "checks": {
      "type": "object",
      "required": ["required_items", "document_match"],
      "properties": {
        "required_items": {"type": "string"},
        "document_match": {"type": "string"}
      }
    }
  }
}

金額を文字列ではなく数値にする、状態をPASS・FAIL・REVIEWに限定する、といったルールが見える形になります。日付はYYYY-MM-DDに統一し、項目名の表記も固定しましょう。

4. APIレベルで構造化出力を指定する

次は、生成AIのAPIにスキーマを渡して出力形式を固定します。

構造化出力とは、プロンプトだけでなくAPI側の制約によって、指定したJSONの形で回答させる仕組みです。

実装時は、利用するサービスがJSON Schema対応のStructured Outputsを提供しているか確認します。プロンプトには「推測せず、資料で確認できない値はnullまたはREVIEWにする」と書きます。ただし、プロンプトは補助です。形式の保証はAPIと受信後の検証に任せます。

5. 受信後にJSON Schemaを再検証する

APIが正しい形式を返したように見えても、受信後の再検証を省略しないでください。通信設定の変更や別モデルへの切り替えで、想定外の値が混ざることがあるためです。

Pythonならjsonschema、Node.jsならajvを使えます。たとえばPythonでは、次のように検証します。

from jsonschema import Draft202012Validator

errors = sorted(
    Draft202012Validator(schema).iter_errors(result),
    key=lambda error: list(error.path)
)

if errors:
    messages = [
        f"{list(error.path)}: {error.message}"
        for error in errors
    ]

requiredにない項目が欠けていれば必須キー不足、数値欄が文字列ならデータ型不一致、許可外の状態ならenum違反です。ここでは「形」を検査し、まだ「正しい金額か」までは判断しません。

6. 業務ルールをコードで別に確認する

次に、見積書の内容が業務上正しいかを確認します。JSON Schemaは設計図の検査であり、業務上の意味までは保証しないからです。

たとえば、次のルールを別の関数として実装します。

• 明細の単価×数量と小計が一致する
• 小計の合計と請求総額が一致する
• 数量が在庫数や契約上限を超えていない
• 見積書と注文書の取引先・品目・金額が一致する
• 契約開始日が資料内で確認できる

検査結果は一つの「問題なし」にまとめません。次のように、判定と理由を分けて出します。

{
  "status": "REVIEW",
  "checks": {
    "required_items": "PASS",
    "document_match": "REVIEW"
  },
  "reasons": ["注文書の数量が資料内で確認できない"]
}

これなら担当者は、すべてを読み直すのではなく、document_matchだけを確認できます。

7. エラー内容を返して再生成する

検証に失敗したら、「もう一度出してください」とだけ依頼しません。どの場所で、何が、どう違ったのかを返します。

次の検証エラーを修正して、同じJSON Schemaで再生成してください。
- prices[0]は数値である必要があります。現在は文字列です。
- statusはPASS、FAIL、REVIEWのいずれかにしてください。
- contract_start_dateが確認できない場合は推測せずREVIEWにしてください。

再生成回数には上限を設けます。たとえば2〜3回で直らなければ、人へ回します。無限リトライは、同じ誤りを繰り返すだけでなく、API費用や処理時間も増やします。

8. 最後に「例外だけ」を担当者へ渡す

人に回す条件を先に決めておくことが重要です。たとえば、資料が欠けている、関連書類と金額が一致しない、同じ項目に複数の候補がある、再生成の上限に達した、といった場合です。

注意したいのは、FAILとREVIEWを混同しないことです。FAILはルール違反を確認できた状態、REVIEWは資料不足などで機械が断定できない状態です。この2つを分けると、担当者の判断が安定します。

最後に、元資料、AIへの入力、出力JSON、検証エラー、再生成回数、担当者の最終判断を保存しましょう。これがあれば、なぜその判定になったかを後から確認できます。形式の検証と業務チェックを分け、エラーを具体的に返し、判断できないものを人へ戻す。この三つが、確認作業を減らしながら安全性を保つ基本です。設計の詳しい背景は、生成AIのJSON出力を信頼できる形にする方法【2026年版】も参考になります。

成果は、担当者がすべての書類を読み直す運用から、FAIL・REVIEWの例外と、その理由だけを見る運用に変わったことです。彩たちの画面では、確認項目が固定され、問題のない結果は読み飛ばせるようになりました。対応時間の短縮率は業務量や書類の種類で変わるため一律には言えませんが、3種類の誤りを分け、5段階で検証する設計が確認作業を減らす土台になります。出典1

彩が最初に変えたのは、AIの文章ではなく「項目」でした

運用開始日、新しい一覧画面には次のような結果が並びました。

• 必須項目の有無：PASS
• 関連資料との一致：FAIL
• 金額の型：検証済み
• 契約開始日の確認：REVIEW
• 理由：関連書類に該当日付の記載なし

以前は、AIが生成した文章を担当者が最初から最後まで読んでいました。今は、FAILやREVIEWの箇所を開き、理由と参照資料を確認します。

JSON Schemaとは、JSONの必須項目、データ型、許可する値を決める「データの設計図」です。

たとえば、出力を次のように固定します。

{
  "document_match": {"status": "FAIL", "reason_code": "MISSING_DATE"},
  "amount": {"status": "PASS", "value": 120000},
  "contract_start_date": {
    "status": "REVIEW",
    "reason": "関連書類に該当日付の記載なし",
    "source_refs": []
  }
}

statusをPASS・FAIL・REVIEWの3値に限定し、理由コードと参照元も持たせます。こうすると、一覧画面で例外を絞り込みやすくなります。

「JSONで出して」だけでは、確認作業は減りません

生成AIのJSON出力には、形式の誤り、スキーマ上の誤り、意味の誤りという3つの壁があります。JSONらしい形でも、キーが抜けたり、金額が文字列になったり、資料にない日付を推測したりすることがあるためです。出典1

構造化出力とは、AIに文章でお願いするだけでなく、API側の制約によって、指定したデータ構造に沿うよう出力させる仕組みです。

まずJSON Schemaを定義し、それをAPIへ渡して生成します。単にプロンプトへ「JSONで出して」と書く方法より、キーの欠落や型の揺れを抑えやすくなります。ただし、スキーマに適合しても、金額が資料と一致するとは限りません。形と意味は、別々に確認する必要があります。

成功しやすい5段階の流れ

この事例でうまくいった工夫は、AIに一度で正解させようとしなかったことです。次の順番で、機械的な確認から人の判断へつなぎました。

1. 欲しい形を定義する：必須キー、型、列挙値、日付形式をJSON Schemaに書きます。
2. 構造化出力を生成する：スキーマをAPIへ渡し、決めた形式で受け取ります。
3. 形式を再検証する：受信後もjsonschemaやajvで検証します。出典1の検証例では、JSON Schema Draft 2020-12、Python 3.14系とjsonschema 4.26、Node.js 24系とajv 8.20が使われています。
4. 業務ルールを確認する：金額や日付を関連資料とコードで照合します。在庫数を超えていないか、合計金額が明細と合うかも確認します。
5. エラーを反映して再生成する：型の誤りや不足項目は、エラー内容を次の生成へ渡して再試行します。判断できない内容は無理に直さず、REVIEWとして人へ戻します。出典1

ここで大切なのは、スキーマ違反と業務ルール違反を別のエラーとして記録することです。前者は「データの形が違う」、後者は「形は正しいが、仕事の条件に合わない」という違いがあります。原因が違うため、再生成するのか、人が確認するのかも変わります。

担当者が見るのは「例外」と「理由」になった

彩たちは、AIの判定をそのまま信じる運用にはしませんでした。参照元が見つからない場合は推測を禁止し、理由と資料の位置を記録しました。その結果、担当者の仕事は「出力を全部読むこと」から、「例外の内容を確認して最終判断すること」へ変わりました。

確認作業そのものがなくなったわけではありません。しかし、確認する範囲と順番が整理されました。現場へ応用するなら、まず1種類の書類で、必須項目・照合項目・人へ戻す条件を決めてみてください。AIの性能を待つより、確認しやすい出口を先に設計するほうが、改善の手応えを得やすいですよね。

今日のポイントは5つです。生成AIの確認作業を減らすには、次の順番で「確認しやすい受け皿」を作ることが大切です。

• 欲しい項目と形式を、JSON Schemaで先に決める
• APIの構造化出力で、決めた形に沿って生成する
• 受信後に、スキーマ違反がないか再検証する
• 値の正しさや業務上の整合性を、別のルールで確認する
• 判断できない結果はREVIEWとして人に戻し、失敗時は再生成する

たとえば、請求書の読み取りをAIに任せる場合です。「JSONで出して」と頼むだけでは、amountが抜けたり、金額が文字列になったりします。見た目はそれらしくても、数量が在庫を超えている可能性もありますよね。AIの性能を上げるだけでは、確認作業は減りません。出力を機械的に検証できる形へ整えることが先です。

JSON Schemaとは、JSONに含める項目、データ型、必須項目、許可する値などを定義する設計図です。

「正しい」の中身を3段階に分ける

最初に押さえたいのは、出力の誤りには3種類あることです。

1. 形式の誤り：JSONとして読み取れない、かっこが閉じていない
2. スキーマ上の誤り：必須キーがない、数値が文字列になっている
3. 意味の誤り：価格が負の値、数量が在庫数を超えている

構造化出力は、APIレベルで形式や構造をそろえる仕組みです。ただし、商品価格が本当に正しいかまでは保証しません。そこで、形式の検証と業務上の判断を分けます。前者はjsonschemaやAjv、後者は自社のコードや業務ルールで確認します。

最低限の受け皿を作る

まずは、対象業務で必ず必要な項目を3〜5個に絞って定義しましょう。いきなり完璧な設計を目指す必要はありません。たとえば、注文情報なら次のような形です。

{
  "type": "object",
  "properties": {
    "order_id": { "type": "string" },
    "quantity": { "type": "integer", "minimum": 1 },
    "status": { "enum": ["OK", "REVIEW", "FAIL"] }
  },
  "required": ["order_id", "quantity", "status"],
  "additionalProperties": false
}

enumとは、許可する値を限定する指定です。statusをOK、REVIEW、FAILの3つに固定すれば、「確認済み」「人の確認が必要」「処理失敗」の意味がぶれません。additionalProperties: falseは、定義していない余分な項目を受け付けない指定です。項目の増殖やキー名の揺れを防げます。

実装では、次の流れをひとつの処理として組み込みます。

1. JSON Schemaを用意する
2. スキーマをAPIへ渡し、構造化出力を生成する
3. 受け取ったJSONを再検証する
4. 在庫、金額、日付などの業務ルールを確認する
5. エラー内容を記録し、必要なら再生成する

構造化出力を使っても、受信後の再検証は省かないほうが安全です。APIやモデルの変更、入力資料の例外に備える「入荷検査」と考えると分かりやすいですよね。詳しい実装例は、生成AIのJSON出力を信頼できる形にする方法（2026年版）も参考になります。

人が見るのは「例外」と「理由」だけにする

確認画面には、AIの全文ではなく、判定結果、エラー項目、理由、元資料の該当箇所を表示します。たとえば、次のような内容です。

• FAIL：quantityが整数ではない
• REVIEW：請求書の合計金額と明細の合計が一致しない
• REVIEW：商品名が用語集に見つからない

これなら担当者は、最初から全件を読み直す必要がありません。人は例外の解消や最終判断に集中できます。判断できないものをAIが無理にOKへ進めないことも重要です。

明日から始める3ステップ

まず、直近1週間で確認に時間がかかった出力を10件だけ集めます。次に、欠落した項目、型の違い、表記揺れ、業務上の間違いを分類します。最後に、最も多かった項目からスキーマとチェックルールを1つずつ追加します。

生成AI導入の成果は、「AIが何％正解したか」だけでは測れません。どのエラーを機械で止め、どの例外を人へ戻せたかが重要です。確認作業が増えたときは、モデル選びをやり直す前に、出力の受け皿を見直してみてください。小さなスキーマから始めれば大丈夫です。AIをすべて任せる道具ではなく、判断しやすい結果を届ける業務基盤へ、明日から少しずつ育てていきましょう。