25年8/2-3にかけて行われた，「全国学生対抗 Qiita × FastDOCTOR Health Tech Hackathon」の参加レポートです．

どんなハッカソン？？

本ハッカソンは、日本最大級のエンジニアコミュニティ「Qiita（キータ）」と，テクノロジーによって医療の質・体験・生産性を変革し，持続可能な地域医療を実現する医療プラットフォームを運営するファストドクター社が共同で開催されたハッカソン．参加者は，8月2日（土）・3日（日）の2日間に渡り，「オンライン診療×AIで、未来の医療を共創しよう！」をテーマに，生成AIを活用してオンライン診療に関する新しいウェブサービス，モバイルアプリのプロトタイプの企画・開発を行うというもの．

イベントの概要としてはこんな感じ．

なんで参加したの?って話

自分は研究室のイベントでB3の頃からちょいちょいハッカソンに参加していました．

23/8 : HACK U Nagoya
24/3 : HACK U Osaka
24/9 : 愛知県大学対抗ハッカソン(Hack Aichi+2024)
数えてみたら今回で4回目らしいです．3回目のHack Aichi+2024では企業賞と審査員賞をいただき，ハッカソン楽しいなーと感じていたし，ぼんやりと得意意識もあった．Hack Aichi今年もやるなら最上位の賞である愛知県知事賞を狙いたいな…

話が逸れましたが，一つ目の理由としてはそもそもハッカソンが好きという経緯があります．もう一つの理由としては，医用画像とAIに関する研究に取り組んでおり，このハッカソンとの親和性が高いと感じたから．情報工学を専門に勉強している人に限れば，多少は知識面なども自信があるといった経緯がありました．

メンバー

開発が得意で今回のハッカソンを見つけ，誘ってくれた友人

パワポ作りとアイデア出しが上手で議論のファシリテーターになれる友人

私

M1が2人と，自分より1個年上なのになぜかB3の3人．各々，得意分野があってきちんと作業できるメンバー．また，3人ってのも良かった．(多すぎてもタスク振りずらいので)

ちなみにチーム名は「import 好き好きクラブ」です．某スクールアイドルクラブのファンネームが由来だとかそうじゃないとか…
また，importはPythonのimport文から取っています．しかし，結局開発にはPython使わなかったというギャグ．

なんか見えます?気のせいですよ😊

解決したかった課題と解決方法，方針

1日目の午前中にインプットセミナーとして現在抱えている日本の医療が抱えている問題点等の紹介があった．いくつか候補として上がっていたが，我々は「医師のリソース不足解決」をテーマとして選定した．少子高齢化により，労働人口が減少し，社会福祉が必要となる人口が圧倒的に増えている現在の日本では医師のリソースが不足するのは必然で，それを解決しようというもの．

では，これをどのように解決する…?って話なわけですよ．何か思いつきますかね．

我々は，「(病院に行くか，行かないか微妙な場面において)患者が病院へ行く回数が多い」のでは？というところに着目しました．(現在，軽症でも救急車を呼んでしまい，それが医療リソースを圧迫しているというのは有名な話だと思いますが，それの超軽症版だと思ってもらえるとイメージしやすいかと思います．)->病院に行くか，行かないか微妙な場面において病院に行くべきかどうかを患者の情報(カメラの様子，スマートウォッチなどのセンサ類，既往歴)から総合的に判断するかかりつけAI的なものを開発しようと考えました．

(もちろん，既往歴などによっては微妙な症状でもすぐ病院に行くべき人もいるはずなので，上で既往歴についても触れています．)

作業の流れなど

day1
当然，上に書いた方針がポンと湧いてくるわけではないので，まずはアイデア出しと課題の深掘りを．アイデア出しにはMiroを使用．Miroって個人的にはすごい使いにくい印象だったけど，全員集まって共同で何かするときにはすごく良いツールだと感じた．(全員で編集できるし)

