ElatoAI: ESP32に音声AIを載せるためのサーバー構成とライセンスの読みどころ

ElatoAIが埋めているのは「ESP32と音声APIの間」の配線

ESP32で音声対話を作ろうとすると、マイク入力のバッファリング、Opus圧縮、WebSocketの維持、VADによる発話区間の検出、そしてSTT・LLM・TTSの3つのAPIをつなぐ順序制御を、すべて自分で書くことになる。ElatoAIが引き受けているのはこの配線部分だ。READMEの機能一覧には、Secure WebSockets、Server VAD Turn Detection、Opus Audio Compression、OTA Updates、captive portalによるWiFi設定が並ぶ。アプリケーションロジックではなく、デバイスとクラウドの間で切れやすい部分をまとめたリポジトリだと読める。

対象は、Arduino FrameworkでESP32を触ったことがあり、音声APIのキーを自分で用意できる開発者だ。クラウド側の音声パイプラインをゼロから設計したくないが、デバイス側の挙動は自分で調整したい、という層にちょうど重なる。逆に、音声対話そのものが初めてで、まずブラウザで動かしたいだけなら、このリポジトリのESP32側は荷が重い。

サーバーが3系統に分かれている理由と、それぞれの受け持ち

リポジトリのserverディレクトリは、deno、cloudflare、fastapiの3つに分かれている。これは排他的な選択肢ではなく、レイテンシとモデル選択の自由度のトレードオフが異なる3つの経路だ。

server/deno/models配下には、openai、gemini、grok、elevenlabs、hume、boson.tsが並ぶ。ここは各社のspeech-to-speech APIへ直接つなぐ経路で、STTとTTSを自前で組み合わせる必要がない。READMEの表現を借りれば「Realtime Speech-to-Speech」で、会話の途中でモデルを差し替えるより、1つのAPIに会話全体を任せる設計になる。

Cloudflare Workers側は構成が逆で、STT・LLM・TTSを別々に選ぶ。READMEのNewsにある2026年4月17日の項目では、Workers AIがDeepgramのSTT/TTSをネイティブに提供するため、利用者が用意するのはLLMのAPIキーだけでよいと説明されている。Durable Objectsを使ってデバイス間をつなぐ「Global Devices/Toys network」という位置づけもここで示されている。

FastAPI側はPipecatを使い、100以上のSTT・LLM・TTSの組み合わせからパイプラインを組む経路だ。3系統のうち、モデルの組み合わせを最も細かく制御できる代わりに、サーバーを自分でホストする前提になる。

導入はファームウェアとサーバーで手順が分かれる

ビルド経路はPlatformIOとArduino IDEの2つが用意され、READMEからそれぞれwww.elatoai.com/docs/platformioとwww.elatoai.com/docs/arduinoへリンクされている。どちらを使うかは、既存の開発環境に合わせて選ぶ形になる。

サーバー側は、Deno経路ならserver/deno/models配下の使いたいモデルのディレクトリに入り、そのAPIキーを設定してデプロイする。Cloudflare経路ならWorkers AIのSTT/TTSを使うため、READMEの記述に従えば用意するキーはLLMのものだけになる。FastAPI経路はserver/fastapiに実装があり、Pipecatのパイプライン定義を編集してモデルを差し替える。

デバイスの初期設定はcaptive portal経由でWiFiにつなぎ、NextJSのwebappからデバイスの登録と認証を行う。会話履歴とリアルタイム文字起こしはSupabaseに保存される構成で、ファームウェアの更新はOTAで配信される。つまり、動かすまでに必要な外部サービスは、選んだ音声API、Supabase、そしてwebappを載せるホスティングの3つ以上になる。READMEには個々の環境変数名の一覧までは示されていないため、実際のキー名はdocs側で確認する必要がある。

PSRAM不要という制約の裏側

機能一覧に「No PSRAM Required」と明記されている点は、このリポジトリの設計上の選択がはっきり出ている箇所だ。PSRAMを積まないESP32でも動くということは、音声バッファを潤沢に持てない前提で、Opus圧縮とストリーミングのタイミングを詰めていることになる。安価なボードで試せる反面、会話の途切れや再接続の挙動はボードのRAM余裕とWiFi品質に敏感に出る。READMEには20分以上の連続会話という記述があるが、これはサーバー側のEdge配置を含めた主張であり、手元のボードと回線で同じ結果になるかは別に検証が要る。

