VSCode向けClaude Codeを公開

• AnthropicのClaude CodeをVSCodeと統合し、開発者のコーディング体験を強化する拡張機能
• 動作にはClaude Codeの別途インストールが必要

主な機能

• 自動インストール: VSCodeのターミナルでClaude Codeを実行すると、拡張機能が自動で検出・インストールされる
• 選択範囲のコンテキスト認識: エディタで選択したテキストがClaudeの入力コンテキストに自動で含まれる
• Diffビュー対応: コードの変更点（diff）をVSCodeの内蔵ビューアですぐに確認できる
• キーボードショートカット: Alt+Cmd+Kのようなショートカットで、選択したコードをClaudeのプロンプトへ簡単に渡せる
• タブ認識機能: ClaudeはVSCodeで開いているファイルの情報を把握し、状況に応じたコード支援が可能
• 設定オプション: /configでdiff toolをautoに指定すると、IDE統合関連の機能を簡単に有効化できる

• 初期公開（early release）版のため、利用中にバグが発生する可能性や一部未完成の機能が含まれる場合がある

[digitect38]

Cursor との明確な違い

1. Cursor は VSCode に縛られている。一方、Claude Code は CLI（command line interface）方式なので、どのツールとも利用できる。

2. Cursor は実質的に他の LLM を活用しているが、Claude Code は Claude に特化している。しかも、実力を比較すると明らかに優位に立っている。これは Gemini 2.5 Pro と比べても同様だ（DotNet 基準であり、言語ごとに異なる可能性がある）。

[bluekai17]

では、Cursorと何が違うのでしょうか？

[iolothebard]

いや、Windows版（WSLじゃないやつ）は作らずに、またこんなことばっかりやってるのか…… -_ -;;;

[wahihi]

WSLもWindows OSの一部なのに、使い方を知らないんだな……GUIだけで開発していて、CLIはまったく分からないとか……

[yeorinhieut]

WSLを使うと、ファイルシステムの性能が大きく低下する問題（WSL2）もありますし、仮想化をHyper-Vに依存しているという欠点もあります。WSLを使えないケースも多いです。

[namojo]

私も共感します。会社でWSLの使用が禁止されているので、あれこれやってみましたが結局あきらめました。
SSL証明書をどうにか突破して進めてみたら、WSLが使えないんですね。

[ng0301]

笑笑笑、本当に共感する

[melong0124]

Git Copilot とどんな違いがあるのでしょうか？

[digitect38]

Copilot は MS IDE に特化しており、率直に言って初心者レベルである一方、Claude は CLI / Git Bash で動作するため、複数の環境で利用でき、コーディング能力も相対的に高い方だ

[kimjoin2]

IntelliJ プラグインもあります。
単純な CLI との違いは、IDE で見ている、あるいは選択しているファイルや行をすぐに認識することですね。
もちろん通常のターミナルで実行して、/ide コマンドで連携を開始することもできます。

[GN⁺]

Hacker Newsの意見

• 既存のIDEにエージェントベースのコーディングを統合する方向性は間違っていると思う。複数のGit worktreeを管理し、それぞれのエージェントが同時に動く方式のほうがよい。Claude Codeが作業を終えるのを20分以上待つ必要はない。だからそれを管理するUIを自作し、だんだん複数のエージェントを管理・レビューする新しいタイプのIDEへと発展しつつある。従来のように一度に1つずつ作業するわけではない。https://github.com/stravu/crystal
  • 私は個人的には違う考えだ。毎日Cursorを商用プロジェクトで使っている。background agentは特定の状況では役立つが、たいていは気が散る原因にしかならない。私が好むコーディングのやり方は、1つの目標に集中して反復的に解決へ近づいていくものだ。作業が終わるのを待つあいだはドキュメントや関連情報を調べて次の段階を考える。既存コードや変更点を見直して現在の進捗を正確に把握するのも非常に重要だ。各作業で複数のエージェントを管理するという考え方は自分のスタイルには合わない。コンテキストスイッチとマルチタスクが多すぎる。
  • こうしたワークフロー提案でいつも気になるのは、自分の個人的なコンテキストをどう管理できるのかという点だ。チームメイトのコードレビューでも、すべてのコードを完璧に理解して検証するというより、主に大きなミス（コードスタイル、ベストプラクティスなど）だけを素早く確認する。だから1日に多くのPRをすばやくレビューできる。もっと重要な作業（自分が責任を持つ場合）では、branchをテストし、実装を細かく確認する。PR更新のたびにこれを繰り返すので、かなり時間がかかる。複数のエージェントが同時にdiffを提案してきたとき、特に検証が必要な場合にどうコンテキストスイッチすべきか、また1回の更新が別の作業に微妙な影響を与えるときにmodule依存をどう管理するかが悩ましい。
  • こういうやり方もIDEプラグインとして同じように作れる。
  • すばらしいツールだ！ Claude Code TS SDKを使わなかった理由が気になる。パッケージはインストールしているが、別途claudeコマンドを直接実行する構造のようだ。ちなみにelectron-trpcも見てみるといい。IPC処理がずっと簡単になる。
  • このツールもすばらしいが、解決している問題が違う。background agentには大きく2つの問題がある。1) 分離された環境をきちんとセットアップするのに参入障壁がある。プロジェクトごとに難しさの差が大きく、単にコンテナを選べば済むものから、依存関係の設定が地獄になるものまでさまざまだ。一方でIDE内で作業するなら、たいていは必要なものがすでに揃っている。2) 人々はエージェントがどうコードを書くのかを学ばなければならない。エージェントがIDE内で動き、自分がリアルタイムで助言や修正を与えられるなら、長期的にはbackground agentよりずっと役に立つ。
