Claude Code VS Code連携の設定と使い方

『VS Code』で『Claude Code』を使い始めるなら、いちばん近道なのはVisual Studio Marketplaceから公式拡張を入れて、そのままパネルを開く流れです。
この記事では、初回導入で迷いやすい拡張設定と ~/.claude/settings.json の役割分担、権限モードの選び方を、整理します。
さらに @ メンションや Plan mode、統合ターミナルの claude 連携までを一気に解説します。

Claude Code の VS Code連携でできること

拡張で得られる体験

『VS Code』で『Claude Code』を使うなら、いちばん素直な入り口は公式拡張です。
拡張機能ビューは macOS なら Cmd+Shift+X、Windows と Linux なら Ctrl+Shift+X で開けます。
検索欄に『Claude Code』と入れて公式拡張を見つけ、そのままインストールすれば導入自体は短時間で終わります。
導入直後にパネルやアイコンが見当たらないときは、『VS Code』を再起動するか Developer: Reload Window を実行すると表示が戻ることがあります。

起動後の体験がブラウザ版のAIツールと違うのは、会話と編集が同じ画面でつながっている点です。
エディタ内にインライン差分が出るので、提案内容を読んでそのまま適用可否を決められます。
会話では @ メンションでファイルや文脈を渡せて、Plan mode では「いきなり書き換える」のではなく、まず変更案を出させる流れを取れます。
大きめのリファクタ前に Plan mode で変更案を眺め、問題なければ適用する運用にすると、変更を一旦止めて考える余白が生まれます。
勢いのまま編集を走らせずに済むので、設計を崩したくない場面と相性がいい印象です。

パネルはコマンドパレットや拡張の導線から開けますが、実際には導入後に左側へ追加される『Claude Code』の入口から入る場面が多くなります。
初回オンボーディングでは、利用開始に必要な案内に沿ってサインインや基本設定を進める流れになります。
ここで会話タブや履歴の見え方を一度触っておくと、その後の作業が止まりません。
複数会話タブを並べられるので、実装相談、レビュー、調査メモを分けて置いておけるのも拡張ならではです。

GitHub - anthropics/claude-code: Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.

Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster

github.com

CLI と拡張の役割分担

『Claude Code』の拡張には CLI も同梱されています。
つまり、普段はGUI中心で作業しつつ、必要な場面だけ統合ターミナルから claude を呼べます。
統合ターミナルは macOS なら Cmd+\、Windows と Linux なら Ctrl+\` で開けます。
ここで claude` を実行すると、拡張だけでは触れにくい高度な機能や、ターミナル前提の操作にそのまま入れます。

使い分けはシンプルです。
拡張側は、エディタで差分を見ながら会話したいとき、履歴を残したいとき、複数の相談をタブで並べたいときに向いています。
CLI 側は、自動化、スクリプト連携、より細かい操作をまとめて流したいときに向いています。
『VS Code』の中で完結させるなら統合ターミナルの claude が自然ですが、外部ターミナルで長めの処理を流し、結果確認だけ『VS Code』へ戻す運用も選べます。

設定の置き場所が分かれている点も、この役割分担を理解すると整理できます。
『VS Code』の拡張設定はIDE内の表示や動作に関わるもので、~/.claude/settings.json は CLI と拡張の両方で共有される『Claude Code』側の設定です。
企業環境で外部プロバイダを使う構成などは後者に寄るため、GUIの見た目調整と認証・接続設定を同じ場所に探しにいかなくて済みます。

導入後にまず目に入る変化として報告されているのが、左のActivity Barへ追加される spark アイコンです。
古い版のままだと拡張が表示されない、設定項目が記事と異なる、などの食い違いが起こり得ます。
実際に使ってみると、拡張だけでも会話、差分確認、Plan mode までは十分に触れられます。
ただ、少し踏み込んで設定の切り分けや高度な操作を試したくなると、統合ターミナルで claude が動く状態かどうかで作業の連続性が変わります。
『VS Code』の中で会話パネルとターミナルを行き来できると、ウィンドウを切り替える回数が減り、集中が途切れにくくなります。

次に詰まりやすいのが、拡張そのものではなく『Claude』側の利用条件です。
個人利用なら通常のアカウントでサインインする流れを想定しやすい一方、組織利用では「そのアカウントで利用できるか」「社内で許可された接続経路か」が先に確認すべきポイントになります。
これらの違いを見落とすと、記事の手順どおりに進めても画面や導線が異なる場合があります。
組織構成や認証方式は環境に依存するため、必要に応じて公式ドキュメントや管理者に確認してください。

ショートカット早見表

