Claude Cowork ベストプラクティス17選｜プロンプトより「設計」で差がつく理由

カイ@プロダクトマネージャー

2026/03/26

Claude Cowork ベストプラクティスより先に知るべき「設計」の考え方

Claude Coworkを使い始めたけど、正直こんな状態になっていませんか。

「プロンプトを何度も書き直しているのに、出力が安定しない」「ChatGPTの感覚で使ってみたけど、思ったほど成果が出ない」 ――もしドキッとしたなら、安心してください。

あなたのプロンプト力が足りないわけじゃないんです。

その手前の「設計」が足りていないだけかもしれません。

2026年3月、AIの実践的な活用法を発信しているNav Toor氏がXに投稿した「17 Best Practices That Make Claude Cowork 100x More Powerful」が大きな反響を呼びました。

日本でもチャエン氏の紹介ツイートを通じて一気に拡散され、多くのCoworkユーザーの間で話題になっています。

この17の方法の核心メッセージは明快です。

ChatGPT時代の武器は「プロンプト工学」だった。

Cowork時代の武器は「システム工学」だ。

これ、読んだ瞬間に「うわ、そういうことか」ってなりませんか。

つまり、プロンプトの書き方をいくら磨いても、コンテキスト・構造・スキル・制約の「設計」がなければ天井があるということです。

逆に言えば、設計さえ整えれば、雑なプロンプトでも安定した成果が返ってくる。

これ、めちゃくちゃ希望のある話だと思いませんか。

この記事では、Nav Toor氏の17の方法を「コンテキスト設計」「タスク設計」「自動化」「プラグイン&スキル」「安全運用」の5パートに整理し、日本語ユーザーの業務文脈に合わせて解説します。

Part 1：コンテキスト設計 ── Claude Coworkの精度の9割はここで決まる（方法1〜5）

Coworkの出力品質を左右する最大の要因は、プロンプトではなくどんな情報を読ませるかです。

ここ、地味に見えて超重要です。

ここを軽視すると、どれだけ時間をかけてプロンプトを練っても全部ムダになります。

Part 1では、Coworkに渡すコンテキストを設計する5つの方法を紹介します。

方法1：_MANIFEST.mdでファイルの「読む/読まない」を宣言する

Coworkにフォルダを渡すと、中のファイルを自動的に読み込みます。

しかし、ファイルが増えるほど「読む必要のないファイル」もCoworkのコンテキストに入り、出力の品質が下がります。

「全部読んでくれるなら多いほうがいいのでは？」と思いがちですが、実はこれが罠なんです。

Nav Toor氏のスレッドでは、462ファイルのフォルダでCoworkが矛盾した出力を出し続けた事例が紹介されています。

原因は、古い提案書と最新の方針書が同時にコンテキストに入っていたこと。

人間でも、会議中に去年の資料と今年の資料がごちゃ混ぜで配られたら頭がバグりますよね。

Coworkも同じです。

で、その解決策が_MANIFEST.md。

フォルダ内のファイルを3つのTierに分類し、Coworkに「何を優先的に読むべきか」を宣言します。

# _MANIFEST.md

## Tier 1（正本 - 必ず読むべきファイル）
- project-brief.md  ← 最新の案件概要
- brand-guidelines.md  ← ブランドルール

## Tier 2（領域別 - 必要に応じて参照）
- research/competitor-analysis.md
- research/user-interviews.md

## Tier 3（アーカイブ - 基本的に読まない）
- archive/2025-draft-v1.md
- archive/old-proposal.md

ファイル名の先頭にアンダースコア(_)をつけることで、フォルダ内の一番上に表示されます。

Coworkは自然言語を理解するので、このファイルを置いておくだけで「Tier 1を最優先で参照すべき」と判断してくれます。

これが嬉しいのは、たった1つのMarkdownファイルを追加するだけで出力の矛盾が消えること。

作業時間30秒、効果は絶大。

コスパ最強の方法です。

方法2：Global InstructionsをOSとして設計する

Claude Desktopの「Settings → Cowork → Global Instructions」には、すべてのセッションに共通する指示を設定できます。

Nav Toor氏はこれをCoworkのOS（オペレーティングシステム）と呼んでいます。

この「OS」という比喩、めちゃくちゃ言い得て妙です。

OSを入れないPCは起動するたびに挙動がバラバラですよね。

Coworkも同じで、Global Instructionsがないと毎回のセッションで出力の傾向がブレまくります。

ここに入れるべきは、毎回のプロンプトで繰り返すのが面倒な恒久的なルールです。

# Global Instructions の設定例

