AnimaBox — クラウドに送らない、手のひらのAIと話す | スポットライト

神戸ソフト編集部

2026.06.06 公開

ネットにつながず、Raspberry Pi の中だけで日本語AIが考え、3Dキャラが表情つきで喋り返す。エッジAIサイネージ「AnimaBox」のアーキテクチャを、技術的に解説します。

ネットにつながないAIと、話す

近年の対話AIは、その賢さの大半をクラウドの巨大なモデルに頼っています。便利な反面、回線が落ちれば止まり、会話の内容は外部のサーバーへ送られ、応答にはネットワーク往復の待ち時間がかかります。

AnimaBox は、その前提を反転させたデモンストレーションです。来場者の声をその場で聞き取り、端末内の小さな日本語AIだけで考え、3Dキャラクター「MINATO」が表情・口パク・視線をつけて短く丁寧に喋り返す——これを Raspberry Pi 5 の上で、完全オフライン・クラウドゼロで実現しています。

AnimaBox は、神戸ソフトの技術チームが企画・開発したエッジAIの実証プロジェクトです。音声認識モデルの最適化から会話エンジン、3Dキャラの描画まで、すべて自社で内製しました。Interop Tokyo 内「AI Native Expo」の神戸ソフトブースで展示しています。本稿では、その内部構造を技術的に掘り下げます。

システム全体の構成

カメラとマイクからの入力を、状態機械（ディレクター）が束ね、会話パイプラインを経て3Dキャラの描画へ流す——という一方向のデータフローです。クラウドへ出る矢印は、どこにもありません。

カメラは状態機械へ、マイクは会話パイプラインへ。出力は事前生成済みの音声・表情（＋感情ラベル9種）として3Dキャラに反映される。すべて端末内で完結し、クラウドへ出る矢印はない。

ハードウェアは Raspberry Pi 5 ＋ Raspberry Pi AI HAT+ 2（Hailo-10H 搭載）。Hailo-10H は 40 TOPS・オンボード 8GB を備えた小型のエッジAIアクセラレータで、PCIe 経由で Pi に接続します。音声認識やキャラ描画を含むすべての処理を、この手のひらサイズの構成だけで完結させています。

オンデバイスで動くモデル群

ランタイムで動くのは、すべて端末内に載る軽量モデルだけです。

音声認識（STT）: Whisper（base, 74M）。Hailo 向けに HEF 化し、日本語を強制。
意味検索の埋め込み: Ruri-v3-130m（cl-nagoya）。512次元・正規化済みでコサイン類似を取る。
Rewriter / Reranker: Qwen2.5-1.5B-Instruct（量子化 Q4_K_M）。指示語や省略の文脈解決に使う。
キャラ描画: three-vrm / WebGL（ブラウザ）。Pi5 で 720p・約27fps。

学習やデータ生成といった重い処理はクラウドの大型モデルで事前に済ませ、本番のランタイムはこの軽量モデルだけで動かす——という役割分担が設計の軸になっています。

whisper-base を日本語に最適化する — Hailo-10H への道

エッジで日本語を聞き取るために、OpenAI の whisper-base を Hailo-10H 向けにコンパイルし直しました。ここが地味ながら最も苦労したところです。

ポイントは、これは重みの再学習ではないということです。やったのは、

モデルのエクスポート: whisper-base を ONNX へ書き出す（Hailo Dataflow Compiler 5.3.0 は torch 2.9.1 / dynamo 無効でのエクスポートが必要、といった依存関係の罠を一つずつ潰しました）。
日本語データでの量子化キャリブレーション: NPU は整数演算で動くため、浮動小数点モデルを量子化します。このときどんなデータを通すかで精度が変わります。日本語音声コーパス ReazonSpeech を流してアクティベーションの分布を測り、日本語に合わせて量子化しました。
HEF へのコンパイル: エンコーダは10秒入力、デコーダはシーケンス長64という構成で、Hailo の実行形式（HEF）にコンパイル。

