Claude CodeとCoworkの違い｜分かれ目は、リポジトリかフォルダか

Claude Code と Claude Cowork。
名前が似ていて、どちらもAIに仕事を任せる道具です。

この2つの違いを聞かれたとき、「Claude Code はコマンドライン、Cowork はデスクトップアプリ」と説明されることがあります。
この説明は、正確ではありません。

Claude Code の公式ドキュメントは、冒頭でこう書いています。

デスクトップアプリで動きます。
ターミナルの有無では分かれません。

では、何で分かれるのか。
この記事では、公式の文書に書かれていることだけを並べて、判断の軸を1つに絞ります。
最後に、同じ発信のための2つの仕事を例にして、なぜ道具が分かれるのかを見ます。

公式は、何で分けているのか

Claude Code は、5つの場所で動く

公式ドキュメントは、Claude Code が動く場所をこう書いています。

実際に用意されているのは、ターミナルの CLI、VS Code 拡張機能、デスクトップアプリ、Web、JetBrains プラグインの5つです。

デスクトップアプリについては、こう説明されています。

そして、こうも書かれています。

ターミナルを使わずに Claude Code を動かすことは、最初からできます。

製品ページのFAQが、答えを1つ書いている

Cowork の製品ページには、この疑問そのものを扱うFAQがあります。

Claude Code はソフトウェア開発のために作られている。コードを書き、デバッグし、出荷する。

Cowork はコードを書かない知的作業のために作られている。調査、分析、文書の作成、その他の複数手順にわたる作業。

分かれ目は、道具の形ではありません。
何を仕上げるための道具か、です。

Claude Code が見ているのはコードベースです。
Cowork が見ているのはファイルとツールです。

中身のエンジンは、同じもの

ここで意外に思われるかもしれない点があります。
2つは、別々に作られた別系統の製品ではありません。

Cowork のヘルプセンターは、はっきりこう書いています。

Claude Cowork は、Claude Code を動かしているのと同じエージェント型のアーキテクチャを使っている。ただしターミナルは不要である。

同じ記事の書き出しは、Cowork を「Claude Code のエージェント機能を、コーディング以外の知的作業に持ち込むもの」と説明しています。
先ほどのFAQも、同じことを1行で書いています。

つまり Cowork は、Claude Code の仕組みを、コード以外の仕事に向けて作り直したものです。
遠い親戚ではなく、同じ心臓を持った兄弟だと考えると、後の話が分かりやすくなります。

エンジンが同じだと、できることが重なる

エンジンが同じであることには、実務上の意味があります。
できることの範囲が、思ったより重なるということです。

Cowork は、ドキュメントを整えるだけの道具ではありません。
必要ならスクリプトを書いて実行しますし、データを集計しますし、画像も作ります。

逆に Claude Code も、コードしか触れないわけではありません。
ドキュメントを書きますし、CSVを整えますし、調査もします。

だから、どちらでもできる仕事がかなりの範囲で存在します。
そのうえで、それぞれに向いた形があります。
その形の違いが、次に見る実行環境とファイルの扱いです。

処理はどこで動き、ファイルにどう届くのか

Cowork の処理は、既定ではクラウドで動く

まず驚かれることが多い点から書きます。
Cowork に仕事を頼んだとき、その処理はあなたのパソコンで動いているとは限りません。

アーキテクチャを説明したヘルプセンターの記事には、こう書かれています。

Cowork のセッションは既定でクラウドで動く。エージェントのループとコードの実行は、Anthropic のサーバー上で動く。

その中身も書かれています。

Anthropic が管理するインフラ上の、隔離された一時的なサンドボックス。
セッションごとに作られ、終わると壊されます。

デスクトップで動かす場合についても記述があります。
こちらではエージェントのループが端末上で動き、コードの実行は専用のLinux仮想マシンの中で行われます。
macOS では Apple Virtualization.framework、Windows では Hyper-V を使うと明記されています。

どちらの場合も、あなたのWindowsやMacの上で直接コマンドが走っているわけではありません。

ローカルのファイルには、デスクトップアプリを経由して届く

処理がクラウドで動いているなら、パソコンの中のファイルはどうやって扱われるのか。
ここに、この製品の設計がよく表れています。

同じ記事には、こう書かれています。

クラウドのセッションが利用者の端末にあるもの、たとえばローカルのファイルやブラウザを必要とするとき、そのリクエストは端末上の Claude Desktop アプリを経由する。

そして、アクセスできる範囲には制限があります。

ローカルファイルへのアクセスは、そのメンバーがデスクトップで接続したフォルダに限られる。

