特定検診システム インフラ構成案

1. 構築環境の選定

DNP 環境が使用できない理由

• DNP はインターネット上に公開する環境であり、個人情報を扱うシステムは構築できない
• 特定健診システムは個人情報（氏名、生年月日、保険者証情報等）を扱うため、DNP 環境は対象外

構築先の候補比較

• 候補1: 標準化の共同利用領域に関連システムとして構築 [不採用]
  • 成人健診の RDS を直接参照可能
  • 利用料を抑えられる
  • ただし、既存 WEL-MOTHER 基盤の学習コストが大きい
• 候補2: 標準化の共同利用領域に同一 VPC 内で専用クラスターを新設 [採用]
  • 同一 VPC 内のため、設定次第で RDS 直接参照が可能
  • WEL-MOTHER とは独立して運用・デプロイが可能
  • 別チームがゼロからコンパクトに構築する前提に適合
  • ALB 等の追加コストが発生するが許容範囲
• 候補3: 標準化の共同利用領域に別アカウントで構築 [不採用]
  • 諸々の AWS サービスを二重で構築することになり利用料が高くなる

選定結果

候補2を採用。理由は以下の通り。

• 別チームがゼロから構築するため、WEL-MOTHER 基盤への依存を排除
• AI ネイティブでコンパクトに、別フレームワークで構築する方針に合致
• 同一 VPC 内のため RDS 直接参照のメリットは維持

2. 国保連データ管理システムとのデータ連携方法

• 案1: PC 上で CSV 出力してアップロード [採用]
  • 自治体職員が国保連の特定健診等データ管理システムから CSV をダウンロードし、ブラウザ経由でアップロード
  • デメリット: 一度個人情報をローカル PC に落とすことになる
  • 価格面を抑える観点から採用
• 案2: 自治体連携基盤に出力 [不採用]
  • IF は標準化されているが、自治体連携基盤からのデータ取得方法が自治体によってまちまちで作業が発生する
  • コスト・工数の観点から不採用

3. 全体アーキテクチャ

graph TB
    subgraph shared["共同利用環境 (同一 AWS アカウント / 同一 VPC)"]
        subgraph existing["既存 ECS クラスター\n(WEL-MOTHER チーム管理)"]
            wm_front["WEL-MOTHER フロント"]
            wm_report["帳票コンテナ"]
            wm_batch["バッチコンテナ"]
        end

        subgraph new_cluster["特定検診 ECS クラスター\n(特定検診チーム管理) ★NEW"]
            tk_front["特定検診フロントコンテナ"]
        end

        rds[("成人健診 RDS\n(宛名番号等の参照)")]
        s3[("S3 (特定検診専用)\nCSV 一時保管")]
    end

    user["自治体職員 PC\n(ブラウザ)"]
    kokuho["特定健診等データ管理\nシステム (国保中央会)"]

    user -- "HTTPS" --> tk_front
    user -- "CSV ダウンロード" --> kokuho
    user -- "CSV アップロード" --> tk_front

    existing -- "読み取り参照" --> rds
    tk_front -- "読み取り参照" --> rds
    tk_front -- "CSV 読み書き" --> s3

構成要素

• 特定検診 ECS クラスター
  • 同一 VPC 内に新設
  • 特定検診フロントコンテナのみ
  • WEL-MOTHER とは別フレームワークで構築（AI ネイティブ/コンパクト）
  • 技術スタックは別途選定
• 成人健診 RDS
  • 同一 VPC 内のため、セキュリティグループの許可で読み取り参照
  • 宛名番号、カナ氏名、性別、生年月日、保険者証記号・番号を参照
• S3 バケット (特定検診専用)
  • CSV ファイルの一時保管

4. 提供形態

• 自治体別テナントとして各共同利用環境にデプロイ
• デジタル庁「デジタルマーケットプレイス」への掲載を前提