コーディングエージェントの自己改善技術

序文

image自己再帰的改善（リカーシブ・セルフインプルーヴメント）とは、モデルが自らを反復して改良し、特異点への道を開くという考え方です。私たちは Cline において、その概念を実現するバージョンを達成しました。

ここ数日、Kimi K3 に対する反応は驚くべきものでした。この勢いを背景に、Cline を活用して性能を最適化し、ワンショットの自己再帰的改善によって Terminal-Bench 2.1 で SOTA（最良）の結果を達成しました。

コストは 49.8 ドルでスコア 88.8% を記録。これは Fable 5 の結果を上回るもので、しかも費用は約 10 分の 1 です。Fable は 552 ドル、GPT-5.6 Terra でさえも Tbench 2.1 に 400 ドルを費やしています。

imageシステムプロンプトと数回のヒントを除き、これは完全に自己完結したものでした。GPT-5.6-Sol をリーダーモデルとして採用し、単一のプロンプトで 17 時間にわたるコーディングエージェントの連続実行が開始されました。トークン使用量は合計 10 億。そのうち 4 億はコーディングエージェントが消費し、残りの 6 億は反復的な評価ランで使用されました。使用したプロンプトの詳細はこちらをご覧ください。

通常であれば、私たちが常に行っているようなヒルクライミング（勾配上昇法）を採用していたはずです。しかし今回は、モデル自身が PR を作成しました。これは「良いスコア」を「SOTA スコア」へと引き上げる、前例のないヒルクライミングの成功です。なお、Fable 5 でも同様の実験を試みましたが、AI セーフティフィルターがモデルを Opus-4.8 に降格させたため、結局は断念しました。

Cline のヒルクライミングの経験

ヒルクライム手法自体は、私たちにとって新しいものではありません。Cline ではすでに一定期間、評価とヒルクライムを繰り返してきました。今年 1 月には、Opus 4.5 を用いて Terminal-Bench のスコアを 47% から 57% に引き上げました。この成果を得るためには、モデルのトレースを読み込み仮説を立て、修正を試み、目の充血するほど失敗ログを見つめ続けるという、数週間にわたる人的作業が必要でした。

2 月にはそのプロセスをまとめたプレイブックを発表しました。これはエンジニアリングチームの 4 名が共同で取り組んだ成果です。

それから半年後、ハーンとモデルの両方が大幅に改善され、今回の実行はエンジニア 1 名の単一のプロンプトだけで完了しました。数週間にわたる人的作業が、17 時間に及ぶエージェントによる長時間実行へと変換されたのです。トレースの読み込みや仮説形成、修正テストといったすべての工程を、固定された目標と適応可能なコンテキストウィンドウを持つエージェントがカバーしています。

現時点で明確なのは、ボトルネックはモデルそのものではなく、それを使う人間にあるということです。

また、私たちのスコアは慰められるべきものではありません。Moonshot がベンダー報告した Terminal-Bench 2.1 の SOTA は 88.3% です。私たちは一般向けのハーンを用いて、最初の再帰的キャンペーンでこれに匹敵する結果を出しました。コスト計算と証明トレースの詳細はここに添付しています。

まずは、再帰的な実行がどのように行われたのかを手順を追って解説しましょう：

実際のヒルクライム

以下のすべては、単一のプロンプトから始まりました。

まずベースラインを設定しました。標準の Cline ハーンで Kimi K3 を OpenRouter 経由で実行し、Terminal-Bench 2.1 のフルランを行いました。結果は 69/89（77.5%）、コストは 79 ドルでした。

手動でヒルクライミングを行う代わりに、GPT-5.6 にプロンプト作成を依頼しました。通常の climbing の手順を説明すると、AI はそれを再帰的自己改善の指示書へと変換してくれました。最初のドラフトはすでに網羅的な内容でしたが、エッジケースへの対応を追加し、明確な終了状態を定義してブラッシュアップしています。目標は控えめなものに留めました。「しばらく実行してみて、結果を見てみよう」という程度です。これほどまでに高い性能を発揮するとは予想もしていませんでした。しかし、現在では SOTA（State of the Art）スコアを達成しています。

完全なプロンプトは、こちらの GitHub Gist で確認できます。

エージェントは異なる実験を順次実行し、無限ループに陥らないよう、自身の成果を巨大なファイルに記録しながら進めました。

Experiment 0: 最大推論能力の活用。最初の発見として、Cline が K3 の最大推論努力を正しく表現できていないことが判明しました。実際にはハッチが静かにそれを「高」レベルへ圧縮してしまっていたのです。モデルはこの抽象化を修正しました。スコア自体は変わりませんが、下流の処理をすべて可能にする重要な不具合修正です（コミット d1bc440）。

Experiment 1: HTTP 429 エラーへの再試行対応。5 つのベースライン失敗が同じ原因によるものでした。OpenRouter が 429（レート制限超過）を返すと、Cline はただ諦めてしまうのです。セッション自体は健全なまま、単一のレート制限によって終了してしまっていました。当時、Kimi K3 を提供していたプロバイダーは一つだけで、キャパシティが逼迫していたためです。これは単純な修正作業で、再試行回数を増やし、指数バックオフ（exponential backoff）を実装するだけでした。診断用スライスでは、失われていた 5 つのケースすべてがパスに転換しました（コミット cabfa9e）。

実験 2：より賢いループ検出機能

