Warp、Claude を活用した自己改善型エージェントの構築手法を公開

本シリーズでは、スタートアップがAIを活用して業界を変革する事例を紹介しています。この記事では、Warp がステートレスなユーザーフィードバックをエージェントの自己改善ループに変換した手法について解説します。

エージェントは、反復的なタスクを確実に、かつ効果的に処理する必要があります。タスクの 80% を正しくこなす最初の試行プロンプトでは、ユーザーにとってノイズが多く、ストレスの多い体験になってしまいます。

Warp は AI パワー型のターミナルおよびエージェント開発環境として Claude Platform を基盤に構築されていますが、チームは社内コードレビューエージェントでこの「ノイズの多い体験」という問題に直面しました。エンジニアからは、「エージェントが役に立たないコメントを付けたり、質の低い出力を生成したりする」といった不満が出たのです。

当初、チームは目撃されたコードレビューの失敗に基づいてプロンプトを手動で書き直すといった応急処置を試みました。これにより出力の実用性は向上しましたが、スケーラビリティの問題は残りました。AGENTS.md などのコンテキストファイルの改善も役立ちましたが、根本的な解決策とは程遠いものでした。

最終的にチームが気づいたのは、エージェントへのフィードバックは目的が何であれ、セッション終了と同時に消えてしまい、その結果、重要な文脈がエージェントのループから失われてしまうという点です。そこで彼らが提案したのが、Agent Skills を活用したフレームワークです。これによりフィードバックが時間とともに蓄積され、継続的に出力を洗練・強化する「自己改善型エージェント」を実現しました。

以下では、Claude Platform 上で Skills を活用してどのようにこれを構築したのかをご紹介します。

スキルに基づくエージェントの自己改善ループ

中核となる技術は、**スキル**を活用した自己改善ループです。スキルとはファイルベースで知識を記述する形式であり、生きたプロンプト内に指示を直接埋め込むのを防ぎます。Warp はこの仕組みを発展させ、人間によるフィードバックを挟むことで構成される 2 つのスキルからなる自己改善型エージェントアーキテクチャを実現しました。

内部（ベース）スキルには、機能的なドメイン知識と具体的な指示が格納されています。例えば、プルリクエストが開かれた際、Warp のコードエージェントはこのベーススキルと文脈を用いてレビューを生成します。

エージェントの出力に対する人間のフィードバックは、この自己改善ループにおいて極めて重要な要素です。コードレビューにおいては「いいね」のようなシンプルな評価でも構いませんが、より具体的で詳細なフィードバックほど効果的です。

Warp の創業者である Zach Lloyd はこう説明します。「人間は『これは有益で良いコメントだ』と肯定することもできますし、逆に『なぜこのレビューが適切ではなかったのか』という具体的な理由を伝えることも可能です。例えば、『変数名のリネームを提案しましたが、当社のコードベースの規約では、この種の変数は特定の命名規則に従うべきです』といった詳細な指摘は、エージェントに次回どのように正しく対応すべきかを教えることになります。」

「外側・改善（outer/improver）スキル」は、タスクごとに実行されるのではなく、スケジュールに基づいて動作する観測エージェントとして機能します。このスキルは蓄積された人間のフィードバックを取得し、エージェントが提案した内容と人間からの反応を比較した上で、ベースとなるスキルに対する小さく焦点を絞った編集案を提示します。

スキルは単なるファイル形式であるため、エージェントによる更新作業は非常にスムーズに行えます。これらの更新内容はレビュー可能で承認もでき、プルリクエスト（PR）やコードレビューの標準的なワークフローを通じて流すことができます。マージが完了すれば、次の「内側スキル」の実行時にその改善点が自動的に引き継がれます。

現在、Warp ではこのパターンをオープンソースのリポジトリ全体に展開しており、仕様記述、レビュー、トリアージを担当するエージェントそれぞれが独自の自己改善ループを持っています。

Zach 氏はこう説明しています。「ファイルベースのスキルとは、知識をプロンプトに直接埋め込むのではなく、エージェントが作業中に参照できる形でエンコードする方法です。このフレームワークは実は非常にシンプルで、ドメイン固有のベーススキルと、それを洗練させる改善スキルの 2 つから成り立っています。このアプローチの美しさは、まさにそのシンプルさにあります。」

エージェント向けに自己改善型スキルを書く方法

Warp チームが試行錯誤を経て確立した、エージェントループ用の自己改善型スキル作成におけるいくつかのコツをご紹介します：

「ルールではなく原則を記述する」ことが重要です。Zach 氏は、「賢い人間に指示を出すようにスキルを構築し、コンピュータをプログラミングするように書くべきではない」と語ります。「繰り返しコードを探す」のような具体的な方向性をスキルに含めることは、変数名に関する網羅的な規則を設けるよりもはるかに効果的な指針となります。

「なぜそうするのかを説明する」ことも不可欠です。規則の背後にある理由を提供することで、エージェントが硬直した指示に従うのではなく、問題自体について推論できるようになります。これにより、より汎用的な対応が可能になります。

