再学習なしで自己改善するエージェント — Warpが人間のフィードバックをスキルファイルに変換する方法 (2026)

Warpは、Claudeプラットフォーム上に構築されたAI搭載ターミナルおよびエージェント開発環境です。規模を示すと、$73Mの資金調達、月間アクティブ開発者800K人、Fortune 500の56%、40M回のWarp Agentの会話、そして驚くべき数字として「これまでにWarp内で実行されたClaude Codeセッションは10M回、毎週400K+回以上」に達しています。

課題は社内で不評だった内部エージェント

Warpのコードレビューエージェントは、自社のエンジニアをイライラさせていました。彼らは「エージェントが役に立たないコメントをし、低品質な出力を生成する」と不満を漏らしていました。記事では、この一般的な状況を簡潔に表現しています。「タスクの80%を正しくこなす初期プロンプトであっても、ユーザーにとってはノイズが多く、不快な体験を生み出す可能性がある。」

最初に2つのその場しのぎの対策が取られましたが、これらはどちらもほとんどのチームが試す方法です。失敗が観察されるたびに手動でプロンプトを書き直すことは「出力の使い勝手を向上させたが、スケールしなかった」。AGENTS.mdのようなコンテキストファイルを改善することも「役には立ったが、完全な解決策には程遠かった」。この限界の一般的なケースについては、why agents ignore the instruction files you wrote（エージェントが作成した指示ファイルを無視する理由）で解説しています。

インナースキルが知識を保持する

ベースとなるスキルは「機能的なドメイン知識と指示を保持」します。PR（プルリクエスト）が開かれると、Warpのコードエージェントはそのスキルに基づいて実行され、レビューを生成します。

Warpの創業者であるZach Lloydは、ファイル形式が重要である理由を次のように説明しています。「ファイルベースのスキルは、知識をプロンプトに直接入れることなく、エージェントが業務を遂行する過程で簡単に参照できるものとして、エージェント向けに知識をエンコードする方法です。」

改善スキルは観察者であり、参加者ではない

これこそがループを機能させる部分であり、スケジューリングの詳細を見落としがちです。アウタースキルは「タスクごとではなく、スケジュールに基づいて実行される観察者エージェントとして機能します。蓄積された人間のフィードバックを取得し、エージェントの提案と人間の反応を比較して、ベーススキルに対する小さく焦点を絞った編集を提案します。」

タスクごとではありません。スケジュールベースです。これは各実行にボルト留めされたリフレクション（自己省察）ステップではなく、コーパスを監視する独立したジョブです。

人間に対して求めるのは「具体性」です。Lloydの例：「人間は『これは良い、有用なコメントだった』と肯定することもできます。しかし、コードレビューが良くなかった詳細な理由を伝えることもできます。『この変数の名前変更を提案しているが、私たちのコードベースの規約では、このタイプのグローバル変数はこの特定の命名コンテキストを使用する』といった具体的な内容は、次回どのように正しく行うべきかをエージェントに教えることになります。」

コードレビューを通じてループが閉じる

これが単なる巧妙なトリックにとどまらない理由となる特性です。「スキルはプレーンなファイルであるため、エージェントはそれらを更新するのが非常に得意です。レビュー可能、承認可能、マージ可能なこれらの更新は、通常のPR/コードレビューのワークフローを流れることができます。マージされると、インナースキルの次の実行にその改善が引き継がれます。」

Warpのイシュートリアージエージェントは、これをエンドツーエンドで示しています。GitHub Actionがエージェントを起動し、新しいイシューの複雑さと実現可能性を分析し、ラベルを割り当て、方向性を提案します。あるイシューで、エージェントは ready to spec ラベルを付け忘れてしまいました。メンテナーはイシュー自体に（「まさに作業が行われていた場所」で）フィードバックを残し、期待していた内容とその理由の両方を説明しました。

