https://youtu.be/zz6jXpiT2Y8

Karpathy氏のオープンソースプロジェクト「AutoResearch」調査レポート

概要と背景

2026年3月7日、AI研究者の**Andrej Karpathy（アンドレイ・カルパシー）**がGitHubで公開した「AutoResearch」は、機械学習の実験ループをAIエージェントに任せるための630行程度のPythonスクリプトです。彼は実験のやり方を“Karpathy loop”と呼び、夜の間にAIが自律的に数十〜数百の実験を行い、改善が確認された変更だけをコミットする仕組みを示しました。The New Stackの記事によると、この自動化ループは「編集対象ファイル」「評価指標」「時間制限」という3つの要素で一般化できる。

Karpathy氏が実験していたのは小規模なGPTモデルの事前学習であり、従来は人間がハイパーパラメータやアーキテクチャを変更→数分〜数十分実行→検証値を確認→採用／破棄というサイクルを手動で繰り返していました。この反復的な作業を完全に自動化し、夜の睡眠時間に50以上の実験を進め、翌朝には成果のコミット履歴ができあがっていたと報告されています。に示すように、AutoResearchは**「科学的実験の方法」をコードに適用したもの**と捉えられています。

デザインパターンと設計思想

三つの要素

The New Stackの記事は、AutoResearchを支える設計パターンを次の三つに整理しています。

要素	役割・効果
編集対象ファイル (editable asset)	エージェントが変更できる唯一のファイル。AutoResearchでは`train.py`だけが編集対象です。対象を単一ファイルに限定することで探索空間が理解しやすくなり、変更の差分もレビュー可能になります。
スカラー指標 (scalar metric)	改善を判断するための単一の数値。AutoResearchでは検証データにおけるval_bpb（validation bits‑per‑byte）が採用され、トークン数やモデル変更に関係なく公正に比較できます。
時間制限付きサイクル (time‑boxed cycle)	実験の長さを固定することで結果を直接比較可能にします。AutoResearchは1回の訓練を5分に固定し、計算資源やモデルサイズが違っても同じ条件で評価できます。モデルサイズを倍にする変更も学習率を半分にする変更も同じ予算内で評価されます。

この三つの要素により、特定のMLタスクにとどまらない汎用的な実験ループが構築されます。論文ではなくマークダウン形式の文書（後述のprogram.md）を使って指示と制約を記述し、エージェントがそれを読み取り実行します。

システム構成 – 3ファイルアーキテクチャ

AutoResearchは3つのファイルの契約で動作します。

prepare.py – データ準備と評価を担当するファイル。BPEトークナイザを構築し、訓練データを前処理し、val_bpbを計算します。ユーザもエージェントも編集してはいけないため、公正な評価基準が保証されます。
train.py – GPTモデルのアーキテクチャ、Muon+AdamW最適化器、訓練ループを含む630行のスクリプトで、ここだけがエージェントに変更を許可されたサンドボックスです。活性化関数の変更や注意機構の工夫、学習率スケジュールの調整など、モデル・訓練コード全般を自由に改変できます。
program.md – 人間が記述するマークダウン文書で、エージェントへの実験方針・禁止事項・終了基準を定義します。基準となるval_bpbやVRAM使用量を記録し、実験実行コマンド、クラッシュ時の対処法、タイムアウト（10分以上は失敗扱い）などを細かく指示します。最も重要な指示は「NEVER STOP」で、実験ループが始まったら人間に相談せず永遠に回し続けることが求められています。

下図はAutoResearchのワークフローを示した概念図です。人間はprogram.mdで研究方針を指示し、AIエージェントがtrain.pyを編集して実験を実行します。prepare.pyが評価を行い、改善があればコミット、失敗ならリセットします。

デザイン上の工夫

READMEでは次のような設計上の配慮が紹介されています。

単一ファイルのみ編集：エージェントはtrain.pyだけを変更し、その他のファイルには触れないため、変更箇所が明確でレビューしやすいgithub.com。
固定時間予算：すべての実験が5分で終了するよう設計され、プラットフォームの違いによるばらつきを抑えますgithub.com。
自己完結型：PyTorchとごく少数のパッケージ以外に依存せず、分散訓練や外部サービスも不要で、単一GPU上で完結しますgithub.com。
プラットフォーム要件：基本はNVIDIA GPUを前提としますが、小型GPUやCPUでも動かせるようにTinyStoriesなど小さなデータセットを使い、ボキャブラリサイズやモデル深さ、バッチサイズを減らす工夫が紹介されていますgithub.com。
クローン/フォーク：公開直後からmacOS、Windows、AMD GPU向けなどのフォークが多数作成され、コミュニティによる拡張が進んでいますgithub.com。

実験ループの動作

