シンプルな位置ベースのプロンプト用モバイルアプリの作り方

「位置ベースのプロンプト」とは（事例付き）

位置ベースのプロンプトは、ユーザーがある実世界の場所に入ったり出たりしたときにアプリが表示するメッセージです。時間に依存するリマインダーではなく、「どこにいるか」に紐づくリマインダーだと考えてください。

簡単な定義

基本的には、位置ベースのプロンプトは三要素から成ります：

• 場所（例：「自宅」や「スーパーマーケット」）
• トリガー（到着、退出、滞在）
• プロンプト（短いメッセージやチェックリスト）

例：「薬局に着いたら処方薬を受け取るのをリマインドして」

よくある実用的なユースケース

位置ベースのプロンプトは、コンテクストが重要な日常のちょっとした促しに向いています：

• リマインダー: 「会社を出たら整備工場に電話する」
• チェックリスト: 「ジムに着いたら：水筒、タオル、ロック」
• 安全メモ: 「登山口に着いたら：友人に現在地を共有する」
• 習慣づけ: 「家に着いたら：ビタミンを飲む」

ポイントは、ユーザーが行動しやすい瞬間（すでに正しい場所にいるとき）に表示されることです。

このガイドでの“シンプル”の意味

“シンプル”は品質が低いという意味ではなく、焦点を絞るという意味です：

• 明確な単一トリガー（到着／退出）
• 基本的なルールセット（どの場所、どんなメッセージ、場合によっては時間窓）
• 最小限のセットアップ（数タップで完了、複雑なオートメーションビルダーはなし）

IFTTTのような完全な「もし〜なら〜」システムを作るのではなく、信頼できるリマインダーツールを作ります。

このガイドがカバーすること（としないこと）

このガイドはアイデアからリリースまでを扱います：MVPの定義、アーキテクチャ選定、権限の扱い、効率的な位置検出、良いUXでのプロンプト配信、プライバシーを考慮したリリース。

逆に扱わない領域：高度なルーティング、ターンバイターンナビ、ソーシャルな位置共有、高頻度トラッキングを必要とするフィットネス分析—これらは複雑さ、バッテリー要件、プライバシー期待を大きく変えます。

まずはMVPから：トリガー、プロンプト、ルール

位置ベースのプロンプトのMVPは「完全版の小型版」ではありません。明確な約束です：ある場所に到達したときに、バッテリーを浪費したりスパム的になったりせずに、役立つ形で確実に通知すること。

最初に定義すべきはトリガーの種類、プロンプトの形式、そして体験を健全に保つためのルールです。

トリガーの種類を選ぶ

初期リリースは一文で説明できるトリガーに絞りましょう：

• Enter（到着）: 半径内に入ったときに発火（例：「スーパーで」）
• Exit（退出）: 出たときに発火（例：「オフィスを出たら」）
• Dwell（滞在）: 一定時間滞在した後に発火（例：「ジムに10分いたら」）
• 時間窓: トリガーを発生させる時間帯を制限（例：平日8時〜18時）

迷ったら、まずは Enter + 時間窓 で始めましょう。多くのリマインダー用途をカバーし、エッジケースを抑えられます。

プロンプトの形式を決める

主な配信方法を1つとフォールバックを1つ選び、他は後回しにします。

• 通知: 即時でハンズオフのリマインダーに最適。アクション（例：「完了にする」「スヌーズ」）をつける。
• アプリ内カード: 既にアプリを開いているときに文脈と履歴を出すのに便利。
• ウィジェット: 便利だが表面積とQAが増えるため、第2フェーズで検討。

実用的なMVPの組み合わせは 通知 + アプリ内カード：通知で注意を引き、アプリで何が発火したかを示します。

「通知地獄」を防ぐ制限を設ける

単純なリマインダーアプリでもガードレールが必要です：

• 保存場所の上限: 初期は20〜50件程度に制限してパフォーマンスとテストを簡単にする
• 半径の範囲: 100m〜1kmなどの妥当な範囲を強制して常時発火する設定を防ぐ
• 頻度上限: 1地点あたり「X分以内は再発火しない」や「同じ場所で同時に1つのアクティブなプロンプトのみ」など

これらの制限でアプリは配慮された印象を与えられます。

MVPの成功指標を事前に決める

