ClineとClaude Codeの違い — 課金・統合形態・対応モデルで使い分ける

Claude CodeとClineの違いは「課金の出どころ」と「統合の重心」

違いは、何にお金を払うかと、どこを起点に動くかの2点です。

月のAPI従量がProの月額20ドルを下回る軽い使い方ならCline、Maxの水準に届くヘビーな使い方ならClaude Codeが噛み合います。

Claude CodeとClineは、どちらも「コードベースを読み、ファイルを編集し、ターミナルコマンドを実行する」AIコーディングエージェントです。担う仕事は近いのですが、設計思想は対照的です。それぞれの中身は次のとおりです。

比較する2つのツールの正体

最初に、それぞれが「何であるか」を正確に押さえておきます。同じ「AIコーディングエージェント」という括りでも、提供主体と配信形態が異なります。

Claude CodeはAnthropicが提供するエージェント型のコーディングツールです。ターミナルで動く全機能版のCLIを中心に、VS Code拡張、JetBrainsプラグイン、デスクトップアプリ、ブラウザー版という複数の入口を持ちます。どの入口も同じClaude Codeエンジンに接続し、CLAUDE.md(プロジェクト共有の指示書)や設定、MCP(モデルコンテキストプロトコル)サーバーの構成を共有できるのが特徴です。

ClineはCline Bot Inc.が開発するオープンソースのコーディングエージェントで、ライセンスはApache 2.0です。GitHubのREADMEは、同じエンジンを次の5つの入口から使えると案内しています。

複数エージェントを並行で回すKanban形式のボードも、別アプリ(リサーチプレビュー)として用意されています。コミュニティ主導で開発が進み、公式サイトには250人を超えるコントリビューターが関わると示されています。

どの軸で比べるか

両ツールを実用視点で選ぶための評価軸を、次の5つに絞ります。冒頭で触れた課金と統合に、エージェントとしての中身を加えたものです。

1. 統合形態(どこで動くか。CLIかエディタ拡張か)
2. 課金モデル(定額サブスクか、BYOキーの従量か)
3. 対応モデル(使えるLLMの幅)
4. 拡張性(MCP対応、独自ツール、フックなど)
5. エージェントの作業スタイル(計画と実行の進め方)

比較マトリクス

5つの軸を1枚の表にまとめます。読者が自分の使い方に近い行だけを拾えるよう、判定はなるべく具体的な事実で書いています。

各セルの根拠は、このあとの「課金モデル」「対応モデル」「拡張性」の各節で詳しく見ていきます。

課金モデルの違いが最も効く

選択を最も左右するのが課金の構造です。両者は出発点がまったく異なります。

Claude Codeは、Anthropicのサブスクリプションで使うのが基本です。個人向けはProが月額20ドル(年払いなら月あたり17ドル相当)、上位のMaxは月額100ドルからで、Proの5倍または20倍の利用枠を持つ2段階が用意されています。ProとMaxのいずれにもClaude Codeが含まれます。月額の定額に収まるため、使うほど請求が膨らむ心配が小さく、コストの見通しが立てやすいのが特徴です。

※Claude Codeの価格は税抜です。日本から契約すると消費税10%が加わります。

Cline自体は無償のオープンソースで、ソフトウェアにライセンス料はかかりません。動かすには、利用者がAnthropicやOpenAI、Googleなどから取得した自分のAPIキーを設定し、各プロバイダーへ直接従量で支払うBYOキー方式が中心です。使うモデルとコストを利用者が直接管理でき、APIの利用量がそのまま請求に乗ります。

CLIのサインインには、自分のAPIキーのほかにClineアカウントやChatGPTのサブスクリプションも選べます。本記事の試算は、BYOキーで各社APIへ従量で払う場合のものです。

つまり、Claude Codeは「定額で予測しやすい」、Clineは(BYOキー利用時)「従量で柔軟だが使うほど積み上がる」という対比になります。ここで効いてくるのが「自分の月間トークン消費量が、定額の元を取れる水準に届くか」という損益分岐の視点です。次の節で具体的に試算します。

BYOキー従量と定額サブスク、損益分岐はどこか

