「過去の見積書を全部集計して、商品ごとの平均単価を出したい」「問い合わせメールを種類別に分類して、多い相談を可視化したい」——中小企業の経営者や IT 担当から、こうした相談をよく受けます。やりたいことは明確なのに進まない。理由はいつも同じで、データが PDF やメール本文や自由記述といった「人間は読めるが、機械は集計できない」形（非構造化データ）で散らばっているからです。一件ずつ目で読んで Excel に転記すれば不可能ではない。でも何百件、何千件となれば現実的ではありません。
ここに大きく効くのが、近年の LLM が標準で備えた 構造化出力（JSON / Function Calling）です。LayerX の LLM時代のデータ基盤：非構造化データを扱うETLプロセスの重要性 が指摘するように、文字起こしや PDF・メールといった非構造化データを LLM で項目に分解し、データウェアハウスや業務システムに載せる ETL が、組織のデータ活用の前提になりつつあります。2026 年の LLM は「文章を返す」だけでなく、指定したスキーマ（項目定義）どおりの JSON を返すことに対応しており、業務システムに組み込みやすくなりました。受託で開発を支える立場では、これは「ChatGPT に貼って整形する」という単発の作業ではなく、「散らばった非構造化データを、継続的に・検証つきで構造化し続ける仕組み」をどう設計するかという、れっきとしたシステム開発の課題だと捉えています。
「その場でAIに整形」と「パイプライン化」は別物
非構造化データの構造化を、担当者が ChatGPT に貼り付けて手作業でやる——これでも少量なら回ります。ですが業務に組み込むとなると、まったく別の設計が要ります。
| 観点 | その場でAIに整形 | 構造化パイプライン（受託） |
|---|---|---|
| 対象量 | 数件〜数十件 | 継続的に大量処理 |
| 出力の形 | 都度バラバラ | スキーマで統一 |
| 間違いの検知 | 人が目視 | バリデーションで自動検知 |
| 再現性 | 担当者依存 | 仕組みとして再実行可能 |
| 連携先 | コピペで手動 | DB・業務システムへ自動投入 |
業務で使うなら、「項目が常に揃っている」「おかしな値を検知できる」「同じ処理を何度でも回せる」ことが不可欠です。ここを設計せずに AI 任せにすると、抽出ミスがそのまま業務データに混入し、後から手戻りが膨らみます。AI を業務に組み込む際のコスト面の考え方は Cloudflare AI Gateway で AI 予算ガバナンスを組む（GH Media） も併読してください。
構造化の中核 — スキーマを先に決める
うまくいくパイプラインに共通するのは、「どんな項目を抜き出すか（スキーマ）」を先に厳密に決め、LLM にはその形でしか返させないという設計です。下は、見積書 PDF から必要項目を抜く際のスキーマ定義のイメージです。
// 抽出したい項目を「型」として先に定義する
const QuoteSchema = {
type: "object",
properties: {
customer: { type: "string" }, // 宛先企業名
issuedAt: { type: "string", format: "date" }, // 発行日 (YYYY-MM-DD)
items: {
type: "array",
items: {
type: "object",
properties: {
name: { type: "string" }, // 品名
unit: { type: "number" }, // 単価
quantity: { type: "integer" }, // 数量
},
required: ["name", "unit", "quantity"],
},
},
total: { type: "number" }, // 合計金額
},
required: ["customer", "issuedAt", "items", "total"],
};
// LLM には「このスキーマに従った JSON だけを返す」ことを強制する
// → 返ってきた JSON をバリデーション → 通ればDBへ、落ちれば人手レビューへこのように型を先に固定しておくと、LLM の出力は常に同じ構造になり、total が数値でない・必須項目が欠けるといった異常を機械的にはじけます。文章ではなく構造化された値で返させることが、業務データとして使えるかどうかの分かれ目です。社内文書を AI に扱わせる発想の入口は ChatGPT 業務活用ガイド（GH Media） も参考になります。
受託で組む「構造化パイプライン」の勘所
弊社の受託では、抽出処理そのものよりも、間違いをどう扱うかに最も力を割きます。LLM は便利ですが万能ではなく、まれに項目を取り違えます。業務で使う以上、その前提で仕組みを組みます。
具体的には、抽出した JSON を必ずバリデーションに通し、スキーマに合わない・金額の桁が異常・合計が明細と合わない、といったものは自動で弾いて人手レビューのキューに回します。確からしいものだけを DB や業務システムに自動投入し、怪しいものは人が確認する——この「自動 8 割・人手 2 割」の振り分けこそが、現場で破綻しないパイプラインの肝です。ある卸売業のクライアントでは、取引先からバラバラの様式で届く注文書を構造化して受注システムに流す仕組みを作りましたが、最初から「読み取れない・怪しい注文書は人に回す」前提で設計したことで、安心して自動化を任せられる運用に落ち着きました。
また、抽出元のファイルと抽出結果をひも付けて保管し、後から「この数字はどの PDF の何ページから来たか」を追えるようにします。これがないと、誤りが見つかったときに原因をたどれず、データへの信頼が崩れます。AI の出力を業務で扱う際の品質保証の考え方は AI 成果物の品質ガバナンス（GH Media） も参考になります。
どんなデータが対象になるか
| 構造化しやすい | 設計に注意が要る |
|---|---|
| 見積書・請求書・注文書 PDF | 手書き・低品質スキャン画像 |
| 問い合わせ・申込の自由記述 | 専門用語が多い契約書 |
| 議事録・通話の文字起こし | 機密性が極めて高い文書 |
| 名刺・アンケート | 表記ゆれが激しい古い台帳 |
定型に近い帳票や問い合わせ文は、比較的素直に構造化できます。一方、手書きや高度な機密文書は、認識精度や情報の取り扱い方針を含めて設計が必要です。「何から手を付けるか」は、量が多く・様式がある程度そろっていて・集計したい欲求が強いデータから選ぶのが定石です。
価格モデル — 非構造化データ構造化パイプライン
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 実現性検証 | 20 万円〜 | 1 種類 | サンプルで抽出精度・スキーマを検証 |
| 標準構築 | 80 万円〜 | 1〜2 種類 | 抽出 + バリデーション + DB 投入の構築 |
| 業務連携 | 160 万円〜 | 複数種類 | + 業務システム連携 + 人手レビュー導線 |
| 運用保守 | 5 万円〜 / 月 | 運用 | 精度モニタリング + スキーマ追補 |
実現性検証（20 万円〜）だけでも、「自社のこのデータは、どこまで自動で構造化でき、どこから人手が必要か」を実データで見極められます。いきなり大きく作らず、精度が出ると分かった対象から段階的に広げるのが、失敗しない進め方です。
まとめ — 「読めるが集計できない」を資産に変える
社内に眠る PDF・メール・自由記述は、読めば分かるのに集計できないせいで、これまで分析にも自動化にも使えませんでした。LLM の構造化出力は、ここを項目に分解して業務データへ変える鍵になります。ただし業務で使うには、スキーマを先に固め、抽出結果をバリデーションし、怪しいものは人手に回す——その仕組みを設計して初めて、安心して任せられるパイプラインになります。受託で開発を支える立場では、この「検証つきの構造化パイプライン構築」が、眠っていたデータを意思決定と自動化に使える資産へ変える主力サービスです。
「過去の帳票を集計したい」「問い合わせを分類して可視化したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。まずは 1 種類の実現性検証から始められます。
