Claude Codeのプロンプト指示術｜精度を上げる7つの設計技法

Claude Codeの出力品質は、指示（プロンプト）の設計で決まります。プロンプト設計とは「AIに正しく推測させる」技術ではなく、「推測の余地をなくす」技術です。

「同じことを頼んでいるのに、人によって出てくるコードの質が違う」「一度で意図どおりに動いたことがなく、毎回3回は言い直している」「ベテランは使いこなせているが、新人が使うと手戻りばかり増える」——AIコーディングツールを導入した現場で、こうした声をよく伺います。

Claude Codeのプロンプト設計とは、AIが推測しなければならない余白（対象ファイル・完成状態・禁止事項・検証条件）を、指示の側であらかじめ埋めておく設計手法です。本記事では、その余白を埋める7つのテクニックと、それを個人の腕前ではなくチームの仕組みに落とす方法を、2026年10月時点のClaude Codeの仕様に沿って解説します。

なお、この考え方はコードを書かない業務でも同じように効きます。マーケティング・営業・経理での具体例は非エンジニアがClaude Codeでできることで紹介しています。

この記事でわかること

Claude Codeの出力品質は、モデルの性能よりも指示の設計で大きく変わります。この記事では、初回正答率を上げてやり直しを減らすための7つの実践テクニックを、Before/Afterの具体例とともに解説します。

• なぜプロンプト設計で出力品質が変わるのか — Claude Codeは高度なコード理解力とファイル操作能力を持ちますが、最終的な出力は「推測させた量」に左右されます。推測が外れた分だけやり直しが発生します。
• 全指示で共通する基本テクニック2つ — ゴールファースト（最終状態を先に書く）と制約の明示（やってはいけないことを先に書く）を、悪い例と良い例の対比で解説します。
• タスクに応じて使い分ける実践テクニック3つ — Before/Afterの提示、段階的タスク分解、検証手順の組み込みを、実際の指示文サンプルで示します。
• 個人技を仕組みに変えるCLAUDE.mdとコンテキスト管理 — 毎回書いていたルールをファイルに集約し、チーム全員の出力を同じ水準に揃える方法を解説します。
• AIに任せる範囲と人間が判断すべき範囲の線引き — プロンプトを丁寧に書いても任せるべきでない領域があります。その境界も率直に書いています。

Claude Codeを使い始めたエンジニアの方、そしてチームでの利用品質を標準化したいマネージャーの方に向けて書いています。最後まで読むと、自社のプロジェクトに合わせたプロンプトの型とCLAUDE.mdの初版を、その日のうちに作り始められるようになります。

プロンプト設計がClaude Codeの出力品質を決める理由

Claude Codeは高度なコード理解力とファイル操作能力を持つAIエージェントですが、最終的な出力品質はユーザーの指示に大きく依存します。同じタスクでも、指示の出し方によって結果は大きく変わります。ここでは、なぜ差が生まれるのかを構造で捉えます。

曖昧な指示と具体的な指示は何が違うのか

# 曖昧な指示
ログイン機能を修正して

# 具体的な指示
src/auth/login.ts の handleLogin 関数で、
パスワード入力が空の場合に500エラーが返る問題を修正して。
空文字チェックを追加し、空の場合は400エラーと
「パスワードを入力してください」のメッセージを返すようにして。
修正後に既存のテスト（src/auth/__tests__/login.test.ts）を実行して、
全テストがパスすることを確認して。

曖昧な指示では、Claude Codeは「どのファイルのどの関数を」「どのようなバグを」「どう修正するか」を推測しなければなりません。推測が正しければ結果は良好ですが、推測が外れると意図しない修正が行われ、やり直しが発生します。

「推測の余地」を4つに分解する

手戻りが起きた指示を振り返ると、埋まっていない余白が見つかることが多くあります。指示文は次の4観点で確認できます。

この4つが埋まっていれば、残りのテクニック（段階的分解・CLAUDE.md・コンテキスト最適化）は「埋めた内容をどう効率よく伝え続けるか」の話になります。つまり7つのテクニックは並列の小技ではなく、「余白を埋める4つ」と「それを持続させる3つ」という構造になっています。

指示の質を営業パイプラインの設計と同じように扱う