• 私が望むのは次のようなものだ。git worktreeベースのコンテキスト切り替えを同じIDEウィンドウ内で強力にサポートする環境、各worktree branchごとにターミナルベースのエージェントを接続できるフレームワーク、最終的にはdiff・権限要求通知・進捗通知のためのより良いオープンプロトコルへ進化する環境、各worktree branchごとのエージェント状態と通知を監視するサイドバー、複数のbranch全体でエージェントのメッセージに通知のように素早く対応できるインターフェースだ。standaloneのagent managerツールにはこうした機能があるが、実際のエンジニアリング作業にすぐ飛び込みたいときには、そういうツールをまともに使えない。branchごとにブラウザのテストウィンドウやモバイルエミュレータ／シミュレータのインスタンスと連携する必要もある。高速なモデルベースのコード補完、多様な言語サーバー対応、高品質なIDEとしての拡張エコシステムも必要だ。私は今、macOSの複数のデスクトップでWindsurf、Claude agent、Webブラウザ、モバイルシミュレータをそれぞれ分けて管理している。このやり方はとても煩雑だ。
  • 私が欲しいのはデバッグ機能を持つコーディングエージェントだ。スタックをたどり、ローカル変数や引数の値を見て、printやassertではなく実際に内部で何が起きているのかをのぞきたい。
  • 複数のbranchでエージェントのメッセージに通知のようにすばやく反応する機能について、私もVSCode向けプラグインを作ろうとしたことがある。Claudeがファイルと行へ直接ジャンプできる機能だったが、ある程度は動いたものの、たびたび止まる問題があった。
• CursorとClaude Codeの実際の違いがよく分からない。両方使ったことがあり、会社でサポートされているのでそのままCursorに移った。CLIかUIか以外では、どちらもマルチファイル編集ができるので、これといった違いを見つけられなかった。複数のエディタを同時に使ったり、JetBrainsとCursorを行き来したりしなければならない不便な過渡期が早く終わってほしい。
  • 品質と実用性の面で両者には大きな差がある。Claude Codeは完全にagenticな方式だ。作業を任せると全体を自分で実装し、かなりまともでよく動くコードを作ってくれる。テスト、コミット、コマンド実行、リモートシステムへの接続、デバッグなども可能だ。トークン使用量の最適化はしないので、Cursorより初回の試行で高品質なコードが出やすいが、そのぶんコストは高い。Cursorのagent modeはまだ初期段階だ。Cursorは主にファイル編集ツールに近く、Claude Codeはジュニア開発者のような役割だ。
  • 両方のツールを一緒に使うことは多い。CursorはIDE、Claude CodeはIDEのターミナルで実行する形だ。パフォーマンス面でエージェント方式が違い、同じベースモデルを使っていても、コードベース分析、下位モデルの使い方、ツール連携などで差が大きい。
  • 違いをあまり感じないというのが不思議だ。私にとってはClaudeがあらゆる面で圧倒的に優れている。主にscala、python、js、dartを使っている。Claudeのおかげで非常に生産的なアシスタントを得られている。小規模〜中規模の変更では特にとても有用だ。計画をきちんと立てて使えば魔法のように感じる。コードの重複は多少あるが、その程度だ。Cursorは手直しが多く必要で、かえって遅くなった。
  • Claude Codeは本当に印象的だ。まるでもう1人のプログラマが自分のターミナルに一緒に座っているような感覚だ。完璧ではないし、こちらのやりたいことを正しく理解するまでは助けてやる必要がある。だがコンテキストさえきちんと合えば、本当に驚かされる。私の場合、プロジェクトを完全に理解させたわけでもないし、TypeScriptやWeb開発にも使っていない。
  • Cursorは別のIDEへ切り替える必要があり（もともとVSCodeを使っていない限り）、Claude Code（またはAider）は今のIDEと並行してターミナルから直接プロジェクトファイルを編集する。私の場合はvim+tmux+bashの組み合わせなのでCLIアシスタントを好むが、VSCode以外のGUI IDEを使う人にも同じ利点がある。
