Clineとは？VS Code拡張とCLIの使い方・料金・自動承認設定を実装目線で解説

Clineは、エディタやターミナルの中でコードを読み、書き換え、コマンドまで実行するオープンソースのコーディングエージェントです。日本語の解説記事の多くはVS Code拡張の導入手順で終わっていますが、2026年9月時点のClineは拡張だけでなくCLI・デスクトップアプリ・SDKへ広がり、選ぶ入り口によって自動化できる範囲が変わります。この記事では、公式ドキュメントで実測した版数と設定名、そのまま打てるコマンドで、4形態の選び方からPlan／Actモードの運用、自動承認の絞り込み、費用の見積もり方までを順に追います。OS別の設定ファイル保存場所はClineの設定ファイルとインストールを整理した記事にまとめてあるため、本稿は「どれを選び、どこまで権限を渡すか」の判断へ絞りました。

まとめ｜Clineの4形態選定と自動承認の権限境界を先に決める結論

先に結論を置きます。個人のコード修正ならVS Code拡張だけで足ります。CI やバッチから呼びたい、あるいは複数リポジトリをまたいで定型作業を回したいなら、CLIとSDKまで含めて構成を決めてください。この判断を後回しにすると、拡張のGUI設定とCLIの設定が二重管理になります。

権限の決め方はもっと単純です。受託開発で他社のコードを触るなら、自動承認は「ワークスペース内のファイル読み取り」と「安全と判定されたコマンド実行」の2つまでに絞る。公式が用意している9つの自動承認項目のうち、残り7つは案件ごとに明示的な合意がある場合だけ開けます。全チェックを外すYOLOモードには、公式ドキュメント自身が “This is dangerous.” と警告を置いています。

費用については、Cline本体に座席課金がありません。支払い方は3通りで、Cline経由の従量課金、月額9.99ドル定額のClinePass、自前のAPIキーを持ち込むBYOKから選びます。つまり月額は座席数ではなく、選んだ経路と使ったモデルの単価で決まる構造です。見積もりの軸をここに置き換えるところから始めてください。

Clineの実体｜VS Code拡張・CLI・Desktop・SDKの4形態と担当範囲

「Cline＝VS Codeの拡張機能」という理解は、2025年時点では正しく、いまは半分だけ正しい状態です。同じ名前で提供される入り口が4つに増えました。

拡張v4.1系・CLI v3.0系・Desktop v0.0系の版数と更新間隔

公式リポジトリのリリース一覧を2026年9月5日時点で確認すると、系統ごとに別のタグで配布されていることが分かります。IDE拡張は v4.1.17（2026年9月2日公開）、CLIは cli-v3.0.61（同日）、デスクトップアプリは desktop-v0.0.23（2026年9月3日）、SDKは sdk/v0.0.82（同2日）でした。

版数の桁を見れば成熟度の差は明らかです。デスクトップ版とSDKは0.0系、つまり破壊的変更が入りうる段階にあります。3日で3タグという更新頻度も、業務の土台に据えるには速すぎます。本番運用の中心に置くなら、まずは4系の拡張と3系のCLIまでにしておくのが安全でしょう。なお過去バージョンの機能差についてはv3.25.0のアップデート内容を解説した記事が参考になりますが、Deep PlanningやAuto Compactはその後の版で扱いが変わっているため、現行の挙動は公式ドキュメントで確認してください。

拡張・CLI・Desktop・SDKの使い分けと併用時の設定共有範囲

使い分けの基準は「人が横で見ているかどうか」です。人が承認しながら進める作業は拡張、人がいない時間に回す作業はCLIかDesktop、自社プロダクトの機能として埋め込むならSDK。この3分類で迷うことはほとんどありません。

拡張の普及度も判断材料になります。Visual Studio Marketplaceの拡張ページでは、2026年9月5日時点でインストール数が5,215,266件と表示されていました。500万件規模の利用があるということは、詰まったときに同じ症状の報告が見つかりやすいという実務上の利点につながります。CLIやSDKにはまだその蓄積がありません。

