このページで見えること
以下に並ぶ 4 つのセクションは、それぞれ 独立した CLI ツールを単独実行した結果です。 すべて手元の Mac（CIFAR-10 部分は CPU、それ以外は API + ローカル実行）で取得した実データを表示しています。
- §1 PaperBench Iter — 論文再現コードを反復改善し、スコアを 43.2% → 67.5% → 94.5% まで伸ばした実験
- §2 Self-Improving Agent — CIFAR-10 用の弱い CNN を AI が自動で書き換え、5 サイクル走らせた結果
- §3 Reproduce Pipeline — Stochastic Interpolants 論文を arXiv URL から自動再現したログ（5 ステージ完走）
- §4 Literature Scout — 関連論文発見ツールの出力サンプル
- §5 全体俯瞰 — 4 コンポーネントの「入力 / 出力 / 主な発見」を一覧
💡 各セクションのチャートは Chart.js でその場で描画されています。チャート上をホバーすると詳細値が出ます。
§1 PaperBench Iteration
採点方法: PaperBench 公式の SimpleJudge（claude-sonnet-4 ベース）が、論文の rubric（評価項目ツリー、計 58 ノード）を 0〜100 で採点。各ノードに重みが付き、子の達成度が親に伝播する 階層スコア が最終値です。
① スコアの伸び方
v0（最初の 1 回生成）から v2（2 回目の改善）まで、階層スコアと単純平均がどう変化したか。点線（単純平均）が実線（階層スコア）より上にあるのは、低スコアの一部ノードが重み付きで効いているため。
右のチャートは 各 iter で 58 ノードがどのスコア帯に分布したか。赤（0-25）が大きいほど未達ノードが多い。v2 では赤が 5 ノードまで縮み、緑（76-100）が 52 ノードに増えた = ほぼ全ノードが満点近い。
② 各反復で具体的に何が変わったか
各 iter で SimpleJudge の reasoning（採点の根拠）から抽出した「改善した点」「まだ失敗していた点」。クリックで展開できます。
③ 業界の他エージェントとの比較
★ 行が我々の結果。autores v0.1（baseline）の 43.2% はすでに IterativeAgent o1-high 平均と同等で「初期生成は SOTA レベル」。さらに 2 反復で 94.5% に到達。
| エージェント | スコア | 備考 |
|---|
§2 Self-Improving Agent
注目すべきポイント: 「毎サイクル改善するわけではない」「LLM の提案には偏りがある」「ロールバックと NRR が必要」という工学的知見がそのまま見えるところ。退行（赤バッジ）2 件と best サイクル（金色）1 件があります。
① 5 サイクルの精度推移
青 = 通常サイクル、金 = best、赤 = 退行（前 best より精度が下がった）。Y 軸は CIFAR-10 のテスト精度。サイクル 3 と 5 は提案を試したが退行している = 「LLM の提案は常に賢いわけではない」
② 各サイクルで Claude が何を提案したか
各カードは 1 サイクル分。提案カテゴリ（scheduler / regularization / architecture 等）と信頼度（Claude 自身の自信スコア 0〜1）も表示。退行サイクルは右上に赤バッジ。
§3 Reproduce Pipeline
2310.03725 を入力にして 5 ステージのパイプラインを end-to-end で完走させた実ログ。ステージごとの所要時間、成功/失敗、論文の数値主張と実行結果の比較が見られます。
注目すべきポイント: 5 ステージ全て成功（人手なら数時間かかる作業が 161 秒で完了）。ただし再現スコア 0.5＝動かすところまでは行ったが、論文の数値完全一致は未達。これは EnvBench / PRBench で示されている業界全体のギャップと一致。
対象論文: (arXiv: )
① 全体結果サマリ
左の半円ゲージは再現スコア（0.0〜1.0）。今回は 0.5 で「半分の主張が検証済み」状態。右側に合計時間。
② 5 ステージの時間配分
Code Finding が 90 秒で全体の 56%を占める。これは Claude が論文記述から一からコードを生成しているため。公式 GitHub をクローンする選択肢なら数秒で済む（設計上のトレードオフ）。
③ 各ステージで何が起きたか
緑のドット = 成功、赤 = 失敗。各ステージは「生ログ（パイプラインが出力したそのまま）」と「解説（日本語の補足）」の 2 段で表示しています。生ログが英語なのは実装上のもので、噛み砕き解説はその下にあります。
④ 5 ステージのデータフロー
各ステージで何が入力され、何が出力されたかの流れ。これを見ると「arXiv URL という 1 行の入力から、最後は数値検証結果まで」変換されている全体像が分かります。
⑤ 主張の検証（論文の数値と実行結果の照合）
論文の Table 2 / Table 3 から Claude が抽出した 3 つの数値主張（すべて FID = 画像生成品質指標）を、実行結果と照合した結果です。各カードは「論文側のどの数値か（metric / dataset / モデル / 出典 Table）」と「照合結果（一致 / 不一致 / 未検証）」を示しています。
再現スコア 0.5 の中身
「3 件中、何件が一致確認できたか」のサマリ。今回はすべて 未検証（後述）でしたが、それでもスコアが 0 ではなく 0.5 なのは、PaperBench の hierarchical scoring がパイプラインの完走自体（実行成功）に部分点を与えているため。
各 claim の詳細
下の各カードは「論文の Table から取った 1 つの数値主張 + その照合結果」です。未検証（黄色）になっているのは「実行スクリプトが該当 metric を出力していなかった」が原因 — 実装上は FID 評価コードが Stage 4 で起動されていない or 出力フォーマットが違うのが理由。これは §1 PaperBench Iter での反復改善ループで対処できる課題です（v2 で fid_score.py を追加して 94.5% 達成済み）。
上記の 0.5 という数字は微妙すぎたので、4 つのコード改善（metric alias 拡張 / success 厳密化 / pdfplumber / max_tokens）を入れて、 PaperBench から 5 論文を選んで baseline / improved を比較。さらに同じ問題を自律研究エージェント (ARA) にも並行で解かせ、 人間が見落としていた既存バグ 4 件 と 1 仮説で +24.3pp の改善 を発見させました。
§4 Literature Scout
注意: 本日のショーケースでは arXiv API の rate limit（HTTP 429）と Semantic Scholar の 0 件返却でライブ取得が失敗。代わりに過去の代表的な出力を擬似サンプルとして表示しています。実体は CLI で動作確認済み。
① 動作の流れ
クエリ入力 → 並列 API 検索 → Claude による関連度判定 → ランク済み出力、の 4 ステップ。
② CLI 出力サンプル
実際のコマンドラインの様子。--context フラグで進行中の研究文脈を渡すのがポイント。
③ サンプル出力（代表的な論文）
関連度（0.0〜1.0）順にソートされ、Claude による判断理由が付く。なぜ関連と判定したかが透明なので、ユーザーが「これは読むべき / 違う」を瞬時に判断できます。
§5 4 コンポーネント 全体俯瞰
4 コンポーネントの「入力 / 出力 / 主な発見」を 1 枚で俯瞰。
それぞれが独立した CLI ツールですが、組み合わせると研究の end-to-end ループになります。組み合わせの詳細は 手法ページ §5 へ。
| コンポーネント | 入力 | 出力 | 主な発見 |
|---|