ここは営業・マーケティングの世界と発想が似ています。パイプライン設計で受注率がぶれる原因の多くは、ステージの定義があいまいで、誰が何をもって「見積もり提示」とみなすかが人によって違うことにあります。ステージごとの定義と必須入力プロパティを決めてしまえば、担当者の経験値に関係なくデータの粒度が揃う場合が多いです。プロンプトも同じで、「何を先に書いておくか」をあらかじめ決めてしまえば、書き手の習熟度に関係なく出力の下限が上がります。

ただし、率直に申し上げると、プロンプトを整えれば何でも解決するわけではありません。仕様そのものが決まっていない、あるいは社内で合意が取れていないタスクは、どれだけ丁寧に書いてもAIの出力は迷います。プロンプト設計は「決まっていることを正確に伝える技術」であって、「決まっていないことを決める技術」ではない、という前提は押さえておきたいところです。

基本テクニック1｜ゴールファーストで最終状態を先に伝える

まず押さえておきたいのは、指示の冒頭に「最終的にどうなっていてほしいか」を書くことです。Claude Codeは指示文を上から順に処理するため、ゴールが先頭にあれば全体の方向性を把握しやすい状態で作業を開始できます。手順から書き始めると、作業はするが目的を外す、という現象が起きます。

手順先行とゴール先行の比較

実際の指示文で比べる

# 悪い例
package.json を開いて eslint-plugin-unused-imports を追加して。
次に ESLint の設定ファイル（eslint.config.js など）を開いて rules に unused-imports/no-unused-imports を追加して。
最後に npm run lint を実行して。

# 良い例
ESLintの設定を更新して、未使用のimport文を自動で検出・削除できる状態にして。
具体的には:
- eslint-plugin-unused-imports を導入
- ESLint の設定ファイル（現行の標準は eslint.config.js。旧形式の .eslintrc を使う既存プロジェクトならそちら）に検出ルールを追加
- npm run lint で動作確認
- 既存コードで検出された未使用importがあれば自動修正

ゴールファーストの指示では、Claude Codeが「未使用import削除」という目的を理解しているため、パッケージの追加だけでなく、設定ファイルの更新、動作確認、既存コードの自動修正まで一貫して実行します。

ゴールが書けないときは、まだ依頼するタイミングではない

ゴールファーストを実践しようとすると、「そもそも完成形を言語化できない」場面に出会います。これは指示の問題ではなく、設計が固まっていないサインです。そういうときは実装を頼むのではなく、「この要件で考えられる実装方針を3案出して、それぞれのトレードオフを比較して」と、選択肢の洗い出しから依頼する形に切り替えます。実装を頼むのか、設計の叩き台を頼むのかを分けるだけでも、手戻りは減らせます。

基本テクニック2｜制約を明示してやってはいけないことを先に伝える

Claude Codeは指示を忠実に実行しますが、「やってはいけないこと」が明示されていなければ、最適解として意図しない操作を行う可能性があります。ゴールファーストが「どこへ向かうか」を決めるものだとすれば、制約の明示は「どこへ踏み込ませないか」を決めるものです。

制約ありの指示文はこう書く

# 制約なし（リスクあり）
データベースのマイグレーションファイルを作成して、
usersテーブルにemail_verified カラムを追加して。

# 制約あり（安全）
データベースのマイグレーションファイルを作成して、
usersテーブルにemail_verified（boolean, default: false）カラムを追加して。

制約:
- 既存のマイグレーションファイルは変更しない
- DROP TABLE / DROP COLUMN は使用しない
- 本番データベースへの直接接続は行わない
- マイグレーションファイルの命名は YYYYMMDD_add_email_verified_to_users.sql

制約を書くべき4つのシーン

制約の明示は、特に以下のシーンで重要です。裏を返せば、ここを書き忘れた指示は、うまくいったとしても運任せだったと考えたほうが安全です。

• データベース操作（破壊的変更の防止）
• 本番環境に関わる設定変更（誤デプロイの防止）
• 既存コードのリファクタリング（意図しない変更の防止）
• APIキーやトークンが関わる操作（情報漏洩の防止）

制約は毎回書くのではなくファイルに寄せる