機能を追加する前に「動いているとは何か」を測る指標を決めます。初版では次のような定量的シグナルに集中してください：

• 有効化率: インストールのうち1つ以上プロンプトを作成した割合
• プロンプト保存数: アクティブユーザー1人あたりの平均プロンプト数
• リテンション: 新規ユーザーが最初の週を過ぎても戻ってくるか

これらが改善すれば、トリガー種別の拡張、ウィジェット追加、スマートなスケジューリングなどを検討する価値が出ます。

技術スタックとアプリのアーキテクチャ選び

技術選定は一つの問いに応じるべきです：アプリはどれだけ確実に場所関連のトリガーを検知してプロンプトを表示できるか——しかもバッテリーを浪費せず、ユーザーを混乱させない形で。

ネイティブ vs クロスプラットフォーム

ネイティブ（iOS: Swift + Core Location、Android: Kotlin + Location APIs） はバックグラウンドでの位置動作やOSの制限、デバッグの予測性が高く、最も確実に動作する傾向があります。チームが各プラットフォームに慣れていれば、最短で「どこでも動く」MVPに到達しやすいです。

クロスプラットフォーム（Flutter、React Native） はUI開発を高速化しコードベースを一本化できますが、位置関連機能はプラグインに依存するため、バックグラウンド制限や端末メーカー特有の挙動、OSアップデートの際にネイティブコードの修正が必要になることがあります。

実用的なルール：位置トリガーが主要機能なら、チームが既にクロスプラットフォームで位置機能を扱った経験がない限りネイティブをデフォルトにするのが安全です。

迅速にプロトタイプを作りたい場合やイテレーションを早く回したい場合、チャットベースの仕様から動くアプリを生成するようなプラットフォーム（例：Koder.ai）を使ってFlutterでプロトタイプを生成し、必要に応じてバックエンドにGo + PostgreSQLを使う選択肢もあります。

出せるシンプルなアーキテクチャ

MVPは小さく保ちます：

• モバイルアプリ: プロンプトの作成、トリガー監視、通知表示を担当
• ローカルストレージ: SQLite/Room（Android）、Core Data/SQLite（iOS）などの軽量DB層
• バックエンド（任意）: 本当に必要なら追加

この構成はオフライン利用にも自然に対応できます。

本当にバックエンドが必要になるとき

マルチデバイス同期、共有リスト（家族・チーム）、分析、サーバー駆動の実験が必要になったらバックエンドを追加します。それまではバックエンドはコストとプライバシーと障害点を増やすだけです。

バックエンドを導入する場合は境界を明確に：同期に必要なオブジェクトだけを保存し、トリガー判定は可能な限り端末側で行うのが望ましいです。

データモデルの基本

コアオブジェクトはシンプルに：

• Prompt（プロンプト）: タイトル、メッセージ、有効／無効、優先度
• Location（場所）: 保存された場所の詳細（ラベル＋座標＋半径）
• Schedule（スケジュール）: 任意の時間窓や曜日設定
• Trigger history（トリガー履歴）: 発火時刻、マッチした条件、ユーザーのアクション

このモデルがあれば後から土台を作り直すことなく拡張できます。

ユーザーを混乱させない位置権限の扱い

位置機能は許可を求める瞬間に失敗しやすいです。ユーザーは「位置情報そのもの」を拒否しているわけではなく、不確かさを拒否しています。何をいつするのかを正確に伝えることがあなたの仕事です。

システムポップアップの前に「なぜ」を説明する

OSのダイアログを先に出してはいけません。まずは簡潔な説明画面を出しましょう：

• 何に使うか（例：「スーパーに着いたらリマインドするため」）
• いつアクセスするか（例：「プロンプト作成時と実行時のみ」）
• 何をしないか（例：「移動履歴を保存しません」）

短く、具体的に、平易に。2文で説明できないなら機能が広すぎる可能性があります。

iOSとAndroidでユーザーに見える選択肢

iOSでは多くのユーザーが When In Use（使用中のみ） と Always（常時） のどちらかを選びます。アプリが閉じているときにもプロンプトが必要なら、なぜ Always が必要かを説明し、少なくともユーザーが少なくとも1つプロンプトを作成した後に要求してください。

Androidでは通常まず フォアグラウンド位置 を与え、必要に応じて別途 バックグラウンド位置 を要求します。これは二段階の信頼獲得フローとして扱ってください：まず価値を示してからバックグラウンド権限を求める。

