Menú
Claude 4.x 最新プロンプトエンジニアリングガイドと推奨構成
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
PRのコードレビューをAgentで別セッション実行し、low以下のみなら自動マージする（個人開発向け）
ブランチを切ってプルリクエストを作成する
フィードバックを受け取り、.claude配下のskillや設定を自己改善する
直近1週間のメッセージ/アクティビティを取得・分析してGitHub issueを起票する
| name | prompt-guide |
| description | Claude 4.x 最新プロンプトエンジニアリングガイドと推奨構成 |
| disable-model-invocation | true |
曖昧な指示は避け、具体的に書く。
# Bad
ダッシュボードを作って
# Good
分析ダッシュボードを作成してください。グラフにはRechartsを使い、
日次/週次/月次の切り替えフィルターを含めてください。
Claudeは構造化プロンプトの訓練を受けている。XMLタグで意味を明確にする。
<instructions>やること・振る舞い方</instructions>
<context>背景情報、データ、ドキュメント</context>
<task>このインタラクションでの具体的な依頼</task>
<output_format>期待する出力形式</output_format>
1つの良い例は段落の説明に勝る。入出力ペアを2-3個示す。
<examples>
<example>
<input>ユーザーがログインできない</input>
<output>認証トークンの期限切れが原因です。リフレッシュトークンのフローを確認してください。</output>
</example>
</examples>
複雑な問題ではステップバイステップの推論を促す。 ただし Extended Thinking が有効な場合は「ステップバイステップで考えて」は不要（冗長でトークン浪費）。
あなたは: [役割]
目標: [達成すべきゴール]
制約:
- [制約1]
- [制約2]
不明な場合: 明示的にそう伝え、1つ明確化の質問をする
手動の budget_tokens ではなく、effort パラメータで深さを制御する。
client.messages.create(
model="claude-opus-4-6",
max_tokens=64000,
thinking={"type": "adaptive"},
output_config={"effort": "high"}, # max, high, medium, low
messages=[...],
)
Claude Opus 4.6 以降、最後の assistant ターンでの prefill は非サポート。
代替手段:
前置きなしで直接回答してください。"Here is..." のようなフレーズで始めないでください。Claude 4.x は以前より積極的。過剰な強調は逆効果 (overtriggering)。
# Bad (過剰)
CRITICAL: You MUST ALWAYS use this tool when...
# Good (適切)
このツールは～の場合に使ってください。
<use_parallel_tool_calls>
依存関係のない複数のツール呼び出しは並列で実行してください。
</use_parallel_tool_calls>
Claude Opus 4.6 はサブエージェントを過剰に使う傾向がある。
サブエージェントは以下の場合に使用:
- タスクが並列実行可能
- 独立したコンテキストが必要
- 独立したワークストリーム
単純なタスク、単一ファイル編集、ステップ間のコンテキスト維持が必要な場合は直接作業する。
アクションの可逆性と影響範囲を考慮してください。
ローカルで可逆的なアクション（ファイル編集、テスト実行）は自由に。
破壊的・共有システムへのアクション（ファイル削除、force-push、外部投稿）は確認後に。
アプローチを決めたらコミットしてください。
推論に直接矛盾する新情報がない限り、決定を再考しないでください。
<investigate_before_answering>
開いていないコードを推測しないでください。
ユーザーが特定ファイルを参照した場合、回答前にファイルを必ず読んでください。
根拠のある、ハルシネーションのない回答をしてください。
</investigate_before_answering>
直接要求されたか明らかに必要な変更のみ行う。
依頼されていない機能追加、リファクタリング、「改善」はしない。
仮定の将来要件のための設計はしない。
フロンティアLLMは約150-200の指示を合理的に処理可能。 各行について「これを削除するとClaudeはミスするか？」と自問し、Noなら削除。
~/.claude/CLAUDE.md # 全セッション共通（グローバル）
./CLAUDE.md # プロジェクトルート（git管理、チーム共有）
./CLAUDE.local.md # 個人設定（gitignore）
親ディレクトリ/CLAUDE.md # モノレポ用
子ディレクトリ/CLAUDE.md # オンデマンド読み込み
@ インポートで他ファイル参照プロジェクト概要は @README.md を参照。
npmコマンドは @package.json を確認。
CLAUDE.md を軽量に保つため、ドメイン知識はスキルに分離する。
.claude/skills/
├── skill-name/
│ └── SKILL.md
---
name: skill-name
description: このスキルの説明
disable-model-invocation: true # /skill-name で明示的に呼び出す場合
---
# スキル名
## 手順
1. ...
2. ...
---
name: fix-issue
description: GitHub issue を修正する
disable-model-invocation: true
---
GitHub issue $ARGUMENTS を分析・修正してください。
1. `gh issue view` で issue 詳細を取得
2. コードベースで関連ファイルを検索
3. 変更を実装、テスト作成、検証
4. 説明的なコミットを作成しPRをpush
Hooks は CLAUDE.md の指示（助言的）と違い、例外なく毎回実行される。
| Hook | 用途 |
|---|---|
PostToolUse (Edit) | ファイル編集後の自動フォーマット |
UserPromptSubmit | コンテキスト注入 |
PreCommit | コード品質チェック |
バグ修正のissueに取り組む前に、根本原因がどのレイヤーにあるかを判断する。
判断基準:
- データが不正/不要 → バックエンドで修正（保存・送信をスキップ）
- データは正しいが表示が不正 → フロントエンドで修正
- 迷ったら → ユーザーに確認する
例:
- 「空のlink cardが表示される」→ 空データを保存しないバックエンド修正が正解
（フロントで非表示にするのは対症療法）
- 「日付のフォーマットが間違い」→ フロントエンド修正が正解
# Bad
メールアドレスを検証する関数を実装して
# Good
validateEmail 関数を書いてください。
テストケース: user@example.com → true, invalid → false, user@.com → false
実装後にテストを実行してください。
/clear を実行/compact <instructions> で対象を絞った要約/clear して初期プロンプトを書き直す| パターン | 対策 |
|---|---|
| キッチンシンクセッション（無関係タスクの混在） | タスク間で /clear |
| 何度も修正を繰り返す | 2回失敗後、/clear してプロンプトを書き直す |
| CLAUDE.md の肥大化 | 削除しても問題ないなら削除 |
| 信頼後に検証しない | テスト・スクリプト・スクリーンショットで検証 |
| 無限の探索 | 調査範囲を狭めるかサブエージェントを使う |
| 質問・提案を実装依頼と誤解する | 「〜した方がいい？」「〜はどう？」は意見を返すだけにとどめ、明示的に依頼されるまで実装しない |
| 修正レイヤーを誤る | 表示の問題でもデータの問題なら根本原因（バックエンド）で修正する。実装前に「どのレイヤーで直すべきか」を判断する |
| 複数タスクを同時に依頼されたとき片方を忘れる | 着手前にすべての依頼を「1. ... 2. ...」と箇条書きで確認・列挙する。各タスク完了後に残りのタスクが残っていないかチェックしてから返答する |