Copilot Applied Scienceにおけるエージェント駆動開発

私は自分の仕事の一部を自動化するエージェントを構築するためにコーディングエージェントを使用しました。これにより、私はおそらく完全に異なる仕事に自分自身を自動化してしまいました…これはソフトウェアエンジニアの間でよくあるパターンです。インスピレーション、フラストレーション、時には怠惰から、退屈な作業を排除し、より創造的な仕事に集中するためのシステムを構築します。そして、最終的にそれらのシステムを所有・保守し、自動化の恩恵を周囲の人々に開放します。

AI研究者として、私は最近このアイデアをこれまで不可能だったレベルにまで押し上げ、知的労働を自動化しました。そして今、Copilot Applied Scienceチームの同僚全員が同じことをできるように、このツールを維持しています。このプロセスを通じて、GitHub Copilotを効果的に作成しコラボレーションする方法について多くを学びました。これらの学びを適用することで、自分自身の開発サイクルが驚くほど高速化されただけでなく、チームメイトが自分のニーズに合ったソリューションを構築できるようになりました。

これをどのように実現したかを説明する前に、このプロジェクトを生み出した背景を説明し、GitHub Copilotで何ができるかの範囲を理解してもらいます。

きっかけ

私の仕事の大部分は、TerminalBench2やSWEBench-Proなどの標準化された評価ベンチマークに対するコーディングエージェントのパフォーマンスを分析することです。これには、いわゆる「軌跡」（エージェントがタスクを実行する際の思考プロセスとアクションのリスト）を大量に精査する必要があります。評価データセット内の各タスクは、エージェントがそのタスクを解決しようとした方法を示す独自の軌跡を生成します。これらの軌跡は、多くの場合、数百行のコードを含むJSONファイルです。ベンチマークセット内の数十のタスクにそれを掛け合わせ、さらに毎日分析が必要な多数のベンチマーク実行に掛けると、分析すべきコードは数十万行に達します。

これは一人で行うには不可能なタスクですが、通常はAIの助けを借りていました。新しいベンチマーク実行を分析する際、同じループを繰り返していることに気づきました：GitHub Copilotを使って軌跡のパターンを表面化させ、それから自分で調査する—これにより、読む必要のあるコード行を数十万から数百に減らしました。

しかし、エンジニアとしての私はこの反復的なタスクを見て、「自動化したい」と思いました。エージェントはこの種の知的作業を自動化する手段を提供してくれます。こうしてeval-agentsが誕生しました。

計画

エンジニアリングチームとサイエンスチームは、協力することでより良い成果を上げます。これが私がこの新しい課題に取り組む際の指針でした。

そこで、このプロジェクトの設計と実装戦略には、いくつかの目標を念頭に置きました：

• これらのエージェントを共有・使用しやすくする
• 新しいエージェントの作成を容易にする
• コーディングエージェントをコントリビューションの主要な手段にする

最初の2つの目標はGitHubの生命線であり、私のキャリア全体（特にGitHub CLIのOSSメンテナーとしての期間）を通じて得た価値観とスキルです。

しかし、プロジェクトを最も形作ったのは3つ目の目標でした。GitHub Copilotを効果的にツール構築に活用できるように設定すると、プロジェクトの使用とコラボレーションも容易になることに気づきました。この経験からいくつかの重要な教訓を得て、最終的に第一と第二の目標を予想外の方法で前進させることになりました。

コーディングエージェントを主要なコントリビューターにする

まず、私のエージェンティックコーディング設定を説明します：

• コーディングエージェント：Copilot CLI
• 使用モデル：Claude Opus 4.6
• IDE：VSCode

また、Copilot SDKを活用してエージェント作成を加速したことも注目に値します。このSDKは内部でCopilot CLIによって駆動されています。これにより、既存のツールやMCPサーバーへのアクセス、新しいツールやスキルを登録する方法、そしてその他のエージェンティックな機能をすぐに利用でき、一から再発明する必要がありませんでした。

これにより、いくつかの基本原則に従うことで、開発プロセス全体を非常に迅速に合理化できました：

プロンプト戦略：エージェントは、会話的で冗長なプロンプトを使用し、エージェントモードに入る前に計画モードを活用すると最も効果的に機能します。

アーキテクチャ戦略：頻繁にリファクタリングし、頻繁にドキュメントを更新し、頻繁にクリーンアップする。