精密（Precise）と概略（Approximate）の扱い

多くの端末は 精密 と 概略 の選択肢を提供します。ユーザーが概略を選んでも体験が壊れないように：

• トリガー半径を広げる（大きめのバッファを使う）
• 「より厳密にしたいなら精密位置を有効にしてください」と案内する

権限が拒否された場合：アプリを有用に保つ

フォールバックを提供しましょう：時間ベースのリマインダー、手動の「ここにいる」チェックイン、またはアプリが開かれているときのみ動作する住所ピッカー等。

また、後で権限を再有効化するための明確な導線（設定画面で説明＋システム設定を開くボタン）も用意してください。

位置検出の方法：ジオフェンシング vs GPSトラッキング

アプリが「ユーザーがどこにいるか」を知る方法の選択は、バッテリーと信頼性に最も大きく影響します。シンプルな位置ベースのプロンプト（「店に着いたらリマインド」など）では、可能な限り軽い手段で十分な精度を保つのが理想です。

ジオフェンシング：到着／退出に最適

ジオフェンシングはある場所の周りに仮想の境界（円）を定義し、OSがその境界への入退出イベントを監視して必要なときにアプリを起動します。

到着・退出のような場所ベースで二値的なプロンプトに最適で、ユーザーに説明もしやすい（「近くに来たら通知します」）。

シンプルなアプリ向け推奨デフォルト：

• 半径: 150〜300メートル（小さいと不安定になりやすい）
• デバウンス／クールダウン: 1地点あたり10〜30分
• 1ルールあたりの日次上限: 3〜10回（用途による）

Significant location change vs 継続的なGPSトラッキング

おおよその現在地更新が必要なら、Significant location change（有意な位置変化） は連続GPSより良い中間手段です。デバイスが意味のある移動を検出したときだけ更新が来るため、常時GPSより遥かに省電力です。

継続的なGPSトラッキング はナビやフィットネストラッキングのように本当にリアルタイムが必要な場合に限定してください。バッテリー消費が早く、プライバシー感度も高いため、リマインダー用途には過剰です。

考えておくべきエッジケース

• GPSのズレ: 境界付近で誤発火しやすい。半径を少し大きめにし、クールダウンを入れる。
• 高層ビルや地下: 信号が不安定で遅延や見逃しが発生する。アプリ内に手動で「今すぐ実行」できる機能を用意する。
• 高速移動（車／電車）: 小さなジオフェンスを素早く通過してしまう。より大きな半径を使い、超短いクールダウンは避ける。

実践的なアプローチは、一次的にはジオフェンスを使い、必要があれば信頼性向上のためにSignificant-change更新を追加することです。

プロンプトの配信：通知とアプリ内UX

位置トリガーは、適切な瞬間に適切な表現で表示され、かつ行動しやすくなければ意味がありません。配信は単なる実装ではなくプロダクト機能です：タイミング、文言、次の操作が重要です。

ローカル通知 vs プッシュ通知：最もシンプルな道を選ぶ

ほとんどのMVPでは、ローカル通知 が最速で確実な選択です。端末上で発火し、サーバーを必要とせず、アーキテクチャも単純です。

プッシュ通知 は、リマインダーの同期、リモートでのプロンプト変更、共有カレンダーやチームに紐づく通知など、サーバー駆動が本当に必要な場合に限定してください。

「通知疲れ」を防ぐスマートな抑制

有用なリマインダーでも繰り返されるとノイズになります。分かりやすいルールを入れてください：

• クールダウン: 例：「30分以内は再通知しない」
• 静かな時間帯: 睡眠中や会議時間は通知しない
• 最大繰り返し: 無視が続いたら停止（例：3回で止める）

これらはアプリの評価を守るのにも役立ちます。

アクション可能なプロンプトを作る

良いプロンプトは「次に何をすべきか」を示します。通知に次のようなアクションを付けてください：

• スヌーズ（5/15/60分など）
• 完了にする（Mark done）（ログに残すオプション）
• アプリを開く（該当プロンプトへ直接遷移）
• 地図を開く（ナビや近隣タスクの確認が必要な場合）

通知と合わせた落ち着いたアプリ内体験

