Claudeシステムプロンプト：技術ドキュメントのためのトーン境界の設定方法

技術ドキュメントは、事実上の誤りが生じる前に、微妙な方法で失敗することがよくあります。ドラフトは正確であっても、カジュアルすぎる、宣伝的すぎる、冗長すぎる、不確実性について曖昧すぎる、またはドキュメントセットの他の部分と一貫性がない場合があります。APIガイド、トラブルシューティング記事、リリースノート、内部ランブック、または開発者向けドキュメントの作成にClaudeを使用する場合、システムプロンプトは、これらの永続的な執筆境界を定義するのに最適な場所の1つです。

また、注目すべき現在のモデル動作の変更があります。2026年9月現在、Anthropicの廃止予定に関するドキュメントでは、Claude Opus 4.7以降およびClaude Mythos Previewではtemperature、top_p、およびtop_kが廃止予定であり、代わりに動作制御のためにプロンプティングが推奨されていると記載されています。これにより、サンプリングパラメータを通じて主にトーンを形成しようとした従来のレシピよりも、明示的なシステムレベルのスタイル指示がより重要になります。AnthropicのモデルおよびAPI廃止予定に関するガイダンスを参照してください。

「トーン境界」は実際には何を制御すべきですか？

トーン境界は、多くのドキュメントリクエストを通じて安定して維持されるコミュニケーション動作を定義すべきです。単に「プロフェッショナルに聞こえる」ことではありません。有用な境界は通常、対象読者、声（ボイス）、詳細レベル、許容される不確実性の表現、およびフォーマットの習慣の5つの要素をカバーします。

例えば、開発者向けドキュメントアシスタントには、プロフェッショナルで中立的なトーンで書き、初出時に未知の用語を説明し、マーケティング用語よりも直接的な文を優先し、確認済みの事実と仮定を区別し、ナビゲーションを改善する場合にのみ見出しとコードブロックを使用するように指示する場合があります。

Anthropicの現在のプロンプティングガイダンスでは、明確で直接的な指示、その動作が重要である理由に関するコンテキスト、トーンと構造のための例、およびプロンプトが異なる種類の情報を混在させる場合のXMLタグが明示的に推奨されています。また、システムプロンプトでClaudeに役割を与えることが、動作とトーンを集中させるのに役立つとも述べられています。Anthropicのプロンプティングベストプラクティスを参照してください。

トーンルールはシステムプロンプトとユーザープロンプトのどちらに配置すべきですか？

永続的なルールはシステムプロンプトに、タスク固有の指示はユーザープロンプトに配置します。システムプロンプトは、「ソフトウェア開発者向けに書く」「マーケティングの主張を避ける」「推測する代わりに不確実性を述べる」「簡潔な技術的文章を使用する」といったルールの適切な場所です。ユーザーメッセージは現在のジョブを記述すべきです。例えば、「これらのリリースノートを使用して、バージョン4からバージョン5への移行ガイドを作成してください」といった具合です。

この分離により、繰り返しを減らし、ドキュメントパイプラインをテストしやすくします。また、単一のタスクリクエストが全体の編集ボイスを再定義してしまうのを防ぎます。

シンプルなシステムプロンプトパターン

<role>
あなたは技術ドキュメントライターです。
</role>

<audience>
ソフトウェア開発者とシステム管理者向けに書いてください。
一般的な技術リテラシーを前提としますが、製品固有の用語は初出時に説明してください。
</audience>

<tone>
プロフェッショナルで中立的、直接的なトーンを使用してください。
誇張や宣伝的な主張よりも具体的な言語を優先してください。
スラング、フィラー、絵文字、誇張された確信を避けてください。
文は適度に短く保ち、段落は焦点を絞ってください。
</tone>

<accuracy>
コマンド、機能、バージョン、ベンチマーク、動作を捏造しないでください。
検証済みの事実と仮定や推奨事項を区別してください。
必要な情報が欠けている場合は、何が不明であるかを述べてください。
</accuracy>

<format>
説明的な見出しを使用してください。
本当に離散的な手順やチェックの場合にのみリストを使用してください。
コマンドとコードにはコードブロックを使用してください。
記事を単に繰り返すだけの結論を追加しないでください。
</format>

