Warp の自己進化型エージェント構築手法を公開

Claude の新ブログ「How Warp builds self-improving agents on Claude」を読み、非常に有益な内容でした。この記事が解決しようとしているのは、スキル（Skill）の進化という課題です。

私も以前、この問題に取り組んだことがあります。JS コードを逆コンパイルするための Skill を作成し、GitHub に公開しました（GitHub）。Agent が反復処理を行う際、新たな状況に対応して解決した事例を基に Skill を自己更新する仕組みです。このアプローチは一定の成果を上げ、継続的な最適化が可能でしたが、Skill ファイルが肥大化する課題が残りました。

また、執筆プロセスにおける自己進化型の Skill についても研究しましたが、これは期待したほど機能しませんでした。明確な評価基準が統一されておらず、結果として負の連鎖（ネガティブフィードバック）を招き、質が低下するケースが多発したためです。

Agent がコードレビューを行う際、必要なのは能力ではなく記憶

さて、Warp について話しましょう。Warp は非常に有名なターミナルエミュレータですが、内部では AI を活用したコードレビューの実験も行っています。

当初はエージェントにコードレビューを任せていましたが、結果は芳しくありませんでした。主な問題は、エージェントがプロジェクトの文脈を理解していない点にあります。チームのコーディング規約や、過去の失敗から得られた教訓も把握できていません。指摘された問題についても、次回には忘れてしまうという記憶機能の欠如が根本的な課題でした。

初期段階では、これらの課題に対処するためにいくつかの対策を講じました。

• 失敗事例に基づき、手動でシステムプロンプトを修正する

プロジェクトの AGENTS.md ファイルを充実させましょう。興味深い点として、この記事は Claude が投稿したものでありながら、ファイル名がデフォルトの CLAUDE.md ではなく AGENTS.md に設定されています。実は、Claude は通常 AGENTS.md をサポートしていないと認識していました。

しかし、その効果は必ずしも期待通りではありませんでした。まず、この手法は人間が能動的に関与する必要があり、コストが高くなるという課題があります。また、チームメンバーがコードレビュー時に PR に付けた高品質なコメントも、十分に活用されていないのが実情です。

スキルを2つ、そして人間のフィードバック

彼らが提案した解決策は、2 つのスキルを活用するものです。1 つ目の基礎的なスキルはコードレビューを担当し、2 つ目の改善用スキルは定期的に、特にエージェントによるレビュー結果に対するエンジニアからのコメントを収集します。その上で、エンジニアのフィードバックをもとにコードレビュー用のスキルを更新していく仕組みです。

つまり、モデルが自分自身で進化するのを待つのではなく、エージェントが人間によるモデル結果のラベル付け（コードレビューへのコメント）を基にスキルを改善するのです。

重要なのは、このプロセスが極めて摩擦が少ない点です。人間が手動でコメントを収集・整理する必要もなければ、アンケートに答える手間もかかりません。エンジニアは自然な形でコード下にコメントを残すだけで、残りの処理はすべてエージェントが自動で行います。

これがまさにエージェントのベストプラクティスの一つと言えるでしょう。人間が高次元のラベル付け、コメント、フィードバックを担当し、エージェントは実行を担う。そして、人間のフィードバックをもとにスキルを改善していくのです。

Warp がまとめた 6 つのベストプラクティス

さらに彼らは、いくつかのベストプラクティスをまとめています。

1. ルールを硬く書くのではなく、原則を示す

スキルを作成する際は、コンピュータにプログラムを教えるのではなく、賢い人間を指導しているつもりで臨みましょう。スキルの中に「重複コードを検索せよ」と記述する方が、変数名に関する詳細なルールを列挙するよりも効果的です。

2. なぜそうするのかを説明する

ルールの背景にある理由を説明することで、エージェントは問題に対して推論を行うようになり、単に硬直した指示を機械的に実行するだけではありません。その結果、類推や応用がしやすくなります。

3. フィードバックの摩擦をゼロに、負担なく

フィードバックは、開発者が普段作業している場所（例えば PR や Issue への直接コメント）で収集し、プロセスを自動化して追加の手間をかけないようにしましょう。摩擦が低いほど、信号は継続的に流れ続けます。もしフィードバックに手間がかかりすぎれば、誰も提供せず、結果として Skill の改善もできなくなります。

4. Skill は簡潔に保ち、段階的に情報を開示する

優れた Skill ファイルは巨大になりません。リソースファイルやスクリプトを参照し、一度にすべてのコンテキストを詰め込むのではなく、必要な情報だけを呼び出します。

5. フィードバックの質が量よりも重要だが、量も役立つ

ベテランエンジニアからの少量でも詳細で分野に特化したフィードバックは、大量の雑なフィードバックよりも価値が高いものです。単純な「賛成」や「反対」だけでは、「なぜそうなのか」という理由が伝わらないからです。

サンプル数が比較的小さくても、フィードバック提供者がその分野の知識を持っており、かつ内容が詳細であれば、非常に質の高い信号を得ることができます。これは、エージェントが他の方法では決して得られない知識です。ただし、高品質な信号のデータセットが多ければ多いほど、効果は向上します。

6. Skill を改善する Skill を作り、それを他の Skill の改善にも活用する

Skill の改善（つまり前述のコードレビュー Skill や Skill 改善用のツール）を確立すれば、その恩恵は現在の Agent ループに限定されません。Skill の改善手法は異なるユースケース間でも高い汎用性を持ちます。ドメイン固有の知識を除けば、これは非常に普遍的で再利用可能なメカニズムです。コードレビュー Agent 向けの改善 Skill は、他の Skill の改善にも応用可能です。

もしフィードバック自体が間違っていたら？

「フィードバック自体が誤りだった場合、どうすればよいのか」と心配する人もいるかもしれません。

Warp のアプローチは、エージェントに盲目的にフィードバックを受け入れさせないことです。基本的な妥当性チェックを行える十分なコンテキストを与え、誰のフィードバックが Skill 更新に影響できるかを制限します（すべての意見が同等に重要ではないため）。そして最終的には、人間がループに参加して変更を審査することを常に保証します。

コードがテストに合格したか、デプロイが成功したかなど、明確な正解が存在する分野では、検証基準を事前に構築し、エージェント自身でその基準に対して実行させます。一方、コードのスタイルやドキュメントの品質など、明確な正解がない分野では、ドメイン専門家の判断に頼り、誰でも自由にフィードバックできる状態にはしません。