もう1つの制約はサーバー構成の選択そのものだ。Deno経路はモデル側のAPIに会話を丸ごと渡すため、VADの閾値やターン検出の細かい調整は各APIの仕様に従うことになる。逆にCloudflare経路やFastAPI経路はSTT・LLM・TTSを分けて持つので、途中のテキストを加工したり、独自のロジックを挟んだりできる。どちらが優れているという話ではなく、会話の制御をどこに置くかで経路が決まる。

Pipecatを自分で組む場合との違い

比較対象として素直なのは、Pipecatを使って音声パイプラインを自分で定義する構成だ。ElatoAIのFastAPI経路もPipecatを使っているので、両者の差はフレームワークの有無ではなく、どこまでが同梱されているかにある。

Pipecatを素で使う場合、STT・LLM・TTSの各サービスをつなぐパイプラインを自分で書き、ターン検出、割り込み処理、音声の送出タイミングを自分で決める。柔軟だが、ESP32側のファームウェア、デバイス認証、OTA、会話履歴の保存は別途作ることになる。ElatoAIはこのうちデバイス管理とファームウェアを持っている代わりに、ESP32のArduino Frameworkという前提から外れることができない。

もう1つの比較軸は、speech-to-speech APIを直接使うかどうかだ。OpenAI Realtime APIやGemini Live APIを直接呼ぶ構成では、STTとTTSを分ける必要がなく、パイプラインの段数が減る。その代わり、途中のテキストに対する処理を挟みにくく、モデルの選択肢も各社の提供範囲に縛られる。ElatoAIがserver/deno/modelsに6つの実装を並べているのは、この縛りを実装ごとに切り替えられるようにするためだと読める。

ライセンス表記がNOASSERTIONであることの意味

このリポジトリのライセンスはNOASSERTIONと記録されている。これは、リポジトリのメタデータから自動判定できる標準的なライセンスが見つからなかったという状態を示すもので、ライセンスが存在しないという意味でも、特定の条件が適用されるという意味でもない。

実務上は、リポジトリ直下のLICENSEファイルの実体を自分で開いて確認する以外に方法がない。商用製品に組み込む場合、あるいはファームウェアを配布する場合、この確認を飛ばすと後から条件が問題になる。ここでは法的な助言はできないので、判断は法務に委ねるとして、少なくとも「NOASSERTIONだから自由に使える」という読み方は成り立たない。

もう1点、外部依存のコストも見ておきたい。音声API、Supabase、webappのホスティング、そして選んだサーバー基盤の4つ以上に対して、それぞれの料金体系とAPIキー管理が発生する。リポジトリ自体の更新コストより、接続先サービスの料金改定やAPI仕様変更のほうが影響は大きい。READMEのNews項目が2026年4月に集中しているのも、上流APIの変化に追随する形で構成が増えてきたことの表れだと読める。

どの経路を選ぶかで、後から変えられる範囲が決まる

3系統のサーバーは、後から乗り換えるのが簡単ではない。Deno経路からCloudflare経路へ移すと、会話の制御はモデル側から自分のコード側へ移り、用意すべきAPIキーの種類も変わる。ファームウェア側のWebSocketの扱いも、相手がspeech-to-speech APIかSTT/LLM/TTSのパイプラインかで影響を受ける。

先に決めるべきは、会話の途中に独自の処理を挟みたいかどうかだ。挟まないならDeno経路が構成として短く、挟むならCloudflareかFastAPIを選ぶ。デバイスを複数台つないでネットワーク化したい場合は、READMEのNewsがCloudflare Voice AgentsとDurable Objectsに触れているので、その経路が想定されていると読める。

もう1つ、モデルを頻繁に差し替える予定があるならFastAPI経路が向く。100以上のモデルから選べるとREADMEは説明しており、パイプライン定義の編集で切り替える形になる。逆にモデルを1つに固定して早く出したいなら、server/deno/modelsの該当ディレクトリをそのまま使うのが最短になる。

編集部の結論

ESP32で音声対話デバイスを試作し、会話履歴やデバイス認証まで含む一式を自前で組み立てたくない個人開発者や小規模チームに向く。逆に、ライセンス条件を法務確認なしに商用製品へ組み込みたい場合や、サーバー側を完全に自前のインフラで運用したい場合には向かない。着手前に確認すべきは3点で、リポジトリのLICENSEファイルの実体、server/deno/models配下で使うモデルごとのAPIキー要件、そしてPlatformIOかArduino IDEかどちらのビルド経路を取るかである。ドキュメントの導線はwww.elatoai.com/docsに集約されており、READMEだけでは設定キーの一覧までは追えない。

公式情報源

1. akdeb/ElatoAI on GitHub
2. Issues
3. Project website
4. README