エッジコンピューティングのFastlyの共同創業者にインタビュー。生成AIを高速化する仕組みを解説

連載 :

2025年7月18日(金)

エッジコンピューティングのFastlyの共同創業者にインタビューを実施した。生成AIを高速化する仕組みのAI Acceleratorを解説してもらった。

CDN（Content Delivery Network）から出発してエッジコンピューティングの総合的なソリューションプロバイダーとなったFastlyの共同創業者からCTOを経て、現在はフェローのTyler McMullen氏にインタビューを行った。

自己紹介をお願いします。

McMullen：私はFastlyの共同創業者で現在はフェローとして働いています。フェローになる前は13年ぐらいCTOとして仕事をしていましたが、もっとコードを書くことと顧客や他のエンジニアと話すことに集中したかったので、約1年前にフェローというポジションに就きました。FastlyはダイナミックなWebコンテンツが主流になりつつある2011年に創業されたんですが、当時の創業メンバーは大規模なWebサイトに関わっていまして、どうしてAkamaiなどのCDNがイメージや動画などの素材だけを対象にして動的なコンテンツをキャッシュできないのか？例えばNew York Timesや日経新聞のサイトのトップページのようなダイナミックなデータをキャッシュできないのか？という疑問から始まりました。

コンテンツは常に更新されますから、キャッシュされたコンテンツに対してはそれがもう使えないということを指示する必要があります。そうすることで常に最新のコンテンツへ素早くアクセスできるようになるわけです。そのために私が書いたのは、インスタントパージという機能です。それはキャッシュの更新がAkamaiであれば20分もかかるものを数ミリ秒で更新するというものでした。

そして今の生成AIは、当時と同じ状況に陥っていると思います。それがAI Acceleratorを開発した最初の発想でした。どうして毎回似たようなプロンプトに対して推論という重い処理を何度も繰り返さなければいけないのか？似た質問であればその結果をキャッシュすることはできないのか？ということです。

いかにもコンピュータオタクと言った風貌のMcMullen氏

最近はどこに行っても誰もがAIについて語っている状況ですが、AIについて私自身はよく理解をしていると自負しています。Fastlyを創業する前は、Scribdというドキュメントに関連した企業でデベロッパーをしてました。そこではテキストをサマライズしたり良く似た内容のテキストを検索したりするのが仕事だったので、テキストを機械学習で処理するタスクには慣れています。ですので機械学習の詳細も生成AIの中身も十分に理解していると思います。生成AIを使いたいという顧客は非常に多いのですが、実際のところ、現在のインターネットには多くの使い物にならないデータで溢れています。あるリサーチでは全体の半分がBotによって生成されているとも言われていますし。反面、セキュリティについても懸念する顧客も多いのです。

その発想から2025年1月にFastly AI Acceleratorという新機能が発表されたわけですが、それについてもう少し詳しく教えてください。

McMullen：その中身を簡単に説明すると生成AIアプリケーションを使ってチャットを行う場合、ユーザーが入力した質問、つまりプロンプトと呼ばれるテキストですね、これをベクターという単語の関係性を表すグラフデータとして処理します。それを受け取ったアプリケーションはそのグラフをベースに関連するデータを検索して回答を生成するわけです。RAG（Retrieval-Augmented Generation）であれば、企業が持つデータベースをベクター化して特定領域の知識として使うことで精度が上がります。ベクターは多次元の複雑な関係性を持つ大きなデータですが、プロンプトとしては違っても良く似た内容が使われるケースも多いとも言えます。そして例を挙げると掃除機を売っている会社であればその掃除機に関する質問はかなり特定できるわけですよね。なので掃除機の機能や使い方をデータとして与えることで、その製品については精度の高い回答を返すことができるわけです。それがRAGですね。

しかしここで問題が発生します。回答の品質が上がってもその処理が遅いのであれば、顧客は満足しないわけです。そこで生成AIのレイテンシーを改善するために開発したのがAI Acceleratorです。これはプロンプトがベクター化される際にその内容をハッシュのようなプロンプトの特徴を要約する形で小さな数値データに変換し、それをキャッシュとして保存しておきます。同時に中間的に生成されるデータも数値データに紐付いたかたちで保存しておきます。そうすると似たような質問が来た時に、それに最も近いキャッシュデータを再利用することで生成AIの回答速度を上げるのがAI Acceleratorです。この説明が一番、簡単に理解できるかもしれないですね。実際にはもっと複雑な処理が絡みますが、なるべくわかりやすいように説明するとこうなります。

つまりプロンプトの特徴を要約したデータを使ってそのデータに近い値を持つ結果や中間データをキャッシュすることで生成AIの処理を省いて高速化するというわけですね。