## 読み込みルール
- フォルダ内に_MANIFEST.mdがある場合、必ず最初に読み込むこと
- _MANIFEST.mdのTier分類に従ってファイルの優先度を判断すること

## 作業フロー
- タスクを実行する前に、必ず計画を提示して承認を待つこと
- 計画を承認されてから実行に移ること

## 出力ルール
- 出力はMarkdown形式で統一すること
- 不要な前置き・言い訳は書かないこと
- 指示に曖昧さがあれば、推測せずに質問すること

これを設定しておくだけで、雑なプロンプトでも安定した品質の出力が得られます。

毎回「Markdownで書いて」「計画を先に見せて」と指示する手間がなくなる。

「あれ、なんで毎回同じこと言ってるんだろう」って思ったことありませんか。

それ、今すぐGlobal Instructionsに移してください。

その瞬間からストレスが1つ消えます。

方法3：3つの永続コンテキストファイルを作る

Global Instructionsは「ルール」を書く場所です。

一方、Coworkにあなた自身のことを理解させるには、別のファイルが必要です。

Nav Toor氏は以下の3ファイルを推奨しています。

about-me.md ── 自分の役割・専門領域・プロジェクト背景
brand-voice.md ── 文章のトーン・スタイル・避けるべき表現
working-style.md ── 好みの作業の進め方・フィードバック方法

この3ファイルが効くと何が嬉しいかっていうと、Coworkの出力から「AI臭」が消えるんです。

Coworkはデフォルトだと汎用的なビジネス文体で出力します。

あの「いかにもAIが書きました」という、どこか他人事みたいな文章、イラっとしませんか。

brand-voice.mdに「カジュアルな敬語を使う」「専門用語は初出時に説明する」と書いておけば、あなたの文体に近い出力が得られます。

Nav Toor氏のアドバイスは「毎週リファインすること」。

少しずつ修正を重ねるたびにCoworkの出力精度が上がり、効果が複利のように積み上がっていくと説明しています。

1週間で劇的に変わるものではないけれど、1ヶ月続ければ「これ、自分が書いたのと区別つかない」レベルに近づきます。

これ、やった人だけが実感できる気持ちよさです。

方法4：Folder Instructionsで案件別ルールを重ねる

Global Instructionsが「すべてのセッションに適用されるルール」なら、Folder Instructions（フォルダ指示）は特定のフォルダにだけ適用されるルールです。

この仕組みにより、以下の3レイヤー構造でCoworkへの指示を管理できます。

レイヤー

範囲

設定例

Global Instructions

全セッション共通

作業フロー、出力形式、読み込みルール

Folder Instructions

案件/フォルダ別

クライアント固有の用語集、納品形式、制約事項

Prompt（直接の指示）

そのタスク限定

「今回は第3章だけ書いて」

ソフトウェア開発の「設定ファイルの階層構造」と同じ考え方ですね。

グローバル設定 → プロジェクト設定 → ローカル設定。

エンジニアなら「あ、あのパターンか」とピンとくるはずです。

たとえばクライアントAのフォルダには「敬体で書く」「数字は万単位」、クライアントBのフォルダには「常体で書く」「数字はK/M表記」というように、案件別のルールをフォルダ単位で切り替えられます。

案件が10個、20個と増えても、フォルダごとに独立しているので管理が破綻しません。

これ地味にありがたくないですか。

方法5：「全部読ませない」── スコープ管理が精度を決める

Claude Coworkのコンテキストウィンドウ（一度に処理できる情報量）は、Opus 4.6モデルで最大100万トークンと非常に大容量です。

しかし、コンテキストが大きいからといって全部読ませればいいわけではありません。

Nav Toor氏は「コンテキストウィンドウが大きくても、ノイズが増えれば品質は下がる」と警告しています。

想像してみてください。

机の上に資料を100枚広げて仕事をするのと、必要な3枚だけ置いて仕事をするのと、どちらが集中できますか。

答えは明白ですよね。

Coworkもまったく同じなんです。

実践的なポイントは以下の通りです。

方法1の_MANIFEST.mdでTier分類し、不要なファイルを除外する
1つのタスクに関連するファイルだけをフォルダに入れる
過去の成果物はarchive/フォルダに移動し、Tier 3に分類する
「このタスクにはどのファイルが必要か？」と意図的に考える習慣をつける

Part 1のまとめです。

コンテキスト設計は「Coworkに何を読ませるか」を意図的にコントロールする技術です。

ここに手を抜くと、どれだけ良いプロンプトを書いても出力が安定しません。

