Dev Tracker

最終ビルド: 2026/6/25 6:31
← 一覧に戻る

saas-manager

GitHub ↗ TypeScript 最終push: 2026/6/23 10:17

WIP（現在進行中）

Work In Progress

このプロジェクトで現在進行中の作業と、過去のスナップショットを記録する。

現在の状況

MVP 完成（2026-06-23）。 Vite+React+TS の SaaS 横断ダッシュボードが動作する状態。 npm run dev → http://localhost:5180 で、cdev 配下プロジェクト×SaaS×無料枠を一覧できる。

次にやること（優先順）:

  1. 台帳 public/registry.yaml の精査：auto: true の誤検出（render/anthropic 等）を除去・確定。
  2. 主要サービスの freeTier 数値を公式で確認 → verified: true。まずメール系(Resend/SendGrid)とSupabase。
  3. 各プロジェクトの実利用量 usage を埋める（枠ゲージが意味を持つようになる）。
  4. （任意）台帳をブラウザから編集→保存できる UI、または月次利用量の自動取得。

詰まり: なし。

過去のWIPアーカイブ

（新しい「現在の状況」を書く前に、古いものをここに追記でアーカイブする。新しいものが上）

ROADMAP（計画）

ロードマップ

今週

（今週中にやりたいこと）

今月

（今月中にやりたいこと）

今四半期

（今四半期の目標）

いつか

（いつかやりたいこと・アイデアストック）

DECISIONS（意思決定）

意思決定記録

このプロジェクトで下した重要な意思決定を記録する。 最新が上に来る。

2026-06-23 データ収集方式と UI 形態

  • データ収集＝中央台帳（手動 YAML）を採用。 候補は ①中央台帳 ②devnotes 自動解析（毎回） ③各プロジェクトにマーカー追記、の3案。
    • cdev のスタックが多様（PHP/iOS/Python/Node/各種運用リポ）で config 自動検出が効きにくく、devnotes も散文でノイズが多い。
    • 各プロジェクトへのマーカー追記は全リポ編集が必要で重い。
    • → 単一の public/registry.yaml を手で管理する方式が最もシンプルかつ確実。初期値だけ devnotes 走査で生成。
  • UI ＝ ローカル Web ダッシュボードを採用（CLI / Markdown 生成 ではなく）。フィルタ・無料枠ゲージの可視化に向くため。
  • 台帳は実行時 fetch（再ビルド不要）。 public/registry.yaml をブラウザが読む構成。手編集→リロードで即反映。

DEVLOG（作業ログ）

開発日誌

このプロジェクトでの作業を時系列で記録する。 最新のエントリが上に来る。

2026-06-23 台帳更新スキル saas-track を作成

「他プロジェクトで SaaS を追加/撤去したら台帳に自動反映したい」への解。

  • 方式: 自動スキャンではなく ユーザーレベルスキル saas-track（~/.claude/skills/saas-track/SKILL.md）で、 意図的な add / remove / update(usage) を台帳に反映する。
    • 自動スキャン案を採らない理由: devnotes は撤去を検出できない（追記式）し誤検出が多い。 実 config スキャンは可能だがスタック混在で精度に限界。意図ベースのスキルなら確実・誤検出ゼロ。
  • スキルの挙動: カレントディレクトリ名から project を判定 → registry.yaml を add/remove/update → YAML 検証 → 影響サービスの無料枠残量を報告 → saas-manager を commit。
  • 1スキルに add/remove/update を集約（共通処理が大半のため）。発動フレーズは追加系・撤去系の両方を description に列挙。
  • ループ: スキルが台帳更新 → ブラウザ再読込でダッシュボード反映。
  • saas-manager/CLAUDE.md に更新フローを明記。

2026-06-23 実利用量 (usage) 入力 — Resend

You ヒアリングで Resend の実績を入力:

  • review-antenna: 約100通/月 (レビュー通知)
  • subnote: ほぼ0 (認証メール基盤は構築済みだが本番送信まだ・未稼働)
  • 合算 100 / 3,000 通(月) = 3% 使用、残り 2,900。 → 新プロジェクトで Resend を足しても余裕。
  • 前提確認: Cloudflare / Supabase は全プロジェクトで1アカウントに集約。 無料枠はアカウント単位なので「全プロジェクト合算 vs 枠」で見るのが正しい (rollup も合算)。registry ヘッダに明記。

残: Cloudflare/Supabase/Vercel の実数 usage は未取得 (devnotes に数値なし・実測待ち)。

2026-06-23 無料枠の公式確認 (verified 化)

freeTier 定義済みサービスの数値を公式ページで確認し verified: true に。

  • resend: 月3,000 / 日100通 ✓ (据え置き)
  • cloudflare: Workers 日10万リクエスト ✓ (UTC 0時リセット)
  • vercel: Hobby Fast Data Transfer 100GB/月 ✓ (metric 名を明確化)
  • supabase: 2プロジェクト / 500MB / 50,000 MAU ✓ (MAU メトリクス追加・1週間無操作で pause)
  • railway: 訂正 — 月次無料枠は廃止。一回限り $5 トライアルのみ → freeTier を [] に変更
  • UI: 各カードに「✓公式確認済み / 概算・要確認」表示を追加。

2026-06-23 台帳の誤検出クリーニング

