Claude Cowork を最強にする 17 の方法 — プロンプトではなく「設計」で差がつくシステム工学

@masahirochaen 氏が X で投稿した、Claude Cowork のベストプラクティス解説が反響を呼んでいます。

海外でバズった「Claude Cowork を最強にする 17 の方法」の学びが深い。プロンプト力ではなく「仕組み」で差がつく

元になっているのは @heynavtoor（Nav Toor）氏の X Article「17 Best Practices That Make Claude Cowork 100x More Powerful」です。Nav Toor 氏は 2026 年 1 月 12 日から Cowork を使い始め、7 週間で 400 セッション以上を重ねた経験をもとに、Anthropic が公式ドキュメントに書いていない 17 の実践法をまとめています。いいね 3,194、ブックマーク 13,149、閲覧 188 万超と大きな反響を得ました。本記事では、この 17 の方法を技術的に掘り下げて解説します。

Claude Cowork とは

Claude Code との違い

Claude Cowork は、Anthropic が提供する非エンジニア向けの AI エージェント環境です。Claude Code がターミナルベースの開発者向けツールであるのに対し、Cowork は Claude デスクトップアプリ内で動作する GUI ベースの作業環境です。

Cowork の本質は「Claude にローカルフォルダへのアクセスを与え、ファイルの読み書きを自律的に行わせる」ことです。コードを実行する代わりに、ドキュメント作成・データ整理・レポート生成などのナレッジワークを自動化します。

素の Cowork は「おもちゃ」

Nav Toor 氏が強調するのは、設定なしの Cowork は凡庸だということです。

素の Cowork の問題:

  1. フォルダ内の全ファイルを読もうとする → コンテキスト溢れ
  2. 毎回ゼロから文脈を説明する必要がある → 非効率
  3. 出力が「AI っぽい」汎用的な文章になる → 品質が低い
  4. 複雑なタスクで途中で止まる → 信頼性が低い

これらの問題を解決するのが、17 のベストプラクティスです。

Part 1: コンテキスト設計（17 のうち最重要）

Nav Toor 氏は「ここが 9 割」と断言しています。Cowork の出力品質は、プロンプトの巧みさではなく事前のコンテキスト設計で決まります。

1. _MANIFEST.md を必ず置く

_MANIFEST.md は、フォルダ内のファイルを**3 つの階層（Tier）**に分類するマニフェストファイルです。ファイル名のアンダースコアにより、フォルダの先頭にソートされます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# _MANIFEST.md

## Tier 1: Canonical（必ず読む）
- brand-guidelines.md（ブランドガイドライン）
- product-roadmap.md（製品ロードマップ）
- team-structure.md（チーム構成）

## Tier 2: Domain（必要時のみ）
- /marketing → マーケティング関連
- /engineering → 技術ドキュメント
- /finance → 財務データ

## Tier 3: Archival（読ませない）
- /archive → 過去のドラフト、旧版
- /deprecated → 廃止されたドキュメント

462 ファイルのフォルダでも、この Tier 分類により Claude は必要なファイルだけを選択的に読み込みます。「全部読む問題」を防ぎ、コンテキストウィンドウの浪費を回避します。

Tier 間で矛盾がある場合は Tier 1 が優先されます。これにより、正本の権威が保たれます。

2. Global Instructions を OS 化する

Global Instructions は、Settings > Cowork で設定する全セッション共通の指示です。Nav Toor 氏はこれを「OS」と表現しています。

Global Instructions の設計例:

  行動原則:
    - 作業開始前に必ず Plan を提示し、承認後に実行する
    - _MANIFEST.md を最優先で読み込む
    - 不確実な場合は推測せず確認する

  出力形式:
    - Markdown 形式で構造化する
    - 冗長な前置きを省く
    - 箇条書きと表を積極的に使う

  安全規則:
    - ファイルを削除しない
    - 既存の内容を上書きする前に確認する

この設定により、毎回「簡潔に書いて」「計画を見せて」と言う必要がなくなります。一度設定すれば全セッションに適用されるため、安定した品質が得られます。

3. 3 つの永続ファイルを作る

以下の 3 つのコンテキストファイルを作成し、Tier 1 に配置します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# about-me.md

## 私について
- 役割: プロダクトマネージャー
- チーム: エンジニア 5 名、デザイナー 2 名
- 担当プロダクト: B2B SaaS（プロジェクト管理ツール）
- 主なステークホルダー: CTO、営業チーム

## コミュニケーション
- 社内報告は簡潔に（箇条書き推奨）
- クライアント向けは丁寧語
- 技術用語は非エンジニアにも分かるように

Nav Toor 氏によると、これらのファイルは週次で微調整することで、出力品質が継続的に向上します。

4. Folder Instructions で案件別ルールを設定

Folder Instructions は、特定のフォルダに紐づく案件固有の指示です。

