私たちは現在、パーソナルAIエージェント「ポチっと（Pocchito）」を開発しています。今回は、その初動を小型LLMで担えるかを調べる中で行った、小さな実験を紹介していきます。
パーソナルAIの「わかってくれる」を、小型LLMで検証する——具体例と文脈を分けて試す
「明日の朝9時に、薬を飲むよう知らせて」
人なら、リマインダーを頼まれたと受け取ると思います。
ところが、私たちが試した小型LLM（Qwen3-0.6B）は、この依頼を「雑談」と分類しました。返答はきれいなJSONです。形式は正しい。でも、頼まれたことは受け取れていません。
ポチっとで育てたいのは、ユーザーとの関係
ポチっとは、予定、メモ、リマインダー、探しものなど、日々の頼みごとを手伝うAIエージェントです。
私たちが最も大切にしているのは、ユーザーがポチっととの関係を育てていくことです。
日常の中で話しかける。少しずつ好みを伝える。間違って覚えられたら訂正する。頼んだことを任せられるようになる。
そうした積み重ねによって、「自分のことをわかってくれる」と感じられる存在を目指しています。
長期的には、この関係をスマートフォンだけに閉じ込めたくありません。車載端末や音声インターフェース、ロボット、さまざまなIoT機器でも、同じ記憶や会話の続きを引き継げるようにしたいと考えています。
そのためにも、小型モデルでどこまで処理できるかを、探求していきます。
最初の課題は「何を頼まれたか」
エージェントが動き始めるには、まず今回の発言を理解する必要があります。
たとえば、次の依頼は似ていても、進む処理が異なります。
- 「明日10時に会議を入れて」なら、予定の作成
- 「明日10時に知らせて」なら、リマインダーの設定
- 「明日の会議を11時に変えて」なら、既存予定の変更
- 「11時で」なら、直前に何を話していたかの確認
最後の「11時で」は、特に文脈に依存します。
開始時刻を聞かれている最中なら、その回答として扱えます。突然言われた場合は、何の時刻かを確認する必要があります。
ユーザーとの関係が深まり、短い言葉で会話できるようになるほど、この違いを扱う重要性が増していくと考えています。
具体例と文脈を、別々に試す
今回使ったのは、Qwen3-0.6Bです。公式に公開されているモデルを、手元のGPUで実行しました。公式モデルカード
比較したのは、次の二つです。
- 分類の具体例を与えると、依頼を理解しやすくなるか
- 現在の作業状態や直前の会話を与えると、理解しやすくなるか
この二つを一度に加えるだけでは、どちらが効いたのかわかりません。そこで、4条件に分けました。
| 条件 | 分類の具体例 | 入力する文脈 |
|---|---|---|
| A | なし | なし |
| B | あり | なし |
| C | なし | あり |
| D | あり | あり |
具体例は8件です。入力と、それに対応する分類結果をプロンプトに含めました。今回の比較では、重みの追加学習は行っていません。
モデル、基本の分類指示、ラベル、生成設定は固定しました。各依頼に対する4条件の実行順は、ケースごとに循環させています。
文脈が助ける場合と、邪魔をする場合
診断用の入力は16件です。
12件は、「今日の予定を教えて」「近くのテニスコートを探して」など、発言自体に依頼が表れているものです。この12件の文脈あり条件には、以前の無関係なレストラン検索の会話を加えました。
残る4件は、「11時で」「来週水曜」「90分」「18時に変えて」という短い返答です。こちらには、現在進めている予定の作成・変更と、直前の確認質問を加えました。
つまり、見たいのは単に「過去の会話を多く渡せばよいか」ではありません。
必要な文脈を使い、無関係な文脈に引っ張られずに、今回の発言を受け取れるかを確認しました。
短い4件は、文脈なしでは「依頼が曖昧」、文脈ありでは「現在の予定作業への回答」を期待する、と実行前に決めています。
結果は、具体例と文脈の組み合わせで変わった
16件を4条件で試し、計64回の分類を行いました。
| 条件 | 全体の正解 | 明示的な依頼 | 短い返答 |
|---|---|---|---|
| 具体例なし・文脈なし | 6/16 | 6/12 | 0/4 |
| 具体例あり・文脈なし | 11/16 | 11/12 | 0/4 |
| 具体例なし・文脈あり | 6/16 | 5/12 | 1/4 |
| 具体例あり・文脈あり | 14/16 | 11/12 | 3/4 |
今回の条件では、具体例を加えると、明示的な依頼の分類が改善しました。
一方、文脈を加えただけでは、全体の正解数は増えませんでした。短い返答で1件改善したものの、無関係な過去の会話を加えた明示的依頼で1件悪化しています。
具体例と文脈の両方を与えた条件では、短い返答も3件理解できました。
文脈を渡すだけでなく、その文脈を分類にどう使うかも伝える必要がある。今回の結果からは、その可能性が見えました。
JSONが正しくても、依頼の理解は間違う
64回の返答は、すべて有効な分類用JSONでした。
しかし、最も正解が多かった条件でも、冒頭の「薬を飲むよう知らせて」は雑談に分類されました。
もう一つ残ったのは、予定変更の入力中に答えた「18時に変えて」です。期待したのは現在の作業への回答でしたが、新しい予定変更の依頼として分類されました。
この違いは、実際の体験に影響します。入力中の内容が引き継がれず、同じことを説明し直す場面につながるためです。
分類結果を受け取る側でも、現在の作業状態や確認済みの内容を扱う設計が必要になります。
今回わかった範囲
これは、自分たちで作成・ラベル付けした16件による開発用の診断です。12件は以前にも使用した入力で、独立した正式評価はまだ行っていません。
また、分類の具体例は全ラベルを均等に網羅していません。各条件は1回ずつの実行です。
そのため、14/16という結果を、そのまま一般的な正答率として扱うことはできません。今の目的は、入力や例示のどこを変えると挙動が変わるかを見つけ、次に検証する仮説を作ることです。
外部の推論APIやクラウドGPUは使わず、既存のモデルキャッシュと手元のGPUで実行しました。
次に調べたいこと
次は、今回残った二つの境界を、別の確認用ケースで調べます。
- リマインダーの依頼と、雑談・相談の区別
- 新しい変更依頼と、進行中の作業への回答の区別
例示の追加によって、一部の分類だけがよくなり、別の分類が悪化することも考えられます。全体の正解数に加え、どの入力が改善し、どの入力が悪化したかを追っていきます。
こういう問題を、一緒に考える人と出会いたい
私たちが取り組んでいるのは、ユーザーと長く付き合えるパーソナルAIです。
何を覚えるか。どの場面で思い出すか。今の発言と過去の記憶が食い違ったらどうするか。そして、理解した内容をどう確認し、実際の行動につなげるか。
モデルの評価、記憶と文脈の設計、バックエンド、アプリの体験がつながっているところに、この開発の面白さがあります。
今後も、実験したことや失敗したことを少しずつ公開していきます。小型LLMやエージェント、ユーザーとの関係を育てるプロダクトづくりに関心のあるエンジニアの方と、お話しできればうれしいです。ポチっと · お問い合わせ · 採用ページ
本の紹介
そして、こちらの本も絶賛販売中です。 LLM周りの話をまとめています、LLMをもっと理解したい方は是非一度頂けましたら幸いです。