その後、改善エージェント（improver）が、WarpのエージェントオーケストレーションプラットフォームであるOzで、スケジュールされた「アップデートトリアージ」エージェントとして実行されました。GitHubに対して認証を行い、スキルにバンドルされたPythonスクリプトを実行してフィードバックのある最近のイシューを取得し、それらをJSONファイルに要約して、コンテキストに読み戻しました。そして、「具体的なUIやUXの形状がまだ定義されていなくても、イシューが実際の問題を説明している場合には『ready to spec』ラベルを適用するように、インナースキルを編集するPRを開きました。」

そして、人間がそれをマージしました。Anthropicはこのステップを次のように表現しています。「その最後の人間によるステップがループを閉じ、実際に何が変更されるかを人間がコントロールし続けることを可能にします。」

Warpは現在、これをオープンソースリポジトリ全体で実行しており、仕様作成、レビュー、トリアージのそれぞれに独立したエージェントが独自のループを持っています。「何百人もの人々が貢献し、私たちは何千ものコードレビューを行っています。」

このパターンは説得力があります。その証拠はベンダーのケーススタディであり、その違いについて正確に把握しておく価値があります。

ビフォー・アフターの数値は示されていません。 記事では、レビュー品質、トリアージ精度、または不満の量の測定された改善については報告されていません。800K人の開発者、10M回のClaude Codeセッションという印象的な数字は、Warpのビジネス規模を表しているものであり、このループの効果測定値ではありません。エージェントがどれだけ良くなったかを定量化するものはここにはありません。

Warpは、これを実現するための環境が異例なほど整っています。 何百人もの貢献者がすでにPRコメントを残している公開リポジトリは、ほとんどのチームが持っていないフィードバックコーパスです。Ozは、スケジュールされたエージェントのための社内オーケストレーションプラットフォームです。どちらか一方でも欠ければ、このループは自作の何かに置き換える必要があります。

選ばれたドメインは、相性の良いものです。 コードレビューとイシュートリアージには、既存のレビューの習慣があり、大まかに検証可能な出力があります。Warp自身のガイダンスでも難しいケースを率直に認めており、「あなたのドメインは検証可能か？」と問いかけ、そうでない場合は「ゴールデンアウトプットに対する決定論的な評価（evals）が存在する場所では、それに頼る」ことを勧めています。

これは自律的な自己改善ではありません。 すべての変更は人間がマージするPRです。「自己改善」とは提案がどこから来るかを説明しているだけであり、誰が決定するかを指しているわけではありません。

Warpは、フィードバックが時々間違っていることを前提としています。 彼らの回答は、この記事の中で最も有用な一文であるため、全文を引用します。「間違っていると想定してください。エージェントにフィードバックを盲目的に受け入れさせてはいけません。サニティチェック（妥当性確認）を行うためのコンテキストを与え、誰の入力が有効かをフィルタリングし、フィルタリングまたは最終レビューの段階で人間をループに介在させ続けてください。」

そして、これは手続き的なループであり、memoryシステムではありません。 これは非常に重要であるため、Anthropicは記事自体のFAQの最初、つまり「スキルとmemoryを混同していませんか？」という見出しの下にこれを配置しました。その回答は次のとおりです。「スキルは手続き的で安定したものであり（『Xを行う方法』）、実行に依存せず、意図的に変更されます。memoryは推論時にエージェントによって自動的に書き込まれ、変化し続けます。」

これは、私たちがwhy Agent Skills aren't memory（エージェントのスキルがmemoryではない理由）で主張してきたのと同じ区別であり、ベンダーによって明言されています。これがここで重要なのは、このループが何を改善するのか、すなわち「エージェントがタスクをどのように実行するか」を教えてくれるからです。プロジェクトについてエージェントが何を知っているか、ではありません。

「スキルは今やmemoryである。」 記事の見出しでは、その逆が述べられています。スキルは意図的に変更する安定した手続きであり、memoryは推論時に書き込まれ、変化し続けるものです。Warpのループは、レビューを通じて意図的に手続きを改善します。

「エージェントが自ら改善する。」 すべての変更は人間がマージします。そのステップを排除すると、エージェントが監視なしで自身の指示を編集することになり、これは全く異なる、より悪いシステムになってしまいます。

