クリスチャン・スタノ、AnyscaleのField CTO — インタビューシリーズ

クリスチャン・スタノ氏はAnyscaleのField CTOとして、大規模なAIインフラ、機械学習プラットフォーム、分散コンピューティングの分野でキャリアを築いてきました。Anyscaleに加わる前はAttentiveのAI・機械学習プラットフォーム部門を率い、5億人を超える登録者向けのパーソナライズを支えるインフラを拡張しました。また、開発を速めながら運用コストを削減する、Rayを基盤とした統一的な計算システムの導入を推進しました。それ以前にはCoalfireやDeloitteなどで、サイバーセキュリティ、クラウド設計、公共部門のAI事業に携わり、米国国防総省における初期の機械学習プラットフォームの一つにも貢献しています。AIプラットフォームの開発、MLOps、クラウドネイティブなインフラ、開発者への支援、組織の拡大にまたがる経験を持ち、企業がAIを大規模に本番運用できるよう支援してきました。

Anyscaleは、Rayを開発する企業です。Rayは、CPUとGPUのクラスターを使ってAIやPythonの処理を拡張するために広く利用されている、オープンソースの分散コンピューティング基盤です。Anyscaleはカリフォルニア大学バークレー校のRISELabでRayを生み出した開発者たちが設立しました。学習、推論、データ処理、AIエージェントの処理に必要な大規模AIインフラの導入、実行管理、運用を簡素化することに注力しています。同社のプラットフォームでは、クラウドとオンプレミスの両方で分散AIシステムを動かせます。さらに、最新のAIアプリケーションに向けたシステムの状態把握、ガバナンス、性能の最適化を提供します。Rayは新たなAIインフラを構成する中核的な層となっており、既存のPythonコードをわずかに変更するだけで、1台のマシンから数千ノードへ処理規模を拡大できます。

サイバーセキュリティ、公共部門の機械学習プラットフォーム、超大規模なパーソナライズシステムに携わってこられました。組織がAIの試験導入から本番運用へ進む際、共通してどのような傾向が見られますか。

業界を問わず、三つの傾向が繰り返し現れます。第一に、開発から本番運用へ進むための、信頼できる整備された手順がありません。ノートブック環境でモデルを作れても、本番で動かす方法が標準化されていないのです。導入のたびに個別対応となり、障害が起きるたびに想定外の事態になります。第二に、インフラが需要に合わせて拡張できません。試験導入では動いたシステムも、実際のデータ量やトラフィックを与えると耐えられなくなります。第三に、チームが状況を十分に把握できていません。システムが実際にどのように動き、どこが限界に近づき、いつ介入すべきかを知るための可観測性が不足しています。

三つに共通する根本的な課題は、複数のマシンへ処理を分散して規模を拡大することについて、チームが適切な考え方を持っていない点です。順序を意識して進めず、一度にすべてを解決しようとします。私は三段階で考えています。まず動かし、次にきちんと整え、最後に速くする。これは一度だけ通過する節目ではなく、繰り返す段階です。今壊れているものと、次に壊れそうなものの間で、絶えず優先順位をつけます。成功するチームは自分たちの段階を理解し、基盤が固まる前に先走らない姿勢を守っています。

Anyscaleには、あらゆる段階のチームが相談に来ます。まだ動かそうとしていて、開発から本番運用までの確実な道筋を必要とするチームもあります。その道筋はあっても運用の複雑さに圧倒され、仕組みを整える必要があるチームもあります。また、動くものは作れたものの、事業が求める規模まで拡大できずに来るチームも多いです。統一された計算基盤はどの段階でも役立ちますが、どこから着手するかは、何が最も切実な問題かによって決まります。

Attentiveでは、数億人のユーザーを支えるAIシステムの拡大に貢献されました。その規模に達するために乗り越える必要があった、設計上または組織上の最大の制約は何でしたか。

