特徴量という言葉が昔流行しました。2010年代にマシンラーニング（ML）や画像処理の実証実験が流行った頃に、それに併せて広まった言葉だと思います。
LLMが普及した今、これは過ぎ去った文化のように思われるかもしれません。今はいちから画像処理モデルを作ったり、MLモデルを作ったり、そんなことをする必要性が減っている（ような気がする）からです。
しかし実際には、特徴量の重要性は今でも全く失われていません。というよりむしろ、以前より重要度が増しているかのように思えます。
結局、特徴量とは何だったのか
特徴量がなんなのか説明できる人はあまりいないと思います。流行した当時は特に、「AI」と似たような、あいまい語だったからです。
多くの人にとっては「AI（MLモデルなど）に投入するデータ」あるいは、「それをさらにAIがうまく使えるように加工したもの」、という理解ではないでしょうか。
確かにその要素もデータ利活用の世界には存在しており、決して間違いではないのですが、とはいえ特徴量の最も重要なポイントの説明としては不十分です。
特徴量が何かというと、特徴を直接的に、かつ簡潔に表した記述です。問題の特徴を論理表現や量で表現しました、ということになります。
データが大量にあっても、それが必ずしも扱いたい問題の特徴を捉えているわけではない。逆に、ごく少量のデータが的確に特徴を表していることもある。そういうケースを想像すると、特徴量とただの情報の山との違いがわかるのではないでしょうか。
もう少し抽象化すると、特徴量は「解決したい問題を定性・定量的に書いたもの」です。問題の特徴を直接的かつ簡潔に表すために、適切な要素と尺度を選択し、論理記号や量などで表現しています。（数式もここに含まれますが、数式以外でも論理構造を表現できます。）
特徴量がなぜ重要なのか→問題の記述化だから
特徴量の本質は問題の翻訳です。大体以下のようなステップで、「直観的理解→自然言語→論理言語→機械語」というように翻訳が進みます。
- 問題の認識
- 自然言語による記述化
- 論理記号や尺度による定性・定量的な表現による記述化
- モデルの設計・データセットの設計（特徴量設計）
- データの記述や収集・アルゴリズムの記述（特徴量・モデルの実体の獲得）
（少しだけ余談ですが、現行のLLMの本質は、上記の機械語への翻訳のショートカットにあります。自然言語でプログラミングやデータへのアクセスができる「インターフェース」です。詳細は別の記事で書こうと思います。）
問題を抽象化できていると、そこには優れた特徴量が存在します。逆に抽象化ができなければ特徴量は存在できません。
（抽象化については別の記事で細かく説明しているので、そちらも参考にしてください。）
特徴量はないが使えそうなデータはある、という場合もありますが、これはデータのパターンだけがある、という状態です。これは、「見かけの相関」の話や、「相関はあっても因果関係ではなかったので、汎化できなかった（別のケースでは役に立たなかった）」、みたいな話です。
予測モデルは作れたし、収集済みデータによる実験環境では精度が出た。しかし、本番環境では精度が低かったり、結局は問題の解決に寄与しなかったりする。つまり、パターンを再現し反復する仕組みは作ったものの、それが実務の役に立たない、ということが起きます。
特徴量が作れていないということは、問題がわかっていないか、問題を記述化できていない、ということとほとんど同じなのです。
データだけがある状態は、そこにパターンがあれば何かを記述化できていて、パターンの再現と反復は可能です。しかし、問題が記述できているとは限りません。
AI・LLMの時代に特に重要なこと
過去のML開発の時代には、特徴量が設計できないと、そもそもモデル自体がまともに動いているように見えず、何も生まないので使わない、という結末になっていました。
これは損失ではありますが、ある意味適切な中止判断に辿り着いており、追加の損失を食い止めています。
一方でLLMは、より大きな損失を生みやすい構造があります。とりあえずは動いてしまうからです。
LLMは、問題と本質的に関係がなくても、既存の何かのパターンに近づけて、何かもっともらしい成果物を生成することができます。
つまり、問題を抽象化できていなくても、とにかく動くし、成果物を生み出すし、コストを生み出します。これはGIGO（Garbage In, Garbage Out. ゴミがゴミを産む）というデータ利活用の典型的な失敗ケースです。
LLMは、極めて簡単に実装でき、極めて高速で、極めて量産に向いています。抽象化の能力が不足していると、この問題に気づくことができません。組織的にGIGOを繰り返し、コストとゴミの山を生み出してしまいかねません。
今はLLMをはじめ、画像モデルなど、構築済みモデルを簡単に運用できるようになりました。
そのため、汎用モデルを使って、とりあえずたくさんのデータを集めて、学習させて、調整して、精度を上げよう、という発想でプロジェクトが進むことが増えてきています。
しかし、実はこれが単純に成立するとは限らないのが実態です。
ケース1：RAG
例えば、ある専門家の意思決定の再現を目的としたプロジェクトでは、AIプラットフォームに大量のデータを渡してRAGを組んだり、予測モデルを作ったりした結果、ほとんど機能しなかったケースがありました。
これを引き受け、短い2ファイルに意思決定の要点のコアだけを集約し、簡潔なRAGを組むところからプロジェクトを再考したところ、その時点で実用に耐える高い精度になったことがあります。（この後さらにデータを活用して、AIによる自己診断・自己改善によって精度を引き上げています。）
これはちょうど、問題を簡潔に記述化して、特徴量として必要十分なデータやワークフローだけを切り出すことに成功した、ということに当たります。
余談ですが、このときの費用は私の人件費1人分で、AIプラットフォームのコストはLLM-APIのみ、かつ静的運用でよく、初期コストも運用コストも極めて軽量に収まりました。
ケースB：画像分析
また、ある物体の状態を画像から診断するプロジェクトでは、既存の高性能な汎用画像モデルと大量のデータでアプローチしようとしたところ、ほとんど精度が出なかった上に何が悪いのか原因がよくわからない、という事態が起きました。
このケースでは「画像なんだからデータ量があれば必ず解決できる」という信念で、とにかくデータセットを増やそうとしていました。しかし、問題が不明確でありデータセット自体が効果的に設計できないことと、データ収集の手戻りやリソース調達（専門家に対して、大量の単純作業に協力してもらわなければならない）のリスクを考慮して、一旦それを制止し、問題を特徴量として記述化するアプローチに切り替えました。
その結果、解決可能性が判断でき、また、どのようなデータ設計をすればデータ収集が無駄にならず、投資効率を上げることができるのかが把握できました。初期データがなぜ機能しなかったのか、データの欠陥やモデルの性能限界についても大枠が把握できました。
進んで良い方向、進んではいけない方向が事前に把握できた、ということです。これも問題を記述化し、特徴量を設計した恩恵です。
加えて、特徴量を作るということはモデルがあるのとほとんど同義です。特徴量を作った時点で、データを集めなくてもある程度の精度で予測ができる、問題を記述したモデルが手に入っています（事実上の、ゼロショットモデル＝学習不要なモデルです）。
このケースでは、そのモデルを使用して、初期のトレーニングデータの収集もある程度自動化できています。データ収集前の時点で、データ収集に対するROIとその確度が高い状態に持ち込めています。
「とりあえずAIとデータ」を卒業する
ここでの問題を振り返って整理すると、次のような話になります。
- LLMや公開モデルは「問題理解が浅くても動いてしまう」
- そのためGIGOが頻発し、規模が拡大する
- その結果、特徴量の記述能力、つまり、問題記述能力の価値が上がる
特徴量とは、単なるデータ加工ではなく、問題の分析と解釈そのものを意味しています。特徴量設計という言葉はビジネス界で影が薄くなりかけていますが、その重要なプロセスを忘れないでください。
LLMの時代に問題解釈のプロセスを欠いてしまうと、問題の理解の浅さがそのまま、ゴミの量産を引き起こします。
それはAIやデータへの投資が、技術的負債と累積コストにすり替わってしまう、ということを意味します。
作る、動かすことが簡単になった今、問題を記述する能力でより大きな差が生まれるようになりました。その能力を欠くと、成果で劣るだけではなく、大きな損失を生むリスクすらある、ということです。
実はこの問題は根本的には2010年代から変わっていません。2010年代との違いは、言語や画像の解釈をするモデルを個別に作る必要がなくなり、とりあえずすぐに動くものが手に入るようにはなった、という点です。
すぐ動くAIは、問題解決能力があれば恩恵として、なければ落とし穴として、いずれにせよ「ただの掛け算」として働きます。あくまで再現と反復を合理化する「レバレッジ」であり、足し算ではありません。
投資目線では以下のように捉えてください。
- モデルの性能よりも、問題の記述の質が成果を左右する
- データ量よりも、特徴量の設計がROIを左右する
- AIは掛け算であり、マイナスの場合でも倍増する
LLMが普及したことで、モデル開発のエンジニアリングが提供していた「反復の実現」という効用は「誰でもできて当たり前」に近づき、相対的に問題の記述化に重点が移り始めています。それが組織のROIや競合との成果の差に直結するので、問題解決のアプローチそれ自体の妥当性を見極める能力が必要です。
ただシステムが動いていることと、問題を解いていることを区別する能力と、問題から技術までをシームレスに翻訳する能力が、これまで以上に重要になります。投資を預かる立場であればなおさらそうでしょう。
特徴量という言葉は技術用語としては古くなったかもしれません。しかしその本質である「問題を記述する能力」は、むしろLLM時代になって、これまで以上に重要になっています。