📍 AIのしくみ地図 — 18/29章

この記事はAIの基礎からMeta-Harness·応用比較まで順に読む全29章シリーズの18章目です。
📚 全体地図を見る

← 前の章: M4. Harness · 次の章: M6. Autoresearch →

Table of Contents

「Claudeがもっと良くなった」が危ない言葉である理由

0. シリーズの現在地 — 実務セクションMの5本目

FIG. 「良くなった」の罠

以前のスコア

平均的で安定

「改善」後

一指標だけ突出・他は同じ

一指標が上がった=良くなった、ではない。どの分布で上がったか・他指標は下がってないかを同時に見る

AIのしくみ地図 M シリーズも、いつのまにか5本目です。M1 で retrieval の4階を掴み、M2 で long-context と memory、M3 で agent と LLM の境界線、M4 でハーネスを部品単位まで解いてきました。今回は、その流れの関節のような位置にある回です。なぜかというと、M1〜M4 を読み終わると「agent を改善する」「ハーネスをチューニングする」という言い回しがずっとついて回ります。ところが 「良くなった」という判定そのものを何で下すのか を先に固めておかないと、その次の回がぜんぶ空中に浮いてしまうんです。

この記事を読み終えたら、次の3つが自分の手に馴染んでいるはずです。

「今月 agent を改善しました」という言葉を聞いて、何を基準に良くなったのか を聞き返せる
Benchmark・task-specific・production eval という3層が、それぞれ何を測っていて、どこで裏切るのかの感覚がつく
DSPy のような自動最適化フレームワークが、なぜ評価の上にしか乗れないのかが理解できる

M6(autoresearch)と M7(Meta-Harness)は 全部この評価構造の上でしか回りません。今回の記事は、道具箱の役割を担います。

1. 「Claudeが前より賢くなった」という言葉が危ない理由

開発者コミュニティでよく流れてくる一文があります。「最近の Claude、ほんとに良くなってない?」「GPT-5 より Claude 4.7 のほうがコーディングは上だった。」私自身もこういう言い方をよくしますし、よく聞きます。日常会話としては、なんの問題もありません。

でもこの言葉を プロダクト改善の根拠 として使うと危なくなります。「良くなった」という言葉には基準がないからです。基準のないまま「良くなった」を転がし続けると、3つの故障が起きます。

ひとつめ、無限ループ。いつ止めればいいか分からないので、ずっとチューニングし続けます。昨日はプロンプトを変え、今日はツール定義を変え、明日はモデルを変える。でも昨日と今日を比べる共通のものさしがないので、本当に良くなったのか分からない。だからまた変える。サイクルが止まりません。

ふたつめ、悪い方向にも進み続ける。基準があって初めて「この方向は違う」が出てきます。無いと、体感に頼ることになる。体感は裏切ります。昨日うまくいっていたケースで今日もうまくいけば「良くなった」と感じる。ところが実際には、昨日うまくいっていた他の10ケースで今日はぜんぶ壊れているかもしれない。体感だけではその裏面が見えません。

みっつめ、改善錯覚。その場にいるのに良くなったと信じている状態。これが一番こわい。評価なしで働くと、脳が勝手に「良くなった」という物語を作ってくれる。その物語を根拠に次の決定を下していくので、失敗が複利で積もります。

だから self-improving loop の話をするには、「良くなった」を判定する基準が先にないと いけない。この基準が回るのが evaluation で、その基準点を上げていく活動が optimization です。このふたつを1本の記事に束ねて扱う理由は、基準なしには最適化が不可能 だからです。順序があります。まず的、次に矢。

2. Evaluation は「的の定義」から — ダーツの比喩で感覚を掴む

いちばん単純な比喩で始めます。ダーツを投げると想像してみてください。

壁に円盤があります。真ん中に赤い円があって、その周りに広がっていく輪がある。真ん中が50点、外に行くほど点数が下がる。あなたはダーツを投げます。刺さった位置の点数を足して、勝ち負けを決めます。

