Anthropic Cowork：Claude Desktopのファイル編集エージェントを解説

Anthropic CoworkのClaude Desktopエージェント：ターミナルの外でファイル編集は何を変えるのか

プロダクトマネージャーが、38ページのローンチ計画、CSV形式のエクスポートファイル三つ、そしてNotionからMarkdownへの移行が途中まで進んだデータを、ローカルのプロジェクトフォルダーに入れます。その人は学びたいわけではありません git, sed。Claude Codeについても同様です。求めているのは、「イベント名を統一し、リリース用チェックリストを更新して、各地域の責任者向けに整理された要約を作って」と伝えるだけで済むことです。

これがAnthropic Coworkの背後にある実用的な約束です。チャット画面で質問に答えるだけでなく、ローカルファイルを直接扱うことを目指したClaude Desktopのエージェント体験です。エージェントに関する初期の報道では、完全に自律したオフィス業務のように語られがちです。実際には、重要な変化はもっと限定的で、そのぶん有用です。Claude Desktopは、ターミナルを開かずにエージェントの支援を必要とする非プログラマーや部門横断チームに向けて、権限に基づくファイル編集ワークフローへと進んでいるように見えます。

開発者にとって興味深い問いは、「Claudeはファイルを編集できるか」ではありません。ソフトウェアプロジェクトでは、Claude Codeがすでにそれを非常にうまくこなしています。より適切な問いは、AnthropicがClaude Codeの、ファイルを把握してタスクを進める仕組みを日常的なデスクトップ作業向けに提供すると、何が起こるのか、ということです。

その答えは、チーム運営、ドキュメントのワークフロー、社内ツール、セキュリティレビュー、そしてAnthropicのエージェント戦略全体の方向性に関わります。

Anthropic Coworkは何であり、何ではないと考えられるか

「Anthropic Cowork」という名称は、初期の報道で、ローカルファイルを扱えるClaude Desktopエージェントを指すものとして使われています。詳細は今後変わる可能性があり、初期の報道はこうしたシステムの自律性を誇張することもあります。私はCoworkを、「Claudeが従業員になる」というより、「Claude Desktopに、ファイル作業のための、より安全なユーザー向けエージェントループが加わる」と捉えます。

この違いは重要です。

役に立つデスクトップのファイル操作エージェントには、次の四つの具体的な機能が必要です：

• ユーザーがアクセスを許可したローカルファイルを調べられること。
• 貼り付けられた断片だけでなく、複数のファイルを横断して推論できること。
• 確認可能な履歴を残しながら、編集を提案または適用できること。
• 新しいフォルダーの読み取り、ファイルの上書き、ファイルの移動、結果のエクスポートといった境界で、許可を求められること。

これは汎用的な自律ワーカーとは異なります。デスクトップエージェントも、モデルのコンテキストウィンドウ、ツールの権限、アプリケーションのUX上の制約の範囲内で動作します。1Mクラスのコンテキストに対応するFable 5のような大規模コンテキストモデルであっても、実際のファイル作業には、選択、インデックス作成、要約、レビューが必要です。共有ドライブ全体をコンテキストに放り込むことは、ワークフローではなく、リスクの種です。

現実的なCowork型の流れは、次のようになります。

User: In this folder, clean up the partner briefing pack.

Claude Desktop:
1. Reads the selected folder manifest.
2. Identifies duplicate drafts and stale files.
3. Proposes a plan:
   - merge notes from partner-notes-v2.md into briefing.md
   - extract action items into next-steps.md
   - leave archived PDFs untouched
4. Requests permission to edit two Markdown files.
5. Shows a diff or summary before saving.

価値は、魔法のような自律性にあるのではありません。意図、ローカルの文脈、確認可能な変更の間にある摩擦を減らすことにあります。

Anthropic CoworkのClaude DesktopエージェントとClaude Codeの比較

