Claude CodeはCLI版とアプリ版どっちを使う？｜ブラウザ操作と画面操作をアプリ版に任せて手作業を減らす

公開日: 2026年7月14日

この記事はClaude Codeを黒い画面で使っていて、アプリ版との違いが気になっている人向けです（インストール済みで、基本の操作が分かる前提）。

Claude CodeのCLI版とアプリ版は何が違う？

CLI版は、ターミナルでclaudeと打って起動する使い方です。

ターミナルは、黒い画面に文字のコマンドを打ち込む画面のことです。

WSLやMacに加えて、WindowsのPowerShellでもそのまま動きます。

アプリ版は、Claudeデスクトップアプリの中にある「Code」タブです。

今のアプリはChat・Cowork・Codeの3タブ構成です。

その1つがまるごとClaude Code。

対応OSはmacOSとWindowsで、Linux版もベータ提供が始まっています。

Windowsで使うにはGit for Windowsのインストールが必要です。

いちばん大事なのはここ。中身のエンジンは全く同じです。

公式ドキュメントも「Desktopは同じ基盤エンジンをGUIで動かしている」と説明しています。

同じPCで両方を同時に起動して、同じプロジェクトを触る使い方まで想定されています。

違うのは「手足」の部分です。片方にしかない機能を表にまとめます。

上下関係ではなく分業です。

Computer Useでは何ができる？CLI版でも使える？

Computer Useは、Claudeがパソコンの画面を見て、マウスとキーボードを操作する機能です。

動き方は単純です。

このループで、動画編集ソフトの操作やスマホアプリの動作確認まで任せられます。

2026年7月時点の対応状況はこうです。ここが古い記事と一番違うところ。

「Computer Useはアプリ版専用」という情報は、もう古いです。

macOSならCLI版でも動きます。

逆にWindowsのCLI版では動かず、アプリ版を使います。

TeamとEnterpriseプランでは使えません。

研究プレビューなので、条件は今後も動きます。

--printを使ったスクリプト実行でも動きません。

人が見ている対話中だけです。

安全装置もしっかり組まれています。

• アプリごとに「このセッションで許可するか」を毎回確認される
• ブラウザや証券アプリは「見るだけ」、ターミナルやIDEは「クリックだけ」に制限
• 作業中はEscキーでどこからでも即停止
• 手元のターミナル画面はスクリーンショットに映らない

Escで即止まる設計は安心材料です。

ブラウザ操作はどっちに任せる？Chrome連携と内蔵ブラウザの違いは？

ブラウザ仕事のやり方は2つあります。

Chrome連携と、アプリ版の内蔵ブラウザです。

Claude in Chromeは、ChromeとEdgeに入れる拡張機能です。

画面を「見る」のではなく、ページの中身（DOM）を直接読み書きします。

だからComputer Useより速くて正確です。

ログイン中の状態を共有するので、GmailやNotionもそのまま操作対象になります。

CLI版からはclaude --chromeで起動するか、途中で/chromeと打てばつながります。

ログインページやCAPTCHAに当たると、Claudeは手を止めて人間に交代を求めます。

おまけに、ブラウザ操作をGIF動画で残す録画機能つき。

内蔵ブラウザは、アプリ版に最初から入っている「まっさらなブラウザ」です。

ログイン情報も履歴も持たない、検証専用の画面です。

コードを直すたびに、devサーバーを立ち上げて動作チェックまで自動で走ります。

この自動検証（auto-verify）は標準でオン。

頼まなくても勝手に確認が回ります。

auto-verifyは正直ずるい便利さです。

私はこの機能だけでもアプリ版を開く価値があると思っています。

使い分けはこの2行で足ります。

• 開発中のアプリ検証、ログイン不要のサイト → 内蔵ブラウザ
• 「本人として」ログイン済みサイトを操作 → Chrome連携

そしてClaudeは、頼まれた仕事に対して「一番正確で速い道具」から順に試します。

Computer Useが最後なのは、何でもやれるけれど一番遅いからです。

実際の仕事でどう組み合わせる？（実例1：クラウドソーシング）

クラウドワークスやランサーズで案件を受けて稼ぐ場面を例にします。

CLI版だけだと、ブラウザで行う作業は全部人間の手作業です。

特にWSLのCLI版はChrome連携が使えないので、コピペ役から逃げられません。

アプリ版を足した後の流れを、番号付きで並べます。

1. 案件探し（Chrome連携）：「Python案件で予算5万円以上を探して」で候補をリストアップ
2. 提案文作成（どちらでも）：CLAUDE.mdに書いた実績を参照させて下書き
3. フォーム入力（Chrome連携）：応募フォームへ提案文を流し込み。送信ボタンは人間が押す
4. 開発（CLI版）：受注後はターミナルに戻ってコードを書かせる
5. 動作確認（内蔵ブラウザ）：auto-verifyが編集のたびに検証
6. 納品（Chrome連携）：納品画面でのアップロードを代行。最終確認は人間

対外的に飛ぶ文章の無確認送信は事故のもとです。

役割の型はこうなります。

考える仕事と作る仕事はCLI版、画面をポチポチする作業はアプリ版。

人間は中身の確認と判断に回る。ここが「仕事が変わる」の正体です。

動画編集の作業ではどう分担する？（実例2）

もう1つ、動画編集のプロジェクトで考えます。

CLI版に向く仕事は、出力が「ファイル」になる作業です。

• 音声の文字起こしから字幕ファイル（SRT）を作る
• 大量の素材をルール通りにリネーム・フォルダ分けする
• 台本や構成案のドラフトを書く