• 先週githubがcopilotのプレミアムリクエスト制限を導入したとき、大きな反発がなかったことのほうがむしろ衝撃だった。本格的に制限に引っかかる人が出てくれば、もっと大きな反発が起こると思う。競合製品があるのは本当にありがたい。
  • Claude Codeは1回の実行で10ドルが一瞬で消えることもある。
• VSCode CopilotをAgent mode + Claude Sonnet 3.7や4で使う場合と比べて、何か特別な利点があるのか気になる。自分が何を見落としているのか知りたい。
  • 実際にClaude Codeを体験してみないと、この質問には答えられない。ここで議論しても意味がない。Linuxターミナルを主力で使うなら、すぐにハマるはずだ。必ずドキュメントも読むこと。CLAUDE.mdを書き、大きな作業はマークアップ形式の計画文書にして、計画と修正を繰り返しながら実装を任せるべきだ。context limitに近づいたら、メモリをファイルにwriteして/clear後に再読込する方法を使うと、ずっと効率的になる。
  • Playwright MCPとCopilot agent modeを連携させようとしたが失敗した。インストールされ、ツール選択にも表示されるのに、結局Copilotがその機能へのアクセスを許可しなかった。
• Copilot agent modeでClaude backendを使うのと比べて、このソリューションの利点は何なのか気になる
  • このスレッドのほかの説明（特にhttps://news.ycombinator.com/item?id=44353972）はvscode copilotにも当てはまる
  • 数日使ってみた結果、この統合のおかげで、ファイルを直接開いて更新を確認しなければならなかった不便さが改善された。terminal modeではすべてがバックグラウンドで処理されて何が起きているのか分からなかったが、統合IDEではリアルタイムで全部見える。ただし、エージェントが付ける名前（例: Pondering、Twerking、Jugglingなど）は最初は新鮮だったが、すぐに無意味に感じるようになった。
• 少し脱線した質問だが、VSCodeでRooを使っている人がいるのか気になる。そしてRooのブラウザ機能がGitHub copilotが提供するClaudeとうまく連携するのかも知りたい。
• 私の理解では、VSCode（またはCursor）でClaude Codeを実行すると、これが自動インストールされる。わざわざ別途探してインストールする必要はない、という認識で合っている？
  • Claude CodeをVSCodeで実行すると自動インストールされるというのは、少し侵害的に感じないか？
  • そう。拡張機能のWebページにも明記されている。

  Auto-installation: When you launch Claude Code from within VSCode’s terminal, it automatically detects and installs the extension
  

• Claude Codeが複数の段階を一度に理解するという事実を意識するようになってから、ワークフローが変わり始めた。ファイル単位で考えていたやり方が、徐々に「モジュール分割、テスト作成、呼び出し側のリファクタリング」のような単一の行動単位へと移ってきている。Claudeもそれを1つの単位として理解する（最大努力モード）。こうした変化が少しずつコーディングへのアプローチを変えている。構文を気にすることが減り、より多くのスキャフォールディングを書き、複数の作業をまとめて処理するようになる。微妙だが長期的な影響は大きい。今後、LLMエージェントがよりよく探索できるように、コードベースの構造（フラット、回り道最小、宣言的メタデータなど）を意図的に改善する時期がどれだけ早く来るのか気になる。
  • いつを未来と呼ぶか以前に、すでに始まっている。Armin RonacherがPythonよりGoでコードを書く比重を増やしたのも、LLMがGoをよりよく理解するからだ。私の同僚も、ツーリングと型システムのおかげでエージェントが探索しやすいという理由で、デスクトップアプリをRustへ移した。AIが読みやすい形で文書化する方向へ、すでに発想が移りつつある。
  • LLMは、Goのように明確な静的型付けと簡潔な文法、一貫した書き方がある言語で確かによく機能するという話を聞くたびに、こうした点を考え続けている。ツール（言語、フレームワーク、ライブラリなど）から派生する不要な複雑さをどれだけ気にせずに済むかによって、私たちの脳のリソースをより本質的な問題解決に使えるようになる。
• Claude CodeがJetbrainsにも来ると聞いて楽しみだ！ https://plugins.jetbrains.com/plugin/27310-claude-code-beta-
  • なぜこのコメントに低評価が多いのか分からない。私も同じく楽しみにしている。共有ありがとう。

[namojo]

Claude Code を使うにあたって、MSA に近い考え方というか、マイクロサービス単位で分割できるだけ細かく分けて、それを1つの単位として任せるのがいちばん効率的なんじゃないかと思います。