Coworkタスク指示の書き方 — 「やり方」でなく「欲しい結果」を書く

Claude Coworkの製品ページには「Say what, not how」という一文があります。「どうやるかでなく、何が欲しいかを言え」という意味で、Coworkにタスクを渡すときの唯一の設計原則です。手順を細かく書くほど良い結果が出ると考えがちですが、Coworkの実行アーキテクチャではむしろ逆に働くことがあります。この記事では、なぜそう言えるのかを内部動作から説明し、実際にどう書き分ければいいかを示します。

「Say what, not how」とは何か

「Say what, not how」とは、Coworkへの指示を「達成したい結果」だけで書き、「その結果に至る手順」は書かないという設計原則です。公式ページの説明文はこうです。「Tell Claude what you need, not how. It opens browsers for web tasks and takes over your screen only when it has to. You're always in control.」(Claudeに必要なことを伝えてください、やり方ではなく。ウェブ作業ではブラウザを開き、必要なときだけ画面を引き継ぎます。あなたは常にコントロールを保てます)

この一文には2つの主張が入っています。ひとつは「手順はClaude側が決める」こと、もうひとつは「それでも制御を失わない」ことです。後者は承認モードという別の仕組みが担保しているので、両立します。この関係は後段で扱います。

なぜ「やり方」を書くと精度が落ちるのか

結論から言うと、Coworkは指示を受け取った時点で自分の計画を立てるため、人間が先回りして手順を固定すると、その計画と衝突しやすくなります。公式のGet Startedガイドは、タスク開始後のCoworkの動きをこう説明しています。

• リクエストを解析し、計画を立てる
• 必要に応じて複雑な作業をサブタスクに分割する
• 隔離された環境でコードとシェルコマンドを実行する
• 妥当なら複数の作業を並行して調整する
• 完成した成果物をセッションに届ける

これはClaude Codeを支えているのと同じエージェント的アーキテクチャです。タスクを渡した瞬間から、Coworkは「何が最短経路か」「どのサブタスクに分けるべきか」を自分で評価しています。ここに人間が「まずAをして、次にBをして、Cを確認してからD」という手順書を重ねると、Coworkの評価と食い違う指示が発生します。

食い違いが起きたとき、Coworkは基本的に人間の指示を優先します。結果として、実行中に見つかった近道や、失敗したときの回復ルートを使わず、指定された手順をなぞろうとして遠回りになる、あるいは手順の途中で前提が崩れて止まる、という事態が起きます。手順を固定するほど、Coworkが持っている計画能力とサブエージェント連携の恩恵を引き出しにくくなるという構図です。

具体例で考えます。「請求書フォルダを整理して」という結果指定の指示なら、Coworkはフォルダの中身を見た時点でファイル形式や命名規則の実態を把握し、それに合わせた分類方法を選べます。ここに「まずPDFだけを別フォルダへ移し、次にファイル名を日付形式にリネームし、最後に取引先ごとのサブフォルダへ振り分けて」と手順まで指定すると、実際にはPDF以外の形式(画像・Excel)が混ざっていた場合や、日付が読み取れないファイル名だった場合に、指示された手順のどこで止まるべきかをCoworkが自分で判断できなくなります。結果だけを渡していれば、Coworkは例外ケースを検知した時点で計画を立て直せますが、手順が明示されていると「指示にない状況」として立ち止まる確率が上がります。

「何が欲しいか」の書き方 — 具体例で見る分かれ目

結果指定と手順指定の違いは、同じ業務でも指示文の作り方で明確に分かれます。公式ガイドが挙げる例(「Organize my Downloads folder by type and date」= Downloadsフォルダを種類と日付で整理して)は、この原則をそのまま体現した書き方です。

手順指定側に共通するのは、「どのツールを、どの順番で使うか」まで人間が決めていることです。結果指定側は「最終的にどんな状態になっていればいいか」だけを書き、経路の選択はCoworkに委ねています。ツールの選び方やサブタスクへの分割は、Coworkの計画フェーズがすでにやっている仕事なので、そこを人間が重複して指定する必要はありません。

一方で、結果指定に「制約」を足すのは原則に反しません。分量・期限・使ってよい情報源・出力形式(スプレッドシートかMarkdownか)といった条件は「欲しい結果の輪郭」であって「手順」ではないため、むしろ具体的に書くほど精度が上がります。原則が禁じているのは手順の指定であって、条件の指定ではありません。

結果を書いても制御を失わないのはなぜか

「常にコントロールを保てる」という後半の主張は、指示文とは別の仕組みで実現されています。Coworkには行動の承認方法を決める3つのモードがあります。