反復戦略：「信頼するが確認する」は「プロセスを責め、エージェントを責めない」に変わりました。

これらの戦略を発見し遵守することで、驚くべき現象が起こりました：新しいエージェントや機能の追加が迅速かつ簡単になったのです。初めてプロジェクトに参加した5人のメンバーが、3日未満で合計11の新しいエージェント、4つの新しいスキル、そしてeval-agentワークフロー（科学者の推論ストリームのようなもの）の概念を作成しました。これは345ファイルにわたる+28,858/-2,884行のコード変更に相当します。

すごい！

以下では、これらの3つの原則と、それらがどのようにこの驚くべきコラボレーションとイノベーションを可能にしたかを詳しく説明します。

プロンプト戦略

AIコーディングエージェントは、範囲の明確な問題を解決するのが非常に得意ですが、シニアエンジニアにしか任せられないような複雑な問題には手取り足取りの指導が必要です。

したがって、エージェントにエンジニアのように行動してもらいたいなら、エンジニアとして扱いましょう。思考を導き、前提を過剰に説明し、その調査速度を活用して変更に飛び込む前に計画を立てます。問題に対する意識の流れの考えをプロンプトに入れ、Copilotと計画モードで協力することは、簡潔な問題文や解決策を与えるよりもはるかに効果的であることがわかりました。

以下は、ツールにさらに堅牢な回帰テストを追加するために書いたプロンプトの例です：

> /plan 最近、Copilotが新しいパラダイムに合わせてテストを喜んで更新しているのを観察しましたが、それらのテストは更新されるべきではありません。Copilotが触れられない、または回帰から保護するために予約しなければならない予約テストスペースを作成するにはどうすればよいでしょうか？

これにより、最終的に人間のみが更新できる契約テストのような一連のガードレールが生まれる対話が行われました。私は何が欲しいかのアイデアを持っていましたが、会話を通じてCopilotが正しい解決策に導いてくれました。

人間のエンジニアを最も効果的にするものは、これらのエージェントを効果的にするものと同じであることがわかりました。

アーキテクチャ戦略

エンジニアの皆さん、歓喜してください！コードベースをより読みやすくするためにやりたかったリファクタリング、書く時間がなかったテスト、オンボーディング時に存在してほしかったドキュメントを覚えていますか？それらは今や、エージェントファーストのリポジトリを構築する際に最も重要な作業です。

この作業を新機能開発よりも優先順位を下げなければならなかった時代は終わりました。Copilotで機能を提供することは、よくメンテナンスされたエージェントファーストのプロジェクトがあれば簡単になるからです。

私はこのプロジェクトのほとんどの時間を、名前やファイル構造のリファクタリング、新しい機能やパターンの文書化、そして進めながら見つけた問題のテストケースの追加に費やしてきました。さらに、エージェント（あなたのジュニアエンジニアのように）がこれらすべての新機能と変更を実装する際に見逃したかもしれないデッドコードのクリーンアップにも数サイクル費やしました。

この作業により、Copilotはコードベースを簡単にナビゲートし、パターンを理解できるようになります。他のエンジニアと同様です。

私は「今の知識があれば、これをどのように異なる設計にするだろうか？」と尋ねることさえできます。そして、実際に戻ってプロジェクト全体を再アーキテクチャすることを正当化できます（もちろんCopilotの助けを借りて）。

夢が叶いました！

そして、これが最後のガイダンスにつながります。

反復戦略

エージェントとモデルが改善されるにつれ、私は「信頼するが確認する」という考え方から、より信頼し疑わない考え方に移行しました。これは業界が人間のチームを扱う方法を反映しています：「人ではなくプロセスを責める」。これが最も効果的なチームの運営方法です。なぜなら、人は間違いを犯すので、その現実を中心にシステムを構築するからです。

この非難のない文化の考え方は、チームに反復と革新のための心理的安全性を提供し、間違いを犯しても非難されないことを知っています。核となる原則は、間違いを防ぐためのプロセスとガードレールを実装し、間違いが起こった場合、そこから学び、チームが同じ間違いを繰り返さないように新しいプロセスとガードレールを導入することです。