この構造で一番大事なものは何でしょう。投げる人の腕? ダーツの重さ? 違います。壁に的が描かれている、ということ です。

的のない壁にダーツをいくらうまく投げても点数は出ません。「真ん中に当たった」を判定する基準がないからです。投げた人が後から「今のが真ん中だよ」と言っても意味がないし、別の人が「いやこっちが的だ」と言っても反論できない。

LLM の評価も、これとまったく同じです。的 = 評価基準。これが無いと、モデルが出した答えがどんなに見映え良く見えても「良い」と宣言する根拠がありません。逆に、的が定義されていれば、一見平凡な答えでも「この的に対して何点か」は正確に出ます。

だから評価設計のほぼ半分は 「的をどう描くか」 です。どんな入力を与えるか、どんな出力を期待するか、当たったかどうかをどう測るか。これを先に決めずに「とりあえず回して、あとは感覚で見ます」という人が、思っているより多い。その瞬間、評価は評価ではなくて主観に化けます。

ダーツの比喩をもう一押しすると、的には 大きさと位置がちゃんとあります。真ん中がどこか、輪がいくつあるか、一輪あたり何点か、全部決まっているから点数が出る。評価も同じように具体的でないとダメです。「答えが OK ならいい」は的じゃありません。「答えが JSON 形式を守り、3つの必須フィールドを含み、数値の誤差が1%以内なら満点」みたいなものが、ちゃんとした的です。この具体性が抜けると、評価を回しても数字だけが出てきて判断ができません。

3. 評価の3つの層 — 地図を広げる

的が一種類じゃないという話に入ります。実務では評価は 3層で動きます。各層が別の問いに答えます。

3-1. Benchmark evaluation — 「一般的にうまいか」

最初の層は 公式 benchmark です。業界が共通で使っている標準テスト。代表的なもので MMLU(言語知識全般)、SWE-bench(実際の GitHub イシュー解決)、GSM8K(小学算数)、HumanEval(Python コーディング)などがあります。

これは大学受験みたいなものです。全国の受験生が同じ問題を解き、同じ採点基準で点数が出る。だから モデル同士の比較 には便利です。Claude 4.7 が GPT-5 より SWE-bench で何%上、みたいな話が記事に出てくるのは benchmark のおかげです。

強みは 比較可能性。弱みは 自分の問題じゃない こと。うちの会社の実務は MMLU の一般常識問題ではないし、SWE-bench の OSS リポのイシューでもありません。なのに benchmark の点数が上がったというニュースだけを見てモデルを乗り換えると、いざ自分の実務では同じか悪化する、ということがよく起きます。

3-2. Task-specific evaluation — 「自分の仕事にうまいか」

2つめの層は 自分で作った的 です。自分がやりたい作業に合わせて自分で組む評価セット。これを golden set と呼んだり eval set と呼んだりします。

例として、私はブログ運営 agent を使っています。週に数本の記事を書いて発行する。この agent が「良くなった」を判定するには何が必要でしょう。MMLU のスコア? 意味ない。SWE-bench? 関係なし。必要なのは 「先月書いた記事30本のうち SEO 81点を超えた割合」 みたいなものです。そこにスタイルガイド違反率、壊れリンク混入率、発行後の修正回数みたいなものを足していく。

これが task-specific eval です。Benchmark が世の中共通の的なら、こっちは自分の壁に自分で描いた的です。

3-3. Production eval (A/B) — 「実ユーザーにうまいか」

3つめの層は 実使用データ です。Offline のテストではなくて、本物のユーザートラフィックにモデルを乗せて結果を測ります。いちばんよくある形は A/B テスト。ユーザーの半分には前バージョンを、半分には新バージョンを使わせて、満足度・完了率・再利用率みたいな指標を比べる。

この層が3つの中でいちばん信用できます。本物のユーザー が 本物の文脈 で 本物の結果 を作った数字だから。ただ、いちばん遅くていちばん高い。回すには実トラフィックが要るし、統計的に有意になるまで時間がかかるし、間違ったバージョンを出すと実損害が出ます。