初回セットアップでは、検索窓よりショートカットを覚えておいたほうが手順がぶれません。
『VS Code』で最低限使う操作は 3つで、拡張機能ビュー、設定、統合ターミナルです。
ここを手でたどるより、キー操作で開けたほうが記事の画面と手元の動きが揃います。

この 3つだけでも覚えておくと、拡張の検索、設定の見直し、claude の切り分けまでが 1 つの流れでつながります。
実際に触っていると、拡張を入れたあとに設定画面で項目名を確認し、そのまま統合ターミナルでコマンドを試す、という往復が何度も出てきます。
マウスで毎回メニューを開くより、キー操作で移れるほうがテンポが崩れません。

企業環境のログインとプロバイダ設定

企業環境では、個人向けのサインイン画面がそのまま出るとは限りません。
Amazon BedrockGoogle Vertex AIAzure AI Foundryのような外部プロバイダ経由で運用する構成では、ログイン方法と設定の置き場所が変わります。
こうした環境では、拡張側で通常のログインを促すより、Disable Login Prompt を有効にして、~/.claude/settings.json 側でプロバイダ設定を持たせる運用が紹介されています。

ここで押さえたいのは、『VS Code』の拡張設定と ~/.claude/settings.json は役割が違うという点です。
前者は IDE 内での表示や拡張動作を調整する場所で、後者は『Claude Code』本体の共有設定として働きます。
企業の認証やプロバイダ指定が絡む場合、編集先を取り違えると設定したつもりでも反映されません。
この線引きが見えていると、「画面の挙動を変えたいのか」「接続先そのものを変えたいのか」で迷わず分けられます。

セキュリティ面では、Windows の扱いにも少し注意が必要です。
とおり、WebDAV を有効にしたり、\\* を含むパスへ広くアクセス許可を与えたりする運用は避ける前提で見たほうが整理しやすいのが利点です。

実務目線では、個人環境の感覚で「まず拡張を入れてログイン」と進めるより、「自分の組織ではどのプロバイダで認証するか」が先に定まっているほうが導入の詰まりが少なくなります。
特にプロキシや IdP を挟む構成では、ログイン画面の見え方自体が違うので、一般向けのオンボーディングとは見え方や手順が異なるため、対応しきれないことがあります。
その前提を持っておくと、インストール後の違和感を不具合と誤解せずに進められます。

VS Code拡張機能のインストール手順

拡張機能の入手とインストール

『VS Code』を開いたら、まず拡張機能ビューに入ります。
ショートカットは前述の早見表どおりで、macOS なら Cmd+Shift+X、Windows と Linux なら Ctrl+Shift+X です。
左サイドバーの拡張機能ビューが開いたら、検索欄に Claude Code と入力します。

ここで見ておきたいのは、名前が似た拡張と取り違えないことです。
Visual Studio Marketplaceの掲載名はClaude Code for VS Codeで、提供元が Anthropic になっているものが公式です。
Claude Code for VS Code - Visual Studio Marketplaceでも正式名と発行元を照合できます。
検索結果に関連拡張が並ぶことがありますが、正式名と発行元の2点が一致していれば迷いません。

インストールはそのまま Install を押すだけで進みます。
導入直後は会話パネルの位置が思った場所に出ないことがあり、初見だと「入ったのに見当たらない」と感じやすいのが利点です。
実際、筆者も最初は左端のActivity Barを見落として少し探しました。
見つけたあとに spark アイコンをピン留めしておくと、次回から視線の移動が減って手が止まりません。

拡張には CLI も同梱されているので、必要なら『VS Code』の統合ターミナルもその場で開けます。
ショートカットは macOS が Cmd+\、Windows と Linux が Ctrl+\` です。
導入直後に claude` と打って反応を見ると、拡張側の表示と CLI 側の動作を同じウィンドウで切り分けられます。
会話パネルだけで進める場合でも、この確認が1回入るだけで詰まりどころを早めに切り分けられます。

インストールした拡張は通常 Visual Studio Marketplace 上で更新できます。

パネルを開く・初回オンボーディング

インストール後に『Claude Code』を開く方法は2通りあります。
ひとつは左端のActivity Barに追加される spark アイコンから入る方法、もうひとつはコマンドパレットから起動する方法です。
画面レイアウトを変えていてアイコンが埋もれているときは、コマンドパレット経由のほうが見失いません。

パネルが開くと、初回はオンボーディングの案内に沿って進める形になります。
一般的な流れは、利用開始の説明を確認してサインインし、会話パネルを使える状態まで通す、という順番です。
『VS Code で Claude Code を使用する』でも、この導入フローが起点になっています。
前のセクションで触れたとおり、組織認証や外部プロバイダを使う環境では表示される画面が少し異なりますが、パネルを開いて最初の案内を完了させるところまでは共通です。

