生成AIを選定するとき、機能一覧やデモ画面だけでは比較しきれない場面が増えています。特に、社内文書、顧客データ、営業支援、問い合わせ対応のように業務へ深く入るAIでは、「どんな入力を受け、どこで強く、どこで弱いのか」を事前に読める資料がないと、後から運用事故につながりやすくなります。
そこで重要になるのが Model Card です。Model Card は、精度を誇る販促資料ではなく、モデルの入力、出力、想定用途、評価条件、制約、倫理上の注意点をまとめる透明性文書として読むと意味が通ります。AI選定では、価格表や機能比較表の前に、まず Model Card があるかどうかを確認する価値があります。
AI Model Card（モデルカード）は、AIモデルの入力と出力、学習データ、評価の方法、想定用途と制約、安全性の検証をまとめた説明書です。選定では、モデルカードの各見出しを自社の調達チェックリストの欄に対応させて読み、「入力形式」「想定用途と既知の制約」「評価の対象」「提供経路」「更新日」を転記します。一方、自社が入力したデータが学習に使われるか、ログがどこに残るかは、モデルカードではなく利用するプランの契約と規約で確認します。
要点
- モデルカードは、入力と出力、学習データ、提供経路、評価、想定用途と制約、安全性の検証をまとめた、AIモデルの説明書です。
- 選定では見出しを調達チェックの欄に対応させ、入力形式、用途と既知の制約、評価の根拠、提供経路、更新日を転記して比べます。
- 自社が入力したデータが学習に使われるかやログの扱いはモデルカードでは決まらないため、利用するプランの契約と規約で確認します。
AI Model Cardとは何か
Model Card という考え方は、Googleの研究者らによるModel Cards for Model Reportingで広く知られるようになりました。狙いは、モデルの性能を単一の指標だけで語るのではなく、想定用途、評価条件、注意点を標準化して伝えることです。
Salesforceも2026年5月28日に更新したModel Cards for AI Model Transparencyで、Model Card を「栄養成分表示のようなもの」と説明しています。さらに、Compliance サイトでは、公開済みのモデルカード群を一覧化しており、入力、出力、使いどころ、倫理上の考慮を継続的に追えるようにしています。
ここで大切なのは、Model Card を「難しい研究資料」と見ないことです。企業の導入判断では、むしろ営業、マーケ、CS、情シス、法務が同じ資料を読みながら、『このモデルは何に向くか』『どこは自社で補わないと危ないか』を会話するための実務文書として使う方が自然です。
Model Card で最低限確認したい6項目
Model Card の書式は提供者ごとに少しずつ違いますが、導入判断で最低限確認したい項目はおおむね共通しています。少なくとも、次の6項目が見えるかを確認した方が安全です。
| 項目 | 確認すること | 見落とすと起きること |
|---|---|---|
| 入力 | どんなデータや形式を前提にしているか | 想定外データで精度が崩れる |
| 出力 | 何を返すモデルか、説明可能性はあるか | 業務フローにそのまま載せて事故が起きる |
| 想定用途 | 何の業務に向くか、何に向かないか | 用途外利用で誤判断が増える |
| 評価条件 | どんなデータ、環境、基準で性能を測ったか | 数字だけ比較して誤る |
| 制約 | 苦手条件、注意点、倫理上の考慮 | 弱点を知らずに本番投入する |
| 更新状況 | 更新日、版、公開先が追えるか | 古い情報を前提に判断する |
特に生成AIでは、モデル名が同じでも提供面が複数あります。アプリで使う場合、APIで使う場合、SaaSへ組み込まれている場合で、ログ、権限、利用規約、制御範囲が変わることがあります。Model Card を読むときは、単に『モデルの特徴』ではなく、『どの提供面の、どの条件のモデル説明か』を見る必要があります。
実例で読む：公開されているモデルカードの見出しと読みどころ
実物の例として、Google DeepMindが公開しているGeminiのモデルカードを見ます。Google DeepMindはモデルカードの一覧ページを公開しており、モデルごとに更新日が表示されています。一覧で2026年10月13日更新と表示されているGemini 4 Argonのモデルカードは、主に次の見出しで構成されています（2026年10月26日時点）。
| 見出し | 書かれていること | 選定での読みどころ |
|---|---|---|
| Model Information | 入力（テキスト、画像、音声、動画）と出力（テキスト）、入力と出力を合わせて扱える量、モデルの構造 | 自社で入力したい資料の形式と量に対応しているか |
| Model Data | 学習に使ったデータの種類と出所 | モデルの開発時の情報として読む。自社が入力したデータの扱いはここでは決まらない |
| Distribution | モデルを使える提供経路（アプリ、API、開発者向けツール、法人向けサービスなど） | 自社が使う予定の提供経路が含まれているか |
| Evaluation | 評価に使ったベンチマークの分野と結果。評価方法の詳細は別ページで公開 | 自社の業務に近い分野の評価があるか、評価方法が公開されているか |
| Intended Usage and Limitations | 想定用途と、幻覚、応答の遅れやタイムアウト、知識の期限（2026年3月）などの既知の制約 | 知識の期限より新しい情報を扱う業務か、制約に対して人の確認をどこに置くか |
| Safety & Security | 安全性の評価と、前のモデル（Gemini 3.1 Pro）と比べた項目ごとの結果 | 自社の利用で関係する項目の数値が前のモデルより悪くなっていないか。悪くなっていれば、その条件で追加の検証をする |
このカードには、評価方法を改訂したため、過去のGeminiのモデルカードに載っている数値とは直接比べられないという注記もあります。版をまたいで数値を比べるときは、こうした注記がないかを先に確認します。
見出しの名前は提供者によって違いますが、入力と出力、学習データ、提供経路、評価、想定用途と制約、安全性という並びは多くのモデルカードに共通しています。Salesforceのように、自社が開発したモデルのカードを一覧で公開している企業もあります。どのカードを読むときも、表の右端の「読みどころ」を問いとして当てはめると、比べやすくなります。
調達チェック欄への対応表
調達や稟議でモデルを比べるときは、モデルカードの記載を自社のチェックリストの欄へ転記し、モデルカードでは分からない点を「追加で確認すること」として同じ行に残します。
| 調達チェックの欄 | モデルカードで読む箇所 | 転記すること | 追加で確認すること |
|---|---|---|---|
| 対応する入力と出力 | モデル情報 | 入力の種類、出力の種類、一度に扱える量 | 自社の実際の資料（帳票、長いPDF、画像）で試した結果 |
| 用途の適合 | 想定用途と制約 | 向いている用途、向かない用途 | 自社の業務がどちらに当たるか、業務部門の判断 |
| 既知の制約 | 想定用途と制約、安全性 | 幻覚、知識の期限、前のモデルより数値が悪くなった項目 | 制約に対して人が確認する場所と担当 |
| 評価の根拠 | 評価 | 評価した分野、方法の公開先 | 自社の評価用データでのPoCの結果 |
| 利用する提供経路 | 提供経路 | アプリ、API、法人向けサービスのどれで使うか | その提供経路の契約での学習利用、ログの保存、データの保存場所 |
| 版と確認日 | カードの更新日、モデル名 | 確認したモデル名、カードの更新日、確認した日 | 提供終了の予定と後継モデル（運用中の終了対応はAIモデル廃止への変更管理） |
「追加で確認すること」の列が埋まらないまま契約へ進まないようにします。特に、自社が入力したデータがモデルの学習に使われるかどうかは、モデルカードの学習データの欄ではなく、利用するプランの規約で確認します。同じモデルでも、個人向けアプリと法人向けの契約とAPIでは条件が異なることがあります。
Model Card がない、または薄いときに確認したい質問
Model Card がない場合は、それ自体をリスクとして扱い、ベンダーへ追加質問を出す方がよいです。すべてのベンダーが十分な Model Card を公開しているわけではありません。もし Model Card が見当たらない、または内容が薄い場合は、最低限次の質問を投げると比較しやすくなります。
- このモデルは何を入力し、何を出力する前提ですか。
- 向かない用途や苦手条件は何ですか。
- どのデータや環境で評価しましたか。
- 更新履歴や版管理はどこで追えますか。
- 倫理上の考慮や公開制約はどこに整理されていますか。
- アプリ版とAPI版でログや利用条件は同じですか。
この質問に曖昧な回答しか返ってこない場合、モデルそのものの良し悪し以前に、運用透明性が不足している可能性があります。高性能でも、説明責任を果たせないAIは、本番利用で詰まりやすくなります。
Model Card だけでは判断しきれないこと
AI選定で失敗しやすいのは、よく見える数値だけを比較することです。Model Card の価値は、最良条件での性能を見せることより、どこで性能が落ちるか、どんな前提に依存しているかを読める点にあります。
Model Card を読む目的は、「一番強いモデル」を見つけることではなく、「自社の業務に対して、どこまで安心して任せられるか」を把握することです。
ただし、Model Card だけで導入可否を決めるのは危険です。なぜなら、Model Card はモデルの透明性文書であって、実装先の権限設計や、社内承認ルールや、監査ログの取り方までは十分にカバーしないことが多いからです。
たとえば、モデルの想定用途が明確でも、CRMへ書き込みできる権限をAIエージェントへそのまま渡してよいかは別問題です。生成精度が安定していても、顧客データをどこまで入力してよいか、出力レビューを誰が持つか、例外時にどこで止めるかは、組織側で設計しなければいけません。
| Model Card で分かること | 別途確認が必要なこと |
|---|---|
| モデルの入力、出力、評価条件 | 自社データを入れてよい範囲 |
| 用途や制約 | 業務フロー上の承認責任 |
| 倫理上の注意点 | 監査ログ、保持、削除ポリシー |
| 更新状況や公開履歴 | 接続先、ツール権限、停止条件 |
このため、AI導入では Model Card を入口にしつつ、AIリスクアセスメント、AI第三者評価、監査証跡設計を横に並べて読む方が実務的です。
よくある質問
Model Card があれば安全性は十分に確認できますか？
十分ではありません。Model Card はモデルの透明性資料として重要ですが、権限、監査ログ、承認フロー、データ持ち込みルールは別途確認が必要です。安全性の欄で前のモデルより数値が悪くなった項目があれば、自社の利用条件でその項目を追加で検証します。
モデル比較では、まずどこを見るべきですか？
最初は精度よりも、想定用途、苦手条件、評価条件、更新日を見た方が失敗しにくくなります。数字の比較はその後です。
生成AIアプリにも Model Card は必要ですか？
必要です。アプリとして提供される場合でも、基盤モデルの制約や想定用途が見えないと、業務導入の判断が難しくなるためです。
Model Card がないベンダーは避けるべきですか？
一律に避ける必要はありませんが、透明性の不足はリスクとして扱うべきです。最低限の質問に答えられるかどうかを確認した方が安全です。
モデルカードの学習データの欄を見れば、自社のデータが学習に使われるか分かりますか？
分かりません。学習データの欄は、そのモデルを開発したときに使ったデータの説明です。自社が入力したデータが今後の学習に使われるか、ログがどこにどれだけ残るかは、利用するアプリやAPI、法人向けプランの契約と規約で確認します。
