EP.1 で「予定から始める」と書きました。理由は単純で、効果が最も早く、家族全員が恩恵を感じられるからです。この回では、散らばった予定を1本に集約し、送迎の重なりや詰め込みすぎを機械に検知させるところまでを設計します。
1. 予定が散らばる理由
中学受験期の家庭に予定が届く経路を数えてみると、その多さに驚きます。しかも経路ごとに形式が違うのが厄介です。
| 経路 | 形式 | 扱いにくさ |
|---|---|---|
| 塾 | アプリ通知 / 紙 / メール | 振替や補講で後から変わる |
| 学校 | 配布プリント / 連絡メール | 紙が多い。行事は数ヶ月先まで一気に来る |
| 模試 | 申込サイト / 受験票 | 申込期限という別種の締切が付く |
| 習い事 | 個別連絡 / 口頭 | 記録が残らないことがある |
| 家庭側 | 通院、帰省、きょうだいの行事 | 把握しているのが片方の親だけになりがち |
これらを人間が手で1箇所に写すのは、続きません。経路ごとに「自動で入る道」を作るのが設計の中心になります。
2. 集約先を決める
まず を決めます。家族共有カレンダー1本。ここに入っていない予定は「存在しない」と全員で扱えるところまで持っていくのが目標です。
アプリの選定は家族がすでに使えているものを優先してください。新しいアプリの習得を家族に求めると、そこが最大の障壁になります。ほとんどのカレンダーは 形式を読めるので、集約する仕組みさえ作れば表示先は選べます。
- 色で系統を分ける: 塾 / 学校 / 習い事 / 家庭。見た瞬間に密度が分かる
- 送迎は独立した予定にする: 「塾（19:00-21:00）」ではなく、送りと迎えを別に置く。衝突検知が効くようになる
- 締切も予定として置く: 申込期限は当日ではなく締切の3日前に置く
もう1つ、集約先を決める段階で考えておきたいのが運用開始後の維持です。最初の1ヶ月は目新しさで回りますが、問題は3ヶ月目に来ます。自動で入る経路が1つでも切れると、そこから「カレンダーは当てにならない」という空気が家庭に生まれ、一度そうなると誰も見なくなります。だから経路を欲張らないこと。塾と学校の2経路が自動で入るだけでも体感はかなり変わるので、まずそこを確実にしてから広げてください。
3. プリントを予定に変える
紙の配布物が最大の難所です。ここは 「撮るだけ」 に収めます。EP.1 で書いたとおり、人間に許される操作は撮る・一言返すまでです。
処理の流れはこうなります。撮影 → → で日付・時刻・持ち物・場所を抽出 → 確認 → カレンダー登録。確認の1ステップを残すのは、読み取りが 100% ではないからです。それでも手入力よりは桁違いに速く済みます。
読み取り品質について、実務的な感覚も書いておきます。日付と時刻は比較的安定して取れます。崩れやすいのは、表組みで作られた年間行事予定表と、手書きの追記が入ったプリントです。そして厄介なことに、モデルは「読めませんでした」と言う代わりにもっともらしい日付を埋めてくることがあります。確認の1ステップが効くのはまさにここで、間違いを見つけるためというより、自信のない読み取りを素通りさせないために置いています。
学校の配布物には氏名・クラス・住所・写真が載っていることがあります。撮影した画像を外部サービスへ送る構成にする前に、手元で処理できないかを検討してください。ローカル LLM の道具箱 で扱っている構成なら、画像を外に出さずに処理できます。
4. 衝突と無理を検知する
集約の本当の価値は、並べただけでは見えないものが見えるようになる点にあります。代表が送迎の重なりです。
- 送迎の衝突: 同じ時刻に別の場所へ。カレンダー上は別予定なので目視では気づけない
- 移動が間に合わない: 前の予定の終了から次の開始までが、移動時間より短い
- 詰め込みすぎ: 1日の拘束時間が閾値を超えている。空白が0の日が続いていないか
- 締切の集中: 同じ週に申込期限が3件重なる
これらは機械が得意な検査です。人間が毎週カレンダーを睨んで見つける仕事ではありません。定期実行する に週次で点検させ、問題があった週だけ知らせる形にしておくと、確認という作業そのものが意識から消えます。
from datetime import datetime, timedelta
# 予定は「場所」を持たせるのが肝心。場所がないと移動の無理を検知できないEVENTS = [ {"title": "塾 送り", "start": datetime(2026, 9, 3, 17, 30), "end": datetime(2026, 9, 3, 17, 50), "place": "塾"}, {"title": "ピアノ 迎え", "start": datetime(2026, 9, 3, 17, 40), "end": datetime(2026, 9, 3, 18, 0), "place": "教室"},]
# 場所間の移動時間（分）。実測値を少しずつ埋めていくTRAVEL_MIN = {("塾", "教室"): 25, ("教室", "塾"): 25}
def conflicts(events): """重なり、および移動が間に合わない組み合わせを返す""" found = [] ordered = sorted(events, key=lambda e: e["start"]) for i, a in enumerate(ordered): for b in ordered[i + 1 :]: if b["start"] >= a["end"]: # 時間は重ならない。移動が間に合うかを見る need = TRAVEL_MIN.get((a["place"], b["place"])) if need is not None: gap = (b["start"] - a["end"]) / timedelta(minutes=1) if gap < need: found.append((a, b, f"移動 {need}分に対し {int(gap)}分しかない")) continue found.append((a, b, "時間が重なっている")) return found
for a, b, why in conflicts(EVENTS): print(f"[要確認] {a['title']} と {b['title']}: {why}")5. リマインドを設計する
通知は多いほど無視されます。「毎朝すべての予定を読み上げる」は2週間で切られます。行動が変わるものだけに絞ってください。
| タイミング | 内容 | 理由 |
|---|---|---|
| 前日の夜 | 明日の持ち物と集合時刻のみ | 準備が必要なものだけ。予定そのものは繰り返さない |
| 締切の3日前 | 申込・提出の締切 | 当日通知では間に合わない種類がある |
| 週の初め | その週の異常だけ（衝突・詰め込み） | 問題がなければ何も言わない |
| 変更が入った時 | 振替・中止 | これは即時が価値を持つ |
週次の通知は、問題がない週には何も言わない設計にしてください。毎週律儀に「異常ありません」と届く通知は、すぐに開かれなくなります。黙れる仕組みだけが、長く信用されます。
6. 落とし穴
- 新しいアプリを家族に覚えさせる: 習得コストが最大の障壁。すでに使えているものを使う
- 送迎を予定に書かない: 書かないと衝突検知が効かない。送りと迎えを別予定に
- 通知を増やす: 行動が変わるものだけ。それ以外は黙る
- 空白を残さない: 見えると埋めたくなる。空白を予定として置くと守られる
- 読み取り結果を確認せず登録する: 日時の誤りは事故になる。確認の1ステップは残す
- プリント画像を無自覚に外部へ送る: 氏名・住所・写真が写っている
7. ふくふくの進め方
予定の集約は、業務でいえば散在する情報源を1つのビューに統合する仕事とまったく同じ構造です。難しいのは技術ではなく、正本をどこに置き、誰も入力しなくて済む形にどう寄せるかの設計でした。
8. ここまでのまとめ
- 正本は家族共有カレンダー1本。表示先は家族がすでに使えているものでよい
- 送迎は独立した予定にする。これをやらないと衝突検知が働かない
- プリントは 撮るだけ。読み取り → 確認 → 登録の3段
- 集約の価値は 並べただけでは見えない無理が見えること（送迎の重なり、移動時間、詰め込み）
- 通知は 行動が変わるものだけ。問題のない週は黙る
次回 EP.3 は学習です。参考書のスキャン、課題の残量管理、定期考査や模試に向けた逆算を扱います。この連載は、読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。