はじめに
ヘンリーでレセコンの開発をしているバックエンドエンジニアの横山です。これはHenryアドベントカレンダー 2025 シリーズ 1における18日目の投稿です。この記事では、ヘンリーのエンジニアリングの面白さと、巨大で複雑な医療ドメインに対するAI活用についてお伝えします。
モダンなSaaSと、私たちが挑む領域の違い
昨今の「モダンなSaaS」と呼ばれるプロダクトには共通点があります。洗練されたUI/UX、最新の技術スタック、クラウドネイティブなアーキテクチャ。しかし、これらのプロダクトの多くは扱う業務領域が比較的絞られていると思います。限定された領域で高いクオリティを実現し、幅広い市場に届け、大量のトランザクションを効率的に処理する。これがモダンなSaaSの勝ちパターンの一つだと思います。
一方、私たちが取り組む電子カルテ・レセコンの領域は性質が異なります。
医療システムは、大手企業が数十年の歴史をかけて作り上げてきた巨大なシステム領域です。SIerが手掛けてきた基幹システムに近く、ドメインが巨大であることに加え、医療機関ごとに異なるカスタマイズも求められるため、多くの人手と工数を必要とする領域です。国が定める医療制度のきめ細かいルールを大量に実装する必要があり、地方自治体ごとの差分、医療機関ごとの運用差分にも対応しなければなりません。それでいて、現代のユーザーはモダンなSaaSと同等のUI/UXを期待します。
この領域を、モダンなSaaSのやり方で作る。それが私たちの挑戦です。では、実際にどんな難しさがあるのでしょうか。
多様で優先度の高い要求が押し寄せる
日々の開発では、多様な要求が同時に押し寄せます。
- 障害対応（計算不一致、レセプト出力の問題、潜在的なバグ）
- 新しい医療機関や新しい県への導入で発覚するルール対応
- 主要機能の開発
- 運用はできているが不便だとわかっている改善
- 連携企業とのインターフェース不備など突発的なタスク
- 他機能の開発・修正から影響を受ける依存タスク（ドメインとして必要な情報が連続的に流れてくるため、機能間の依存が生まれます）
- チームの生産性向上活動（ドキュメント整備、勉強会など）
スクラム・アジャイルで開発を進めていますが、正直なところ、教科書通りのやり方だけではスピードが追いつきません。これまで実現されてこなかった領域には相応の理由があります。
戦略的にエンジニアリングする面白さ
本や流行のフレームワーク、プロセスを取り入れて遂行することはもちろん大切です。しかし、それを実行しても事業が大きく前進していなければ、勝てているとは言えません。
私たちには、日々の開発で積み上げてきた経験と、現場で得た膨大な情報があります。それらをもとに現在の状況を深く考察すれば、教科書通りの方法よりもさらに踏み込んだ工夫ができるはずです。
「今この瞬間、何をすれば最も事業が前進するか」——その戦略を常に考えながら、日々のタスクを捌いていく。どの問題から解くべきか、どう解くのが最善か。優先順位と解き方の両方を考え続けることが求められます。これがヘンリーのエンジニアリングの面白さだと思っています。巨大で複雑な領域だからこそ、とても挑戦的で、やりがいのある環境です。
AIで解決されてきた開発のボトルネック
そうした中で最近、LLMが開発現場で実践的に使える道具になってきたように感じています。使っていて感じる感覚的な部分も多いですが、実際にどういう局面で役立っているか紹介してみます。
いままで苦労していた工程のそれぞれに効いていて助かっています。
課題: 影響範囲の把握が難しい
電子カルテ、オーダー、レセコン——これらは長いスパンで連携し続けるデータを扱います。共通で保持する情報も多く、一箇所の変更が思わぬところに影響することがあります。影響範囲を見落とせばバグになり、過去には大きな障害につながったこともありました。
AIを使うことで、関連コードや修正箇所を探索できるようになりました。一つの指示で複数ファイルを横断的に検索し、関連がありそうな箇所を探し出してくれるように思います。
初手の調査にかかる工数は大幅に減り、事前の影響範囲調査が格段に早く、正確になると思います。
実際に、大規模な範囲に影響する開発で試せていないので、どこまで広範囲に見てくれるか、漏れはどの程度かの検証はできていない状況ではありますが、「あの機能を修正するのを完全に忘れてた」というような事態は減らせそうな感覚があります。
初手でざっくり全体像をぱっと提示してもらえることで、関連機能を思い出すこともあったりする。
例えば、以下のようなざっくりしたキーワードでも該当するusecaseやテーブルを洗い出してくれます
消費税に関する処理を行っている場所を教えて、net_xxxのカラムを処理している場所をおしえて
課題: 調査・修正箇所の特定
なにかバグが発生し、その周辺機能に詳しくなかったとき、そのドメインはどういったものなのか、どこに実装されているのか、現状どういう処理仕様なのかといったことを理解する必要があります。
理解した上で、どの程度改修工数がかかるのか、発生頻度と修正工数を見て対応方針を決める。このようなステップがあると、初期調査から腰が重くなりがちで、チケットが滞留しやすくなってしまったりします。
このようなことは機能数が多く、覚えるべきドメインが多いほど起こりやすいことなので、ヘンリーでは課題の一つになります。
例えば、特記事項の編集に関するバグがあり、特記事項について何も知らないとしましょう。
LLMに「レセプトの特記事項を扱っている場所おしえて」と質問すると上記の不明点の大半が解決されます。
最近は、自然言語でコミュニケーションできるようになってきたと思います。
以下のように実装されているものが出てきました。(ファイル名は誤魔化しています)
レセプト特記事項の主要な場所：
■ 定義
XxxEnums.kt - enum
■ UseCase・ビジネスロジック
XxxUseCase.kt - 特記事項の取得・登録・削除
XxxService.kt - 処方箋の特記事項
■ レセプト出力
XxxOutput.kt - UKEファイルへの出力
XxxConverter.kt - 特記事項変換
XxxContext.kt - 患者レセプトコンテキスト
■ データ取得
XxxFetcher.kt
YyyFetcher.kt
■ DB
XxxTable.kt
YyyTable.kt
ここから先は、usecaseどのような仕様で処理しているかなどを聞けば、処理仕様がわかります。
ものによっては、バグチケットの内容をそのまま聞くだけでどこを修正すればいいか教えてくれることもあると思います。
課題： 過去の負債を読み解く必要がある
スタートアップの初期に書かれたコードには、スピードを優先した結果として負債が残っています。当時の文脈を知らないと読み解くのが困難なコードも少なくありません。
以前は、ドメインに詳しいか、過去のコードや背景に詳しいか、どちらかがないと正確に把握できませんでした。新しく入ったメンバーにとって、ここが最も時間のかかる部分でした。特に、未知のドメインと複雑な既存コードの組み合わせは、最も生産性を低下させる要因でした。
しかし今は、複雑なコードをAIに読ませて、気になる部分を一つひとつ解説してもらうことができます。コードの動きを自然言語で理解できますし、解説の粒度や抽象度もこちらの指示でコントロールできます。エンドポイントから該当クラスまでのシーケンスや、主要なクラスの関係なども引き出せるようになりました。また、既存のコードからドメインの概要や仕様を抽出できるため、コードを読み始める前に大枠を理解することもできます。
課題： 触ったコードを綺麗にして去る
機能を修正する際、そこを触ったならば、ただ直すだけでなく、ドメインの再整理やリファクタリング、命名・コメントの整理も行い、次に触る人の開発生産性が上がるように見直す——という活動を心がけています。
AIはこの活動を大きく加速してくれます。
「メソッドをprivateに分割して」「サービスクラスに切り出して」といったリファクタリングは、大まかな指示でも高精度かつ高速に実行できるようになりました。
命名についても「このニュアンスで変更して」と指示すれば、具体的な案を自分で考え切らなくても、提示された候補から選ぶだけで解決できることが多いです。コメントも同様で、「70歳以上は限度額認定証が無くても高額療養費が発生する点も書いて」のように要点を伝えるだけで、いい感じの文章に仕上げてくれます。伝えたい内容が多い場合は、音声入力で伝えることで解決できる場合もあります。
負債を解消する前に、既存メソッドのテストを書き出してもらい、動作を担保してから書き換える——といったことも高速にできるようになりました。「このメソッドのテスト書いて」と指示するだけで大枠が完成します。こちらとしては、レビューに注意を払えば良いだけです。
課題： 医療制度のドメイン知識そのものの習得
医療制度に関する基礎的な知識は、近年のLLMがある程度理解できるようになっています。基礎的な概要をAIに聞いて理解した上で、個別の詳細をドメインエキスパートに確認する、というステップを踏みやすくなりました。
以前は、そもそもどこに何の資料が公開されているかもわかりにくく、抽象的な体系から具体的なルールへと段階的に理解を深めることが難しい状況でした。最初に目に入るのは個別の具体的なルールであり、体系的な説明資料は十分に揃っていませんでした。
chatGPTに「レセプト特記事項についておしえて」と聞いた場合、いまではなかなか高精度の回答が返ってきます。
概要、何のために書くか、事例をいくつか
正確な情報は別途確認が必要なものの、ざっくり理解するには充分なことが多いです。
よく使われるレセプト特記事項の代表例
① 高額療養費・限度額関係
限度額認定証の提示があった／なかった
月途中で保険変更があった
世帯合算を行った
例：
「限度額認定証（区分ウ）提示あり」
「月途中資格取得のため自己負担額調整あり」
課題： ドメイン知識のチーム共有
スタートアップでは、ドキュメントを書くにも機能開発と同じくらいの価値を出す必要があり、どうしても優先度が下がりがちでした。しかし今は、コードベースに対してLLMに質問を投げることでドメインの情報を引き出せるようになっています。詳細な仕様はコードへの質問で一定吸い上げられると感じています。とはいえ、新しいメンバーはなにをどういう順で調べていけばよいかがわかりません。そのため、ドメインのインデックスとなるものをまず用意して、個別の詳細はLLMに聞きながらレビューし、少しずつ訂正して埋めていく形を考えています。
やりたいことだけ伝えて、プロンプトを作ってもらいました。そのプロンプトをもとに、コードベースから情報を整理してもらい、インデックスとなるものを引き出します。
## 目的
コスト登録・編集から、負担額計算、請求確定までのコードを分析し、
主要なドメイン処理を「概念レベル」で整理したい。
粒度の例:
コスト取得→包括処理→点数計算→負担額計算
新しく入った人が、
- 実装詳細を読まずに
- まず全体像と考え方を掴める
ことを最優先にします。
以下のようなステップがわかる図も作ってくれますし、それぞれのステップでなにをしているかも書いてくれました。各ステップ内で登場する主要なドメイン概念についても書き出してもらいました。こういったものを手軽に作れるようになっていて助かっています。
graph TB
A[1.データ入力] --> B[2.検証・訂正]
B --> C[3.確定トリガー]
C --> D[4.前処理]
D --> E[5.計算処理A]
E --> F[6.計算処理B]
F --> G[7.出力生成]
2. 主要ドメイン概念
算定単位（CalculationUnit）
診療報酬請求の最小単位
診療行為・医薬品・特定器材をひとまとめにしたもの
レセプト（診療報酬明細書）の1行に対応
シンプルに生産性が上がった部分
AIツールの進化によってシンプルに生産性が上がっている部分もあります。
最近のLLMモデルは、細かく指定しなくても意図を汲み取ってくれるように思います。
機能追加や修正においては、「〇〇の機能について、△△版を作りたい」程度の大まかな指示でも、おおよそのベースを作ってくれますし、コードベースを理解しているので自然言語(ドメイン用語)で話が通じます。
LLMのレスポンスが早くなったことでインタラクティブに開発できるようになり、日々の機能改善が加速しています。
おわりに
医療という巨大で複雑なドメインに、モダンなSaaSのやり方で挑む。簡単ではありませんが、だからこそ面白い領域だと思っています。
LLMの進化によって、これまでボトルネックだった部分が軽減されつつあります。この追い風を活かして、ガンガン機能を作っていきたいと思っています。
複雑で膨大なドメイン知識をどう扱うかは、引き続き大きな課題です。LLMを活用しながら、ドメインの体系やキーワードを整理し、チーム内での理解を早める仕組みを作っていきたいと考えています。
※筆者はcursorを主として利用しています