「フィードバックを与えやすくする」工夫も必要です。人々がすでに作業を行っている場所、例えば PR やイシューへの直接コメントなどでフィードバックを収集しましょう。また、追加の提出ステップなしで自動的に実行される仕組みにします。「摩擦の少なさこそがシグナルの流れを保つ鍵です」と Zach 氏は指摘しています。「ハードルが高すぎると、フィードバックを得られず、スキルの改善もできなくなります」。

「スキルは小さく保ち、段階的に情報を開示する」ことが望ましいです。優れたスキルファイルは巨大なものではなく、リソースファイルやスクリプトを参照するものであり、すべての情報を一度にコンテキストに読み込むようなものではありません。良いスキルの例はこちら。

フィードバックの質は量よりも重要ですが、量も役立ちます。シニアエンジニアからの少量でも詳細かつドメイン固有のフィードバックは、単なる「いいね」「ダメ」の二値評価よりも価値があります。なぜなら、後者では「なぜそうなのか」という理由が伝わらないからです。「エージェントが通常得られないようなドメイン固有の知識を持つ人物からの、非常に詳細なフィードバックであれば、サンプルサイズが比較的小さくても、極めて良いシグナルを得ることができます」と Zach は続けます。「ただし、高品質なシグナルのコーパスが大きければ大きいほど、それはより良くなります。Warp では、オープンソースリポジトリ全体の管理にループを活用しています。数百人の貢献者がおり、数千件のコードレビューを行っています。」

改善スキル（improver skill）への追加投資が報われる。改善スキル（観測エージェント）の作成により一層の努力を払うことは、即座のエージェントループを超えた価値をもたらします。なぜなら、改善スキルは異なるユースケース間で非常に再利用可能だからです。「ドメイン固有の知識コンポーネントを除けば、これは比較的再利用可能なメカニズムです。コードレビューエージェント向けの改善スキルと、他のあらゆるエージェント向けの改善スキルの間に大きな違いはありません。」

ループの実践：Warp の課題選別エージェント

Warp の課題選別エージェントは、自己改善型エージェントのスキル・フレームワークを示すデモです。このパターンは、誰かが GitHub に新しい課題（issue）を登録するたびに発動します。GitHub Action がトリガーとなり、エージェントが課題の複雑さや実現可能性を分析してラベルを付与し、修正に向けた方向性を提案します。

この選別プロセスでは、「ドメイン知識」を保持した内部スキルファイルが稼働します。そこには各ラベルの意味や、アクションを起こす前にコードベースをどのように調査すべきかが記されています。

サンプル課題に対して、第一段階の内部スキルは概ね良好な結果を出しましたが、「仕様の策定（ready to spec）」というラベルを見落としていました。これは、コントリビューターが課題に基づいてプロダクトや技術仕様書の作成を開始できることを示す重要なシグナルです。

Warp チームのメンテナーがこの抜け漏れに気づき、作業が行われているその場で直接フィードバックを残しました。重要なのは、彼が「何を期待しているか」だけでなく、「なぜそれを期待するのか」という理由まで明確に説明した点です。これにより、エージェントは後で吸収しやすい具体的なフィードバックを得ることができました。

外部の改善用スキル（outer improver skill）は、Warp のエージェント管理プラットフォームである Oz 上で、スケジュールされた「選別更新」エージェントとして稼働しています。このエージェントは GitHub に認証し、スキルにバンドルされた Python スクリプトを実行してフィードバック付きの最近の課題を抽出、それらを JSON ファイルに要約しました。そして、その結果をコンテキストとして読み込みます。

スクリプト自体がパッケージされていることはベストプラクティスの一つです。スキルは毎回新しいコードを書くのではなく、リソースファイルを参照することで効率的に動作できます。

そこから、エージェントはメンテナのコメントに含まれる具体的なフィードバック信号を特定し、それらを反映する最小限の変更案を提案しました。具体的には、実際の課題が記述された際に「仕様に準拠済み」ラベルを付与するよう、内部スキルの一部を編集するプルリクエスト（PR）を作成したのです。なお、UI や UX の具体的な形状はまだ定義されていない場合でも、この処理は適用されます。

更新対象となるのはスキルファイルのみであるため、通常のコードレビューワークフローをそのまま通過します。PR には、どの信号が変更のきっかけとなり、何が修正されたのかを説明する記述が付随しています。人間によるレビューと承認を経てマージされ、次のトライアージスキルの実行では、その新しい知識が引き継がれます。この最終的な人間のステップがループを完結させ、実際の変更内容を人が管理し続ける仕組みとなっています。

現在、Warp ではこのメカニズムをオープンソースリポジトリ全体でスケールして運用しています。仕様作成エージェント、レビューエージェント、トライアージエージェントそれぞれが、独自の自己改善ループを回しているのです。

どんなタスクを担当するエージェントであっても、最初からこうしたループを組み込んでおけば、時間の経過とともに能力は向上します。人間のフィードバック信号を捉え、それをスキル更新に変換し、単発のヘルパーから組織全体で相乗効果を発揮できる有能なシステムへと進化させることが可能になるからです。

詳細なライブデモや、Warp がチームからのフィードバックを元に学習し、時間とともに自己改善するエージェントを構築するために Claude をどのように活用しているかについての深い議論については、ウェビナーの全文を見る してください。

今日から Claude Platform を使って構築を始めてください。