Claudeへの指示の書き方

Claudeが確実に従う指示を書くための原則とパターン—プロジェクト指示、スタンドアロンプロンプト、スキルコンテンツのいずれの形式でも。

適切な形式の選択

執筆前に形式を決定します。間違った容器は良い指示も台無しにします。

プロジェクト指示—ワークスペースの永続的なコンテキスト。プロジェクト内のすべての会話が共有知識、チーム協業コンテキスト、またはイニシアチブ固有の動作を必要とする場合に使用します。シグナル：「このプロジェクトでは」「Xに関するすべての会話」「チームワークスペース」。 詳細はreferences/project-instructions.mdを参照してください。

スタンドアロンプロンプト—一時的で会話的、即座。1回限りのリクエスト、その場の指示、または会話的な改善に使用します。シグナル：「このタスクについて」「今すぐに」「今回だけ」。 テクニックについてはreferences/standalone-prompts.mdを参照してください。

スキルコンテンツ—複数のコンテキスト横断で必要に応じて読み込まれるポータブルな専門知識。複数のプロジェクトにわたって機能が必要、手続き的知識が広く適用可能、および指示が関連するトリガーで自動的にアクティベートされるべき場合に使用します。シグナル：「毎回」「いつでも」「再利用可能」「Claudeに方法を教える」。 完全なスキルの構築（構造、テスト、反復、パッケージング）については、skill-creatorスキルを使用してください。

組み合わせたアプローチも効果的です：プロジェクト指示は「知っておくべきこと」（参考資料、コンテキスト）を提供し、スキルは「やり方」（メソッド、手順）を提供します。詳細な比較と移行パターンについてはreferences/choosing-formats.mdを参照してください。

コア執筆原則

これらはすべての指示形式に適用されます。影響度の高い順に列挙されています。

1. 命令法構文

直接的な命令としてフレーム化します。命令法言語は曖昧性を減らし、指示がオプションではないことを示します。

• ❌ 「Xの作成を検討してください」→ ✅ 「条件Yのときに、Xを作成します」
• ❌ 「検索したほうがいいかもしれません」→ ✅ 「検索します」
• ❌ 「最適化してみてください」→ ✅ 「〜によって最適化します」

2. コンテキストと動機付け

要件が存在する理由を説明します。Claudeは目的について推論を行い、述べられていないエッジケースでより良い決定を下します。WHYコンテキストはOpusの自律判断に特に価値があります。

• ❌ 「形式的なトーンを使用します」
• ✅ 「エンタープライズクライアントを対象としたドキュメンテーションが権威のある音声を期待しているため、形式的なトーンを使用します」

コンテキストのない要件はClaudeが機械的に従うルールです。コンテキストのある要件はClaudeが知的に拡張できる原則です。

3. ポジティブな指示フレーミング

何をしないかではなく、何をするかを述べます。否定的な指示はClaudeに望ましい代替案を推測させます—ポジティブな指示はそれを直接述べます。

• ❌ 「箇条書きを使用しないでください」→ ✅ 「流れるような段落形式で書きます」
• ❌ 「技術用語を避けてください」→ ✅ 「初心者向けにアクセスしやすい言語を使用します」
• ❌ 「生データを決してアウトプットしないでください」→ ✅ 「解釈とコンテキストとともにデータを提示します」

否定的な制約が本当に必要な場合、ポジティブな代替案と組み合わせてください：「流れるような段落形式で提示します。箇条書きではなく。理由は、流れるようなテキストが学習コンテキストでより会話的だからです。」

4. 戦略的よりも手続き的

ステップバイステップの手順ではなく、目標と意思決定フレームワークを提供します。Claudeが目標から手順を推論できる場合は、目標のみを指定します。

• 指定する：成功基準、境界、意思決定フレームワーク、品質基準
• 最小限にする：順序立った手順、詳細な実行、Claudeが目標から決定できる操作

この原則はモデル機能とともにスケーリングします—Opusはハイク以下の手続き的詳細を必要とします（下記のモデル対応キャリブレーションを参照）。

5. ベース動作への信頼

Claudeのシステムプロンプトは既に引用プロトコル、著作権、安全性、一般的なツール使用、アーティファクト作成、会話トーン、および精度基準を処理します。これらのデフォルトからのプロジェクト固有またはドメイン固有の逸脱のみを指定します。

システムプロンプト動作を複製するとトークンを浪費し、矛盾した信号を作成する可能性があります。指示を追加する前に、Claudeが既に望むことを行うかどうかをテストしてください。

モデル対応キャリブレーション

指示はハイク、ソネット、オーパス全体で実行される場合があります。各モデルは指示密度と抽象化レベルに異なる反応を示します。

ハイク（1.3～1.5倍の詳細）： 明示的な命令的コマンドと具体的な決定ツリーで主導します。ハイクは直接的な手順に確実に従いますが、抽象的な原則に苦労します。すべての予想シナリオの正確な条件、具体的なフォールバック、完全な例を提供します。次のように構造化します：「XのときY、ZのときWを実行します」。

ソネット（1.0～1.2倍の詳細）： 明示的な条件と2～3つの具体的な例を含む意思決定フレームワークを提供します。ソネットは例から強く学習し、デモンストレーションで固定された場合、中程度の抽象化を処理します。手続き的な明確性と戦略的コンテキストのバランスを取ります。

オーパス（0.6～0.8倍の詳細）： 手順よりも戦略的目標、推論コンテキスト、および原則を強調します。オーパスは述べられていないケースの自律判断のためにリッチなWHYコンテキストを使用します。通常、1つの明確な例で十分です。過度に手続き的な指示はオーパスを不必要に制約します。次のように構造化します：「目標はYだからXです。述べられていないケースについては判断を適用してください」。

