Karpathy の autoresearch を Twitter で見かけたときは衝撃だった。
「測る → 提案する → 残すか戻す」のタイトループを、ハードな指標に対してエージェントに延々と回させる。元々はモデル学習の文脈の話だが、他にも使えそうだと感じていた。

エージェントを手放しで長時間動かす方法は他にもある。Ralph loop のように同じプロンプトを延々と叩き続けるやり方や、TODO リストでタスクを切って小さなコンテキストで回すやり方など。 寝ている間にエージェントを回して起きたらアウトプットが出ている、というはロマンがあるよね。

ただ、それらはどれも「何をやるか」は人間が決めてエージェントに渡すものだった。autoresearch が斬新だったのは、何をやるかまでエージェントが考えるところだ。指標さえ与えれば、アイデアを出すのもエージェント、書くのもエージェント、捨てるかどうか決めるのもエージェント。

そして、これをAI自身の性能に対して回すようになったとき、、もう人間はお手上げなんだろうな、とも思った。それがもう目の前にある、という怖さも、autoresearch という言葉が頭に残り続けた理由の一つだ。

ある朝、大きな plan ファイルを Cursor で開いたら、Markdown プレビューが表示されるまでまるまる1秒以上かかった。
持ってたハンマーにあう釘が見つかった。

AI と一緒にコードを書くようになって、長くてコード片の多い plan / design ドキュメントを Markdown で読む時間が圧倒的に増えている。一回の待ちは1秒でも、一日に何十回も繰り返せば積み重なる。
「はやく目的のコードに辿り着く」と同じく、Markdown のレンダリング待ちには耐えられない。

仕掛け 見出しへのリンク

初めに計測すべき、最小化すべき指標を決定する。

Cursor の fork 元の VS Code のコードを Claude と読みながら、Markdown プレビュー機能を取り出して VS Code 拡張としてインストールできる環境を作った。
VS Code に拡張をロードした状態で複数の Markdown パターン（コードブロック、テーブル、箇条書きと文章）をレンダリングし、Markdown ファイルを開く直前からレンダリング完了までを TTFP (Time To First Paint) として定義し、これを計測できるスクリプトを書いた。

  • E2E TTFP — Playwright + Chrome DevTools Protocol で、Quick Open で Enter を押してから preview webview に最初の見出しが現れるまでの実時間。

次に autoresearch のエッセンスを取り込んだ。autoresearch の README.md と program.md は、それぞれ研究全体の方針とエージェントが回す実行ループを定義する役割。これを Markdown の TTFP にカスタマイズして、autoresearch skill と program.md を作った。

program.md には、エージェントが編集してよい範囲（フォーク配下のみ）と触ってはいけないファイル（ベンチハーネスとベースライン）、最小化すべき指標 (TTFP_e2e)、ベンチの取り方、keep / discard / crash の判定基準、results.tsv への記録フォーマット、そして「同じ性能なら単純な実装を優先する」といったルールが書いてある。 エージェントはこれを読み、自分でアイデアを出し、フォークを編集し、ベンチを取り、判定して残すか戻すかを決める。

そして autoresearch skill にループを自走させた。アイデアを選び、フォークを編集し、ビルドし、ベンチを取り、results.tsv に記録し、数字次第で commit して残すか revert する。判定ルールはシンプル: median TTFP が3%以上改善し、p95 が5%以上悪化していなければ keep、それ以外は discard。

そして散歩に出かけた。

autoresearch progress

各グレーの点は捨てられた実験、緑の点は採用された改善、緑の階段が running best。 この図がまた良いよな。

ループが見つけた最適化 見出しへのリンク

最終的に3つの最適化が残った。

  • Lazy highlight — highlight.js をホストから webview に遅延させ、最初の描画では viewport に見えているコードブロックだけをハイライトする。残りはスクロールに合わせて順次ハイライトされる。
  • Viewport-first rendering — viewport に見える部分を先にレンダリング・ペイントし、fold より下は first paint の後にレンダリングする。
  • Token-boundary slicing — ドキュメントを一度パースし、markdown-it のトップレベルトークン境界で分割する。viewport 分のトークンだけ同期的にレンダリングし、残りは first paint 後に遅延レンダリング。ソース行ではなくトークンで切るので、コードブロックやリスト、テーブル、引用が途中で分断されない。

結果、大きな plan ファイルの TTFP は約 4.6 秒から1秒未満になった。すべてのレンダリングが終わった後の最終的な DOM は組み込みと一致する。

demo

私はデバッグをした。 Viewport-first rendering の実装は初期、コードブロックなど Markdown ブロックの途中で分割してしまっていて、ファイルを一回でレンダリングした場合と、viewport だけ先にレンダリングしてから残りを足した場合とで結果が変わるバグがあった。Token-boundary slicing はこれを直すために入った。

Markdown Fast 見出しへのリンク

その結果を Markdown Fast (marketplace) として公開した。

UX は組み込みの Markdown レンダラーと同じdrop in replacement。 組み込みの vscode.markdown-language-features を無効にすれば、Markdown Fast がデフォルトのプレビューになる。

code --install-extension maaashjp.markdown-fast

その後この手順で組み込みの Markdown レンダラーを無効にしてください。

おまけ 見出しへのリンク

なお、Cursor は独自の Markdown ハンドリングをしていて、3rd party の拡張を使うことで高速化することは（ひと週末では）難しかった。
これで Cursor → VS Code に乗り換え直し。Markdown レンダリングが遅いエディタは使えないわ。

おまけ2 見出しへのリンク

Keep Claude working toward a goal により 2026 年 5 月 11 日、Claude Code v2.1.139 でリリースされた組み込み機能で、ゴールに向けて長時間作業を続けることができるようになった。

おわりに 見出しへのリンク

エンジニアの世界では「推測するな、計測せよ」とよく教わってきた。計測せずに当てずっぽうにハックを入れてメンテナンス性は悪くなる上にその結果ユーザー体験にはあまり影響がない、というのは痛い経験だしだからこそ計測は大事だが、

さらに「計測せよ、さすれば改善できる」 2026 年には計測の重要性は一段と増したよね。

何を測り改善したいかを決める、意思のようなプロセスが人間にはまだ残されている。