特徴量の選び方で予測は変わる｜AIに渡す列を決める

「モデルを新しいものに替えたのに、当たり方がほとんど変わりませんでした」「渡せる列を全部渡したのに、精度が上がりません」。AIで予測を始めた会社から、着手して数か月のうちに届く声です。どちらも真面目に手を動かした結果として出てくるので、余計に行き詰まります。しかしこれは、選んだ道具が悪かったという話ではありません。本当は、モデルを新しくするより、渡す列を変えるほうが結果は大きく動きます。そして列は増やすほど当たるようになるわけではありません。この記事では、予測に渡す列をどう決めるかを、課題・原因・対策の順に整理します。商談になるかどうかの予測と、解約するかどうかの予測という、BtoBでよく持ち上がる2つの例で具体化していきます。

特徴量とは、予測に渡す材料の列のこと

最初に言葉を置き直します。特徴量とは、予測させたい相手に渡す材料の列のことです。表を思い浮かべてください。1行が1社、列に業種、従業員数、年商、直近の接触回数が並んでいる。この表で「商談になったかどうか」を当てにいくとき、当てたい対象が目的の列で、当てるために渡す残りの列が特徴量です。名前に「量」が付いているので数値だけを指すように見えますが、業種のような区分も、資料を見たかどうかのような有無も、すべて列として渡せます。

なぜ選び方で結果が変わるのか。理由は単純で、予測は、渡された列の中にある差しか使えないからです。商談になった会社とならなかった会社を分けている事情が、どの列にも現れていなければ、どんな手法を使っても取り出しようがありません。逆に、その差が列にはっきり出ていれば、単純なやり方でもかなりの精度になります。材料に入っていないものは、調理法を変えても出てきません。

実務の側から見ると、この作業は分析の作業に見えて、実際には別の顔を持っています。列を決めるとは、自社のどの記録を、どの形で、どこまで出すかを決めることです。氏名を含む列を出すのか。取引先から預かった数字を混ぜるのか。営業部門しか見ていない記録を情報システム部門の環境に置くのか。ここが決まらないと、どんなに良い列を思いついても渡せません。だから列の選定は、分析担当が単独で進める工程ではなく、情報システム部門とAI導入担当が最初から関わる工程になります。

課題：モデルを替えても当たり方が変わらない

行き詰まり方には決まった型があります。まず手元にある顧客の表をそのまま渡してみる。当たらない。次に、より新しい手法や、より大きな仕組みを試す。やはり当たらない。そこで「うちのデータでは無理なのではないか」という結論に傾きます。この順序で進むかぎり、何を試しても結果は似たところで止まります。替えているのは処理の側だけで、渡している材料が一度も変わっていないからです。

もう一つの型が、列を足し続ける進み方です。使えそうな列を50から200に増やす。ところが増えた150列の中身が、同じ事柄の言い換えだったとしたら、判断の材料は実質的に増えていません。年商と資本金と従業員数は、どれも会社の規模を別の角度から書いたものです。3つ並べても、規模という1つの手がかりが3回出てくるだけです。

むしろ列を増やすと副作用が出ます。ほとんど空欄の列や、たまたま数字が一致しただけの列が混ざると、手元のデータの細かい癖まで覚え込んだ状態になります。この状態は検証の段階では良い数字が出るのに、新しい相手には外れるという形で表れます。列を足したら数字が良くなった、という手応えほど、あてにならないものはありません。増やすかどうかは、その列が新しい手がかりを持ち込んでいるかどうかで決めます。

原因1：表にそのまま入っている列だけでは差がつかない

ではなぜ、手元の表をそのまま渡すと当たらないのか。多くの場合、その表に入っているのが属性の列だけだからです。業種、従業員数、所在地、資本金、設立年。どれも会社を説明する情報ではありますが、時間が経っても値がほとんど変わらないという共通点があります。そして同じ業種で同じ規模の会社は、名簿の中に何百社と並んでいます。

商談化の予測で、業種と従業員数だけを渡すとどうなるか。出てくるのは「製造業で従業員300人以上の会社は商談になりやすい」といった粗い傾向です。営業担当が日々感じていることとほぼ同じで、新しい情報になりません。予測を入れる目的が、担当の勘を数字で裏付けることではなく、勘では気づけない相手を見つけることだとすれば、この結果は目的に届いていません。