「必要なのは2つのファイルだけである。」 フィードバックが届く場所、スケジューラー、そしてコーパスをコンテキストに引き込む何か（Warpの場合はGitHub Action、Oz、およびバンドルされたPythonスクリプト）も必要です。

「フィードバックは多ければ多いほど良い。」 Warpの立場は「品質第一」です。「エージェントが他の方法では取得できないような、ドメイン固有の知識に関する人間からの非常に詳細なフィードバックであれば、比較的少ないサンプルサイズからでも非常に優れたシグナルを得ることができます。」また、検証不可能なドメインについては、「ドメインエキスパートに限定し、門戸を広げすぎないようにする」ことを勧めています。

「これは書き留める作業に取って代わる。」 これは書き留める作業を「工業化」するものです。改善エージェント（improver）の仕事のすべては、フィードバックを永続的なファイルに変換することです。

Warpのセットアップ以外でこれを模倣しようとすると、2つのギャップが生じます。どちらもスキルではなく、コーパスに関するものです。

1つ目は、改善エージェント（improver）はアクセスできるフィードバックからしか機能しないということです。WarpのフィードバックはPRコメントにあります。なぜなら、そこが彼らの作業場所だからです。もしあなたの修正指示がSlackのスレッド、レビュー会議、あるいは誰かの頭の中に留まっているなら、スケジュールされたジョブが取得できるものは何もありません。

2つ目は、ベンダー自身の区別が示している点です。スキルは手続きを保持します。それらは、修正指示が通常含んでいる「事実」（なぜその規約が存在するのか、すでに何を試したのか、どの制約によって明らかな答えが間違っていたのか）を格納するには不適切なコンテナです。Warpの修正例には、命名規約、それが適用されるカテゴリ、および理由の3つすべてが含まれています。手続きはスキルに入ります。しかし、理由には行き場がありません。

それこそが、MemoryLakeが保持するものです。エージェントがクエリするレイヤーにプロジェクトの永続的な事実を保持するため、手続き的知識と事実的知識が同じファイルを奪い合うことがなくなります。セットアップは3つのステップです。

ステップ 1: APIキーを作成する

サインインしてAPIキーを作成します。接続するツール間で共通の1つの認証情報です。

ステップ 2: 最初のmemoryをアップロードする

1つの主張につき1つの短いエントリ。すでに与えた修正指示は、最良のソース素材になります。

規約と理由。 「グローバル設定値は、ローダーが起動時にそれらをgrepするため、CFG_ プレフィックスを使用します。」ルールはスキルに含めることができます。理由があることで、ルールが元に戻されるのを防ぎます。

すでに却下されたアプローチ。 どのスキルファイルにもコミットメッセージにも現れず、新しいセッションのたびに再提案されてしまうようなカテゴリです。

複数回与えた修正指示。 2回言ったのであれば、それはそのタスクに関する好みではなく、プロジェクトに関する事実です。

どこにも明記されていない環境制約。 CIでのみ失敗するテスト、ドキュメント化されていないレート制限、2つのジョブ間の順序依存関係などです。

ステップ 3: AIとエージェントを接続する

MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのエージェント（Claude、Claude Code、Codex、OpenClawなど）はMCPサーバーを指定することで接続し、他のアシスタントはAPIを介して同じmemoryを読み取ります。改善エージェント（improver）スタイルのジョブは、変更を提案する前にコンテキストをクエリすることができ、これはまさにWarpが推奨するサニティチェック（妥当性確認）そのものです。

3つの率直な限界があり、最初のものがここで最も重要です。これはループの代替にはなりません。 Anthropicの区別は両刃の剣です。memoryレイヤーは手続きを保持せず、スキルは事実を保持しません。エージェントにタスクをより良く実行させたい場合は、ループを構築してください。Warpの設計は優れており、PRレビューのステップはmemoryレイヤーにはない真の強みです。MemoryLakeはスキルファイルを書き換えませんし、エージェントの実行を監視することもありません。また、あなたやエージェントが入力したものだけを保持するため、ステップ2は意図的に行う必要があります。