**プロンプトを工夫する前に、まずコンテキストを整える。 ** この順番を覚えておくだけで、マジで成果が変わります。

Part 2：タスク設計 ── 「完成品」を受け取る指示の出し方（方法6〜10）

コンテキストが整ったら、次はタスクの渡し方です。

Coworkはチャットボットではなくコワーカー（同僚）です。

同僚に仕事を頼むときと同じように、「何ができたら完了か」を明確にすると、驚くほど出力の質が変わります。

「なんとなくお願い」して「なんとなく返ってくる」状態から、「完成形を定義」して「完成品を受け取る」状態へ。

この切り替え、一度体験すると本当に感動しますよ。

Part 2はその方法です。

方法6：手順ではなく「Done（完成形）」を定義する

Coworkに指示を出すとき、多くの人は「手順」を書いてしまいます。

「まずこれを読んで、次にこれをして、それからこうして...」と。

しかしNav Toor氏は、手順よりも「完成形」を定義するほうがはるかに効果的だと指摘しています。

なぜか。

手順を書くと、Coworkは「その通りに動く」ことが目的になります。

完成形を書くと、「その状態に到達する」ことが目的になる。

Coworkが自分で最適な手順を考えてくれるので、実は完成形の定義のほうが柔軟で高品質な出力につながります。

具体的には、以下の3つの質問に答える形で指示を書きます。

何ができたら完了か？（Done条件）
制約は何か？（守るべきルール）
不確実なときどうするか？（判断基準）

悪い指示と良い指示を比較してみてください。

この差、一目瞭然です。

# 悪い指示（手順を書いている）
リサーチフォルダの資料を読んで、競合分析のセクションを見つけて、
主要な競合3社の情報をまとめて、それぞれの強みと弱みを分析して、
比較表を作成してください。


# 良い指示（完成形を定義している）
## Done条件
主要競合3社の比較分析レポート（Markdown形式、2000字以内）

## 制約
- 情報源はresearch/フォルダ内の資料のみ
- 各社の「強み」「弱み」「当社への示唆」の3項目で整理
- 数値データがある場合は必ず含める

## 不確実な場合
- データが見つからない項目は[要確認]と明記する
- 3社に絞れない場合は、売上規模上位3社を選定する

この形式で指示を出すと、Coworkは「何を作ればいいか」を正確に理解し、手戻りが激減します。

最初は面倒に感じるかもしれませんが、手戻りに費やしていた時間を考えたら圧倒的に速いです。

騙されたと思って一度やってみてください。

方法7：実行前に必ずPlan確認を挟む

方法2のGlobal Instructionsに「計画を提示→承認後実行」のルールを入れたのを覚えていますか？ Nav Toor氏はこれを最も費用対効果の高い設定と呼んでいます。

理由はシンプルです。

Coworkが計画を提示してくれれば、30秒のレビューで「方向性が合っているか」を確認できます。

方向がズレたまま20分作業されて、出てきた結果に「いや、そうじゃなくて...」ってなった経験、ありませんか。

あのガッカリ感、もう味わわなくてよくなります。

**30秒の確認で20分の手戻りを防げる。 ** これが「最も費用対効果が高い」と言われる理由です。

Global Instructionsに以下のように書いておきましょう。

## 作業フロー
1. タスクの計画を箇条書きで提示する
2. 私の承認（「OK」「進めて」等）を待つ
3. 承認後に実行する
4. 完了後に成果物の概要を報告する

方法8：不確実な時のルールを書く

Coworkは指示が曖昧だと「推測」で作業を進めてしまうことがあります。

推測が当たっていれば問題ありませんが、外れていると大きな手戻りになります。

「なんか違うんだよな...」「惜しいけどそうじゃない...」っていう微妙なズレがずっと続くこと、ありませんか。

それ、Coworkが推測で判断している可能性が高いです。

Nav Toor氏は、不確実な状況でのCoworkの行動をあらかじめルール化することを推奨しています。

## 不確実時のルール
- 日付が不明な情報には [VERIFY] タグをつける
- ファイルの保存先に迷ったら needs-review/ フォルダに一時保存する
- 確信度が80%未満の判断は、実行せずにフラグを立てて報告する
- 複数の解釈が可能な指示は、最も保守的な解釈を採用する

このルールを書いておくと、Coworkが「わからないまま暴走する」事故を防げます。

特に重要なデータを扱う業務では、これがないと怖くて任せられません。

ソフトウェア開発で言えば、エラーハンドリングの設計と同じ発想ですね。

「想定外の入力が来たときにどう振る舞うか」を事前に決めておく。