ユーザーが通知からアプリを開いたら、フォーカスされた画面に遷移させましょう：リマインド文、クイックアクション、控えめな「完了」状態表示など。賑やかなダッシュボードへ放り込むのは避け、割り込みの性質に合った一貫した体験を提供します。

プロンプト作成の体験設計

位置ベースのプロンプトは、ユーザーが迷わず短時間で設定できることが重要です。特に場所の選択は非技術的なユーザーには難しく感じられがちなので、フローは親切で取り消しやすく、早く終わるように設計してください。

「プロンプト作成」フロー：場所、半径、メッセージ

フローは三つの決定に集中させます：

1. 場所を選ぶ（どこで発火させるか）
2. 半径を選ぶ（どの程度近ければ発火するか）
3. メッセージを書く（何を思い出させたいか）

実用的なデフォルトは、メッセージ欄に短いテンプレート（例：「忘れないように…」）を自動入力し、分かりやすい半径を事前選択してユーザーがメートルやフィートを理解しなくても先に進めるようにすることです。

場所の選び方：検索、現在地、地図ピッカー

複数の選択肢を提供しますが、一度に全部見せる必要はありません。

検索優先 は多くの場合最速です：オートコンプリート付きの検索バーで「自宅」「Whole Foods」「特定の住所」を簡単に見つけられます。

サポートとして二つのオプションを加えると良いです：

• 現在地を使う: すばやく設定したいとき（「今ここでリマインドして」）
• 地図ピッカー: 公園や登山口、駐車場などのケース用。ピンをドラッグし、住所／場所名を表示し「位置を確定」ボタンを明確に置く。

ユーザーに分かりやすい半径UI

多くのユーザーはメートルで考えません。スライダーに「非常に近い」「近く」「数ブロック」といった平易なラベルを付けつつ、数値も併記して透明性を保ちます。

小さなプレビュー文（例：「この場所から約200m以内で発火します」）があれば驚きが減ります。

作成後のプロンプト管理

保存したプロンプトを扱いやすくします：

• 有効／無効のトグル（一時停止用）
• 複製（同じ場所で別メッセージを使う）
• アーカイブ（メインリストを散らかさない）

リストはスキャンしやすく：場所名、一行メッセージプレビュー、状態（「有効」「一時停止」「アーカイブ」）を表示します。

障害者対応（アクセシビリティ）の基本

位置UXは小さな地図コントロールに頼りがちなので、アクセシビリティ設計を意図的に行ってください：

• 読みやすいテキストと十分なコントラスト
• トグルや地図ボタン、「確定」アクションの大きなタップターゲット
• スクリーンリーダー向けの明確なフォーカス順とラベル（例：「半径スライダー、200メートル」）

素早く分かりやすく取り消しやすいセットアップ体験はサポート工数を減らし、ユーザーが位置ベースリマインダーを作り続ける確率を高めます。

オフライン対応、バッテリー、バックグラウンド制限

接続が不安定、バッテリー残量が少ない、あるいはアプリを何日も開いていない状況でも、位置ベースのリマインダーは機能すべきです。これらの制約を早期に設計に組み込むことで「シンプル」アプリが信頼できるものになります。

オフラインファーストのストレージ（プロンプトは常に発火）

端末をトゥルーソースとして扱い、プロンプトをローカルに保存します（例：名前、緯度経度、半径、有効状態、最終編集タイムスタンプ）。ユーザーが編集したら即座にローカルに書き込みます。

後でアカウントや同期を追加する場合は、変更をアウトボックステーブルにキューイング（create/update/deleteとタイムスタンプ）し、ネットワークがあれば送信してサーバ確認後に完了とマークします。

バックグラウンド制限：何を当てにするか

iOSとAndroidの両方で、特にアプリを頻繁に開かないユーザーに対してバックグラウンド動作が制限されます。信頼できるアプローチはOS管理のトリガー（ジオフェンス／リージョン監視）に依存することです。OS管理のトリガーは端末を常時アクティブにせず正しい瞬間にアプリを起こすよう設計されています。

注意点：

• すべての状況で即時にコールバックが来るとは限らない（省電力モード、再起動、OSのスケジューリング）
• トリガー後のバックグラウンド実行時間は短いことがある：行う作業は最小限にして、通知をスケジュールする程度に留める

バッテリー：ポーリングを避ける

