autoresearch

autoresearch skill の概要

autoresearch は何のための skill か

autoresearch は、成功を計測できるコーディング作業に向いた、自律型の実験ループです。エージェントに大きな修正を一発で頼むのではなく、目標・指標・制約を先に定義し、そのうえで変更、テスト、計測、採用または巻き戻しの判断を反復して進めます。

autoresearch を導入すべき人

autoresearch skill が最も合うのは、一度きりの回答ではなく、再現性のある改善を求める開発者です。特に有効なのは次のようなケースです。

• パフォーマンスチューニング
• プロンプトで駆動するベンチマーク改善
• 信頼性やテスト通過率の改善
• ビルド時間や実行コストの削減
• 複数の実装案を安全に試したい場合

単純なバグ修正、コードレビュー、あるいは成果を測定できない作業であれば、autoresearch はたいてい適していません。

実際に解決したい仕事

ユーザーが autoresearch を採用するのは、エージェントに「コード生成役」ではなく「実験オペレーター」として振る舞ってほしいからです。やるべきことは「コードを書く」ではなく、「定義済みの指標に対して規律ある反復を回し、改善が頭打ちになるか制約に達したら止める」ことです。

通常のプロンプトと autoresearch の違い

通常のプロンプトは、ひとつの解決案を返して終わることが少なくありません。これに対して、autoresearch for Workflow Automation は次の要素を前提に作業を構造化します。

• 明示的なゴール
• ベースライン計測
• 再現可能な実験ループ
• git ベースのチェックポイント
• 結果を残すか捨てるかの判断プロセス

この違いが効くのは、効きそうな変更案が複数あり、どれが本当に有効かを計測でしか判断できない場面です。

最初に知っておきたい導入上の制約

autoresearch install を試す前に、次の必須条件を確認してください。

• プロジェクトがすでに git リポジトリであること
• エージェントがターミナルを使えること
• 作業に測定可能な指標があること
• その指標を反復に耐える頻度で実行できること

この skill は補助ファイルが少なく、実質的に SKILL.md が中心です。導入判断では、機能の多さよりも、そのワークフローが自分の環境に合うかどうかが重要になります。

autoresearch skill の使い方

skill 環境に autoresearch をインストールする

GitHub の skill リポジトリから、次のコマンドでインストールします。

npx skills add github/awesome-copilot --skill autoresearch

インストール後は、まず skills/autoresearch/SKILL.md を開いてください。この skill には追加スクリプトや補助リファレンスがないため、運用上の詳細のほとんどはこのファイルに集約されています。

まず最初に読むべきファイル

最初に確認するのは次です。

• SKILL.md

このリポジトリには独立した自動化アセットが含まれていないため、autoresearch usage の良し悪しは、隠れたツールを探すことではなく、このファイルに書かれたワークフローを正しく理解できるかにかかっています。

自分のプロジェクトに合うかを確認する

autoresearch を使うべきなのは、次の3つすべてに答えられるときです。

1. どの成果を、正確に改善したいのか
2. それをどう測定するのか
3. 破ってはいけない制約は何か

良い例:

• 「すべてのテストをグリーンに保ったまま、endpoint latency を 20% 下げる」
• 「bench/search.js の benchmark throughput を上げつつ、メモリ増加を 10% 以内に抑える」
• 「不安定なテストの pass rate を 82% から 95% に改善する」

弱い例:

• 「コードをもっときれいにする」
• 「このあたりをリファクタする」
• 「悪そうなところを直す」
• 「アーキテクチャを改善する」

ループ開始前に指標を定義する

この autoresearch guide で最も重要な準備は、エージェントが実際に実行できる指標を選ぶことです。強い指標には、次の特徴があります。

• 客観的である
• 再実行に十分な速さがある
• 比較できる程度に安定している
• 本当の目標に結びついている

例:

• npm test -- --runInBand
• 中央値の実行時間を取る benchmark script
• build duration
• ローカル harness から測る request latency
• binary size
• 繰り返し実行時の failure count

指標にノイズが多い場合は、複数回実行するか、有意な改善とみなすための閾値を設けてください。

