AI coding agentの評価で、いちばん信用できない文字列は「完了しました」だと思う。
たとえば、pnpm testが未実行で、指定外の共通コンポーネントまで変わっている。途中では同じtool errorを何度も踏み、都合の悪い部分も残った。それでも最終メッセージだけなら、きれいに完了したように見える。
QwenCloudは2026年9月2日のchangelogで、qwen3.8-max-0902についてengineering-scale project、long-horizon autonomous development、multi-tool orchestrationの強化を案内している。contextは1Mのままだ。
この説明は試す理由にはなる。ただ、採用判定には足りない。context容量と長いruntimeと正しい完了は、それぞれ別に測る必要がある。
そこで自分なら、モデルを長時間走らせる前に「何を残せば完了と呼べるか」を固定する。派手な総合スコアを作るより、あとから失敗箇所を読める5種類の証拠を残したい。
まずmodel snapshotとbase commitを固定する
比較にunversioned aliasを使うと、数週間後に同じ名前が同じモデルを指している保証がない。QwenCloudのchangelogに記載されたsnapshot alias、qwen3.8-max-2026-09-02をrunへ保存する。
タスク開始前にbase commitも取っておく。
git rev-parse HEAD
その値を、タスクと変更範囲、受け入れcommandと一緒にeval-task.ymlへ書く。
# これはQwenCloud公式のschemaではなく、評価用に自分で用意する形式
run_id: qwen3.8-max-2026-09-02-run-01
model: qwen3.8-max-2026-09-02
base_commit: <git-sha>
task: tool-result panelへloading / success / error stateを追加
allowed_paths:
- src/features/tool-result/**
- tests/tool-result/**
acceptance_commands:
- pnpm lint
- pnpm test
- pnpm build
このファイルはagentを動かす前に書く。途中でタスクを広げたり、落ちたtestを受け入れ条件から外したりすると、モデルではなく採点方法を変えたことになる。
API parameterやagent CLIは手元のharnessに合わせればよい。公式情報で確認できない呼び出し方を、評価記事のために作る必要はない。
小さいが、境界をまたぐfrontend taskを選ぶ
長時間性能を見たいからといって、巨大なリポジトリ全体のリファクタリングを渡すと判定がぼやける。一方で、文字列置換だけではtool orchestrationも復帰性も見えない。
今回の例では、tool-result panelを1件だけ対象にする。
feature: tool-result panel
states:
loading
success
error
boundaries:
state parsing
UI rendering
component test
featureは小さい。それでもデータの解釈、表示、testという境界をまたぐので、agentが変更範囲と受け入れ条件を保てるか確認できる。
UI patternの候補が足りない場合は、生成AI UIデザインのリソース集でSDKやOSSの実装例を探す。採用したpatternはtask noteへ記録するが、このページをQwenの仕様や性能の根拠にはしない。
run directoryに5種類の証拠を分けて置く
runごとにdirectoryを作り、過去の結果を上書きしない。
.agent-evals/qwen3.8-max-2026-09-02/run-01/
eval-task.yml
acceptance.tsv
changed-paths.txt
tool-retries.tsv
checkpoint.json
review.md
logs/
残す証拠は次の5種類に分ける。
| 証拠 | artifact | 判定例 |
|---|---|---|
| task contract | eval-task.yml |
fixed / incomplete |
| acceptance | acceptance.tsv |
pass / fail / not-run |
| diff scope | changed-paths.txt |
inside / escaped |
| tool retry | tool-retries.tsv |
clean / repeated / unknown |
| interruption recovery |
checkpoint.json + review.md
|
pass / fail / not-tested |
not-runやunknownを0.5点のように丸めない。総合点が同じでも、test未実行とscope逸脱では直す場所が違うからだ。
1. task contract
eval-task.ymlには少なくとも次を固定する。
- model snapshot
- base commit
- task
- allowed paths
- acceptance commands
modelかbase_commitが空なら、そのrunは比較対象から外す。何を動かしたか特定できない結果は再実行できない。
2. acceptance結果
agentの「testは通りました」を転記せず、自分のrunnerでcommandを実行してexit statusを保存する。以下はartifactを作るための最小例で、実行前に対象repositoryのscript名へ合わせる。
RUN_DIR=.agent-evals/qwen3.8-max-2026-09-02/run-01
mkdir -p "$RUN_DIR/logs"
printf 'command\tstarted_at\texit_status\tartifact_or_log\n' \
> "$RUN_DIR/acceptance.tsv"
run_check() {
name="$1"
shift
started_at="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
set +e
"$@" > "$RUN_DIR/logs/$name.log" 2>&1
status=$?
set -e
printf '%s\t%s\t%s\t%s\n' \
"$*" "$started_at" "$status" "logs/$name.log" \
>> "$RUN_DIR/acceptance.tsv"
}
run_check lint pnpm lint
run_check test pnpm test
run_check build pnpm build
commandを起動できずexit statusも取れなかった場合は、空欄のままpassにせずnot-runと記録する。架空の成功logで表を埋めても、比較には使えない。
3. diff scope
変更ファイル一覧はbase commitから機械的に取る。
RUN_DIR=.agent-evals/qwen3.8-max-2026-09-02/run-01
BASE="$(awk '/^base_commit:/ { print $2 }' "$RUN_DIR/eval-task.yml")"
git diff --name-only "$BASE"...HEAD \
> "$RUN_DIR/changed-paths.txt"
changed-paths.txtをallowed_pathsと照合する。lockfileやsnapshotが増えていても、自動的にscope内とは扱わない。必要な変更なら、人が理由をreview.mdへ残す。
4. tool retry
長いrunでは、最終成果物だけ見ても途中のループが消える。toolの試行を次の列で残す。
tool<TAB>attempt<TAB>result<TAB>error_class
同じerror分類が連続していればrepeated、問題なく進めばcleanとする。harnessからtool eventを取り出せないならunknownでよい。見えなかったものを成功扱いするより、観測できないと残したほうが次の改善につながる。
5. interruption recovery
長時間対応を名乗るモデルなら、最後まで放置するだけでなく、一度止めて再開も確認したい。
{
"model": "qwen3.8-max-2026-09-02",
"base_commit": "<sha>",
"last_head": "<sha>",
"completed": ["state-parser"],
"pending": ["error-view", "component-test"],
"blocking": [],
"next_check": "pnpm test"
}
これはQwenCloudの公式formatではない。安全な作業境界でsessionを止めるためのcheckpoint.jsonだ。
再開時は全文transcriptを渡す前に、次の3つを読ませる。
eval-task.yml- 現在のGit state
checkpoint.json
review.mdには、中断前のhead、再開直後に読んだartifact、最初に実行した確認command、最終headを書く。再開できても「モデル単体の能力」とは断定しない。repositoryの構造やagent harnessも含めたsystem-levelの結果として扱う。
次のsnapshotではmodel欄だけを変える
比較runを作るときは、新しいdirectoryを切る。
.agent-evals/
qwen3.8-max-2026-09-02/run-01/
<next-snapshot>/run-01/
揃える条件はbase commit、task、allowed paths、acceptance commands。変更するのはmodel identifierとrun directoryだ。実行日による依存関係の揺れを避けるため、同じlockfileとruntime versionもtask noteへ残しておくと比較しやすい。
最後に5列を横に並べる。pass数だけで勝敗を決めず、どこで失敗したかを見る。
| snapshot | contract | acceptance | scope | retries | recovery |
|---|---|---|---|---|---|
| qwen3.8-max-2026-09-02 | <fill> | <fill> | <fill> | <fill> | <fill> |
| <next-snapshot> | <fill> | <fill> | <fill> | <fill> | <fill> |
QwenCloudのchangelogには、成功率、旧snapshotとの差、速度、料金の比較値は載っていない。ここで得られるのも、特定repositoryとharnessを含んだ結果だ。他モデル全般の順位表には広げない。
長時間agentほど、会話よりartifactが効く
長時間のcoding agentを複数sessionで使う場面が増えると、「本人が最後に何と答えたか」だけではrunを引き継げない。別の人や別sessionが、途中の状態と判定根拠を読める必要がある。
1M contextは、長い入力を扱うための仕様だ。正しい完了、scope遵守、中断からの復帰まで保証するものではない。
モデル更新を見つけたら、すぐに巨大タスクを投げるより先にeval-task.ymlを作る。5種類の証拠が同じrun directoryへ残れば、次のsnapshotでも同じ条件でやり直せる。自分が欲しいのは「完了しました」という返事より、失敗を含めて再現できる記録だ。
Source notes
- QwenCloud model releases: 2026-09-02のQwen3.8-Max-0902に関する公式changelog。
- Research acceleration: the view inside OpenAI: coding agentの長時間・複数session利用が増えた運用背景として参照。