メールに埋もれた情報を構造化する。欲しい項目を自動で抜き出す

見積の依頼、仕様の確認、日程の調整といった情報の多くは、メールの本文の中に埋もれたままになっています。

埋もれた情報は、そのままでは集計できません。
「今月の見積依頼は何件あったか」と聞かれても、誰かが表に転記していなければ答えられないからです。
転記の作業は手作業だと後回しになるので、記録されなかった依頼はそのまま埋もれていきます。

今回は、メールからの情報抽出を自動で回して構造化するやり方を整理していきます。
問い合わせを記録して振り分けるところは問い合わせ対応を記録・判定・通知まで自動化する。一次対応の設計にまとめてあります。

受注機会がメールボックスに埋もれている

まず、いま何が起きているのかを整理しておきます。

いま何件の依頼が来ているのか、即座に答えられるでしょうか？
件数が分からなければ、対応の体制も判断できません。
内容の傾向も見えないので、「見積が多いのか、仕様確認が多いのか」を勘で語ることになります。
一覧になっていないと対応済みかどうかも記憶に頼ることになり、取りこぼしにも気づけません。

もっとも損失が大きいのは、担当が変わると経緯を追えなくなることです。
案件の経緯がメールの中にしかない状態は、担当者の受信箱に業務の記録が閉じ込められているのと同じだからです。

やり取りの中にしかない情報を外に出す話はAIは前の会話を覚えているのか。情報の置き場所を決める3分類で扱っています。

抽出する項目は、使い道から逆算して決まる

作る前に決めておくことがあるとすれば、それは「何を抜き出すか」です。

ここを決めずに始めると、なんとなく要約された列ができるだけで、集計には使えません。
決め方は、その情報を何に使うかから逆算することです。

例えば見積の依頼なら、「件数を数えたい」「金額の規模を知りたい」「納期の傾向を見たい」「どの製品の依頼が多いか知りたい」といった目的があります。
この目的から逆算すると、抜き出す項目は依頼者・製品・数量・希望納期になります。

項目は5〜7個に絞っておきます。
網羅的に抜き出そうとすると精度が落ちますし、使わない列も増えていくからです。

ただ、「集計に使う項目」と「読むための項目」は分けておきます。
数量や日付は集計に使うので形式をそろえ、要望の内容は読むためのものなので文章のままで構いません。

転記だけ→項目抽出→集計の順につなぐ

ここでも、段階を踏んで進めます。
最初は転記だけにして、受信したメールを表に1行追加します。
日時・送信者・件名・本文・対応状況を並べるだけで、内容の解析はまだしません。
表の作り方そのものはスプレッドシートを社内DBとして扱う。AI自動化の土台設計にまとめてあります。

この段階だけでも、一覧になる、件数が数えられる、対応済みかどうかが分かるという価値が生まれます。
2週間続ければ、実態が見えてきます。

何件来ているか、どんな内容が多いか。
想定と違うことがよくあるので、実態を見てから抽出する項目を決めるほうが確実です。
目安は2週間で、40〜100件ほど溜まれば傾向はつかめます。

実態が見えたら、抽出の列を足していきます。
まず抜き出せない場合の扱いを決めておき、本文に書かれていない項目は空欄にします。
「不明」と入れるより、空欄のほうが後の集計で扱いやすいからです。
空欄が多い項目は、そもそも本文に書かれていないということなので、抽出の対象から外します。

次に形式を指定しておき、日付は「2026-09-10」の形、数量は数字だけと決めます。
ここを決めておかないと表記がばらばらになって、集計そのものができなくなります。
抽出の書き方そのものはスプレッドシートのAI関数で終わる業務・終わらない業務で扱っています。

もうひとつが、元の本文を残すことです。
抽出した列だけにすると、抽出が誤っていたときに確認できなくなるからです。
判定は完璧にならない前提で設計し、手で直せる形にしておきます。

列が埋まるようになったら、集計まで接続します。
週次または月次で件数、金額の規模、製品別の内訳、納期の分布を出し、「誰が見るか」を決めておきます。
ここが決まっていないと、列が埋まるだけで終わってしまいます。

見た結果を何に使うかも、あらかじめ決めておきます。
「依頼が多い製品について、見積の型を用意しておく」「納期の要望が厳しい依頼が増えていれば、生産の計画に反映する」という具合です。
数字を判断に使う形にするところは数字を見える状態にする。データ集計と分析をAIで日常業務化するにまとめてあります。

