Warp、Claudeを活用した「自己改善型AIエージェント」の構築手法を公開 ファイルベースのスキル更新で精度を継続向上
要点
-
AIターミナル開発のWarpが、Claude Platformを活用してAIエージェントが自律的に精度を向上させる「自己改善ループ」の開発パターンを公開した。
-
プロンプトの手動修正ではなく、知識を記述した外部ファイル(スキル)を別の観察エージェントが自動更新する仕組みを採用している。
-
開発者からの日常的なフィードバックを定期集約し、修正案を通常のプルリクエストとして提案・反映させる。
-
オープンソースリポジトリでの実践をもとに、スキルの記述方法やフィードバック収集など6つの運用原則を提示している。
-
AIターミナルおよびエージェント型開発環境を手がける米Warpは2026年8月26日、Anthropicの公式ブログにおいて、Claude Platform上で自律的に改善を続けるAIエージェントの開発パターンを公開した。開発者が行う日常的なフィードバックを外部ファイルとして管理される指示定義に還元することで、継続的にエージェントの出力精度を高めるアプローチだという。同社はこの仕組みを社内およびオープンソースリポジトリの運用に広く導入していることを明らかにした。
コードレビューの品質課題と一時しのぎの限界
2020年設立のWarpは、RustやGolang、GitHub Actions、社内エージェント基盤「Oz」、Claude Platformなどを採用するスタートアップで、累計7300万ドルの資金を調達している。現在、月間80万人の開発者が利用し、Fortune 500企業の56%に導入されている。同環境内で実行されたClaude Codeのセッション数は累計1000万回(週40万回以上)、Warpエージェントの総会話数は4000万回に達しているという。
同社では社内向けコードレビューエージェントを運用していたが、役に立たない指摘や低品質な出力がエンジニアの不満を招いていた。チームは当初、失敗事例に合わせてプロンプトを手動で書き直したり、指示用のコンテキストファイル(AGENTS.md)を改善したりする対症療法を試みたものの、規模拡大には対応できなかったと説明している。セッションが終了するたびにユーザーからのフィードバックが失われ、改善ループから重要な文脈が消えてしまうことが根本的な課題だったと分析している。
「2つのスキル」と人間からのフィードバックで構成される改善ループ
そこでWarpが構築したのが、Claude Platformの「Agent Skills」を活用した自己改善ループである。エージェントスキルとは、プロンプト内に直接指示を書き込むのではなく、外部ファイルとして知識や手順を定義して参照させる仕組みを指す。このアーキテクチャは、主に以下の3つの要素で構成されている。
- インナー/ベーススキル(基礎スキル): 業務のドメイン知識や指示を保持する。プルリクエスト(PR:コード変更の取り込み提案)作成時などに、エージェントがこのスキルと文脈を参照してレビューを実行する。
- 人間によるフィードバック: エージェントの出力に対する開発者の評価。単純な評価だけでなく、「この変数名変更の提案は、当リポジトリのグローバル変数命名規約に沿っていない」といった具体的な理由が含まれるほど効果的だという。
- アウター/インプルーバースキル(改善スキル): タスクごとではなく定期的にスケジュール実行される観察エージェント。蓄積されたフィードバックを集約し、エージェントの提案と人間の反応を比較した上で、ベーススキルに対する小さく的を絞った編集案を作成する。
スキルはプレーンテキストファイルであるため、エージェント自身による更新が容易である。提案された変更は通常のPRとして人間がレビューや承認を行い、マージされると次回のベーススキル実行時に即座に改善が反映される。Warpではこの手法を、仕様策定、コードレビュー、Issueトリアージなど、オープンソースリポジトリ全体の各エージェントに適用しているという。
Warpが提示する「自己改善スキル」作成の6つの原則
WarpのCEOであるZach Lloyd氏は、自己改善型スキルを効果的に運用するためのポイントとして以下の6項目を挙げている。
- ルールではなく原則を書く: コンピュータのプログラムではなく優秀な人間に指示するように記述する。「重複コードを探す」といった方針を示す方が、網羅的な命名規則よりも適切な指示になるという。
- 理由(Why)を説明する: 単に指示を並べるのではなく背景の理由を明記することで、エージェントが問題について推論できるようになり、汎化性能が高まる。
- フィードバックの手間をなくす: PRやIssueへのコメントなど、エンジニアが普段作業している場所で自動的に収集し、特別な提出手順を不要にする。
- スキルを小さく保ち、段階的開示を活用する: スキルファイル自体を肥大化させず、必要に応じて外部の参照ファイルやスクリプトを呼び出す設計(段階的開示:必要な情報のみを順次読み込ませる手法)を採用する。
- 量よりもフィードバックの質を重視する: 単なる高評価・低評価のボタンよりも、シニアエンジニアによる詳細な理由付きフィードバックの方が有益なシグナルになる。ただし、データ母数が多いことも重要であると補足している。
- 改善スキルの作成に注力する: 観察エージェント(インプルーバースキル)はドメイン知識に依存しないため、一度作成すれば他の様々な用途のエージェントに再利用できる。
補足
Warpは本アーキテクチャの実践例として、GitHub Issueの自動トリアージ(優先度や分類の振り分け)を行うエージェント(warp-agents-demo-github-issue-triage)のデモをGitHub上で公開している。