この記事の要点：Claude Cowork と Claude Code を、同じ Claude Desktop の画面から丸1日並べて使い比べました。結論：手元で完結するオフィス仕事（要約・集計・下書き・調査）までは、両者はほぼ同じです。同じ頭脳・同じ画面・同じ日本語での頼み方。違いが現れるのは、この日常の範囲を越えて踏み出すときで、それが2つだけあります。① できる範囲——会社のシステムまで手を伸ばせるか（Code は届く、Cowork は隔離された作業部屋の中まで）。② 使ってよい範囲——規制・監査のかかる業務に載せてよいか（Cowork は対象外、Code は統制の整備が前提）。①は設計で決まる「能力」の話、②は提供条件で決まる「ルール」の話。違いだと思われがちな「賢さ」や「操作ログの残り方」は、調べてみると違いではありませんでした。その顛末も含めて整理します（機能・仕様は変わりやすいため、執筆時点＝2026年7月の情報にもとづきます）。

はじめに ― 丸1日、並べて使ってみた

本シリーズではこれまで、Cowork と Code の使い分けを1枚チートシートにまとめ、機能単位のできる・できないも総点検してきました。それでもなお、「で、結局どこが違うの？」と一言で聞かれると、答えが長くなってしまう。そこで今回は発想を変え、両方を Claude Desktop という同じアプリの画面から丸1日並べて使い倒し、「削ぎ落としたら何が残るか」を確かめました。

結論から言います。手元で完結する仕事のあいだ、両者はほとんど区別がつきません。一定のレベルまでは、ほぼ同じなのです。違いが現れるのは、その範囲を越えようとした瞬間——そして、越え方はちょうど2つだけありました。それがそのまま、本質的な違いの2つです。

ただし、この2つは一見似ています。どちらも「使える範囲」の話に聞こえるからです。そこで先に軸を分けておきます。①は「そもそも何ができるか」という能力の話で、製品の設計で決まります。②は「会社として使ってよいか」というルールの話で、契約や監査の枠組みといった提供条件で決まります。車にたとえるなら、①はエンジンの性能（時速何キロ出せるか）、②は交通ルール（公道で何キロ出してよいか）。性能とルールが別物であるように、この2つも別々に確認が必要です。

Cowork オフィス仕事の成果物をつくる Code コードとシステムに手を入れる 手元で完結する仕事 要約・集計・下書き・調査 ここまでは、ほぼ同じ 同じ頭脳・同じ画面（Claude Desktop）・同じ頼み方 ▼ この線を越えると、違いが2つ現れる ▼ ① できる範囲 会社のシステムまで 手を伸ばせるか ＝ 能力の話（設計で決まる） 隔離された作業部屋の中まで 会社のシステムには 承認なしでは触れない 会社のシステムまで直接 GitHub・設定・認証情報に 手が届く ② 使ってよい範囲 規制・監査のある業務に 載せてよいか ＝ ルールの話（提供条件で決まる） 使えない BAA・SOC 2 など監査の 枠組みの適用範囲外 条件つきで使える 統制を自社で整備する ことが前提 土台は完全に共通 ― 同じ Claude・同じエージェント基盤 賢さ・仕事の質・操作感・コネクタ・スケジュール実行 … すべて共通 ① は「できるか」（能力）、② は「使ってよいか」（ルール）― 越えるときだけ効く2つ
図：手元で完結する仕事まではほぼ同じ。その線を越えるときに、①「できる範囲」（能力・設計で決まる）と②「使ってよい範囲」（ルール・提供条件で決まる）の2つの違いが現れる。

前提 ― 一定のレベルまでは、ほぼ同じ

まず土台の確認です。Cowork は Claude Code と同じエージェント基盤の上に作られており、頭脳にあたるモデルも同じです。しかも今回はどちらも Claude Desktop という同じアプリから使ったので、画面も、日本語で頼むだけの操作感も同じ。資料の要約、データの集計、下書きの作成——手元のファイルで完結する日常のオフィス仕事の範囲では、どちらに頼んでも結果は変わりませんでした。丸1日の前半で確認できたのは、この「一定のレベルまでは同じ」という事実です。

違いが現れるのは、この日常の範囲を越えようとしたときです。越え方は2つあり、それがそのまま2つの違いになります。順に見ていきます。

違い① できる範囲 ― AIの手がどこまで届くか（能力の話）

1つ目の越え方は、手元のPCの外——会社のシステム——まで手を伸ばそうとしたときです。ここで初めて「そもそも何ができるか」という能力の違いが現れます。これは設定や契約では変わらない、製品の設計そのものです。

