マティス・ジョフル、Blaxel共同創設者兼エンジニアリングリード – インタビュー・シリーズ

マティス・ジョフル、Blaxel共同創設者兼エンジニアリングリードは、ヨーロッパ最大のクラウドプラットフォームの一つであるOVHcloudでインフラストラクチャを拡大するために従事していた、豊富なインフラストラクチャエンジニアです。Blaxelでは、AIエージェント向けの低遅延、スケーラブルなシステムの開発を主導し、パフォーマンス駆動型のデプロイをサポートするオープンソースツールの重要な貢献者です。

Blaxelは、エージェントの開発、テスト、実行を可能にする、自律型AIエージェント用に設計されたコンピューティングプラットフォームです。インフラストラクチャの管理は不要です。超高速マイクロVM、バッチジョブの実行、ルーティングとフォールバックのためのグローバルゲートウェイが含まれています。Blaxelは、生産性の高いエージェントのデプロイをサポートするために、セキュアなサンドボックス化、リアルタイムの観測可能性、シームレスなスケーラビリティを優先しています。

OVHcloudでのAIおよびデータインフラストラクチャのR&Dに3年間従事した後、BlaxelをAIエージェント用に設計されたクラウドとして構築することを決めた、重要な瞬間または洞察は何でしたか?

OVHcloudのフラグシップAI製品の一つであるAIエンドポイントで働いている間、次世代のクラウドアーキテクチャとAIの使用例がどれほど複雑になるかを実感しました。伝統的なチャットボットから完全に自律的なシステムへの移行は、ソフトウェアスタックやデータセンターのアーキテクチャを再考することを余儀なくします。その認識がBlaxelを構築するきっかけとなりました。

Orange Businessでのネットワークツールの構築やOVHcloudでのスタックの定義など、エンジニアリングの初期の経歴を振り返ると、Blaxelのアーキテクチャと哲学にどのような影響がありましたか?

Blaxelは、顧客の現実的なニーズを中心に構築されました。コード生成からビデオ分析まで、トレンドに追随するのではなく、実際のユースケースを解決することに重点を置きました。エージェントが効果的に実行されるための必要なものを提供する、目的を絞ったプラットフォームを提供することを目指しました。

モデルコンテキストプロトコル（MCP）とマルチリージョンモデルのゲートウェイの役割について説明してください。エージェントの耐障害性とスケーラビリティをどのように向上させますか?

エージェントはコンテキストに依存しています。関連する情報にアクセスする能力が、効果的に動作する上で重要です。MCPは、インフラストラクチャとの統合を容易にするため、エージェントのプライマリインターフェイスとして機能します。SaaS世界では、開発者がアプリを接続するためにREST APIを使用するのと同様に、開発者はエージェントに特定のコンテキストを提供するためにモデルコンテキストプロトコルを使用します。

コンテキストだけでは不十分です。エージェントはLLM（OpenAIやAnthropicが提供するもの）にも依存しています。需要の増加により、これらのプロバイダーのサーバーは時々トラフィックで圧倒されることがあります。そこで、マルチリージョンモデルのゲートウェイが登場します。

モデルゲートウェイにより、トラフィックを最も近い利用可能なLLMエンドポイント（遅延時間に基づく）に動的にルーティングできます。OpenAI、Anthropic、または他のプロバイダーが対象となります。これにより、応答時間の改善だけでなく、フォールトトレランス（代替プロバイダーへのフォールバック）とスケーラビリティ（複数のリージョンとモデルにわたる負荷の分散）が向上します。

Blaxelは、エージェント自身が呼び出すことができる開発者ツールをサポートしています。人間ではなくエージェントがAPIを消費するように設計した動機は何ですか? これはどのように進化すると思いますか?

OpenAIのOperatorのリリースは私にとって目覚ましいものでした。インフラストラクチャを直接消費するエージェントの未来を実現するきっかけとなりました。エージェントは歴史的なデータを分析し、質問に答えるようになりました。次にコードを生成するようになりました。次の論理的なステップは、コードを自律的にデプロイすることです。

エージェントはインフラストラクチャを直接消費する必要があります。Blaxelは、エージェントが将来のIT操作を駆動するという考えに基づいて構築されています。

