データサイエンティストのツールとテックスタック：2026年版の正直なビルドガイド

ほとんどのデータサイエンスチームが実際に持っているスタックを説明させてください。8桁のARRを持つ企業でも同じです。

誰かのラップトップ上のJupyterノートブック。customers_FINAL_v3_use_this.csvという名前のS3上のCSV。3四半期前にSlackでバックエンドエンジニアにメールで送られたmodel.pkl。結合がサイレントに変わり続けるため誰も信頼しないLookerダッシュボード。データ部門の前責任者が辞める前日に最後に編集された「ML Architecture」というタイトルのConfluenceページ。

これがあなたのスタックなら、遅れているわけではありません。ほとんどのチームはここにいます。正直な問いは、あなたのセットアップが恥ずかしいかどうかではありません。ここに留まるか、抜け出すための退屈な作業をするかどうかです。

このガイドは、ゼロからスタックを構築するか、引き継いだ寄せ集めを監査する必要がある、ICデータサイエンティスト（VP向けでも、プラットフォームチーム向けでもない）のためのものです。Core 6の各レイヤーを歩き、オープンソースのデフォルト、有料アップグレードを名指しし、それぞれがいつ価値があるかを率直に述べます。このロールの採用をきちんと行いたい場合は、データサイエンティスト職務記述書テンプレートがコンパニオンです。

なぜ今これが重要なのか

ノートブック内のモデルはお金を生みません。「AUC 0.87でモデルを学習した」から「ビジネスが毎日この予測を使って意思決定をしている」までのギャップは、おおよそ80%がツールで20%がサイエンスです。統計学の博士号に3年費やしたデータサイエンティストは特にそれを聞きたくありませんが、事実です。

倉庫から監視まで完全なスタックを立ち上げられるデータサイエンティストが、昇進し、ヘッドカウントを取り、予算を取り、SQLを実行するコストセンターとして扱われなくなります。できない人がノートブックをリリースし続け、なぜ次のレイオフに自分の名前があるか疑問に思います。

MLOpsを好きにならなくても構いません。ただし、それについて話せる必要があります。

Core 6：すべてのMLスタックが実際に必要なもの

6つのレイヤー。実際の価格。それぞれがいつ価値があるか。

それぞれを見ていきましょう。テーブルはチートシートであり、議論ではないので。

データウェアハウス / データレイヤー

Snowflake、BigQuery、またはDatabricks SQL。データエンジニアリングチームが既に支払っているものを選んでください。データエンジニアリングチームがなく一から選ぶなら、BigQueryが最も安く始められます（クエリ課金で$6.25/スキャンTB、アイドル倉庫コストなし）。Snowflakeは非技術アナリストとの共有が最も簡単です。

毎週目にする間違い：DSチームが「コスト節約」のためにウェアハウスレイヤーなしでS3上の生Parquetに直接モデルを学習しようとすること。すべてのジョブが200GBを再読み込みし、pandasでスキーマを書き直します。それはコスト節約ではありません。DSの時間を燃やしており、それはウェアハウスのクレジットより10倍コストがかかります。ウェアハウスを購入してください。dbtを使ってその中で変換してください。整理されたテーブルで学習してください。

ノートブック / IDE

Jupyterは無料、ローカル、個人作業には問題ありません。3人以上のチームでは、協働ノートブック（Hexで$40〜$80/ユーザー/月、Deepnoteはやや安い）はSQL、Python、公開可能な成果物を1つのキャンバスに置くため本当に活躍します。ステークホルダーはHexのドキュメントを読めます。analysis_v7_final.ipynbは読めません。

Databricks NotebooksはDatabricksのコンピュートにバンドルされています。既にコンピュートに支払っているなら、ノートブックは問題ありません。支払っていなければ、本質的にはホスト済みJupyterに対してDatabricksのプラットフォーム価格を払っており、その計算は合いません。

過小評価されているオプション：VS CodeにJupyter拡張機能。無料、高速、本物のGit、デバッガー、拡張機能があります。尊敬するシニアデータサイエンティストのほとんどは本格的な作業にこれを使い、探索とステークホルダー共有にはホスト済みノートブックを使います。