これがあるだけで安心感が段違いです。

方法9：関連タスクは1セッションにまとめる

「5つの別セッションで1つずつタスクを実行する」よりも、「1セッションで5つのタスクを実行する」ほうが、コスト効率も品質も高くなります。

理由はコンテキストの共有です。

1セッション内であれば、Coworkは前のタスクで得た情報を次のタスクにも活用できます。

別セッションだと、毎回ゼロから情報を読み込み直す必要があります。

身近な例で考えてみてください。

同僚に「競合分析やっておいて」と頼んだ直後に「その結果を使って戦略資料作って」と頼めば、スムーズに繋がりますよね。

でも翌日改めて「昨日の競合分析の結果を踏まえて戦略資料を...」と一から説明し直すの、地味にストレスたまりませんか。

Coworkのセッションもこれとまったく同じです。

たとえば「競合分析→戦略立案→提案書作成」という3つの連続タスクは、1セッションでまとめて依頼しましょう。

競合分析の結果がそのまま戦略立案に活かされ、一貫性のある提案書が仕上がります。

情報のロスがない分、クオリティが目に見えて上がりますよ。

方法10：subagentsで並列処理する

Coworkの強力な機能の1つがsubagent（サブエージェント） です。

メインのCoworkが複数のサブエージェントを起動し、独立したタスクを並列で処理できます。

起動方法はシンプルです。

プロンプトに「Spin up subagents to...」と書くだけ。

Spin up subagents to analyze the following 4 vendor proposals:
- vendor-a/proposal.md
- vendor-b/proposal.md
- vendor-c/proposal.md
- vendor-d/proposal.md

Each subagent should evaluate: pricing, delivery timeline,
technical capability, and risk factors.
Then consolidate into a comparison table.

Nav Toor氏の事例では、4社のベンダー比較が40分から10分に短縮されたとのことです。

4倍速ですよ、4倍速。

4つの独立タスクを4並列で走らせているので理屈上は当然なんですが、これが1行のプロンプトで実現できるのは本当に強力です。

subagentが有効なのは、独立して処理できるサブタスクがある場合です。

互いに依存するタスクには向きません。

また、Nav Toor氏はモデルにOpus 4.6の使用を推奨しており、トークン消費量は増える点に注意してください。

Part 2の5つの方法は、要するに「Coworkをチャットボットではなく、優秀な同僚として扱う」ためのテクニックです。

指示の出し方を変えるだけで、返ってくる成果物の質がここまで変わるのかと、最初は正直びっくりするはずです。

Part 3：自動化 ── Claude Coworkを「自律システム」に進化させる（方法11〜13）

Part 1でコンテキストを設計し、Part 2でタスクの渡し方を整えました。

ここからは、Coworkに繰り返し作業を自動で実行させる方法です。

ここまでの方法で「1回のタスク」の品質は上がっています。

でも毎週同じ作業を手動でやっているなら、まだまだ伸びしろがあります。

ここからが本当にワクワクするパートです。

方法11：/scheduleで定期タスクを自動実行する

Coworkには/scheduleコマンドがあり、定期的なタスクをスケジュール実行できます。

Nav Toor氏は以下のような活用例を紹介しています。

毎週月曜の朝：今週の予定・優先タスクをまとめたブリーフィングを生成
毎週金曜の夕方：1週間のタスク進捗をまとめたステータスレポートを生成
毎日：競合3社のニュースを追跡し、変化があれば要約レポートを作成

想像してみてください。

月曜の朝、PCを開いたら今週のブリーフィングがもう出来上がっている。

金曜の夕方には週報の下書きが完成している。

この「自分が何もしなくても回っている」感覚は、一度体験すると本当に戻れなくなります。

ただし制約があります。

/scheduleが動作するのはPCが起動していて、かつClaude Desktopが起動している間のみです。

クラウド上で24時間稼働するわけではありません。

なお、PCがスリープ状態から復帰した際には、スキップされたタスクが自動的に実行されます。

方法12：記憶はすべてファイルに外部化する

Coworkの重要な特性として、セッション間の記憶を持たないという点があります。

前のセッションでどれだけ詳しく説明しても、新しいセッションではゼロからスタートです。

「さっき言ったじゃん...」ってイラッとしたこと、ありませんか。

あの脱力感、めちゃくちゃわかります。

でもこれはCoworkの欠点ではなく、設計で解決すべき仕様なんです。

この問題を解決するのが「記憶のファイル化」です。

