プロンプトエンジニアリングの基本 ― 質の高い出力を引き出す5原則と設計テンプレート

「同じClaude CodeやCursorを使っているのに、隣の同僚はサクッと使いこなしているのに自分は全然うまく使えない」 ― 現場エンジニアから頻繁に聞く悩みだ。同じツール、同じモデル、同じプロジェクトでも、出力の質に大きな差が出る。その差の正体は、ほぼ100%プロンプトエンジニアリングにある。「ECサイトのカート機能を作って」という一行と、技術スタック・要件・出力形式・制約まで明示した構造化プロンプトでは、返ってくるコードの質が桁違いに違う。本稿では、AIDDの土台となるプロンプト設計の5原則、悪いプロンプトと良いプロンプトの違い、6つの基本テクニック、構造テンプレート、ありがちな失敗パターン、プロンプト資産化と上達ステップまでを整理する。明日から実務で使える形でまとめた。

要点：プロンプトは「お願い」ではなく「設計仕様書」。明確性・具体性・構造化・文脈・検証可能性の5原則を揃え、テンプレート化して組織の資産にすることで、AIDDの再現性が一気に上がる。

1. プロンプトの良し悪しを決める5原則

プロンプトの質を決めるのは5原則だ。明確性は「何をしてほしいか」を曖昧にしないこと。具体性は期待する出力の例を示すこと。構造化は情報を整理して渡すこと。文脈は前提条件を漏らさないこと。検証可能性は良い／悪いを判定できる基準を含めること。これら5つは独立ではなく相互に補完する。「明確に書いたが具体例がない」「具体例はあるが構造化されていない」といった片寄りがあると、出力品質はすぐ頭打ちになる。5原則すべてを満たすプロンプト設計を、まず自分の習慣にすることが、AIDDの第一歩になる。

💡 ポイント：5原則を1枚チェックリストにしてプロンプト送信前に必ず確認するだけで、出力品質が体感で2〜3割上がる。慣れれば10秒で確認できる。

2. 悪いプロンプト ― 「ECサイトのカート機能を作って」が破綻する理由

「ECサイトのカート機能を作って」という一行プロンプトは、典型的に失敗する。言語・FWが不明、データ構造が不明、商品マスタの仕様不明、ユーザー認証の有無不明、テストの要否不明 ― あらゆる前提が欠けている。AIは平均的な答えしか返せず、出てくるコードは現場で使えない。これは「AIの能力不足」ではなく「プロンプト設計の責任」だ。エンジニアの世界で「曖昧な要件で発注された案件は失敗する」のと全く同じ構造で、AIへの依頼も同じ法則が働く。

⚠️ 注意：「とりあえず投げて反応を見る」プロンプト習慣は、レビュー時間を大幅に増やし、結果的に生産性を下げる。最初に5〜10分使ってプロンプトを構造化するほうが圧倒的に速い。

3. 良いプロンプト ― 構造化された設計仕様書としての書き方

良いプロンプトは設計仕様書の体裁を持つ。コンテキストとして言語（TypeScript）・フレームワーク（Next.js 14 App Router）・DB（PostgreSQL/Prisma）・認証（next-auth）を明示し、タスクを「ECサイトのカート機能を実装する」と1行で述べ、要件として商品IDと数量保存・ログインユーザー単位で永続化・数量変更削除全削除対応・在庫超過チェック付きを列挙する。出力形式（API Route Handler、Prismaスキーマ、Vitestテスト）と制約（TypeScript strict mode、ProblemDetails形式エラー）も明示する。これだけ揃えると、AIは「現場で使える」コードを出してくる。

📊 経営判断のコツ：プロンプトテンプレートを社内Wikiで共有するだけで、新人エンジニアが半年でシニア相当の出力を出せるようになる。育成投資として極めて費用対効果が高い。

4. 6つの基本テクニック ― ロール・ステップ・例示

プロンプトの質を高める基本テクニックは6つ。ロール指定は「あなたは10年経験のあるバックエンドエンジニアです」のように立場を与える。ステップ指定は「1.仕様要約 → 2.設計案3つ提示 → 3.ベスト1つを選び実装」のように進行を分割する。Few-shot（例示）は「入力X→出力Y」の例を示す。制約の明示は「外部APIは呼ばない」「日本語コメント」のような禁則を伝える。出力フォーマット指定はMarkdownのセクション構成を指定する。自己批評の指示は「最後に弱点を3つ自己批評してください」と入れる。これら6つを組み合わせることで、出力品質が安定する。

