Claude Code のインターフェース比較！デスクトップアプリ・CLI・VS Code 拡張の違いと選び方

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

OS で決まる最初の分岐と入り口の選び方

Claude Code を試したいけれど、入り口が増えて「どこから入ればいいか」で止まってしまう場面が増えています。最初の判断軸はシンプルで、普段使っている OS で入り口が大きく分かれます。

macOS や Windows なら入り口は 3 つに広がり、デスクトップアプリの Code タブ・ターミナルの CLI・VS Code 拡張のなかから、自分の作業に合うものを選ぶ形になります。

OS で候補が絞れたら、次の章でまず「デスクトップアプリ」と「Code タブ」の関係をほぐしたうえで、3 つのインターフェースの違いを順に見ていきます。

Claude Desktop アプリと Code タブの違い

OS の分岐が見えたら、次にほぐしておきたいのが「Claude Desktop アプリ」と「Code タブ」の関係です。

結論からいうと、Claude Desktop アプリの中にある「Code タブ」が、Claude Code の GUI 体験そのものです。チャット中心の汎用 AI アプリと、開発者向けの Claude Code は別物、というイメージを持っている方も多いのですが、現在の両者は 1 つのアプリの中で同居しています。

公式ドキュメントによると、Claude Desktop アプリには 3 つのタブが用意されています。

もともと Claude Code はターミナルで claude コマンドを叩く CLI が出発点でした。現在はそこに Desktop アプリの Code タブ・VS Code 拡張・Web ブラウザといった選択肢が加わり、同じエンジンを別の入口から呼び出す前提に変わっています。

そのため本記事で「デスクトップアプリで Claude Code を使う」と書くときは、常にこの Code タブを指します。

3 つのインターフェースの全体像

ここからは、Desktop アプリの Code タブ・ターミナルの CLI・VS Code 拡張という 3 つの入り口の輪郭を、横並びで俯瞰します。

それぞれの 1 文要約と、他に置き換えがきかない固有の核を、先に並べます。

以降の 3 つの章で、それぞれの輪郭をひとつずつ見ていきます。「どの作業をどこに渡すと一番楽か」という作業起点の住み分けは、後ほどの『向く作業 / UX を 5 軸で比較する』の章で改めて整理するので、ここでは各入り口の核がどこにあるかを掴むことに専念します。

① Desktop アプリの Code タブ

Desktop アプリの Code タブは、Claude Code を GUI だけで完結できる入り口です。ターミナル操作や IDE のセットアップを通らずに、1 つのウィンドウ内でファイル変更・確認・実行まで進められます。

このインターフェースを象徴する GUI 体験は次の 4 つです。

いずれもターミナル文字列だけの世界では再現しにくい体験で、Code タブを「一番リッチな選択肢」として位置づける核になっています。どの作業をここに渡すと一番楽になるかは、後ほどの「向く作業の住み分け」の章で扱います。

② ターミナルの CLI

ターミナルの CLI は、claude コマンドを叩いてその場で Claude Code を呼び出す、もっとも素の入り口です。GUI を持たない代わりに、シェルから直接呼べる headless な surfaceとして設計されています。

この surface の固有の価値は、ターミナルだけで完結しスクリプトに埋め込める点にあります。デスクトップアプリが対応しない Linux でも動く唯一の入り口で、対応 OS の幅も最も広く取れます。

承認まわりの作り込みも CLI ならではです。事前に許可したツールだけを通す dontAsk モードは CLI 専用で、--dangerously-skip-permissions や --print での非対話実行とあわせて、確認ダイアログなしで動かせる設計になっています。

そのままパイプや cron、CI スクリプトに claude の呼び出しを差し込んでも、人の y/n 入力を待たずに最後まで走り切らせられます。どの作業を CLI に渡すと楽かという住み分けは、後ほどの『向く作業の住み分け』の章でまとめて扱います。

③ VS Code 拡張

