「AIに調査を任せて、パソコンを閉じる。翌朝、制作に使える資料ができている」。Claude Coworkのクラウド移行は、この使い方を考え直すきっかけになります。ただし、クラウドで動くAIと、手元のパソコンで操作する道具は、同じ場所にあるわけではありません。
本記事では、2026年10月6日からの変更を整理し、Webデザインの競合調査と構成案づくりを例に、閉じても進む仕事・接続が必要な仕事を切り分けます。後半の課題、指示文、確認表は本記事の運用提案です。Claude実機での動作・完了時間は未検証で、生成結果を示す記事ではありません。情報確認日は2026年10月7日です。
1．10月6日に変わったことと、9月の発表を分ける
公式ヘルプでは、2026年10月6日から、Pro・Maxで開始する新しいCoworkタスクはクラウドで実行されると説明されています。それ以前に作ったローカルタスクとローカルの定期タスクは、そのまま手元で動きます。Pro・Maxの新規タスクで、実行場所をローカルへ戻す選択肢はありません。公式：Web・デスクトップ・モバイルでのCowork
一方、ChatとCoworkを一つのClaudeへまとめる発表は9月16日です。こちらはPro・Maxから段階的に展開するとされた体験の変更。10月6日の実行場所の変更とは、日付も対象も分けて読む必要があります。公式：Cowork is now Claude
| 見ている変更 | 読み取れること | 制作で確認する点 |
|---|---|---|
| 9月16日の統合発表 | 会話とタスクを一つの体験へ段階的に統合 | 手元の画面にChat／Coworkの切り替えがあるか |
| 10月6日からのPro・Max新規タスク | 新しいタスクの実行場所がクラウドへ | 昔のタスクを再開していないか |
| 以前のローカルタスク・定期タスク | 従来の実行場所を維持 | 以前の設定が自動で移行したと思い込まない |
比較表は上の公式資料を整理したものです。以下はPro・Maxの新規タスクを主な対象にします。TeamのWeb・モバイルはベータ、Enterpriseは管理者側の有効化が条件で、組織利用を一律に同じ状態とは扱えません。プランと管理設定を先に確認してください。公式：利用環境と対象プラン
2．クラウドで考える部分と、端末に触る部分は別
クラウドセッションでは、AIが作業を組み立てて進める処理とコード実行がAnthropic側で動きます。一方、ローカルフォルダーへのアクセスは、接続されたデスクトップアプリを経由する経路です。端末がオフラインなら、その端末のファイルには到達できません。公式：Coworkのアーキテクチャ
この区別は、依頼文の書き方に直結します。「添付した企画書から比較表を作る」と「デスクトップの最新企画書を探して書き換える」では、必要な材料も操作も違います。前者は必要な版をあらかじめ渡せます。後者は、実行中に端末へ接続してファイルを探す工程を含みます。
さらに、Coworkの組み込みブラウザはデスクトップアプリ内にあり、利用にはアプリが開いていてオンラインである必要があります。クラウドセッションという名前だけで、ブラウザ操作まで端末から独立したとは判断できません。公式：組み込みブラウザ
ここでいうブラウザ操作は、ログインしたサイトでクリックしたり入力したりする工程です。調査資料を読むことと、サイトの管理画面を操作することは、依頼の中で別の工程として書くと依存関係が見えます。
たとえば「競合を調べ、LPを改善し、CMSに反映して」では、調査、構成の判断、端末上の編集、外部サイトへの書き込みが混ざります。まず「調査結果と改善案を成果物にする」までに範囲を絞ると、どこで作業が止まったか、何を人が確認するかを説明しやすくなります。
3．最初の課題は、LPの競合調査を制作資料に変える
おすすめする最初の課題は、完成サイトを丸ごと作らせることではなく、競合5件から、判断に使える構成メモを作ることです。架空の例として、オンラインのWebデザイン講座のLPを考えます。読者は初学者、目標は説明会への申し込み。これなら、単なるサイト紹介から一歩進んで、情報の並べ方を検討できます。
最初に、調査対象のURL、講座の特徴、対象読者、使用できる実績、禁止する表現を用意します。「実績が足りなければ補って」ではなく、「材料にない数字、受講者の声、成果保証は作らない」と決めます。AIが書きやすい文章と、掲載できる文章の間には、こうした条件の差があります。
成果物は、次の三つに分けて指定します。
| 成果物 | 入れる内容 | 使い道 |
|---|---|---|
| facts.csv | URL、確認日、根拠の箇所、観察できた事実、未確認事項 | 原典へ戻って検証する |
| brief.md | 想定読者、比較から得た仮説、LPの見出し順、各節の役割 | ワイヤーフレームを考える |
| review.md | 採用候補、採らない案と理由、追加で必要な素材 | 次の制作判断を残す |
このファイル名と形式は本記事の提案です。実際にファイルを出力できるか、どの形式で受け取れるかは、手元の環境で確認してください。表の行数や見出しの数だけを指定するより、各ファイルを何の判断に使うかまで伝える方が、検品の基準を作れます。
共有する材料は、Claudeアカウント側で扱えるファイルやプロジェクトに準備します。公式資料では、新規プロジェクトはアカウントへ保存される一方、手元の既存フォルダーから作ったプロジェクトは、その端末に残ると説明されています。「プロジェクトに入れた」という言葉だけでは、保存場所の確認になりません。公式：Coworkのプロジェクト
4．そのまま試せる指示文と、再現の手順
以下は本記事が作成した指示文です。URLと角括弧の内容を置き換えて使います。自動操作の実測結果ではなく、試すための入力例です。
目的：初学者向けWebデザイン講座のLPを設計するため、指定する競合5件を比較してください。対象読者は［読者像］、目標行動は［申し込み等］です。対象URLは［5件のURL］。渡した企画書を自社情報の根拠としてください。各サイトで確認できた事実、あなたの解釈、未確認事項を分け、事実にはURLと確認日を添えてください。読めないページやログインが必要なページは未確認と記録し、推測で埋めないでください。成果物はfacts.csv、brief.md、review.md。brief.mdではLPの見出し順と各節の役割を提案し、どの不安・疑問に答える節なのか説明してください。実績、金額、口コミを創作しないでください。外部サイトへの書き込みは依頼に含めません。まず作業方針と不足する材料を示してください。
- 元の企画書に版名と日付を付け、AIへ渡す材料を確定します。作業中に別の版へ差し替えるなら、その変更も伝えます。
- 依頼を新しいセッションで始めます。Chat／Coworkの選択が残る画面ならCoworkを選び、統合された画面なら会話から依頼します。公式：Coworkの開始方法
- 最初に示された方針を見て、対象URL、成果物、書き込みの有無が依頼と一致するか確認します。「全部任せる」より、最初の1回で範囲を合わせる方が検品しやすくなります。
- 完了後は三つの成果物を取り出し、次節の確認表を使います。未確認のページがあるなら、その条件のまま使える範囲を決めます。
- 修正は一つの問題に絞ります。たとえば「初心者の不安への回答が遅い。根拠のある情報だけで、学習内容の前へ移す案を作って」と頼み、採否を記録します。
この課題では、見た目が似ている競合を多数並べても、良い構成案になるとは限りません。たとえば、受講後の働き方を知りたい人と、仕事を続けながら学べるか知りたい人では、先に答えるべき質問が違います。調査表から「よくある見出し」を拾うだけで終わらず、自分の読者の迷いへ結び付けてください。
5．「きれいな成果物」を、判断できる成果物へ直す
検品では、まず事実の行を数件選んで原典と照合します。説明がもっともらしいほど、引用元にない解釈が混ざっていても見逃しやすくなります。「確認済み」と書いてあること自体は、確認の証拠にはなりません。
| 確認する項目 | 合格の目安 | 不足していたらどう直すか |
|---|---|---|
| 事実と解釈 | 観察した内容と、AIの提案が分かれている | 根拠のない行を未確認へ戻す |
| 出典への追跡 | URLと確認日から元の説明に戻れる | 該当箇所の説明を追加する |
| 自社情報との整合 | 提供できる内容だけで訴求している | 実績・金額・保証の創作を除く |
| 見出し順の理由 | 各節が読者の具体的な疑問に答える | 「誰の何を解決するか」を書き足す |
| 次の制作への接続 | 必要な素材と未決の判断が残っている | 写真、図、数字の不足を列挙する |
たとえば「競合の多くが卒業後の仕事を強調している」は観察の整理ですが、「だから自社も収入を保証するべき」は別の提案です。後者を採用するには、自社の提供内容と根拠が必要です。AIの比較から直接、掲載表現の承認へ飛ばないことが、制作資料の質を守ります。
ワイヤーフレームへ進むときは、brief.mdの各節を「見出し」「伝える事実」「必要な図や写真」「読者の次の行動」に分けます。ここで初めて、文章量と視覚的な強弱を考えます。AIが長い説明を出した場合も、全部を同じ重さで載せず、申し込み判断に必要な情報を先に置く。クラウド化が肩代わりするのは作業の実行であり、どの情報を主役にするかという編集判断は、引き続き必要です。
6．毎朝の調査にするなら、まず1回を完成させる
定期タスクは指示と頻度を保存して実行する仕組みです。公式ヘルプでは、クラウドの定期実行はPCのスリープ中やアプリを閉じた状態でも動き、左側の「Scheduled」から過去・今後の実行を確認できるとしています。ただし、以前のローカル定期タスクは残り、ローカルファイルやアプリが必要なタスクにはローカル実行の注意書きもあります。PCを閉じる前提なら、入力と工程からローカル依存を外し、実際のタスク設定を確認します。公式：定期タスク
一度の調査が未完成のまま毎日繰り返すと、同じ不足も毎日増えます。先にfacts.csvの根拠、brief.mdの判断理由、review.mdの未確認事項を人が読める状態まで整え、その後で頻度を決めるのがおすすめです。
統合されたClaudeでは、会話で頻度を伝え、提案された名前・予定・指示を確認して「Schedule」を押す流れです。Coworkの画面が残る場合は、「Scheduled」→「New task」→「Create with Claude」から作成できます。公式：定期タスクの作成手順
毎朝9時に、指定した公開URLの更新を確認し、前回の資料と比べて変更点を整理する定期タスクを提案してください。日本時間を想定しています。作成前に、予定時刻とタイムゾーン、参照する資料、出力先、必要な接続を確認してください。変更を確認できない日は、その旨を記録してください。未確認の内容は確定情報にせず、成果物は人が確認する調査メモまでとしてください。
時刻の指定は、完成時刻の保証とは分けて考えます。午前9時に開始する設定なら、9時に完成していることまで期待せず、調査に必要な時間を見込んで確認時間を決めます。これは本記事の運用上の考え方で、製品が保証する所要時間ではありません。
朝の確認では、「起動予定がある」「実際に開始した」「材料へアクセスできた」「成果物が揃った」の四つを分けて記録します。予定だけを見て成功扱いにせず、前回と同じ出力を誤って採用しないよう、成果物の確認日と対象期間も見ます。
7．有料プランでも、使える量と止まる条件は確認する
現在のCoworkの案内対象はPro・Max・Team・Enterpriseの有料プランです。複数工程を進めるタスクは短い会話より使用量が増えやすく、利用状況の確認が必要になります。また、承認の設定にかかわらず、作業が確認待ちになる可能性は残ります。公式：利用条件・使用量・承認
制作での評価は「アプリを閉じても動いた」だけで終えない方がよいでしょう。同じ調査について、依頼の準備、人の照合、修正にかかった時間を記録し、手作業で行った場合と比較します。本記事では削減率を実測していないため、「何割速くなる」とは言いません。
最初から競合30件、全ページ比較、完成デザインまで広げず、5件のURLと一つの構成メモで試します。量を増やす基準は、出力の長さよりも、次の判断に使えたかどうかです。読めないページが多いなら、情報源や依頼範囲を変える方が先になります。
8．今日やることは、入力の保存場所を一度見直す
最初に見直すのは、普段の依頼で使う材料です。アカウントに渡した資料か、手元のフォルダーか、ログインした管理画面か。それぞれを一行ずつ書き出し、PCを閉じると届かなくなる工程を確認します。
次に、一つの新しいタスクで「調査→構成メモ→人の照合」までを試します。クラウドへ移ったことを理由に、制作全体の無人運転を急ぐ必要はありません。まず、離席中に下準備が進み、戻ったときに根拠と判断材料を受け取れる流れを作る。その成果物が使えると確かめてから、定期実行へ広げてください。
情報確認：2026年10月7日。図解は公式資料の説明と、本記事独自の制作例を整理したもので、製品画面・実測結果ではありません。UIと利用条件は更新されるため、設定時には本文中の公式リンクも確認してください。