フクシラボふくおか Webアプリ開発事例｜執筆ブリーフ

# フクシラボふくおか Webアプリ開発事例｜執筆ブリーフ

作成日: 2026-08-12
案件: ROCKHEARTS
想定著者: 檀
著者プロフィール: https://rockhearts.co.jp/member/dan-yoshihiro
イベントページ（参照先として保持・本調査では未閲覧）: https://fuku-shakyo.jp/jinzai/fukushilabo/

## 公開ゲート

**福岡県社会福祉協議会による自社実績掲載の承認が確認できるまで、記事を公開しないこと。**

2026年8月10日時点のプロジェクト資料では、「Webアプリ自社実績掲載」について、福岡県社会福祉協議会への確認をロックハーツ社内で依頼した段階。承認済みとは確認できていない。

記事本文の執筆前または遅くとも公開前に、以下を確認する。

- クライアント名・イベント名を実名で掲載できるか
- アプリ画面、カードデザイン、会場写真を掲載できるか
- 技術構成と当日運用をどこまで公開できるか
- 参加人数、体験人数、アンケート等の結果を掲載できるか
- 子どもの写真・氏名・生成カード画像は使用しない。必要な画面例はダミーデータで作成する

## 記事の目的

一般的な「Webアプリの作り方」を解説する記事ではなく、小学生向け福祉体験イベントという現場で、体験設計・端末制約・オフライン対応・写真カード生成・印刷・引き換え・プライバシー保護までを一体で設計した一次事例として公開する。

検索順位だけを狙う量産記事ではなく、生成AIや企画担当者、エンジニアが「イベント向けWebアプリ」「会場で止まらないPWA」「子ども向けUI」「オンサイト印刷」「イベントでの写真データ保護」について調べた際、根拠として参照できるケーススタディを目指す。

## 推奨する中心テーマ

> Webアプリ単体ではなく、来場者の体験から当日のスタッフ運用までを一つのシステムとして設計した。

最も独自性があるのは技術スタックそのものではない。次の現場制約を、設計判断に変換した過程である。

- 小学生が説明を受けなくても進めやすいこと
- 会場の通信状況に依存せず、体験を止めないこと
- 複数台のiPadからカードを回収し、その場で印刷・引き換えできること
- 写真のオンライン配信を希望しない保護者の意思を運用ミスなく反映すること
- 端末故障、AirDrop失敗、印刷遅延などが起きても全体を止めないこと

## 確認済みのプロジェクト情報

### イベント

- イベント名: フクシラボふくおか
- 主催: 福岡県社会福祉協議会 福祉人材センター
- 開催日: 2026年8月9日
- 会場: 天神スカイホール
- 対象: 小学生
- 定員: 150名
- 目的: 仕事体験を通じ、子どもに福祉の仕事への関心を持ってもらうこと
- チラシ上の体験アプリ訴求: 「タブレットで福祉のお仕事を体感しよう！（オリジナルアプリ）」
- アプリ本番リリース: 2026年8月8日（檀）
- イベントは2026年8月9日に実施済み

### アプリで提供した体験

- iPad横向きを前提としたPWA。ブラウザで動作し、App Storeからのインストールは不要
- 5職種から1つを選び、各職種4つのシーンを体験する
- 各シーンは3択で、正解・不正解を決める形式ではない
- 実装上の5職種は、保育士・看護師・介護福祉士・管理栄養士・社会福祉士
- 体験後、4種類からカードデザインを選ぶ
- 名前は最大8文字。写真あり・写真なしの両方に対応
- 完成カードには職種、称号、名前、写真、二次元コード等を描画できる
- カードはL判印刷を想定した1226×1750pxで生成

注意: 初期のチラシ構成案では「福祉用具」と記載された時期があるが、最終実装の `data.js` では「社会福祉士」。記事では最終実装を正とし、初期案を混在させない。

### 技術・設計