起動直後の印象としては、拡張を別ウィンドウの道具として使うより、『VS Code』の作業面にそのまま会話が増える感覚に近いです。
コードを見ながら同じ画面内でやり取りできるので、差分確認やファイル参照のたびに別アプリへ飛ばずに済みます。
こうした切り替えの少なさは積み重なると効いてきて、短いレビューや修正確認でも集中が途切れにくくなります。

オンボーディングが終わったあと、パネルが開いたまま反応を見たいときは、簡単な入力を1つ送るか、統合ターミナルで claude が起動するかを見比べると状態を把握しやすくなります。
片方だけ動く場合は、認証か表示のどちらに寄っている問題かをすぐ切り分けられます。

表示されない時の再起動とReload Window

インストールが終わっているのに spark アイコンが出ない、パネルを開いても反応がない、コマンドパレットに項目が見当たらない、という場面では、拡張そのものより『VS Code』側の読み込みが途中で止まっていることがあります。
このときは、いったん『VS Code』を再起動するのが最短です。

再起動までしたくない場合は、コマンドパレットで Developer: Reload Window を実行すると、ウィンドウだけを再読み込みできます。
拡張の追加直後に表示が揃わないときは、この操作で出てくることが珍しくありません。
筆者の手元でも、インストール直後はパネル位置が既定と違って見えず、Reload Window のあとにActivity Barへアイコンが現れたことがありました。
表示されたらその場でピン留めしておくと、次に探す時間が減ります。

それでも画面側が静かなままなら、統合ターミナルを開いて claude の反応を見ると切り分けが進みます。
CLI が動いてパネルだけ沈黙しているなら、拡張 UI の再読み込みやサインイン状態の見直しに寄せて考えられます。
逆に CLI 側も起動しないなら、導入そのものが通っていない可能性を追ったほうが早いです。
会話パネルとターミナルを同じ『VS Code』内で並べて確認できるのは、この拡張の地味に助かるところです。

初期設定で先に決めるべき3項目

権限モード（承認あり/自動適用）の決め方

動き始めた直後にまず決めておきたいのが、変更をどこまで自動で通すかという権限モードです。
最初の設定では 承認あり を基準に置くのが無難です。
これは単に慎重だからではなく、Claude がどの範囲まで触るのかを自分の作業感覚に合わせて把握できるからです。
とくに『VS Code』拡張はインライン差分で変更箇所を追いやすいため、提案内容を見てから通す流れにしておくと初期の学習コストをレビュー時間に変えずに済みます。

この判断は、個人開発かチーム開発かでも変わります。
個人環境では自分が差分の責任をすべて追えるので自動化を広げやすい一方、チームでは「誰がどの設定で動かしたか」が曖昧になるとレビュー観点がぶれます。
最初の数日は承認ありで運用し、触らせてよい作業の輪郭が見えてから自動適用を広げるほうが、設定の意味と実際の挙動が一致しやすくなります。

VS Code設定と settings.json の役割分担

次に整理しておきたいのが、『VS Code』側の拡張設定と ~/.claude/settings.json の役割を混ぜないことです。
ここが曖昧なままだと、どこを直せば挙動が変わるのか見失います。
Use Claude Code in VS Codeでは、前者が IDE 内での拡張の振る舞い、後者が CLI と拡張で共有される『Claude Code』の設定という整理になっています。
つまり、画面の中でどう見せるか、どこまでIDEに寄せるかは拡張設定で持ち、モデル接続やプロバイダ、共有したい既定値は ~/.claude/settings.json に寄せる、という切り分けです。

実務では、この分け方を最初に決めるだけで混乱が減ります。
筆者の手元では、『VS Code』側で UI と権限まわり、~/.claude/settings.json でプロバイダとプロジェクト既定を持つ形にしたところ、チームをまたいでも「その設定はどこにあるのか」で止まりにくくなりました。
拡張設定はそのエディタ体験に閉じた話として扱い、CLI でも同じ前提で動いてほしいものは共有設定に寄せるほうが、統合ターミナルで claude を打ったときの挙動とも揃います。

とくに API キーや接続先プロバイダのような、IDE だけでは完結しない要素は ~/.claude/settings.json に集約しておく考え方が安定します。
拡張側に持たせるのは、IDE の安全設定や UI 関連に絞るほうが保守しやすく、あとで外部ターミナルや CI に設定思想を広げるときも崩れません。
秘密情報そのものはファイルへ直書きせず、環境変数やシークレットストア経由で渡す前提にしておくと、共有設定の置き場所と機密の置き場所を分離できます。

