端末内LLMで、アプリのどの仕事を引き受けられるか

モデルを載せた後、利用者は何を短く済ませられるか

端末内でLLMが動くと、アプリは通信せずに文章を扱う選択肢を持てる。だが、モデルを呼び出せることと、利用者の仕事が短くなることは別だ。長いメモを要約する、メールから予定候補を抜き出す、記録に分類タグを付ける。こうした操作なら、入力、期待する結果、誤りを直す場所をアプリ側で具体化できる。

AppleのFoundation Models文書も、要約、人物や場所の抽出、文章の編集、分類などを端末内モデルの用途として挙げる。モデルの存在を見せるために新しい会話画面を作るだけでなく、既存のメモや編集画面へ一つの操作として組み込める。筆者は、こうした用途を絞った機能を、端末内LLMの導入を判断する単位にしたい。

「小さいモデル」という括りにも注意が必要だ。Appleが6月に発表した第3世代モデル群では、AFM 3 Coreは30億パラメーターの密なモデルで、AFM 3 Core Advancedは総数200億のうち要求に応じて10億〜40億を使う構造と説明されている。総数と一度に使う規模は異なる。さらにモデル群の発表から、すべてのアプリがすべてのモデルを選べるとは言えない。導入時にはAPIが提供するモデルと対応端末を確認し、機能の結果を評価する必要がある。

Androidでは、用途を絞ったAPIと自由な指示を選べる

ML KitのGenAI Prompt APIは、Gemini Nanoへ独自の指示を渡し、文章や画像から結果を生成する。公式文書は、自由度の高いPrompt APIと、要約・校正・書き換え・画像説明に調整されたAPIを比較している。前者では指示の設計と品質確認が増え、後者では出力の形や用途が限定される代わりに実装を始めやすい。

たとえば、Summarization APIは記事や会話を1〜3項目に要約する。日本語も対応言語に含む。ただし、使える言語と機能の組み合わせは端末の設定やダウンロード済みモデルによって変わるため、実行時に確認する必要がある。「この会議の決定事項だけを、担当者と期限を付けて抽出する」といった独自の結果が必要なら、固定した箇条書きの要約とは異なる機能として設計することになる。

筆者なら、必要な結果が既存の専用APIに収まる場合は、まずその結果で利用者の操作を減らせるか確かめる。独自の抽出や分類が必要な場合に、自由な指示へ進む。自由度を増やすほど、誤りの種類と修正する画面を自分たちで定める仕事も増える。モデルへの入口が共通でも、機能を完成させる負担は同じではない。

アプリのデータ型へ接続しても、内容の正しさは残る

自由な文章をそのまま画面へ貼るだけでは、予定の日時や分類先を安定して扱いにくい。Appleのguided generationは、アプリが定義したSwiftのデータ型へ結果を生成する仕組みを提供する。文字列の解析を減らし、日時の候補、人物名、要約などを別々の欄に表示する構成を作れる。

AndroidにもKotlinの型と注釈で結果を指定するStructured Output APIがある。調査日の文書ではPrompt APIがベータである一方、この構造化出力はアルファとして案内され、独自の利用可否確認も必要だ。両者を同じ公開段階として扱わず、必要な機能が対象端末で実際に使えるかを調べる必要がある。

型に合う結果が返ることは、元の文章に忠実な結果が返ることとは違う。日時欄に形式の整った値が入っていても、その日付を原文が指定していない場合がある。候補の表示や保存処理へ接続しやすくなった分、元の記述との対応を確認する仕事が明確になる。構造化出力を、意味の正しさや実行済みの証明として扱わないことが重要だ。

メモから予定候補を作る、という一つの機能で考える

ここからは、実装を説明するための仮想例である。メモに「明日15時に田中さんとオンラインで打ち合わせ」とあるとき、端末内モデルが人物、時刻、場所の候補を抽出する。アプリは原文を候補の隣に表示し、「明日」を解釈する基準の日付と時間帯を示す。メモを書いた日と処理した日が違う場合には、基準を勝手に決めて保存しない。

利用者が日時を直し、保存を押して、カレンダー側の処理が成功してから予定を追加したと表示する。モデルの出力は予定候補であり、保存の事実はアプリの処理結果である。予定がない文章や「来週あたり相談したい」のような曖昧な文章には、無理に確定した日時を作らず、未確定の候補や抽出なしとして返す設計が必要になる。

