https://kakehashi-dev.hatenablog.com/entry/2025/12/23/150000

はじめに

こんにちは。PE新規サービス開発チームでソフトウェアエンジニアをしている荻野です。

こちらの記事はカケハシ Advent Calendar 2025 の 22日目の記事です。

私が所属するチームでは、新規事業のために社内のさまざまなプロダクトやデータを連携させる取り組みを行っています。その様子については以下の記事をご覧ください。

kakehashi-dev.hatenablog.com

例えば、調剤薬局向け次世代型の業務支援サービス『Musubi』と患者フォローアプリ『Pocket Musubi』を連携させたり、既存プロダクトに蓄積された医療コンテンツを別のサービスで活用したりと、複数のプロダクトを横断してプロジェクトが進むことも多くあります。

テストデータ作成の悩み

このように複数のプロダクトを横断して開発を行う際、悩ましいのがテストデータの準備です。

カケハシのプロダクトの多くは医薬品を扱っていますが、各プロダクトで医薬品のDBの持ち方は異なっており、処方箋のデータなども微妙に違う形式で格納されていたりします。そのため、2つのプロダクト間でデータを連携させる場合、それぞれのプロダクトに合わせた形式のテストデータを用意しなければなりません。

また、新規事業ならではの悩みもあります。社内で新しいアイデアの可能性を検討する際、サンプルとして「お薬1」「お薬2」といった架空の名前のデータを使っていては、なかなかイメージが湧きにくいものです。さらに、テストの際にも、表示されている内容が正しいのかどうか判断しづらいこともあります。そのため、できるだけ実際の医薬品に近いリアルなデータを使いたいというニーズがありました。

カケハシにはドメインエキスパートとして薬剤師をはじめとする医療の専門家が多数在籍していますが、開発で必要になるたびにデータ作成を依頼していてはお互いとても大変です。また、専門家がテストコードやfixtureを直接書けるわけではなく、サンプルをもらってもどのみちそれをコードに変換する手間はかかります。

AIにテストデータを作ってもらおう！

しかし、今は2025年。AIが飛躍的に発展し、もはや去年の今頃とは環境が全く違います。こんな課題に人間が悩んでいる場合ではありません。そうです、処方箋のfixtureなど、生成AIにサクサク作ってもらえばいいのです！やってみましょう。

まずは処方箋データの構造について簡単にご紹介します。あるプロダクトでは、処方箋データは以下のような構造になっています（大幅に簡略化しています）。

┌─────────────────────────┐       ┌─────────────────────────┐
│ Medicine                │       │ Prescription            │
├─────────────────────────┤       ├─────────────────────────┤
│ code : 医薬品コード     │       │ patient_id : 患者ID     │
│ name : 医薬品名         │       │ prescription_date : 処方日│
└───────────┬─────────────┘       │ clinic_name : 医療機関名│
            │                     │ doctor_name : 医師名    │
            │                     └───────────┬─────────────┘
            │                                 │
            │      ┌──────────────────────────┘
            │      │
            ▼      ▼
┌─────────────────────────────────┐
│ PrescriptionItem                │
├─────────────────────────────────┤
│ prescription_id (FK) : 処方箋ID │
│ medicine_code (FK) : 医薬品コード│
│ usage : 用法                    │
│ ...（省略）                     │
└─────────────────────────────────┘

これまではこういったテストコードを手で書いていました。生成AIが使えるようになってからも、自動生成されるfixtureにはdummyのデータを入れることなどが多かったと思います。

ということでAIにもっとそれっぽいデータを作ってもらうのを実際に試してみましょう。今回はClaude Codeを使用してみます。カケハシでは様々なAIツールを使うことができますが、私が普段よく使っているのがClaude Codeです。プロジェクト上でClaude Codeに「ロキソニンの処方をつくって」とお願いしてみたところ、以下のような出力が得られました。

  LOXONIN_MUCOSTA = Prescription(
      patient_id=101,
      prescription_date=date(2025, 12, 1),
      clinic_name="むすびクリニック",
      doctor_name="掛橋一郎",
      items=[
          PrescriptionItem(
              medicine_code="1149019F1560",  # ロキソニン錠６０ｍｇ
              dosage_form_code=NAIHUKU,
              usage="１日３回　毎食後",
              prescription_days=7,
              amount=3.0,
              unit="錠",
          ),
          PrescriptionItem(
              medicine_code="2329021F1102",  # ムコスタ錠１００ｍｇ
              dosage_form_code=NAIHUKU,
              usage="１日３回　毎食後",
              prescription_days=7,
              amount=3.0,
              unit="錠",
          ),
      ],
  )