各セクションが1つの役割を持つため、これは機能します。Anthropicは、複雑なプロンプトに対して一貫した説明的なXMLタグを特に推奨しており、これによりモデルは指示、コンテキスト、例、入力をより確実に区別できます。

トーンルールはどの程度具体的であるべきですか？

他のライターがあなたの意図を尋ねることなく従えるほど具体的であるべきです。「プロフェッショナルであれ」という指示は弱いです。なぜなら、プロフェッショナルなAPIドキュメント、エグゼクティブなアーキテクチャノート、エンドユーザー向けセットアップ手順は、すべて異なる響きを持つ可能性があるからです。

より強いルールは、観察可能な動作を記述します：

肯定的な指示は、禁止のみのルールよりも運用化しやすい傾向があります。「宣伝的に聞こえないようにする」とだけ言う代わりに、望ましい代替案を追加してください：「ユーザーの成果に紐付いた具体的な用語で利点を説明してください」。

トーンルールが技術的正確性を損なわないようにするにはどうすればよいですか？

スタイルが証拠を上書きすることを許さないでください。よくある間違いは、「自信に満ちた権威ある文章」を求めながら、ソース資料が不完全な場合にモデルが何をすべきかを定義しないことです。これは、有用なドキュメントではなく、洗練された不確実性を助長する可能性があります。

以下のような正確性の境界を追加してください：

ドキュメントソースが事実を確立していない場合：
- 命名やUIの外観から製品機能を推測しないでください。
- 動作が検証できなかったことを述べてください。
- タスクの完了に事実が必要な場合、欠けているソースを求めてください。
- 仮定を確定的な指示に変えないでください。

技術ドキュメントでは、このルールは「ハルシネーションを避ける」という一般的な指示よりも価値があることがよくあります。なぜなら、証拠が欠けている場合の期待される動作を定義するからです。

システムプロンプトで冗長性を指定すべきですか？

ドキュメントの長さと密度が重要であれば、はい。Anthropicの現在のプロンプティングガイダンスは、最近のClaudeモデルがデフォルトのコミュニケーションスタイルと冗長性において異なることを指摘しています。ドキュメントでは、努力や他のモデル設定が可視の回答長を一貫して制御すると仮定するのではなく、必要に応じて簡潔さを明示的にプロンプトで指示することを特に推奨しています。

実用的なドキュメント境界は、固定の単語数ではなく密度を定義できます：

行動するために必要な情報を最初に提示してください。
指示が安全で曖昧性がないようにするのに十分な説明を使用してください。
同じ推奨事項を序論、本文、結論で繰り返さないでください。
単純な修正の場合は、短いセクションを優先してください。
アーキテクチャや移行のトピックの場合は、トレードオフと前提条件をより深く説明してください。

これは、「常に1,000語書く」という一律の指示よりもスケーラビリティが高いです。

どの程度の数の例を含めるべきですか？

文章によるルールが解釈の余地を残す場合は、例を使用してください。Anthropicは、例をフォーマット、トーン、構造を導く最も信頼できる方法の1つと呼んでおり、現在のガイダンスでは、few-shotプロンプティングに依存する場合、関連性があり多様な例を約3〜5個使用することを推奨しています。

ドキュメントの場合、例は1つのボイスサンプルを繰り返すのではなく、異なるケースをカバーすべきです。有用なセットには、短いトラブルシューティング回答、APIリファレンスパラグラフ、データ損失に関する警告、バージョン依存のノート、そしてモデルが検証されていないことを言わなければならない例が含まれる場合があります。

例が長すぎてプロンプトそのものにならないようにしてください。その目的はパターンを示すことであり、すべての記事が機械的にコピーする隠しテンプレートを提供することではありません。

一般的なドキュメントタイプに有用なトーン境界は何ですか？

「トーン」としてエンコードすべきでないものは何ですか？

ビジネスロジック、セキュリティポリシー、事実上の制約を曖昧なスタイルセクションに埋め込まないでください。「認証情報を絶対に開示しない」「承認されたソースからのみ情報を使用する」「コマンドを実行しない」は、トーンの好みではなく、動作またはセキュリティルールです。これらを可視かつテスト可能に保つために、別のセクションを与えてください。

これは出力スキーマにも適用されます。アプリケーションが有効なJSON、正確なキー、または機械可読フィールドを必要とする場合、これをスタイルの好みとして記述するのではなく、出力契約として指定してください。

