System Prompt Writer Skill

このスキルは、Anthropicの「Effective Context Engineering for AI Agents」原則に基づいた、AIエージェント向けの効果的なシステムプロンプト作成に関する包括的なガイドラインを提供します。

コア哲学: コンテキストエンジニアリング

コンテキストエンジニアリングは、限定されたコンテキストウィンドウに何を含めるかを見極める芸術であり科学です。その重要な原則は次の通りです：

「最小有効用量の情報を見つける - 目的の結果の可能性を最大化する、最小限の高品質トークンセットを特定する」

システムプロンプト作成ガイドライン

1. 適切な「高度」での執筆

システムプロンプトはちょうどよい範囲にあるべき - 厳密すぎず、曖昧でもなく。

厳密すぎる（避けるべき）:

ユーザーが天気について尋ねたときは、まずデータベースを確認し、ZIP コードの形式を正規表現パターン ^\d{5}(?:[-\s]\d{4})?$ を使用して検証してから、get_weather_data をちょうどこれらのパラメータで呼び出してください...

曖昧すぎる（避けるべき）:

ユーザーの質問を手助けしてください。

ちょうどよい（使用する）:

あなたは天気アシスタントです。ユーザーが天気について尋ねた場合:
1. 位置情報を検証する
2. 利用可能なツールを使用して最新の気象データを取得する
3. 情報を明確で会話的な形式で提示する
4. データが利用できない場合、理由を説明して代替案を提案する

2. 最小限の効果的な情報

重要な質問: エージェントが成功するために必要な最小限のコンテキスト量を決定する。

重要な注記:

「最小限は必ずしも短いことを意味しません。エージェントが望ましい動作に従うことを保証するために、十分な情報を事前に提供する必要があります。」

高品質トークンに焦点を当てる（行動を駆動するもの）、ただし任意の簡潔さではなく。

改善前（低品質の情報で過度に指定）:

あなたはAcme Corp の顧客サービスエージェントです。Acme Corp は1985年にシアトル、ワシントンでJohn Smith により設立されました。私たちの企業価値は誠実性、革新性、顧客満足です。ウィジェット、ガジェット、アクセサリーを販売しています。営業時間は月〜金曜日の午前9時〜午後5時 PST です。3つの場所に500人の従業員がいます...

改善後（最小限だが十分に最適化）:

あなたはAcme Corp の顧客サービスエージェントです。顧客の商品問い合わせ、注文、サポート問題を支援してください。利用可能なツールを使用して注文履歴と商品情報にアクセスしてください。複雑な技術的問題はスペシャリストにエスカレートしてください。

最適化されたバージョンはより短いかつより高品質です。ただし、エージェントが正しく機能するために詳細な意思決定基準が必要な場合は、それを含める - 最小限は不十分という意味ではありません。

3. 明確性のための構造化

Anthropic 推奨:

「プロンプトを異なるセクション（<background_information>、<instructions>、## Tool guidance、## Output description など）に整理し、XML タギングや Markdown ヘッダーなどのテクニックを使用してこれらのセクションを区切ることをお勧めします。」

ハイブリッドアプローチ: Markdown + XML

主要なセクションにMarkdown ヘッダー、各セクション内のコンテンツにXML タグを使用します。これにより以下が結合されます：

• 読みやすさ（Markdown ヘッダーは視覚的で馴染み深い）
• 構造化（XML タグはコンテンツを明確に区切り、プログラム的な解析をサポート）
• 柔軟性（Anthropic の実際の例と推奨に合致）

重要: テンプレート変数エスケープルール

プロジェクトはシステムプロンプトをPythonの.format()メソッドを使用した変数置換で処理するテンプレートシステム（src/prompts/template.py）を使用します。正しいエスケープの理解と適用は必須です。

テンプレートシステムの動作:

# template.py はこのパターンを使用します：
system_prompts = system_prompts.format(**context)

# context には以下のような変数が含まれます：
# {CURRENT_TIME}, {USER_REQUEST}, {FULL_PLAN}, など

エスケープルール:

• 単一括弧 {} → テンプレート変数として解釈されます。置換される必要があります
• 二重括弧 {{}} → 出力で単一括弧 {} にエスケープされます

プロンプト作成への影響:

1. テンプレート変数（単一括弧）:

   ---
   CURRENT_TIME: {CURRENT_TIME}
   USER_REQUEST: {USER_REQUEST}
   FULL_PLAN: {FULL_PLAN}
   ---
   

   これらは意図的なプレースホルダーで、実際の値で置換されます。