インストールから最初のタスク実行までの手順とプロバイダ設定の分岐

導入自体は数分で終わります。時間を取られるのは、そのあとのAPIプロバイダの選択です。

VS Code拡張とCLIそれぞれのインストールコマンドと前提バージョン

公式の導入ガイドは4経路を示しています。IDE拡張はマーケットプレイスから検索してインストールし、そのままプロバイダ設定へ進む流れ。CLIは Node.js 20 以上が前提で、グローバルインストール1行です。Kanbanはプレビュー段階のため、npxで都度起動する形になっています。

# CLI（Node.js 20 以上が前提）
npm i -g cline

# 対話セッションを開始する
cline

# タスクを1回だけ実行して終了する
cline "refactor this module to use async/await"

# 結果をJSONで受け取る（CIやスクリプトから呼ぶ場合）
cline --json "list TODO comments"

# Kanban（プレビュー版）を起動する
npx kanban

CLIリファレンスに載っているサブコマンドは auth・config・mcp・doctor・history・schedule・hub・kanban の8種類です。導入直後に覚えるのは auth と doctor の2つで足ります。動かないときは cline doctor が診断と修正の入り口になります。

Cline ProviderとBYOKどちらで認証を通すかの判断と設定箇所

認証は3択です。Cline経由の従量課金で使うか、月額9.99ドル定額のClinePassを契約するか、自分で用意したAPIキーを持ち込むか。公式ドキュメントは3番目を “bring your own provider key” と呼び、OpenAI・Anthropic・Googleなどのキーをそのまま使えると記載しています。

受託開発では後者を選ぶ場面が多くなります。理由は請求の帰属です。案件ごとに別のAPIキーを割り当てておけば、どの案件でいくら推論したかが契約先の請求明細でそのまま分かれます。Clineのプロバイダ経由にまとめると、案件別の按分を自分で計算し直すことになります。逆に、社内の検証や短期のPoCなら、キー調達の手間がないCline Provider側のほうが着手は早いでしょう。設定ファイルの保存場所とOSごとのパスは設定ファイルの完全ガイドに整理してあります。

Plan／Actモードの切り替え運用と大規模改修でのdeep-planning指定

Clineの挙動を決めているのはモデルの賢さだけではありません。読むだけの時間と、書き換える時間を分ける仕組みがあります。

Planモードで許可される操作とActモードへ切り替える判断の目安

公式のPlan and Actの解説によれば、Planモードでできるのはコードベースの読み取り・検索・方針の議論までで、ファイルの修正とコマンド実行はできません。Actモードに切り替えると実装に移ります。切り替えても計画時の文脈はそのまま保持されるため、方針を説明し直す必要はありません。

切り替えの判断はひとつだけです。「どのファイルをどう変えるか」を自分の言葉で言えるようになったら、Actへ移る。まだ曖昧なままActに入ると、動くけれど設計が破綻したコードが積み上がります。差し戻しのコストは、計画に足した5分より確実に大きくなります。

タスク規模別のモード運用とPlan／Actでモデルを分ける設定手順

公式ドキュメントはタスク規模ごとに3段階の運用を示しています。誤字や単純なバグ修正はActのみ。新規APIエンドポイントの追加やUI実装はPlanからActへ。複数ファイルにまたがる機能追加や大規模リファクタリングでは /deep-planning を使う、という区分です。

# 計画から入る（読み取りと調査のみ・書き換えは発生しない）
cline -p "決済モジュールの依存関係を洗い出して改修計画を出す"

# モデルとプロバイダを指定して実行する
cline -m claude-opus-5 -P anthropic "失敗しているテストの原因を特定する"

# 作業ディレクトリとタイムアウトを固定して実行する
cline -c ./services/billing -t 600 "テストが通る状態まで修正する"