最小構成の考え方は、たとえば次のようにまとめられます。
キー名は公式仕様に沿ったものだけを使う前提で、ここでは「共有設定ファイルにプロバイダ設定を置く」という骨格だけ示します。

{
 "provider": "bedrock"
}

この種の設定を ~/.claude/settings.json に寄せておくと、『VS Code』拡張だけでなく CLI 側の動きも同じ方向に揃えられます。
拡張に CLI が同梱されている構成だからこそ、設定の責務分離を先に決めておく価値があります。

Login Prompt無効化とプロバイダ設定の実践

組織の認証基盤を通す環境では、標準のログイン案内がかえって遠回りになることがあります。
とおり、Bedrock、Vertex、Foundry のような外部プロバイダを使う企業環境では、Disable Login Prompt を有効にして、認証や接続先の前提を ~/.claude/settings.json 側で持つ構成のほうが流れが安定します。
拡張がブラウザログインを促す前提と、実際の社内運用の前提がずれていると、オンボーディングは通っても実行に移せないことがあります。
そうした詰まり方になりやすいからです。

ここでのポイントは、ログイン画面を消すこと自体ではなく、「認証方法は外部プロバイダで決まっている」という前提を『Claude Code』に明示することです。
そうしておくと、会話パネルで始めても統合ターミナルで始めても、同じ接続先の前提で動かせます。
CLI 共有設定の考え方と噛み合うので、拡張だけ直しても CLI では別挙動、というズレも避けやすくなります。

この構成は、企業利用だけでなく複数プロジェクトをまたぐ運用でも効いてきます。
IDE ごとに認証の扱いを変えるより、Claude の動作そのものに関わる設定をホームディレクトリ側で共有しておくほうが、作業場所が変わっても判断基準がぶれません。
反対に、拡張設定へ接続まわりまで詰め込むと、『VS Code』からは通るのに外部ターミナルでは再設定が必要になり、運用が二重化します。
初期設定でこの線引きをしておくと、動いたあとに触る場所が明確になります。

基本の使い方

@file / @folder/ の使い分け

最初の一歩は、編集したいファイルを『VS Code』で開いた状態から、そのまま自然文で聞くことです。
たとえば設定ファイルや実装ファイルを選んだまま、「この関数の分岐を整理して、既存の挙動を保ったまま読みやすくして」のように投げると、会話の文脈に現在の作業対象が乗るので、ゼロから説明しなくても話が通ります。
変更提案はエディタ内の差分プレビューで追えるため、どこを書き換えるつもりなのかを会話とコードの往復なしで確認できます。
この流れだと、外部ツールへ移らず同じ画面で判断を続けられるので、細かな修正が連続する場面でも集中が切れにくくなります。

参照範囲を自分で足したいときは @file と @folder/ を使います。
単一ファイルだけを見てほしいなら @file、関連する複数ファイルを横断して考えてほしいなら @folder/ です。
たとえば @file src/auth.ts と書けば、そのファイルを前提に質問できますし、@folder/ scripts/ と書けば、そのディレクトリ配下をまとめて参照対象に載せられます。
対象を広げれば何でも当たるわけではなく、むしろ範囲を絞ったほうが提案の焦点が定まります。
実際、リポジトリ直下の scripts/ を @folder/ で指定してからバグ修正の手順を尋ねると、単一ファイルの読み替えでは出てこない関連スクリプトまで拾って、修正順や確認ポイントを横断して返してくれる感触があります。

複数ファイルにまたがる相談では、質問文も少しだけ具体化すると精度が上がります。
たとえば「@folder/ scripts/ このデプロイスクリプト群で失敗時のロールバックが抜けている箇所を洗い出して、最小修正案を出して」のように、対象と観点を同時に渡す形です。
単に「見て」と頼むより、どの観点で読んでほしいかが明確になり、返答もレビュー可能な粒度に揃いやすくなります。

複数行で前提を書きたいときは、入力欄で Shift+Enter を使って改行し、送信は Enter に任せる形が扱いやすいのが利点です。
たとえば1行目に依頼内容、2行目に制約、3行目に見てほしいファイルという並びにすると、あとで会話履歴を見返したときも意図が崩れません。
短い依頼を何度も打ち直すより、入力バッファに条件を書き足してから一度で送ったほうが、修正の往復回数が減ります。

Plan modeで安全に適用する流れ