お気付きになられたと思いますが、ロキソニンと一緒に「ムコスタ」も含まれている点に注目です。ムコスタはロキソニンと併用されることが多い薬剤ですが、特に指示を出していなくてもAIがこういった形で「空気を読んで」ありそうな処方パターンを生成してくれています。内容によってはちょっと余計なお世話なときもありますが「ロキソニンだけの処方にして」など追加で指示を行うことももちろんできます。今回は特に支障がないのでこのままいきましょう。

まあ、このくらいのシンプルな処方であれば、それほどがんばらなくても手で書けると思うかも知れません。しかし、もっと複雑なケースをテストする必要があったとしたらどうでしょう？例えば「1人の人が処方期間の途中で頓服をもらいに来たときの処方の組み合わせ」や「4週間ごとに慢性疾患の治療で通院している患者さんの処方3ヶ月分」といった、複数の処方箋が絡み合うパターンを手で書くのは間違いが入る可能性もありなかなか大変ですが、AIならば簡単に生成してくれます。

テストデータ共有という課題

さて、ここまででこのシステムにおいてはAIで簡単にテストデータを作成できるようになりました。しかし、新たな課題が浮上します。

例えば、このシステムと連携している別のシステムがあり、特定の処方パターンに対する処理に手を加えたとします。変更前後で後工程のシステムに影響が出ないことを保証するためには、連携先のシステムにも同じケースのテストを追加したいところです。

もちろん、連携先のプロジェクトでも同じようにAIにテストケースを作らせることはできます。しかし、それぞれのプロジェクトで別々に生成すると、微妙な差異が入り込んでしまう可能性があります。医薬品には、よく似た名前のものなども多数あり、もし今回のテスト対象がそのわずかな差異に影響していたらどうでしょう？「同じ処方パターン」のつもりが、実は細部が異なっていてテストにならなかった…、というのでは元も子もありません。

なんとか複数のプロジェクト間でテストデータを揃える方法がないものか…と考えていたところ、ひとつアイデアが思い浮かびました。それはMCPサーバーの活用です。作成した処方パターンを記憶しておいて、名前をつけて呼び出せる「prescription-memory」MCPサーバーがあれば、別のプロジェクトからも気軽に同じ処方パターンを参照して、そちらでもテストケースを作成してもらえそうです。

MCPサーバーを使ってみよう！

早速、Claude Codeに相談してみました。

> こういうのを、処方パターン1として記憶できる、prescription-memory mcpを作れますか？

⏺ いいですね！作りましょう！

力強い返事をいただきました。そしてただプロンプトにyesと答え続けるだけでほとんど全自動で実装が進み、あっという間に以下のようなファイル構成のMCPサーバーができあがりました。

prescription-memory-mcp/
├── pyproject.toml
├── README.md
└── src/
    └── prescription_memory_mcp/
        ├── __init__.py
        ├── prescriptions.db
        └── server.py

prescriptions.dbはSQLiteのデータベースファイルで、ここに処方パターンがJSON形式で保存されます。

作成されたMCPツールは以下の4つです。

ツール	説明
`save_prescription`	処方パターンをJSON形式で保存します
`get_prescription`	保存された処方パターンを取得します
`list_prescriptions`	保存されている処方パターンの一覧を表示します
`delete_prescription`	不要になった処方パターンを削除します

別プロジェクトからの利用

それでは、このMCPサーバーを別のプロジェクトから利用してみましょう。.claude/mcp.jsonにMCPサーバーの設定を記述することで、他のプロジェクトからも同じ処方パターンにアクセスできるようになります。

