Claude Coworkカスタマイズ — Skills / Projects / メモリ / CLAUDE.md / 設定の7階層

要点

Claude Coworkは7つの階層(Global Instructions / Projects / Memory / CLAUDE.md / Skills / Connectors / Scheduled Tasks)を組み合わせて自分仕様にチューニングするプロダクトです。
それぞれは役割が異なり、「どこに何を書くか」を誤ると指示が競合してレスポンスがブレます。
この記事では7階層フレームで全体像を俯瞰し、Global Instructions・CLAUDE.md・Skillファイルの動くサンプルを提示します。
ビジネスパーソン向けの最小構成から専門ユーザー向けフル構成までの3プロファイルと、実務で踏みやすい「つまずき10選」も収録します。

Coworkカスタマイズの7階層

Coworkの設定項目は公式ヘルプでも一覧化されていますが、抽象度の違うものが同じ画面に並ぶため全体像がつかみにくいのが悩みどころです。ここでは実務で使い分けやすい7階層に分類し直しました。

階層	要素	スコープ	主な用途
L1	Global Instructions	全セッション共通	一貫した前提・トーン・出力形式
L2	Projects	単一トピック束	会話 + ナレッジベース(KB)をまとめる
L3	Memory	ワーキングツリー単位	過去の修正・好みの自動学習
L4	CLAUDE.md	プロジェクト/ユーザー単位	手書きの永続指示ファイル
L5	Skills	プロジェクト/ユーザー単位	繰り返しタスクの手順レシピ
L6	Connectors	アカウント単位	Gmail・Drive・Slackなど外部接続
L7	Scheduled Tasks	タスク単位	定期自動実行

ポイントは上位層ほど広くかかり、下位層ほど局所的で具体的ということです。Global Instructionsに手順を書くとすべてのセッションが重くなり、Skillに一般原則を書いても呼び出されなければ効きません。各階層の役割を正しく切り分けるのが、Coworkを使いこなす最初の関門です。

なお、Coworkを触り始めたばかりの方はClaude Cowork入門で全体像をつかんでから本稿に戻ると理解が早いはずです。

Global Instructionsを設計する

Global Instructionsは「全Coworkセッションに常時適用される前提条件」を書く場所です。公式ヘルプでは「設定 > Cowork > グローバル指示」から編集できると案内されています。ここに書いた内容は、Projectの有無や会話内容に関係なく、毎回モデルのシステムプロンプト相当として注入されます。

書くべきこと

自分のロール(「SaaSスタートアップのPMです」「個人開発のWebメディアを運営しています」)
望ましいトーンと言語(敬体/常体、日本語/英語の出し分け)
出力の既定フォーマット(箇条書き優先 / 見出し + 表)
汎用的なNG事項(「医療・法律・投資の断定的助言はしない」等)
連絡先や組織情報など、あとで参照しやすい静的情報

書きすぎると逆効果な内容

特定タスクの手順書 — Skillに切り出す
長大な用語集 — CLAUDE.mdかProject KBに
機密データ(顧客名・契約番号・社内URL) — 常時プロンプトに乗るためリスクが高い
頻繁に更新する情報 — 運用コストがかさむ

動く例: ビジネスパーソン向けGlobal Instructions

global-instructions-business.md

# 基本設定
- 私は SaaS スタートアップの PM です。日本語で応答してください。
- トーンは敬体(ですます調)。親しみやすく、過剰にカジュアルにはしない。
- 英数字と日本語の間にスペースを入れない。
 
# 出力フォーマット
- 3 項目を超える列挙は箇条書きに。
- 比較は 2〜3 列の表に。4 列以上は定義リストで。
- コードブロックには言語名を必ず付与。
 
# やってほしいこと
- 意思決定の背景を聞かれたら「事実 / 解釈 / 選択肢」の 3 段で返す。
- 長い文章を要約するときは「3 行要約 → 詳細」の順に。
 
# 避けてほしいこと
- 医療・法律・税務・投資の断定的な助言。
- 「絶対」「間違いなく」など過度に断定的な表現。
- Anthropic 公式を騙る表現や、出典不明の数値断定。