フォルダ構造と Instructions の適用:

  ~/work/
  ├── client-a/          ← Folder Instructions: A 社用語集、締切、成果物形式
  │   ├── _MANIFEST.md
  │   └── ...
  ├── client-b/          ← Folder Instructions: B 社のブランドガイドライン
  │   ├── _MANIFEST.md
  │   └── ...
  └── internal/          ← Folder Instructions: 社内ルール
      └── ...

  適用順序:
    Global Instructions（全セッション共通）
    → Folder Instructions（フォルダ固有）
    → _MANIFEST.md（ファイル優先度）
    → セッション中の指示

Global Instructions が「OS」なら、Folder Instructions は「アプリケーション設定」に相当します。

5. 「全部読ませない」

5 つ目のプラクティスは、上記 4 つの総括です。

コンテキスト管理の原則:

  × フォルダを開いて「全部読んで」
  → 462 ファイルを全部読もうとしてコンテキストが溢れる

  ○ _MANIFEST.md で Tier 分類 + スコープ限定
  → 必要なファイルだけ選択的に読み込む

  スコープ管理 ＝ ノイズ削減 ＝ 精度向上

これは Claude Code における CLAUDE.md の設計思想と同じです。コンテキストは希少資源であり、必要な情報だけを必要なタイミングで渡すことが品質を決定します。

Part 2: タスク設計（完成品にする）

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

× 手順指示:
  「競合を調査して、表にまとめて、レポートを書いて」

○ Done 定義:
  「以下の条件を満たすレポートを作成:
    - 競合 5 社の機能比較表（価格・機能・ターゲット）
    - 各社の強み・弱みを 3 点ずつ
    - 当社の差別化ポイントを 2 つ提案
    - 形式: Markdown、2,000 字以内
    - 迷ったら「要確認」タグを付けて続行」

「どうやるか」ではなく「何ができていれば完成か」を定義します。Claude は手順を自分で組み立てる能力があるため、ゴールを明確にする方が高品質な出力が得られます。

7. 実行前に必ず Plan 確認

Global Instructions に「Plan 提示 → 承認 → 実行」のフローを組み込みます。これにより、Claude が意図と異なる方向に進んでしまう事故を防ぎます。

Claude Code の Plan モード（Shift+Tab）や EnterPlanMode と同じ思想です。

8. 不確実時のルールを書く

不確実時のルール例:

  - 情報の確信度が低い場合: [VERIFY] タグを付ける
  - 複数の解釈が可能な場合: [needs-review] タグを付けて両案を提示
  - 外部データが必要な場合: プレースホルダーを挿入して先に進む
  - 推測で補完しない: 不明点は明示的に質問する

「推測で埋めて間違える」より「不明点を明示して確認を求める」方が、結果的に高品質になります。

9. 作業は 1 セッションにまとめる

Cowork のセッションはコンテキストを保持しています。1 つのタスクを 1 セッションで完結させることで、コンテキストの一貫性が保たれ、速度・コスト・品質が最適化されます。

セッションを分割すると、毎回コンテキストの再構築が必要になり、効率が落ちます。

10. Subagents で並列処理

Cowork は複雑なタスクを自動的に分割し、複数のサブエージェントを並列に実行できます。

サブエージェントの活用例:

  タスク: 「競合 5 社の最新動向を調査」

  逐次処理（遅い）:
    A 社調査 → B 社調査 → C 社調査 → D 社調査 → E 社調査

  並列処理（Subagents）:
    サブエージェント 1: A 社調査
    サブエージェント 2: B 社調査
    サブエージェント 3: C 社調査
    サブエージェント 4: D 社調査
    サブエージェント 5: E 社調査
    → 統合レポート作成

各サブエージェントは独立したコンテキストを持つため、互いに干渉しません。調査・比較・分析タスクで劇的に高速化できます。

Part 3: 自動化

11. /schedule で定期実行

Cowork の /schedule コマンドで、定期タスクを自動実行できます。

定期実行の活用例:

  毎週月曜 9:00: 週報の下書きを生成
  毎日 18:00: 今日の作業ログを整理
  毎週金曜 15:00: 競合の新機能をチェック
  毎月 1 日: 月次レポートのテンプレート作成

注意点として、/schedule はコンピュータが起動中の場合のみ実行されます。スリープ中やシャットダウン中は実行されません。

12. 記憶はすべてファイル化する

Cowork のメモリは「会話の記憶」ではなくファイルシステムです。

ファイル化の原則:

  × Cowork に口頭で伝えた情報
  → セッション終了後に消える

  ○ Markdown ファイルに書いた情報
  → 永続的に参照可能

  管理すべきファイル:
    - SOP（標準作業手順）
    - 過去の成果物ログ
    - テンプレート集
    - 用語集・スタイルガイド

これは Claude Code の CLAUDE.md や Auto Memory（MEMORY.md）と同じ思想です。揮発するチャットではなく、永続するファイルに知識を蓄積することで、セッションを跨いだ一貫性が得られます。

13. Connectors × /schedule で半自動運用

Connectors（MCP）を通じて Slack・Gmail・Google Drive などの外部サービスと連携し、/schedule と組み合わせることで半自動運用が実現します。