3層の性格差を表にまとめておきます。

層	問い	速さ	コスト	信頼度
Benchmark	一般的にうまいか	速い	低い	比較用・中
Task-specific	自分の作業にうまいか	中	中	実務的に高い
Production A/B	実ユーザーにうまいか	遅い	高い	最終判定

実務で健全な構造は3層を 順番に 使うことです。Benchmark で候補モデルをふるいにかけ、task-specific で自分の作業に合うかを見て、最後に production A/B で最終判定。1層だけ見て決めると、後ろで必ず穴が開きます。

4. Benchmark の罠 — 「点数は上がったのに実務はなぜ駄目なんだ」

Benchmark をもう一歩掘ります。この層で騙される人が一番多いからです。

罠1: Contamination(汚染)。モデルが学習する際に、benchmark の問題が訓練データに混ざり込んだ可能性がある。すると試験を受けるのではなく、覚えた答えを復元しているだけになります。点数が高くても、それが本物の実力か判別できない。実際、公開 benchmark は答えごとネットに出回っているものが多く、大規模モデルの訓練コーパスに偶然であれ意図的であれ混ざる可能性がずっと指摘されています。

罠2: Over-specialization(過適合)。モデルを作った側がその benchmark で点数が出るように特別にチューニングしているかもしれません。その benchmark の形式にぴったり合う答えを返すのはうまいのに、少し形式が変わるとがくっと落ちる、ということが起きます。SWE-bench のスコアがいいモデルが、SWE-bench と少し違うスタイルのバグ修正では平凡、というケースがある。

罠3: Narrow task coverage(狭い課題範囲)。Benchmark は結局 特定の課題 に対するスコアです。SWE-bench は「GitHub に上がっている OSS リポのバグイシューを解決する作業」しか測っていない。ところがあなたの実務は、もしかしたら「社内モノリシックアプリの DB マイグレーションスクリプト修正」かもしれない。見かけ上は同じ「コーディング」でも性格がまったく違います。SWE-bench のスコアが高いからといって、あなたのマイグレーション作業に強いモデルとは限らない。

SWE-bench は具体例としてもう一段掘る価値があります。2024〜2025 年の間に複数のモデルが SWE-bench でスコアを大きく伸ばしました。そのニュースを見たチームがそのモデルに乗り換えたところ、実務ではむしろ回帰が出た事例が広まりました。なぜかというと、SWE-bench はテストが既にある OSS プロジェクトで「失敗しているテストを通す作業」に集中しているからです。これは非常に特殊な形の修正作業です。実務では、テストがないコードを直すケース、直す前にまず再現が要るケース、サイドエフェクトが決定打になるケースのほうがずっと多い。Benchmark はこの多様性をカバーしていません。

この層での教訓を一文で。「Benchmark は比較用であって決定用ではない。」 ニュースで点数が上がったと聞いても、乗り換える前に必ず次の層を回してみるべきです。

5. Task-specific eval — 自分の作業に合う的の作り方

2つめの層が実務者にとって一番大事な層です。ほとんどの改善サイクルはここで回ります。どう作るかを少し具体的に見ます。

5-1. Golden set の構成

Golden set は 代表入力と期待出力のペア の束です。少なくて20〜30個、多ければ数百個。少なすぎると標本が小さくてぶれ、多すぎると回すたびのコストが効いてくる。始めるときは30〜50個で十分です。

大事なのは 多様性 です。簡単なケースばかり入れるとスコアは100点で張り付いて改善が見えない。難しいケースばかりだとスコアが動かずに折れる。簡単・中・難しい・エッジケースをバランスよく混ぜて、初めてスコアが意味のある動き方をします。実務ログで実際に起きた失敗事例を必ず数件入れておくのが良い。

5-2. Rubric — 採点基準の文書化

