Claudeでモデルカードを作成する — 評価ログから根拠のある項目だけ埋める手順

モデルカードは、モデルに添える説明書です。何ができて、何に使ってはいけず、どのデータでどう測ったかを書きます。書く内容の大半は、手元の実験ログと評価結果にすでにあります。足りないのは、それを項目ごとの文章に起こす時間です。

この転記と文案づくりは、Claudeに任せられます。ただし、Claudeは評価ログを見ていない項目まで、もっともらしい文で埋めてしまうことがあります。そこでこの記事では、ログと弱点メモをProjectsに置き、根拠のある文だけを書かせ、数値は最後にスクリプトで照合する流れを組みます。

先に決める:Claudeが書く部分と、人が確定する部分

最初に分担を決めておくと、出力を見るときに迷いません。

線引きは単純です。ログに書いてあることの転記と構成はClaudeの仕事で、ログに無いことの断定は誰の仕事にもしません。

モデルカードの項目と、埋める材料の対応

項目の並びは、自社の様式があればそれに従います。無ければ、Hugging Faceのテンプレートを骨格にできます。Hugging Faceのドキュメントは、モデルカードに書くべき内容として次の5点を挙げています。

• モデル自体の説明
• 想定する用途と、起こりうる制約(バイアスや倫理的配慮を含む)
• 学習時のパラメータと実験情報
• 学習に使ったデータセット
• 評価結果

同社のテンプレートでは、これが次のような見出しに分かれます。見出しごとに、どの材料から埋めるかを決めておきます。

テンプレートの注記によると、Factorsは評価を何で分けて見たか(サブグループやドメイン)を書く欄です。Metricsは使った指標を、できれば理由とあわせて書く欄です。この2つがログに無いと、サブグループ別の性能は書けません。

テンプレートの各欄には、未記入の既定値として [More Information Needed] が入っています。この既定値をそのまま使うと、空欄が空欄だと読み手にも分かります。次の指示文で、この運用をClaudeに守らせます。

Projectsに置く4つの資料

Projectsは、独自のチャット履歴と知識ベースを持つ作業場です。アップロードした文書は、そのプロジェクトの全チャットで文脈になります。毎回同じ材料を参照するモデルカードの作成に向いています。無料アカウントでも使えますが、作れるプロジェクトは最大5つまでです。

知識に入れる資料は4つです。

1. 評価ログ(CSV。1行が1回の評価の結果)
2. 評価の設計メモ(テストデータの出所、指標を選んだ理由、分け方)
3. 弱点メモ(失敗した例、気づいた偏り、試して諦めたこと)
4. モデルカードの様式(自社様式、または上のテンプレート)

評価ログは、列を固定します。サブグループ別の性能を書くには、サブグループの列が要ります。架空の例を挙げます。

run_id,subgroup,metric,value,n
r07,all,accuracy,0.912,2400
r07,formal,accuracy,0.934,1100
r07,casual,accuracy,0.893,1300
r07,short_text,accuracy,0.841,380

この例は架空の分類モデルの値です。実際のログでは、n(件数)の列を必ず残します。件数が少ない行の数値は、そのまま文にすると過大に読まれるためです。

置き方で気をつける4点

• プロジェクトの名前と説明は、Claudeからは見えません。モデル名やバージョンは、設計メモの中に書きます
• 同じプロジェクトの別チャット同士で、会話の中身は引き継がれません。確定した文は知識に戻します
• プロジェクトの知識に入るファイルは、1ファイル30MBまでです。中身はテキスト抽出が基本なので、図を画像で埋め込んだ文書の図は読まれません
• XLSXを使うには、アカウントでコード実行とファイル作成を有効にする必要があります。ログはCSVで置くほうが素直です

有料プランでは、知識がコンテキストの上限に近づくと、Claudeが自動でRAGのモードに切り替えます。この仕組みはProjectsのRAG検索の解説にまとめています。モデルカードの材料は小さいことが多く、RAGが働く前の全文投入で収まる場合がほとんどです。

指示文:根拠の無い項目は埋めない

Projectsには「プロジェクトの指示」を設定できます。保存した指示は、そのプロジェクトのすべてのチャットで使われます。モデルカードでは、次の内容を入れます(下は例です)。

あなたはモデルカードの下書きを作る補助です。
- 文は、プロジェクトの資料に書かれた事実だけから作る
- 各文の末尾に、根拠にした資料名と行(例: eval_log.csv の run_id r07)を付ける
- 根拠が見つからない項目は、文を作らず「[根拠なし]」と書く
- 数値は資料の値をそのまま写す。丸め・平均・単位の換算は行わない
- 件数(n)が100未満の行は「件数が少ない」と注記する
- 弱点メモに無い弱点を推測で足さない
- 範囲外の用途は、弱点メモと失敗例から導けるものだけを書く

指示は短い箇条書きにします。長い散文だと、どの規則が守られたかを後から確認しづらくなります。末尾に根拠を付けさせる規則が要です。根拠の無い文が出たとき、その場で見つけられます。

手順:項目ごとに埋めて、根拠の欄を見る

一度に全項目を頼まず、項目ごとに依頼します。文の量が少ないほど、根拠の付け忘れに気づけます。

