Claude Codeプロンプト設計の実践テンプレート集

Claude Codeに「テストを書いて」と指示して、期待通りの出力が返ってこなかった経験はないでしょうか。AIコーディングエージェントの出力品質は、プロンプトの設計で決まります。本記事では、私が実務で構築した3層構造のプロンプト設計テンプレートを、具体的なコード例とともに公開します。

なぜ「漠然とした指示」では失敗するのか

2026年現在、Claude Codeは開発者の46%が「最も気に入っているツール」に挙げるほど普及しました。しかし、ツールの性能が上がっても「AIに漠然と記事を書かせると99%失敗する」という現実は変わりません。

「ブログ記事を書いて」「このコードを改善して」といった曖昧な指示では、AIは一般的で表面的な出力しか返せません。これは人間の部下に「いい感じにやっといて」と丸投げするのと同じです。

私自身、Claude Codeを業務に本格導入した当初は、この壁にぶつかりました。記事執筆、コード生成、提案資料の作成――どれも一発で実用レベルの出力が得られません。試行錯誤の末にたどり着いたのが、プロンプトを「3層構造」で設計・管理する方法です。

プロンプト制御の3層構造

Claude Codeのプロンプト設計には、3つの制御レイヤーがあります。

本質は「制限することで本質的な価値を高めること」にあります。レースカーに例えるなら、Claude Codeは強大なエンジンです。しかしエンジンだけでは走れません。躯体（CLAUDE.md）を作り、ハンドル（Skills）で操り、ブレーキ（Hooks）で制御する必要があります。

第1層: CLAUDE.md + Rules（ガイドライン層）

CLAUDE.mdはプロジェクトのルートに置く設定ファイルで、Claude Codeが全セッションで自動的に読み込みます。プロジェクトの方針、禁止事項、表記ルールなどを記載します。

ただし、ここで重要なのは書き込みすぎないことです。コンテキスト長に関する研究によれば、入力テキストの長さが増えるだけでLLMの推論精度は低下します。関連情報を正しく抽出できていても、コンテキストが長いだけで誤った回答に至るケースが確認されています。

私のCLAUDE.mdは「各行について、これを削除したらClaudeがミスをするか？」を基準に絞り込んでいます。全セッションで必要な情報だけをCLAUDE.mdに書き、それ以外はrules/ディレクトリに分離します。

# 実際の構成例
.claude/
├── rules/
│   ├── article-writing.md   # 記事執筆ルール（全セッション自動ロード）
│   ├── coding.md             # コーディング規約
│   └── business-context.md   # サービス体系・料金
└── skill-components/          # 必要時のみRead（自動ロードしない）
    ├── writing/
    │   ├── seo.md
    │   ├── x.md
    │   └── note.md
    └── image/
        └── diagram.md

rules/は全セッションで自動ロードされますが、skill-components/は必要時にのみReadされます。この2層分離によって、常時のコンテキスト消費を最小限に抑えながら、必要な時には詳細な指示を参照できます。

第2層: Skills + Commands（ワークフロー層）

Skillsは、特定のワークフローを定義するマークダウンファイルです。.claude/skills/に配置すると、スラッシュコマンドとして呼び出せます。

2026年初頭時点で、Skills（Agent Skills標準）はOpenAI Codex、Google Gemini CLI、Cursor、JetBrains Junieなど30以上のエージェント製品で採用されています。Claude Code固有の機能ではなく、業界標準のワークフロー定義形式です。

私のスキル活用法は、ゼロから自作するだけではありません。GitHubでスター数が多い人気スキルを収集し、中身を読んで理解した上で、自分のワークフローに合うよう改良して使うのが主な方法です。車輪の再発明を避けつつ、自社の業務に最適化できます。

第3層: Hooks（強制監視層）

Hooksは、Claude Codeのライフサイクルの特定タイミングで自動的にシェルコマンドを実行する仕組みです。ここが3層構造の要になります。

CLAUDE.mdやSkillsは「こうしてほしい」という依頼であり、LLMが従わない可能性があります。一方、Hooksは確定的な制御です。コミット前のリンター実行、ファイル変更時のテスト実行など、LLMの判断に依存しない品質保証ができます。

私の場合、メール・提案資料・記事執筆など公に公開するアウトプットでは、Hooksで公開前に強制的にチェックリスト照合と最終校正を実行しています。「ルールを書いたのに守られない」という問題を、仕組みで解決するアプローチです。

スキルのコンポーネント化設計

2026年4月に私が実装したのが、スキルのコンポーネント化設計です。これはReactのコンポーネント設計と同じ思想で、同じインプットから複数のアウトプットを書き分ける仕組みになっています。

具体的には、実績データベースやAI開発ツール知見データベースといった共通のインプットを用意し、そこからSEO記事・X Article・note記事・提案資料PDFと、プラットフォームごとに最適化された形式で出力します。

この設計の利点は3つあります。

一次情報の一元管理: 実績や知見を1箇所に蓄積すれば、すべてのアウトプットに反映されます
プラットフォーム最適化: SEOは5,000字HTML、Xは2,000字の実体験重視、noteは3,000字の読み物調と、読者層に合わせた変換ができます
保守性の向上: 共通コンポーネント（writing/seo.md等）を修正すれば、すべてのスキルに反映されます

具体的なプロンプト指示の出し方

3層構造を整備しても、日常的な指示の出し方が曖昧では意味がありません。ここでは、よくある業務シーンごとのテンプレートを紹介します。

テスト作成の指示例

# NG: 曖昧
「テストを書いて」

# OK: 制約と文脈を明示
「Jest + React Testing Libraryで、UserLoginFormコンポーネントの
結合テストを作成。以下をカバーすること:
- 正常系: メール/パスワード入力 → ログイン成功 → リダイレクト
- 異常系: 空欄送信時のバリデーションエラー表示
- 異常系: API 401レスポンス時のエラーメッセージ表示
モックはMSWを使用。既存テストは src/__tests__/ を参照」

記事執筆の指示例

# NG: 丸投げ
「AIの業務活用について記事を書いて」

# OK: ハーネスの整備 × 一次情報の指定
「/fyve-seo-article を実行。
テーマ: 中小企業のAI導入における失敗パターン
一次情報: data/実績・経験データベース.md の介護施設A社の事例を使用
キーワード: 中小企業 AI導入 失敗
主張: 現場ヒアリングなしの導入は100%失敗する」

コードリファクタリングの指示例

# NG: 方向性が不明
「このコードを改善して」

# OK: 改善の基準を明示
「src/app/services/page.tsx をリファクタリング。
改善基準:
- サーバーコンポーネントをデフォルトにし、useState/useEffectがある
  部分のみ別ファイルでuse client化
- 繰り返しているカード表示をServiceCardコンポーネントに抽出
- 型定義をtypes.tsに分離
既存のCSS（_shared/lp.css）のクラス名は変更しないこと」