Claude Code プロンプトの基本原則。短く・具体的に・段階的に
Claude Code を使い始めて少し慣れた頃、必ずぶつかる壁があります——「うまく当たらない」プロンプト。難しい言い回しを覚えるのではなく、3つの原則を押さえれば、当たる確率はぐっと上がります。基本原則と一発で当たる型を、修正例とともに整理しました。
はじめに
Claude Code を使い始めて少し慣れてくると、たいていこんな経験をします。
依頼を投げた。返ってきた。なんか違う。 もう一度書き直す。返ってきた。やっぱり違う。 3回くらい往復して、ようやく当たり始める——。
私自身、最初の頃はこの往復が10回を超えていた依頼もありました。「やっぱり AI に細かいことを伝えるのは難しい」と諦めかけたとき、ふと気づきました。問題は AI ではなく、自分の依頼の書き方 だったんです。
プロンプトは、難しい呪文を覚える必要はありません。3つの原則を押さえるだけで、一発で当たる確率がぐっと上がります。この記事では、その原則と、一発で当たるプロンプトの「型」、そしてプロンプトを育てる感覚までを通しで整理します。
3つの基本原則
原則1：短く書く
プロンプトは長く書くほど効くと思いがちですが、実際は逆です。1つの依頼につき1つの目的に絞ったほうが、当たる確率は上がります。
❌「ヘッダーのデザインを直して、ついでにナビの並び順も変えて、フォントもちょっと考え直したい」 ✅「ヘッダーのナビのフォントを、Noto Sans JP の 14px に変えて」
長いプロンプトは、Claude が 「どれを優先するか」で迷います。短く・1依頼1目的にすると、迷わせる余地が消えて、結果が安定します。
原則2：具体的に書く
抽象的な動詞は効きません。「整理して」「キレイにして」「使いやすくして」——これらは、人によって解釈が違います。
❌「コードをキレイにして」
✅「useEffect の依存配列が空になっている箇所を全部探して、依存している変数を入れて」
「動詞＋目的語＋判断基準」のセットで書くと、Claude が判断できる材料が揃います。
原則3：段階的に分ける
大きな依頼を1回で投げると、ほぼ失敗します。Claude のコンテキスト（一度に扱える情報量）にも、人間の理解にも、上限があるからです。
❌「サイトをリニューアルして」
✅「まず src/pages/index.astro のヒーローセクションだけ、見出しを 1段階大きくして、写真を右に寄せて」
「最初の1ステップだけ」を渡し、できたら次の1ステップを渡す。少しずつ、確実に進めるほうが、最終的に早い のは、人間に頼むのと同じです。
ありがちな失敗と修正例（5つ）
実際に往復が増える失敗パターンを5つ紹介します。
失敗1：曖昧な動詞
❌「いい感じにして」 ✅「行間を 1.6 → 1.75 に広げて、見出しの上下マージンを 16px → 24px にして」
失敗2：複数依頼の混在
❌「ヘッダーを直しつつ、フッターも整理して、CSSもまとめて」 ✅「①ヘッダーのナビ順を変える、②フッターのリンク数を5→4に減らす、③CSS の整理は別途お願い——まず①からお願い」
失敗3：前提の省略
❌「このコンポーネント、Tailwind に書き換えて」
✅「このコンポーネント、src/components/Hero.astro を、Tailwind に書き換えて。Tailwind v3 を使っていて、設定は tailwind.config.mjs にある」
失敗4：抽象的な要望
❌「もっと現代的なデザインにして」
✅「角丸を 8px → 16px に変える、シャドウを 0 1px 2px rgba(0,0,0,.05) に置き換える、配色を #333 → #1a1a1a に寄せる」
失敗5：成果物の形式が指定されていない
❌「このデータを集計して」 ✅「このデータを集計して、Markdown のテーブル形式で、列は『日付・閲覧数・流入元』の3つにまとめて」
before/after を見比べると、修正後はすべて「具体・1依頼・短文」になっている のがわかります。3つの原則が、ちゃんと効いています。
一発で当たるプロンプトの型
複雑な依頼でも、4ブロック構造で書けばだいたい当たります。
【Goal】何を実現したいか
【Context】前提（プロジェクト・既存コード・参考資料）
【Constraints】守ってほしい制約（言語・ライブラリ・避けたいパターン）
【Format】成果物の形式（コード・Markdown・JSON 等）実例で見てみます。
【Goal】記事一覧ページのカードに「公開日」を追加したい
【Context】
- src/pages/posts/index.astro の <ArticleCard> を使っている
- pubDate は frontmatter に ISO 文字列で入っている
- フォーマットは「2026.04.30」のドット区切りで揃えたい
【Constraints】
- 既存のレイアウトは崩さない
- 日付の表示位置はカードの右下
- グローバルCSSの色変数 var(--ink-3) を使う
【Format】
- ArticleCard.astro と関連ファイルの差分のみここまで書ければ、ほぼ1往復で完結します。プロンプトを書く時間が増えても、往復が減るほうが結果的に速い——これが基本原則の効果です。
プロンプトを育てる感覚
何度も同じプロンプトを書いていることに気づいたら、それは 昇格のタイミング です。
| 頻度 | 昇格先 | 理由 |
|---|---|---|
| 月1回程度 | そのままでOK | 都度書いてもコストが低い |
| 週1回以上 | スラッシュコマンド化 | /<コマンド名> で1発呼び出し |
| 案件ごとに毎日 | CLAUDE.md に書く | 起動時に自動で読まれる前提情報に |
| プロジェクト横断 | Skill として独立化 | 複数プロジェクトで再利用できる |
プロンプトは「書き捨て」ではなく、残してメンテすると毎日の操作がどんどん軽くなる資産 です。書きながら「これ、また書きそうだな」と感じたら、その瞬間が育てどきです。
投げる前のチェックリスト
依頼を投げる前、こんな問いで点検しています。
- 1依頼1目的に絞れているか
- 動詞は具体的か（曖昧な形容詞を使っていないか）
- 大きすぎないか（最初の1ステップに絞れているか）
- 前提は省略していないか（ファイル名・既存設定・使っているライブラリ）
- 成果物の形式は決まっているか（コード・Markdown・差分・JSON 等）
- 「やらないでほしいこと」があるなら明示しているか
ここが揃っていれば、たいていのプロンプトは1回で当たります。
まとめと次回
プロンプトの基本原則は、短く・具体的に・段階的に——この3つを徹底するだけです。難しい呪文を覚える必要はありません。3つを意識して、4ブロック構造を試して、何度も書くものは育てていく。これだけで、毎日の操作がぐっと軽くなります。
次回は、スタイルガイドの作り方 を扱います。プロンプトは「単発の依頼」ですが、スタイルガイドは「特定タスクを毎回同じ品質で頼むための、ルール集」です。プロンプト基本原則の応用編として、ぜひ読んでみてください。
WordPressを実際に動かしてきたサーバー：ロリポップ
Claude Code でWordPressサイトを組み立てるとき、最初に置く先として無理のないレンタルサーバー。月数百円から始められ、WordPressの自動インストールにも対応しています。設定で詰まりがちな初期段階の時間をかなり減らせます。