あなたが使える保健事業が、
3つの質問でわかる。

1. 基本の考え方：「エンジン」と「データ」を分ける

判定の仕組み（エンジン）と、各事業の対象条件（データ）を分離します。こうすると、健保が変わってもコードは変えず、条件表だけ差し替えればよい構造になります。これが横展開できる強みの核です。

2. 1つの保健事業 ＝ 1件の条件データ

事業ごとに「対象となる条件」を持たせます。今回の入力は 区分・年齢・性別 の3つ。最小入力では判定しきれない条件（出産・健診結果な��）は 追加条件 として持ち、結果を「条件付き」に振り分けます。

// 保健事業1件のデータ例（JSON）
          {
          "id": "lady",
          "名称": "レディース巡回健診",
          "対象区分": ["被保険者","被扶養者"], // 空＝全員
          "年齢下限": 35,
          "年齢上限": null,
          "対象性別": "女性", // null＝不問
          "追加条件": null, // 例:"出産された方"
          "リンク": "/healthcare/lady"
          }
        

3. 判定ロジック（3段階に振り分け）

区分・年齢・性別を すべて満たすか？
          ├─ いいえ ───────────���──→ ✕ 対象外
          └─ はい
          └─ 追加条件があるか？
          ├─ なし ──────→ ✓ 利用できます
          └─ あり ──────→ △ 条件付き（追加条件に該当すれば可）

「条件付き」は、最小入力では白黒つかない事業のための受け皿です。ただし本ナビの方針として、対象者へ自動で送付・案内されるもの（重症化予防の受診勧奨、育児雑誌贈呈、特定保健指導の招待 等）は掲載しません。本人が選んで使うものではないためです。その結果、現在の対象事業はすべて区分・年齢・性別だけで判定でき、表示は「利用できます／対象外」の2段階になっています。
仕組みとしては 追加条件 を残してあるので、将来「本人が申し込む＋一定条件」のような事業を足したくなったら、条件付きを復活させられます。入力項目を増やすと精度が上がる——入力の手間と精度のトレードオフがそのまま設計に表れます。

4. 現在の判定ルール一覧（すべて仮・要確認）

5. 次の検討ポイント（コンサル → エンジニアの論点）

・確定した支給要件の収集（事業ごとの正式条件）。これが最重要かつコンサルの腕の見せ所です。
・掲載／非掲載の線引き：本人が���込・利用するものは載せ、自動送付・自動案内のものは載せない、という方針の確認と運用。
・入力項目をどこまで増やすか（妊娠・出産、健診結果、勤務形態 等）。
・健保ごとの条件データをどう管理するか（CMS／スプレッドシート連携 等）。
・結果から各事業の申請ページ・申請書へ直接つなぐ導線。