- 本体はHTML/CSS/JavaScriptで構成し、ランタイム依存を持たない
- UI層と、シーン遷移・ID発行・カードデータ・保存・ZIP生成等のコアロジックを分離
- 端末内のカードデータはIndexedDBに保存
- Service Workerで必要アセットをキャッシュし、オフライン時にも体験を継続できる設計
- オンライン時はネットワーク上の最新版を優先し、取得失敗時にキャッシュへフォールバック
- Service Worker更新時は必要アセットが全件取得できた場合だけ新キャッシュへ切り替え、不完全な更新を成立させない設計
- 複数台運用ではグループ記号と連番で引換番号を一意に管理
- 公開用IDにはランダム文字列を加え、単純な連番URLにならないようにしている
- カード画像をZIPで差分・一括書き出しできる
- ZIPは件数または容量で分割し、端末メモリと保存失敗のリスクを抑える
- リポジトリREADMEでは、コアロジック123テストと主要UIフロー20件のE2Eテストを用意したと記録されている

テスト件数はREADME記載値。今回、テストの再実行による独立確認は行っていないため、執筆時には「リポジトリでは〜と記録されている」または檀への確認後に確定情報として扱う。

### 当日運用まで含めた設計

- iPad 6台を準備し、5台を稼働、1台を予備とする運用
- 稼働端末をグループ分けし、カード引換番号の重複を防ぐ
- Mac 3台とSELPHY 3台でカードを印刷
- 約30分ごとに新規カードだけを差分書き出しし、AirDropでMacへ回収
- QRありのオンライン配信対象と、QRなしの非アップロード対象をZIP内の別フォルダへ物理的に分離
- 印刷したカードをグループ別・番号順に並べ、引換券と照合して渡す
- 端末故障、カメラ停止、AirDrop失敗、Mac・プリンタ故障を想定した復旧・代替手順を事前に用意

### プライバシー設計

- 保護者がオンライン配信を希望しない場合、二次元コードを付けず、カード画像をアップロード対象から除外できる
- オンライン配信対象と非対象を別フォルダに分け、一括アップロード時の誤公開を防ぐ
- カード保存ディレクトリの一覧表示を無効化し、検索エンジンのインデックス対象外にする構成
- 写真データはイベント後に共有ドライブへ格納し、サーバー上のデータを約30日後に削除する運用
- プロジェクト資料上の削除予定日は2026年9月10日

注意: ランダムURLと一覧表示禁止はアクセス制御そのものではない。記事では「完全に安全」「第三者がアクセスできない」と断定しない。どのようなリスク評価を行ったかは檀への取材で確認する。

## 現時点で未確認の情報

以下は資料から確認できないため、推測で埋めない。

- アプリを実際に体験した人数
- 生成・印刷したカード枚数
- 体験完了率と平均所要時間
- 当日に発生した不具合と件数
- 写真あり／なし、オンライン配信同意／不同意の割合
- 子ども、保護者、スタッフの具体的な反応
- PWA、依存ゼロ、IndexedDB、差分ZIP等を選んだ最終的な意思決定理由
- 開発期間と実稼働時間
- 檀の正確な担当範囲、他メンバーの担当範囲
- 企画当初の課題と、アプリ開発が決まった経緯
- 次回に向けて改善したい点

## 檀への取材項目

回答は箇条書きでもよい。記事執筆AIは、回答を本人の発言として捏造せず、受領した内容だけを使用する。

1. アプリ開発の相談を受けた時点で、何が課題として提示されていましたか。
2. その課題を、どのように機能要件と当日運用へ分解しましたか。
3. ネイティブアプリではなくPWAにした理由は何ですか。
4. 本体を依存ゼロにし、UIとコアロジックを分けた理由は何ですか。
5. オフライン対応で最も難しかった点は何ですか。Service Workerの更新方式を見直した経緯も教えてください。
6. 子ども向けUIで、一般的な業務アプリと変えた点は何ですか。
7. 正解・不正解を設けない3択形式にした狙いは何ですか。
8. カードID、差分ZIP、グループ分けは、どのような当日事故を防ぐための設計ですか。
9. 写真と二次元コードの扱いについて、どのようなリスクを検討しましたか。
10. 実機・会場テストで発見し、設計を変更した点はありますか。
11. 当日は何人が体験し、カードは何枚生成・印刷されましたか。
12. 当日に起きた不具合、想定外の利用行動、スタッフの負荷はありましたか。
13. 子ども、保護者、運営スタッフから印象に残った反応はありましたか。公開許可のある内容だけ教えてください。
14. 開発前に戻れるなら、何を変えますか。次回追加したい改善は何ですか。
15. 檀の担当範囲、開発期間、関係メンバーとの分担を教えてください。