実験管理

ほとんどのチームが決定せずに3つのツールを持っているレイヤーです。1つを選んでください。

MLflowはオープンソースで、月約$50のVMで自己ホスト可能です。トラッキングUIは問題ありません。モデルレジストリは機能的です。セットアップに1エンジニアリング日、保守に四半期あたり数時間かかります。

Weights & Biasesはカテゴリで最も美しいUIで、ステークホルダーと最も共有しやすく、週20回以上の実験を実行する場合や、チームが比較ツールを本当に使う場合には支払う価値があります（ティアによって$20〜$100/ユーザー/月）。2人で四半期に3回実験するなら、MLflowで十分でW&Bは過剰です。

Neptune.aiはほぼ同じ機能を持つより安いW&Bの代替です。W&Bの価格が怖いなら見る価値があります。

何を選んでも、他を廃止してください。最悪の実験管理スタックは、AliceがW&Bを使い、BobがMLflowを使い、新入社員が前の職場で使っていたからTensorBoardを開く状態です。

フィーチャーストア

Feastはオープンソースで、ドルは無料です。時間は無料ではありません。Redis（または他のオンラインストア）をホストし、レジストリをセットアップし、マテリアライゼーションジョブを書き、すべてを動かし続ける必要があります。本番に3つのモデルを持つ2人のチームにとって、Feastは理論的なインフラであり、よく整理されたdbtプロジェクトが保守の10分の1でやれます。

TectonはエンタープライズPaidオプションです。スタート価格は6桁です。チーム横断の実際の特徴量再利用を持つ50以上の本番モデルがある場合にのみ正当化できます。2人のチームがTectonを購入することは、この分野での資本配分の失敗として最も大きな声でシグナルを出しています。

Databricks Feature StoreはDatabricksを既に使っているならバンドルされています。使っているなら活用してください。それを取得するためにプラットフォームを切り替えないでください。

率直な見解：本番10モデル以下のほとんどのチームはまだフィーチャーストアが必要ありません。dbt内のクリーンな特徴量パイプラインと命名規則が必要です。5つの学習ジョブにわたって特徴量を重複させる痛みがFeastを立ち上げる痛みより大きくなるまで、フィーチャーストアレイヤーをスキップしてください。

モデルサービング

サービングレイヤーはほとんどのスタックで過剰エンジニアリングされています。4つの実際のオプションがあります。

SageMakerはAWSネイティブで複雑であり、インスタンスによって1エンドポイントあたり$0.05〜$2/時で実行されます。AWS を大量に使用していて、エンドポイントを管理するプラットフォームエンジニアがいる場合の正しい答えです。HTTPエンドポイントの裏にモデルが欲しいだけの2人のDSチームには間違った答えです。

Vertex AIはGCPの相当品です。同様の価格、同様の複雑さ、同様の注意点があります。

ModalはサーバーレスGPUです。コンピュートの秒単位で課金されます。スパイクな推論（低トラフィックサイトでのレコメンデーション、バッチスコアリングジョブ、アイドルのエンドポイントに支払いたくないもの）に優れています。デベロッパーエクスペリエンスはカテゴリで最高です。インディペンデントおよびスモールチームのセットアップには私のデフォルト推奨です。

BentoMLはオープンソースのフレームワークです。推論ロジックを書き、BentoMLがパッケージ化し、Kubernetes（またはModal、Lambda、どこでも）にパッケージをデプロイします。Modalと組み合わせてスタートアップ価格でサーバーレスGPUスタックが完成します。

ModalとBentoMLの組み合わせは、プラットフォームチームなしでゼロからDSチームを始める場合に今日構築するものです。SageMakerはプラットフォームチームがあり、既にAWSクレジットを含む調達契約がある場合にコミットするものです。

監視とドリフト検出

本番にモデルがあって監視がなければ、本番にモデルがありません。AUCでスコア化された時限爆弾があります。

