crafting-instructions

Claude 向け指示の作成

Claude.ai 向けの指示形式として、プロジェクト指示、スキル、または単独プロンプトを選び、選択した形式に合わせて構成します。

重複に関するお知らせ。 以下のコア最適化原則は writing-instructions にも記載されており、そちらではより詳しく説明しています。このスキルが担当するのは形式の選択です。writing-instructions が担当するのは、選択した形式で適切に書く方法です。両者の説明は非常に似ているため、どちらにも当てはまる依頼があり得ます。どちらの問いに該当するかに基づいて振り分けてください。

判断フレームワーク：どの形式を使うか？

次の質問を検討し、適切な形式を判断してください。

次の場合はプロジェクト指示を使用します：

• ワークスペース内のすべての会話でコンテキストを維持する必要がある
• 複数のチームメンバーが共有知識を使って共同作業する
• 特定の取り組みに必要な背景知識がある
• カスタム動作を1つのプロジェクトだけに適用する

判断の手がかり： 「このプロジェクト向け」「X に関するすべての会話」「チームのワークスペース」「プロジェクト固有」

次の場合はスキルを使用します：

• 複数のコンテキストやプロジェクトで能力が必要
• 幅広く適用できる手順に関する知識がある
• 関連する場面で指示を自動的に有効化する
• 必要に応じて読み込める、持ち運び可能な専門知識が必要

判断の手がかり： 「毎回」「いつでも」「再利用可能」「複数のプロジェクトで」「Claude に〜する方法を教える」

次の場合は単独プロンプトを使用します：

• その場のコンテキストを伴う単発の依頼
• 1回だけ使う臨時の指示
• 会話内での調整
• 継続的に保持する必要がない

判断の手がかり： 「このタスク向け」「今すぐ」「今回だけ」「〜してくれますか」

組み合わせて使う方法：

プロジェクト指示＋スキル：

• プロジェクト指示：継続的に保持するコンテキスト（市場データ、製品仕様）
• スキル：再利用可能な方法（分析フレームワーク、レポートのテンプレート）
• 使う場面：ワークスペースのコンテキストと、持ち運び可能な機能の両方が必要な場合

スキル＋プロンプト：

• スキル：一般的な専門知識（コードレビューの基準）
• プロンプト：具体的なコンテキスト（「この PR をセキュリティの観点からレビューする」）
• 使う場面：基盤となる能力と、その場での指示が必要な場合

コア最適化原則

以下はすべての指示形式に適用されます。

1. 命令形で書く

提案ではなく、直接的な行動の指示として記述します。

• ❌ 「X の作成を検討してください」→ ✅「条件 Y に該当する場合は X を作成してください」
• ❌「〜するとよいでしょう」→ ✅「実行してください」／「生成してください」
• ❌「最適化を試みてください」→ ✅「〜によって最適化してください」

2. 肯定的な指示で表現する

してはいけないことではなく、するべきことを示します。

• ❌「箇条書きは使わないでください」→ ✅「流れるような段落形式で書いてください」
• ❌「専門用語を避けてください」→ ✅「初心者にもわかりやすい言葉を使ってください」
• ❌「リストを出力しないでください」→ ✅「自然な文章で情報を提示してください」

理由：否定的な指示には推論が必要です。肯定的な指示なら、望ましい動作を直接伝えられます。

3. 背景と目的を伝える

要件がある理由を説明します。

• ❌「段落形式を使ってください」
• ✅「流れるような文章はカジュアルな学習において会話に近い表現になるため、段落形式を使ってください」

理由：背景を示すことで、例外的な状況でも Claude がより適切に自律的な判断を下せるようになります。

4. 手順より戦略を重視する

手順を一つずつ示すのではなく、目標と判断フレームワークを提示します。

• 明確にするもの：成功の基準、境界、判断フレームワーク
• 最小限にするもの：連続した手順、詳細な実行方法、明白な操作
• 原則：目標から Claude が手順を推測できる場合は、目標だけを指定します

現在のモデルは、提示された目標に基づいて計画を立てます。破壊的なコマンド、認証フロー、コンプライアンス手順など、決まった手順が唯一の安全な方法である場合に限り、手順を明記してください。

5. 基本動作を信頼する

Claude のシステムプロンプトでは、すでに次の内容がカバーされています。

• 引用の手順、著作権のガイドライン、安全性
• 一般的なツールの使用方法、成果物を作成する基本
• 会話の基本的なトーン、拒否への対応
• 基本的な正確性と有用性の基準

プロジェクトや分野に固有の例外だけを指定してください。

形式ごとのガイダンス

プロジェクトの指示について

参照先：references/project-instructions.md

主なポイント：

• システムプロンプトに追加する（重複させない）
• ワークスペース固有の動作に焦点を当てる
• より深い検討が必要な分野を明示する
• 複雑さが必要とする場合を除き、シンプルな構成（見出し／段落）にする

スキルについて

参照先：references/creating-skills.md

主なポイント：

• 段階的に開示する（メタデータ → 詳細な指示 → 同梱リソース）
• フロントマターには、トリガーパターンを含む name と description を記載する
• SKILL.md は 500 行未満にする
• 詳細な分野別の内容には references/ を使用する

単独のプロンプトについて

参照先：references/standalone-prompts.md

主なポイント：

• 求める出力を明確かつ具体的にする
• 役立つ場合は、コンテキストと例を提示する
• タスクに応じて複雑さを調整する
• 不確実性を表明できるようにする

何を提案するか

ユーザーが次のように言った場合は「スキルを使う」を提案します：