## 推奨素材

- アプリの8ステップが分かる画面キャプチャ。すべてダミー名・ダミー写真を使用
- UI層、コアロジック、IndexedDB、Service Workerの関係を示す簡潔な構成図
- iPadからMac、プリンタ、引き換えまでの当日フロー図
- QRあり／なしで保存先を分ける考え方の模式図
- 会場写真はクライアント承認済みかつ子どもの顔や名札が判別できないものに限定
- 実際のカード画像を使う場合も、ダミーデータで再生成する

## 記事執筆AIへの禁止事項

- 未確認の参加人数、成果、感想、開発期間を補完しない
- 檀の発言を創作しない
- 「完全なセキュリティ」「個人情報漏えいを防止できる」など、保証を意味する表現を使わない
- 子どもの氏名、写真、カードID、実カードURLを掲載しない
- スタッフ用の管理操作、復旧用コード、サーバーの具体的なディレクトリ構成を必要以上に公開しない
- クライアント担当者の氏名、連絡先、社内資料の予算情報を掲載しない
- 広告運用の成果を、Webアプリの成果として混同しない
- 初期仕様と最終実装の差分を確認せず混在させない
- 一般的な福祉DX市場や技術トレンドを外部情報で水増ししない
- 実績掲載承認前に公開しない

## 一次資料

### 開発リポジトリ

- `/Users/shoheishimizu/Downloads/fukushilab-main/README.md`
- `/Users/shoheishimizu/Downloads/fukushilab-main/data.js`
- `/Users/shoheishimizu/Downloads/fukushilab-main/app.js`
- `/Users/shoheishimizu/Downloads/fukushilab-main/service-worker.js`
- `/Users/shoheishimizu/Downloads/fukushilab-main/core/`
- `/Users/shoheishimizu/Downloads/fukushilab-main/docs/DAYOF.md`
- `/Users/shoheishimizu/Downloads/fukushilab-main/docs/SETUP.md`
- `/Users/shoheishimizu/Downloads/fukushilab-main/docs/PREFLIGHT.md`
- `/Users/shoheishimizu/Downloads/fukushilab-main/docs/RESCUE.md`
- `/Users/shoheishimizu/Downloads/fukushilab-main/docs/PRINT_OPS.md`

### プロジェクト資料

- `/Users/shoheishimizu/Library/CloudStorage/GoogleDrive-shimizu-s@rockhearts.co.jp/共有ドライブ/ai_environment/clients/fukuoka_shakyo/CONTEXT.md`
- `/Users/shoheishimizu/Library/CloudStorage/GoogleDrive-shimizu-s@rockhearts.co.jp/共有ドライブ/ai_environment/clients/fukuoka_shakyo/STATUS.md`
- `/Users/shoheishimizu/Library/CloudStorage/GoogleDrive-shimizu-s@rockhearts.co.jp/共有ドライブ/ai_environment/clients/fukuoka_shakyo/references/06_fukushi_lab/brief.md`
- `/Users/shoheishimizu/Library/CloudStorage/GoogleDrive-shimizu-s@rockhearts.co.jp/共有ドライブ/ai_environment/clients/fukuoka_shakyo/references/06_fukushi_lab/flyer_structure.md`
- `/Users/shoheishimizu/Library/CloudStorage/GoogleDrive-shimizu-s@rockhearts.co.jp/共有ドライブ/ai_environment/clients/fukuoka_shakyo/references/06_fukushi_lab/schedule.md`

## 出典の扱い

このブリーフは上記ローカル一次資料だけを使用して作成した。顧客情報を扱うため、Web検索およびイベントページの閲覧は併用していない。イベントページURLは、記事執筆・公開前に承認済み公開情報と照合するための参照先として記録している。