Twinny と Continue：何が変わったか、今どちらを使うべきか

TwinnyとContinueは、もはや同じ仕事を競っていません。Continueは現在も動作する完成済みソフトウェアであり、Twinnyは現在もリリースが続く、より範囲を絞ったツールです。 continue.dev自身のページタイトルは「Continue (acquired by Cursor)」で、READMEはリポジトリが現在積極的に保守されておらず読み取り専用だと説明しています。一方、Twinnyは2026年9月18日の1日だけでバージョン4.1.1、4.1.2、4.1.3をリリースしました。ただし、Twinnyには意図的にエージェントモードもMCPツールもないため、Continueが担っていた機能の一部は置き換えられますが、すべてではありません。

まず名称が混同されやすいため、区別しておきます。Twinnyという名称で、無関係な2社が事業を展開しています。1社は twinny.es のスペインのエンタープライズ自動化プラットフォーム、もう1社は twinny.ai の韓国のロボティクス企業で、2026-09-19に確認した時点でいずれも稼働中でした。どちらの価格や資金調達情報も、このページに載せる対象ではありません。ここで扱う製品は twinny.dev の VS Code 拡張機能で、twinnydotdev/twinny リポジトリの rjmacarthy.twinny として公開され、twinny-docs でドキュメント化されています。

Continueで実際に起きたこと

要点だけ言えば、製品は終了しましたが、コードは終了していません。Continueの README には明確に、「リポジトリは『現在積極的に保守されておらず、すべてのユーザーに対して読み取り専用』」と記載されています。ホームページのメタディスクリプションは「Continue has been acquired by Cursor.」という一文です。ただし、読み取り専用はアーカイブ済みを意味しません。多くの解説が取り違えているのは、この違いです。

すべての項目を2026-09-19に確認しました。計画を立てる前に、特に強調すべき点が2つあります。第一に、READMEでは最終版2.0.0がVS Code拡張機能、CLI、JetBrainsプラグインを対象としていたとされていますが、公開済みアーティファクトのうち2つはこれと一致しません。CLIは1.5.47を超えておらず、JetBrainsプラグインも1.0.67を超えていません。これを説明する一次情報はないため、このガイドでは理由を説明せず、その食い違いを報告します。第二に、ハブより長く存続しているドキュメントサイトは、現在も解決できないホストからモデルやルールを取得する uses: <owner>/<slug> 構文を docs.continue.dev が教え続けているという、実運用上の落とし穴です。明示的な provider、apiBase、apiKey エントリを持つ完全ローカルの config.yaml だけが、現在、解決されることを保証された構成です。

どの製品を誰が選ぶべきか

Continueで実際に使っていたのがオートコンプリート、コードについてのチャット、インライン編集、レビュー、コミットメッセージで、現在も誰かが手を入れているコードベースを求めているなら、Twinnyを選んでください。リポジトリ はMITライセンスで、アーカイブされていません。2026-09-19時点の最新コミットは、2026-09-18付けの4.1.1から4.1.3までのバージョン更新でした。特に、自分のハードウェア上でモデルを実行する場合に適しています。Twinnyはローカルサーバーを設計の中心としており、fill-in-the-middle方式のオートコンプリートは1.5Bから7Bのベースモデルで良好に動作します。

Twinnyにない機能に依存しているなら、Continueを選んでください。より正確には、使い続けてください。最も明確な例はエージェントモードとMCPツールサーバーです。Continueの MCPドキュメント には、MCPは「エージェントモードでのみ使用できる」とあるため、両者の利用可否は連動しています。もう1つはCLIとJetBrainsプラグインです。TwinnyにはVisual Studio Code 1.93以降、またはVSCodiumなどの互換ビルドが必要で、コマンドラインクライアントもJetBrains版もありません。固定されたContinueのインストールは動作し続けますが、改善されることはありません。

実行モデルこそが本当の分岐点です。これは、リリースで埋められる機能差ではありません。Twinnyの FAQ は「twinnyは私のファイルを自分で編集するエージェントを実行しますか？」という質問に、「いいえ。すべての変更は、あなたが依頼し、保持する前に確認できるものです。承認する提案、承認する差分、確認するコマンドです。これは設計上のものです」と答えています。Continueを使って複数段階のタスクを委任し、結果をレビューしていたなら、Twinnyは初日から明確なダウングレードです。Continueをチャットと編集モードで使い、エージェントモードに不安を感じていたなら、Twinnyは望まなかった部分を除いた同じワークフローです。

移行コストは低いものの、ゼロではありません。 Continueはすべてのモデルをrolesリスト付きの1つのYAMLファイルに置きます。一方、Twinnyには設定ファイルがなく、サイドバーでプロバイダーを1ジョブずつ構築するため、3つのロールを持つ1つのContinueエントリは、Twinnyでは最大3つのプロバイダーになります。TwinnyはContinueの設定を読み込みません。書き換えに約1時間を見込み、さらにワークスペースのインデックスを再構築してください。異なる埋め込みモデルのベクトルは混在できないため、埋め込みモデルを変更すると再インデックスが必要です。

