Cline、1100万人のユーザーを最大のハーンアップグレードへ移行

Cline 拡張機能は、Claude 3.5 Sonnet のリリース直後の 2024 年に開発が開始されました。この拡張機能は、数百万人の開発者が利用する初期の「エージェント型コーディング体験」の一つを生み出しましたが、その後のモデルや、それらがエージェント・ハネス内で動作する仕組みは大きく変化しています。また、IDE の周辺で拡張機能が成長を続けるにつれ、基盤となるハネスの進化が次第に困難になっていました。

今年に入り、私たちは Cline SDK を中心に Cline の基盤を再構築しました。これによりエージェント・ハネスを拡張機能から分離し、共有型のモジュラーランタイムへと移行させると同時に、ハネス自体も改善を進めています。モデルを取り巻くハネスがその動作に与える影響の大きさは、特にオープンウェイトモデルにおいて顕著であり、私たちはその実感を強く持っています。

https://x.com/cline/status/2069171146994729078

私たちは、この新しいハネスを 1,100 万人以上の開発者が利用する主力 VS Code エクステンションに導入することを待ちきれませんでした。しかし、このような移行は決して簡単な作業ではありません。

最初の試行には数ヶ月の工数がかかり、ようやくリリースした際には重大な不具合が発生し、即座にロールバックを余儀なくされました。これにより、移行そのものだけでなく、数百万人の開発者が日常的に依存するワークフローを妨げずに、いかにして大規模な変更を安全に提供するかという根本的な再考を迫られました。また、VS Code Marketplace には、このようなリリース段階的に展開する機能も用意されていませんでした。

その後、私たちは拡張機能の創設以来最大のリファクタリングを行い、本番環境へ安全に導入するためのプロセスを一から構築することになりました。

その具体的な手法について解説します。

なぜ Cline SDK への移行を決断したのか

この移行はビジネスにとって大きな投資であり、適切に行われなければユーザーに機能低下や不快感をもたらすリスクを伴うものでした。急速に進化する AI コーディングの分野において、時間をかけて慎重に取り組むという判断は、決して安易なものではありませんでした。

Cline は当初 VS Code 拡張機能として始まりました。その後、JetBrains プラグイン、CLI、そして SDK と進化を遂げました。これらの各プラットフォームで必要とされるのはすべて同じものです。エージェントループ、ツール実行、プロバイダー統合、コンテキスト管理、そしてエージェントハーンとしてのあらゆる機能を備えた基盤です。

Cline SDK を活用して新製品の機能を次々と開発する一方で、最も古くかつ利用頻度の高い VS Code 拡張機能は、独自の実装に依存したままでした。そこには約 76,000 行の巨大なモノリシックコアが存在し、エージェントの改善やプロバイダーの追加、新モデルの導入など、あらゆる変更に対して手作業での対応と新たなリリースが必要となっていました。

image今回の移行により、このモノリシックコアは SDK に置き換えられます。これにより、毎月のように登場する新モデルや機能に対応するために従来必要だった手作業の多くが自動化されます。私たちは、競合環境と同じスピードで進化するコードベースを必要としていました。

image新しい Cline SDK は、特にオープンウェイトモデルにおいてパフォーマンスが大幅に向上しています。Cline SDK の紹介記事より抜粋します。

ベストインクラスのエージェントハーンス。Cline 2.0 ではハーンスの強化に注力しました。プロンプトの再設計、ループの簡素化、コンテキスト管理の強化、フィードバックループとエラーハンドリングの改善、そしてモデルへのツール定義と提示方法の見直しを行いました。これらの成果は、アプリ内ではなくランタイムで実装されているため、Cline のすべての機能に共通して適用されます。

オープンウェイトモデルにおける比較結果：

• モデル：Cline / Hermes / OpenCode
• DeepSeek V4 Flash：60.67% / 57.3% / 52.8%
• GLM 5.3 Flash：64.0% / 56.2% / 61.8%
• Kimi K3：82.02% / 71.9% / 76.4%
• DeepSeek V4 Pro：59.6% / 56.2% / 55.1%

注：Cline CLI のスコアは pass@1 です。N/A は、tbench.ai（Terminal-Bench 2.0）でそのエージェントとモデルの組み合わせに公開された実行結果がないことを意味します。

幸いなことに、旧バージョンの拡張機能は gRPC をベースにしていました。これはコアと GUI（React Webview）の間で通信するメッセージングシステムであり、共有プロトコルを使用しています。これらのコンポーネントは、SDK ベースの新バージョンでも容易に再利用可能です。ユーザーが筋肉記憶として慣れ親しんだ UI は、Cline SDK のセッションイベントを Webview が常に受け取ってきたメッセージタイプに変換する翻訳レイヤーを通じて、シームレスに引き継がれました。

VS Code マーケットプレイスの制限事項

マーケットプレイスには、リリースを管理するレバーがたった一つしかありません。それは「公開」です。一度公開すれば、100% のユーザーが即座にそのバージョンを取得します。