誤解のないように補足すると、属性の列が無意味なわけではありません。効き方が変わるのは、次に述べる履歴の列と組み合わせたときです。同じ「直近30日に5回接触した」でも、従業員5,000人の会社と20人の会社では意味が違います。属性の列は、動きの列の意味を補正する役割で効きます。単独で土台にはならない、という位置づけで扱うのが実務的です。

対策1：効く列は、履歴から作り出す（商談化の予測）

ここからが本題です。結果を動かす列は、たいてい表にそのまま入っていません。履歴を畳んで、こちらで作り出す必要があります。メールの開封記録、資料の閲覧記録、ウェビナーの参加記録は、1社につき何十行も溜まっています。これを1社1行の表に落とし込むとき、どう畳むかを決める作業が、そのまま列を作る作業になります。

商談化の予測で作る列は、たとえば次のようなものです。直近30日の接触回数。初回接触からの経過日数。資料の閲覧が2回以上あったかどうか。閲覧した資料の種類の数。直近14日以内に何らかの動きがあったかどうか。そして同じ会社の中で、何人が接触したか。最後の1つはBtoBに特有の列です。法人の購買は複数の関係者が関わることが多いため、1人が10回見ている状態と、3人がそれぞれ3回見ている状態では、意味が違ってきます。手元のデータで実際に効くかどうかは検証が要りますが、作る価値のある列です。

畳み方を決めるときの落とし穴が、期間の決め方です。直近30日で数えるか、90日で数えるかは、まったく別の列になります。両方を作って比べること自体は正しい進め方ですが、学習で使った期間と、本番で使う期間は必ず揃えます。ある技術文書では、学習では過去10日間の平均を使い、予測を頼むときには直近1か月の平均を使ってしまう、という食い違いが典型例として挙げられています。列の名前が同じでも中身が別物になるため、この種のずれは気づきにくく、本番に出てから精度だけが落ちます。

対策2：解約の予測で効くのは「変化」の列

同じ履歴から作る列でも、解約の予測では作り方の発想が変わります。商談化の予測は「どれだけ動いているか」を見ますが、解約の予測は「以前と比べてどう変わったか」を見ます。今月のログイン回数が100回だったという事実そのものより、3か月前まで300回だったのが100回に落ちた、という変化のほうに兆しが出ます。

実際に作る列としては、直近1か月の利用回数が直前3か月の平均に対して何割か、使われている機能の種類が減っていないか、問い合わせの件数とその内容の種別、契約更新日までの残り日数、担当者が交代したかどうか、といったものが並びます。このうち担当者の交代は、記録が営業部門の側にしか残っていないことが多い列です。利用のログは情報システム部門が持ち、契約と担当者の情報は営業部門が持つ。両方を突き合わせないと作れない列があるという事実が、この工程を部門をまたぐ話にします。

注意点も2つあります。1つは、更新日までの残り日数のような列は、後で述べる時点の扱いを間違えると事故のもとになることです。もう1つは、答えに近すぎる列を混ぜてしまうことです。解約の手続き画面を開いたかどうかは強烈に効きますが、それは予測ではなく事後の確認です。兆しを掴む列と、結果そのものを写した列は、区別して扱います。この区別が次のH2の主題になります。

最大の事故：答えが混ざっている列

実務で最も多く、最も損害が大きい事故がこれです。結果が分かってから埋まる列を、そのまま予測に渡してしまう状態を指します。検証の段階では驚くほど当たるのに、本番に出した途端に外れます。海外の用語解説では、予測すべき対象の情報が列の側に漏れ込んでいる状態として説明され、抗生物質を使ったかどうかという列で感染症を当てにいく例が挙げられています。抗生物質は感染したあとに使うものなので、当たるのは当たり前です。予防策として示されているのは、結果が出た時点でまだ分かっていなかったデータを外す、というただ1点です。

BtoBの現場に置き換えると、混ざりやすい列は次のようなものです。

