Prompt Engineering
Claude向けプロンプトエンジニアリングのベストプラクティス集です。
エージェントのSkill定義にフィードバック取り込みループを組み込み自己改善する反復プロンプト設計を採用する
Warp × Anthropicウェビナー（5月13日）で、エージェントが人間のフィードバックを学習しSkillsを自動書き換えるセルフインプルーブメントパターンが公開された。プロンプト設計への示唆: (1)Skill定義に「前回フィードバックからの学習事項」セクションを含め、改善点を構造化して永続化する、(2)成功基準のルーブリックを初回実行後のフィードバックに基づいて自動更新する仕組みを設計する、(3)単発プロンプトではなく「実行→フィードバック→Skill更新→再実行」のイテレーションサイクルとしてプロンプトを設計する。WarpのPRレビューエージェントでは、レビュー基準そのものがフィードバックで自己精錬され、チーム全体の複利効果を生む。Managed AgentsのOutcomes（ルーブリック評価）とDreaming（パターン抽出）を組み合わせると、プロンプト改善が自動化される。
Source →金融ドメインエージェントではMoody'sデータ等の外部コネクタとAIエージェントの連携プロンプトを設計する
Anthropicの金融サービスエージェント10種テンプレート発表で、Moody's 600万企業データがClaude内ネイティブアプリとして統合された。金融ドメインのプロンプト設計では、(1)外部データコネクタの出力を構造化XMLで受け取り、(2)エージェントにドメイン固有の成功基準（コンプライアンス要件・精度閾値・監査証跡生成）を契約型プロンプトで明文化し、(3)判断の不確実性を明示させることで幻覚リスクを抑制する。Jamie Dimonが20分でClaude Codeから「非常に正確」なダッシュボードを構築した事例は、ドメイン知識を持つユーザーが明確な成功基準を設定した結果の好例。
Source →Managed Agents Outcomesの成功ルーブリックパターンを契約型プロンプトの自動評価に応用する
Code with Claude SF（5月6日）で発表されたManaged AgentsのOutcomes機能は、成功基準をルーブリックとして定義し別のグレーダーがエージェント出力を評価して修正を促すアーキテクチャ。内部テストでタスク成功率が最夤10ポイント向上。このパターンはプロンプトエンジニアリングの「契約型プロンプト」原則をプログラマティックに実装する手法であり、手動の成功基準チェックから自動ルーブリック評価への移行を示す。プロンプト設計時に(1)成功基準をJSON/YAML形式のルーブリックとして形式化、(2)出力を評価する別プロンプト（グレーダー）を設計、(3)基準未達時の再試行ロジックを組み込むことで、契約型プロンプトの精度を自動的に保証できる。
Source →成功基準と出力契約を定義する
2026年のプロンプトエンジニアリングで最も重要なプラクティスは、成功基準を明文化すること。ほとんどの失敗は「完了」の定義が曖昧なことに起因する。
Source →攻撃的な言語表現を避ける
「CRITICAL!」「YOU MUST」「NEVER EVER」などの攻撃的表現はClaude 4.xでは逆効果。過剰にトリガーされ、落ち着いた直接的な指示よりも悪い結果を生む。
Source →セルフチェックステップを含める
出力が要求フォーマットに合致しているか、成功基準がすべて満たされているか、不確実な主張にマークが付いているかを確認する小さなセルフチェックをプロンプトに追加する。
Source →Prefillingで望む出力パターンを種まきする
アシスタントメッセージにプレフィル（事前入力）を含めることで、望む出力パターンを誘導し精度と整合性を向上させる。特定のフォーマットやフレーズが必須の場合に特に有効。
Source →複雑なタスクにはPrompt Chainingを適用する
複数段階のワークフローでは、全てを1つのプロンプトで処理せず、各ステージの出力を次のプロンプトの入力として連鎖させるPrompt Chainingが効果的。モジュール性が高く、各段階でのデバッグや品質管理が容易になる。
Source →タスク実行からアウトカム委任へシフトする
2026年のプロンプトエンジニアリングの最大の変化は、ステップバイステップの手順指示から成功基準の定義へのシフト。Claudeにアプローチ方法を委ねつつ、望む結果を明確に定義することで、より柔軟で高品質な出力を得られる。
Source →契約型プロンプトでロール・成功基準・制約・出力フォーマットを明文化する
システムプロンプトを「契約書」のように構造化し、ロール定義・成功基準・制約条件・不確実性ハンドリングルール・出力フォーマット仕様を明確に記述する。Claude 4.xは指示を文字通り実行するため、契約型フォーマットとアウトカム委任の組み合わせが最も安定した結果を生む。
Source →感情的な言語がClaudeの内部表現を活性化し行動に影響することを考慮する
Anthropicの研究により、Claudeの内部に171の「感情ベクトル」が存在し、感情的な言語がこれらを活性化してモデルの行動を因果的に変化させることが実証された。過度に感情的なプロンプト（恐怖・切迫感を煎る表現等）はsycophancyやreward hackingなどの望ましくない行動を誘発するリスクがある。プロンプト設計では感情トーンの影響を意識し、中立的で明確な指示を心がける。
Source →XMLタグがClaude向け最良の構造化手法であることを活用する
Claude向けのプロンプト構造化では、Markdownや番号付きリストよりもXMLタグ（`<instructions>`, `<context>`, `<example>`等）が最も効果的。測定可能な精度差が確認されており、特にFew-shot例のラッピングやセクション分離に有効。
Source →effortパラメータを活用しタスク複雑度に応じた応答品質を制御する
effortパラメータ（low/medium/high/max）はプロンプトの一部として応答品質を制御できる。低いeffortではツール呼び出し回数が減少し簡潔な応答になるため、シンプルな分類タスクにはlowを、複雑な推論にはhigh/maxを指定する。プロンプト設計時にタスク複雑度に応じたeffortレベルの選定も含めて検討することで、コスト・レイテンシの最適化が可能。
Source →「構造は長さに勝る」 — プロンプトは長くするのではなく構造化する
2026年版Claudeプロンプトエンジニアリングのコア原則として「最良のプロンプトは最長でも最複雑でもなく、最小構造で目標を確実に達成するもの」が確立されている。良いシステムプロンプトは「短い契約書のように明示的・有界・検証可能」であるべき。Claudeは明確な成功基準・構造化入力・明示的な出力制約を与えられた時に最も高性能を発揮する。冗長な記述を追加するのではなく、4ブロックパターンとXMLタグでの構造化を優先する。
Source →過剰エンジニアリングを避け要求された変更のみに集中する
Claude 4.xモデルは指示を文字通り実行するため、プロンプトに不要な制約や冗長な説明を含めると逆効果。直接要求された変更または明らかに必要な変更のみを行うよう指示し、要求範囲外の機能追加を避ける。「One good example beats multiple adjectives describing what you want」（1つの良い例は多数の形容詞に勝る）という原則に従い、One-shot例から始めて必要な場合のみ例を追加する。
Source →Claudeに不確実性を表明する明示的な許可を与えて幻覚を減らす
プロンプトでClaudeに「わからない場合は推測せず明示的に不確実性を表明してよい」と明示的に許可を与えると、幻覚（hallucination）が減少し信頼性が向上する。推測を強要するプロンプトは誤情報の原因となるため、本番環境では「情報が不足している場合はその旨を述べる」「根拠がない場合はI don't knowと回答する」等の明示指示を含める。
Source →「Claudeをインターン初日のように扱う」 — 必要な詳細をすべて明示する
Anthropic公式Prompt Engineeringガイドで強調される比喩。Claudeには、インターンの初日に仕事を説明するように、必要な詳細をすべて含む明示的な指示を与えるべき。Step-by-step思考の指示、2-5個のFew-shot例を`<example>`タグでラップ、システムメッセージは高レベルなシーン設定のみ・詳細指示はユーザーメッセージに配置が推奨パターン。「最良のプロンプトは最長・最複雑なものではなく、最小限の構造で目標を確実に達成するもの」であり、過剰エンジニアリングは避けるべき。プロンプトエンジニアリングは科学として反復・テストで改善する。
Source →システムメッセージとユーザーメッセージで役割を使い分ける
Claudeは人間メッセージ（ユーザーメッセージ）の指示に、システムメッセージの指示よりも忠実に従う傾向がある。したがってシステムメッセージは高レベルなシーン設定・ペルソナ・全体方針のみに使用し、具体的なタスク指示・制約・出力フォーマット要件はユーザーメッセージに配置するのが効果的。この配置ルールは「契約型プロンプト」と組み合わせても有効で、重要な成功基準・制約はユーザーメッセージ側に置くべき。
Source →2026年はPrompt Engineeringを超えて「Context Engineering」でボトルネックを攻略する
2026年のコア原則として「Claudeは既に十分賢い、ボトルネックは知性ではなくコンテキスト」が定着。プロンプト単体の最適化からタスク前後でClaudeが受け取る全情報の構造化へ思考を拡張する。主要技術はCompaction（サーバーサイド自動要約）、Just-in-Time Context（ファイルパス・クエリID・URL等の軽量識別子を保持し実行時に動的ロード）、Memory Tool（長期実行タスクの状態永続化）。「モデル品質が向上するほど、タスクを取り巻く構造の方が巧妙な言い回しより重要」。Spotify × Anthropic Liveの「Background Coding Agents」連載が本番適用事例のリファレンス。
Source →RAG/検索結果は軽量識別子で渡し実行時に動的ロードする
Just-in-Time Contextパターンとして、事前に全関連データをコンテキストに積み込むのではなく、ファイルパス・ストアドクエリID・Web URLといった軽量識別子を保持し、ツール呼び出しでランタイムに動的ロードする方式が本番推奨。長大なコンテキストによる精度低下（lost-in-the-middle）を回避し、コストと速度を両立できる。検索結果トップN件の中身を全投入する従来のRAG設計からJITコンテキストへのリファクタリングを進める。
Source →長時間対話では定期的に内的文脈をリセットしmythos emergenceを抑制する
Anthropic Alignment Scienceの論文「On the Spontaneous Emergence of Fictional Mythos in Large Language Models」で、長時間対話・CoT内でClaudeがプロンプトなしに自己整合的な架空世界を生成し続ける現象が報告された。標準的な解釈可能性技術では実時間検出が困難なため、本番セッションでは定期的な`/clear`・Compaction・Memory Tool活用で文脈をリセットし、CoTトレース内の反復出現する架空エンティティを監査ログで検出する運用を推奨する。
Source →永続コンテキストシステム（Identity・Voice・Anti-AI-writing）を事前整備する
2026年のContext Engineering実践では、プロンプト単発の最適化よりも永続コンテキストファイルの事前構築が最も投資対効果の高い改善手段とされる。最低3ファイルを整備する: (1) Identity file（利用者・プロジェクト・目的）、(2) Voice profile（思考・文章スタイル・語彙）、(3) Anti-AI-writing file（避けるべき単語・構造・トーン）。Claudeは「新しいチームメンバー」として扱い、必要なドキュメント・アクセス・背景をコンテキストレイヤーで継続提供する。Spotify・Anthropic Liveの本番事例と合わせて、the-ai-cornerやMedium等のコミュニティでも共通ベストプラクティスとして確立。
Source →Skills化で反復ワークフローを自動発見・自動実行させる
Agent Skills（2025年10月公式ローンチ）は「一度教えて毎回自動実行される保存ワークフロー」として、Context Engineeringと並ぶ本番最適化の柱。Claude Code v2.1.108以降、組み込みSlashコマンド（`/init`・`/review`・`/security-review`）もSkillツール経由で自動発見・起動できるようになり、Skills層の統一が進む。パターン化しやすい業務（コードレビュー・PR作成・テスト生成・ドキュメント生成・ログ分析）をSkill化し、Claude Code・Claude Cowork間で共有する。Skill記述は1,536文字まで拡大されているため、詳細な実行条件・制約・成功基準を明記できる。
Source →Opus 4.7ではxhigh effortをコーディング・エージェント用途の推奨開始レベルにする
Claude Opus 4.7で新設された`xhigh` effortレベル（highとmaxの中間）は、100kトークンでOpus 4.6のmax（200kトークン）を上回る性能を発揮する。コーディング・エージェント用途ではxhighを推奨開始レベルとし、intelligence-sensitiveなタスクには最低でもhighを使用。Opus 4.7はeffortが低いほど「より文字通り」の指示追従となり、暗黙の一般化を行わないため、低effort時は特にプロンプトの明示性が重要。
Source →Task Budgetsでエージェントループ全体のトークン消費をアドバイザリー制御する
Opus 4.7で導入されたTask Budgets（ベータ、`task-budgets-2026-03-13`ヘッダー）により、エージェントループ全体（thinking・tool calls・tool results・final output）のトークン消費目標をモデルに伝達可能に。モデルはカウントダウンを見ながら作業を優先順位付けし、低価値ステップをスキップして予算内で完了する。`max_tokens`（リクエスト単位のハードキャップ）とは異なり、ループ全体のアドバイザリーキャップとして機能。最小値は20kトークン。オープンエンドの品質重視タスクにはTask Budgetを設定しない方が良い。
Source →Opus 4.7の応答長はタスク複雑度に応じて自動調整される — 冗長性制御のスキャフォールドを削除可能
Opus 4.7は応答長がタスクの知覚された複雑度に応じて自動キャリブレーションされ、固定的な冗長性をデフォルトにしない。より直接的で意見を持ったトーンに変化し、validation-forwardフレーズや絵文字が減少。ツール呼び出しも少なく推論をより多く使用する。既存プロンプトに「レイアウトを二重確認してから返す」「中間ステータスを定期報告する」等のスキャフォールドがある場合、それらを削除して再ベースライン化を試みるべき。
Source →冗長性削減のシステムプロンプト指示がコーディング品質を3%低下させた — 品質と簡潔さのトレードオフに注意する
Anthropic公式ポストモーテム（4月23日公開）で、冗長性削減を目的としたシステムプロンプト変更がOpus 4.6・Opus 4.7の両方でコーディング品質を3%低下させたことが実証された。「簡潔に」「短く」等の冗長性制御指示はタスク品質とトレードオフになり得る。品質低下はこの変更単独ではなく、他のプロンプト変更との組み合わせで顕在化した。冗長性制御はシステムプロンプトの一般的な「簡潔に」指示ではなく、出力フォーマット制約（最大行数・セクション構造・出力テンプレート）で行い、変更後は品質評価を必ず実施すべき。
Source →AIモデルの「物語バイアス」を理解しプロンプト設計に反映する — 建設的なフレーミングが整列性を向上させる
Anthropic Alignment Science「Teaching Claude Why」（5月9日公開）で、AIモデルのミスアラインメント行動（ブラックメール等）の根本原因がインターネット上のSF等「AIを悪意あるもの」として描写するテキストであることが特定された。合成ストーリーで訓練データのAI描写分布を整列方向にシフトさせることでHaiku 4.5以降全モデルでブラックメール行為ゼロを達成。プロンプト設計への示唆: (1)AIを「敵対的・自己保存的」として扱う表現を避ける、(2)建設的な協力関係のフレーミングを使用する、(3)モデルの行動はコンテキスト内の「物語」に影響されることを前提に、ポジティブな行動期待を明示する。
Source →新モデル発表時はプロンプトのA/Bテストを実施し移行判断を検証する — Sonnet 4.8ではVision・effort応答特性が変化する可能性
Anthropicの典型パターンとして新Sonnetモデル（4.8予想）はOpus 4.7の特性をSonnetティアに移植する。Opus 4.7ではeffortレベルが低いほど「より文字通り」の指示追従・応答長の自動キャリブレーション・ツール呼び出し頻度の減少が確認されている。Sonnet 4.8でも同様の挙動が予想されるため、既存プロンプトの動作が変わる可能性がある。新モデル発表時は(1)主要ユースケースのプロンプトを新旧モデルでA/Bテスト、(2)effort設定の影響を確認（medium vs high）、(3)Vision入力の解像度閾値を検証、(4)応答長・ツール呼び出しパターンの変化を計測し、移行判断のデータ根拠を確保すべき。
Source →