変更をいきなり書き換えさせたくない場面では、『Claude Code』のPlan modeが合います。
流れは単純で、まず変更案を一覧で出させ、その内容を見てから適用へ進む二段階です。
小さなリネームなら通常の会話だけでも進められますが、関数の分割、ディレクトリ構成の見直し、複数ファイルの整理のように影響範囲が読みにくい作業では、この一段クッションが効きます。

たとえば @folder/ src/ を添えて「例外処理のばらつきを揃える計画を出して。
まだ変更は適用しない」と頼むと、対象候補や修正方針、想定される差分のまとまりを先に把握できます。
そのうえで「この案のうち 1 と 2 だけ適用」「命名変更は除外」のように絞って進めると、広い提案をそのまま飲み込まずに済みます。
大きな変更の前に安全確認を挟む、という使い方がいちばん素直です。

この段階で役立つのが差分プレビューです。
計画だけ眺めていると抽象度が高くなりがちですが、実際の変更候補が差分として見えると、危ない置換や不要な巻き込みを早めに見つけられます。
コードレビューの感覚で「この修正は通すが、この変更は意図と違う」と切り分けられるので、会話ベースの操作でも判断軸がぶれません。
インライン差分が同じウィンドウ内にある構成は、作業の分断を減らしやすく、細かな確認を積み重ねる場面で効いてきます。

Plan mode に入る前の依頼文も、複数行で整えておくと扱いやすくなります。
1行目に目的、2行目に触ってよい範囲、3行目に触らないでほしい範囲を書くと、あとから案を見たときに何を条件にした計画なのかが残ります。
入力欄の反応も軽く、手元では長めの条件を書き足しても待たされる感じが薄いので、短く削って伝えるより、必要な条件を最初から置いたほうが結果が安定します。

統合ターミナルでCLIを使う

普段の読解や差分確認は拡張の会話パネル中心で足りますが、長めの生成や CLI 側の機能を使いたいときは、統合ターミナルから claude を併用すると流れが止まりません。
エディタでコードを見ながら、隣で claude を実行できるので、外部ターミナルへ移るより視線の移動が少なく済みます。

たとえば会話パネルで対象ファイルを確認し、必要なら @file や @folder/ で参照範囲を絞って方針を固め、その後に統合ターミナルで claude を使って長めの処理を走らせる、というつなぎ方です。
レビューはエディタ側、実行はターミナル側と役割を分けると、どこで何を判断するかがはっきりします。
とくに CLI 専用の流れや、ターミナル出力を見ながら進めたい作業では、この併用が自然です。

統合ターミナルはmacOSなら Cmd+\、WindowsLinuxなら Ctrl+\` で開けます。
そこで claude を起動し、必要な指示を与えて進めます。
会話パネルで作った前提をそのまま文章化して貼ると、IDE 側で考えた方針と CLI 側の実行内容がずれません。
たとえば会話パネルで「この修正は scripts/` 配下だけに限定」と整理しておき、その条件をターミナルでも引き継いで実行する形です。

この併用が気持ちよく機能するのは、会話、差分、ターミナルがひとつの『VS Code』ウィンドウに収まるからです。
別アプリを往復するより、目の前の情報が散らばりません。
日常の修正は拡張で始め、処理の重い場面や CLI に寄せたい局面だけ claude を呼ぶ、という分担にすると、最小ワークフローとして無理なく回せます。

VS Code で Claude Code を使用する - Claude Code Docs

Claude Code 拡張機能を VS Code にインストールして設定します。インラインの差分表示、@-メンション、プラン確認、キーボードショートカットを使用した AI コーディング支援を取得します。

code.claude.com

実務で便利な設定: CLAUDE.md と Git・MCP連携

CLAUDE.mdの最小スターター

『Claude Code』を日常運用に乗せるなら、会話のたびに前提を言い直さなくて済む土台を先に置いておくと流れが安定します。
その役割を持つのが CLAUDE.md です。
これはプロジェクト固有の永続コンテキストをまとめるためのファイルで、コーディング規約、テスト方法、命名規則、レビューで見てほしい観点を共有しておけます。
汎用的な指示を毎回プロンプトに書くより、リポジトリの近くに置かれた数行のルールが効きます。

実際、CLAUDE.md に“テストは npm test を先に走らせる”と一文あるだけで、会話の初動が静かに整う感覚があります。
いきなり実装案を広げるのではなく、まず既存の確認から入る前提が共有されるので、修正の往復が減ります。
ルールを細かく書き込みすぎるより、最初は判断の芯になる文だけ置くほうが効きます。

スターター生成のあとに追記する内容は、まず3〜5行で十分です。たとえば次のような最小構成なら、過不足なく回り始めます。