Claude Codeは、エージェントによる作業の優れた仕組みを備えているため、すでに多くの開発者にとって比較の基準になっています。リポジトリを読み、変更を計画し、ファイルを編集し、コマンドを実行し、失敗を調べて、反復するという仕組みです。ただし、Claude Codeは意図的に開発者向けのツールとして作られています。ユーザーがターミナル、ソース管理、パッケージマネージャー、テストコマンド、コードレビューに慣れていることを前提としています。

Claude Desktopのファイルエージェントでは、中心となるものが異なります。ドキュメント、フォルダー、スプレッドシート、プレゼン資料、エクスポートデータ、概要資料、会議メモを軸に仕事をする人々に対応する必要があります。

実際、Claude Codeがうまく機能するのは、強力な外部検証手段を備えた開発ループに組み込まれているからです。Python関数を誤って変更すれば、テストで問題を検出できます。設定の編集を誤った場合は、 git diff によって変更内容を正確に確認できます。危険な処理を実行しようとすれば、権限モデルがそれを中断できます。

デスクトップ作業では、通常、検証手段がより弱くなります。マーケティング計画にはユニットテストがありません。スプレッドシートの整理は、重要な行をひそかに落としながら「ほぼ正しい」結果になることがあります。要約は洗練されて聞こえても、決定内容を逆に伝えている可能性があります。つまり、Cowork型のエージェントには、コーディングエージェントよりも慎重なレビューUXが必要であり、簡略化すべきではありません。

デスクトップのファイルエージェントが役立つ具体的なワークフロー

最も有用なCoworkのワークフローは、「私の仕事をやって」といった曖昧なプロンプトではありません。範囲が明確で、出力を確認できるファイル操作です。

1. 複数ドキュメントの整理

技術職ではないチームには、次のようなファイルが蓄積しがちです。

launch/
  notes.md
  notes-final.md
  notes-final-v3.md
  launch-plan-old.md
  launch-plan.md
  stakeholder-feedback.csv
  customer-quotes.txt

優れたエージェント向けプロンプトは、求める出力と制約を具体的に示します。

Review the files in this folder. Create a new file called launch-brief.md.
Use launch-plan.md as the source of truth.
Pull only unresolved feedback from stakeholder-feedback.csv.
Do not modify the original files.
Show me the outline before writing the final brief.

ここで本当に重要なのは、「元のファイルを変更しないでください」という指示です。デスクトップエージェントは、元のファイルを変更する前に、派生ファイルを簡単に作成できるようにすべきです。これは、開発者が何かをコミットする前にClaude Codeにパッチ案を作らせるときと同じ原則です。

2. 人によるレビューを伴うCSVの正規化

CSVのワークフローは、検証できる程度に構造化されていながら、エンジニアリング以外の分野でも一般的なため、非常に適しています。

入力例：

account,event_name,event_date,owner
Acme, QBR - West, 2025/02/14, Maya
Globex,west qbr,14-02-2025, maya r.
Initech, Renewal Call, Feb 18 2025, Sam

デスクトップエージェントは、正規化した出力を提案できます。

account,event_name,event_date,owner
Acme,West QBR,2025-02-14,Maya R.
Globex,West QBR,2025-02-14,Maya R.
Initech,Renewal Call,2025-02-18,Sam

レビューの段階では、前提を示す必要があります。

{
  "changes": [
    {
      "row": 2,
      "field": "event_name",
      "from": "west qbr",
      "to": "West QBR",
      "reason": "Matched existing event naming pattern"
    },
    {
      "row": 2,
      "field": "owner",
      "from": "maya r.",
      "to": "Maya R.",
      "reason": "Normalized capitalization only"
    }
  ],
  "requires_user_review": [
    {
      "row": 1,
      "field": "owner",
      "question": "Should 'Maya' be expanded to 'Maya R.'?"
    }
  ]
}

よくある落とし穴として、モデルは正規化の結果を整合性があるように見せるのが非常に得意です。しかし、エンティティの同一性について、自動的に正しい判断を下せるわけではありません。「Maya」と「Maya R.」は同じ人物かもしれませんし、そうではないかもしれません。信頼できるファイルエージェントは、黙って決めるのではなく、これを確認事項として示すべきです。