program.mdには具体的な実験手順が記されています。DataCampの記事ではこのループを「ラチェット・ループ」と呼んでいます。

準備：program.mdを読んで研究方針や禁止事項を理解し、train.pyと過去の結果results.tsvを確認します。必要ならuv run prepare.pyでデータ準備を行いますgithub.com。
仮説立案・編集：モデルや最適化器、ハイパーパラメータを変更する仮説を立て、train.pyを修正しますgithub.com。
コミット：変更をgitブランチにコミットします（枝名はautoresearch/<タグ>）github.com。
実験実行：uv run train.pyを呼び出し、訓練を5分間行いますgithub.com。program.mdは出力をログにリダイレクトし、途中でstdoutを一切出さないよう指定していますgithub.com。
結果取得：ログからval_bpbやピークVRAM使用量などを抽出しますgithub.com。実験がクラッシュした場合はスタックトレースを確認し、軽微なタイプミスなどなら修正して再実行し、根本的に壊れている場合は「crash」と記録しますgithub.com。
結果記録：results.tsvに①コミットID②val_bpb③VRAM使用量④ステータス（keep/discard/crash）⑤変更内容の説明を追記しますgithub.com。例示ではベースラインに対して学習率を増やした変更が「keep」になっていますgithub.com。
判断とリセット：val_bpbが改善していれば変更を保持しブランチを「進める」。改善していなければgit reset HEAD~1で元の状態に戻しますgithub.com。これによりコードベースが常に改善方向へのみ「ラチェット」されます。
繰り返し：成功・失敗にかかわらず次の仮説を立ててループを続けます。program.mdは「NEVER STOP」と明記しており、人間が停止を指示するまでエージェントは実験を続けますgithub.com。

このループにより、1回あたり約12本の実験ができ、1晩（7〜8時間）で80〜100本の実験を自動的にこなせます。DataCampのレポートでは、初回の一晩の実験で83件中15件が採用され、val_bpbが0.9979から0.975まで改善したこと、2日間の拡張実験では約700回の変更から20件の改善を積み重ねることでGPT‑2の訓練時間を2.02時間から1.80時間へと約11 %短縮したことが報告されています。Karpathy氏はさらに大規模GPUクラスターで数千件の自律実験を行っており、コミュニティでもHyperspace AIなど複数エージェントがネットワーク越しに成果を共有し合う事例が生まれています。

実行環境とセットアップ

AutoResearchを動かすには、20 GB以上のVRAMを持つNVIDIA GPU、Python 3.10+、パッケージ管理ツールuv、およびコード生成エージェント（Claude Code、Cursor、Codexなど）が必要です。READMEに従って以下の手順でセットアップしますgithub.com。

リポジトリをクローンし、依存関係を同期します。

git clone https://github.com/karpathy/autoresearch.git cd autoresearch uv sync
初回のみデータ準備を行います（トークナイザやデータシャードの生成）。

uv run prepare.py
単一の訓練を手動で走らせ、環境が正しく動作することを確認します。

uv run train.py
コーディングエージェントをプロジェクトルートで起動し、program.mdを読み込ませて実験を開始させます。コマンドなどはエージェント側から実行されるため、ユーザはエージェントに対して「program.mdに従って実験を進めてください」といった指示を与えるだけで構いません。

結果とコミュニティ反応

実験成果

Karpathy氏の実験では、1晩で126本の実験が実行され、val_bpbは0.9979から0.9697まで下がりました。さらに深さ12のモデルを2日間自動チューニングした結果、約700件の変更のうち20件が有効で、より大きなモデルにその改善が転移したと報告されています。これにより既存のベンチマーク「Time to GPT‑2」が11 %短縮されました。
コミュニティ再現では、83件中15件の改善が採用され、val_bpbが1.000から0.975まで改善した例や、126件中7件が成功して0.9979→0.9697まで向上した例が紹介されています。ShopifyのCEO Tobi Lütke氏は、社内のクエリ拡張モデルにAutoResearchを適用し、37回の実験で19 %のスコア改善を得たと報告しています。
複数エージェントによるネットワーク実験では、35台のノードが計333本の実験を自律的に実施し、Xavier初期化やバンド化注意など過去の研究成果を短時間で再発見したケースが報告されました。

反響と応用可能性

VentureBeatの記事は、AutoResearchが単なる生産性向上ツールではなく「コードに対して科学的手法を自動化することで、知能の進歩スピードを人間の思考速度からシリコンの速度へ引き上げる根本的なシフト」であると評しています。この枠組みは機械学習以外の分野にも適用可能で、データベースクエリ最適化やサポートチケットルーティング、マーケティングのA/Bテストなど、明確な評価指標と反復実行が可能なタスクに広がると指摘されています。マーケティング領域では、従来は年間30件程度だった実験数を3万件以上に増やせるという野心的な応用例が紹介されました。