「フォルダを接続する」という操作が必要なのは、このためです。
接続していないフォルダは、Claude からは存在しないのと同じです。
パソコン全体が見えているわけではありません。

自分のパソコンの中で完結しているわけではない

ここは、社内で説明するときに外せない点だと思います。
同じ記事は、こう書いています。

クラウドのセッションは Anthropic のサーバー上で動くため、エージェントの作業は、デスクトップアプリ経由で開いたローカルファイルも含めて、端末に留まるのではなくAnthropicのサーバー上で処理される。

手元のパソコンにあるファイルを扱っていても、処理そのものは外に出ています。
扱ってよい情報の範囲は、この前提で決めることになります。

なお同じ記事には、サンドボックスが既定では社内ネットワークに到達できないこと、外向きの通信は必ずプロキシを通り許可された宛先だけが通ること、サンドボックスが持つのは数時間で失効するセッション限定のトークンだけであることも書かれています。
心配な点がある場合は、この記事を読むのが早いと思います。

デスクトップアプリを閉じると、ファイルには届かなくなる

この構造から、実務上の制約が1つ生まれます。
Webやモバイルからの利用について、ヘルプセンターはこう書いています。

クラウドのセッションが、接続したフォルダのファイルを読み書きできるのは、そのパソコンでデスクトップアプリが開いているあいだで、かつそのセッションがデスクトップで開始されたものである場合に限る。アプリが閉じられていると、セッションは動き続けるが、ローカルのファイルには届かない。

外出先のスマートフォンから続きを頼むことはできますが、そのとき自宅や会社のパソコンが起動していてアプリが開いていなければ、ファイルには触れません。
使い始めてから気づくことが多い制約だと思います。

処理がどこで行われるか、どのフォルダを接続してよいかを社内のルールにするなら、ひな形があります。
条文と、判断フローと、社内への説明原稿をまとめています。

Claude Code が前提にしているのは、リポジトリ

作業の起点は、いまいるディレクトリ

一方の Claude Code は、前提が違います。
公式ドキュメントが示すターミナルでの始め方は、プロジェクトのディレクトリに移動して claude コマンドを実行する、というものです。

作業の起点が「いまいるディレクトリ」です。

そして Claude Code は、git と直接つながっています。

さらに GitHub Actions や GitLab CI/CD と組み合わせて、コードレビューや課題のトリアージを自動化できるとされています。

この設計は、バージョン管理されたコードの塊を相手にすることを前提にしています。
変更の履歴が残り、レビューを経て、取り込まれる。
その流れの中に置かれる道具です。

共通している土台もある

違いばかり書きましたが、共通している部分もあります。

Claude Code のドキュメントは、複数のサーフェスについてこう書いています。

CLAUDE.md は、プロジェクトのルートに置くマークダウンのファイルです。
コーディング標準や、使ってほしいライブラリ、レビューの観点などを書いておく場所です。

MCP は、外部のデータソースとつなぐための規格です。
ドキュメントは、これを使うと Google Drive のドキュメントを読んだり、Jira のチケットを更新したり、Slack からデータを取ってきたりできると書いています。

この「前提を書いておくファイル」と「外部サービスとの接続」は、どちらの道具でも効いてきます。
覚え直しになる部分ではない、ということです。

PR

「とりあえず Claude Code」が正解にならない理由

なぜ取り違えが起きるのか

AIに仕事を任せたい、という相談を受けたとき、Claude Code を勧める案内をよく見かけます。
できることが多く、事例も豊富で、実際に強力な道具です。

ただ、相談の中身が Cowork 向きの仕事だった場合、この案内は最善になりません。
理由は2つあると思います。

1つ目は、Claude Code のほうが先に世に出ていて、情報量が圧倒的に多いこと。
検索しても、事例を探しても、出てくるのは Claude Code の話です。

2つ目は、いま見たとおりエンジンが同じで、できることが重なること。
Cowork でできる仕事の多くは、Claude Code でもできます。
だから「できます」と答えること自体は、嘘になりません。

先に断っておくと、Claude Code が劣っているという話ではありません。
向いていない仕事に当てると、道具の力が出ないという話です。

1つ目：導入の手前で止まる

向いていない道具を当てたときに起きることを、順に見ていきます。
最初に起きるのが、そもそも始まらない、という現象です。

Claude Code のドキュメントを開くと、インストールの手順から始まります。
macOS・Linux・WSL では curl のコマンド、Windows では PowerShell か CMD のコマンド。
Homebrew、WinGet、apt、dnf、apk といった選択肢も並びます。

ドキュメントには、PowerShell と CMD を取り違えたときのエラーメッセージまで書かれています。
その取り違えが、実際によく起きるということです。

