「みんなの水」要件整理

1サービス概要

地震で井戸が使えなくなった熊本県八代市の世帯に、給水車で水を届ける NPO サービス。
サポーターは一覧から 1 世帯を選び、世帯人数に応じた月額（平均水道料金と同額）を寄付して、その世帯の給水を支える。

運営は一般社団法人 能登乃國百年之計。
決済はコングラントの継続寄付を使う。

サービスを支える 3 つのアプリ

申し込みフォーム世帯

被災世帯がタンクとポンプの無料設置を申し込む入口。
申し込むと受付番号が発行され、スタッフが訪問して設置する。
仕組みの詳細は 8 章。

みんなの水 本体サポーター

サポーターが水を待つ世帯の一覧から 1 世帯を選び、月々の寄付で支える公開サイト。
給水が始まると、世帯からの毎月の便りがここを通じてサポーターへ届く。
仕組みの詳細は 9 章。

給水マップ給水スタッフ

給水スタッフが「今日どこへ水を届けるか」を確認し、配達の実績を記録する地図。
班分けと巡回順の管理にも使う。
仕組みの詳細は 10 章。

2用語

世帯

井戸が使えなくなり、給水を必要とするお宅。

サポーター

一つの世帯を選び、月々の寄付でその世帯の給水費を支える人。

マッチング

世帯とサポーターの組が成立すること。

支援コード

寄付がどの世帯に向けたものかを決済側に伝えるコード（形式 MZ-A003-K7QF）。

設置完了

給水を受けるためのタンクとポンプの設置が終わった状態。現行の申込管理では「対応完了」。厳密な定義は未確定（5.1）。

便り

給水中の世帯が月 1 回投稿する近況とお礼。サポーターにメールで届く。

自費世帯

給水費を寄付でなく自分で払う世帯。一覧には掲載しない。

班

その日に給水を回る給水トラックのチーム。

採番

マップのピンへ、班ごとの巡回順の番号を振り直すこと。

隔日（青ピン）

2 日に 1 回の給水でよい世帯の属性。マップの青色（本日給水済み）とは別物だが、運用の呼び名として定着しているため併記する。

遅れ（赤ピン）

前回給水から 3 日以上（隔日世帯は 4 日以上）空いた状態。マップでは赤で表示される。

3サービスのルール

世帯とサポーターの流れ

支援は次の 1〜5 の順に進む。

共通のルール

月額と料金表サポーター

サポーターの月額は、世帯人数に応じた平均水道料金と同額に設定する。

11 人以上は 1 人 1,500 円を加算。
人数不明は 6,500 円。
給水に使うタンクやポンプなどの資機材は、単発の寄付で別に募っている。

自費世帯と自己負担世帯

給水費を自分で払う世帯（自費世帯）は公開一覧に載せず、運営が毎月の寄付を案内する。
申込の完了画面では、費用を自分で払いたい世帯向けに、任意の自己負担（世帯人数分の月額を寄付）を案内する。
寄付の有無で給水の内容は変わらない。

給水の運用給水スタッフ

給水は原則毎日で、2 日に 1 回でよい世帯は「隔日（青ピン）」として扱う。
前回給水から 3 日以上（隔日は 4 日以上）空いた世帯は「遅れ（赤ピン）」とみなす。

その日の班数を決め、班ごとに効率のよい順番で回る（順番の付け方は 変更 6 で見直す）。

設置スタッフの報酬設置スタッフ

タンク設置はスタッフへの委託で、報酬はタンク 1 台 8,000 円（税込）。
法人へ月ごとに請求する。

4変更したい点

4.1 支援コードの手入力をなくす

手入力には、控え忘れや入力間違いで寄付とマッチングが結びつかない弱点と、転記の手間がサポーターの離脱点になる弱点がある。
変更後は、世帯ごとの寄付リンクから決済フォームへ遷移するだけで、どの世帯への寄付かが運営に伝わる状態を目指す。

実現の候補はコングラントの「支援ルート」機能（世帯ごとの専用 URL を作ると、決済記録に経由 URL が自動で残る）。

flowchart LR
    subgraph now["現状"]
        A1["世帯を選ぶ"] -->|"支援コードを発行"| B1["サポーターが控える"] -->|"コメント欄に手入力"| C1["コングラントで決済"]
    end
    subgraph after["変更後"]
        A2["世帯カード"] -->|"世帯ごとの専用リンク"| C2["コングラントで決済（世帯が自動で記録）"]
    end
  

4.2 マッチングを寄付完了時点に移す