メンターの方とも相談し，少しずつどんなものを作るか決める．途中で迷走したりしたが，夕方にはきちんと作るものを決めた．迷走したら図を書いて，要点を整理するといいね．他のチームの様子はすでに開発に着手しているところがほとんどだったようだが，ハッカソンはアイデア出しというか，実装よりも設定した課題に対して正しくアプローチできているかが重要なので，ここには十分時間を割いて良いと考えた．この選択は今でも後悔していないし，失敗とも思っていない．

夕方になり，当初の会場の使用制限時間だった18時には会場を出た．結局，ファストドクター様のご厚意で20時まで会場は使えたそう.

宿着で即開発開始．各々役割分担をして作業開始．自分は後述するカメラ機能の実装を行うべく，Githubのレポジトリを探し回ったり，Teachable Machineというツールの学習を行った．

day2
カメラ機能の実装と，アプリとの統合を行い，デバッグ．発表の準備に自分は関与していない．できるだけ，早く開発できると発表準備の人が楽なのだが，結構ギリギリまで作業してしまった．

作品->かかりつけAI

このかかりつけAIは以下の2つのペインを解決することを想定．

信頼性，気軽さを兼ね備えた情報源がない->かなり軽い症状，微妙な症状でも病院に行ってしまうことが多くなる

(だから)地方やへき地の医師の負担が増えてしまう

(1. は患者側，2.は医師側のペイン)

以下のような手順で動作，機能する．

1.カメラで常に使用者の様子をモニタリング->表情の変化や，動きをあまり検知しなくなると(寝ている時間が多いなど)，AIによる診断を提案する．このAIによる診断はカメラでのトリガー以外にも任意のタイミングで実行可能．(スマートウォッチのデータも使いたかったが，実装時間の関係で今回はカメラによる認識のみ)

人が検出されると「体調○」や「体調△」などと表示される体調△が一定時間，複数回表示されると診断提案が始まる

2.あらかじめ登録しておいた，情報やAIによる問診などからレポートを作成．問診と，レポートの生成にはOpenAI(GPT-4o)のAPIを使用．本当は問診にはGPT-4oの会話モードを使用したかったが，実装時間の関係で断念．そしてレポート生成のエビデンス，情報の参照元としてOpenEvidenceという別のAIを使用した．

OpenEvidenceは，自然言語で質問すると，JAMAやNEJMなど信頼性の高い文献や最新ガイドラインから数秒で根拠を提示するAI医療情報プラットフォームで，米国では医師の約4割が日常的に利用し，臨床判断を迅速に支援しているといったもの．

医療系に特化したAIサービスを使用することで，信頼性の高い情報を引用することが可能で，ハルシネーションを起こす確率も下げられるということで採用．これによってペイン1が解決される．

↑事前に既往歴などを登録しておける

↑このように既往歴とAI問診によって一般向けと医師向けのレポートが生成される

医師向けのレポートには，詳しい参考文献(論文)なども併せて掲載したレポートが生成され，患者が受診を決めた際にこのレポートが医師に送信されることを想定．(あらかじめ，既往や症状，AIの判断根拠等などがレポートに記載されているため診察時間の短縮にもつながる->ペイン2にも貢献)

発表(主に反省点)

発表練習ができなかった->スライドの説明にかかる時間を把握できなかった．これはギリギリまで開発に時間を割いてしまったことが原因．
発表中でのPCの変更->自分のPCのカメラで学習したため，発表で使うPCとカメラ性能に差が出てしまい，表情の変化を捉えられなくなった．
上記問題に対して，デモを行うときのみ自分のPCに接続して発表を行うことで対処しようとしたが，スライドの説明で思ったより時間が押してしまったこと，繋ぎ変えたことで時間をロスしてしまい，デモを見せることができなかった．

発表もデモも自分のPCで行えばよかったのだが，自分だけMacだったので，発表する人が使いにくいという理由で繋ぎかえるという方針に．WindowsのPCでもきちんと学習させるべきだったか…難しい，短期間の開発でそこまで意識が回らなかった.

まとめ，感想

愛知から参加した甲斐のある楽しいハッカソンでした．それだけに結果が悔しいので，別のハッカソンにまた参加したい．

運営していただいた，スタッフの皆さんありがとうございました！