最大の制約は、インフラの複雑さがS字曲線を描いて増していくことでした。モデルが扱うデータとサービスを提供する顧客を増やすにつれ、計算基盤は転換点に達しました。単体の性能を最大限に高めたノードでさえメモリ不足エラーが起き、単純にノード数を増やすだけでも対処できなかったのです。計算能力がデータの規模に追いつきませんでした。

自然な対応は、制約を回避するためにツールをさらに重ねることでした。私自身、以前の経験からその方法を取っていました。各ツールは限られた問題を解決する一方、運用を複雑にしました。機械学習の処理基盤は、継ぎはぎの連携システムになりかねませんでした。新しい用途が増えるたびに、接続作業、障害の種類、コスト、プラットフォームチームの負担も増えたのです。

最終的に規模拡大を可能にしたのは、データ処理、学習、推論、モデルの提供をRayとAnyscaleの上に統一したことです。効果はすぐに現れました。インフラコストが大幅に下がり、データ量が増えても学習のサイクルは大きく短縮し、モデルでサービスを提供できる顧客数を何桁も増やせるようになりました。

どのような理由から、この時期にAnyscaleへ加わることを決めたのでしょうか。また、Field CTOの役割は、企業のAI導入にどのような影響を与えると考えていますか。

AttentiveにAnyscaleを導入した経験で、機械学習プラットフォームを構築する私の方法は根本から変わりました。それ以前は、分断されたシステムをつなぎ合わせる作業が、プラットフォーム開発のコストの大きな部分を占めていました。Anyscaleによってその負担の多くをなくし、開発者の使いやすさ、信頼性、性能に集中できました。この変化はチームの生産性とシステムの成果の両方に大きく影響しました。Anyscaleへの参加は、この問題に専念し、同じ移行に取り組むほかの組織を支援する機会でした。Field CTOとしての私の役割は、こうした現場の教訓を、顧客がAIの規模を拡大する際に繰り返し使える実践方法へ変えることです。

多くの企業は、いまだにAIの試験導入の段階から抜け出せていません。初期の実験を本番システムへ拡張しようとすると、具体的に何がうまくいかなくなるのでしょうか。

AIの実験から本番運用へ進む際、問題がモデルだけにあることはまれです。むしろ、その周囲のシステムや運用が行き詰まります。早い段階でインフラの限界に達し、望む規模で学習やモデルの提供ができないこともあります。その結果、モデルが対応する顧客数や用途を制限せざるを得ません。より多いのは、本番運用中に想定外の例外的な状況やデータの変化で問題が起きるケースです。特に多いのがメモリ不足です。データの大きさ、分布、種類が変わると、処理がメモリを使い切って失敗します。こうした問題は予測が難しく、自動復旧はさらに困難です。AIの本番運用では、障害は避けられません。目標は障害を完全になくすことではなく、素早く検知して理解し、事業に影響する前に解決する自己復旧型のシステムを作ることです。

Anyscaleの設立者たちが開発した分散コンピューティング基盤Rayが、AI処理の基盤として普及しています。分散実行は、なぜ現代のAIインフラでそれほど重要になっているのでしょうか。

分散実行と処理負荷の管理は、AIの処理基盤に不可欠な条件となりました。現代のAI処理は本質的に並列で、多くの計算資源を必要とします。学習、推論、データ処理のいずれも、CPUとGPUにまたがる多数のタスクの調整が必要で、多くの場合、その調整は動的に行われます。現在の計算環境では、限られた資源に処理を割り当てる複雑さが、運用上の大きな負担になっています。従来のシステムは、この複雑さや規模を想定していません。Rayのような基盤が重要なのは、裏側の調整を自動化し、1台のマシンから数千ノードへ無理なく処理を拡張できるからです。この変化は、AIのための計算基盤への、より大きな移行を示しています。古い設計思想を転用するのではなく、AI処理の特徴に合わせてインフラを設計するということです。

Anyscaleのプラットフォームを通じてRayを導入する企業が増える中、統一的な方式を標準とする組織と、ばらばらのツールを組み合わせる組織には、どのような違いがありますか。