初期 seed (devnotes 単語一致) の誤検出を実体確認して除去。

  • 原因の一つは icon.png(バイナリ) への grep 一致。scan.mjs は .md のみ読むので再走査で多くが解消。
  • 削除した誤検出:
    • render: 全件 (render() 関数 / 広告レンダリング / Unity RenderGraph / render_html.py)。Render.com は未使用。
    • anthropic/openai: Codex・MCP・Claude Design 等ツール言及、または png バイナリ一致。アプリのランタイム依存ではない。
    • slack: 候補比較で不採用 / 「次回やること」/ 例示のみ (未実装)。
    • notion/sendgrid: 他 SaaS の例・代替候補として名前が出ただけ (採用は Resend)。
    • neon / review-antenna の supabase: 「将来 Postgres 移行案」で現状未使用 (D1 利用)。
    • xai: grok (SuperGrok) に統合。
  • 実利用を確定 (auto 解除): subnote=Resend/Supabase, review-antenna=Resend/Cloudflare, entameen=Grok/Gemini, crosstechlab=Gemini, ai-odorokiya/numachan=Grok, dev-timer=ntfy。
  • fort-rank / hinata-mahjong / intelligence-bank は仮検出が全て誤りのため台帳から除外。
  • 結果: services 17→11, projects 29→25。未定義 service 参照なし・build 成功。
  • 再発防止: scan.mjs の render パターンを render.com 限定に変更。

2026-06-23 初期実装：SaaS 横断管理ダッシュボード

  • プロジェクトの目的を確定：cdev 配下の各プロジェクトが使う SaaS を一元管理し、無料枠の残量・重複利用を把握する。
  • データソースの方針を決定（→ DECISIONS）：中央台帳 public/registry.yaml（手動）＋ Web ダッシュボード。
  • ~/cdev/*/.devnotes/ をプロジェクト単位で走査し、SaaS 言及マップを取得（26 プロジェクトで検出）。
    • 多い順：lightsail / cloudflare / supabase / resend / firebase / 各種 LLM API など。
  • Vite + React + TS で SPA を実装：
    • public/registry.yaml：サービスカタログ（無料枠 freeTier 付き）＋プロジェクト別利用 SaaS の初期台帳。
    • src/rollup.ts：サービス単位に集計し status（枠超過/残りわずか/余裕あり/利用量未入力/枠なし）を算出。
    • src/App.tsx：カード一覧＋無料枠ゲージ＋検索/カテゴリ/プロジェクトのフィルタ。
    • scripts/scan.mjs：npm run scan で台帳たたき台を再生成。
  • npm run build 成功、npm run preview で配信確認（index 200 / registry.yaml 配信 OK）。

残課題

  • 台帳の auto: true は単語一致の仮検出。render(動詞)・anthropic(Claude Code 言及) 等の誤検出を要精査。
  • 無料枠 freeTier の数値は概算。公式料金で確認して verified: true に更新する。
  • 各プロジェクトの実利用量（usage）は未入力。重要サービス（メール系など）から埋める。

最近のコミット

README

saas-manager

~/cdev/ 配下の各プロジェクトが使っている SaaS（Resend, Cloudflare, Supabase, 各種 LLM API …）を 一元管理するための個人用 Web ダッシュボード。

「プロジェクト B でも Resend を使いたい。既存の利用と合わせて無料枠で足りる？」を一目で確認するのが目的。

概要

  • データソースは 中央台帳 public/registry.yaml（手動管理）。
  • 台帳の初期値は各プロジェクトの .devnotes/ を走査して自動生成（auto: true = 要確認の仮検出）。
  • ブラウザはこの YAML を実行時に読むだけなので、台帳を編集して再読み込みすれば即反映（再ビルド不要）。

セットアップ

npm install
npm run dev      # http://localhost:5180 が開く

その他:

npm run build    # 型チェック + 本番ビルド (dist/)
npm run preview  # ビルド結果を配信
npm run scan     # ~/cdev の .devnotes を再走査して台帳たたき台を出力

使い方

  1. public/registry.yaml を開く。
  2. services: に SaaS のカタログ（無料枠 freeTier を含む）を定義。
  3. projects: に各プロジェクトが使う SaaS を列挙。分かれば usage に利用量を入れる。
    • usage のキーを freeTier[].metric と一致させると、サービス単位で合算して枠ゲージに反映される。
projects:
  - id: review-antenna
    services:
      - service: resend
        usage: { "emails / month": 500 }   # この数値が枠と突き合わされる
      - service: supabase
        auto: true                          # 仮検出。確認したら auto を消す
  1. ダッシュボードは各サービスを「枠超過 / 残りわずか / 余裕あり / 利用量未入力 / 枠なし(従量)」で色分け表示。 検索・カテゴリ・プロジェクトで絞り込める。

台帳の更新フロー

  • 新しいプロジェクトを追加 / SaaS を増やしたら npm run scan でたたき台を出し、差分を registry.yaml に手で取り込む。
  • freeTier の数値は概算・調査時点のもの。最新の公式料金で確認したら verified: true に。

注意

  • auto: true は devnotes の単語一致による仮検出。render（動詞）や anthropic（Claude Code 利用の言及）等は 誤検出しうるので、必ず中身を確認すること。