頻繁なGPSポーリングはバッテリーを急速に消耗し、アプリがアンインストールされる原因になります。代替案：

• 到着／退出にはジオフェンスを使う
• 定期更新が必要なら低電力モードを使う
• 複数のリマインダー処理は一括で行う（バッチ処理）

同期を追加する場合：競合処理

複数デバイスで編集可能にするなら競合ポリシーを先に決めておく。実用的なデフォルトはサーバタイムスタンプを用いた「last write wins」で、削除にはトゥームストーンを使って古いデバイスからの再出現を防ぎます。

位置機能に関するプライバシーとセキュリティ

位置ベースのリマインダーは個人的な感じが強いため、ユーザーはあなたのアプリをデータの扱いで判断します。良いプライバシーは単なるポリシーではなくプロダクト設計そのものです。

思ったほど多く収集しない

必要最小限のデータから始めてください。リマインダーが場所到達で発火するだけなら移動履歴を保存する必要はほとんどありません。

• 最小限必要なデータのみ収集し、位置履歴の保存は避ける
• 生のGPSログよりユーザー定義の場所（例：「スーパーのジオフェンス」）を保存する方が望ましい
• 「平日のみ」など機能に必要な場合のみタイムスタンプを保持する

可能なら端末上で処理する

「トリガーが満たされた → プロンプト表示」の判定を端末で行えるならそうしてください。端末で処理することで露出を減らし、コンプライアンスも簡素化できます。

• プロンプト処理は可能な限り端末で行う
• サーバが必要な場合は最小限の情報（場所IDやトリガー状態など）だけを送る

アプリ内で分かりやすいプライバシー表現を

法的文言だけに隠さず、オンボーディングや設定に短く平易な説明を入れてください：

• 何を追跡するか、理由、削除方法を示すプライバシー画面
• 位置機能の一時停止、保存場所の削除、アプリデータ全削除のコントロール

セキュリティの基本

保存する場所データはセンシティブとして扱ってください。

• 場所やラベルを保存するローカルDBは暗号化する
• ネットワークはTLSを使い、通信の認証を適切に行う
• アプリ内部で、位置にアクセスできる部分を最小限に制限する

簡単なルール：自分で2文でデータ利用を説明できないなら、おそらく収集が多すぎます。

位置トリガーのテストとデバッグ

位置機能は「自分の端末では動く」が実ユーザーでは失敗することが多いです。弱い電波、端末差、バッテリー制限、予測できない移動。良いテストプランはこれらの失敗を早期に可視化します。

実環境でテストする（机上だけでなく）

少なくとも数回は外で実機ビルド（デバッグ用のショートカットではない）でテストしてください。

• 徒歩テスト: 同じ場所に異なる方向から近づき、入退出を試す
• 車でのテスト: 高速移動で境界を飛び越すか遅延が出るかを確認
• 低GPS環境: 地下駐車場、密集市街地、室内などでの挙動
• 低電力モード: 省電力設定がバックグラウンド更新を遅らせるか確認

期待される発火時刻、実際の発火時刻、アプリがフォアグラウンド／バックグラウンド／強制終了かをメモしておきます。

再現性のためにシミュレータとモックを使う

実地テストは不可欠ですが遅いので、再現可能なテストを追加してください：

• シミュレートされたルート（境界を通過する一連の動き）
• 「ジャンプ」テスト（遠方から一気にゾーン内にワープ）
• 境界付近をふらふらするエッジテスト（繰り返し発火の確認）

モックでバグを正確に再現し、同じ場所に戻らずに修正確認できます。

デバイスマトリクスを作る（小規模でも意図的に）

位置挙動はAndroidのベンダーやOSバージョンで変わります。カバーすべきは：

• 古めのAndroid機、最近のAndroid機、iPhoneの少なくとも1モデルずつ
• パーミッション状態の複数パターン（Allow Once、While Using、Always、Denied）
• バックグラウンド制限がデフォルトの設定と省電力が積極的な設定での差

敏感な履歴を残さない形でのログ

ログはデバッグ用であり位置の長期日誌にしてはいけません。記録するのは：

• タイムスタンプ、トリガー種別（到着/退出）、プロンプトID
• パーミッション状態とバックグラウンド更新が許可されているか
• 精度レベルと失敗理由の粗いコード（例：「permission_denied」「location_unavailable」）

