pass@kとは？AIコード生成の実力を測る指標と3つの落とし穴
この記事のポイント pass@kは「AIにk回書かせて、1回でも動くコードが出る確率」を表す指標です。 k=1とk=100では同じモデルでも数字が3倍近く変わるので、kを見ずにスコアだけ比べると判断を誤ります。 業務で自動化を任せたいなら、1回当たれば勝ちのpass@kより、毎回成功を求めるpass^kのほうが実態に近い数字です。 公表スコアを読むときは「k」「サンプル数n」「テストの厳しさ」の3点を確認するだけで、だいたいの誇張は見抜けます。
モデルの発表資料に並ぶ「pass@1で〇〇%」という数字。なんとなくすごそうだけど、この@のあとの数字が何を意味しているのか、正直よく分からないまま眺めている人は多いはずです。
答えを先に置きます。pass@kの「k」はAIに何回チャレンジさせたかの回数です。ここが分かると、公表スコアの読み方が一気に変わります。
pass@kとは、k回のうち1回でも当たれば成功とみなす指標です
pass@kとは、あるタスクに対してAIにk個の答えを作らせたとき、そのうち少なくとも1つが正解になる確率です。コード生成なら「生成したk本のコードのうち、1本でも用意したテストを全部通れば成功」と数えます。
ポイントは「1本でも」というところ。10本書かせて9本がゴミでも、1本動けばそのタスクは成功扱いになります。
この数え方は、人間がAIを使う実際の流れに近い形になっています。候補を何個か出させて、動くものを採用する。多くの開発者がやっている使い方です。逆に言えば、候補を選ぶ手間を誰かが払う前提の指標でもあります。
判定は人の主観ではなく、あらかじめ書かれたテストコードが自動で行います。だから再現性が高く、比較に使いやすい。ここが他の評価指標にない強みです。
なぜ1回の正解率では足りないのか？
AIの出力は毎回変わります。同じ指示文（AIへの指示のこと。プロンプトとも呼びます）を投げても、1回目は動いて2回目は動かない、ということが普通に起きる。
だから「1回試して当たった／外れた」だけでは、そのモデルの実力なのか、たまたまなのか区別がつきません。
| 測り方 | 何が分かるか | 弱点 |
|---|---|---|
| 1回だけ試す | その場の当たり外れ | 運の要素が大きすぎる |
| 平均正解率 | 出力全体の平均的な質 | 「候補から選ぶ」使い方と噛み合わない |
| pass@k | k回内に正解が出る確率 | kを揃えないと比較できない |
| pass^k | k回すべて成功する確率 | 数字が低く出るので見栄えが悪い |
つまり、pass@kは「何回か試せる前提」を数式に組み込んだ指標です。
ここで気をつけたいのが、kを大きくすればスコアは必ず上がるという性質。だからこそ、次の計算式を知っておく価値があります。
pass@kの計算式はどうなっている？
素朴に考えると、1問あたりの正解率を p として 1 - (1 - p)^k になります。「全部外す確率」を1から引いた形。
ただし実際の評価では、この式をそのまま使いません。1問につきn個の答えを生成し、そのうちc個が正解だったときに、組み合わせを使った偏りのない推定式を使うのが標準です。
pass@k = 1 - C(n - c, k) / C(n, k)
記号の意味を整理しておきます。
| 記号 | 意味 | 実際の値の例 |
|---|---|---|
| n | 1問あたり生成した答えの総数 | 100、200 |
| c | そのうち正解だった数 | 34 |
| k | 「何回まで試せるか」の設定 | 1、5、10、100 |
| C(a, b) | a個からb個選ぶ組み合わせの数 | 高校数学のコンビネーション |
この式が使われる理由はシンプルで、少ないサンプルから素朴に計算すると数字が上振れしやすいからです。n=kのときに1問でも当たっていれば100%と出てしまうような偏りを、組み合わせで補正しています。
表の要点はひとつ。公表スコアの裏では、たいてい1問あたり100本以上のコードが生成されているということです。
k=1、k=10、k=100で数字はどう変わる？
ここが一番おもしろい部分です。同じ実力（1回あたりの正解率p）でも、kを変えるだけで見え方が激変します。
| 1回あたりの正解率p | pass@1 | pass@5 | pass@10 | pass@100 |
|---|---|---|---|---|
| 10% | 10% | 約41% | 約65% | 約99.997% |
| 30% | 30% | 約83% | 約97% | ほぼ100% |
| 50% | 50% | 約97% | 約99.9% | ほぼ100% |
つまり、実力3割のモデルでも100回投げれば「ほぼ解ける」と表現できてしまう。数字のマジックです。
pass@1が実務のラインだと考えてください。人が候補を選別する余裕がない自動化パイプラインでは、1発目の質がそのまま結果になります。逆に、腰を据えて書くコードで候補を5本並べて選ぶなら、pass@5が現実に近い。
もうひとつ、スコアを動かす隠れた変数があります。生成のランダムさを決める温度（temperature）です。温度を下げると出力が安定してpass@1が上がりやすく、温度を上げると答えの幅が広がってkが大きいときに有利になります。ベンダーがkごとに温度を調整して測るのは、この性質があるからです。
同じモデルでも設定次第で数字は動く。だからスコアの横にある小さな注記を読む価値があります。
pass@kが測れること、測れないこと
得意・不得意をはっきりさせておきます。
| 観点 | pass@kで測れる | 測れない |
|---|---|---|
| 動くかどうか | ○ テストが通れば正解 | — |
| コードの読みやすさ | — | × 保守性は評価対象外 |
| セキュリティ | — | × 脆弱なコードでもテストは通る |
| 実行速度 | — | × 計算量が最悪でも合格 |
| 長い作業の完遂 | △ 1問完結なら可 | × 複数ファイルにまたがる改修は苦手 |
要するに、pass@kは「動くか」だけを見る指標です。品質は別で測る必要がある。
社内の評価基準を作るときは、この表の右側をどう埋めるかがそのまま設計の勘所になります。監査や内部統制の観点でAIの出力を扱うなら、社内の点検業務にAIを組み込む考え方を先に押さえておくと、評価項目の粒度が決めやすくなります。
pass^kとは何が違うのか？
読み方は「パス・ハット・ケー」。pass@kが「k回のうち1回でも成功」なのに対し、pass^kはk回すべて成功する確率です。積で表すので p^k に近い形になります。
この違いが効いてくるのが、AIエージェント（人が逐一確認せず、AIが手順を判断して作業を進める仕組み）の評価です。
| 使い方 | 適した指標 | 理由 |
|---|---|---|
| 人が候補を選ぶ | pass@k | 1本当たれば作業は進む |
| 自動で実行させる | pass^k | 1回でも失敗すると事故になる |
| 顧客に直接出す | pass^k | 失敗の許容回数がゼロに近い |
数字で見るとインパクトが分かります。1回あたりの成功率が90%のエージェントでも、10工程を連続でこなす確率は約35%。95%あっても20工程なら約36%です。
ここまでの整理：pass@kは「当たりくじが引けるか」、pass^kは「全部当たりか」。人が見張る運用ならpass@k、任せきる運用ならpass^k。この使い分けだけで、ベンダー資料の数字が実務にどれくらい効くかを判断できます。
自動化の設計をしている人ほど、pass^k側の数字を要求すべきです。見栄えは悪くなりますが、事故の起きにくい設計に近づきます。
サンプル数nが少ないと数字は信用できない
pass@kは確率の推定値です。推定値である以上、サンプルが少なければブレます。
1問あたり10本しか生成していない状態で算出したpass@10は、実質「10本のうち1本でも当たったか」を見ているだけ。これを「実力」と呼ぶには弱すぎます。
近年は、この点数一発で語るやり方を問題視して、確率の幅（信用区間）で報告すべきだという提案も出ています。単一の数字より、「70〜78%のあたり」と幅で示すほうが誠実だという主張です。
実務で使うなら、こう考えてください。
- 問題数が100問未満の自作ベンチマークは、差が5ポイント程度なら誤差の範囲
- 1問あたりの生成数nは最低でも20、できれば50以上
- 差を主張したいなら、同じ条件で日を変えて2回測る
数字の精度を上げる一番安いやり方は、モデルを変えることではなく問題数を増やすことです。
ベンチマーク側の落とし穴：テストの穴とデータ汚染
pass@kの弱点は、指標そのものより判定に使うテストの質にあります。
テストが甘いと、間違ったコードが合格します。境界値を試していないテスト、例外を投げるケースを書いていないテスト。こうした穴を通り抜けた「偽の正解」がスコアを押し上げる。
もうひとつ深刻なのが、学習データへの混入です。有名なベンチマークの問題と解答はネット上に大量にあり、モデルの学習に含まれている可能性が消えません。答えを知っている問題を解いても、実力の証明にはならない。
公開ベンチマークの代表格であるHumanEvalは164問の関数生成問題で構成されていますが、公開から時間が経つほどこの汚染リスクは高まります。定義や問題セットはOpenAIの公式リポジトリで確認できます。
対策は3つです。
- 社内の実タスクから問題を作る（外に出ていないので汚染されない）
- テストを厳しく書く（異常系を必ず入れる）
- 公開ベンチとの併用にして、公開ベンチ単独では判断しない
外部の数字は目安、自社の数字が本番。この順番を崩さないことです。
自社のタスクでpass@kを測る5ステップ
道具は揃っています。手順に落とすとこうなります。
- 問題を50問集める — 過去のチケットや実際に書いた関数から作ると精度が上がります
- 合否を決めるテストを書く — 正常系1本ではなく、異常系を含めて3本以上
- 1問につきn=20以上生成する — 温度は用途に合わせて固定し、記録に残す
- c（正解数）を数えて式に入れる — pass@1とpass@5の両方を出しておく
- 同じ問題セットで別モデルも測る — 条件を変えずに横並びにする
工数の目安は、問題50問なら準備に2〜3日、実行は数時間です。一度作れば、モデルが新しくなるたび使い回せる資産になります。
コーディング支援ツールの選定なら、AIコーディングのカテゴリで候補を絞ってから、この手順で自社タスクにかけるのが早い。GitHub CopilotやCursorのようなIDE統合型は、生の推論APIと出力傾向が違うので、実際に使う経路のまま測るのがコツです。
公表されたpass@kを読むときのチェックリスト
資料を渡されたとき、この5行だけ確認すれば大きく外しません。
| 確認項目 | 見るポイント | 危険信号 |
|---|---|---|
| kの値 | @の後ろの数字 | kの表記がない |
| サンプル数n | 1問あたりの生成数 | 記載なし、または10未満 |
| 問題セット | 公開ベンチか自社ベンチか | 独自ベンチで中身非公開 |
| 温度設定 | 生成のランダムさ | kごとに条件が違う |
| テストの厳しさ | 異常系を含むか | 正常系のみ |
このうち2つ以上が空欄なら、その数字は営業資料の飾りだと思って構いません。
数字の読み方が身につくと、モデル選びの会話が「なんとなく賢そう」から「どの条件で何%」に変わります。
コード以外にpass@kの考え方は使えるのか？
使えます。正解を機械的に判定できる領域なら、そのまま応用が効きます。
分かりやすいのが画像生成です。1枚で採用できることはまれで、実際は何枚も出して使えるものを選ぶ。これはまさにpass@kの世界観そのもの。「10枚出して1枚使える」なら、pass@10で成功と数えているのと同じです。
この採用率の感覚は、ツール選びの基準としてかなり役立ちます。生成枚数あたりの単価と採用率を掛け合わせれば、1枚の実コストが出るからです。イラスト用途で候補を探しているなら、用途別のAIイラストツールの選び方を先に読むと、この計算の当てはめ先がはっきりします。ローカル環境で大量に回して選別する運用を考えているなら、ComfyUIとStable Diffusionの違いが判断材料になります。
リサーチ用途はもう少し厄介です。答えが1つに決まらないので、機械判定が難しい。ただ「出典URLが実在するか」「引用元のページに該当記述があるか」なら自動で確かめられます。この基準でAI検索を評価する発想は、Felo（フェロー）の使い方まとめのような出典表示型のツールと相性がいい。
対話アシスタント全般でも同じで、Meta AIの機能と使いどころのように用途が広いサービスほど、自分の業務でのpass@1を一度測っておくと、期待値の置き方を間違えずに済みます。
判定基準さえ作れれば、どんなAIにも同じ物差しを当てられる。それがこの指標の応用力です。
AI PICKS編集部の判定
pass@kは、AIの実力を語るうえで今も一番マシな共通言語です。自動判定で再現性があり、誰が測っても同じ数字になる。この性質は破格に貴重で、ここを否定する理由はありません。
ただし、公表スコアの比較材料としては正直イマイチです。kもnも温度も問題セットもバラバラなまま並べられるので、横並びの表がほとんど意味をなさない。ベンダー資料の「pass@k 〇〇%」は、条件が書かれていない限り参考値未満だと考えています。
使い道を1つに絞るなら、自社タスク50問で測るpass@1が一択です。外部ベンチの順位より、自分の業務でどれだけ1発で通るかのほうが、導入判断に直結します。作るのに数日かかりますが、モデルが入れ替わるたびに効いてくる資産になる。
そして自動化を前提にするなら、pass@kではなくpass^kを見てください。90%を10回続ける難しさを数字で突きつけられると、人の確認をどこに挟むべきかが自然に決まります。数字が低く出ることを嫌がらないこと。ここを直視したチームだけが、事故らない自動化にたどり着きます。
よくある質問（FAQ）
Q. pass@1とpass@10、どちらを見ればいいですか？
自動化に組み込むならpass@1、人が候補を選ぶ使い方ならpass@5〜10です。両方が載っている資料なら、その差の大きさが「候補を並べる価値」を表します。差が小さいモデルは、何本出させても似た答えしか返ってこないという意味でもあります。
Q. pass@kが高ければ、業務で使えるということですか？
そうとは限りません。pass@kは「テストが通るか」だけを見ているので、読みやすさ・安全性・実行速度は評価対象外です。テストが通ったコードのレビューは、結局人がやることになります。
Q. pass^kはどう計算しますか？
1回あたりの成功率をpとすると、おおよそ p^k です。厳密には試行ごとの独立性を仮定した近似ですが、実務の見積もりにはこれで十分。成功率95%を20工程つなげると約36%、と計算できます。
Q. 自社ベンチマークは何問あれば足りますか？
最低50問、できれば100問です。50問未満だと1問の当たり外れが2ポイント以上動くので、モデル間の小さな差が読めません。まずは頻度の高い作業から30問作って始め、運用しながら足すやり方が現実的です。
Q. 温度設定は何にすればいいですか？
pass@1を測るなら低め（0〜0.2程度）、大きなkで多様性を見たいなら高めに振ります。大事なのは値そのものより、測定のたびに同じ値を使うこと。ここがズレると前回との比較が成立しません。
Q. データ汚染は自分で確認できますか？
完全な確認は無理です。ただ、公開ベンチで非常に高得点なのに社内タスクでは平凡、という乖離が出たら汚染を疑うサインになります。だからこそ、外に出ていない自社問題を持っておく価値があります。
Q. コード以外のタスクでも測れますか？
自動で合否を判定できるなら測れます。データ抽出、分類、書式変換あたりは相性がいい。文章の良し悪しのように正解が1つに定まらないタスクは、別の評価方法と組み合わせる必要があります。
関連する比較・代替を見る
評価の物差しが決まったら、次は比較対象を絞る番です。
- ChatGPTとClaudeの比較 — 生成の安定性と長文処理の傾向差
- ClaudeとGeminiの比較 — コード生成と読解のバランス
- GitHub CopilotとCursorの比較 — IDE統合型の使い勝手の違い
- ChatGPTとGeminiの比較 — 汎用アシスタントとしての守備範囲
- GitHub Copilotの代替ツール — 乗り換え候補の一覧
- ChatGPTのツール詳細 / Claudeのツール詳細 — 料金と機能の基本情報
- AIエージェント — 自動実行を前提にしたツール群
次に読むならこれ：自動化を任せる前提で選ぶなら、社内の点検業務にAIを組み込む考え方がおすすめです。pass^kの数字をどこで人のチェックに置き換えるか、その設計の具体例がつかめます。
各ツールの公式サイト（一次情報）
料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。
