🩺 はじめに
私は看護師です。そして、コードを書きます。
現場で感じていた「申し送りの非効率」を解決するために、
AIでSBAR形式の申し送りを自動生成するWebアプリを作成しました。
今回はバイブコーディングで開発しており、設計とUXにフォーカスしてまとめています。
🔗 デモはこちら（実際に触れます）
🐙 GitHubはこちら
デモは Google Gemini の無料枠を使用しています。1つのIPアドレスから1時間に5回まで利用できます。上限に達した場合は時間をおいてお試しください。
👉 音声 or テキスト入力 → SBAR生成
録音後のSBAR生成画面のスクリーンショット
💡 解決したかった課題
- 申し送りにフォーマットがない
- 新人は何を話せばいいかわからない
- 忙しくて整理する余裕がない
👉 構造化は必要だが、現場では難しい
🧩 アプローチ
SBAR（Situation（状況） / Background（背景） / Assessment（評価） / Recommendation（提案））形式に
AIで自動変換する仕組みを実装しました。
⚙️ 技術スタック
- Next.js 14（App Router） + TypeScript
- Gemini API（Streaming）
- Dexie.js（IndexedDB）
- Zod（バリデーション）
- PWA
⚙️ 実装ポイント
① プロンプト設計（SBAR精度）
SとBが混ざる問題を防ぐため、明確に定義
S: 現在の事実のみ
B: 過去情報
👉 出力精度が大きく改善
② ストリーミングでUX改善
const reader = res.body!.getReader();
👉 「待たされる」体験を削減
③ Privacy by Design
- 音声データは保存しない
- 匿名化されたテキストのみ保持
👉 医療現場では「持たない設計」が重要
④ オフライン対応
- IndexedDBに保存
- 復帰時に自動解析
👉 現場は常にオンラインではない
※初回起動・AI解析には通信が必要
⑤ SBARの手動修正機能
AI出力は完全ではないため、
- SBAR各項目を編集可能
- 1文申し送りも修正可能
👉 「AIは補助、最終判断は人間」という前提で設計
⑥ 型安全（Zod）
z.discriminatedUnion(...)
👉 不正データの流入防止
⑦ APIレート制限
const RATE_LIMIT_MAX = 5;
👉 デモ公開時のAPI枯渇対策
🧠 学び
- SBARは明示的に定義しないと崩れる
- UXは速度より体感が重要
- 医療では「持たない設計」が重要
- オフライン前提が必要
- AIの出力はそのまま使わず、前提設計で制御する必要がある
🚀 動かしてみたい方へ
🐙 GitHub：こちらのREADME.mdをご覧ください。
git clone ...
npm install
npm run dev
環境構築・APIキー設定を行えばローカルで動作します。
また、リポジトリ内の DOCS.md は設計仕様書として整理しています。
この内容を ClaudeCode などのAIに渡すことで、
同様のアプリ構成をベースに再現・カスタマイズすることも可能です。
プロンプトを書き換えることで、自分の現場に合わせたツールに応用できます。
DOCS.mdは実装コードではなく「設計を再現するためのドキュメント」です。
📘 詳細な設計・背景・UI/UX解説はZennで公開中👇
👉 現場の看護師がAIで「申し送り」を解決しようとした話——ミルレコ開発記