subs — SaaSサブスクリプション支出分析は何をしますか？

ユーザーの定期サブスクリプション支出を銀行/カードCSVエクスポートとメール領収書から分析します。支出サマリー、無駄のフラグ、更新トラッキング、節約提案を出力します。

台帳が基盤です

ワークスペース内の subscriptions.yaml が唯一の真実源です。実行のたびに新しいデータを台帳に調整（ reconcile ）します — 毎回ゼロから再導出はしません。これにより、更新トラッキングと実行間の一貫性が実現し、「無駄」を計算可能にします（数ヶ月請求された後に突然なくなったサブスクリプション＝失効または解約すべきもの）。台帳全体を上書きせず、調整してください。

台帳エントリのスキーマ（サブスクリプションごとに1エントリ）:

- vendor: GitHub               # 正規名
  amount: 4.00                 # 最新の請求額
  currency: USD
  cycle: monthly               # weekly | monthly | quarterly | semiannual | annual
  category: Dev tools
  first_seen: 2025-01-12       # 既知の最初の請求のISO日付
  last_seen: 2026-06-03        # 最新の請求のISO日付
  next_renewal: 2026-07-03     # last_seen + 1サイクル
  status: active               # active | price_hike | lapsed? | cancelled
  notes: "was 4.00 since signup"

前提条件: Gmailコネクタ

このスキルは、コーディングエージェントが利用可能なGmailコネクタ/MCP（例: Claude CodeのGmailコネクタ）を介してGmailからサブスクリプション領収書を読み取ります。ステップ1の前に、エージェントがGmail検索/読み取りツール（search_threads / get_thread のペア、または同等のもの）を持っていることを確認してください。Gmail統合が利用できない場合は、停止してユーザーに有効にするよう伝え、スキルを再実行してください。詳細とクエリは email-receipts.md を参照してください。

プロセス

以下のステップを順に進めてください。ステップ5までレポートは出力しないでください。

0. ワークスペースを特定する

現在のワーキングディレクトリをワークスペースとして使用します。data/statements/、data/receipts/、reports/ が存在することを確認し（なければ作成）、subscriptions.yaml が存在すれば読み込み、存在しなければ台帳は空として扱います。 完了条件: ワークスペースのディレクトリが存在し、台帳が（空でも）読み込まれていること。data/statements/ が空で、subscriptions.yaml がまだ存在せず、ユーザーがPlaidを使用していない場合は、ユーザーに銀行/カードCSVエクスポートを data/statements/ に配置するよう伝えて停止します — CSVは定期検出の基盤です。

1. 入力を収集する

Plaid CLI経由の銀行データ（推奨 — 手動CSVエクスポート不要）: CLIが準備できていることを確認し、plaid.md に従ってトランザクションを data/statements/plaid-transactions.csv に取得します。そうでない場合は、ユーザーが data/statements/ に配置したCSVに依存します。

次に、data/statements/ 内のすべてのCSVをリストアップします。email-receipts.md に従ってGmailからサブスクリプション領収書を取得し、data/receipts/ 内の補足的な .eml / .txt ファイルも読み取ります。 完了条件: data/statements/ 内のすべてのCSVが列挙され、Gmailの領収書検索が戻ってきた（またはコネクタ不足で実行が停止した）こと。

2. 定期請求を検出する

すべての明細CSV（Plaid由来のものを含む）に対して、決定論的検出器を実行します — 行を目視しないでください。<skill-dir> はこのスキル自身のディレクトリです（Claude Codeでは ~/.claude/skills/subs/）:

python3 <skill-dir>/scripts/detect_recurring.py data/statements/*.csv

low 信頼度の候補やマーチャント正規化のエッジケースについては、recurrence-detection.md を参照してください。これらの候補をステップ1で収集したGmail領収書と組み合わせます — 領収書は、短期の明細では見逃される年間サブスクリプションを捕捉し、曖昧な記述子を特定します。 完了条件: すべての定期候補に、マーチャント、周期、金額、最終確認日が設定されていること。

3. 台帳に調整する

候補を subscriptions.yaml に調整します:

新規マーチャント → エントリを追加し、categories.md に従ってカテゴリ分類。
既存 → last_seen と next_renewal を更新。金額が上昇した場合は status: price_hike を設定し、以前の金額を notes に記録。
台帳にはあるが、最近のデータにない（今日から約1.5サイクル以内に請求がない）→ status: lapsed? を設定。

完了条件: すべての台帳エントリの status が active | price_hike | lapsed? | cancelled のいずれかであり、すべての候補が正確に1つの台帳エントリにマッピングされていること。

4. 分析する

調整済みの台帳から、以下の4つすべてを計算:

(a) 支出サマリー — 月間合計と年間換算合計、カテゴリ別、ベンダー別、請求サイクル別にグループ化。すべてのエントリを月間換算額（$/月）に正規化: 年次÷12、半期÷6、四半期÷3、月次×1、隔週×2.17、週次×4.33、半月次×2。レポートではこの$/月を再利用します（唯一の真実源）。
(b) 無駄 — 重複（同じサービスが2回）、重複ツール（同じカテゴリで同じ機能の2つの製品）、値上げ（status: price_hike）、失効/未使用（status: lapsed?）。
(c) 今後の更新 — next_renewal が今後60日以内にあるエントリを、早い順に表示。
(d) 節約提案 — 年次⇔月次の切り替え、ダウングレード、統合、解約。それぞれ、台帳エントリと金額への影響を引用する必要があります。

完了条件: 4つすべてが出力され、すべての提案がエントリ＋金額への引用を含んでいること。

5. レポートする

台帳を保存し、それに基づいて両方のレポートを書き出します:

Markdown reports/<YYYY-MM-DD>-subscriptions.md（report-template.md に従う）;
自己完結型HTMLダッシュボード reports/<YYYY-MM-DD>-subscriptions.html（html-report.md に従う）を開く（open <path>）。

次に、チャットで簡潔なサマリーを表示します（主要合計＋トップ3アクション）。 完了条件: 両方のレポートに支出サマリー、無駄フラグ、今後の更新、順位付けされた提案が含まれ、subscriptions.yaml が保存されていること。

subs — SaaSサブスクリプション支出分析