曖昧な目標を強いプロンプトに変える

弱い依頼だと、ループは何を基準に進めるべきか判断できません。強い依頼は、エージェントに対して目標、指標、対象範囲、停止条件を明確に渡します。

弱い例:

Use autoresearch to improve this service.

より強い例:

Use autoresearch on this repository to reduce npm run bench:api median latency by at least 15%. Keep npm test passing, do not change external API behavior, and limit work to src/cache and src/http. Establish a baseline first, commit each experiment, and stop after 8 iterations or when improvements plateau.

このプロンプトが機能しやすいのは、ループ側で安全に推測できない曖昧さを先に取り除いているからです。

スコープ制約を明示して渡す

この skill は、セットアップ詳細を対話的に確認する前提で設計されています。次の情報を先に指定しておくと、より安定して使えます。

• 変更を許可するディレクトリ
• 触ってはいけないファイル
• 依存関係の変更を許可するかどうか
• 実行時間やメモリの上限
• 許容できるトレードオフ
• 最大反復回数

これがないと、エージェントは本来すぐ除外できたはずの領域の探索に反復回数を使ってしまうことがあります。

想定どおりの autoresearch ループで進める

実運用では、autoresearch skill は次の流れで使うのが最も効果的です。

1. ゴールを定義する
2. 指標を定義する
3. ベースラインを記録する
4. 実験案をひとつ提案する
5. コードを変更する
6. 計測を実行する
7. ベースラインと比較する
8. 採用するか捨てるか決める
9. その試行を commit する
10. 停止条件を満たすまで繰り返す

運用上の要点は、大きく自律リファクタリングさせることではなく、制御された反復を回すことです。

skill が想定する形で git を使う

ここでは git は必須です。ワークフローは、各実験の試行をチェックポイントとして残す前提で成り立っています。これにより次の利点があります。

• 試行を巻き戻せる
• アイデア同士を比較しやすい
• 監査しやすい履歴が残る
• 自律的な探索をより安全に進められる

開始前の working tree が散らかっているなら、先に整理してください。各試行が分離されているほど、autoresearch は信頼しやすくなります。

実リポジトリでの autoresearch usage の進め方

autoresearch usage を実際のリポジトリで回すなら、次の手順が現実的です。

1. working tree をクリーンにする
2. metric command がローカルで動くことを確認する
3. baseline を一度手動で確認する
4. ゴール、指標、スコープを添えて skill を起動する
5. 小さな単位で反復させる
6. 捨てた案すべてではなく、採用した commit をレビューする
7. merge 前に勝ち筋の結果を自分でも再実行して確認する

この流れなら、実験ループの利点を活かしつつ、レビューの規律も手放さずに済みます。

出力品質をすばやく上げるコツ

効果の大きい習慣は次のとおりです。

• 競合する目標を5つ並べるのではなく、主要な指標を1つに絞る
• 最初は実験対象の範囲を小さく保つ
• 「回帰なし」の定義を先に決める
• 最大反復回数を設定する
• 試行内容と結果の短いログを求める
• 主観評価より、測定できるローカルコマンドを優先する

凝った言い回しより、こうした設定のほうが結果を大きく左右します。

autoresearch skill の FAQ

autoresearch は普通のコーディングプロンプトより優れている？

測定可能な最適化タスクなら、はい。単発の実装依頼なら、たいていは違います。autoresearch の価値は、最初のコード生成品質そのものではなく、計測を伴う反復試行にあります。

autoresearch は初心者にも使いやすい？

初心者でも使えますが、実行可能な指標を定義できて、スコープを決められる程度にはリポジトリを理解している必要があります。この skill は実験の手探りを減らしてくれますが、明確な成功条件の必要性まではなくしてくれません。

どんなときは autoresearch を使うべきではない？

次のような場合は autoresearch skill を見送るべきです。

• 信頼できる指標がない
• タスクの中心が設計判断である
• コードベースが自律編集に対してリスクが高すぎる
• 実験の実行が遅すぎる、または高コストすぎる
• 必要なのが単純な修正だけである

