現場アプリの試作集(自作デモ)

課題の根拠: サウナの最中はスマホを持ち込めず、濡れた手や熱で画面操作がしづらい。自分自身が使う場面から出発した個人用アプリで、市場調査で裏づけた需要ではありません。
設計判断: 時計だけで完結(単独アプリ)。1 セット=サウナ→水風呂→外気浴を 1 周とする

手動モードは「次へ」を大きく。終了は「このセットを終了」と「サウナを終了して保存」の二択

水に触れる場面のため、防水ロックのボタンを用意

ロジックは画面から切り離し、Mac 上でテストできる形に
構築: SwiftUI + WidgetKit(文字盤)。Xcode 27 / watchOS 27。無料の Apple ID で署名して実機へ。アイコンは 3 色のリングと火の子。
確認できたこと: 純ロジックのテスト 75 件が全て通過(Mac 上)

実機(Apple Watch Series 11)へ導入し、手首で操作(本人が確認)

実機で分かった制約: 防水ロック中のダブルタップは反応しない(公式仕様でもプログラムからの解除は不可)。対策としてアプリ内の「タッチロック」を試作中
未確認・限界: 文字盤コンプリケーション・心拍・防水ロックの触覚は実機で未確認

試作中のタッチロックは時計での確認待ち

Google への記録送信は未設定(送信先未接続)

無料署名のため約 7 日で起動しなくなり、入れ直しが必要(配布用ではない)

アプリアイコン(紹介動画は準備中)

CASE 02 · PWA

熱中症の「報告・連絡・周知」を支える

課題の根拠: 2025 年 6 月 1 日施行の労働安全衛生規則第 612 条の 2 で、暑熱環境での一定の作業について「報告させる体制の整備・実施手順の作成・関係者への周知」が事業者の義務になりました(罰則は労働安全衛生法第 119 条)。
出典: 労働安全衛生規則第 612 条の 2(取得 2026-10-23。自作の調査レポートの整理に基づく)。対象は体制整備・手順・周知で、記録の義務は定められていません。適用される作業の条件は公式の文面で確認してください。
設計判断: 検知も判定もしない。体温・心拍など生体情報は扱わない(医療機器の線を引かない)

「周知した」ことを残す: 手順の版が上がると全員に再確認を求める

具合が悪い人がいたら 1 タップで責任者へ報告 → その場に手順と連絡先、手順の最後は 119 番へ

休憩・水分は「目安の時間」を出すだけ。数値は法令の値ではなく現場が決める設定
構築: 素の HTML / CSS / JS(PWA)。判断部分は画面から切り離した純関数。サーバー不要・月額 $0。圏外でも開けるよう外部フォントなし。
確認できたこと: 純関数のテスト 12 件が通過(60 分で休憩・30 分で水分の境界、報告→対応済み、手順更新で再確認、CSV ほか)

ヘッドレスブラウザで実際に操作して 18 項目を確認(周知を読むまで開始できない・時間を進めてリマインド・報告で手順と 119 が出る・リロードしても保持・横スクロールなし)
未確認・限界: 実際の現場で使われた実績はありません。現場の個人の声も集められていません

責任者への通知は同じ端末内の画面のみ。複数端末の連携(サーバー)はこのデモにはありません

実機のスマホでのホーム画面追加・オフライン動作は未確認(ブラウザでの確認のみ)

手順・連絡先の文言はサンプル。実運用の内容は現場の責任者が決めます

上の枠の中で実際に動きます。「+60分」で時間を進められます。
単独で開く

CASE 03 · PWA

定型記録 → 日報。業種の違いは「設定」だけ

課題の根拠: 温度・巡回・清掃のような「毎日同じ項目を書いて、基準外なら対応を残す」記録は多くの現場にあります。ただし同種の記録アプリは既に複数あり、これは売り物の主張ではなく、設計の実演です。
設計判断: 記録票と項目を JSON で定義。コードを変えずに業種を差し替えられる

基準外の値は、是正措置を書かないと保存できない

数字が空欄のまま保存しない(黙って 0 にしない)

日報は文面コピー・CSV・印刷の 3 通り(送信はしない)
構築: 素の HTML / CSS / JS(PWA)。設定の検証(重複 ID・不正な種類・min>max)つき。サーバー不要。
確認できたこと: 純関数のテスト 11 件が通過(境界値・JST の日付・CSV の引用符ほか)

ヘッドレスブラウザで 17 項目を操作確認(是正措置なしで保存されない・設定差し替え・不正な JSON を弾く・コピーと CSV)
未確認・限界: 実運用の現場での検証なし。基準値(冷蔵 0〜10℃ など)は例で、公的な基準の確認は未実施

