mcpField
A
autoresearch

autoresearch

github.com/githubエージェントワークフロー40.5k3.4k 回インストール1 日前に更新
リポジトリ

autoresearch について

測定可能な成果を持つプログラミング作業向けの、自律実験スキルです。目標、指標、変更範囲を確認してから基準値を測定し、結果を記録しながら反復し、指標が改善しない変更は戻します。

主な機能

  1. 01目標と実験範囲の対話的な設定
  2. 02指標のベースライン測定
  3. 03各実験前のコミット
  4. 04TSV での測定結果記録
  5. 05改善しない変更の取り消し

活用シーン

  1. 01実行時間やメモリ使用量の最適化
  2. 02テスト合格率やカバレッジの向上
  3. 03コード変更によるビルド指標の比較

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill autoresearch

インストール後、Claude Code で/autoresearchを入力して読み込まれたか確認します。

詳細

Autoresearch：自律的な反復実験

あらゆるプログラミングタスクに対応する、自律的な実験ループです。目標と測定方法を定義すると、エージェントはコードの変更、実験の実行、結果の測定、変更の維持または破棄を自律的に繰り返し、中断されるまで続けます。

このスキルはKarpathyのautoresearchに着想を得ており、MLのトレーニングから、測定可能な成果を伴うあらゆるプログラミングタスクへと一般化したものです。

エージェントの動作ルール

  1. 必ずループを開始する前に、セットアップフェーズを対話形式でユーザーに案内してください。
  2. 必ず変更を加える前に、ベースラインを測定してください。
  3. 必ず実験を実行する前に、すべての実験の試行をコミットしてください（確実に元に戻せるようにするためです）。
  4. 必ずすべての実験を記録した結果ログ（TSV）を保持してください。
  5. 必ず指標が改善しない変更は元に戻してください（最後に確認された良好な状態までgit resetします）。
  6. 必ずループ開始後は自律的に実行し、「続けてもよいですか？」と尋ねるために処理を中断しないでください。
  7. 絶対にユーザーが対象外と指定したファイルを変更しないでください。
  8. 絶対に測定のステップを省略しないでください。すべての実験で測定が必要です。
  9. 絶対にユーザーがトレードオフを明示的に許可しない限り、指標が悪化する変更を維持しないでください。
  10. 絶対にユーザーの承認なしに、新しい依存関係をインストールしたり環境を変更したりしないでください。

フェーズ 1：セットアップ（対話形式）

実験を始める前に、ユーザーと協力して以下のパラメーターを設定します。 各項目についてユーザーに直接尋ねてください。推測したり、省略したりしないでください。

1.1 目標を定義する

ユーザーに尋ねます。

何を改善または最適化しようとしていますか？

例：実行時間、メモリ使用量、バイナリサイズ、テスト合格率、コードカバレッジ、 API 応答レイテンシー、スループット、エラー率、ベンチマークスコア、ビルド時間、バンドルサイズ、 行数、循環的複雑度など。

ユーザーの回答を目標として記録します。

1.2 指標を定義する

ユーザーに尋ねます。

成功をどのように測定しますか？指標を生成する正確なコマンドは何ですか？

以下が必要です。

  1. 実行するコマンド（例：dotnet test、npm run benchmark、time ./build.sh、pytest --tb=short）
  2. 出力から指標を抽出する方法（例：正規表現パターン、特定の行、JSON フィールド）
  3. 方向：小さいほど良いですか、それとも大きいほど良いですか？

例：「dotnet test --logger trxを実行し、合格したテストの数を数えます。多いほど良いです。」 例：「hyperfine './my-program'を実行し、平均時間を抽出します。短いほど良いです。」

以下を記録します。

  • METRIC_COMMAND：実行するコマンド
  • METRIC_EXTRACTION：数値の指標を抽出する方法
  • METRIC_DIRECTION：lower_is_betterまたはhigher_is_better
1.3 範囲を定義する

ユーザーに尋ねます。