一方で、DataCampの記事は限界や課題も指摘しています。ラチェット・ループは直近の改善のみを採用するため、一時的な性能低下を許容して大きな改善を得るような探索ができず、局所解に陥りがちであること、同じ検証セットに対して多数の実験を行うと過剰適合のリスクがあること、LLMが安全志向（RLHFによる）で大胆な変更を避ける傾向があることが挙げられています。

まとめと展望

AutoResearchは、データ科学や機械学習の実験サイクルをエージェントに委ねるための最小限かつ実用的なオープンソース実装です。train.pyという単一の編集対象、val_bpbという明確な指標、5分間の固定時間という枠組みのもと、エージェントが連続的に改善を試み、Git 履歴に実験記録を残します。このアーキテクチャは、実験プロトコルをコードではなく**Markdownドキュメント（program.md）**として記述することで、人間が研究方針を示し、エージェントが実行・記録するという役割分担を可能にしました。

Karpathy氏は、この仕組みを「エージェント工学（agentic engineering）」の次の段階として位置づけ、人間はコードを書くのではなく実験設計を行う研究アドバイザーに進化すると述べています。現時点ではモデルをわずかに改良するような局所探索が中心ですが、将来的にはprogram.md自体をメタエージェントが最適化する試みや、複数エージェントが連携して探索範囲を広げる研究が始まっています。評価指標やデータセットの設計に人間の知見が必要な点は変わりませんが、このツールによって研究者は反復的な作業から解放され、新しいアイデアの提案や評価基準の設計に集中できるようになると期待されています。

AutoResearchを動かすには、20 GB以上のVRAMを持つNVIDIA GPU まあまあ高スペックのPCが要求されますか？

結論から言うと、「必須ではないが、かなり有利」です。 KarpathyのAutoResearchは設計的に軽量でも動くが、性能を出すにはGPUが欲しいという立ち位置です。

✔️ 必要スペックの実態

■ 推奨（Karpathyが想定している環境）

NVIDIA GPU（20GB以上 VRAM）
→ 例：RTX 3090 / A100 / H100

👉 これは「快適に回すための条件」です理由：

1回の実験が約5分
一晩で100回以上回す前提
モデルもそれなりに大きい

■ 最低限（実はもっと低くても動く）

AutoResearchの重要ポイントはここ👇 👉 モデル・データは自分で小さくできる つまり：

軽量設定なら

RTX 3060（8〜12GB）でもOK
さらに言えば
CPUでも動く（めちゃ遅いけど）

✔️ なぜ重いのか（本質）

AutoResearchが重い理由はツール自体ではなく👇 👉 中でやってるのが「GPTの学習」だから つまり：

train.py = 小型GPTの学習コード
prepare.py = データ処理
val_bpb = 言語モデル評価

👉 AutoResearch = フレームワーク 👉 重さ = 中身（モデル・データ）次第

✔️ スペック別の現実

① ハイスペック（3090以上）

一晩で数十〜100実験
実用レベル
Karpathyの再現が可能

② ミドル（3060 / 4060）

小さいモデルならOK
実験回数は減る
学習の安定性はやや低い

👉 現実的な個人開発ライン

③ 低スペック（CPU / ノートPC）

動くが
1実験 = 数十分〜数時間

👉 AutoResearchの価値（高速探索）がほぼ死ぬ

✔️ 重要なポイント（ここが本質）

AutoResearchの価値は👇 👉 「回数」×「試行錯誤」なので

GPUなし → 回数が減る → 価値減
GPUあり → 爆速で回る → 本領発揮

✔️ 現実的なおすすめ

あなたの用途別に整理すると：

■ とりあえず触る

ローカルPCでOK（3060でも十分）
モデルを小さくする

■ 本気で使う

GPUサーバー（RunPod / Lambda / AWS）
夜回し運用

■ 研究用途

複数GPU or クラスタ
→ AutoResearchの真価が出る

✔️ 面白いポイント（重要）

AutoResearchは実は👇 👉 「GPUがあると強い」ではなく 👉 「試行回数を稼げる環境が強い」 です

✔️ あなた向けの視点（かなり重要）

あなたは今：

ロボット（SCOUT）
VPR
実験ループ

をやってますよね 👉 実はAutoResearchの思想は完全に同じです

🔥 応用するとこうなる

AutoResearch的に言うと：

editable = 制御パラメータ / VPR閾値
metric = 成功率 / 停止率 / gap
loop = 自動実験

👉 つまり あなたの研究にそのまま適用できる

✔️ まとめ

高スペックGPUは「必須ではない」
ただし「価値を最大化するにはほぼ必須」
本質はGPUではなく「実験回数」

