# エンタープライズ向けに ML アルゴリズムをスケールさせる David Landup 注意 この記事は、当社が Treasure Data という社名だったときに TokyoDev に掲載されたものです。元のインタビューはこちらでご覧いただけます：[Scaling ML Algorithms for Enterprise — TokyoDev](https://www.tokyodev.com/companies/treasure-ai/interviews/david-landup) David が、ML とソフトウェアの帽子を被り替える楽しさや、Treasure AI の「広大なエコシステム」をなぜこれほど楽しいと感じるのかを語ります。 本人いわく、Treasure Data のスタッフ機械学習／ソフトウェアエンジニアである [David Landup](https://www.linkedin.com/in/david-landup-859455144/) は、いくつもの帽子を被り分けることが大好きです。フルタイムの役割に加えて、彼は Google のあるチームのパートタイム契約者でもあり、最近ではオープンソースへの貢献により [Google Developer Expert](https://developers.google.com/community/experts) になりました。また、彼が「ミニマリストな日本語リーダー」と表現するテキスト分析・言語学習アプリ [Yomu](https://yomuapp.jp/) も開発しています。 複数の役割を掛け持ちし、専門分野を行き来したいというこの思いこそが、David を Treasure Data へと惹きつけたものでした。「当時、Treasure Data には私が求めていた機会がありました」と彼は説明します。「私はソフトウェアエンジニアとしても、機械学習リサーチエンジニアとしても働いてきました。これらは非常に異なる分野の、まったく違う帽子です。でも同時に、ある面では非常によく似た分野でもあります。その 2 つの帽子を被り替え、チームがそのギャップを埋める手助けをすること……それが私の力の最も良い使い方だと感じたんです、伝わりますかね。」 > エキサイティングで未知の ML 研究があります。そこでは解決策を見つけられるかどうか本当にわかりません。そもそも問題をうまく定式化できているかさえわからない。一方で、安定していて予測可能なソフトウェア開発がある……そこでは良いルーティンに従うことができます。どちらか一方だけをやっていると、予測可能すぎるか、ストレスが溜まりすぎるかのどちらかになると気づいたんです。 ## リーダーシップへの一歩 来日前、David は故郷であるセルビアからリモートエンジニアとして働いていました。2023 年に東京へ移り、伝統的な統計的機械学習モデルと物理的な制約や事前情報を組み合わせる仕事に取り組む機械学習リサーチエンジニアとして雇用された後、現在の Treasure Data でのポジションを引き受けました。それは複数の観点で、まさに彼が探し求めていたものでした。 「私はもっとエンジニアリングのリーダーシップに踏み込みたかったんです」と David は言います。「人を育てられるか、ビジョンやプロセスを定義できるか、チームともっと時間を過ごせるか、そしてより多くの研究をプロダクションに持っていけるかを確かめたかった。私が探していたのは、超大規模ではない、中堅規模の会社で、研究とプロダクションを同時に行っていて、その 2 つを行き来できるような場所でした。[それは]驚くほど稀で、Treasure Data は私が求めていたそのバランスを持つ場所の 1 つだったんです。」 ## Treasure Data がやっていること 「Treasure Data の主眼は、カスタマーデータのための基盤プラットフォームを作ることです」と David は言います。「人々や企業が使うさまざまなサービスやデータベースの間のサイロを打ち破り、それらを 1 つの基盤へと統合するんです。 そして基本的に、その基盤データの上にプロダクトのスイートがあります。それがソフトウェア寄りのものであれ、よく踏み固められた道であれ、あるいは今私たちが実験している ML のようなものであれ、その基盤の上にサービスやプロダクトを差し込むことができます。」 現行のプロダクト（AI Signals）では、Treasure Data は自社の機械学習モデルを訓練して提供しているわけではない、と David は明確にします。彼らがクライアントに提供しているのは、クライアント自身のデータを収集し、その価値を引き出すために必要なインフラ、プラットフォーム、ソリューションです。「私たちは社内でモデルを所有しているわけではなく、その代わりに、訓練と予測のためのエンドツーエンドの機械学習パイプラインを作り、それをカスタマーが自分たちのデータ上で実行しているんです。」 > チームにデータサイエンティストがいれば、そのデータサイエンティストはデータをそのまま扱えます。でも、たとえばマーケターのような、技術的ではないオーディエンスやカスタマー向けには、よりプリビルドな、プラグアンドプレイの体験も提供しています。 ## ML チーム Treasure Data の ML チームは、プロダクトの多くの異なる側面を掛け持ちしています。「モデリングも、ソフトウェアの側面も、インフラの側面も、すべてチーム内で行います。それは実は、私が入社して最初にやったことの 1 つでした。このテックスタックがどう連携するかを[定義すること]です。」 「私が入社したとき」と彼は説明します。「ML は会社の中でまだ比較的新しいものでした。プラットフォームに ML を組み込む最初の試みがあって、それはどちらかというと探索的な[プロジェクト]で、クライアントがそれをどう使ったか、どう使うつもりかを聞いて、具体的な感触を持ってもらいたいというものでした。……私はちょうど、フィードバックの収集をやめて次のフェーズの計画を立て始めた頃に入社したんです。」 > 当時私が担っていた役割は、これらすべてのシステム間の相互作用を描き出し、モデル自体の配布をどう行うか、そして全体の相互作用をどう維持するかについて提案を作ることでした。それが基本的に、私が入社して最初にやったことです。 ## David の最初の大仕事 David が Treasure Data で働き始めたのは 2024 年 11 月だったため、フィードバックを得る時間はあまりありませんでした。「半数の人が PTO（有給休暇）を取る 12 月のスローダウンに入ってしまったんです。自分の仕事をレビューしてくれる人があまりいない。リリースフリーズもありました。……私は実際、その時間を使ってすべてをやったんです。」 「私はアーキテクチャ設計のドキュメント、システム／プロセスの提案をすべて作り、レビューに送り、年末の PTO から人々が戻ってくる前に POC に着手しました。彼らが PTO から戻ってくる頃には、社内でドッグフーディングするための動く MVP がデプロイされていました。」 作業の大半は David 自身が行いましたが、彼はまったくの一人で動いていたわけではありませんでした。「私は SRE の一人、実は以前インタビューを受けた Tyler とも一緒に働く機会があって、社内でのデプロイや配布に関する多くのことのセットアップを手伝ってもらいました。私たちはすでに、実験して試すための社内環境に MVP をオンラインでデプロイしていました。そして社内での見え方に満足したら、徐々にそれをより外向きにしていき、最終的にカスタマーに開放していったんです。」 ## ML アルゴリズムのスケーリング David は最初それをスムーズなプロセスのように語りましたが、後にそうではなかったと強調しました。「Treasure Data 自体がどう動くのか――大きなエコシステムですから――そして業界でこれらの問題がどう扱われているのかを本当に深く掘り下げるために、多くの時間と労力が必要でした。」 > 私たちは、業界ではあまり一般的ではないことを実際にやっていると気づきました。私たちが今『レベル 2 の ML Ops』と呼びたいものをやっているんです。つまり、モデルを成果物として納品するのではない。社内で実行するパイプラインを納品するのですらない。私たちはクライアントのアカウント環境上で、エンドツーエンドのパイプラインの継続的インテグレーションを納品しているんです。これはオンラインでもなかなか情報が見つからないことで、実際にそれをやっている会社はごくわずかだからです。 「それには、私たちがまだ完全には乗り越えようとしている最中の、独自の課題が伴います」と彼は言いました。 その課題の 1 つがスケーリングでした。「ML で使うライブラリは、しばしばあまりスケーラブルではありません。研究の視点から作られているところがあって、たとえプロダクション対応とラベル付けされていても、たいていは通常のほとんどのソフトウェアシステムでは持たないような前提を抱えているんです。 エンタープライズ規模を達成するには、数百万プロファイルの訓練と予測に数時間かかる状態から、数十億プロファイルを 1 日に何度も処理する状態へと移行する必要がありました。これらのライブラリの多くは規模が大きくなると壊れがちで、あるいはスケールさせるのを非常に難しくするアーキテクチャ上の前提やハードリミットを持っています。……これらにパッチを当てるのは時として非常に、非常に難しいんです。なぜなら、それが特定のライブラリの開発の中核的な信条の 1 つである場合、半分をゼロから書き直す必要があるため、そう簡単にはパッチを当てられないからです。それらをうまく回避する良い方法を見つけなければなりません。」 > 最終的には、わずかなコストで約 2 時間のランタイムで数十億プロファイル規模を達成できました。MVP 開発中、RFM のようなソリューションについては、1 分あたり多数のカスタマーリクエストをシミュレートする数百回の実行にわたって、新アーキテクチャを 100 億プロファイル同時処理までストレステストしました。 これらの手動による介入についてさらに詳しく尋ねると、David はすぐに答えを返しました。「一例を挙げると、独自の CUDA カーネルを同梱しているのに CUDA 11 を必須要件としているライブラリがあった一方で、私たちが依存しているハードウェアやイメージは CUDA 12 を同梱していました。さらにそのライブラリは、二次的にスケールするベクトルを int32 表現にエンコードしていて、これが 2^32 個のインデックス（21.4 億）というハードリミットを課していたんですが、訓練中の私たちのベクトルはそれよりはるかに大きな規模まで急増する可能性があり、整数オーバーフローを引き起こしていました。これは CUDA カーネルレベルで行われているので、インストールのために依存関係をどう再コンパイルするかも考えなければなりませんでした。 最終的に私たちがやったのは、CUDA 12 のコンテナを出荷し、元のメソッドを修正版に再割り当てすることでライブラリの内部に動的なパッチを当て、あたかも実際に CUDA 11 上で動いていると『思い込ませる』ようにハックしたんです。実際に動いたことには自分でもちょっと驚いていますが、それらのパッチによって予測にかかる時間が 80% 以上短縮され、私たちの Next-Best-Product ソリューションではプロファイルあたりのコストが 40% 削減されました。」 ## コストの削減 これらの課題を乗り越えながら、David は新プロダクトのコストと複雑さを削減する方法も何とか見つけ出しました。「最初のプロダクトと、私たちが作ろうとしていた新プロダクトの間で、まず以前のプロダクトのインフラを再利用するところから始めました。そこには、主に要件の変更に起因するオーバーヘッドがいくらかありました。」 時間が経つにつれて、彼らはクライアントの要件をより深く理解するようになりました。「だから当時、私たちは物事を作るためのまったく異なる方法を本当に模索していました。移行期間中には、すでに古いものの上に新プロダクトを作り始めていたにもかかわらずです。最初に私がやっていたことの 1 つは、次世代をどう作るかを定義することでしたが、同時に、古いソリューションを新しいインフラと、新アーキテクチャのために私たちが定義した新しいエンジニアリングパラダイムの両方へと移行させることでもありました。だから、そこにも多くの計画がありました。何度も行ったり来たりです。」 > でもそれは最終的に、さまざまなことに使えるかなり汎用的なコンピュートプラットフォームへと成長しました。すべてをゼロから作ったという意味で完全に自前であり、新しい要件が入ってきたときに、より多くのプロダクトをラインに乗せる[柔軟性]を私たちに与えてくれます。 それが明らかに大きな成果を生んだとはいえ、Treasure Data がこれほど早い段階で David にこれほど多くの自由を許したのは注目に値します――少なくとも、David 自身はそう思っています。「当時、[私に]多くの信頼と尊重が寄せられていて、それに本当に感謝していました。正直なところ、なぜ彼らが[私に]あれほど信頼を置いてくれたのかわかりません。入ってきたばかりの人に対して、私だったらもっと懐疑的になると思いますから……でも、本当にとても感謝しています。」 ## David の Treasure Data マップ おそらく、Treasure Data のよく整理されたオンボーディングのプロセスが David の道をスムーズにする助けになったのでしょう。「最初の 2 週間は、基本的にほとんど人と知り合うことです」と彼は言います。「当時は多くの 1on1 がありました。……[マネージャーが]多くの人を紹介してくれて、そうした会話のほとんどで、その人が誰なのか、どこで働いているのか、どんなことで頼ればよいのかを明確にするんです。」 David は Treasure Data のコミュニケーションのスタイルを本当に高く評価しています。「私たちには、人々がただ質問するという文化があります。チャンネルはとてもオープンです。……他の多くの人が質問して答えを得ているのを見ることは、私にとっても間違いなく励みになりました。」 > Treasure Data には強力なサービスオーナーの文化があります。各チームが何かを所有しています。……最初は本当に、組織のこの社内マップを作るような感じで、それぞれのチームから数人の連絡窓口を知っていくことで、彼らに連絡を取りやすくなったんです。 その「社内マップ」を作り上げることは、David が Treasure Data で気に入っている経験の 1 つです。「[会社には]多くの動いている、可動する部品があります」と彼は言います。「かなり広大なエコシステムで働けることは、いつも楽しいと思います。新しいことを学べるし、多くの人と関わることができる。質問をして、新しいコードベースに飛び込むことができるんです。」 > 私たちには非常に経験豊富な人が多く、才能が高度に集中したタレントプールがあります。その中には、私が生きてきたのとほぼ同じくらい長くコーディングをしてきた人たちもいるので、彼らと話し、経験を交換できることは、本当に楽しく、啓発的で、満たされる経験でした。 ## AI ポリシーを形作る 会社の社内 DevAI ユニットのテクニカルアドバイザーとして、David は AI 活用に関する会社のポリシーを形作る手助けをしており、特に AI 生産性ツールとエンジニアリングの交差点を探求しています。「いわゆる『バイブコーディング』の新しい波や、Claude Code をはじめとするコーディングツールの影響については、私たちはほぼ全員が認識していると思います。……これらがさまざまな組織でどう展開したかについては、賛否の分かれる話がいくつもあります。」 > 私たちはそこで一歩先んじようと決め、基本的に[AI 活用]とその影響を追跡し、ガイドラインを作成し、この新たに台頭しつつある分野で十分な経験を持つ少人数のグループを作って、私たちを正しい方向へ導く手助けをするユニットを立ち上げました。……会社内での AI の導入がうまくいかなくなることがないようにするためです。うまくいかなくなる道は数多くあります。 David は自分自身をバイブコーディングの懐疑論者だと言います。「主に、私がこれらのモデルをやや低いレベルで扱っているからです。……そのボトムアップの視点から、私は概して LLM に対して非常に懐疑的でした。それらに多くのユースケースがあることは確かに見えていますし、上品に使える方法も間違いなくあると思います。でも、まったく使いたくない場面もあると思うんです。」 「もちろん、これらのモデルがどう訓練されているか、どう評価されているか、ベンチマークやそれらへの資金提供という明らかに競合する利害といった、全体に覆いかぶさる差し迫った倫理的な問いがあります」と彼は付け加えます。「それはかなり後味の悪さを残しますし、私が最初それらの導入に非常に慎重だった理由の 1 つでもあります。 でも私たちは、AI の活用を通じて、AI の影響を理解し、その約束と危険性を検証し、今後のポリシーを形作ることを可能にする測定可能なフレームワークの中で、不合理な期待を強制したり広めたりすることなく、エンジニアの能力を増強し、新しい分野に取り組む上品な方法を見つけることができたと思います。」 ## Treasure Data が次に採用する人 Treasure Data は現在採用中で、自身も比較的最近の入社者である David は、会社がどのような応募者を求めているかをよく把握しています。「私たちが概して入社を期待している[開発者]は、ビッグデータエンジニアとプロダクトエンジニアです。ここではプロダクトエンジニアリングを多く行っているので、特に……日本のクライアントと働いた経験のある人ですね。」 > 雰囲気はかなり良いと思います。私が所属する研究開発部門の中では、主にエンジニア志向です。物事に取り組む柔軟性が多くあります。特に私たちの持つタレントの集中度を考えると、敬意が空気の中に多くあります。 「私が入ってくるときに、誰かが私を信頼する特別な理由はまったくありませんでした」と David は言います。「特に、ここにいる多くの人は私よりはるかに経験豊富ですからね。でも私は、基本的に初日から多くの信頼と尊重を与えられてきました。……それは単に、私たちがここに持っている文化なんです。」