• 「毎回これを説明しなければなりません」
• 「X のやり方を覚えておいてもらえますか？」
• 「複数のプロジェクトで使いたいです」
• 会話のたびに同じ指示を繰り返している

ユーザーが次のように言った場合は「プロジェクトの指示を使う」を提案します：

• 「このプロジェクトでは、常に…」
• 「チームで…できるようにしたい」
• 「この取り組みに関するすべての会話で…」
• 永続的なコンテキストを持つワークスペースを構築している

ユーザーが次のように言った場合は「より良いプロンプトを使う」を提案します：

• 結果にばらつきがある
• Claude が意図を誤解する
• 出力形式が適切でない
• より包括的な回答が必要

スキルとプロジェクトの主な違い

詳しい比較については、references/skill-vs-project.md を参照してください。

クイックリファレンス：

プロジェクト =「知っておくべきこと」

• 常に読み込まれる静的な参照資料
• 取り組みの背景知識
• チームのワークスペースのコンテキスト

スキル =「物事の進め方」

• 必要に応じて動的に読み込まれる専門知識
• 手順に関する知識と手法
• あらゆる会話で利用できる

例：

• プロジェクト：「Q4 Product Launch」。市場調査や競合他社の資料を含む
• スキル：あらゆる競合他社を分析するための競合分析フレームワーク

強力な組み合わせを実現するには、両方を併用してください。

例の品質への配慮

例は、意図していないものも含め、例に含まれるあらゆるパターンを教えます。

例を含める場合：

• あらゆる詳細（形式、冗長さ、構成、語調）を確認する
• すべての要素が望ましい動作を示すようにする
• 相反する例を含めるより、省略するほうがよい
• 例で箇条書きを使いながら、文章形式を望む場合、Claude は箇条書きを標準として使うようになります

シンプルな構成

明確に整理することを基本とします：

• 見出しと余白を主な方法として使う
• 関係性を明示する
• 自然な段落の流れにする

構造化マークアップ（XML／JSON）は、次の場合に限って使います：

• 複雑なシナリオで異なる種類のコンテンツを分ける場合
• コンテンツの境界を確実に明示する必要がある場合
• 構造化された解析が必要な API 駆動のワークフローの場合

思考の深さ

プロンプトにどんな文言を加えても、思考が始まるわけではありません。現在の Claude モデルはデフォルトで適応的に思考し、その深さは設定によって決まります。API の effort 設定、または Claude.ai の UI コントロールで調整します。「段階的に考えて」や手書きのトリガーフレーズに効果はありません。

指示で役立つのは、分野のどの部分をより深く検討する必要があるかを伝え、読み手がどこで effort を高めるべきか分かるようにすることです：

[Specific complexity] in this domain is worth extra deliberation because [why].

複雑さの調整

タスクの必要性に合わせて、指示の複雑さを調整します：

単純なタスク → シンプルなプロンプトまたは簡潔な指示
中程度のタスク → 意思決定の枠組みを含む構造化されたガイダンス
複雑なタスク → 包括的な指示。effort を高める

複雑さを加える前に、よりシンプルな表現でも同じように機能しないか検討してください。

指示の密度

タスクがモデルの自発的な動作からどれほど離れているかに応じて、指示の密度を調整します。 目標、制約、成功の確認方法を明示し、順序が重要な場合にのみ手順を加えます。ルールをもう一つ加えるか、その理由について背景情報を補足するか迷った場合は、背景情報を記述します。モデルが他の方法では得られず、列挙されていないケースにも適用できるのは、その情報だからです。

指示で扱われていないケースにも判断が適用されることを明示します。

品質チェックリスト

指示を提示する前に、次の点を確認します。

戦略:

• 細かく指図せず、明確な目標を示している
• 要件が必要な理由を背景情報で説明している
• 曖昧なケースに対応する判断の枠組みがある
• 可能な限り、制約を肯定的な表現で示している

技術:

• 全体を通じて命令形を使っている
• 否定的な制限より肯定的な指示を優先している
• 適切な構成にしている（原則としてシンプルに）
• システムプロンプトを重複させていない
• 例を含める場合、すべて要件に完全に沿っている

実行:

• すぐに実行に移せる
• 成功基準が明確である
• 複雑さに合った形式になっている

よくある間違いとその回避方法

❌ システムプロンプトの重複 — 「最新情報には web_search を使い、情報源を引用する」 ✅ プロジェクト固有の例外がない限り、省略します。

❌ 否定的な表現 — 「リストを使わない。冗長にしない」 ✅ 「自然な文章の段落で説明します」

❌ 見せかけの思考トリガー — 「深く考えるときは『慎重に考える』と言う」 ✅ この分野で熟考が役立つ場面を具体的に示し、そこに労力をかけるよう設定します。

❌ 手順の過剰な細分化 — 「ステップ1：X。ステップ2：Y……」 ✅ 「目標：X。品質基準：Y。アプローチ：Z。」

❌ 背景情報のない要件 — 「常にフォーマルな口調を使う」 ✅ 「受け手が権威ある語り口を期待するため、専門的な文書ではフォーマルな口調を使います」

❌ 要件に合わない例 — 文章で説明するよう求めているのに、例では箇条書きを使う ✅ 完全に要件に沿った例を作るか、例を省略します。

参考資料

• references/creating-skills.md - 完全な Skills の作成方法
• references/project-instructions.md - Project instructions の詳細なガイダンス
• references/standalone-prompts.md - 効果的なプロンプトのパターン
• references/skill-vs-project.md - 詳細な比較と選択のガイダンス