ここで気づいていただきたいのは、上の4つは「そのタスク固有の制約」ではなく「このプロジェクトでは常に守るべき制約」だという点です。毎回書くのは現実的ではありませんし、書き忘れた人の指示だけリスクが高くなります。だからこそテクニック6のCLAUDE.mdに寄せていくわけですが、これについては後半で詳しく扱います。

ちなみに環境側で操作範囲そのものを制限する方法もあり、Claude Codeのサンドボックス設定で解説しています。プロンプトでの制約と環境での制約は、どちらか一方ではなく両輪で考えるのが現実的です。

実践テクニック｜Before/After提示・段階的分解・検証手順

ここからはタスクの性質に応じて使い分ける3つのテクニックです。基本テクニックが「全指示で共通して使うもの」だとすれば、こちらは「特定の型のタスクで効果が跳ね上がるもの」という位置づけになります。

テクニック3｜Before/Afterで期待する変換パターンを示す

Claude Codeに「こう変えてほしい」ではなく「この入力がこの出力になるべき」と具体例を示すことで、変換パターンを正確に伝えられます。

# 抽象的な指示
全てのAPIレスポンスに統一的なエラーハンドリングを追加して。

# Before/After付きの指示
APIレスポンスのエラーハンドリングを統一して。
以下のBefore/Afterのパターンに従って、src/api/ 配下の全ファイルを修正して。

Before:
try {
  const data = await fetchUser(id);
  return res.json(data);
} catch (error) {
  return res.status(500).json({ message: "Internal Server Error" });
}

After:
try {
  const data = await fetchUser(id);
  return res.json({ success: true, data });
} catch (error) {
  const statusCode = error instanceof AppError ? error.statusCode : 500;
  const message = error instanceof AppError ? error.message : "予期しないエラーが発生しました";
  logger.error({ error, endpoint: "fetchUser", userId: id });
  return res.status(statusCode).json({ success: false, error: { code: statusCode, message } });
}

Before/Afterを1つ示すと、Claude Codeが変換ルール（レスポンス構造の統一、AppError対応、ログ出力の追加）を把握しやすくなり、残りのファイルにも同じパターンを適用しやすくなります。文章で「統一的に」と書くより、実例を1つ置くほうがよく伝わる、というのがこのテクニックの本質です。

テクニック4｜大きなタスクを段階的に分解する

1回の指示で多くのことを依頼すると、後半のタスクほど品質が低下する傾向があります。大きなタスクは段階的に分解し、各段階の完了を確認してから次に進む設計にします。

# 一括指示（品質低下リスクあり）
新しい認証システムを実装して。JWT認証、リフレッシュトークン、
パスワードリセット、メール認証、二要素認証、セッション管理を全部作って。

# 段階的な指示（品質を維持）
認証システムのPhase 1として、JWT認証の基盤を実装して。

Step 1: 認証用のデータベーススキーマ設計
- users テーブルに必要なカラムを追加
- refresh_tokens テーブルを新規作成
- マイグレーションファイルを作成

Step 2: JWT発行・検証ロジック
- src/auth/jwt.ts にトークン生成・検証関数を実装
- アクセストークン有効期限: 15分
- リフレッシュトークン有効期限: 7日

Step 3: 認証ミドルウェア
- src/middleware/auth.ts にJWT検証ミドルウェアを実装
- 認証不要のルートをホワイトリストで管理

Step 4: テスト
- 各関数のユニットテストを作成
- 認証フロー全体のインテグレーションテストを作成
- 全テストがパスすることを確認

Phase 1完了後に、Phase 2（パスワードリセット・メール認証）に進みます。

段階的な分解には3つのメリットがあります。第一に、各ステップの出力品質を個別に確認できます。第二に、問題が発生した場合に該当ステップだけをやり直せます。第三に、Claude Codeのコンテキストウィンドウを有効に使えます。

これはHubSpot導入の進め方とも重なります。いきなり全機能を一気に立ち上げるのではなく、自社で効果が出そうな範囲を見極めて優先順位をつけ、そこから段階的に広げていく考え方です。AIへの指示も、まずはPhase 1の完了基準を決めてから着手するほうが、結果的に早く着地します。

