第12章: 臨床応用システム

この章を読む理由

臨床応用では、解析ができることと、診療や報告に使えることは同義ではありません。 第12章では、研究用データやシステム設計を、 匿名化、責任境界、証拠水準、監査可能性の観点から見直します。

本章で使う共通題材

• 題材B: TCGA-LUAD 研究用ミニケース
  • TCGA-LUAD
  • 公開の研究用データを使い、研究・教育用サマリを作る前に必要な整理事項を確認します。
  • 研究用途の retrospective review であり、診断・治療判断に直接用いるものではありません。

なぜ IT 技術者に必要か

臨床応用システムでは、解析 pipeline、LIMS、EHR、CDSS、clinical report、監査ログ、権限管理が連携する。IT 技術者が研究解析と臨床実装の境界を理解していないと、研究用 annotation や候補リストを診断・治療・投薬判断として誤用する危険がある。本章では、公開・教育用の例で責任境界を確認し、実患者の判断は専門家レビューと施設手順に委ねる前提を固定する。

学習目標

• がんゲノム医療、希少疾患の候補探索、薬理ゲノミクスの各場面で必要な入力、QC、責任境界を説明できる
• 研究用結果を研究・教育用サマリに整理する際に必要な追加確認事項を整理できる
• 研究・教育用サマリに留める情報と、臨床実装で専門家判断・施設承認へ進めるべき情報を切り分けられる
• TMB、MSI、HRD、companion diagnostics、evidence level を検査法・閾値・適応・DB版と結びつけて説明できる
• ACMG/AMP、AMP/ASCO/CAP、oncogenicity、actionability / evidence level の用語を混同せず説明できる

前提知識

• 第4章の FASTQ / BAM / VCF、reference_version、QC、variant annotation、annotation DB version の考え方。入力ファイルと根拠DBの版が分からない所見は、臨床・研究のどちらでも説明責任を満たさない。
• 第9章の germline / somatic / population frequency、ancestry metadata、PRS / PGS の一般化可能性。集団差や背景頻度を、個人の診断・治療判断へ短絡しないこと。
• 第10章の ClinVar、ClinGen、CIViC、OncoKB、CPIC / ClinPGx、PharmCAT、FDA table、accession、API / DB release、license / terms、provenance の記録方法。ClinGen の variant classification guidance / actionability assertion は ClinVar の record とは独立して確認日・specification version・根拠文献を残すこと。
• 第11章の個人情報、要配慮個人情報、個人識別符号、仮名加工情報、匿名加工情報、NBDC、研究倫理、次世代医療基盤法、access control / audit log の責任境界。
• ACMG/AMP、AMP/ASCO/CAP、ClinGen VCEP、ClinGen/CGC/VICC oncogenicity、clinical actionability、DB-specific evidence level は同じ分類体系ではないこと。
• LIMS、EHR、CDSS、clinical report、validation / QA / audit は、単なるファイル出力ではなく、施設SOP、専門家レビュー、変更管理、監査証跡を伴う運用であること。
• 本章のサンプルコードと表は研究・教育用途であり、患者の診断、治療選択、投薬判断、患者説明、保険・薬事上の判断には使わないこと。

基本概念

第12章では、研究解析、教育用解析、臨床実装、clinical report、LIMS、EHR、CDSS を明確に分ける。variant classification、oncogenicity、actionability、pharmacogenomics recommendation は、それぞれ参照する標準・DB・専門家レビュー・施設手順が異なる。

入力データと出力データ

標準的なワークフロー

1. 解析目的を研究・教育・臨床実装のいずれかに分類し、責任者と承認経路を確認する。
2. germline / somatic / pharmacogenomics を分け、参照すべき標準・DB・ガイドラインを決める。
3. 入力データの由来、利用条件、個人識別性、アクセス権、確認日を記録する。
4. annotation / classification / tiering / actionability の各段階で、DB version と evidence level を残す。
5. LIMS / EHR / CDSS へ接続する場合は、QA、監査ログ、権限、変更管理、専門家レビューを施設手順で確認する。
6. 出力は研究・教育用サマリとして扱い、診断・治療・投薬判断へ直接接続しない。

実務上の落とし穴

• ClinVar や OncoKB 等の annotation を、確認日・evidence level・適用範囲なしに臨床判断として扱う。
• germline、somatic、pharmacogenomics の根拠ソースと報告責任を混同する。
• 研究用 pipeline の結果を、LIMS / EHR / CDSS にそのまま流し込む。
• clinical report の文面、説明責任、専門家レビュー、施設承認をシステム出力だけで代替できると誤解する。
• 公開・合成データの例を、実患者データや非公開医療データの利用許可として読む。

