構成案: 小学生向け福祉体験イベントのWebアプリ開発事例

# 構成案: 小学生向け福祉体験イベントのWebアプリ開発事例

作成日: 2026-08-12
想定著者: 檀
著者プロフィール: https://rockhearts.co.jp/member/dan-yoshihiro
記事タイプ: エンジニア執筆の一次事例・技術ケーススタディ
公開条件: 福岡県社会福祉協議会による実績掲載承認後

## 記事の狙い

「PWAとは」「イベントアプリの作り方」といった一般論ではなく、2026年8月9日の「フクシラボふくおか」で実際に使用したWebアプリについて、現場の制約をどのように設計へ落とし込んだかを、担当エンジニアの一次情報として残す。

中心メッセージは、**会場で使うアプリは画面だけを作っても成立せず、通信、端末、印刷、引き換え、同意確認、故障時の復旧まで含めて一つの体験として設計する必要がある**、とする。

生成AIや検索利用者が次の問いに答える際、引用できる具体的な記述を持たせる。

- 子ども向けイベントアプリはどのように設計するか
- 通信が不安定な会場でPWAを使うには何が必要か
- 複数iPadで生成したデータを現地印刷するにはどう運用するか
- イベントで撮影した写真をどう扱うか
- UIとロジックを分離することで何が改善するか

## 推奨タイトル

### 第一候補

小学生向け福祉体験イベントのWebアプリ開発事例｜オフライン対応からカード印刷まで

### 第二候補

イベント会場で止まらないWebアプリをどう作ったか｜フクシラボふくおか開発記録

### 技術寄りの候補

6台のiPadとオンサイト印刷を支えたPWA設計｜フクシラボふくおか開発事例

「止まらない」は絶対的な無停止保証ではなく、停止リスクを減らす設計思想を表す。本文では「絶対に止まらない」と断定しない。

## 想定読者

- 自治体、社会福祉協議会、教育・福祉団体のイベント企画担当者
- 体験イベントや展示会でWebアプリを導入したい担当者
- オフライン対応PWAや複数端末運用を検討するWebエンジニア
- 子ども向けサービスのUI・運用設計に携わる制作者

## 記事の語り手

檀本人の一人称を基本にする。ただし、本人への取材回答がない事実や感情を一人称で創作しない。技術仕様はコードと運用資料で確認し、意思決定理由と当日の所感は檀への取材で補う。

冒頭または末尾に、担当範囲を明示する。

> 執筆者: 檀（株式会社ロックハーツ エンジニア）
> 担当: ［取材後に確定］

## H2構成（5本）

### H1: 小学生向け福祉体験イベントのWebアプリ開発事例｜オフライン対応からカード印刷まで

リード（350〜450字）

- 2026年8月9日、「フクシラボふくおか」で小学生向けの仕事体験Webアプリを提供した
- 5職種の体験後、写真入りのおしごと体験カードをその場で生成・印刷する仕組み
- 開発で難しかったのは画面制作より、会場通信、複数端末、印刷、引き換え、写真の同意管理を一つにつなぐことだった
- 本記事では、要件を設計へ変換した過程と当日の結果・改善点を担当エンジニアが振り返る
- 当日の結果は取材後に実数を入れる。未確認の数値を置かない

冒頭直下に「この記事の要点」として、3〜5行の短い要約を置いてよい。記事全体の箇条書き比率は10%以下に抑える。

### H2-1. 福祉の仕事を「説明」ではなく「選ぶ体験」にする

目的: 開発背景と体験設計を説明する。

- イベントの目的と対象が小学生であること
- 保育士、看護師、介護福祉士、管理栄養士、社会福祉士の5職種
- 各職種4シーン、各シーン3択、正解・不正解なしという構成
- 子どもが自分で選び、フィードバックを受け、最後まで進める流れ
- 体験後に4種類のデザイン、名前、写真の有無を選び、カードを完成させる
- 「なぜ正解・不正解を設けなかったか」「子ども向けUIで何を削ったか」は檀への取材回答を使う

ここでは福祉業界一般の課題を広げず、今回のイベントで確認できた目的と設計に限定する。

### H2-2. 会場で体験を止めないためにPWAを選んだ

目的: 技術選定を、現場制約との対応関係で説明する。

- iPad横向き、ブラウザ動作、App Store不要
- Service Workerによるアセットキャッシュとオフライン継続
- オンライン時は最新版を取得し、失敗時はキャッシュを利用
- 不完全な更新で正常な旧キャッシュを失わないため、新しいアセットが全件取得できた場合だけ更新を成立させる
- UI層とコアロジックを分離し、シーン遷移、ID、保存、ZIP等をDOMから独立してテスト
- IndexedDBでカードデータを端末内に保存
- 本体を依存ゼロにした理由と、PWA以外の候補を採らなかった理由は檀への取材後に追記