アプリ版に向く仕事は、出力が「画面上の操作」になる作業です。

• 素材サイトの巡回とリストアップ（Chrome連携）
• DaVinci Resolveなど動画編集ソフトの画面操作（Computer Use）
• YouTubeへのアップロード作業（Chrome連携。公開ボタンだけ人間）
• 公開後のXやInstagramでの告知準備（Chrome連携）

迷ったら「成果物はファイルか、画面操作か」で切ると外しません。

WSLで使っている場合、アプリ版と記憶を共有するには？

ここがWSLユーザーの核心部分です。

前提として、Chrome連携はWSL未対応、Computer UseのCLI対応はmacOSだけ。

つまりWSLの中のClaude Codeは、今も画面とブラウザに触れません。

だからWindows側のアプリ版と分業する価値があります。

私もWSLのCLI版が主戦場なので、この分業に落ち着きました。

ただし壁が1つ。WSLとWindowsは「家が2軒」の状態です。

Claude Codeの自動メモリ（MEMORY.md）や個人設定は、それぞれの家の中に保存されます。

WSLのCLI版が覚えたことを、Windowsのアプリ版は自動では見に行きません。

東京の家の日記は大阪の家では読めない。それと同じです。

解決策1：プロジェクトフォルダを「共有の部屋」にする。

アプリ版でフォルダを選ぶとき、次の形式でWSLの中を直接指定します。

\\wsl.localhost\Ubuntu\home\あなたの名前\projects\my-project

昔ながらの\\wsl$\...形式もまだ動きます。

ただ、今の正式な書き方は\\wsl.localhostです。

こうすると、プロジェクト内のCLAUDE.mdを両方が同じファイルとして読み書きします。

公式も「DesktopとCLIは設定とプロジェクトのCLAUDE.mdを共有する」と明言しています。

解決策2：「CLAUDE.mdに記録して」を口癖にする。

アプリ版で作業を終えたら「今日の作業と発見をCLAUDE.mdに追記して」と頼みます。

CLI版に戻れば、新しいセッションが自動でそれを読みます。

人間のチームの引き継ぎメモと同じ運用です。

解決策3：記録用テンプレを貼っておく。

# プロジェクト情報
- プロジェクト名：
- 目的：

# 作業ログ
## 最新の作業状態
- 最後に何をしたか：
- 次にやるべきこと：
- 未解決の問題：

## 過去の作業メモ
（日付ごとに追記）

解決策4：プロジェクトはWSL側に置く。

おすすめは/home/あなたの名前/projects/の下です。

Windows側の/mnt/c/...をWSLから触ると、読み書きが目に見えて遅くなります。

Microsoftも、ファイルシステムをまたぐアクセスの遅さを公式に案内済み。

おまけをもう1つ。

アプリ版チャットで使っているMCPをCLI版へ移すコマンドがあります。

claude mcp add-from-claude-desktop

公式にmacOSとWSLでの対応が明記されています。

地味に助かります。

結局どっちを使えばいい？使い分け早見表

片方だけでも十分に便利です。

ただ、両方を組み合わせたときの「人間は判断と確認だけ」という感覚は別物。

私もコード書きはCLI版、ブラウザ仕事はアプリ版と完全に分けています。

毎回手でやっているのに、Claudeに任せられる作業はどれか。

そこから1つ試すのが早いです。

FAQ

Q1. CLI版とアプリ版で設定や記憶は共有されますか？

プロジェクトのCLAUDE.md、MCP設定、settings.jsonの権限設定は共有されます。

会話履歴とセッションは別々に管理されます。

WSLとWindowsをまたぐ場合は、この記事の「家が2軒」問題への対策が必要です。

Q2. WindowsのCLI版でComputer Useは使えますか？

2026年7月時点では動きません。

CLI版のComputer UseはmacOS限定です。

Windowsで画面操作を任せたい場合は、アプリ版の設定からComputer Useをオンにします。

Q3. Chrome連携がWSLで動かないのはなぜですか？

公式ドキュメントがWSL未対応と明記しています。

回避策は2つあります。

1つはWindows側でアプリ版を使う方法。

もう1つはWindowsネイティブのCLI版からclaude --chromeでつなぐ方法です。

Q4. 料金はどのプランが必要ですか？

Claude Code自体はPro（月20ドル）以上か、API従量課金で使えます。

Maxは月100ドルと200ドルの2段階です。

Computer UseとDispatchはProかMax限定です。

TeamとEnterpriseでは使えません。

私はまず月20ドルのProで試して、上限に当たる頻度で上げるか決めれば十分だと思っています。

Q5. アプリ版だけで全部済みますか？

対話で完結する作業ならほぼ済みます。

ただしスクリプト連携（--print）やAgent SDK、Agent TeamsはCLI版だけです。

Amazon Bedrockなどクラウド経由の接続も同様です。

自動化を組みたくなった時点でCLI版が要ります。

参考リンク

• Claude Code公式ドキュメント: Desktop application
• Claude Code公式ドキュメント: Computer use（CLI）
• Claude Code公式ドキュメント: Use Claude Code with Chrome
• Claude Code公式ドキュメント: Agent teams
• Claude 料金ページ
• Microsoft公式: WSLのファイルシステム間パフォーマンス

この記事を書いた人

aisola

Aisola Lab 運営者

AIツールを使ったコンテンツ制作・リサーチ・WordPress運用を日常的にやっています。自分で動かせるものは実際に触って書き、触っていないものは公式ドキュメントと一次情報をもとに書き分けています。

運営者情報X（@ai_sola27）note

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。