autoresearch に特別なプロジェクト構成は必要？

特別なフレームワークは不要ですが、次は必要です。

• git リポジトリ
• ターミナルアクセス
• 進捗を測るためにエージェントが実行できるコマンド

つまり、measurement loop が本物である限り、言語を問わず幅広いプロジェクトに適用できます。

CI 主導の最適化と何が違う？

CI は結果の検証には向いていますが、autoresearch は候補となる変更をループの中で生成し、評価するためのものです。CI を安全網、autoresearch を実験オペレーターだと考えるとわかりやすいです。

パフォーマンスチューニング以外でも autoresearch は役立つ？

はい。成果が測定できるなら有効です。信頼性、pass rate、コスト、build speed など、明確な指標を置けるプログラミング作業にも向いています。逆に、「とにかく改善して」のような曖昧な依頼にはあまり向きません。

autoresearch skill を改善する方法

まずは問題設定をよりシャープにする

autoresearch の結果を最も手早く改善する方法は、曖昧な目標を運用可能な条件に置き換えることです。最低でも次を含めてください。

• target metric
• baseline command
• 許容できる回帰
• スコープの境界
• 停止条件

エージェントに自由度を増やすより、設定を正確にするほうが、たいてい結果は良くなります。

skill を疑う前に指標のノイズを減らす

よくある失敗は、ランダムなばらつきを追いかけてしまうことです。結果が揺れるなら、まず benchmark setup を改善してください。

• 複数回実行する
• 中央値を使う
• バックグラウンドプロセスを切り離す
• キャッシュのウォーム状態をそろえる
• 入力データセットを固定する

プロンプトを変えるより、計測を整えるほうが skill の成果に効くことは少なくありません。

早い段階で探索空間を絞る

autoresearch の探索範囲が広すぎるなら、制約を強めてください。ひとつのサブシステム、ひとつのホットスポット、あるいはひとつの変更タイプから始めるよう指示します。広い探索は強力に見えますが、レビュー可能な改善を得やすいのは、たいてい狭い探索です。

絶対に変えてはいけない条件を伝える

結果が悪くなる原因の多くは、ガードレール不足です。次のような譲れない条件を明示してください。

• API compatibility
• テストスイートの pass 要件
• 依存関係の固定
• メモリ上限
• スタイルやセキュリティ上の制約

これにより、局所的には良く見えても全体として悪い変更を、エージェントが却下しやすくなります。

最終コードだけでなく実験ログも求める

この autoresearch guide のワークフローからより多くを得るには、エージェントに次を要約させてください。

• 試した変更ごとの内容
• 計測結果
• keep/discard の判断
• 却下理由

こうしておくと反復の監査性が上がり、失敗パターンも見つけやすくなります。

1回目の結果を見てからプロンプトを調整する

最初の実行結果が期待外れでも、同じ内容でそのまま再実行しないでください。次のどれかを改善します。

• 指標
• 許可するスコープ
• 停止ルール
• benchmark command
• 明示的に検証したい仮説

例:

On the next autoresearch run, focus only on allocation reduction in src/parser, ignore stylistic refactors, and compare median time across 7 runs.

この種の調整は、実際に挙動を大きく変えます。

autoresearch でよくある失敗パターンを知っておく

次のような兆候には注意してください。

• 間違った指標を最適化している
• 弱いテストにより回帰が隠れている
• 1反復あたりのコード変更が大きすぎる
• benchmark command が遅い、または不安定
• 一度の見かけ上の勝ちで早く止めすぎる

こうした問題は、たいてい skill 自体の限界ではなく、セットアップの不備です。

採用候補は merge 前に独立して検証する

autoresearch for Workflow Automation が改善案を見つけたとしても、ループの外で必ず検証してください。

• benchmark を自分でも再実行する
• より広いテストスイートを回す
• 保守性のトレードオフを確認する
• その改善が本番で意味のある差か確かめる

この skill が最も得意なのは、有望な候補を見つけることです。最終的な採用判断は、やはり慎重に行うべきです。