Cline のループ検出機能が、実際には背景処理を継続的にポーリングしている正当なエージェントを誤って停止させたため、2 つのタスクが失敗しました。同じコマンドを実行しても出力が変化しており、これは実際の進捗を示すものであり、無限ループではありませんでした。そこでモデル側で検出器を出力状況に連動するよう改善したところ、両方のタスクが成功に転じました（コミット dbcdba8）。

実験 3：7.6 秒の「幽霊」失敗

あるタスクは 7.6 秒で終了し、トークン数もセッション情報も残っていませんでした。モデルはこの現象の原因を「@a スタイルのトークンを含むプロンプトが、参照されていない非同期ワーカーへのファイル参照ルックアップを引き起こし、プロセスがモデル呼び出し前に正常に終了した」という極めて具体的な事象として特定しました。この 1 行の修正（ライフサイクル保証）により、結果は確定的に改善されました（コミット 289cb82）。

実験 4：タスクの自殺防止

2 つのタスクが失敗したのは、エージェントが pkill -f を実行した際、そのパターンが自身のハッシュコマンドラインと一致してしまい、タスク実行中に自分自身を停止させてしまったためです。解決策は、広範なパターンマッチによる終了ではなく、PID（プロセス ID）を追跡するツールガイドへの修正でした。これにより両方のタスクが成功に転じました（コミット 23d5970）。

その後の全体実行結果：

統合候補の評価では 89 タスク中 77 件（86.5%）を達成し、コストは 65 ドルでした。これはベースラインから 8 タスク分向上した結果です。確認用ランでは 89 タスク中 79 件（88.8%）を達成し、コストは 49.8 ドルに抑えられました。つまり、失敗が確実なリトライや自己停止によるトークンの無駄遣いが減り、スコアも向上しながらコストも削減できたのです。

効果があったのは、リトライ機能の実装、出力を考慮したループ検出の導入、インデックスのライブネス（生鮮度）に関する修正、そしてスコア向上のためのプロセス強制終了処理です。これらすべての改善は汎用的なハッチング（実行環境）の強化であり、ベンチマーク固有のものや、報酬ハッキングに繋がるような偽物の対策ではありませんでした。

一方、効果が出なかったのは「最大推論時間」に関する修正です。これは因果関係による評価を得られませんでした。なぜなら、OpenRouter はすでに K3 がサポートしている唯一の推論設定にマッピングされていたためです。また、「pkill（プロセス強制終了）のガイダンス」は広範なマッチングコマンドを減らしましたが、完全に排除するには至りませんでした。

確認用の 2 回の試行では、オーケストレーターを誤って停止させたために無効化され、破棄されました。この事象は報告され、除外された上で再実行されています。その他にも、モデルのスコアが低いことが明確にモデル自体の限界によるものだと判明した実験はいくつかありました。

人間の介入はほぼゼロでした。キャンペーン全体は単一のプロンプトから約 17 時間連続で稼働しました。私たちの役割は主に、エージェントを数時間ごとに監視し、偶発的に停止した際に「続行」ボタンを押す程度のものでした。エージェントが永遠に動作し続けるよう、クラウド上の VM で実行しました。

報酬ハッキングは設計段階で回避しています。最初の結果が非常に良いため、直感的には報酬ハッキングを疑いましたが、実際にはそうではありませんでした。検証者の編集やタスク名の検出、タイムアウトの誇張といった手法は一切使われていません。プロンプトでもこれを明示的に禁止していました。

驚いたことに、プロンプトによるガードレールは機能しました。モデル自体が自己監視を行い、帰属に関する制限を記録し、無効化された実行結果を自身のスコアから除外するほどでした。最終的なバックストップは完全に人間が行うもので、マージ前にプルリクエスト全体を手動レビューしました。

コストとトレース

今回の実験では、トークン数は約 10 億、費用は 680 ドル程度でした。これはエンジニアが数週間を費やす時間や機会損失と比較すれば、まだ非常に安価です。そのため、特定のタスクにおいては、Kimi K3 などの最先端モデルに実際に投資することが決して無駄ではないと考えています。今回の実験では、GPT-5.6-Sol がトップの結果を出しました。Fable を使用できればよかったのですが、前述の通り、その安全フィルターが AI 評価研究の実施を繰り返しブロックしてしまいました。また、Fable を利用した場合、費用はさらに大幅に増える可能性も高いです。すべてのトレース、コード、そしてコストの内訳については、こちらの GitHub Gist で確認できます。

Kimi K3 を実行するには Cline が最適な環境です。Moonshot 公式の Kimi ハーネスで得られた SOTA（最良）スコアと同等の結果を Cline でも達成できました。ClinePass を利用すれば、サブスクライバー向けに推論コストが割引になります。月額 9.99 ドルで、Kimi K3、DeepSeek、GLM、MiniMax、Qwen など厳選されたオープンウェイトモデルを利用でき、標準的な API レート制限の 2〜5 倍の速度で利用可能です。個別のプロバイダーキーも不要です。ぜひお試しください。

今後の展開

再帰的自己改善（RSI）はもはやSFの域を出た実験ではなく、AI 評価のように複雑で時間のかかる作業を可能にする最先端モデルが登場したことを心から歓迎しています。現在、Cline では新モデルリリース時の標準プロセスとして、まず即座にベースラインを実行し、その後 RSI スタイルのプロンプトを用いて各モデルの性能を最大限引き出す運用を開始しました。皆様に、より長時間実行されるタスクを通じてモデルの限界に挑戦していただくよう推奨します。