- 変更前に `npm test` を実行し、失敗時は原因を先に要約する
- コンポーネント名は PascalCase、ユーティリティ関数は camelCase
「変更の目的」「影響範囲」「未対応項目」を分けて書く
- レビューでは破壊的変更の有無とテスト追加の要否を明記する

このくらいの密度でも、会話の返答がプロジェクトの流儀に寄ってきます。
とくにレビュー基準と命名規則を書いておくと、提案の粒度が揃いやすく、差分を見たときの違和感が減ります。
規約集を丸ごと貼るより、現場で繰り返し登場する判断だけを抜き出すほうが実務向きです。

Git運用に活かすメモの書き方

CLAUDE.md が効くのは、コード生成の場面だけではありません。
Gitまわりの支援でも、変更の意図をどう説明するかを明記しておくと、差分要約やレビュー前の整理が安定します。
たとえば「コミットは1つの目的ごとに分ける」「リファクタと挙動変更を同じコミットに混ぜない」と書いてあるだけで、変更案のまとめ方に一貫性が出ます。

ここで効いてくるのが、変更内容そのものより変更理由の型を定義しておくことです。
たとえば「なぜ触ったのか」「どこまで影響するのか」「テストで何を確認したのか」を毎回含めるルールにしておくと、レビュー前の要約文がぶれません。
会話パネルで「この差分をレビュー向けに要約して」と頼んだときも、要点が一定の順序で出てきます。

実務では、次のような一文があるだけで十分に効きます。
変更の目的を先に書く、コミット粒度は機能単位にする、差分説明では副作用を隠さない。
この3点です。
『Claude Code』はインライン差分を見ながら説明文まで整えられるので、コードと文章を別々に考える負担が減ります。
同じ『VS Code』の中で差分確認と要約作成がつながるため、レビューに出す前の整理で手が止まりにくくなります。

たとえば CLAUDE.md に「コミットメッセージ案では変更の意図を先頭に置く」「レビュー用要約では影響ファイルを列挙する前に目的を書く」といった簡潔な指針を置くと、差分の読み上げで終わらず判断軸が先に出るようになります。
こうした型を定めておくと、人間同士のレビューでも読み筋が揃います。

拡張からのMCP管理

外部サービスや社内ツールとの接続を広げたくなったら、拡張側からの MCP 管理も確認しておきましょう。
拡張から /mcp を使って MCP サーバーの有効化や再接続、OAuth 管理が可能になった旨が報告されています。
実際の操作手順や権限要件は環境やリリースに依存するため、該当のリリースノートと公式ドキュメントを確認のうえ運用してください。

この手の設定は、CLAUDE.md の記述例とも相性があります。
たとえば「社内ドキュメント系の MCP は調査時のみ使う」「コード変更前は Git 状態を先に確認する」のように、ツールの使い分けまで書いておくと、支援の順番が整います。
/mcp は機能として便利ですが、現場で効くのは“何をつなげるか”より“どの順で使うか”です。
まずは接続先を絞り、必要な操作だけを固定化する。
そのくらいの慎重さのほうが、日々の開発にはなじみます。

安全に使うための設定ポイント

承認ありモードで始める

自動編集を試したくなる場面は早い段階で出てきますが、導入直後は“承認ありモード”を起点にしたほうが運用が整います。
とくに『Claude Code』を『VS Code』の中で使い始めたばかりの時期は、どこまで触らせるかの感覚がまだ揃っていません。
先に全面自動へ寄せると、便利さよりも「その変更を誰が判断したのか」が曖昧になり、チームの不安が残ります。

自分の現場感では、最初の数日は“承認あり + Plan mode”で回すと、事故を避けながら合意を作りやすいのが利点です。
先に計画を出させて、差分を見て、そこで初めて適用する流れにすると、会話のテンポを保ったまま判断の責任線が見えます。
『Claude Code』はエディタ内で差分を追えるので、提案と変更内容が同じ画面に収まり、レビューの軸がぶれません。

自動適用へ進めるのは、プロジェクト側で「この種類の変更なら任せてよい」という合意ができてからで十分です。
たとえばリネーム、コメント整理、軽いテスト補助のように影響範囲を読みやすい作業から段階的に広げるほうが、運用の筋が通ります。
Anthropicの『VS Code で Claude Code を使用する』でも、拡張内で差分確認やPlan modeを活かせる前提が示されており、最初から無防備に自動編集へ寄せる必要はありません。

設定ファイル編集の安全運用