この機能なら、文字を読み取る処理、候補を作る処理、利用者による修正、カレンダーへの保存を別々に評価できる。確認時間が長ければ、抽出精度が高くても利用者の仕事は短くならない。元の文章を失わず、候補を直して通常の操作へ戻れることまでが、ネイティブアプリへの組み込みの価値になる。

端末内で推論することと、機能全体が端末内で完結すること

Appleの現行Foundation Models frameworkは、端末内モデルに加え、Private Cloud Computeや他社のサーバーモデルを同じSwift APIで扱う。Dynamic Profilesでは一つのセッション内でモデル、指示、道具を切り替える構成も示されている。したがって、フレームワーク名だけを見て、入力がすべて端末内で処理されるとは判断できない。

さらに道具の呼び出しは、アプリが用意したコードから情報を取得したり、操作を実行したりできる。モデル自体が端末内にあっても、道具がネットワークへ送信する設計なら、機能の一部は端末外へつながる。解析用のログやクラウド同期も含めて、元の文章、抽出結果、会話の履歴がどこへ渡るかを確認する必要がある。

端末内推論には、モデルサーバーへ入力を送らずに処理できるという具体的な利点がある。その利点を利用者へ説明するなら、実際の経路を説明に合わせたい。端末内で完結すると案内した機能を、使えない端末で黙ってクラウドへ切り替えれば、機能の約束が変わる。クラウド処理を提供する場合は、送る対象と切り替え条件を明確にして選べるようにする。

非対応、準備中、利用制限も通常の画面で扱う

Appleの文書は、端末や地域の対応、Apple Intelligenceの設定、モデルのダウンロードによる利用可否を確認し、使えない場合の代替体験を用意するよう求める。ML Kitの開始手順にも、利用不可、ダウンロード可能、ダウンロード中、利用可能という状態がある。対応する機種を持っていることと、今この操作を実行できることは同じではない。

ML Kitの概要では、端末によってGemini Nanoの版が異なり、同じ指示でも出力が変わり得ると説明されている。また、アプリごとの推論量や電池使用量の制限があり、推論は最前面のアプリでのみ許可される。フォアグラウンドサービスでも、アプリが最前面にない場合の利用は認められない。画面を閉じた後も大量のメモを処理し続ける構成には、この制約が影響する。

要約が使えないときにも、元のメモの閲覧や編集を続けられるようにする。準備中なら準備中と伝え、繰り返し押しても同じ処理を重ねない。処理中に利用者が別のメモへ移った場合は、遅れて返った結果を新しいメモへ上書きしない。こうした制御はモデルの正答率からは測れないが、普段のアプリ機能として使うには欠かせない。

日本語の品質と、修正を終えるまでの時間を測る

Appleの言語対応文書は、実行時の言語確認を提供する。対応言語であることは、そのアプリの入力に十分な精度があることを意味しない。日本語の予定抽出なら、相対日付、和暦、敬称、主語の省略、複数人の予定、予定のない文章を含め、誤った候補を生成する条件を調べたい。

Googleの品質評価手順は、用途ごとの入力と期待結果を用意し、Gemini Nanoの各版で結果を評価するよう勧める。AppleのEvaluations frameworkも、機能のデータセットと評価指標を扱う。予定抽出なら日時や人物の誤り、要約なら重要な条件の欠落を測る。型に合ったか、文章が自然かだけでは、利用者が誤りを直す負担を測れない。

速度も、最初の文字が出るまでと、結果を確認して操作を終えるまでを分ける。AppleのInstrumentsによる調査例は、入力処理、生成、道具の呼び出し、全体の遅延を追う方法を示している。実機では初回のモデル準備、長文、連続利用、電池消費も確認したい。この記事では実機比較を行っていないため、端末内モデルが常に速い、あるいは省電力だとは結論しない。

筆者なら、まず一つの機能について、通常の手入力や既存の専用処理と比較する。失敗、利用不可、取り消し、人による修正を含めて、目的の操作を完了した割合と時間を記録する。端末内LLMの価値は、モデルの規模を小さくしたことに加えて、利用者が結果を確かめ、直し、次の操作へ進むまでをアプリが引き受けられるかで判断したい。