設定から有効にすると、PlanとActで別々のモデルを割り当てられます。計画には推論の強いモデル、実装には応答の速いモデルという配分が取れるため、費用と速度の両方に効きます。仕様そのものを先に合意してから実装へ渡す進め方は、OpenSpecによる仕様駆動開発の記事で扱っている考え方とほぼ同じ構造です。

.clinerulesにプロジェクト規約を書いて説明の反復を減らす設定手順

同じ前提を毎回打ち込んでいるなら、それはルールファイルに移すべき内容です。

.clinerulesディレクトリの構成例と読み込まれるファイル形式

公式のCline Rulesドキュメントは、単一ファイルではなくディレクトリ形式を案内しています。.clinerules/ の中にある .md と .txt をすべて読み込み、ひとつのルール集として結合する仕様です。数字プレフィックスは整理のために付けられますが、必須ではありません。

your-project/
├── .clinerules/
│   ├── 01-coding.md
│   ├── 02-testing.md
│   └── 03-architecture.md
├── src/
└── package.json

プロジェクトをまたいで効かせたいルールは、グローバル側に置きます。保存先はWindowsが Documents\Cline\Rules、macOSとLinux／WSLが ~/Documents/Cline/Rules（見つからない場合は ~/Cline/Rules）です。1ファイル1トピックに保つことも公式が推奨しています。

frontmatterのpaths指定でルールを適用範囲ごとに切り分ける書式

ルールを全ファイルに一律で効かせると、フロントエンドの規約がバッチ処理のコードにも適用されて邪魔になります。YAML frontmatter の paths で適用範囲を絞ると、この衝突が消えます。

---
paths:
  - "src/components/**"
  - "src/hooks/**"
---
# Reactコンポーネントの規約

## 命名
- ファイル名はPascalCaseで書く（例：UserCard.tsx）
- 既存の実装は src/components/UserCard.tsx を参照する

## 状態管理
- ローカル状態はuseStateで完結させ、グローバル化しない
- 理由：画面をまたがない状態をストアへ上げると依存が読めなくなるため

書き方のコツは、指示に理由を添えることです。「グローバル化しない」だけだと例外の判断ができませんが、理由が書いてあれば妥当な例外を選べます。ルールファイルそのものの位置づけと書式の詳細は.clinerulesを解説した記事で扱っています。

自動承認9項目を受託開発の権限境界に合わせて絞り込む設定の考え方

ここが受託開発で最も慎重になるべき設定です。生産性の設定ではなく、契約上の責任範囲の設定として扱ってください。

自動承認9項目の内訳と安全判定されるコマンド・要承認コマンドの実例

公式のAuto Approveドキュメントが挙げている項目は9つです。ワークスペース内のファイル読み取り、ワークスペース外を含む全ファイルの読み取り、ワークスペース内のファイル編集、全ファイルの編集、安全と判定されたコマンドの実行、すべてのコマンドの実行、ブラウザの使用、MCPサーバーの使用、長時間コマンドの通知。

境界は「読み取り専用かどうか」ではなく「元に戻せるかどうか」で引かれています。npm install が要承認側にあるのは、依存関係の追加がロックファイルとビルド結果を変えてしまうからです。この観点は自社の追加ルールを作るときにも流用できます。

受託案件でYOLOモードを禁じる理由と代わりに置く承認範囲の設定

すべての安全チェックを無効化するYOLOモードについて、公式ドキュメントは重要ファイルの無警告削除、システム設定を変えるコマンドの実行、設定ファイルの上書きを危険例として列挙し、”This is dangerous.” と明記しています。他社の資産を預かる案件では、この一行だけで採用しない理由が足ります。

# 自動承認を切って1タスクずつ承認する
cline --auto-approve false "本番設定ファイルの差分を確認する"

# MCPサーバーの登録状況を確認する
cline mcp

# 認証と設定の状態を出力する
cline auth
cline config

# 想定どおり動かないときの自己診断
cline doctor