注意したいのは、コード本体より設定ファイルの自動編集です。
.vscode/settings.json や tasks.json は、見た目には小さな差分でも、保存時アクション、実行コマンド、拡張挙動にそのまま影響します。
ここを会話の勢いで更新すると、本人は一箇所の設定を変えたつもりでも、ワークスペース全体の振る舞いが変わってしまいます。

そのため、こうしたファイルを触る提案は、承認ありモードに加えてPlan modeを通し、差分レビューを必ず目視で挟むのが前提です。
とくに tasks.json はタスク実行の入口なので、コマンドの追加や引数の変更を漫然と受け入れないほうが安全です。
.vscode/settings.json も同様で、フォーマッタや保存時処理の変更は、他メンバーの作業結果にまで波及します。
コード修正より設定変更のほうが後から気づきにくく、レビューで見落とすと日常運用に残り続けます。

秘密情報の置き場所にも線引きが必要です。
APIキーやトークンをエディタ設定、会話履歴、CLAUDE.md に書く運用は避け、環境変数やシークレットストアに寄せたほうが管理が崩れません。
CLAUDE.md は永続コンテキストとして便利ですが、そこに認証情報まで混ぜると、ルール集と秘密情報が同居してしまいます。
役割を分けておくと、共有範囲も整理されます。

企業環境で ~/.claude/settings.json を使う場面でも、IDE側の設定と混同しないほうが扱いやすくなります。
『Claude Code』の拡張設定は『VS Code』内の動作に関わり、~/.claude/settings.json はCLIと共有される設定です。
設定の責務を切り分けておくと、どの変更がどこへ効くのかを追いかけやすく、トラブル時の切り分けも短く済みます。

Windows固有の注意と信頼境界

Windowsでは、ファイル共有まわりの権限設定に気を配りたいところです。
ネットワーク越しの場所までまとめて触れられる設定は、一見すると便利でも、意図しない範囲へ権限を広げる入口になります。

信頼できないリポジトリを開くときは、最初から「信頼しない」前提で扱う姿勢が合っています。
ワークスペースの設定、推奨タスク、補助スクリプトは、プロジェクトを開いた瞬間に開発者の判断へ割り込んできます。
見慣れないリポジトリほど、先に構成を読む、設定ファイルを見る、何を実行しようとしているか把握する順で進めたほうが落ち着きます。
必要があれば /sandbox のような隔離された実行環境を使い、普段の作業環境と切り分ける発想も有効です。

この「信頼境界を先に決める」感覚は、拡張機能を入れた直後より、慣れてきた頃のほうが効いてきます。
会話、差分、ターミナルが一つの流れにつながるぶん、便利さに引っ張られて実行まで一直線に進みがちだからです。
同じ画面で完結する快適さは集中を保つ助けになりますが、そのぶん「今どこまで許可したか」を自分で意識しておく必要があります。
信頼していないコードと、普段の資格情報やネットワーク権限を近づけすぎない。
この線引きが、日常運用の安全性を支えます。

セキュリティ - Claude Code Docs

Claude Code のセキュリティ対策とセキュアな使用方法のベストプラクティスについて学びます。

code.claude.com

よくあるトラブルと対処法

拡張が表示されない/開かない

『Claude Code』を入れたはずなのに『VS Code』側に出てこないときは、まず拡張そのものが読み込み直されていないケースを疑うと話が早いです。
いったん『VS Code』を閉じて開き直すか、Developer: Reload Windowでウィンドウを再読み込みすると、その場で表示が戻ることがあります。
拡張機能まわりは本体更新や他の拡張の読み込み順の影響を受けるので、見えていない状態でも実体は入っている、ということが起こります。

あわせて見直したいのが、入れた拡張が本当にAnthropicの『Claude Code』かどうかです。
名前が近い拡張や非公式の補助拡張を先に入れてしまうと、想定した画面やコマンドが出ません。
とくに導入直後は「入れたつもり」で別物だった、というズレが意外に残ります。
表示されない問題は、拡張本体の不調というより、再読み込み不足か取り違えで片づくことが多いです。

応答がない時の基本手順

入力欄には書けるのに返事が返ってこない、途中で止まる、送信後に画面だけ静かなまま、というときは、順番を固定して切り分けると迷いません。
先にネットワーク疎通を見て、その次に会話状態を切り離し、それでもだめならCLI側で動作確認する、という流れです。

まず通信経路が詰まっていないかを見ます。
会社のネットワーク、VPN、プロキシ配下では、ブラウザは使えても拡張内の通信だけ止まることがあります。
ここで通信に問題がなければ、次は既存スレッドを引きずらずに“新規会話”を作って試します。
実際、動きが鈍い会話ほど新規会話に切り替えた途端に戻ることがあり、私はこの挙動を何度も見ています。
問題の多くは、会話スレッドが長くなりすぎたことや、一時的な状態の食い違いで起きている印象です。