EvidentlyはPythonライブラリまたはスタンドアローンサービスとして実行できるオープンソースです。正しい出発点です。ノートブックに組み込んで午後には基本的なドリフトレポートを実行できます。

WhyLabsには無料ティアがあり、スケールアップできます。Arizeの予算なしでホスト済みダッシュボードが欲しい場合の良い選択です。

Arizeは本格的なPaidオプションで、本番ボリュームで$1k〜$10k/月です。本番に5以上のモデルがあるか、規制要件（金融サービス、医療、監査役がいるもの）がある場合に支払う価値があります。

まずEvidentlyを無料で始めてください。本番のモデル数またはコンプライアンスの圧力が正当化するときにアップグレードしてください。監視が必要なモデルを持つ前にArizeを購入しないでください。

信頼できる唯一の情報源の問題（ほとんどのDSスタックが腐る場所）

ゴミのラベルが入ればゴミのモデルが出ます。既に知っています。内面化していないのは、ほとんどのラベルのゴミがどこから来るかです：運用上の情報源。CRM。3つの異なるPMが2回の組織再編にわたって3通りの方法でセットアップした製品分析。

「顧客が解約した」ラベルが、セールス担当者AがディールをClosed Lost - No Decisionとマーク、担当者BがLost - Competitorとマーク、担当者CがディールをただDeleteするCRMから来るなら、MLflowのトラッキングでは救えません。解約モデルは顧客の行動ではなく、担当者の一貫性のないデータ衛生を学習しています。

クリーンな運用情報源はファンシーなフィーチャーストアより重要です。派手ではありません。カンファレンストークを取りません。しかし、CRMのパイプラインステージ定義を修正して必須フィールドのバリデーションを強制することに1週間費やすデータサイエンティストは、3回フィーチャーストアを切り替えるデータサイエンティストより次の2年間で優れたモデルをリリースします。

Rework CRM $12/ユーザー/月は、構造化されたパイプラインステージ、バリデーション付きカスタムフィールド、倉庫にストリーミングできるイベントログ、解約モデルとコンバージョンモデルが依存する顧客ライフサイクルの信頼できる唯一の情報源を提供します。どのCRMを使っても、原則は同じです：上流のデータ品質が下流のモデル品質を決めます。別のハイパーパラメータを調整する前に修正してください。

Build vs. buy：実際の意思決定ツリー

以下がマトリックスです。自分の行を見つけ、それに応じて構築してください。レベルをスキップしないでください。

レベルをスキップしないでください。私が見る2つの最も一般的なスタックミスは順に：

1. カンファレンストークを見た誰かがTectonを購入した2人のチーム。
2. 「まだMLOpsは不要」という理由で単一の創業者のラップトップですべてを実行する8人のチーム。

どちらも悪いです。1つ目は見返りなしの過剰投資。2つ目は毎週生産性と信頼性を失う過少投資です。

30日間のスタック監査

具体的に、週単位で。引き継いだ混乱でも自分で構築したものでも実行してください。

1〜3日目：実際にデプロイされているものを棚卸し

アーキテクチャスライドにあるものではありません。実際に動いているものです。すべてのcron、すべてのAirflow DAG、すべてのSageMakerエンドポイント、スケジュール上のすべてのノートブックを開いてください。スプレッドシートを作ってください。列：ツール、オーナー、月次コスト、使用率、最終操作日、Kill/Keep/Upgradeの判定。

存在を知らなかったものを少なくとも3つ見つけるでしょう。

4〜7日目：本番のすべてのモデルを見つける

各モデルについて：誰がオーナーか、何のデータで学習するか、最後に再学習したのはいつか、現在のパフォーマンス指標は何か、それが止まっても誰かが気づくか。

誰も気づかなければ、廃止してください。誰もオーナーでなければ、それを割り当てる問題があなたのものです。

8〜14日目：最も監視が不十分なモデルに監視を追加

