What it does
できること
文章から日時候補を抽出
他アプリから共有された文章を解析し、日付、開始時刻、予定名の候補を作ります。『明日』『来週』『18:30』など形式が異なる表現を、現在日時を基準に解釈します。
- 元の文章を残して確認できる
- 複数候補がある場合は選択させる
- 未確定項目は推測せず入力を求める
予定とタスクを整理
日時が確定している予定だけでなく、期限だけ決まっている作業も同じ場所で扱えるようにしました。重要度を付け、今日見るべき項目が先に分かる構成です。
- 重要度による分類
- 完了状態の切り替え
- 予定化できない文章もタスクとして保持
月と日の2つの視点
月表示では空いている日を把握し、日表示では実行順を確認できます。同じデータを目的に応じて見せ分け、情報を一画面へ詰め込みすぎないようにしました。
- 月表示は件数と存在を優先
- 日表示は時刻と内容を優先
- 選択中の日付を常に視覚化
Why I made it
きっかけと課題
メッセージで予定を受け取るたびに、アプリを切り替え、文章を見直しながら日時と件名を手入力していました。短い作業ですが頻度が高く、転記ミスも起きやすい点に課題を感じました。
目標を完全自動登録にはしませんでした。自然文には曖昧さがあるため、抽出で入力を減らし、最後の確認は人が行う『半自動』が安全性と速さのバランスに優れると考えたためです。
Process
進め方・実装手順
- 01
表現パターンを収集
実際の連絡文を、絶対日付、相対日付、曜日、時刻、期間に分類し、どの情報が省略されやすいかを整理しました。
OUTPUT — 日時表現のパターン表 - 02
共有テキストを受け取る
Androidの共有先としてアプリを表示し、受け取った文字列を解析画面へ渡します。空文字やURLだけの共有も例外として扱います。
OUTPUT — 共有入口と受信確認 - 03
候補を段階的に解析
明示された年月日を優先し、次に『今日・明日・来週』、最後に曜日を解釈します。時刻がなければ勝手に補わず未入力にします。
OUTPUT — 解析ルールと候補モデル - 04
確認画面を設計
抽出した予定名、日付、時刻を編集可能な項目として並べ、元文章と見比べてから登録できるようにしました。
OUTPUT — 登録前レビュー画面 - 05
境界条件を検証
月末、年末、日付をまたぐ時間帯、同じ文中に複数日時がある場合をテストし、誤登録しやすい条件を洗い出しました。
OUTPUT — 日時解析テストケース
Problems & decisions
苦労したこと
01『来週火曜』の解釈＋
現在の曜日や利用者の感覚によって、相対日付が指す日が変わることがあります。
解析結果を確定値として隠さず、具体的な年月日へ変換して確認画面に大きく表示しました。
自動化の便利さを保ちながら、意図しない日付への登録を防ぎやすくしました。
02文章中に候補が複数ある＋
締切と開催日が同じ文章に含まれると、どちらを予定にすべきか自動では判断できません。
すべての候補を一覧にし、利用者が選んだ日時だけをフォームへ反映する設計にしました。
誤った一件を自動登録するより、選択できることを優先しました。
03月表示の情報量＋
予定名をすべて表示すると小さな画面で読めず、日付の把握もしにくくなりました。
月表示は予定の有無と件数に絞り、選択した日の詳細を別領域で見せました。
俯瞰と詳細の役割が分かれ、目的の日へ移動しやすくなりました。
Reproduction guide
再現するための手順
未来の自分や、同じものを作りたい人が迷わないように、最短の再現手順を残します。
1. 10〜30件の連絡文を集める
個人情報を除いた例文を作り、日付表現を分類します。先にデータを見ることで、正規表現を場当たり的に増やすのを防げます。
2. 日時を内部形式へ統一する
抽出結果は表示文字列のまま持たず、日付、時刻、タイムゾーン、確信度、元文字列に分けて管理します。
3. 確認画面を先に完成させる
解析精度が低い段階でも手入力で予定を作れる画面を用意します。その後、解析できた項目だけを自動入力する形で育てます。
4. 端末のカレンダーへ渡す
登録前に件名・日時・説明を最終確認し、端末標準の予定作成画面または許可されたカレンダー連携へ渡します。
Reflection
振り返り
WHAT I LEARNED
- 曖昧な入力では、正解を装うより確認可能性を高める
- 月表示と日表示は同じ情報を縮小するのではなく役割を分ける
- 日時処理は通常例より月末・年末・複数候補のテストが重要