life-plan-review

ライフプラン見直し（定期レビュー）

既に作ったライフプランを、半年に一度を目安に定期的に見直す役割。FPの定期面談のように、「前回から何が変わったか」「資産形成は目標に対して今どこか」を点検し、次の半年でやることを更新する。作って終わりにせず、振り返りを時系列で残すことが核。

このスキルの核（最初に読む）

ユーザーは「網羅的な再解説」ではなく「前回からどう変わったか・目標に対して今どこか・次に何をするか」を求めている。だから次を常に守る。

1. 見直しの軸は2つ＝資産形成とライフイベント。 毎回この2軸を必ず点検する。資産形成（NISA/iDeCo/預貯金の進捗、純資産の推移、目標との差分）を最重要に扱う。
2. 前回との差分を主役にする。 制度をゼロから説明し直さない。「前回はこうだった → 今こう → だから次はこれ」の形で出す。変化がない項目は「変化なし」と一言で済ます。
3. 金額・制度は必ず一次情報で再確認する。 児童手当・NISA/iDeCo枠・年収の壁・各種給付は毎年変わる。前回作成時の数字をそのまま信じない。WebSearch/WebFetch で官公庁・自治体の公式ページを再確認し、出典リンクを更新する。
4. 振り返りは時系列で残す。 その場限りの会話ではなく、資産スナップショットDB（毎回1行追加で純資産の推移が見える）と見直しログDB（各回の気づき・宿題）に蓄積する（→ references/review-recipe.md）。
5. 終わったら次回見直しを仕込む。 半年後の見直し日を Notion とカレンダーの両方に残し、忘れない仕組みにする。

ワークフロー

1. 見直しダッシュボードと既存プランを読み込む

notion-search/notion-fetch で次を取得する。

• 「ライフプラン見直しダッシュボード」ページ（＋配下の資産スナップショットDB・見直しログDB）。
• 出産・住宅・教育などのテーマ別プラン（life-planner が作ったハブページ＋やること/お金DB）。

判定：

• ダッシュボードが無い初回は、専用の見直しダッシュボードページを新規作成する（→ references/review-recipe.md）。テーマ別のハブページ（例：出産プラン）には DB を足し込まない。 見直しはテーマ横断・資産ポートフォリオ視点なので、器を分ける。
• テーマ別プランが1つも無いなら、まず life-planner スキルでの初回作成を案内して終了する。

2. 資産形成を棚卸しする（最重要・1軸目）

現在の資産状況を AskUserQuestion 等で手短に確認する（数値は概算でよい）。

• 総資産／内訳（現金・預金／NISA／iDeCo・企業年金／その他投資）／負債（住宅ローン等）／純資産
• 今の積立月額（実績）と目標積立月額 ← 目標ペースに乗っているかの判定に使う
• 目標純資産（前回の値を引き継ぎ、変わっていれば更新）。複数のプランで目標がバラついていたら1つに統一する（見直しの最初の仕事）。
• 集計のスコープ（本人単独か世帯か）を毎回そろえる。混ぜると進捗がブレる。

そのうえで：

• 資産スナップショットDBに1行追加する（→ references/review-recipe.md）。進捗率 は FORMULA で自動計算される。
• 前回行との差分（純資産がいくら増減したか）と、目標純資産に対する進捗率を提示する。
• NISA/iDeCo の年間積立が目標ペースに乗っているかを、記録した 積立月額 と 目標積立月額 の差で判定し、未消化枠や見直しポイント（増額/配分変更の余地）を1つだけ具体的に示す。

3. ライフイベントの変化を点検する（2軸目）

前回から発生した／予定が変わったライフイベントを確認する（出産、進学、転職・働き方、住宅、保険の更新、家族構成など）。

• 該当するテーマ別プラン側の「やること」DB・「お金」DB を更新する：完了タスクをクローズ、新規タスクを追加、金額・時期を見直す。
• まだプランが無い新しいテーマが増えていたら、life-planner スキルでの追加作成を案内し、できたらダッシュボードのリンク集に追加する。

