モデルカードは最小の技術文書たり得るか――Hugging Face Model Cardsを素材に雑感

0　はじめに

　年越しに書き溜めたAIに関して役立つ資料について雑感を付して7点掲載する。今年も皆さんにとっていい年であることを心より祈念する。

　オープンソースの機械学習（ML）モデルは、いまや単なるソフトウェア部品というより配布される知識に近い。数十億、数兆のパラメータからなる重み（weights）と推論コードがセットで流通し、下流の開発者がそれを自社システムに組み込み、さらに別のサービスがその上に乗る。AI開発の民主化と呼ばれるこの現象は、同時に責任の所在を曖昧にするプロセスでもある。結果として、モデルの来歴、どのデータで訓練され、どのような目的で設計され、どの程度の性能と限界を持つのかが、社会にとって極めて重要な前提情報になる。

　Hugging Face HubのModel Cards（モデルカード）は、その前提情報をREADME.mdという、開発者にとって最も親しみのある最小単位のファイル形式で固定しようとする試みである。モデルカードは、モデルに付随する情報ファイルであり、Markdownによる自由記述の本文に加えて、YAML形式のメタデータを持つ。Hub上ではこれが機械可読なメタデータと人間可読なテキスト記述という二層に分かれ、検索性（discoverability）や再現性（reproducibility）のための基盤として位置づけられている〔1〕。

　技術的に見れば、それは単なるテキストファイルに過ぎない。しかし、法的な眼差しで見れば、その軽さは重い意味を持つ。なぜなら、そこに文書が存在するという事実だけで、予見可能性や注意義務といった責任の議論の地図が書き換わるからである。本稿は、Hugging FaceのModel Cardsを素材に、モデルカードが（1）責任の断片化をどこまで縫い合わせられるか、（2）EU AI Actなどの規制文書とどこまで接続できるか、（3）実務として何を書けばよいか、という三点を雑感として整理するものである。

1　問題の所在――「説明」はどこへ置くのか

　AIのガバナンスやコンプライアンスを議論すると、最終的には「誰が何を知っていたか（あるいは、知るべきであったか）」という認識の問題に帰着しがちである。事故が起きたとき、あるいは差別的な出力や誤判定が疑われたとき、法が問うのはモデルの性能それ自体ではなく、開発者が高度な注意義務として何を実施し、リスクについてどの程度の予見可能性を持ち、その限界をどの相手に伝えたかである。つまり、技術はログと文書の形で法に捕捉される。

　2024年に成立したEU AI Act（欧州AI法）は、この「捕まえ方」を制度化した代表例といえる。同法は、高リスクAIシステム（High-Risk AI Systems）の提供者に対し、市場投入前に技術文書（technical documentation）を作成し、適合性評価手続の一環として常に最新化し続けることを要求する〔2〕。この文書は、所管当局がAIシステムの法適合性を評価できるだけの情報を、明確かつ包括的に示すものでなければならない。

　さらに重要なのは、ChatGPTのような汎用モデル、すなわち一般目的AIモデル（General-Purpose AI Model: GPAI Model）に対する規律である。AI法第53条は、GPAIモデルの提供者に対し、訓練・テスト過程や評価結果を含む技術文書を作成・更新し、AI Office（AI局）や所管当局の求めに応じて提示できるようにする義務を課している〔3〕。しかも、その最低限の記載事項はAnnex XI（附属書11）で細かく列挙されている。そこには、モデルのタスク、アーキテクチャ、パラメータ数はもとより、訓練に使用したデータセットの出所やキュレーション方法、計算資源の使用量に至るまでが含まれる〔4〕。

　このように、規制は説明を一つの包括的な文書に押し込もうとする。だが、実際の開発現場では、説明は散逸する運命にある。仕様は論文（Paper）に、コードはGitHubリポジトリに、実装の微調整や議論はブログ記事、社内Wiki、Slackのログ、そして口頭のコミュニケーションの中に散らばっている。これら断片の総和としての説明は、いざ紛争や調査となったとき、極めて証拠化しにくい。外部から見れば、それは存在しないも同然である。モデルカードは、この情報の断片化に対する対抗装置として理解できる。開発サイクルの中心に、常に更新される一つの説明の場所を確保しようとする試みだからである。

2　Hugging Face Model Cardsの構造――README.md＋YAMLという設計

　Hugging FaceにおけるModel Cardsの面白さは、それがWordファイルやPDFのような重厚なドキュメントではなく、開発者が日常的に触れるREADME.mdというプレーンテキストで構成されている点にある。むしろ貧相なほど単純に見えるこの設計こそが、普及の鍵となっている。

　モデルカードは、各モデルのリポジトリのルートに置かれるREADME.mdファイルであり、その先頭に「---」で囲まれたYAMLヘッダ（Front Matter）を持つ。このYAMLセクションには、モデルの言語（language）、ライセンス（license）、対応するタスク（pipeline_tag）、学習に使用したデータセット（datasets）などの構造化データが記述される。Hugging Face Hubのプラットフォームは、このメタデータを自動的にパースし、検索フィルタやモデルページ上のタグ表示として機能させる〔1〕。つまり、モデルカードは人間にとって「読む文書」であると同時に、プラットフォームやスクリプトにとって「機械に読ませるデータ」でもある。