研究解析・教育用解析・臨床実装の境界

本章の例は、公開データや合成データを使って「どの情報を確認し、どの証跡を残すか」を学ぶためのものです。研究用の所見候補を表にできても、それだけで診断、治療選択、投薬判断、患者説明に使えるわけではありません。臨床実装では、施設の品質管理、検査法の妥当性確認、専門職レビュー、規制・倫理・情報管理の手順が別途必要です。

第11章で整理した制度・ガイドライン確認表は、この境界表の前提です。第12章ではさらに、variant / 変異の根拠、患者背景、検査品質、報告責任者、更新時の再評価を分けて記録します。

NBDCヒトデータベース、研究機関の倫理審査、個人情報保護法、次世代医療基盤法は、同じ「医療・ゲノムデータの利用」に関わっていても適用枠組みが異なります。研究・教育用サマリを作る段階では、データ提供元、同意・利用目的、公開区分、アクセス権、匿名加工情報/仮名加工情報の扱いを混同しないよう、2026年版出典監査メモの human data sharing / NBDC、research ethics / 人を対象とする研究、medical data / 次世代医療基盤法 の各確認行へ戻って記録します。

表現・分類・報告・発見・アクセスを分ける

臨床ゲノムの相互運用では、同じ variant / 変異を扱っていても、表現、分類、報告、薬理ゲノミクス、発見、アクセスの層が異なります。IT 技術者が要件定義で最初に行うべきことは、どの層の標準を使っているのかを明示し、別の層の結論へ読み替えないことです。

ClinVar の classification を読むときは、germline、somatic oncogenicity、somatic clinical impact を別項目として扱います。ClinVar は aggregate record で3種類の分類を集約し得ますが、同じ variant に複数の分類が表示されても、用途は同じではありません。germline classification は Mendelian disease や薬物応答などの inherited / germline 文脈での臨床的意義を扱います。somatic oncogenicity は腫瘍細胞での増殖・生存上の優位性など、発がんへの関与を分類します。somatic clinical impact は特定の腫瘍種・状態における診断、予後、治療などの clinical impact を扱います。研究・教育用サマリでは、classification_type、対象疾患または腫瘍種、提出者、review status、根拠文献、確認日を分けて残し、1つのラベルへ丸めません。²⁴

germline / somatic / pharmacogenomics の根拠ソース境界

variant / 変異の根拠を調べるときは、同じ「variant」という語でも、germline / 生殖細胞系列、somatic / 体細胞、薬理ゲノミクスで責任境界が変わります。研究・教育用サマリでは、結論を1つに丸めず、どの根拠ソースを、どの版・accession・確認日で見たかを残します。

ClinPGx ecosystemの役割境界

ClinPGxへの移行は、PharmGKB、CPIC、PharmCATが同じ役割または同じ製品名になったことを意味しません。 ClinPGx公式は3プロジェクトを統合するclinical PGx resourceとして説明し、2025年の移行告知はPharmGKB相当コンテンツと旧URLをClinPGxへ再編・redirectすると説明しています。¹⁰¹⁹

注意すべき点は、データベースやツールが「根拠を整理する場所」であって、読者がそのまま診断名、治療方針、投薬量を決める場所ではないことです。 たとえば ClinVar は提出情報と根拠を集約する public archive ですが、提出内容を独自にcurate / modifyしないことを明示しています。 CPIC guideline、PharmGKB / ClinPGxのcurated annotation、PharmCAT reportを使う場合は、それぞれの出典、利用条件、確認日、tool version、入力VCF要件、source guidelineを分けて記録し、ツール出力を処方判断そのものとして扱いません。 OncoKB の FDA-recognized 扱いも、FDAが示す Level 2 / Level 3 biomarkers の範囲を超えて一般化しません。^{1681019111821}

variant classification / tier / oncogenicity / actionability の用語境界

臨床ゲノムの用語では、pathogenic、likely pathogenic、VUS、Tier I、oncogenic、actionable が似た文脈で出てきます。しかし、これらは同じ意味ではなく、対象データ、疾患文脈、根拠体系、報告目的が異なります。研究・教育用サマリでは、用語だけを抜き出して別体系へ翻訳せず、どの分類体系・版・根拠で使った用語かを残します。

特に VUS は「不明だから重要でない」でも「疑わしいから陽性」でもありません。研究・教育用サマリでは、不確実性、再評価条件、必要な追加情報（表現型、家系、腫瘍種、検査法、文献、DB版）を残します。臨床実装では、分類変更、再報告、患者説明、治療方針への反映は施設SOPと専門家レビューの対象です。

