商流・単価をメールから自動判定する仕組みと「不明」の扱い
SES案件・人材メールの商流と単価は、本文をAIが解析することで自動判定でき、記載が見当たらない商流は無理に推測せず「不明」として正直に区分します。
商流と単価は、Dot Linkがメールから抽出する項目の中でも最優先の2つです。
この記事では、この2項目をどう自動判定するか、そして判定できないときにどう振る舞うかという見落とし防止の仕組みを、実データを元に解説します。
商流の確認を目視に頼る運用の限界
商流の確認を目視に頼る運用の限界は、書かれ方がメールごとにばらばらで、しかも記載そのものが無いケースが多い点にあります。
単価であれば「85万円」といった数値が本文のどこかにありますが、商流は「貴社まで」「1社先可」「商流不問」のように表現も位置も一定しません。
営業担当の方は、この曖昧な情報を1通ずつ読み取り、頭の中で取引条件を組み立てています。
案件メールと人材メールで商流の書かれ方が違う
商流の書かれ方は、案件メールと人材メールで大きく異なります。
案件メールは「どこまでの商流なら受けられるか」が取引条件そのものなので、比較的明記されやすい傾向があります。
一方で人材メールは、その人のスキルや稼働時期が主役になり、商流の条件は書かれないまま届くことがほとんどです。
この非対称を意識せずに全メールを同じ感覚で確認すると、そもそも情報が無いところを探し続けて時間を使ってしまいます。
商流の誤認が多重下請けのトラブルにつながる
商流の確認で怖いのは、読み違いや思い込みが後工程のトラブルに直結することです。
SESは多重下請けの構造を持つため、本来は多段階だった商流を「貴社まで」と誤認すると、想定外の商流で提案してしまい「話が違う」という信頼問題になりかねません。
だからこそ商流は、正確に判定することと同じくらい、根拠が無いときに決めつけないことが重要になります。
同じ受信メールでも、1通に複数案件が混在して後半を見落とすケースについては、別の記事で扱っています。
データで見る商流判定の実態
商流の判定結果を実データで見ると、「メールに書かれているかどうか」で判定できるかが決まる、という構造がはっきり表れます。
以下は、Dot Linkが2026年3月17日〜7月23日に処理したメール由来の案件・人材情報のうち、マッチングに使える形へ正規化済みのレコード（1レコード＝1件の案件または人材情報）を集計した結果です。
母数は49,478件で、うち案件（JOB）が24,610件、人材（CANDIDATE）が24,868件です。
49,478件のうち商流を明記していたのは19.5%
商流の具体的な値（「貴社まで」「1社先可」「商流不問」等）を判定できたのは9,672件で、全体の19.5%でした。
残りは、商流の記載が見当たらず「不明」として扱ったものが32,295件（65.3%）、項目自体が対象外だったものが7,511件（15.2%）です。
つまり、メールから商流が具体的に取れるのは全体の約2割で、大半はそもそも本文に書かれていないという実態が見えます。
案件は37.4%が明記｜人材は1.8%という非対称
商流を判定できた9,672件を種別で分けると、その大半が案件側に偏っています。
案件（JOB）側は9,215件で案件全体の37.4%、人材（CANDIDATE）側は457件で人材全体の1.8%でした。
案件メールは商流を明記することが多く、人材メールではほとんど明記されないという非対称が、数字の上でも明確に出ています。
この違いを踏まえると、人材メールの商流が「不明」でも、それは抽出の失敗ではなく元のメールに書かれていないことの反映だとわかります。
65.3%を「不明」として正直に区分した意味
「不明」が最多の65.3%を占めるという結果は、一見ネガティブに見えて、実は見落とし防止の中核です。
もし商流不明のメールをAIが適当に「貴社まで」と決めつけて処理すれば、実際には多段階だった案件を誤った条件でマッチングし、後からトラブルになります。
書かれていない情報を推測で埋めず、根拠が無ければ「不明」と正直にフラグを立てることで、確認すべき対象がはっきり切り分けられます。
営業担当の方は、この「不明」とマークされた案件・人材だけを重点的に見ればよく、全件を1件ずつ目視で確認し直す必要がなくなります。
単価は9割超が自動で数値化できる
商流とは対照的に、単価はメールに数値が書かれていることが多く、その9割超を比較可能な数値レンジへ自動判定できます。
同じ母数49,478件・同じ集計期間で、単価情報を数値レンジへ自動正規化できたのは92.1%にあたる45,548件でした。
単価は「書かれているものをどう揃えるか」が主な課題で、商流の「そもそも書かれているか」という課題とは性質が違います。
単価正規化の仕組みと表記ゆれの扱いは、姉妹記事で詳しく解説しています。
商流と単価をメール転送だけで自動判定する流れ
商流と単価の自動判定は、ses@dot-link.jpにメールを転送するだけで動き、営業担当の方の手作業は転送の一手だけになります。
その後の本文解析、商流・単価の切り出し、判定できないものの区分けは、すべて自動で進みます。
ここで大事なのは、判定できたものと「不明」なものが最初から区別された状態でデータになる点です。
ses@dot-link.jpに転送して2項目を切り出す
受信した案件・人材メールをses@dot-link.jpに送ると、AIが本文を解析して商流・単価を最優先の項目として切り出します。
商流は明確な値が取れれば具体的な条件として、単価は数値が取れれば比較可能なレンジとして構造化されます。
営業担当の方が本文を読み取って条件を組み立てる工程が、転送だけで置き換わります。
根拠がなければ「不明」とフラグを立てる
Dot Linkは、メールに書かれている情報だけを根拠に商流を判定します。
本文に商流の記載が見当たらなければ、それらしい値を推測で当てはめず、「不明」というフラグをそのまま立てます。
これは判定の失敗ではなく、根拠の無い決めつけをしないという設計判断であり、誤った商流でのマッチングを未然に防ぐための区分です。
「不明」だけを確認すれば全件目視が要らない
商流が「不明」とマークされていれば、営業担当の方はそこだけを重点的に確認すれば済みます。
判定済みの案件は自動で条件が揃っているため、確認の手を入れる必要があるのは「不明」の一部に絞られます。
全件を1通ずつ見直す運用から、確認すべき対象だけが明示される運用へ変わることが、見落とし防止の実務的な効果です。
マッチングの土台としての商流・単価
商流・単価を正確に区別することは、その先のマッチングが機能するための土台になります。
Dot Linkは自由文のメールから直接マッチングするのではなく、いったん正規化した案件・人材データを突き合わせて候補を生成する設計です。
候補生成は2段階で、1段目が商流・単価によるhard filter、2段目がスキル等の評価という順で動きます。
1段目で使う商流・単価が、判定済みと「不明」に正しく分かれていてはじめて、絞り込みが誤った前提で走らずに済みます。
つまり「不明」を正直に残すことは、単に確認範囲を絞るだけでなく、マッチングの信頼性そのものを支えています。
見落としを設計で防ぐという考え方
商流・単価の見落としは、注意力ではなく設計で防ぐべき問題です。
商流のように「そもそも書かれていない」情報が多い項目では、無理に推測して埋める運用のほうが、かえって誤判定のリスクを増やします。
判定できるものは正確に、判定できないものは正直にという2つを両立させることで、営業担当の方は不明な一部だけに確認を集中できます。
商流・単価の自動判定を実際の受信メールで確かめたい営業担当の方は、まずはメールを転送して試してみてください。
Dot Linkの全体像や発信方針は、こちらでも紹介しています。
Dot Linkにメールを転送して商流・単価判定を試す
無料登録してメール連携する →よくある質問
商流を「不明」と判定するのはなぜですか
メール本文に商流の記載が見当たらないときに、AIが無理に値を推測せず「不明」としてフラグを立てているためです。
書かれていない商流を勝手に「貴社まで」等と決めつけると、実際には多段階だった案件を誤った条件でマッチングしてしまい、後から信頼問題につながります。
Dot Linkが処理した49,478件のうち65.3%が「不明」区分でした（2026年3月〜7月集計）。
これは抽出の失敗ではなく、根拠が無いことを正直に残す設計です。
人材メールの商流がほとんど判定されないのは問題ですか
問題ではなく、元のメールに商流が書かれていないことの反映です。
商流を具体的に判定できたのは案件側で37.4%、人材側で1.8%でした（2026年3月〜7月集計）。
人材メールはスキルや稼働時期が主役で、商流の条件は書かれないまま届くことがほとんどです。
Dot Linkは書かれていない情報を推測で埋めないため、人材側の判定率が低いこと自体は設計通りの挙動です。
商流が「不明」の案件はどう確認すればよいですか
「不明」とマークされた案件・人材だけを重点的に確認するのが効率的です。
判定済みの案件は自動で条件が揃っているため、営業担当の方が手を入れるべき対象は「不明」の一部に絞られます。
全件を1通ずつ目視で見直す必要がなくなり、確認の労力を本当に必要な案件へ集中できます。
Dot Linkの他の記事は、ブログトップからも読めます。
参照データ算出方法
本記事の数値は、Dot Linkが処理したメール由来の案件・人材情報のうち、マッチングに使える形へ正規化済みのレコード（1レコード＝1件の案件または人材情報。メールから抽出した商流を判定した状態、および案件か人材かの種別を保持するフィールドがある）を集計したものです。
集計期間は2026年3月17日〜7月23日、母数は49,478件です。
商流判定結果の全体集計:
SELECT
COUNT(*) AS total_records, -- 母数（N）
COUNTIF([商流判定状態] = 'determined') AS determined, -- 具体的に判定できた
COUNTIF([商流判定状態] = 'unknown') AS unknown_flagged, -- 「不明」として区分
COUNTIF([商流判定状態] IS NULL) AS not_applicable -- 項目自体が対象外（null）
FROM `[マッチング用正規化テーブル]`
WHERE [正規化日時] BETWEEN '2026-03-17' AND '2026-07-23';
種別ごとの商流判定率（案件JOB / 人材CANDIDATE）:
SELECT
[レコード種別] AS record_type, -- JOB / CANDIDATE
COUNT(*) AS records, -- 種別ごとの母数
COUNTIF([商流判定状態] = 'determined') AS determined -- 具体的に判定できた
FROM `[マッチング用正規化テーブル]`
WHERE [正規化日時] BETWEEN '2026-03-17' AND '2026-07-23'
GROUP BY record_type;
[マッチング用正規化テーブル]・[商流判定状態]・[レコード種別]・[正規化日時] は実際のテーブル名・カラム名のプレースホルダです。
