はじめまして。データビジネス本部の木村です。普段は福岡オフィスで Python の機械学習系のライブラリを使ったデータ分析・予測モデルの構築を行っています。
IDCF は今年、高齢者介護施設においてIoTセンサーとデータ分析技術を活用し、機械学習による介護/看護職員の行動認識・業務分析を実証実験として実施しました。今回はその実証実験について、技術視点でお伝えしたいと思います。
Contents:
実験フィールドは「介護現場」
このプロジェクトは、福岡県を中心に全国で84施設の介護施設を運営する株式会社さわやか倶楽部さん、九州工業大学、 IDCF の合同で行われた実証実験です。 IoT デバイスを使ったセンシングと機械学習により、施設の職員の方々の行動認識を行いました。
実験フィールドは、福岡県北九州市にある定員65名の介護付き有料老人ホームです。それなりに大きな介護施設で、利用者の方々も職員の方々もたくさんいらっしゃいます。実験時は介護士の方が22名、看護師の方が5名でした。
実験の目的は「職員の業務効率化」
職員の方々は、日々の業務を手書きで記録しています。記録業務は、業務時間全体で大きなウェイトを占めています。そこで、実験ではセンシングと機械学習により行動認識を行い、業務を推定することで記録業務を自動化したいというねらいがありました。また、行動認識により「いつ」「どこで」「誰が」「何を」していたかを蓄積することで、職員の業務負担を可視化して忙しい時間と場所にリソースを分配するなど、介護業務の効率化・品質向上を図るねらいもありました。今回は実証実験として、各手法が「本当に業務効率化の役に立つか？」にフォーカスしています。 IDCF としては、センシング技術や機械学習技術の習得をしたい、というねらいもあります。
行動認識をする上で業務をカテゴリ化する必要がありました。実験では介護・看護という職種で分割し、「食事介助」「服薬介助」「トイレ介助」など、それぞれ25種類程度の業務に分割しました。介護・看護の業務は重複があるので、全体で31種類の業務が定義されました。行動認識では、その業務のうちどれを実施してたかを機械学習で予測します。
要素技術
全体構成
全体の構成は次のようになりました。
施設の壁などに設置される「環境センサー」と、職員のあたりに装着される「スタッフセンサー」により温度、湿度、加速度などのデータを取得します。取得データは BLE (Bluetooth Low Energy)通信により職員が携帯しているスマートフォンに送られます。センサーデバイスだけでなく、スマートフォンに搭載されているセンサーのデータも付加されます。データは Wi-Fi ルーター経由でサーバーにアップロードされます。サーバーサイドのアプリケーションは、 IDCFクラウド上の OpenShift という PaaS 基盤の上で動作します。そこで認証、データクレンジングが行われ、センサーデータは トレジャーデータサービス by IDCF に格納されます。バッチ処理により機械学習アプリケーションが実行され、その日の職員の行動が予測として出てきます。また、センサーデータとは別に、職員の手入力による行動ログも記録されます。このデータは機械学習の教師データとして利用します。
IoT デバイス
「環境センサー」と「スタッフセンサー」は同じデバイスを使っています。Texas Instruments 社の SimpleLink SensorTag というデバイスです。
CC2650STK SimpleLink SensorTag | TIJ.co.jp
「温湿度センサー」「周辺光センサー」「赤外線温度センサー」「加速度、ジャイロセンサー」「気圧センサー」が搭載されており、 BLE 通信によりスマートフォンなどのデバイスとの連携が可能です。
スマートフォン
デバイスは FREETEL の Priori3 という端末を使いました。この実験ではスマートフォンの役割は2つあります。ひとつはセンサーデータの集計とアップロードで、もうひとつは業務記録の集積です。
センサーデータの取り扱いは、九州工業大学の井上研究室の方々が開発した InuLog というアプリケーションを使います。このアプリケーションは主に以下の5つの機能を持っています。
- スマホ搭載センサーのデータ取得
- 加速度、地磁気、方位、角速度、照度
- センサーデバイス(SensorTag)のID取得
- 設置場所情報として利用
- マルチスレッドによるセンサーデータ取得
- 同時並行で複数のデバイスの複数のセンサー種に接続・データ取得
- 自動ログイン
- 定期的にログイン実行、セッション切れに対応
- バッファ関連機能
- バックグラウンド実行を継続
- 端末再起動後もアプリが起動
- ネットワークが中断しても確実に1回アップロード
業務記録の入力には、サードパーティの aTimeLogger というアプリケーションを利用しました。あらかじめ登録しておいた行動を手動で登録することができます。開始時と終了時に画面をタップすることで、いつ何をしていたかを記録します。入力した行動データはあとから修正可能になっています。クラウド機能もあり、 app.atimelogger.com と自動で同期するようになっています。同期された行動履歴情報はAPIで取得することができます。
サーバーサイド
サーバーサイドアプリケーションの役割は認証、データの加工、機械学習による行動認識です。
まず Ruby on Rails アプリでデータを受け、クライアントの認証を行い、それを次の Node.js アプリに投げます。そこでは簡単なデータの加工やクレンジングを行います。空データをはじいたり、タイムスタンプのフォーマットの表記ゆれを修正したりします。クレンジングされたデータは トレジャーデータサービス by IDCF に保存されます。
aTimeLogger に保存されたデータは、バッチ処理により定期的に PostgreSQL にコピーされます。このデータと トレジャーデータサービス by IDCF に保存されたセンサーデータをもとに機械学習を行います。機械学習のロジックは R で書かれており、 k-最近傍法という手法をコアに実装され、行動のクラスタリングを行います。
IDCF の役割
開発フェーズではサーバーサイドの技術選定と実装、運用・実験フェーズではデータの可視化、分析レポートの作成などを行いました。
- データフローの設計、構築
- 要件･実験フェーズにあわせた技術選定
- コンテナベースのアプリ群を OpenShift 上にデプロイ
- 試行錯誤･探索型の開発プロセスに対応
- BIツールによる 行動データ･センサーデータの可視化
- Re:dash による可視化環境の構築･運用
- 分析レポート作成
- 行動ラベルデータと職員属性を比較した分析レポートの作成
行動ラベル分析
実証実験の主なねらいは行動認識による自動予測です。しかし、せっかく手入力の業務記録を集積したのに、機械学習に使うだけではもったいないですよね。このデータを使って業務分析をやってみました。
作業時間の分布
まずは各作業の完了時間でヒストグラム化してみました。10分以内で終わる作業が一番多いことがわかりますね。これだけでも、介護業務が細切れのタスクがたくさんある、ということがわかります。
作業項目ごとの平均作業時間とトータルの実施回数
縦軸を平均作業時間、横軸を総実施回数としてマッピングしてみました。「トイレ介助」は1回あたりの作業時間は長くないが頻度は最も高い、など各作業の特性がわかりますね。
1回あたりの作業時間と職員属性の関係
経験の長さと作業時間にはなにか関係があるのでは？と思い、縦軸を1回あたりの作業時間(中央値)、横軸を経験(年)として各職員をプロットしました。また、職員の持っている資格によってグループ分けしてあります。プロットされた各点の数字はデータ上の識別番号で、意味はありません。
これを見る限りでは、経験年数や資格で1回あたりの作業時間に差がある、ということはなさそうです。これは、各業務が標準化されて職員の経験によって差がでにくいようになっていると言えるのかもしれません。
中央値や平均値では差はありませんでしたが、もっとよく調べてみると作業時間の「ばらつき」には資格の有無で差がありそう、ということがわかってきました。より高度な資格を持っている職員ほどばらつきが多いようです。つまり、短時間で終わる作業は全職員が行うが、高度な資格を持っている職員は比較的長時間の作業をする必要がある、ということでしょう。このあたりは、さらに踏み込んだ調査が必要になりそうです。
機械学習による行動認識
さて、機械学習による行動認識の精度はいかほどだったでしょうか。
通常、行動認識を行う場合は「その瞬間何をしていたか」あるいは時間を一定のセグメントに区切って「各セグメントで何をしていたか」を認識するシンプルなクラスタリングを行います。しかし、今回は「開始・終了時刻の予測」と「その期間何をしていたか」を同時に予測します。また、介護業務では並行作業もあるため、さらに複雑になります。
精度評価は、「開始時刻の予測精度」と「継続時間の予測精度」別々で行います。時刻や時間の精度を秒単位で行うのは大変むずかしいので、ある程度マージンを持たせて、精度評価を行っています。また、さらに作業項目ごとにわけて評価を行っています。
まずは「開始時刻の予測精度」です。
マージンは3時間としています。つまり、誤差が3時間以内なら認識成功としています。「朝礼」や「休憩」などの精度の高い項目を除き、あまり高い精度で予測できていないことがわかります。
次に「継続時間の予測精度」です。
継続時間予測では、10分の誤差を認識成功として評価しています。開始時刻予測に比べれば高い精度が出ていることがわかります。
まとめと課題
介護現場での IoT と機械学習による行動認識実証実験についてお伝えしました。センサータグとスマートフォンによりデータを収集し、機械学習による行動認識を試みました。一方でラベルデータとして収集した行動ログを分析し、職員の方々の作業傾向の可視化を行いました。
センサータグについては、故障や電池切れによる現地作業が頻繁に発生し、データの安定収集に課題があることがわかりました。スマートフォンでの作業実績の記録については、職員の方々のリテラシーに課題が見られました。普段スマートフォンを使っていない方が多くいらっしゃったようで、入力に苦戦していたようでした。
行動ログの分析については、誰がどんな作業をしているか、感覚に頼って予測していたものを定量的に可視化することができました。それにより、作業負荷が高いフロアや時間帯にパート職員の方を配置する、定時作業を比較的作業の少ない時間帯にずらす、などの対応策が可能となりました。職員のみなさんの業務を定量的に見える化することで、介護業務の効率化と品質向上に貢献することが原理的には可能であることを示すことができたと思っています。
一方で、機械学習による行動認識の精度には課題があります。継続時間予測はそれなりの精度が出ていますが、開始時刻の予測に難があります。この精度では予測結果をそのまま業務記録として使うことは難しいでしょう。精度向上のためには、アルゴリズムの見直しだけでなく、センサーデバイス側の改善も必要です。例えば、今回は職員の位置情報の予測には環境センサーのデバイスIDを使っていましたが、ビーコンを使ってより正確な位置の把握をすべきでしょう。また、センサーデバイスを増やすことで精度向上につながると考えられます。高い精度の行動認識システムを構築できれば、職員のみなさんが手入力することなく行動ログの集積と分析を行うことができます。きっと業務の効率化と品質向上につながることでしょう。
今回の実証実験の内容は、プレスリリースでも公開しており、日経新聞さんにも取り上げていただいています。また、「介護施設における介護スタッフの行動センシング実験」というタイトルで研究会発表、論文執筆も行っています。詳細が気になる方は、ぜひそちらもご確認ください。
- プレスリリース: ウチヤマホールディングス、九州工業大学、IDCフロンティア、介護施設従事者のIoTによる行動認識実証実験を実施
- 介護現場センサーで分析 ウチヤマＨＤなど 効率化、書類記録カギ ：日本経済新聞
- 介護施設における介護スタッフの行動センシング実験 - 情報処理学会 電子図書館
普段は IDCF クラウド関連の記事が多いこのテックブログですが、今回は一味違った内容をお届けできたと思っています。 IDCF といえばクラウドやデータセンターなど、 IT インフラのイメージが強い方もいらっしゃるかもしれませんが、 IoT やビッグデータ、機械学習などのキーワードを中心に新規ビジネスの開拓も常に行っています。もし、この分野で活躍したいエンジニアがいらっしゃいましたら、ぜひ採用ページからご応募ください！ OSS を中心とした最新技術の調査・検証を行いながら、新たなビジネスを創るチャレンジングな職場です。インフラ、ミドルウェア、サーバーサイドアプリケーション、 Web フロントエンド、機械学習・分析、どのレイヤーのエンジニアでも強みを活かして貢献することができます！
