8月26日、Michael Segnerが「How Warp builds self-improving agents on Claude」と題した記事を公開した。AI搭載ターミナル「Warp」が、Anthropicの大規模言語モデルClaudeを基盤とするClaude Platform上で自己改善型エージェントを構築するために編み出したパターンについて詳しく紹介されている。
問題の出発点：フィードバックがセッション終了と同時に消える
Warpのチームは社内のコードレビューエージェントを運用する中で、典型的な問題に直面した。エンジニアから「的外れなコメントが多い」「出力の質が低い」というクレームが相次いだのだ。
最初は手動でプロンプトを書き直したり、AGENTS.mdのようなコンテキストファイルを改善する対処療法を試みた。一時的な改善にはなったが、根本解決にはならなかった。
真の問題は構造的なものだった。エージェントへのフィードバックは、セッションが終わると消えてしまう。 その結果、改善のサイクルが回らず、エージェントは同じミスを繰り返す。
Warpは2020年創業、Rust製のAI搭載ターミナルおよびエージェント開発環境だ。月間アクティブ開発者数は80万人、Fortune 500企業の56%が利用しており、これまでに4,000万回のWarp Agentセッションが実行されている。このスケールにおいて、エージェント品質のわずかな差がユーザー体験に直結する。
解決策：スキルベースの自己改善ループ
Warpが編み出したのは「スキル（Skills）」を使った自己改善ループだ。スキルとは、プロンプトに直接埋め込むのではなく、ファイルとして外部に切り出した知識・手順のエンコーディングを指す。
アーキテクチャはシンプルで、2つのスキルと人間のフィードバックで構成される。
[ベーススキル（内側）] → エージェントが実行 → 出力
↑ ↓
[インプルーバースキル（外側）] ← 人間のフィードバック
- ベーススキル（base skill）: ドメイン固有の知識と手順を保持する。例えばコードレビューエージェントなら「各ラベルの意味」「コードベース規約」などを記述する。
- インプルーバースキル（improver skill）: オブザーバーエージェントとして定期的に（タスクごとではなくスケジュール実行で）動く。蓄積されたフィードバックを読み込み、ベーススキルへの小さな修正を提案する。
スキルはプレーンなテキストファイルなので、エージェント自身がそれを更新するのが得意という点が重要だ。提案された修正はPRとして上がり、通常のコードレビューフローでレビュー・マージできる。マージされれば、次回実行のベーススキルに改善が反映される。
WarpのCEO Zach Lloydはこのシンプルさを次のように説明している。
「フレームワーク自体は非常にシンプルです。ドメイン固有のベーススキルと、それを改善するインプルーバースキルがある。このシンプルさこそがこのアプローチの美しさです。」
実際の動作：Issueトリアージエージェントの例
Warpのオープンソースリポジトリで稼働するIssueトリアージエージェントが、この仕組みをよく示している。
- GitHubに新しいIssueが作成されると、GitHub Actionsが起動
- エージェントがIssueの複雑さと実現可能性を分析し、ラベルを付与して修正方針を提案
- あるケースでは、ベーススキルは概ね正しい判断をしたが、
ready to specラベル（コントリビューターが仕様策定に入れる状態）の付与を見落とした - メンテナーがIssue上に「なぜ
ready to specが必要か」を直接コメント - インプルーバースキルがWarpの社内エージェントオーケストレーション基盤「Oz」上でスケジュール実行され、フィードバックを収集・分析
- ベーススキルの修正をPRとして提出、マージ後は次回から改善済みの知識で動作
Ozはバンドルされたリソースファイルやスクリプトを参照して動くため、毎回コードをゼロから書かずに済むというのもベストプラクティスとして紹介されている。なお、Ozは現時点でWarp社内で運用されているオーケストレーション基盤であり、一般公開ツールとは明示されていない。
実装時のポイント
Warpチームが積み上げてきた具体的な指針は以下のとおりだ。
- ルールではなく原則を書く: 「変数名はXXX形式」のような規則列挙より「繰り返しのコードを探せ」のような方向性の方が汎化しやすい
- 理由（why）を説明する: 根拠があると、エージェントがルール外のケースでも推論できる
- フィードバックの摩擦を限りなくゼロに: PRやIssueに直接コメントするだけで完結するようにする。「フィードバックしにくいと、シグナルが流れ込んでこない」（Zach）
- スキルファイルは小さく保つ: 全情報を詰め込まず、リソースファイルやスクリプトへの参照で段階的に開示する
- インプルーバースキルは使い回せる: コードレビュー用のインプルーバーとトリアージ用のインプルーバーは構造がほぼ同じ。ここに手間をかけると横展開が効く
- フィードバックの質 > 量: 上級エンジニアによるドメイン固有の詳細フィードバック少量の方が、単純な👍👎多量より価値が高い。ただし高品質なシグナルが多いほど良い
なお、スキルは「メモリ（Memory）」とは別物だ。スキルは手続き的で安定しており（「Xをどうやるか」）、意図的に変更される。メモリはエージェントが推論時に自動書き込みするもので、常に変化し続ける。この区別を混同しないことをWarpチームは強調している。
Warpが今なぜここに注力するか
エージェントが反復タスクを担うようになると、初期プロンプトの80点が「ノイズの多い迷惑な体験」に直結する。WarpはすでにClaude Codeセッションを週40万回以上、累計1,000万回実行しており、エージェント品質のわずかな差がユーザー体験に大きく影響するスケールで開発を続けている。
Warpはこのパターンを、仕様策定・コードレビュー・Issueトリアージの各エージェントに展開済みだ。コントリビューターは数百人、コードレビューは数千件規模で自己改善ループが回っている。
詳細はHow Warp builds self-improving agents on Claudeを参照していただきたい。
