AI モデル公開前のドキュメント不足を検出する？ NVIDIA MCG Toolkit の仕組みを整理してみた
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
NVIDIA の技術ブログで How to Automate AI Model Documentation with the NVIDIA MCG Toolkit という記事が公開されていました。AI モデルのドキュメント、いわゆるモデルカードを自動生成するツールの紹介なのですが、読み進めるうちに「これは単なる生成ツールというより、公開前のドキュメントの穴を見つける道具として面白いな」と感じたので、自分なりに整理してみます。
MCG Toolkit 本体はまだ早期アクセス段階で、まだ手元で動かせる状態ではないため、今回は「AI モデルを公開・採用するときの説明責任をどう仕組み化するか」という、ツール紹介より一段広い視点でまとめてみました。
AI モデルにも出荷前ドキュメントが要る時代になってきた
ソフトウェアを世に出すときに README や API ドキュメントを書くのは当たり前になりました。これと同じことが、AI モデルにも求められはじめています。
背景にあるのが規制の動きです。米国カリフォルニア州の AB-2013（Generative Artificial Intelligence: Training Data Transparency Act）は 2026 年 1 月 1 日に施行され、生成 AI の開発者に対して学習データの概要、データ点数、著作物の有無、個人情報の扱いといった情報の開示を求めます。EU AI Act も透明性要件や学習データの著作権サマリ公表を要求しており、「モデルを作って公開する」だけでは済まない流れが固まりつつあります。
ここで説明できる必要があるのは、ざっとこういった項目です。
- 何のためのモデルか（想定用途）
- どんなデータで学習されたか
- どの用途に向いているか、向いていないか
- 制限やリスクは何か
- バイアス、プライバシー、安全性をどう扱っているか
これらを整理したものが、もともと「モデルカード」と呼ばれてきた文書です。NVIDIA は以前からモデルカードによる透明性の取り組みを進めていて、今回の MCG Toolkit はその延長線上にあります。読者として想定されているのも開発者だけではありません。調達担当、リスク評価、ポリシー担当といった、モデルを採用するかどうかを判断する人たちが含まれます。ここがソフトウェアの README とは少し毛色の違うところで、AI モデルのドキュメントは「監査される前提の文書」になっているわけです。
モデルカードと Model Card++ という形式
従来のモデルカードは、モデルの用途・性能・制約・ライセンスなどを 1 枚にまとめた文書でした。MCG Toolkit が生成するのは、これを拡張した Model Card++ という形式です。
Model Card++ は Overview に加えて、4 つのサブカードを持ちます。
ポイントは、単なるモデル概要で終わらず、バイアス・説明可能性・プライバシー・安全性という、リスクと説明責任にかかわる観点を独立した区画として持っている点です。規制が気にするのはまさにこのあたりなので、最初からこの 4 区画を埋める前提になっているのは合理的だと思います。
もう 1 つ細かいですが大事なのが、出力が CycloneDX 準拠の構造化 JSON を経由して Markdown 化される点です。CycloneDX は SBOM（Software Bill of Materials）で使われる標準で、AI モデルの文書を機械可読な形で他システムと連携させやすくなります。人間が読む Markdown と、ツールが処理する JSON の両方を出せる、という整理です。
NVIDIA MCG Toolkit とは何か
MCG は Model Card Generator の略で、その名のとおりモデルカードを生成するツールです。一番の特徴は、ゼロから手で書くのではなく、既存のソースから直接読み取って生成するところにあります。
入力として受け付けるのは、次の 2 系統です。
- URL 指定: GitHub / GitLab / Hugging Face / 任意の公開 Web ページ
- ファイルアップロード: ZIP / PDF / DOCX / Markdown
つまり、既にあるリポジトリや資料をそのまま放り込めば、そこからモデルカードの草案を起こしてくれる、という発想です。操作はインタラクティブな UI に加えて REST API も用意されているので、手動レビューにも CI/CD への組み込みにも使えます。
MCG Toolkit 本体は現時点で早期アクセス段階ですが、生成物のひな型である Model Card++ テンプレートや各種透明性カードは、NVIDIA/Trustworthy-AI というリポジトリでオープンソース公開されています。ツール本体を待たずに、テンプレートだけ先に触ってみることはできる、という状態です。
仕組みを 3 段のパイプラインで読む
MCG Toolkit はコンテナ化されたパイプラインで、Ingestion（取り込み）→ Extraction（抽出）→ Rendering（描画）の 3 段で構成されています。中央のオーケストレーターが URL やファイルのリクエストを受け取り、各ステージを順に呼び出します。
NVIDIA 公式のアーキテクチャ図は元記事の Figure 1 にまとまっているので、あわせて眺めると全体の流れがつかみやすいと思います。各段をざっくり追うと、こうなります。
Ingestion では、入力を取得してチャンクに分割し、ドキュメント・設定ファイル・コードという種別に分類します。Extraction では、その分類済みチャンクを RAG（Retrieval-Augmented Generation）パイプラインに通します。ここで NVIDIA の推論マイクロサービス（NIM）上に乗った Nemotron RAG が embedding（llama-nemotron-embed-1b-v2）と reranking（llama-nemotron-rerank-500m-v2）を担い、抽出の中核は GPT-OSS-120B が受け持ちます。コード・設定・ドキュメントで別々の retriever を使い、信号の濃いソースを優先する作りになっているのが細かい工夫です。
ここで自分が一番うなずいたのが、抽出結果をそのまま採用せず validation のステップを挟む点です。出力を JSON として確定する前にチェックが入り、確信を持って埋められないフィールドは無理に推測しません。「not found」「information not available」と明示します。最後に Rendering で構造化 JSON を Markdown テンプレートに流し込み、Overview と 4 サブカードを含む完成形を出力します。
生成ツールというより、ドキュメントの穴を見つける道具
MCG Toolkit は「モデルカードを書いてくれるツール」であると同時に、「公開前のドキュメントがどれだけ足りないかを可視化するツール」として使えます。
それがはっきり出ているのが、NVIDIA 自身が公開している実験結果です。まず、公開モデルのリポジトリを標準テストにかけたときの、MC++ Overview 生成の結果がこちらです。
| モデル | 生成時間 | Completion | Accuracy |
|---|---|---|---|
| NVIDIA Nemotron Nano 8B | 56 秒 | 97% | 92% |
| NVIDIA Cosmos Reason 2 | 86 秒 | 94% | 82% |
| NVIDIA Parakeet | 65 秒 | 92% | 87% |
| NVIDIA Proteina | 52 秒 | 94% | 82% |
| 第三者モデル（DeepSeek-V3 / Evo2 / Gemma / Llama） | 約 80 秒 | 約 89% | 約 80% |
Completion は意味のある内容で埋まったフィールドの割合、Accuracy はプレースホルダーでない回答のうち正しかった割合です。多くのリポジトリで 1 分前後、completion は NVIDIA モデルで 92〜97%、accuracy も 80〜92% に収まっていて、全体では completion 91% / accuracy 76% でした。
ここで面白いのが、ドキュメントを削ったときの変化です。同じリポジトリからドキュメント（.pdf / .md / .txt）をすべて削除し、コードだけを残して再処理したところ、5 モデルの平均で completion rate が 91% から 61% へ、検証可能なフィールドだけで測った strict accuracy が 76% から 28% へ落ちました。
この数字の読み方が大事だと思っています。completion が 61% でも残るのは、コード・設定ファイル・リポジトリ構造だけからでも、ツールがそれなりに意味のある情報を拾えるからです。一方で accuracy が大きく落ちるのは、フィールドを正しく埋めるにはドキュメントの寄与が大きい、ということを示しています。言い換えると、良い README や設定ファイルが、良いモデルカードを作るわけです。
そして先ほどの validation の挙動が効いてきます。情報が足りなければ推測で埋めず穴として示すので、できあがったモデルカードを見れば「どこが説明不足のまま公開されようとしているか」が一目でわかります。実務での落としどころとしては、こんなところが考えられます。
- リリース前チェックとして、公開直前にドキュメントの抜けを洗い出す
- CI/CD のリリースゲートに組み込み、空欄が多いと止める
- 他社モデルを採用するときの審査資料として、説明の充実度を測る
- 顧客向けの説明資料のたたき台として使う
「生成して終わり」ではなく「足りないところを突きつけてくれる」点が、ドキュメントを書いている最中のチームにとってもありがたいわけです。
AI ガバナンスと説明責任の観点で見る
4 つのサブカード（Bias / Explainability / Privacy / Safety & Security）を、規制対応という文脈で改めて眺めてみます。
冒頭で触れた AB-2013 や EU AI Act が求めるのは、ざっくり言えば「このモデルは何で学習され、どんなリスクを持ち、どう扱えば安全か」を説明できることです。Model Card++ のサブカードは、この問いにほぼ 1 対 1 で対応しています。Privacy はデータの取り扱いと個人情報の扱いを、Bias は偏りの分析を、Safety & Security は安全性とセキュリティを、Explainability は判断根拠の説明可能性を受け持ちます。規制要件を満たすために何を書けばいいか迷ったとき、この区画割りそのものがチェックリストとして機能します。
もう 1 つ、自分が現場目線で大事だと思うのは、これが開発チームだけの文書ではない点です。製造業の案件でも、AI を入れるかどうかを決めるのは現場のエンジニアだけではなく、品質保証や調達、ときには法務が絡みます。そういう人たちが「このモデルは使って大丈夫か」を判断するための共通言語として、構造化されたモデルカードは効いてきます。手書きの README だと人によって粒度がバラバラになりますが、決まったフォーマットで揃っていれば比較も監査もしやすくなります。
自社環境で動かせる作りと、応用の広げ方
ガバナンス文書を扱う以上、データをどこで処理するかは無視できません。モデルのコードや社内資料を外部の SaaS に投げるのは、機密性の観点で避けたい場面が多いはずです。
MCG Toolkit はこの点に配慮した作りになっています。コンテナ化されたサービスとして提供され、ワンコマンドでセットアップできます。オーケストレーター・Ingestion・Extraction・サブカード生成の各ステージが別々のコンテナとして動き、データベースとタスクキューも同梱されます。特定クラウドへのロックインはなく、オンプレミス・自社クラウド・Kubernetes のいずれでも動かせる、とされています。機密性の高いモデルや社内コードを扱う場合に、自社の管理下で完結できるのは大きいです。
実例として、Oracle が最初のパートナーの 1 つとして本番インフラに統合しています。OCI の Kubernetes（OKE）上に MCG ポッドと NIM ポッドを配置し、抽出モデルには Llama-3.3-Nemotron-Super-49B-v1 を採用、Nemotron RAG が embedding と reranking を担い、GPT-OSS-120B は専用 AI クラスタ（2×H100）とオンデマンドの両方でホスト・検証された、という構成です。なかなか本格的な構成で、業務での実運用が前提になっていることが伝わってきます。
応用の広げ方として面白いのが、3 つの軸で差し替えができる点です。
- モデル: 言語モデル・embedding・reranking のエンドポイントを差し替えられる。性能・コスト・データ所在地の要件に合わせて別の NIM や互換 API を指定できる
- テンプレート: 出力は Markdown テンプレートで決まるため、Model Card++ だけでなく社内標準や新しい規制フォーマットに合わせて差し替えられる。抽出ロジックには手を入れない
- ガイド: 何を拾い、どう書くかというフィールド単位のガイドを、知識ベースとして更新できる。規制や業界要件が変わっても本体コードを触らずに追従できる
ここまで分離されていると、Model Card++ をそのまま使うだけでなく、自社の AI 審査プロセス用テンプレートや業界別のチェックリストに仕立て直す、といった使い方も見えてきます。新しい開示要件が出てきたら、パイプラインではなくテンプレートとガイドを更新すればいい、という設計思想は実務に優しいと思います。
まとめ
NVIDIA MCG Toolkit を、ツール紹介ではなく「AI モデルの公開・監査プロセスをどう仕組み化するか」という視点で整理してきました。要点を 4 つにまとめます。
ひとつ目は、AI モデルにも出荷前のドキュメントが求められる時代になってきたということです。AB-2013 や EU AI Act を背景に、モデルカードは監査される前提の文書になりつつあります。
ふたつ目は、MCG Toolkit が既存のリポジトリや資料から Model Card++ を生成し、Overview に加えてバイアス・説明可能性・プライバシー・安全性という説明責任の区画を最初から埋めにいく作りだということです。
3 つ目は、このツールが生成器であると同時に、ドキュメントの穴を見つける道具として使えるということです。情報が足りなければ推測せず「not found」と返すので、公開前にどこが説明不足かが見えます。ドキュメントを削るだけで accuracy が 76% から 28% まで落ちる数字は、良いドキュメントが良いモデルカードを作るという当たり前を改めて示しています。
4 つ目は、コンテナ化されていてオンプレや自社クラウドで完結でき、モデル・テンプレート・ガイドを差し替えられるため、社内の AI ガバナンスや審査プロセスに合わせて育てていける、ということです。
現場で「このモデルを採用していいか」「自社モデルを公開して大丈夫か」を判断する場面は、これから確実に増えていきます。そのときに、決まったフォーマットで説明を揃え、足りないところを機械的に洗い出せる仕組みがあると、議論がだいぶ進めやすくなるはずです。AI モデルの開発そのものだけでなく、公開のプロセスも自動化の対象になってきた、という流れを感じる記事でした。ツールが広く使えるようになったら、実際に動かして確かめてみたいですね。
参考リンク
- How to Automate AI Model Documentation with the NVIDIA MCG Toolkit | NVIDIA Technical Blog
- NVIDIA/Trustworthy-AI（Model Card++ テンプレート / GitHub）
- Enhancing AI Transparency and Ethical Considerations with Model Card | NVIDIA Technical Blog
- NVIDIA Nemotron RAG（Hugging Face Collection）
- CycloneDX
- California AB-2013（Generative AI: Training Data Transparency）
