Claude Code を VS Code で使うとき、最初に迷うのは「CLI と何が違うのか」です。ターミナルで claude を起動すれば十分に見える一方、VS Code 拡張には inline diff、plan review、選択範囲の @mention、会話タブ、IDE の diagnostics 連携があります。便利ですが、設定や権限を曖昧にすると、CLI と IDE のどちらが作業を持っているのか分からなくなります。
私も最初は「普段のエディタの横に Claude が出るだけ」と軽く見ていました。実際に使うと、変更の受け入れ、選択範囲の渡し方、Jupyter 実行、Chrome 連携、MCP 管理の境界がターミナル版と少し違います。ここを理解しないまま Auto 相当の権限を開くと、IDE 設定ファイルや開いているファイルの文脈までまとめて作業対象に入りやすいです。
この記事では、Claude Code VS Code拡張を IDE 内の作業レーンとして設計する方法を整理します。Claude Code 全体の導入順は Claude Code の使い方 実践ガイド、MCP server の追加手順は Claude Code MCP ガイド、常時表示の運用 UI は Claude Code status line 設計ガイド、ブラウザ操作は Codex browser use ガイド や Codex Chrome extension ガイド に分けています。CLI と IDE のどちらを入口にするか自体で迷うなら Claude Code vs Codex CLI 比較 を先に読み、GitHub PR の通常レビューは Claude Code code review 実践ガイド、auth・permission・workflow差分をcommit前に狭く確認する場合は Claude Code security review 設計ガイド へ進むと役割が混ざりません。
今回扱うのは、CLI の総論ではありません。VS Code の中で、どの作業を Claude Code 拡張へ寄せ、どこから CLI や別レーンへ逃がすかです。
先に結論: VS Code拡張は「差分を見ながら進める作業」に使う
Claude Code の公式 docs では、VS Code 拡張は IDE 内のネイティブな GUI として説明されています。inline diff、plan review、@mention、キーボードショートカット、会話履歴、複数タブが主な価値です。つまり、強いのは「コードと差分を見ながら人間が途中判断する作業」です。
私なら、最初は次のように分けます。
| 作業 | 優先する入口 | 理由 |
|---|---|---|
| 1ファイルから数ファイルの修正 | VS Code拡張 | inline diff と plan review で確認しやすい |
| 選択範囲への質問、局所リファクタ | VS Code拡張 | @mention で対象行を狭く渡せる |
| 大量ログ、長い調査、複数 repo 横断 | CLI | terminal 出力、file-based workflow、resume が扱いやすい |
| MCP server 追加や credential 確認 | CLI + VS Code拡張 | 追加は CLI、管理は /mcp で確認する |
| 認証付きブラウザ操作 | Chrome連携や専用plugin | VS Code拡張だけで権限境界を説明しにくい |
VS Code拡張は CLI の下位互換ではありません。逆に、CLI の完全な置き換えでもありません。編集画面に近いほど VS Code拡張、実行環境や長い調査に近いほど CLI と分けると扱いやすいです。
最初に確認する4つの前提
導入前に見るべき条件は多くありません。
- VS Code 1.94.0 以上か
- Claude の有料 subscription または Claude Console account で sign in できるか
- chat panel 用の bundled CLI と、terminal で使う standalone CLI を混同していないか
- workspace が信頼済みか
公式 docs では、VS Code拡張は chat panel 用に CLI を同梱します。ただし、VS Code の integrated terminal で claude を実行したい場合は standalone CLI のインストールが別に必要です。ここを混同すると、「拡張は動くのに terminal の claude が見つからない」という状態になります。
私なら、導入直後にこの3コマンドだけ確認します。
code --version
claude --version
which claudeclaude が見つからないなら、VS Code拡張の問題ではなく standalone CLI の PATH 問題です。逆に、terminal では動くのに拡張が見えない場合は、VS Code version、workspace trust、Spark icon、拡張の有効状態を見ます。
plan review は「最初の承認点」として使う
VS Code拡張の価値は、変更前の plan を IDE 内で確認しやすいことです。私は、最初の依頼を必ず plan review に寄せます。
Open a plan first.
Scope the change to src/components/SearchBox.tsx and its test.
Do not edit shared layout files unless you explain why.
After the plan, wait before applying edits.良い plan は、次の4点を含みます。
| 見る点 | 判断 |
|---|---|
| 対象ファイル | 依頼した範囲を越えていないか |
| 変更理由 | 症状ではなく原因へ触れているか |
| 検証方法 | build、test、manual check が具体的か |
| 戻し方 | 失敗時にどこまで戻せるか |
ここで雑な plan のまま進めない方がよいです。Claude Code は賢いですが、IDE の横にいると「少し直して」が増えます。小さな依頼でも、最初に scope と stop condition を固定した方が差分が膨らみにくいです。
inline diff は「受け入れ単位」を小さくする
VS Code拡張では、Claude の変更を IDE の diff viewer で見られます。ここで大事なのは、diff が見やすいことではなく、受け入れ単位を小さくできることです。
私は次の順番で見ます。
- shared file が混ざっていないか
- generated file や lock file が不要に変わっていないか
- 変更が plan の順番と対応しているか
- test 追加が実装に寄りすぎていないか
- コメントや文言が過剰に増えていないか
特に UI 実装では、Claude が helper や style token を増やしがちです。1画面の修正なのに design system 全体へ差分が伸びたら、その場で止めます。VS Code拡張は、変更を受け入れる前に「この hunk は要るが、この hunk は要らない」を判断しやすいのが強みです。
@mention は選択範囲を渡す道具として使う
VS Code拡張では、現在の file や選択範囲を @mention として渡せます。これは便利ですが、開いているものを何でも渡す癖がつくと、不要な context を増やします。
私は、選択範囲を使う依頼では必ず次の形にします。
Use only the selected lines and the adjacent type definitions.
Explain the failure mode first.
Then propose the smallest edit.
Do not inspect unrelated files unless the selected code imports them directly.@mention の目的は、Claude に全部読ませることではありません。今見ている行から判断してほしいと伝えることです。広い調査が必要になったら、その時点で CLI か通常の repo read に切り替えます。
CLI と拡張の役割を混ぜない
公式 docs では、VS Code拡張と CLI は会話履歴を共有でき、拡張から CLI へ続きも持ち込めます。これは便利ですが、運用では混乱の元にもなります。
私なら、次のルールにします。
| 迷う場面 | 判断 |
|---|---|
| 拡張の chat panel で進めた変更を terminal で続けたい | claude --resume で同じ会話を選ぶ |
| terminal で長い build log を見せたい | paste せず log file を作って読ませる |
| VS Code integrated terminal に巨大入力を貼りたい | 避ける。file-based workflow にする |
| external terminal から IDE diff を使いたい | /ide で VS Code へ接続する |
特に長い log は貼り付けません。Claude Code docs でも、VS Code integrated terminal は巨大 paste で文字を落とすことがあるため、長い入力はファイルにして読ませる方がよいと説明されています。ここは実務でもかなり効きます。
MCP は「追加はCLI、確認は拡張」に分ける
VS Code拡張から MCP を使うとき、最初に覚えることは単純です。MCP server の追加は claude mcp add を CLI で行い、既存 server の接続確認や認証管理は chat panel の /mcp でもできます。
claude mcp add --transport http github https://api.example.com/mcpその後、VS Code拡張の chat panel で次を確認します。
/mcpここで server が connected か、認証が失敗していないかを見ます。MCP の stdio / remote HTTP / OAuth scope / read-write 分離は Claude Code MCP ガイド の領域です。VS Code拡張の記事で全部扱うと、IDE 操作の話と接続統制の話が混ざります。
ただし、VS Code拡張には IDE 用の built-in MCP server があります。これは selection、diff、diagnostics、Jupyter 実行など IDE 側の機能をつなぐためのものです。組織で PreToolUse hook や MCP allowlist を使うなら、mcp__ide__getDiagnostics と mcp__ide__executeCode のような tool 名が見えることを前提にしておきます。
diagnostics は読むが、Jupyter実行は別承認にする
IDE MCP server のうち、diagnostics を読む tool は read-only です。VS Code の Problems panel を参照できるので、TypeScript error や linter error の切り分けには向いています。
一方、Jupyter notebook の Python code 実行は read-only ではありません。公式 docs では、mcp__ide__executeCode は VS Code 側の Quick Pick confirmation が入り、キャンセルすれば何も実行されないと説明されています。これは重要です。
私なら、notebook を含む repo では次をルールにします。
Claude may read diagnostics.
Claude must ask before proposing notebook execution.
Do not run notebook cells that load secrets, customer data, or network resources.
Use a small synthetic dataframe when possible.Jupyter 実行は便利ですが、notebook は手元の kernel state を持っています。コード差分の編集と同じノリで実行まで進めない方がよいです。
権限モードは workspace の信頼度で決める
VS Code拡張には initialPermissionMode があります。設定値には default、plan、acceptEdits、bypassPermissions などがあります。私は最初から Auto 相当に寄せません。
| workspace | 初期モード | 理由 |
|---|---|---|
| 初めて開く repo | plan | まず方針だけ出させる |
| 社内 repo / 機密情報あり | default | tool 実行や編集を確認しやすい |
| 小さな個人 repo | acceptEdits | 差分を見ながら進めやすい |
| disposable sandbox | bypassPermissions を検討 | internet なし、破棄可能な環境に限る |
公式 docs でも、auto-edit permissions を有効にすると settings.json や tasks.json のような VS Code が自動実行し得る設定ファイルを変更できる点に注意が必要だと説明されています。信頼できない workspace では Restricted Mode を使い、Manual 寄りに始める方が堅いです。
Chrome連携は「IDEの便利機能」として雑に開けない
Claude Code は VS Code拡張から Chrome 連携も使えます。公式 docs では、Chrome extension が入っていれば VS Code では追加フラグなしで利用できると説明されています。
ただし、Chrome 連携は IDE 内の diff とは別物です。ログイン済み browser state、site permission、visible tab、フォーム操作が絡みます。私は、VS Code拡張から使う場合でも次を必ず分けます。
Browser access rules:
- Use Chrome only for the specified localhost or staging URL.
- Confirm the visible account and environment before acting.
- Do not submit, delete, publish, export, or change permissions.
- Stop if the page switches to production or billing.画面確認が目的なら、Chrome 連携は強力です。ですが、単なるコード編集や diff review に Chrome を混ぜる必要はありません。ブラウザ状態を使う作業は、コード編集とは別の承認点として扱います。
team配布で決める設定
チームで VS Code拡張を使うなら、個人の好みに任せる前に最低限の設定方針を決めます。
| 項目 | 方針 |
|---|---|
initialPermissionMode | workspace の種類ごとに標準を決める |
useTerminal | graphical panel と terminal mode のどちらを標準にするか決める |
autosave | Claude が読む前に保存される前提を共有する |
respectGitIgnore | 無視ファイルを検索対象にしない前提を維持する |
disableLoginPrompt | third-party provider 利用時だけ検討する |
allowDangerouslySkipPermissions | sandbox 以外では標準にしない |
組織配布なら、VS Code の拡張設定だけでなく Claude Code settings、managed settings、MCP allowlist まで見る必要があります。settings.json に閉じる話ではありません。MCP server や hooks まで配るなら Claude Code managed settings 設計ガイド と MCP エンタープライズ運用ガイド 側で統制します。社内の許可境界やレビュー前提を文章で固定したい場合は、あわせて AIコーディングツールの社内ガイドライン へつなぐと、IDE 個別設定だけが先行する事故を防ぎやすいです。
実務で使う最小runbook
私が新しい repo で Claude Code VS Code拡張を使い始めるなら、この順番にします。
- VS Code version、workspace trust、sign in、standalone CLI を確認する
- 最初の会話は plan mode にする
- 対象 file と stop condition を依頼文に書く
- inline diff で shared file と generated file を先に見る
- diagnostics は読ませるが、notebook 実行は別承認にする
- MCP server 追加は CLI で行い、
/mcpで接続確認する - Chrome 連携は対象 URL、account、許可 action、停止条件を固定した時だけ使う
- 長い log や巨大 paste はファイルにして読ませる
テンプレート化するなら、最初の依頼はこの程度で十分です。
Use Claude Code in VS Code for this task.
Start with a plan and wait before edits.
Scope changes to the selected file and its direct test only.
Use inline diffs for every edit.
You may read diagnostics.
Do not run notebook cells, use Chrome, add MCP servers, or edit VS Code settings unless I explicitly ask.
After edits, run the smallest relevant verification and summarize the diff.この形なら、VS Code拡張の強みを使いながら、Jupyter、Chrome、MCP、settings 変更を別レーンへ分けられます。
よくある失敗
1. 拡張が入っただけで CLI も入ったと思う
chat panel は bundled CLI で動きますが、terminal の claude は standalone CLI が必要です。which claude で切り分けます。
2. 選択範囲ではなく workspace 全体を読ませる
@mention の価値は対象を狭くできることです。最初から repo 全体を読ませると、VS Code拡張を使う意味が薄れます。
3. Auto 相当の権限を信頼していない repo で使う
settings file や task file の変更は IDE 側の実行面に影響します。初見 repo では plan / default から始めます。
4. MCP 追加と IDE 操作を同じ依頼に混ぜる
server を追加しながらコードも直すと、接続権限と編集権限が混ざります。追加、確認、作業を分けます。
5. Chrome連携を画面確認以外にも広げる
Chrome はログイン済み状態を持ちます。API や専用 plugin で済む作業を Chrome へ逃がすと、監査しづらくなります。
参考資料
- Claude Code Docs: Use Claude Code in VS Code
- Claude Code Docs: Settings
- Claude Code Docs: Permissions
- Claude Code Docs: Use Claude Code with Chrome
- Claude Code Docs: Configure your terminal for Claude Code
まとめ
Claude Code VS Code拡張は、CLI を置き換えるためのものではなく、IDE 内で差分と選択範囲を見ながら進めるための作業レーンです。inline diff、plan review、@mention、diagnostics は日常のコード修正に効きます。一方で、MCP 追加、Chrome 連携、Jupyter 実行、権限モード変更は別の承認点として扱うべきです。
最初から全部を便利に使おうとせず、plan、scope、diff、verification の順番を固定する。これだけで、VS Code拡張は「横にいるAI」ではなく、レビュー可能な開発ワークフローの一部になります。