clinical report / LIMS / EHR / CDSS と QA の責任境界

研究・教育用サマリから臨床実装へ進むときは、variant annotation だけでなく、検体、解析run、報告、電子カルテ連携、意思決定支援、品質管理の境界を分けて設計します。本書では clinical report / 臨床報告書を作る手順そのものではなく、IT技術者が要件定義で混同しやすい入出力と監査項目を整理します。

この表の目的は、どのシステムへ何を渡すかを早く決めることではなく、渡してはいけないものを明確にすることです。たとえば研究・教育用サマリは、variant候補と根拠sourceを整理する成果物であって、署名済みclinical report、EHRへ保存する診療記録、CDSSの自動推奨ではありません。実装時には、施設の品質保証部門、検査責任者、医療情報部門、セキュリティ担当、法務・倫理担当が、それぞれ承認すべき項目を分けて確認します。

TMB / MSI / HRD / companion diagnostics / evidence level の責任境界

TMB、MSI、HRD、companion diagnostics、evidence level は、臨床判断を支えるための情報であって、本書のサンプルコードだけで診断や治療を決める根拠ではありません。研究・教育用サマリでは、値やlevelだけを抜き出さず、検査名、解析手法、閾値、腫瘍種、適応、DB版、参照日、限界を併記します。

この表の目的は、バイオマーカーや根拠レベルを「結論」ではなく「確認対象」として扱うことです。TMB、MSI、HRD は assay / 検査法、閾値、検体品質、対象疾患に依存します。companion diagnostics は対応する薬剤の安全・有効使用に必要な情報を与える検査であり、治療判断を単独で完結させるものではありません。OncoKB と CIViC の evidence level は、それぞれのキュレーション体系における根拠メタデータであり、別DBのlevelへ機械的に換算しません。

12.1 がんゲノム医療

体細胞変異解析パイプライン: 以下は研究・教育用に体細胞変異の所見候補を整理する Python 断片です。入力 VCF、検査妥当性、承認済み手順、腫瘍ボード等の専門家レビューを省略しているため、診断・治療判断には利用できません。 🧪 概念例（実行不可: 入力 VCF・検査妥当性・専門家レビューを省略した Python 断片）

class CancerGenomicsEvidenceReview:
    """研究・教育用に体細胞変異の所見候補を整理する概念例"""
    
    def __init__(self, tumor_sample, normal_sample):
        self.tumor = tumor_sample
        self.normal = normal_sample
        
    def collect_driver_candidates(self):
        """
        ドライバー候補の整理。
        臨床判断に使うには、検査妥当性、専門家レビュー、
        施設の承認済み手順が別途必要。
        """
        # 体細胞変異の検出
        somatic_variants = self.call_somatic_variants()
        
        # 既知のがん関連遺伝子リストとの照合
        cancer_genes = self.load_cancer_gene_list()
        
        driver_candidates = []
        for variant in somatic_variants:
            if variant['gene'] in cancer_genes:
                # 機能的影響が大きい可能性のある候補を記録
                impact = self.assess_functional_impact(variant)
                if impact == 'HIGH':
                    driver_candidates.append({
                        'variant': variant,
                        'evidence_status': 'candidate',
                        'next_check': '根拠DB、文献、検査品質、専門家レビューを確認'
                    })
                    
        return driver_candidates
    
    def tumor_mutational_burden(self, callable_mb, somatic_variants=None):
        """
        腫瘍変異負荷（TMB: mutations per megabase）の計算例。

        注:
        - 分母（Mb）は panel / exome / genome や callable region の定義に依存する。
        - 分子も「何を数えるか」（例: 非同義SNV/indel）を明確にする。
        - この例では、数えるべき変異タイプでのフィルタリングは事前に行われている
          （例: 非同義SNV/indel のみを somatic_variants に渡す）ことを前提とする。
        """
        if callable_mb <= 0:
            raise ValueError("callable_mb must be > 0")

        variants = somatic_variants if somatic_variants is not None else self.call_somatic_variants()
        # ここでは変異タイプに応じたフィルタリングは行わない想定。
        # 分子として数える変異の選択（例: 非同義SNV/indel のみ）は、
        # あらかじめ variants（somatic_variants）を用意する段階で実施しておく。
        total_mutations = len(variants)
        return total_mutations / callable_mb

研究・教育用所見として整理する項目:

• 分子標的薬に関連し得る variant / 変異の根拠DB・文献確認
• 免疫チェックポイント阻害薬の議論に関わる TMB / MSI 等の算出条件と限界
• 臨床試験候補を調べる前に必要な適格条件・データ利用条件の整理

導入チェックリスト（実務）