密度乗数は、同じタスクについて有能な同僚に言うことに相対的です。

実用的なレイアリングパターン： 指示を構造化して、命令的コマンドが最初に来る（ハイクが必要なものをすぐに得る）、その後に意思決定フレームワークと例が続く（ソネットの最適点）、戦略的推論とWHYコンテキストが全体に織り込まれる（オーパスがエッジケースに活用する）ようにします。単一の指示セットが、レイアリングが良い場合は3つのモデルすべてに対応します。

ターゲットモデルが不確実な場合： ソネット用に最適化します。ソネット最適化された指示は、ハイク（若干冗長だが機能的）とオーパス（若干過度に指定されているが有害ではない）の両方で適切に機能します。

例の品質認識

例は最も強力で最も危険な指示ツールです。Claude 4.xはすべてのパターンを例から学習します—フォーマット、冗長性、構造、トーン、用語法—意図しなかったパターンを含めて。

例のルール：

• 詳細を監査します：例が箇条書きを使用するが散文を望む場合、Claudeはデフォルトで箇条書きを使用します
• すべての例のすべての側面が望ましい動作を示すことを確認します
• 混合信号を持つ例を含めるより、例を完全に省略する方が良いです
• 1つよく作られた例は3つの不十分な例を上回ります

モデル固有の影響：

• ソネット：例は非常に影響力があります—望ましいパターンを完璧に実証する2～3つを含めてください
• オーパス：例は役立ちますがオーパスは明示的な原則により重く重みづけします—1つの明確な例で十分、すべての要件に完璧に整合できない場合は完全に省略してください
• ハイク：例は重要です—各予想シナリオをカバーする完全な入力/出力ペアを提供します

構造的シンプルさ

見出し、空白、自然な段落フローを使用した明確な組織にデフォルトします。内容の明示的な言語による関係の記述は通常十分です。

構造化マークアップ（XMLタグ、JSONスキーマ）は、複雑なシナリオで異なるコンテンツタイプを分離する場合のみ、コンテンツ境界について絶対的な確実性が必要な場合、またはパーシング構造化が必要なAPIドリブンワークフローに使用します。

決定ルール： これは見出しで組織化できますか？→ 最初にそれを実行します。見出しが本当に明確性を作成するのに失敗した場合のみXML/JSONに手を伸ばします。

拡張思考ガイダンス

拡張思考はUIトグルであり、プロンプトフレーズで制御できません。指示では：

• アシスタントはそれが機能として存在することを認識させます
• いつそれを提案するかのためのドメイン固有のインジケーターを提供します
• ❌ 「注意深く考える」のような「トリガーフレーズ」を含めないでください—拡張思考をアクティベートしません

パターン：「[特定の複雑性]を含むタスクについて、拡張思考を有効にすることを提案し、なぜそれがこのタスクに役立つかを簡潔に説明してください。」

複雑性スケーリング

指示の複雑性をタスクニーズに合わせます。複雑性を追加する前に、次のことを尋ねます：より単純な定式化が同様に機能する可能性はありますか？

シンプルなタスク→明確で簡潔なプロンプトと明示的な出力期待 中程度のタスク→構造化ガイダンス、意思決定フレームワーク、1～2つの例 複雑なタスク→モデル対応のレイアリング+拡張思考の提案を含む包括的な指示

最良の指示は、信頼できる結果を生成する最小限の複雑性を使用します。

よくある間違い

システムプロンプト複製—「現在情報についてはweb_searchを使用し、出典を引用します」。これはトークンを浪費し、価値を追加しません。プロジェクトがデフォルト動作からの特定の逸脱を持つ場合を除き、省略します。

代替案のない否定的フレーミング—「リストを使用しない、詳細にならない」。ポジティブを述べます：「自然な散文段落で提示します」。

フェイク思考トリガー—「深い思考については『注意深く考える』を使用してください」。フレーズは拡張思考を制御しません。特定の複雑性タイプについてUIトグルを提案します。

手続き的マイクロマネジメント—「ステップ1：分析。ステップ2：検索。ステップ3：統合」。代わりに：「研究目標：X。品質基準：Y。結果をZとして提示」。

コンテキストレスな要件—「常に形式的なトーンを使用します」。WHYを追加：「監査レポートに形式的なトーンを使用します。規制当局が権威のある音声を期待しているため」。

不完全な例—例は箇条書きを使用するが散文を望みます。完璧な例を作成するか、完全に省略します。

品質チェックリスト

指示セットを配信する前に：

何をするかを述べていますか？ 命令的コマンド、ポジティブフレーミング、明確な成功基準。

なぜかを述べていますか？ 明白でない要件のコンテキストと動機付け、知的なエッジケース処理を有効にする。

キャリブレーションされていますか？ ターゲットモデルの適切な詳細密度、モデルが不明な場合はレイアリング構造。

最小限ですか？ システムプロンプト複製なし、不要な複雑性なし、Claudeが目標から推測できる手続きステップなし。

例は安全ですか？ すべての例のすべての側面が望ましい動作を示すか、例は省略される。

形式固有の参照

• references/project-instructions.md—プロジェクト指示の作成：役割定義、品質基準、意思決定フレームワーク、ドメインツールパターン
• references/standalone-prompts.md—効果的なプロンプトの作成：具体性、コンテキスト、例、複雑性スケーリング
• references/choosing-formats.md—スキル、プロジェクト、プロンプトをいつ使用するか、組み合わせたアプローチ、移行パターン