もしよければ👇 👉「SCOUT版AutoResearch（実験自動化）」を設計できますかなり相性いいので、これやると論文1本レベルになります

データベースクエリ最適化やサポートチケットルーティング、マーケティングのA/Bテストなど、明確な評価指標と反復実行が可能なタスクに広がると指摘されています。を具体的に教えてください

いいところに目を付けています。ここは AutoResearchの本質＝「実験ループの一般化」 が一番よく出る部分です。

✔️ まず前提（AutoResearchの抽象構造）

AutoResearchはこれだけ👇

editable（変更できるもの）
metric（評価指標）
loop（繰り返し）

👉 これに当てはまれば全部AutoResearch化できる

① データベースクエリ最適化

■ 何を最適化するのか

SQLクエリの書き方
インデックス設計
JOIN順序
実行プラン

■ AutoResearchに当てはめる

要素	内容
editable	SQLクエリ or 実行ヒント
metric	実行時間（ms）
loop	クエリを変えて実行→計測

■ 実際のループ

クエリを書き換える（JOIN順変えるなど）
実行
実行時間取得
速ければ採用、遅ければ戻す

👉 完全にAutoResearch

■ 具体例

-- before
SELECT * FROM A JOIN B ON ...

-- after（エージェントが提案）
SELECT * FROM B JOIN A ON ...

👉 これだけで数倍変わることもある

■ 強い理由

DBはブラックボックス最適化問題
人間の勘より探索が強い

👉 AutoResearchが刺さる典型

② サポートチケットルーティング

■ 何を最適化するのか

チケットをどの担当に振るか
優先度の付け方
自動返信の内容

■ AutoResearchに当てはめる

要素	内容
editable	ルーティングルール / LLMプロンプト
metric	解決時間 / CS満足度
loop	振り分け→結果評価

■ 実際のループ

「このチケットは技術チームへ」などルール変更
実運用 or シミュレーション
解決時間を測定
良ければ採用

■ 具体例

ルール変更：
- before：キーワードベース
- after：LLM分類

👉 metric：

平均解決時間
エスカレーション率

■ 本質

👉 組織のオペレーション最適化 これをAIが回す

③ マーケティング A/Bテスト

これが一番わかりやすいです

■ 何を最適化するのか

広告文
LP（ランディングページ）
ボタン配置
UI

■ AutoResearchに当てはめる

要素	内容
editable	コピー / デザイン
metric	CTR / CVR
loop	表示→クリック率測定

■ 実際のループ

広告文を変える
ユーザに表示
クリック率測る
良ければ残す

■ 具体例

A: 今すぐ登録
B: 無料で始める

👉 Bの方がCVR高い → 採用

■ AutoResearch化すると

👉 AIが勝手にこれを回す

コピー生成
配信
評価
改善

👉 人間いらなくなるレベル

✔️ 共通構造（重要）

全部まとめると👇

分野	editable	metric
DB	SQL	実行時間
サポート	ルール	解決時間
マーケ	コピー	CVR

👉 全部同じ構造

✔️ なぜAutoResearchが効くのか

理由はシンプル👇

① 人間は試行回数が少ない

1日10回とか

② AIは無限に回せる

1日1000回

👉 勝つのはどっちか明らか

✔️ さらに重要な話（本質）

AutoResearchは実は👇 👉 「AIが最適化問題を総当たりする仕組み」

✔️ あなたの研究への応用（かなり重要）

SCOUTに当てはめると👇

要素	内容
editable	VPR閾値 / step幅 / hold判定
metric	成功率 / 停止率
loop	走行→評価

👉 つまり 完全にAutoResearch適用対象

✔️ 一段深い話（かなり重要）

AutoResearchが効く条件👇

✔️ 向いている問題

評価が数値で出る
繰り返しできる
シミュレーション or 自動実行できる

❌ 向いてない問題

評価が主観（例：デザインの良さ）
1回のコストが高い（例：実機試験のみ）
ノイズが大きすぎる

✔️ まとめ

AutoResearchは「ML専用」ではない
本質は実験ループの自動化
DB・マーケ・業務改善すべてに適用可能
あなたのロボット研究とも完全一致

希望あれば👇 👉「SCOUT用AutoResearch設計（具体コードレベル）」まで落とせますこれ、普通に論文ネタになります

👉「SCOUT版AutoResearch（実験自動化）」を設計してください

できます。しかもSCOUTは AutoResearchの思想とかなり相性が良い です。あなたのケースでは、Karpathy版のように「train.pyを勝手に書き換えて学習」ではなく、走行パラメータ・判定ロジック・探索戦略をAIが自動で試す実験ループ にするのが本筋です。

SCOUT版AutoResearchの全体像

目的

SCOUTのTeach & Repeat / Step-and-Checkにおいて、

どのパラメータ設定が
どの条件で
どの程度うまくいくか