動く例: 開発者向けGlobal Instructions

global-instructions-dev.md

# 役割
- 私はソロ開発者で、Next.js / TypeScript / Python を主に使います。
- デフォルト言語は日本語、コード内コメントは英語。
 
# コードスタイル
- TypeScript は strict モードを前提にする。
- Python は型ヒントと pydantic v2 を前提にする。
- 2 スペースインデント。セミコロンは TypeScript では省略しない。
 
# 出力のクセ
- ライブラリを提案するときは「公式 / 人気 OSS / ニッチ」のどれかを明示。
- バージョン番号を出す場合は「2026-04 時点」など鮮度を添える。
- コマンドは zsh / macOS 前提で提示。
 
# 避けてほしいこと
- 未検証の API シグネチャ断定。わからないときは「要確認」と明示。
- Deprecated なライブラリの提案。
- 非公開情報を前提とした回答。

この2つはそれぞれ15〜25行に収まるよう削ぎ落としています。Globalは短いほど効くというのが実運用での実感で、100行を超えると指示の重みが分散し、むしろ個別指示に従いにくくなります。

Projectsで文脈をまとめる

Projectsは、関連する会話・ファイル・指示をひとつのワークスペースに束ねる機能です。公式ヘルプでも「関連するタスクを独自のファイル、コンテキスト、指示、メモリを持つ別のワークスペースにグループ化できる」と説明されています。Coworkの中ではProjectがナレッジベース(KB)と会話履歴のハブとして動きます。

KBに入れるべきファイル

プロジェクト固有の用語集・プロダクト仕様書
定型フォーマット(週報テンプレ・議事録テンプレ)
過去レポート数本(書き方の参考になる)
参考リンク集を集約した1枚

KBに入れない方が良いファイル

数百MB級の巨大PDF(全文は引けないことが多い)
頻繁に更新されるマスターデータ(Sheets/DBに置いてコネクタ経由で引く)
生の個人情報・機密契約書(Projectの共有範囲に注意)
非公開顧客データ(用途が限定される場合はRBAC〔役割ベースのアクセス制御〕で絞る。詳細はCowork RBAC設定ガイド)

Projectsの活用パターン5種

競合モニター — 対象企業の公式RSS / プレス / 求人をKBに集約し、週次で差分要約
四半期レポート — 過去4QのレポートPDFをKB、Q毎のdraftを会話として残す
採用オペ — 職種別JDテンプレ、選考フロー、面接評価テンプレをKBに
プロダクト調査 — 一次情報リンク + 仮説メモ。Deep-diveの叩き台を量産する用
チーム議事録 — 定例アジェンダ、過去議事録、Action Item履歴をKBに

Projectを作るかどうかの判断基準は「同じ文脈で5回以上会話するか」です。単発ならGlobal + 都度プロンプトで十分で、Projectを乱立させると逆に「どこで何を話したっけ」状態になりがちです。

メモリ機能との向き合い方

Coworkのメモリは、あなたが明示的に書くCLAUDE.mdと、Claudeが自動的に蓄積する自動メモリの2層で考えるのが公式の枠組みです。公式ドキュメントでは自動メモリは「ビルドコマンド、デバッグの洞察、アーキテクチャノート、コードスタイルの好み、ワークフローの習慣」などをClaude自身が判断して蓄積すると説明されています。

保持される情報/されない情報

種類	保持される	保持されない
あなたの修正指示の傾向	自動メモリに蓄積	1回限りの訂正はしばしばスルー
好みのツール・ライブラリ	自動メモリに候補登録	マシン横断はしない(ローカル保存)
個別案件の機密数値	CLAUDE.mdかProject KBで明示管理	自動メモリには原則残さない設計

意図した記憶を残すコツ

「このリポジトリではpnpmではなくbunを使ってください」のように、対象を明示 + 継続してほしい動作をセットで伝えると自動メモリに残りやすい傾向があります。逆に「次からは〜」のような未来指示だけだと、一時的な会話内訂正として扱われることがあります。