現状は自己申告や手動確認で成立とするため、決済の事実とずれうる。
寄付の完了（決済側の記録）をもって成立とし、一覧の表示と実際の支援状況を一致させる。

4.3 掲載を設置完了時点に移す

現状は、掲載に同意した世帯が資機材の設置を待たずに一覧へ載る。
変更後は設置完了した世帯だけを掲載し、一覧の世帯はすべて「サポーターがつけば給水を始められる家」にする。

stateDiagram-v2
    direction LR
    [*] --> 申し込み済み: フォーム入力
    申し込み済み --> 募集中: 設置完了（ここで掲載）
    募集中 --> 水が届いている: 寄付完了
    水が届いている --> 井戸が復旧: 通水
  

状態の正式な名前と全体像は 5.1 で定義し直す。

4.4 ドメインを minnano-mizu.jp に統一する

サポーター向けサイトと被災者側フォームは一続きの仕組みなので、同じドメインの下で動かす。

4.5 ふるさと納税コードによる寄付を加える

八代市にふるさと納税をした人にコードを発行し、「みんなの水」で入力すると寄付ができるようにする。
月々の寄付とは別の入口であり、制度と仕様の両方に未確定点が多い（5.4）。

4.6 採番にピンの扱いを反映する

現状の採番は緊急度と隔日を考慮しないため、優先して届けたい世帯でも順番が後ろになることがある。
変更後は遅れ（赤ピン）の世帯が早い番号になるよう優先し、隔日（青ピン）の世帯は採番の対象から外す（隔日は番号を持たない）。

flowchart LR
    subgraph now["現状の採番"]
        direction LR
        n1(["1"]):::other --> n2(["2"]):::blue --> n3(["3"]):::red --> n4(["4"]):::other --> n5(["5"]):::red --> n6(["6"]):::blue
    end
    subgraph after["変更後の採番"]
        direction LR
        a1(["1"]):::red --> a2(["2"]):::red --> a3(["3"]):::other --> a4(["4"]):::other
        b1(["隔日"]):::blue
        b2(["隔日"]):::blue
    end
    classDef red fill:#bf4a3d,color:#ffffff,stroke:none
    classDef blue fill:#3f6dab,color:#ffffff,stroke:none
    classDef other fill:transparent,stroke:#888888,color:#888888
  

優先の度合いと、隔日世帯を外す期間の扱いは未確定（5.5）。
班数の上限（変更 7）は同じ画面の設定であり、15 程度へ広げる。

5未確定の仕様

決めないと実装や運用に進めない点を挙げる。

6段階分け

作り直しは段階に分けて進める。
最初の段階を Phase 1 と呼ぶ。

Phase 1（公開サイトを一日で作る）

目的は新しい公開サイトのガワを見せることで、何よりも速さを優先する。

• 対象は公開サイト（トップ、世帯一覧、世帯詳細、支援申し込みの導線）のみ。便り、申込フォーム、給水マップ、運営処理は既存 GAS を使い続ける。
• 支援申し込みの導線は支援ルート方式（4.1）に前倒しする。世帯カードから世帯ごとの支援ルート URL へ直接リンクし、仮押さえと支援コード発行は作らない。
• 世帯データは「支援募集」シートの掲載世帯（支援ID、表示名、地区、世帯人数、公開メモ、月額、状態）を運営から受け取り、手動で同期する。自動連携は作らない。
• 画面は現行を踏襲せず、新デザインで作る。現行の公開一覧ページはクライアント側描画のため URL から中身を取得できず、文言も新規に書き起こす。
• 公開先は minnano-mizu.jp とする（取得済み）。

実施日は未定。
着工までに必要な準備は次のとおり。

• コングラントで掲載世帯分の支援ルートを作成し、URL の一覧を用意する（運営）。
• 「支援募集」シートの掲載世帯データを渡す（運営）。
• minnano-mizu.jp を Cloudflare に登録し、ネームサーバーを切り替えておく。

実装時の注意

• 公開サイトに、サポーター向けの注意書きとして「支援先の世帯が給水を必要としなくなった場合、支援は別の世帯へ引き継がれることがある」ことを載せる。現行のサポーター自動移行（9 章）は事後のメール連絡だけで、サポーターが事前に知る場所がない。

7全体構成

GAS ウェブアプリ 3 つが、スプレッドシート 2 冊を介して連携する。
アプリ間の API はなく、すべてシートの読み書きとメールでつながる。

