学習済みモデルは、1つのファイルに収まることがあります。しかし、それを運用するためのシステムはそうではありません。
MLチームから製品、プラットフォーム、病院、パートナーのエンジニアリングチームへモデルを渡すとき、引き継ぎはしばしば「モデルをAPI経由で呼び出せるようにする」と説明されます。しかし、この言い方では作業の大半が見えなくなります。エンドポイントがリクエストを受け付けてスコアを返せても、前処理、しきい値の意味、不正な入力への対応、バージョンの識別、プライバシーの境界、運用責任が未整理のままということはあります。
医療AIでは、これらの抜けは周辺的な問題ではありません。実際にどのシステムを使っているのか、その出力を解釈できるのか、問題が起きたときに推測に頼らず調査できるのかを左右します。
したがって、有用なモデルからAPIへの引き継ぎでは、重み以上のものを渡します。範囲が限定され、テスト可能で、バージョン管理された推論システムと、その運用責任を誰が担うかを明確にした記録を引き継ぐのです。
エンドポイントより先に用途の境界を定める
URLやクラウドサービスを選ぶ前に、将来の連携が支援する意思決定を定義します。
想定する利用者、受け入れる入力、運用環境、必要な処理時間、出力の意味、その後に取り得る行動を文書化します。APIを使ってはならない用途も明記します。適切な資格を持つ担当者による確認に向けて画像の優先順位を付けるサービスと、別のシステムに測定値を渡すサービス、人による確認を前提に文章を下書きするサービスでは、許容される判断や行動の範囲が異なります。
IMDRFの2025年の機械学習の適正な実践に関する原則は、意図した目的と臨床ワークフローの文脈を出発点としています。また、製品ライフサイクル全体にわたるソフトウェアエンジニアリング、セキュリティ、トレーサビリティ、デプロイ、監視、保守を重視しています。[1] これらの原則はAPIの設計を指定するものではありませんが、エンジニアリング上の教訓は明確です。モデルは、その出力が使われる文脈から切り離せません。
モデルを作る側と組み込む側の両方がテストできる形で境界を記述します。「リスクスコアを返す」だけでは不十分です。そのスコアに意味を与える対象集団、入力元、単位、除外条件、時間枠、ポリシーのバージョンは何でしょうか。誰がそのスコアに基づいて行動できますか。どの意思決定がサービスの範囲外に残りますか。
これらが未解決なら、APIは実験段階のモデルを呼び出しやすくするだけで、安全性や有用性を高めるとは限りません。
実行可能な推論システムをまとめる
モデル成果物は、リリースを構成する要素の1つにすぎません。デプロイ単位を変更不可のバンドルとして扱い、少なくとも次の要素を特定することを推奨します。
- モデルの重みとアーキテクチャ、または実行形式。
- 前処理、特徴抽出、入力品質のルール。
- 後処理、キャリブレーション、しきい値、ポリシーロジック。
- 出力ラベル、単位、範囲、不確実性を表すフィールド。
- コード、ライブラリ、ドライバー、実行環境の依存関係。
- 動作を変える必須の設定。
- テスト用の固定入力と期待される結果。
- リリース識別子、成果物のハッシュ、ビルド記録、承認の根拠。
これにより、よくある失敗を防げます。2つのチームが「同じモデル」をデプロイしたと言いながら、異なる画像変換、カテゴリの対応付け、しきい値、依存関係のバージョンを使っているという失敗です。
環境固有のシークレットやインフラ設定はモデルのバンドルから切り離します。一方、評価の対象となった、動作を変える設定はバージョン管理します。秘密鍵をイメージに埋め込んではいけません。どのケースをフラグ付けするかを変えるしきい値を、文書化されていないダッシュボード上の値として放置してもいけません。
バンドルを、そのリリースを支えた評価記録に結び付けます。ModAsteraのAIトレーサビリティガイドでは、データとモデルの開発からデプロイ、人による確認までをつなぐ、より広い識別子の連鎖を解説しています。引き継ぎでは、稼働後に根拠を再構成するのではなく、その根拠を参照できるようにします。
API仕様を機械にも利用者にも明確にする
API仕様では、正常なリクエスト、正常なレスポンス、想定されるすべての失敗の種類を定義します。少なくとも次の事項を指定します。
- 認証と認可の要件。
- 対応するメディアタイプ、スキーマ、単位、次元、ファイルの制限。
- 必須および任意のメタデータ。
- 検証ルールと、入力を拒否した場合の動作。
- 同期処理または非同期処理の意味と動作。
- タイムアウト、再試行、冪等性、キャンセル時の動作。
- レスポンスのフィールド、信頼度や不確実性の意味、ポリシーのバージョン。
- エラーコード、結果なしの状態、リクエストを再試行できるかどうか。
- 廃止予定の通知と互換性のポリシー。
OpenAPI Specificationは、HTTP APIが提供する機能を人とソフトウェアが理解し、文書、クライアント、テストを生成するための、プログラミング言語に依存しない方法を提供します。[4] 適した場面では、このような機械可読な仕様を使います。ただし、スキーマが完全であることと、臨床的な意味が明確であることは別です。
confidenceという名前のフィールドは、それだけでは意味が分かりません。モデルの生の確率、キャリブレーション後の推定値、距離、製品固有のスコアを指す可能性があります。範囲、解釈、既知の限界、運用ポリシーとの関係を文書化します。サービスがカテゴリを返す場合は、それがモデルの出力なのか、しきい値に基づく状態なのか、ワークフロー上の推奨なのかを明記します。
有効な入力、境界ケース、各種の失敗について例を用意します。公開する例や一般的な開発者向け文書に、実際の患者データを含めてはいけません。
すべての結果にリリース情報を付ける
APIを利用する側は、どのシステムが出力を生成したのかを知る必要があります。受け付けた各リクエストに追跡可能なリクエスト識別子を付け、各結果で処理を行ったリリースを特定できるようにすることを推奨します。
用途に応じて、レスポンスまたはアクセスが保護されたトレースに、次の情報を記録できます。
- リクエストまたはジョブの識別子。
- サービスとAPIのバージョン。
- モデルリリースの識別子。
- 前処理とポリシーのバージョン。
- 入力検証の結果。
- 受信、処理、完了のタイムスタンプ。
- 出力の状態と警告コード。
- プライバシーに配慮した、元のトランザクションへの参照。
レスポンスに内部パス、シークレット、不要なインフラの詳細を露出させてはいけません。目的は処理を再構成できることにあり、無差別にログを残すことではありません。
リリースの識別情報は、非同期キューや再試行を経ても維持される必要があります。あるバージョンでリクエストの処理を開始し、新しいリリースのデプロイ後に完了する場合、記録には実際に処理したバージョンを示します。再試行によって行動が重複する可能性があるなら、最初のインシデントが起きてからではなく、連携の前に冪等性を定義します。
失敗と結果なしを予測から分ける
医療AIのAPIは、「システムがこの入力を評価できなかった」という状態を、通常の陰性結果に変換してはいけません。
次のような状態を区別します。
- 非対応の入力、または形式が不正な入力。
- 必須メタデータの欠落。
- 品質ルールによる入力の拒否。
- モデルまたは依存先が利用できない状態。
- 処理のタイムアウト。
- 出力は生成されたものの、必要な意思決定の時間枠を過ぎた状態。
- モデルの判断保留、またはポリシーで定めた結果なしの状態。
- 警告を伴う正常な出力。
具体的な分類はワークフローによって異なります。重要なのは、通信の成功、推論の完了、利用できる結果が、それぞれ異なる出来事だという点です。
どの状態なら再試行できるのか、どの状態では入力の修正が必要なのか、どの状態を人による確認につなげるべきか、どの状態で運用アラートを出すべきかを定義します。組み込む側のシステムの動作もテストします。APIを慎重に設計していても、利用側が200以外のすべてのレスポンスを黙って「所見なし」に変換すれば、意図した動作は崩れます。
NISTは、モデル開発と、デプロイ、運用・監視、テスト・評価・検証・妥当性確認の活動を区別しています。[2] この区別は、ここでも有用です。オフラインで良い評価結果が得られていても、クライアントの再試行、キュー、タイムアウト、フォールバックが意図した動作を維持するとは証明できません。
データとセキュリティの境界を定める
引き継ぎでは、どのデータがAPIの境界を越えるのか、どこで処理されるのか、何が保持されるのか、何がログ、バックアップ、監視、サポートツールに入るのかを明記します。
次の事項を指定します。
- 呼び出し元の識別と最小権限でのアクセス。
- テナント単位とオブジェクト単位の認可の境界。
- 暗号化と認証情報の管理に関する要件。
- 許可する入力の所在と外向きの接続。
- データの保存地域、保持、削除、バックアップ時の動作。
- 一般的なアプリケーションログから除外するペイロードのフィールド。
- 監査イベントと、それにアクセスできる人。
- レート、サイズ、同時実行数、コストの制御。
- インシデントの報告経路と認証情報の失効経路。
OWASPのAPI Security Top 10は、認可の不備、認証の不備、制限のないリソース消費、セキュリティ設定の不備、不適切なAPIのインベントリ管理を、繰り返し現れるリスクとして挙げています。[5] この一覧だけでアーキテクチャが完成するわけではありませんが、認証付きエンドポイントを完成したセキュリティ設計だと考えてはいけない、という有用な警告になります。
データ、意図した用途、デプロイ環境、適用される義務に応じた保護策を実施します。特定のクラウド構成や認証方式を使えば規制に適合すると主張してはいけません。
稼働前に責任を割り当てる
APIは連携テストに合格しても、その周囲の境界を誰も管理していなければ、サービスとして機能しなくなることがあります。
次の事項を含む責任分担の記録を作成します。
- モデルのリリースとその根拠を誰が承認するか。
- 推論を提供するインフラとアクセス制御を誰が管理するか。
- 代表的な連携用入力を誰が提供し、検証するか。
- 可用性、遅延、エラー、データ品質、モデルの動作を誰が監視するか。
- インシデントに誰が対応し、影響を受けるチームに連絡するか。
- 設定、しきい値、依存関係、モデルの変更を誰が承認するか。
- ホスティング費用、容量、サポート時間、サービスの制限を誰が管理するか。
- サービスの一時停止、ロールバック、廃止を誰が実施できるか。
- 引き継ぎ時または契約終了時に、どの成果物とデータを返却または削除するか。
NISTのAI RMFは、リスク管理、継続的な監視、不測の事態への対応、安全な廃止を通じて、役割とコミュニケーションを明確にするよう求めています。[3] また、その活動主体のモデルでは、デプロイと運用に関わるのはモデルを学習させたチームだけではなく、連携担当者、開発者、運用者、利用者、評価者、分野の専門家、ガバナンスを担う人々であるとしています。[2]
責任分担表は規模に見合ったものにします。小規模なパイロットに大きな管理体制は不要ですが、それでも責任者、エスカレーションの経路、意思決定権は明確である必要があります。
引き継ぎをシステム全体でテストする
検証は、バンドルから運用の境界へと範囲を広げていきます。
成果物の確認： ハッシュを検証し、クリーンな環境でリリースを読み込み、固定したテスト入力を使って、前処理から出力までの一連の処理を実行します。
API仕様の確認： スキーマ、単位、制限、エラーコード、認証失敗、廃止予定の機能の動作、クライアントとの互換性を検証します。
連携の確認： 想定する入力元の経路から、適法に利用できる代表的な入力を使います。識別子の対応付け、処理のタイミング、キューの動作、下流での解釈を確認します。
耐障害性とセキュリティの確認： 不正な入力、依存先の障害、タイムアウト、重複リクエスト、認証情報の失効、レート制限、復旧手順を試します。機密性の高い本番データは、不必要に使わないようにします。
性能の確認： 想定するワークフローを反映した負荷で、遅延、スループット、同時実行数、リソースの制限、コストの前提をテストします。開発者のマシンで1回のリクエストが速く処理できても、処理容量を示す結果にはなりません。
ロールバックの確認： 管理された環境で新しいリリースをデプロイし、以前の承認済みリリースに戻します。そのうえで、有効なバージョンと、それが生成した出力を引き続き特定できることを検証します。
運用の確認： ダッシュボード、アラート、運用手順書、サポート窓口、バックアップと削除の手順、後から得られる結果を正しいリリースに結び付けるプロセスを確認します。
AIプロジェクトがプロトタイプからデプロイまでの間で停滞する理由の記事では、連携に伴うより広いギャップを解説しています。サービスの運用が始まった後は、AIモデル監視ガイドで、兆候を調査と管理された対応につなげる方法を確認できます。
URLではなく受け入れ記録で締めくくる
意図した用途、正確なリリース、API仕様、テストの根拠、未解決の限界、責任分担表、ロールバック先、承認判断を含む1つの受け入れ記録を双方がレビューできれば、範囲を限定した次の段階へ進むための引き継ぎが整ったと言えます。
その記録は、臨床的な有益性、規制当局による承認、制限のない利用への準備が整ったことを証明するものではありません。モデルとサービスの境界を明確にし、承認された次の段階に進むために十分なテストを行ったことの根拠です。
実務上の問いは、「エンドポイントが予測を返すか」だけではありません。「その予測を生成したシステム全体を特定し、解釈し、運用し、制約を設け、調査し、安全に変更できるか」です。
ModAsteraは、フルスタックのヘルステック、医療AI、規制対象のソフトウェアを開発しています。検証済みのモデルはあるものの、レビュー可能で継続的に支援できる推論サービスへの道筋が見えない場合は、モデルからAPIへの引き継ぎについてご相談ください。まずワークフローの境界を定め、すべてのインターフェースと責任をテスト可能にします。
References
[1] IMDRF N88 PDF, IMDRF (2025), Good machine learning practice for medical device development: Guiding principles
[2] https://airc.nist.gov/airmf-resources/airmf/appendices/app-a-descriptions-of-ai-actor-tasks/, NIST AI RMF 1.0, Appendix A: Descriptions of AI Actor Tasks
[3] https://airc.nist.gov/airmf-resources/airmf/5-sec-core/, NIST AI RMF 1.0 Core
[4] https://spec.openapis.org/oas/v3.2.0.html, OpenAPI Specification 3.2.0
[5] https://owasp.org/API-Security/editions/2023/en/0x11-t10/, OWASP Top 10 API Security Risks, 2023 edition