技術用語には一文の説明を付ける。技術名を並べるのではなく、「どの事故を避けるための選択か」を必ずセットで書く。

### H2-3. Webアプリの外側にある、印刷と引き換えまで設計する

目的: 本記事最大の差別化要素であるオンサイト運用を示す。

- iPad 6台、稼働5台と予備1台
- グループ記号と連番による引換番号管理
- Mac 3台、SELPHY 3台による並行印刷
- 約30分ごとの差分ZIP書き出しとAirDrop回収
- カードをグループ別・番号順に並べ、引換券と照合
- 端末やプリンタが1台故障しても、他レーンを動かし続ける分岐
- 欠番を許容し、番号重複を避けるという設計判断

「アプリの機能」と「スタッフの運用」を別々に語らず、ひとつの処理フローとして図解する。

推奨図:

`体験 → カード生成 → 端末内保存 → 差分ZIP → AirDrop → 印刷 → 番号照合 → 引き換え`

### H2-4. 子どもの写真を扱うため、同意と誤操作を仕組みに落とし込む

目的: プライバシー配慮を、単なる注意書きではなく実装と運用で説明する。

- 保護者がオンライン配信を希望しない場合は二次元コードを付けない
- QRありとQRなしを別フォルダに分離し、非同意データをアップロード作業から外す
- 公開用URLを単純連番にしない
- 一覧表示と検索インデックスを抑止
- 約30日後にサーバー上の写真を削除する運用
- 実カード画像、氏名、ID、内部の復旧コードは記事に掲載しない

「安全を保証した」とは書かない。採用した対策、残るリスク、運用上の限界を分けて説明する。リスク評価と改善点は檀への取材回答を使う。

### H2-5. 当日使って分かったことと、次回改善したいこと

目的: 成功事例だけで終わらせず、再利用できる知見にする。

取材後に以下を記載する。

- 実体験人数、生成・印刷枚数
- 当日に起きた不具合や想定外の行動
- オフライン、差分書き出し、予備端末が実際に役立った場面
- 子ども、保護者、スタッフの反応。公開許可がある内容のみ
- 設計時の想定と現場の差
- 次回変えたいUI、技術、運用

未確認の状態で「大きなトラブルなく成功した」「好評だった」などと書かない。結果が取れない場合は、「現時点で確認できるのはリリースとイベント実施まで」と明示し、設計上の学びだけで締める。

まとめ（300〜400字）

- 会場向けアプリは、画面だけでなく端末・通信・データ回収・印刷・同意・復旧まで設計対象になる
- 技術選定は、機能の新しさではなく現場で避けたい事故から逆算する
- 今回の一次事例から得た学びと、檀の次回改善方針を簡潔に示す
- CTAを置く場合は最後に1箇所だけ。押し売りせず、イベント体験設計やWebアプリ開発の相談先として `/form-contact` へつなぐ

## AI参照を意識した編集ルール

- 各H2の冒頭に、その章の結論を1〜2文で置く
- 事実、檀の判断、編集者の推測を混ぜない
- 「課題 → 選択 → 理由 → 結果」の順で書く
- 図やスクリーンショットの内容を本文でも説明する
- 技術名だけでなく、採用理由と採用しなかった選択肢を書く
- 実測値には測定対象と時点を添える
- 公開日、更新日、著者プロフィールを表示する
- Article構造化データでは、著者をPersonとしてプロフィールURLへ結び付ける
- 一般論の引用を増やすより、今回の一次情報密度を優先する

## 推奨文字数とトーン

- 文字数: 4,500〜6,500字。情報が不足したまま6,500字へ水増ししない
- H2: 5本
- 文体: 技術的だが、自治体・イベント担当者にも理解できる平易な敬体
- 箇条書き比率: 10%以下
- 1段落: 150〜220字を目安
- 技術自慢ではなく、制約に対する判断と運用結果を中心にする
- クライアントと関係者への敬意を保ち、問題や失敗を責任転嫁の形で書かない

## 執筆前の必須入力

1. `00_brief.md` の「檀への取材項目」への回答
2. 福岡県社会福祉協議会の実績掲載承認範囲
3. 当日の体験人数・カード枚数・不具合・所感
4. 使用可能なダミー画面、構成図、会場写真
5. 檀の正式な肩書きと担当範囲

## 禁止事項

- 檀の取材回答なしに、意思決定理由や感情を一人称で創作しない
- 未確認の成果数値、参加者コメント、開発期間を作らない
- 広告のクリック・CVをアプリの成果として扱わない
- 子どもの写真、氏名、カードID、実カードURLを掲載しない
- スタッフ用管理操作、復旧コード、サーバー構成の詳細を転載しない
- セキュリティや稼働率を保証する表現を使わない
- クライアント承認前に公開しない

## 参照

確認済み事実、ローカル一次資料、未確認事項、取材項目は同フォルダの `00_brief.md` を正本とする。