11件の課題で測った人たちは、点数を主役にしなかった｜小さな検証を誠実に報告する作法

小さな検証をして、その結果で判断する場面があります。3社に聞いた、5件試した、2週間回してみた。そういう規模の検証です。

報告を書くとき、数字を前に出したくなります。点数や件数があると、読む側は「測った」と受け取ります。逆に「おおむね良好でした」と書けば、印象論に見えます。だから、サンプルが少ないときほど数字を前に出したくなる——これは自然な力の働き方です。

最初は、これは誠実さの問題だと考えていました。弱い検証で強い書き方をするのは不誠実だ、という整理です。

しかし、ある評価報告の書き方を読んで、整理が足りていないことに気づきました。その報告は、数値を持っていながら、本文の主役に置いていませんでした。 隠したのでもなく、弱気だったのでもない。読み取らせたい強さに、提示の形を合わせていました。

だとすれば、論点は「数字を出すか出さないか」ではありません。設計の強さと、提示の形が合っているかです。この記事の見立てはここです。

扱わないものを先に置きます。AIが仕事を代替できるかどうかは論じません。評価対象の優劣も扱いません。ここで扱うのは、小さな検証を報告するときの形だけです。

30秒で要点

• 参照する報告は 11課題・各1回・採点者1名という設計を、自分で限界として開示している
• 本文に総合スコアが無い。 数値は図にのみ示されている。数値を持っていないのではなく、主役に置いていない
• 著者は限界を4点挙げている。小標本・主観的な基準・自社固有の課題・対象ごとに別の実行環境
• スコアがほぼ同じ水準に並んだ2つの対象について、著者は同点が差を小さく見せていると書いている。点数の一致は、同じ使い方ができることを意味しない
• 結論には「少なくとも Epoch においては」という限定が付いている。限定を落とした引用は、別の主張になる
• 判断軸は「数字を出すか」ではなく「設計の強さに提示の形を合わせているか」である

何が測られ、何が測られなかったのか

参照するのは Kelly Hong と Greg Burnham による「Can AI automate Epoch?」です（2026年10月8日付。2026年10月25日に本文を取得して確認）。

性格を先に置きます。これは、自社の業務を自社で評価した報告です。 評価者と、評価対象となる業務の提供元が同じです。この点は、結果の読み方を決める前提になります。

設計はこうです。課題は11件で、5つの区分に分かれています。

表が収まらない場合は、横にスクロールできます

各対象は、各課題を1回ずつ実行しました。採点は区分ごとのルーブリック——採点基準を項目に分けて書き出した表——で行われ、客観的な基準と主観的な基準が混在しています。そして、各出力を採点したのは1名の人間です。

評価対象は6つで、報告本文の表記では Claude Fable 5.1、GPT-6 Astra、Grok 4.6、Gemini 3.8 Flash、Kimi K3、Qwen 3.8 Max です。この6つがどういう基準で選ばれたかは、報告が選定理由を述べていないため、ここでは触れません。

この設計を一列に並べると、弱さが見えます。11課題。各1回。採点者1名。基準の一部は主観。どれか1つでも違っていれば、順位は違っていたかもしれないという状態です。

本文に総合点が無いという選択

ここが、この報告の書き方の中心です。

数値のスコアは、棒グラフにのみ示されています。本文には総合点が書かれていません。

これを「数値が無い報告」と読むと、何も読み取れません。数値はあります。図の中にあります。読み取るべきなのは、数値が本文の論の運び方に使われていないことです。

本文が代わりに書いているのは、どこで差が出て、どこで出なかったかという挙動の記述です。たとえば、評価対象のうち2つが「おおむね同率で首位」であると述べられています。順位としてはそれだけで、何点対何点かは本文に出てきません。

この選択の意味を、逆から考えると見えます。もし本文に「総合82点」と書いていたら、その数字は引用されます。引用された数字は、11課題・各1回・採点者1名という設計から切り離されて運ばれます。数字は運ばれ、設計は運ばれません。 本文に置かないことは、切り離されやすい形で情報を出さないという判断です。

図に置いてあることも重要です。隠してはいません。図を見れば数値は確認できます。ただし図は、本文のように断片として引用されにくい。置き場所を選ぶことで、強さの取り違えが起きにくい形にしています。

限界を、自分で4点書いている

報告は限界として次の4点を挙げています。