Rubric は 「どう採点するか」 を文章に起こしたものです。「答えが合っていれば満点」のようにぼかしてはいけません。「答えに X が含まれていれば1点、X が含まれかつ Y の順序で述べられていれば2点、X・Y・Z がぜんぶ揃えば3点」のように段階別に書く。複数の人が同じ答えを採点しても同じ点数に揃うようにするのが目標です。

Rubric がよく設計されていると、採点者が誰でも、機械であっても似たような点数が出てきます。この性質が次のステップに繋がります。

5-3. LLM-as-judge — 判定を自動化する

人の手で毎回採点するのは高い。50個の golden set を週2回回すと週100件採点することになる。長続きしません。そこで登場するのが LLM-as-judge です。

構造は単純です。評価用 LLM(通常は一番強いモデル)に、rubric と入力・期待答え・実際の答えを渡して、「この答えを rubric に沿って採点して」と指示する。すると数字が返ってくる。この数字を信じていいかを人間がサンプルで検品する、という構造。Anthropic の評価ガイドや複数の研究報告で、LLM-as-judge は人間採点とかなり高い相関を示すと報告されています。100%ではないけれど、80〜90%程度は一致する。

注意点があります。判定モデルと評価対象モデルに同じものを使うとバイアスが出ます。自分が作った答えを自分で採点する格好になるので、自分のスタイルの答えに甘い点数をつける傾向が出る。判定用は別モデルを使うか、少なくとも別バージョンを使うのが推奨です。

LLM-as-judge でパイプラインを組んでおくと、コードを1回回せば点数が自動で出る 構造になります。この構造があって初めて最適化が回ります。最適化というのは基本的に「点数を繰り返し測り直す活動」だからです。

6. Optimization は「的に合わせる学習」

評価が的なら、最適化は その的に合わせようとしてフォームを変え続ける活動 です。評価点を上げるあらゆる行動が optimization に入ります。

実務で最適化が行われる代表的なレイヤーをいくつか。

プロンプト最適化: system prompt、few-shot 例、出力フォーマット指示を変えて、スコアが上がる組み合わせを探す
Hyperparameter チューニング: temperature、max tokens、top-p など生成パラメータを変える
ツール定義の改善: agent が使う tool の名前・説明・パラメータスペックを磨く(M4 のハーネス改善に繋がる)
Retrieval の改善: RAG を使う場合、chunk サイズ・埋め込みモデル・再ランカーを変える
モデル交換: モデル自体を別バージョンに変える

これら全部に共通して必要なのが 「変える前のスコアと変えた後のスコアを比較できる状態」 です。評価なしでこれをやろうとすると勘でやるしかないのですが、勘は裏切ると先ほど書いた通り。

そしてこれらの活動が可能になると、自然に浮かぶ問いがあります。「これ自動で回せないか?」。人間が毎回プロンプトを変えながら点数を測るのは疲れる作業です。ここで 自動最適化フレームワーク が登場します。

7. DSPy — プロンプトを gradient のように optimize する

DSPy は Stanford NLP グループ発のフレームワークです。2023年から使われ始めて、今は agent 設計界隈でほぼ標準に近い位置にあります。

1行で言うと、プロンプトを人が手で磨く代わりに、評価データだけ渡せば自動で最適化してくれる道具。

構造を簡単に。

使う側は 作業を関数のように宣言 します。「入力 X が入ったら出力 Y を返せ」というシグネチャ。
使う側は 評価関数 を渡します。「この出力がどれだけ良いか」を数字で返す関数。ここに前節の golden set・rubric・LLM-as-judge を差し込む。
使う側は 学習データ(input, 期待 output)の例 をいくつか渡します。
DSPy が 複数のプロンプト変形を試し、評価スコアを基準にもっと良いプロンプトを見つけてくれる。BootstrapFewShot、MIPRO みたいな optimizer が内部で回る。

感覚的に言うと、ニューラルネットを gradient descent で学習させるように、プロンプトを gradient 似の信号で学習 させている。違いは、連続値の重みの代わりに離散値のプロンプトテキストを動かしているだけです。