データは端末内のみ。端末が変わる・ブラウザのデータを消すと失われます(CSV で保管)

写真添付・署名・複数人での共有は未対応

「冷蔵庫」に 12 と入れると基準外に。
「設定」タブで JSON を書き換えると業種が変わります。
単独で開く

CASE 04–06 · PWA

調査の候補一覧から、作例を 3 つ

自作の市場調査(2026-10-23)で挙がった候補のうち、見せ方が分かりやすいものを試作しました。調査では現場の個人の声が集められておらず、需要の裏づけが弱い候補も含みます。作例としての位置づけです。

04 荷待ち・荷役の打刻(物流)

課題の根拠: 物流効率化法で、荷主・運送事業者に荷待ち・荷役の効率化が努力義務(2025-04)、特定事業者には計画・定期報告が義務(2026-04)。
出典: 自作の調査レポートの整理(取得 2026-10-23・確度中〜高。一次資料の再確認はしていません)。荷待ち時間の計測方法は業界で統一されていない、という指摘があります。
設計判断: 到着 → 荷役開始 → 荷役終了 → 出発を、順番どおりにしか打刻できない(誤タップで飛ばさない)
押し間違いは直前の打刻だけ取り消し
超過の印は「現場・荷主が決める設定値」(法令の値ではない)
確認できたこと: 純関数のテスト 10 件・ヘッドレスブラウザで 12 項目(二重到着を弾く・時間を進めて超過の印・日報の文面コピー・CSV・リロード後の保持)。
未確認・限界: 特定事業者は大企業中心で、顧客の規模が合わない可能性があります
荷主への報告様式・既存の運行管理との連携は未確認。現場の声も 0 件

車両名を入れて「到着」。「+60分」で待たされた状態に。
単独で開く

05 訪室タイマー(夜勤の見守り巡回)

課題の根拠: 夜勤の見守り巡回は 30 分〜2 時間ごと(重度は 10 分)の訪室と、複数の帳票への重複記入が負担、という公的資料・ベンダー資料が複数ありました(件数 3〜4・確度中)。
設計判断: バイタルの測定・異常の判定はしない。記録するのは訪室の時刻と、職員が選ぶ 3 つの状況だけ
居室ごとの間隔で「次に見に行く順」を並べ、遅れを赤く示す
介護の情報は預からない設計(このデモはダミーのみ)
確認できたこと: 純関数のテスト 9 件(期限ちょうどは遅れでない・取消・JST の CSV ほか)・ヘッドレスブラウザで 8 項目。画面にバイタル系の語が無いことも確認。
未確認・限界: 実際の施設の運用・帳票との突き合わせは未実施。見守り機器の製品が先行しています
医療・介護の情報を預かる受託は責任が重く、北極星では避ける領域です。作例として示すだけです

「+60分」で遅れの居室が赤くなります。
単独で開く

06 並行タイマー(施術の工程)

課題の根拠: 美容室などで「手が離せない・並行して施術する」場面があるという整理でしたが、現場の声の裏づけは弱く(確度低)、安価な既存のタイマーアプリも多数あります。需要の主張ではなく、動きの作例です。
設計判断: 終了が近い順に並べる。終わったものは「確認した」を押すまで消えない(見逃さない)
延長 +5 分・音と振動の合図
毎秒は数字だけ更新し、ボタンは状態が変わる時だけ作り直す
確認できたこと: 純関数のテスト 9 件・ヘッドレスブラウザで 9 項目。確認中に実際の不具合を 2 つ見つけて直しました(タイマーが 0 本のとき案内が出ない/毎秒の描き直しと拡縮で、押そうとしたボタンが入れ替わりタップを取りこぼす)。
未確認・限界: 音・振動はスマホ実機で未確認(ブラウザは画面を一度触るまで音を鳴らせません)
画面を閉じている間の通知は未対応(ブラウザの制約)

工程を選んで開始。下の「デモ用」で時間を進めると終了します。
単独で開く

PROCESS

つくり方 — 確かめた分だけ書く

根拠を一次資料で取る法令・公的資料まで遡り、取得日を残す。取れなければ「分からない」と書く。
やらないことを先に決める検知・診断・判定、効果の保証、他社実績の引用はしない。
判断部分を画面から切り離して、テストで固める境界値・空欄・二重操作を先にテスト。時刻は外から渡す。
実際の画面で操作して確かめるヘッドレスブラウザで通し操作。実機でしか分からないものは「未確認」のまま残す。

やっていないこと
現場への導入、効果の測定、お客さんの声の収集。数字の成果は載せません。

画面について
人名・電話番号・数値はすべてダミー。入力は端末の外へ送られません。