これは
👉 「今は読まれなくていい。でも後で必ず役に立つ」
👉 「kakanai projectの思想を壊さず、静かに運用できる」
そのための文書です。
1. 本プロジェクトの位置づけ
■ kakanai project とは
kakanai project は、
「記録を書かせる」ことを目的としない
医療・介護・障がい福祉向けの 思考支援・観測支援プロジェクト である。
- 書くこと → 目的ではない
- 読むこと → 人には限界がある
- 気づくこと → 本来、人がやるべき仕事
v6.5 は、その流れの中で
「記録をAIが読み、申し送りとして“整えて返す”段階」 にあたる。
2. v6 → v6.5 の進化ポイント
v6（これまで）
- 温度感（青・緑・黄）を可視化
- 日付 × 担当者の傾向を「見える化」
- 管理者が後から振り返るための仕組み
v6.5（現在）
- 記録内容をAIが読解
- 兆候を検知し、申し送り文を自動生成
- 毎日の意思決定を支援するエージェント化
可視化 → 助言
過去を見る → 「今日どうするか」を考える
3. 現場での基本的な使い方
■ 職員がやること
👉 いつも通り記録を書く。それだけ。
- 新しい操作は不要
- ボタン操作は不要
- AIやシステムを意識する必要はない
■ 職員がやらなくていいこと
- 申し送り文を書く
- 状況をまとめる
- 「今日は何が大事か」を整理する
これらは v6.5 が裏側で行う。
4. 自動処理の流れ（裏側）
■ 実行タイミング
v6.5 は 時間ベースで静かに動く。
- 毎日 8:00
→ 夜勤者・早番向けの申し送り生成 - 毎日 15:00
→ 日中の様子を反映した申し送り生成
※ 職員が忘れても問題なし
※ 手動操作に依存しない設計
5. エラーが起きた場合の考え方
■ 基本方針
現場を止めない・驚かせない・パニックにさせない
- 画面にエラーを出さない
- 職員に「何か直して」と言わせない
- エラーは「静かに記録」される
■ エラー時の挙動
- API制限・通信エラー時
→ 暫定データで記録
→ 管理者が後から確認可能
職員側の業務には 一切影響しない。
6. 導入についてのスタンス
■ 今すぐ導入しない理由
- 現場の理解が追いついていない
- 「便利そう」だけで入れると失敗する
- 運用設計が先、ツールは後
kakanai project は
「急がないこと」を前提に設計されている。
7. 導入判断の目安（管理者向け）
以下の状態になったときが導入タイミング：
- 記録はあるが、読まれていない
- 申し送りが属人化している
- 管理者の「勘」に頼りすぎている
- 問題が起きてから動いている
👉 “異常”ではなく“兆候”を拾いたくなったとき
8. 管理者・導入担当者の役割
■ 管理者がやること
- 申し送りを「判断材料」として使う
- AIの出力を鵜呑みにしない
- 最終判断は必ず人が行う
■ 管理者がやらなくていいこと
- 記録を全部読む
- 毎日細かくチェックする
- 職員にAIの説明をする
9. v6.5 のゴール
v6.5 は 完成品ではない。
- 判断しないAI
- 命令しないAI
- 考える余地を残すAI
それが v6.5 の役割。
10. 次のフェーズ（参考）
v7（構想段階）
- Looker Studio 連携
- 組織DoXダッシュボード
- エンゲージメント・負荷の俯瞰
※ 急がない
※ 今は v6.5 を「静かに使う」ことが最優先
🔚 まとめ
- v6.5 は 現場のための道具
- 目立たなくていい
- 説明されなくていい
- 気づいたら、仕事が少し楽になっている
それが kakanai project の正解。
この説明書は
- 事業所向け説明
- 内部共有
- 将来の導入資料
どれにもそのまま使えます。