を、AIエージェントが自動で仮説生成→実験→評価→採用/棄却する仕組みにします。

1. SCOUT版AutoResearchの基本構造

Karpathy版に対応させるとこうなります。

AutoResearch原型	SCOUT版
editable asset	実験設定ファイル、判定ロジック、探索方針
scalar metric	成功率、停止適切性、逸脱量、衝突回避、進捗率
time-boxed cycle	1走行、または1条件×N試行
prepare.py	データ整理・評価計算・ログ抽出
train.py	実験対象コード（step幅、hold判定、jump判定等）
program.md	研究方針、禁止事項、評価優先順位

SCOUTでは、train.py相当を丸ごと編集させるより、まずは設定ファイル中心にした方が安全です。

2. まず採るべき設計方針

推奨は3段階です

段階1

設定ファイルのみ変更

step_m
move_speed
vpr_window
hold_stop_K
jump_stop_J
reverse_tol
reverse_stop_K
min_sim
min_gap
etc.

段階2

判定ロジックの閾値関数のみ変更

hold判定条件
jump判定条件
reverse判定条件
停止条件の組み合わせ

段階3

戦略そのものを変更

step幅の可変化
再探索動作追加
reverse時の挙動分岐
条件依存の速度切替

いきなり段階3に行くと危ないです。最初は**“設定探索 AutoResearch”**として回すのが堅実です。

3. システム構成

ファイル構成案

scout_autoresearch/
├─ README.md
├─ program.md
├─ prepare.py
├─ runner.py
├─ evaluate.py
├─ experiment_config.yaml
├─ controller_logic.py
├─ candidate_space.yaml
├─ results.tsv
├─ experiments/
│  ├─ exp_0001/
│  ├─ exp_0002/
│  └─ ...
├─ logs/
└─ prompts/
   └─ agent_prompt.md

4. 各ファイルの役割

`program.md`

人間が書く研究方針。最重要。中身の例：

今回改善したい対象は何か
何を変えてよいか
何を変えてはいけないか
何を成功とみなすか
何を危険とみなすか
実機試験回数制限
まずシミュレーション優先
衝突リスクがある設定は禁止
単純化を優先
改善量が小さくても頑健性が高いなら採用

これはKarpathy版のprogram.mdと同じで、研究者の意図を固定する憲法です。

`prepare.py`

評価器。絶対にAIが触ってはいけないファイル。役割：

実験ログ収集
CSV/TSV整形
スコア算出
安全性チェック
成功/失敗判定
総合指標算出

ここを固定することで、公平比較ができます。

`experiment_config.yaml`

AIが主に変更する設定。例：

step_m: 0.10
move_speed: 0.15
vpr_window: 35
min_sim: 0.82
min_gap: 0.0025
hold_window_fail_threshold: 10
hold_stop_K: 3
jump_stop_J: 30
reverse_tol: 3
reverse_stop_K: 2
recovery_turn_deg: 15
recovery_enabled: false

最初はこれだけ触らせれば十分です。

`controller_logic.py`

走行ロジック本体。最初はAI編集禁止でもよいです。後で限定的に編集許可します。

`runner.py`

1実験を実行するスクリプト。役割：

config読込
ROSノード起動確認
実験実行
ログ保存
異常終了時の後始末
実験ID発行

`evaluate.py`

prepare.pyから呼ばれてもよいですが、分離してもよいです。役割：

進捗率
stop_reason妥当性
teach indexの前進性
横ずれ
衝突/接近
無意味停止率
成功スコア

`results.tsv`

AutoResearchの中核ログ。例：

exp_id	config_hash	score	status	progress_ratio	stop_reason	collision	min_clearance_m	max_lateral_error_m	notes
0001	a81c2d1	0.62	keep	0.74	hold_stop	false	0.42	0.18	baseline
0002	b93df22	0.68	keep	0.81	hold_stop	false	0.39	0.12	increase jump_stop_J
0003	c12ed90	0.31	discard	0.95	wall_near	true	0.08	0.35	too aggressive

5. editable asset を何にするか

最初にAIに触らせる範囲を厳格に決めます。

レベルA: 触ってよい

experiment_config.yaml

レベルB: 条件付きで触ってよい

controller_logic.py の閾値関数のみ
recovery_policy.py の中の定義済み候補のみ

レベルC: 触らせない

prepare.py
evaluate.py
ROS安全停止処理
実機インタフェース
緊急停止処理
障害物検出系
実験データ原本

これが重要です。 SCOUTは実機なので、Karpathy版より制約を強くする必要があります。

6. metric の設計

ここが最重要です。 1つのスカラーに落とせないとAutoResearch化しにくいです。

推奨：総合スコア化

例えば：