従量(Cline + BYOキー)と定額(Claude Code)のどちらが安いかは、月にどれだけトークンを消費するかで決まります。判断の起点は、API従量で支払う額が定額プランの価格を超える地点です。

API従量のトークン単価

Anthropic APIは送受信したトークン(文章を細かく区切った処理単位)の量で課金されます。主要モデルの標準単価は次のとおりです。Clineで自分のAnthropicキーを使う場合も、この単価がそのまま適用されます。

コーディングエージェントは、コードベースやファイル内容を都度プロンプトに載せるため入力トークンが膨らみやすく、出力より入力の比率が高くなる傾向があります。プロンプトキャッシュ(同じ前置きを再利用してコストを下げる仕組み)が効くとキャッシュ読み取りは入力単価の10%程度まで下がります。Opus 5.5とSonnet 5.5は5%、Fable 5.1は2.5%程度とさらに低く、実際の請求はモデル選択とキャッシュ活用で大きく上下します。

シナリオ別の損益分岐試算

利用強度を3パターンに分け、月間のAPI従量コストを概算しました。1日あたりの消費トークンに稼働日数を掛けた、キャッシュ・割引を考慮しない上限寄りの見積もりです(実際の費用は使い方で大きく変わります)。

この試算からは、おおまかな分岐点が読み取れます。月のAPI従量がProの月額20ドルを下回る軽い使い方なら、固定費が出ないBYOキー従量が無駄になりにくいといえます。反対に、Opus中心で長時間・並行に回すヘビーな使い方では、Max(月100〜200ドル)の定額枠のほうが割安に振れていきます。ミドル層はPro定額の1.5倍前後で、キャッシュヒット率次第で逆転します。

「コスト上限」の置き方が両者で違う

損益分岐の数字以上に実務で効くのが、コストの天井が読めるかどうかです。Claude Codeの定額は、どれだけ回しても請求が月額で頭打ちになる(利用枠の範囲内)ため、予算を組みやすく、チームへの精算もしやすい構造です。

Clineの従量は、使った分だけ後から請求される仕組みのため、自律エージェントを長時間放置すると、想定外にトークンを消費してコストが膨らむことがあります。BYOキー方式では、暴走時の歯止めをAPIキーを発行したプロバイダー側の利用上限で掛ける運用になります。「使うほど積み上がる」リスクを管理する手間が、従量の柔軟さと引き換えに生じます。

Claude Code側にも、従量(APIキー)で回すときの歯止めがあります。後述の実機確認のとおり、非対話実行には1回あたりの予算上限を渡す引数があります。

対応モデルの幅はClineが広い

使えるLLMの選択肢では、Clineのほうが幅広い構成を取ります。

Claude CodeはAnthropic製のClaudeモデル(Opus / Sonnet / Haiku)を主軸に動きます。ターミナルのCLI、VS Code、JetBrainsでは第三者プロバイダー経由の利用にも対応していますが、設計の中心はClaudeにあります。Claudeの世代差をどう使い分けるかは、Claudeモデル比較(使い分けと組み合わせ)が参考になります。

Clineは、複数のプロバイダーを横断して使えるのが持ち味です。AnthropicのClaude、OpenAIのGPT系、GoogleのGemini系に加え、OpenRouter経由の多数のモデル、AWS BedrockやAzure・GCP Vertex、Cerebras、Groqといったホスティング、さらにOllamaやLM Studioを使ったローカルモデル、OpenAI互換の任意のエンドポイントまでサポートします。モデルをプルダウンで切り替えられるため、タスクや予算に応じて使い分けたい場合に柔軟です。

この対応モデルの幅は、課金の柔軟さと裏表の関係にあります。Clineは「安いモデルで下調べ、難所だけ高価なモデル」のようにタスク単位でモデルを切り替えてコストを最適化できる一方、その判断を利用者が都度負うことになります。Claude Codeは選択肢を絞る代わりに、Claudeの性能を前提に作り込まれた一貫した体験を提供します。特定プロバイダーに縛られたくない、機密性の観点でローカルモデルを試したい、といった要件があるならClineの自由度が効いてきます。Google製のコーディングエージェントそのものと比較したい場合はClaude Code vs Gemini CLIも参考になります。

