現場実装の クムビーバー です。大きな評価セットは魅力的ですが、最初から重いと回りません。社内検証では、まず失敗が一目で分かる スモークスイート から始めます。
この回の答え
重いベンチの前に、coding / JSON / tool-calling の3タスク・スモークで門番を通す。失敗が一目で分かる最小スイートが先。本番ベンチではない。
この回だけの用語
| 用語 | ひとことで |
|---|---|
| スモークスイート | 壊れていないかを見る最小の門番テスト |
| coding | 指定の関数断片を書けるか |
| json_schema | 必須キー付き JSON を機械が受け取れるか |
| tool_call | 期待ツールを必須引数付きで呼べるか |
| pass_rate | 合格率。到達失敗とモデル劣化を分けて読む |
| tool parser | ツール呼び出し形式を解釈する起動側の設定 |
現在の最小構成は3タスクです。
- coding: 指定のPython関数を書けるか
- json_schema: 必須キー付きJSONを安定出力できるか
- tool_call: 期待ツールを必須引数付きで呼べるか
なぜこの3つか
業務エージェントに最低限必要な能力を圧縮しています。
- コード生成は実装支援の入口
- JSON安定性は業務システム連携の入口
- tool calling は社内APIや検索・実行系の入口
ここを落ちる構成を、長文要約の勝率だけで採用するのは危険です。逆に、この3つが安定して通るなら、「少なくともエージェントの土台はある」と言えます。完璧さより、明らかな不適合の早期発見が目的です。
門番の coding は関数断片レベルです。本計測では 関数 / リポジトリ / エージェント の段階に分けて拾います（詳細は品質プレイブックと投機検証の回へ）。
| タスク | 見る能力 | 落ちたときの疑い先 |
|---|---|---|
| coding | 指示追従と基本生成 | モデル適性、プロンプト崩れ |
| json_schema | 構造化出力の耐性 | 出力形式、サンプリング設定 |
| tool_call | ツール選択と引数 | tool parser / auto tool choice |
タスク設計のポイント
coding
期待値は厳密なユニットテストより、まずは contains（必要断片の含有）からで構いません。目的は「完全正解」より「明らかな崩壊を早期発見」です。関数名やシグネチャの断片が入っているか、禁止パターン（空応答、無関係な長文）になっていないか、くらいから始めます。
JSON
JSON only を指示しても、前置きやコードフェンスを付けるモデルは多いです。scorer 側でパース可否と必須キーを見ることで、業務接続の耐性を測ります。「人間が読めればよい」ではなく、「機械が受け取れるか」が合否です。
tool calling
プロンプトでツール利用を促し、expected_tool と required_params を検証します。ここで落ちる場合、モデル能力だけでなく、起動プロファイルの tool parser / auto tool choice 設定も疑います。品質失敗を全部モデル責任にすると、設定修正で直る案件を見逃します。
回し方
- 対象プロファイルを起動し health を確認
- 同じスイートを固定して評価
- pass_rate だけでなくタスク別の失敗理由を読む
- 失敗が「到達不能」か「出力不正」かを分ける
- 設定変更は1軸にし、再評価
- 門番通過後にだけ、重い性能計測や追加スイートへ進む
実行チェックリスト
- [ ] dry-run 済みで、意図したプロファイルが起動されている
- [ ]
/health相当が通っている - [ ] スイートIDとバージョンが記録されている
- [ ] タスク別の raw 失敗理由が残っている
- [ ] 次に変える軸が1つに決まっている
よくある落とし穴
| 落とし穴 | 何が起きるか | 対処 |
|---|---|---|
| 未起動のまま評価 | 全滅をモデル不合格と誤読 | health を門番にする |
| スイートを毎回改変 | 比較不能 | 改変したらスイート版を上げる |
| pass_rate だけ見る | どの能力が弱いか消える | タスク別内訳を必須にする |
| 重いセットを先に回す | 時間が溶けて反復が止まる | smoke → deep の順を守る |
| 設定を複数同時変更 | 学びが消える | 1軸ルールを徹底 |
スモークの合格をどう使うか
スモーク通過は「本番採用」ではありません。意味は次に限定します。
- この用途の土台として、次の比較に進めてよい
- 重いベンチや judge を回すコストを払う価値がある
- まだ stable ではない（制約付き testing の継続）
門番を過大評価すると、長文や同時実行で落ちる構成を早出しします。逆に門番を軽視すると、明らかに不適合な候補へ時間を溶かします。
スモーク合格は、深い品質ベンチの測定条件が妥当であることの証明ではありません。reasoning や事実性の重いスイートへ進むときは、sampling・生成長・thinking キー・リクエスト実体を改めて確認します。
タスク別の合格一文テンプレ
レビューや引き継ぎでは、次のように一文で残すと議論が早くなります。
- coding: 「指定関数名と基本シグネチャ断片が出力に含まれる」
- json_schema: 「パース可能で必須キーが揃った JSON である」
- tool_call: 「期待ツールが必須引数付きで選択される」
完璧な採点基準を最初から書こうとすると進みません。まずこの粒度で固定し、誤検知が出てから厳格化します。スモークの仕事は、深い評価の代替ではなく、深い評価へ進む価値があるかの判定です。
つまずいたこと
大きなベンチを回す前に、短いスモークで落とすべきでした。長い評価を回してから設定ミスに気づく浪费を、何度もやりました。
苦労したのは、スモークを「簡易版」と侮らない空気を作ることです。短いからこそ、失敗の意味を定義しないと単なるグリーンランプになります。
この回の要点
- 長い評価の前に短いスモークで落とす
- スモークの失敗意味を定義する
- グリーンランプだけで安心しない
coding-smoke は落とすための短い型であり、コーディング品質の最終判定ではありません。タスク別の実測パス率は再計測と匿名化後に足し、用途合格ラインは別途決めます。
次は「品質判定を拡張する：contains / JSON / tool_call scorer」です。スモークで落ちた理由を、差し替え可能な採点器で分解します。
よくある質問
なぜ3タスクから始めるのですか？
大きなスイートは魅力的ですが、最初から重いと回りません。門番を通った候補だけを深い評価へ進めます。
スモークで落ちたら即不合格ですか？
モデル劣化か到達性・フォーマット失敗かを分けます。原因ラベルが無いと次の改善がずれます。
この回の数値は実測ですか？
設計の型の説明です。未確定の合格ラインや未計測のスコアは断定しません。
スモーク合格なら深い品質ベンチの条件も十分ですか？
いいえ。門番通過は次へ進む価値がある、までです。reasoning や事実性ベンチは別の測定衛生が要ります。