テクニック5｜検証手順を組み込んで完了条件を明確にする

「実装して」で指示を終えると、Claude Codeは実装だけで作業を終了します。検証手順を指示に含めることで、実装後の動作確認までを作業の完了条件にできます。

# 検証なし
ユーザー一覧APIを実装して。

# 検証手順あり
ユーザー一覧API（GET /api/users）を実装して。

実装仕様:
- ページネーション対応（page, limit パラメータ）
- name での部分一致検索（search パラメータ）
- レスポンス形式: { success: true, data: [], pagination: { page, limit, total } }

検証手順（全てパスすること）:
1. npm run test で既存テスト含め全件パス
2. npm run lint でエラー0件
3. curl http://localhost:3000/api/users でレスポンスが返ること
4. curl "http://localhost:3000/api/users?page=1&limit=5" でページネーション動作（URL全体を引用符で囲む）
5. curl -G http://localhost:3000/api/users --data-urlencode "search=田中" で検索が動作
6. 存在しないページ（page=9999）で空配列が返ること（500エラーにならないこと）

検証手順を含めると、Claude Codeは実装後にテスト・lint・curl実行までを手順どおりに進め、結果を報告します。問題が見つかった場合は、修正して再検証するまで進めてくれるケースが多いです。

この「完了条件をあらかじめ決めておく」という考え方は、営業パイプラインのステージ定義と同じです。各ステージの定義を明文化しておけば、誰が担当してもステージの意味がぶれません。検証手順は、AIにとってのステージ定義にあたります。こうしたClaude Codeの活用に関心のある方は、経営データの可視化やコンテンツマーケティングの効率化もぜひご覧ください。

環境設定テクニック｜CLAUDE.mdでプロンプト品質を仕組みにする

ここまでの5つは、書き手が意識して実践するテクニックでした。ただ、意識に頼る仕組みは属人化しやすいものです。CLAUDE.md はプロジェクトルートに配置する設定ファイルで、Claude Codeがセッション開始時に自動で読み込みます（2026年10月時点。AGENTS.md がある場合は、CLAUDE.md の代わりにそちらも読めます）。プロジェクト固有のルール・規約・コンテキストをここに記述しておけば、毎回の指示で繰り返し書く必要がなくなります。

なお、手順書のように特定の作業でだけ使う指示は、常時読み込まれるCLAUDE.mdではなく、スキル（SKILL.md）に切り出すのが向いています。スキルの本文は使うときにだけ読み込まれるため、普段のコンテキストを消費しません。また、/memory から使えるauto memoryは、作業中に分かった内容をClaude Code自身が自動で保存する機能です。チームで揃えたい規約は、Gitで共有できるCLAUDE.mdに明文化しておくと、保存先が人ごとに分かれずに済みます。

CLAUDE.mdに書くべき内容

# プロジェクト概要
ECサイトのバックエンドAPI。Next.js App Router + Prisma + PostgreSQL。

# コーディング規約
- TypeScript strict mode必須
- 関数はアロー関数で統一
- コメントは日本語で記述
- エラーハンドリングはAppErrorクラスを使用

# ディレクトリ構造
- src/app/api/ — APIルート
- src/lib/ — ユーティリティ関数
- src/services/ — ビジネスロジック
- src/repositories/ — データベースアクセス
- prisma/schema.prisma — DBスキーマ

# テストルール
- テストファイルは __tests__/ ディレクトリに配置
- テストフレームワーク: Vitest
- テスト名は日本語で「〜すべき」形式

# やってはいけないこと
- prisma/schema.prisma の既存モデルの変更（新規追加のみ）
- .env ファイルの変更・コミット
- node_modules/ 配下のファイル操作

CLAUDE.mdがあると何が変わるか

CLAUDE.mdを設定することで、2026年10月時点のClaude Codeでは以下の変化が生まれます。注目していただきたいのは、個人の出力が上がるだけでなく、チーム間の品質差が縮まる点です。

「うまい人のプロンプト」を資産に変える運用