違いは、突き詰めれば何に集中できるかと効率です。つながっていない複数のシステムに頼るチームは、それらを接続し、不整合を管理し、異なる環境の障害に対応することに多くの時間を費やします。運用の負担が増え、実験も遅くなります。統一的な方式なら、一つのシステムの改善に集中できます。その結果、信頼性と性能が高まり、開発者も使いやすくなります。仕組みが一貫して理解しやすいため、当番での障害対応やデバッグも簡素化できます。得られるのは技術面の効率だけでなく、組織としての役割や進め方の明確さでもあります。

機械学習プラットフォーム全体を構築してきた経験から、各チームのAI導入を速めるうえで、開発者体験、いわゆるDevExはどの程度重要だと考えていますか。

開発者体験は、AI導入を速めるうえで最も大きな効果を期待できる分野の一つです。プラットフォームチームが、標準化された手順やテンプレート、インフラを扱う煩わしさの軽減を通じてシステムを使いやすくすると、組織のすべてのエンジニアの生産性が高まります。変化が極めて速く、競争力を保つために素早い改善を繰り返す必要があるAIでは、特に重要です。開発者体験の改善は、実験の高速化、本番運用までの時間短縮、最終的には事業への貢献の拡大に直結します。AIを使ったコーディング支援ツールは、こうしたDevExの基本的な要素の効果をさらに高めます。さまざまな意味で、組織全体の開発速度を引き上げるために最も広く展開しやすい方法です。

AI処理の規模が拡大するにつれ、コスト効率が大きな課題になっています。性能を犠牲にせずインフラコストを減らすために、企業が見落としがちな方法には何がありますか。

AI処理が大規模になると、コスト管理はより重要になると同時に複雑になります。特にGPUを使うインフラでは、非効率によってコストがどれほど急速に膨らむかが見落とされがちです。大規模なクラスターでは数千のノードを起動できます。資源を適切に管理したり停止したりしなければ、コストは急増します。チームが追跡・制御できる速度を超えて計算資源の利用が増える、AI特有の無秩序な拡大が起きるのです。対処には、強固なガバナンス、可視化、自動化を組み合わせる必要があります。たとえば、自動的な規模調整、不要な資源の自動停止、資源の一元管理です。大規模な運用では、コスト効率は運用上の課題にとどまらず、システム設計の基本要素です。

特徴量ストアからリアルタイム推論システムまで携わってこられました。バッチ処理とリアルタイムのAI処理のバランスは、どのように変化していると考えていますか。

そのバランスは根本的には変わっておらず、今も事業上の要件で決まります。バッチ処理は一般にコスト効率が高く運用も容易なので、多くの用途に適しています。一方、チャットアプリや不正検知のように、遅延がユーザー体験や事業の成果に直接影響する場合はリアルタイムのシステムが欠かせません。両方の方式は今後も共存します。組織にとって重要なのは、どちらにも効果的に対応できるプラットフォームを作ることです。判断は最終的に、コスト、遅延、信頼性の間で何を優先するかに帰着します。

2〜3年後、成熟した企業向けAIプラットフォームはどのような姿になるでしょうか。RayのようなツールやAnyscaleのようなプラットフォームは、その未来にどう位置づけられますか。

今後数年で、成熟した企業向けAIプラットフォームには、いくつかの特徴が備わるようになります。個別のツールの寄せ集めではなく、データ処理から学習、推論まで、AIの全工程を支える統一インフラを使うようになります。導入後の継続運用もしっかり整い、エージェントによって自動化された状態把握、信頼性の確保、迅速なデバッグが可能になります。コスト管理は予測可能で統制が利き、組織は持続可能な形で規模を拡大できます。そして、おそらく最も重要なのは、開発を速く進められ、チームがアイデアを素早く本番運用に移せることです。RayやAnyscaleは、その規模と効率を可能にする、AI向けに設計された基盤を提供することで、中心的な役割を担います。

貴重なお話をありがとうございました。詳しく知りたい方は、Anyscaleのサイトをご覧ください。