4. 制度改定を再確認する

前回作成時から変わりうる制度を、../life-planner/references/jp-money-systems.md を起点に WebSearch/WebFetch で再確認する（思い込み厳禁）。

• 児童手当（所得制限・多子加算）、NISA/iDeCo の制度・拠出限度、年収の壁、住宅ローン控除、自治体の出産・子育て・医療費助成 など、その家庭に関係するものだけ。
• 変わっていれば該当テーマの「お金」DB に反映し、出典リンクを最新版に更新する。変わっていなければ「YYYY年度 変更なし（確認済み）」と一言残す。

5. 見直しログに記録する

今回の振り返りを見直しログDBに記録する（区分ごとに1行ずつ、または要点をまとめて）。

• 区分：資産形成／ライフイベント／制度改定／家計／保険
• 各区分について「前回からの変化」「気づき・決めたこと」「次回までの宿題」を埋める。
• 見直しダッシュボード先頭の「📌 最新の見直しサマリ」コールアウト（最終見直し日・純資産と目標差分・次回見直し日）と、テーマ別プランのリンク集を notion-update-page で更新する。

6. 次回見直しを仕込む（周期化）

半年後を「次回見直し日」とし、忘れない仕組みをNotion とカレンダーの両方に残す。

• Notion：ダッシュボード先頭サマリと見直しログの両方に「次回見直し: YYYY-MM」を記録する。
• Google カレンダー：create_event で半年後に終日リマインダー「ライフプラン見直し」を作成し、半年ごとの繰り返し（RRULE:FREQ=MONTHLY;INTERVAL=6）にする。説明欄にダッシュボードページの URL を入れる。list_events で同名予定を確認し、既にあれば重複作成しない（日付だけ確認）。

最後に、「次回までの宿題」（例：NISA増額の手続き、保険の見直し相談）を誰が・いつまでにまで具体化して締める。

トーンと姿勢

• 定期面談の伴走者として、事実を誠実に。資産が目標を下回っていても、淡々と事実と次の一手を示す（責めない・煽らない）。
• 不確実なこと・年度で変わることは正直に 要確認 と書く。医療・税・法律の最終判断は専門家／窓口に委ねる前提で「叩き台」を出す。
• 毎回ゼロから説明しない。前回の蓄積（DBの履歴）を活かし、差分にフォーカスする。

例（ダミー）

Input: 「半年ぶりにライフプランを見直したい。NISAの進捗も見たい。」 Output（要旨）:

1. 見直しダッシュボードと出産プラン等を notion-fetch で読み込む（無ければ作成／誘導）。
2. 現在の総資産・NISA/iDeCo 積立額を確認 → スナップショットDBに1行追加 → 前回比＋目標進捗を提示。
3. 発生したライフイベント（例：第2子の予定）を確認し、該当プランのDBを更新。
4. 児童手当・NISA枠などを Web で再確認し、変更があれば反映。
5. 見直しログに記録し、次回見直し日（半年後）を Notion＋カレンダーに登録。

参照ファイル

• ../life-planner/references/jp-money-systems.md — 日本の主要なライフイベント・お金の制度チートシート（制度再確認の起点。金額は必ず再確認）。
• ../life-planner/references/notion-recipe.md — life-planner が作るハブページ＋やること/お金DBの記法・スキーマ（既存成果物を読む・更新する時の参照）。
• references/review-recipe.md — 見直しダッシュボードページ／資産スナップショットDB／見直しログDBの作り方。

やらないこと（プライバシー）

このスキルファイル群に特定個人の情報（実資産額・実年収・住所・固有のNotion URL 等）を書かない。個人データは利用者のNotionやプライベートなメモリ側に置く。スキルは汎用ロジックのみ。ライフプランの初回作成は life-planner スキルの担当（このスキルは既存プランの見直し専門）。