VS Code 拡張は、エディタで開いているファイル・選択範囲・行範囲といったIDE のコンテキストを保ったまま Claude に渡せる入り口です。コードを書く画面の真横に Claude との対話が並ぶ surface だと考えると分かりやすいでしょう。

この入り口を象徴するのが、行番号付きの @-mention(@app.ts#5-10)を Option+K(Windows/Linux は Alt+K)で選択範囲から差し込める IDE インライン入力です。

Desktop アプリの Code タブにも @-mention でファイルを引き当てる機能はありますが、そちらはファイル単位で参照する作りです。VS Code 拡張は選択した数行をそのまま行範囲付きで渡せる点が固有の核で、参照の粒度が違います。

JetBrains IDE(IntelliJ IDEA や PyCharm など)向けにも同等のプラグインが提供されており、選択範囲の共有や行番号付き file reference の挿入が IDE 内から使えます。仕組みの詳しい話は後ほどの『IDE 連携と行番号メンション』の章で、どの作業を渡すと楽かは『向く作業の住み分け』の章でまとめて扱います。

向く作業 / UX を 5 軸で比較する

3 つの入り口の輪郭が掴めたところで、次は読者の作業視点に切り替え、5 つの観点でそれぞれの使い心地を比較していきます。

ここでは機能の有無を◯×で並べたマトリクス表ではなく、「どの作業を渡せば誰が一番楽になるか」という意味で言語化することに重きを置きます。同じ機能でも、surface ごとに手触りが大きく違うためです。

以降の章で扱う 5 つの観点は次の通りです。

まずは、最初の観点である「向く作業の住み分け」から見ていきます。

① 向く作業の住み分け

日々持ち込む作業ごとに、どこへ渡すと一番ラクかを 5 つに並べます。

② 承認 UX と permission mode

コマンド実行やファイル編集が走るたびに出る「許可しますか？」をどう捌くかは、入り口選びで意外と効いてくる観点です。

Claude Code の承認 UX は、ここ数年で構造ごと変わりました。毎回その場で y/n を打つ運用から、いくつかの permission mode を選んで切り替えておく運用へ動いた、というのが要点です。問題はこの「mode を切り替える UI」が、surface ごとに違う形をしている点にあります。

CLI ではフラグや設定ファイルでモードを固定し、--print と合わせて確認ダイアログ自体を出さない書き方が素直にハマります。一方でデスクトップアプリや VS Code 拡張では、画面上のセレクタからモードを切り替え、編集前後の差分を目視で承認していく流れです。

読者が持ち帰るべき判断軸は機能の有無ではなく、「承認ポリシーを事前に決め置きたいか」「1 ステップずつ目視で承認したいか」の二択です。前者なら CLI、後者ならデスクトップアプリや VS Code 拡張が手に馴染みます。

各モードが surface ごとにどんな UI として現れるかは、Anthropic 公式ドキュメントの permission modes のページが最新です。mode 名を全部覚える代わりに、どちらの極で運用したいかだけ決めて先に進めば十分です。

③ ローカルファイル操作

リポジトリ内のファイルを読み書きさせるとき、同じファイルでも入り口によって「渡し方」の前提が違います。

デスクトップアプリはフォルダピッカーで対象を選び直す前提なので、複数リポジトリを跨いで切り替える運用と相性が良いです。一方で CLI は cd で目的のリポジトリへ移動してから claude を叩く流儀で、シェル習慣にそのまま乗ります。

VS Code 拡張はエディタで開きっぱなしのフォルダがそのまま渡るため、普段の編集動線から離れずに済むのが利点です。なお、選択した行範囲ごとピンポイントで渡す話は、後ほどの『IDE 連携と行番号メンション』の章で扱います。

頻繁に扱うリポジトリがどこに住んでいるか、どう切り替えるかで、自分にとって一番ストレスの少ない入り口が決まります。

④ IDE 連携と行番号メンション

VS Code 拡張の @app.ts#5-10 形式の行範囲メンションは、機能名としては行番号付きの file reference ですが、読者にとっての本当の価値はもう一段深いところにあります。

エディタで気になる数行を選んで Option+K(Windows/Linux は Alt+K)を押した瞬間、そのカーソル位置と選択範囲そのものが質問の中身になる、という点です。ファイルを指し直してから何を聞くか書くのではなく、選んだコードがすでに質問で、後は短い指示を添えるだけで会話が始まります。

デスクトップアプリの @-mention もファイルを引き当てる仕組みは持っていますが、そちらはファイル単位を指すポインタとして働きます。VS Code 拡張は編集している動線そのものが AI への入力に変わる方式で、参照の粒度も入力の作法も性質が違います。

JetBrains 系の IDE 向けプラグインも同じ流儀で使えるので、IDE でコードを書く時間が長い読者にとっては、デスクトップアプリや CLI とは別軸の独立した価値が出てくる入り口になります。

⑤ 非エンジニア適性

同じ Claude Code でも、デスクトップアプリ・CLI・VS Code 拡張では、ターミナルや IDE に馴染みが無い読者にとっての入りやすさが大きく違います。

デスクトップアプリの Code タブは GUI だけで操作が完結するため、ターミナルも IDE も一度も触ったことが無い人でも、アプリをインストールしてサインインするだけで使い始められます。一方で CLI は claude コマンドをターミナルから起動するのが前提で、シェルそのものに慣れていることが先に必要になります。VS Code 拡張も同様に、その VS Code 自体を日常的に使えていることが土台になります。

迷ったらどこから始めるか・併用の型

適性差まで見えたところで、ここからはこれまでの軸をひとまとめにして「最初にどこから触るか」と「併用するならどう分けるか」を渡します。

迷ったときの推奨はシンプルです。macOS か Windows で、レビューや調査から入りたい読者は Desktop アプリの Code タブから始めるのが一番ストレスが少ない入り口になります。Linux ユーザーや、CI / shell から呼ぶ自動化を先に組みたい読者は CLI の claude コマンドから始めるのが筋のよい選択です。

慣れてきたら 1 つに絞らず併用に進むのが現実解です。たとえば「レビューと並列セッションは Desktop、編集中ファイルの書き換えは VS Code 拡張、毎晩の定型処理は CLI から cron」という役割分担が成立します。

もう 1 つ典型的な型は、外出先のブラウザで Web 版に下書きさせて、戻ったら手元で git pull → ローカルでビルド → push という Web ↔ ローカル CLI の橋渡しです。出先で書く入り口と、手元で動かす入り口を 1 本の作業に繋ぐパターンになります。

3 つを横並びで見たときの読後感としては、Desktop は GUI 完結の主軸、CLI は自動化と Linux の保険、VS Code 拡張は IDE 内編集の高速化、という役割で組み合わせると一番無駄が出ません。

まとめ

ここまでの話を、もう一度地図としてまとめておきます。

本記事ではまずOS による最初の分岐を確認し、Claude Desktop アプリ内の Code タブが Claude Code の GUI 体験そのものだという前提を押さえました。そのうえで Desktop の Code タブ・ターミナルの CLI・VS Code 拡張という 3 つの入り口を俯瞰し、向く作業・承認 UX・ローカルファイル操作・IDE 連携・非エンジニア適性の 5 つの観点で比較し、最初の入り口と併用の型まで提案してきました。

読み終えた後は、次の順番で動き出すとつまずきにくくなります。

機能差の細かい一覧や最新の差分は、必ず Anthropic 公式の Claude Code Desktop ドキュメント にある Feature comparison 表を確認してください。ご自身の OS と作業に合わせてまず 1 つ選び、必要に応じて二つ目を足していけば、無理なく Claude Code の役割分担を組み立てられます。