意図せぬ記憶混入を避ける

自動メモリは便利な反面、以前のプロジェクトの癖が新プロジェクトに漏れることがあります。Cowork内のメモリ一覧(公式では /memory コマンド相当の操作で参照可能)を定期的に開き、不要なエントリは削除するのがおすすめです。機密を含みそうな蓄積は、メモリディレクトリ自体を別の場所に設定する運用もあり得ます。

CLAUDE.mdをプロジェクトに置く

CLAUDE.mdは、プロジェクトルート(または .claude/CLAUDE.md)に置くことで自動読み込みされる永続指示ファイルです。Global Instructionsが「全セッション共通」、CLAUDE.mdは「このリポジトリ/フォルダにいるときだけ」という役割分担になります。

配置ルール

./CLAUDE.md または ./.claude/CLAUDE.md — プロジェクト固有、git管理推奨
./CLAUDE.local.md — あなた個人のローカル好み、.gitignore 対象
~/.claude/CLAUDE.md — ユーザー全体の好み(全プロジェクト適用)
管理ポリシー用のOS別パス — 組織展開用

CLAUDE.mdは起動時にツリーを上に歩いて祖先ディレクトリのファイルをすべて連結します。サブディレクトリ内のCLAUDE.mdは、そのサブディレクトリのファイルを読むタイミングでオンデマンド読み込みとなります。

動く例: ビジネスプロジェクト向けCLAUDE.md

.claude/CLAUDE.md

# プロジェクト: 四半期レポート生成
 
## 目的
国内 SaaS 競合 5 社の四半期動向を社内向けにまとめる。
毎四半期末(3/6/9/12 月末)に ZIP ダウンロード済み IR 資料を元に生成。
 
## 入出力
- 入力: `./inputs/YYYY-QN/*.pdf`(各社 IR / 決算説明資料)
- 出力: `./drafts/YYYY-QN/competitor-report.md`
 
## 出力フォーマット
1. サマリ(3 行、直近四半期の要点)
2. 指標表(2 列: 指標名 / 前 Q 比)
3. 各社動向(1 社あたり 200〜300 字)
4. 次四半期の見立て(「〜と言えそう」の控えめ表現で)
 
## 禁則事項
- 数値は IR 資料から直接引用。推測で埋めない。
- 企業名の公式表記を厳守(例: "株式会社〜" の有無)。
- "買うべき" "売るべき" 等の投資助言的表現は使わない。
 
## 参照
- 用語集: @./docs/glossary.md
- 過去レポ: @./drafts/2025-Q4/competitor-report.md

`@file` 参照でメンテナンス性を保つ

CLAUDE.mdは @相対パス で他ファイルを参照・展開できます。用語集や長いテンプレートは別ファイルに切り出し、CLAUDE.md本体は骨格(200行以下が目安)を保つのがコツです。公式ドキュメントでも「CLAUDE.mdファイルあたり200行以下を目標に」と明記されています。CLAUDE.md自体の書き方の型はCLAUDE.mdを実用に引き上げる10のパターンに詳しいので、本節と組み合わせると「どこに置くか」と「何を書くか」が両側から埋まります。

Skillsで繰り返しタスクを定型化

Skillは「手順 + トリガー + 成功条件」を書いたMarkdownファイルで、ディレクトリ名を /<name> のスラッシュコマンドとして呼び出せます。Cowork / Claude Code共通の仕組みで、SKILL.md をエントリポイントとするディレクトリとして定義します。

配置場所

スコープ	パス	共有対象
Personal	`~/.claude/skills/<name>/SKILL.md`	自分の全プロジェクト
Project	`.claude/skills/<name>/SKILL.md`	このプロジェクトだけ
Enterprise	管理設定で配布	組織全体

同名の場合はEnterprise > Personal > Projectの優先順で解決されます(現行ドキュメント時点)。

動く例: weekly-report Skill

.claude/skills/weekly-report/SKILL.md

