医療AIモデルに必要なデータ量は、突き詰めれば計算で出せます。何を主張するか、主要評価項目は何か、統計上どこまでの誤差を許すか。この3つが決まれば、必要なイベント数は式から出てきます。その計算は姉妹記事医療AIモデルの学習にはどれだけのデータが必要かで詳しく扱っています。
行き詰まるのは、計算ではありません。
行き詰まるのは、その計算が当たり前の前提にしていることのほうです。各サンプルはどこから来たのか。誰が、どの版の手順書に従ってラベルを付けたのか。どのモデルがそれを学習したのか。テストセットに触れたことはないか。そして2年後、改良版のために新しい独立データが必要になったときにも、同じ問いにまだ答えられるのか。
これがデータライフサイクルの問題です。資金の潤沢な医療AI開発が、見込みのある試作品と、根拠を説明できる製品との間で足踏みする理由でもあります。MAEA（モッドアステラのMedical AI Engineering Agent）が取り組んでいるのは、この問題です。
問題を正確に言い直す
医療AIの開発では、最初にデータを受け取ってから、市販後に改良を加えるまでのあいだ、次の8つを同時に、しかもずっと成り立たせ続けなければなりません。
- どのサンプルも、出どころと使ってよい範囲がはっきりしている。 どの施設の、どのシステムから、いつの期間のものか。どの同意または法的根拠に基づくのか。商用利用、第三者への提供、将来の再学習のための保管について、どこまでの権利があるのか。
- どのラベルも、誰がどの手順で付けたのかがはっきりしている。 どの作業者が付けたのか。どの版の作業指針に従ったのか。1人で読んだのか、2人で読んだのか、判定会議にかけたのか。判断が割れたときはどう決着させたのか。
- どのデータセットも、名前と版を持つひとつのまとまりとして扱われている。 フォルダでも、共有ドライブでも、「3月に届いたエクスポート」でもない。
- データを分ける境界が、正しい単位でずっと保たれる。 患者、症例、標本、受診、施設、期間のうち、主張を支えるのに必要な単位で分ける。しかもそれを毎回手作業でやり直すのではなく、使い回すたびに自動的に守られる。
- 主張したい範囲をどれだけカバーできているかを、数字で確かめられる。 全体の件数だけではない。施設、機器、撮像・検査手順、年齢や性別などの層、疾患のタイプ、想定される失敗のしかた。それぞれの件数まで見える。
- どの結果も、それを生んだ状態まで正確にさかのぼれる。 資料に載っている数値から、使ったデータセットの版、設定、コードの状態、実行の記録までたどり着ける。
- 固めたモデルを、そのまま持ち出せる。 1台のマシンで学習させたものを、その場に居合わせなかった人も含めて、別の場所で再現できる。
- 本番での動きが見えていて、検証で確かめた成績と比べられる。 そうでなければ、それは監視ではなく、ただのダッシュボードにすぎない。
1つだけなら難しくありません。厄介なのは、これらを何年にもわたって、担当者が入れ替わっても、しかもそもそもこうした記録を残すようにできていない道具を使いながら、同時に成り立たせなければならない点です。
なぜ記録が失われるのか
よくある医療AIの開発環境は、それぞれ自分の仕事はきちんとこなすものの、その経緯を次の工程に引き継がない道具の寄せ集めです。PACSやLISからのエクスポート、症例IDを並べた表計算ファイル、ラベリングツール、オブジェクトストレージ、いくつものノートブック、学習スクリプト、そして最後に推論環境。
受け渡しのたびに、情報が1つずつこぼれ落ちます。エクスポートしたデータからは、それを取り出したときの検索条件が消えます。表計算ファイルからは、同意の根拠が消えます。ラベリングツールからは、そのとき有効だった作業指針の版が消えます。ノートブックからは、どの版のデータセットを読んだのかが消えます。そして結果が資料に載る頃には、もう誰もその流れをたどり直せません。
これは無視できる雑務ではありません。Willeminkらの推定によれば、アルゴリズムに入力できる形にするまでの前処理とデータ整備が、医療画像の機械学習プロジェクトの工数の80%以上を占めます。医療AI予算の大半は実際にここへ消えていきます。しかもその作業は、そこで生まれた構造が残らなければ、何の根拠も生みません。
つまずき方は、だいたい決まっています。
- データの混入に、気づくのが遅れる。 同じ患者の画像、標本、受診が学習側と評価側の両方に入り込んでいて、それが判明した時点で数か月分の結果が使えなくなります。仕組みは医療AIにおけるデータリークで扱っています。
- テストセットが、いつのまにか開発用データになる。 調整のたびに何度も見てしまい、気づけば何の性能も測れていません。
- ラベル付けの回ごとの結果を、比べられない。 途中で作業指針が変わったのに、いつ変わったのかを誰も記録していません。
- 再現できない数値が残る。 それを出したモデルが上書きされたか、データセットがその場で書き換えられたかのどちらかです。
- 足りない層の存在に、最後になって気づく。 全体の件数は多かったのに、主張したい対象の層は40例しかなかった、というものです。
- 改良を試す場所がない。 手つかずで残っているのが、すでに申請で使ってしまったテストセットだけ、という状態です。
MAEAはライフサイクルそのものを軸にしている
MAEAは、ライフサイクルそのものを製品として扱います。モデルの学習を製品と考えて、ライフサイクル管理をその周辺の書類仕事として片付けるのではありません。以下に挙げる各段階は、記録が生まれる場所です。その記録を次の段階まで持ち越すことが、MAEAの役割です。
1. 取り込み：データはフォルダではなく、ひとつのまとまりになる
サンプルは、名前の付いたデータセットの一部としてMAEAに入ります。タグ、ボリュームデータやマルチフレーム画像からのスライス切り出し、データセット単位のアクセス権限もあわせて管理されます。ストレージの設定、接続を許可するホスト、APIキー、組織内の役割も、別建てのインフラ設定ではなく同じシステムの一部です。
現場での効き目は単純です。「これは何のデータか」の答えが、ファイル名の付け方や、エクスポートを設定した本人の記憶に頼らなくなります。
2. ラベル付け：正解の基準は、データのある場所で決める
MAEAのラベル付け画面は、ひととおりの作業をカバーしています。多角形や矩形での領域指定。動画・マルチフレームの操作。DICOMのウィンドウ調整と向きの補正。あらかじめ決めたラベル一覧と、キーボード中心の確認作業。さらに、クリックで補助する半自動・全自動のラベル付けや、他所で作ったラベルをマスク画像として取り込むこともできます。
ただ、描画機能より大事な点が2つあります。1つは、ラベルが別のシステムに飛んでいかず、サンプルとデータセットにひもづいたまま残ること。もう1つは、自動ラベル付けを、人が決める正解基準の代わりではなく、あくまでその作業を速くする道具として扱っていることです。この線引きがあるからこそ、できあがったラベルを根拠として使えます。
3. 構成：学習データセットは、手で組まずに条件で書く
MAEAの学習データセットは、すでにまとまりとして存在するデータセットに対して、絞り込み条件、タグ、検索条件を指定して組み立てます。「フォルダに一度だけファイルをコピーする」のではなく、あとから中身を確かめられ、もう一度同じように適用でき、妥当かどうかを議論できる形で残ります。
データ分割が健全かどうかは、ここで決まります。条件として書いておけば、患者単位や施設単位の境界は使い回すたびに保たれます。手で組んだフォルダはその一度きりで、次の人が組み直した時点で失われます。
4. カバー範囲：データセット解析で、手薄な層があらわになる
学習を始める前に、データの中身を確かめる画面があります。正解ラベルやタグの分布、データの提供元から、サンプル1件ごとの詳細まで見られます。特定の層で結果が振るわなかった後ではなく、その前に気づくためのものです。
データ量の見積もりには、「全体の件数は、手薄な層を覆い隠す」という大事な論点がありました。これはその論点への、実務的な答えです。5万症例のデータセットでも、主張したい層が40例しかなければ、集団全体についての主張は支えられても、その層については何も支えられません。この不足に手を打てるのは、まだ集める時間が残っているうちに、誰かが気づいた場合だけです。
5. 根拠：パイプラインと実験が、自分の履歴を持ち歩く
学習と評価は、パイプラインとして動きます。指標を選び、追加学習を行い、結果を図で確かめ、複数のパイプラインを並べて比較できます。その上でMAEAの実験機能が、実験の設定を組み立て、変換し、実行し、失敗時には直します。実行ごとに、生成物の時系列、版を管理した設定、分析用のグラフ、あとから中身を確認できる設定記録が残ります。
肝心なのは、このプラットフォームでモデルを学習できること自体ではありません。モデルを学習させる道具ならいくらでもあります。肝心なのは、グラフに載った数値から、誰の記憶にも頼らずに、それを生んだ設定と実行までたどり着けることです。
6. 固定と持ち出し：スナップショット
パイプラインのスナップショットは、書き出しも読み込みもできます。固めたモデルは持ち運べるひとまとまりになり、協力先が中身を確認でき、別の環境で再現でき、改良版を「実際に検証した版」と比べる必要が出てきたときに、後から取り出せます。
多くの開発環境では、設計凍結は書類を作る作業です。ここでは、持ち出せる成果物として残ります。
7. 導入と監視：検証で確かめた成績とつながったままになる
導入した環境、その利用状況、API呼び出し回数、応答時間といった指標は、そのモデルを生んだデータセットや実験と同じシステムの中にあります。だから監視が、切り離されたダッシュボードではなく、わかっている成績との比較になります。この違いがあって初めて、性能の劣化や運用上の兆候に手を打てます。監視の詳細は規制対象ワークフローにおけるAIモデル監視で扱っています。
8. 変更管理：改良の根拠に、出どころができる
構成が条件として書かれ、設定の版が管理され、スナップショットを持ち出せる。だから改良版は、「たまたま余っていたデータ」ではなく、独立していると示せる取り置きデータで評価できます。これは、管理された変更手続きを回すための前提条件です。そして、それが手元にないことにチームが気づくのは、たいてい必要になったその瞬間です。
データ予算の何が変わるのか
規模を見積もる記事では、「どれだけのデータが必要か」への本当の答えは、日程に沿って組んだデータ予算だと述べました。データは何回かに分けて調達し、そのたびに学習曲線を引き直す。モデルと判定閾値を選ぶ前に、手を触れないテスト用の集団を確保しておく。カバー範囲は合計件数ではなく層ごとに数える。そういう進め方です。
どれも、ライフサイクルを支える土台があってはじめて成り立ちます。
- 何回かに分けた調達には、データセットが版を管理したまま育っていけること、そして学習曲線を、ぶれない「同じ課題」の定義に対して引き直せることが必要です。
- テスト用集団の早めの確保には、その取り置きが担当者の記憶ではなく、システムの側で守られることが必要です。
- カバー範囲の集計には、層がファイル名から復元するものではなく、検索できる属性として持てていることが必要です。
- 段階をまたいだ根拠の使い回しには、概念実証の結果が、3段階先でもまだ読み解ける状態で残っていることが必要です。
この土台がなければ、データ予算は2か月目には実態と合わなくなる表計算ファイルにすぎません。トレーサビリティが、書類づくりの話ではなくデータ計画の話である理由も、ここにあります。
MAEAがしないこと
できないことをはっきりさせておくのも、役に立つことのうちです。
- これを入れれば規制に適合する、というものではありません。 使用目的の設定、リスクマネジメント、臨床評価、品質マネジメントシステム上の義務、申請の進め方は、これまでどおり製造販売業者の責任です。MAEAはそれらを支える追跡可能な記録を残しますが、作業そのものを肩代わりはしません。
- 手元にないデータや、取れていない利用許諾を、生み出すことはできません。 データの調達、提携、権利処理は別の仕事です。
- 使用目的、主要評価項目、合格基準を決めてはくれません。 これらは臨床上・規制上の判断であり、道具が出てくる前の段階で必要症例数を決めてしまいます。
- 自動ラベル付けは、正解の基準ではありません。 臨床の専門家が引き続き責任を持つべきラベルを、より安く作るための道具です。
- 外部での検証を省けるようにはなりません。 そのデータを一度も見たことのない施設でモデルがどう振る舞うかは、どんなライフサイクル管理の仕組みでも教えてくれません。
どこから始めるか
試作品と製品のあいだのどこかにいるなら、最初に効く一手は、基盤の乗り換えではなく棚卸しです。
- 説明責任を負っている結果を1つ選びます。直近の資料に載せた代表的な数値で構いません。
- その数値から、使ったデータセットの版、分割の定義、ラベル作業指針の版、設定、コードの状態まで、正確にたどってみます。
- 途中で流れが切れた箇所を、すべて書き出します。
- その切れた輪を今つなぎ直す手間と、2年後につなぎ直す手間を見比べます。
この作業をやってみれば、データライフサイクルが自分たちにとって現実の問題なのか、それとも机上の話にすぎないのかは、たいていはっきりします。現実の問題だったなら、MAEAは、見つかった切れ目をふさぐために設計されています。そうでなかったとしても、棚卸し自体に大した費用はかかりません。
それより前の段階にいるなら、モデル構築前のAIデータ準備状況のほうが、出発点として適しています。モッドアステラでは、モデルの比較をやり直す手戻りが大きくなる前に、データセットの構造、分割の考え方、根拠の整い具合を見直すお手伝いができます。
参考文献
- How much data is needed to train a medical AI model
- Willemink et al., Preparing Medical Imaging Data for Machine Learning, Radiology 2020
- IMDRF N88, Good Machine Learning Practice for Medical Device Development: Guiding Principles
- FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for AI-Enabled Device Software Functions
- MDCG 2025-6 / AIB 2025-1, interplay between the MDR, IVDR, and the AI Act
- Data leakage in medical AI: building trustworthy train, validation, and test splits
- AI model monitoring for regulated workflows
- AI traceability in regulated workflows
