医療現場の効率化を、自分でつくる側に——理学療法士のAI開発のはじまり

プロフィール

• 氏名：佐倉 さら（さくら さら）
• 屋号：理学療法士×AI開発
• 職種：理学療法士として総合病院に勤務
• 保有資格：理学療法士
• 現在の活動：リハビリテーション科の急性期病棟勤務
• AI活用歴：約3か月（2026年5月〜）
• 使っているツール：Claude Code、Cursor（どちらも、日本語で指示するとコードを書いてくれる開発ツール）、ChatGPT、Gemini

AIに触れる前は、何を考えていましたか？

リハビリ職への、漠然とした不安が常にありました。

今後の自分のあり方を考えたときに、その不安が出てきます。何か具体的な出来事があったわけではありません。ただ、この先どうなるのかが見えない感覚が、ずっとありました。

もうひとつ考えていたのが、医療現場での業務効率化ができないかということです。現場にいると、ここは変えられるのではないかと思う場面があります。ただ、思うだけで止まっていました。

AIに触れたきっかけは何ですか？

メンターとの出会いです。

クラウドソーシングのサイトで出会った方でした。AIの勉強をしようとして探したわけではありません。仕事を探す場で、たまたまつながった形です。

その方から、AI活用エンジニアという手段があると知りました。それまで自分の選択肢の中に無かったものです。理学療法士として働いている自分と、AIで何かを作るということが、頭の中でつながっていませんでした。

※ AI活用エンジニア：AIを前提の開発環境として使いこなし、設計・実装・テストまで高速に進めるエンジニア。

手段があると知ったことが、いちばん大きかったと思います。

最初に作ったものは何ですか？

電卓でした。

本当に、ただの電卓です。数字を入れて、足したり引いたりできるだけのものです。

なんでもできるじゃん！

そう思ったのを、はっきり覚えています。感動しました。作ったものが小さいかどうかは、あのときは関係ありませんでした。自分が指示を出して、動くものが目の前に出てきた、ということが大きかったです。

短期間で、何が変わりましたか？

ものの考え方です。

いちばん変わったのは、「これ以上は無理だろう」と思っていたものが、できるようになったことです。以前は、そこに線を引いて止まっていました。その線が動きました。

見え方も変わりました。今まで目につかなかったものから、アイディアをもらえるようになりました。同じ景色を見ているはずなのに、拾えるものが増えた感覚です。病棟での仕事も、以前とは違う目で見ています。

線が動いたあとに手をつけたのが、勤務表の作成と、その日の患者さんの割り振りです。どちらも自分が毎日見ている業務で、以前は「これは人がやるものだ」と思っていた部分でした。いまはどちらも実装段階まで来ています。

この3か月で変わったのは、作れる量よりも先に、何を作れると思えるかの範囲だったと思います。

うまくいかなかったのは、どんなときですか？

プロンプトへの、詳細なイメージの伝え方です。

頭の中にはイメージがあります。それをAIに伝わる言葉にするところが、うまくいきませんでした。細かいところまで伝えきれていないと、出てくるものが自分の思っていたものとずれます。

ずれた原因はAIではなく、自分の伝え方でした。何をどうしたいのかを、自分でも細かく決めきれていなかったのだと思います。

AIを使っても、難しかったのはどこですか？

難しかったのは、コードを書くところではなかった

先にお伝えすると、コードを書く部分では苦労していません。そこはAIがやってくれます。

大変だったのは、その手前と、作ったあとにありました。

病棟のルールを、ひたすら伝えた

勤務表にも割り振りにも、病棟のルールがあります。それをひたすらClaudeに伝えました。

自分が普段どういう順番で考えて、何を見て決めているのか。手を動かしているときは意識していない部分を、そのつど言葉にしていくことになります。

他のスタッフが困惑しないように

作るときに気をつけたのが、他のスタッフが困惑しないようにすることです。

新しいものを覚えてもらう形にはせず、これまで通りの形式でできるようにしました。使う側から見て今までと変わらないことを、先に決めていました。

いま向き合っているのは、他のPCで動くかどうか

勤務表と割り振りは、まだ実装段階です。

自分の手元で動くだけでは、業務では使えません。病棟の他のPCでも稼働できるようにする必要があります。実際に他のPCで動かして実装できるかどうか、いまはそこに向き合っています。

ご自身には、どんな変化がありましたか？

変わりました。

一職員として働いていたところから、AIが使えるという視点で物事を考えて、発言できるようになりました。同じ職場にいて、同じ業務を見ているのに、話せることが変わりました。

上司と話していたときに、こんな話が出ました。医療系のAIを導入するには150万円かかる。それがネックで、導入できていなかったのだそうです。

それができるようになったら助かる。

その一言が、いま自分のやっていることの位置を教えてくれた気がしています。

次に作りたいものは何ですか？

医療現場で活かされるシステムを作りたいと思っています。