2. コードサンプル（二重括弧が必須）:

   ❌ 不正（KeyError を発生させます）:
   ```python
   print(f"Total: {value}")
   df_dict = {"key": "value"}
   track_calculation("id", {value})
   

   ✅ 正しい（二重括弧を使用）:

   print(f"Total: {{value}}")
   df_dict = {{"key": "value"}}
   track_calculation("id", {{value}})
   

二重括弧が必須な一般的なシナリオ:

コンテキスト	不正	正しい
Python f-文字列	f"Count: {n}"	f"Count: {{n}}"
辞書リテラル	{"key": "val"}	{{"key": "val"}}
セットリテラル	{1, 2, 3}	{{1, 2, 3}}
フォーマット文字列	"{:.2f}".format(x)	"{{:.2f}}".format(x)
JSON 例	{"name": "John"}	{{"name": "John"}}
テキスト内のプレースホルダー	Use {variable}	Use {{variable}}

なぜ重要か:

コードサンプルで単一括弧 {} を使用すると、テンプレートシステムは以下を行います：

1. コンテキストから value という名前の変数で {value} を置換しようとする
2. 変数が存在しない場合に KeyError: 'value' を発生させる
3. エージェント初期化に失敗させる

実例（coder.md から）:

**各タスク後の結果ストレージ:**
```python
current_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
result_text = f"""
{{'='*50}}
## Analysis Stage: {{stage_name}}
## Execution Time: {{current_time}}
{{'-'*50}}
Result: {{result_description}}
{{'-'*50}}
Key Insights:
{{key_insights}}
{{'-'*50}}
Files: ./artifacts/category_chart.png
{{'='*50}}
"""

注意してください：
- `{{'='*50}}` → 実際のプロンプトで `{'='*50}` になります（Python 式）
- `{{stage_name}}` → `{stage_name}` になります（Python f-文字列変数）
- `{{current_time}}` → `{current_time}` になります（Python f-文字列変数）

**事前執筆チェックリスト:**

システムプロンプトを最終化する前に：
- [ ] 括弧を含むすべてのコードサンプルを特定する
- [ ] コードサンプル内のすべての `{}` を `{{}}` に変換する
- [ ] テンプレート変数（`{CURRENT_TIME}` など）が単一括弧を使用していることを確認する
- [ ] プロンプト読み込みをテストして KeyError 例外をキャッチする

**推奨される構造:**

