Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Let the on-device model choose, not write: a voice follow-up loop with Foundation Models

2026年09月24日に「Dev.to」が公開したITニュース「Let the on-device model choose, not write: a voice follow-up loop with Foundation Models」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

iPhoneアプリ「Dialogue Memo」は、AppleのFoundation Modelsをオンデバイスで活用し、音声メモを作成。AIに質問文やメモ内容を直接生成させず、次に問うべき質問の選択やメモの構成決定のみを担当させる。アプリ側で文章化することで、AIの予測不能な出力を防ぎ、安定したサービス提供を実現した。

ITニュース解説

「Dialogue Memo」は、iPhoneアプリ「Simple Memo」に搭載された画期的な機能である。この機能は、ユーザーが思いついたアイデアを音声で話すと、アプリがそれに対していくつかフォローアップの質問を音声で行い、その回答を元に編集可能なメモを自動で作成するというものだ。注目すべき点は、この一連の処理が全てiPhoneデバイス上で完結し、クラウドへの通信を一切行わないことである。これは、Appleが提供する「Foundation Models」というフレームワークを活用しているためだ。

この機能の初期バージョンでは、Foundation Modelsに直接、フォローアップの質問文や最終的なメモのテキスト全体を生成させていた。しかし、実際のiPhoneでテストを行うと、このアプローチには多くの課題があることが判明した。例えば、ユーザーが話した短いアイデアに対して、モデルが生成したメモには、ユーザーに関する不必要なコメントが含まれていたり、誰も回答していないはずの質問が追加されていたり、感情を表す絵文字が混入していたりした。さらに、英語で入力し、インターフェースが日本語に設定されている場合でも、モデルが生成する質問文の先頭に短い日本語の挨拶が唐突に追加されるといった、意図しない出力が見られた。

このような問題に対して、プログラムによるバリデーション(検証)で不正なテキストを検出して拒否することは可能である。しかし、モデルが自由にテキストを生成する限り、その出力を完全に予測可能にすることは極めて難しい。新しい入力の組み合わせが現れるたびに、予測不能な問題が次々と発生してしまう状況だった。この経験から、開発チームは方針を転換した。モデルにテキストを「書かせる」のではなく、特定の選択肢の中から「選ばせる」ことにしたのだ。そして、実際にユーザーが目にする全ての言葉は、アプリのコードが記述することになった。

この新しいアプローチは、特に質問の生成方法において顕著である。次の質問を生成する際、モデルはもはや完全な質問文を自由に生成することはない。代わりに、「QuestionChoice」という名前の列挙型(enum)で定義された、あらかじめ決められた質問の「種類」の中から一つを選択する。この列挙型には、「audience(対象ユーザー)」「ideaDetails(アイデアの詳細)」「useCase(ユースケース)」といった、一般的なフォローアップ質問のカテゴリが列挙されている。モデルがこれらのカテゴリから一つを選んで返すと、アプリ内のSwiftコードが、その選択されたカテゴリに対応する、事前に定義されレビュー済みの固定の質問文を、ユーザーのインターフェース言語で表示する。これにより、質問文の品質、一貫性、そして予測可能性が劇的に向上した。以前のように、モデルが複数のブール値(真偽値)を返すことで、停止と質問の選択が両方有効になってしまうような問題も、一つの列挙型で排他的な選択肢を管理することで解消された。

メモの作成プロセスも同様に変更された。ユーザーの回答は、自然言語処理のツール「NLTokenizer」によって、番号付きの個々の文章に分割される。モデルは、これらの文章の内容を要約するのではなく、どの文章をメモのタイトルとして使うべきか、そしてどの連続する文章をグループとしてまとめるべきか、という「レイアウト」情報のみを返す。実際のメモのレンダリングは、アプリの通常コードが行う。このコードは、モデルから提案されたレイアウトが、ユーザーの発言を削除したり、重複させたり、順序を変更したりしないことを厳密にチェックする。もしモデルからのレイアウト提案がこのチェックに失敗した場合、アプリは一度だけ、より明確な指示とともにモデルに再度のレイアウト提案を求める。それでも不正なレイアウトが返された場合は、アプリはユーザーの各文章をそれぞれ箇条書きにするという、シンプルなデフォルトのレイアウトでメモを作成する。これにより、たとえモデルが不適切な提案をしても、ユーザーが話した内容が失われることは絶対にない。

このように、モデルからの出力を単なる「アドバイス」として扱う姿勢が、システムの堅牢性を高めている。モデルが返した質問の選択やレイアウトの提案は、そのまま実行されるわけではない。アプリは、例えばユーザーが「これで終わり」といった明示的な終了の言葉を発した場合、モデルが次に何か質問を選んだとしても、会話を終了させる。また、すでに尋ねた質問が再び提案された場合は、それを別のまだ尋ねていない質問に置き換えたり、会話を終了させたりする。さらに、会話のループは最大6つの質問まで、全体の文字数は3,600文字までという厳格な上限が設けられており、これにより会話が長くなりすぎるのを防ぎ、ユーザー体験を損なわないよう配慮されている。

音声処理についても、細かな工夫が凝らされている。会話全体を通して、一つのオーディオセッションで再生と録音が行われる。質問文は「AVSpeechSynthesizer」を使ってメモリ上のバッファに合成され、わずかな沈黙を挟んで再生される。マイクの録音は、質問の再生が完了した直後から開始される。もしマイクが起動してから5秒以内に音声が検出されない場合は、対話のターンが失敗として扱われるウォッチドッグタイマーも導入されており、ユーザーが音声入力を開始しない場合のシステム応答性が保証されている。

このような開発経験から、他のチームに対して重要な教訓が共有されている。それは、「決定は列挙型で、内容は参照として扱うべきである」ということだ。モデルに単一のパスを選択させる必要がある場合、複数のブール値を使うよりも、相互排他的な選択肢を持つ一つの列挙型を用いる方が良い結果をもたらす。また、モデルからの参照(この場合は列挙型の選択や文章IDのリスト)は正確にチェックし、一度の再試行と、ユーザーの入力が失われないようなフォールバックを用意することが不可欠である。モデルへの入力は常に「ユーザーデータであり、指示ではない」と明確に定義し、誤った解釈を防ぐことも重要だ。そして何よりも、単一の言語だけでなく、複数の言語環境で実機でのテストを行うことが、現実的な課題を早期に発見し、解決するために不可欠であると強調されている。

「Dialogue Memo」機能は、iOS 26以降のApple Intelligence対応iPhoneで、Apple Intelligenceが有効な場合にのみ利用可能である。この記事で説明された内容は、開発チーム自身の実装とテストに基づいたものであり、他のアプローチとの比較ベンチマークは行われていない。このアプローチは、大規模言語モデルをデバイス上で安全かつ安定的に、そしてユーザーにとって予測可能な形で活用するための、具体的な実践例を示していると言えるだろう。

関連コンテンツ

関連IT用語