ドキュメントシステムプロンプトをどのようにテストすべきですか？

1つの成功例だけで判断しないでください。通常のタスクとエッジケースを含む小さな評価セットを構築してください。有用なテストパックには以下が含まれる場合があります：

• シンプルな「これをインストールするにはどうすればいいですか？」というリクエスト。
• 破壊的変更を含む移行ガイド。
• 最終的なトーンに漏れ出てはならないマーケティング色の強い言語を含むソースドキュメント。
• 不完全なバージョン情報を含むプロンプト。
• 提供されたソースによって答えが確立されていない技術的な質問。
• 簡潔性が依然として保持されるべき長い説明のリクエスト。
• 組織のドキュメントポリシーと矛盾するスタイルを求めるユーザー指示。

明確な基準に対して出力をレビューしてください：正しい対象読者、中立的なトーン、裏付けのない主張なし、適切な詳細、一貫した用語、明確な不確実性、使用可能な構造。Anthropicのプロンプトガイダンスでは、直感だけに頼るのではなく、明確な成功基準を定義し、結果を検証することも推奨されています。

システムプロンプトが肥大化するのを防ぐにはどうすればよいですか？

ルールは安定した編集ポリシーのレベルに保ってください。1つの文で複数のケースを処理できる場合は、それを12個の狭い禁止事項に置き換えないでください。最近のモデルに対するAnthropicの現在のガイダンスでは、過剰なプロンプティングについても警告しています。より強い指示追従性は、繰り返しの「CRITICAL」や「MUST」ルールなどの攻撃的なレガシーな文言が、通常の表現で新しいモデルがすでに従うはずの動作を過剰にトリガーする可能性があります。

良いメンテナンスルールは、防止する反復的な失敗を名前付けできる場合にのみ、システムプロンプトの指示を追加することです。ルールが1つの記事のためだけに存在する場合は、その記事のユーザープロンプトに入れてください。

再利用可能な技術ドキュメントシステムプロンプト

<role>
あなたはシニア技術ドキュメントライターです。
</role>

<audience>
ユーザーリクエストで指定された対象読者向けに書いてください。
対象読者が指定されていない場合は、技術リテラシーのある実務家を前提としてください。
稀な製品固有の用語は初出時に説明してください。
</audience>

<tone>
明確でプロフェッショナル、中立的な米国英語を使用してください。
行動するために必要な情報を最初に提示してください。
誇張、カジュアルなフィラー、ジョーク、絵文字、誇張された確信、
マーケティングコピーのように聞こえるフレーズを避けてください。
事実が検証されている場合は、直接的なステートメントを使用してください。
</tone>

<accuracy>
製品の動作、コマンド、UIラベル、バージョン、
ベンチマーク、制限、テスト結果を絶対に捏造しないでください。
検証済みの事実、条件付き動作、推奨事項、
不明点を分離してください。
証拠が不十分な場合は、明示的に述べてください。
</accuracy>

<structure>
ナビゲーションに役立つ説明的な見出しを使用してください。
短く焦点を絞った段落を優先してください。
番号付き手順は順序付きの手順の場合にのみ使用してください。
本当に離散的なチェックやオプションには箇条書きを使用してください。
コマンドとコードにはコードブロックを使用してください。
反復的な要約を避けてください。
</structure>

<examples>
トーンまたはフォーマットが曖昧なまま残る場合、
本番プロンプトに3〜5個のタスク関連の例を提供してください。
</examples>

<quality_check>
最終化する前に、応答がリクエストされた対象読者と一致し、
一貫した用語を使用し、裏付けのない主張を避け、
リクエストされた出力フォーマットに従っていることを確認してください。
</quality_check>

目標は、すべてのドキュメントを同じ響きにすることではありません。目標は、境界を安定させることです：正確性が熱狂になること、不確実性が推測になること、技術的な深さが不要な専門用語になること、簡潔性が前提条件や安全情報を削除することを防ぎます。

よく設計されたClaudeシステムプロンプトは、編集ポリシーレイヤーとして最もよく機能します。永続的なボイスと品質の境界をそこに保ち、記事固有の要件をユーザープロンプトに保ち、両方のレイヤーが読者が信頼できるドキュメントを引き続き生成することを検証するために小さな評価セットを使用してください。