コストについては、両方のクライアントが無料で、どちらも費用がかかる部分ではありません。 Continueには価格がまったくありません。continue.devには価格ページがもうなく、ソフトウェアについてFAQが述べているのは、Apache-2.0のソースとドキュメントがGitHubに残っていることだけです。Twinnyの拡張機能はMITライセンスで無料ですが、金額が登場するのはチームゲートウェイであり、この2つを混同しやすくなっています。

機能とライセンスの比較

2026-09-19に、2つの Marketplace 掲載、リポジトリ、各プロジェクトのドキュメントから読み取りました。インストール数は日々変動し、現在の利用状況ではなく履歴を示します。Continueは保守された製品として3年間にわたり数を積み上げました。また、TwinnyのMarketplaceの一行説明（「vscode向けのローカルホスト型AIコード補完プラグイン」）とGitHubの説明は、現在 twinny.dev がチームゲートウェイを前面に出している位置付けより古いものです。Twinnyのピアツーピア「Symmetry」ネットワークを説明する古い記事は、削除済み機能を扱っています。FAQによれば、Symmetryは削除されてDevicesに置き換えられました。Devicesは自分のマシン同士だけを接続します。

それぞれの料金

Twinnyのプラン価格は2026-09-19に ライセンスとシートのページ から読み取りました。Continueについてはcontinue.dev自体の情報です。正直に述べるべき注意点が2つあります。シートとは個人ではなくアクティブなアクセスキーであり、キーを失効させるとシートは直ちに解放されます。また、これは公開価格であり、このガイドでチェックアウトを通した価格ではありません。サイトにはライセンス発行者としてrjmacarthy.xyzが記載されていますが、その背後の販売主体は調査していません。Twinnyのホームページ比較では、ホスト型アシスタントのシート単価として「通常$19–39」とも記載されていますが、これはマーケティング上の数字であり、ここで検証した数字ではありません。

OpenAI互換ゲートウェイで、いずれかのクライアントが到達できるもの

ここで、機能表には現れない形で、2つのツールは互換的に使えなくなります。どちらも作業をジョブに分割しますが、チャット補完ゲートウェイと通信できるジョブは一部だけです。

チャットは理論上適合します。 Twinnyの プロバイダー概要 によれば、チャットのAPIパスはベースであり、Twinnyが /chat/completions を付加します。そのため、api.kunavo.com に対するAPIパス /v1 はKunavo独自のルートと一致します。問題はどのプリセットを選ぶかです。Twinnyの ホスト型APIページ には、ホスト型APIを使うチャットは「ベンダーのSDK経由で固定エンドポイントに送られるため、ホスト名、ポート、パスのフィールドは非表示」とあります。OpenAIおよびAnthropicのプリセットはキーを要求しますが、そのキーは自分で選んだアドレスではなく各ベンダーに送信されます。したがって、ゲートウェイキーをこれらに設定してはいけません。アドレス欄が表示されるのはローカルサーバーのプリセットであり、汎用の「OpenAI-compatible server」プリセットが、Twinnyに専用プリセットのないサーバー向けです。https://api.kunavo.com/v1 をHostnameに貼り付けると、フォームがプロトコル、ホスト、ポート、パスに分割します。キーは Authorization: Bearer ヘッダーとして送信されます。

オートコンプリートが適合しない理由は、独立して2つあります。 Twinnyの 汎用プリセット は /v1/completions 形式のルートで補完を実行しますが、Kunavoにはそのようなルートがありません。APIには従来型のテキスト補完エンドポイントがなく、/v1/chat/completions とその他のチャット形式のサーフェスだけがあります。別の理由として、Twinnyの 対応モデルページ は、カーソルの前後にある内容の間を補完できるのはfill-in-the-middleトークンで学習したモデルだけであり、instructモデルは「補完する代わりに、おしゃべりしたり説明したりする傾向がある」と明記しています。Kunavoのカタログはinstructおよびチャットモデルで、fill-in-the-middleベースモデルは1つもありません。どちらか一方だけでも結論は出ます。Continue独自の オートコンプリートガイド も、Twinnyの用語を使わずに同じ方向を示しています。このロールにはCodestralとQwen2.5-Coderの1.5Bおよび7Bを推奨し、thinking系モデルは適していないと警告しています。オートコンプリートは小型のローカルモデルから提供してください。これは両プロジェクトがいずれにせよ推奨している構成です。

Kunavoは埋め込みを一切提供していません。 カタログ内のモデルに埋め込みエンドポイントを持つものはないため、/v1/embeddings はモデルを解決した後、リクエストを拒否します。Twinnyの埋め込みプロバイダー、またはContinueの embed ロールは、ローカルサーバーか外部の埋め込みプロバイダーに向けてください。Twinnyのドキュメントでは、この用途に nomic-embed-text を推奨しています。