これがなぜ重要かと言うと、M7 で扱う Meta-Harness の中核部品のひとつがこれだからです。Meta-Harness は「ハーネスが自分自身を改善する」という概念で、その自己改善エンジンのひとつが DSPy のような自動プロンプト最適化です。そして DSPy が回るには 評価関数 が必ず要る。評価がないと DSPy は一歩も動けない。この依存関係が、今回の記事が存在する理由です。

8. Eval がないと self-improving が錯覚になる理由 — 事例3つ

抽象の話だけだと染み込まないので、具体的な事例を3つ。架空のチームですが、現場で本当によくあるパターンです。

事例 A: 「プロンプトを改善したのに指標が下がる」

ブログ生成 agent を運営するチーム。記事の品質を上げようと、system prompt に「事実確認ルール」をびっしり追加した。読んでみるとずっと慎重な記事を書いてくれる。チーム内で「改善された」と合意が出来ました。

3週間後に月次分析を回すと、月間 PV が 18% 落ちていた。理由は、あの慎重な口調のせいで記事が全部似たように平板になってしまったから。SEO 上はよく見えたけれど、読者は数行読んで離脱していました。

何が抜けていたか: Task-specific eval に「読者の滞在時間」や「文体の多様性」が入っていなかった。「事実正確性」だけを測っていた。片側の的しか立てていなかったわけです。

事例 B: 「新モデルに変えたら解約が増えた」

カスタマー応答 agent を運営する SaaS チーム。ベンチマーク点がいいと紹介された新モデルに乗り換えた。応答速度が速くなり、応答品質も社内 QA の評価で上がった。「アップグレード成功」でリリース。

1ヶ月後、解約率が目に見えて上がっていた。調べると、新モデルは旧モデルよりユーザーのミスを正確に指摘する傾向があった。正確ではあるけれど冷たく響いていた。旧モデルは不正確でも温かくて、ユーザーは温かさのほうを望んでいた。

何が抜けていたか: Production eval がなかった。Offline ベンチマークと社内 QA の評価だけ信じて、実ユーザーの行動指標を A/B で測っていなかった。

事例 C: 「毎週ハーネスを直しているのに、作業が遅くなっている気がする」

Agent ハーネスをずっとチューニングしている1人開発者。毎週 skill を追加し、hook を足し、permission を締めている。当人は「ずっと良くなっている」と感じていた。

6ヶ月後に振り返ると、最初より作業完了時間が 30% 伸びていた。ハーネスがだんだん複雑になり、agent が毎回チェックすべきルールが多すぎて、小さな作業ひとつに呼び出し数が爆発していた。

何が抜けていたか: ハーネス変更の前後での 「代表作業サンプル10個」の golden set がなかった。感覚だけで「良くなった」と感じていて、実際の時間・呼び出し数・コストが測られたことがなかった。

3事例の共通の病因: 評価がない、評価の軸がひとつしかない、または offline で終わっている。このうちどれかを落とすと、self-improving は物語としてしか存在しなくなります。

9. 評価設計でよくある失敗5つ

ここで、評価設計が 実際にどう崩れるか を整理しておきます。私自身もよくはまる罠なので、ノートみたいに書いておいてたまに開きます。

(a) Test set leakage。モデルが学習中に eval set の答えを見たことがある状態。点数が上がっても、本物の実力か覚えただけかが分からない。公開 benchmark は特にこのリスクが大きいし、自分の golden set でもモデルに一度見せてフィードバックを貰うループの中に置いておくと leakage が発生します。解決は 学習用と評価用のデータを厳格に分けること。自分の eval set は評価目的のみに使い、プロンプトチューニングには別の dev set を使う。

