Claude Projects のカスタム指示は、使い始めてすぐに「これは便利だ」と気づく機能の一つです。ただ、いざ書こうとすると「何をどこまで書けばいいのか」で迷いがちです。
私もしばらく試行錯誤を繰り返しました。最初は「丁寧に答えてください」「専門用語を使わないでください」くらいの簡単な文を入れていたのですが、それだけでは期待通りに動いてくれないことが多くて。
今は「指示の構造」を意識して書くようにしたところ、Claudeの回答精度がかなり安定してきました。その経験をもとに、実際に効果のあった書き方を整理してお伝えします。
なぜカスタム指示が必要なのか
通常の会話では、Claudeは毎回「白紙の状態」から始まります。あなたが開発者なのか、マーケターなのか、どんな文体を好むのか——何も知りません。
カスタム指示はこの問題を解決します。プロジェクトに紐付いた「常時有効な文脈」として機能し、毎回説明しなくてすむ前提知識をClaudeに与えておけます。
ただし誤解しやすいのですが、カスタム指示は「命令」というより「共有された文脈」と考えたほうがうまくいきます。「必ず〜せよ」という強制より、「あなたはこういう人物で、こういう状況で働いています」という設定の共有です。
効果的な指示の3つの要素
実際に試した中で、特に効いた要素が3つあります。
1. 役割と文脈の定義
Claudeに「誰として」「何のために」作業するのかを明示します。
あまり効果がなかった例:
あなたはプロのライターです。
効果があった例:
あなたは個人開発者向けのテックブログの編集担当です。
読者は30〜40代のエンジニアで、実務経験はあるが特定の技術の深い専門家ではありません。
このブログの目的は、実践的なノウハウを「使える形」で伝えることです。
具体性が増すほど、Claudeは状況を正確にイメージして回答を調整してくれます。
2. 出力の制約と形式
何を「しない」かを明示するのが意外と重要です。
回答の制約:
- 前置きや要約で回答内容を予告しない（「以下に〜をまとめます」は不要）
- 箇条書きより文章で説明する。リストは本当に必要な場合のみ
- 長さは問いに応じて自然に調整する。短い回答で十分な場合は短くてよい
- コード例は完全な実行可能コードで示す（スニペットの断片は避ける）
特に「前置きを省く」指示は効果が出やすいです。Claudeはデフォルトだと「ご質問について〜」「いくつかの観点から〜」といった導入を入れがちですが、これを省くだけで会話がかなりスムーズになります。
3. 専門用語と優先知識の共有
あなたのプロジェクト固有の言葉や前提を共有しておくと、毎回説明が不要になります。
プロジェクト固有の用語:
- 「記事」は MDX形式のブログ記事（コードとマークダウンが混在）
- 「Push」はGitHubへのコミット＋プッシュの一連の流れ
- 「サイト」は claudelab.net / gemilab.net のいずれかを指す
よく使うツール: Claude Code, Next.js, Cloudflare Workers, GitHub Actions
実際に動いている指示の構造例
以下は私がコーディング支援プロジェクト用に使っている構造をベースにしたサンプルです。
## あなたの役割
個人開発者の技術的なパートナーとして、コード・設計・記事の作成を支援する。
## 読み手のプロフィール
- Next.js / TypeScript を日常的に使う中級エンジニア
- クラウド基盤は Cloudflare Workers を使用
- 一人開発なので、実装の速さと保守性のバランスを重視
## 回答のスタイル
- 日本語で、丁寧だが簡潔に
- 長い説明より動くコードを優先する
- 「なぜそうするか」を1〜2文で添える
- 前置き・まとめ・要約は不要
## 優先する判断基準
1. 動作する（型安全・エラーハンドリングあり）
2. シンプル（過剰な抽象化をしない）
3. Cloudflare Workers で動く（Node.js固有のAPIは使わない）
## プロジェクト情報
- リポジトリ: masakihirokawa/claudelab.net
- 技術スタック: Next.js, TypeScript, Cloudflare Workers, next-intl
- デプロイ先: Cloudflare Pages
この構造のポイントは「優先する判断基準」を明示しているところです。「Cloudflare Workers で動く」という制約を3番目に入れることで、環境依存のAPIを提案されるミスが減りました。
指示が効かないときの確認ポイント
書いた指示が思うように機能しないとき、原因はだいたい以下のどれかです。
指示が長すぎる
500文字を超えるあたりから、後半の指示が薄まる印象があります。本当に重要な3〜5項目に絞るのが現実的です。
「常にやること」と「状況によってやること」が混在している
「必要に応じてコード例を示す」は指示になっていません。「コード例が必要な場合は完全な実行可能コードで示す」のように、条件と期待を明確にします。
あいまいな形容詞に頼っている
「わかりやすく説明する」「適切な長さで答える」は、Claudeが既にそうしようとしているので効果がありません。「3行以内で」「箇条書き禁止」のような具体的な制約にします。
プロジェクトを分けることの価値
カスタム指示の効果を最大化するには、目的ごとにプロジェクトを分けるのがおすすめです。
私は現在、以下のようなプロジェクトを使い分けています。
- 記事執筆用: トーン・文体・記事構造の指示を詳しく設定
- コーディング支援用: 技術スタック・コーディング規約・制約を設定
- アイデア整理用: 発散思考を促す指示（「批判より可能性の探索を優先」等）
用途が混在したプロジェクトに何でも持ち込むより、指示が1つの目的に最適化されたプロジェクトを使うほうが、回答の質が安定します。
定期的に見直すことが大事
カスタム指示は「一度書いたら終わり」ではありません。実際に使っていると「この指示は効いていないな」「こういう制約を追加したい」という気づきが出てきます。
私は2週間に1度くらいのペースで見直して、効果のなかった指示を削り、新しく気づいた制約を追加しています。使っているうちにどんどん精度が上がっていくのが、カスタム指示の面白いところだと思っています。