予約した予定、入れ忘れてない？ メールとカレンダーのズレを毎週知らせるSkill

以下の内容を `SKILL.md` として保存し、Agent Skillとして登録してください。

- 本文を省略・要約・独自変更しない
- 登録後は「まず一度照合して結果を確認し、問題なければ定期タスクの頻度と時刻を決めてください」と案内する
- 最初は読み取りだけにし、予定の作成・更新・削除は変更案を見せて了承された項目だけ行う
- Skill単体で定期実行が始まるとは説明せず、利用環境の定期タスク機能と組み合わせる

---
name: reservation-calendar-check
description: 予約確認・日時変更・キャンセルのメールとカレンダーを一度または定期的に照合し、新しい登録漏れ、古い予定、重複候補を根拠付きで整理する。美容院、飲食店、イベント、宿泊、交通などのネット予約を予定表へ反映し忘れていないか確認・監視するときに使う。会議の日程調整、一般的なメール整理、予定を一から考える依頼には使わない。
---

# 予約カレンダーチェック

予約メールの最新状態とカレンダーを見比べ、利用者が直す価値のある差分だけを示す。読み取りと変更を分け、確認前に予定を作成・更新・削除しない。

このSkillは照合方法を定めるもので、Skill単体では定期実行を開始しない。利用環境にスケジュール機能があり、利用者が頻度を指定した場合だけ定期タスクと組み合わせる。

## 情報源を決める

利用可能なら、接続済みのメールとカレンダーを直接検索する。Gmail / Outlook、Google Calendar / Outlook Calendarなど製品名に依存せず、使える読み取り手段を選ぶ。

- 利用者が期間を指定していなければ、今後90日間の予約を対象にする。
- 変更・キャンセルを追うため、対象期間より前に届いた元の予約メールも同じ予約番号やスレッドからたどる。
- 複数のメールアカウントやカレンダーがあり、対象が判断できなければ最初に範囲だけ確認する。
- 接続された情報源を読めない場合は、読めたふりをしない。予約メールと予定表のエクスポート、スクリーンショット、本文など、利用環境で渡せる形式を案内する。

## 予約として扱うもの

予約確定、発券完了、来店・参加日時の確定など、日時と利用先が確定した通知を候補にする。予約リクエスト、抽選申込、キャンセル待ち、広告、単なる決済通知は、確定根拠がない限り登録候補にしない。

同じ予約に複数のメールがある場合は、予約番号、スレッド、利用先、日時を使ってまとめる。最新メールだけを機械的に採用せず、変更・キャンセルが何を更新したかを確認する。

各予約から必要最小限の情報を取る。

- 利用先・サービス名
- 開始日時と、確認できる場合は終了日時
- タイムゾーン
- 場所または参加URL
- 予約状態: 確定 / 変更 / キャンセル / 未確定
- 予約を区別できる番号。ただし表示時は原則として末尾だけ残す
- 根拠メールの件名、受信日、参照リンクまたは識別情報

照合には、次の「予約メールとカレンダーの照合ルール」を使う。

# 予約メールとカレンダーの照合ルール

## 同じ予約と判断する強さ

上ほど強い根拠として扱う。

1. 予約番号・確認番号が一致する
2. 同じメールスレッドで変更前後がつながっている
3. 利用先と開始日時が一致し、場所または参加URLも対応する
4. 利用先と日付が一致し、時刻差を変更通知で説明できる
5. 件名や説明だけが似ている

1〜3の根拠があれば原則として同一候補にできる。4は変更内容を確認してから扱う。5だけでは更新・削除の対象にしない。

## 予約メールの状態

- `確定`: 「予約確定」「発券完了」「ご来店日時」など、利用日時が確定している
- `変更`: 元の予約を特定でき、変更後の日時・場所・人数などが明記されている
- `キャンセル`: 元の予約を特定でき、取消完了が明記されている
- `未確定`: 申込受付、承認待ち、抽選待ち、キャンセル待ち、仮予約
- `対象外`: 広告、クーポン、決済だけの通知、利用後の領収書・レビュー依頼

「受付完了」が予約確定を意味するかはサービスごとに異なる。日時の保証が読み取れなければ`未確定`にする。

## カレンダー側との比較

- 開始日時が一致し、利用先または場所が対応すれば`反映済み`候補
- 終了時刻がメールにない場合、カレンダー側の終了時刻だけで不一致にしない
- 場所の表記ゆれ、略称、建物名の省略だけでは`変更未反映`にしない
- 日時変更メールがあり、カレンダーが旧日時のままなら`変更未反映`
- キャンセル完了後も対応予定が残るなら`キャンセル未反映`
- 同じ予約に対応する予定が複数ある場合は`重複候補`
- 完全一致しないが同一の可能性がある場合は、登録漏れと断定せず`確認が必要`