実務では、自動承認を全面禁止にすると承認ダイアログの連打で誰も使わなくなります。読み取りと安全コマンドの2項目だけ開け、編集は都度承認から始める。案件が進んで挙動が読めてきたら「ワークスペース内のファイル編集」まで広げる。この順序なら、緩めた瞬間に何が起きるかを把握したまま進められます。

BYOKとCline Providerの料金構造と月あたり費用の見積もり手順

料金の質問には、ツール代とモデル代を分けて答える必要があります。

座席課金がない料金構造とAI推論クレジットの支払い対象の切り分け

公式の料金ページは、個人開発者にとってClineは無料であり、支払うのはAIモデルを使ったときの推論ぶんだけだと記載しています。ベンダーロックインもないという記述で、座席単位の課金は登場しません。エンタープライズプランはSSO・SLA・専任サポートを含むカスタム価格で、金額は問い合わせ扱いです。

この料金ページには、2026年9月5日時点で推論クレジットの単価表が載っていません。定額で読める唯一の実額はClinePassの月額9.99ドルです。GLM 5.3・Kimi K3・DeepSeek V4 Pro・Qwen 3.8 Maxといったオープンウェイト系13モデルが対象で、標準API単価に対して2〜5倍の利用量が枠として提供されると記載されています。従量課金のCline経由の支払いとは独立して併用でき、公式も “You can use both independently” と明記した構成です。見積書に載る行はライセンス費ではなく、このClinePassの定額かAPI利用料のどちらかになります。

BYOKで月額を見積もる際に効くモデル選択とコンテキスト管理

月額を決める変数は2つしかありません。1リクエストあたりに送る文脈量と、使うモデルの単価です。前者はリポジトリの規模ではなく、指示の出し方で変わります。

• Planには推論の強いモデル、Actには速いモデルを割り当て、計画1回に対して実装を複数回回す
• タスクを小さく切り、1セッションで扱うファイル数を絞る（-c で作業ディレクトリを固定する）
• 繰り返し説明している前提は .clinerules に移し、毎回のプロンプトから外す

この3つは、いずれも送信トークンを減らす操作です。順番に効くのは1番目で、モデル単価の差はそのまま請求額の差になります。逆に、無理な圧縮を狙って文脈を削りすぎると、誤った実装のやり直しでかえって推論回数が増えます。減らすべきは無駄な前置きであって、必要な仕様ではありません。

Claude Code・Cursor・Roo Codeとの使い分けと導入を見送る条件

ここは言い切ります。すべてのチームにClineを勧めることはしません。

Claude Code・Cursorとの機能重複とClineを選ぶ具体的な条件

3者の機能はかなり重なっています。それでもClineを選ぶ理由になるのは、次の条件が当てはまるときです。第一に、モデルを自分で選びたい場合。ClineはBYOKを前提に据えているため、案件ごとに使うモデルとAPIキーを変えられます。第二に、エディタを変えたくない場合。Cursorは専用エディタへの移行が前提ですが、Clineは既存のVS Codeにそのまま乗ります。

反対に、ターミナル中心の作業が主で、プロジェクト規約をリポジトリ管理したいだけなら、Claude Codeの使い方をまとめた記事で扱っている構成のほうが素直です。両者を併用するチームもありますが、ルールファイルが .clinerules と CLAUDE.md に分散するため、片方を正としてもう片方から参照する運用に決めておかないと内容がずれていきます。

Roo Codeなど派生との違いと導入を見送るべきチーム条件

Clineはオープンソースのため、Roo Cline（現Roo Code）をはじめとする派生が複数あります。派生ごとの違いはClineの種類を比較した記事に整理しました。実務では、本家の更新頻度に追随できる体制があるかどうかで選ぶことになります。