• データ保護・規制: 匿名化/仮名化、同意取得、監査ログ、データ保持期間（第11章/付録D参照）
• 精度評価: ゴールドスタンダード/外部精度管理（EQA）、バリデーション手順書
• 運用: SOP/手順書、権限管理、バックアップ/DR、障害時の連絡体制
• 品質管理: QC/QA基準、変更管理、バージョン管理、再現性（コンテナ/ワークフロー）
• 説明責任: 研究・教育用サマリ様式、根拠リンク（文献/DB）、可視化（専門家レビューへ渡す前提）
• 性能: スループット/遅延目標、スケーリング戦略、モニタリング/アラート

（関連）第11章（プライバシー）、付録D（セキュリティベストプラクティス）

12.2 希少疾患の候補探索

エクソーム/ゲノム解析: 以下は研究・教育用に希少疾患の候補 variant / 変異を優先順位付けする Python 断片です。入力 VCF、家系情報の確認、表現型照合、同意、専門家レビュー、確認検査を省略しているため、診断名の決定には利用できません。 🧪 概念例（実行不可: 入力 VCF・家系/表現型確認・確認検査を省略した Python 断片）

class RareDiseaseCandidatePrioritizer:
    """研究・教育用に希少疾患の候補 variant / 変異を整理する概念例"""
    
    def __init__(self, proband_vcf, parent_vcfs=None):
        self.proband_vcf = proband_vcf
        self.parent_vcfs = parent_vcfs
        
    def trio_analysis(self):
        """
        トリオ解析（発端者+両親）で de novo 候補を抽出する。
        診断名を決めるものではない。
        """
        if not self.parent_vcfs:
            # 両親データがない場合も戻り値型を一定にする。
            return []
            
        # de novo候補の検出
        de_novo_candidates = []
        
        for variant in self.proband_vcf:
            if (variant not in self.parent_vcfs['mother'] and 
                variant not in self.parent_vcfs['father']):
                de_novo_candidates.append(variant)
                
        return de_novo_candidates
    
    def prioritize_variants(self, variants):
        """
        候補 variant / 変異の優先順位付け。
        ここでの点数は教育用の重み付けであり、
        臨床的なvariant分類や診断基準ではない。
        """
        scored_variants = []
        
        for variant in variants:
            score = 0
            
            # 教育用の重み付け例。実際の分類基準ではない。
            if self.is_null_variant(variant):
                score += 10
            if self.in_disease_gene(variant):
                score += 5
            if self.rare_in_population(variant):
                score += 3
                
            scored_variants.append((variant, score))
            
        return sorted(scored_variants, key=lambda x: x[1], reverse=True)

12.3 薬理ゲノミクス

薬理ゲノミクス確認項目の整理: 以下は研究・教育用に薬理ゲノミクスの確認項目を整理する Python 断片です。CPIC 等のガイドライン確認、検査結果の妥当性、薬剤ラベル、施設手順、専門家レビューを省略しているため、投与可否や用量決定には利用できません。 🧪 概念例（実行不可: ガイドライン確認・検査妥当性・施設手順を省略した Python 断片）

class PharmacogenomicsEvidenceReview:
    """研究・教育用に薬理ゲノミクスの確認項目を整理する概念例"""
    
    def __init__(self):
        self.pgx_reference = self.load_pgx_reference()
        
    def collect_drug_gene_findings(self, genotype, drug):
        """
        薬剤と遺伝子型に関係し得る所見候補を整理する。
        薬剤応答を予測したり、投与可否・投与量を決めたりしない。
        """
        # 関連する薬理遺伝子変異の確認
        relevant_variants = self.pgx_reference.query(drug)
        
        evidence_summary = {
            'drug': drug,
            'observed_variants': [],
            'evidence_notes': [],
            'clinical_review_required': True
        }
        
        for variant in relevant_variants:
            if self.has_variant(genotype, variant):
                evidence_summary['observed_variants'].append(variant)
                evidence_summary['evidence_notes'].append(
                    self.describe_evidence_limit(variant)
                )
                
        return evidence_summary

12.4 研究・教育用サマリと臨床レポートの境界

研究・教育用サマリ作成: 以下は研究・教育用サマリの構成を説明する Python 断片です。患者説明、臨床報告書、監査、承認済みテンプレート、専門家レビューを省略しているため、臨床レポートとしては利用できません。 🧪 概念例（実行不可: 臨床報告書要件・監査・専門家レビューを省略した Python 断片）