Code は、開発の現場に直結しています。書いたコードを GitHub（プログラムの共同保管庫）に反映する、システムの設定を書き換える、認証情報を使って社内の仕組みにつなぐ——いわば会社のシステムの配管に、直接手が届く道具です。これは開発者にとっての生命線であると同時に、事故が起きたときの影響も配管の先まで及ぶ、ということでもあります。

Cowork は逆です。隔離された作業部屋（VM＝仮想の実験室）の中で働き、部屋の外にある会社のシステムには、承認なしに手を出せません。実際、前回の実験では、Cowork の作業部屋から GitHub への反映を試みたところ部屋の中では完結できず、部屋の外に出ようとした操作は許可ダイアログで止まりました。非エンジニアに安心して配れる理由が、この「届かなさ」そのものです。

この「届く・届かない」を、GitHub の認証情報を例に図にするとこうなります。GitHub に反映（push）するための認証情報は、ふつうプロジェクトフォルダの外——Mac ならキーチェーン、Windows なら資格情報マネージャーという OS の保管庫——にしまわれています。Code はそこまで手が届くので反映まで完了できる。Cowork は保管庫が部屋の外にあるため、取りに出ようとした時点で止まるのです。

Cowork Code GitHub コードの共同保管庫 GitHub コードの共同保管庫 利用者のPC 利用者のPC 隔離された作業部屋（VM） 📁 プロジェクトフォルダ ここで Cowork が働く 📁 プロジェクトフォルダ ここで Code が働く 🔑 認証情報の保管庫 Mac：キーチェーン Windows：資格情報マネージャー 🔑 認証情報の保管庫 Mac：キーチェーン Windows：資格情報マネージャー ✕ 部屋の外へは 許可ダイアログで停止 ✕ 反映（push）は 完結できない ✓ 読み取れる ✓ push（反映）できる ⚠ ただし、認証情報をプロジェクトフォルダの中に置いた場合は別 フォルダごと部屋に持ち込まれるため Cowork からも読める。「届かない」のは部屋の外にある保管庫の話。
図：GitHub への反映に必要な認証情報は、ふつうプロジェクトフォルダの外——Mac ならキーチェーン、Windows なら資格情報マネージャー——に保管されている。Code はそこまで手が届くが、Cowork は部屋の外に出ようとした時点で止まる。ただし、認証情報をフォルダの中に置けば Cowork からも読める。
ただし、例外があります。認証情報（APIキーやパスワードを書いたファイルなど）をプロジェクトフォルダの中に置いていれば、フォルダごと作業部屋に持ち込まれるため、Cowork からも当然読めます。「届かない」のはあくまで部屋の外にある保管庫の話。渡すフォルダに機微な情報を入れない——この基本は、隔離された Cowork でも変わりません。

ビジネスユーザーの目線で言い換えると、こうなります。「会社のシステムを直接いじる仕事を任せたいか？」——答えがイエスなら Code（を使える開発者）に、ノーなら Cowork に任せる。①の判断はこれだけです。

違い② 使ってよい範囲 ― 規制・監査のある業務に使えるか（ルールの話）

2つ目の越え方は、規制・監査のかかる業務にAIを載せようとしたときです。①が「技術的にできるか」という能力の話だったのに対し、こちらは「会社として使ってよいか」——契約や監査の枠組みで決まる、ルールの話。ただ、この②にたどり着くまでには回り道がありました。

よくある誤解 ―「Code ならログが残る」

2つ目の違いは、当初「操作ログの残り方」だと考えていました。「Code は企業向け（Enterprise）契約なら操作ログが残せるが、Cowork は残せない」——そう理解している方は多いはずです。実は筆者もそうでした。

ところが一次情報を確認すると、これは正確ではありませんでした。Enterprise の監査ログや Compliance API（監査・法務部門が組織の利用記録を取得する仕組み）が対象とするのは、ログインや設定変更といった組織レベルの操作記録です（チャットのやり取りの中身までは記録されません）。Code も Cowork も、利用者のPC側で動くため、どちらも監査ログの対象外でした。そして「自社の監視基盤に動作記録を送る仕組み（OpenTelemetry）」は、現在はどちらにも用意されています。ただし初期設定には差があり、Coworkは入力した文章の全文を送る一方、Codeは長さだけで本文を送りません。「ログが残るか」で比べると両者は近い位置にいますが、「何がどこまで残るか」は同じではないのです。本シリーズの過去記事にも「Code は監査ログの対象」と書いた箇所があり、本稿にあわせて訂正しました。