最高のビジネスインパクトと最悪の監視を持つモデルを選んでください。今週Evidentlyを追加してください。きれいでなくても構いません。週次のドリフトレポートをチャンネルにメールするだけで十分な出発点です。

15〜21日目：実験管理を統合

1つのツールを選んでください。アクティブな実験を移行してください。他を使うのをやめるようチームに伝えてください。残りをアーカイブしてください。廃止するツールをセットアップした人が個人的に受け取るため、これは聞こえるより政治的に難しいでしょう。それでも行ってください。

22〜30日目：スタックを1つのREADMEにドキュメント化

チームリポジトリの1つのREADME。アーキテクチャ図（ボックスと矢印、Visioの傑作でなくて良い）。各ツールの目的、オーナー、ログイン。本番の各モデルのオンコールの手順。次のデータサイエンティスト採用者が1時間で読んで引き継ぐものを理解できるべきです。

30日後、1つの文章で答えられます：本番のすべてのモデル、オーナー、最後に再学習した日、現在のドリフト状況、明日廃止するツール。答えられなければ、監査は完了していません。

よくある落とし穴

おおよそ見た頻度順です。

• 本番にモデルがある前にツールを購入する。 「フィーチャーストアが必要だ」。本当に？ 特徴量はある？ それを使うモデルはある？ まだ構築していない未来のためにインフラを購入しないでください。
• 保守時間を予算に含めずMLflowを自己ホストする。 ドルは無料。時間は無料ではありません。VMのパッチ適用、データベースのバックアップ、認証を維持する誰かが必要です。その誰かがモデルもリリースする必要があるなら、管理オプションの方が計算が合うかもしれません。
• 各DSに自分のツールを選ばせる。 「前の職場で使っていたものを使う」が、3つの実験管理ツール、2つのフィーチャーストア、40ページのオンボーディングドキュメントに至る方法です。
• 3つのモデルが正当化する前に「プラットフォーム」を構築する。 1人のプラットフォームチームの罠。汎化する具体的なものができる前に汎化しないでください。
• 「MLではない」という理由でCRMと運用データレイヤーを無視する。 それはラベルが本物かどうかを決めるレイヤーです。MLの隣人ではなく、MLの基盤です。

構築する価値のあるテンプレート

チームリポジトリに保管する4つの成果物です。

1. スタック監査スプレッドシート。 ツール、月次コスト、オーナー、使用率、最終操作日、Kill/Keep/Upgradeの決定。
2. 「実際に本番にあるもの」の棚卸し。 モデル、オーナー、学習データソース、最後の再学習、監視状況、ビジネスインパクト、オンコールの手順。
3. Build vs. buyの意思決定マトリックス。 この記事のテーブルをチームの具体的なスタック向けにカスタマイズしたもの。
4. 最小限の実用的なスタックリポジトリ構造。 MLflow + BentoML + Evidentlyを組み合わせた動くサンプル。次のデータサイエンティスト採用者が最初の週にモデルをリリースするためにクローンできるもの。

結論

MLスタックで最も難しいのはMLではありません。退屈な上流レイヤー（クリーンなラベル、クリーンなイベント、信頼できる唯一の情報源）と退屈な下流レイヤー（実際に見ている監視）です。中間部分（どのモデル、どのフィーチャーストア、どのサービングフレームワーク）が最も注目を集め、最も重要度が低いです。

ツールは重要です。スタックの規律の方が重要です。30日間の監査を実行し、2つの重複したツールを廃止し、READMEを書くデータサイエンティストは、5つの勾配ブースティングライブラリをベンチマークするデータサイエンティストより価値があります。

このロールの採用をしているなら、データサイエンティスト職務記述書テンプレートで責任とそのハードルが概説されています。既にロールに就いていて、スタックがこのガイドの冒頭のようであれば、月曜日に監査を始めてください。

関連ガイド

• データサイエンティストの一日
• データサイエンティストとしての最初の30/60/90日
• モデルを壊さずに本番へ移行する
• DSメトリクス：リリース済みモデル、ビジネスインパクト、モデルの劣化
• データサイエンティスト職務記述書テンプレート