💡 ポイント：6テクニックすべてを毎回使う必要はない。タスクの複雑度に応じて2〜4個を組み合わせるのが現実的。慣れてくれば自然に適切な組み合わせが選べる。

5. プロンプト構造テンプレート ― 実務で使える型

実務で繰り返し使えるテンプレートを定義しておくと再現性が上がる。コンテキスト（プロジェクト概要・使う技術・既存資産）、タスク（1行で）、要件（機能要件・非機能要件）、出力形式（ファイル構成・形式）、制約（やってはいけないこと・守るべきルール）、受け入れ条件（クリア基準）の6セクション構成が標準形だ。これをチームで標準化し、Slackやリポジトリにテンプレートを置いておくと、誰でも一定品質のプロンプトを書けるようになる。「プロンプトをコピペで構造化する」習慣が定着すると、レビュー時間が大幅に減る。

⚠️ 注意：テンプレートは「使い回し前提」だが、毎回コンテキストだけは現場固有に書き換える。テンプレートのコピペで満足してコンテキスト省略すると、出力が一気に薄くなる。

6. ありがちな失敗パターン4選

頻発する失敗パターンは4つ。失敗1：仕様の後出しは「忘れてた、〇〇も対応して」とやり直す羽目になる。最初に網羅するのが鉄則。失敗2：抽象的な形容詞は「シンプルで美しいコード」のような曖昧表現で、定義は人によって違う。具体的な基準を示す。失敗3：複数タスクの混在は「APIとUIとテスト全部一気に」で出力品質が下がる。1プロンプト1タスクが基本。失敗4：コンテキスト不足は「このバグを直して」とコードもエラーも添えない状態。AIは推測するしかない。これら4パターンを避けるだけで、プロンプトの精度は劇的に上がる。

📊 経営判断のコツ：失敗パターンを社内勉強会で共有することで、組織全体のプロンプト品質が上がる。「失敗事例集」をWikiに蓄積する文化が、暗黙知を組織知に変える。

7. プロンプトを資産化する ― リポジトリと規約ファイルへの統合

優れたプロンプトはチームの資産だ。プロンプト管理の方法は3層で組む。リポジトリ内の .prompts/ ディレクトリで案件固有のプロンプトを管理、CLAUDE.md / .cursorrulesにプロジェクト規約として共通プロンプトを記述、社内Wikiで業務横断のベストプロンプトを共有する。評価指標は出力の再現性、レビュー後の修正回数、チームメンバーの利用頻度の3つ。これら指標を追跡することで、プロンプト改善のサイクルが回る。「個人のスキル」から「組織の資産」へとプロンプトの位置づけを上げることが、AIDD成熟度を上げる鍵になる。

💡 ポイント：プロンプトを「個人のメモ」のままにしておくのが最大の機会損失。Gitリポジトリに置くだけで、レビュー・改善・継承が可能になる。

8. プロンプトエンジニアリングの上達5ステップ

上達は5ステップで進む。Step 1は良いプロンプトと悪いプロンプトの差を体感する。同じタスクを違うプロンプトで投げて結果を比較するのが最速の学習法だ。Step 2はテンプレート化して使い回す。Step 3は自分用ベストプロンプト集を作る。Step 4はチームで共有・改善する。Step 5はプロジェクト規約に組み込む。多くのエンジニアはStep 1〜2で止まり、Step 3〜5に進めない。組織として上達させるには、Step 4〜5への移行を意識的に支援する施策が必要だ。社内勉強会・プロンプトレビュー会・規約整備プロジェクトなどが具体策になる。

⚠️ 注意：「個人で上達する」ではなく「組織として上達する」設計が重要。個人スキルだけ高くても、属人化リスクが残る。

9. プロンプトエンジニアリング廃れる説への反論