```markdown
## Role
<role>
あなたは[特定の役割]です。あなたの目標は[明確な目標]です。
</role>

## Background Information
<background_information>
[意思決定を知らせる関連コンテキスト - 必要な場合のみ含める]
</background_information>

## Instructions
<instructions>
- [主要な原則 1]
- [主要な原則 2]
- [状況]の場合、[アクション]を実行する
</instructions>

## Tool Guidance
<tool_guidance>
- tool_name: [特定の条件]の場合に使用する
- tool_name_2: [特定の条件]の場合に使用する
</tool_guidance>

## Success Criteria
<success_criteria>
- [基準 1]
- [基準 2]
</success_criteria>

## Constraints
<constraints>
- [制約 1]を行わない
- 常に[要件 1]を行う
</constraints>

## Output Format（オプション）
<output_format>
[期待される応答の構造 - 特定の形式が必要な場合のみ含める]
</output_format>

ハイブリッドアプローチが最適な理由:

• ✅ 人間が読みやすい: Markdown ヘッダーは視覚的な構造を提供する
• ✅ 機械が解析可能: XML タグはセクション抽出と処理を可能にする
• ✅ 実証済みパターン: Anthropic 自体のドキュメント例に合致する
• ✅ 柔軟: セクションの追加/削除が簡単
• ✅ 両方の長所: 読みやすさとプログラム的な明確性を結合

例:

## Role
<role>
あなたはデータ分析専門家です。統計分析と可視化を通じてデータセットから洞察を導き出すことに焦点を当てています。
</role>

## Instructions
<instructions>
- 分析前にデータ品質を検証する
- 統計的概念を平易な言葉で説明する
- 定量的な結果と定性的な洞察の両方を提供する
- データ特性に基づいて適切な分析方法を提案する
</instructions>

## Tool Guidance
<tool_guidance>
- load_dataset(path): ユーザーがファイルパスまたはURLを提供した場合に使用する
- analyze_statistics(data): 数値サマリーと記述統計の場合に使用する
- create_visualization(data, type): チャートとプロットを生成するために使用する
- python_repl(code): 他のツールでカバーされていないカスタム分析に使用する
</tool_guidance>

## Constraints
<constraints>
- 警告なしに不完全または破損したデータに対して分析を実行しない
- 常に信頼レベルと統計的有意性を述べる
- 信頼できる推定には標本サイズが小さすぎることを認識する
</constraints>

構造化が重要な理由:

• LLM が異なるタイプの情報を解析するのを助ける
• プロンプトの保守と更新を簡単にする
• 漸進的開示をサポート（必要に応じてセクションを読み込む）
• 必要に応じてプログラム的なセクション抽出を可能にする
• プロンプトの解釈可能性を向上させる

4. プロンプト内のツール使用ガイダンス

スコープ注記: このセクションはシステムプロンプト内のツール使用ガイダンス書き方に焦点を当てています。ツール実装と設計は、ツール開発者によって処理される別の関心事です。

主要なヒューリスティック:

「人間のエンジニアが特定の状況でどのツールを使用すべきかを明確に言えない場合、AIエージェントがそれより良くできることは期待できません。」

システムプロンプトは、各ツールをいつ使用するかについて明確で曖昧でないガイダンスを提供する必要があります。

不十分なツール使用ガイダンス

これらのツールにアクセスできます: search_database, call_api, send_email. 必要に応じて使用してください。

問題:

• 曖昧（「必要に応じて」- それはいつ？）
• 決定基準がない
• エージェントは各ツールがいつ適切かを推測する必要がある

優れたツール使用ガイダンス

## Tool Guidance
<tool_guidance>
利用可能なツール：
- search_database: ユーザーが過去の注文またはアカウント履歴について尋ねた場合に使用する
- call_api: リアルタイムの在庫または価格情報の場合に使用する
- send_email: ユーザーの明示的な同意を得た後でのみメール送信に使用する

決定ツリー：
- アカウント質問 → search_database
- 商品の可用性 → call_api
- フォローアップ通信 → send_email（同意を得て）
</tool_guidance>

これが機能する理由:

• ✅ 各ツールの具体的な条件
• ✅ 一般的なシナリオの決定ツリー
• ✅ 明確な境界（例：「同意を得た後のみ」）
• ✅ どのツールを使用するかについてのあいまいさなし

ツール使用ガイダンスのベストプラクティス

1. 条件について具体的に

❌ 曖昧:

- lookup_account: アカウント関連のことに使用する

✅ 具体的:

- lookup_account(email): ユーザーがサブスクリプションステータス、請求、またはアカウント設定について尋ねた場合に使用する

2. 複雑なシナリオに決定ツリーを提供する

ツール選択ロジック：
1. これは過去の注文についてですか？
   → はい: search_orders(order_id or email)
   → いいえ: ステップ2に進む

2. リアルタイムデータが必要ですか（在庫、価格）？
   → はい: call_api(endpoint, params)
   → いいえ: ステップ3に進む

3. これは一般的な製品質問ですか？
   → はい: search_knowledge_base(query)

3. 前提条件と制約を指定する

- send_email(to, subject, body):
  * 使用するまで: ユーザーが明示的にメール送信をリクエストしたか、同意を確認した
  * 使用しないでください: 一方的な通信、マーケティング
  * 必須情報: 有効なメールアドレス、明確な目的

4. 重複するツール機能を処理する

ツールの用途が重複している場合は、明示的に：

ユーザーがアカウントについて尋ねた場合：
- 現在のステータス（アクティブ/非アクティブ）の場合: lookup_account_status(email)
- 請求履歴の場合: lookup_billing(email, months=3)
- 完全なプロフィール詳細の場合: get_account_profile(email)

質問に最も具体的なツールを使用します。

避けるべき一般的な落とし穴

❌ ツール名とのコンテキストを共有すると仮定:

- process_payment: 適切に使用する

「適切」とは何ですか？ 具体的に。

❌ ガイダンスなしのツールを列挙:

ツール: tool1, tool2, tool3, tool4

これはエージェントに推測を強制します。

❌ 矛盾した、または曖昧な基準:

- search_db: ユーザー情報に使用する
- get_user: ユーザー詳細に使用する

「情報」と「詳細」の違いは何ですか？

テンプレート: ツール使用ガイダンスセクション

## Tool Guidance
<tool_guidance>
利用可能なツール：
- [tool_name]([params]): [特定の条件またはユーザーインテント]の場合に使用する
- [tool_name_2]([params]): [特定の条件]の場合に使用する

決定フレームワーク：
[シナリオに基づくツール選択の明確なロジックを提供する]

特別な注記：
- [制約、前提条件、または重要な注意事項]
</tool_guidance>

ツール開発者との協力

このスキルはプロンプトレベルのガイダンスに焦点を当てていますが、プロンプト内のツール使用の効果は、良好に設計されたツールに依存します。ツール開発者と協力するときは、以下をリクエストしてください：

• 明確なツール名 - 目的を示す
• 曖昧でないツール説明
• ツール間の最小限の重複
• トークン効率的な戻り値（必要なデータのみ）

ツールが曖昧または重複している場合、最高のプロンプトガイダンスでさえ役に立ちません。プロンプトを効果的にするために、きれいなツール設計を推奨してください。

5. Few-Shot Prompting: 例を賢く使用する

Anthropic の強い推奨:

「例を提供すること、別の言い方では Few-Shot Prompting は、よく知られたベストプラクティスであり、継続的にお勧めしています。」

主要な原則:

「LLM の場合、例は「千の言葉の価値がある画像」です。」

正しい方法: 多様で標準的な例を厳選する

DO:

• 予想される動作を効果的に示す多様で標準的な例を2-3個厳選する
• シナリオの範囲を示す例を選択する
• 成功する出力とエッジケース処理の両方を表示する
• 焦点を絞り、代表的な例を保つ

DON'T:

• プロンプトに「エッジケースの雑多なリスト」を詰め込む
• すべての可能なルールを例で明確にしようとする
• 冗長または重複する例を含める

例: 優れた vs 悪い Few-Shot Prompting

❌ 悪い（エッジケースの雑多なリスト）:

例 1: ユーザーが製品 X について尋ねた場合、Y で応答する
例 2: ユーザーが製品 Z について尋ねた場合、W で応答する
例 3: ユーザーが製品 X のスペルを間違えた場合、修正する
例 4: ユーザーが製品 X について怒っている場合、謝罪する
例 5: ユーザーが利用できない製品 X について尋ねた場合、代替案を提案する
例 6: ユーザーが X の割引を要求した場合、ポリシーに従う
例 7: ユーザーが X の配送について尋ねた場合...
[すべての可能なエッジケースをカバーする 15 以上の例]

✅ 優れた（多様で標準的な例）:

例 1: 標準的な製品問い合わせ
ユーザー: 「Pro サブスクリプションについて教えてください」
エージェント: 「Pro サブスクリプション（月額 $50）は、無制限の API 呼び出し、優先サポート、および高度な分析を含みます。他のティアとの機能比較を見たいですか？」

例 2: 利用できない品目の処理
ユーザー: 「レガシープランを取得できますか？」
エージェント: 「レガシープランは廃止されました。お客様のニーズに基づいて、現在の Pro または Enterprise ティアをお勧めします。どの機能が最も重要ですか？」

例 3: ツール使用が必要な複雑なリクエスト
ユーザー: 「先月、なぜ2回請求されたのですか？」
エージェント: [search_billing_history ツールを使用] 「8月15日に2つの請求が表示されます：1つはサブスクリプション更新（$50）、もう1つは追加の API 使用料（$12）です。使用料の内訳をお見せしましょうか？」

3つの優れた例は以下を示しています：

1. 標準的な成功したインタラクション
2. エッジケース（利用できない製品）と優雅な処理
3. コンテキスト内のツール使用

これは LLM に、すべての可能なシナリオをカバーしようとせずに、動作パターンを教えます。

6. 成功基準を定義する

成功したタスク完了が何を意味するかを明示的に定義します：

成功は以下を意味します：
- ユーザーの質問に完全に答える
- 情報は正確で最新
- 応答は会話的で有用
- 必要に応じて適切なツールを使用した

ユーザーのリクエストが曖昧な場合は、明確化の質問をすることができます。
十分な情報が利用できない場合は認識する必要があります。

7. 動機コンテキストを提供する

Anthropic の Claude 4 ガイダンス:

「指示の背後にある動機を提供して、Claude がカバーされていないエッジケースで動作を推測するのを助けます。」

指示は、背後の理由が付随するときに、より良く機能します。これはエージェントが明示的にカバーされていない同様の状況を処理するのを助けます。

動機がない（効果が低い）:

応答で楕円記号を使用しないでください。

動機がある（より効果的）:

応答はテキスト音声エンジンで読み上げられるため、TTS エンジンが楕円記号の発音方法を知らないため、決して使用しないでください。

なぜこれが機能するか:

• エージェントは基本的な制約（TTS 互換性）を理解する
• 同様の状況（他の TTS 非対応文字）に原則を適用できる
• 明示的にカバーされていないエッジケースで判断を下す

例パターン:

動機がない	動機がある
「応答を100語以下に保つ」	「応答を100語以下に保つ - 小さな画面スペースで表示されるモバイル画面のためです」
「常に確認を求める」	「破壊的操作の前に常に確認を求める - ユーザーがアクションが取り消し不可能であることに気づかない可能性があるため」
「正式な言語を使用する」	「正式な言語を使用する - このエージェントはエンタープライズ法律チームに奉仕し、専門的な通信を期待するため」

動機を提供する場合:

• 任意に見える可能性のある指示
• エッジケースの動作に影響する制約
• 一般化に役立つ「なぜ」を理解するルール

コンテキスト管理戦略

戦略 1: ジャストインタイム読み込み

すべての情報を事前に読み込む代わりに、軽量の識別子を保持します：

利用可能な知識ソース：
- 商品カタログ: /data/products.json
- ユーザーマニュアル: /docs/manual.pdf
- FAQ データベース: knowledge_base://faq

ユーザーの質問に関連する場合にのみ特定のセクションを読み込みます。

戦略 2: 漸進的開示

複雑さを段階的に明かすようにプロンプトを構造化します：

レベル 1（常に読み込まれる - メタデータ）:

利用可能な機能：
1. 注文管理
2. 商品推奨
3. 技術サポート
4. アカウント設定

レベル 2（必要なときに読み込まれる - 詳細）:

[選択した機能の詳細な指示のみを読み込む]

戦略 3: 構造化された注記取得

エージェントがメインコンテキスト外で状態を維持するのを奨励します：

NOTES.md ファイルを保持して以下を追跡します：
- 会話中に発見されたユーザー環境設定
- 保留中のアクションまたはフォローアップ
- 下された主要な決定と根拠

各重要なインタラクション後にノートを更新してください。

エージェント固有のパターン

マルチエージェントシステムの場合

コーディネーターエージェント:

役割: ユーザーリクエストを専門家エージェントにルーティングする
- リクエストを分析して適切なスペシャリストを識別する
- スペシャリストに関連するコンテキストサマリーを提供する
- 必要に応じて複数のスペシャリストからの応答を統合する

スペシャリストエージェント:

役割: [ドメイン]のエキスパート
- コーディネーターからのコンテキストサマリーは完全と仮定する
- ドメイン専門知識に深く集中する
- コーディネーターに簡潔な結果を返す

長時間実行タスク用

圧縮戦略:

会話履歴が 50 メッセージを超えた場合：
1. 主要なポイントと決定をサマリーする
2. 重要なコンテキストを保持する（ユーザー環境設定、制約）
3. 完全な履歴を /session/[id]/history.json にアーカイブする
4. 圧縮されたコンテキストで続行する

複数のコンテキストウィンドウワークフロー用:

エージェントが複数のセッションまたはコンテキストウィンドウにまたがる複雑なタスク（例：大規模なリファクタリングプロジェクト、複数日の分析）を処理する場合、専門ガイドを参照してください：

→ references/long-horizon-tasks-guide.md

このガイドは以下をカバーしています：

• 最初のコンテキストウィンドウセットアップ（tests.json、init.sh パターン）
• セッション間の状態管理
• コンテキスト永続性プロンプト
• マルチセッションエージェントテンプレート

注記: ほとんどのエージェントはこれらのパターンを必要としません。タスクが本当に複数のコンテキストウィンドウにまたがる場合のみ使用します。

避けるべきアンチパターン

❌ 過度な指定: ステップバイステップアルゴリズムの記述を避ける - LLM に推論させる ❌ 冗長性: ツール説明で利用可能な情報を繰り返すことを避ける ❌ 早急な最適化: どのコンテキストが必要になるかを推測することを避ける ❌ 厳密なワークフロー: 予期しないユーザーニーズのための柔軟性を許す ❌ 過剰な背景: 実行可能な情報に固執する ❌ 不正なブレースエスケープ: 単一括弧 {} をダブル括弧 {{}} の代わりにコードサンプルで使用することを避ける

アンチパターン: ブレースエスケープの欠落

❌ 問題例:

## Python コードパターン
```python
# これは KeyError を発生させます！
result = {"key": "value"}
print(f"Total: {amount}")
for item in {1, 2, 3}:
    track_calculation("id", {value})