flowchart LR
    R[被災世帯] --> FORM
    S[サポーター] --> MAIN
    V[給水スタッフ] --> MAP
    subgraph gas["GAS ウェブアプリ"]
        FORM["申し込みフォーム"]
        MAIN["みんなの水 本体"]
        MAP["給水マップ"]
    end
    subgraph sheets["スプレッドシート"]
        SS1[("水回り支援_申込一覧")]
        SS2[("給水ボランティア記録")]
    end
    CG["コングラント（決済）"]
    FORM -->|"申込を追記"| SS1
    MAIN <-->|"30分ごとに取り込み・状態更新"| SS1
    FORM -->|"対応完了でピン追加"| SS2
    MAP <--> SS2
    MAIN -.->|"寄付ページへ誘導"| CG
    CG -.->|"コメント欄の支援コードを運営が目視照合"| MAIN
  

3 つのアプリの役割分担

世帯からみると、申込から卒業までのあいだに 3 アプリすべての世話になる。
受け持ちが途中で切り替わる点が、後述する連携の弱さ（11 章）の背景である。

flowchart LR
    S(["世帯が申し込む"]) --> T["30分ごとに取り込み<br>同意があれば掲載（本体）"]
    S --> I["訪問調査と設置<br>対応完了でピン登録（フォーム→マップ）"]
    T --> M["サポーターが決まり給水中（本体）"]
    I --> W["毎日の給水と記録（マップ）"]
    M --> L["毎月の便り（本体）"]
    W --> G
    L --> G(["通水で卒業<br>本体とマップを別々に手動更新"])
  

外部サービスとの連携

世帯を指す番号が 3 系統ある

flowchart LR
    A[("申込一覧<br>受付番号")] -->|"受付番号をキーに取り込み"| B[("支援募集<br>支援ID")]
    A -->|"氏名と住所の文字一致で連携"| C[("給水ポイント<br>ポイントID")]
    B -. "対応表なし" .- C
  

支援ID とポイントID を結ぶ情報はどこにもなく、同じ世帯を二重に管理する原因になっている（11 章）。

8申し込みフォーム

概要

被災世帯がタンクとポンプの無料設置を申し込むフォーム。
同じ画面にスタッフ向けの申込管理と請求書発行が同居する（共有の暗証番号つき。番号は本書に記載しない）。

役割

本来の役割は申込の受付だが、受付後の運用もここで完結する。
スタッフは同じ画面で対応状況を管理し、対応完了にした世帯は給水マップへ自動でピン登録される。

設置スタッフへの支払いも担っており、月ごとの設置実績から請求書 PDF を発行して法人へ請求する（報酬のルールは 3 章）。
フォームの冒頭には、未対応と対応中の件数から「現在◯人待ち」を表示する。

データモデル

「水回り支援_申込一覧」スプレッドシートの「申込一覧」シート 1 枚に、性格の違う列が同居する。

写真はドライブ「水回り支援_申込データ」、請求書は「請求書控」シートと PDF フォルダに記録する。

処理の流れ

申込世帯

sequenceDiagram
    actor R as 世帯
    participant F as フォーム
    actor O as 運営
    R->>F: 入力して送信
    F->>F: 受付番号を発行し、シートへ追記。写真はドライブへ保存
    F-->>O: 全文と写真添付のメール
    F-->>R: 受付完了メール
    F-->>R: 完了画面で任意の自己負担を案内
  

受付番号は yyMMdd-HHmm に乱数 2 桁を足した形式。
水道契約が有る世帯は対象外として送信をブロックし、それ以外の世帯には掲載への同意チェックを必須とする。

完了画面の自己負担の案内（ルールは 3 章）では、コングラントのコメント欄に受付番号を書いてもらい、運営がどの世帯の負担かを突き合わせる。

対応管理設置スタッフ

stateDiagram-v2
    direction LR
    [*] --> 未対応: フォーム送信
    未対応 --> 対応中: 訪問調査
    対応中 --> 対応完了: 設置完了
    未対応 --> キャンセル
    対応中 --> キャンセル
  

状態の更新には担当者名と日付を、キャンセルには理由も記録する。
対応完了にした瞬間、給水マップへ「氏名＋様宅」の名称でピンを自動登録する（同名か同住所のピンがあれば追加しない）。

キャンセルにすると、本体側の取り込みが検知してサポーターの自動移行が走る（9 章）。

請求書設置スタッフ

設置スタッフが対象月の自分の設置実績を読み込み、住所と振込先を入力すると、請求書 PDF が発行される。
PDF は本人へメールされ、台帳シートに記録が残る。

9みんなの水 本体

概要