　加えて、メタデータの入力方法が複線化されている点も実務向きである。Hub上のWeb UIからフォーム形式で編集してもよいし、リポジトリをgit cloneしてローカルでREADME.mdのYAMLを直接書き換えてもよいし、huggingface_hubというPythonライブラリ経由でプログラム的に更新してもよい〔1〕。文書化が開発フローから切り離された「特別な事務作業」になった瞬間に、エンジニアの心理的障壁は上がり、更新は滞る。コードのcommit/pushと同じ導線で文書も更新できる設計は、それ自体がガバナンスの実効性を高めるUX（ユーザー体験）といえる。

　さらにHugging Faceは、このライブラリを通じてモデルカードの作成・検証・更新をAPI化している。ModelCardクラスを使えば、カードのメタデータ部分とMarkdownの本文部分をオブジェクトとして操作でき、テンプレートから生成したり、必須項目の有無を検証したりして、Hubへpushすることができる〔5〕。これは地味だが極めて重要である。文書化が人間の善意や記憶だけに依存するなら、必ず腐る（陳腐化する）。CI/CD（継続的インテグレーション／デリバリー）のパイプラインにモデルの再学習とセットでカードの自動更新を組み込めるなら、文書は腐りにくくなる。

3　「境界物」としてのモデルカード――誰のための何の文書か

　では、そのモデルカードには何を書くべきか。Hugging FaceのGuidebookは、モデルカードを「boundary objects（境界物）」として位置づけている。境界物とは、社会学的な概念で、異なる背景や目的を持つ複数のコミュニティ（開発者、政策担当者、倫理研究者、影響を受けるエンドユーザー等）の間をつなぎ、コミュニケーションを可能にする人工物を指す〔6〕。

　境界物である以上、モデルカードは単一の専門用語だけで書かれた一枚岩の技術仕様書にはなりえない。開発者向けにパラメータの詳細だけを書けば一般市民や規制当局には読めず、逆に一般向けに平易な説明だけを書けば、下流の開発者にとって必要な技術情報が欠落する。この緊張関係は、モデルカードという概念の宿命である。

　Model Cardsを最初に提案したMitchellらの論文（2019）でも、この点は意識されていた。彼女らは、モデルの意図された用途（Intended Use）、評価された手続、条件別の性能、そして限界（Limitations）を短い文書としてモデルに添付することを提案した〔7〕。目的は、モデルがどのような文脈で使われることを想定しているかを明示し、文脈外の不適切な利用を減らすことにある。ここでの短さは、多くの人に読んでもらうための美徳であるが、同時に法的な危うさでもある。短いがゆえに、書かれなかったこと（省略された詳細）が膨大に残るからだ。また、肯定的側面ばかりが強調され、カタログスペックを並べただけのマーケティング文書に化けやすいという問題もある。

　実際、Hugging Faceが行ったユーザースタディでも、参加者からはモデルカードを食品の「栄養成分表示（nutrition facts label）」になぞらえる肯定的な声がある一方で、多くのカードが空欄のままであること、特にライセンス情報が不記載であること、更新が追いついていないことへの不満が指摘されている〔8〕。境界物は、しばしば空白を抱えたまま流通する。問題は、その空白が現実社会で事故や権利侵害を引き起こしたとき、誰を傷つけ、誰の責任になるかである。

4　法的含意――モデルカードは責任の糊になれるか

　モデルカードという技術文書が法的に効力を発揮する局面は、大きく二つあると考えられる。

　第一に、下流利用者（Downstream Users）との間の責任分界点としての機能である。モデルカードに「意図された用途（Intended Use）」と「禁止される用途（Out-of-scope Use / Misuse）」、そして「既知の限界（Known Limitations）」が明記されていれば、それは下流の設計判断に直接的な影響を与える情報となる。例えば、「このモデルは医療診断には使用できない」と明記されているにもかかわらず、下流事業者がそれを無視して診断アプリに組み込み事故が起きた場合、モデル提供者は「警告（Warning）」を行っていたとして、製造物責任や不法行為責任における抗弁を主張しやすくなるだろう。逆に、そうした限界が曖昧なままであれば、下流利用者は自前でゼロから評価を行うか、あるいはブラックボックスのリスクを抱えたまま利用するかの二択を迫られることになる。紛争時には、「そのリスク情報は提供されていたか」「予見可能であったか」が主要な争点となる。