また、以前のバージョンに戻すこともできません。バージョン番号は厳密に単調増加であり、どんなことがあっても番号を進めることしか許されません。もしリリースに問題が発生した場合の唯一のリカバリー手段は、より新しいバージョンを準備して、すべてのユーザーが更新されるのを待つことです。このプロセスには数時間から数日がかかり、数分単位で済むものではありません。

さらに、他のソフトウェア分野では標準的な「段階的ロールアウト」も、VS Code 拡張機能ではネイティブにはサポートされていません。新しいバージョンを公開すれば、全員に即座に配布されます。段階的な展開も、テストグループの設置も、即時の巻き戻しもできません。

アハ体験：もし一つの拡張機能の中に二つの機能をバンドルしたらどうなるか？

この制限を回避するため、1 つのリリースに旧バージョンと新バージョンの 2 つのエクステンションをバンドルしました。実質的にエクステンション自体が展開メカニズムとなっています。Cline をインストールすると、実際には以下の 3 つの要素がセットされます。

• 約 46 KB のローダースクリプト
• legacy/：移行前のオリジナル拡張機能
• next/：新しい SDK ベースの拡張機能

ウィンドウ起動時に、ローダーはキャッシュされた状態に基づいてどちらのバンドルをアクティブにするか決定します。これは PostHog の機能フラグによるパーセンテージ展開によって制御されています。仕組みは以下の通りです。

機能フラグがオフになっているユーザーには旧拡張機能が実行され、オンになっているユーザーには移行済みの拡張機能が実行されます。旧バージョンのコホートには移行前のコードがそのまま適用されるため、本番環境における既存ユーザーの体験に変化や不具合は一切発生しません。これが対照群（コントロールグループ）であり、フラグをオンにした状態で展開割合を徐々に上げていきます。

もし新拡張機能でクラッシュが発生した場合、自動的にフォールバックします。next がアクティブ化中に失敗すると、ローダーは同じウィンドウ内で legacy を起動し、そのマシンを強制的に旧バージョンに固定します。ユーザーには動作する製品が提供されながら、クラッシュ情報はテレメトリーとして収集されます。

このフラグがキルスイッチの役割を果たします。何か問題が発生した場合は、展開割合を 0% に下げることで即座に対応できます。

状態は共有されています。両方のバンドルは同じ設定、認証情報、タスクストレージを読み書きするため、コホート間を移動してもデータは完全に引き継がれます。

フラグの更新はアクティブ化後にバックグラウンドで行われ、次のウィンドウ起動時に反映されます。ユーザーが作業中にエージェントの基盤が突然切り替わるようなことはありません。

最も重要なのは、レガシー版と次世代版が VS Code API と互換性を持つために、同じビューと拡張ライフサイクルのエントリーポイントを公開しなければならない点です。そうでなければパッケージはビルドされません。

VS Code 拡張機能の IDE 統合の多くは、package.json マニフェスト内で静的に宣言されます。これにはサイドバーやビュー、コマンド、キーバインド、設定スキーマ、そしてアクティベーションイベントが含まれます。1 つの拡張機能につき 1 つのマニフェストしか存在しないため、私たちのビルドプロセスでは両方のバンドルから統合されたマニフェストを生成します。

両方のバンドルで宣言されている貢献項目はそのまま通過し、片方のバンドルにのみ存在するコマンドは、ローダーが設定するコンテキストキーによって制御されます。また、2 つのブランチ間でビューや設定スキーマが分岐した場合、ビルドは強制的に失敗します。このビルド時の契約こそが、同じ package.json の背後で両方のコードベースが存在している間も、リロード時に互いに交換可能であることを保証するものです。

A/B テストとデータ、そしてデータ、さらにデータ

安全なリリースは課題の半分を占めるに過ぎず、新しいエンジンの方が優れていることを証明することが残りの半分です。ロールアウトビルドから送信されるすべてのテレメトリイベントには、extension_variant: next | legacy というフラグが含まれています。

古い拡張機能と新しい拡張機能からキャプチャされたテレメトリイベントを比較可能にするために、私たちは膨大な時間を費やしました。これには、既存のハネスに多数のイベントを追加し、メトリクス観測機能を強化することも含まれます。

このような移行プロジェクトを行う方々へのおすすめとして挙げたいのは、新しいシステムと比較する前に、まず古いシステムに計装（インストルメンテーション）を施しておくことです。

その取り組みの一環として、新旧のハーン（harness）間で最も重要なイベントを監視するための厳密なサイドバイサイドダッシュボードを整備しました。

例えば、最も重視すべき指標は「task.mistake_limit_reached」です。これは旧ハーンの遺産とも言うべきメトリクスで、エージェントが連続して 3 つのミスを犯すと動作を停止し、人間にガイダンスを求める仕組みに対応しています。この行動は旧ハーンにおいて最も苦情の多かった部分でしたが、その多くはハーン自体の非効率性に起因するツール呼び出しの失敗でした。新しい SDK ハーンではこのメトリクスを追跡していましたが、旧拡張機能では対応していませんでした。そこで、同じ意味を持つ形で旧ハーンにもこの指標を追加したことで、両者の挙動をクリーンに比較できるようになりました。