---
name: weekly-report
description: 週次営業レポートを生成する。毎週月曜の朝に前週分を集計。ユーザーが「週報作って」「週次レポート」「weekly-report」と言ったら起動。
argument-hint: [対象週(YYYY-WW)]
allowed-tools: Read Grep
---
 
# Weekly Report Generator
 
対象週 `$ARGUMENTS` の営業レポートを生成してください。
 
## 入力
- `./data/deals/YYYY-WW.csv` — 週次の商談データ
- `./templates/weekly-report.md` — 出力テンプレ
 
## 手順
1. CSV を読み込み、ステージ別に件数と金額合計を集計する。
2. 前週(YYYY-WW から 1 減算)と比較し、増減と増減率を算出する。
3. テンプレの該当プレースホルダを埋めて `./drafts/weekly/YYYY-WW.md` に保存。
4. 以下 3 行サマリをチャットに返す:
   - 今週クローズした案件件数と総額
   - 前週比の純増減額
   - 翌週注視すべき案件(金額上位 3 件)
 
## 成功条件
- 出力ファイルが Markdown として有効であること。
- サマリ 3 行が 200 字以内に収まっていること。
- 金額は千円単位で 3 桁区切り表記にすること。
 
## 禁則
- 数値の推測埋めは禁止。CSV に無いセルは「-」にする。
- 顧客名の伏字化(必要に応じて頭文字 + 業種)を保つ。

SkillとGlobal / CLAUDE.mdの使い分け

書くもの	置き場所	理由
トーン・言語・常時守る禁則	Global Instructions	全セッションで必要
プロジェクト固有の前提・用語・出力先	CLAUDE.md	リポジトリに入った時だけ必要
再現性ある多段手順・テンプレ埋め込み	Skills	呼び出したときだけ読み込み、普段は軽量

Skillは呼び出されて初めて読み込まれるのが大きな利点です。CLAUDE.mdに手順をびっしり書いて常時2,000トークン消費するより、Skill化して通常は説明文だけ載せる方がコンテキストを節約できます。Skillファイルそのものの設計パターンはSkillsで使える5つの設計パターンで具体例とともに扱っています。

Connectorsの設定最適化

ConnectorsはGmail / Google Drive / Calendar / Slack / Microsoft 365などの外部サービスとCoworkを繋ぐレイヤーです。ローカルファイル許可とは独立したスコープ管理になっていて、OAuthで付与した権限の粒度がそのまま効きます。

接続するか判断する基準

読むだけで済むか、書き込みも必要か — 読むだけなら読み取り専用スコープに絞る
共有範囲が個人か組織か — 組織共有ドライブをフル許可するとスコープが広い
監査が必要か — 必要ならビジネス以上のプランでログ確認可能か事前に確認

よくある失敗と回避策

Driveを丸ごと読み取り許可 → マイドライブ配下の指定フォルダだけに絞るコネクタを優先
Gmailを書き込みまで許可 → 送信API込みは誤送信リスク。読み取りのみから始める
個人アカウントで接続したまま業務利用 → 業務用アカウントに再接続し直す

Microsoft 365を接続する場合は、Claude CoworkとMicrosoft 365の連携設定を併読すると、Entra ID側の権限設計含めて一気通貫で押さえられます。

コネクタ運用の原則

接続時に「書き込み権限を要求される」スコープは都度レビュー
退職・異動時のアカウント棚卸しでCowork接続も見直し
監査観点では、Cowork側のアクセスログと接続先(Workspace Admin等)ログの突合が必要になる点を事前に認識しておく

Scheduled Tasks(定期実行)の設計

公式ヘルプでは「Claudeが自動的にまたはオンデマンドで実行するタスク」として案内されており、任意のタスクで /schedule コマンドを使うか、左サイドバーの「スケジュール済み」から管理します。

設計のポイント

入力の安定性 — スケジュール実行時に必要なファイル/メールが確実に存在する時間帯を選ぶ
出力先の固定 — 実行日時を含むファイル名(YYYY-MM-DD.md)で衝突を避ける
依存タスクの順序 — 「まず集計 → 次にメール送信」のような2ステップは1本のタスクに畳むか、時間差で2本に分ける
失敗時の通知 — 結果はチャットスレッドに戻るので、通知タイムラインを定期的に確認する運用にする