エンジニアにとっては何でもない手順ですが、法務や経理の担当者にとってはここが壁になります。
そして、壁で止まった人は「AIは自分には無理だった」という結論を持ち帰ります。
道具の問題ではなく、案内の問題です。

なお、デスクトップアプリを使えばこの壁は避けられます。
アプリに Claude Code が含まれているので、CLI のインストールは要りません。
それでも、解説も事例もターミナル前提で書かれているものが多い、という事情は残ります。

2つ目：前提がかみ合わない

無事に導入できたとします。
次に起きるのが、道具の前提と仕事の形が合わない、という現象です。

Claude Code は作業ディレクトリと git を前提にしています。
git と連携し、変更をステージングし、コミットメッセージを作り、ブランチを切り、プルリクエストを開く。
この流れは、コードを扱う仕事では強力です。

一方、手元にあるのがバージョン管理されていない Word や Excel や PDF の束だった場合、この機能はほとんど効きません。

使わない機能があること自体は害ではありません。
しかし道具の設計の中心がそこにある以上、案内も解説も事例も、その前提で書かれています。
参考にできる情報が、自分の仕事から遠いということです。

3つ目：最後の受け渡しが噛み合わない

3つ目が、いちばん実務に響きます。

Cowork 向きの仕事の多くは、最後に「人が受け取れる形の成果物」で終わります。
整理されたフォルダ、体裁の整った文書、集計された表、貼り付けられた画像。

Cowork には、その受け渡しを助ける機能が用意されています。
デスクトップアプリに内蔵されたブラウザです。
ヘルプセンターはこう書いています。

サイトを開き、ページを読み、クリックし、入力し、フォームを埋める。それを利用者が見ている前で行い、ウィンドウを切り替える必要がない。

自分のブラウザとは別のブラウザで、ログインもタブも分かれています。
社内システムへの入力や、CMSへの入稿といった作業を想定した機能です。

こうした「最後の一歩」の部分は、コードを書く道具の設計思想とは別のところにあります。

逆に、Cowork に寄せないほうがよい仕事

公平を期すために、逆も書きます。
次のような仕事は、Cowork に寄せないほうがよいと思います。

• バージョン管理されたコードを継続的に改修する仕事

• プルリクエストのレビューを自動化したい仕事

• CIやCD、つまりビルドとデプロイの流れに組み込みたい仕事

• IDEの中で、書きながら相談したい仕事

Claude Code には GitHub Actions や GitLab CI/CD との統合が用意されており、ドキュメントには「すべてのPRで自動コードレビューを取得する」といった使い方が示されています。
VS Code や JetBrains の拡張機能もあります。

このあたりは、コードを扱う仕事のために作り込まれた部分です。
無理に Cowork でやる理由はありません。

判断するための3つの問い

案内する側の目安として、3つの問いを挙げておきます。

1. その仕事の対象は、リポジトリの中にあるか。はいなら Claude Code、いいえなら Cowork が出発点

2. 成果物を受け取るのは誰か。機械（CI、デプロイ先）なら Claude Code、人（上司、取引先、顧客）なら Cowork

3. その人はターミナルを日常的に使うか。使わないなら、その一点だけでも案内を変える価値がある

どちらでもできる仕事は確かに多いのですが、「できる」と「向いている」は別です。
そして向いていない道具を勧めた場合、その人はたいてい戻ってきません。

2つの仕事で、道具が分かれる

事例1：毎日の自動投稿を回す仕組み

具体例で見ます。
毎日決まった時刻に、その日の話題を要約した投稿を自動で出す仕組みを考えます。

構成はこうなっているとします。

• Pythonで書かれたプログラムを、GitHubのリポジトリで管理している

• 外部のスケジューラーから、決まった時刻に呼び出される

• 生成した文章が条件を満たさない場合は、投稿せずに止まる仕組みが入っている

この仕組みに手を入れる作業は、次のようなものになります。

• 文章の生成条件を書いた部分を修正する

• 投稿を止める判定の基準を調整する

• 不具合が出たときに、実行のログを追って原因を特定する

• 直したら、変更履歴を残して反映する

3つの問いに当てはめてみます。
対象はリポジトリの中にあります。
成果物を受け取るのは機械です。
そして最後の「変更履歴を残して反映する」が、git の仕事です。

Claude Code の設計に、そのまま乗ります。

事例2：記事を作る仕事

もう1つの仕事です。
記事の制作では、扱っているものが違います。

• 数十本のテキストファイルが、ローカルのフォルダに並んでいる

• 記事ごとにヘッダー画像を作り、別のフォルダに置いている

