AI・機械学習
Warp、Claude上で自己改善エージェントを構築
Warp builds self-improving agents on Claude (claude.com)
要約
Warpは、Claudeプラットフォームを活用して、自己改善ループを持つAIエージェントを開発しました。このアプローチでは、エージェントの機能知識をファイルベースの「スキル」としてエンコードし、人間のフィードバックを収集して、そのフィードバックを基にスキルを継続的に更新する「インプルーバー」エージェントを運用します。これにより、エージェントは時間とともにパフォーマンスを向上させ、より信頼性の高い出力を提供できるようになります。
全文翻訳
WarpがClaude上で自己改善エージェントを構築する方法
Warpが、誰でも利用できるシンプルな開発パターンを用いて自己改善エージェントを作成する方法を学びましょう。
カテゴリ
エージェント
製品
Claude Platform
日付
2026年8月26日
読了時間
5分
共有
リンクをコピー
https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude
著者
Michael Segner
シリーズでは、スタートアップがAIで業界をどのように変革しているかを紹介しています。この記事では、Warpがステートレスなユーザーフィードバックをエージェントの自己改善ループに変換した方法を共有します。
クイックピッチ
名前
Warp
設立
2020年
創業者
Zach Lloyd (CEO)
スタック
Rust, Golang, GitHub Actions, 内部エージェントオーケストレーションプラットフォーム (Oz), Claude Platform
成長
7300万ドルの資金調達。80万人の月間開発者がWarp上で開発。Fortune 500企業の56%がWarpを使用。これまでにWarp内で1000万回のClaude Codeセッションが実行され、週あたり40万回以上。合計4000万回のWarp Agent会話。
エージェントは、繰り返しタスクを信頼性高く効果的に処理する必要があります。タスクの80%を正しく実行する最初のプロンプトでは、ユーザーにとってノイズが多く、不快な体験を生み出す可能性があります。Warpはこの教訓を苦労して学び、それを製品戦略に反映させ、世界中の約100万人の開発者にとってより良い体験を創造しました。
Warpは、AI搭載のターミナルおよびエージェント開発環境であり、Claudeプラットフォーム上に構築されています。チームは、社内のコードレビューエージェントでこの「ノイズの多い体験」という問題に直面しました。エンジニアは、エージェントが役に立たないコメントを生成し、低品質な出力をすると不満を漏らしました。
チームは当初、観察されたコードレビューの失敗に基づいてプロンプトを手動で書き直すなどの一時的な解決策を試しました。これにより出力はより使いやすくなりましたが、スケーリングしませんでした。AGENTS.mdのようなコンテキストファイルを改善することも役立ちましたが、完全な解決策には程遠いものでした。最終的に、彼らは、エージェントの目的が何であれ、フィードバックはセッションが終了すると通常消えてしまい、エージェントループから重要なコンテキストが失われるという根本的な問題に気づきました。彼らの解決策は、フィードバックが時間とともに蓄積され、エージェントの出力を継続的に洗練・強化する、スキルベースのフレームワークを使用して自己改善エージェントを作成することでした。Claudeプラットフォーム上にスキルを構築して、どのように実装したかを以下に説明します。
スキル上に構築されたエージェントの自己改善ループ
中核となる技術は、スキルを使用した自己改善ループです。スキルとは、生のプロンプトから指示を取り除く、ファイルベースの知識エンコーディングです。Warpは、人間のフィードバックを挟んで、2つのスキルからなる自己改善エージェントアーキテクチャを進化させました。
内部/ベーススキルは、機能的なドメイン知識と指示を保持します。例えば、PRが作成されると、Warpのコードエージェントはそのベーススキルとコンテキストを使用してレビューを生成します。
エージェントの出力に対する人間のフィードバックは、自己改善ループの重要なコンポーネントです。コードレビューの場合、これは単なる「いいね」ボタンのような簡単なものでも構いませんが、より具体的であるほど良いです。「人間は、『これは良い、有用なコメントだった』と肯定することができます」とWarpの創業者Zach Lloyd氏は説明します。「しかし、人間はコードレビューがなぜ良くなかったのかについて詳細な理由を与えることもできます。例えば、『この変数をリネームすることを提案しましたが、私たちのコードベースの規約では、この種のグローバル変数はこの特定の命名コンテキストを使用します』といった具体性は、エージェントに次回どのように正しく行うかを伝えます。」
外部/インプルーバー(改善者)スキルは、タスクごとではなくスケジュールで実行されるオブザーバーエージェントとして機能します。これは蓄積された人間のフィードバックを取得し、エージェントが提案した内容と人間がどのように応答したかを比較し、ベーススキルに小さく焦点を絞った編集を提案します。
スキルはプレーンファイルであるため、エージェントはそれらを更新するのが非常に得意です。レビュー、承認、マージが可能なこれらの更新は、通常のPR/コードレビューワークフローを通じて流れることができます。マージされると、内部スキルの次の実行は改善を継承します。Warpは現在、このパターンをオープンソースリポジトリ全体で実行しており、それぞれが独自の自己改善ループを持つ、仕様作成、レビュー、トリアージのエージェントが別々に存在します。
「ファイルベースのスキルは、エージェントがその仕事をする過程で単に参照できるものとして、プロンプトに直接知識を置くことなく、エージェントのために知識をエンコードする方法です」とZach氏は言います。「フレームワークは実際には非常にシンプルです。ドメイン固有のベーススキルがあり、そのドメイン固有のスキルを洗練するインプルーバー(改善者)スキルがあります。このシンプルさがこのアプローチの美しさです。」
エージェントのための自己改善スキルを書く方法
以下は、Warpチームがエージェントループのための自己改善スキルを書く上で試行錯誤して得たヒントです。
ルールではなく原則を書く。「スマートな人に指示しているかのようにスキルを構築してください。コンピューターをプログラミングするようなものではありません」とZach氏は言います。「『繰り返しコードを探す』といった指示をスキルに含めることは、網羅的な変数命名規則よりも優れた指示を提供します。」
理由を説明する。ルールの背後にある根拠を提供することで、エージェントは厳格な指示に従うのではなく、問題について推論できるようになり、より良い一般化が可能になります。
フィードバックを容易に与えられるようにする。人々がすでに作業している場所、例えばPRや課題に直接コメントすることで、フィードバックをキャプチャします。また、追加の送信ステップなしで、これを自動的に行います。「低摩擦がシグナルを流れ続ける鍵です」とZach氏は指摘します。「あまりにも難しくすると、フィードバックが得られず、スキルを改善できなくなります。」
スキルを小さく保ち、段階的な開示を使用する。良いスキルファイルは大きくありません。すべてを一度にコンテキストにダンプするのではなく、リソースファイルやスクリプトを参照します。
フィードバックの質 > 量、しかし量も役立つ。シニアエンジニアからの詳細でドメイン固有のフィードバックは、多数の表面的フィードバックよりも価値がある場合があります。なぜなら、バイナリの「いいね/悪いね」では理由がわからないからです。「比較的少ないサンプルサイズでも、非常に詳細なフィードバックであれば、非常に良いシグナルを得ることができます。それは、エージェントがそうでなければ決して得られないような、ドメイン固有の知識に関するものです」とZach氏は続けます。「とはいえ、質の高いシグナルのコーパスが大きければ大きいほど良いです。Warpでは、オープンソースリポジトリ全体を管理するためにループを使用しています。何百人もの人々が貢献しており、私たちは何千ものコードレビューを行っています。」
インプルーバー(改善者)スキルに余分な労力をかける。インプルーバー(オブザーバーエージェント)スキルを書くのに余分な労力をかけることは、直接的なエージェントループを超えて成果をもたらします。なぜなら、インプルーバースキルはさまざまなユースケースで非常に再利用可能だからです。「ドメイン固有の知識コンポーネントの外では、これはかなり再利用可能なメカニズムです。コードレビューエージェントのインプルーバースキルは、他のどのアージェントのインプルーバースキルともそれほど違いはありません。」
ループの動作例:Warpの課題トリアージエージェント
Warpの課題トリアージエージェントは、自己改善エージェントスキルフレームワークを示しています。このパターンは、誰かが新しいGitHub課題を提出するたびにトリガーされます。GitHub Actionが、課題の複雑さと実現可能性を分析し、ラベルを付け、修正の方向性を提案するエージェントを起動します。そのトリアージエージェントは、各ラベルの意味と、アクションを実行する前にコードベースを調査する方法に関するドメイン知識を保持する内部スキルファイルで動作します。
サンプル課題では、最初のステージの内部スキルはうまく機能しましたが、「準備完了」というラベルを1つ見逃しました。これは、貢献者が課題に対して製品および技術仕様の作成を開始できることを示すシグナルです。Warpチームのメンテナーがそのギャップに気づき、作業が行われているまさにその場所である課題に直接フィードバックを残しました。決定的なのは、期待していたことと、なぜそれを期待していたのかの両方を説明したことです。これは、エージェントが後で吸収しやすい実行可能なフィードバックでした。
外部のインプルーバー(改善者)スキルは、WarpのエージェントオーケストレーションプラットフォームであるOzで、スケジュールされた「トリアージ更新」エージェントとして実行されます。エージェントはGitHubに認証し、スキルにバンドルされたPythonスクリプトを実行して、フィードバックを含む最近の課題を取得し、それらをJSONファイルに要約して、コンテキストに読み込みました。バンドルされたスクリプト自体がベストプラクティスです。スキルは、実行ごとに新しいコードを書くのではなく、リソースファイルを参照できます。
そこから、エージェントはメンテナーのコメントに含まれる具体的なフィードバックシグナルを特定し、提案しました。