統合DB | 株式会社２７９

👥

利用者

—

統合件数

🧑‍⚕️

職員

—

統合件数

🏠

事業所

—

登録件数

📥

最終取込

—

最近の取込履歴

日時	拠点	ファイル	ステータス	詳細
読み込み中...

ZIPファイルアップロード

拠点選択

📁

FirstCareV7.zip をここにドロップ
またはクリックして選択

Drive 自動取込スケジューラー稼働中

Google Drive の監視フォルダを今すぐチェックして新しい ZIP を取込みます。

自動実行間隔

※ スケジューラーは設定間隔に満たない場合スキップされます。

FC エージェント管理

読み込み中...

手動アップロード同期

サーバー上の FC エージェントに対して、今すぐ ZIP を吐き出して Storage にアップロードするよう指示します。
エージェントが次回ポーリング（最大1分以内）で受け取り実行します。

取込履歴

日時	拠点	ファイル	所要時間	ステータス	詳細
読み込み中...

利用者マスター（統合）

「読み込む」をクリックしてください

職員マスター（統合）

「読み込む」をクリックしてください

freee 除外リスト同期対象から外す freee 従業員の管理

読み込み中...

事業所マスター

「読み込む」をクリックしてください

職員変更履歴（入社・退職・改名）

「読み込む」をクリックしてください

職員DB × Workspace 照合

APIマニュアル読み取り専用エンドポイント

🔑

全リクエストにヘッダー x-api-key: <MASTER_API_KEY> が必要です（Secret Manager: tougou-db-f9f9e）

Jigyosho（1,220件+）

GEThttps://asia-northeast1-tougou-db-f9f9e.cloudfunctions.net/getJigyosho

Shokuin（78件+）

GEThttps://asia-northeast1-tougou-db-f9f9e.cloudfunctions.net/getShokuin

Riyousha（1,700件+）

GEThttps://asia-northeast1-tougou-db-f9f9e.cloudfunctions.net/getRiyousha

クイックスタート

<!-- headに追加 -->
<script src="https://tougou-db-f9f9e.web.app/master-api.js"></script>

// APIキーを初期化（Secret Manager: MASTER_API_KEY）
MasterAPI.init("your-master-api-key");

// どこからでも呼び出せます
const jigyosho = await MasterAPI.getJigyosho();
const shokuin  = await MasterAPI.getShokuin();
const riyousha = await MasterAPI.getRiyousha();

// 氏名検索
const results = await MasterAPI.searchRiyousha("田中");

スキーマ: 事業所

#	列名	説明	種別
1	統合事業所ID	主キー	PK
2	事業所番号	10桁コード	基本
3	名称 / 正式名称	名前	基本
4	住所_郵便番号〜その他2	住所	住所
5	TEL / FAX / eメール	連絡先	連絡先
6	担当_1〜2	担当者情報	連絡先
7	有効フラグ	有効=1	システム
8	レコード更新情報	最終更新	システム

スキーマ: 職員

#	列名	説明	種別
1	統合職員ID	主キー	PK
2	職員名称_姓 / 名 / 姓名	氏名	基本
3	性別 / 生年月日	属性	基本
4	自宅電話 / 携帯 / eメール	連絡先	連絡先
5	介護支援専門員番号	ケアマネ番号	介護
6	有効フラグ	有効=1	システム

スキーマ: 利用者

#	列名	説明	種別
1	利用者ID / 統合利用者ID	主キー（UUID）	PK
2	姓 / 名 / 姓名	氏名	基本
3	統合職員ID / 担当者名	担当ケアマネ	FK
4	性別 / 生年月日	属性	基本
5	住所_郵便番号〜その他2	住所	住所
6	電話 / 携帯 / FAX	連絡先	連絡先
7	連絡先1〜3	緊急連絡先	連絡先
8	主治医 / 歯科医 / 薬局	医療	医療
9	保険者番号 / 被保険者番号	介護保険	介護
10	要介護状態区分等	要介護度	介護
11	拠点	所属拠点	基本

System Design Document

279 統合利用者DB — システム設計書

ファーストケア（FC）自動エクスポート → GCS → Cloud Functions → Firestore　|　2026-04-12 更新

Node.js 22 Cloud Functions v2 Cloud Firestore GCS（Cloud Storage） fc_agent（Windows）

月額コスト（旧）

$255

Cloud Run 常時稼働

月額コスト（現在）

$1.62

fc_agent + Cloud Functions

削減率

▼99%

$253/月削減

アーキテクチャ概要（2026-04-12 現在）

💻

ファーストケア

いわき・札幌

10分ごとにZIP自動エクスポート
C:\FcCsvExport\