• 契約金額の欄——商談化の予測に渡すと、金額が入っている会社は既に成約している会社になる
• 受注日・失注理由・失注の分類——いずれも結果が決まってから入力される
• 担当営業の変更日——成約が決まった時点で事務が担当を付け替える運用だと、結果と同時に埋まる
• 解約手続きの受付番号や解約予定日——解約の予測に渡せば、ほとんど答えそのものになる
• 与信審査の結果区分——成約が決まってから審査に回す運用なら、時間の順序が逆になっている
• 最終接触日——成約後にお礼の連絡を入れる運用だと、成約した会社ほど日付が新しくなる
• 顧客の区分（重点顧客・要注意先など）——結果を見た人が後から手で付け替えている場合がある

この事故が厄介なのは、起きているときの見た目が「成功」だからです。精度の数字が跳ね上がるので、良い列を見つけたと受け取られます。社内の報告も通ります。外れていることが分かるのは、実際に運用に乗せて数か月経ってからです。検証の数字が急に良くなったときは、モデルが良くなったのではなく答えが混ざったのだ、と先に疑うのが実務の作法です。特に、1つの列を足しただけで大きく跳ねたときは、ほぼこれです。

混ざりを見つける手順：列ごとに「いつ埋まるか」を書く

答えの混ざりを確実に見つける方法は1つしかありません。列ごとに、その値が実際に埋まる時点を書き出すことです。統計的な検査で当たりを付けることもできますが、最後は業務の手順を知っている人が、いつ入力されるかを言えるかどうかで決まります。手順にすると5段階です。

最後の段が最も手間がかかり、最も抜けます。理由は、多くの業務システムが「今の姿」しか持っていないからです。現在の契約状態、現在の担当者、現在の顧客区分。これらは値が上書きされるので、半年前の時点でどうだったかを復元できません。復元できない列は、正しく検証することもできません。使わないという判断が安全です。

そして、この制約は設計に跳ね返ります。将来どこかで予測を作りたいなら、上書きせずに更新の履歴を残す形にしておく必要があります。過去の時点の姿は、後から作れません。列の設計の話がデータの持ち方の話に接続するのは、この一点によります。予測を検討し始めた段階で、情報システム部門に確認しておく価値があります。

ほかに入れてはいけない列：特定できる列と、本番で取れない列

答えが混ざっている列のほかに、外すべき列が2種類あります。1つ目は個人を特定できる列です。氏名、メールアドレス、電話番号、名刺に書かれている内容。会社を単位にした予測なら、そもそも個人の情報は精度にほとんど寄与しません。それでいて、社外の環境に出すときの制約は最も重くなります。個人データを第三者に提供する場合は、原則としてあらかじめ本人の同意を得なければならない、と個人情報保護法の第27条と第28条に定められています。効かないうえに面倒な列を持ち出す理由はありません。

2つ目は本番では手に入らない列です。検証のために人が手作業で調べて埋めた列が、これに当たります。担当者に聞いて埋めた業種の細かい分類。手で名寄せした親会社と子会社の関係。公開資料を読んで判定した設備投資の意欲。作るときは対象が500社なので人力でも回りますが、毎日新しい問い合わせに対して予測を出す運用になると、同じ手順は回りません。判定は簡単で、その列の値が人の手を介さずに自動で埋まるかだけを見ます。

この2種類と、答えが混ざっている列を合わせた3つを、効くかどうかより先に落とします。順序を逆にして、まず全部の列で試して効く列を見つけてから制約を確認すると、最も効いていた列が出せない列だったと後から分かり、設計をやり直すことになります。実際にこの順序の間違いで数か月を失う例は珍しくありません。制約による絞り込みが先、効果の検証が後です。

ミニ用語解説：会話が噛み合うための7語

ここで、周辺の言葉を短く整理しておきます。社内の会議でも、開発を依頼する場面でも、この7語が読めるかどうかで話の進み方が変わります。定義を暗記する必要はなく、相手が何を指して言っているかが分かれば十分です。