3. ローカルの知識資料セットの作成

チームは、ローカルに散在する資料を整理された一式にまとめる必要に迫られることがよくあります。

project-root/
  calls/
  exports/
  screenshots/
  research-notes/
  final/

実用的なエージェントへの指示：

Create a customer-research-pack folder.
Copy, do not move, the three most relevant call summaries and the latest product export.
Create index.md with a one-paragraph summary for each included file.
Do not include screenshots unless they are referenced by a note.

このワークフローには明確な権限が必要です。ファイルのコピー、移動、削除は、同じ操作ではないからです。成熟したClaude Desktopエージェントであれば、インターフェース上で次の操作を分けて扱うことを期待します。

• 選択したフォルダー内のファイルを読み取る
• 新しいファイルを作成する
• 既存のファイルを編集する
• ファイルをコピーする
• ファイルを移動する
• ファイルを削除する
• 選択したフォルダー外のファイルにアクセスする

こうした境界は地味に聞こえますが、有用な自動化で済むか、サポート対応が必要な問題になるかを分けるものです。

開発者向けのファイル権限の捉え方

Claudeを活用したシステムを構築しているなら、「ツール利用」がモデルの推論と外部の状態をつなぐ実際のインターフェースであることは、すでにご存じでしょう。デスクトップのファイルエージェントは、本質的にはツールを使うモデルであり、そのツールは、一般ユーザーに使いやすいUIで包まれたローカルファイルシステムの操作です。

基盤となる権限の構造は、概念的には次のようなAPIに似ているかもしれません。

{
  "workspace": "/Users/sofia/Documents/launch",
  "permissions": {
    "read": ["/Users/sofia/Documents/launch/**"],
    "write": ["/Users/sofia/Documents/launch/generated/**"],
    "delete": [],
    "external_access": "ask"
  },
  "review_required": true
}

社内でCoworkを評価する開発者には、次の各レベルで制御できるかを確認することを勧めます。

まず、ワークスペースの範囲設定です。ユーザーは、マシン全体ではなく、特定のフォルダーへのアクセスを許可できるべきです。アクセス権は可視化され、取り消せる必要があります。

次に、操作ごとの承認です。ファイルの読み取り、新規ファイルの作成、元の文書の編集、ディレクトリの削除を、同じ権限として扱うべきではありません。

最後に、永続的な監査記録です。ユーザーは、エージェントが何を読み、何を変更し、自分が何を承認したのかを確認できるべきです。

コードを書かない人向けの監査証跡は、Gitのような見た目である必要はありませんが、考え方は同じです。「Claudeがファイルを三つ変更しました」では不十分です。「Claudeは行12-37を置き換えました。対象は regional-plan.csvで、作成したのは summary.md、そして pricing.xlsx は変更しませんでした」という記録のほうが、はるかに有用です。

Anthropicのより広範なエージェント戦略における位置づけ

Anthropicのエージェントに関する方向性は一貫しています。Claudeにツールへのアクセスを与え、権限でそれらのツールを制限し、独立したチャットではなく実際のワークフローでモデルを役立てるというものです。Claude Codeは、その戦略の開発者向けの部分を担います。デスクトップのファイルエージェントは、同じパターンを日常的な業務へと近づけます。

現在のClaudeのラインアップも、エージェントのさまざまな作業に明確に対応しています。

• Opus 4.8：掘り下げた計画、複雑なレビュー、重大な判断を伴う推論。
• Sonnet 4.6：品質、速度、コストのバランスが求められる一般的なエージェント作業。
• Haiku 4.5：軽量な抽出、分類、迅速な文書処理。
• 1Mのコンテキストを持つFable 5：コンテキスト量が重要になる、大規模な文書や広範なワークスペースを対象とした推論。

モデルはシステムの一部にすぎません。実際の導入では、エージェントの実行環境もモデルと同じくらい重要です。Claude Codeが強力なのは、読み取り、編集、コマンド実行、結果の確認を行うツールを備えているためです。デスクトップエージェントも同じ基準で評価されます。最初のデモがどれほど印象的かではなく、不完全な情報、曖昧な指示、ファイルの競合、ユーザーによるレビューに、どれほど確実に対応できるかが問われます。

