SMILE (haifengl/smile): JVM で統計から深層学習までを 1 つの依存にまとめる

SMILE が埋めようとしている穴は「JVM で統計と学習を同じ依存に置く」ことにある

Java でデータ分析を書くと、統計処理は Apache Commons Math、前処理は自前のユーティリティ、モデルは別のライブラリ、可視化はさらに別、という具合に依存が散らばりやすい。SMILE はこの散らばりを 1 つのフレームワークに畳もうとしている。README の Features 表には、分類、回帰、クラスタリング、多様体学習、特徴量エンジニアリング、NLP、系列学習、近傍探索、数値計算、可視化が並ぶ。対象読者は、JVM を主戦場にしているエンジニアと、Scala や Kotlin でモデルを組み立てたい人である。README は Scala と Kotlin 向けの idiomatic な API を提供すると明記しており、Java だけを想定したライブラリではない。

base と core の分割、そして Studio という別レイヤー

リポジトリの構造は README の Module Map で説明されている。base/ はデータ構造、数学、線形代数、統計ユーティリティ、I/O を担当し、core/ は分類、回帰、クラスタリング、多様体学習などのアルゴリズム本体を担当する。base 側のドキュメント一覧には DATA_FRAME.md、DATA_IO.md、DISTRIBUTIONS.md、HYPOTHESIS_TESTING.md、WAVELET.md、COMPRESSED_SENSING.md などが並び、core 側には CLASSIFICATION.md、REGRESSION.md、CLUSTERING.md、ANOMALY_DETECTION.md、TIME_SERIES.md、VALIDATION_METRICS.md が並ぶ。つまり「統計だけ使いたい」場合は base を、「学習まで使いたい」場合は core を、という切り分けが文書レベルで用意されている。加えて README は SMILE Studio を agentic IDE として紹介し、Python、Java、Scala から自然言語でデータを操作する入口だと説明する。ここは注意が必要で、Studio はライブラリ本体とは別の成果物であり、studio/README.md に導線が分かれている。ライブラリとして評価するのか、IDE として評価するのかで読むべき文書が変わる。

導入は Maven 座標から始まる。Java のバージョン要求が最初の関門

README はインストール手順を Maven、SBT (Scala)、Gradle (Kotlin)、Native Libraries (BLAS / LAPACK) の 4 つに分けている。Maven Central のバッジは com.github.haifengl/smile-core を指しており、依存を追加する際の座標はこの artifact が起点になる。Maven 以外のビルドツールを使う場合も、SBT と Gradle の節がそれぞれ用意されているので、Scala や Kotlin のプロジェクトでも同じ artifact を引く形になる。見落としやすいのは Java のバージョンで、README は SMILE v5+ が Java 25 を、v4.x が Java 21 を、それ以前が Java 8 を要求すると明記している。Java 25 は長期サポート版ではないため、本番のランタイムを固定している現場では、SMILE の採用がそのまま JDK 更新の意思決定になる。ここは「ライブラリを 1 つ足す」話ではなく「実行環境を上げる」話として扱うべき箇所だ。ネイティブライブラリの節が独立している点も重要で、BLAS/LAPACK をどう供給するかはビルドと配布の設計に影響する。README はこの節の詳細を本文に展開していないため、実際の手順は base や core の README を参照する必要がある。

LLM と可視化まで抱え込む範囲の広さは、そのまま依存の重さになる

Features 表で目を引くのは LLM の行で、LLaMA-3 推論、tiktoken BPE トークナイザ、OpenAI 互換 REST サーバ、SSE によるチャットストリーミングが挙げられている。深層学習は LibTorch/GPU バックエンドと EfficientNet-V2 による画像分類、独自レイヤー API を備える。可視化は Swing のプロット群と宣言的な Vega-Lite チャートの両方が用意されている。ここから読み取れる設計方針は、数値計算の基礎からアプリケーション寄りの機能までを 1 つのリポジトリに集めるというもので、利用者にとっては依存の数を減らせる利点になる。同時に、LLM 推論や GPU バックエンドを使わないプロジェクトにとっては、不要な機能を抱えた大きな依存になる。モジュールが base と core に分かれているとはいえ、core 側のアルゴリズム群は 1 つの artifact にまとまっている。バッチ処理で分類器だけを使いたい場合でも、core を引く形になる。Swing の可視化はサーバサイドのジョブには無関係だが、クラスパスには載る。採用時は「どの機能を使うか」ではなく「使わない機能をどこまで許容するか」を先に決めたほうがよい。

向かないケース: Java 25 に上げられない現場と、Python 前提の案件