• 目的変数……当てたいもの。商談になったか、解約したか、金額はいくらか。「正解」「ラベル」と呼ばれることもある
• 説明変数……当てるために渡す列。特徴量とほぼ同じ意味で使われる。統計の文脈では説明変数、機械学習の文脈では特徴量と呼ばれやすい
• 前処理……欠けた値をどう扱うか、単位や表記を揃える作業。列を作る前の下ごしらえに当たる
• 重要度……どの列が結果にどれだけ効いたかの目安。あくまで順位であって、なぜ効いたかの理由ではない
• 過学習……手元のデータの細かい癖まで覚え込み、新しい相手には外れる状態。列を増やしすぎたときに起きやすい
• 検証用データ……作るときにあえて使わず取り分けておく分。精度はここで測る。取り分ける前に前処理を全体へ当ててしまうと、この分け方が意味を失う
• 粒度……1行が何を表しているか。1社なのか、1商談なのか、1人なのか

実務でつまずくのは、最後の粒度です。1社1行の表に、1人ごとの情報である「役職」の列をそのまま入れようとすると、誰の役職なのかが決まりません。この場合は、代表して問い合わせた人の役職にするのか、社内で最も上位の人の役職にするのか、それとも部長級が何人接触したかという人数の列にするのかを、先に決める必要があります。粒度がずれた列を混ぜると、表としては作れてしまうのに意味が壊れます。列の名前を決める前に、1行が何かを声に出して確認するのが確実です。

どの列を社外に出してよいか、着手前に仕分ける

ここから体制の話に入ります。列を決める作業には、実際には3者が関わります。記録を持っている情報システム部門、使い道と責任を決めるAI導入担当、業務の意味を知っている現場です。3者が揃わないまま分析担当が列を選ぶと、後から出せない列が混ざっていたことが分かり、やり直しになります。だから仕分けは、モデルを作り始める前に済ませます。

3番目の「加工すれば出せる」の中身を具体化しておきます。粗くする（年齢を年代に、住所を都道府県に、金額を階級に）。置き換える（会社名や氏名を、意味を持たない管理番号に）。まるごと落とす（自由記述の欄）。自由記述の欄は、機械的に外すのが早いという判断で構いません。商談メモや問い合わせ本文には、個人名も取引条件も他社の名前も混ざり得ます。中身を1件ずつ確認して安全な行だけを残す作業は、量が増えると現実的でなくなります。

預かった列と、部門をまたぐ列は、契約と目的で決まる

仕分けの中で判断が難しいのが、この2つです。まず、取引先から預かったデータの列。自社の予測のために使ってよいかは、社内の方針では決まりません。渡した側との契約に書かれていることで決まります。預かったデータを自社の分析に使ってよいと読める条文があるか。目的が限定されていないか。契約が終わった後の扱いはどうなっているか。判断がつかないうちは入れない、が初期設定になります。

社外の環境で学習させる場合は、もう一段の確認が要ります。個人情報保護委員会は令和5年6月2日に生成AIサービスの利用に関する注意喚起を出しており、そこでは、入力した情報を提供者が自らのAIの精度向上のために学習データとして利用する場合、利用者から提供者に対して個人データを提供したことになるという整理が示されています。予測モデルを外部の環境で作る場合も、入力した列が相手側でどう扱われるのかという同じ問いが立ちます。学習に使わない設定になっているか、それをいつ誰が確認したかまで記録しておくと、後から説明できます。

次に、部門をまたぐ列です。利用のログは情報システム部門、商談の記録は営業部門、問い合わせの履歴は支援部門。これらを1つの表に集める行為そのものが、それぞれの部門が本人に伝えている利用目的の範囲に収まっているかどうかを確かめる必要があります。部門ごとに集めたときの目的が違えば、集めて別の目的に使うことが自動的に許されるわけではありません。実務では、どの記録をどの目的で使ってよいかを部門ごとに一度確認し、その結果を残しておく形にします。ここを飛ばすと、動くものはできても、外部から問われたときに答えられません。

列は増やすより、減らすほうが結果につながる

制約による絞り込みが済んだら、次は効果の側の絞り込みです。ここでも方向は同じで、足すより落とすほうが結果につながります。理由は2つあります。似た列が並ぶと、どの列が効いているのかが読めなくなること。そして、列の数が行の数に対して多すぎると、たまたまの一致を拾って覚え込みが起きることです。

落とす候補は、機械的に洗い出せます。ほとんど埋まっていない列（たとえば8割が空欄）。ほぼ1つの値しか入っていない列（99%が同じ区分）。他の列から計算できてしまう列。意味の重なる列。ただし1つ目には例外があり、空欄になる理由が結果と関係している場合は、空欄であること自体を列にします。たとえば予算の欄が空欄の商談は、そもそも予算が決まっていない段階だという情報を持っています。この場合は、値を無理に埋めるより「未記入かどうか」の列を1つ足すほうが素直です。

