Estatix 子育て支援

子育て支援給付金の比較・通知サービス

〜「引越し先選び」と「もらい忘れ防止」を、全国の自治体データで支える〜

本リポジトリは Claude Code エージェント群による完全自律運用 を前提に設計された、子育て世帯向けの給付金パーソナライズサービスです。データ収集 → 検証 → 計算 → UI 配信 → マーケティング → 問い合わせ対応 → 経営判断までを、Human Out of the Loop（HOOTL） で循環させることを目指しています。

---

1. 評価軸との対応サマリ

本プロジェクトを、提示された 3 つの評価軸（テーマ：HOOTL）に対して概観すると以下のとおりです。詳細は各章を参照してください。

---

2. 全体アーキテクチャ（一枚絵）

        ┌────────────────────────────────────────────────────────────────────┐
        │                  ★ ceo （全体を俯瞰・週次経営判断） ★              │
        │   KPI / journal / ユーザー行動を集約 → Top 3 施策 → 各層へ委譲     │
        └──┬──────────────┬───────────────┬──────────────┬──────────────┬───┘
           │ 観測          │ 観測           │ 観測          │ 観測         │ 委譲
           ▼              ▼               ▼              ▼              ▼
  ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌──────────────┐ ┌────────────────┐
  │ データパイプ    │ │ 問い合わせ      │ │ マーケティング  │ │ コンテンツ    │ │ プロダクト      │
  │ ライン          │ │ パイプライン     │ │ パイプライン    │ │ 制作          │ │ 実装            │
  │                │ │                │ │                │ │              │ │                │
  │ planner        │ │ inquiry-triage │ │ threads-       │ │ note-writer  │ │ frontend-      │
  │  ↓ queue.json  │ │  ↓             │ │ marketing      │ │  ↓           │ │ developer      │
  │ collector /    │ │ 領域別          │ │  ↓ post +      │ │ 有料記事      │ │  ↓ UI / mock   │
  │ updater        │ │ エージェント     │ │  metrics       │ │ ドラフト      │ │                │
  │  ↓             │ │  ↓             │ │  ↓ 日次学習    │ │              │ │ db-modeler     │
  │ validation     │ │ inquiry-       │ │  post_         │ │              │ │  ↓ migration   │
  │  ↓ LESSONS(31) │ │ responder      │ │  strategies    │ │              │ │                │
  └────────┬───────┘ └────────┬───────┘ └────────┬───────┘ └──────┬───────┘ └────────┬───────┘
           │                  │                  │                │                  │
           ▼                  ▼                  ▼                ▼                  ▼
   ┌────────────────────────────────────────────────────────────────────────────────────┐
   │  データ層: data/ (programs.json 135 自治体, journal)                                │
   │  DB 層:   Supabase (family_profiles, inquiry_tickets, post_metrics, page_visits)   │
   │  アプリ層: Next.js PWA (/conditions, /results, /mypage, /history, /inquiries)      │
   └────────────────────────────────────────┬───────────────────────────────────────────┘
                                            │
                                            ▼
                              ユーザー操作・Threads 流入
                              （行動データを threads-marketingとceo が再利用）