生座標や長い移動履歴は保存しないでください。デバッグに位置が必要なら任意で短期間だけ保持し、ユーザーに明示するべきです。

公開：ストア要件とリリースチェックリスト

位置ベースのプロンプトアプリを審査通過させるには、権限の理由を明確に示し、常時位置アクセスが必要ならその正当性を説明し、ユーザーへの配慮を示すことが重要です。

権限に影響するストア要件

iOS（App Store）:

Appleは権限の目的文字列（purpose strings）を審査します。常時（Always）の位置を要求する場合、なぜWhile Usingでは不十分かの正当な理由を用意しておく必要があります。

Android（Google Play）:

Googleはバックグラウンド位置に厳格です。要求する場合、Play Consoleで機能と前提を説明する申告が必要になりがちです。またData Safetyセクションで何を収集しどう使うかを記載する必要があります。

ストア向けの説明文は利便性を先に書く

ストアの説明では利点を一文で先に示してください：

「スーパーに着いたら買い物リストを思い出せるようにリマインドします。」

併せて記載する内容：

• どのタイミングで発火するか（到着、退出、近くにいるとき）
• 位置はリマインダー配信のためだけに使われること
• バックグラウンド位置が任意である場合、その欠落で何が劣化するか

ロールアウト計画：テスト→ベータ→段階的リリース

シンプルな段階を踏みます：

1. 内部テスト（チーム端末、複数OSバージョン）
2. クローズドベータ（実ユーザー、実際の場所）
3. 段階的リリース（まず低割合で公開し、徐々に拡大）

クラッシュ率、権限のオン率、トリガーの発火率を追い、安定性を確認します。

リリースチェックリスト（必須）

• アプリ内の説明と実際の権限ダイアログの文言が一致している
• プライバシーポリシーが位置の利用を反映している
• サポートページの経路（例：/help/location-permissions）の準備（トラブルシューティングと「なぜ必要か」説明）
• スクリーンショットや文言で常時トラッキングを示唆しない（ジオフェンスを使っているならその点を誤解させない）

成功の測定と次のイテレーション計画

位置ベースのプロンプトMVPを出すことは仕事の半分に過ぎません。残りは実ユーザーで有用性を証明し、根拠に基づいて次の機能を決めることです。

早期に追加しておくべき分析（盲点を避けるため）

ローンチ初期から追うべきイベント：

• プロンプト作成（「半径バケット」や「トリガー種別」といったメタデータを含める。生座標は含めない）
• 権限許可／拒否（ユーザーが後で変更したかも追う）
• トリガー発火（システムが到着／退出を検知したと判断したとき）

この3つだけで、ユーザーがプロンプトを作っているか、位置検知が動作しているか、コア機能が走っているかを把握できます。バックエンドを使う場合はプライバシーを優先し、可能な限り集計データで保存し、生座標は避けて下さい。

ボリュームだけでなく品質を測る

トリガー数が多くても体験が悪ければ意味がありません。品質指標を追加してください：

• 誤発火（False triggers）: ユーザーが「それは違う」と答えた回数（簡単なサムズダウンで収集）
• 見逃し（Missed triggers）: ユーザーが期待していたが表示されなかったケース（「正しいタイミングで通知されましたか？」質問で回収）
• 通知の反応: 開いた数、スワイプで消された数、無視の時間

MVPの実用的な目標は週ごとに誤発火と見逃しを減らすことです。

工数とコストの現実確認

初期構築以外の継続的作業を見積もってください：

• MVPスコープ: 2〜4スクリーン、基本ルール、通知配信
• デザイン: 明快さが磨きより優先。オンボーディング文と権限教育に予算を割く
• QA: 実機テストを都市部・屋内・通勤パターンで行うこと
• 保守: OSアップデート、権限挙動の変更、エッジケースの修正

早く出したいなら反復を早めるツールを検討してください。例えばKoder.aiはスナップショットやロールバック、ソースコードのエクスポートをサポートし、多様なOSや端末の組み合わせでテストを回す際に役立ちます。

MVPで価値が証明された後の次期機能案

再利用を増やす方向で優先順位をつけます：

• 共有プロンプト（家族やチームで共有）
• テンプレート（「ジムに着いたら…」など）
• カレンダー連携（特定の日だけリマインド）
• ウィジェット（クイック作成／クイックスヌーズ）