name: My Config
version: 0.0.1
schema: v1
models:
  - name: Claude Sonnet 4.6
    provider: openai          # the protocol, not the vendor
    model: claude-sonnet-4-6
    apiBase: https://api.kunavo.com/v1
    apiKey: <your Kunavo key>
    roles: [chat, edit, apply, summarize]
    capabilities: [tool_use]  # only if agent mode stays unavailable

この部分について2点あります。provider: openai はベンダーではなくワイヤプロトコルを示すため、/v1/chat/completions を実装するあらゆるエンドポイントに適用できます。そして capabilities の行が、分かりにくい唯一の部分です。Continueの capabilitiesドキュメント には、プロバイダーとモデル名から tool_use を検出し、「自動検出を上書きすることはできず、capabilitiesを追加することだけができる」とあります。Continueの表が認識しないIDを提供するゲートウェイにはtool_useが付与されず、capabilitiesページでは、これによってエージェントモードが利用できなくなると説明されています。この行を追加すると有効になり、無効に戻すものはありません。また、Kunavo独自の Continue設定ページ には、autocomplete ロールでチャットモデルを使う2つ目のエントリもあります。この構成は記録上、誰もランタイムテストしていません。また、Continue独自のオートコンプリートガイドがこのロール向けに挙げているモデルはチャットモデルではなくコード補完モデルです。このセクションで説明する注意をもって扱い、検証済みのレシピとは考えないでください。

チャット形式の作業におけるトークン見積もり例

オートコンプリートはゲートウェイに到達できないため、Kunavoに対してどちらのクライアントを使っても、トークン請求の対象はチャットトラフィックだけです。チャット回答、インライン編集、コードレビュー、コミットメッセージが該当します。そのため、補完中心のアシスタントより計算は小さくなります。モデルを選ぶ前に規模を確認する価値があります。1日の作業を 12回のチャットまたは編集ターン とし、各ターンの平均を キャッシュされていない入力トークン18,000個と出力トークン1,200個 と仮定します。合計では入力216,000トークン、出力14,400トークンです。これらは例示的な仮定なので、予算作成前に自分の数値へ置き換えてください。料金は、100万トークンあたりの Kunavoカタログ の現在の価格です。

これらはトークン数に基づく計算例であり、実測したタスク費用でも、請求額の上限でもありません。掲載されている料金が最も安いことと、タスクを完了するための費用が最も低いことは、別の主張です。レビューで2回目の試行が必要になるモデルは、1回目で期待どおりの結果を出す、より高単価のモデルよりも費用がかかる場合があります。Kunavoのカタログ記載額は、請求額の上限ではなく下限です。上流プロバイダーが料金を報告した場合、請求額は、カタログ料金と、上流プロバイダーの料金に適用されるマークアップを乗じた額のうち、いずれか高い方になります。キャッシュ料金と、ローカルで実行する処理の費用は、この例には含まれません。最低チャージ額は前払いクレジットで$10です。これは入金額の最低額であり、タスク料金やサブスクリプションではありません。請求の詳細をご覧ください。

設定方法

KunavoはContinue向けのセットアップガイドを公開していますが、Twinny向けのものはありません。また、公開された設定リファレンスは互換性テストではありません。どちらのクライアントも、このエンドポイントに対してランタイムテストされていません。片方を試す間は動作するルートを開いたままにし、単一の制限付きタスクを実行してから、アカウントに記録された請求額を確認してください。Continueでは、まず Continue統合ガイド を開き、上記の注意事項と併せて読んでください。Twinnyでは、ここで説明した汎用OpenAI互換プロバイダーと、Twinny独自の Test provider ボタンを使用してください。このボタンはそのプロバイダーのジョブに対して小さなリクエストを送信し、成功またはサーバーのエラーと呼び出したURLを表示します。誤ったパスと誤ったキーを見分ける最短の方法です。キーへの入金準備ができたら、Kunavoアカウントを作成してください。

さらに比較しますか？OpenAI互換APIではプロトコルが扱うものと扱わないものを説明し、ClineとClaude Codeの比較ではContinueのエージェントモードを手放せない場合に2つのエージェントを比較しています。

よくある質問

2026-09-19に直接取得して確認しました。両方のGitHubリポジトリAPIとコミット一覧、2つのVS Code Marketplace掲載、@continuedev/cliおよびtwinny-serverのnpmエントリ、JetBrainsプラグイン掲載、continue.devとそのREADME、hub.continue.devのDNSルックアップ、docs.continue.devのOpenAIプロバイダー、機能、MCPのページ、Twinnyの概要、プロバイダー、ホスト型API、対応モデル、ライセンス、FAQのページです。確認していないものは、どちらのクライアントからKunavoへのランタイムリクエストも、Twinnyのチェックアウトも含みます。Kunavoのトークン料金は現在のカタログから取得し、ここでのドルの例はすべて例示的なトークン計算です。