動く例: 典型的な3パターン

朝8時に前日売上レポート生成
- 入力: Drive上の前日集計CSV
- 出力: Drive上の sales/daily/YYYY-MM-DD.md
- トリガー: 平日8:00
毎週金曜17時に週次ダイジェストをメール送信
- 入力: プロジェクト会話履歴 + KBの週次指標
- 出力: 指定アドレスへのメール本文
- トリガー: 毎週金曜17:00
月初1日に競合モニター更新
- 入力: 対象5社の公式RSS + IR頁
- 出力: Project KB内に月次差分レポート追加
- トリガー: 毎月1日10:00

スリープで落ちないための実務ヒント

ラップトップ閉じていてもVM側で走るのが原則。ただしローカルファイルを必要とするタスクはマシンオンが必須になる
クラウド側だけで完結するように、入出力をDrive / Gmailに寄せる設計にすると安定する
重いタスクは途中でタイムアウトしうるので、20〜30分で1ステップが終わる粒度に分解する

Scheduled Tasksの内部挙動はClaude Coworkの機能深掘りでより詳しく扱っています。

Permissions(権限)の最適化

ファイルアクセスの粒度設計はCowork運用の肝です。公式の挙動としては「初回許可・以後記憶型」で、フォルダ単位の信頼がベースになります。

粒度の選択

粒度	向いている場面	注意点
個別ファイル	機密性が高い単一ファイルを扱う	毎回ダイアログ。量が多いと非現実的
プロジェクトフォルダ	通常の業務タスク	Cowork専用ワーキングフォルダを切るのが無難
全体(ホーム配下ごと)	非推奨	意図せぬファイルが範囲に入るリスク

「一度だけ / 常に」の判断基準

機密性が低く、同一タスクを繰り返すなら「常に」で効率化
機密度の高いフォルダや、初見のスクリプト実行は「一度だけ」で段階承認
書き込み・削除系は原則「一度だけ」から始めるのが安全

過剰に広げない運用原則

Cowork専用フォルダ(例: ~/cowork-workspace/)を切り、そこだけ常時許可
DownloadsやDesktop直下を丸ごと許可しない — 意図せぬ機密ファイルが混入しやすい
コネクタ側の読み取り権限と併せて点検・整備する(ローカルは絞ったがクラウド側で広い、という穴に注意)

権限まわりはClaude Coworkビジネス運用ベストプラクティスでより運用寄りに扱っているので、チーム展開を考える段階で併読するとスムーズです。

7階層を連動させるベストプラクティス

7階層は単独で使うよりも組み合わせたときに効果が最大化します。核となるのが「Globalで前提、Projectで文脈、CLAUDE.mdで指示、Skillで手順」の4層連動です。

4層連動の基本形

Global — 「日本語で応答 / 敬体 / 医療助言しない」などの常時前提
Project — 「四半期レポート案件」「採用オペ」のような文脈とKB
CLAUDE.md — そのプロジェクトの入出力パス・テンプレ・禁則
Skill — 「週次レポ生成」「議事録要約」などの具体手順

Memoryは4層の外側で「好みの自動学習」、Connectorsは入出力の物理層、Scheduled Tasksは起動トリガー層、と並べると7階層全体の役割分担がクリアになります。

3プロファイル別推奨構成

プロファイル	最小構成	推奨構成	フル構成
使い始め(ビジネスパーソン)	Global(短) + 1 Project	+ CLAUDE.md + Connectors 2本	+ 週次Skill + Scheduled 1本
中堅(小規模チーム)	Global + Projects複数	+ CLAUDE.md + Skills 3〜5本	+ Connectors複数 + Scheduled週次/月次 + Memory棚卸し運用
専門ユーザー(開発者/運用)	Global多層 + Projects多数	+ CLAUDE.md階層 + Skills 10本超	+ 管理ポリシー CLAUDE.md + Connectors制限付き + Scheduled複数系列 + 自動メモリ監査

