← Back to Best Practices

Prompt Engineering

Claude向けプロンプトエンジニアリングのベストプラクティス集です。

#1

4ブロックパターンを基本構造として使用する

Claude 4.x向けのプロンプトでは、INSTRUCTIONS / CONTEXT / TASK / OUTPUT FORMATの4ブロックパターンが推奨される。構造化された「契約型プロンプト」が最も安定した結果を生む。

Source →
#2

Claude 4.xは指示を文字通り実行する

以前のバージョンは曖昧な指示を推測して拡張していたが、Claude 4.xは指示を文字通りに解釈する。「それ以上」の行動を求める場合は明示的に指示する必要がある。

Source →
#3

ルールの「理由」を説明すると一般化性能が向上する

「省略記号を使わないで」ではなく「テキスト読み上げエンジンが省略記号を発音できないため使わないで」のように理由を添えると、Claudeはルールをより適切に一般化できる。

Source →
#4

Few-shotはまず1例から始める

1つの良い例は、望む出力を説明する複数の形容詞に勝る。出力が合わない場合にのみ追加の例を提供する。

Source →
#5

不確実性の表明を明示的に許可する

「確信がない場合はそう述べてください」というルールを追加し、事実の主張にはソースを要求することで、ハルシネーションを削減できる。

Source →
#6

構造は長さに勝る

長く複雑なプロンプトが常に良いわけではない。目標を確実に達成する最小限の構造を持つプロンプトが最良。過剰設計を避ける。

Source →
#7

成功基準と出力契約を定義する

2026年のプロンプトエンジニアリングで最も重要なプラクティスは、成功基準を明文化すること。ほとんどの失敗は「完了」の定義が曖昧なことに起因する。

Source →
#8

攻撃的な言語表現を避ける

「CRITICAL!」「YOU MUST」「NEVER EVER」などの攻撃的表現はClaude 4.xでは逆効果。過剰にトリガーされ、落ち着いた直接的な指示よりも悪い結果を生む。

Source →
#9

セルフチェックステップを含める

出力が要求フォーマットに合致しているか、成功基準がすべて満たされているか、不確実な主張にマークが付いているかを確認する小さなセルフチェックをプロンプトに追加する。

Source →