最終的にどれくらいの数に絞るかは、行の数との釣り合いで決まります。数百社しか実績がない表に数百の列を渡せば、覚え込みが起きやすくなります。行が足りないときに先にやるべきなのは、列を減らすことです。列を増やして粘るより、対象を広げて行を増やすか、当てる対象を粗くする（金額の予測をやめて、大きいか小さいかの2区分にする）ほうが、結果として使えるものになります。

AIに任せてよいことと、人が決めること

列を選ぶ作業そのものを、AIに手伝わせることはできます。ただし任せてよい範囲と、任せてはいけない範囲がはっきり分かれます。任せてよいのは、事実の突き合わせと候補出しで済む次のような作業です。

• 表の定義書から、候補になりそうな列を機械的に書き出す
• 空欄の多い列、値がほぼ1種類しかない列、表記が揺れている列を洗い出す
• 意味が重なっていそうな列の組み合わせを候補として挙げる
• 履歴から作る列の案を並べる。期間違いの候補をまとめて出させる使い方が向いている
• どの列がどれだけ効いたかの順位を出し、上位の列について確認すべき点を列挙させる

一方、次の判断は人がします。いずれも、間違えたときに数字では気づけない種類のものです。

• この列を渡してよいかどうかの可否——契約の条文と社内規程に当てる作業で、一般論では決まらない
• 個人を特定できるかどうかの最終判断——氏名がなくても、複数の列の組み合わせで特定できる場合がある
• 予測時点をいつに置くかの決定——業務の運用を知らないと決められない
• 効いた理由の説明——順位は出せても、なぜ効くのかの理屈は出せない
• 予測の結果を、そのまま行動に変えること——外れたときに誰が責任を持つかが決まっていない

最後の点を補足します。数字の上で効いている列が、実は別の事情の代わりになっているだけ、ということが頻繁に起きます。たとえば「ある資料を閲覧した会社は商談になりやすい」という結果が出たとします。しかしその資料が展示会の会場でしか案内していないものだったなら、効いているのは資料ではなく、展示会で直接会ったという事実のほうです。この読み替えは、その記録がどう作られているかを知っている人にしかできません。重要度の順位は問いの入口であって、答えではありません。上位に出た列については、なぜ効くのかを業務の言葉で説明できるかを必ず確認します。

渡す前の確認表：列ごとに6点を見る

ここまでの内容を、列を1つ渡すたびに使える形にまとめます。候補の列を1つ選んだら、次の6点を上から順に見ます。上の3つで落ちた列は、効くかどうかを調べる前に外します。調べてから外すと、惜しくなって残してしまうためです。

確認する点	見るもの	外れたときの扱い
この値はいつ埋まるか	記録の更新日時と、実際の業務の手順	予測時点より後に埋まるなら外す。迷ったら外す
社外に出してよいか	個人を特定できるか、預かったデータか、部門の利用目的の範囲か	粗くする、番号に置き換える、まるごと落とすのいずれかにする
本番でも同じ経路で取れるか	人の手を介さず自動で埋まるか、取得元が今後も残るか	手作業が必要なら外す。取得元が不安定なら代わりの列を探す
過去の時点の値を復元できるか	上書きされる列か、更新の履歴が残っているか	復元できないなら、正しく検証できないので使わない
欠けている割合と、その理由	空欄の比率。空欄になる会社に偏りがあるか	理由が結果と関係するなら、未記入かどうかの列に置き換える
意味を業務の言葉で説明できるか	その記録が、誰の、どの操作で作られるか	説明できない列は、効いていても運用に乗せない

この表は一度通せば終わりではありません。列を足すたびに、その列だけを通します。実務で事故が起きるのは、最初に丁寧に確認した20列ではなく、後から「これも入れておこう」と足した1列です。足すときこそ手順を省きたくなるので、確認を通していない列は本番の対象に入れない、という運用の縛りをかけておくのが確実です。

外部に発注するときに確認する項目と、列が腐るのを防ぐ運用