サポーターが世帯を選んで支援する公開サイトと、その裏の運営処理。
世帯の取り込みから公開、マッチング、便り、卒業までのライフサイクルを管理する。

役割

世帯のライフサイクル全体を一手に担う。
30 分ごとに申込一覧から世帯を取り込んで匿名化し、掲載に同意した世帯を公開一覧に載せる。
サポーターの申し込みを仮押さえと支援コードで受け付け、入金確認を経て給水開始とその通知を行う。

給水開始後は、便りの受付と 35 日途絶の検知で支援の継続を見守り、申込がキャンセルされた場合はサポーターを別の世帯へ自動で移す。
このほか、自費世帯の一覧を毎月 1 日に実名と電話つきで運営へメールする。

データモデル

申込と同じスプレッドシートに 3 シートを追加する。
3 シートは支援ID で結びつく。

月額は世帯人数から自動計算する（料金表は 3 章）。
同じ表がフォームの完了画面にもハードコードされている（11 章の課題 3）。

世帯の状態

stateDiagram-v2
    [*] --> 募集中: 取り込み（同意があれば掲載）
    募集中 --> お手続き中: サポーターが選ぶ
    お手続き中 --> 募集中: 30分で期限切れ
    お手続き中 --> 給水中: 自己申告または入金確認
    state 給水中 {
        [*] --> 便りが続いている
        便りが続いている --> 連絡確認中: 世帯の投稿が35日途絶（自動）
        連絡確認中 --> 便りが続いている: 世帯が便りを投稿（自動で復帰）
    }
    給水中 --> 募集中: サポーター離脱（運営の手動操作）
    給水中 --> 通水・卒業: 運営の終了操作
  

連絡確認中とは：便りが 35 日止まった世帯を、運営が電話などで確かめている状態。
便りが止まる典型は井戸が直って連絡が不要になったケースで、通水していればそのまま終了操作で卒業になり、まだ水が要るなら便りの再開で元に戻る。
公開一覧ではどちらも「給水中」と表示され、区別は運営にしか見えない。

図とシートの対応：シートの状態列の値は「募集中」「お手続き中」「給水中」「連絡確認中」「通水・卒業」の 5 つ。
図で「便りが続いている」と描いた内部状態が、シートの「給水中」にあたる。

状態と掲載区分は別もの：世帯は状態のほかに掲載区分（掲載／非掲載／自費）を持ち、公開一覧に出るのは「掲載」の世帯だけである。

卒業とサポーター離脱：「通水・卒業」にした世帯は戻せない。
サポーターの解約（コングラント側の継続寄付停止）を検知する仕組みはなく、気づいた運営が支援申告を「停止」にし、シートを直接編集して世帯を募集中へ戻す。

処理の流れ

取り込みと匿名化（30 分ごと）自動

要件に「設置」を含む申込だけを取り込み、支援ID（A＋3 桁連番）を振る。
個人情報は 3 章の公開範囲に従って変換する。
イニシャルはふりがなから作り、地区は住所から町名までを抽出し、断水の状況は 160 字の公開メモに整形する。

掲載区分は申込の「費用のご希望」で決まる。
掲載同意があれば「掲載」、実費（旧フォームのみ）は「自費」、選択がなければ「非掲載」のまま運営が手動で確認する。

支援の成立サポーター運営

sequenceDiagram
    actor S as サポーター
    participant M as みんなの水
    participant C as コングラント
    actor O as 運営
    S->>M: 世帯を選ぶ（名前とメールを入力）
    M-->>S: 支援コードを発行（30分仮押さえ）
    S->>C: コメント欄にコードを書いて継続寄付
    S->>M: 「寄付を完了しました」ボタン
    Note over M: 申告だけで「給水中」になる（決済の裏取りなし）
    O->>C: コメント欄のコードを目視照合
    M-->>S: 給水開始メール
    M-->>O: 世帯へ便りURLの送付依頼（世帯メール未登録時）
  

給水中への遷移は、自己申告ボタンのほかにシートのメニューと確認状況セルの直接編集があり、入口が 3 つある。
処理は共通で、便りトークンを発行し、サポーターへ開始メールを、世帯へ便り URL を送る。
期限切れの仮押さえは 10 分ごとの自動実行が募集中へ戻す。

サポーターへの連絡サポーター

便り世帯

sequenceDiagram
    actor H as 世帯
    participant M as みんなの水
    actor S as サポーター
    H->>M: 専用URLから近況とお礼を投稿（月1回、写真は任意）
    M-->>S: 便りをメールで届ける
    Note over M: 最終便り日を更新。連絡確認中なら給水中へ自動復帰
    loop 毎朝7時
        M->>M: 便りが35日途絶えた給水中の世帯を「連絡確認中」へ
    end
  