さらに、当初「日本語にならない」という不具合に悩まされましたが、原因は HEF 側ではなくランタイム側にありました。トークン埋め込みの加算（add_embed）が無効になっていたのと、デコーダへ言語プレフィックス <|ja|><|transcribe|> を明示的に与えていなかったことが原因です。ここを直したことで、安定して日本語を出力するようになりました。

成果物（日本語キャリブ済み HEF と推論アプリ）は、リポジトリで公開しています。

$ python3 -m app.app_hailo_whisper --hw-arch hailo10h --variant base
🎤 ...
おはようございます。今日もよろしくお願いします。

レイテンシは Pi 5 + Hailo-10H で短い発話なら約1〜2秒。74M の小型モデルゆえ固有名詞は苦手ですが（「神戸」が「校部」になる等）、日常会話レベルの日本語であればオフラインで十分実用的に聞き取れます。

リポジトリ: github.com/kobesoft-inc/whisper-base-japanese-hef（MIT）

「考える」中身 — 生成ではなく「検索→選択」

会話の心臓部は、文章を動的に生成しないという割り切りにあります。小型モデルに自由作文をさせると、速度も品質も破綻しがちです。そこで AnimaBox は「あらかじめ用意した回答群から、文脈に最も合うものを選ぶ」という、検索ベースの設計を採りました。

① Rewriter: 来場者の発話を会話履歴とつなぎ、検索用の短いクエリに書き換える。「もっと詳しく」のような指示語・省略を解決する。
② 意味検索: Ruri の埋め込みでクエリに近い質問候補を引く（recall）。言い換えに強い意味マッチ。
③ Reranker: 候補の中から文脈に最も合う回答を小型LLMが選ぶ（precision）。

そのうえで、非力なモデルでも破綻させないための工夫を重ねています。

確信度ゲート: 検索が高確信（コサイン類似 ≥ 0.85）なら Reranker を省略し、検索の1位を即採用。0.5B級の Reranker が正解を壊さないように保護する。
二段エスカレーション: top-10 で決まらなければ top-20 から選び直し、それでも自信が出なければ検索1位へフォールバック。
元発話を必ず残す: 挨拶やお礼は原文が高スコアで勝つようにして、Rewrite の暴走を相殺する。
回答は事前生成済みの音声から再生: LLM に喋り言葉を即興させない。だから品質と速度が安定する。

事前に大きなAIで「調教」しておく

「小さいAIなのに、なぜ的確に答えられるのか」——答えは、会場で動く前にクラウドの大型AIで鍛えてあるからです。会場では一切クラウドを使いませんが、回答データの整備は事前にオフラインで完了させています。

その整備は、人手ではなく自動の稽古ループで回します。

大型モデルが20種の来場者ペルソナ（エンジニアから経営者、いたずら客まで）を演じて MINATO と会話する。
別の大型モデルがその会話を審査（Judge）し、改善点を抽出する。
回答の追加・想定発話の追加・重みの調整・不足インテントの新規作成を仮適用する。
もう一度同じ相手と会話させ、スコアが上がれば採用、下がればロールバックする。

検索が取り違えやすい「近すぎる発話ペア」も自動で検出して調整します。人手のチューニングをループ化したこと、これが小型モデルを実用品質に引き上げた鍵です。

表情・口・視線で「生きている」ように見せる

描画は単一の HTML と three-vrm（WebGL）で動く VRM プレイヤーが担います。WebSocket で「モーション / 表情 / 口形 / 視線」の4ストリームを受け取って駆動する仕組みです。

口形（viseme）: 母音の口形でリップシンク。
視線: 目が先行し、顔が遅れて追従する自然な見方で、検出した来場者の方を向く。
感情ラベル: 回答ごとに9種（neutral / happy / angry / serious / troubled / surprised / shy / sad など）を付与し、表情へ反映する。
ディレクター: カメラの顔検出を状態機械（気づく→惹きつける→会話→見送り）に通し、状態に応じた振る舞いをプレイヤーへ push する。