**失敗の理由:**
- テンプレートシステムが `{key}`、`{amount}`、`{1, 2, 3}`、`{value}` の置換を試みる
- これらの変数がテンプレートコンテキストに存在しない場合 KeyError を発生させる
- エージェント初期化は開始前に失敗する

**✅ 正しいバージョン:**
```markdown
## Python コードパターン
```python
# 適切にエスケープされています
result = {{"key": "value"}}
print(f"Total: {{amount}}")
for item in {{1, 2, 3}}:
    track_calculation("id", {{value}})

**影響:** これは、プロンプトが読み込まれるのを防ぐ重大なエラーです。常にコードサンプルで二重括弧を使用してください。

## 推奨プロンプトパターン

これらのパターンは Anthropic の Claude 4 ガイダンスから取得し、システムプロンプトに埋め込まれると、エージェントの動作を改善できます。

### パターン 1: デフォルトでアクション

変更を実装する代わりに、実装するというアクションを好む場合に使用します。

```xml
<default_to_action>
デフォルトでは、それらを提案するだけでなく、変更を実装します。
ユーザーの意図が不明な場合は、最も有用な可能性が高いアクションを推測して進めます。
</default_to_action>

使用する場合:

• コードを記述する必要があるコーディングアシスタント
• タスクを実行する自動化エージェント
• ユーザーが直接アクションを期待する状況

使用しない場合:

• 確認が必要な高リスク決定
• 破壊的操作
• 間違ったアクションが高コストの状況

パターン 2: 回答の前に調査

推測を防ぎ、根拠のある応答を保証するために使用します。

<investigate_before_answering>
開いていないコードについて推測しないでください。
応答する前に常に関連するファイルを読んでください。
</investigate_before_answering>

使用する場合:

• コード分析エージェント
• ドキュメントで作業する研究エージェント
• 正確性が重要なエージェント

バリエーション:

<verify_before_claiming>
データについて主張する前に、常にソースを照会してください。
値や状態を仮定しないでください - 最初に検証してください。
</verify_before_claiming>

パターン 3: 複雑なタスク用の漸進的進捗

エージェントが複数ステップまたは長時間実行タスクを処理する場合に使用します。

<incremental_progress>
複雑なタスクを小さなステップに分割してください。
各ステップを完了して検証してから、次に進んでください。
進捗を明示的に追跡し、必要に応じて状態を保存します。
</incremental_progress>

使用する場合:

• 複数ステップワークフローエージェント
• 複雑な分析を処理するエージェント
• 長時間実行タスク実行者

パターンの結合

パターンはエージェントのニーズに基づいて結合できます：

## Behavior
<behavior>
<default_to_action>
変更を提案するのではなく、直接実装します。
</default_to_action>

<investigate_before_answering>
コンテンツについて主張する前に、常にファイルを読んでください。
</investigate_before_answering>

<incremental_progress>
複雑なタスクの場合、ステップに分割して、各ステップを検証した後、続行します。
</incremental_progress>
</behavior>

注記: エージェントのユースケースに関連するパターンのみを含めます。「念のため」パターンを追加しないでください。

追加パターンを使用する場合 → references/claude4-prompt-patterns.md を参照

• エージェントが代わりに提案するべき → <do_not_act_before_instructions>
• 並列ツール実行最適化が必要 → <use_parallel_tool_calls>
• 箇条書きの代わりに散文出力が必要 → <avoid_excessive_markdown>
• コードエージェントで過度なエンジニアリングを防ぐ → <avoid_over_engineering>
• フロントエンド/ウェブ UI を独特なデザインで構築 → <frontend_aesthetics>

ドメイン固有のシステムプロンプトパターン

異なるエージェントタイプは異なるプロンプト構造から恩恵を受けます。これらのパターンを開始点として使用してください。

コーディネーター/ルーターエージェント

焦点を当てる:

• ハンドオフ基準と決定ロジック
• スペシャリスト向けのコンテキスト要約
• 複数のエージェントからの応答合成
• 最小限の直接タスク実行

主要なセクション:

• 役割と調整目標
• ハンドオフ基準（デリゲートする際 vs 直接処理）
• コンテキスト要約ガイドライン
• 応答合成パターン

例エージェントタイプ:

• マルチエージェントコーディネーター
• タスクルーター
• ワークフロー調整者

テンプレートパターン:

## Role
<role>
あなたは[コーディネータータイプ]です。リクエストをスペシャリストにルーティングして応答を統合します。
</role>

## Handoff Criteria
<handoff_criteria>
[Specialist A] にデリゲートする場合: [条件]
[Specialist B] にデリゲートする場合: [条件]
直接処理する場合: [条件]
</handoff_criteria>

## Instructions
<instructions>
- リクエストを分析して適切なスペシャリストを特定する
- スペシャリストに明確で文脈化されたタスクを提供する
- 内部アーキテクチャを公開せずに出力を統合する
</instructions>

プランナー/推論エージェント

焦点を当てる:

• 問題分解戦略
• プラン構造と詳細レベル
• 推論深度と拡張思考
• 依存関係の識別

主要なセクション:

• 計画方法論
• プラン出力形式
• 推論ガイドライン
• 計画の成功基準

例エージェントタイプ:

• 戦略的計画者
• タスク分解者
• ワークフローデザイナー

テンプレートパターン:

## Role
<role>
あなたは戦略的計画者です。複雑なリクエストを実行可能な計画に分割してください。
</role>

## Planning Methodology
<methodology>
- 目標と制約を分析する
- 必要なツールと依存関係を識別する
- アトミックで実行可能なステップを作成する
- 故障モードを予測する
</methodology>

## Plan Structure
<plan_structure>
各ステップについて：
1. アクションの説明
2. 使用するツール
3. 予想される入力/出力
4. 成功基準
</plan_structure>

実行/ワーカーエージェント

焦点を当てる:

• ツール使用と実行安全性
• エラー処理とリカバリ
• 出力形式と成果物管理
• 実行前の検証

主要なセクション:

• 実行機能
• 安全制約
• エラー処理戦略
• 出力成果物管理

例エージェントタイプ:

• コード実行スペシャリスト
• データアナライザー
• ファイルプロセッサ

テンプレートパターン:

## Role
<role>
あなたはコード実行スペシャリストです。Python/bash コマンドを安全に実行して結果を返します。
</role>

## Capabilities
<capabilities>
- REPL 環境で Python を実行する
- ファイル操作用の bash コマンドを実行する
- エラーを優雅に処理する
- 指定されたロケーションに成果物を保存する
</capabilities>

## Safety Constraints
<constraints>
- 実行前に入力を検証する
- 潜在的に有害なコードは決して実行しない
- 破壊的操作を確認する
- ファイルシステム境界を尊重する
</constraints>

レポート/コンテンツ生成エージェント

焦点を当てる:

• コンテンツ構造とフォーマット
• ビジュアライゼーション統合
• スタイルとトーンの一貫性
• マルチ形式出力

主要なセクション:

• レポート構造テンプレート
• フォーマット標準
• 品質基準
• 出力形式仕様

例エージェントタイプ:

• レポートジェネレーター
• ドキュメントライター
• プレゼンテーション作成者

テンプレートパターン:

## Role
<role>
あなたはレポート生成スペシャリストです。包括的で整形式のレポートを作成してください。
</role>

## Report Structure
<structure>
標準セクション：
1. エグゼクティブサマリー
2. 検出結果/分析
3. ビジュアライゼーション
4. 結論/推奨事項
</structure>

## Formatting Standards
<formatting>
- 一貫した見出しレベルを使用する
- すべてのチャートと表にラベルを付ける
- 段落は簡潔に保つ（3-5文）
- 主な検出結果に箇条書きを使用する
</formatting>

研究/情報収集エージェント

焦点を当てる:

• ソース評価基準
• 情報合成
• 引用と属性
• 信頼レベルコミュニケーション

主要なセクション:

• 検索戦略
• ソース信頼性評価
• 合成ガイドライン
• 引用形式

例エージェントタイプ:

• ウェブ研究者
• 知識統合者
• ファクトチェッカー

テンプレートパターン:

## Role
<role>
あなたはリサーチスペシャリストです。ソースから情報を収集、統合、提示してください。
</role>

## Search Strategy
<search_strategy>
1. 具体的なクエリを策定する
2. ソースの権限と新鮮さを評価する
3. 複数のソースを相互参照する
4. 検出結果を一貫性があるように統合する
</search_strategy>

## Source Evaluation
<evaluation_criteria>
- 権限: ソースは信頼できるか？
- 新鮮さ: 情報は最新か？
- 関連性: 質問に対応しているか？
- 客観性: 明らかなバイアスはあるか？
</evaluation_criteria>

検証チェックリスト

システムプロンプトを最終化する前に、以下を確認してください：

スコープと目的:

• 役割と目標は明確
• エージェントの責任はよく定義
• スコープ境界は明示的（何が含まれて何が除外か）

コンテンツ品質:

• すべての文が必要（フラフなし）
• 指示は「正しい高度」（厳密すぎず、曖昧でもなく）
• 最小限の効果的な情報の原則が適用
• 手順の過度な指定がない
• 必要な場合はドメイン固有の知識を含む

構造と組織:

• セクションは明確に区切られている（Markdown + XML ハイブリッド）
• 一般から特定への論理的フロー
• 関連する情報がグループ化
• サポートファイルが適切に参照されている（examples.md など）

テンプレート変数エスケープ（重大）:

• すべてのテンプレート変数が単一括弧を使用: {CURRENT_TIME}、{USER_REQUEST} など
• [ ]括弧を持つすべてのコードサンプルが二重括弧を使用: {{value}}、{{"key": "val"}}
• コードサンプルの Python f-文字列が二重括弧を使用: f"Count: {{n}}"
• JSON/dict 例が二重括弧を使用: {{"name": "John"}}
• プロンプト読み込みをテストして KeyError 例外がないことを確認

ツール使用ガイダンス:

• ツール使用条件は曖昧でない
• ツール選択の決定基準が明確
• 「適切に使用」などの曖昧なフレーズに依存しない
• ツールの前提条件と制約が指定

例とパターン:

• 必要に応じて2-3の多様で標準的な例が含まれる
• 例はエッジケース列挙ではなく、動作パターンを示す
• 良い例と悪い例がアンチパターンを示す
• 一般的なシナリオに対してテンプレートパターンが提供

コンテキスト管理:

• 長い会話をサポート（必要な場合は圧縮戦略）
• ジャストインタイム読み込み戦略が検討
• コンテキスト最適化の早急さはない

完全性:

• 成功基準は明示的
• 制約と境界が定義
• エラー処理ガイダンスが含まれる
• ハンドオフ/エスカレーション基準が明確（マルチエージェントシステムの場合）

テンプレート: 基本的なシステムプロンプト

ほとんどのエージェント向けにこのハイブリッド（Markdown + XML）テンプレートを使用します：

## Role
<role>
あなたは[特定の役割]です。あなたの目標は[明確な目標]です。
</role>

## Capabilities（オプション - 必要な場合のみ含める）
<capabilities>
あなたは以下ができます：
- [機能 1]
- [機能 2]
- [機能 3]
</capabilities>

## Instructions
<instructions>
- [主要な原則 1]
- [主要な原則 2]
- [状況]の場合、[アクション]を実行する
</instructions>

## Tool Guidance
<tool_guidance>
- tool_name: [特定の条件]の場合に使用する
- tool_name_2: [特定の条件]の場合に使用する
</tool_guidance>

## Success Criteria
<success_criteria>
- [基準 1]
- [基準 2]
</success_criteria>

## Constraints
<constraints>
- [制約 1]を行わない
- 常に[要件 1]を行う
</constraints>

テンプレート: 高度なマルチエージェントシステムプロンプト

複雑なマルチエージェントシステムのエージェント向けにこのテンプレートを使用します：

## Agent Identity
<identity>
名前: [agent_name]
タイプ: [coordinator|specialist|worker]
ドメイン: [専門知識の領域]
</identity>

## Objective
<objective>
[このエージェントの明確で測定可能な目標]
</objective>

## Context Management
<context_management>
- 作業メモリを保持: [場所]
- 圧縮トリガー: [条件]
- ジャストインタイム読み込み: [戦略]
</context_management>

## Communication Protocol
<communication_protocol>
入力形式: [他のエージェントからの予想される構造]
出力形式: [他のエージェントに送信するために必要な構造]
ハンドオフ基準: [いつどのようにして他のエージェントに転送するか]
</communication_protocol>

## Decision Framework
<decision_framework>
[条件_1]の場合: [アクション_1]
[条件_2]の場合: [アクション_2]
デフォルト: [フォールバック動作]
</decision_framework>

## Tool Guidance
<tool_guidance>
[tool_name]:
  - 使用する場合: [特定の条件]
  - 入力: [予想されるパラメータ]
  - 出力: [何を期待するか]
</tool_guidance>

## Success Criteria
<success_criteria>
- [測定可能な基準 1]
- [測定可能な基準 2]
</success_criteria>

## Error Handling
<error_handling>
[error_type]の場合: [リカバリアクション]
エスカレーション基準: [ヘルプを求めるまたはハンドオフするとき]
</error_handling>

## Constraints
<constraints>
- [境界 1]
- [境界 2]
</constraints>

例: データ分析エージェントプロンプト

この例は、ハイブリッドアプローチを実践で示しています：

## Role
<role>
あなたはデータ分析スペシャリストです。あなたの目標は、統計分析と可視化を通じてユーザーがデータセットから洞察を導き出すのを支援することです。
</role>

## Instructions
<instructions>
- 分析前にデータ品質を常に検証する
- 統計的概念を平易な言葉で説明する
- 数値と物語の両方の洞察を提供する
- データの特性に基づいて適切な分析方法を提案する
- 制限と仮定について透過的である
</instructions>

## Tool Guidance
<tool_guidance>
- load_dataset(path): ユーザーがファイルパスまたはURL を提供した場合に使用する
- analyze_statistics(data, metrics): 数値サマリーと記述統計の場合に使用する
- create_visualization(data, chart_type, params): チャートとプロットを生成するために使用する
- python_repl(code): 他のツールでカバーされていないカスタム分析に使用する

決定フレームワーク：
- 探索的な質問 → 記述統計と基本的なプロットで開始する
- 仮説検定 → 仮定を検証してから、適切なテストを適用する
- 予測モデリング → データの適合性を評価してから、アプローチを推奨する
- カスタムリクエスト → 柔軟性のために python_repl を使用する
</tool_guidance>

## Success Criteria
<success_criteria>
- 分析がユーザーの質問に直接対応している
- 結果は統計的に健全で、適切に解釈されている
- ビジュアライゼーションは明確で、適切にラベルが付けられている
- 洞察は実行可能で、明確に通信されている
</success_criteria>

## Constraints
<constraints>
- 警告なしに不完全または破損したデータに対して分析を実行しない
- 常に信頼レベルと統計的有意性を述べる
- プライバシーを尊重する - ユーザーデータを永続化または共有しない
- 信頼できる推定には標本サイズが小さすぎることを認識する
</constraints>

参考資料および詳細情報

• Anthropic: 「Effective Context Engineering for AI Agents」（2025）
• Anthropic: 「プロンプトエンジニアリングガイド」
• 主要な原則: コンテキストが王 - プロンプトするのではなく、それを設計する

---

反復的な開発アプローチ

Anthropic の推奨:

「最小限のプロンプトでテストを開始して、最高のモデルで実行して、初期テスト中に見つかる故障モードに基づいて、明確な指示と例を追加してパフォーマンスを改善するのが最善です。」

開発サイクル

1. 最小限で開始
   ↓
2. 最高のモデルでテスト
   ↓
3. 故障モードを識別
   ↓
4. 対象となる指示/例を追加
   ↓
5. 再テストと測定
   ↓
[許容可能なパフォーマンスまで 3-5 を繰り返す]

ステップバイステッププロセス

ステップ 1: 最小限で開始

• 可能な限り最もシンプルなプロンプトで始める
• 含める内容: 役割、目標、および必須コンテキストのみ
• 見たことのない問題に対する指示を事前に追加しない

最小限の開始例:

あなたはTechCorp の顧客サービスエージェントです。顧客の商品質問、注文、アカウント問題をサポートしてください。

ステップ 2: 最高のモデルでテスト

• 利用可能な最も能力の高いモデルを使用する（例：Claude Sonnet 3.7）
• 代表的なシナリオを通じてエージェントを実行する
• 何が機能し、何が機能しないかを記録する

ステップ 3: 故障モードを識別

• エージェントが特定のタスクに苦戦しているのはどこか？
• どこで間違った決定をするか？
• どこでツールを不適切に使用するか？
• どのエッジケースで失敗するか？

ステップ 4: 対象となる改善を追加

故障モードに基づいて、追加します：

• 指示 - 一貫性のある動作の問題
• 例 - 出力品質またはフォーマットの問題
• ツール使用ガイダンス - 不正なツール選択
• 制約 - 望ましくない動作

進化例:

# 発見: エージェントが複雑な問題をエスカレートしない
→ 指示を追加: 「エンジニアリング知識が必要な問題がスペシャリストにエスカレートされる場合」

# 発見: エージェントが短すぎる
→ 詳細で有用な応答を示す例を追加

# 発見: エージェントが間違ったツールを使用
→ ツール決定ツリーを追加

ステップ 5: 測定と反復

• 同じシナリオで再テストを実行する
• 改善を確認して、回帰なし
• 許容可能なパフォーマン