変更してよいファイルやディレクトリはどれですか？

また、変更禁止（読み取り専用）のファイルはどれですか？

以下を記録します。

  • IN_SCOPE_FILES：エージェントが編集できるファイルやディレクトリ
  • OUT_OF_SCOPE_FILES：変更してはならないファイルやディレクトリ
1.4 制約を定義する

ユーザーに尋ねます。

守るべき制約はありますか？

例：

  • 実験ごとの時間予算（例：「各実行は2分未満にする」）
  • 新しい依存関係を追加しない
  • 既存のすべてのテストを合格した状態に保つ
  • パブリック API を変更しない
  • 後方互換性を維持する
  • VRAM／メモリの上限
  • コードの複雑さに関する制限（よりシンプルな解決策を優先する）

CONSTRAINTSとして記録します。

1.5 実験の予算を定義する（任意）

ユーザーに尋ねます。

実験は何回実行しますか？それとも、停止を指示されるまで続けますか？

数字（例：「20回試す」）または「無制限」と指定できます（中断されるまで実行します）。

MAX_EXPERIMENTS（数値またはunlimited）として記録します。

1.6 シンプルさの基準

デフォルトのシンプルさポリシーをユーザーに伝えます。

シンプルさポリシー（デフォルト）： ほかの条件が同じであれば、よりシンプルなほうが優れています。見栄えの悪い複雑さを加えるほどの価値がない小さな改善は、採用する価値がありません。指標を維持または改善しながらコードを削除できれば、素晴らしい成果です。複雑さによるコストと改善の大きさを比較して判断します。このポリシーでよいですか。それとも調整しますか？

調整内容は SIMPLICITY_POLICY として記録します。

1.7 セットアップの確認

すべてのパラメーターをわかりやすい表にまとめて、ユーザーに提示します。

パラメーター値
目標...
指標のコマンド...
指標の抽出方法...
方向低いほどよい／高いほどよい ...
対象範囲内のファイル...
対象範囲外のファイル...
制約...
最大実験数...
シンプルさポリシー...

ユーザーに確認を求めます。確認が取れるまで先に進まないでください。

フェーズ 2：ブランチとベースライン

ユーザーの確認後：

  1. ブランチを作成する：今日の日付に基づいたタグを提案します（例：autoresearch/mar17）。 ブランチを作成します：git checkout -b autoresearch/<tag>。

  2. 対象範囲内のファイルを読む：現在の状態を十分に把握するため、対象範囲内のすべてのファイルを読みます。

  3. results.tsv を初期化する：リポジトリのルートに、次のヘッダー行を含む results.tsv を作成します。

    experiment	commit	metric	status	description

    .git/info/exclude に results.tsv と run.log を追加します（すでに記載されている場合は追記せず、追跡対象ファイルを変更しないまま、これらを未追跡の状態に保ちます）。

  4. ベースラインを実行する：変更を加えていない現在のコードに対して、指標のコマンドを実行します。 results.tsv に、ステータスを baseline として実験 0 の結果を記録します。

  5. ベースラインを報告する：

    ベースラインを確立しました：[metric_name] = [value] 自律的な実験ループを開始します。

フェーズ 3：実験ループ

このループを継続して実行します。ユーザーに確認を求めるために停止しないでください。次のいずれかに該当するまで実行します。

  • MAX_EXPERIMENTS に到達した
  • ユーザーが手動で中断した