score =
+ 0.45 * progress_score
+ 0.20 * stop_quality_score
+ 0.15 * safety_score
+ 0.10 * path_stability_score
+ 0.10 * simplicity_bonus
- 0.30 * collision_penalty
- 0.20 * false_stop_penalty
- 0.15 * reverse_penalty

各要素の具体例

1) progress_score

どこまで進めたか。

progress_score = stop_best_idx / total_teach_idx

または距離比率。

2) stop_quality_score

止まるべきときに止まったか。例：

壁近接で停止 → 高評価
まだ進めるのに停止 → 低評価
完全に逸脱しても進み続ける → 低評価

3) safety_score

最小障害物距離
衝突なし
急旋回なし
異常速度なし

4) path_stability_score

横ずれ
進捗の単調性
teach indexの前進の安定性
reverse頻度

5) simplicity_bonus

設定やロジックが複雑すぎないことを優遇。 Karpathy版の「シンプルな改善を優先」を入れる。

7. 実験単位の設計

案A: 1条件1回

速いがノイズが大きい。

案B: 1条件3回

おすすめ。同じ条件を3回走らせ、平均スコアで評価。

案C: 1条件×複数環境

最も良い。例：

通常照明
少しズレた開始位置
若干の速度差
teach密度違い

これで頑健性を見られます。

8. SCOUT版の実験ループ

自律ループ

program.mdを読む
results.tsvを見る
現在のベースライン設定を確認
次の仮説を立てる
experiment_config.yamlを書き換える
runner.pyで実験
prepare.pyで評価
results.tsvに記録
スコア改善ならkeep
改善しなければdiscard
次へ進む

これはKarpathy版そのものです。

9. program.md の中身の雛形

以下のように書きます。

研究目的

Step-and-Checkの停止判断を改善し、安全性を保ちつつ進捗率を最大化する。

現時点の課題

hold_stop_Kが小さすぎると早停止する。
jump_stop_Jが小さすぎると探索不足、大きすぎると危険。
min_simとmin_gapのバランスで誤停止が発生する。

変更してよいもの

experiment_config.yaml 内の閾値
既定候補内での recovery_policy

変更してはいけないもの

緊急停止処理
実験評価器
実機安全制約
ROSサービスI/F

成功条件

progress_ratio を高める
collision = false
false_stop を減らす
reverse頻度を抑える

優先順位

安全性
適切な停止
進捗率
単純さ

ルール

危険設定は試さない
一度に大きく変えすぎない
良い方向が見えたら局所探索
行き詰まったら探索幅を広げる

10. 具体的に探索させるパラメータ

まずはこのへんです。

運動系

step_m
move_speed
rotate_speed
recovery_turn_deg

VPR系

vpr_window
min_sim
min_gap
global_relocalize_interval

停止判定系

hold_window_fail_threshold
hold_stop_K
jump_stop_J
reverse_tol
reverse_stop_K

回復行動系

recovery_enabled
recovery_policy
micro_back_enabled

11. 探索戦略

AIに何でも自由にやらせるより、探索戦略も決めた方がいいです。

フェーズ1: 粗探索

広く試す。

step_m = 0.05, 0.08, 0.10, 0.12
jump_stop_J = 20, 30, 40, 50
hold_stop_K = 2, 3, 4, 5

フェーズ2: 局所探索

良さそうな周辺を細かく。

step_m = 0.08, 0.09, 0.10
jump_stop_J = 28, 32, 36
min_gap = 0.0022, 0.0025, 0.0028

フェーズ3: 相互作用探索

speed × step
sim × gap
hold × jump の組み合わせを見る。

12. 実機向け安全制約

ここは絶対入れるべきです。

ルール例

move_speed > 0.20 禁止
step_m > 0.15 禁止
jump_stop_J > 80 禁止
hold_stop_K < 2 禁止
近接センサしきい値を下回ったら即停止
実機は必ず監視者つき
夜間完全無人は禁止

つまりSCOUT版は、 **完全無人ではなく「半自律研究ループ」**から始めるのが現実的です。

13. シミュレーション優先構成

本命はこれです。

推奨構成

まずオフライン評価
次に簡易シミュレータ
最後に実機確認

レベル1: オフライン再生

記録済み画像列・ログ列に対して判定だけ試す

レベル2: 擬似実験

過去ログを使って、もしこの設定ならどこで止まるか再計算する

レベル3: 実機

上位候補だけ実機投入これにすると、実機消耗と危険を大幅に減らせます。

14. あなたの研究テーマに直結する metric 例

あなたのVPR as State Monitorに合わせるなら、総合スコアはこう作れます。

提案スコア