半自動運用の例:

  毎日 9:00:
    1. Gmail から未読メールを取得（Connector）
    2. 重要度でフィルタリング
    3. 要約を Slack に投稿（Connector）

  毎週金曜 16:00:
    1. Google Drive から週次データを取得（Connector）
    2. レポートを生成
    3. Slack チャンネルに投稿（Connector）

Part 4: プラグイン & スキル

14. プラグインは複数併用する

Cowork のプラグインは、スキル・コネクタ・スラッシュコマンド・サブエージェントを単一パッケージに統合したものです。複数のプラグインを同時に有効化することで、能力を合成できます。

プラグイン組み合わせ例:

  分析プラグイン + 営業プラグイン
  → 市場データを分析し、営業資料を自動生成

  リサーチプラグイン + ライティングプラグイン
  → 調査結果をもとにブログ記事を自動作成

15. 繰り返し作業は Skill 化する

頻繁に行う作業は Skill（スキル）として定義します。短いプロンプトで高品質な出力が得られるようになります。

Skill 化の例:

  Skill: /weekly-report
    入力: 今週の作業ログフォルダ
    出力: 構造化された週報（Markdown）
    品質基準: brand-voice.md に準拠

  Skill: /competitor-check
    入力: 競合リスト
    出力: 各社の最新動向サマリー
    形式: 比較表 + 所感

これは Claude Code の Skills 機能（SKILL.md + scripts/ + references/ + assets/）と同じ概念です。

16. Plugin Management で独自プラグインを作成

チーム独自のプラグインを作成し、標準化できます。個人のノウハウをチーム全体で共有する仕組みです。

Part 5: 安全運用

17. Cowork は「強い社員」として扱う

Nav Toor 氏の最後のプラクティスは、Cowork を人間の社員と同じセキュリティポリシーで管理することです。

安全運用の 5 原則:

  1. バックアップ必須
     → 重要ファイルは別の場所にバックアップ

  2. 機密は別フォルダ
     → API キー、個人情報、契約書は Cowork がアクセスしないフォルダに隔離

  3. 削除禁止を明示
     → Global Instructions に「ファイルを削除しない」と明記

  4. 最初は監視
     → 初期段階では Plan 確認を徹底し、出力を検証する

  5. Prompt Injection に注意
     → 外部から取得したテキストに悪意ある指示が含まれる可能性

Cowork は隔離された仮想環境で動作するため、Claude Code よりセキュリティリスクは低いですが、ファイルの読み書き権限を持つ以上、慎重な運用が必要です。

Claude Code ユーザーへの示唆

17 のプラクティスの多くは、Claude Code にも直接応用できます。

特に _MANIFEST.md の Tier 分類は、大規模リポジトリの CLAUDE.md 設計に直接応用できます。「全部読ませない」「正本を定義する」「領域別に遅延読み込みする」という原則は、Claude Code のコンテキスト管理とまったく同じです。

「プロンプト工学」から「システム工学」へ

Nav Toor 氏とチャエン氏が共通して強調するのは、以下のパラダイムシフトです。

ChatGPT 時代: プロンプト工学
  → 「どう聞くか」が差を生む
  → 毎回プロンプトを工夫する

Cowork 時代: システム工学
  → 「どう設計するか」が差を生む
  → 一度設計すれば、10 文字の指示でクライアント品質が出る

投資すべきはプロンプトではなく設計です。数時間のセットアップが、その後の全セッションの品質を決定します。これは Claude Code における CLAUDE.md の重要性、Skills の設計、MCP ツールの選定と同じ思想です。

まとめ

• コンテキスト設計が 9 割: _MANIFEST.md による Tier 分類（Canonical / Domain / Archival）で「全部読む問題」を防ぎ、必要なファイルだけを選択的に読み込む
• Global Instructions で毎回安定品質: Plan 提示 → 承認 → 実行のフローを全セッションに適用。about-me.md / brand-voice.md / working-style.md の 3 ファイルで「AI っぽさ」を排除
• タスク設計は「Done 定義」が鍵: 手順ではなく完成形を定義し、不確実時のルール（VERIFY / needs-review タグ）を事前に設定する
• Subagents で並列処理: 調査・比較タスクを複数のサブエージェントで同時実行し、劇的に高速化
• Connectors × /schedule で半自動運用: Slack・Gmail・Drive 連携と定期実行で、日常業務を自動化
• 繰り返し作業は Skill 化: 短いプロンプトで高品質な出力を得るための再利用可能なワークフロー定義
• 「プロンプト工学」から「システム工学」へ: 投資すべきはプロンプトの巧みさではなく、コンテキスト設計とワークフロー構造。数時間のセットアップが全セッションの品質を決める

参考

• @masahirochaen 氏のポスト（日本語要約）
• @heynavtoor 氏の X Article（17 Best Practices）
• Claude Cowork: Get started — Claude Help Center
• Introducing Cowork — Claude Blog
• The Difference Between Claude Code and Cowork — Forte Labs
• How I Fixed Claude’s Context Window Problem in a 462 File Folder（DEV Community）
• cowork-context-kit — GitHub（Tiered Context Management）
• Claude Code: Best practices for agentic coding — Anthropic