導入を見送るべき条件も明示しておきます。ひとつ、社外へのコード送信が契約で禁じられている案件。BYOKでもコードはモデル提供者へ渡るため、ここは設定で回避できません。ふたつ、レビュー体制がない少人数チーム。承認を機械的に押すだけの運用になり、生成されたコードの負債がそのまま残ります。みっつ、更新に追随する担当を置けない場合。0.0系のDesktopやSDKを含めて3日で複数タグが出る速度に、片手間では追いつきません。この3つのいずれかに当てはまるなら、まずは人が横で見る範囲、つまり拡張の対話利用だけに留めるべきです。

導入判断そのものを社外の視点で詰めたい場合や、Clineを組み込んだ開発フローの設計から相談したい場合は、生成AI開発・AI受託開発で受け付けています。既存の開発体制に合わせて、権限設計とルールファイルの初期整備まで含めて設計できます。

よくある質問

導入初期に届きやすい質問を、公式ドキュメントの記載にもとづいて整理しました。

Clineは無料で使えますか？

ツール本体は無料です。公式の料金ページには、個人開発者にとってClineは無料であり、座席課金はないと記載されています。費用が発生するのはAIモデルの推論ぶんだけで、自分で契約したOpenAI・Anthropic・GoogleなどのAPIキーを持ち込む形（BYOK）も選択肢です。定額で使いたい場合は月額9.99ドルのClinePassという任意のサブスクリプションもあり、こちらはオープンウェイト系13モデルが対象です。推論クレジットの単価表は2026年9月5日時点で公式ページに掲載されていないため、BYOKの実額は選んだモデルの従量単価から見積もることになります。

ClineとRoo Codeは何が違いますか？

Roo Code（旧Roo Cline）はClineから派生したプロジェクトで、機能追加の方針と更新の速度が本家と異なります。派生にはほかにCool Cline、Bao Clineがあり、それぞれ独自の機能を持つプロジェクトです。選定の観点は本家の更新へ追随できるかどうかで、詳細はClineの種類を比較した記事にまとめてあります。

VS Codeを使っていなくてもClineは動きますか？

動きます。IDE拡張の提供先はVS Codeのほか、cursorとjetbrains系のIDEです。また、エディタを使わずターミナルだけで動かすCLI版もあります。CLIは Node.js 20 以上の環境に npm i -g cline で導入でき、cline "指示" の形でタスクを1回だけ実行させることも可能です。CI から呼ぶ場合は --json で構造化出力を受け取れます。

自動承認はどこまで開けても安全ですか？

他社のコードを扱う案件では、ワークスペース内のファイル読み取りと、安全と判定されたコマンドの実行までに留めるのが妥当です。公式が安全側に分類しているのは npm run build や git status のように元に戻せる操作で、npm install や rm -rf は承認が必要な側に置かれています。すべてのチェックを外すYOLOモードには公式自身が危険との警告を出しているため、業務では選択肢から外してください。

.clinerulesは1ファイルにまとめるべきですか？

分けると管理しやすい構成です。公式は .clinerules/ ディレクトリ内の .md と .txt をすべて読み込んで結合する仕様を案内しており、1ファイル1トピックを推奨しています。フロントエンドとバックエンドで規約が違う場合は、YAML frontmatter の paths に対象ディレクトリを書いて適用範囲を絞ると、無関係なコードへ規約が効くのを防げます。

関連記事

• Clineの設定ファイルとインストール完全ガイド｜MCP設定・OS別パス・Hooksを整理：設定がどこに保存されるかをOS別に確認したい段階で読む記事です。
• .clinerulesとは何か？開発現場で注目される理由を徹底解説：ルールファイルの位置づけと書式をさらに詰めるときの参照先です。
• Clineの種類を徹底比較！Roo Cline・Cool Cline・Bao Clineの違い：本家と派生のどれを選ぶかを判断する材料になります。
• Cline v3.25.0でのアップデート内容を詳しく解説: Deep Planning, Focus Chain, Auto Compactなどの新機能：v3系時点の機能追加の経緯をたどれます。
• Claude Codeの使い方｜導入から権限とCLAUDE.md設定まで実務手順：ターミナル中心の代替構成と権限設計を比較する際の対照記事です。