私たちがおすすめしているのは、手戻りが起きた指示と、一発で通った指示の両方をチームで共有し、後者に共通していた要素をCLAUDE.mdに昇格させていく運用です。うまい人のコツが本人の頭の中にあるうちは、その人が抜けた瞬間に品質が落ちます。ファイルに書き出してGitで管理すれば、新しく参加したメンバーもその日から同じ前提で作業できます。

ここが「個人の力量で解決する」のか「仕組みで解決する」のかの分かれ目です。プロンプトのうまさを教育で底上げしようとすると時間がかかりますが、制約と規約をファイルに寄せてしまえば、下限を揃えやすくなります。人に依存せず仕組みで担保する、という考え方はHubSpotの必須入力プロパティ設計とも共通しています。

ただし、CLAUDE.mdは長ければよいものではありません。プロジェクトと関係が薄いルールを大量に書くと、それ自体がコンテキストを消費し、肝心の指示が埋もれます。まずは「禁止事項」と「ディレクトリ構造」の2ブロックだけから始めて、チームで手戻りが出た箇所を都度追記していく形が、無理なく続けやすいと思います。項目は少ないほうが、書き手もAIも集中できます。

CLAUDE.mdの設計パターンについては「Claude CodeのCLAUDE.md設計パターン」で詳しく解説しています。

コンテキストウィンドウの最適化｜情報量を絞って精度を保つ

Claude Codeには処理できる情報量の上限（コンテキストウィンドウ）があります。コンテキストが増えすぎると、指示の重要な部分を見落とすリスクが高まります。ここまでの6つを実践していても、セッションが長引けば精度は落ちます。最後のテクニックは、その劣化を防ぐための運用です。

/compact コマンドで会話を圧縮する

長時間の作業セッションではコンテキストが肥大化します。/compact コマンドを実行すると、それまでの会話を要約して圧縮し、コンテキストの空き容量を確保できます。

# セッション中にコンテキストが肥大化したら
/compact

# 特定のテーマに焦点を絞って圧縮
/compact 認証機能の実装に集中してコンテキストを整理して

コンテキスト管理の詳細は「Claude Codeのメモリとコンテキスト管理」をご覧ください。

不要なMCPサーバーを無効化する

使用していないMCPサーバーが有効になっていると、そのサーバーのツール定義がコンテキストを消費します。作業に不要なMCPサーバーは /mcp disable で無効化してください（2026年10月時点の公式コマンドは /mcp [reconnect|enable|disable [|all]] です）。

# 今はSlack連携が不要な場合
/mcp disable slack

# 必要になったら再度有効化
/mcp enable slack

サーバーを新しく追加するときは、HTTP接続が推奨です（claude mcp add --transport http <名前> ）。SSE接続は非推奨で、HTTPに対応していないサービスにだけ使います。チームで共有するサーバーは、プロジェクトルートの .mcp.json に書いてGitで管理できます。なお、v2.1.299 以降は許可ルール mcp__a が別のサーバー a__b には一致しなくなったため、サーバー全体を許可するときは mcp__<サーバー名>__* と書きます。

上の画面は、ここまでで扱った /compact と MCPサーバーの有効・無効を切り替えるコマンドを、実際のターミナルに並べたものです。先頭行はバージョン確認の実出力で、それ以外はコマンドの入力形のみを示しています。

以下の画面は、ターミナルで /compact・/mcp disable・/mcp enable などのスラッシュコマンドを並べた画面です。

ファイル参照を絞り込む

Claude Codeに「全ファイルを確認して」と指示すると、大量のファイル内容がコンテキストに読み込まれ、重要な指示が埋もれます。対象ファイルを明示的に絞り込みましょう。

# 悪い例（コンテキスト消費大）
プロジェクト全体のコードを確認して、パフォーマンス問題を探して。

# 良い例（コンテキスト消費小）
src/services/orderService.ts の calculateTotal 関数が遅い問題を調査して。
N+1クエリが発生していないか、src/repositories/orderRepository.ts と
合わせて確認して。

ここでも、必要な情報だけを絞るという考え方が効いてきます。管理項目を増やしすぎたSFAが結局一部しか使われなくなるのと同じで、参照させる情報を絞ったほうが、AIは目の前のタスクに集中します。

7つのテクニックの使い分けと、AIに任せない領域