「プロンプトエンジニアリングは廃れる」という言説が一部にあるが、現場感覚とはズレている。確かにUIが洗練されるほど、初歩的なプロンプト技術の重要度は下がる。しかし、コンテキスト設計（何を渡すか）の重要度は逆に上がり続けている。プロンプトとコンテキストは表裏一体で、両者を分けて議論するのは便宜上のもの。本質は「AIに何をどう伝えるか」であり、これはAIが進化しても消えない。「プロンプトエンジニアリング」という言葉が消える可能性はあるが、その本質的スキルは「コンテキストエンジニアリング」「AI協働設計」といった名前で残り続ける。投資の重みをコンテキスト側に置くのが、これからの方向性だ。

💡 ポイント：「廃れる派」は表層的な技術を見ているだけ。本質的なスキル（情報設計・文脈伝達・評価設計）は今後10年で重要度が増す。投資判断は「重要派」を採用すべき。

10. 経営層・CTOが押さえるプロンプト戦略の論点

経営層が押さえる論点は3つ。第1に、プロンプト設計を「個人のスキル」から「組織の資産」へと位置づけを変えること。第2に、プロンプト共有・レビュー・改善のサイクルを社内に組み込み、四半期に1回見直す運用にすること。第3に、評価制度に「プロンプト共有・改善への貢献」を組み込むこと。これら3点を整えれば、AIDDの組織能力が継続的に伸びる。「プロンプトは現場任せ」と放置すると、属人化が進み、人材流出時に組織能力が消える。CTOと人事責任者の連携で、プロンプトを組織能力として育てる仕組みを作る。

📊 経営判断のコツ：プロンプト共有を評価対象にすると、現場の動機づけが変わる。「自分だけ使えるプロンプト」から「チーム全体で使えるプロンプト」へと文化がシフトする。

まとめ

プロンプトエンジニアリングは「お願い」ではなく「設計仕様書」を書く技術だ。明確性・具体性・構造化・文脈・検証可能性の5原則を揃え、6つの基本テクニック（ロール・ステップ・Few-shot・制約・出力形式・自己批評）を使い分け、6セクション構造テンプレート（コンテキスト・タスク・要件・出力形式・制約・受け入れ条件）で実務化する。4つの失敗パターン（後出し・抽象形容詞・タスク混在・コンテキスト不足）を避け、リポジトリ・規約・Wikiの3層でプロンプトを組織資産化する。経営層は「個人スキル」から「組織能力」への転換を主導し、評価制度・教育プログラム・改善サイクルで継続的に強化する設計を整えてほしい。

プロンプト設計チェックリスト

• [ ] 5原則（明確性・具体性・構造化・文脈・検証可能性）を満たしている
• [ ] 6セクション構造テンプレート（コンテキスト・タスク・要件・出力形式・制約・受け入れ条件）を使っている
• [ ] 6基本テクニックの中から適切なものを2〜4個組み合わせている
• [ ] 4つの失敗パターン（後出し・抽象・複数タスク・文脈不足）を避けている
• [ ] プロンプトがGitリポジトリ・社内Wikiで管理されている
• [ ] CLAUDE.md / .cursorrules等のプロジェクト規約が整備されている
• [ ] プロンプト改善の四半期レビューが運用されている
• [ ] チームでベストプロンプト集を共有している
• [ ] プロンプト貢献が人事評価の対象になっている
• [ ] プロンプト研修が新人オンボーディングに組み込まれている

IT COMPASSのAI駆動開発支援

IT COMPASS では、CTO経験者が外部CTO・技術顧問として、AI駆動開発のプロンプト設計とナレッジ整備を伴走支援しています。

支援できること

• 🎯 プロンプト設計のテンプレート化：チーム共通のプロンプト集と運用設計、5原則・6テクニック・6セクション構造の組織導入
• 🛠 ツール選定とパイロット設計：Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
• 👥 開発組織の再設計：AIエージェントを前提としたチーム編成・役割定義・評価制度
• 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
• 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート

こんな方におすすめ

• プロンプト設計を属人化させたくないCTO・テックリードの方
• 全社共通のプロンプトガイドラインを作りたい開発マネジメント層の方
• AIDDの実装スキルを底上げしたい開発リーダーの方

お問い合わせ

スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。
👉 IT COMPASS お問い合わせフォーム
経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。

監修者

西脇　靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）

「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援している。著書はオライリー・ジャパンから複数刊行。

 
lanitech合同会社 webサイト