Claude Media
Claude CodeとContinueの違い — cn CLIとIDE拡張の使い分け

Claude CodeとContinueの違い — cn CLIとIDE拡張の使い分け

ContinueはIDE拡張とCLI(cn)の2面を持つオープンソースのAIコーディング支援です。Claude Codeとモデル選択、設定ファイルの置き場所、承認の仕組み、ヘッドレス実行を並べます。

Continueは、VS CodeとJetBrains向けのIDE拡張に、ターミナル用のcnコマンドを加えたオープンソースのAIコーディング支援です。Claude CodeはAnthropicのコーディングエージェントで、ターミナルのCLIが本体、VS Code拡張はそのCLIを同梱した画面です。

どちらもIDEとターミナルの両方から使えます。違いが出るのは、どのモデルを載せられるか、設定をどこに置くか、承認をどう扱うかの3点です。

2つのツールの出発点はどこが違うか

ContinueのドキュメントはIDE拡張を軸に書かれています。主な機能として挙がるのは、Agent・Chat・Edit・Autocompleteの4つと、ターミナル向けのContinue CLI(cn)です。cnは、IDE拡張を動かしているのと同じエージェントをターミナルで動かすものです。

Claude Codeの側は、VS Code拡張の説明文にインラインdiff、@メンション、プランレビュー、キーボードショートカットが並びます。拡張は独自のCLIコピーを同梱しており、統合ターミナルでclaudeを使うには単体のCLIインストールも要ります。

観点ContinueClaude Code
提供される面ContinueVS Code / JetBrains拡張、cn CLIClaude CodeCLI、VS Code拡張ほか
モデルの選び方Continue複数のプロバイダーから選ぶClaude CodeClaudeモデルを選ぶ
設定の主ファイルContinue~/.continue/config.yamlClaude Code~/.claude/settings.json
承認の記憶先Continue~/.continue/permissions.yamlClaude Codesettings.jsonの許可ルール
単発実行Continuecn -p "..."Claude Codeclaude -p "..."

モデルの選択肢はどこまで違うか

最も差が出るのはここです。

Continueのモデル紹介ページは、Anthropic・OpenAI・Gemini・Ollama・Amazon Bedrock・Azure・xAIなど多数のプロバイダーに対応しています。設定例にはClaude Sonnet 4.6のほか、Qwen Coder 3、GPT-5、Kimi K2、Gemini 3.1 Pro、Grok Code Fast 1、Devstral Medium、gpt-oss-120bが載っています。モデルには役割(ロール)があり、チャット用とオートコンプリート用で別のモデルを割り当てられます。

Claude Codeが載せるのはClaudeモデルです。--modelにはsonnet・opus・haiku・fableといったエイリアスか、モデルの完全名を渡します。接続先はAnthropic APIに加え、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundryなどから選べます。

ANTHROPIC_BASE_URLで接続先を変えても、答えるモデルは変わりません。モデル設定のドキュメントでは、これは「リクエストの送り先を変えるもので、どのモデルが答えるかを変えるものではない」設定です。LLMゲートウェイ経由の運用でも、Claude以外のモデルへのルーティングはサポート対象外です。

設定ファイルはどこに置くか

Continueの設定は~/.continue/config.yamlです(Windowsは%USERPROFILE%\.continue\config.yaml)。cnが読むのも同じファイルで、フォーマットはIDE拡張と共通です。つまり、拡張で整えたモデル設定をCLIでもそのまま使えます。

起動時に別の設定を指す方法は2つあります。

# ローカルのYAMLを指定して起動
cn --config ./my-config.yaml
 
# ルールを起動時に足す(ファイルパスでも文字列でも可)
cn --rule ./rules/style.md
cn --rule "Always use TypeScript strict mode"

TUIセッションの中では/configで設定を切り替えられ、選んだ設定は次回以降も保存されます。IDE拡張側のワークスペース設定には.continuerc.jsonもありますが、ドキュメントでは「Legacy Configuration Methods (Deprecated)」の節に載っています。APIキーなどの秘密値は環境変数に置き、設定ファイルからは${{ secrets.MY_API_KEY }}の形で参照します。

Claude Codeの設定は、置き場所で効く範囲が決まります。

ファイル効く範囲
~/.claude/settings.json効く範囲自分の全プロジェクト
.claude/settings.json効く範囲そのリポジトリの全員(コミットして共有)
.claude/settings.local.json効く範囲自分だけ(個人の例外)

チームで共有するルールはリポジトリにコミットし、個人の上書きはlocalに分ける、という使い分けが設定の置き場所で表現されます。プロジェクトへの指示はCLAUDE.mdに書きます。CLAUDE.mdの代わりにリポジトリのAGENTS.mdを読ませることもできます。

Continueは「ユーザーのホームに1つの設定」を基本にし、起動時のフラグでルールやエージェントを足す設計です。Claude Codeは、ユーザー・プロジェクト・個人上書きの3層に分ける設計です。チームで設定をリポジトリごと配りたい場合に、この差が効いてきます。

承認と権限の仕組みはどう違うか

どちらも、ファイルの書き込みやコマンド実行の前に承認を求めます。Continue CLIでは読み取り専用のツール(Read・List・Search・Fetch・Diffなど)は自動で通り、書き込み系はTUIで承認を求められます。選択肢は3つです。

  • Continue: この呼び出しだけ承認
  • Continue + don't ask again: 承認してポリシーを保存
  • No: 拒否して、エージェントに別の指示を出す

「今後は聞かない」を選ぶと、~/.continue/permissions.yamlに規則が追記されます。