OSS拡張とCLIエージェント、統合形態の違いを実務で見る

課金と並んで日々の使い勝手を左右するのが、ツールが「どこに住んでいるか」という統合形態の違いです。両者は重心が異なり、その差は拡張のしかたや運用への組み込みやすさに表れます。

Clineは「エディタに同居するOSS拡張」

Clineの出発点はエディタの中にあります。VS Codeのサイドパネルに常駐し、コードを見ながら対話する体験が原点です。オープンソース(Apache 2.0)であることの実務的な意味は、次の3点に表れます。ただしJetBrainsプラグインのソースは公開されていません。

ひとつは、ソフトウェア自体を読んで監査・改変できる点です。エージェントが何をしているかをコードレベルで確認でき、社内方針に合わせてフォークする選択肢もあります。次に、.clinerulesというファイルをリポジトリに同梱することで、コーディング規約やアーキテクチャー方針をエージェントに教え込めます。そして、SDKを使えばカスタムツールやライフサイクルフックを登録できます。

エディタ中心であるため、コードを目で追いながら一手ずつ確認する作業や、エディタを離れずに対話を完結させたい場面に馴染みます。

Claude Codeは「ターミナル常駐のCLIエージェント」

Claude Codeの重心はターミナルにあります。CLIとして起動し、シェルのパイプやスクリプトに自然に組み込める設計です。tail -200 app.log | claude -p "異常があれば知らせて"のように、ほかのコマンドと連結して使えます。

ただし、パイプで流し込めるのはClaude Codeだけの特権ではありません。ClineのCLIのREADMEにも、cat file.txt | cline "Summarize this"というパイプ入力と、CI/CDやスクリプト向けのヘッドレス実行が載っています。差はパイプの可否ではありません。JSON出力(Clineは--json、Claude Codeは--output-format json)や承認の省略はどちらにもあり、はっきり違うのはドル建ての予算上限を引数で渡せるかどうかです。Claude Code側の実際の引数は、次の実機確認で見ます。

CIのステップとしてコードレビューや翻訳を自動化したり、スケジュール実行で定期タスクを回したりといった、エディタの外側のワークフローに展開しやすいのがClaude Codeの特徴です。ただしClineのCLIにも、cronで定期実行するスケジュール機能があります。拡張要素としては、プロジェクト共有の指示書CLAUDE.md、繰り返し作業をまとめるSkills(スキル)、操作の前後でシェルコマンドを走らせるHooks(フック)、タスクを分担する複数エージェントのSubagents(サブエージェント)を標準で備えます。これらは複数の入口で共有されます。

外部ツールとつなぐMCP(AIツールと外部データ源をつなぐオープン標準)には両者とも標準対応し、データベースやAPI、社内ツールをエージェントから呼び出せます。差が出るのは周辺のエコシステムの厚みで、拡張の用語や設計が両者で異なるため、既存の運用にどちらが馴染むかで選ぶことになります。ClineのmcpServers設定をそのままClaude Codeへ移す手順はClineからClaude CodeへMCP設定を移行する手順で扱っています。

手元のClaude Code v2.1.287で確認した非対話実行・予算・権限の引数

ここまでの「CIに組み込みやすい」を、実際のヘルプ出力で確かめます。インストール済みのClaude Code v2.1.287で--versionと--helpだけを実行しました。モデルは呼んでおらず、課金も発生しません。

claude --version
# 2.1.287 (Claude Code)
 
claude --help
#   -p, --print              Print response and exit (useful for pipes).
#   --output-format <format> "text" (default), "json" (single result),
#                            or "stream-json" (realtime streaming)
#   --max-budget-usd <amount> Maximum dollar amount to spend on API calls
#                            (only works with --print)
#   --permission-mode <mode> choices: "acceptEdits", "auto",
#                            "bypassPermissions", "manual", "dontAsk", "plan"
#   --mcp-config <configs...> Load MCP servers from JSON files or strings