同じ哲学をエージェント駆動開発に適用することは、この非常に迅速な反復パイプラインを解放するために基本的でした。つまり、エージェントが間違いを犯すのを防ぐためにプロセスとガードレールを追加しますが、間違いを犯した場合、追加のガードレールとプロセス（より堅牢なテストやより良いプロンプトなど）を追加して、エージェントが同じ間違いを二度と犯せないようにします。さらに一歩進めると、優れたCI/CDプラクティスを実践することが必須です。

厳格な型付けのようなプラクティスは、エージェントがインターフェースに準拠することを保証します。堅牢なリンターは、エージェントに実装ルールを課し、良いパターンとプラクティスに従わせます。そして、手動で構築するにはコストがかかる可能性のある統合テスト、エンドツーエンドテスト、契約テストは、エージェントの支援によりはるかに安価になり、新しい変更が既存機能を壊さないという自信を与えます。

Copilotが開発ループ内でこれらのツールを利用できる場合、自分の作業をチェックできます。あなたはCopilotを成功に導いているのです。プロジェクトでジュニアエンジニアを成功に導くのと同じ方法です。

すべてをまとめる

コードベースがエージェント駆動開発用に設定されている場合、開発ループは次のようになります：

1. /planを使用してCopilotと新機能を計画する。
2. 計画を反復する。
3. 計画にテストが含まれていることを確認する。
4. コードが実装される前に、ドキュメントの更新が計画に含まれていることを確認する。これらは計画と並ぶ追加のガイドラインとして機能します。
5. Copilotに/autopilotで機能を実装させる。
6. Copilotコードレビューエージェントでレビューループを開始するよう促す。私の場合、よくあるのは：Copilotコードレビューをリクエストし、レビューが終了するのを待ち、関連するコメントに対処し、再レビューをリクエストする。関連するコメントがなくなるまでこのループを続ける。
7. 人間によるレビュー。ここで前のセクションで説明したパターンを適用します。

さらに、機能ループの外では、以下のプロンプトを頻繁に実行していることを確認してください：

• /plan コードをレビューして、欠落しているテスト、壊れているかもしれないテスト、デッドコードを探す
• /plan コードをレビューして、重複や抽象化の機会を探す
• /plan ドキュメントとコードをレビューして、ドキュメントのギャップを特定する。関連する変更を反映するためにcopilot-instructions.mdを更新することを忘れずに

これらは週に一度自動的に実行していますが、新しい機能や修正が入るたびに週を通して実行し、エージェント駆動開発環境を維持しています。

持っていくもの

不可能と思われる反復的な分析タスクへのフラストレーションから始まったものが、はるかに興味深いものに変わりました：ソフトウェアの構築方法、コラボレーション方法、エンジニアとしての成長方法についての新しい考え方です。

コーディングエージェントファーストの考え方でエージェントを構築することは、私の働き方を根本的に変えました。それは単なる自動化の勝利ではありません——4人の科学者が3日未満で11のエージェント、4つのスキル、そしてまったく新しいコンセプトを出荷するのを見るのは驚くべきことですが——さらに重要なのは、この開発スタイルがあなたに優先順位を強制することです：クリーンなアーキテクチャ、徹底的なドキュメント、意味のあるテスト、思慮深い設計——これらは常に重要だとわかっていながら時間がなかったものです。

ジュニアエンジニアとの類推は、繰り返し証明されています。しっかりとオンボーディングし、明確なコンテキストを与え、ミスが大惨事にならないようにガードレールを構築し、そして成長を信頼します。何かがうまくいかなければ、プロセスを責めます。エージェントではありません。これから持ち帰ってほしいことが一つあるとすれば、優れたエンジニアであり優れたチームメイトであるためのスキルは、Copilotで構築するのに優れているためのスキルと同じだということです。テクノロジーは新しい。原則はそうではありません。

だから、コードベースを掃除し、先延ばしにしていたドキュメントを書き、Copilotをチームの最新メンバーとして扱い始めましょう。あなたはキャリアの中で最も興味深い仕事に自分自身を自動化するかもしれません。

私がクレイジーだと思いますか？では、これを試してみてください：

• Copilot CLIをダウンロード
• 任意のリポジトリでCopilot CLIをアクティブ化：cd && copilot
• 次のプロンプトを貼り付け：/plan リポジトリを読み、エージェントファースト開発のためにこのリポジトリを最適に改善する方法を計画するのを手伝ってください。