AIBR プレミアム
拓海先生、お聞きしたいんですが、最近部下から『Androidのマルウェア対策に機械学習を使おう』と言われて困っています。署名ベースの対策でずっとやってきた私としては、どこから手を付ければよいのか見当がつきません。要するに今の防御はもう限界という理解で合ってますか？
素晴らしい着眼点ですね！確かに従来の署名ベースは未知の変種には弱く、機械学習を使えば振る舞いの“パターン”から検出できる可能性がありますよ。ただし技術選定では『現場で運用できる速さと誤検知の低さ』が鍵になります。大丈夫、一緒に整理しましょう。
具体的にはどんなデータを見て学習させるんですか。現場からは『アプリの中身全部取ってきて学習すればいい』と言われましたが、現実的に時間も金もかかりそうで心配です。
いい質問です。ここで鍵になるのは『特徴量抽出』と『表現の扱い方』です。研究のひとつに、アプリのマニフェスト（manifest）やソースコードから特徴を取り出し、それを数値ベクトルに変換して学習する手法があります。ポイントは3つです。まず、どの情報を使うか。次に、取り出した情報が非常に疎（まばら）で長いベクトルになる点。最後に、特徴同士の相互作用をどうモデル化するかです。大丈夫、一緒に順序立てて説明できますよ。
要するに、データは取れるけれど『長くてスカスカ』になってしまう、と。で、学習させるときにそれらの『組み合わせ』が重要になると。これって要するに、ある特徴同士が揃ったときだけ悪さをするケースを見つけられる、ということですか？
その通りですよ。すばらしい理解です！ただ、従来の方法で特徴の『掛け合わせ』を全部個別に学習しようとするとパラメータが爆発してしまい、しかも観測されない組み合わせが多くて学習できない問題が出ます。ここで紹介する研究は、Factorization Machine（FM：ファクタライゼーションマシン）という考え方を使って、相互作用を効率的に表現しつつ学習を速くしています。説明を3点でまとめますね。1) 長い疎なベクトルを前提にしている、2) 組み合わせを潜在ベクトルで内積として表現する、3) 学習が速いので現場導入の負担が小さい、ですよ。
速いのはありがたいです。現場では『学習に何日もかかる』と現場が尻込みするんですよ。ところで、誤検知が増えると現場の信用を失うので、誤検知率が低いのも重要です。実績面ではどの程度なんですか？
良い指摘です。論文ではDREBINデータセットとAMDデータセットという公開データで評価しています。結果は、ある場合で精度（precision）がほぼ100%に近く、別のデータセットでも高精度かつ誤検知率（false positive rate）が1.1%程度という報告です。加えて、学習が従来法よりかなり高速であるため、頻繁な再学習やモデル更新が現実的になります。つまり運用コストの面でも優位だと言えるのです。
なるほど。最後に現場導入で気を付ける点を一言で言うと何ですか。コストと効果を天秤にかけたいので、判断基準が欲しいです。
要点は3つです。まず、導入目的を『誤検知の許容範囲』『検出したい脅威の種類』『更新頻度』の3点で定義すること。次に、実データでの検証を小さく早く回して、誤検知率や学習時間を実測すること。最後に、モデルの説明性とログ出力を整備して運用者が判定理由を追えるようにすることです。大丈夫、一緒に計画を作れば必ずできますよ。
分かりました。私なりに言い直します。要するに、この論文は『長くてスカスカなアプリの特徴を、組み合わせの価値を失わずに効率良く学習できる手法を示し、実運用の視点でも高速に動くから現場導入のハードルが下がる』ということですね。これなら話が進められそうです。