→

🔨

fc_agent

Pub/Sub Pull型 / NSSMサービス

1時間ごとに起動
ZIPをGCSへアップロード

→

☁

GCS

Cloud Storage

firstcare-imports-v2/
kyoten/file.zip

GCSトリガー ↓ Cloud Functions

🔆

processFirstCareZipV2

Cloud Functions

ZIPを展開・CSV解析
keika_kiroku は即時委譲

→

⚡

processKeikaCsv

最優先処理

経過記録を約4秒で反映
差分チェックポイント管理

→

🗄

Firestore

統合利用者DB

riyousha / records
hihosho / jigyosho

稼働拠点（2026-04-12 現在）

拠点	kyoten ID	利用者数	ZIP処理時間	fc_agent サーバー	ステータス
いわき	iwaki	240名	約15分/ZIP	Windows Server（いわき）	稼働中
札幌	sapporo	1,567名	約30分/ZIP	Windows Server（札幌）	稼働中

fc_agent — Windows自動アップロードエージェント2026-04-11 追加

動作フロー

ファーストケアが10分ごとにZIPをエクスポート
Cloud Scheduler が2時間ごとに Pub/Sub へ命令発行
fc_agent_pubsub.ps1（NSSMサービス）が30秒ポーリングで命令を受信
fc_agent が C:\FcCsvExport\ のZIPをGCSへアップロード（ZIPハッシュ比較で差分のみ処理）
アップロード成功後にZIPを自動削除
GCSトリガーで processFirstCareZipV2 が自動起動

設定ファイル（uploader_servers コレクション）

実行スケジュール	2時間ごと（Cloud Scheduler → Pub/Sub）
ZIPパス	C:\FcCsvExport\*.zip
GCSバケット	firstcare-imports-v2
削除設定	アップロード後に自動削除
設定管理	Firestore: uploader_servers

技術スタック

Agent（NEW）

fc_agent（PowerShell）

Cloud Scheduler + Pub/Sub / NSSMサービス常駐

Runtime

Cloud Functions v2

Node.js 22 / TypeScript

Trigger

GCS Storage トリガー

onObjectFinalized（v2）

Database

Cloud Firestore

NoSQL Document DB

Storage

Cloud Storage（GCS）

asia-northeast1 (東京)

Auth

Firebase Auth + Google

279279.net ドメイン制限

Cloud Functions 一覧

関数名	トリガー	役割	優先度
processFirstCareZipV2	GCS Storage	ZIPを展開、CSV分類、keika_kiroku を processKeikaCsv に委譲、他CSVをポリシーゲート経由で処理	メイン
processKeikaCsv	直接呼び出し	経過記録（keika_kiroku）を最優先処理。差分チェックポイントで重複書き込みを防止。約4秒で完了	最優先
csv_process_policy	Firestore設定	keika_kiroku以外のCSVの処理間隔を制御するポリシーゲート	設定
getUploaderConfig	HTTP	fc_agent がGCSアップロード先・設定を取得するためのAPI	—

Firestore コレクション一覧（2026-04-12 現在）

コレクション	Doc ID	説明	ソース	種別
riyousha	FC UUID	統合利用者（2拠点統合、名寄せ済み）	riyousha.csv	Master
records	keika_kiroku_{uuid}_{kyoten}_{ts}	経過記録（履歴保持。上書きしない設計）	keika_kiroku.csv	記録
hihosho	{uuid}_{kyoten}_{num}	被保険者証	hihosho.csv	介護
jigyosho	PK_サービス事業者	事業所マスタ	jigyosho.csv	Master
shokuin / unified_shokuin	{code}_{seq}	職員マスタ（統合職員）	shokuin.csv	Master
import_logs	auto	インポートログ	—	システム
import_checkpoints	kyoten_csv	keika差分チェックポイント（重複防止）	—	システム
csv_process_policy	default	CSV処理ポリシー・間隔設定	—	システム
kyoten_id_mapping	auto	拠点ローカルID ↔ UUID 対応表	—	システム
uploader_servers	server-id	fc_agent サーバー設定（ZIP経路・スケジュール）	—	システム
kyoten_config	sapporo / iwaki	拠点設定マスタ	—	システム

セキュリティ & 認証