SOP（標準作業手順書） ── 繰り返す作業の手順をMarkdownで文書化
ログ ── 過去の意思決定や作業履歴を記録
テンプレート ── 頻繁に使う出力フォーマットを定義

Nav Toor氏のスレッドでは、大規模な週次レビューシステムを一度構築し、以降は毎週そのファイルを読み込ませるだけで同品質のレビューが実行できる仕組みを作った事例が紹介されています。

ポイントは、最初の構築に時間を投資すれば、以降は繰り返し使える資産になるということです。

コードで言えば、関数化・モジュール化と同じ考え方ですね。

一度書いたら何度でも呼び出せる。

エンジニアなら「あー、それね」と腹落ちする感覚じゃないでしょうか。

方法13：コネクタ × /schedule で半自動運用する

Coworkは多数の外部サービスとコネクタ連携が可能です。

Gmail、Slack、Google Drive、Google Calendarなど主要なビジネスツールが対応しています。

これと/scheduleを組み合わせると、半自動の業務フローが構築できます。

スケジュール

コネクタ連携

処理内容

毎週月曜

Slack

#product-feedbackチャンネルの投稿を集約し、Google Driveにレポート保存

毎朝

Gmail

請求書メールを検出し、経費管理シートを更新

毎日夕方

Google Drive

タスクの進捗をまとめ、Slackで日報送信

コネクタの設定はClaude Desktopの「Customize → Connectors」から行えます。

連携したいサービスのアカウントで認証するだけで使えるようになります。

Part 3の自動化は、一度仕組みを作れば毎日の作業時間を大幅に削減できます。

Part 1〜2が「1回の品質」を上げる投資なら、Part 3は「毎日の時間」を生み出す投資です。

「仕組みが勝手に働いてくれる」という体験、ぜひ味わってみてください。

Part 4：プラグイン＆スキル ── Claude Coworkの能力を拡張する（方法14〜16）

ここまでの方法はCoworkの「使い方」を最適化するものでした。

Part 4では、Coworkの「能力」そのものを広げるプラグインとカスタムスキルの活用法を紹介します。

デフォルトのCoworkは「何でもそこそこできる汎用AI」です。

ここに専門スキルを追加すると、「特定の業務に特化した専門AI」に変わります。

この変化、想像以上にインパクトがあります。

方法14：プラグインは複数スタックして使う

Claude Coworkのプラグインは、ドメイン別の専門スキルをCoworkに追加する仕組みです。

重要なのは、プラグインは1つだけでなく複数を組み合わせて使えるということ。

ここが面白いんです。

たとえば以下のような組み合わせが考えられます。

Data Analysis + Sales ── 営業データを分析し、売上予測レポートを生成
Writing + SEO ── SEOを意識した記事を自動作成
Research + Summarization ── 市場調査データを収集し、要点を要約

各プラグインは独立したスキル集なので、複数を有効にすると能力が合成されます。

「分析しながら文章を書く」「リサーチしながら比較表を作る」といった複合タスクに対応できるようになります。

単体で使うよりも、組み合わせで使うほうが真価を発揮する。

UNIX哲学の「小さなプログラムをパイプで繋ぐ」に通じるものがありますよね。

方法15：繰り返し作業はカスタムスキルにする

プラグインは公式に用意されたものですが、カスタムスキルは自分で作ることができます。

Markdownファイルでスキルの定義を書き、Coworkに読み込ませるだけです。

Nav Toor氏が紹介しているスキルファイルの構造は以下の通りです。

# Article Drafting Skill

## Purpose
与えられたトピックについて、SEOを意識した記事の初稿を作成する

## Inputs
- topic: 記事のトピック
- target_audience: 想定読者
- word_count: 目標文字数
- tone: 文体（カジュアル / フォーマル）

## Process
1. トピックに関連するキーワードを5つ提案する
2. 記事構成（見出し構造）を作成して承認を待つ
3. 承認後、各セクションの本文を執筆する
4. メタディスクリプション（120字以内）を作成する

## Output
- Markdown形式の記事本文
- メタディスクリプション
- 使用したキーワードリスト

## Constraints
- 一文は80字以内を目安とする
- 見出しは最大H3まで
- 引用元のない統計データは使用しない

使い方は「Run my article drafting skill on [トピック]」とプロンプトに書くだけです。

毎回同じ品質のアウトプットが得られるので、繰り返し発生する作業に最適です。

これ、よく考えるとソフトウェア開発の「関数定義」と同じですよね。

入力・処理・出力・制約を定義して、呼び出すだけで動く。

エンジニアにとっては「なるほど、そう来たか」と膝を打つ設計だと思います。