• 出典の一覧、通し番号、表記のゆれを、全体を横断して点検する

• 完成したものを、ブラウザからCMSに入稿する

同じ問いに当てはめます。
対象はフォルダの中にあります。
成果物を受け取るのは人です。
バージョン管理はしていませんし、この種の仕事では必要になることも多くありません。

そして最後の「ブラウザから入稿する」が、決め手になります。
サイトを開き、読み、クリックし、入力し、フォームを埋める。
入稿という作業は、まさにこれです。

同じ発信の仕事なのに、道具が分かれる理由

注目したいのは、この2つが同じ発信のための仕事だという点です。
テーマも、読者も、アカウントも同じです。
それでも道具が分かれます。

分かれ目になるのは、テーマでも規模でもありませんでした。
作業の対象が、リポジトリの中にあるか、フォルダの中にあるかです。

言い換えると、道具を選ぶときに見るべきなのは「何についての仕事か」ではなく「何を触る仕事か」だということです。
セキュリティの仕事だから、経理の仕事だから、という分け方では決まりません。
コードを触るのか、ファイルを触るのか。
その1点で決まります。

定期実行は、どちらにもある

ここで、1つ補足しておきます。
「定期的に動かしたいなら Claude Code」という理解は、正確ではありません。

Claude Code のドキュメントには、定期的なスケジュールで動かす方法として、ルーティンとデスクトップスケジュール済みタスクが挙げられています。

一方 Cowork にも、スケジュール実行があります。
ヘルプセンターにはこう書かれています。

毎朝メールを確認する、毎週数字を集める、金曜にレポートをまとめる。一度伝えれば、以後は頼まなくても処理する。

つまり定期実行は、どちらにもあります。
違うのは、何を定期実行するかです。

コードを走らせて機械に結果を渡すなら Claude Code、ファイルや文書を人が受け取れる形に整えるなら Cowork。
ここでも判断の軸は同じです。

なお Cowork のクラウドのセッションについては、スケジュールしたタスクは端末が1台もオンラインでなくても動く、と書かれています。
一方で、そのタスクがローカルのファイルを触る必要があるなら、先ほどの制約がかかります。

分けたことで、必要になったもの

最後に、道具を分けたことの副作用も書いておきます。

2つの道具は、それぞれ別の場所で動いています。
片方が知っていることを、もう片方は知りません。
そのため、次のような作業が必要になりました。

• それぞれの運用ルールを、別々の文書に書き出しておく

• どちらの担当かをはっきり決めておく

• 片方で決めたことを、もう片方の文書にも反映する

道具を分ければ、その分だけ引き継ぎの手間が生まれます。
これは避けられません。
逆にいえば、その手間を払う価値があるかどうかが、分けるかどうかの判断材料になります。
1つの小さな仕事なら、無理に分ける必要はないと思います。

2026年9月時点の提供条件

条件は変わります。
検討するときは、この記事ではなく、そのときの公式ページで確認してください。
そのうえで、いまの整理を書いておきます。

Cowork が使える場所

Cowork は有料プラン向けの機能です。
ヘルプセンターの整理は、次のとおりです。

• Claude Desktop（macOS・Windows）：すべての有料プラン

• Web（claude.ai）：Pro・Max・Team。Enterprise は管理者が有効にした場合

• モバイル（iOS・Android）：Pro・Max・Team。Enterprise は管理者が有効にした場合

• Claude in Chrome のサイドパネル：Max・Team。Pro には順次提供。Enterprise は管理者が有効にした場合

WebとモバイルのCowork は、ベータの扱いです。

デスクトップの位置づけは、こう書かれています。

デスクトップが完全版で、ローカルのファイルとブラウザを使えるのはここ。

内蔵ブラウザは、デスクトップアプリの Pro・Max・Team で順次提供されています。
Enterprise はオーナーが有効にした場合です。
デスクトップアプリがオンラインであれば、WebやモバイルのCoworkからも使えます。

Claude Code が使える場所

Claude Code については、ドキュメントが「ほとんどのサーフェスには Claude サブスクリプションまたは Anthropic Console アカウントが必要です」としています。
デスクトップアプリには有料サブスクリプションが必要と書かれています。

資料のURLが変わっている

1つ、資料の所在について注意点があります。
Cowork の製品ページは、anthropic.com から claude.com に移りました。
古い記事や社内資料に anthropic.com のURLが残っている場合は、貼り替えることになります。

まとめ

• 「Claude Code はコマンドライン、Cowork はデスクトップアプリ」という説明は成り立たない。Claude Code はターミナル、VS Code、デスクトップアプリ、Web、JetBrains の5つで動く