別のプロジェクト（今回はTypeScriptのプロジェクト）で「保存されている処方をfixtureにして」と依頼してみたところ、以下のような結果が得られました。

/**
 * ロキソニン + ムコスタ（7日分・単発処方）の処方アイテム
 * - ロキソニン錠60mg（解熱鎮痛剤）
 * - ムコスタ錠100mg（胃粘膜保護剤）
 */
export const LoxoninMucostaPrescriptionItems: PrescriptionItem[] = [
  {
    medicine_name: "ロキソニン錠６０ｍｇ",
    usage: "１日３回　毎食後",
    prescription_days: 7,
    dispensed_quantity_unit: "21錠",
    amount_unit: "3錠",
  },
  {
    medicine_name: "ムコスタ錠１００ｍｇ",
    usage: "１日３回　毎食後",
    prescription_days: 7,
    dispensed_quantity_unit: "21錠",
    amount_unit: "3錠",
  },
];

/**
 * ロキソニン + ムコスタの処方詳細（単発処方）
 */
export const LoxoninMucostaPrescriptionDetailFixture: PrescriptionDetailResponse =
  {
    clinic_name: "むすびクリニック",
    dispensing_date: "2025-12-01",
    pharmacy_name: "カケハシTest薬局",
    prescription_items: LoxoninMucostaPrescriptionItems,
    patient_name: "テスト患者",
  };

/**
 * ロキソニン + ムコスタの処方履歴（単発）
 */
export const LoxoninMucostaPrescriptionHistoryFixture: PrescriptionResponse[] =
  [
    {
      id: 101,
      dispensing_date: "2025-12-01",
      clinic_name: "むすびクリニック",
      pharmacy_name: "カケハシTest薬局",
      patient_name: "テスト患者",
    },
  ];

いかがでしょうか。元のPythonコードとは言語もデータ形式も異なりますが、MCPサーバーから取得した処方パターンを元に、プロジェクトの型定義に合わせたfixtureを生成してくれています。

具体的に違いを見てみると、例えば医薬品の識別方法がPython版ではmedicine_codeが外部キーになって参照していたのに対し、TypeScript版ではmedicine_nameとして直接記述されています。また、用量の表現もPython版ではamount: 3.0とunit: "錠"を別々に持つのに対し、TypeScript版ではamount_unit: "3錠"のように結合した文字列で保持しています。

このようにプロダクトごとにデータの持ち方が異なっていても、MCPサーバーに保存された処方パターンを元に、AIがそれぞれのプロジェクトの型定義を読み取って適切な形式に変換してくれます。開発者は形式の違いを意識することなく、同じ処方パターンのテストデータを両方のプロジェクトで利用して開発できるようになりました。（注: このデータ構造は説明用に簡略化されたもので実際はもう少し複雑なのでもっと恩恵が大きい）

まとめ

今回は、生成AIとMCPサーバーを組み合わせて、医薬品関連のテストデータを効率的に作成・共有する方法をご紹介しました。

従来、複雑な処方パターンのテストデータを作成する際は、間違いが混入しないか確認しながら慎重に作業する必要があり、なかなか気合いを要する作業でした。しかし、このような仕組みがあれば、むしろ複雑なテストパターンも積極的に試してみようという気持ちになれます。込み入った仕様でも躊躇なく実験できることになって、提案の幅が広がるかも知れません。

医療系のシステム開発では、正確なデータを用いたテストが品質担保において非常に重要です。今回ご紹介したアプローチは本当に単純なものですが、これだけでも大いに可能性を感じました。

カケハシでは、このようにAIを活用しながら新規事業の可能性を探るエンジニアやPdMを募集しています。今回ご紹介したように、社内には複数のプロダクトで蓄積されたデータや医療ドメインの知見があり、それらを組み合わせて新しい価値を生み出すチャレンジができる環境です。生成AIの活用にも積極的に取り組んでおり、新しい技術を試しながら医療に貢献したいという方、ぜひ一緒に働きませんか？少しでも興味を持っていただけた方は、ぜひ以下の採用ページからご連絡ください。

ランキング参加中

プログラミング