前提：なぜスマホローカルLLMが面白いのか

プロンプト：8GBスマホでGemma 4 E2Bが動く——プライベート音声メモアプリの実装詳解（記事内画像）

クラウドAPIは速い。精度も高い。だが、音声メモには個人情報が混入する。「歯医者に明日3時に電話」「帰りに牛乳を買う」——こういった断片的な発話は、日常の行動パターンそのものだ。それをクラウドに送り続けることへの抵抗感は、ユーザーとして当然ある。

そこへ、Sourceの報告が現れた。Reddit /r/LocalLLaMAに投稿されたこのスレッドで、開発者 /u/Effective-Drawer9152 は数ヶ月間にわたるオンデバイス運用の結果を詳細に記述している。モデルはGemma 4 E2B（2.4GB）、端末はOnePlus CE 5（RAM 8GB）。構成はシンプルだが、実装の密度は高い。

筆者が注目したのは「JSON出力の品質」という一点だ。2.4GBのモデルがスマートフォン上で構造化JSONを安定して返す——この事実は、プロンプトエンジニアリングの文脈でも重要な示唆を持つ。

アーキテクチャ：2モデル構成とその役割分担

実装は2モデルで構成される。

Whisper Small（244MB）：音声文字起こし担当。Sherpa-ONNXを経由してオンデバイス推論。10〜15秒の音声に対して約5秒で文字起こしを完了する。

Gemma 4 E2B（2.4GB）：テキスト分類・構造化担当。LiteRT-LMを経由して推論。文字起こし結果を受け取り、アイテム分割・タグ付け・時間解決を行う。処理時間は約8〜10秒。

エンドツーエンドのレイテンシは12〜15秒。内訳はWhisper 5秒＋Gemma 8〜10秒＋モデルロード・DB書き込み・UI遷移。実用上許容できるかどうかはユースケース次第だが、「音声メモを残す」という行為のUXとして、15秒以内であれば許容範囲と見る開発者は多いはずだ。

データ永続化にはRoomを使用。Androidネイティブの構成として自然な選択だ。クラウドへのデータ送信はゼロ、アカウント登録も不要——これがアーキテクチャの核心にある設計思想だ。

検索設計：クエリ展開とRRFによる精度担保

音声メモアプリの本質的な価値は「後から探せること」にある。この実装では、検索時に以下の処理が走る。

まずクエリ展開。「先週歯医者について何と言ったか」というユーザーの自然言語クエリを、キーワードと仮説的な例示アイテムに書き換える。これはHyDE（Hypothetical Document Embeddings）の思想に近い手法と推測される。

次に複数のFTS（全文検索）レーンを並列実行し、結果をRRF（Reciprocal Rank Fusion）でマージする。RRFは複数ランキングを統合する手法として検索品質の安定に寄与する。

さらにオプションとして、上位K件に対してGemmaによるリランキングパスを実行する。タイムアウトは15秒。時間内に完了しない場合はRRF順位にフォールバックする設計だ。このフォールバック設計は実用システムとして重要な判断だ。Gemmaのリランキングが常に完了するとは限らない——その現実を受け入れた上で、劣化グレースフルに設計されている。

プロンプトエンジニアリングの観点で言えば、Gemmaへの入力設計がここで効いてくる。分類プロンプトと検索リランキングプロンプトは、おそらく異なる構造を持つはずだ。前者は「アイテム分割＋タグ付け＋時間解決」という複合タスクを1プロンプトで処理させる。後者は「上位K件の順序付け」という比較タスクだ。2.4GBのモデルにこれだけの処理を任せるには、プロンプトの構造が出力品質を直接決定する。

// 分類プロンプトの推定構造（原文未公開のため推測）
You are a note parser. Given a voice note transcript, output JSON.
Split into separate items. For each item:
- "content": the item text
- "tag": one of [reminder, buy, task, other]
- "time": resolved ISO datetime or null

Transcript: {{transcript}}

Output JSON array only. No explanation.

「Output JSON array only. No explanation.」という末尾指示が、スマホサイズモデルのJSON出力安定性に大きく寄与している可能性がある。小さいモデルほど、出力形式の明示的な制約が効く。これは筆者の経験則とも一致する。

職人の視点：1単語の差が出力構造を変える

「JSON出力がクリーンで驚いた」という開発者の感想は、プロンプト設計の成果でもある。2.4GBモデルに構造化出力を安定して返させるには、プロンプトの末尾に何を置くかが決定的だ。

「Return JSON」と「Output JSON array only. No explanation.」は、見た目は似ているが出力結果が異なる。前者は説明文が混入するリスクがある。後者は出力形式を2つの制約で挟んでいる——「array only」で型を固定し、「No explanation」で余分なテキストを排除する。

小さいモデルで構造化出力を安定させるための原則を整理する。

1. 出力形式を型レベルで指定する（「JSON」ではなく「JSON array」）
2. 禁止事項を明示する（「No explanation」「No markdown」）
3. フィールド定義をプロンプト内に完全記述する（モデルに推測させない）
4. 入力変数は最後に置く（指示の後に入力を渡す）

これらは大きなモデルでは「あってもなくても大差ない」ことがある。だが2.4GBのモデルでは、各指示の有無が出力の構造的整合性に直結する。差は数%ではなく、パースエラー率の大幅な変動として現れる可能性がある。

結論：エッジAIの現在地と次の問い

この実装が示すのは「スマホでLLMが動く」という事実だけではない。「適切なプロンプト設計があれば、2.4GBのモデルが複合タスクを処理できる」という実証だ。

開発者はカテゴリ分類の精度について「おもちゃのメモではなく実際のメモでも悪くない」と述べている。定量的な数値は公開されていないが、数週間の実運用を経た評価として信頼性は高い。

筆者が次に検証したいのは、分類プロンプトのビフォーアフターだ。「tag: one of [reminder, buy, task, other]」というラベル定義を変えると分類分布はどう変わるか。「other」カテゴリの比率が高い場合、ラベル設計の見直しが精度向上の最短経路になる。

この実装を自分のデバイスで再現したい読者は、まず分類プロンプトの末尾指示から設計を始めるべきだ。モデルサイズが小さいほど、プロンプトの構造が出力品質の天井を決める。その天井を1単語ずつ上げていく作業——それがエッジAIプロンプトエンジニアリングの本質だ。

関連リンク

  • Gemma 4 E2B（Google DeepMind）：Googleが開発したエッジデバイス向けオープンモデル。E2B/E4BはモバイルやIoT向けに設計されている。
  • Sherpa-ONNX（GitHub）：インターネット接続不要でAndroid/iOSを含むマルチプラットフォームに対応するオンデバイス音声認識フレームワーク。