メッセージは 500 字までの必須項目。
継続の約束と終了判断のルールは 3 章のとおりで、システムが自動化しているのは途絶の検知までである。

申込キャンセルとサポーター自動移行自動

flowchart TD
    A["申込側がキャンセルになる"] --> B{"給水中だったか"}
    B -->|いいえ| C["一覧から外し、運営へ記録メール"]
    B -->|はい| D{"募集中の世帯があるか"}
    D -->|ある| E["サポーターを自動移行<br>月額が同じ世帯を最優先<br>次に世帯人数が近い順"]
    E --> F["サポーター、新世帯、運営へメール"]
    D -->|ない| G["運営へ要対応メール<br>サポーターには連絡しない"]
  

月額が変わる移行では、サポーターへコングラント側での金額変更を依頼するメールが送られる。

10給水マップ

概要

給水スタッフが現場で使う地図アプリ（Leaflet と OpenStreetMap）。
どこへ水を届けるべきかの把握と、給水実績の記録に使う。

役割

給水先、水源、拠点をピンで管理し、前回給水からの経過日数で緊急度を色分けして「今日どこへ行くべきか」を示す。
スタッフはその場で給水量と担当者を記録し、本日の合計 L と給水済み箇所数がヘッダーに集計される。

管理メニューでは班分けとルート採番を行い、1 日の終わりには LINE にそのまま貼れる日報を生成する。
ピンごとに現場メモ（例「バックで入る」）と写真も持てる。

データモデル

独立した「給水ボランティア記録」スプレッドシートを使う。
世帯一覧との対応表はない。

ピンの色は保存値ではなく、表示のたびに前回給水からの経過日数で決まる（「遅れ」の定義は 3 章）。

隔日ポイントには白丸「2」のバッジが重なる。
隔日は手動指定できるほか、直近 3 回の給水が 1 日あたり 100L 以下なら自動でそうみなす。
水源と拠点は青緑、通水済みは灰色で、いずれも給水記録の対象外である。

処理の流れ

給水の記録給水スタッフ

ピンを開いて給水量 L（満水で不要なら 0）と担当者、備考を記録すると、ヘッダーの本日集計が更新される。
担当者名は端末に記憶され、次回の入力を省ける。

日報給水スタッフ

「本日の報告」を押すと、給水済み、未給水、隔日スキップ、通水済みをまとめたテキストが生成され、そのまま LINE へ共有できる。

班分けと採番（管理メニュー）運営

flowchart LR
    A["対象を抽出<br>有効な給水先のみ"] --> B["作業量を見積もる<br>滞在10分＋給水量見合い"]
    B --> C["扇形に班数分割<br>作業量が均等になる切り方"]
    C --> D["班ごとに巡回順を決定<br>水源起点の最近傍法＋2-opt"]
    D --> E["A1、A2…と採番<br>担当団体列とルート順列へ"]
  

対象から水源、拠点、通水済み、座標のないピンを除く。
隔日かどうかは考慮しない。
給水量の実績は直近 7 日の平均を使い、実績のない新規ピンは 150L/日 とみなす。
班数は画面では 1〜4、コード上は 6 まで選べる。

「AI が並べ直す」と呼ばれてきた機能の実体はこのヒューリスティックで、LLM 等は使っていない。

その他の管理運営

ピンの追加は住所を国土地理院のジオコーダで座標化し、見つからなければ地図をタップして位置を指定する。
重複ピンの整理は、住所の表記ゆれをならしたうえで、住所と用途が同じピンを 1 件残して停止にする。

11横断的な課題

1. 世帯の番号が 3 系統で、対応表がない（7 章）。
2. 世帯一覧と給水マップが別のデータベースで、卒業（通水）を別々に手で更新している。
3. 料金表と寄付 URL が 2 箇所にハードコードされている。
4. 給水中への遷移の入口が 3 つあり、挙動差が生まれやすい。
5. 入金確認は申告ベースで、決済の事実を確認していない。
6. ジオコーダが 2 種類あり、同じ住所でも座標がずれうる。
7. 便りと給水ポイントの写真は、リンクを知っていれば誰でも見られる。
8. 暗証番号は平文で、フォームとマップに別々にある。
9. 一括操作や誤り訂正の手段がなく、使い捨てスクリプトをエディタから直接実行してきた。
10. 本体の公開 URL がハードコードされ、再デプロイのたびに書き換えが要る。