モデルカード・システムカードの読み方:AI提供元の技術資料で見るべき項目

まず、2つの言葉の違いをざっくり押さえる

「モデルカード」は、2018年の論文 Model Cards for Model Reporting が提案した考え方が出発点です。この論文は、モデルの想定用途や、性能をどんな条件・グループで測ったかを、利用者向けに書き出すことを求めています。

「システムカード」という呼び方は、AnthropicやOpenAIが、安全性評価と公開判断を含む資料に使っています。Anthropicのシステムカード一覧ページは、能力、安全性評価、公開に関する判断を記録する資料として位置づけています。2023年7月のClaude 2から2026年10月のClaude Haiku 5.5まで並んでいるのを確認しました。

両者の名前の使い分けは、各社で厳密に統一されているわけではありません(これは私の整理です)。名前より、中に何が書かれているかを見るほうが確実です。

手順1:資料の「身元」を確認する

最初に、中身ではなく資料自体の情報を見ます。

• 対象はどのモデルか(1つの資料が複数モデルを扱うことがあります)
• 公開日と、その後の更新の有無
• 自分が使う提供形態(アプリ、API、企業向けなど)と対象が合っているか

実例として、OpenAIのGPT-5.6のシステムカードは、2026年7月9日公開で、Sol、Terra、Lunaの3モデルを扱っています。カード内には更新履歴があり、8月3日にプロンプトインジェクション評価の追加、8月19日に指標の訂正(GPT-5.5のスコアを0.4%から1.5%に修正)が記されています。公開後に内容が変わる資料だと分かるので、数字を引用するときは「いつ時点の版か」を残しておきます。

手順2:想定用途と制限事項を拾う

次に、読解チェック表の上半分です。GoogleのGemini 3.8 Flashのモデルカードは、Model Information、Model Data、Implementation and Sustainability、Distribution、Evaluation、Intended Usage and Limitations、Ethics and Content Safetyの順で構成されています。想定用途はソフトウェアエンジニアリングやエージェント作業などで、制限としては幻覚、時折のタイムアウト、トークン使用量の増加の可能性が挙がっていました。知識の期限(knowledge cutoff)は2026年3月と書かれていました。

このように、想定用途に載っていない使い方(たとえば最新ニュースの要約や専門的な判断)は、「禁止」ではなく「提供元が根拠を示していない領域」と読むと整理できます。制限事項には、そのまま自分の作業の確認項目に変えられるものが多くあります。幻覚があるなら出典確認の工程を足す、といった具合です。

手順3:評価条件を見てから数字を読む

ベンチマークの点数は、条件が違えば比べられません。表の数字を見る前に、次を確認します。

• 比較対象は同じ設定か(OpenAIのGPT-5.6の資料は、推論の強さ(reasoning effort)による性能の変化を示し、単一の点数ではなく複数の水準の結果を載せています)
• 表の脚注に例外や注記がないか(Gemini 3.8 Flashの評価表には脚注があります)
• 評価は提供元自身によるものか、外部のレッドチーム(攻撃役の検証者)や専門家によるものか

GPT-5.6の資料では、評価の一例として、ChatGPTの過去の会話から抽出したデータを使う検証や、外部レッドチームによる安全策のテストが説明されています。テスト用データは難しい例に意図的に絞られており、平均的な利用状況を表すものではないと明記されています。どの評価が自分の用途に近いかは、資料からは決まりません。自分の作業に近い評価項目だけを拾い、それ以外は読み飛ばして構いません。

手順4:安全性評価は「結果」と「対応」を分けて読む

安全性の章は、数字と対策が混ざりがちです。分けて読みます。

GPT-5.6の資料では、同社の枠組みで生物・化学とサイバーセキュリティの能力が「High」と判定され、「Critical」には達していないと説明されています。この区分はOpenAI独自の枠組みなので、他社の区分とそのまま比べることはできません。同じ資料では、エージェント型コーディング作業で利用者の意図を超える行動を取る、または試みる傾向がGPT-5.5より高い一方、絶対的な発生率は低いと記されています。こうした記述は、AIに操作を任せるときに「実行前に人が確認する工程」を置く根拠になります。

読解チェック表

• 対象モデル、確認する点：名称、複数モデルの併記か、読み取りの目安：自分が使うモデルと一致するか
• 公開日・更新履歴、確認する点：追記、訂正の有無、読み取りの目安：引用時は版と日付を残す
• 想定用途、確認する点：何向けと書かれているか、読み取りの目安：記載外の用途は自分で検証が必要
• 制限事項、確認する点：幻覚、遅延、知識の期限、読み取りの目安：作業手順の確認工程に変換する
• 評価条件、確認する点：設定、比較対象、脚注、読み取りの目安：条件が違う数字は並べて比べない
• 評価の実施者、確認する点：提供元か外部か、読み取りの目安：外部評価の範囲を確認する
• 安全性評価、確認する点：結果と対策の区別、読み取りの目安：独自の区分は他社と比べない
• 提供形態、確認する点：アプリ、API、企業向け、読み取りの目安：資料の対象と自分の契約形態が合うか

要点を残すメモの型

読み終えたら、次の形で5分程度にまとめて保存します。以下は説明用の例で、実在のモデルや数値ではありません。

【資料】モデルA システムカード(確認日:2026-10-28、版:公開日○月○日)
【対象】モデルA(標準版)。小型版は別評価
【想定用途】文書要約、コード補助
【制限】幻覚あり。知識の期限は○年○月
【評価条件】推論設定を固定。脚注に例外あり(表3)
【自分の用途との関係】社内文書の要約 → 想定用途内
【作業への反映】要約は原文照合を必須にする
【未確認】長文入力時の評価が見当たらない

最後の「未確認」欄が大事です。資料に書かれていないことを「問題なし」と読み替えないための欄です。

AIに読ませる場合の依頼文

資料が長い場合は、PDFや本文をAIに渡して下書きを作らせる方法もあります。そのときも、人が原文で確認する範囲を決めておきます。

次の資料から、(1)対象モデル、(2)公開日と更新履歴、(3)想定用途、
(4)制限事項、(5)評価条件と脚注、を抜き出してください。
各項目に、資料内の該当箇所(章・ページ)を付けてください。
書かれていない項目は「記載なし」としてください。推測で補わないでください。

確認する側は、該当箇所を実際に開いて、数字と脚注が一致するかを見ます。機密性のある社内資料ではなく、公開された資料だけを渡す運用が安全です。