1. 評価結果(Results)を先に埋める

数字が確定している項目から始めます。依頼は「eval_log.csvのr07を、サブグループ別の表にしてください。nも載せてください」のように、ログの範囲を指定します。Claudeが返す表は、ログの行と1対1で突き合わせます。

例えば次のような形になります(上の架空ログに沿った形です)。

この表の後に、短い要約文を置きます。要約文は「short_textの値が全体より低い」のように、表から言えることに限ります。原因の説明は、弱点メモに書いてあるときだけ添えます。

2. 制約とリスクを弱点メモから起こす

弱点メモの箇条書きを、Bias, Risks, and Limitationsの欄の文にします。ここでClaudeに期待するのは言い換えと並べ替えで、新しい弱点の発見ではありません。

指示文に書いた通り、メモに無い弱点は足させません。Claudeが「一般にこの種のモデルでは〜が起こりえる」と書いてきたら、根拠の資料名が付いていないはずです。その文は消します。

3. 用途と範囲外の用途は、失敗例から線を引く

想定用途は設計メモから書けます。範囲外の用途は書きづらい欄です。失敗例のログと弱点メモから導けるものだけを書かせ、導けないものは [根拠なし] で残します。

例えば「短い文では精度が下がる」という弱点メモがあれば、「短文のみを入力とする用途は想定外」という記述の根拠になります。メモが無いのに範囲外を並べると、読み手には評価済みの事実に見えてしまいます。

4. 空欄を一覧にして、追加の評価を決める

最後に「[根拠なし]の項目を一覧にしてください」と頼みます。空欄の一覧は、そのまま次の評価計画になります。サブグループ別の欄が空なら、サブグループを分けた評価をまだ回していないという意味です。

根拠付きの文は、どう見えるか

指示文の通りに動いたときの形を、架空の例で示します。次のような文が並ぶのが目安です(公式の挙動ではなく、指示文で狙う形の例です)。

全体のaccuracyは0.912(n=2400)。[eval_log.csv の r07 / all]
short_textは0.841で、全体より低い。件数は380。[eval_log.csv の r07 / short_text]
短い入力で誤りが増える傾向がある。[weakness_notes.md の3項目目]
学習データの言語分布: [根拠なし]

末尾の角括弧が、読み手の確認先です。角括弧の指す行がログに無ければ、その文は書き直します。最後の行のように、資料に無い項目が [根拠なし] のまま残るのが正しい状態です。カードを公開する前に、角括弧は削除します。

数値の照合:文章でなくスクリプトで確かめる

Claudeに「数値は合っていますか」と聞き直しても、確認にはなりません。同じ材料を同じ読み方で見ているからです。数値の照合は、評価ログとモデルカードを機械的に突き合わせます。

次のスクリプトは、モデルカードに出てくる数字のうち、評価ログのどの値・件数とも一致しないものを列挙します。

import csv, re
 
card = open("model_card.md", encoding="utf-8").read()
log = set()
with open("eval_log.csv", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        log.update([row["value"], row["n"]])
 
for num in sorted(set(re.findall(r"\d+(?:\.\d+)?", card))):
    if num not in log:
        print("要確認:", num)

バージョン番号や日付も拾うため、出力には無関係な数字が混ざります。それでも、評価結果の欄にある数字がログに無いなら、丸め・写し間違い・Claudeの計算のどれかが起きています。ログの値を桁まで揃えて直し、もう一度実行して出力が空になるまで繰り返します。

評価を回し直したときの更新

モデルを更新して評価をやり直すたびに、カードの数字は古くなります。更新は、新しいログをプロジェクトの知識に足し、古いログとファイル名で区別するところから始めます。

指示文には「対象のrun_idは依頼で指定したものだけ」と書いておきます。指定が無いと、古い評価と新しい評価の値が同じ表に混ざることがあります。更新後のカードは、先ほどのスクリプトを新しいログで回し直し、出力が空になることで確かめます。

古いカードの文を残すかどうかは書き手が決めます。比較に価値があるなら、版ごとの結果を並べる表を作る手があります。その表も、行ごとにログの根拠を付けます。

つまずきやすい点

• ログにサブグループの列が無い。評価を回し直すか、サブグループ別の欄を空欄で出します。Claudeに推定で埋めさせると、実測でない数字がカードに載ります
• 学習データの説明が薄い。Training Dataの欄は、データの説明書が無いと書けません。出所と収集手順のメモを先に作ります
• Claudeが事実を作る。材料に無い内容を述べてしまう現象への対処は、Claudeが存在しない内容を述べる原因の整理が参考になります
• 材料が多くてアップロードできない。プロジェクトの知識は1ファイル30MBまでです。上限の全体像はClaudeのファイル上限にあります。巨大なログは、集計表だけを置きます
• 同じプロジェクトを複数のモデルで使い回す。評価ログのファイル名にモデル名とバージョンを入れ、指示文で「対象はファイル名のモデルのみ」と書きます

まとめ

モデルカードの下書きでClaudeに任せるのは、ログと弱点メモの転記と構成です。根拠を付けさせ、根拠が無い項目は [根拠なし] で残させると、空欄がそのまま次の評価計画になります。数値の照合は、文章ではなくスクリプトで行います。