7つを一度に完璧にやろうとすると続きません。優先度をつけて、必須のものから習慣にしていくのが現実的です。あわせて、プロンプトを丁寧に書いても人間が判断すべき領域についても率直に書いておきます。

使い分け早見表

テクニック1（ゴールファースト）、2（制約の明示）、6（CLAUDE.md連携）は全ての作業で適用すべき基本テクニックです。テクニック3〜5はタスクの性質に応じて使い分けます。テクニック7は、セッションが長引いたときやプロジェクト規模が大きいときに意識してください。

AIが得意なこと／人間が判断すべきこと

プロンプト設計の目的は、AIに全部を任せることではありません。任せる範囲と、人間が握り続ける範囲を分けることです。

向かないケースも正直に書いておきます

プロンプト設計が効きにくい場面もあります。仕様が固まっていないタスク、関係者間で判断基準が割れているタスク、そして影響範囲が本番データに直結するタスクです。こうした場面では、指示を磨くより先に、人間側で決めるべきことを決める必要があります。

また、企業様によって最適な形は異なります。プロダクト開発のチームと、社内業務の自動化を進めるチームでは、CLAUDE.mdに書くべきルールも、検証手順の粒度もまったく違います。本記事の型はあくまで出発点として、自社のプロジェクト特性に合わせて調整していただくのがよいと思います。

プロンプト設計を業務全体の仕組みに接続する

最後に、開発現場の外へ視野を広げます。プロンプト設計は「AIに正確な指示を出す」という普遍的なスキルなので、Claude Codeに閉じた話ではありません。私たち自身も、HubSpotの運用設計やコンテンツ制作の場面で同じ考え方を使っています。

スプレッドシート運用と同じ問題がプロンプトでも起きる

営業やマーケティングの現場でよくあるのが、スプレッドシートで案件や顧客リストを管理していて、担当者ごとに入力粒度が違い、集計のたびに整形作業が発生するという状態です。プロンプトも放っておけば同じことが起きます。人によって書き方が違い、出力の品質がばらつき、レビュー側の負担が増えていきます。

解決の方向は共通していて、「入力のルールを人の記憶ではなく仕組みに持たせる」ことです。CRMなら必須入力プロパティ、Claude CodeならCLAUDE.md。どちらも、誰が担当しても一定の品質が出る状態をつくるための装置です。

HubSpot側のAI活用にも同じ原則が効く

HubSpotのワークフロー内でBreezeを使ってフォーム送信内容を分類したり、レコードの要約を生成したりする場面でも、指示の書き方で精度が変わります。英語ベースのプロダクトなので、日本語のビジネスマナーや敬体の指定をプロンプトで明示しておくほうが、出力が実務で使いやすくなるケースがあります。

そして、ここでもAIと人間の役割分担は同じです。分類・要約・下書きはAIに任せ、送信判断やビジネスルールの定義は人間が持つ。自律的に送信まで完結させる設定は、便利ではあるものの、内容を確認してから送る運用のほうが安全だと考えています。

全体フローのどこにAIを置くかを決める

コンタクト獲得から取引化、受注、請求までの一連の流れの中で、AIに任せる工程はどこか。Claude Codeであれば、レポート生成やデータ整形、定型的な実装といった「ルールが明文化できる工程」が向いています。一方で、パイプラインの設計やライフサイクルステージの定義といった、事業理解が前提になる工程は人間の仕事のままです。

この線引きを最初に決めておくと、プロンプト設計の対象が絞れます。全部をAI化しようとして疲弊するのではなく、まずは1工程から仕組みに落として、うまくいったら隣の工程へ広げる。この進め方は、無理なく広げていきやすい順番だと考えています。

よくある質問

Q1: プロンプトを詳しく書くと、かえってClaude Codeの動作が遅くなりませんか？

プロンプトが長くなると、入力トークンが増える分だけ処理の負荷は増えます。Anthropicの公式ドキュメントでも、遅延を減らす方法として入力と出力のトークン数を抑えることが挙げられています。一方で、具体的な指示を書くと「推測→試行→修正」の手戻りが減るため、やり取り全体で見た作業時間は短くなることが多く、これは1回あたりの処理時間とは別の話です。不必要に冗長な説明（同じことを何度も繰り返す、関係ない背景情報を大量に書くなど）はコンテキストを消費し処理も重くするため、簡潔かつ具体的に書くことを心がけてください。