最後に、外部の会社に予測の仕組みを作ってもらう場合です。中身が見えないまま受け取ると、数か月後に精度が落ちたときに、何が原因かを誰も説明できなくなります。成果物として受け取るべきなのは、動く仕組みだけでなく、列の一覧とその定義です。次の6項目は、契約前の打ち合わせの段階で聞いておきます。

確認する項目	なぜ聞くか	回答が曖昧なときに起きること
どの列を使ったか（一覧で）	引き継ぎと再現のため	担当者が替わった時点で、誰も直せない仕組みになる
それぞれ、いつ時点の値か	答えの混ざりを防ぐため	検証では当たるのに、本番で外れる。原因の特定に数か月かかる
本番でも同じ経路で取れるか	運用に乗せられるかを見るため	毎回どこかで手作業が必要になり、更新が止まる
作り出した列の定義（期間や条件）	同じ名前の別物に置き換わるのを防ぐため	次に作り直すときに、以前と違う列で比較してしまう
個人を特定できる列を含むか	法令と契約に照らすため	公開や社外提供の段階で作り直しになる
精度をどの期間のデータで測ったか	時期の偏りを見るため	繁忙期だけで測った数字を、通年の期待値だと思い込む

受け取った後の運用も、1つだけ決めておきます。列は放っておくと腐ります。取得の経路が変わる（ツールを入れ替えた、項目名を変えた）。業務の手順が変わる（入力するタイミングを変えたので、埋まる時点が変わった）。どちらも現場では改善として行われるため、予測の側に相談は来ません。業務の手順を変えるときに、列の定義書を見る担当者を決めておくこと。これが最も効く歯止めです。

加えて、四半期に一度、列ごとの空欄の割合と値の散らばりを前の期間と比べる点検を入れます。精度が落ちてから原因を探すのではなく、列の状態が変わった時点で気づくためです。点検で見るのは3つだけで足ります。空欄の割合が急に増えた列。値の分布が明らかにずれた列。そして、まったく値が更新されなくなった列。いずれも、上流の何かが変わった合図です。

まとめ

予測が当たらないとき、まず疑うべきはモデルではなく、渡している列です。手元の表にそのまま入っている属性の列だけでは、同じ業種・同じ規模の会社を分ける手がかりになりません。結果を動かすのは、履歴を畳んで作り出す列です。商談化の予測なら直近30日の接触回数や社内の接触人数、解約の予測なら以前と比べた利用の落ち込み幅。そして作り出せる列は、社内のどの記録が、どんな形で残っているかによって決まります。だから列の選定は、分析担当だけで完結しません。

最も損害の大きい事故は、答えが混ざっている列を渡してしまうことです。結果が分かってから埋まる列を渡すと、検証では驚くほど当たり、本番で外れます。見つける方法は1つで、予測する時点を先に1文で決め、列ごとにその値が埋まる瞬間を書き出し、予測時点より後に埋まる列を外すことです。判定できない列は、実際の記録を開いて更新の日時を目で見る。上書きされて過去の姿を復元できない列は、正しく検証できないので使わない。この手順は統計の知識ではなく、業務の手順を知っているかどうかで決まります。

列を絞る順序も決まっています。効くかどうかより先に、社外に出してよいか、本番でも同じ経路で取れるか、意味を説明できるかで落とします。個人を特定できる列は、会社単位の予測ではほとんど効かないうえに制約が最も重くなります。取引先から預かった列は契約で決まり、部門をまたぐ列は各部門が伝えている利用目的の範囲で決まります。効くと分かってから制約に気づくと、設計そのものをやり直すことになります。

AIに手伝わせてよいのは、候補の書き出し、空欄や表記ゆれの洗い出し、作る列の案の列挙、効いた列の順位付けまでです。渡してよいかの可否、特定できるかどうかの最終判断、予測時点の決定、そして効いた理由の説明は人が持ちます。数字の上で効いている列が別の事情の代わりになっているだけ、ということは頻繁に起こり、それを見抜けるのは記録の作られ方を知っている人だけだからです。まずは候補の列を1枚に書き出し、それぞれ「この値はいつ埋まるか」を1行で書くところから始めてください。この1枚があるかどうかで、半年後に説明できるかどうかが変わります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。