スマホアプリの継続率を上げるために通知や無限スクロールを設計に組み込む。この定番パターンに疑問を持ったことがあるフロントエンドエンジニアに向けた内容です。Hacktoberfest（10月に開催されるオープンソース貢献を促すイベント）のOpen Source AI Challengeに投稿された「TerraLens」という個人開発プロジェクトが、その疑問に具体的な実装で答えています。
TerraLensは、ユーザーに外出や観察を促す「オフラインファースト」のAIフィールドコンパニオンです。オフラインファーストとは、ネットワーク接続を前提にせず、端末内で主要な機能が完結するよう設計する考え方を指します。チャットボットのような「何でも聞いてください」という入力欄を中心に置かず、1つのミッション（例：「葉の縁の形が違う葉っぱを2枚見つける」）を提示したら、UIのほとんどを隠す「Touch Grass Mode（タッチグラスモード）」に切り替わる点が特徴です。
この設計思想は、日本のアプリ開発でも無関係ではありません。アプリの滞在時間（セッション継続時間）をKPIにする設計から、ユーザーの行動変容を目的にする設計への転換が必要になる場面は増えています。今回は、こうした「エンゲージメントを目的にしないAI UI」を自分のプロダクトに取り入れるべきかどうかを判断する軸を整理します。
どんな場面でこの判断が必要になるか
健康管理アプリ、学習アプリ、瞑想アプリなど、本来は「使う時間を減らすこと」が成功指標になり得るカテゴリーのプロダクトを担当しているなら、この判断は避けて通れません。
たとえば歩数計アプリやマインドフルネスアプリで、プッシュ通知とストリーク（連続記録）機能だけでリテンション（継続利用率）を稼ごうとすると、本来の目的と利用者の体験がねじれてきます。TerraLensのように「画面を見る時間を減らすことに成功する」設計を検討すべきタイミングです。
判断軸1: コア体験がオンライン依存かどうか
TerraLensはオフラインファーストで設計されています。ミッションの提示やローカルの「ネイチャージャーナル」への記録は、ネットワークなしで完結する想定です。
自分のプロダクトのコア体験が、サーバー側のLLM（大規模言語モデル）推論に強く依存している場合、完全なオフラインファースト化は難しくなります。画像認識や音声認識の一部をオンデバイスで動かす設計（WebAssemblyやTensorFlow Lite、Core MLなどを使う構成）に寄せられるか、まず技術的な棚卸しが必要です。
具体的には、現状のAPI呼び出しのうち「即時性が求められないもの」をリストアップしてみてください。画像の植物判定のように数秒の遅延が許容される処理なら、オンデバイスモデルへの置き換えやキャッシュ戦略の余地があります。
判断軸2: 成功指標をどこに置けるか
TerraLensは「Grass Score」という独自指標を導入し、画面を見ない時間や物理的な発見の数を評価軸にしています。通常のDAU（デイリーアクティブユーザー数）やセッション時間とは逆方向の指標です。
自社プロダクトのビジネスモデルが広告収益やサブスクリプションの継続率に強く紐づく場合、こうした「離脱を促す指標」を経営層やプロダクトオーナーに通してもらうハードルは高くなります。一方で、ヘルスケアやウェルビーイング領域のように、ユーザーの行動変容そのものが価値提案になっているプロダクトなら、指標の再設計は十分検討に値します。
判断軸3: チャットUIを捨てられるか
TerraLensが明確に避けたのは、中央に大きな入力欄を置く典型的なチャットボットUIです。代わりに、1つのミッションカードと「GO FIND IT」ボタンだけを見せるミニマルな画面構成を採用しています。
これはReactやVueでチャットUIライブラリ（Vercel AI SDKのuseChatフックなど）を前提に設計を始めているチームにとって、相応の作り直しコストを意味します。既存のチャットベースの資産をどこまで捨てられるか、見積もっておく必要があります。
判断軸4: 開発体制がプロトタイプ規模かプロダクション規模か
TerraLensは個人開発によるHacktoberfestの投稿作品であり、スケールやセキュリティ要件を厳密に検証したプロダクションサービスではありません。この点は見落とさないほうがよい判断材料です。
参考にする場合は「UXのコンセプト」として取り入れ、認証基盤やデータ永続化の実装は自分たちのプロダクション要件に合わせて別途設計する前提で評価してください。
| 観点 | チャットボット型UI | TerraLens型(ミッション提示+UI隠蔽) |
|---|---|---|
| 主目的 | 対話の継続 | 物理世界での行動喚起 |
| 成功指標の方向 | セッション時間・DAU | 画面を見ない時間・行動完了数 |
| オフライン対応の必要度 | 低〜中(サーバー依存可) | 高(オフラインファースト前提) |
| 既存UIライブラリ流用 | 流用しやすい | 作り直しコストが高い |
ケース別の推奨
学習アプリや習慣化アプリで、ユーザーの「現実世界での行動」が成果指標になっているなら、TerraLens型のミッション提示UIを部分的に取り入れる価値があります。まずは通知を減らし、1回のセッションで提示するタスクを1つに絞る実験から始められます。
広告収益モデルでセッション時間が直接収益に結びつくプロダクトの場合、Grass Scoreのような「離脱を評価する指標」の全面導入は収益構造と矛盾します。この場合はUIのミニマル化だけを部分採用し、指標設計には手を付けない選択肢が現実的です。
カスタマーサポートやナレッジ検索のように、ユーザーが素早く答えを得ることそのものが価値であるプロダクトなら、TerraLensの思想とは目的が異なります。チャットUIを維持したまま、回答精度や応答速度の改善に投資するほうが合理的です。
あえて見送るべき条件
コア機能がリアルタイム性の高いサーバー推論に依存しており、オンデバイス化のコストが見合わない場合は、オフラインファースト化を急ぐ必要はありません。
また、プロダクトのKPIがすでに経営層と合意されたエンゲージメント指標で固定されている段階で、指標そのものを変える提案をするのは現実的ではないケースが多いです。UIの一部機能(通知頻度の調整など)から小さく試すほうが摩擦が少なくなります。
個人開発レベルの検証にとどまっているプロジェクトを、検証なしにプロダクション設計の土台にするのも避けたほうが無難です。まずは自社の小規模な機能追加としてA/Bテストできる範囲から試すのが安全です。
まとめ
TerraLensが示したのは、AIアプリの成功指標を「利用時間」から「利用後の行動」に反転させる設計アプローチです。自分のプロダクトに取り入れるかは、オンライン依存度・成功指標の置き場所・UI資産の作り直しコスト・開発体制の4つの軸で判断できます。
次の一歩としては、現在のプロダクトのAPI呼び出しの中でオンデバイス化できそうな処理を1つ洗い出し、通知頻度を1段階下げる小さな実験から試してみてください。