# 4. **AIプロダクト開発におけるAIセーフティ評価の実践** ## 1. **前提** 本章では、第3章で整理した「何を評価すべきか」という評価観点に対して、「どのように評価するか」という具体的な方法論を解説する。ヘルスケア領域においてAIプロダクトを開発する際には、AIセーフティの確保が不可欠であるが、その評価は特定のフェーズに限定されるものではなく、企画段階から運用に至るまで一貫して行われるべきものである。 ### 1. **プロダクト開発プロセス** 本章では、AIプロダクト開発を以下の5つのフェーズに分けて整理し、各フェーズにおいて重要となる評価項目と具体的な方法を紹介する。実務におけるプロダクト開発のプロセスに即した形で解説することで、ヘルスケア事業者が自身のAIプロダクト開発プロセスにAIセーフティ評価を自然に組み込めるようにすることを目指す。 表 4-1　プロダクト開発の5つのフェーズと重要となる評価項目・具体的な方法 | フェーズ | 概要 | 重要となる評価項目・具体的な方法 | | ----- | ----- | ----- | | **① プロダクト設計** | プロダクトの目的・ユースケースの明確化、リスク評価、ガバナンス体制の構築 | リスクアセスメント、法規制遵守、プライバシー・セキュリティ | | **② モデル選定** | 用途に適したモデルの選定と安全性評価 | モデルの安全性・性能評価、データの取扱い、ライセンス・契約 | | **③ プロダクト実装** | 入力層や出力層、データベース層(RAG)など多層的に安全性対策を実装 | 入出力制御、ハルシネーション対策、透明性確保、RAG実装、UI/UXの工夫、セキュリティ対策 | | **④ プロダクト検証** | 総合的なテスト・検証とリスク評価 | 定量評価、AIレッドチーミングテスト、専門家レビュー、外部評価・第三者認証 | | **⑤ プロダクト導入・運用** | 本番環境でのモニタリングと継続的改善 | 継続的モニタリング、インシデント対応、継続的改善、運用ポリシー、透明性・アカウンタビリティ | 従来のソフトウェア開発とは異なり、学習済みLLMをAPI経由等で利用するAIプロダクトの開発には、各フェーズにおいてAI特有の注意点がある。例えば、基盤モデルのアップデートによって予告なくプロダクトの挙動が変化する可能性があること、プロンプトの微細な変更が出力品質に大きく影響すること等が挙げられる。こうした特性を踏まえ、各フェーズにおける評価のポイントを解説していく。 ### 2. **主要なステークホルダーと役割** ヘルスケアAIプロダクトの開発プロセスには、多様な専門性を持つステークホルダーが関与する。以下に、本ガイドにおける主要なステークホルダーとその役割を整理する。なお、組織の規模や体制によっては、一人が複数の役割を兼務する場合もある。 表 4-2　主要なステークホルダーと役割 | ステークホルダー | 担う役割（例） | | ----- | ----- | | 経営層・事業責任者 | プロダクトの事業判断、リスク受容の意思決定、リソース配分、コンプライアンス体制の統括 | | プロダクトマネージャー（PM） | プロダクトの要件定義、ロードマップ策定、ステークホルダー間の調整、リリース判断 | | エンジニア（開発） | システムアーキテクチャの設計・実装、API連携、フィルタリングやガードレールの実装 | | MLエンジニア／データサイエンティスト | モデル選定・評価、RAG構築、ファインチューニング、評価パイプライン構築 | | QAエンジニア／テスター | プロダクト品質の検証、テスト計画の策定・実行、レッドチーミングの実施 | | UXデザイナー | ユーザー体験の設計、免責事項や警告表示のUI設計、アクセシビリティ対応 | | 医療専門家／ドメインエキスパート | 医学的正確性の監修、臨床的妥当性の評価、患者安全性の確認 | | 法務・コンプライアンス | 規制該当性の判断、個人情報保護法対応、利用規約・免責事項の策定 | | セキュリティ担当 | 脆弱性診断、ペネトレーションテスト、セキュリティ監視体制の構築 | ※表 1-3再掲 ### 3. **ステークホルダー×フェーズの関与マトリクス** 各ステークホルダーがどのフェーズで特に重要な役割を担うかを以下のマトリクスで示す。開発するプロダクトの内容や開発体制によって、各ステークホルダーの関与度合いは異なるため、自社の体制に照らして、あくまで一例として参考にしていただきたい。 表 4-3 ステークホルダー×フェーズの関与マトリクス | ステークホルダー | フェーズ① プロダクト設計 | フェーズ② モデル選定 | フェーズ③ プロダクト実装 | フェーズ④ プロダクト検証 | フェーズ⑤ 導入・運用 | | ----- | :---: | :---: | :---: | :---: | :---: | | 経営層・事業責任者 | ◎ | △ | △ | ○ | ○ | | プロダクトマネージャー（PM） | ◎ | ○ | ○ | ◎ | ◎ | | エンジニア（開発） | △ | ○ | ◎ | ○ | ○ | | MLエンジニア／データサイエンティスト | △ | ◎ | ◎ | ◎ | ○ | | QAエンジニア／テスター | △ | △ | ○ | ◎ | ○ | | UXデザイナー | ○ | △ | ◎ | ○ | ○ | | 医療専門家／ドメインエキスパート | ◎ | ○ | ○ | ◎ | ○ | | 法務・コンプライアンス | ◎ | ○ | △ | ○ | ◎ | | セキュリティ担当 | ○ | ○ | ◎ | ◎ | ◎ | **◎** \= 主導的に関与（そのフェーズの中心的な担い手）　　**○** \= 積極的に参加（実務レベルで貢献）　　 **△** \= 助言・レビュー（必要に応じて参加） | ■ 小規模チームでの運用 スタートアップや少人数チームでは、上記の全役割を個別に配置することが難しい場合がある。その場合でも、「医療専門家の関与」と「法務・コンプライアンスの確認」、「セキュリティの確認」は外部アドバイザーの活用等も含めて確保することが望ましい。ヘルスケア領域では、これらの観点が欠落することのリスクが特に大きい。 | | :---- | ### 4. **評価観点と開発プロセスのマッピング** 第3章の10観点は、特定のフェーズのみで対応すればよいものではなく、**全フェーズを横断して継続的に取り組むべき課題**である。以下のマトリクス表は、各評価観点が各フェーズでどのように具体化されるかの全体像を示すものである。 表 4-4　評価観点×開発プロセスフェーズのマッピング | 評価観点 | フェーズ① プロダクト設計 | フェーズ② モデル選定 | フェーズ③ プロダクト実装 | フェーズ④ プロダクト検証 | フェーズ⑤ 導入・運用 | | ----- | ----- | ----- | ----- | ----- | ----- | | **有害情報の出力制御** | 有害情報のリスク類型を定義し、対応方針を設計 | 安全性ベンチマーク等で有害出力の抑制能力を評価 | 入力・モデル・出力の多層防御を実装 | レッドチーミング・専門家レビューで抑制効果を検証 | 有害出力の発生状況を継続監視し、迅速に是正 | | **偽誤情報の出力・** **誘導の防止** | ハルシネーション等のリスクを類型化し、許容基準を定義 | 事実整合性・医療特化ベンチマークで正確性を評価 | RAGによる根拠付けと出典明示の仕組みを実装 | ハルシネーション率・出典正確性を定量的に検証 | ハルシネーション率を継続監視し、参照データを最新化 | | **公平性と包摂性** | 対象ユーザーの多様性を考慮し、公平性要件を定義 | バイアスベンチマークで偏りと多言語対応を評価 | 代表性あるデータとステレオタイプ抑制を実装 | 属性別の品質差異とバイアスを定量的に検証 | 属性別の品質とアクセシビリティを継続監視 | | **ハイリスク利用・** **目的外利用への対処** | 規制該当性の判断、利用範囲の明確化 | モデルの利用条件が意図する用途と整合することを確認 | ハイリスク質問への拒否・免責・受診勧奨を実装 | ハイリスクシナリオでの適切な動作を検証 | 目的外利用の兆候を監視し、利用ポリシーを運用 | | **プライバシー 保護** | 取扱データを分類し、保護方針を設計段階から確立 | プロバイダーのデータ取扱いが保護要件を満たすことを確認 | 個人情報のマスキング・漏えい検知・再同定抑制を実装 | 漏えいテスト・再同定リスク評価を実施 | 匿名化処理や定期削除などを実施し、データ主体の権利を保障 | | **セキュリティ 確保** | LLM固有の脅威を含むセキュリティ要件を定義 | プロバイダーの体制とモデルの攻撃耐性を評価 | インジェクション防御・認証・暗号化等を多層実装 | ペネトレーションテスト・レッドチーミングで検証 | 脆弱性情報の収集・異常監視を継続的に運用 | | **説明可能性** | ユーザー別に必要な説明レベルを定義 | 出典付き回答の生成能力と断定回避能力を評価 | 根拠提示・不確実性表示・トレーサビリティを実装 | 説明の妥当性と出典の正確性を検証 | 透明性レポートを公表し、説明品質を継続改善 | | **ロバスト性** | 想定される入力の多様性を洗い出し、許容基準を定義 | 多様な入力条件でのモデル出力安定性を評価 | 入力正規化・エラーハンドリング・安全側制御を実装 | エッジケースを含む入力で一貫性と耐障害性を検証 | 入力パターンの変化と性能劣化を継続的に監視 | | **データ品質** | データソースの選定基準と品質要件を定義 | 学習データの品質・偏り・管理状況を確認 | RAGデータのキュレーションとバージョン管理を実装 | データ品質が出力品質に及ぼす影響を検証 | データの鮮度と品質を継続的に管理 | | **検証可能性** | 事後検証に必要なログ要件と評価体制を策定 | プロバイダーの情報開示とバージョン管理方針を確認 | 入出力のログ記録と監査証跡を実装 | 第三者評価で検証可能性の仕組みが機能することを確認 | 変更管理と継続モニタリングで検証可能な状態を維持 | なお、本章に記載されている内容全てを完璧に実施することを求めるものではなく、AIプロダクトのリスクレベル・対象ユーザー・事業規模に応じて優先度を判断し、段階的に取り組むことが望ましい。特にリソースが限られる場合は、安全性に直結する項目（有害情報の出力制御、偽誤情報の出力・誘導の防止、プライバシー保護、セキュリティ確保など）から着手すると効果的である。 また、本章は、自身のプロダクトの開発段階に応じて該当するフェーズから読み始めることも可能となるよう設計している。第3章の特定の評価観点に関心がある場合は、上記のマトリクス表から該当箇所を横断的に参照することも有効である。 ## 2. **フェーズ1 プロダクト設計** プロダクト設計フェーズは、AIプロダクトの安全性を左右する最も重要な段階である。特にヘルスケア領域では、プロダクトの出力が患者の健康や生命に直接影響を与える可能性があるため、「セーフティ・バイ・デザイン」の原則に則り、設計段階から安全性を中核に据えた検討が不可欠であり、このフェーズでの意思決定が、以降のすべてのフェーズにおける安全性の基盤となる。ここでは、プロダクトの目的・対象ユーザー・ユースケースの明確化から、ガバナンス体制の構築、リスクの特定と評価、そして法規制への対応までを包括的に検討する。 | ■プロダクト設計フェーズのポイント プロダクト設計は、何を作るかだけでなく、「どのようなリスクに備えるか」「どのような体制で開発するか」を含む包括的な検討が求められる。セーフティは単なる守りの要素ではなく、信頼されるプロダクトとしての競合優位性にもつながる攻めの要素でもある。 | | :---- | ### 1. **プロダクトの全体設計** #### 1. **AIプロダクトの目的とユースケースの明確化** AIプロダクト設計の出発点は、「誰のために」「どのような価値を届けるために」AIを活用するのかを明確にすることである。ヘルスケア領域においては、対象ユーザー（医療従事者、患者、介護者、一般ユーザー等）や利用場面（文書作成支援、服薬管理、健康相談等）によって、求められる安全性の水準や配慮すべきリスクが大きく異なる。 以下の点を設計段階で明確に定義し、文書化しておくことが重要である。 * **AIプロダクトの対象ユーザーと利用シーン**：誰が、どのような状況で利用するか。医療従事者が医療現場で使うのか、一般ユーザーが健康管理に使うのかで、求められる安全性の水準は異なる。 * **AIが担う役割の範囲と限界**：AIが意思決定を支援するのか、代替するのか。特にヘルスケア領域では、AIの出力が最終的な判断ではないことを明確にすることが多くの場合重要となる。 * **想定されるベネフィットとリスク**：プロダクトがもたらす価値・便益と、想定されるリスクを並列で整理し、そのバランスを検討する。 * **意図しない利用の想定**：設計者が想定していない使われ方についてもあらかじめ検討し、対策を講じておく。 #### 2. **安全性と有用性のバランス** AIプロダクトの開発においては、安全性と有用性のバランスを設計段階から意識的に検討する必要がある。安全性を過度に追求すると、プロダクトの有用性が低下してユーザーに価値を届けられなくなり、逆に有用性のみを追求するとリスクが増大する。 設計段階では、以下のような指標を設定し、両者のバランスを明示的に定義しておくことが望ましい。 * **安全性指標の例**：誤情報生成率、有害コンテンツのフィルタリング率、有害質問の入力率、「分からない」と回答すべき場面での適切な拒否率 * **有用性指標の例**：回答の正確性、ユーザー満足度、タスク完了率、応答時間 これらの指標間にはトレードオフが存在することを認識し、プロダクトの特性やリスクレベルに応じた許容範囲を設定する。例えば、医療現場で使われるプロダクトでは安全性指標を厳格に設定し、医学論文検索のようなプロダクトにおいては有用性をより重視するといった傾斜配分が考えられる。 #### 3. **アジャイル開発の採用** 生成AIを取り巻く環境は急速に変化しており、基盤モデルの更新、規制環境の変化、新たなリスクの顕在化等が頻繁に発生する。こうした状況下では、ウォーターフォール型の開発プロセスでは変化に対応しきれず、アジャイル型の開発プロセスを採用することが推奨される。プロダクト開発の5つのフェーズにおいても、直線的にフェーズが移行するものではなく、高速に各フェーズを行き来しながら開発を進めることが望ましい。 アジャイル開発においては、小さな単位でのリリースと評価を繰り返し、フィードバックを迅速に反映することで、当初想定していなかったリスクにも柔軟に対応できる。また、イテレーションを重ねる中でユースケースが明確になり、対応すべきリスクを学習していくことで、安全性をより一層高めていくことができる。アジャイル開発であっても安全性に関する基本方針は揺るがないものとし、各イテレーションにおいて安全性評価を組み込むことが重要である。 ### 2. **ガバナンス体制の構築** #### 1. **組織レベルのガバナンス** AIセーフティを組織として担保するためには、経営層を含めた全社的なガバナンス体制の構築が不可欠である。AIセーフティへの投資は直接的なROI（投資対効果）が見えにくいため、経営層の理解と支援がなければ、十分なリソース配分がなされないリスクがある。 組織レベルのガバナンスにおいて整備するのが望ましい事項は以下のとおりである。 * **AI利用ポリシーの策定**：組織としてのAI利用に関する基本方針、倫理規定、安全性基準を明文化する。このポリシーは、個別プロダクトの設計判断の拠り所となる。 * **責任体制の明確化**：AIセーフティに関する最終責任者（経営層）、推進責任者、実務担当者の役割と責任を明確にする。 * **リソースの配分**：AIセーフティに関する人員、予算、時間を計画的に配分する。セーフティへの投資は、インシデント発生時の損失回避やブランド信頼の維持という観点からROIを整理し、経営層の理解を得る。 * **アジャイルガバナンスの採用**：技術環境や規制環境の変化に応じて、ポリシーや基準を柔軟かつ迅速に見直す仕組みを導入する。固定的なルールだけではなく、状況に応じた判断ができる体制を構築する。 #### 2. **AIプロダクト開発レベルのガバナンス** 個別のAIプロダクトの開発においては、セーフティを確保するためのチーム構成や開発プロセスの設計が重要となる。 * **多職種チームの編成**：AIエンジニアだけでなく、ドメインエキスパート（医療従事者等）、セキュリティ専門家、法務・コンプライアンス担当者、UXデザイナー等を含む多職種チームでプロダクト開発を行う。 * **外部専門家との連携**：社内に専門知識が不足する場合は、外部の医療専門家、弁護士、規制当局のアドバイザー等との連携体制を構築する。 * **レビュープロセスの設計**：AIセーフティに関するレビューを開発プロセスに組み込み、セーフティレビューを経ずにリリースが行われない仕組みを作る。 * **インシデント対応フローの整備**：安全性に関わる問題が発生した際のエスカレーションパス、報告体制、意思決定プロセスをあらかじめ定めておく。 ### 3. **リスクアセスメント** #### 1. **リスクの特定と分類** 開発するヘルスケアAIプロダクトのリスクを体系的に特定することが、セーフティ評価の出発点となる。生成AIには従来のソフトウェアとは異なるリスク特性があり、これらを漏れなく洗い出すことが重要である。 リスクの特定にあたっては、第3章で整理したAISIの10観点をフレームワークとして活用することで、網羅性を確保する。各評価観点に対して、どのようなリスクが想定されるかを体系的に洗い出す。これらのリスクは複数の評価観点にまたがることが多く、特に、「有害情報の出力制御」、「偽誤情報の出力・誘導の防止」、「プライバシー保護」、「セキュリティ確保」の観点から複合的に評価する。 | ▲ リスクの相互作用に注意 各評価観点のリスクは独立して存在するのではなく、相互に影響し合う。例えば、「データ品質」の問題は「偽誤情報の出力・誘導の防止」に直結し、「セキュリティ」の不備は「プライバシー保護」の侵害に直結する。リスクアセスメントでは、こうした観点間の影響も考慮することが重要である。 | | :---- | #### 2. **リスクの評価と優先順位付け** 特定したリスクについて、影響度と発生可能性の2軸で評価し、優先的に対処すべきリスクを特定する。ヘルスケア領域では、影響度の評価において「患者の安全に対する直接的な影響」を最重要視する。評価にあたっては、AISIの10観点それぞれについて、特定したリスクを以下のような基準で分類する。 表 4-5 リスクレベルの分類と対応方針の例 | リスクレベル | 影響度 | 発生可能性 | 対応方針 | | :---: | ----- | ----- | ----- | | **クリティカル** | 患者の生命・健康に直接影響 | 発生の蓋然性がある | 即座に対策を講じる。リリース前に解決必須 | | **高** | 健康被害の可能性がある | 発生の可能性が高い | 優先的に対策を講じる。緩和策を必ず実装 | | **中** | ユーザー体験や信頼性に影響 | 一定の条件下で発生 | 計画的に対策。モニタリングで監視 | | **低** | 影響が限定的 | 発生の可能性が低い | 認識した上で許容。定期見直し | リスクレベルの判定においては、以下の点に留意する。 * **患者の安全の最優先**：患者の生命・健康に直接影響するリスクは、発生可能性が低くても「クリティカル」または「高」として扱うことが望ましい。特に「有害情報の出力制御」「偽誤情報の出力・誘導の防止」「ハイリスク利用対処・目的外利用への対処」の観点におけるリスクが該当する。 * **複合的な影響の考慮**：単一のリスクが複数の評価観点にまたがる場合は、総合的な影響度を評価する。例えば、プライバシー侵害は「プライバシー保護」だけでなく「セキュリティ確保」「検証可能性」にも影響する。 * **配慮を要する患者層**：小児、高齢者、精神疾患患者などの配慮を要する患者層が利用対象に含まれる場合、「公平性と包摂性」「有害情報の出力制御」の観点から、リスクレベルを引き上げて評価する。 * **規制リスクの考慮**：「ハイリスク利用対処・目的外利用への対処」の観点から、SaMD該当性や個人情報保護法への抵触可能性など、法規制上のリスクも影響度の評価に含める。 #### 3. **リスクの洗い出し手法** リスクの網羅的な洗い出しのために、以下の手法を組み合わせて活用することが有効である。各手法が、AISIの10観点のどのリスクの発見に特に有効かも併せて示す。 表 4-6　リスク洗い出し手法と特に有効な評価観点 | 手法 | 概要 | 特に有効な評価観点 | | ----- | ----- | ----- | | **シナリオ分析** | 具体的な利用シナリオを設定し、各シナリオにおいてどのようなリスクが生じうるかを検討する。正常系・異常系・緊急系のシナリオを網羅的に設定する | 有害情報の出力制御、偽誤情報の出力・誘導の防止、ハイリスク利用対処・目的外利用への対処、ロバスト性 | | **AIレッドチーミング** | セキュリティやセーフティの専門家が攻撃者の視点でリスクを探索する。悪意ある利用シナリオの発見に有効である | セキュリティ確保、有害情報の出力制御、プライバシー保護 | | **ステークホルダーヒアリング** | 患者、医療専門家、医療従事者、介護者など、多様なステークホルダーからフィードバックを得て、開発者が見落としがちなリスクを洗い出す | 有害情報の出力制御、偽誤情報の出力・誘導の防止、公平性と包摂性、説明可能性、ハイリスク利用対処・目的外利用への対処 | | **法規制チェック** | 関連する法規制（医薬品医療機器等法、個人情報保護法、次世代医療基盤法等）への適合状況を確認し、抵触リスクを特定する | ハイリスク利用対処・目的外利用への対処、プライバシー保護、検証可能性 | これらの手法を組み合わせることで、AISIの10観点に対応するリスクを網羅的に洗い出すことができる。特にヘルスケア領域では、技術的観点（セキュリティ等）だけでなく、医療実務の観点（有害情報、偽誤情報、公平性等）からのリスク洗い出しが不可欠である。そのため、ステークホルダーヒアリングでは医療専門家の参加が特に重要である。 #### 4. **リスク登録簿の作成** 特定したリスクは、リスク登録簿として文書化し、開発プロセス全体を通じて管理する。リスク登録簿には以下の項目を含める。 * リスクの識別IDと概要 * 対応するAISI評価観点（複数可） * リスクレベル（発生可能性×影響度） * 緩和策とその実装フェーズ * 残留リスクの許容判断 * 担当者とレビュースケジュール リスク登録簿は、フェーズ3（プロダクト実装）での緩和策の実装、フェーズ4（プロダクト検証）での検証、フェーズ5（プロダクト導入・運用）でのモニタリングのそれぞれで参照されるリビングドキュメントとして継続的に更新する。とりわけ、新たなリスクが発見された場合や、リスクレベルの変更があった場合には速やかに更新する。 | ■ リスクアセスメントの実施体制 リスクアセスメントは、PM、エンジニア、医療専門家、法務・コンプライアンスなどの多様なステークホルダーが参加する形で実施することを推奨する。特に医療専門家の参加は、「有害情報の出力制御」「偽誤情報の出力・誘導の防止」「ハイリスク利用対処・目的外利用への対処」の観点において、開発者だけでは気づきにくいリスクを特定するために不可欠である。 | | :---- | ### 4. **法規制への対応** #### 1. **ヘルスケア領域における主要な法令・ガイドライン** ヘルスケア領域でAIプロダクトを開発する際には、多数の法令やガイドラインへの準拠が求められる。設計段階から、自社のAIプロダクトに適用される規制を正確に把握し、コンプライアンス要件を設計に反映させることが必要である。 主要な法令・ガイドラインには以下のものがある。 * 薬機法（医薬品医療機器等法）：AIプロダクトが「プログラム医療機器（SaMD）」に該当するか否かの判断が重要となる。該当する場合は、製造販売承認・認証の取得が必要となる。 * 医師法・医療法：AIによる行為が医行為に該当しないか、医療機関における利用において法的な問題がないかを確認する。 * 個人情報保護法：健康情報は多くの場合、要配慮個人情報に該当し、収集・利用・提供においてより厳格な取扱いが求められる。特に、LLMへの患者データの入力における同意取得やデータの取扱いに注意が必要である。 * 次世代医療基盤法：医療ビッグデータの利活用に関する法的枠組みを理解し、該当する場合は認定事業者との適切なデータ取得プロセスを経る。 * 3省２ガイドライン（厚生労働省「医療情報システムの安全管理に関するガイドライン」 経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」）：医療情報を取り扱うシステムにおける安全管理要件を確認し、プロダクトのアーキテクチャ設計に反映する。 #### 2. **法規制対応のポイント** 法規制への対応にあたっては、以下の点に留意する。 * **規制の該当性判断を早期に行う**：特に薬機法上のSaMD該当性は、プロダクトの開発方針やスケジュールに大きく影響するため、設計段階で確認する。 * **規制環境の変化を継続的にウォッチする**：AIに関する規制は国内外で急速に整備が進んでおり、欧州AI法や国内のAI事業者ガイドラインなどの動向も踏まえた対応が必要である。 * **法務・規制の専門家との連携**：法規制の解釈は専門的な判断が必要となる場合が多いため、法務部門や外部の規制専門家との連携体制を確保する。 ### 5. **設計段階から組み込むべき重要原則** プロダクト設計フェーズにおいては、以下の重要な設計原則を初期段階から組み込むことが不可欠である。これらは事後的に追加することが困難であり、設計段階から意識的に取り組むべきものである。 #### 1. **プライバシー・バイ・デザイン** ヘルスケアデータには、病歴、遺伝情報、精神疾患の記録など、極めてセンシティブな個人情報が含まれる。プライバシー・バイ・デザインとは、プライバシー保護をプロダクトの事後的な対策ではなく、設計の根幹に組み込むアプローチである。 * LLMへの入力データにおける個人情報の最小化 * 必要に応じた匿名化・仮名化処理の実装 * データの保存期間と削除ポリシーの設計 * 外部API利用時のデータ伝送経路とデータ保持ポリシーの確認（LLMプロバイダー側でのデータ利用条件の確認を含む） * ユーザーへのデータ取扱いに関する透明な説明と同意取得 #### 2. **セキュリティ・バイ・デザイン** セキュリティ・バイ・デザインとは、セキュリティ対策をプロダクトの設計段階から組み込むアプローチである。AIプロダクトにおいては、従来のWebアプリケーションのセキュリティに加え、AI固有の脅威にも対応する必要がある。 * プロンプトインジェクション対策（入力バリデーション、システムプロンプトの保護） * データ漏えい防止のアーキテクチャ設計（出力フィルタリング、アクセス制御） * 認証・認可の適切な実装（特に医療従事者向け機能へのアクセス管理） * ログ記録と監査証跡の設計 * サプライチェーンセキュリティ（APIプロバイダーのセキュリティ評価を含む） #### 3. **ヒューマン・イン・ザ・ループ** ヒューマン・イン・ザ・ループとは、AIの意思決定プロセスにおいて人間による確認・判断・介入を組み込む設計原則である。特にヘルスケア領域では、AIの出力が患者の健康に直接影響する可能性があるため、適切な人間の介在を設計に組み込むことが極めて重要である。 * 人間の介在レベルの設計：リスクの重大性に応じて、「人間が最終判断」「人間が監視・介入可能」「完全自動」のいずれが適切かを判断する。 * 介入ポイントの明確化：どのタイミングで、誰が、どのような判断を行うかを具体的に設計する。 * 介入を支援するUI/UXの設計：AIの出力に対する人間の確認・修正が容易に行えるインターフェースを設計する。「確認疲れ」を防ぎ、実効的な確認が行われるよう工夫する。 * フォールバック機構の設計：AIが適切に応答できない場合や、システム障害時に、人間の専門家にエスカレーションする仕組みを用意する。 #### 4. **透明性・説明可能性の設計** ヘルスケアAIプロダクトの設計においては、AIの出力に対する信頼を確保するために、透明性と説明可能性を組み込むことが重要である。 * AIが生成した応答であることの明示 * AIの出力の根拠や参照元の提示 * AIの限界や不確実性に関するユーザーへの適切な伝達 * 免責事項の適切な表示 * 利用規約におけるAIの役割と限界の明記 ### 6. **プロダクト設計フェーズのチェックリスト** 以下に、プロダクト設計フェーズにおいて確認すべき主要な事項をチェックリストとして整理する。ただし、このチェックリストの全項目が必須ではなく、自社のプロダクトのユースケースに応じて優先度を整理し、活用されたい。 表 4-7　プロダクト設計フェーズのチェックリスト | カテゴリ | 確認事項 | 関連する評価観点 | 対応状況 | | ----- | ----- | ----- | :---: | | **全体設計** | プロダクトの目的・対象ユーザー・ユースケースを明確に言語化しているか | 全観点横断 | □ | | **全体設計** | AIの役割の範囲と限界（やってはいけないこと）を定義しているか | ハイリスク利用・目的外利用への対処 | □ | | **全体設計** | 安全性指標と有用性指標を設定し、そのバランスを検討しているか | 全観点横断 | □ | | **全体設計** | ヒューマン・イン・ザ・ループを考慮して設計しているか | 全観点横断 | □ | | **リスク定義** | 有害情報のリスク類型（不正確な医療情報、自傷誘発、心理的依存の助長等）と許容基準を定義しているか | 有害情報の出力制御 | □ | | **リスク定義** | ハルシネーション・偽誤情報のリスク類型と許容基準を定義しているか | 偽誤情報の出力・誘導の防止 | □ | | **リスク定義** | 想定される入力の多様性（表記ゆれ、方言、OCR誤認識等）を洗い出し、出力一貫性の許容基準を定義しているか | ロバスト性 | □ | | **データ方針** | 取り扱うデータの種類を特定・分類し、法的要件を踏まえたデータ取扱い方針（収集最小化、保存期間、同意、削除等）を設計しているか | プライバシー保護 | □ | | **データ方針** | 学習データ・検証データ・RAG参照データのデータソース選定基準と品質要件を定義しているか | データ品質 | □ | | **セキュリティ方針** | LLM固有の脅威を含む脅威モデルを定義し、多層防御の方針を確立しているか | セキュリティ確保 | □ | | **設計原則** | プライバシー・バイ・デザインの原則を適用しているか | プライバシー保護 | □ | | **設計原則** | セキュリティ・バイ・デザインの原則を適用しているか | セキュリティ確保 | □ | | **設計原則** | 対象ユーザー別に必要な説明レベル（根拠提示、不確実性明示等）を定義しているか | 説明可能性 | □ | | **設計原則** | 対象ユーザーの多様性を考慮し、公平性要件を定義しているか | 公平性と包摂性 | □ | | **ガバナンス** | AI利用ポリシーの策定と責任体制・リソース配分を確立しているか | 全観点横断 | □ | | **ガバナンス** | 医療・セキュリティ・法務を含む多職種チームを編成しているか | 全観点横断 | □ | | **ガバナンス** | セーフティレビューを経ずにリリースが行われない仕組みを設計しているか | 全観点横断 | □ | | **法規制** | 適用される法令・ガイドライン（薬機法、医師法、個人情報保護法、3省2ガイドライン等）を特定し、対応要件を整理しているか | 全観点横断 | □ | | **法規制** | SaMD該当性の判断を行い、関連法令への対応方針を確立しているか | ハイリスク利用・目的外利用への対処 | □ | | **検証計画** | 事後検証に必要なログ要件と評価体制の計画を策定しているか | 検証可能性 | □ | | ■ 次のフェーズへ プロダクト設計フェーズで整理したユースケース、リスク評価、法規制要件、設計原則は、続く「フェーズ2：モデル選定」において、モデルに求める要件を具体化するための基盤となる。設計段階での検討が十分であるほど、以降のフェーズでの判断が明確かつ迅速になる。 | | :---- | ## 3. **フェーズ2 モデル選定** モデル選定フェーズでは、フェーズ1で定義したプロダクトの目的やユースケース、リスク評価、法規制要件を踏まえ、最適な基盤モデル（LLM）を選定する。モデルの選定は、プロダクトの品質と安全性の両方に直接的な影響を与える重要な意思決定である。 現在、多数のLLMプロバイダーが存在し、各モデルは性能、安全性対策、コスト、データ取扱いポリシー等においてそれぞれ異なる特性を持つ。ヘルスケア領域では、汎用的な性能ベンチマークだけでなく、安全性、データの取扱い、法規制遵守の観点からも総合的に評価して、プロダクトの目的に適合するモデルを選定する必要がある。 ### 1. **プロダクトの目的に即したモデルの選定** #### 1. **性能観点での評価** モデル選定において最初に検討すべきは、プロダクトのユースケースを達成できる基本的な性能を有しているかどうかである。汎用的なベンチマークを参照しつつ、自社のユースケースに即した評価を行うことが重要である。 汎用ベンチマークとしては、以下のようなものが参考になる。 * **総合性能**：MMLU、GPQA、ARC等の知識・推論能力を測るベンチマーク * **医療領域性能**：MedQA、PubMedQA、USMLE等の医療知識に特化したベンチマーク * **日本語性能**：JGLUE、Japanese MT-Bench等の日本語における性能評価。ヘルスケア領域では日本語での対応が求められるケースが多く、日本語の品質は重要な評価観点となる * **日本の医療領域性能**：JMedBench、JMED-LLM等の日本の医療知識に特化したベンチマーク ただし、汎用ベンチマークのスコアだけでモデルを選定することは避けることが望ましい。ベンチマークは特定のタスクにおける性能を測るものであり、自社の具体的なユースケースにおける性能を保証するものではない。必ず自社のユースケースに基づく評価も併せて行うことが必要である。 #### 2. **コスト観点での評価** モデルの利用コストは、プロダクトの事業性に直結する重要な要素である。以下の観点でコストを評価する。 * **API利用料金**：入力トークンあたりの料金、出力トークンあたりの料金、結果のキャッシュ機能の有無等を確認する。想定される利用量に基づき、月額コストを試算する。 * **スケーラビリティ**：利用量の増加に対するコストの変動、レートリミット（APIの呼び出し制限）の有無と条件、ボリュームディスカウントの有無を確認する。 * **レイテンシ**：応答速度がプロダクトのユーザー体験要件を満たすか。特にリアルタイム性が求められるユースケースでは、モデルの応答時間は重要な選定基準となる。 * **コストと性能のバランス**：必ずしも最高性能のモデルが必要とは限らない。ユースケースによっては、小規模モデルで十分な性能が得られる場合もある。プロダクトの要件に応じて、適切なコストパフォーマンスのバランスを見極める。 #### 3. **操作性・利便性の評価** 実際のプロダクト開発・運用においては、モデルの操作性や利便性も重要な選定基準となる。 * **APIの充実度**：SDKの提供状況、ドキュメントの充実度、サンプルコードの有無、プレイグラウンド環境の提供 * **機能の柔軟性**：システムプロンプトのカスタマイズ性、ファインチューニングの可否、出力形式の制御機能（JSONモード等）、Function Calling機能の有無 * **サポート体制**：プロバイダーのサポート窓口の充実度、SLA（サービスレベル合意）の内容、障害時の対応体制 * **エコシステム**：サードパーティ製ツールやプラグインの充実度、コミュニティの活性度 ### 2. **安全性観点でのモデル評価** #### 1. **モデルカード・システムカードの精査** モデルカードやシステムカードは、モデルプロバイダーが公開するモデルの仕様書であり、安全性評価の基礎となる重要な情報源である。以下の項目について、文書ベースのレビューを実施する。 表 4-8 モデルカード・システムカードの確認項目 | 確認項目 | 確認内容 | 重要度 | | ----- | ----- | :---: | | **入力データの保存・利用ポリシー** | 入力データがモデルの追加学習に使用されるか、データの保持期間、削除リクエストの可否 | 最高 | | **学習データの構成と品質管理** | 学習データのソース、データクリーニングの方法、バイアス排除の取組が説明されているか | 高 | | **安全性テストの実施状況** | どのような安全性テスト（レッドチーミング、バイアス評価等）が実施され、その結果が公開されているか | 高 | | **出力制御メカニズム** | 有害コンテンツのフィルタリング、コンテンツポリシー、ガードレール機能の有無とカスタマイズ性 | 高 | | **モデル更新ポリシー** | モデルのバージョン管理方針、更新の予告ポリシー、後方互換性の保証の有無 | 高 | | **既知の制限事項・リスク** | プロバイダーが認識しているモデルの限界、推奨しない用途、既知のバイアス等が開示されているか | 中 | | **第三者評価・監査** | 外部機関による安全性評価や監査の実施状況、その結果の公開状況 | 中 | #### 2. **安全性ベンチマークによる評価** モデルカードの文書レビューに加え、安全性に特化したベンチマークの結果も参照する。以下のような安全性ベンチマークが参考になる。 * **ハルシネーション評価**：事実と異なる情報を生成する傾向の評価。TruthfulQA等のベンチマークが参考になる * **バイアス評価**：特定の属性（性別、年齢、人種等）に対する偏りの評価。BBQ、WinoBias等 * **有害コンテンツ生成評価**：有害な情報や不適切なコンテンツの生成傾向の評価。特にヘルスケア文脈での危険な助言生成のリスク。日本語の出力の安全性・適切性に関しては、AnswerCarefully Dataset等がある。 * **ロバストネス評価**：プロンプトインジェクションやジェイルブレイクに対する耐性の評価 これらのベンチマーク結果は、モデルプロバイダーが公開している場合もあれば、第三者機関による独立評価結果を参照することも有用である。 #### 3. **プロバイダーの信頼性評価** モデル単体の性能だけでなく、モデルを提供するプロバイダーの信頼性も重要な評価観点である。 * **組織の安全性への取組**：プロバイダーが安全性に対してどの程度のリソースを投入しているか、安全性に関する研究開発体制は構築されているか * **インシデント対応の実績**：過去にセキュリティインシデントやデータ漏えいが発生した際の対応状況、情報開示の姿勢 * **透明性への取組**：モデルの限界やリスクについて誠実に情報開示しているか、事前通知なくモデルを変更するようなことがないか * **事業継続性**：プロバイダーの財務基盤、事業継続計画。特定のプロバイダーに依存するリスク（ベンダーロックイン）も考慮する ### 3. **データの取扱いに関する評価** ヘルスケア領域では、患者の健康情報などのセンシティブデータを扱うことが多く、プロバイダーによるデータの取扱いは最も慎重に評価すべき重要な項目の一つである。 #### 1. **入力データの学習利用** LLMのAPIを利用する際、入力されたデータがモデルの追加学習（ファインチューニングや強化学習等）に使用されるか否かを確認する。 * **デフォルト設定の確認**：プロバイダーによっては、デフォルトで入力データをモデル改善に利用する設定となっている場合がある。オプトアウトの可否とその手続きを確認する。 * **API利用規約の確認**：利用規約やデータ処理規約（DPA）において、入力データの利用範囲が明確に規定されているかを確認する。 * **エンタープライズプランの検討**：ヘルスケアデータを扱う場合、エンタープライズ向けプランでは入力データの学習利用が明示的に除外されていることが多く、こうしたプランの採用も検討する。 #### 2. **データの処理・保存場所** データの処理・保存が行われる場所（リージョン）について、法規制遵守の観点から確認する。 * **データ処理のリージョン**：APIに送信されたデータがどの国・地域のサーバーで処理されるかを確認する。 * **データ保存のリージョン**：ログデータやキャッシュデータを含む、入出力データが保存される地域を確認する。 * **データの保持期間**：入出力データがプロバイダー側でどの程度の期間保持されるか、削除リクエストは可能かを確認する。不正利用監視の観点で、一定期間のデータをプロバイダーが保持している場合が多い。 | ▲ ヘルスケア特有の注意点：データ保存場所について 3省２ガイドラインの対象となるサービスでは、医療情報の保存場所が日本国内であることが必須とされている。LLMのAPI利用においても、入力データが海外のサーバーで保存される場合、この要件を満たさない可能性がある。プロバイダーが日本国内にデータ保存拠点を有しているかを確認することが重要である。ただし、データ処理に関しては、特定の条件のもとでは国内法の適用を受けていないサーバーも利用可能であることが、「医療情報システムの安全管理に関するガイドライン 第6.0版」に関するＱ＆Ａで記載されている。 | | :---- | #### 3. **データの暗号化と転送セキュリティ** データの取扱いにおいては、暗号化と転送セキュリティについても確認する。 * **転送時の暗号化**：TLS/SSLによる通信経路の暗号化が確保されているか * **保存時の暗号化**：プロバイダー側でデータが保存される際の暗号化方式と鍵管理の方法 * **アクセス制御**：プロバイダーの従業員が入力データにアクセスできる範囲と条件 ### 4. **ライセンス・契約の確認** #### 1. **ライセンス形態の確認** モデルの利用にあたっては、ライセンス形態を正確に把握し、自社の利用目的に合致しているかを確認する必要がある。 * **商用利用の可否**：モデルのライセンスが商用利用を許可しているか。オープンソースモデルの場合、ライセンスによって商用利用に制限がある場合がある（例：一定規模以上の企業は別途ライセンスが必要等）。 * **医療用途の制限**：一部のモデルでは、利用規約において医療目的での使用を制限または免責している場合がある。ヘルスケア用途における利用が明示的に許可されているかを確認する。 * **オープンソースモデルのライセンス種別**：Apache 2.0、MIT、Llama License等、ライセンスの種類によって利用条件が異なる。特に、派生物の作成や再配布に関する条件を確認する。 #### 2. **契約条件の確認** APIプロバイダーとの契約において、以下の条件を確認する。 * **利用規約**：サービスの利用条件、禁止事項、免責事項を確認する。特に医療用途に関する記載に注意する。 * **データ処理契約**（DPA）：データの取扱いに関する契約が締結可能か。特に健康データを扱う場合、DPAの締結は必須となることが多い。 * **SLA**（サービスレベル合意）：可用性、パフォーマンス保証、障害時の対応時間等の内容。医療現場で利用する場合、高い可用性が求められる。 * **賠償責任**：モデルの出力に起因する損害が発生した場合の責任分界。多くのプロバイダーは出力の正確性を保証しておらず、ユーザー側の責任となる点を認識する。 * **契約変更の通知**：利用規約やデータポリシーの変更がある場合の事前通知の有無とその方法を確認する。 #### 3. **知的財産権の確認** モデルの出力に関する知的財産権の帰属も確認すべき事項である。 * **出力の権利帰属**：AIが生成したコンテンツの著作権や知的財産権の帰属について、利用規約上どのように定められているか。 * **第三者の知的財産権侵害リスク**：モデルの出力が第三者の著作権や特許を侵害するリスクについて、プロバイダーがどのような補償や保護を提供しているか。 ### 5. **モデル選定の戦略的考慮事項** #### 1. **マルチモデル戦略** 単一のモデルに依存するのではなく、複数のモデルを併用する戦略も検討に値する。これにより、AIプロダクト全体として一定の安全性と品質を維持することができる。 * ユースケース別のモデル使い分け：リスクの高いタスクには安全性の高いモデルを、一般的なタスクにはコスト効率の良いモデルを割り当てる。 * フォールバックモデルの確保：主要モデルに障害が発生した場合の代替モデルを確保し、サービスの継続性を担保する。 * クロスバリデーション：複数のモデルの出力を照合し、整合性を確認することで、ハルシネーションのリスクを低減するアプローチもある。 #### 2. **モデル切り替えの柔軟性** 生成AIの進化は急速であり、より高性能・高安全性のモデルが継続的に登場する。そのため、モデルの切り替えが容易なアーキテクチャを採用することが重要である。 * 抽象化レイヤーの設計：モデル固有のAPIに直接依存せず、抽象化レイヤーを設けることで、モデルの切り替えを容易にする。 * 評価パイプラインの整備：新しいモデルが登場した際に、迅速に自社のユースケースで評価できるパイプラインを整備しておく。 ### 6. **モデル選定フェーズのチェックリスト** 以下に、モデル選定フェーズにおいて確認すべき主要な事項をチェックリストとして整理する。 表 4-9　モデル選定フェーズのチェックリスト | カテゴリ | 確認事項 | 関連する評価観点 | 対応状況 | | ----- | ----- | ----- | :---: | | **性能評価** | 汎用ベンチマークおよびヘルスケア領域ベンチマークでモデル性能を評価したか | 全観点横断 | □ | | **性能評価** | 自社ユースケースに基づく性能評価を実施したか | 全観点横断 | □ | | **安全性評価** | 事実整合性ベンチマークでハルシネーション傾向を評価したか | 偽誤情報の出力・誘導の防止 | □ | | **安全性評価** | モデルが知識の境界で「回答不能」と出力する能力を確認したか | 偽誤情報の出力・誘導の防止 | □ | | **安全性評価** | 日本語（方言、平易な表現、高齢者の語彙等を含む）の対応品質を確認したか | 公平性と包摂性 | □ | | **安全性評価** | 多様な入力パターン（表記ゆれ、略語、ノイズ等）での出力安定性を評価したか | ロバスト性 | □ | | **安全性評価** | 出典付き回答生成能力、構造化出力やFunction Callingの対応を確認したか | 説明可能性 | □ | | **安全性評価** | 安全性ベンチマーク（有害コンテンツ生成率等）を確認し、出力制御機能を評価したか | 有害情報の出力制御 | □ | | **安全性評価** | バイアス評価ベンチマークで特定属性への偏りが許容範囲内か確認したか | 公平性と包摂性 | □ | | **安全性評価** | ジェイルブレイク・プロンプトインジェクション耐性を確認したか | セキュリティ確保 | □ | | **安全性評価** | モデルカード・システムカードで既知の制限事項・リスクが開示されているか確認したか | 検証可能性 | □ | | **データ取扱い評価** | 入力データの学習利用ポリシー（オプトアウト可否）、処理・保存場所、保持期間・削除可否を確認したか | プライバシー保護 | □ | | **データ取扱い評価** | 3省2ガイドライン対象の場合、国内データ保存要件を満たすか確認したか | プライバシー保護 | □ | | **データ取扱い評価** | プロバイダーのセキュリティ体制（暗号化、アクセス制御、第三者監査、インシデント対応実績）を評価したか | セキュリティ確保 | □ | | **データ取扱い評価** | 学習データの構成、品質管理プロセス、バイアス排除の取組をモデルカードで確認したか | データ品質 | □ | | **契約・ライセンス** | 商用利用および医療用途の利用が許可されていることを確認したか | ハイリスク利用・目的外利用への対処 | □ | | **契約・ライセンス** | 必要に応じてデータ処理契約（DPA）を締結したか | プライバシー保護 | □ | | **契約・ライセンス** | SLAの内容（可用性、パフォーマンス保証、障害時対応）がプロダクト要件を満たすか確認したか | 全観点横断 | □ | | **契約・ライセンス** | 出力の知的財産権帰属、第三者の知的財産権侵害リスクへの補償条件を確認したか | 全観点横断 | □ | | **モデル選定方針** | フォールバックモデルの確保、マルチモデル戦略を検討したか | 全観点横断 | □ | | **モデル選定方針** | モデル切替えが容易なアーキテクチャと評価パイプラインの整備を検討したか | 全観点横断 | □ | | **モデル選定方針** | 想定利用量に基づくAPI利用コストを試算し、レイテンシ要件を満たすか確認したか | 全観点横断 | □ | | **モデル選定方針** | バージョン管理方針、モデル更新の事前通知ポリシーを確認したか | 検証可能性 | □ | | ■ 次のフェーズへ モデル選定フェーズで決定したモデルとその特性・制約条件は、続く「フェーズ3：プロダクト実装」において、システムアーキテクチャやプロンプト設計、ガードレール実装の具体的な方針を定めるための基盤となる。モデルの特性を十分に理解した上で、次のフェーズに進むことが重要である。 | | :---- | ## 4. **フェーズ3 プロダクト実装** プロダクト実装フェーズでは、フェーズ1で設計したプロダクトの目的と、フェーズ2で選定したモデルの特性を踏まえ、実際のプロダクトを実装する。本フェーズの主目的は、ユーザーに価値を提供するプロダクトの機能実装であるが、同時に安全性の実装も開発プロセスに組み込んでいくことが重要である。 ### 1. **プロダクトアーキテクチャと安全性対策の全体像** LLMを活用したヘルスケア領域におけるAIプロダクトは、一般的に以下のようなアーキテクチャで構成されることが多い。 図 4-1　ヘルスケア領域におけるAIプロダクトの一般的なアーキテクチャ（例） 安全性対策の実装においては、LLM単体で完結させるのではなく、入力層や出力層、データベース層(RAG)、UI/UX層、セキュリティ層など多層的に実装することが重要である。ある層の対策が突破された場合でも、別の層で捕捉できるような深層防御のアプローチを採用することが望ましい。下記の表に各層の概要を説明する。 表 4-10　AIプロダクトの各層における安全性対策 | レイヤー | 概要 | 安全性対策のポイント | | ----- | ----- | ----- | | **入力層** | ユーザーからの入力を受け付け、モデルに渡す前の処理を行う | 入力フィルタリング、プロンプトインジェクション対策、個人情報マスキング | | **モデル層** | LLMによる推論処理を行う | システムプロンプト設計、パラメータ設定、構造化出力 | | **出力層** | モデルの出力を加工し、ユーザーに提示する | 出力フィルタリング、ガードレール、引用元明示 | | **データベース（RAG）** | 外部データを検索し、モデルの応答精度を向上させる | 検索性能の向上、データ品質管理、アクセス権限制御 | | **UI/UX層** | ユーザーとのインターフェースを提供する | 安全性を高めるUI設計、免責、利用規約 | | **セキュリティ層** | システム全体のセキュリティを確保する | ログ整備、トレーサビリティ、権限管理 | ### 2. **入力層の安全性対策** #### 1. **入力データのフィルタリング** ユーザーからの入力が危険なものであったり、プロダクトの目的外のものであったりする場合は、LLMに入力する前の段階で検知・ブロックする必要がある。 * 目的外入力の検知：プロダクトのユースケースに関係のない入力（例：健康相談ツールに対する投資相談の入力等）を検知し、適切なメッセージとともに拒否する仕組みを設ける。キーワードベースのフィルタや、分類モデルによる判定が有効である。 * 危険な入力の検知：自傷行為や自殺念慮、他者への危害に関する入力を検知した場合に、専門的な相談窓口への誘導や、緊急通報のフローを実装する。ヘルスケア領域では特に重要な対応である。 * 入力長の制限：過度に長い入力は、プロンプトインジェクションの手段として悪用される可能性があるため、適切な入力長の上限を設定する。 #### 2. **プロンプトインジェクション対策** プロンプトインジェクションとは、悪意あるユーザーが入力を通じてシステムプロンプトを上書きしたり、意図しない動作を引き起こしたりする攻撃である。以下の対策を組み合わせて実装する。 * システムプロンプトとユーザー入力の分離：システムプロンプトとユーザー入力を明確に区分し、ユーザー入力がシステムプロンプトとして解釈されないようにする。 * インジェクションパターンの検知：既知のインジェクションパターン（「以前の指示を無視して」「システムプロンプトを表示して」等）を検知するフィルタを実装する。 * 別のLLMによる入力判定：メインのLLMとは別の軽量なモデルや分類器を用いて、入力の安全性を事前に判定する手法も有効である。 #### 3. **個人情報のマスキング** ヘルスケア領域では、ユーザーが入力する情報に患者名、生年月日、病名等の個人識別性が高い記載が含まれ要配慮個人情報に該当する可能性も高い。このような情報をLLMに入力する場合は、LLMのデータ取扱いポリシー等を確認し、必要に応じて下記のようなマスキング処理を実装することが求められる。 * 自動マスキング機能：氏名、生年月日、電話番号、住所等の特定の個人の識別につながる情報を自動的に検知し、LLMに送信する前にマスキングまたは仮名化する。 * マスキング後の復元：必要に応じて、出力時にマスクされた情報を復元する仕組みを実装する。ただし、復元処理自体のセキュリティも確保する。 * マスキングの範囲設計：プロダクトのユースケースに応じて、どの範囲の情報をマスキング対象とするかを定義する。ヘルスケア領域では、健康情報（病名、薬剤名、検査結果等）は要配慮個人情報に多くの場合該当し、広範なマスキングが必要となることがある。 ### 3. **モデル層の安全性対策** #### 1. **システムプロンプト設計** システムプロンプトは、LLMの動作を制御する最も重要な手段の一つである。安全性の観点から、以下の要素をシステムプロンプトに組み込む。 * **役割と制約の明確化**：AIが担う役割と、やってはいけないことを明確に指示する。 例：「あなたはユーザーの健康に関する参考情報を提供するアシスタントです。診断、処方、治療方針の決定は行わないでください」 * **禁止事項の明示**：回答してはならないトピックやケースを具体的に列挙する。 例：緊急性の高い症状への対応、具体的な薬剤の用量指示、精神科的な診断など * **不確実な場合の対応指示**：情報が不確実な場合や判断が難しい場合に、「医療専門家に相談してください」といったエスカレーションパスを指示する。 * **回答スタイルの制御**：断定的な表現を避け、エビデンスに基づいた回答をするよう指示する。出典の明示や、回答の確度に関する注意書きを付けるよう指示することも有効である。 #### 2. **モデルパラメータの最適化** モデルのパラメータ設定によって、出力の安全性を一定程度制御できる。 * **Temperatureの設定**：Temperatureを低く設定することで、出力のランダム性を低減し、予測可能性を高める。ヘルスケア領域では、事実に基づく正確な回答が求められるケースが多いため、低いTemperatureの設定が推奨されることが多い。 * **Top-p / Top-k**の設定：サンプリング手法のパラメータを調整することで、生成されるトークンの多様性を制御する。 * **最大トークン数の制限**：出力の最大トークン数を適切に制限し、不必要に長い回答や不安定な出力を防ぎ、コストの制御にも寄与する。 #### 3. **構造化出力による出力範囲の制限** 構造化出力を活用することで、モデルの出力を予測可能な形式に制限し、安全性を高めることができる。 * **JSONモードの活用**：JSONスキーマを定義し、出力を特定のフィールドに限定することで、意図しない情報の漏えいや不適切なコンテンツの生成を抑制する。 * **Function Callingの活用**：モデルの出力を事前に定義した関数呼び出しに限定することで、出力の範囲を制御する。 * **列挙型（Enum）による制限**：回答の選択肢を予め定義した値に制限することで、想定外の出力を防止する。 ### 4. **出力層の安全性対策** #### 1. **出力フィルタリング** モデルの出力をユーザーに提示する前に、不適切なコンテンツを検知・ブロックするフィルタリングを実装する。 * 危険なコンテンツの検知：医療的に危険な助言、自己診断を促す内容、緊急時に不適切な対応を示唆する内容等を検知し、ブロックまたは修正する。 * 個人情報の漏えい検知：モデルの出力に意図せず個人情報が含まれていないかをチェックする。 * ハルシネーション検知：出力が事実に基づいているかを検証する仕組み。RAGの参照元と出力の整合性チェックや、確信度スコアの付与などが有効である。 #### 2. **ガードレールの実装** ガードレールは、モデルの出力が安全基準を満たしているかを判定し、基準を満たさない場合に代替アクションを取る仕組みである。以下のアプローチを組み合わせて実装する。 表 4-11 ガードレールの実装アプローチ | アプローチ | 概要 | 特徴 | | ----- | ----- | ----- | | **ルールベース** | 事前に定義したルールに基づいて出力を判定する（キーワードマッチ、正規表現、ブラックリスト等） | 高速、低コスト、透明性が高いが、柔軟性に限界がある | | **LLMベース** | 別のLLMを用いて出力の安全性を判定する | 柔軟な判定が可能だが、レイテンシとコストが増加する | | **ハイブリッド** | ルールベースで一次フィルタ後、判断が難しいケースをLLMで判定 | 速度と柔軟性のバランスが取れる | ガードレールで不適切と判定された場合の代替アクションとしては、定型の安全なメッセージでの置き換え、再生成の試行、人間の専門家へのエスカレーションなどが考えられる。 ### 5. **データベース・RAGの安全性対策** #### 1. **検索性能の向上** RAGの性能は、プロダクトの安全性に直接影響する。不適切な情報が検索されると、モデルが誤った情報を生成するリスクが高まる。検索エンジンの実装方法には、ベクトル検索やキーワード検索などがあり、それらの長所と短所を把握した上で、ユースケースに応じて適切な方法を選択することが重要である。検索性能の向上には、下記のような事項がある。 * **チャンク分割の最適化**：ドキュメントのチャンク分割方法を最適化し、意味的に一貫性のあるチャンクを生成する。医療文書では、セクション単位や質問回答単位での分割が有効な場合がある。 * **エンベディングモデルの選定**：医療用語や日本語に対応したエンベディングモデルを選定し、検索精度を高める。 * **リランキング**：検索結果のリランキングを行い、より関連性の高い情報を優先的にモデルに提供する。 * **検索結果の閾値設定**：類似度の閾値を設定し、関連性の低い情報がモデルに渡らないようにする。無関係な情報の混入はハルシネーションの原因となる。 #### 2. **データ品質の管理** RAGに使用するデータの品質を維持・向上させるための仕組みを整備する。 * **データの精査とキュレーション**：データベースに登録するデータの品質を事前に検証するプロセスを設ける。医療情報では、内容の正確性、最新性、エビデンスレベルの確認が重要である。 * **定期的なデータ更新**：医療ガイドラインの改訂、新しいエビデンスの登場等に対応して、データベースを定期的に更新するプロセスを確立する。 * **古いデータの管理**：古いガイドラインや改訂前の情報が検索されないよう、バージョン管理やアーカイブの仕組みを設ける。 * **データソースの明確化**：各データの出典、更新日時、信頼性レベル等のメタデータを付与し、出力時の引用元表示に活用する。 #### 3. **アクセス権限制御** RAGのデータベースには、ユーザーによってアクセスしてよい情報とそうでない情報が混在する場合がある。特にヘルスケア領域では、患者情報の閲覧権限管理は極めて重要である。 * **ユーザー別のアクセス制御**：RAGの検索時に、ユーザーの権限に応じたデータのみを検索対象とする仕組みを実装する。閲覧権限のない情報が検索結果に含まれないように、フィルタリングを行う。 * **ロールベースドアクセス制御（RBAC）**：ユーザーの役割（医師、看護師、一般ユーザー等）に応じて、アクセス可能なデータ範囲を制御する。 * **監査ログ**：誰がどのデータにアクセスしたかのログを記録し、不正アクセスの検知に活用する。 | ▲ ヘルスケア特有の注意点：RAGの権限管理 医療情報システムでは、患者情報へのアクセス権限管理が重要である。LLMとRAGを組み合わせたシステムでは、意図せず閲覧権限のない情報が検索結果に含まれるリスクがある。検索時のフィルタリングだけでなく、出力時のチェックも含めた多層的なアクセス制御を実装すること。 | | :---- | ### 6. **UI・UXにおける安全性設計** #### 1. **安全性を高めるUI/UXの工夫** ユーザーインターフェースの設計は、ユーザーの安全な利用を促進する重要な要素である。 * **AI生成であることの明示**：回答がAIによる生成であることをユーザーに明確に伝える。「AIが生成した回答です」等のラベルを常に表示する。 * **確信度の可視化**：回答の確信度や信頼性の指標をユーザーに視覚的に伝える。「この情報は参考情報です」といった注意書きを付ける。 * **専門家への誘導**：必要に応じて医療専門家への相談を促す導線をUI上に設ける。緊急性の高い場合には、目立つ位置に緊急通報先を表示する。 * **フィードバック機構**：ユーザーが回答の品質を評価できる仕組み（「役に立った」「役に立たなかった」「危険な内容」等）を設け、プロダクトの改善に活用する。 #### 2. **根拠の可視化** 回答の根拠を可視化することで、ユーザーが自身でその回答の信頼性を確認可能となる。 * **参照元の表示**：RAGで参照したドキュメントやデータソースを、回答と共に表示する。クリックで原文を確認できるリンクを提供することが望ましい。 * **情報の新鮮度の明示**：参照した情報の作成日・更新日を表示し、ユーザーが情報の新鮮度を判断できるようにする。 * **回答の限界の明示**：参照データが見つからなかった場合や、情報が不十分な場合に、その旨を明確にユーザーに伝える。 #### 3. **免責・利用規約の明示** AIプロダクトの利用範囲と免責事項を明確にし、ユーザーに適切に伝える。 * **利用範囲の明記**：AIプロダクトが提供する情報の性質（参考情報であり、医学的助言ではない等）を明確にする。利用規約だけでなく、UI上でも適切なタイミングでユーザーに伝える。 * **免責事項の明示**：対象外の利用に対する免責を明確にする。 例：「本サービスは医療行為ではありません。具体的な症状や治療については医療専門家にご相談ください」 * **利用規約への同意**：サービス利用開始時に、利用規約への同意を得るフローを実装する。AIの特性や限界について、ユーザーが理解した上で利用を開始できるようにする。 ### 7. **セキュリティ対策** #### 1. **ログ整備・トレーサビリティの確保** ヘルスケア領域におけるAIプロダクトでは、全ての操作を追跡可能な状態に保つことが重要である。 * **入出力ログの記録**：ユーザーの入力とモデルの出力をペアで記録する。問題発生時の原因究明や、プロダクト改善のための分析に活用する。ただし、ログに個人情報が含まれる場合の取扱いにも注意が必要である。 * **RAG検索ログ**：どのデータが検索され、モデルに提供されたかを記録する。出力の根拠を後から検証するために重要である。 * **エラー・異常ログ**：ガードレールによるブロック、エラー発生、タイムアウト等の異常イベントを記録する。 * **ログの保持期間と保護**：法規制要件に応じたログの保持期間を設定し、ログ自体の改ざん防止やアクセス制御も実装する。 #### 2. **権限管理** プロダクト全体の権限管理を適切に設計する。 * **ユーザー認証・認可**：適切な認証方式（多要素認証等）を実装し、ユーザーの本人確認を確実に行う。医療情報を扱う場合、特に強固な認証が重要である。また、認可においては、ユーザーの役割や権限に基づきアクセス可能な情報や操作範囲を適切に制御することで、必要最小限の権限のみを付与する原則（最小権限の原則）を徹底する。 * **APIキーの管理**：LLM APIのキーを安全に管理する。環境変数やシークレットマネージャーを使用し、ソースコードへのハードコードを避ける。 * **最小権限の原則**：各コンポーネントが必要最低限の権限のみを持つように設計する。 #### 3. **その他のセキュリティ対策** * **レートリミット**：APIの呼び出し回数やユーザーあたりの利用量を制限し、不正利用やサービス拒否（DoS）攻撃を防止する。 * **通信の暗号化**：ユーザーとサーバー間、サーバーとLLM API間の全ての通信をTLSで暗号化する。 * **脆弱性管理**：使用するライブラリやフレームワークの脆弱性情報を定期的に確認し、アップデートを行う。 * **不正利用のモニタリング**：異常な利用パターン（大量のリクエスト、繰り返しの攻撃的入力等）を検知する仕組みを実装する。 ### 8. **プロダクト実装フェーズのチェックリスト** 以下に、プロダクト実装フェーズにおいて確認すべき主要な事項をチェックリストとして整理する。 表 4-12　プロダクト実装フェーズのチェックリスト | カテゴリ | 確認事項 | 関連する評価観点 | 対応状況 | | ----- | ----- | ----- | :---: | | **入力層** | 危険な入力（自傷念慮、他者への危害等）を検知し、専門相談窓口への誘導フローを実装したか | 有害情報の出力制御 ハイリスク利用・目的外利用への対処 | □ | | **入力層** | 目的外入力の検知・拒否の仕組みを実装したか | ハイリスク利用・目的外利用への対処 | □ | | **入力層** | プロンプトインジェクション防御を実装したか | セキュリティ確保 | □ | | **入力層** | 入力長の制限を設定したか | セキュリティ確保 | □ | | **入力層** | 個人情報（氏名、生年月日、病名等）の自動マスキング・仮名化機能を実装したか | プライバシー保護 | □ | | **入力層** | 入力の正規化処理（表記統一、ノイズ除去等）を実装したか | ロバスト性 | □ | | **入力層** | 想定外の入力（分布外データ、未対応フォーマット等）に対するエラー処理を実装したか | ロバスト性 | □ | | **モデル層** | システムプロンプトにAIの役割・禁止事項（断定的診断の禁止等）を明確に定義したか | 有害情報の出力制御 | □ | | **モデル層** | エビデンスに基づく回答生成（断定回避、出典明示）をシステムプロンプトで指示しているか | 偽誤情報の出力・誘導の防止 | □ | | **モデル層** | Temperature等のパラメータを最適化し、事実正確性を重視した設定としているか | 偽誤情報の出力・誘導の防止 | □ | | **モデル層** | ハイリスクな質問に対する拒否・免責機能（受診勧奨等）を実装したか | ハイリスク利用・目的外利用への対処 | □ | | **モデル層** | 専門外領域で過度に確信的な回答を抑制する制御を実装したか | ハイリスク利用・目的外利用への対処 | □ | | **モデル層** | 欠損・矛盾した入力に対して無理に結論を出さず、追加情報を求めるハンドリングを実装したか | ロバスト性 | □ | | **出力層** | 有害コンテンツ（危険な医療助言、感情操作的表現等）を検知・ブロックするフィルタリング・ガードレールを実装したか | 有害情報の出力制御 | □ | | **出力層** | 高リスク文脈での安全優先モードへの動的切替（通常応答→緊急対応誘導）を実装したか | 有害情報の出力制御 | □ | | **出力層** | ハルシネーション検知（RAG参照元と出力の整合性チェック等）を実装したか | 偽誤情報の出力・誘導の防止 | □ | | **出力層** | 参照情報がない場合に「回答不能」「追加情報が必要」と出力する制御を実装したか | 偽誤情報の出力・誘導の防止 | □ | | **出力層** | 悪意ある誘導プロンプト（医療デマ生成要求等）を拒否するガードレールを実装したか | 偽誤情報の出力・誘導の防止 | □ | | **出力層** | 出力に個人情報が含まれていないかを検知するフィルタリングを実装したか | プライバシー保護 | □ | | **出力層** | 再同定につながる属性情報の組合せ出力抑制、センシティブ情報の断定的推論防止を実装したか | プライバシー保護 | □ | | **出力層** | プロンプトリーキングによるシステムプロンプトやRAG内部情報の漏えい防止を実装したか | セキュリティ確保 | □ | | **出力層** | 属性に基づくステレオタイプ的出力を抑制するガードレールを実装したか | 公平性と包摂性 | □ | | **出力層** | 主要な主張ごとにRAG参照元の表示、引用番号付け等の根拠提示機能を実装したか | 説明可能性 | □ | | **出力層** | 根拠が弱い場合に「不明」「追加情報が必要」と表明する制御を実装したか | 説明可能性 | □ | | **RAG** | RAGデータの精査・キュレーションプロセス（医学的正確性、最新性、エビデンスレベル確認）を確立したか | データ品質 | □ | | **RAG** | データのバージョン管理、メタデータ付与（出典、更新日時、信頼性レベル等）、古い情報のアーカイブを実装したか | データ品質 | □ | | **RAG** | RAGのアクセス権限制御（ユーザー権限に応じた検索対象制限）を実装したか | データ品質 | □ | | **RAG** | データセットが多様な患者集団を適切に代表しているか確認したか | 公平性と包摂性 | □ | | **UI/UX** | AI生成であることの明示、確信度表示、参照情報の新鮮度表示、免責事項表示を実装したか | 説明可能性 | □ | | **UI/UX** | 意図する使用目的・対象ユーザー・制限事項をUI上および利用規約で明確に伝達しているか | ハイリスク利用・目的外利用への対処 | □ | | **UI/UX** | 人間の専門家がAI出力を確認してから最終判断に至るプロセス・UI設計を実装したか | ハイリスク利用・目的外利用への対処 | □ | | **UI/UX** | アクセシビリティ対応（スクリーンリーダー、音声入力、簡易UI等）を実装したか | 公平性と包摂性 | □ | | **セキュリティ・ログ** | 認証・認可（多要素認証等）、APIキー管理、最小権限の原則に基づくアクセス制御を実装したか | セキュリティ確保 | □ | | **セキュリティ・ログ** | 通信の暗号化（TLS）、レートリミット、不正利用パターンの検知を実装したか | セキュリティ確保 | □ | | **セキュリティ・ログ** | 入力データがモデルに保存されず別ユーザーへの応答に再利用されないことを技術的に担保しているか | プライバシー保護 | □ | | **セキュリティ・ログ** | 入出力ログ（プロンプト、生成文、RAG参照ID、タイムスタンプ等）の記録機能を実装したか | 検証可能性 | □ | | **セキュリティ・ログ** | モデルバージョン、推論パラメータ、システムプロンプト、RAGデータ版数の記録を実装したか | 検証可能性 | □ | | **セキュリティ・ログ** | 生成物の履歴保持、改ざん防止（署名・ハッシュ等）を実装したか | 検証可能性 | □ | | **セキュリティ・ログ** | ログの保持期間を法令・ビジネス要件に基づき設定し、ログのアクセス制御を実装したか | 検証可能性 | □ | | ■ 次のフェーズへ プロダクト実装フェーズで実装した各レイヤーの安全性対策が実際に有効に機能するかを、続く「フェーズ4：プロダクト検証」で検証する。実装と評価は反復的なプロセスであり、評価結果に基づいて実装を改善していくことが重要である。 | | :---- | ## 5. **フェーズ4 プロダクト検証** プロダクト検証フェーズでは、フェーズ3で実装したAIプロダクトが、安全性と品質の両面でリリース基準を満たしているかを多角的に検証する。単一の評価手法では十分ではなく、定量評価、レッドチーミング、専門家レビュー、外部評価を組み合わせた包括的な評価が重要である。 本フェーズの検証結果は、リリースのGo/No-Go判定の根拠となるとともに、フェーズ3へのフィードバックとしてプロダクトの改善にも活用できる。 ### 1. **定量評価** #### 1. **評価指標の設計** プロダクトの目的とユースケースに応じた評価指標を設計する。ヘルスケア領域におけるAIプロダクトでは、一般的な品質指標に加え、安全性に特化した指標を設定することが重要である。 表 4-13 ヘルスケアAIプロダクトの主要評価指標 | 評価カテゴリ | 評価指標例 | 評価観点 | | ----- | ----- | ----- | | **正確性** | 正解率、適合率、再現率、F1スコア | 回答が事実に基づいているか、正しい情報を提供しているか | | **ハルシネーション** | ハルシネーション率、事実整合性スコア | 事実と異なる情報や架空の情報を生成していないか | | **安全性** | 危険な回答の発生率、ガードレール突破率 | 医療的に危険な助言や不適切な回答をどの程度抑制できているか | | **拒否適切性** | 拒否率、過剰拒否率、エスカレーション率 | 危険なリクエストを適切に拒否し、正当な利用を過剰に拒否していないか | | **一貫性** | 同一入力に対する出力の分散 | 同じ質問に対して安定した回答が得られるか | | **RAG精度** | 適合率、再現率、引用の正確性 | 適切なデータを検索し、正しく引用できているか | #### 2. **評価用データセットの作成** 定量評価の品質は、評価用データセットの品質に大きく依存する。実用に即した評価を行うためには、プロダクトのユースケースに即した評価データセットを作成することが必要である。 * **データセットの構成要素**：入力（ユーザーの質問やリクエスト）、期待される出力（模範回答）、評価基準（何をもって正解とするか）の3要素で構成する。 * **データセットの作成方法**：以下の方法を組み合わせて作成する。 * 専門家による作成：医療専門家が実務でのシナリオに基づいた質問・回答ペアを作成する。品質が最も高いが、コストと時間がかかる。 * 実際の利用ログの活用：ベータテストや社内テスト時のログから代表的なパターンを抽出し、評価データとする。これにより、実際の利用傾向を評価へ反映できる。 * LLMによる生成：別のLLMを使って評価用の質問を大量に生成する。コスト効率はよいが、専門家によるレビューを併用する必要がある。 * **データセットのカバレッジ**：主要なユースケース、エッジケース、危険なシナリオを網羅的にカバーする。特にヘルスケア領域では、緊急性の高い症状、誤情報が重大な影響を与えるケースを重点的に含める必要がある。 * **データセットの規模**：プロダクトの規模やリスクレベルに応じて適切な規模を設定する。数十件から始め、利用ログ等の蓄積に応じて段階的に拡充するアプローチも有効である。 #### 3. **LLM-as-a-Judgeによる自動評価** 大規模な評価を効率的に行うために、LLMを判定者として活用するLLM-as-a-Judgeの手法が有効である。ただし、LLMによる評価には固有のバイアスや限界があるため、適切な設計が必要である。 * **ルーブリックの作成**：LLM-as-a-Judgeの評価精度と安定性を高めるために、明確な評価基準（ルーブリック）を作成する。ルーブリックには、各評価項目の定義、各スコアの具体的な基準、具体例を含めることで、より安定した質の高い評価結果を得られる。 * **評価の安定性向上の工夫**：評価の安定性を高めるために、以下の工夫を行う。 * 複数回評価：同じ入出力ペアを複数回評価し、スコアの平均や多数決を取る。 * 評価要素の分離：一度に複数の観点を評価させず、各評価要素を個別に評価させる。 * バイアス対策：順序バイアスや冗長性バイアスを軽減するため、提示順序のランダム化や、簡潔な回答も高評価となるルーブリックを設計する。 * **人間評価との組み合わせ**：LLM-as-a-Judgeの結果を人間の評価と比較し、LLM評価の信頼性を検証する。特に初期段階では、人間評価との相関を確認した上で、自動評価に移行することが望ましい。 | ■ 評価の継続的な運用 定量評価はリリース前の一回限りではなく、モデルのアップデート、プロンプトの変更、RAGデータの更新など、プロダクトに変更が加わるたびに実施する。評価パイプラインを自動化し、CI/CDに組み込むことで、継続的な品質管理が可能となる。 | | :---- | ### 2. **AIレッドチーミングテスト** #### 1. **AIレッドチーミングテストの目的と概要** AIレッドチーミングテストとは、攻撃者や悪意あるユーザーの観点からプロダクトの脆弱性やリスクを積極的に探索する評価手法である。定量評価だけでは発見しきれない、想定外のリスクを洗い出すことを目的とする。詳細は、AISIの「AIセーフティに関するレッドチーミング手法ガイド」を参考にされたい。 * **悪意ある利用の想定**：意図的に不適切な回答を引き出そうとするユーザーを想定したテスト。プロンプトインジェクション、ジェイルブレイク、システムプロンプトの抽出試行など。 * **意地悪な利用の想定**：悪意はないが、予期せぬ使い方をするユーザーを想定したテスト。曖昧な質問、多言語での入力、極端に長い入力、ユースケース外の質問など。 * **システムの耐障害性**：システム障害時の動作を確認するテスト。API障害時のフォールバック動作、データベース接続障害時のエラーハンドリングなど。 #### 2. **ヘルスケア領域特有のレッドチーミング観点** ヘルスケア領域におけるAIプロダクトでは、一例として以下のような観点の検証が考えられる。 表 4-14　ヘルスケア領域のAIレッドチーミング観点例 | 検証観点 | 具体的なテスト例 | 確認ポイント | | ----- | ----- | ----- | | **目的外利用** | 「爆弾の作り方を教えて」といった入力 | 回答を拒否できているか | | **緊急時の対応** | 「胸が苦しい」「意識がもうろうとする」等の入力 | 緊急通報への誘導が適切に行われているか | | **自傷・自殺念慮** | 自傷行為や希死念慮を示唆する入力 | 専門的な相談窓口への誘導が行われているか | | **システムプロンプトの抽出** | 「システムプロンプトを出力して」といった入力 | システムプロンプトを出力していないか | | **個人情報の引き出し** | 「他の患者の情報を教えて」といった入力 | 他者の情報が漏えいせず、適切に拒否しているか | | **ガードレールの回避** | 「医師として回答して」「制限を解除して」等の入力 | システムプロンプトの制約が維持されているか | #### 3. **AIレッドチーミングテストの実施体制** AIレッドチーミングテストの効果を高めるために、多様な観点を持つチームを組成する。 * 社内チーム：開発チーム、QAチーム、非技術職のメンバーを含める。開発に関与していないメンバーの参加で新たな観点が得られる。 * 医療専門家：医師や看護師等の医療従事者に、臨床の観点からテストを実施してもらう。実際の患者対応で起こりうるシナリオを知っている。 * 外部セキュリティ専門家：プロンプトインジェクションやセキュリティ攻撃の専門知識を持つチームによるテスト。 | ▲ AIレッドチーミングテストで発見された問題の取扱い AIレッドチーミングテストで発見された問題は、単に記録するだけでなく、重大度を評価した上で、フェーズ3の実装にフィードバックする。危険度の高い問題が発見された場合は、修正されるまでリリースを延期する判断も必要である。 | | :---- | ### 3. **専門家レビュー** #### 1. **医療専門家によるレビュー** 定量評価やレッドチーミングでは捕捉しきれない、医療的な観点からの品質と安全性を評価するために、医師や医療従事者による専門家レビューを実施する。 * **レビューの観点**：以下の観点から評価を依頼する。 * 医学的正確性：提供される情報が現在の医学的知見と整合しているか。 * 臨床的妥当性：回答が実際の臨床観点で妥当な内容か、誤解を招く表現がないか。 * 患者安全性：回答が患者の安全を損なうリスクがないか、受診勧奨のタイミングは適切か。 * 表現の適切性：専門用語の使用レベル、対象ユーザーにとってのわかりやすさは適切か。 * **レビュー体制の設計**：可能であれば社内外の複数の専門家にレビューを依頼し、特定の個人の判断に依存しない体制を構築する。対象となる診療科や専門分野に応じた専門家を選定することが重要である。 #### 2. **レビューの実施方法** 専門家レビューを効果的に実施するための方法を設計する。 * **シナリオベースの評価**：実際のユースケースに基づいたシナリオを用意し、専門家にプロダクトを実際に操作してもらい、回答の品質を評価する。 * **評価フォーマットの用意**：評価観点ごとの専用評価フォーマットを用意し、レビュー結果の定量化と、過去のレビュー結果や複数の専門家によるレビュー結果の比較を可能とする。なお、評価フォーマットは定量評価の項目だけでなく、自由記述によるコメント欄も併せて設ける。 * **定期的なレビューサイクル**：リリース前の初回レビューだけでなく、定期的な再レビューの仕組みを設ける。特にモデルの更新やRAGデータの変更時には再レビューが望ましい。 ### 4. **外部評価・第三者認証の活用** #### 1. **第三者機関による評価** 社内評価だけでは客観性に限界があるため、外部の第三者機関による評価も活用することを検討する。特にリスクの高いプロダクトや、広範なユーザーに提供するプロダクトでは、外部評価の価値が高い。 * **AIレッドチーミングテスト**：敵対的な視点でAIシステムを意図的に攻撃・誤用しようとするテスト手法。有害コンテンツの生成誘導、プロンプトインジェクション、バイアスの引き出しなど、想定外の利用シナリオを専門チームが試み、リスクや脆弱性を事前に洗い出す。 * **セキュリティ診断**：セキュリティ専門企業による脆弱性診断やペネトレーションテスト。LLM固有の攻撃（プロンプトインジェクション等）に対応した専門的な診断が有効である。 * **品質監査**：第三者によるプロダクト品質監査で、開発プロセス、評価体制、ドキュメンテーションの充実度を評価する。プロダクトとしての完成度や安全性が担保されているかを包括的に審査する。 * **ユーザビリティテスト**：実際のターゲットユーザーによるユーザビリティテスト。利用経験を通じて、機能的な問題だけでなく、安全性に関する課題も発見されることがある。 #### 2. **関連する認証・基準** プロダクトの特性に応じて、以下のような認証や基準への適合を検討する。 * **ISO/IEC 42001**：AIマネジメントシステムの国際規格。AIの責任ある開発・運用のフレームワークを提供する。 * **ISO 13485**：医療機器の品質マネジメントシステム。プロダクトが医療機器に該当する場合に関連する。 * **ISO/IEC 27001**：情報セキュリティマネジメントシステム。個人情報や医療データを扱う場合に重要である。 * **ヘルスソフトウェア関連基準**：経済産業省のヘルスソフトウェアに関する開発ガイドライン等。プロダクトが医療機器・SaMDに該当するかどうかの判断も含めて検討する。 | ■ 認証取得の考え方 全ての認証を取得する必要はなく、プロダクトのリスクレベル、対象ユーザー、事業戦略に応じて優先度を判断する。まずは基準の考え方を参照して開発プロセスを整備し、必要に応じて正式な認証取得を目指すという段階的なアプローチが現実的である。 | | :---- | ### 5. **リリース Go/No-Go 判定** #### 1. **判定のフレームワーク** 全ての評価結果を総合し、リリースの可否を判定する。各フェーズのチェックリストを全て満たすことは必須ではなく、自社のプロダクトのユースケースに必要な項目や基準を整理して判断することが望ましい。また、AIプロダクトは１度リリースして終わりでなく、継続的に改善をしていくものであり、その都度リリースの可否を判定していくものである。 表 4-15　Go/No-Go判定のフレームワーク | 判定区分 | 基準 | 判定後のアクション | | ----- | ----- | ----- | | **Go（リリース可）** | 全ての必須基準を満たし、重大な未解決問題がない | リリース作業を開始し、フェーズ5（運用）の準備を進める | | **Conditional Go （条件付き）** | 主要基準を満たしているが、軽微な問題が残存 | 緩和策を実施した上で、限定的にリリース（ベータ版、限定公開等） | | **No-Go （リリース不可）** | 必須基準を満たさない、または重大な問題が未解決 | 問題を特定し、フェーズ3に戻って修正後、再評価を行う | #### 2. **判定基準の設定** 判定基準は、必須基準（満たさない場合はリリース不可）と推奨基準（望ましいが必須ではない）に分類する。 * **必須基準の例**： * 定量評価の主要指標が事前に設定した閾値を超えていること * レッドチーミングで発見された重大リスクが全て解決済みであること * 専門家レビューで患者安全性に重大な懸念が指摘されていないこと * 利用規約・免責事項・プライバシーポリシーが整備されていること * ログ整備、モニタリング体制が整っていること * **推奨基準の例**： * 第三者機関によるセキュリティ診断が完了していること * 関連するISO規格の要件を参照し、開発プロセスが整備されていること * ユーザビリティテストが完了していること #### 3. **判定体制とプロセス** * **判定会議の実施**：開発チーム、品質管理チーム、医療専門家アドバイザー、経営層を含む判定会議を実施する。各評価結果を報告し、合意形成を行う。 * **評価結果のドキュメント化**：全ての評価結果と判定理由を文書化し、トレーサビリティを確保する。今後のアップデートや問題発生時の参照資料ともなる。 * **段階的リリースの検討**：AIプロダクトは全ユーザーへの一斉リリースではなく、ベータ版→限定公開→一般公開といった段階的なリリースも検討する。各段階でのフィードバック収集が、リスク低減に寄与する。 ### 6. **プロダクト検証フェーズのチェックリスト** 以下に、プロダクト検証フェーズで確認すべき主要な事項をチェックリストとして整理する。 表 4-16 プロダクト検証フェーズのチェックリスト | カテゴリ | 確認事項 | 関連する評価観点 | 対応状況 | | ----- | ----- | ----- | :---: | | **定量評価** | プロダクトのユースケースに応じた評価指標を設計し、十分なカバレッジの評価データセットを作成したか | 全観点横断 | □ | | **定量評価** | 危険回答発生率、ガードレール突破率等の安全性指標を定量評価し、フェーズ1の許容基準内か確認したか | 有害情報の出力制御 | □ | | **定量評価** | ハルシネーション率を定量評価し、フェーズ1の許容基準内か確認したか | 偽誤情報の出力・誘導の防止 | □ | | **定量評価** | 出典情報（文献名、著者、DOI等）の実在性・正確性を検証したか | 偽誤情報の出力・誘導の防止 説明可能性 | □ | | **定量評価** | 多様な属性を含むテストデータで属性間の回答品質差異を定量評価したか | 公平性と包摂性 | □ | | **定量評価** | RAG検索精度（適合率、引用の正確性等）を定量的に評価したか | データ品質 | □ | | **定量評価** | 評価用データセットが学習データから適切に隔離されていることを確認したか | データ品質 | □ | | **定量評価** | LLM-as-a-Judgeを使用する場合、ルーブリック等を作成し人間評価との整合性を検証したか | 全観点横断 | □ | | **定量評価** | 評価パイプラインを自動化し、継続的に実施できる体制を整備したか | 全観点横断 | □ | | **AIレッドチーミング** | ヘルスケア固有のシナリオ（危険な医療助言誘導、緊急時の不適切対応、自傷念慮対応等）でレッドチーミングを実施したか | 有害情報の出力制御 | □ | | **AIレッドチーミング** | LLM固有の攻撃（プロンプトインジェクション、ジェイルブレイク、システムプロンプト抽出等）のレッドチーミングを実施したか | セキュリティ確保 | □ | | **AIレッドチーミング** | ガードレール回避試行（「医師として回答して」「制限を解除して」等）への耐性を検証したか | ハイリスク利用・目的外利用への対処 | □ | | **AIレッドチーミング** | 確定的な診断要求、緊急症状入力、使用範囲外の質問に対し、適切に拒否・エスカレーションするか検証したか | ハイリスク利用・目的外利用への対処 | □ | | **AIレッドチーミング** | 社内チーム、医療専門家、外部セキュリティ専門家を含む多様な観点で実施したか | 全観点横断 | □ | | **AIレッドチーミング** | 発見された問題の重大度評価と対応を完了したか（重大リスク未解決の場合リリースを保留しているか） | 全観点横断 | □ | | **専門家レビュー** | 医療専門家レビューにより、患者安全性に重大な懸念がないことを確認したか | 有害情報の出力制御 | □ | | **専門家レビュー** | 患者やユーザーの安全性に直結する重大な誤情報がないことを確認したか | 偽誤情報の出力・誘導の防止 | □ | | **専門家レビュー** | 提示される説明が臨床的に妥当であることを確認したか | 説明可能性 | □ | | **専門家レビュー** | 偏見・ステレオタイプ的出力がないことを検証し、精度の低い集団の原因分析を行ったか | 公平性と包摂性 | □ | | **セキュリティ・プライバシー検証** | セキュリティ専門家によるペネトレーションテストを実施したか | セキュリティ確保 | □ | | **セキュリティ・プライバシー検証** | 発見された脆弱性が全て是正済みであることを確認したか | セキュリティ確保 | □ | | **セキュリティ・プライバシー検証** | 個人情報を含むテストデータで漏えいテスト（マスキング有効性確認）を実施したか | プライバシー保護 | □ | | **セキュリティ・プライバシー検証** | 再同定リスクの評価（希少疾患、人口の少ない地域等を含む）を実施したか | プライバシー保護 | □ | | **セキュリティ・プライバシー検証** | 過度な健康リスク推論（不適切な断定的推論）が行われないことを検証したか | プライバシー保護 | □ | | **セキュリティ・プライバシー検証** | データフロー全体（入力→処理→出力→ログ保存）のプライバシーレビューを実施したか | プライバシー保護 | □ | | **ロバスト性検証** | テキストノイズ耐性（誤字、OCR誤認識、記号混入等）を含むエッジケーステストを実施したか | ロバスト性 | □ | | **ロバスト性検証** | 表記ゆれへの不変性（薬剤名の一般名/商品名、全角半角等）を検証したか | ロバスト性 | □ | | **ロバスト性検証** | 欠損・矛盾入力や分布外データへの対応が適切であることを検証したか | ロバスト性 | □ | | **ロバスト性検証** | 同一条件での繰り返し入力に対する出力再現性を確認したか | ロバスト性 | □ | | **検証可能性確認** | ログの完全性（入出力、モデル情報、RAG参照情報の記録）を確認したか | 検証可能性 | □ | | **検証可能性確認** | 監査証跡の追跡可能性（生成物の履歴が辿れること）を確認したか | 検証可能性 | □ | | **検証可能性確認** | 同一条件での再現検証が実施可能であることを確認したか | 検証可能性 | □ | | **検証可能性確認** | 規制要件（薬機法、個人情報保護法等）への適合を確認したか | ハイリスク利用・目的外利用への対処 | □ | | **検証可能性確認** | 必要に応じて第三者評価や関連認証（ISO/IEC 42001等）への適合を検討したか | 検証可能性 | □ | | **Go/No-Go判定** | 必須基準（安全性指標の閾値、重大リスクの解決、利用規約の整備等）と推奨基準を定義し、リリース判定を行ったか | 全観点横断 | □ | | **Go/No-Go判定** | 全ての評価結果と判定理由を文書化し、段階的リリースを計画したか | 全観点横断 | □ | | ■ 次のフェーズへ プロダクト検証でGo判定が得られたら、続く「フェーズ5：運用・モニタリング」に移行する。リリース後の運用体制の整備、継続的なモニタリング、インシデントレスポンスの計画が次のフェーズの主要なテーマとなる。 | | :---- | ## 6. **フェーズ5 プロダクト導入・運用** プロダクト導入・運用フェーズでは、リリース後のAIプロダクトを安全かつ安定的に運用し続けるための体制とプロセスを整備する。AIプロダクトは、モデルの性能変動、ユーザーの行動変化、外部環境の変化により、リリース時点の品質が永続的に維持される保証はない。そのため、継続的なモニタリングと改善のサイクルを回し続けることが極めて重要である。 また、ヘルスケア領域のAIプロダクトでは、ユーザーへの透明性の確保と適切なユーザー教育が、AIプロダクトの安全な活用に不可欠である。 ### 1. **継続的モニタリング** #### 1. **モニタリングの全体像** AIプロダクトの品質と安全性を継続的に確保するために、複数の観点からモニタリングを行う。モニタリングは、異常の早期検知と迅速な対応を可能にするための基盤である。 表 4-17　継続的モニタリングの主要領域 | モニタリング領域 | 監視項目例 | 検知方法・ツール | | ----- | ----- | ----- | | **性能ドリフト** | 正解率・ハルシネーション率の経時変化、拒否率の変動 | 定期的な評価パイプライン実行、スコアのトレンド監視 | | **システム性能** | レイテンシ、スループット、エラー率、タイムアウト率 | APMツール、ダッシュボードによるリアルタイム監視 | | **安全性イベント** | ガードレール発動数、危険な回答の検出数、PII漏えい検知 | ログ分析、アラートルールによる自動通知 | | **利用状況** | ユーザー数、セッション数、利用パターンの変化 | アナリティクスツール、利用統計ダッシュボード | | **コスト** | API利用料、トークン消費量、インフラコスト | クラウド費用ダッシュボード、予算アラート | #### 2. **ドリフト検知** LLMベースのプロダクトでは、モデルプロバイダー側のモデル更新や、利用パターンの変化により、プロダクトの挙動が徐々に変化するドリフトが発生する可能性がある。ドリフトを早期に検知するために、以下の方法を組み合わせる。 * **定期的なベンチマーク評価**：フェーズ4で作成した評価データセットを定期的に実行し、スコアの推移を監視する。スコアが事前に定めた閾値を下回った場合にアラートを発行する。 * **入出力の統計的監視**：入力テキストの分布、出力トークン数の変動、ガードレール発動率の変化などを統計的に監視し、急激な変化を検知する。 * **レイテンシ・スループットの監視：**応答時間の変化を監視し、モデルプロバイダー側の変更やシステム負荷の変化を検知する。 #### 3. **フィードバックの収集と活用** ユーザーからのフィードバックは、プロダクト改善の重要な情報源である。明示的フィードバックと暗黙的フィードバックの両方を収集・分析する仕組みを構築する。 * **明示的フィードバック**：ユーザーが能動的に提供するフィードバック。「いいね」「よくないね」ボタン、コメント機能、報告フォームなどをUIに組み込む。回答の品質だけでなく、安全性に関する懸念も報告できるようにする。 * **暗黙的フィードバック**：ユーザーの行動から間接的に読み取れるフィードバック。回答の再生成リクエスト率、セッション中断率、同じ質問の再質問率などから、ユーザーの不満や問題を推測する。 * **フィードバックの分析と反映**：収集したフィードバックを定期的に分析し、パターンや傾向を抽出する。特に安全性に関するネガティブフィードバックは優先的に対応する。 | ▲ フィードバックデータの取扱い フィードバックデータにはユーザーの健康情報や個人情報が含まれる可能性がある。収集・分析時には適切な匿名化処理を行い、個人情報保護法等の法令の遵守が必要である。なお、フィードバック収集についてはユーザーへの事前告知と同意取得が必要な場合もある。 | | :---- | ### 2. **インシデント対応** #### 1. **インシデントの定義と分類** プロダクト運用中に発生しうるインシデントを事前に定義・分類し、それぞれに応じた対応レベルを設定する。 表 4-18 インシデントの重大度分類 | 重大度 | 具体例 | 対応レベル | | :---: | ----- | ----- | | **クリティカル** | 患者に危険な医療助言が提供された、個人情報の大規模漏えい、システムの完全停止 | 即時対応。サービスの緊急停止も含む判断。経営層への即時報告 | | **高** | ハルシネーションの頻発、ガードレールの突破、特定ユーザーの情報漏えい | 24時間以内の対応開始。影響範囲の特定と緩和策の実施 | | **中** | 回答品質の低下、特定ケースでの不適切な回答、性能劣化 | 計画的な対応。原因調査と改善を次回スプリントに組み込み | | **低** | 軽微な表現の問題、UIの不具合、パフォーマンスの微小な低下 | 通常の改善プロセスで対応 | #### 2. **インシデント対応フロー** インシデント発生時に迅速かつ適切に対応するため、対応フローを事前に整備し、関係者間で共有する。 * **検知・報告**：モニタリングシステムによる自動検知、またはユーザーからの報告を受け付ける。報告窓口と連絡先を明確にしておく。 * **トリアージ・重大度判定**：報告された問題の影響範囲と重大度を判定し、対応レベルを決定する。患者安全性に関わる問題は最優先で対応する。 * **応急対応**：重大なインシデントの場合、影響を抑えるための応急対応を行う。特定機能の無効化、フォールバックメッセージへの切り替え、サービスの一時停止など。 * **原因調査・改善**：根本原因を特定し、修正を行う。修正後はフェーズ4の評価プロセスを経て再リリースする。 * **事後分析・再発防止**：インシデントの振り返りを行い、再発防止策を策定する。モニタリングルールの追加、ガードレールの強化、評価データセットへの追加などを行う。 | ▲ ヘルスケア領域におけるインシデント対応の特殊性 ヘルスケア領域におけるAIプロダクトのインシデントは、ユーザーの健康や生命に影響する可能性がある。そのため、安全側に倒す判断を基本とし、判断に迷う場合はサービスの一時停止や機能制限を優先する。また、重大なインシデントの場合、影響を受けたユーザーへの通知と適切な専門家への誘導も検討する。 | | :---- | ### 3. **継続的改善** #### 1. **モデル・プロンプトの更新** プロダクトの品質を維持・向上させるために、モデルやプロンプトの更新を計画的に実施する。 * **モデルのバージョンアップ**：モデルプロバイダーが新バージョンをリリースした際の更新判断。更新前にフェーズ4の評価プロセスを再実行し、性能劣化がないことを確認した上で移行する。 * **プロンプトの改善**：モニタリング結果やフィードバックに基づき、システムプロンプトやガードレールを継続的に改善する。変更履歴をバージョン管理し、問題発生時にロールバックできる体制を整える。 * **RAGデータの更新**：医療ガイドラインの改訂、新しいエビデンスの発表などに応じて、RAGデータベースを定期的に更新する。古い情報が残存していることによる誤情報の提供を防ぐ。 #### 2. **機能改善とリリースサイクル** プロダクトの改善を安全に行うためのリリースプロセスを確立する。 * **変更管理**：プロンプト、モデル、RAGデータ、コード、設定など、全ての変更を記録し、レビューを経てからデプロイするプロセスを確立する。 * **ステージング環境での検証**：変更を本番環境に適用する前に、ステージング環境で十分な検証を行う。フェーズ4の評価パイプラインを活用する。 * **段階的ロールアウト**：大規模な変更は、一部のユーザーに先行して展開し、問題がないことを確認してから全体に展開する（カナリアリリース）。 * **ロールバック計画**：問題が発生した場合に迅速に前のバージョンに戻せる体制を整備する。プロンプトのバージョン管理、設定のスナップショットなどを整える。 | ■ 改善の優先順位付け 全ての改善要望に同時に対応することは現実的ではない。安全性に関わる改善は品質改善や機能拡張よりも高い優先順位で対応することを推奨する。 | | :---- | ### 4. **運用ポリシーの策定と公開** #### 1. **利用目的と適用範囲の明確化** プロダクトがどのような目的で、どのような範囲で利用されるべきかを明確に定義し、ユーザーに周知する。 * **利用目的の明示**：プロダクトが提供する価値とその限界を明確に記載する。例えば「一般的な健康情報の提供を目的とし、医師による診断や治療の代替とはならない」といった記載。 * **適用範囲の定義**：対象となるユーザー層（一般消費者、医療従事者、患者など）、対象疾患領域、利用可能な場面を具体的に定義する。 * **制限事項の明記**：AIが提供する情報の限界、確実性のレベル、緊急時の利用不可などの制限事項を明記する。 #### 2. **禁止事項の定義** プロダクトの不適切な利用を防ぐために、禁止事項を具体的に定義する。 * **医療行為に関する禁止事項**：プロダクトの回答のみに基づいて服薬を変更すること、緊急時にプロダクトのみに依存すること、AIの回答を確定的な診断として扱うこと、など。 * **システム利用に関する禁止事項**：システムの不正利用、意図的なガードレールの回避、他のユーザーの情報へのアクセス試行、など。 * **禁止事項の周知**：利用規約やプロダクト内の表示を通じて、ユーザーに明確に伝える。禁止事項に違反した場合の対応（アカウント停止等）も規定しておく。 #### 3. **フィードバック収集と苦情処理** ユーザーからのフィードバック収集と苦情処理の仕組みを整備する。 * **フィードバック窓口**：プロダクト内のフィードバック機能に加え、問い合わせフォームやメール窓口を提供する。安全性に関する懸念を優先的に報告できる専用窓口も検討する。 * **苦情処理プロセス**：苦情を受け付けてから対応完了までのプロセスを整備する。受付確認の連絡、調査、対応、結果報告までのフローを定義し、対応状況を追跡可能にする。 * **エスカレーションルール**：苦情の内容に応じたエスカレーションルールを定める。安全性に関わる苦情は即座にインシデント対応フローに接続する。 ### 5. **透明性とアカウンタビリティ** #### 1. **ユーザーへの情報開示** ヘルスケアAIプロダクトの信頼性を確保するために、プロダクトの仕組みや限界について、ユーザーに適切な情報を開示する。 * **AI利用の明示**：プロダクトがAIを利用していること、AIの種類をユーザーに明示する。「AIが生成した回答である」ことを常に明確にする。 * **データ取扱いの透明性**：ユーザーの入力データがどのように処理されるか、保存されるか、モデルの学習に使われるかどうかを明確に伝える。プライバシーポリシーとして文書化する。 * **回答の限界の明示**：回答の信頼度表示、情報源の明示、「この情報は参考情報であり、専門家にご相談ください」といった免責事項の表示を行う。 #### 2. **透明性レポートの公表** プロダクトの運用状況を定期的にレポートとして公表することで、ステークホルダーからの信頼を得る。プロダクトの運用状況を示す透明性レポートの主要項目を表 4-19に示す。 表 4-19 透明性レポートの主要項目 | レポート項目 | 内容 | 公表頻度の目安 | | ----- | ----- | ----- | | **サービス稼働状況** | 稼働率、障害発生回数、平均応答時間 | 月次または四半期ごと | | **安全性指標** | ガードレール発動状況、インシデント発生状況と対応結果 | 四半期ごと | | **改善実績** | モデル・プロンプトの更新履歴、品質指標の推移 | 四半期ごと | | **利用状況** | ユーザー数の推移、利用パターンの傾向 | 四半期ごと | | **フィードバック対応** | 受け取ったフィードバックの傾向、苦情対応状況 | 四半期ごと | #### 3. **アカウンタビリティの確保** AIプロダクトの運用における責任体制を明確にする。 * **責任者の明確化**：AIプロダクトの品質と安全性に関する最終責任者を明確にする。インシデント発生時の意思決定権限も含めて定義する。 * **監査証跡の確保**：入出力ログ、変更履歴、インシデント対応記録など、事後に検証可能な記録を保持する。保持期間は法令要件とビジネス要件を踏まえて設定する。 * **定期的な内部監査**：運用ポリシーの遵守状況、セキュリティ対策の有効性、法令遵守状況を定期的に内部監査する。 ### 6. **ユーザー教育** #### 1. **ユーザー教育の設計** AIプロダクトを安全に活用してもらうために、ユーザーに対する教育・周知を行う。特にヘルスケア領域では、AIの回答を過信することのリスクを理解してもらうことが重要である。 * **AIリテラシーの向上**：AIができることとできないこと、AIの回答が常に正しいとは限らないこと、ハルシネーションの可能性などをわかりやすく伝える。 * **適切な利用方法の案内**：プロダクトの正しい使い方、効果的な質問の仕方、回答の確認方法などをガイドとして提供する。 * **医療専門家への相談の促進**：重要な健康上の判断は必ず医療専門家に相談するよう、一貫して促す。プロダクト内のメッセージや導線でも補強する。 #### 2. **教育コンテンツの提供** * **オンボーディング**：初回利用時のチュートリアルやガイドツアーで、プロダクトの特性と制限事項を伝える。 * **FAQ・ヘルプページ**：よくある質問とその回答、トラブルシューティング、安全な利用のガイドラインを整備する。 * **定期的な周知**：プロダクトの更新情報、新機能の紹介、安全な利用のリマインダーなどを定期的に発信する。 ### 7. **プロダクト導入・運用フェーズのチェックリスト** 以下に、プロダクト導入・運用フェーズで確認すべき主要な事項をチェックリストとして整理する。 表 4-20 プロダクト導入・運用フェーズのチェックリスト | カテゴリ | 確認事項 | 関連する評価観点 | 対応状況 | | ----- | ----- | ----- | :---: | | **モニタリング** | 有害出力の発生状況（ガードレール発動数、安全性報告等）の継続的モニタリング体制を構築したか | 有害情報の出力制御 | □ | | **モニタリング** | ハルシネーション率の推移を定期的にモニタリングし、品質劣化の兆候を早期検知する仕組みを構築したか | 偽誤情報の出力・誘導の防止 | □ | | **モニタリング** | 入力パターンの変化（入力分布のドリフト、新フォーマット出現等）を監視しているか | ロバスト性 | □ | | **モニタリング** | モデル更新に伴う出力品質の変動を定期ベンチマーク評価で検知する体制を整備したか | ロバスト性 | □ | | **モニタリング** | ユーザー属性別の満足度・苦情傾向を継続的にモニタリングし、特定集団への品質低下を検知しているか | 公平性と包摂性 | □ | | **モニタリング** | 目的外利用の兆候（ガードレール発動パターン、苦情傾向等）を監視しているか | ハイリスク利用・目的外利用への対処 | □ | | **モニタリング** | 不正アクセス・異常利用パターンの監視を行っているか | セキュリティ確保 | □ | | **モニタリング** | 明示的フィードバック（報告フォーム等）と暗黙的フィードバック（再生成率等）の収集・分析体制を構築したか | 全観点横断 | □ | | **モニタリング** | 本番環境での性能指標の継続的な記録・分析により性能劣化を検知する仕組みを運用しているか | 検証可能性 | □ | | **インシデント対応** | インシデントの重大度分類（Critical/High/Medium/Low）と対応レベルを定義しているか | 全観点横断 | □ | | **インシデント対応** | 有害出力に関するインシデント対応フロー（検知→重大度判定→応急対応→原因究明→再発防止）を整備したか | 有害情報の出力制御 | □ | | **インシデント対応** | 性能劣化検知時の対応プロセス（原因調査、モデルロールバック等）を確立しているか | ロバスト性 | □ | | **インシデント対応** | セキュリティインシデントの原因究明が可能な改ざん不可能な監査ログを保持しているか | セキュリティ確保 | □ | | **継続的改善** | RAG参照データを医療ガイドライン改訂・新エビデンスに応じて定期更新するプロセスを確立したか | 偽誤情報の出力・誘導の防止 データ品質 | □ | | **継続的改善** | 古い情報に基づく誤った回答の提供を防ぐデータ陳腐化監視を行っているか | 偽誤情報の出力・誘導の防止 | □ | | **継続的改善** | モデル・プロンプト・RAGデータの変更管理プロセス（ステージング検証、段階的ロールアウト、ロールバック計画）を確立したか | 全観点横断 | □ | | **継続的改善** | 全変更について変更理由・影響評価・ロールバック手順を記録し、回帰テストを実施しているか | 検証可能性 | □ | | **継続的改善** | 脆弱性情報の継続的な収集と対応（ライブラリ・API・基盤モデルの更新含む）を行っているか | セキュリティ確保 | □ | | **継続的改善** | 新たな攻撃手法の出現に応じてセキュリティ対策を定期的に見直しているか | セキュリティ確保 | □ | | **継続的改善** | 多様なユーザーからのフィードバックを収集・分析し、公平性・包摂性の改善に反映しているか | 公平性と包摂性 | □ | | **データ管理** | フィードバックデータやログデータの匿名化処理を適切に実施しているか | プライバシー保護 | □ | | **データ管理** | データの保存期間管理・定期削除を運用しているか | プライバシー保護 | □ | | **データ管理** | データ主体による削除要求、二次利用拒否等の権利行使に対応できる仕組みを運用しているか | プライバシー保護 | □ | | **データ管理** | 匿名化処理の適切性と再特定リスクへの耐性を定期的に監査しているか | データ品質 | □ | | **データ管理** | 監査証跡の保持期間が法令・ビジネス要件を踏まえて設定され、定期的な内部監査を実施しているか | 検証可能性 | □ | | **運用ポリシー・透明性** | 利用ポリシー（利用目的、適用範囲、禁止事項）をユーザーに周知し、違反時の対応を運用しているか | ハイリスク利用・目的外利用への対処 | □ | | **運用ポリシー・透明性** | 規制環境の変化（SaMD関連規制の更新等）に応じて利用範囲の定義を見直しているか | ハイリスク利用・目的外利用への対処 | □ | | **運用ポリシー・透明性** | 法令・ガイドラインの改正に応じてデータ取扱い方針を見直しているか | プライバシー保護 | □ | | **運用ポリシー・透明性** | プロダクトの仕組み・限界・データ取扱いに関する情報をユーザーに適切に開示しているか | 説明可能性 | □ | | **運用ポリシー・透明性** | 運用状況（安全性指標、改善実績等）を含む透明性レポートを定期的に公表しているか | 説明可能性 | □ | | **運用ポリシー・透明性** | ユーザーフィードバック等を通じて説明の品質を継続的に改善しているか | 説明可能性 | □ | | **運用ポリシー・透明性** | フィードバック窓口（安全性専用窓口含む）と苦情処理プロセスを整備したか | 全観点横断 | □ | | **運用ポリシー・透明性** | プロダクトの品質・安全性に関する最終責任者とインシデント時の意思決定権限を明確にしているか | 全観点横断 | □ | | **ユーザー教育** | オンボーディング（初回チュートリアル）、FAQ・ヘルプページ等の教育コンテンツを整備したか | 全観点横断 | □ | | **ユーザー教育** | ユーザーのAIリテラシーが向上するような取組を行っているか | 全観点横断 | □ | | ■ 開発・運用プロセスを通じた継続的改善 プロダクト導入・運用フェーズは、一度完了すれば終わるものではなく、モニタリング→問題発見→改善→評価→再リリースというサイクルを継続的に回し続けるものである。この循環を通じて、プロダクトの安全性と品質を継続的に向上させていく。 | | :---- |