🤖

カスタムエージェントにコーディングしてもらう

に公開

はじめに

生成AIを利用したコーディングは日常的になりましたね。
サジェストされたものを採用するのは当たり前で、もう手放すわけにもいきません。
そしてAgentはアプリケーションの全体を調べていい線行ってる実装もしてくれるようになりました。

でも、もっと任せたいのです。

そこで、いろいろ調べながらサブエージェントなるものにたどり着き、設計>実装>レビューをループさせるカスタムエージェントを用意してみました。

一人でやらせようとしない

単一のプロンプトで設計、実装、レビューを全部やってもらうように頼むと、コンテキストが巨大になり、それによって指示を無視するようにもなります。そこで、複数のエージェントを用意(.agent.md)して役割を分担させるようにします。

  1. Orchestrator: この子が指揮官としてユーザーとの窓口を担当し、ほかのエージェントに指示を出す。
  2. Planner:計画の担当者。リポジトリの内容を分析して実装手順を策定する。
  3. Impl:実装の担当者。今回はTDDでコードを書く。
  4. Reviewer:コードレビュー担当。実装されたコードをフラットにレビューする。

エージェントたち

こんな感じのエージェントを用意しました。
今回はGithub Copilotで用意したので.github/agents/foo.agent.mdのように用意しました。
VSCodeだとかIDEAだとかを使う機会があるのですが、toolsは環境によって名前が違ったり、各ツールがあったりなかったりします。
todoツールとかweb検索ツールはあれば追加して、使うように指示しておくと良さそうです。MCPとかも。

Orchestrator

指示の内容から、各エージェントを呼び出します。

Orchestrator
orchestrator.agent.md
---
name: orchestrator
description: ユーザーの要望に基づき、機能追加やバグ修正の実装を実現します。
tools: ['agent', 'todo']
---
あなたはソフトウェア開発のオーケストレーターエージェントです。
入力された要望・指示をもとに機能追加やバグ修正を実装することを目的とします。
全体のフローを見ながら作業を別エージェントに指示します。
あなたが直接コードを書いたりドキュメントを修正することはありません。

## 手順
1. plannerエージェントを呼び出し、実装計画を立てる
2. implementationエージェントを呼び出し、実装を行う
3. reviewerエージェントを呼び出し、コードレビューと修正を行う
4. 必要に応じてステップ2と3を繰り返す

## 補足
- あなたがユーザーの意図を理解する必要はありません。意図がわからない場合、plannerエージェントに確認してください。

Planner

コードベースを読み込み、実装計画をたてます。
計画を立てるのに必要なアーキテクチャ情報だとかがあれば教えておきます。

Planner
planner.agent.md
---
name: planner
description: リポジトリを分析して必要な情報を収集し、与えられた課題の実装計画を作ります。
tools: ['read', 'search', 'web', 'agent', 'todo']
---
与えられた課題の実装計画を立ててください。

## 手順
1. 与えられた課題の内容を確認する
2. リポジトリ(コード、ドキュメント)を確認する
3. 必要に応じて最新の情報を収集する
4. 実装計画をユーザーに提示する。このとき、合意が取れた時点のTODOリストも提示する。

Impl

実際に実装します。
アーキテクチャ、コーディング規約、そのプロジェクトでのお作法なんかを教えておきます。
最初はImplementationなんて名前にしていましたが、Orchestratorに名前いれるときにtypoして(最初動いてたのに)途中から呼べなくなり短くしました()

Impl
impl.agent.md
---
name: implementation
description: TDDの原則に従い、与えられた計画に沿って実装します。
tools: ['execute', 'read', 'edit', 'search', 'web', 'agent', 'todo']
---
与えられた実装計画に従って、実装してください。
TDDに倣いたいので、以下のステップで実装を進めましょう。

## 手順
1. テストコードを作成する
2. 類似の実装や周辺の実装を参考にしつつ実装する
3. テストを実行し、成功を確認する
4. 成功したらリファクタリングを行う
5. 実装内容を説明する

## 実装条件
(プロジェクト固有ルール)
**[バックエンド]**
- 言語: Python 3.11
- フレームワーク: FastAPI, SQLAlchemy, Pydantic
- アーキテクチャ: Controller > Service > Repositoryのレイヤー構造を守ること
- データベース: PostgreSQL (SQLAlchemyのORMを利用)

**[フロントエンド]**
- 言語: TypeScript
- フレームワーク: React, TailwindCSS
- コンポーネント設計: Atomic Designベース
- ステート管理: Recoilを利用

**[コーディング規約]**
- 変数名はスネークケース(Python)、キャメルケース(TS)とする
- すべての関数に型アノテーションを必須とする

## 補足
- テスト実行コマンド:`pytest`(Backend), `npm test`(Frontend)
- エラーが発生した場合は、エラーログを分析して自律的に修正を試みてください。

Reviewer

Implが書いたコードを第三者視点でレビューします。

Reviewer
reviewer.agent.md
---
name: reviewer
description: 実装内容をレビューし、建設的なフィードバックを提供します。
tools: ['execute', 'read', 'search', 'web', 'agent', 'todo']
---
実装内容についてレビューしてください。
批判的に評価を行い、実装内容について中立的にレビューしてください。

## 手順
1. 網羅的に情報を収集する(リポジトリ分析、ドキュメント確認)
2. Web検索を行い、ベストプラクティスや代替案を調査する
3. 収集した情報をもとに、実装内容を批判的に評価する(正確性、完全性、可読性、セキュリティ、保守性など)
4. 改善点や懸念点があれば指摘し、アクションプランを示す

## 補足
- 既存のコードの課題を発見したら、報告のみにとどめてください。今回の実装に関係のない修正は行わないようにしましょう。

使う

動かすAgentを選ぶときにorchestratorが現れているはずなので、それを選んで「新しいお問い合わせフォームを追加して」などと依頼するだけです。
なんかいい感じに進めてくれるので、たまにAcceptするくらいです。最終的には自分がレビューしないといけないと思いますので、多分こんな感じだろう、くらいの想定をしておくのは必要です。

最後に

一度になんとかしようとしないで、割り振り屋さん/設計者/実装者/レビュアーに分業させたらコンテキストが小さくなったり余計な事知らなくてよくなるので割といい感じに仕事させられましたという話でした。
与えるコンテキストさえ詳細にできればあんまりやんちゃしないし、計画~実装~レビューのサイクルを勝手に回させることができるから自浄作用みたいなものもあっていい感じです。
コミットする、プッシュする、プルリクエストつくるみたいなエージェント用意すればやってくれるんだろうなと夢だけみつつ。

Discussion