臨床研究などである疾患におけるリスク因子を同定するとき（例えば、IPFにおける死亡リスク因子）やバイオマーカーやAI、診断モデルの開発では、「開発（探索）コホート」と「検証コホート」を分けて解析を行うことが一般的です。
まず、開発コホートでリスク因子の同定やモデル構築を行い、検証コホートでそれが機能するかどうかを確かめます。
その目的は、モデルや結果の一般化可能性を確保し、過適合を防ぐことにあります。以下では、これらの概念を解説しながら、その重要性を順を追って説明します。
開発コホートと検証コホートとは？
- 開発コホート
リスク因子の同定やモデルの構築、バイオマーカーの選定を行うためのデータセットです。 - 検証コホート
同定したリスク因子や開発したモデル、選定したバイオマーカーが別のデータセットでも有効かを確認するために使用されるデータセットです。
ちなみに、開発コホート・検証コホートは以下のような表現を使うことがあります。
開発コホート（Development Cohort）
日本語での言い換え:
- 学習用コホート:モデルを「学習」させるためのデータセットとして強調する場合に使われる。
- 構築用データ:モデルの構築やアルゴリズム調整に使うデータというニュアンス。
- 導出コホート：臨床研究でよく使われる表現で、データからモデルを「導出（derive）」するニュアンス。
英語での言い換え:
- Training Cohort:機械学習で特に一般的に使われる表現。
- Model Development Cohort:モデル開発を強調する場合に使われる。
- Training Dataset:機械学習やAI分野で頻出の表現。
- Derivation cohort:導出コホートの英訳
検証コホート（Validation Cohort）
日本語での言い換え:
- 検証用コホート：開発したモデルを「検証」する目的を強調する場合に使われる。
- 評価用データ：機械学習では「モデル評価」に使うデータとして一般的な表現。
- 外部検証コホート：開発に使われなかったデータ（外部データ）を明示する場合に使う。
英語での言い換え:
- Validation Cohort：一般的な表現で、研究やAI開発の分野で広く使われる。
- Test Cohort：検証の最終段階（テスト）を指す場合に使われる。
- Evaluation Dataset：検証目的のデータというニュアンスを持つ表現。
- External Validation Cohort：開発データから完全に独立したデータを指す際に使われる。
開発コホートは「モデルを作るためのデータ」、検証コホートは「モデルを評価するためのデータ」という基本的な役割の違いを明確にすることが重要です。
一般化可能性（Generalizability）とは？
一般化可能性とは、モデルや研究結果が新しいデータや異なる集団に対しても同じように適用できる能力を指します。つまり、「特定のデータセットや環境だけでなく、他の状況でも有効に機能するか」を評価する概念です。
なぜ一般化可能性が重要なんでしょうか？
→詳しくはこちらの一般化可能性と過適合のページで。
過適合（overfitting）とは？
過適合とは、AIモデルや統計モデルが訓練データ（開発コホート）に対して学習しすぎた結果、訓練データでは良い結果を出せるものの、未知のデータや現実世界のデータではうまく機能しなくなる状態を指します。
詳しくはこちらの一般化可能性と過適合のページで。
開発コホートと検証コホートを分ける理由
過適合などの問題を防ぎ、一般化可能性を高めるためです。
繰り返しになりますが、データを開発用と検証用に分け、
開発コホートでリスク因子の同定やモデル構築を行い、検証コホートでそれが機能するかどうかを確かめます
具体的なメリット
過適合の発見
過適合が起きている場合、検証コホートで性能が大幅に低下するため、過適合を検知できる。
バイアスを防ぐ
モデルが開発コホートのみに偏らず、他のデータにも対応できるかを確認できる。
一般化可能性の評価
検証コホートでの性能評価によって、モデルが新しいデータでも有効かどうかを判断できる。
どうやって開発コホートと検証コホートを作ったらよい？
複数のデータセットを準備する
異なるデータセットを利用する方法です。特に多施設研究や異なる集団を含む研究に適しています。
当たり前ですが、これが一番シンプルで、実現可能性があります。自分の所属施設のデータと、共同研究を締結している病院のデータを収集してどちらかを開発、もう一方を検証コホートにします。
- 施設間の分割
- 例: 開発コホートを専門病院の患者データから作り、検証コホートを一般病院の患者データから作る。
- メリット: 開発と検証に完全に独立したデータを利用できるため、モデルの一般化性能を評価しやすい。
- デメリット: 施設ごとの患者背景が異なる場合、開発コホートで学んだリスク因子が必ずしも適応できないことがある。
- 地域や国別の分割
- 例: 開発コホートを都市部の患者データ、検証コホートを地方の患者データから作る。
- メリット: 地域差を考慮した検証が可能。
大きなデータセットを分割する
単一の大規模データセットを分割して、開発コホートと検証コホートを作る方法です。
- ランダム分割
- データ全体を無作為に分割して、70%を開発コホート、30%を検証コホートとする。
- メリット: 容易に実行可能。
- デメリット: データの背景に偏りがあると、開発コホートと検証コホートが類似しすぎる可能性がある。
- 層別分割（Stratified Splitting）
- リスク因子や疾患ステージなど、重要な要素が均等に分布するようにデータを分割。
- 例: 年齢、性別、重症度のバランスを保ちながら、開発コホートと検証コホートを作る。
- メリット: 開発と検証の間でデータの偏りを減らせる。
- 時間順分割
- データを収集された時間順に分割する。古いデータを開発コホート、新しいデータを検証コホートに割り当てる。
- メリット: 将来のデータを予測する現実的なシナリオを模倣できる。
- デメリット: 古いデータと新しいデータに背景の違いがあると、過適合が検出されない可能性。
- 地理的分割
- 特定の地域や病院の患者を開発コホート、別の地域や病院の患者を検証コホートとする。
- メリット: 地域ごとの違いを評価可能。
クロスバリデーション（Cross-Validation）を活用
データ量が少ない場合や分割データの偏りを防ぎたい場合に有効。
- K分割交差検証（K-Fold Cross-Validation）
- データをK個（例: 5つ）に分割し、1つを検証コホート、残りを開発コホートとして訓練。これをK回繰り返して、すべてのデータが検証に使われる。
- メリット: データが少なくても全体の評価ができる。
- デメリット: 計算コストが高い。つまりめんどくさい。
- 層別K分割交差検証
- 重要な因子（例: 年齢層、性別）が均等になるように層別化してK分割を行う。
- メリット: 特定のサブグループが偏らない。
- リーブワンアウト交差検証（LOOCV: Leave-One-Out Cross-Validation）
- データセットから1つのサンプルを検証用に取り出し、残りを開発コホートとして訓練。これを全サンプルで繰り返す。
- メリット: 極端に小さいデータセットでも評価可能。
- デメリット: 計算コストが非常に高い。
外部検証
独立した外部データセットを使う方法で、モデルの汎用性を評価します。
- 外部データを別途収集
- 例: 別の国や施設から提供されたデータを検証コホートとして利用。
- メリット: 最も厳密な評価が可能。
- デメリット: 外部データを収集するコストや手間が大きい。
- 公開データベースの利用
- 公開されている患者データセット（例: BioBank、CDCのデータ）を検証コホートとして利用。
- メリット: 手軽に利用可能。
おすすめの組み合わせ
- 大規模データがある場合
- 層別ランダム分割（開発コホート70%、検証コホート30%）＋ 外部検証データ。
- データが少ない場合
- K分割交差検証（特に層別を推奨）。
- 異なる施設間の比較をしたい場合
- 施設ごとに開発コホートと検証コホートを設定し、外部データも検証に活用。
データの分割方法や検証方法は、研究目的や利用可能なデータに応じて柔軟に選択することが重要です。
まとめ
開発コホートと検証コホートを分けることは、以下を確保するために重要です：
- 同定したリスク因子やモデル、バイオマーカーの一般化可能性を高める。
- 過適合を防ぎ、リアルワールドでの実用性を向上させる。
- データに対する偏りやバイアスを最小化する。
これにより、信頼性の高い研究結果やモデルの構築が可能になります。
学会発表や論文作成では、複数の関連病院や共同研究機関と連携して複数のコホートを準備するのが一番シンプルかもしれませんね！
＜スマートフォンをご利用の皆さまへ＞
他の記事をご覧になりたい場合は、画面左上の「メニュー」からジャンルを選択してお楽しみいただけます。
また、画面右下の「サイドバー」を使って、気になる話題を検索することもできますので、ぜひご活用ください。
＜PCをご利用の皆さまへ＞
他の記事をご覧になりたい場合は、画面上部のメニューバーや画面右側のサイドバーをご利用いただき、気になる話題をお探しください。