Q2: CLAUDE.mdはチームメンバー全員が同じ内容を使うべきですか？

はい、CLAUDE.mdはプロジェクトルートに配置してGitリポジトリにコミットすることが推奨されます。チーム全員が同じルール・規約・制約条件のもとでClaude Codeを使用できるため、出力品質のばらつきを抑制できます。個人固有の設定は ~/.claude/CLAUDE.md（グローバル設定）に書くことで、プロジェクトの共通ルールと個人の好みを分離できます。

Q3: プロンプト設計のスキルはClaude Code以外のAIツールにも応用できますか？

応用できます。本記事で解説した7つのテクニックは、「AIに正確な指示を出す」という普遍的なスキルに基づいています。ゴールファースト、制約の明示、Before/Afterの提示、段階的タスク分解、検証手順の組み込みは、GitHub Copilot、Cursor、ChatGPT、Geminiなど、あらゆるAIツールに対して有効です。CLAUDE.md連携はClaude Code固有の機能ですが、他のツールでも同様の設定ファイル（.cursorrules、copilot-instructions.md など）が用意されています。

Q4: 7つ全部を一度に導入すべきでしょうか？

一度に全部を回そうとすると続かないことが多いです。まずはゴールファーストと制約の明示の2つだけを、全員が共通して書く項目として決めるところから始めるのがおすすめです。この2つが習慣になった段階で、繰り返し書いている内容をCLAUDE.mdに移し、その後にBefore/After提示や検証手順を必要なタスクで足していく、という順番が無理なく定着します。

Q5: プロンプトを整えても期待した結果が出ない場合、どこを疑うべきですか？

まず疑っていただきたいのは、完成状態・禁止事項・変換ルール・完了条件の4つのうち、どれが埋まっていなかったかです。この4つがすべて埋まっているのに結果がぶれる場合は、コンテキストの肥大化か、そもそも仕様が固まっていないかのどちらかであることが多いです。前者なら /compact やファイル参照の絞り込みで改善しますが、後者はAI側の問題ではないため、人間側で判断基準を決めるのが先になります。

まとめ

Claude Codeのプロンプト設計は、AIの性能を引き出すうえで取り組みやすく、効果の見えやすい打ち手です。本記事の要点をまとめます。

• プロンプト設計とは推測の余地をなくす技術 — 完成状態・禁止事項・変換ルール・完了条件の4つの余白を、指示の側で埋めておく
• 必須は3つ（ゴールファースト・制約の明示・CLAUDE.md連携） — 残りの4つはタスクの性質とセッションの長さに応じて使い分ける
• 個人技ではなく仕組みに落とす — うまい人のプロンプトの共通項をCLAUDE.mdに昇格させ、Gitで共有することで、新しいメンバーでも同じ前提で作業できる
• AIと人間の役割を分ける — ルールが明文化できる工程はAIに、設計判断と本番影響のある承認は人間に
• 自社に合わせて調整する — プロダクト開発と社内業務自動化では、書くべきルールも検証の粒度も異なる

まずはゴールファーストと制約の明示の2つから始めて、慣れてきたらCLAUDE.mdへの集約、Before/After提示や検証手順へと段階的に広げていく、という進め方をおすすめします。次の行動は3ステップです。

1. 直近で手戻りが発生した指示を1つ選び、「完成状態」「禁止事項」「完了条件」のどれが書かれていなかったかを確認する
2. 書かれていなかった項目を補った指示文を作り直し、同じタスクで再実行して結果を比べる
3. 繰り返し書いている制約とディレクトリ構造だけを抜き出し、CLAUDE.mdの初版としてリポジトリにコミットする

より網羅的なコマンド活用はClaude Codeチートシートを参照してください。

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• Claude Codeのサンドボックス設定｜ファイルシステム・ネットワークの安全な制限方法
• Claude Codeでプロジェクト管理を効率化する方法｜CLAUDE.md・タスク分割・進捗管理の実践
• Claude Codeのステータスライン設定｜レートリミット・コンテキスト使用率をリアルタイム表示する方法