1. 課題集合が限られ、各対象が各課題を1回ずつしか実行していないため、スコアがノイジーであること
2. 基準の多くが主観的で、スコアが正解値ではないこと
3. 自社固有の課題であり、他の仕事や他の評価基準に一般化できないこと
4. 対象ごとに別の実行環境（ハーネス——モデルに課題を与え、結果を受け取る仕組み）で走らせたため、差が実行環境の違いに由来する可能性

4番目は見落としやすい項目です。同じ課題を与えていても、与え方の仕組みが違えば、結果の差が課題への対応力の差とは言えなくなります。この項目を自分で書くことは、「順位は仕組みの違いで説明できる可能性がある」と認めることです。

ここで注意しておきたいことがあります。この4点を根拠に「だから信用できない」と結論するのは、読み方として筋が通りません。開示されている弱さは、結論の強さを調整するために使えます。 調整できる報告と、調整できない報告の差が、ここにあります。

同じ設計で、限界を書かずに順位だけを出した報告があったとします。読む側は、その順位がどれくらい揺れるのかを知る手がかりを持ちません。弱さが書かれていないことは、弱さが無いことではなく、読む側が強さを判断できないことです。

「同点」が差を小さく見せる、と著者が書いている

もう1つ、この報告が本文で扱っている論点があります。

Epoch Capabilities Index という別の指標で、評価対象のうち Kimi K3 は158点であり、Grok 4.6 とほぼ同点でした。ここで報告は、同点であることをそのまま置いていません。著者は、この同点が差を小さく見せていると述べています。 理由として、Kimi K3 が、Grok 4.6 がより安定して扱う基本的な課題で苦戦したことを挙げています。

この指標は、11件の課題とは別のものです。11課題の成績として読み替えることはできません。ここで取り上げるのは、指標の中身ではなく、同点をどう扱ったかです。

点数が同じ水準に並んだとき、ふつうは「同等」と要約します。要約としては正しい。しかし著者は、同じ点数に至る経路が違うことを見ていて、その違いが実務上は無視できないと判断しました。点数が揃うことと、同じ使い方ができることは別です。

これは、少ないサンプルの検証でこそ起きます。3社に聞いて2社が同じ評価だったとき、同じ評価に至った理由が違えば、同じ扱いはできません。点数は理由を記録しません。

結論に付いている限定を、落とさない

報告の結論は、現時点では「少なくとも Epoch においては、まだ労働者を代替できない」というものです。

ここで扱いたいのは、後半の限定です。"at least not at Epoch"——少なくとも Epoch においては。 この5語を落とすと、「まだ労働者を代替できない」という一般的な主張になります。落とさなければ、「自社の業務を自社で評価した範囲では」という読み方になります。

限定を落とす操作は、悪意なしに起きます。引用する側は短くしたい。限定句は、短くする過程で最初に落ちる部分です。そして落とした結果は、元の主張より強くなります。要約は、弱める方向だけでなく、強める方向にも働きます。

自分の検証を報告するときにも、同じことが起きます。「当社の環境では」「この3社については」という限定を書いたとしても、それが引用されるときに残るとは限りません。残らない前提で書くなら、限定を本文の後ろではなく、主張と同じ文の中に置くことになります。

設計の記録として残された、打ち切りの事実

もう1つ、報告が残している記録があります。

予備実験で、ある対象の "Benchmarking (9 Questions)" という課題において、出力上限4096トークンのため、280応答のうち61が答えを示す前に打ち切られました。

これは本体の11課題の結果ではありません。予備実験での事象です。それでも記録されています。

記録されていることの意味は、結果の数字が、測定の都合によって動いた痕跡を残すことです。61/280という割合は、設計の不備の記録です。これを書かなければ、予備実験の結果は単に低い点数として見えます。書けば、低い点数の原因が課題への対応力ではなく出力長の設定だったと分かります。

小さな検証では、この種の痕跡がたくさん出ます。回線が切れた、担当者が不在だった、設定を間違えていた。報告から落とすと結果はきれいになり、原因の説明はできなくなります。

なぜ、点数を主役にしてしまうのか

ここまで整理しても、報告を書く側に戻れば点数を前に出したくなります。理由は3つあります。

第一に、点数は要求される形に合っています。 会議で求められるのは「結局どうなのか」です。挙動の記述はその形になりませんが、点数はなります。求められた形で返すと、話が前に進みます。

第二に、挙動の記述は読む側に負担をかけます。 「基本的な課題で苦戦した」という記述を使うには、読む側が自分の用途に当てはめる作業が必要です。点数なら、比較だけで済みます。負担の少ない情報が選ばれるのは、受け取る側の選択です。