レイヤー	方式	詳細
Web Console	Firebase Auth + Google OAuth	279279.net ドメイン制限
API Endpoints	x-api-key ヘッダー	Secret Manager 管理（MASTER_API_KEY）
CORS	applyCors() ホワイトリスト	279279.net / tougou-db-f9f9e.web.app のみ
GCS（Storage）Rules	Firebase Security Rules	279279.net ユーザーのみ firstcare-imports-v2/** へ書き込み可
fc_agent 認証	Firebase Service Account	Windows Server に SA キーを配置、GCS直接アップロード

リポジトリ

GitHubytsukuda4470/master-db-cloud-sync

Branchmain

GCPプロジェクトtougou-db-f9f9e

Regionasia-northeast1 (東京)

fc_agent格納scripts/fc_agent/（PowerShell）

拠点一覧ファーストケアの拠点設定

読み込み中...

アップローダー管理Windows Server → Cloud Storage 自動アップロード

読み込み中...

アップロード履歴各サーバーの最近のアップロード状況

日時（JST）	サーバー	拠点	ステータス	ファイルサイズ	詳細
読み込み中...

管理者設定コンソール管理者の追加・削除

管理者のみがシステム設計書 / 拠点設定 / 管理者設定にアクセスできます。

Workspace ユーザーから追加

現在の管理者

メール	ロール	追加者	操作
読み込み中...

freee 認証管理再デプロイ不要でトークンを更新できます

確認中...

🔑 再認証手順

freee 認証ページを開く ↗
279のfreeeアカウントでログイン → 「アプリを連携する」を許可
表示された認可コードをコピーして下に貼り付け → 「更新する」

Google Chat 通知設定取込・エラー発生時のチャット投稿ルールを設定

確認中...

投稿タイミング

投稿しない — チャットへの通知を完全に停止 エラー時のみ通知 — 取込失敗・障害発生時のみ投稿（推奨） 1日1回（朝に前日分） — 毎朝8時に前日の取込サマリーを投稿（推奨） 常に通知 — 取込成功・エラーすべての結果を投稿

Webhook URL

Google Chat の受信 Webhook URL（変更する場合のみ入力）
※ 空欄のまま保存すると、現在登録済みのURLはそのまま保持されます。上書きされません。

2026-04-12 データモデル最新状況

2026-04-10: pk_sapporo / pk_iwaki → firstcare_pks: { sapporo, iwaki }

全拠点のPKを1フィールドに集約。新拠点追加時はコード修正不要。

2026-04-11: records コレクション追加（経過記録）

keika_kiroku_{uuid}_{kyoten}_{timestamp} 形式。上書きせず履歴を保持。import_checkpoints で差分管理。

🗂 Firestore ER図統合利用者DBの全コレクション構造

erDiagram kyoten_config { string id PK "sapporo / iwaki" string name "表示名" number code "FC ID種類ID" string drivePattern "ZIPファイル名" boolean active "取込ON/OFF" } riyousha { string id PK "FC UUID" string shimei "氏名" string birthdate "生年月日" object firstcare_pks "拠点別PK map" string source "fc/merged/ss_only" string ss_riyoushaId "旧SS doc ID" } records { string id PK "keika_{uuid}_{kyoten}_{ts}" string riyoushaId "利用者UUID" string kyoten "拠点ID" string csvType "keika_kiroku" string content "記録内容" string importedAt "取込日時" } hihosho { string id PK "{uuid}_{kyoten}_{num}" string riyoushaId "利用者UUID" string kyoten "拠点ID" string hokenNo "保険番号" } unified_shokuin { string id PK "{code}_{seq}" string shokuinName "職員名" string email "Workspace照合キー" string primary_kyoten "主所属拠点" object app_roles "アプリ別権限" } jigyosho { string id PK "PK_サービス事業者" string jigyoshoName "事業所名" string jigyoshoCode "介護保険番号" string kyoten "拠点ID" } import_logs { string id PK "auto" string kyoten "拠点ID" string fileName "ZIPファイル名" string status "dispatched/completed/error" string importedAt "取込日時" } import_checkpoints { string id PK "{kyoten}_{csvType}" string lastTimestamp "最終処理タイムスタンプ" string lastRowId "最終行ID" } csv_process_policy { string id PK "default" number intervalMinutes "処理間隔(分)" boolean enabled "有効/無効" } uploader_servers { string id PK "server-id" string name "サーバー名" string schedule "実行スケジュール" array kyotenPaths "拠点ZIPパス配列" boolean deleteAfterUpload "アップロード後削除" } kyoten_id_mapping { string id PK "auto" string kyoten "拠点ID" string localId "旧SS doc ID" string unifiedId "新FC doc ID" string csvType "riyousha/shokuin" } kyoten_config ||--o{ riyousha : "firstcare_pks key" kyoten_config ||--o{ unified_shokuin : "primary_kyoten" kyoten_config ||--o{ jigyosho : "kyoten" kyoten_config ||--o{ import_logs : "kyoten" kyoten_config ||--o{ kyoten_id_mapping : "kyoten" kyoten_config ||--o{ records : "kyoten" kyoten_config ||--o{ hihosho : "kyoten" kyoten_config ||--o{ import_checkpoints : "kyoten" riyousha ||--o{ kyoten_id_mapping : "unifiedId" riyousha ||--o{ records : "riyoushaId" riyousha ||--o{ hihosho : "riyoushaId"

★ 新フィールド（firstcare_pks）

旧フィールド廃止予定（pk_sapporo/pk_iwaki）

参照キー

👤 riyousha コレクション統合利用者マスタ（FC + SS統合）

フィールド	型	必須	説明
`id`	string	必須	doc.id = ファーストケアUUID
`氏名`	string	必須	利用者氏名（姓名結合）
`姓 / 名`	string	任意	姓・名（分割フィールド）
`生年月日`	string	任意	YYYY-MM-DD形式
`firstcare_pks`	object	必須	`{sapporo:"123",iwaki:"456"}` ★新規
`pk_sapporo / pk_iwaki`	string	任意	後方互換のため残存。廃止予定
`source`	string	任意	`merged` / `ss_only` / `fc`
`ss_riyoushaId`	string	任意	旧SS docのID（移行追跡用）

👥 unified_shokuin コレクション統合職員マスタ（FC + Workspace統合）

フィールド	型	必須	説明
`統合職員ID`	string	必須	doc.id = {code}_{seq}（例: 1_000001）
`職員名称_姓名`	string	必須	氏名（姓名結合）
`eメール`	string	任意	Workspaceとの照合キー
`primary_kyoten`	string	任意	主所属拠点ID（例: sapporo）
`kyoten_list`	array	任意	所属する全拠点リスト
`app_roles`	object	任意	アプリ別ロール `{appName: "role"}`
`ws_uid / ws_synced_at`	string	任意	Workspace連携情報

🏢 jigyosho コレクション事業所マスタ（FCの事業所データ）

フィールド	型	必須	説明
`PK_サービス事業者`	string	必須	doc.id = FCの事業者PK
`事業所名称`	string	必須	事業所の名称
`サービス事業者番号`	string	任意	介護保険の事業所番号
`kyoten`	string	必須	拠点ID（sapporo / iwaki...）
`サービス種類名称`	string	任意	居宅介護支援 / 訪問介護など

⚙️ kyoten_config コレクション拠点設定マスタ。追加するだけで新拠点に対応。

フィールド	型	必須	説明
`id`	string	必須	doc.id = 拠点ID（小文字英数字例: sapporo）
`name`	string	必須	表示名（例: 札幌）
`code`	number	必須	FCの「ID種類ID」（1=札幌, 2=いわき, 3=盛岡…）
`drivePattern`	string	必須	GoogleDriveのZIPファイル名（例: FirstCareV7_morioka.zip）
`active`	boolean	必須	false にすると取り込みをスキップ

kyoten_id_mapping コレクション旧SS doc ID → 新FC doc ID の対応表

フィールド	型	説明
`kyoten`	string	拠点ID（sapporo / iwaki）
`localId`	string	旧SS doc ID
`unifiedId`	string	新FC doc ID（= riyousha doc.id）
`csvType`	string	riyousha / shokuin / jigyosho
`createdAt`	string	マッピング作成日時

records コレクション経過記録（keika_kiroku）— 2026-04-11 追加。履歴保持設計

設計ポイント: 上書きしない。doc.id に keika_kiroku_{uuid}_{kyoten}_{timestamp} を使用することで、同一利用者の記録が時系列で全て保持される。 import_checkpoints で差分管理し、重複書き込みを防止。

フィールド	型	必須	説明
`id (doc.id)`	string	必須	`keika_kiroku_{uuid}_{kyoten}_{timestamp}`
`riyoushaId`	string	必須	riyousha の UUID（riyousha コレクションの doc.id）
`kyoten`	string	必須	拠点ID（sapporo / iwaki）
`csvType`	string	必須	`keika_kiroku`
`recordDate`	string	任意	記録日（CSVの日付フィールド）
`importedAt`	string	必須	取込日時（JST ISO 8601）

import_checkpoints コレクションkeika_kiroku の差分チェックポイント — 重複書き込み防止

フィールド	型	説明
`id (doc.id)`	string	`{kyoten}_{csvType}`（例: sapporo_keika_kiroku）
`lastTimestamp`	string	最後に処理したレコードのタイムスタンプ（この値より新しいものだけ処理）
`lastRowId`	string	最後に処理した行のID
`updatedAt`	string	チェックポイント更新日時

現在の設定による月額試算

$– （¥–）

Cloud Run 実行コスト（$0.0000295/秒・512MB）の試算値

ZIP処理月間回数

–

月間処理時間

–

現状比

–

⬆ ZIPアップロード間隔（fc_agent） Windowsサーバーから GCS へのアップロード頻度

アップロード間隔

※ fc_agent のスケジュールタスク設定と合わせてください

現在の設定（Firestore）

読み込み中...

📋 CSV種別ごとの処理間隔 ZIPが届いても、設定間隔未満なら処理をスキップします

CSV種別	説明	処理間隔	有効	最終処理	次回処理予定	コスト寄与
読み込み中...

💰 コスト内訳設定変更に連動してリアルタイム更新

🗄

Technical Design Document

279 統合利用者DB — 設計資料

ファーストケア自動エクスポート → fc_agent → GCS → Cloud Functions → Firestore 統合アーキテクチャ　|　2026-04-12 更新

作成: 次田 / Claude

相談相手: 本田エンジニア

CONFIDENTIAL

🌐 システム全体像

flowchart LR SCHED[Cloud Scheduler\n2時間ごと] PUBSUB[Pub/Sub\nfc-agent-commands] SCHED -->|命令発行| PUBSUB subgraph WIN[Windows Server 279_SVR\n札幌・いわき両拠点担当] FC_IWA[ファーストケアいわき\n利用者240名] FC_SAP[ファーストケア札幌\n利用者1567名] AGENT[fc_agent_pubsub.ps1\nNSSMサービス・30秒ポーリング] FC_IWA -->|ZIP生成| AGENT FC_SAP -->|ZIP生成| AGENT end PUBSUB -->|pullAgentCommand API経由| AGENT GCS[(GCS\nfirstcare-imports-v2)] AGENT -->|札幌ZIP upload| GCS AGENT -->|いわきZIP upload| GCS subgraph CF[Cloud Functions] ZIP_PROC[processFirstCareZipV2\nGCS Trigger] KEIKA[processKeikaCsv\n最優先約4秒] ZIP_PROC -->|keika委譲| KEIKA end GCS -->|Storage Trigger| ZIP_PROC subgraph FS[Firestore 統合DB] RIY[riyousha\n利用者] REC[records\n経過記録履歴保持] HIH[hihosho\n被保険者証] SHO[shokuin\n職員] JIG[jigyosho\n事業所] CHK[import_checkpoints\n差分管理] POL[csv_process_policy\nポリシーゲート] LOG[import_logs\n取込履歴] end ZIP_PROC --> RIY ZIP_PROC --> SHO ZIP_PROC --> JIG ZIP_PROC --> HIH ZIP_PROC --> LOG KEIKA --> REC KEIKA --> CHK subgraph APPS[利用アプリ] CARENOTE[CareNote] SOUDAN[新規相談受付] JIGYOSHO_APP[事業所検索] end RIY --> CARENOTE REC --> CARENOTE RIY --> SOUDAN SHO --> CARENOTE JIG --> JIGYOSHO_APP

—

統合利用者数（riyousha）

—

統合職員数（unified_shokuin）

—

事業所数（jigyosho）

2

稼働拠点数（kyoten_config）

📊 データソース比較：スプレッドシート（SS）vs Firestore（統合DB）

観点	スプレッドシート（旧）	Firestore 統合DB（新）
利用者データ
主キー	`利用者ID`（SS独自の連番）	`FC UUID`（ファーストケアのUUID）
FC連携キー	なし（手動入力・管理が煩雑）	`firstcare_pks: { sapporo:"123", iwaki:"456" }`（全拠点PK保持）
データ更新	手動入力・担当者依存	FCのZIPから自動取込（定期実行）
多拠点対応	シートを別に作成（管理分散）	`kyoten_config`に追加するだけで自動対応
重複管理	手作業・ミスが起きやすい	`deduplicateRiyousha`で自動名寄せ
職員データ
主キー	`職員ID`（SS独自）	`{kyoten_code}_{seq}`（例: 1_000001）
Workspace連携	なし	メールアドレスでGoogleアカウントと紐付け
アプリ権限	なし	`app_roles`フィールドで各アプリの権限管理
事業所データ
主キー	`事業所番号`（手動管理）	`PK_サービス事業者`（FCのPK = docId）
データ更新	手動入力	FCのCSV（jigyosho.csv）から自動取込

📁 FCのCSV列 → Firestore フィールド対応表（riyousha）

FCのCSV列名	Firestore フィールド	備考
PK_利用者	firstcare_pks.{kyoten}	拠点別PKをmapで保持
姓 / 名	姓 / 名 / 氏名	氏名は結合して保存
姓_フリガナ / 名_フリガナ	姓_フリガナ / 名_フリガナ	そのまま保存
生年月日	生年月日	YYYY-MM-DD
性別	性別
住所_郵便番号〜その他	住所_郵便番号〜住所_その他	住所系列はそのまま
PK_担当者（職員FK）	担当者FK → 統合職員IDに変換	kyoten_id_mappingで解決

⚠️ 名前が空の行が存在する理由

現在の riyousha コレクションには 3種類のドキュメントが混在しています：

種別	doc.id	名前フィールド	状態
FC由来	FC UUID（8桁+...）	✅ 氏名あり	正常
SS由来（未名寄せ）	利用者ID（SSの番号）	⚠️ 姓・名なし	dedup実行で解消
no_motodb（孤立）	FC UUID	❌ 名前空またはなし	FCのPKと一致するSSがない（569件）

→ 解消方法: deduplicateRiyousha（本番実行）でSS由来ドキュメントをFCドキュメントにマージすれば、名前が空の行は大幅に減少します。

👤

riyousha — 統合利用者

FCとSSのデータを統合したマスタ。doc.id = FC UUID

フィールド	型	必須	説明	更新タイミング
id (doc.id)	string	🔑	FC UUID（名寄せ後はFCが基準）	FC ZIP取込時
氏名 / 姓 / 名	string	✅	利用者氏名（分割・結合両方保存）	FC ZIP取込時
firstcare_pks	object	✅	`{sapporo:"123", iwaki:"456"}` ★新設計	ZIP取込・名寄せ時
pk_sapporo / pk_iwaki	string	—	後方互換のため残存。廃止予定	移行完了後に削除
生年月日 / 性別	string	—	基本属性	FC ZIP取込時
source	string	—	`fc` / `merged` / `ss_only`	名寄せ時
ss_riyoushaId	string	—	旧SS doc ID（移行追跡用）	名寄せ時

👥

unified_shokuin — 統合職員

doc.id = {kyoten_code}_{seq}

フィールド	型	説明
統合職員ID	string	🔑 doc.id（例: 1_000001）
職員名称_姓名	string	氏名（姓名結合）
eメール	string	Workspaceとの照合キー
primary_kyoten	string	主所属拠点ID
kyoten_list	array	所属全拠点リスト
app_roles	object	アプリ別ロール `{appName:"role"}`
介護支援専門員番号	string	ケアマネ番号

🏢

jigyosho — 事業所

doc.id = PK_サービス事業者（FC由来）

フィールド	型	説明
PK_サービス事業者	string	🔑 doc.id = FCのPK
事業所名称	string	事業所の正式名称
サービス事業者番号	string	介護保険の事業所番号（10桁）
サービス種類名称	string	居宅介護支援 / 訪問介護など
kyoten	string	拠点ID（sapporo / iwaki）

⚙️

kyoten_config — 拠点設定

★ 新設計。追加するだけで新拠点に対応

フィールド	型	説明
id (doc.id)	string	🔑 拠点ID（sapporo / iwaki / morioka）
name	string	表示名（札幌 / いわき / 盛岡）
code	number	FCの「ID種類ID」（1=札幌, 2=いわき…）
drivePattern	string	DriveのZIPファイル名パターン
active	boolean	false = 取込をスキップ

🔑

kyoten_id_mapping — ID変換表

旧SS doc ID → 新FC doc ID。各アプリの移行に使用

フィールド	説明
kyoten	拠点ID（sapporo / iwaki）
localId	旧SS doc ID（= 利用者ID）
unifiedId	新FC doc ID（= riyousha doc.id）
csvType	riyousha / shokuin / jigyosho
createdAt	名寄せ実行日時

📋

import_logs — 取込履歴

ZIP取込の全履歴。エラー追跡に使用

フィールド	説明
kyoten	拠点ID
fileName	ZIPファイル名
status	`dispatched` / `completed` / `error`
triggeredBy	drive_trigger / manual_upload
importedAt	取込日時（JST）

✅ 名寄せ完了（2026-04-12）

deduplicateRiyousha を本番実行済み（602件マージ）。FC由来 UUID が正統 ID として確定しました。

以降の ZIP インポートでは riyousha差分チェック（2026-04-12 実装）により、変更がない行の Firestore 書き込みを完全にスキップします。

📊 差分チェック効果（実測）

kyoten_id_mapping を1回の一括クエリでキャッシュ（行ごとクエリ廃止）
既存ドキュメントを30件単位バッチ読み込み（db.getAll）
_csvHash_${kyoten} ハッシュ一致 → 書き込みゼロ
新規 UUID 行のみ従来の resolveRiyoushaUUID フローで処理

🗓️ いわきカットオフフィルター（2026-04-13）

いわき拠点は2024年に札幌DBをまるごとコピーして開始したため、2024-04-01以前のデータはすべて札幌の複製です。

取込前にカットオフフィルターが自動で除外します（val.substring(0,10) <= "2024-04-01"）。

📊 カットオフ効果（実測 2026-04-13）

CSV	いわき全件	スキップ	判定フィールド
riyousha.csv	295	36	レコード作成情報
hihosho.csv	2,658	2,362	レコード作成情報
settei_sentaku.csv	313	281	レコード更新情報
keika_kiroku.csv	429,061	~423,000	レコード更新情報

合計スキップ: 2,697件（いわきZIP処理時間約50%削減）

🔀 名寄せ（deduplicateRiyousha）とは？

ファーストケア（FC）とスプレッドシート（SS）はそれぞれ独立したシステムのため、同じ利用者が両方に存在しています。

名寄せとは「FC由来のドキュメント」に「SS由来のデータ」をマージし、1人 = 1ドキュメントに統合する処理です。

🔍 SS由来ドキュメントの識別方法

// SS由来の条件（3つすべて満たすもの）
1. doc.id が 8桁の数字（例: "00123456"）
2. firstcare_pks フィールドが存在しない
3. pk_sapporo / pk_iwaki フィールドが存在しない
// マージ判定：SSドキュメントにある PK_利用者 を
// firstcare_pks / pk_sapporo / pk_iwaki で逆引きして FC doc を特定
const fcDoc = fcByPk[ss.PK_利用者]  // ← motoDB

📊 Dry-run 結果（2026-04-10 実施）

600

merged
（マージ可能）

5

ss_only
（SSのみ）

569

no_motodb
（FC対応なし）

1174

total SS docs
（SS由来合計）

区分	件数	処理	備考
merged	600件	FC docにSSフィールドをマージ → SS docを削除 → mappingを記録	✅ 本番実行待ち
ss_only	5件	FCに対応なし → SSドキュメントをそのまま残す	手動確認が必要
no_motodb	569件	FC PKと一致するSSが見つからない	⚠️ 要相談：退所済み？データ不整合？

⚠️ no_motodb 569件について本田さんと要確認：
FCの利用者としてCSVにはあるが、SSの「利用者ID」と紐づくPKが見つからない。考えられる原因：
① 退所済みでSSに登録されなかった ② SSのPK列が未入力 ③ 拠点コードの不一致

📋 名寄せ実行前の必須チェック

✅ 完了済み

✔ CareNote Issue #1 移行スクリプト作成
✔ jigyosho-app 移行スクリプト作成
✔ firstcare_pks データモデル実装
✔ kyoten_id_mapping 設計
✔ dry-run 実行・件数確認

❌ 未完了（要実行）

☐ migrate-firstcare-pks.js 本番実行
☐ deduplicateRiyousha 本番実行
☐ CareNote 移行スクリプト実行
☐ jigyosho-app 移行スクリプト実行
☐ no_motodb 569件の方針決定

🗂 ER図 — 全コレクション

erDiagram kyoten_config { string id PK "sapporo/iwaki" string name "表示名" number code "FC ID種類ID" string drivePattern "ZIPファイル名" boolean active "取込ON/OFF" } uploader_servers { string id PK "server-iwaki等" string name "サーバー名" string schedule "実行間隔" array kyotenPaths "拠点ZIPパス" boolean deleteAfterUpload "削除フラグ" } riyousha { string id PK "FC UUID" string shimei "氏名" string birthdate "生年月日" object firstcare_pks "拠点別PK" string ss_riyoushaId "旧SS doc ID" string source "fc/merged/ss_only" } records { string id PK "keika_{uuid}_{kyoten}_{ts}" string riyoushaId "利用者UUID" string kyoten "拠点ID" string csvType "keika_kiroku" string importedAt "取込日時" } hihosho { string id PK "{uuid}_{kyoten}_{num}" string riyoushaId "利用者UUID" string kyoten "拠点ID" } import_checkpoints { string id PK "{kyoten}_{csvType}" string lastTimestamp "最終タイムスタンプ" string lastRowId "最終行ID" } csv_process_policy { string id PK "default" number intervalMinutes "間隔(分)" boolean enabled "有効/無効" } unified_shokuin { string id PK "{code}_{seq}" string shokuinName "職員名" string email "Workspace照合キー" string primary_kyoten "主所属拠点" object app_roles "アプリ別権限" } jigyosho { string id PK "PK_サービス事業者" string jigyoshoName "事業所名" string jigyoshoCode "介護保険番号" string kyoten "拠点ID" } kyoten_id_mapping { string id PK "auto" string kyoten "拠点ID" string localId "旧SS doc ID" string unifiedId "新FC doc ID" string csvType "エンティティ種別" } import_logs { string id PK "auto" string kyoten "拠点ID" string fileName "ZIPファイル名" string status "dispatched/completed/error" string importedAt "取込日時" } kyoten_config ||--o{ riyousha : "firstcare_pks key" kyoten_config ||--o{ unified_shokuin : "primary_kyoten" kyoten_config ||--o{ jigyosho : "kyoten" kyoten_config ||--o{ import_logs : "kyoten" kyoten_config ||--o{ kyoten_id_mapping : "kyoten" kyoten_config ||--o{ records : "kyoten" kyoten_config ||--o{ hihosho : "kyoten" kyoten_config ||--o{ import_checkpoints : "kyoten" uploader_servers ||--o{ kyoten_config : "管理" riyousha ||--o{ kyoten_id_mapping : "unifiedId" riyousha ||--o{ records : "riyoushaId" riyousha ||--o{ hihosho : "riyoushaId" unified_shokuin ||--o{ kyoten_id_mapping : "unifiedId"

2026-04-11〜12 完了事項

✓ fc_agent（PowerShell）実装・Windows Server導入

✓ 279_SVR（いわき・札幌担当）にfc_agent_pubsub配置・NSSMサービス登録・Pub/Sub連携設定

✓ processFirstCareZipV2 + processKeikaCsv 実装

✓ 経過記録（records）コレクション + 差分チェックポイント設計

✓ 月額コスト $255 → $1.62（▼99%削減）を達成

✓ uploader_servers コレクション + Webポータル管理画面実装

次フェーズの開発優先課題

✅ 完了 deduplicateRiyousha 本番実行 2026-04-13 実施済み

SSレガシードキュメント 572件を処理完了。merged: 2件、ss_only: 1件保持、no_motodb: 569件削除。
ss_only残存 0件・名前が空の行を解消。FC由来UUIDが正統IDとして確定。

✅ 完了 fc_agent Pub/Sub移行・常駐サービス化（両拠点） 2026-04-13 実施済み

タスクスケジューラー方式を廃止。Cloud Scheduler → Pub/Sub Pull型に移行。
NSSMで常駐サービス化（FC_Agent_PubSub）。fc_agent_pubsub.ps1 が30秒ポーリング。
動作確認済み: GCPから命令送信 → Windows受信 → アップロード → 処理まで一気通貫で確認。

申し送り済み CareNote riyoushaId 移行（dedup後）

CareNoteプロジェクトへ申し送り済み。carenote_keika/{riyoushaId}/records パスの更新はCareNote側で対応。
参考: deduplicateRiyousha実行後のID対応表は unified_riyousha の firstcare_pks フィールドで確認可能。

申し送り済み jigyosho-app registrations.riyoushaId 移行

jigyosho-appプロジェクトへ申し送り済み。registrations コレクションの旧riyoushaId更新はjigyosho-app側で対応。

P2 中優先 pk_sapporo / pk_iwaki フィールド廃止

firstcare_pks に完全移行後、旧フィールドを削除。全アプリの参照コードも更新。

P3 将来 FCへの逆同期（keika_kiroku → FC への書き戻し）

firstcare_pks を設計した最大の理由。CareNoteで記録した支援経過をFC側にも反映できるように。
要件定義が必要: FC APIの有無・書き込みフォーマット・タイミング

P3 将来 3拠点目（盛岡など）の追加

kyoten_config に新ドキュメントを追加するだけで対応完了。コード変更不要。
fc_agent のインストール手順書（scripts/fc_agent/README.md）に従い非技術者でも設定可能。

確認事項リスト

fc_agent 稼働確認 ✅ — Pub/Sub移行・NSSMサービス常駐化完了（2026-04-13）。「アップローダー管理」タブでリアルタイム確認可能。
no_motodb 569件の扱い — FCにはいるがSSに対応PKがない利用者。退所済み？データ不整合？方針を決めたい。
FCへの逆同期 — FC APIは存在するか？書き込みフォーマット・認証方式は？
deduplicateRiyousha の実行タイミング — 業務に影響しない時間帯は？メンテナンス窓口は必要か？
今後の認証方式 — 全アプリFirebase Auth統一？それとも外部IdP（Azure AD等）への移行予定は？

ダッシュボード

拠点を別サーバーへ移管

パス設定の変更