(b) Single metric 固定 — Goodhart の法則。「測定値が目標になると、良い測定値ではなくなる」という法則です。1つの指標だけ見ると、モデルがその指標だけ上がるように最適化されてしまう。例えば「答えの正確性」だけ見ると、答えが短くなり親切さが消える。解決は 互いに牽制する指標を複数 一緒に見ること。正確性と長さ、正確性とユーザー満足度、速度とコスト、みたいに相反するペアを2〜3組セットで見る。

(c) 自動評価だけ信じる。LLM-as-judge が楽だからと自動だけで点数を見ていると、判定モデルの弱みがそのまま評価に焼き付きます。人間のサンプル検品を入れないと判定バイアスが積もっていく。解決は 定期的に人の目でサンプリング を混ぜること。週に30件のうち5件は人間が直接読む、というくらい。

(d) Production 評価なし。事例 B のケース。Offline のスコアだけで出すと、実使用の文脈で壊れる。解決は 可能な限り実使用の A/B か canary デプロイ を通すこと。トラフィックが小さくてもゆっくり流してみる。

(e) コストと遅延を無視。正確性だけ見てコスト・応答遅延を見ないと、使えないモデルを選んでしまう。秒あたりコストが2倍で応答遅延が3倍なのに正確性が3%しか高くないモデルは、実務では損です。解決は コスト・遅延を指標の束に必ず含める こと。指標が増える代わりに現実的な決定になります。

この5つは一度はまった人だけが分かる罠です。初めて評価を組む人は、たいてい (b) と (e) から倒れます。

10. Claude Code の verification loop がなぜ良い評価設計なのか

抽象から実務に一段降ります。Claude Code の verification loop は、実はよく作られた評価構造です。M4 でハーネスの8階の最後として軽く触れましたが、評価の観点で見直すと、なぜ優れているかが理解できます。

Claude Code は作業が終わったと判定する前に、3つの関門を通します。

自動 lint・フォーマット: 決められたスタイルをコードが守っているかを機械が採点
テスト実行: 該当ファイル関連のテストを回してパスするか確認
人の承認: 上2つが通っても最後は人間が見る

この3層が、先ほどの評価3層と綺麗に対応します。

Lint は 自動 benchmark の性格。客観的ルールへの速い判定。
テストは task-specific eval。このプロジェクトに合わせてチームが自分で書いた的。
人の承認は production eval の縮小版。実使用の文脈を知っている人間が最終判定。

そしてこの3層が 「全部通過しないと次に進めない」 という AND ゲートで結ばれている。どれか1層だけ通ってもダメ、1層でも落ちたら止まる。これが評価設計として非常に健全な形です。Goodhart の罠を自然に避けられている。どれか1つの指標だけで「良くなった」を宣言できない構造なので。

おまけに、この3層は コスト・遅延が低いものから高いものへ 並んでいます。Lint が一番安くて速いから先に走り、テストが中間、人の承認が一番高くて遅い。安い関門で引っかかれば高い関門まで行かないので、全体コストが最小化される。評価パイプライン設計の良い例としてよく引かれる理由です。

この構造をあなたのチームの agent に移植するのは難しくありません。自動ルールチェック・自分の eval set・人間のサンプル検品、この3層を AND で束ねればいい。

毎週月曜日、AIトレンドニュースレター配信中

会員登録すると、毎週月曜日に「今週のAI・バイブコーディング最新情報」をお届けします。
バナー広告なし・本当に役立つ情報だけを厳選するクリーンなAI専門メディアです。

ニュースレター登録(無料・30秒)→

11. Autoresearch・Meta-Harness の予告 — eval があって次の2編が成り立つ

今回の最後の席です。なぜ M5 を M6・M7 の前に置いたかを整理します。

M6 — Autoresearch。Agent が自分でリサーチして、自分で結果を整える構造です。でも「整える」ためには 「この結果は良いのか」 を自分で判定できないといけません。判定というのは評価のこと。評価関数がないと autoresearch はただの無限ループになる。検索して答えて、また検索して答えて、と、止まる場所がなくなります。