score =
+ 0.40 * normalized_progress
+ 0.20 * stop_correctness
+ 0.15 * safety_margin
+ 0.15 * monotonicity_of_best_teach_idx
+ 0.10 * low_lateral_deviation
- 0.25 * collision_or_near_collision
- 0.15 * unnecessary_early_stop
- 0.10 * oscillation_penalty

monotonicity_of_best_teach_idx

best_teach_idx が前進傾向にあるか。これはあなたの「停滞」「逆行」検出の考え方に合います。

unnecessary_early_stop

holdで止まったが、その後のログを見るとまだ進めた可能性が高いケースを罰する。

oscillation_penalty

左右振れや前後行き来が多い場合を減点。

15. AIエージェントに渡すべきプロンプト方針

AIへの指示は、こんな感じにします。

コア指示

安全性を最優先せよ
評価器は変更するな
まず設定ファイルだけを変えよ
大胆すぎる変更は避けよ
改善が確認できた変更だけを保持せよ
ログから仮説を作れ
停滞・逆行・過早停止の原因を推定せよ
同じ失敗を繰り返すな
単純で解釈しやすい改善を優先せよ

16. results.tsv に入れるべき列

おすすめ列はこれです。

exp_id
parent_exp_id
timestamp
config_hash
step_m
move_speed
vpr_window
min_sim
min_gap
hold_stop_K
jump_stop_J
reverse_tol
reverse_stop_K
progress_ratio
stop_best_idx
stop_reason
collision
near_collision
min_clearance_m
max_lateral_error_m
reverse_count
hold_count
jump_count
score
status
notes

こうしておくと、あとで論文の表にも使えます。

17. SCOUT版AutoResearchの最初の研究テーマ

まずはこれが一番よいです。

テーマA

停止パラメータ最適化

hold_stop_K
jump_stop_J
reverse_stop_K
min_sim
min_gap

目的：

早止まりを減らしつつ危険進行を防ぐ

これはあなたの既存研究に直結です。

テーマB

teach密度に対する頑健化

sub1 / sub2 / sub3 で最適設定がどう変わるか

目的：

撮影密度依存を潰す

テーマC

step幅・速度の共同最適化

step_m × move_speed の最適領域探索

目的：

安全と効率の両立

18. 論文としての新規性

これ、普通に論文化できます。

タイトル案

小型移動ロボットにおける自律実験ループを用いた視覚ベースTeach and Repeatのパラメータ最適化
VPR状態監視型ナビゲーションに対するエージェントベース自動実験手法
実機制約下の移動ロボット実験に対するAutoResearch型評価ループの設計と検証

新規性の芯

LLMでロボット実験条件を自律探索
実機安全制約込み
VPR停止判定最適化
人手による試行錯誤の削減
実験ログからの仮説生成

19. 最初に作るべき最小実装

最初はこれだけで十分です。

MVP

experiment_config.yaml
runner.py
prepare.py
results.tsv
program.md

AIは

configだけ変更
実験実行
評価
keep/discard を行う

この段階で十分「SCOUT版AutoResearch」です。

20. 実装順序

Step 1

オフライン評価器を固定する

Step 2

設定ファイル変更だけで回す

Step 3

複数回試行平均にする

Step 4

回復行動の選択肢を導入

Step 5

必要なら一部ロジック編集を許可

21. あなた向けの具体提案

あなたの今の研究テーマに一番合う初期版はこれです。

初期版テーマ

「hold/jump/reverse停止条件の自動探索」

editable

hold_stop_K
jump_stop_J
reverse_tol
reverse_stop_K
min_sim
min_gap

metric

progress_ratio
false_stop率
near_collision率
stop_reason妥当性

dataset

既存のauto_runログ一式
sub2 / sub3 teach list
正常系・逸脱系・壁接近系

狙い

「どこで止めるべきか」の設計を人手勘から半自動化する

これはかなり筋がいいです。

必要なら次に、 program.md の実物テンプレート と results.tsv の列設計 と runner.py / prepare.py の雛形コード まで一気に書きます。

評価の中で実際に走行させられるの？

はい、設計としては可能です。ただし、ここで私が直接SCOUTを動かせるわけではありません。実際の走行は、あなたのPC上のスクリプトやROSノードからSCOUTに命令して実行する形になります。整理すると、評価には3段階あります。

1. オフライン評価

これは実走行なしです。既存のログ、画像列、vpr_match.csv、best_teach_idx 推移、停止理由などを使って、

この条件ならどこで止まるか
停滞判定が早すぎないか
逆行判定が敏感すぎないか

を再計算します。これは安全で大量に回せるので、最初にやるべき段階です。

2. 半実機評価

これはSCOUTを実際に走らせる評価です。ただし、AutoResearch本体が直接ロボットを持っているわけではなく、runner.py のような実験実行スクリプトが、

設定ファイルを書き換える
ROSサービスを呼ぶ
1回の走行を実施する
ログを保存する
終了後に評価器へ渡す