最初から「フル構成」を目指すと設定だけで消耗するので、使い始めはGlobal + 1 Projectだけでも十分効きます。各階層を追加するたびに「週に1回は触るか?」を自問すると、肥大化を防げます。

よくあるつまずき10選

運用してみて踏みやすい落とし穴を、症状・原因・解決の3点セットで並べます。

1. Globalに情報を詰め込みすぎて応答が鈍化

症状: レスポンスが遅い、個別指示に従わなくなる
原因: Globalが100行超。毎回大きなプロンプトとして注入されている
解決: 手順はSkillに、案件特有はCLAUDE.mdに切り出す。Globalは30行前後を目安に

2. SkillsとGlobalが矛盾して挙動が不安定

症状: 同じ質問でも答えが揺れる
原因: Globalで「常体」指定、Skill内で「敬体」指定、など優先度が曖昧
解決: 言語・トーンはGlobalに一本化。Skillではタスク固有の出力形式のみ上書き

3. Memoryが意図と違うタイミングで書き換わる

症状: 以前指定した好みが消えている
原因: 自動メモリの容量制限で古いエントリが押し出された
解決: 恒久的に残したいものはCLAUDE.mdに書く。Memoryは揮発前提で考える

4. CLAUDE.mdを複数の深さに置いて競合

症状: サブディレクトリに入ると祖先CLAUDE.mdの指示が矛盾
原因: 親・子で同じトピックを別内容で書いている
解決: 子は親との差分だけ書く。共通事項は親に集約

5. Connectorsの権限が広すぎる

症状: 社内監査で指摘される / 誤書き込み事故
原因: 書き込みスコープを必要以上に付与
解決: 読み取り専用から開始。書き込みが必要な接続は対象フォルダを絞る

6. Scheduled Tasksが静かに失敗し続ける

症状: 週次レポートが出てきた気がしない
原因: 入力ファイルのパス変更、またはローカル依存タスクでPCオフ
解決: タスクの出力をDrive側に固定。失敗通知の受け取り口を決めておく

7. Project KBを肥大化させすぎる

症状: 引用が薄い、関係ない古文書から持ってくる
原因: KBに何でも投げ込んでいる
解決: KBは「週に1回は参照するもの」だけに絞る。アーカイブはDrive側

8. Permissionsを「常に」だらけにして事故る

症状: 意図せぬファイルが読まれる / 書き換えられる
原因: DownloadsやDesktop直下を常時許可
解決: Cowork専用フォルダを切り、他は都度許可に戻す

9. Skill名が説明的すぎて呼ばれない

症状: /skill-name で呼べば動くが自動トリガーされない
原因: descriptionが抽象的でキーワードを含まない
解決: descriptionにユーザーが自然に言うトリガーフレーズ(「週報作って」等)を列挙

10. Global / CLAUDE.md / Skillで同じ指示を重複

症状: 応答が妙に冗長、出力フォーマットが混線
原因: 同じトーンルールを3箇所に書いている
解決: 「この指示はどの階層でしか通用しないか」を自問し、最も広い階層だけに残す

まとめ

Claude Coworkのカスタマイズは、7階層(Global / Projects / Memory / CLAUDE.md / Skills / Connectors / Scheduled Tasks)の役割を正しく切り分けることに尽きます。Globalに詰め込みすぎず、Projectで文脈を束ね、CLAUDE.mdで案件固有の指示を永続化し、Skillで手順をカートリッジ化する。Memoryは揮発前提、ConnectorsとPermissionsは絞り込み運用、Scheduled Tasksはクラウド側完結を原則にする。ここまで整えると、Coworkは「質問するたびに毎回前提を書き直すツール」から「自分仕様に調律された作業環境」に変わります。最初から完璧を目指さず、Global + 1 Projectの最小構成から始め、週次で運用を振り返りながら階層を足していくのが現実的な進め方です。入門段階の方はCowork入門、ビジネス運用の実務面ではベストプラクティス、機能の内部挙動は機能深掘りが近い距離の関連記事なので、7階層のどこに課題があるかで参照先を選んでみてください。

要点