Modal、RunPod、Replicateなどの既存のクラウドプロバイダーとエージェントホスティングプラットフォームを考慮すると、大規模なエージェントのデプロイで最も一般的なギャップはどこにありますか?

現在の多くのプラットフォームは、永続的な状態を持つ自律的なエージェントのために設計されていません。ステートレスジョブや推論APIのために設計されました。コンピューティング、メモリ、ストレージ、ネットワーキングを、長期的なプロセス、メモリ、フィードバックループ、複雑なI/Oをサポートしない方法で組み合わせることになります。結果は、繊細なシステムまたは高運用オーバーヘッドのいずれかです。ギャップは、エージェントが第一級の市民であるインフラストラクチャが必要であるということです。

エージェントを関数のように扱うことなど、最も一般的な反パターンは何ですか? エージェントを本格環境でデプロイするときに、開発者はどのような点で躓きますか?

最も一般的な間違いは、エージェントを呼び出し、実行し、忘れることです。コンテキストを保持し、ツールを管理し、時には外部の信号にリアルタイムで反応する必要があります。開発者は、理想的な条件でテストしますが、実稼働環境では、堅牢な観測可能性、サンドボックス化、復旧戦略が必要です。

ロードマップには、スナップショットのフォーキング、自動フォールオーバー、コンピューティングの最適化などの機能が含まれています。これらの機能の中で、エージェントファーストのシステムにとって最も変革的なものは何ですか?

スナップショットのフォーキングが、デバッグ、実験、並列推論パターンを可能にし、従来のクラウド環境では不可能なものです。エージェントが決定点に到達し、サンドボックスを複数のブランチにフォーキングし、並列に異なる結果を探索し、最適なパスを選択することを想像してください。エージェントのワークフローに固有の分岐ロジックは、従来のクラウドランタイムでは外国語です。

Gartnerによると、2028年までに75%のアプリケーションがAIエージェントを使用する予定です。Blaxelは、AIエージェントが業界全体で普及するにつれてどのように進化すると思いますか?

エージェントが主流になるにつれて、Blaxelは「エージェントのインフラストラクチャ」から「エージェントが依存するオペレーティングレイヤー」へと進化することが予想されます。ライフサイクル、調整、さらにはマーケットプレイスとのやり取りを処理します。エージェントをBlaxelにデプロイするだけでなく、エージェントを構成し、監視し、他のエージェントを管理するエージェントを作成します。財務、セキュリティ、企業の自動化におけるユースケースがすでに現れています。

エージェントがアプリケーションを実行するだけでなく、インフラストラクチャを管理し、再構成する自律的なエージェントの未来を想像しますか? そのようなシフトの文化的およびセキュリティ上の意味は何ですか?

そうです、それは興奮するものですが、不安も感じます。技術的には意味があります。エージェントはシステムのヘルスを監視し、パッチを適用し、ワークロードを最適化できます。しかし、文化的には、コントロールと信頼の概念を再考する必要があります。セキュリティ的には、許可モデルを再考する必要があります。誰が行動できるかではなく、エージェントが何になることができるか。検証可能な自律性と自己改善の新しい抽象化が必要になります。

エージェントネイティブインフラストラクチャが独自のものであるという、最大の誤解は何ですか?

それが単にGPUの増加や長い実行時間の問題であるということです。エージェントネイティブインフラストラクチャは、エージェントが記憶、探索、適応、回復する能力を与える、行動のアフォーダンスについてです。状態の進化を追跡するストレージ、並列性と分岐をサポートする実行モデル、推論に適した観測可能性、遅延だけではありません。心構えの転換が必要です。リソースの増加だけではありません。

OVHcloudでの経験で最も後悔するのは何ですか? Blaxelではそれをどのように解決していますか?

OVHcloudでは、多くのものが、人間のワークロードに最適化されたVM、コンテナ、ネットワークなどのレガシーアブストラクションによって制限されていました。Blaxelでは、クリーンスタートを切りました。エージェントをバッチジョブやマイクロサービスと見なす必要はありません。メモリ、ツール、目標などのプリミティブをランタイムに直接構築できます。新しい設計空間が解放されます。

素晴らしいインタビュー、詳細を知りたい読者はBlaxelを訪れてください。