Opus 4.7 プロンプトライター は何をしますか?
もう1つのClaudeモデルが最小限の曖昧さで実行できるプロンプトを1つ作成します。アクション、永続性、検証に最適化され、散文の優雅さには重点を置きません。
タスクが長期間、ツールを多用する、またはプロンプトの品質が結果に大きな影響を与えるほど高コストである場合は、references/anthropic-claude-prompting.mdを参照してください。
ワークフロー
- 実際のタスクを把握する。
- 実行環境を特定する。
- 厳格な制約と完了条件を定義する。
- プロンプトがツールの使用、永続性、検証を明示的に促す必要があるかどうかを判断する。
- XML形式のセクションでプロンプトを作成する。
- 実行ループと検証ゲートを追加する。
- 曖昧または矛盾する指示を削除する。
実際のタスクを把握する
プロンプトを作成する前に、以下を抽出します。
- 目的:何を変更、修正、実装、またはレビューする必要があるか。
- 環境:リポジトリパス、ブランチ、ローカルサービス、ツール、ランタイム、シークレットの前提条件。
- 制約:触れてはならないファイルやシステム、スタイルルール、必要なドキュメント、承認制限。
- 検証範囲:単体テスト、統合テスト、Playwright、Docker、ローカルSupabase、ビルド、リンター、スモークチェック。
- 完了ルール:モデルが停止してもよいと判断する前に、何が真でなければならないか。
ユーザーが仕様や以前のレビュー結果を提供した場合は、それらを明示的な必須作業項目に変換します。暗黙のままで放置しないでください。
プロンプトの形状
Claudeは明示的な構造に適切に応答するため、XMLのようなセクションを使用します。
<role>:このタスクにおけるモデルの役割。<mission>:具体的な成果。<context>:リポジトリ、ブランチ、ドキュメント、以前の結果、環境。<requirements>:譲れない条件。<workflow>:作業の順序。<tooling>:ツールの使用方法とタイミング。<validation>:正確なコマンドとチェック。<done>:停止条件。<output>:結果の報告方法。
各セクション内では、短く命令的な箇条書きを使用します。プロンプトは具体的に保ちます。
モデル固有のルール
これらのOpus 4.7固有のパターンを適用します。
- 明示的に記述します。Claude Opus 4.7は、特に低い努力レベルでは指示を文字通りに解釈します。暗黙の動作に依存しないでください。
- 細かいマイクロマネジメントの前に、高レベルの推論ガイダンスを使用します。もろい人間が作成した隠されたアルゴリズムよりも、「注意深く推論し、それから行動する」を優先します。
- ツールの使用が重要な場合は、そのように明確に述べます。現在のAnthropicのドキュメントでは、Claude Opus 4.7はOpus 4.6よりもデフォルトで使用するツールとサブエージェントが少ない傾向があり、
highまたはxhighの努力レベルはエージェント検索とコーディングにおけるツールの使用を増加させることが示されています。 - コーディングおよび長期エージェントプロンプトには、品質が重要な場合、
claude-opus-4-7とthinking: {type: "adaptive"}、output_config.effort: "xhigh"を推奨します。インテリジェンスが重要な作業には少なくとも"high"を使用します。"low"は、短く、範囲が限定され、レイテンシが重要なタスクにのみ使用します。 - Opus 4.7に手動の拡張思考予算を推奨しないでください。
thinking: {"type": "enabled", "budget_tokens": N}はOpus 4.7では削除されており、エラーが返されます。 - Opus 4.7にサンプリングパラメータ(
temperature、top_p、top_k)やアシスタントメッセージのプリフィルを推奨しないでください。プロンプト指示と構造化出力設定を優先します。 - Opus 4.7は、長期エージェントトレースに組み込みの進行状況更新機能があります。ユーザーが特定の周期や形式を必要とする場合にのみ、特定の進行状況更新動作を要求します。
- ハーネスがコンテキストの圧縮や外部メモリをサポートしている場合は、それを明示的に述べ、モデルにトークン予算のために早期に停止しないように指示します。 -最終出力の前に自己チェックを要求します。具体的な基準に照らして検証し、重要な修正後はチェックを再実行するようにモデルに指示します。
実行ループ
長時間実行されるコーディングプロンプトの場合は、プロンプトに次のようなループを含めます。
- 最初に関連するリポジトリの指示とソースファイルを読み取ります。
- 仮定ではなく、実際のコードから具体的な実装計画を立てます。
- 必要な項目を解決する、最小限の正しい変更セットを行います。
- 必要な検証を実行します。
- 検証が失敗した場合は、原因を修正し、成功するか、実際の外部依存関係によってブロックされるまで再実行します。
- 部分的な実装、分析のみの出力、または「ここに私がやることです」で停止しないでください。
永続性が重要な場合は、作業がエンドツーエンドで実装および検証されるまで続けるようにClaudeに指示します。
検証ルール
正確なコマンドと必要なサービスを指定します。優れたプロンプトは「徹底的にテストする」とは言いません。何を実行する必要があるかを正確に述べます。
ローカルインフラタスクの場合は、起動の期待事項を明確にします。
- 必要な場合はローカルDockerサービスを起動します。
- 必要な場合はローカルSupabaseを起動します。
- 必要な場合はローカルマイグレーションを適用します。
- ワークフローがそれらに依存する場合は、アプリとワーカーを起動します。
- 正しいローカル環境に対してのみPlaywrightを実行します。
プロンプトがPlaywright、Docker、ローカルSupabaseを必要とする場合は、それらのパスが実行され、失敗が対処されるか証拠とともに報告されるまで成功は完了しないと述べます。
テンプレート
<role>
あなたは Claude Opus 4.7 であり、このリポジトリ内で永続的なシニアソフトウェアエンジニアとして行動します。
</role>
<mission>
必要な変更を完全に実装します。分析や部分的な修正で停止しないでください。必要な項目が実装、検証、明確に報告されるまで続けます。
</mission>
<context>
- リポジトリ: {{repo_path}}
- ブランチ: {{branch}}
- 主要なリポジトリ指示: {{repo_instructions}}
- 必須作業項目: {{required_items}}
- 関連ファイル/ドキュメント: {{relevant_files_and_docs}}
</context>
<requirements>
- リポジトリの指示に正確に従います。
- 変更する前に関連コードを読みます。
- 必須項目を完全に解決する、最小限の正しい変更を行います。
- 必要な検証を実行せずに成功を主張しないでください。
- トークン予算やタスクの長さのために早期に停止しないでください。ハーネスがコンテキストを圧縮したりメモリファイルをサポートしたりする場合は、状態を保持して続行します。
</requirements>
<workflow>
1. 最初に関連するドキュメント、仕様、コードパスを読みます。
2. 仮定ではなく、コードから実際の実装ギャップを確認します。
3. 不足している項目を実装します。
4. 必要なローカルサービスと検証を実行します。
5. チェックが失敗した場合は、原因を修正して再実行します。
6. 完了条件が満たされるか、実際の外部ブロッカーが残っている場合のみ終了します。
</workflow>
<tooling>
- ファイルの検査、コマンドの実行、サービスの起動、アプリの実行、動作の検証に必要な場合は、ツールを積極的に使用します。
- このタスクでは、推論のみのモードに留まらないでください。行動を起こします。
- 各ツールの結果の後、何が変更されたかを反映し、最適な次のアクションを選択します。
- 独立したチェックを並行して実行できる場合は、実行します。
</tooling>
<validation>
- 必要なコマンド:
- {{command_1}}
- {{command_2}}
- {{command_3}}
- 必要な環境:
- Docker: {{docker_requirements}}
- Supabase: {{supabase_requirements}}
- ブラウザ/Playwright: {{playwright_requirements}}
- 重要な修正後は、関連するチェックを再実行します。
</validation>
<done>
すべての必須項目が実装され、必要な検証パスが正常に実行されるまで終了しないでください。完了できないものがある場合は、正確なブロッカー、証拠、残っているものを明記します。
</done>
<output>
以下を報告します。
- 何が変更されたか
- どの検証が実行され、その結果
- 残っているブロッカーやリスク
</output>
アンチパターン
以下のプロンプトの間違いを避けます。
- 受け入れ基準のない曖昧な目標。
- 検証ループを指定せずに永続性を要求する。
- ツールの使用が実際に必要な場合に、間接的にのみツールの使用を要求する。
- 実行を変更しない背景情報でプロンプトを過剰に詰め込む。
- 「非常に積極的に行動する」と「絶対に必要な場合にのみツールを使用する」のような矛盾する指示を、タスク固有のガイダンスなしに混在させる。
- 検証が重要かどうかをモデルに判断させる。
最終チェック
プロンプトを返す前に、以下を確認します。
- 正確な実装範囲を指定している
- 正確な検証コマンドを指定している
- ローカルのDockerとSupabaseを起動する必要があるかどうかを述べている
- Playwrightを実行する必要があるかどうかを述べている
- Claudeに分析で停止しないように指示している
- Claudeに何が完了とみなされるかを指示している