最も明確な非該当は、実行環境を Java 21 以下に固定している現場である。v5 系以降は Java 25 を要求するため、v4.x 系に留まるか、SMILE を見送るかの二択になる。v4.x は Java 21 を要求するので、Java 8 や 11 のままだとさらに古い系列まで下げることになり、その分だけ現行のドキュメントやモジュール構成との差が広がる。二つ目の非該当は、Python 側の学習資産をそのまま使いたい案件だ。SMILE は JVM のフレームワークであり、README が示す Python との接点は SMILE Studio という別レイヤーであって、Python から core のアルゴリズムを直接呼ぶ話ではない。三つ目は、深層学習の実験を主目的にする場合である。LibTorch バックエンドと独自レイヤー API は用意されているが、README の記述は機能の列挙に留まり、学習ループの制御や分散学習については触れていない。この領域は README の範囲では判断材料が足りない。

代替としての Tribuo と、設計思想の違い

JVM で機械学習ライブラリを選ぶとき、比較対象になるのは Oracle Labs の Tribuo である。どちらも Java の型付き API を提供し、分類・回帰・クラスタリングを扱う点では重なる。違いは範囲の引き方にある。Tribuo はモデルの学習と評価、そして ONNX 形式での入出力に焦点を絞り、統計分布や仮説検定、ウェーブレット変換、圧縮センシングといった数値計算の基礎部分は自前では持たない。SMILE は逆で、base/ に分布、仮説検定、補間、ウェーブレット、BFGS による数値最適化までを置き、その上に core/ のアルゴリズムを積む。分析の途中で t 検定やカイ二乗検定を回したい、補間やウェーブレットも同じ依存で済ませたい、という用途では SMILE の範囲の広さが効く。モデルの学習と配布だけが目的で、統計処理は別のライブラリで足りているなら、Tribuo のほうがクラスパスに載るものが少なくて済む。どちらが優れているという話ではなく、統計をフレームワークに含めるかどうかという設計判断の差である。

ライセンス表記とメンテナンスの読み方

このリポジトリのライセンスは NOASSERTION と表示されており、GitHub が既知のライセンス条項として認識できていない状態を示す。README の目次には License の節があるが、提示された本文には条項の中身が含まれていない。Apache-2.0 や MIT のような一般的な表記であれば通常は認識されるため、独自条項か、複数条項の組み合わせか、あるいは表記の形式が原因である可能性がある。いずれにせよ、これは推測の域を出ない。導入を決める前に、リポジトリ直下のライセンスファイルと README の License 節を直接確認し、社内の法務判断を通す必要がある。ここで法的な助言はできない。メンテナンスの面では、最近のリリースが v6.3.0、v6.2.5、v6.2.4 と短期間で並んでおり、活発に更新されていることが読み取れる。ただしパッチ版が数週間間隔で出ているという事実は、裏を返せばバージョンを固定して運用するほうが安全だということも意味する。アップグレードコストを見積もる際は、Java の要求バージョンが系列ごとに変わる点を織り込んでおきたい。v4.x から v6 系へ上げる作業は、API の変更だけでなく JDK の更新を含む。

導入前に確認する 3 つの具体的な手順

第一に、必要なモジュールを決める。統計と DataFrame だけで足りるなら base/README.md を、学習まで必要なら core/README.md を先に読む。README の Module Map は各モジュールの README へリンクしているので、ここから辿るのが最短である。第二に、BLAS/LAPACK の供給方法を決める。README は Native Libraries の節を独立させているが、提示された本文には具体的な設定が含まれていないため、実際の手順はモジュール側のドキュメントで確認する必要がある。第三に、ライセンス条項を確認する。NOASSERTION という表示は、自動判定が効いていないという事実だけを示している。判断の順序としては、JDK の要件を満たせるかを最初に確認し、次にライセンス、最後にモジュールの取捨選択という流れが現実的である。JDK を上げられない時点で他の検討は不要になるからだ。

編集部の結論

JVM 上で分類・回帰・クラスタリングから DataFrame、仮説検定、可視化までを 1 つの依存に寄せたいチーム、とくに Scala や Kotlin から同じ API 面を呼びたい場合は検討対象になる。逆に Java 25 へ上げられない現場、Python 側の学習資産をそのまま使いたい案件には向かない。導入前に確認すべきは 3 点で、第一に base と core のどちらが必要か、第二に BLAS/LAPACK をネイティブで入れるか pure JVM で妥協するか、第三にリポジトリが NOASSERTION と表示しているライセンス条項の実体である。

公式情報源

1. haifengl/smile on GitHub
2. Issues
3. Project website
4. README
5. Releases