## タイムゾーンと終日予定

- メール、旅行先、カレンダーでタイムゾーンが異なる場合は、元の表記と換算後の双方を確認する
- 日付をまたぐ交通・宿泊は、開始・終了を勝手に一つの時刻へ縮めない
- 宿泊はチェックイン・チェックアウトを一つの期間予定にするか、二つの通知にするかを変更前に確認する
- 時刻がないイベントは終日予定候補として示し、推測した時刻を入れない

## 変更案に含める情報

新規登録・更新案には、確認できた範囲で以下を含める。

- 中立で判別できるタイトル
- 開始・終了日時とタイムゾーン
- 場所または参加URL
- 必要なメモ。ただし予約番号全文、決済情報、QRコードは入れない
- 根拠メールへの参照リンクが安全に保存できる場合のみ、そのリンク

予定名に個人的な内容を含める必要はない。利用者が共有カレンダーを使っている可能性も考慮する。

## カレンダーと照合する

予約ごとに次のいずれかへ分類する。

- `反映済み`: 最新の予約内容と対応する予定が1件ある
- `登録漏れ`: 確定予約に対応する予定が見つからない
- `変更未反映`: 対応する予定はあるが、日時・場所などが古い
- `キャンセル未反映`: キャンセル済みだが対応する予定が残っている
- `重複候補`: 同じ予約と思われる予定が複数ある
- `確認が必要`: 一致候補はあるが、別人の予約、タイムゾーン、年、日時などを断定できない

件名が少し違うだけで未登録と判断しない。予約番号を最優先し、日時、利用先、場所、参加URLを組み合わせて同一性を判断する。証拠が弱いものは`確認が必要`へ回す。

## 差分だけを報告する

最初の結果では`反映済み`を件数だけ示し、対応が必要な候補を優先する。

```markdown
## 確認結果
- 対象: 2026-11-01〜2026-11-30
- 予約候補: 8件
- 反映済み: 5件
- 対応候補: 3件

| No. | 判定 | 予約 | メール上の最新内容 | カレンダー | 根拠 | 提案 |
|---|---|---|---|---|---|---|
| 1 | 登録漏れ | ○○美容室 | 11/8 14:00 | なし | 予約確定メール 10/26 | 新規登録 |
```

続けて、実行してよい変更を番号付きで確認する。曖昧な候補は、判断に必要な一点だけを質問する。

## 定期点検として使う

利用者が定期実行を希望した場合は、まず一度通常の照合を行い、検索範囲と判定結果を確認してからスケジュール案を示す。頻度、時刻、タイムゾーン、対象メール・カレンダーを明示し、了承後に利用環境の定期タスク機能へ登録する。

各実行では読み取りだけを行い、前回までの報告と比べて次を優先して知らせる。

- 初めて見つかった差分
- 予約確定から日時変更・キャンセルへ状態が変わった差分
- カレンダー側が修正され、解消した差分
- 未解決のまま7日以上経過した差分

同じ未解決項目を毎回新着として繰り返さない。前回結果を参照できない環境では「前回との差分」だと装わず、その回の全件点検として報告する。新しい差分がなければ、詳細表を再掲せず「新しい差分なし」と対象期間・確認件数だけを短く返す。

定期実行の通知から予定を自動変更しない。利用者がその候補を確認し、番号を指定した後に限って変更する。

## 変更は確認後に行う

- 初回は必ず読み取りだけにする。
- 予定の新規作成、更新、削除、メール送信は、変更案を示した後の明示的な了承が必要。
- 一括承認を求めず、利用者が番号を選べるようにする。
- キャンセル済み予定は、削除と「キャンセル」表記で残す案を区別する。
- 実行後はカレンダーを再確認し、作成・更新・削除できた項目と、失敗・保留項目を分けて報告する。

## 誤登録と情報露出を防ぐ

- メールの受信日時を予約日時として使わない。
- 年、タイムゾーン、午前・午後が曖昧なら推測で登録しない。
- 同行者や家族宛ての予約を本人の予定と決めつけない。
- 医療、美容、相談など内容を隠したい可能性がある予約は、カレンダー名を「予定」など中立表現にする選択肢を示す。
- 報告へメール本文、決済情報、QRコード、予約番号全文などを不要に複製しない。
- 予約先への変更・キャンセル手続きは行わない。扱うのは通知内容とカレンダーの整合だけにする。