引数の説明文から読み取れる点は3つです。1つ目は、--output-formatのjsonとstream-json、そして--max-budget-usdが、いずれも--print(-p)と組み合わせたときだけ効くと説明されていることです。対話画面では使えず、スクリプトやCIから呼ぶ前提の引数だと分かります。

2つ目は、--max-budget-usdが「APIコールに使う金額の上限」を1回の実行ごとに渡せる点です。定額サブスクの枠ではなく、ドル建ての予算を引数で縛る仕組みなので、前の節で見た「従量は天井が読めない」という弱点を、Claude Code側ではAPIキー運用に限って緩められます。ヘルプには対象の課金方式まで書かれていないため、サブスク利用時の挙動は確認できていません。

3つ目は--permission-modeで、選択肢はacceptEdits、auto、bypassPermissions、manual、dontAsk、planの6つです。Plan Modeや自動モードは、画面上の切替だけでなく起動時の引数でも指定できます。

MCPの管理もサブコマンドとして揃っています。claude mcp --helpの出力には、次のコマンドが並びました。

claude mcp addのヘルプには、--transport httpでHTTPサーバーを追加する例と、-e KEY=valueで環境変数を渡す例が載っています。設定の保存先を決める--scopeはlocal / user / projectの3つで、既定はlocalです。ClineのMCP設定はJSONで持つ形なので、設定ファイルをコマンドへ移す具体的な手順はClineからClaude CodeへMCP設定を移行する手順が受け皿になります。

ClineのCLIにも、計画モードで走らせる-p(--plan)、承認を飛ばす--yolo、全ツールの自動承認を切り替える--auto-approveがあります。CLIのREADMEでは、ツール呼び出しは既定で自動承認です。一方、ドル建ての予算上限にあたる引数はREADMEに見当たりません。引数の数で優劣を測るのは控え、自分のCIで必要な指定が揃うかをそれぞれの--helpで見るのが確実です。

エージェントの作業スタイルはどちらも「計画してから実行」

連続した多段階の作業を進めるとき、両ツールとも「まず計画、次に実行」という二段構えを採ります。設計思想が近いところです。

Clineは、Plan ModeとAct Modeをトグルで切り替えます。Plan Modeではコードベースを探索し、不明点を質問しながら方針を立て、合意できたらAct Modeに切り替えて計画を実行します。一手ずつ承認する運用と、auto-approve(自動承認)で自走させる運用を選べます。

Claude CodeもPlan Modeで計画を先に提示し、autoなどの権限モードで自走させる使い方ができます。複数ファイルへの変更を計画し、テストまで回して検証する、といった一連の流れをエージェントが担います。Codex CLI・Cursor・Devinとの権限モデルの違いはAIコーディングエージェント 権限モデル比較で比べています。

作業の進め方そのものは似ているため、ここは決め手になりにくい部分です。むしろ前述の課金・対応モデル・統合形態のほうが、日々の使い勝手を大きく左右します。

用途別の使い分け早見表

どちらか一方が常に正解というものではありません。利用形態ごとに、明確な恩恵があるケースとそうでないケースを早見表にしました。判定語は「向いている / 条件次第 / 別の選択肢が有力」の3段階です。

この表からは、コストの予測しやすさとClaude前提の一貫体験を取るならClaude Code、プロバイダーの自由度とOSSの透明性を取るならClineという、おおまかな住み分けが読み取れます。

併用するという選択肢 — 二者択一にしない判断

両者は排他ではありません。Clineは多数のプロバイダーに対応するため、AnthropicのAPIキーを設定すればCline上でClaudeを動かすこともできます。「Claude Code Clineの違い」を調べる読者の多くは二者択一を想定しがちですが、実際には作業の性質で役割を分ける構成もありえます。

判断の目安として、次のような分け方が考えられます。

エディタ中心の開発からCLI中心へ移る勘所はCursorからClaude Codeへの移行にも通じます。

まとめ

月のトークン消費がMaxの定額水準に届くなら、コストが頭打ちになるClaude Codeが噛み合います。届かない軽い使い方や、複数プロバイダー・OSSの透明性を重視する場合はClineが無駄になりにくい選択です。

引数で差が出るかは、実際に使うCIの条件を各ツールの--helpに当てて確かめてください。併用も排他ではありません。