Cline、1100万人のユーザーを大規模リファクタリングへ移行

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

今年に入り、私たちは Cline SDK を中心に基盤を再構築しました。これにより、エージェントの制御枠組み（harness）を拡張機能から分離し、共有かつモジュール化されたランタイムとして統合すると同時に、その制御枠組み自体も改善しています。モデルを取り巻く環境が、その動作にどれほど大きな影響を与えるかについては、特にオープンウェイトモデルにおいて、私たちは身をもって実感してきました。

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 製品面で恩恵を受けられます。

オープンウェイトモデルでの比較結果：

• Model：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 マニフェスト内で静的に宣言されます。具体的には、サイドバーやビュー、コマンド、キーバインド、設定スキーマ、そしてアクティベーションイベントなどが該当します。拡張機能はマニフェストを一つしか持てないため、私たちのビルドプロセスでは両方のバンドルから統合されたマニフェストを生成しています。

両方のバンドルで宣言されている貢献項目はそのまま通過し、片方のバンドルにしかないコマンドについては、ローダーが設定するコンテキストキーによって制御されます。また、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 がユーザーにガイダンスを求めるタイミングを示します。50/50 のコホートに近いグループで、各バージョンが1日分の本番トラフィックを受けた際の発生頻度は以下の通りです。

旧ハネスではタスクの 6.34% がミス制限に達しましたが、新ハネスでは 0.62% でした。エラーが発生するタスクが約10倍減少しました。

ただし、モデル別の内訳を見るとさらに興味深い結果となります。改善はオープンウェイトモデルに特に偏っています。

• Model：Old harness / New harness / Reduction
• claude-sonnet-5 (direct API)：6.7% / 0.63% / 11x
• deepseek-v4-flash (direct API)：13.4% / 1.30% / 10x
• deepseek-v4-pro：11.5% / 1.14% / 10x
• claude-sonnet-4-6：4.0% / 0.62% / 6x
• gpt-5.6-sol：4.1% / 0.70% / 6x

image方法論の注記：イベントの帰属分析は新エンジンに対してやや不利にバイアスがかかっているため、この数値は保守的な見積もりです。

旧ハネスから何が変わったのか

従来のハネス自体が悪いコードというわけではありません。それは時代の遺物です。異なる時代のために作られたものであり、この話は Cline の事例を超えて、急速に進化する AI 業界全体に通用する教訓になると考えています。

Cline のオリジナルのハネスは 2024 年半ばに Claude 3.5 Sonnet を中心に設計されました。当時としては最良のコーディングモデルでしたが、当時のモデルには手厚いサポートが必要でした。ツールはシステムプロンプトで説明し、モデルからのテキストストリームから XML タグを解析して呼び出す仕組みでした。2024 年のモデルから確実にツール使用を引き出すための確実な方法だったのです。ハネスは守りに入り、補填を行い、すべてを明示的に記述していました。

2026 年のモデルは、ネイティブでツールを呼び出すように強化学習（RL）で訓練されています。それを 2024 年風のハネスに包み込むと、各ステップごとにフォーマットの問題や解析失敗、再試行、そして最終的にはミス制限のリスクというコストが発生します。Cline のすべての表面を、パフォーマンスが最も高いオープンウェイトモデルを採用したアップグレード版ハネスに移行することは必須です。だからこそ、私たちはこの移行には慎重かつ細心の注意を払って取り組んだのです。

私たちの歩みはここで終わりません。オープンウェイトモデルのための最良のハーンとなることに常にコミットし、不断の反省と改善を続けていきます。また、ハーンがオープンウェイトモデルの最先端であり続けるよう、再帰的な自己改善についても深く研究を進めています。詳しくはこちらをご覧ください。

ご協力いただいたすべてのユーザーの皆様へ

不具合の報告にご協力いただいた方々、Google Meet にて一緒にワークフローや破損箇所を確認し、デバッグに付き合ってくださった方々、そしてスムーズなロールアウトのためにフィードバックを寄せてくださった方々：心より感謝申し上げます。Cline は素晴らしいコミュニティによって作られ、コミュニティのために存在するものです。皆様がいなければ、今の私たちはありません。

8 月 23 日現在、ロールアウトは 100% 完了しました。更新とリロードが行われるすべての Cline ウィンドウで SDK エクステンションが実行されており、残りのレガシーセッションもマシンが更新されるにつれて順次解消されています。エクステンションは CLI や SDK と同じエンジン上で動作するようになりました。これにより、エージェントの改善や新ツールの追加、新しいプロバイダーおよびモデル機能の提供がこれまで以上に迅速に行われ、不具合の修正も以前より速くできるようになりました。今回の移行に伴い、一部のあまり使われていない機能が廃止されました（詳細はこちら）。しかし、このアップデートは、現在のモデルに対応したハーンへと Cline を再構築するにあたっての苦闘の末に得られた大きな成功であり、トークン効率の向上、コスト削減、そしてより良い結果を実感していただけることを楽しみにしています。これからも私たちは、継続的な改善の旅を皆様と共に歩んでいきます。