第三に、数字を出さないことが自信の無さに見えます。 これがいちばん強く働きます。限界を4点書いた報告は、書かなかった報告より弱く見えます。見え方の上では、開示は不利です。

この3つが揃うと、「サンプルが少ないほど点数を前に出す」という、逆向きの行動が生まれます。弱い検証ほど強い形で提示される。そして、受け取る側はそれを設計から切り離して運びます。

自分の検証を報告するときの判断軸

正解は「数字を書かない」ではありません。数字を落とすと、読む側は強さを判断できなくなります。

判断軸は、設計の強さと提示の形を合わせることです。具体的には、提示の形を3つに分けて考えます。

1つ目は、本文に置く情報です。 ここには、設計から切り離されても誤解されないものを置きます。挙動の記述、どこで差が出てどこで出なかったか、限定句の付いた結論。切り離して運ばれても、元の意味を保つものです。

2つ目は、図や表に置く情報です。 数値はここに置けます。見たい人は見られる。ただし、断片として引用されにくい形になります。

3つ目は、設計と限界の記述です。 これは本文に置きます。後ろに付けるのではなく、結果を述べる前に置くほうが、読む順序としては強さの調整が効きます。

逆に、やってはいけないことも明確になります。設計の弱さを書かずに、点数を本文の主役に置くこと。 この組み合わせのとき、報告は実際より強い主張として流通します。そして、流通した先で誰かがそれを根拠に判断します。

手元で試せる最小の検証

次に小さな検証を報告するとき、1つだけ試してみてください。

書き上げた報告から、数字をすべて消してみる。 そして、残った文章で結論が成立しているかを読みます。

成立していれば、その報告は数字を根拠ではなく補強として使っています。数字を図に移しても、主張は保たれます。

成立していなければ、数字が主張の全部を担っています。このとき確認することは2つです。その数字は、何回の試行から出たか。何人が判定したか。 1回・1人であれば、担わせている重さに設計が足りていません。足りていないなら、結論の書き方を変えるか、設計を足すかのどちらかです。

この確認には10分かかりません。消すだけです。

確かなことと、確かでないこと

確かなこと（2026年10月25日に本文を取得して確認した範囲）：この報告が2026年10月8日付であること。課題が11件で5区分に分かれ、各対象が各課題を1回ずつ実行したこと。採点が区分ごとのルーブリックで行われ、客観的基準と主観的基準が混在し、採点者が1名であること。数値スコアが棒グラフにのみ示され、本文に総合点が無いこと。評価対象のうち2つが「おおむね同率で首位」と述べられていること。限界として4点が明示的に列挙されていること。Epoch Capabilities Index で Kimi K3 が158点で Grok 4.6 とほぼ同点であり、著者がその同点を差を小さく見せていると評価していること。予備実験で出力上限4096トークンにより280応答中61が打ち切られたこと。結論に "at least not at Epoch" という限定が付いていること。

確かでないこと：評価対象の6つがどういう基準で選ばれたかは、報告が選定理由を述べていないため分かりません。各対象の公表時期についても、この記事では扱っていません。一次情報を取得できていないため、断定できる段階にありません。

この記事が扱っていないこと：評価対象の優劣は扱いません。11課題・各1回・採点者1名・実行環境の違いという条件下の結果であり、順位を一般化できる材料ではありません。また、Epoch Capabilities Index の値を他の指標や11課題の成績と並べて比較することもしていません。別の尺度です。予備実験の打ち切りについては、その後の経緯には触れていません。原文の記述から意味を確定できていないためです。

検証を報告する前に立ち返る問い

立ち返りたいのは、「この数字は、何回の試行から出たか」という問いです。1回なら、その数字は結果ではなく1つの観察です。観察を結果として書くと、読む側は再現性を仮定します。

もう1つは、「この結論から限定句を落とすと、何が変わるか」という問いです。変わらないなら、限定句は飾りです。変わるなら、限定句は主張の一部であり、落ちない場所に置く必要があります。

弱い検証を強く書くことは、短期的には通ります。通ったあと、その報告を根拠に判断した人が結果を引き受けます。設計の弱さは、報告から消しても、判断の結果からは消えません。

参考資料・引用元

• Can AI automate Epoch?（Kelly Hong, Greg Burnham、Epoch AI、2026年10月8日付。自社の業務を自社で評価した報告。2026年10月25日に本文を取得して確認）