• 公式のFAQは、Claude Code をソフトウェア開発のための道具、Cowork をコードを書かない知的作業のための道具と書いている

• 中身のエンジンは同じ。Cowork は「same agentic architecture that powers Claude Code, with no terminal required」と説明されている

• Cowork のセッションは既定でクラウドで動き、Anthropic が管理する隔離されたサンドボックスの中で処理される

• ローカルのファイルには、端末上の Claude Desktop アプリを経由して届く。範囲は接続したフォルダに限られる

• クラウドのセッションでは、デスクトップアプリ経由で開いたローカルファイルも含めて、処理はAnthropicのサーバー上で行われる

• デスクトップアプリを閉じると、セッションは動き続けるがローカルのファイルには届かなくなる

• Claude Code は作業ディレクトリと git を前提にしていて、コミットとプルリクエストまでを含む流れの中に置かれる

• CLAUDE.md と MCP は、どちらの道具でも効く共通の土台

• Cowork 向きの仕事に Claude Code を案内すると、導入の手前で止まるか、前提が噛み合わないか、最後の受け渡しで詰まる

• 定期実行はどちらにもある。違うのは、何を定期実行するか

• 判断は1つの問いで足りる。その仕事で触るものは、リポジトリの中にあるか、フォルダの中にあるか

最後に1つだけ付け加えます。

この手の製品は、数か月で仕様が変わります。
この記事を書くにあたって公式ページを開き直したところ、製品ページのURL自体が変わっていました。
判断の軸は残りますが、条件は必ずそのときの公式ページで確かめてください。

皆さんの職場で、いちばん時間を取られている仕事は、コードとファイルのどちらを触る仕事でしょうか。

参考・引用元

Anthropic 公式ドキュメント

• Anthropic「概要」（Claude Code Docs、日本語版） https://code.claude.com/docs/ja/overview

• Anthropic「Claude Cowork」（製品ページ） https://claude.com/product/cowork

Claude ヘルプセンター

• 「Get started with Claude Cowork」 https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

• 「Claude Cowork architecture overview」 https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview

• 「Use Claude Cowork on web, desktop, and mobile」 https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile

• 「Use the built-in browser in Claude Cowork」 https://support.claude.com/en/articles/16607400-use-the-built-in-browser-in-claude-cowork

• 「Assign tasks from anywhere in Claude Cowork」 https://support.claude.com/en/articles/13947068-assign-tasks-from-anywhere-in-claude-cowork

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40

関連する記事

そもそもAIエージェントとは何かは、別の記事で扱っています。
聞けば答えるAIと、自分で動くAIの境目がどこにあるかと、MCPの役割をまとめています。
https://note.com/yunta_fukurou/n/n92cb991e5bec

製品として何を選ぶかは、こちらで扱っています。
生成AIとの使い分けと、主要製品の現在地をまとめています。
https://note.com/yunta_fukurou/n/ne41c5832b5a3

権限とログをどう設計するかは、別の記事で扱っています。
どこまで任せて、どこで人が承認するかの決め方をまとめています。
https://note.com/yunta_fukurou/n/n978314daa5f4

処理が社外で行われることのリスクは、こちらで扱っています。
シャドーAIから情報漏えい、プロンプトインジェクションまでをまとめています。
https://note.com/yunta_fukurou/n/n0b6b85bdcbb4

リポジトリという言葉が分からない場合は、別の記事で扱っています。
GitHubの用語の意味と、自社のコードがどこにあるかの確認方法をまとめています。
https://note.com/yunta_fukurou/n/na2ae723ddb69

AIエージェントがSaaSを置き換えるという議論は、こちらで扱っています。
株価が動いた背景と、賛否の両論をまとめています。
https://note.com/yunta_fukurou/n/ne0f88841d139

モデルとエフォートの選び方は、別の記事で扱っています。
迷ったときの出発点と、既定の段がどこに置かれているかをまとめています。
https://note.com/yunta_fukurou/n/n8db05af9df9a

CSVやExcelの整形を任せる前に、値が壊れる条件を知っておくと安全です。
先頭の0が消える理由と、開く前に決める手順は、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n8bb215311d9d

AIに作らせたものを社外に出す前に、確かめることがあります。
類似の確認と、プロンプトを残す理由は、別の記事で扱っています。
https://note.com/yunta_fukurou/n/n627054c224ee

この2つのうち、Coworkのほうは2026年9月16日に、短く聞く画面と1つになりました。
リポジトリかフォルダかという分かれ目はそのままですが、入口の名前が変わっています。
https://note.com/yunta_fukurou/n/n1e015de33993