本当の違いは「会社として使ってよい業務の範囲」

では②は消えてしまうのかというと、消えません。形を変えて、より重要な違いとして残ります。ここで当然、こういう疑問が湧くはずです——「両方とも監査ログの対象外なら、使ってよい範囲も同じになるのでは？」。筆者も一度そこで止まりました。答えは、線を引いているのはログではない、です。規制・監査のある業務に載せてよいかは、次の2点で決まります。

  • 提供元が、規制対応の適用範囲に含めているか（契約の話）。セキュリティ事業者の整理によれば、医療情報などを扱うための契約枠組み（BAA）や SOC 2 といった監査の枠組みの適用範囲から、Cowork は明示的に外されています。さらに Anthropic は、Cowork の活動が監査ログ・Compliance API・データエクスポートのいずれにも記録されないことを明言しています。ここは自社の努力や設定の工夫では変えられません。
  • 統制を、会社として作り込み全員に強制できるか（運用の話）。Code には、管理者が全端末に設定を強制配布する仕組みがあり、動作記録を自社の監視基盤に送る運用の整備も体系化されています。Cowork の統制は現時点では各利用者の設定と運用ルールに頼る部分が大きく、以前整理した具体策を積み上げても、「監査に耐える証跡を会社として保証する」水準には届きません。

つまり、個人情報・金融・医療など、規制や監査証跡が求められる業務には、Cowork は現時点で「使えない」と割り切るべきです。一方の Code は、監査ログの対象外である点は同じでも、統制を自社で作り込むことを前提に、開発業務へ組み込んでいける。「ログの残り方は同じ」なのに「使ってよい範囲」が分かれるのは、この2点——提供側の適用範囲と自社統制の作り込みやすさ——が違うからです。

注意：「Code なら何もしなくても安全」ではありません。Code も初期状態のままでは記録は自社に残りません。監視基盤への送信設定や設定の強制配布といった統制の整備が前提です。Cowork を安全に配るための具体策は記録が残らない問題を扱った回で詳しく整理しています。

逆に、「違いではなかったもの」

丸1日の比べ比べで、「違いだと思っていたが、実は違いではなかったもの」も明確になりました。導入検討の場で誤解されやすい順に並べます。

違いに見えるもの実際のところ
賢さ・仕事の質同じモデル・同じ基盤。要約や集計の出来に差はない
操作ログの残り方どちらも監査ログの対象外。自社の監視基盤に送る仕組みは両方にある
画面・操作感デスクトップアプリでは同じ見た目。日本語で頼むだけなのも同じ
周辺機能コネクタ（外部サービス接続）・スキル・スケジュール実行などの土台は共通

この表の項目で悩んでいた時間は、正直、もったいなかったと感じています。比較検討の時間は、上の2つの違い——① できる範囲（能力）と② 使ってよい範囲（ルール）——にだけ使えば十分です。

実務では、こう使う

2つの違いを、そのまま導入判断の質問に置き換えられます。

  • 「誰に配るか」は①（できる範囲）で決める。会社のシステムに手を入れる開発者には Code、資料・集計・調査が中心の業務担当者には Cowork。ここは従来のチートシートのとおりです。
  • 「どの業務で使ってよいか」は②（使ってよい範囲）で決める。規制・監査証跡が求められる業務は、Cowork の対象外と割り切る。Code も「統制の整備が済んだ範囲まで」と線を引く。
  • それ以外は、どちらでもよい。賢さや機能の細かな比較に会議の時間を使わない。迷ったら Cowork から始めて、コードに踏み込む必要が出たら Code に切り替えれば足ります。

まとめ ― 2つだけ覚えて帰る

Claude Desktop から使う Cowork と Code は、手元で完結するオフィス仕事まではほぼ同じ。その範囲を越えるときにだけ、「① できる範囲」と「② 使ってよい範囲」の2つの違いが現れる。①は会社のシステムまで手を伸ばせるかという能力の話、②は規制・監査のある業務に載せてよいかというルールの話——これが丸1日かけてたどり着いた結論です。

機能比較の表は、時間が経てば古くなります。しかしこの2つの違いは、両製品の設計思想（開発の配管に直結する道具か、隔離された部屋で働く道具か）に根ざしているため、当面は揺らがないはずです。導入や社内ルールを検討する際の「最初の2問」として、使っていただければ幸いです。