　このとき、メタデータとしてのライセンスは見落とされがちだが、実務では最も直接的に法的拘束力を持つ。Hugging Faceのユーザースタディでも、モデル利用者はまずライセンスを確認し、自社のユースケースで法的に使えるかどうかを判断するという指摘がある〔8〕。最近ではOpenRAILライセンスのように、利用用途に倫理的な制限（Responsible Use Restrictions）を課すライセンスも増えている。モデルカードがライセンスを明確に表示し、場合によっては利用条件への同意を求めるゲーティング（Gated Models）機能と結び付く以上〔1〕、そこは単なる飾りではなく、リスク配分の法的入口として機能している。

　第二に、規制文書との接続である。前述のEU AI Act Annex XIを見ると、一般目的AIモデルの技術文書に求められる項目は、モデルカードの理想的な構成要素と驚くほど重なっている。Annex XIは、意図するタスク、適用される利用方針、リリース日と配布方法、アーキテクチャとパラメータ数、入出力の形式、ライセンス等を含む「一般記述」を要求する。さらに詳細として、統合に必要な技術的手段、設計仕様と訓練方法、訓練・テスト・検証データの出所と特性（データのキュレーション方法やバイアス対策を含む）、計算資源や学習時間、エネルギー消費等まで要求している〔4〕。

　このリストにある情報の多くは、良質なモデルカードであれば自然と網羅しようとする項目である。規制対応のために、リリース直前になって慌てて膨大な技術文書を捏造するのではなく、日常の配布プロセスとしてのモデルカードの中に、これらの情報を前倒しで構造化して記述しておく方が合理的である。モデルカードは、規制が求める技術文書の簡易版、あるいはその要約として機能し得るし、そうあるべきだ。

　もっとも、モデルカードは万能の免罪符ではない。書けば責任が消えるわけでも、書かなければ直ちに違法になるわけでもない。むしろ、一度書いて公表すれば、その内容の正確性と更新可能性が問われ続けることになる。技術（モデルの重み）が更新されているのに文書が古いままなら、それは善意の看板ではなく、不作為や過失の証拠になりうる。動かない文書は、動くソフトウェアにとってリスクでしかない。

5　実務への示唆――小さな技術文書」にするための三つの工夫

　以上の議論を踏まえ、実務家がモデルカードを作成・運用する際に意識すべき三つの工夫を提示したい。

（1）何のためのモデルかを先に固定すること

　モデルカードは、万能モデルであることを誇示する自慢話の場ではない。むしろ、用途の輪郭線を明確に引く作業である。「意図された用途（Intended Use）」を具体的に書くと同時に、「適用外（Out-of-scope）」や「禁止事項」を明示することが重要である。これにより、予期せぬ利用に伴うリスクについて、提供者の支配領域と利用者の責任領域を区切ることができる。EU AI Act Annex XIも「意図するタスク」と「適用される利用方針（Acceptable Use Policies）」を独立した項目として要求している〔4〕。これを曖昧にすることは、無限の責任を引き受けることに等しい。

（2）性能を一つの数字で終わらせないこと

　リーダーボードのスコアや平均精度（Accuracy）を書くだけでは不十分である。実務で重要なのは、モデルがどのような条件下で失敗するかという「失敗様式（Failure Modes）」と、属性や環境による性能のばらつき（条件依存性）である。評価データセットは何を用いたか、指標は何か、既知のバイアスや限界、倫理的考慮事項は何か。これらを、少なくとも読者が再現できる程度の粒度で記述する。モデルカードの提唱者であるMitchellらが最も重視したのも、この文脈化された性能評価であった〔7〕。

（3）更新を仕様として組み込むこと

　モデルカードは静的な書類ではなく、リリース物（Artifact）の一部である。huggingface_hubが提供するようなAPIやテンプレート生成機能を使い、モデルの再学習やファインチューニングのパイプラインの中に、カードの更新プロセスも組み込むべきである〔5〕。ハイパーパラメータや学習データが変われば、YAMLメタデータや記述も自動的に、あるいは半自動的に更新される仕組みを作る。ユーザースタディでも更新の難しさや空欄カードへの不満が語られている以上〔8〕、更新可能性（Maintainability）は開発者の倫理観の問題ではなく、運用設計の問題として解決されなければならない。

6　雑感

　モデルカードは、AIガバナンスにおける最小の技術文書である。それはEU AI Actが求めるような数百ページの技術文書ではないかもしれない。しかし、開発者の手元にあり、GitHubやHugging Face Hubというエコシステムの中心に位置しているという点で、最も効く文書である。

　文書は期待を作り、期待は責任を作る。Hugging FaceのModel Cardsは、README.mdという開発者の日常言語の中に、法的な足場を作ったといえる。境界物としての不完全さを抱えつつも、断片化しがちなAIの説明を一箇所に寄せ、更新可能な形で残そうとするその設計思想自体が、急速に変化するAI実務に必要な現実主義（Pragmatism）だと考える。我々は、この小さなテキストファイルを、単なる説明書としてではなく、社会と技術を結ぶ契約のひな型として捉え直す必要があるのではないか。

（マガジン）「AIと法-雑感」

　※目次は以下を参照

note総則規約3条2項前段
3.2 クリエイターが制作したデジタルコンテンツの著作権は、クリエイターに帰属します。