Anthropicは8月26日、Warpの取り組みに関するエンジニアリングの振り返りを公開した。モデルの重みには一切手を加えずに、自社のエージェントの振る舞いを継続的に修正する方法を解説する内容だ。
WarpはAIターミナルとエージェント開発環境を手がける企業で、2020年にZach Lloyd氏が創業した。累計調達額は7300万ドル。同社が開示する数字によると、月間アクティブ開発者数は80万人、フォーチュン500企業の56%が同社の製品を利用した経験があるという。Claude CodeはWarp上で累計1000万セッション以上を実行しており、現在は週40万セッションを超え、プラットフォーム上のエージェントとの対話総数は4000万件に達した。
3層構造
この仕組みを分解すると、要素は3つしかない。
最も内側にあるのが基本スキルだ。ドメイン知識と運用ルールを書き込んだファイルで、例えばコードレビューで何を見るべきか、何が阻害要因になるかといった内容を含む。中間にあるのが人間のフィードバック、つまり開発者によるエージェントの出力への評価だ。最も外側にあるのが書き換えエージェントで、Warp社内ではimprover skillと呼ばれている。その仕事はただ一つ、フィードバックを定期的に集約し、基本スキルに小さな修正を提案することだ。
Lloyd氏はこの構造をこう説明する。
"There's the base domain-specific skill and then there's the improver skill that refines that domain-specific skill. This simplicity is the beauty of this approach."
意訳：基本となるドメイン固有のスキルと、それを磨き上げる改善スキルがある。このシンプルさこそがこの手法の美点だ。
スキルはファイルとして保存され、Claudeプラットフォームの Agent Skills API を利用している。この選択がもたらす波及効果は、見た目以上に大きい。ファイルはエージェントが直接編集できるだけでなく、Gitにも取り込める。書き換えエージェントが提案するすべての修正は、通常のコード変更としてチームのレビューを通る。人間は拒否権を持ち、ロールバックでき、diffを見ればエージェントが自分にどんなルールを新たに加えたのかが分かる。知識をプロンプトに積み上げるのではなくファイルシステムに書き込むことで、「モデルが今日また変わった理由」を追跡可能なコミットに変えられる。
見落とされがちな前提がある。3層のうち最も外側の層自体も、1つのスキルファイルだということだ。書き換えエージェントがフィードバックをどう読み、修正すべきかどうかをどう判断し、一度にどれだけ変更するか——これらも同様にファイルに書かれていて、同様に人間が変更できる。システム全体にブラックボックスはなく、問題が起きても2つのファイルをたどれば根本まで追える。
フィードバックの質が上限を決める
Warpのコードレビューエージェントは稼働開始時、精度がおよそ80%だった。残り2割を押し上げているのがこのループだ。Lloyd氏が強調するのはフィードバックの形で、「このレビューは良くなかった」という一言には意味がなく、「なぜそのコードレビューが良くなかったのかという詳細な理由」があって初めて学習が進むという。
難しいのは、詳細な理由を書くには時間がかかる一方で、開発者は自分の仕事を進めるのに忙しいという点だ。Warpが取った対策は、フィードバックの入力口を極力低摩擦にすることだった。Lloyd氏の言葉を借りれば"Low friction is what keeps signal flowing"、摩擦が低いほどシグナルは流れ続ける。この点は3層構造そのものより実現が難しい。仕組みは1週間もあれば組み上がるが、チームが長期にわたって情報量のある評価を残し続けるようにするのは、プロダクト設計の課題だからだ。
この仕組みの限界
このループの経済性を大まかに見積もると、書き換えエージェントはフィードバックが十分に溜まったときだけ動く。1回の実行で読むのは集約済みのフィードバックと、数百から数千トークン程度のスキルファイルで、出てくるのは数行のdiffだ。ファインチューニングと比べればコストはほぼ無視できる水準だが、代わりに変更できるのはファイルに明示的に書かれたルールだけで、モデル自身の判断や好みには手を加えられない。
つまりこれは、モデルを賢くする仕組みというより、エージェントに生きた運用マニュアルを持たせる仕組みに近い。向いているのはルールが明確で、フィードバックが密で、正誤を判定できるタスクだ。コードレビュー、チケットの分類、フォーマット変換などがそれに当たる。モデル自身の根本的な判断を変える必要がある仕事に当たった時点で、このループは限界に達する。
ただ、多くのチームにとってこの上限は大きな問題にはならない。本番環境でエージェントが起こすエラーの大半は、モデルの強さ弱さよりも、明文化されていないルールに起因するものだからだ。ルールを明文化する作業は、これまで人間がプロンプトを何度も書き直すことで担ってきたが、いまや自分で手を動かし、その変更をレビューの俎上に載せる協働者が加わったことになる。
参考資料：AnthropicによるWarpのエンジニアリング振り返りの公式ブログ、CocoLoop、Warpが公開している製品・資金調達情報。セッション数、精度、調達額はいずれも公開情報に基づく。