エコシステムへの影響もあります。開発者は、Claude Desktopがローカルの成果物を操作できることを前提に、社内ワークフローを構築し始めるかもしれません。例えば、次のようなものです。

mkdir -p ~/TeamOps/weekly-review/input
mkdir -p ~/TeamOps/weekly-review/output
cp exports/*.csv ~/TeamOps/weekly-review/input/

その後、ユーザーはデスクトップエージェントに次のように依頼します。

Read the input folder and create output/weekly-review.md.
Include account risks, missing owners, and duplicate follow-ups.
Do not edit the input CSVs.

これは完全なAPI連携ほどプログラムで制御できるものではありませんが、共有ドライブやデスクトップ上のファイルを中心に仕事をしているチームにとっては、はるかに利用しやすいものです。承認済みのインフラを通じてClaude APIを利用している組織では、軽量なデスクトップワークフローが橋渡しの役割を果たすこともできます。まず手動でワークフローの有効性を確かめ、後から安定した部分を自動化するのです。

実務を任せる前に開発者が確認すべきこと

適切な姿勢は、冷笑でも無条件の採用でもありません。ファイル編集エージェントは実際に役立つ可能性がありますが、モデルがローカルの状態を変更できるようになると、リスクの性質が変わります。

気づかないうちに起こるデータ損失に注意

最もリスクの高い操作は、派手なものではありません。一見妥当に見える小さな編集です。

• 重複していない行を「重複」として削除する。
• ポリシー文書を書き直す際に、必須の条項を失う。
• ファイルを新しいフォルダー構造へ移動し、誰かの参照を壊す。
• 反対意見や不確実性を省いたまま、決定事項を要約する。

重要な作業では、まず派生成果物を使ってください。エージェントには、次のものを作成するよう依頼します。 cleaned.csv 上書きする代わりに、対象は source.csvです。また、次のものを求めてください。 brief-draft.md 置き換える前に、対象は brief.md.

差分確認のUXが不十分でないか注意

開発者は便利な差分表示に慣れています。コードを書かない人にも、それに相当するものが必要です。インターフェースは、適切な抽象度で変更内容を確認できるようにするべきです。

テキストファイルには行単位の差分が有効です。CSVにはフィールド単位の変更表示が適しています。フォルダーには、作成、移動、コピー、削除されたファイルを示すツリーが不可欠です。次のようなバイナリファイルでは、 .docx または .xlsxレビューが難しくなるため、エージェントはより慎重に動作するべきです。

権限の拡大に注意

エージェントシステムでよくある落とし穴は、権限が徐々に拡大することです。最初のプロンプトでは、問題のないフォルダーへのアクセスを許可します。次のプロンプトでは、隣のフォルダーが必要になります。その次は共有ドライブです。やがてユーザーは、エージェントが何を閲覧できるのかを忘れてしまいます。

優れたデスクトップエージェントは、作業画面で権限を常に確認できるようにするべきです。Claudeが現在のフォルダーの外にあるファイルを使っている場合、ユーザーがそれを推測しなければならない状態にしてはいけません。

曖昧な状況での断定に注意

ファイルエージェントは、整理されていない成果物から意図を推測しなければならないことがよくあります。それは便利ですが、推測に伴う不確実性は明示するべきです。望ましい動作は、次のようなものです。

{
  "status": "needs_confirmation",
  "question": "There are two files that look like the source of truth: launch-plan.md and launch-plan-final.md. Which one should I use?",
  "suggested_default": "launch-plan-final.md",
  "reason": "It was modified later and contains all sections from launch-plan.md."
}

望ましくない動作は、何も告げずに片方を選び、もう片方を書き換えることです。

Cowork型ワークフローを試すチームのための実践的なガードレール

チームでClaude Desktopのファイルエージェントを試す場合は、誤りが目に見え、元に戻せるワークフローから始めてください。

最初に試すのに適した作業：

• 読み取り専用の元文書から要約を作成する。
• 新しい出力フォルダーにブリーフの下書きを生成する。
• レビューを行いながら、小規模なCSVを正規化する。
• 元のファイルを移動せず、コピーを整理する。
• 会議のメモからアクション項目を抽出する。

初期段階での使用を避けるべき対象：

• 人によるレビューのない、法務、財務、コンプライアンス関連の記録。
• 行単位の誤りを見つけにくい大規模なスプレッドシート。
• ファイルの移動が他の人に影響する共有フォルダー。
• 元のファイルを上書きすることが既定になっているワークフロー。

チームで簡単なルールを決めておくと役立ちます。

/input     source files; agent can read only
/work      temporary files; agent can create and edit
/output    reviewed deliverables
/archive   human-managed only

そのルールに沿って、次のように指示します。

Use /input as read-only.
Create drafts in /work.
Put final proposed outputs in /output.
Do not move, rename, or delete anything.
Before writing to /output, show me a summary of the proposed files.

これは、開発者がブランチ、生成ファイル、レビューゲートで実践しているものと同じ運用上の規律です。形は異なりますが、制御の原則はなじみのあるものです。

Claude Codeが依然として優位な領域

コマンド、テスト、依存関係グラフ、ソース管理に依存するタスクでは、Claude Codeのほうが引き続き適したツールです。サービスのリファクタリング、APIクライアントの更新、テストスイートの実行、ログの確認、パッチの作成が必要なら、私はリポジトリ内でClaude Codeを使いたいと思います。

典型的なClaude Codeの作業サイクルは、次のようになります。

claude

その後、セッション内で次のように指示します。

Read this repository and update the billing webhook handler to reject duplicate event IDs.
Add focused tests and run the relevant test command.
Do not change unrelated formatting.

プロジェクト単位の設定では、チームはClaude Codeとローカルの指示を組み合わせることがよくあります。

# CLAUDE.md

- Use `npm test -- --runInBand billing` for billing tests.
- Do not edit generated files in `src/generated`.
- Prefer existing repository helpers over new abstractions.
- Before finalizing, show `git diff --stat` and test results.

これは、デスクトップエージェントに必要な制御とは種類が異なります。Cowork型ワークフローは、ターミナルの代替を目指すべきではありません。むしろ、組織内のそれ以外の人々、つまり構造化されたエージェントの支援は必要でもシェルへのアクセスは必要ない人々への橋渡しとして、より興味深い存在です。

実践上のポイント

Claude Desktopのファイル編集エージェントという概念としてのAnthropic Coworkは、完全に自律的な同僚ではなく、権限に基づくローカルファイルのワークフローとして捉えるのが最も適切です。有用な形では、選択されたファイルを読み、具体的な変更を提案し、適切な境界で承認を求め、レビュー可能な記録を残します。

開発者は、ツールを持つあらゆるエージェントと同じように評価するべきです。何にアクセスできるのか、何を変更できるのか、レビューはどう行うのか、不確かな場合にどうなるのかを確認します。ターミナルがないからといって、安全性の必要性が減るわけではありません。安全性を確保する作業の重点が、フォルダーの範囲設定、プレビュー、差分確認のUX、人が読める監査証跡へと移るのです。

チームにとって最適な出発点は、派生成果物を作る作業です。要約、整えたコピー、ブリーフの下書き、整理された出力フォルダー、レビュー可能なCSV変換などが該当します。元のファイルは読み取り専用に保ち、エージェントには指定した作業フォルダーへ書き込ませ、元の資料に変更を加える前には確認を必須にしてください。

ソフトウェアエンジニアリングの作業サイクルでは、Claude Codeが引き続きより強力なツールであり続けるでしょう。CoworkのようなClaude Desktopエージェントは、通常のファイルを扱うエージェント型ワークフローを必要とする、コードを書かない人々にとって、より強力なツールになる可能性があります。真価を問うのは、デモが自律的に見えるかどうかではありません。人が明確に主導権を保ちながら、エージェントがローカルで有用な変更を行えるかどうかです。