フィードバックでエージェントを改善するWarpの設計：2つのスキルで継続的な改善を管理する
WarpがClaude上で構築した継続的に改善するエージェントを、実行用スキル、改善用スキル、人間からのフィードバック、評価と実装の観点から解説します。
Xでシェア目次
- 課題：エージェントへのフィードバックが次のセッションに残らない
- 2つのスキルで構成する
- Warpのissueを分類するエージェントでの実例
- スキルを書くときのポイント
- 個別の規則ではなく原則を書く
- 理由を含める
- フィードバックを残す負担を減らす
- スキルを小さく保つ
- 量より質。ただし質の高い量は役立つ
- 改善担当の処理へ投資する
- スキルとメモリは別物
- どこまで効果が検証されているか
- 実際に実装するには
- 1. 実行用スキルと評価対象を固定する
- 2. フィードバックの記録形式を決める
- 3. 改善担当エージェントを定期実行する
- 4. 評価基盤を先に作る
- 5. Pull Requestを安全装置にする
- 6. 段階的に導入する
- 制約と改善課題
- まとめ
- 参照
AI利用の明示
本記事の構成と本文は、OpenAIのコーディングエージェント「Codex」が作成しました。主張と数値は参照元を確認していますが、利用時は原文も確認してください。
今回取り上げるのは、Claude公式ブログで2026年8月26日に公開された「How Warp builds self-improving agents on Claude」です。AnthropicのMichael Segner氏が、Warpによる継続的に改善するエージェントの設計と運用例を紹介しています。
この記事の要点は、タスクを処理する実行用スキルと、人間のフィードバックをもとに実行用スキルの小さな修正を提案する改善用スキルを分け、通常のPull Requestのワークフローで改善を管理するというものです。
課題：エージェントへのフィードバックが次のセッションに残らない
Warpでは、社内のコードレビューエージェントが役に立たないコメントや低品質な出力を返し、エンジニアから不満が出ていました。失敗例を見ながら人がプロンプトを書き直したり、AGENTS.mdのような文脈を与えるファイルを改善したりすると一時的には良くなります。しかし、タスクごとのフィードバックはセッション終了時に消え、修正作業も人手のままなので規模を拡大できません。
初回のプロンプトでタスクの80%を正しく処理できたとしても、残り20%の不要な指摘が繰り返し現れれば、ユーザーにとってはノイズになります。必要なのは「強いプロンプトを一度書くこと」だけでなく、本番環境で得たフィードバックを次の実行へ安全に反映するループです。
2つのスキルで構成する
Warpの構成には、役割の異なる2つのスキルがあります。
| 構成要素 | 実行タイミング | 役割 |
|---|---|---|
| inner / 実行用スキル | タスクごと | 専門知識と実行手順をエージェントへ与える |
| 人間からのフィードバック | タスク後 | 出力の良否と、その理由を普段の作業場所で記録する |
| outer / 改善用スキル | スケジュール実行 | フィードバックを集約し、実行用スキルへの小さな変更を提案する |
| 人間によるレビュー | スキル更新時 | 提案された差分を確認し、マージするか判断する |
処理の流れは次のようになります。
base skillを使ってtaskを実行
→ userやmaintainerが具体的なfeedbackを残す
→ improver agentがfeedbackを定期収集
→ 現在のbase skillと比較し、最小のpatchを作る
→ Pull Requestを作成
→ 人間がreview・approve・merge
→ 次のtaskから更新済みbase skillを利用改善担当エージェントが実行用スキルを直接書き換え、即時反映するわけではありません。この区別が重要です。スキルは通常のファイルなので、差分を確認でき、バージョン管理、レビュー、切り戻しという既存のソフトウェア開発のワークフローに組み込めます。
Warpのissueを分類するエージェントでの実例
紹介されているissueを分類するエージェントは、新しいGitHub issueをtriggerに起動します。コードベースを調べ、complexityとfeasibilityを分析し、ラベルと修正方針を提案します。実行用スキルには、各ラベルの意味や調査手順が書かれています。
あるissueでエージェントは主要な判断には成功しましたが、仕様作成へ進めることを示すready to specラベルを付け忘れました。メンテナーはissue上で、付けるべきラベルだけでなく、なぜ必要なのかもフィードバックとして残しました。
その後、Warpのエージェントの実行を管理する基盤であるOz上の定期実行のエージェントが動きます。スキルにbundleされたPythonスクリプトでフィードバック付きissueを取得してJSONへまとめ、改善担当エージェントが読み込みます。エージェントはフィードバックから具体的なシグナルを取り出し、ready to specを適用する条件を実行用スキルへ加える小さな変更を提案してPull Requestを作成します。最終的に人間がレビューしてマージし、次回から新しい知識が使われます。
公開されている「Ambient Agents Demo - GitHub Actions」では、GitHub ActionからWarpのエージェントを起動する構成を確認できます。ただし、このリポジトリは2026年6月2日にアーカイブされており読み取り専用です。Claude公式ブログの完全な自己改善のループ一式が、そのまま実行可能な形で公開されているわけではありません。
スキルを書くときのポイント
Warpの推奨事項は、次のように整理できます。
個別の規則ではなく原則を書く
変数名の全パターンを列挙するような規則より、「重複したコードを探す」のような原則を与えます。エージェントが未知の事例へ汎化しやすくなるためです。
理由を含める
指示だけでなく理由を書くと、エージェントは表面的なパターン照合ではなく、目的に沿って判断できます。フィードバックにも「間違い」だけでなく「なぜ間違いか」を含めます。
フィードバックを残す負担を減らす
専用フォームへ転記させず、Pull Request commentやissue commentなど、普段の作業場所でフィードバックを収集します。収集が面倒だと改善のシグナルが途切れます。
スキルを小さく保つ
すべてをSKILL.mdへ詰め込まず、必要な参照資料やスクリプトを別ファイルにしてprogressive disclosureを使います。Claude PlatformのAgent Skills overviewでも、必要なファイルだけをon-demandで読み込む構成が説明されています。
量より質。ただし質の高い量は役立つ
単純なthumbs-up／downを大量に集めるより、分野の専門家による具体的なフィードバックの方が改善に使えます。一方で、質の揃ったシグナルなら事例集が増えるほど繰り返しパターンを見つけやすくなります。
改善担当の処理へ投資する
専門知識を持つ実行用スキルはタスクごとに変わりますが、フィードバック収集、差分抽出、最小修正作成、評価、PR作成という改善担当エージェント側の処理は再利用しやすい部分です。
スキルとメモリは別物
Claude公式ブログは、スキルとメモリの違いも明確にしています。
スキルはタスクの進め方を表す手続き的な知識で、比較的安定しています。意図的なレビューを経て更新します。メモリは推論時にエージェントが書き込み、セッションやユーザーに関する状態として継続的に変化します。
すべてのフィードバックをメモリへ自動保存すると、誤った指示や一時的な例外が蓄積する恐れがあります。組織の標準手順として繰り返し使う知識は、レビュー可能なスキルとして管理する方が向いています。
どこまで効果が検証されているか
元記事には、Warpで月間80万人の開発者が開発している、Fortune 500企業の56%が利用している、Warp内のClaude Code sessionが累計1,000万回・週40万回以上、Warp Agentの会話が累計4,000万件、といった利用規模が掲載されています。
ただし、これらはWarpやClaudeの利用規模であり、2-skill loopによる品質改善を直接測った値ではありません。記事では、導入前後の正解率、不要コメント率、スキル変更の採用率、対照群との比較などは公開されていません。
したがって、この参照元から言えるのは「Warpが複数のエージェントでこのパターンを本番で運用している」「issue triageの改善例がある」という事例研究までです。自己改善の改善率や、別組織でも同じ効果が出ることが定量的に実証された、とまでは言えません。
実際に実装するには
以下は、元記事の設計を一般的なコードレビューエージェントへ適用する実装案です。Warpの内部プラットフォームや改善担当エージェント promptは公開されていないため、完全再現ではありません。
1. 実行用スキルと評価対象を固定する
まず、1つの狭いタスクから始めます。たとえば「Pull Requestにセキュリティ上の問題がないかレビューする」のように対象を限定します。実行用スキル、モデルのバージョン、ツール、リポジトリのリビジョンを実行ログへ保存し、どの条件で生成された出力か追跡できるようにします。
2. フィードバックの記録形式を決める
thumbs-up／downだけでなく、期待する動作と理由を保存します。
type AgentFeedback = {
taskId: string;
skillRevision: string;
outputId: string;
verdict: 'useful' | 'not-useful' | 'partially-useful';
expectedBehavior: string;
rationale: string;
authorRole: 'maintainer' | 'domain-expert' | 'contributor';
sourceUrl: string;
createdAt: string;
};フィードバック本文は信頼できない入力として扱います。issueやPRに書かれた命令をそのままスキルへコピーせず、誰のフィードバックを採用対象にするか、どのリポジトリやラベルを収集するかを許可リストで制限します。
3. 改善担当エージェントを定期実行する
毎回のタスク終了時ではなく、日次または週次でまとめて処理します。単発の例外を一般的な規則にしにくく、関連するフィードバックを比較できるためです。
承認されたfeedbackを取得
→ 重複・矛盾・一時的な例外を分類
→ 現在のbase skillで既に扱えるか確認
→ 繰り返し発生し、generalizeできるsignalを選ぶ
→ 1つの目的に絞った最小patchを生成
→ evalを実行
→ evidenceと結果を添えてdraft PRを作成改善内容を一度に詰め込まず、1つのPRを1つの動作の変更へ絞ると、失敗時の原因特定と変更の取り消しが容易になります。
4. 評価基盤を先に作る
改善担当エージェントが「改善した」と自己評価するだけでは不十分です。過去の成功例、失敗例、境界例からgolden 事例集を作り、現行スキルと変更後スキルを同じモデル・設定で比較します。
コードレビューなら、次の指標が候補になります。
コードレビューなら、実際に採用されたコメントの割合、偽陽性となった指摘の割合、重大な問題の再現率が評価指標の候補になります。メンテナーによる有用性の評価も使えます。トークン／APIコストと遅延に加え、マージまでの時間などシステム全体の指標も候補です。
改善対象の指標だけでなく、既に成功していた事例で性能が低下していないか回帰テストも行います。ドメインが機械的に検証しにくい場合は、golden outputを使える部分をdeterministic 評価にし、主観評価は少数の分野の専門家へ限定します。
5. Pull Requestを安全装置にする
改善担当エージェントが作るPRには、少なくとも次を含めます。
PRには、根拠となったフィードバックへのリンクと、問題が繰り返しのパターンなのか単発なのかを記載します。スキルの変更前後の差分、評価結果、既存の性能が低下していないかも示します。想定する影響範囲と切り戻し方法も必要です。
CODEOWNERSなどで担当分野の責任者の承認を必須にし、エージェント自身にはマージ権限を与えない構成が安全です。フィードバックが誤っている前提でsanity checkし、機密情報、個人情報、プロンプトインジェクションをスキルへ取り込まないレビューも必要です。
6. 段階的に導入する
最初は改善担当エージェントにレポートだけ作らせ、次にdraft PRまで許可し、評価と人間の承認が安定してから対象エージェントを増やします。次の運用指標を継続して確認します。
運用では、フィードバックが付いたタスクの割合と、分野の専門家によるフィードバック数を継続して確認します。改善担当エージェントが提案したPRの採用率、スキル更新後の性能低下の割合も確認対象です。タスクの品質、マージまでの時間、コストの長期的な傾向も追います。
制約と改善課題
このパターンには、まだ次の課題があります。
誤ったフィードバック、組織内の少数意見、プロンプトインジェクションをどう選別するかという課題があります。最新のフィードバックへ過剰適合し、以前の事例での性能を損なうcatastrophic forgettingを防ぐ方法も必要です。
複数の矛盾する原則の統合や、実行用スキルが肥大化したときに参照資料へ移す内容と削除する内容の判断も課題です。モデル更新による変化とスキル更新の効果を分離する必要があります。ユーザー満足度、コスト、遅延など複数指標のトレードオフも判断しなければなりません。
特に、「エージェントが自分を改善する」という表現から完全自動の自己書き換えを想像しないことが重要です。Warpの設計は、人間からのフィードバックを収集し、エージェントが小さなスキル変更を提案し、人間がレビューしてマージするhuman-in-the-loopの継続改善です。
まとめ
Warpの事例で最も再利用しやすいのは、実行用スキルと改善用スキルを分けたこと、フィードバックを普段の作業場所で集めたこと、スキル更新をPull Requestとして扱ったことです。
エージェントを改善するには、フィードバックを増やすだけでなく、どのシグナルを信頼し、どの評価で改善を判定し、誰が変更を承認するかを設計する必要があります。スキルをコードと同じようにバージョン管理することで、エージェントの「学習」を監査可能な開発工程へ変えられます。
参照
- Michael Segner, How Warp builds self-improving agents on Claude, Claude Blog, 2026-08-26.
- Anthropic, Agent Skills overview.
- Anthropic, Skill authoring best practices.
- Warp, Ambient Agents Demo - GitHub Actions（2026-06-02にarchive済み）。