class ResearchEducationSummaryDraft:
    """研究・教育用の所見サマリを作る概念例"""
    
    def generate_summary(self, analysis_results):
        """
        解析結果から研究・教育用サマリを生成する。
        診断、治療、投薬、患者説明には使わない。
        """
        summary = {
            'sample_id': analysis_results['sample_id'],
            'created_at': datetime.now(),
            'findings': [],
            'limitations': [],
            'next_checks': []
        }
        
        # 研究・教育用途で確認した所見候補
        for variant in analysis_results['candidate_variants']:
            finding = self.format_research_finding(variant)
            summary['findings'].append(finding)
            
        summary['limitations'] = self.collect_limitations(analysis_results)
        summary['next_checks'] = self.collect_next_checks(analysis_results)
        
        return self.format_as_markdown(summary)

小さな実例

公開variantまたは合成症例を使う最小例では、variant、遺伝子、疾患文脈、参照DB、evidence level、確認日を表にまとめる。目的は臨床レポートを作ることではなく、どの情報が研究・教育用サマリで、どの情報が専門家レビューや施設基準に依存するかを分けることである。

結果の読み方

結果表は、候補の優先順位と根拠ソースの整理として読む。pathogenicity、oncogenicity、actionability、drug response は似た語に見えても、評価軸、対象疾患、DB、専門家レビュー、施設手順が異なる。本文の例だけで診断、治療選択、投薬判断を行ってはならない。

限界と注意点

本章は臨床応用システムの責任境界を学ぶ章であり、医療行為、診断、治療、投薬、患者説明を自動化する手順ではない。実運用では、医師、認定専門家、検査室、倫理・法務・情報セキュリティ部門、施設の QA 体制、関連制度・ガイドラインを確認する必要がある。

まとめ

• 臨床応用で最も重要なのは、解析精度だけでなく、責任境界、証拠水準、監査可能性を明示することです。
• TCGA-LUAD のような研究用公開データは、レポート様式や優先順位付けの練習には使えますが、診断そのものの根拠にはできません。
• 第13章では、こうした判断を支える研究計画、検証設計、再現性確保の考え方へ進みます。

Source notes / 次の一歩

• 2026年版出典監査メモ: 臨床ゲノム（ClinVar / ClinGen / CIViC / OncoKB / CPIC / ClinPGx / PharmCAT / FDA/NCI biomarker 情報、GA4GH VRS / Beacon、FHIR Genomics の確認日）
• 付録F: 第12章の次の一歩
• 付録J: 実在アクセッション一覧
• 付録K: 用語集

2026年時点の更新メモ

• ClinVar、ClinGen、CIViC、OncoKB、CPIC、ClinPGx、PharmCAT、FDA/NCI biomarker 情報、GA4GH VRS / Beacon、FHIR Genomics などは、表現・分類・報告・発見・アクセスの層、version、evidence level、利用条件、確認日を分けて記録する。
• LIMS / EHR / CDSS と連携する場合は、研究用 annotation と clinical report の責任境界、監査ログ、変更管理、専門家レビューを施設手順で確認する。
• 更新根拠は 2026年版出典監査メモの clinical interoperability / data standards、臨床ゲノム項目と、付録Fの第12章項目へ集約する（確認日: 2026-06-05 JST）。

次章への橋渡し

臨床応用で必要な説明責任を満たすには、 なぜその解析条件を選び、どう妥当性を検証したかを研究計画として説明できなければなりません。 第13章では、そのための研究設計と再現性の整理へ進みます。

最小入出力（期待成果物/期待ログ）

• 入力: 要件（対象疾患・検査範囲・報告形式）と、解析結果（合成/匿名化データでも可）
• 出力（期待成果物）: 研究・教育用所見サマリ（臨床レポートではない）、運用チェックリスト（QC/妥当性/監査）、責任境界の整理（最小限）
• 期待ログ（例）: 解析バージョン・入力/出力・QC指標・承認フローの記録（監査可能な形）

演習

1. 研究用公開データを前提に、研究・教育用サマリを作るまでに必要な追加確認事項（同意、匿名化、QC、承認フロー）をチェックリスト化せよ。
2. TCGA-LUAD などの公開データから 1 症例分の所見サマリを作り、研究用途での所見と臨床判断へ回すべき所見を分けて記述せよ。
3. TMB、病的変異候補、薬剤応答候補のいずれか 1 つを選び、分母定義・根拠 DB・限界を 1 ページで説明せよ。

具体課題例

• 研究・教育用サマリのテンプレートに、所見候補、根拠、制約、次の確認事項を分けて記載する。
• 第10章のスキーマ設計を前提に、どのログが監査証跡として必要かを洗い出す。
• 「研究用途の retrospective review」と「診療での利用」を分ける注意書きを明記する。