# ~/.continue/permissions.yaml
allow:
  - Read(*)
  - Write(**/*.ts)
ask:
  - Bash
exclude: []

優先順位は、モード(--auto・--readonly)、CLIフラグ、permissions.yaml、既定値の順です。ここに落とし穴があります。--autoと--readonlyは絶対的な上書きで、--allow・--exclude・permissions.yamlをすべて無視します。たとえば--readonlyで起動して--allow Writeを足しても、書き込みは許可されません。

Claude Codeは、許可・確認・拒否のルールをsettings.jsonに書きます。モードは--permission-modeでdefault・acceptEdits・plan・auto・dontAsk・bypassPermissionsから選び、セッション中はShift+Tabで切り替えます。

Continueの承認は「聞かれたときに保存する」流れで、規則はpermissions.yamlに溜まります。Claude Codeでも「今後は聞かない」を選ぶと.claude/settings.local.jsonに書かれますが、チームで共有する規則は.claude/settings.jsonにコミットできます。この差は、承認の運用をチームで統一したいかどうかで効いてきます。

IDE拡張が自動編集をどこまで許すかは、Claude CodeのIDE拡張が許す自動編集の範囲で扱っています。

プランモードと再開はどう揃うか

調査だけをさせて書き込みはさせない用途には、両者とも専用の入口があります。

  • Continue CLI: cn --readonlyが計画(プラン)モードです。書き込み系ツールは除外され、読み取りとBashは使えます
  • Claude Code: claude --permission-mode plan、またはセッション中のShift+Tabの巡回で入ります

Continueの計画モードは「書き込みツールを外し、読み取りとBashを許す」と定義されています。Bashが使える点は、読み取り専用を期待する場面では頭に入れておく必要があります。

セッションの再開も似た形です。

# Continue CLI: 直近のセッションを再開
cn --resume
 
# Claude Code: 現在のディレクトリの直近の会話を読み込む
claude --continue

Claude Codeでは--continueが「直近の会話」、--resumeが「IDや名前、またはピッカーで選ぶ会話」です。Continueの--resumeは直近のセッションを再開するフラグで、名前の対応が揃っていません。スクリプトに書くときは、フラグ名だけで読み替えないほうが安全です。

ヘッドレス実行はどう書き分けるか

CIやGit hookに組み込む単発実行は、Continueがcn -p、Claude Codeがclaude -pです。標準入力からの受け取りも共通しています。

# Continue CLI: ステージ済み差分からコミットメッセージを作る
git diff --staged | cn -p "Write a commit message for this diff" --silent
 
# Claude Code: ビルドログを渡して原因を説明させる
cat build-error.log | claude -p "Explain the root cause of this error" > cause.txt

出力まわりの差は次のとおりです。

項目Continue CLIClaude Code
構造化出力Continue CLI--format jsonClaude Code--output-format json / stream-json
書き込みの許可Continue CLI--allow Write --allow EditClaude Code--allowedToolsで指定

Continueのヘッドレスモードでは、承認が必要なツール(askのもの)は、承認する人がいないため自動的に除外されます。ファイルを書かせたいときは、--allow Write --allow Editのように明示します。CIで自動修正を回す例では、--allow Bashまで足す形がドキュメントに載っています。Claude Codeも同じ発想で、--allowedToolsに許可するツールを列挙します。

注意点は、エージェントが書き込める範囲をCIの権限設計に含めることです。--allow "*"(Continue)や--dangerously-skip-permissions(Claude Code)のような全許可は、使い捨ての環境に限る使い方になります。

認証と費用の入口は何が違うか

Continue CLIは、起動時にContinueのアカウントでログインするか、Anthropic APIキーを入力するかを選びます。ブラウザのないCI環境ではCONTINUE_API_KEY環境変数で認証します。インストールはシェルスクリプトかnpmで、npm経由にはNode.js 20以上が必要です。

Claude Codeはclaude auth loginでAnthropicアカウントにサインインします。--consoleを付けると、Claudeサブスクリプションではなく、Anthropic Consoleに入ってAPI利用分の課金になります。ContinueでcnにAnthropic APIキーを渡す場合も、費用はAPI側の従量課金です。

どう使い分けるか

オートコンプリートを含めてエディターで完結させるならContinue拡張です。複数社のモデルやローカルモデルを、同じ設定ファイルでIDEとCLIの両方に使えるのも、Continueならではの点です。

一方、権限ルールをリポジトリごと配る運用は、.claude/settings.jsonをコミットできるClaude Codeでしか組めません。Claudeモデルを前提に、プランモードや権限ルールを使い込む場合もこちらです。

併用も成り立ちます。IDEではContinueのオートコンプリートとチャット、重い作業はターミナルのClaude Code、という分担です。この場合、2つの設定ディレクトリ(~/.continueと~/.claude)が別々に育つので、承認の記憶先も別々になる点だけ覚えておくと混乱しません。

近い論点は、Claude CodeとJunie CLIの違い(BYOK型のCLIとの比較)や、Claude CodeとKiroを比較(IDEとCLIの使い分け)でも扱っています。VS Code側の導入手順はClaude Code VS Code拡張機能の使い方に、CLIを軸に据える設計理由はAIコーディングエージェントCLI設計の理由にあります。

まとめ

差は「モデルの自由度」と「設定を配る単位」に集約されます。Continueはプロバイダーを選べる代わりに、設定と承認がユーザーのホーム中心です。Claude Codeは、モデルをClaudeに絞る代わりに、設定と権限をリポジトリ単位で配れます。

CIで使うならcn -pとclaude -pの許可フラグの違いを、チーム運用なら設定ファイルの置き場所を、それぞれ手元で試すと判断しやすくなります。

この記事を共有:XはてブLinkedIn