• 手動承認(Manual): 接続先ツールの使用など、個々のアクションのたびにClaudeが確認を求め、許可か拒否かを選ぶ
• 自動承認(Auto): Claudeが各アクションを安全性の観点で自己チェックし、危険と判断したものは自動でブロックする。書き込み・削除系のツールは状況に応じてClaudeが可否を判断する
• すべてスキップ(Skip): 確認を挟まず、チェックもかけない。関わるツール・ファイル・アプリすべてを完全に信頼できる場合限定

つまりCoworkにおける「制御」は、タスクの実行経路(手順)ではなく、個々のアクションの承認という別レイヤーで担保されています。ここを理解しないまま「不安だから手順を細かく書いておこう」とすると、本来は承認モードの役割であるはずの安心感を、指示文の中に押し込めようとしていることになります。手順を書き込んでも承認は自動で通ってしまうため、安全性は上がらず、むしろ計画の柔軟性だけが失われます。制御したいのが「危険な操作をさせない」ことなら承認モードを、「経路を決める」ことなら結果指定の指示文を、それぞれ担当を分けて考えるのが筋です。

自動承認モードの中身も、この分離を裏付けています。自動承認では、Claudeが各アクションをデータの持ち出しやプロンプトインジェクションといった観点で自己チェックし、危険と判断したものを自動でブロックします。ブロックが続くとClaudeは自分から手動承認モードへ切り替え、人間の判断を仰ぎます。つまり安全性のチェックはタスク開始時の指示文一発ではなく、実行中の各アクションに対して継続的にかかる仕組みです。指示文をどれだけ丁寧に書いても、この継続チェックの代わりにはなりません。

グローバル指示にも同じ原則が働く

「Say what, not how」はタスク単位の指示文だけでなく、Coworkの設定にある標準指示(Settings > Coworkの「Global instructions」)にも同じ形で当てはまります。標準指示は「希望する文体」「出力形式」「自分の役割の背景」といった、全セッションに共通して適用したい前提を書く欄です。ここに書くべきなのも「トーンはですます調で」「Markdown表を優先」のような結果・制約の情報であって、「まずこう確認してから作業を始めて」という手順ではありません。デスクトップ版ではフォルダごとの指示(Folder instructions)も設定でき、Claude自身がセッション中にこの内容を更新することもあります。標準指示・フォルダ指示・タスク本文のどれであっても、書くべき内容の種類は変わらないという点で、この原則はCoworkの指示体系全体を貫いています。

指示が「言い過ぎ」になっているサインと直し方

自分の指示文がまだ手順指定に寄っているかどうかは、いくつかの兆候で見分けられます。

• 指示文の中に番号付きの手順(「1. まず〜 2. 次に〜」)が並んでいる
• 「どの画面のどのボタンを押すか」までUI操作を指定している
• ツールを使う順番(検索してからコピーして、Excelを開いてから)を明示している
• 最終成果物とは無関係な中間チェックポイントを挟んでいる(「10件集めたら一度見せて」など、最終アウトプットの精度に寄与しない確認)

これらが1つでも入っている場合、その部分を「最終的に何が欲しいか」の文へ置き換えられないか見直します。番号手順を消したときに情報が失われるなら、それは制約(順序に業務上の意味がある場合など)として残し、単なる操作の言い換えなら削除します。逆に、出力形式・分量・使う/使わない情報源・締め切りは削らずむしろ具体的に書くべき条件です。

指示文を「結果 + 制約」の2層だけに絞ると、Coworkの計画フェーズが持っている経路選択の自由度を活かせます。具体的な依頼文のテンプレートが欲しい場合はClaude Cowork業務テンプレート12選にまとまっています。指示の優先順位(グローバル指示・フォルダ指示・タスク本文がどう競合するか)はCoworkの指示、優先順位はどう決まるか、複数のサブタスクが並行して走る仕組みそのものを詳しく知りたい場合はCoworkの並列実行の仕組みと指示のコツで扱っています。

まとめ

Coworkの「Say what, not how」は、タスク指示から手順を取り除き、結果と制約だけを残す設計原則です。背景には、Coworkがタスクを受け取った時点で自分の計画を立て、サブタスクへの分割や並行実行の判断を担っているという実行アーキテクチャがあります。手順を人間が固定すると、この計画能力と衝突し、かえって遠回りや停止を招きます。制御を失う不安は指示文の詳細化ではなく、手動承認・自動承認・スキップという承認モードの選択で解消するのが筋です。指示文を書くときは「番号手順」や「操作の順番」が紛れ込んでいないかを見直し、結果と制約の2層に絞ることを目安にしてください。