M7 — Meta-Harness。ハーネスが自分自身を改善する構造です。これが回るには「改善された」を測るものさしが必要で、そのものさしが評価指標です。DSPy のようなフレームワークは、そのものさしをエンジンに内蔵している。評価がないと Meta-Harness は概念としてしか存在できず、回りません。

順序はこうです。評価(M5) → autoresearch(M6) → Meta-Harness(M7)。この順序を逆にしても物語としては繋がりますが、実務で回そうとすると M5 が底にないと残りがぜんぶ揺れます。

12. 締めの一文と次に読むもの

「良くなった」は感覚ではなく、的に対する点数だ。この一文を今回持って帰ってもらえると嬉しいです。Agent でもハーネスでもプロンプトでも、改善の話が出たときにまず聞き返すべきなのは「どんな的に対する点数が上がったのか」です。この問いが楽に出てくるようになると、self-improving loop が物語から道具に変わっていきます。

次回は M6 — Autoresearch、agent が自分でリサーチする構造 です。Agent が検索して、読んで、要約して、自分の要約を再評価して次の検索を選ぶ流れを扱います。この流れが、今回組んだ評価構造の上でどう回るかを見ると、agent 改善サイクルの感覚がもう一段深く降りてきます。

FAQ

Q1. 評価データ(golden set)は何個から始めればいいですか?

30〜50個で始めれば十分です。重要なのは個数よりも多様性です。簡単・中・難しい・エッジケースをバランスよく混ぜ、実務ログから失敗ケースを必ず数件入れてください。時間が経って失敗事例が積もってきたら、100〜200個に増やしていけば大丈夫です。

Q2. LLM-as-judge で採点した点数は、どれくらい信用していいですか?

研究では人間採点と 80〜90% ほど一致すると報告されています。実務で使うのには十分ですが、注意点が2つ。ひとつ、判定モデルと評価対象モデルは別のものを使う(自己バイアスを避けるため)。ふたつ、毎週 5〜10% は人間が直接検品する。完全に自動だけで回すと、判定モデルの弱みが評価に焼き付きます。

Q3. Benchmark の点数は完全に無視していいんですか?

いいえ。無視はせず、「比較用としてだけ」 使ってください。候補モデルを一度ふるいにかける用途には便利です。その点数ひとつでリリース判定を下さないのが原則。Task-specific eval と production eval まで必ず通すこと。

🗺 マップ上の現在地

◀ 前の編: M4. 良いエージェントは良いハーネスを持っている
今の編: M5. Evaluation、『終わった』をどう判定するか (15/20)
▶ 次の編: M6. Autoresearch、agentが自分でリサーチする

📚 全体20編マップに戻る →

ニュースレターのご案内

こうしてひとつの概念を最後まで解きほぐしていく記事を、毎週月曜日の朝にメールでお届けしています。受け取ってみたい方はニュースレター登録(無料・30秒) からどうぞ。

ソース

Anthropic. “Evaluating Claude” — 公式評価ガイド (anthropic.com)
SWE-bench 公式論文およびリーダーボード (swebench.com)
MMLU (Hendrycks et al., 2021) — 大規模多肢選択言語理解ベンチマーク
Khattab et al., “DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines” (2023)
Zheng et al., “Judging LLM-as-a-Judge” (2023) — LLM 採点者バイアス研究

著者: バイブコーディングテイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

📍 シリーズ位置

AIのしくみ地図 · 15/20編

Evaluation · Optimizationの位置にある編です。前後編のリンクは記事下部のマップ上の現在地ボックスで確認してください。

💡 この編の一行要約

「Claudeが良くなった」が危険な言葉である理由。benchmark·task-specific·production 3層評価 + SWE-bench落とし穴 + DSPy。

ソースリスト

テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
AIのしくみ地図エントリーマップ — 全体構造 + 3つの読み方
“Attention Is All You Need” (Vaswani et al., 2017)
Anthropic · OpenAI · Google 公式ドキュメント
mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

著者: バイブコーディングテイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。

Post Views: 16