• データ層: data/<都道府県>/municipalities/<自治体>/programs.json（SCD Type 2 で版管理）
• アプリ層: Next.js 15 / TypeScript / Tailwind / PWA、Supabase Auth & DB、Stripe 課金
• エージェント層: .claude/agents/*.md に定義された 12 体のサブエージェント
• オーケストレーション: macOS launchd（launchd/com.estatix.*.plist）+ シェルスクリプト（scripts/）

---

3. データ資産

サービスのコア資産は 「11 変数パーソナライズ対応の制度データベース」 です。

• 1 自治体あたり平均 17〜29 制度（児童手当・医療費助成・保育料・出産育児一時金・独自上乗せ等）
• パーソナライズ変数 11 種（世帯構成・子の学齢区分・人数・保育形態・進学希望・所得階層・住所など）
• すべての制度に source_url・amount・eligibility を明示し、第三者再計算可能 な構造
• 履歴は SCD Type 2（version 増分・change_summary 記述）で保持し、制度改定の before/after 追跡が可能

データ収集・更新・検証の活動は data/_meta/data-pipeline-journal.md に日次でジャーナルされ、これ自体が「学習する組織の記録」になっています。

---

4. エージェント体制とトリガー（HOOTL の心臓部）

.claude/agents/ 配下の 12 体のサブエージェントが、それぞれ単一責任で連携します。

加えて、/.claude/agents/LESSONS.md には 31 件のグローバル学習ルール（L01–L26, D01–D21, C01–C10） が蓄積されており、全エージェントが新規タスク開始時に必ず参照します。これが「同じバグを二度踏まない」自己改善の核です。

---

5. 稼働性 — 24 時間動き続け、自己復旧する仕組み

5.1 常時稼働スケジューラ（launchd × 3 系統）

launchd/com.estatix.*.plist で 3 つの独立した自動化系統を常駐させています。

[launchd]
├─ com.estatix.data-pipeline.planner   ── 毎日 21:00 JST ── run-planner.sh
├─ com.estatix.data-pipeline.tick      ── 約 2 時間ごと ── run-tick.sh
└─ com.estatix.inquiry-pipeline.tick   ── 毎日 9:00 JST ── run-inquiry-tick.sh

Threads 投稿（朝・昼・夕・夜の学習）も同様の launchd 構成で動作し、合計 1 日 6 回以上の自律実行サイクル が回り続けます。

5.2 多重起動防止と一時停止

scripts/data-pipeline/run-tick.sh には HOOTL 運用に必須となる自己防衛機構を組み込んでいます。

• PID ロックファイル: /tmp/estatix-data-tick.lock で並列実行を抑止。stale lock は自動削除。
• skip-until フラグ: /tmp/estatix-data-tick.skip-until に UNIX epoch を書き込むだけでスケジューラを一時停止可能（Claude Code のレート制限対応にも利用）。
• 1 tick = 1 自治体: バックプレッシャー設計でクラスタを安定運用。
• Discord Webhook 通知: 開始 / 成功 / 失敗を色分けで通知（scripts/lib/discord-notify.sh）。

5.3 失敗からの自己復旧

• scripts/data-pipeline/dispatch.ts がタスクを queued → in_progress → completed / failed の状態機械として管理。
• 失敗タスクは次回 planner ループで再評価され、自動的に再キュー化される。
• 重大バグ（例: in_progress が planner の再生成に踏み潰される設計問題）は判明次第、根本修正としてコミット（直近 81c6324）。
• データ品質は pnpm run validate:data（test 122 件）で常時ガード。

5.4 監査証跡

これらは 「人間が監査・介入したい時に、必要な情報がすべて残っている」 ことを保証する設計です。

---

6. 進化性 — 実行するほど賢くなる仕組み

6.1 データの自動拡張ループ

ユーザー登録 ──▶ Supabase family_profiles
                       │
   毎日 21:00          ▼
  ┌──────────────── data-planner ───────────────┐
  │ 7 日以上未更新の自治体 → update キュー       │
  │ 未収集自治体 → 人口順に new キュー           │
  └──────────────────────────────────────────────┘
                       │
    2 時間ごと         ▼
            data-collector / data-updater
                       │
                       ▼
                data-validation
                       │
                       ▼
     ✅ pass → commit + journal 追記
     ❌ fail → LESSONS.md にルール化 → 全エージェントが次回参照

需要のある自治体から優先的にデータが厚くなり、収集経験が 再利用可能なルール として蓄積されます。

6.2 マーケティング戦略の自己改善

threads-marketing エージェントは日次で以下を回します。

1. 7:00 / 12:00 / 17:00 に投稿（programs.json のファクトベース）
2. Threads API でインプレッション・エンゲージメントを収集
3. 23:00 に post_strategies テーブルを更新（active / inactive を学習）
4. 翌朝の投稿テーマ選定に即反映

6.3 問い合わせ起点の自己改善ループ

ユーザーからの問い合わせは、人手を介さずに 品質向上シグナル へ自動変換されます。

ユーザー問い合わせ（inquiry_tickets に投函）
            │
            ▼  毎日 9:00 JST
   inquiry-triage（件名生成・カテゴリ判定・優先度判定）
            │
            ├─ bug / data_request  → data-collector / data-updater / calculation-engine
            ├─ feature_request    → frontend-developer / ceo
            └─ question           → note-writer（記事化候補としても蓄積）
            │
            ▼
   各専門エージェントが原因調査 → 根本修正 → コミット
            │
            ▼
   バグ・誤判定は LESSONS.md に **新ルールとして自動追記**
            │
            ▼
   inquiry-responder が回答整形・投稿・メール通知・ticket close
            │
            ▼
   resolved 後 7 日で auto_close、journal に活動記録

• 問い合わせは 24 時間以内 に triage → 専門対応 → 返信まで完結
• 「同じバグの再発」は LESSONS.md ルール参照により後続の新規収集・更新時に予防される
• 「同じ質問の再発」は note 記事化候補として蓄積され、SEO 流入資産にも転換される

つまり、問い合わせが増えれば増えるほどデータ品質・コンテンツ資産が自動的に厚くなる 構造になっています。

6.4 経営判断の自己改善

ceo エージェントが毎週月曜 21:10 にユーザー行動 / KPI / agent-journal を集約し、data/ceo/reports/<日付>/report.md に Top 3 施策提案 を出力します。Top 1 が UI 変更を含む場合は frontend-developer を自動的に呼び出し、HTML モック（mockups/top1.html）と Markdown ワイヤーフレーム（mockups/top1.md）まで生成されます。

提案実行はユーザー承認制ですが、判断材料と試作品は完全自動で揃う ため、人間の意思決定コストが極小化されます。

6.5 知見の世代間継承

• LESSONS.md: 一度発生したバグ・誤判定・データ抜けを、全エージェント共通の必読ルールとして蓄積。
• journal 群: 「いつ・誰が・何を変えたか」をエージェント自身が記録し、後続実行の文脈に取り込む。
• SCD Type 2: 制度データの履歴が永続化され、ユーザーには「制度変更の before/after 通知」価値として還元される。

---

7. 事業性 — 解いている課題と実世界インパクト

7.1 解いている課題

子育て支援給付金は 国 + 都道府県 + 市区町村（全国 1,718） の三層構造で提供され、所得・子の人数・年齢・保育形態などの条件で支給額が大きく変わります。引越し検討中の家庭が「自分のケースでどれだけ違うか」を比較するのは、現実には不可能に近いタスクです。本サービスはここを 構造化データ × パーソナライズ計算 で解きます。

• 情報非対称性の解消: 自治体公式サイトを横断する必要なく、世帯条件を入れるだけで「18 歳までの累計支給額」が自治体間で比較できる
• 受給漏れ防止: 引越し予定がなくても、現居住自治体でもらい忘れている制度がわかる
• 制度改定通知: 登録条件で制度変更があった際に、支給額の before/after を通知

7.2 提供価値と差別化

7.3 マネタイズ三層

1. Stripe 月額課金（PRO プラン）: 多子世帯・複数自治体比較・通知機能
2. note 有料記事: note-writer エージェントが自治体データ資産を SEO 最適化記事に変換（ロングテール SEO 6〜12 ヶ月で積み上げ）
3. Threads マーケティング: threads-marketing が新規ユーザー登録を自動獲得（Tier 1 KPI）

将来的には B2B（自治体・不動産・引越し事業者向け API / データ提供）に拡張可能です。

7.4 規模感（現時点）

• カバー自治体: 約 135（千葉・神奈川・東京・埼玉）
• 制度数: 約 2,500〜3,000 件
• 自動投稿: 1 日 3 回 × Threads
• 問い合わせ自動応答: 24 時間以内 に triage → 専門エージェント → 返信
• 累積コミット: 直近 30 日で 160 コミット（feat 91 / fix 42 / docs 2）— 高頻度の自律改善が進行中

---

8. ディレクトリ構成

kosodate/
├── .claude/
│   └── agents/                  # 12 体のサブエージェント定義 + LESSONS.md
├── data/
│   ├── _meta/                   # data-pipeline-journal.md（日次活動記録）
│   ├── national/                # 国制度（児童手当等）
│   ├── tokyo/ kanagawa/         # 都道府県別 × 自治体別 programs.json
│   ├── chiba/ saitama/
│   ├── ceo/reports/             # CEO 週次レポート
│   ├── threads/                 # Threads 投稿戦略・agent-journal
│   └── note/                    # note 記事ドラフト
├── launchd/                     # macOS 常駐スケジューラ（plist）
│   ├── com.estatix.data-pipeline.planner.plist
│   ├── com.estatix.data-pipeline.tick.plist
│   └── com.estatix.inquiry-pipeline.tick.plist
├── scripts/
│   ├── data-pipeline/           # run-planner.sh / run-tick.sh / dispatch.ts
│   ├── inquiry-pipeline/        # run-inquiry-tick.sh
│   ├── threads/                 # Threads 投稿 / メトリクス収集
│   ├── ceo/                     # CEO 週次レポート起動
│   └── lib/                     # Discord 通知共通モジュール
├── src/                         # Next.js (App Router) アプリ本体
│   ├── app/                     # /conditions, /results, /mypage, /history, /inquiries
│   └── lib/                     # calculator.ts ほか
├── supabase/
│   └── migrations/              # family_profiles / inquiry_* / page_visits 他
├── validation-reports/          # data-validation の独立検証レポート
├── docs/                        # 仕様・ロードマップ
├── middleware.ts                # Supabase セッション管理 / 認可ガード
└── README.md                    # ← 本ファイル

---

9. 主要な技術スタック

• フロントエンド: Next.js 15（App Router）/ TypeScript / Tailwind CSS / PWA
• バックエンド: Supabase（Postgres + Auth）/ Drizzle ORM
• 決済: Stripe Subscriptions
• マーケティング: Threads Graph API
• 自動化基盤: macOS launchd + シェルスクリプト + Claude Code サブエージェント
• 通知: Discord Webhook
• データ検証: TypeScript + 専用 validation エージェント

---

10. HOOTL 評価セルフチェック

---

11. 今後の発展

• CEO実行権限拡張（UI改善、新規機能の実装）
• 東京・神奈川・千葉・埼玉以外のエリアへの拡張
• chrome-devtools-mcp を用いた note 投稿の完全自動化

---

Estatix は、子育て世帯の意思決定を支える「データ資産」と、それを 24/7 で育て続ける「自律エージェント群」の両輪で、Human Out of the Loop を実装しています。