Clineには、実装に入る前にコードベースを調べ上げて計画書を作らせるスラッシュコマンド /deep-planning があります。2025年8月のv3.25.0でFocus Chain、Auto Compactと同時に追加された機能ですが、その後の1年で3つの立場は分かれました。Focus Chainは公式に非推奨となり、Auto Compactは標準機能として残り、/deep-planningは大規模タスク向けの計画コマンドとして動き続けています。本記事は2026年9月20日時点の最新版であるVS Code拡張v4.1.19を対象に、公式ドキュメントの記述と、同じバージョンタグの実装ソースを突き合わせて整理します。公式ドキュメントには旧仕様の説明が残っている箇所があるため、食い違いが出た点は実装側の挙動を本文に採用し、どこが食い違うかも併記します。本文で参照する実装はcline/cline リポジトリのv4.1.19タグ、ドキュメントはCline公式ドキュメント、版の履歴は同リポジトリのCHANGELOGです。
まとめ
Clineの計画・コンテキスト管理まわりの現在地は次のとおりです。
| 機能 | 追加 | v4.1.19時点 | 呼び出し方 |
|---|---|---|---|
| Deep Planning | v3.25.0 | 現行（最終ステップが変更） | チャットで /deep-planning |
| Plan/Actモード | v3.2.0 | 現行（v4.0.0で再実装） | モード切替 |
| Auto Compact | v3.25.0 | 現行 | 自動発動 / /compact |
| Focus Chain | v3.25.0 | 非推奨（代替なし） | なし |
つまり「Deep Planningで計画を作り、Plan/Actで実行し、長くなったらAuto Compactが自動で要約する」という流れは今も有効です。ただし、Deep Planningの最終ステップとスラッシュコマンドの構成はv4.0.0のSDK移行に伴って変わっており、公式ドキュメントの記述が追いついていません。以下、実装ソースで確認できる現在の挙動を中心に見ていきます。
/deep-planningコマンドの4ステップ
組み込みスラッシュコマンドの一覧
Clineのチャット入力欄で / を打つと、利用できるスラッシュコマンドの候補が表示されます。v4.1.19のVS Code拡張が組み込みとして持つのは次の4つです。
| コマンド | 役割 |
|---|---|
| /deep-planning | コーディング前に包括的な実装計画を作成 |
| /compact | 現在のコンテキストウィンドウを圧縮 |
| /smol | /compact の別名 |
| /newtask | 現在のタスクを圧縮し、新しいコンテキストで継続 |
ここで注意が必要なのは/newtaskです。ソース上のコメントには、/newtaskは/compactの別名であり、3つの綴りすべてをwebviewが横取りして同じ圧縮処理を実行する、と明記されています。公式ドキュメントに載っている/newruleと/reportbugは、プロンプト展開がSDKランタイムへ移植されるまで非表示になっています。展開されないままだとコマンドの文字列がそのままモデルへ渡り、ただの雑談に劣化してしまうためです。有効化したSkillも同じ/から呼び出せるので、候補一覧にはこれらに加えてプロジェクト固有のコマンドが並びます。
/deep-planningの実行手順と4ステップの内訳
使い方自体は単純で、実装させたい内容を添えてコマンドを打つだけです。
/deep-planning
既存の認証フローにSAMLシングルサインオンを追加したい。
フロントエンドとバックエンドの両方に手を入れる必要がある。コマンドは組み込みプロンプトへ展開され、Clineは4つのステップを順に実行します。STEP 1のSilent Investigationでは、プロジェクトの構造と言語、既存のクラスや関数の定義、import のパターンと依存関係、依存関係マニフェスト、既存のTODOやFIXMEのマーカーを、解説を挟まずに調べます。プロンプトには、node_modules・venv・vendor といった依存フォルダを除外して出力を簡潔に保つよう具体的な指示まで入っています。なお「黙って調べる」とはいえ完全な沈黙ではなく、ユーザーへの具体的な質問がある場合にだけ発言してよい、という但し書きが付いています。
STEP 2のDiscussionでは、実装計画に影響する簡潔で的を絞った質問だけをします。質問してよい場面は、曖昧な要件の明確化、同程度に妥当な複数の実装方針からの選択、既存システムの挙動や制約についての前提確認、実装に影響する技術的な好みの把握の4つに限定されています。STEP 3のCreate Implementation Plan Documentでimplementation_plan.mdを保存し、STEP 4へ進みます。
STEP 4がタスク作成からハンドオフへ変わった経緯
公式ドキュメントはSTEP 4を「Task Creation（追跡可能な実装ステップを持つ新しいタスクの作成）」と説明していますが、v4.1.19の実装ではこのステップは新しいタスクを作りません。ソースのコメントによれば、旧来の拡張機能はnew_taskツールで実装タスクを作っていたものの、このツールはSDKランタイムには存在しません。そのため現行のSTEP 4は「Hand Off for Implementation」に差し替えられ、計画書を保存したあとは計画の要約を提示して実装へ進んでよいかを尋ね、ユーザーが明示的に確認するまで実装を開始しない、という動作になっています。
提示の際は「完全な内訳は @implementation_plan.md を参照」のように計画書を参照させ、実装中に参照できるようにする指示も入っています。つまり、コマンド1回で計画から実装まで自動的に流れる作りにはなっておらず、計画書ができた時点でユーザーの確認を求めるようプロンプトが指示していると理解しておくのが正確です。これはプロンプトによる指示であって、実装の開始を機械的に阻止する承認機構ではありません。「/deep-planningを打てばタスクが自動生成される」と書かれた解説を見かけたら、v3系の挙動である可能性を疑ってください。
implementation_plan.mdの8セクション構成
STEP 3で出力されるimplementation_plan.mdは、ワークスペースに残るただのMarkdownファイルです。書式は自由ではなく、組み込みプロンプトが次の8セクションを持つ構成を指定しています。
| セクション | 書く内容 |
|---|---|
| Overview | 目的の一文と、範囲・背景・方針 |
| Types | 型定義・インターフェース・列挙・データ構造 |
| Files | 新規・変更・削除/移動するファイルと設定更新 |
| Functions | 追加・変更・削除する関数とファイルパス |
| Classes | 追加・変更・削除するクラスと継承関係 |
| Dependencies | 追加パッケージ・バージョン変更・統合要件 |
| Testing | テストファイルの要件と検証方針 |
| Implementation Order | 競合を避ける変更順序の番号付き手順 |
プロンプトは品質基準として、ファイルパス・関数名・クラス名を正確に書くこと、暗黙の了解を前提にせず網羅的に書くこと、そして別の開発者が追加調査なしに実行できる程度に詳細であることを求めています。ファイルとして残る以上、内容に納得できなければ承認前に自分で書き換えられますし、レビュー相手に渡すこともできます。人間が読んで判断するための成果物として設計されている、と考えると位置づけがつかみやすくなります。
Plan/Actモードと/deep-planningの使い分け
Planモードで実行できるコマンドの範囲
Plan/Actは、考える作業と手を動かす作業を分けるClineの二段構えのモードです。公式ドキュメントはPlanモードについて「ファイルの変更もコマンドの実行もできない」と説明していますが、v4.1.19の実装はもう少し緩やかです。ソースのコメントには、Planモードは読み取り専用の調査のためにrun_commandsを使える状態に保つ、と明記されています。そのうえで、弱いモデルがこれを使ってファイルを編集してしまうため、PlanプリセットがblockFileEditingCommandsを設定している場合に限り、実行前にコマンドをブラックリストと照合して、ファイル変更に見えるものをエラーとして拒否します。
この挙動が入ったのはv4.1.4です。CHANGELOGには、プロンプトによる抑止だけに頼るのをやめてPlanモードでファイル編集系のシェルコマンドを強制的に拒否するようにした、読み取り専用の調査は引き続き動作するが、ファイル操作・インプレース編集・ファイルへのリダイレクト・変更を伴うgitサブコマンド・パッケージのインストールは拒否される、と書かれています。リダイレクト先が一時領域やヌルデバイスの場合は例外として通ります。ブラックリストにはrm・mv・cp・touch・mkdir・chmodといったPOSIX系や、del・copy・remove-itemなどのWindows/PowerShell系が並びます。
重要なのは、ソース自身がこれを「単純なブラックリストであってシェルインタプリタではない」と断っている点です。クォートで囲んだbash -cの中に隠したコマンドや、python -c経由の書き込みは捕捉しきれないと明記されており、Planモードは安全のための境界ではなく、モデルがうっかり編集に走るのを止める仕組みだと理解しておく必要があります。
計画がまとまったらActモードへ切り替えます。このときPlanモードでの会話履歴はそのまま引き継がれるので、議論した内容を改めて説明し直す必要はありません。公式ドキュメントはActモードから直接始めることも可能だとしたうえで、計画フェーズがClineに必要な文脈を作るため、先に計画することを推奨しています。
タスク規模別の使い分け3パターン
Planモードと/deep-planningのどちらを使うかは、タスクの規模で決めるのが公式の指針です。
| 規模 | 進め方 | 例 |
|---|---|---|
| 小 | Actモードのみ | タイポ修正・import追加・設定値の更新 |
| 中 | Plan からAct へ | APIエンドポイント追加・UIコンポーネント実装 |
| 大 | /deep-planning | 前後端をまたぐ機能追加・大規模リファクタ |
公式が小さなタスクの条件として挙げているのは、変更量の少なさそのものではなく解決方法がすでに明らかであることです。タイポ修正や確立されたパターンの踏襲のように答えが見えている作業では、計画フェーズは単に往復を増やします。逆に、複数ファイルに波及する変更や設計判断を伴う作業、複数セッションにまたがる作業では、計画書という参照先があるほうが途中の方針のぶれを抑えられます。「複数ファイルに波及するか」「一度で終わらないか」が/deep-planningを選ぶ目安になります。
PlanとActへの個別モデル割り当て設定
Clineの設定には「Use different models for Plan and Act」という項目があり、有効にするとモードを切り替えたときに使用モデルも自動で切り替わります。計画には推論の強いモデル、実装には速いモデルという組み合わせが想定されており、公式ドキュメントはコスト重視・品質重視・速度重視の3パターンを例示しています。モデルの選択はモードごとに保持されるため、往復しても設定し直す必要はありません。プロバイダやモデルの設定そのものはClineの設定ファイルとインストール完全ガイド｜MCP設定・OS別パス・Hooksを整理で扱っています。
Focus Chainの廃止理由と現行版での進捗管理
Focus Chain廃止の公式説明
Focus Chainは、長いタスクの間Todoリストを自動生成して維持し、進捗を追跡する機能として v3.25.0 で追加されました。しかし2026年9月時点の公式ドキュメントの非推奨一覧では、Focus ChainはDeprecated（代替機能なし）として掲載されています。
理由として公式が挙げているのは、現在のハーネスの上に独立した機能として載せておくだけの追加的な利点が、社内テストで確認できなくなったという点です。あわせて、Focus ChainのTodoリストと従来のTodoファイルの挙動は現在のCline体験の一部ではなくなること、新しいハーネスはFocus Chainという層に頼らずにタスク実行とコンテキスト管理を扱う設計であることが明記されています。非推奨一覧の前書きは、こうした見直しの背景として新しいエージェントアーキテクチャによる変更を挙げており、v4.0.0でVS Code拡張が共通のCline SDKベースのランタイムへ移行したことが対応する動きにあたります。
したがって、Focus Chainの設定項目やリマインダー間隔を前提にした手順は、現行版では再現しません。長いタスクの進捗管理が必要なら、/deep-planningでimplementation_plan.mdのような参照先をファイルとして残し、実装中にそれを参照させる形に寄せることになります。前述のとおり/newtaskは新しいタスクを作らず圧縮を行うコマンドなので、タスクを分けたい場合は手動で新規タスクを開始してください。
非推奨一覧に並ぶ3機能
非推奨一覧にはFocus Chainを含めて3つの機能が掲載されています。いずれも主な対象はVS Code拡張です。
| 機能 | 状態 | 推奨される代替 |
|---|---|---|
| .clineignore | 近く廃止 | Block Ignored File Access プラグイン |
| Explain Changes | 廃止済み | Clineに説明を求める |
| Focus Chain | 廃止済み | なし |
.clineignoreについては、もともとコンテキストへ自動で読み込むファイルを制御する仕組みであって、アクセスそのものを防ぐ設計ではなかったこと、シェルコマンド経由では依然として到達できるため誤った安全感を与えかねないことが廃止の理由として説明されています。代替として案内されているプラグインも、ワークスペースの.gitignoreを使って読み書き系ツールを塞ぐだけです。シェルコマンドは塞がないため、こちらもセキュリティ境界として扱うべきではないと明記されました。先ほどのPlanモードのブラックリストと同じ断り書きで、この2つの仕組みはいずれもセキュリティ境界として設計されていないと公式が明示しています。ルールファイル側の記法は.clinerulesとは何か？開発現場で注目される理由を徹底解説にまとめています。
Auto Compactと手動の圧縮コマンド
自動圧縮の発動条件と2つの戦略
Auto Compactは、会話がモデルのコンテキストウィンドウ上限に近づいたときに自動で要約を作る機能です。v4.1.19のSDKでは、しきい値と挙動が定数として定義されています。
| 定数 | 既定値 | 意味 |
|---|---|---|
| COMPACTION_TRIGGER_RATIO | 0.9 | 入力予算に対する発動しきい値 |
| DEFAULT_TARGET_RATIO | 0.7 | しきい値に掛ける圧縮後の目標 |
| LONG_CONVERSATION_TARGET_RATIO | 0.5 | 長い会話で使う目標 |
| DEFAULT_PRESERVE_RECENT_TOKENS | 20,000 | 要約せず残す直近分の上限 |
| DEFAULT_MAX_INPUT_TOKENS | 128,000 | 上限不明時の既定入力枠 |
ここから分かるのは、圧縮が会話全体を要約1本へ置き換えるわけではないという点です。agentic方式では直近分がそのまま保持され、それより前が要約に置き換わります。ただし保持量は2万トークン固定ではなく、この上限と今回の圧縮目標のうち小さいほうが採用されます。目標そのものも入力予算の7割ではなく、発動しきい値に0.7を掛けた値です。会話が5往復以上で、かつモデルの最大出力トークンが入力予算を下回る場合には、入力予算の0.5倍が目標になります。発動判定も「9割を超えたら」ではなく9割に達した時点で、しかも入力予算はプロバイダが実際に報告したトークン数で補正されるため、見かけの文字数から予想した位置とはずれます。
圧縮処理には2つの戦略があり、既定はモデルに要約させるagentic方式です。agentic方式の実行が例外で失敗した場合は、決定的に動作するbasic方式へフォールバックします。また、プロバイダから「コンテキストウィンドウ超過」を返されて復旧する局面でも、最初からbasic方式が使われます。復旧処理が別のモデル呼び出しの成否に依存しないようにするための設計です。なお、要約が空だったり予算が足りなかったりして結果が得られなかった場合は、basicへ切り替えるのではなくその回の圧縮を見送ります。
公式ドキュメントには「それ以外のモデルではAuto Compactを有効にしていてもルールベースの切り詰めにフォールバックする」という趣旨の注記がありますが、実装で確認できるフォールバックの条件はモデルの種類ではなく、設定された戦略と失敗・超過復旧です。圧縮の一般的な仕組みと注意点はauto-compactとは？AIコーディングエージェントの自動コンテキスト圧縮を仕組み・使い方・注意点まで解説で扱っています。
要約が走ったあとで元の状態に戻したい場合は、チェックポイントからタスクの状態を圧縮前まで巻き戻せます。要約のツール呼び出しより前のメッセージを編集した場合も同様に、その時点まで会話が復元されます。
/compact・/smol・/newtaskの関係
自動発動を待たずに自分で圧縮したいときは/compactを使います。/smolはその別名で、/newtaskもv4.1.19では同じ圧縮処理へ集約されています。ソースのコメントは、要約されたきれいなコンテキストウィンドウで作業を続けるという/newtask本来の目的は圧縮で達成できるため、旧来のnew_taskツールなしに別名として扱う、と説明しています。
そのため、v3系の解説でよく見る「同じタスクを続けるなら/smol、仕切り直すなら/newtask」という使い分けは、現行のVS Code拡張には当てはまりません。3つのどれを打っても結果は同じだと考えて差し支えありません。デバッグや検討が煮詰まってコンテキストが埋まってきたら圧縮する、タスクそのものを分けたいなら手動で新しいタスクを始める、という整理になります。
v3.25.0から現行v4.1系までの変遷と更新手順
v3.25.0（2025-08-15）の追加機能
本記事の3機能がそろって入ったのがv3.25.0です。CHANGELOGでは、Todoリストを自動作成・維持して進捗をリアルタイムに追跡するFocus Chain、トークン上限エラーを防ぐために古いメッセージを自動圧縮するAuto Compact、構造化された4ステップの実装計画のための新しいスラッシュコマンド/deep-planningの3点が先頭に並びます。当時のDeep Planningは「Focus Chainと連携して進捗を自動追跡する」と説明されていましたが、この連携は前述のとおり現在は存在しません。このほか、OpenRouterとClineプロバイダでClaude Sonnet 4の200kコンテキストウィンドウに対応し、Requestyプロバイダでカスタムベース URLを設定できるようになっています。なお、Plan/Actモード自体はこれより古く、v3.2.0（2025-01-21）でトグルとして追加されました。
v4.0.0（2026-06-26）のSDK移行による変更点
メジャーバージョンが上がったv4.0.0は、VS Code拡張をSDKベースのランタイムへ移行する大規模な変更でした。エージェントのターン、ツール、Plan/Actモードの調整、MCP、チェックポイント、テレメトリ、プロバイダ変更、圧縮処理、ミス上限、タスク履歴が、共通のCline SDKセッション層を通るようになっています。本記事で触れてきたnew_taskツールの不在やスラッシュコマンドの整理は、いずれもこの移行の副作用です。Plan/Actについては、SDKのコーディネータ経由に作り直され、PlanからActへ切り替えたあとに処理が自動で継続する挙動が加わりました。これとは別に、モデルが自分でPlanからActへ切り替える動作がv4.1.4で削除されています。CHANGELOGは、Planモードから出る操作はモデルがターンの途中で判断するのではなくユーザーが行うようになった、と説明しています。切り替えたあとの継続と、切り替えそのものを誰が決めるかは別の話なので、混同しないでください。
運用面で影響が大きいのは、コマンドの自動承認が既定で無効になった点です。新規設定とリセット後の設定がより安全側に倒れました。このほか、Skills・MCPサーバー・プラグインを管理するCustomizeマーケットプレイスの追加、実行中に送ったメッセージをキューへ積む機能、ClinePassの拡張への搭載などが同時に入っています。一方でExplain Changesは移行時の整理として削除されました。サブエージェントもこのとき一時的に無効化されましたが、現在は既定で有効な実験的機能として復帰しており、use_subagentsツールを設定から無効化することで停止できます。
VS Code拡張とCLIそれぞれのバージョン確認方法
VS Code拡張の最新版はv4.1.19（2026-09-17公開）です。Marketplaceの拡張機能（発行元 saoudrizwan、拡張ID saoudrizwan.claude-dev）も同じバージョンと日付で配信されており、インストール数は約538万件です。自分の環境に入っているバージョンは、VS Codeの拡張機能ビューでClineを開き、詳細画面に表示される番号で確認できます。自動更新が有効なら基本はVS Codeに任せて構いませんが、上の最新版と番号が違う場合は手動で更新してください。更新後にリリースノートを確認したい場合はGitHubのcline/clineリポジトリのCHANGELOGが一次情報になります。
CLIは拡張機能とは別に配布されており、バージョン番号の体系も異なります。CLI側はコマンドで確認と更新ができます。
cline version # CLI のバージョンを表示
cline update # 更新を確認し、あれば適用
cline -p "この変更の影響範囲を調べて" # プランモードで起動CLIには-p, --planオプションがあり、プランモードで起動できます。モードや自動承認を変えるオプションを付けずにプロンプトだけを渡した場合は、自動承認を有効にしたActモードで始まるのが既定の挙動です。CLIを含めたClineの全体像と料金体系はClineとは？VS Code拡張とCLIの使い方・料金・自動承認設定を実装目線で解説で扱っています。
よくある質問
/deep-planningを実行すると実装まで自動で進みますか？
自動では進まない設計です。v4.1.19の組み込みプロンプトでは、最終ステップは計画書を保存したうえで要約を提示し、実装へ進んでよいかをユーザーに尋ねる「Hand Off for Implementation」で、ユーザーが明示的に確認するまで実装を開始しないよう指示されています。あくまでプロンプトによる指示なので、実装を機械的に止める仕組みがあるわけではありません。公式ドキュメントにはこのステップを「新しいタスクの作成」と書いた旧仕様の記述が残っていますが、新しいタスクを作るnew_taskツールはSDKランタイムに存在しません。
Planモードではコマンドを一切実行できないのですか？
いいえ。v4.1.19の実装では、Planモードでも調査目的の読み取り専用コマンドは実行できます。制限されるのはファイルを変更するコマンドで、rmやmvなどのブラックリストと、ワークスペースへの出力リダイレクトが拒否されます。ただし/dev/nullなどのヌルデバイスと、/tmp・/var/tmp・TMPDIRといった一時領域への書き出しは、長時間かかる出力を退避する用途として許可されています。ただしソース自身が単純なブラックリストでありシェルインタプリタではないと断っており、クォート内に隠した変更までは捕捉できません。セキュリティ境界としては扱わないでください。
Focus Chainが使えなくなったのはなぜですか？
現在のハーネスの上に独立した機能として維持するだけの追加的な利点が、社内テストで確認できなくなったためだと公式の非推奨ページで説明されています。新しいハーネスがFocus Chainという層に頼らずにタスク実行とコンテキスト管理を扱う設計になったことが背景です。代替機能は案内されていません。なお、この非推奨一覧が主な対象として挙げているのはVS Code拡張です。
/smolと/newtaskはどう使い分けますか？
v4.1.19のVS Code拡張では使い分けは不要です。/compact・/smol・/newtaskの3つはすべて同じ圧縮処理の別名として扱われ、webviewがどの綴りも同じ処理へ振り分けます。タスクを実際に分けたい場合は、コマンドではなく手動で新しいタスクを開始してください。
/deep-planningと仕様駆動開発はどう違いますか？
計画や仕様を先に文書化してから実装へ進むという発想は共通しています。違いは扱う範囲で、/deep-planningは1つのタスクの前段に調査と計画書生成を挟むスラッシュコマンドであり、仕様のライフサイクル全体を管理する仕組みではありません。要件から設計、タスク分解までを継続的に運用したい場合は、専用ツールを検討することになります。考え方と手順はOpenSpecとは？AI仕様駆動開発(SDD)の導入手順・CLI操作とSpec Kit比較で整理しています。