それでも反応しないなら、統合ターミナルで claude が動くかを見ます。
ここでCLIは正常なのに拡張だけ止まるなら、原因は認証情報そのものより『VS Code』側の状態や拡張の読み込みに寄っています。
逆にCLIでも同じように止まるなら、拡張固有ではなく、認証・通信・実行前提のどこかに絞れます。

ログインまわり

ログイン画面がうまく進まないケースは、個人利用の失敗というより、企業環境の構成と拡張の標準ログイン導線が噛み合っていないことが多いです。
BedrockVertexFoundryのような外部プロバイダを使う運用では、拡張内の通常ログインを通さず、Disable Login Promptを有効にして ~/.claude/settings.json にプロバイダ設定を書く構成が案内されています。

ここで詰まりやすいのは、『VS Code』の拡張設定と ~/.claude/settings.json を同じものとして扱ってしまうことです。
前者はIDE内の挙動、後者はCLIと拡張の双方で参照される設定なので、役割が違います。
ログインできない状態で拡張設定だけ触り続けても、認証元が別にある構成では前に進きません。
企業アカウント連携では、この切り分けを外すと「設定したのに変わらない」が続きます。

標準ログインが通らないのにCLI側では認証済み、という場合もあります。
そのときはアカウント自体より、拡張のログイン導線を無効化すべき構成になっていないかを見るほうが筋が通ります。
会社の運用でプロバイダ指定が前提なら、公式手順どおりに ~/.claude/settings.json 側へ寄せたほうが整理できます。

CLIは動くが拡張が不安定

統合ターミナルでは claude が普通に動くのに、拡張だけ反応が鈍い、表示が崩れる、会話タブの挙動が落ち着かないという場面では、まず『VS Code』側の要因を見ます。
典型的なのは拡張同士の競合、古い拡張バージョン、再読み込み不足です。
『VS Code』は継続的に更新されており、拡張も追従していくので、更新直後や逆に長く放置した環境で差が出やすくなります。

対処としては、拡張の更新、ウィンドウ再読み込み、関連設定の見直しをこの順で当てるとまとまりがいいです。
CLIが生きているなら、実行基盤そのものよりGUI側の状態管理に寄っている可能性が高く、いきなり全設定を疑うより、まず拡張の読み直しで戻るかを見たほうが切り分けが進みます。
最近のリリースでは入力欄まわりの再描画負荷も減っていて、以前より引っかかりは減りましたが、古い状態を引きずったウィンドウでは改善が反映されきらないことがあります。

私は、拡張だけ不安定なときほど「一見関係なさそうな他の補助拡張」を疑います。
サイドバー、会話UI、エディタ装飾、インライン表示を触る拡張が重なると、症状が『Claude Code』固有に見えて実は表示層の衝突、ということがあるからです。
そういうときは、再読み込みと更新だけで急に静かになることがあります。

拡張の設定リセット手順

拡張の保存状態をリセットする手段として、グローバル保存領域の削除が案内されることがあります。
保存パスは OS やインストール形態により異なるため、実行前に VS Code を終了し、対象フォルダの場所と内容を確認してからバックアップを取ることを強く推奨します。
環境によりパスは変わるため、公式トラブルシューティング手順を参照してください。
誤ってプロジェクトデータを削除しないよう十分注意してください。

この操作は『VS Code』を終了してから行うほうが整合が取りやすく、必要なら削除前にディレクトリを退避しておくと戻し先を確保できます。
リセットの対象は拡張の保存状態であって、プロジェクトそのものではありませんが、会話まわりや一時状態は失われる前提で扱うほうが混乱しません。

設定を触るほど症状が増える段階では、細かい修正を積み上げるより、一度まっさらにして再ログイン・再同期したほうが短く済むことがあります。
とくに表示不良、会話一覧の不整合、起動直後の読み込み停止が重なっているなら、このリセットは有効な切り札になります。

まとめと次のアクション

『Claude Code』導入は、拡張とCLIを競わせるのではなく、役割を分けて並走させると安定します。
日常の読解や差分確認は『VS Code』拡張、設定調整や自動化はCLIに寄せると、無理なく運用に乗ります。
私自身、最初は小さな変更でPlan modeを試したことで、その後の広い編集範囲でも任せ方の勘所をつかめました。
詰まったときは、再読み込み、新規会話、CLI確認、設定リセットの順で見ると、原因を短く絞れます。