Claude Code と Cline は両方契約する必要がある？

用途次第です。ソロで小規模プロジェクトなら Cline 単体、CI/CD 自動化メインのチームなら Claude Code 単体で足ります。両方契約する価値が出るのは「個人開発者として高速に動きたい + チームに対しては承認可視化したい」のように両モードを行き来する人です。月コストは合計 35-50 ドル程度になります。

Claude Code と Cline、同じファイルを同時に編集して大丈夫？

片方の変更が消える危険があります。両方使う場合は「片方しか動かさない」運用にして、明示的に切り替えるのが安全です。並行作業はファイル単位を分けるなどの工夫が必要です。

Plan Mode は Claude Code と Cline でどう違う？

Claude Code の Plan Mode は Shift+Tab で起動し、自然言語のステップ列挙が中心です。Cline の Plan/Act モードは UI から明示的にトグルし、チェックリスト + 影響範囲などより構造化された表示です。両方使う場合は Claude Code で Plan を立てて、その計画を Cline で Act モードに移すハイブリッド運用も成立します。

.clineignore と settings.json の permissions.deny は両方書くべき？

両方書くのが安全です。.gitignore に共通ルールを集約し、.clineignore は Cline 固有、.claude/settings.json の permissions.deny は Claude Code 固有のルールに使い分けます。秘匿情報（.env、*.pem）は両方に書いて二重防御するのが安心です。

MCP サーバは Claude Code と Cline で共有できる？

共有できます。Claude Code 側は .claude/settings.json の mcpServers で参照、Cline 側は cline_mcp_settings.json で同じファイルを読むという構成が可能です。ただし MCP サーバの権限管理は別々なので、ツール毎の権限テストは個別に行う必要があります。

コスト的に両方契約する価値はある？

用途による。Claude Code Pro が月 20 ドル固定、Cline はクラウド API 従量で月 15-30 ドル振れる。合計 35-50 ドル/月。両方使うメリットは Pro の固定費で重い処理を吸収しつつ、Cline で IDE 内スポット利用に絞って API コストを抑えること、そしてどちらかが落ちた時の冗長性です。

どちらかを正にするなら Claude Code と Cline どっち？

並列・自律性が必要な大規模タスクは Claude Code、IDE 内の一手ずつ承認したい作業は Cline、と役割で分けるのが現実的です。「正」を1つに決めるよりは、タスクの性質で適切な側を選ぶ運用が向いています。同じタスクを両方に頼むと回答がずれることがあるため、基本は「Claude Code を真、Cline をサブ」のように決めておくと迷いません。

Claude Code × Cline 併用ワークフロー — IDE と CLI の両刀運用でフロー速度を上げる実践【2026年版】

Home / Blog / Claude Code × Cline 併用ワークフロー — IDE と CLI の両刀運用でフロー速度を上げる実践【2026年版】

Claude Code と Cline、どっちか選ぶより両方使うほうが生産性が高い理由と、実プロジェクトでの使い分けフロー。コスト計算、Plan/Act モード活用、MCP サーバ共有、.clineignore と settings.json の併用まで実体験ベースで解説。

エンジニアのゆとです。

Claude Code と Cline の比較記事はもう山ほどある。でも、実際に両方使ってる立場から言うと「比較して片方を選ぶ」発想自体が古い気がする。

僕は普段、Claude Code を CLI で動かしながら、VSCode の中では Cline も同時に立ち上げている。同じプロジェクトに対して、両方のツールが文脈を持ってる状態。最初は「重複しすぎ？」と思ったけど、3 ヶ月使ってみて「両方使うのが一番速い」という結論に落ち着いた。

この記事は、Claude Code と Cline を 併用する側の運用ガイドだ。比較記事ではない。どちらが優れているかではなく、どう組み合わせて何を分担させるかの話。

片方じゃなく両方使う理由

「ターミナルで動くやつ」と「VSCode の中で動くやつ」は、表面的には似てるが、最適なタスクが違う。

僕の体感での得意領域はこうなっている。

観点	Claude Code	Cline
大規模リファクタ（複数ファイル横断）	◎	○
単一ファイルのちょい修正	△（重い）	◎
エディタ内のリアルタイム支援	×	◎
バックグラウンドで長時間タスク	◎	△
サブエージェント並列運用	◎	×
モデル選択の自由度	△（Anthropic 中心）	◎（GPT/Gemini/Ollama も可）
全アクションの明示承認	✕（Hooks 経由で部分実装可）	◎
コスト（Pro 月額 $20 込みで）	◎（定額）	△（API 従量）

これを見ると、両者は重複しているようで、実は 得意な象限が違う。Claude Code は「自律的に長時間動かすバックグラウンドのオーケストレーター」、Cline は「IDE 内で一手ごとに承認を取りながら進めるサポーター」と整理すると、棲み分けが見えてくる。

それぞれを何に使うか

Claude Code の出番

僕が Claude Code に任せる典型的なタスクは:

複数ファイル横断のリファクタ（型シグネチャ変更、API 移行）
大規模なテスト追加（既存実装の網羅テスト生成）
バックグラウンドでの長時間タスク（スクレイピング、バッチ処理、レポート生成）
サブエージェントで並列分担できる作業
ターミナル中心のワークフロー（git 操作、CI 連携、デプロイ）

ここでは「自律性」と「並列性」が効く。ファイル数百個に対して同じパターンの修正を入れる時、Claude Code に投げて寝るのが一番速い。

Cline の出番

逆に Cline を使う場面:

一行〜一関数の修正をエディタの流れの中で済ませる
「いま見てるこの箇所どうなってる？」をリアルタイムで聞く
危険なコマンド（rm、DB 削除、本番 deploy）を実行前に必ず確認したい
API キーや料金を細かく管理したい（OpenAI クレジットや Gemini で動かす場面）
VSCode 内のタブ・カーソル位置といったコンテキストを活用したい

Cline は VSCode 拡張なので、エディタ内での「いまここ」をそのままコンテキストとして使える。Claude Code はターミナルから別プロセスで動くので、エディタの状態は基本的に渡せない。

実プロジェクトでの使い分けフロー（3 ケース）

抽象論だけだとピンと来ないので、実際のプロジェクトで僕がどう動いているかを 3 つのケースで書く。

ケース 1: 新機能追加（中規模、複数ファイル）

例: 「ユーザー設定画面に通知設定タブを追加する」

Claude Code に /plan でPlan Mode起動 → 既存の設定画面アーキテクチャを読み、追加するファイル一覧と依存関係を提案させる
Plan を承認後、Claude Code に実装させる（複数ファイル横断の新規追加）
生成されたコードを VSCode で開く
ここから Cline に切り替えて、細かい調整（CSS の微調整、エラーハンドリングの追加）を 1 手ずつ承認しながら進める
最後の動作確認は Cline で「該当ファイルの差分見せて」と頼みつつ、ターミナルでテスト実行

Claude Code でデカく作って、Cline で詰める。

ケース 2: バグ修正（特定箇所が壊れてる）

例: 「ユーザー削除処理が一部のレコードで失敗する」

Cline に「UserService.delete の最近の差分を教えて」と聞く（カーソル位置とファイル状態が手元にある）
原因仮説を Cline と会話で詰める
修正が小さければそのまま Cline で実装→テスト
影響範囲が広そうなら Claude Code に渡して、関連する全テスト+周辺メソッドの整合性チェックを並列で走らせる

小さい修正は Cline 完結、影響大なら Claude Code に投げる。

ケース 3: 大規模リファクタ（型変更、API 移行）

例: 「UserId を string から branded type UserId にする」

Claude Code に変更計画を立てさせる（影響ファイル、移行順序、テスト戦略）
Plan を承認したら Claude Code に並列で複数サブエージェントを立てて実装させる（モジュール別に分担）
ローカルでビルド失敗箇所が出たら Cline に渡して、エラーメッセージを見ながら 1 件ずつ直す
最終確認とコミット粒度の調整は Cline で（一手ずつコミットメッセージを書きたいので）

並列リファクタは Claude Code、最後の整地は Cline。

Plan/Act モードの違いと併用

Cline には Plan/Act モード という独自の概念がある。Plan で計画だけ立てさせて、Act で実装に入る、という二段構え。

Claude Code にも Plan Mode（Shift+Tab）はあるが、両者は微妙に違う。

観点	Claude Code Plan Mode	Cline Plan / Act
起動方法	Shift+Tab で切り替え	UI から明示的にトグル
Plan の中身	自然言語のステップ列挙	より構造化（チェックリスト + 影響範囲）
Act 移行	ExitPlanMode で承認	「Approve & Execute」明示クリック
中断のしやすさ	キーボードで即離脱	UI 操作が必要

両方使ってると気づくのは、Plan の粒度が違う。Claude Code の Plan は計画文書として読める。Cline の Plan はもう少し UI 寄りで、チェックボックスでオン/オフを切り替えられる。

実用的には、複雑な変更は Claude Code で計画を立てて (/plan 利用)、その計画を Cline にコピーして Act モードで実装、というハイブリッドも成立する。Plan のフォーマットがそのまま使える。

コスト計算: 両方使うとどうなるか

「両方契約する」のがコスト的に正解かどうか、実際の請求書ベースで整理する。

僕の運用（プライベートと業務、月）:

Claude Code Pro: $20/月（固定）
Cline: 月のクラウド API 利用料は だいたい $15-30 で振れる（GPT-5 と Sonnet 4.6 を使い分け）

合計 $35-50/月。

「Claude Code Pro だけ」だと $20/月で固定だが、Cline で扱える「VSCode 内のリアルタイム支援」がない。逆に「Cline だけ」だと $20-40/月（API 従量、用途次第）で、Claude Code の並列サブエージェントとバックグラウンド長時間タスクができない。

両方契約のメリット:

Claude Code 側を固定費でカバー（5 時間制限内なら追加費用ゼロ）
Cline は IDE 内のスポット利用に絞ることで API コストを抑える
どちらかが落ちた時の冗長性

両方使ってると、「重い処理は Pro 枠で吸収、軽い処理は Cline で承認しながら」という分担が自然にできる。

.clineignore と settings.json の併用

ファイル除外設定の扱い方は両方で違う。

ツール	除外設定
Cline	`.clineignore`（gitignore 互換構文）+ allowList/denyList ルール
Claude Code	`settings.json` の `permissions.deny` + `respectGitignore`

両方使う場合、僕の運用は:

プロジェクトルート/
├── .gitignore           # 共通: git 対象外
├── .clineignore         # Cline 専用: 詳しめに除外
└── .claude/
    └── settings.json    # Claude Code 専用: deny ルール

.gitignore を両方が参照（Cline は respectGitignore: true、Claude Code も同様）するので、共通ルールはここに集約。Cline 固有のルールは .clineignore、Claude Code 固有のルールは .claude/settings.json の permissions.deny に書く。

秘匿情報（.env、*.pem）は両方の deny に書いて二重防御するのが安心だ。