Model Card

モデルカードは、AIまたは機械学習モデルの機能、開発・評価方法、適切な使用場面、ユーザーが理解しておくべき制限事項やリスクを説明する構造化文書です。ソースコードやモデル内部へのアクセスを必要とせず、AIの透明性を支援する実用的な情報シートとして、開発者、レビュアー、デプロイ担当者、影響を受けるステークホルダーに役立ちます。この文脈でのモデルカードは、ファッションモデルのプロ向けポートフォリオである「コンポジットカード」とは関係ありません。

モデルカードに記載される内容#

有用なモデルカードは、技術的な根拠と平易な言葉によるガイダンスを組み合わせます。記載の詳しさはモデルの影響に応じて調整します。実験的な画像分類モデルであれば短いカードで済む場合がありますが、医療や金融の意思決定に影響するモデルには、より詳細なドキュメントが必要です。

一般的な構成要素は次のとおりです。

• 目的、所有者、バージョン： モデル、責任を負うチーム、リリースバージョン、タスク、対応する入力と出力、連絡先またはメンテナンス情報を明示します。
• トレーニングデータと開発の背景： データソース、収集条件、アノテーション方法、前処理、モデルアーキテクチャ、トレーニング手順、重要な前提条件について説明します。機密データや専有データは、開示せずに概要を示すことができます。
• 評価とパフォーマンス指標： 明確に特定された検証用またはテスト用データセットでの指標を報告します。物体検出では、適合率、再現率、平均適合率、推論レイテンシ、個別クラスや意味のあるデータサブセットごとの結果などが含まれます。
• 想定用途と対象外の用途： 適切な用途、想定される稼働条件、必要な人間による監督、モデルの設計対象ではないシナリオを説明します。
• 制限事項とリスク： 既知の失敗パターン、不確実性、プライバシー上の懸念、セキュリティ上の考慮事項、起こり得るデータセットバイアスを記録します。また、誤った予測がもたらす可能性の高い影響も明記します。

Amazon SageMaker Model Cardsのドキュメントでは、想定用途、トレーニングの詳細、評価、リスク評価、推奨事項を網羅する、構造化されたライフサイクル記録の例を紹介しています。Google DeepMindのモデルカードなどの公開コレクションは、モデルカードを通じて、より幅広い読者に機能、安全性評価、制限事項を伝える方法を示しています。

モデルカードが重要な理由#

モデルカードは、モデルの採用やデプロイの前に、チームが十分な情報に基づいて判断するのに役立ちます。目を引く指標が、まれなクラス、特殊な環境、特定のユーザーグループでの低い性能を隠している場合があります。評価データセット、テスト条件、グループごとの結果を記録することで、モデルカードは数値を解釈するために必要な背景情報を読者に提供します。

モデルカードは、ガバナンスと説明責任の確保にも役立ちます。NIST AIリスクマネジメントフレームワークは、AIのライフサイクル全体を通じた信頼性の管理を重視しています。また、OECDの透明性と説明可能性に関する原則は、AIの機能や制限事項について有意義な情報を提供するよう求めています。モデルカードは、これらの目標を実現するための実用的な成果物です。

組織内では、モデルカードによってデータサイエンティスト、プロダクトチーム、コンプライアンスレビュアー、運用エンジニア間の引き継ぎが円滑になります。IBM AI Factsheetsなどのシステムは、開発、承認、デプロイ、モニタリングにわたってモデルのメタデータを収集し、このアプローチを発展させています。

関連ドキュメントと主な違い#

関連する成果物には、目的の異なるものがいくつかあります。

• データカード： データセットの由来、構成、収集プロセス、アクセス条件、想定用途、制限事項を説明します。モデルカードはトレーニング済みモデルに焦点を当てますが、関連するデータセットのドキュメントを参照する必要があります。
• モデルレジストリ： モデルの成果物、バージョン、系譜、デプロイ状況を保存・管理します。MLflow Model Registryのワークフローは、この運用上の役割を示しています。モデルカードは意味やリスクを伝え、レジストリはモデル資産を管理します。この2つは連携させることができます。
• システムカード： 複数のモデル、プロンプト、検索コンポーネント、安全対策、インターフェース、人間によるプロセスなどを含む、AIシステム全体を記録します。モデルカードの対象範囲は、より限定的なモデル単位です。
• 説明可能性レポート： モデルが特定の出力を生成した理由を検証します。モデルカードは全体的な動作と制限事項を要約しますが、予測ごとの説明に代わるものではありません。

実際の活用例#

• 製造業における外観検査： 工場では、欠陥検出にコンピュータービジョンモデルを導入する場合があります。モデルカードには、対応する欠陥クラス、カメラの配置、照明に関する前提条件、まれな欠陥に対する性能、最小物体サイズ、エッジデバイスでのレイテンシを記載できます。反射する照明の下で傷を見落とすことが多い場合、その制限事項を記録することで、オペレーターは手動レビューを必須にしたり、追加のトレーニング画像を収集したりできます。

• 臨床画像の診断支援： 医用画像モデルのカードでは、評価時に対象となったスキャンの種類、機器、患者集団、医療機関を明記できます。サブグループごとの性能を報告し、出力は有資格の臨床医を支援するものであり、診断を独立して決定するものではないと明確にできます。この背景情報が欠けていると、病院が未対応の機器や患者集団にモデルを使用し、信頼性の低い推奨につながるリスクが高まります。

サードパーティ製モデルを選ぶ際にも、モデルカードを目にすることがあります。たとえば、Microsoft Foundryのモデルカタログのドキュメントでは、モデルの詳細、ベンチマーク、対応データ型、ライセンス、デプロイ情報を含むモデルカードについて説明しています。

モデルカードの作成とメンテナンス#

デプロイ後ではなく、プロジェクトの計画段階でモデルカードの作成を始めてください。データセットのバージョン、トレーニング設定、評価条件、レビュアーの判断など、根拠となる情報が作成された時点で記録します。Ultralytics YOLO26の物体検出モデルでは、ドキュメント化された検証ワークフローを使用して、評価セクションの指標を生成できます。

from ultralytics import YOLO

# Load the documented model version
model = YOLO("yolo26n.pt")

# Evaluate it on a labeled validation dataset
metrics = model.val(data="coco8.yaml")

# Record these results with the dataset and test conditions
print(f"mAP50-95: {metrics.box.map:.3f}")
print(f"mAP50: {metrics.box.map50:.3f}")
print(f"mAP75: {metrics.box.map75:.3f}")

これらの値は、モデルのバージョン、データセット、データ分割、画像サイズ、ハードウェア、評価設定を併記して初めて意味を持ちます。チームはUltralytics Platformを使用して、データセットのアノテーション、トレーニング実行の追跡、モデルのデプロイ、エンドポイントのモニタリングを行いながら、モデルカードの更新に必要な根拠を維持できます。

モデルカードは、バージョン管理された更新し続けるドキュメントである必要があります。モデル、データセット、評価プロセス、デプロイ環境、既知の制限事項に変更があれば、必ず更新してください。最も重要なのは、トレーニングを担当したチームだけでなく、モデルを使用するかどうか、どのように使用するかを判断する人々に向けて書くことです。