この記事は、当社が Treasure Data という社名だったときに TokyoDev に掲載されたものです。元のインタビューはこちらでご覧いただけます："The Engineering Culture is Unmatched" at Treasure AI — TokyoDev
スタッフソフトウェアエンジニアの Carlo が、Treasure AI の最新の AI への取り組みが、会社と自身のキャリアの双方にこれまでにない機会をもたらしている様子を語ります。
Carlo Luis Espinosa は Treasure Data のスタッフソフトウェアエンジニアで、4 年以上にわたって同社で働いています。
なぜ私がここに残り続けているのか。それは、私の考えでは、エンジニアリングカルチャーが比類なきものだからです。
「成長している今でも」と Carlo は言います。「みんな本当に何かを作りたいと思っているんです。クールなものをね。AI へとシフトしている今も、それは変わっていません。」
入社当初はプラットフォーム API チームに採用されましたが、2 年前、会社は LLM がプラットフォームとどう連携できるかを探るための小さな AI チームを立ち上げました。
その小さなチームで取り組んでいたんです……たぶん 5 人未満の開発者で。私たちは本当に良いプロダクトを作り、それはカスタマーに好評を博し、コアプロダクトの 1 つになりました。だからこそ、今チームを拡大しているわけです。
「だから私がこのインタビューを受けているんだと思いますよ！」と彼は笑いました。
「David と Tyler の以前のインタビューでご存じかもしれませんが」と Carlo は言います。「Treasure Data は基本的にカスタマーデータプラットフォーム（CDP）です。……私たちはさまざまな企業のデータを 1 つの統合されたプラットフォームにまとめ、そのプラットフォーム上で、カスタマーが自分たちのユースケースに合わせてデータをより深く理解できるよう支援するプロダクトを提供しています。」
今、Treasure Data は AI をプロダクトやプラットフォームに取り入れる新しい方法を見出しています。これによりエンジニアやアカウントマネージャーの技術的な負担が軽減されるだけでなく、カスタマー自身がデータをより簡単に解釈できるようになります。
「私の意見では」と彼は続けます。「Treasure Data のプラットフォームは非常に強力ですが、学習曲線が本当に急なんです。たとえば、データを最大限に活用するには SQL に本当に習熟している必要があったりしますよね。
AI を使えば、それが少し簡単になります。たとえば、フロンティアモデルは SQL が本当に得意です。……何百ものテーブルや複数のカスタマーデータベースをもとにシンプルなチャートを生成することは、AI にとってはより簡単なはずです。
これはとても単純なユースケースですが、もっと複雑にすることもできますし、これは本当にクオリティ・オブ・ライフを向上させると言えます。Treasure Data にとっても、カスタマーとやり取りするチームにとっても、そしてカスタマー自身にとってもです。」
「フロンティア」AI モデル、つまり最も広いスケールと最も先進的な能力で既知の限界を押し広げる AI モデルの能力を Treasure Data のプラットフォームに統合することは、会社に多大なメリットをもたらしました。しかし、会社そのものが AI に依存しているわけではありません。
「それが私たちの AI ソリューションの強みの 1 つです」と Carlo は説明します。「今は AI の波が来ていて、みんなその波に乗りたがっています。でも、私たちの会社には物語があります。私たちは AI のためだけに AI をやったわけではないんです。」
彼は、医療履歴やデータを AI と統合することに注力していたヘルスケア業界の一部の AI スタートアップと Treasure Data を対比しました。それらのスタートアップは、OpenAI for Healthcare のローンチによって突如として足元をすくわれました。
最大の違いは、他の会社、たとえば本当に大きなテック企業はたくさんのエンジニアを抱えていて AI に全振りしますが、その裏にあるデータを持っていないということだと思います。私たちはその逆です。データを持っているからこそ、どの AI の道を進むかを慎重に投資できるんです。
「私たちには自社プロダクトがあり、AI ソリューションがそれを補強しているので、良いポジションにいると思います。」
彼のチームは現在、Treasure Data の AI スイートに取り組んでいます。「シンプルな例を挙げると」と Carlo は言います。「私たちは、ユーザーがフロンティア AI モデルを使って自分自身の AI エージェントをカスタマイズできるプラットフォームを提供しています。」
Treasure Data には実際にはいくつかの AI チームがあります。「でも私のチーム、AI エンジニアリングについては、より多くプラットフォーム、つまりバックエンドシステムに注力しています。」
OpenAI も Claude も、それぞれ独自のデータの整形方法や API の呼び出し方を持っています。基本的に私たちのシステムはそれらすべてをラップしているので、どのモデルでもプラグアンドプレイで使えるんです。
「さらに」と Carlo は付け加えます。「それらの LLM を、Treasure Data エコシステム内の Treasure Data マイクロサービスへとつないでいます。」
チームメンバーは、機能開発と研究開発（R&D）の両方に取り組む機会があります。「特に生成 AI の分野は絶えず変化しているので、良いバランスを取ろうとしています」と Carlo は言います。「すでに承認された機能については、プロダクト化して運用を行います。でも、R&D に取り組むことを選ぶこともできます。」
イノベーター対オペレーターと言う人もいるでしょう。イノベーションの部分が本当に好きな人もいますが、その人たちはスケールさせることや、プロダクトとして仕上げることにはあまり注力しません。彼らの主な関心は『これは動くのか？』ということなんです。
「私自身は、物事をスケールさせたいタイプです」と Carlo は言います。「でも同時に、R&D に取り組むこともあります。」
チームメンバーはいつでも機能開発と R&D を簡単に行き来できますが、メンバーがスプリントごとに頻繁に切り替えることはめったにないと Carlo は指摘します。むしろ通常は、どちらか一方により長い期間コミットします。
「ペースが速いですよね？」と Carlo は、彼のチームが直面する AI 特有の課題について尋ねられたときに言いました。「それは良くもあり悪くもあります。たとえば、通常のソフトウェア開発ライフサイクルでは、プロダクトがあり、要件があり、ソフトウェア開発チームがそれをコーディングしてリリースします。」
でも AI の領域では、すごく速いんです。3 か月ごとに何かが変わると思います。5 か月前に作ったものが、もう時代遅れになっているかもしれない。ベストプラクティスが今では違うものになっているかもしれないんです。
「だから、その部分は追加のオーバーヘッドだと言えます。なぜなら、AI プラットフォームに機能を追加するだけでなく、その R&D のレイヤーもあるからです。仮説を立てる必要があります。これが本当に正しい道なのかを確認するために POC を作らなければなりません。……もちろん、その先のロードマップについても考える必要がありますよね。これは将来にわたって通用するのか、と。
その追加のレイヤーは本当にエキサイティングでチャレンジングだと感じています」と彼は締めくくります。「だって、もしかしたら 5 か月後には LLM がもう主流ではなくなっているかもしれない。新しいテクノロジーが出てくるかもしれないんですから。」
Carlo は一例を挙げました。「初期の頃の主流は RAG、つまり検索拡張生成でした。たとえば、自分たちのデータがあって、そのデータのスナップショットを取り、ベクトル化してインデックスを作る。2020 年代初頭は、それが主流だったんです。
でも LLM が進化するにつれて、今では本当に複雑な SQL を生成できるようになりました。だからもうデータをスナップショットしてベクトル化する必要はないんです。なぜなら LLM がデータを直接クエリできて、しかも良いコードだからです。」
これは AI を扱う上でのもう 1 つの課題、つまり「いつ AI が必要なのか」を見極めることにつながります。たとえば、Treasure Data のカスタマーは、AI エージェントに同じ質問を繰り返したときに、なぜエージェントが結果やインサイトを異なる形で表示するのかを知りたがることがあります。「だから私たちやプロダクトチームは」と Carlo は言います。「彼らに、それが LLM の仕組みなんですと伝える必要があります。すべて確率的なんです。同じ結果が得られるプログラミングとは違うんですよ。」
一度きりのレポートが欲しいのであれば、AI を使うのは理にかなっていると Carlo は指摘します。しかし、一貫した情報のダッシュボードが欲しい場合、LLM を使うと毎回同じ見た目にはなりません。「ダッシュボードが欲しいなら、従来のやり方でダッシュボードを作るべきです。」
「それについて（カスタマーと）より多く話すのは、たいてい別のチームです」と Carlo は補足します。彼のバックエンドチームは主に社内からのリクエストを扱います。「でも、ときどき（同僚に）念を押さなければならないこともあります。なぜなら、ソリューションについての提案を受けることがあるからです。」そして、それらの提案のすべてが、AI の能力や限界を十分に理解した上でのものとは限りません。
それを言うのはエンジニアの役目だと感じています。『それは良い AI ソリューションではないと思います』とか『それは AI が向いているソリューションです』とはっきり伝える必要があるんです。
最後に、彼らは LLM がハルシネーションを起こす傾向に対して慎重な対策を講じています。「プロンプトにガードレールを設ける必要があります。私たちのプロンプトエンジニアは、『ハルシネーションを起こすな。手元にあるデータで作業しろ』というガードレールをしっかり設定しています。それでもこれは課題です。なぜなら、たとえば不完全なデータを受け取ると、彼ら（LLM）は物事をでっち上げてしまうからです。
だからこれは継続的な課題です。それを修正する方法は複数あります。……でも今のところは、すべてガードレールです。」
「Treasure Data のコアな強みの 1 つは」と Carlo は言います。「エンジニアリングが本当に優れていることだと思います。私の意見では、最高だと見ています。」
そしてその理由の 1 つは、個人として貢献するメンバー（IC：Individual Contributor）が高く評価されていることだと彼は感じています。「ここ数年は、本当に IC 中心だったと言えます。」
「マネジメントはちゃんとあります」と彼は明確にします。「私の個人的な哲学では、マネジメントが一切ないというのは不可能です。IC であっても少しはあります。たとえば QA や他のチームとスケジュールを調整する必要がありますからね。」
Carlo はそれをよく知っています。彼は楽天でエンジニアリングマネージャーおよびテックリードとして働いていました。今、Treasure Data で、Carlo は新しいマネジメントの役割と、自身が情熱を注ぐ AI の仕事とのバランスを取っています。「私はマネージャーたちに『ピープルマネジメントで燃え尽きたくない』と言いました。実際にそう言ったんです。『本当にいいんですか？ 私はマネージャーよりも IC としての方が価値があると感じるかもしれません』と。」
今や AI はどこにでもあります。テクノロジーの歴史の中で、こんな時期は本当に数えるほどしかないと感じています。この時代にコーダーやアーキテクトとして手を動かさないのは、もったいないことです。
「でも彼らはこう言ったんです。『70 対 30 でいいよ。それでもまだやりたいなら、基本的には自由度が増すということで、自分の自由な時間で何をするか選べる。もっとアーキテクチャや R&D をやりたいなら、いいじゃないか、ぜひやってくれ。チームがうまく回っている限り、それができるよ』と。」
彼の柔軟な働き方が可能なのは、Treasure Data の組織図が非常にフラットだからです。「Treasure Data では EM（エンジニアリングマネージャー）と IC のキャリアパスは本当に並行していると感じます」と彼は言います。
スタッフとエンジニアリングマネージャーの役割は、同じバンドにあるので簡単に行き来できます。これは昇進的なジャンプではなく、並行的なジャンプだと言えます。
Carlo が指摘するように、彼はほとんど前例のない技術革新の時代に働いています。AI は彼のキャリアを形作っただけでなく、会社全体にとっても新しい機会を切り開きました。
「以前の Treasure Data はスタートアップのメンタリティを持っていました」と Carlo は言います。「技術的には中堅企業ではありますが。でも今は、エンジニアリングだけでなく、誰もが成長とスケールについてより多く考えていると思います。……方向性が変わったんです。AI にこれほど多くを投資しているということは、現在の提供範囲を超えてもっと多くのプロダクトを提供する必要があるということです。」
カスタマーデータプラットフォームの領域には、おそらく天井があると感じているからです。……私たちは CDP を超えて考える必要があります。そこで AI や他のソリューションが噛み合うんです。これは本当に良いことです。なぜなら、純粋に CDP だけに注力する場合よりも、会社が進める方向の可能性が広がるからです。
私たちは Carlo に、なぜ開発者は Treasure Data に応募すべきなのかを尋ねました。すると彼は再び、最高水準のエンジニアリングカルチャーと、周囲の人々からどれほど刺激を受けているかについて熱く語りました。「たとえば、Sada をご存じですか？ 彼は Fluentd を作った人です。共同創業者でもあります。……Treasure Data には他にも Ruby のコントリビューターがいますし、本を書いた人たちもいます。……そういう人たちの頭脳から学ぶことができるんです。」
それ自体が、私が他の開発者にここを勧める理由だと思います。そういう人たちの近くにいることで学びが加速し、全体の水準が引き上げられるんです。