McMullen：そうです。「何と何が近いのか？」という問題はもう少し深い解説が必要ですが、簡単にわかりやすく説明するとこうなります。そしてこれはLLMではなくSLM（Small Language Model 小規模言語モデル）でも応用が利くのです。つまり質問をそのまますべてLLMに入れるのではなく、まずSMLで処理してから必要があればLLMに処理を引き渡すということが可能になります。例えば動画の投稿サイトを例に挙げると、ユーザーが投稿した動画が何を撮影しているのかをすべて解明しなくても、最初にスクリーニングのためにSMLでそのサイトにふさわしい動画なのかどうかだけを判断できるようになります。そうすればシステムの負荷を高めずに必要なスクリーニングを行えるわけです。非常に限られた判定基準をSLMで実行することになりますが、実際の業務としては効率を上げる結果になります。

クラウドとエッジで生成AIの処理を分担するというのはロンドンで行われたKubeConのHuaweiのセッションでも解説されていました。それは工事現場で作業員がヘルメットを被っているかどうかを監視カメラの動画から判定するというものでしたが、エッジのデバイスで大雑把に判定をして確信度が低ければ上位のクラウドのモデルでより詳細に推論を行うというもので発想は同じですね。

McMullen：そうですね。SMLの良いところの一つは、それがエッジの中で実行できるようになることでもあります。

Fastlyのエッジコンピューティングと相性が良いというわけですね。プロンプトと中間結果をキャッシュできるとするとエッジ同士でそのデータを共有することも可能でしょうか？何かというとサンフランシスコで自動運転のWaymoを利用した時に、夜だったですが、多くの車が路上駐車をしている脇から犬を散歩している人をセンサーが検知して速度を落としたということがありました。それは肉眼では視えない暗い環境下でWaymoのセンサーが検知したんですが、そういう例をキャッシュ化してその近傍を通行している他のWaymoのタクシーに送って高速な推論に使うことは可能でしょうか？他にはアメリカではあり得る状況ですが、ある街の一角で銃の乱射事件が発生している場合は、その区画を避けて通行するような状況です。

McMullen：私はサンフランシスコに住んでいますのでその状況は理解できます。その場合はクラウド側で状況を即座に更新してクラウドから車輛にデータを送るということが現実的なのかなとは思います。私のWaymoの奇妙な体験としては雨が降っている時になぜかワイパーを動かして自動運転していたということですが、実際に運転手がいないのでワイパーを動かす必要はまったくないのですが、乗っている人の安心感を上げるためには必要だったのかなとは思いますけどね。

エッジでのAIの応用は、さまざまな人と話をすると毎回いろいろなアイデアが出てきますが、要はそれをどうやって実装するのか？それが運用可能なのか？その効果をどうやって評価するのか？という点に尽きると思います。

では最後に最近、特に眼にするようになったMCP（Model Context Protocol）ですが、それについてはどう評価していますか？

McMullen：それは今回の来日の時に必ず出てくる質問でした。私は明日アメリカに帰るので、このインタビューがほぼ最後の仕事なんですが、どのミーティングでも顧客やエンジニアに訊かれましたよ。MCPは素晴らしい発明だと思いますね。MCPによってさまざまな連携が可能になりますし、FastlyもすでにMCPについてはWebAssemblyを使った実装例を公開しています。

●参考：Building an actually secure MCP Server with Fastly Compute

最後にこちらから質問させてください。あなたが書いた記事を見るとWebAssemblyについて何度も取り上げていますし、過去にWasmConにも参加しているのも知っています。私はFastlyの中でWebAssemblyを推進している立場ですが、WebAssemblyについて良いと思うところはなんですか？

逆に質問されるのは珍しいですが、WebAssemblyについてというよりも私の興味の出発点はRustというプログラム言語ですね。メモリーセーフで高速、そしてWebAssemblyに簡単に変換できるというところを評価しています。私はかつてMicrosoftでExcelのプロダクトマネージャーをしていましたが、最近のMicrosoftはRustとWebAssemblyに真剣に取り組んでいてそれは元社員としては嬉しい限りです。Flight SimulatorでRustとWebAssemblyが使われているのはWindowsのDLL Hellを回避したいというのを知った時はちょっと驚きましたが。

McMullen：私がWebAssemblyを評価している一つのポイントは、Polyglot（多言語対応）と言う点ですね。RustからC++で書かれたモジュールを呼ぶこともできますし、Javaのモジュールも呼べます。これによってさまざまなプログラミング言語で書かれたシステムとの連携が可能になります。コンポーネントモデルは非常に重要だと考えています。

脱線しながらもさまざまなテクノロジーや文脈について解説をしてくれたTyler McMullen氏だった。最後にオフレコということで現在のトランプ政権についても意見を訊いたが、そこでも明快に自身の意見を述べてくれたことが印象的なインタビューとなった。