フィードバックが使い捨てではなくなります。 コメントは、誰かがスクロールして通り過ぎるメッセージではなく、ファイル編集になります。

改善がプルリクエストとして届きます。 レビュー可能、元に戻すことが可能、帰属が明確。これは、ほとんどのエージェントチューニングが提供するもの以上の価値です。

「理由を説明する」ことが仕事の習慣になります。 ルールではなく原則を書くというWarpのアアドバイスは、その理由が記録されて初めて報われます。

改善エージェントが再利用可能になります。 Lloydの言葉を借りれば、「コードレビューエージェント用の改善スキルは、他のエージェント用の改善スキルとそれほど変わりません。」

スキルは意図的に小さく保たれます。 肥大化する1つのドキュメントではなく、段階的な開示とバンドルされたリソースファイル。これは、what coding agents actually read（コーディングエージェントが実際に読んでいるもの）で説明されているのと同じ力学です。

事実と手続きの競合がなくなります。 スキルが「どのように（how）」を指示し、別の何かが「なぜ（why）」を保持します。

既存のレビュー習慣があるドメインを選択する。 コードレビューやトリアージが機能するのは、すでに誰かがそれを見る予定になっているからです。

作業が発生する場所でフィードバックをキャプチャする。 Warpのルール：「摩擦が少ないことこそが、シグナルを流し続ける秘訣である。」

判定だけでなく、理由にこだわる。 低評価（バッドマーク）だけでは、何を修正すべきかはわかりません。Warp自身の修正例は1文の長さですが、ルール、カテゴリ、および理由が含まれています。

改善エージェントはスケジュール実行し、タスクごとに実行しない。 単一のインタラクションではなく、比較対象となるコーパスが必要です。

マージには人間を介在させる。 これこそが、システム全体を安全に実行できるようにするステップです。

一部のフィードバックは間違っていると想定する。 誰の入力を重視するかをフィルタリングし、エージェントに妥当性を確認するためのコンテキストを与えます。

ルールではなく原則を書く。 「コンピュータをプログラミングするようにではなく、賢い人に指示を与えるようにスキルを構築してください。」

ドメインが許すなら、まず検証ハーネスを構築する。 その後、エージェントにそれに対する調整を行わせます。

事実をスキルファイルから排除する。 手続きは安定しており意図的ですが、事実は蓄積され変化します。価値の低い事実をアクティブに保ち続けるコストについては、what a retention-scored memory tree showed（保持スコア付きmemoryツリーが示したこと）で測定されています。

Warpのパターンは、ここ最近で公開された自己改善エージェントに関するものの中で最も実用的なものです。その主な理由は、適切な意味で「退屈（シンプル）」だからです。インナースキルがドメイン知識を保持します。アウタースキルはスケジュールに基づいて実行され、蓄積された人間のフィードバックを読み取り、エージェントが提案した内容と人間が実際に求めていた内容を比較し、インナースキルを編集するプルリクエストを開きます。人間がそれをマージします。次の実行は、その変更を引き継ぎます。

これが信頼できるのは、モデルの進化に何も依存していないからです。スキルはプレーンなファイルであり、エージェントはプレーンなファイルを編集するのが得意であり、プルリクエストにはすでにレビュー文化が定着しています。一方で、冷静に受け止めるべき点としては、ビフォー・アフターの数値が公開されていないこと、Warpがこの問題に対して大規模なフィードバックコーパスと社内スケジューラーを投入したこと、そして彼ら自身のガイダンスが、フィードバックは時々間違っていると想定すべきだと伝えていることです。

そして、記事のFAQの冒頭にある区別を忘れないでください。スキルは手続き的で安定しており、意図的に変更されます。memoryは推論時に書き込まれ、変化し続けます。フィードバックループは、エージェントの業務遂行能力を向上させます。プロジェクトを記憶させるわけではありません。異なるコンテナで両方を実現する必要があります。そして、最も早く始める方法は、次の修正指示に「理由」を含めることです。そうすれば、後でそれを読み取るものが何であれ、保持する価値のある情報を得ることができます。