もっとも飛ばされやすいのが、この工程です。
構造化そのものが目的化して、集計されないまま列が溜まっていきます。
構造化の価値は、集計して判断に使うところで初めて生まれます。

メールの構造化をほかの候補と並べて、どの順で進めるかを決めるときは、業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順に沿うと判断がぶれにくくなります。

精度が出ないときは、フォームに寄せる手を考える

運用に入ると、精度の問題が必ず出てきます。
原因ごとに対処を書いておきます。

まず項目の定義があいまいな場合で、「数量」と書いても本文に複数の数字があるとどれを取るか決まりません。
対処は定義を具体的にすることで、「発注を希望する製品の個数」のように書きます。

次に本文の書き方が多様な場合で、相手によって書き方が違うので同じ項目が別の表現で書かれてしまいます。
対処は表現の例を複数示すことで、「『500個』『500pcs』『五百個』のような表記から数量を取ってください」と指定します。

もうひとつが、そもそも書かれていない場合です。
空欄が多い項目は抽出の問題ではないので、対処は項目を外すか、問い合わせのフォームを用意して書かせる形に変えることになります。

フォームに寄せる対処が、実は最も効きます。
メールの自由記述から抜き出すより、フォームで項目を埋めてもらうほうが確実だからです。
構造化の努力より、最初から構造化された形で受け取る設計のほうが、上流の対処になります。

もちろん、ここは判断が必要です。
フォームに寄せられるのは自社のサイトからの問い合わせや、既存顧客からの定型的な依頼で、案内すればフォームを使ってもらえます。
寄せられないのは、取引先が既存のメールのやり取りで依頼してくる場合や、担当者の慣習で変えられない場合です。

こうした相手には、メールからの抽出がそのまま必要になります。
つまり両方が混在するのが普通で、フォームを用意しつつメールからの抽出も残す構成になります。
判断の目安は依頼元との関係で、こちらが案内できる相手にはフォームを、相手の都合が優先される相手にはメールからの抽出を、と分けて設計します。

つまずきやすいのは6つです。
抽出する項目を決めずに始める、転記の段階を飛ばして抽出から作る、項目を10個以上にする、本文の列を残さない、集計の工程を飛ばす、フォームに寄せられる依頼までメールからの抽出で対応する、というものです。
どれも使い道から逆算して、転記から始めて、5〜7個に絞って、本文を残して、見る人と使い道を決めて、依頼元との関係で分ければ避けられます。

構造化したデータは、誰が見るかまで設計して活きる

ここまで書いてきたとおり、構造化の技術的な部分は難しくありません。
難しいのは、構造化した後の設計のほうです。
実務でいちばん多い停滞は、列は埋まっているのに誰も見ていない状態です。
集計の表は作られ、月次で更新されているのに、判断には使われていません。

原因は2つあり、ひとつは見る人と見るタイミングが決まっていないことです。
もうひとつは、集計を見る作業そのものが手間だということです。
表を開いて、絞り込んで、前月と比べる。
この作業が毎回発生すると、忙しい月から飛んでしまいます。

だから必要なのは、見たい形で自動的に出てくる状態です。
開いたときに、そのまま判断に使える形になっているということです。

AIの利用状況についても同じで、当社の組織のAIポータル「AI Portalize」では、部署・職種・グレードごとの利用率と前期比が集計の手間なしで出るので、開いたときにそのまま判断に使えます。
構造化はできたが判断に使われていない状態で止まっているなら、考え方の参考になるかもしれません。

構造化は、集計されて判断に使われて初めて意味を持つ

メールの本文にある情報は、そのままでは集計できません。
手作業の転記は後回しになるので、そのまま埋もれていきます。
作る前に、何を抜き出すかを使い道から逆算して決めます。
項目は5〜7個に絞り、集計に使う項目と読むための項目を分けておきます。

進め方は3段階で、転記だけを自動化して2週間分の実態を見て、抽出の項目を足し、集計して見る人と使い道を決めます。
精度が出ない原因は、定義のあいまいさ、本文の書き方の多様さ、そもそも書かれていないことの3つです。
最後のものは、フォームで項目を埋めてもらう形に変えるのがもっとも効く対処になります。

フォームに寄せられる依頼と、メールからの抽出が必要な依頼は分けて設計しておきます。
目安は、こちらが案内できる相手かどうかです。
受信したメールを2週間分だけ表に転記してみると、抜け落ちていた項目が浮かび上がります。