lemonflowがGemma 4を導入、EV充電向けAIエージェントでP50遅延約350ミリ秒を実現

GemmaとGeminiのEV充電エージェント

lemonflowのサポートエージェントは、発表時点で90を超える言語に24時間対応し、90秒ごとに1人のEVドライバーを支援しています。リアルタイムの会話はCloud TPU上のGemmaが担い、監視エージェントはGeminiで会話と充電器のログを裏側で分析します。^[1]

lemonflowの目標は、充電器で立ち往生するドライバーをなくし、自分の言語で即座に専門的な回答を届けることです。専用のCloud TPU上のオープンモデルが、欧州全域でこの対応を標準にする速度と制御性をもたらすとlemonflowは位置付けています。

仕組みはドライバーから見えず、速い回答と正常に動く充電器だけが届く形が、lemonflowの目標です。lemonflowはGoogle Cloudと協力してこれを標準にし、EV普及を後押しするとしています。

図1　lemonflowの2種類のAIエージェントと変換レイヤー

監視エージェントの分析は、次のドライバーが影響を受ける前に事業者が障害を直せるようにするためのものです。lemonflowは、充電事業者から充電器メーカーまでの多様なe-mobility企業でコアの仕組みをそろえるため、CPMSの変換レイヤーを構築しました。

CPMSをつなぐ変換レイヤー

CPMS（Charge Point Management Systems）は、充電事業者が充電器の運用に使うバックエンドです。lemonflowは、約30種類のCPMSを橋渡しできる標準化された会話エンジンを必要としていました。

図2　CPMSと変換レイヤーの役割

充電トラブルへの遠隔対応

lemonflowが想定する例では、前回のセッションが正しく閉じずに充電が始まらないドライバーが、充電器の番号へ電話します。エージェントは数秒以内に充電器のログから止まったセッションを見つけて充電器を遠隔で再起動し、電力が流れ始めるまで通話を続けます。

lemonflowは、電話やチャット、メール、WhatsAppでリアルタイムの充電トラブルを解決する自動化プラットフォームの構築に取り組みました。ライブ音声サポートでは、複数の技術要件が生じました。

エージェントの操作例です。

充電ステーションはデジタル表示を持たないことが多く、ドライバーはモバイル決済の3D-Secure認証の保留やセッションのタイムアウトに気付きにくくなります。ローミングが有効でない充電カードや現地の負荷管理による出力の低下、車両の充電上限による終了も、気付きにくい原因です。

lemonflowのGemma推論構成

lemonflowは、超低遅延の音声対話と保証された処理容量のため、モデルのホスティング環境の直接制御を必要としました。マネージドAPIからの移行先は、EUのGoogle Cloud TPU v6e上のGemma 4の自前運用です。^[1]

図3　lemonflowの移行の概要

Gemmaは、Geminiとの互換性を持つオープンモデルです。lemonflowは、この互換性によって既存のプロンプト基盤を最小限の変更で移せました。

会話エンジンの処理の流れ

ドライバーが充電器に記載されたサポート窓口へ電話すると、通話は事業者のホットラインを経てlemonflowのConversational Engineに届きます。Conversational Engineは、事業者のCPMSから充電器のライブ状態とOCPPのログをリアルタイムに取得します。

図4　Conversational Engineの接続先

OCPP（Open Charge Point Protocol）のログは、充電器がバックエンドと交わすメッセージです。Conversational Engineは、構造化されたログ要約をTPU上のGemmaへ直接渡す仕組みです。

lemonflowはモデルを直接制御できるため、出力トークンを選んで流し分けています。部分的なテキストのトークンはText-to-Speech（TTS）エンジンへ即座に流れ、構造化されたツール呼び出しのトークンはバックエンドへ非同期に流れます。

推論基盤を支える仕組み

lemonflowはTPUの自前運用によって、決定的なコア層に必要な制御を得ました。コア層を含む仕組みは以下の通りです。

推論基盤の運用上の備え

lemonflowの構成では、TPUの信頼性によってGemmaがライブ会話のターンの99.9%超に応答しています。フォールバックは主にシステム更新時のデプロイの緩衝として使われ、主系も予備もセキュアなEUの計算資源で処理されます。

図5　lemonflowの推論基盤の備え

決定的なセキュリティ制御は、TPU上のLLMへ届く前の入力を検査し、悪意のあるプロンプトを遮断する仕組みです。lemonflowはこのアーキテクチャを欧州の重要インフラの要件を念頭に設計し、典型的な応答は約350ミリ秒で始まります。

lemonflowのエージェントの運用実績

lemonflowが取引するe-mobility企業とドライバー向けに、エージェントは通常すべての電話に応答し、会話の80%超を人への引き継ぎなしで完結させています。ドライバーの満足度は95%です。^[1]

性能面では、Google Cloud TPU上でのGemmaの自前運用によって大きく変わったとlemonflowはしています。主な変化と実績です。

対応規模の数値は発表時点のものです。lemonflowは、同じプラットフォームでさらに多くのネットワークと市場に対応する準備があるとしています。

lemonflowは、追加の計算能力を使ってAgent Coachを導入し、夜間の自動回帰テストも加えました。Agent Coachは、通話中のエージェントに文脈を与え、実際の会話を恒久的なテストケースに変えて各通話を次の通話の改善につなげる裏側のエンジンです。

図6　Agent Coachと回帰テストの役割

モデルと配信の仕組みはlemonflowが変更したときだけ変わるため、テスト結果は意味を持ち続けます。この安定性が、Agent Coachの土台になりました。

lemonflowの事例から確かめる項目

lemonflowの事例は、EUのGoogle Cloud TPU v6e上でGemma 4を自前運用し、予備の経路を含めてEUの計算資源で処理する構成です。同様の構成を検討する場合の確認項目を、編集部が事例から整理しました。^[1]

図7　lemonflowの事例から整理した確認項目

lemonflowは、Googleの第7世代TPUであるIronwoodがlemonflowのEUリージョンで提供され次第、移行する予定です。Ironwoodはチップあたりの高帯域メモリが6倍で、1つのTPUが即答に備えて待機させるオペレーターエージェントを大きく増やせるとlemonflowは見込んでいます。

Ironwoodへの移行を検討する場合は、利用するリージョンでの提供状況を先に確かめる順序が考えられます。lemonflowの移行も、lemonflowのEUリージョンでの提供が前提です。

lemonflowのGemma移行前後の遅延

lemonflowが当初使ったマネージドLLM APIでは、ピーク時に遅延が1.0〜1.2秒から1.7秒超へ跳ね上がりました。世界的な利用集中時には、HTTP 429の制限エラーも発生しています。^[1]

図8　lemonflowの移行前後の状況

lemonflowの各エージェントは、1つの包括的なプロンプトと、稼働中の充電器データを読んで操作する動的なツール呼び出しで動きます。この設計では通話中に計算需要が急増し、ピーク時の共有のマネージドな容量では処理量を保証しにくくなりました。

移行後のP50遅延は約350ミリ秒、P90遅延は約600ミリ秒で、lemonflowはマネージドAPIの基準より約3倍速く、利用者による割り込みを大きく減らせる速さだとしています。専有のTPU基盤ではHTTP 429の制限エラーがなくなり、午後の通話のピーク時も遅延が横ばいです。

図9　lemonflowの遅延の目安と移行後の値

lemonflowは、800ミリ秒を超える遅延で会話の割り込みが起きやすいことを、自社のテストで確かめました。LLMで音声のリアルタイム応答を提供する場合、ピーク時の遅延とHTTP 429の発生を自社の構成で先に確かめる手順が考えられます。