• いま実装しているもの：勤務表の作成と、その日の患者さんの割り振り。他のPCでも動くようにするところ
• 次にやりたいこと：電子カルテとの連動。ここがつながれば、多職種での共有に手が届きます
• その先：患者さんの退院後の支援。もっと高度なものになりますが、ここまで繋げていきたいと思っています

勤務表や割り振りは、病棟の中で完結する話です。多職種の共有や退院後の支援になると、扱う情報も関わる人も増えます。そこまで行きたいというのが、いまの目標です。

これから始める人には、何を伝えたいですか？

他人と過去は変えられない、自分と未来は変えられる。

座右の銘です。

AIに触れる前に感じていた不安は、いま思えば変えられない側を見ていたのだと思います。この職種の先がどうなるのか、環境がどう変わっていくのか。自分では決められないことばかりでした。

でも、自分が何をできるようになるかは決められます。電卓が動いたあの日に変わったのは、たぶんそこを見る向きでした。

これから始める人にも、変えられる側に手を動かしてみてほしいです。私は3か月前まで、自分がシステムを作るとは思っていませんでした。

Shift Forward's View

ここからは、取材した私たち Shift Forward の見方です。

改善点を見つける役が、現場の側に移っている

この3か月で最も大きく変わったのは、成果物ではなくものの見方だと考えています。佐倉さんは「今まで目につかなかったものから、アイディアをもらえるようになった」と話しました。同じ病棟に立って、同じ業務を見て、拾えるものが増えたということです。

これまで、業務のどこを変えられるかを見つけるのは、外から入るコンサルタントや、システム部門のSEの役割でした。業務を聞き取り、整理し、ここが改善できると示す。専門の知見が要る仕事です。それが現場の人の側から出てくるようになりました。

電卓の次に手をつけたのが勤務表と患者さんの割り振りだった、という順番がそれを表しています。リハビリテーション科の改善を外部の開発者が頼まれたとして、最初にそこへは行きません。組織図や業務フローを見て、記録や集計といった分かりやすいところから入るはずです。急性期病棟で毎日その割り振りを見ている人でなければ、そこが一手目だと分からないのです。

上司の「150万円がネックで導入できていない」という話に、一職員として答えられる位置に立ったことも同じです。私たちが Forward Deployed Engineer（FDE）と呼んでいる役割の、最初の一歩がここにあります。

いちばん難しい部分に、現場の人が触れている

もうひとつ重要なのは、佐倉さんが設計の難しさに正面からぶつかっていることです。難しかったのはコードを書くところではなく、病棟のルールをひたすら伝えるところ、頭の中のイメージを言葉にするところだった、と話しています。

これは、エンジニアの仕事の中でも最も重い部分です。自分が何を見て、どういう順番で考えて決めているのか。手を動かしているときは意識していないものを言葉にして、扱える形に整える。業務を言語化し、抽象化する作業そのものです。コードはAIが書くようになりましたが、この部分は残ります。

そして、ここはAIが最も苦手とするところでもあります。病棟の暗黙のルールも、そのとき何を優先するかも、外からは取り出せません。裏を返せば、現場の人が自分の判断を言葉にできるようになったとき、いちばん強い組み合わせになります。「ずれた原因はAIではなく、自分の伝え方だった」と言えている時点で、佐倉さんはその入り口に立っています。

いま判断できているのは、画面が動くかどうかまで

一方で、ここから先に足りないものもはっきりしています。現時点で確かめられているのは、目に見えて動く部分だけです。

先に何を作るかを決めてからAIに渡す進め方は、正しい方向です。ただ、決めた通りに中身が組まれているかどうかは、詳細設計の知見がないと確認できません。勤務表や割り振りのようにルールが絡む処理は、めったに起きない条件で崩れます。しかも画面の上では動いて見えます。壊れていれば気づけますが、動いてしまうと気づけません。

ここを埋めるのが、テスト設計とテスト観点です。どんな条件を通せば壊れるのかを先に洗い出す考え方で、これを身につけると、動くものが本番で使えるものに変わります。もうひとつは、隣にエンジニアがいて助言する形です。他のPCで動かす段、そして電子カルテにつながる段では、扱うのが患者さんの情報そのものになります。病棟の中でずれれば作り直せる。患者さんの情報でずれると、戻せません。

私たちがやること

佐倉さんに足りないのは、作る力ではありません。確かめる力と、その型です。何をテストするか、本番で使う前に何を見るか、何を入れてよくて何は駄目か、誰が確認して誰が通すのか。私たちがやることは、これを一緒に決めて、個人の注意力ではなく組織の型として残すところまでです。基準づくりの考え方はAIに社内データを読ませる前に企業が設計すべきことでも、一部扱っています。

現場を深く知っていて、自分で動くものを作れて、危ないところが分かっている。医療でも製造でも、その職場にこの役割を担う人が現れたら、そこがその組織のAI活用の起点になります。そういう人は、たいていもう社内にいます。その手を止めずに、安全に速く走れるようにするのが私たちの仕事です。自社の現場で動き始めた人をどう伸ばすか、まだ誰も動いていないところをどう始めるか。どちらの段階からでもご相談ください。