実験ごとに：
LOOP:
  1. THINK   - Analyze previous results and the current code.
               Generate an experiment hypothesis.
               Consider: what worked, what didn't, what hasn't been tried.

  2. EDIT    - Modify the in-scope file(s) to implement the idea.
               Keep changes focused and minimal per experiment.

  3. COMMIT  - git add + git commit with a short descriptive message.
               Format: "experiment: <short description of what changed>"

  4. RUN     - Execute the metric command.
               Redirect output to run.log so it does not flood the context window.
               Use shell-appropriate redirection:
               - Bash/Zsh: `<command> > run.log 2>&1`
               - PowerShell: `<command> *> run.log`

  5. MEASURE - Extract the metric from run.log.
               If extraction fails (crash/error), read the last 50 lines
               of run.log for the error.

  6. DECIDE  - Compare metric to the current best:
               - IMPROVED: Keep the commit. Update the "best" baseline.
                 Log status = "keep".
               - SAME OR WORSE: Revert. `git reset --hard HEAD~1`.
                 Log status = "discard".
               - CRASH: Attempt a quick fix (typo, import, simple error).
                 Amend the experiment commit (`git commit --amend`) with the fix
                 and rerun. The experiment keeps its original number.
                 If unfixable after 2 attempts, revert the entire experiment
                 (`git reset --hard HEAD~1`) and log status = "crash".

  7. LOG     - Append a row to results.tsv:
               experiment_number  commit_hash  metric_value  status  description

  8. CONTINUE - Go to step 1.
実験戦略

実験案を作成するときは、次の優先順位に従います。

  1. すぐにできる改善を優先する：単純なパラメーター調整や、明らかな非効率性への対処。
  2. 結果を踏まえる：有望な方向性があれば、その方向性をさらに探ります。
  3. 停滞したら多様化する：直近の3～5回の実験がすべて失敗した場合は、まったく異なるアプローチを試します。
  4. 成功した変更を組み合わせる：実験Aと実験Bがそれぞれ単独で改善した場合は、組み合わせを試します。
  5. シンプル化を試す：指標を維持できるか確認するため、定期的にコードや複雑さを取り除いてみます。
  6. 抜本的な変更を試す：段階的な案を試し尽くした後で、より大規模なアーキテクチャ変更を試します。
制約への対処
  • 時間の予算：実行時間が予想時間の2倍を超えた場合は終了し、クラッシュとして扱います。
  • 既存のテスト：制約にテストの合格が含まれる場合は、実行前と実行後にテストを実行し、失敗した場合は変更を元に戻します。
  • メモリ／リソース：リソースの使用量を監視し、指定された上限を超えた場合は変更を元に戻します。

フェーズ 4：報告

ループが終了したとき（予算に達した場合、またはユーザーが中断した場合）：

  1. results.tsv 全体を整形済みの表として表示します。
  2. 次の内容を要約します：
    • 実行した実験の合計数
    • 採用／破棄／クラッシュした実験の数
    • 開始時の指標（ベースライン）と最終指標
    • 改善率
    • 最も大きな効果があった変更の上位3件
  3. 採用した実験の累積 git ログを表示します。 git log --oneline <start_commit>..HEAD
  4. 次のステップを提案する：結果に基づいて、人間の研究者が次に試すとよい案を提案します（自動実験にはリスクや複雑さが大きすぎた案）。

クイックリファレンス

Results TSV の形式

タブ区切り、5列：

experiment	commit	metric	status	description
0	a1b2c3d	0.997900	baseline	unmodified code
1	b2c3d4e	0.993200	keep	increase learning rate to 0.04
2	c3d4e5f	1.005000	discard	switch to GeLU activation
3	d4e5f6g	0.000000	crash	double model width (OOM)
Git ワークフロー
  • すべての実験は autoresearch/<tag> ブランチで行います
  • 各実験は実行前にコミットします
  • 失敗した実験は git reset --hard HEAD~1 で取り消します
  • 成功した実験ではブランチを進めます
  • results.tsv と run.log は追跡対象にしません（.git/info/exclude に追加します）
主要な原則
  1. すべてを測定する：測定なしで実験を行ってはいけません。
  2. 失敗を取り消す：ブランチを進めるのは改善があった場合のみです。
  3. 自律的に行動する：質問するために作業を止めてはいけません。行き詰まったら、さらに深く考えます。
  4. シンプルに保つ：複雑さにはコストが伴います。得られる効果と比較して判断します。
  5. すべてを記録する：TSV は研究記録です。

コメント

Markdown 対応