確かなシグナルを得るために、私たちは約 1 ヶ月かけて、新しいバージョンのユーザー割合を徐々に引き上げながら監視を行いました。ダッシュボード上の定量的な数値と、GitHub 上の定性的なフィードバックの両方を注視しながらです。1 週間以上は 50/50 の分割比率を維持し、これが最もクリーンな A/B テストの期間となりました。その後、割合を 100% に引き上げました。

観測値がフラグ値より遅れるのは意図的な設計です。更新直後の最初のウィンドウでは必ず旧バージョンが動作し、新バージョンへの移行は2回目のリロード時に完了します。この仕組みの「遅れ」こそが安全性を担保しています。同様の理由で、100% 切り替え後もわずかな残存シェアが見られるのは、まだ更新やリロードが行われていないマシンが存在するためです。これらのマシンは毎日少しずつ旧バージョンから移行されていきます。

改善の結果を示す最も明確な指標は「task.mistake_limit_reached」です。これはモデルが連続して3回ミスを犯した頻度（不正なツール呼び出し、編集失敗、何の進展もない回答など）を計測するもので、Cline がユーザーにガイダンスを求めるトリガーとなります。新旧バージョンそれぞれが1日分の本番トラフィックを処理した際の、ほぼ半々で分かれたコホートにおける発生頻度は以下の通りです。

旧ハネスではタスクの 6.34% でミス制限に達しましたが、新ハネスでは 0.62% に低下。エラーが発生するタスクが約10分の1になりました。

• モデル：旧ハネス / 新ハネス / 削減率
• claude-sonnet-5 (direct API)：6.7% / 0.63% / 11倍
• deepseek-v4-flash (direct API)：13.4% / 1.30% / 10倍
• deepseek-v4-pro：11.5% / 1.14% / 10倍
• claude-sonnet-4-6：4.0% / 0.62% / 6倍
• gpt-5.6-sol：4.1% / 0.70% / 6倍

方法論の注記：イベントの帰属分析は新しいエンジンに対してやや不利に働くため、本記事で示す数値は保守的な見積もりです。旧ハーンから改善された点は以下の通りです。

レガシーなハルネス自体は悪いコードではありません。それは時代遅れの遺物です。異なる時代の、2024 年当時の Claude 3.5 Sonnet を想定して設計されたものでした。当時、そのモデルはツール使用のために実質的な支援を必要としていました。システムプロンプトでツールが説明され、モデルのテキストストリームから解析される XML タグを通じて呼び出されていました。これは、2024 年のモデルから確実にツールを使用させるための信頼できる方法だったからです。ハルネスは守り、補い、すべてを明確に記述していました。

しかし、2026 年のモデルはネイティブでツールを呼び出すように強化学習（RL）で訓練されています。それを 2024 年風のハルネスで包み込むと、すべてのターンでフォーマットの問題や解析失敗、リトライ、最終的にはエラー制限に達するコストが発生します。Cline の全機能を、現在最もパフォーマンスの高いオープンウェイトモデルに対応したアップグレード版ハルネスへ移行することは必須です。だからこそ、私たちはこの移行を慎重かつ細心の注意を払って進めました。

私たちの取り組みはここで終わりません。オープンウェイトモデルのための最良のハルネスを提供し続けることに常にコミットしており、継続的な検証と改善を繰り返しています。また、ハルネスが常にオープンウェイトモデルの最先端であり続けるよう、再帰的自律進化に関する研究にも深く取り組んでいます。詳しくは こちらをご覧ください。

ありがとうございました

Issue の報告や Google Meet でのワークフロー共有、不具合のデバッグ、そしてスムーズな展開のためのフィードバックを提供してくださったすべてのユーザーの皆様へ。心より感謝申し上げます。Cline は素晴らしいコミュニティのために作られ、コミュニティによって支えられています。皆様がいなければ、現在の Cline も存在しなかったでしょう。

8 月 23 日現在、移行は 100% 完了しました。更新とリロードが行われるすべての Cline ウィンドウが SDK エクステンションを実行しており、残りのレガシーセッションもマシン更新に伴い順次終了しています。エクステンションは CLI や SDK と同じエンジン上で動作するようになりました。これにより、エージェントの改善や新ツールの追加、新しいプロバイダーおよびモデル機能の実装がこれまで以上に迅速に行われ、すべての製品でバグ修正も速やかに行える体制となりました。

移行に伴い、一部のあまり使われていない機能は廃止されました（詳細はこちら）。しかし、今回のアップデートは、現在のモデルに対応した基盤へと Cline を再構築するにあたり、苦しい戦いの末に成し遂げた大きな成功です。トークン効率の向上、コスト削減、そしてより良い結果を実感していただけることを楽しみにしています。これからも継続的な改善の旅を皆様と共に歩んでいきます。