という流れで進めます。たとえばあなたの今の環境なら、/UtilNode/algo_move や /UtilNode/algo_action を使う実装にできます。つまり「評価の中で実際に走行させる」は、ローカルの実験実行コードを介してなら十分可能です。

3. 完全自動の連続実走行

理屈の上では可能ですが、最初からはおすすめしません。理由は単純で、SCOUTは実機だからです。

壁接近
想定外の横ずれ
サービス呼び出し失敗
通信切れ
センサ異常
/cmd_vel 競合や停止漏れ

があるので、Karpathy版のように「夜の間に完全無人で回す」は危険です。現実的には、

オフラインで100条件ふるい落とす
上位3〜5条件だけ実機で試す
実機は監視者つきで回す

という運用がよいです。

実際の流れ

実走行を含めるなら、1実験はこうなります。

experiment_config.yaml を更新
runner.py がROS環境を確認
SCOUTに開始位置を合わせる
Step-and-Checkを1本実行
実行ログ、画像、best_teach_idx 推移、停止理由を保存
prepare.py / evaluate.py がスコア算出
results.tsv に keep/discard を記録

なので、評価の一部として実際に走行させることはできる、が正確な答えです。ただし本当に重要なのは、**「毎回実走行しなくてもいいように段階化すること」**です。あなたの研究では、まずオフライン評価器を強くして、実機は最終確認だけに使う構成がかなり相性が良いです。あなたのSCOUT環境に合わせて言うと、次に作るべきは 「1条件を自動で実走行して、ログ保存まで行う runner.py の仕様」 です。

【管理人の独り言】

【管理人メルマガ】副業でも稼げるヒミツ

【管理人メルマガの宣伝 終わり】

Karpathy氏のオープンソースプロジェクト「AutoResearch」調査レポート

概要と背景

デザインパターンと設計思想

三つの要素

システム構成 – 3ファイルアーキテクチャ

デザイン上の工夫

実験ループの動作

実行環境とセットアップ

結果とコミュニティ反応

実験成果

反響と応用可能性

まとめと展望

AutoResearchを動かすには、20 GB以上のVRAMを持つNVIDIA GPU まあまあ高スペックのPCが要求されますか？

✔️ 必要スペックの実態

■ 推奨（Karpathyが想定している環境）

■ 最低限（実はもっと低くても動く）

軽量設定なら

✔️ なぜ重いのか（本質）

✔️ スペック別の現実

① ハイスペック（3090以上）

② ミドル（3060 / 4060）

③ 低スペック（CPU / ノートPC）

✔️ 重要なポイント（ここが本質）

✔️ 現実的なおすすめ

■ とりあえず触る

■ 本気で使う

■ 研究用途

✔️ 面白いポイント（重要）

✔️ あなた向けの視点（かなり重要）

🔥 応用するとこうなる

✔️ まとめ

データベースクエリ最適化やサポートチケットルーティング、マーケティングのA/Bテストなど、明確な評価指標と反復実行が可能なタスクに広がると指摘されています。 を具体的に教えてください

✔️ まず前提（AutoResearchの抽象構造）

① データベースクエリ最適化

■ 何を最適化するのか

■ AutoResearchに当てはめる

■ 実際のループ

■ 具体例

■ 強い理由

② サポートチケットルーティング

■ 何を最適化するのか

■ AutoResearchに当てはめる

■ 実際のループ

■ 具体例

■ 本質

③ マーケティング A/Bテスト

■ 何を最適化するのか

■ AutoResearchに当てはめる

■ 実際のループ

■ 具体例

■ AutoResearch化すると

✔️ 共通構造（重要）

✔️ なぜAutoResearchが効くのか

① 人間は試行回数が少ない

② AIは無限に回せる

✔️ さらに重要な話（本質）

✔️ あなたの研究への応用（かなり重要）

✔️ 一段深い話（かなり重要）

✔️ 向いている問題

❌ 向いてない問題

✔️ まとめ

👉「SCOUT版AutoResearch（実験自動化）」を設計してください

SCOUT版AutoResearchの全体像

目的

1. SCOUT版AutoResearchの基本構造

2. まず採るべき設計方針

推奨は3段階です

段階1

段階2

段階3

3. システム構成

ファイル構成案

4. 各ファイルの役割

program.md

prepare.py

experiment_config.yaml

controller_logic.py

【管理人メルマガの宣伝　終わり】

データベースクエリ最適化やサポートチケットルーティング、マーケティングのA/Bテストなど、明確な評価指標と反復実行が可能なタスクに広がると指摘されています。を具体的に教えてください

`program.md`

`prepare.py`

`experiment_config.yaml`

`controller_logic.py`

`runner.py`

`evaluate.py`

`results.tsv`