プロンプトエンジニアリング入門 — 仕事で"使える"書き方を実例付きで解説
プロンプトエンジニアリングとは — 難しく考えなくていい
「プロンプトエンジニアリング」って聞くと、なんか専門的でとっつきにくいイメージがありませんか？
うちのチームに新しいスタッフが入るたびに「プロンプトエンジニアリングって何ですか？」って聞かれるんですが、そのたびに同じ話をしています。要するに「AIへの指示の出し方を工夫する技術」です。それだけ。
もう少し丁寧に言うと、ChatGPTやClaudeなどの大規模言語モデル（LLM）に対して、より的確な出力を引き出すための入力（プロンプト）を設計・最適化するスキルのことです。
でも正直、最初は「AIに話しかける方法を研究するって、そんなのビジネスになるの？」と半信半疑でした。実際に使い始めて気づいたのは、同じAIを使っているのに、プロンプトの書き方次第で出力の質が天と地ほど違うということ。これが実感として腑に落ちてから、うちのチームでのAI活用が一気に変わりました。
「プロンプトエンジニアリングとは何か」を一言で言い直すなら、「AIと上手に仕事するための対話術」。人間相手のコミュニケーションと本質は同じで、相手に何をしてほしいかを明確に伝える技術です。
---
なぜプロンプトの書き方で結果が激変するのか
ここが一番重要なポイントなので、具体的に見てみましょう。
悪いプロンプトの典型例
「営業メールを書いて」
これをChatGPTやClaudeに投げると、当たり障りのない汎用的な営業メールが返ってきます。使えないとは言わないけど、そのまま送れるクオリティじゃない。結局、自分でかなり書き直すことになる。
同じ目的でも、良いプロンプトだと
「あなたはB2B SaaS営業のベテランです。以下の条件でメールを作成してください：
- 宛先：製造業の中堅企業（従業員300名規模）の情報システム部長
- 目的：業務自動化ツールの初回アポイント獲得
- トーン：丁寧だが堅すぎない、要点を絞った2〜3段落
- 必ず含める要素：具体的な課題（人手不足・属人化）への言及、ROIの示唆、明確なCTA
- 文字数：400字以内」
こう書くと、本当にそのまま使えるレベルのメールが出てきます。
なぜこんなに違うのか。
LLMは膨大なデータで学習した「確率の塊」です。あいまいな指示を受けると、最も平均的・一般的な回答を返します。一方、具体的な条件を与えると、その条件に合致した確率が高い、より特化した出力を生成できます。
人間に置き換えると分かりやすい。「資料を作って」と言われると困るけど、「来週月曜の役員会議用に、今期のSaaS導入効果をグラフ付きで1ページにまとめて、意思決定に使えるよう結論から先に書いて」と言われたら動けますよね。AIも同じです。
うちのチームで試した結果では、プロンプトを改善するだけでアウトプットの再利用率（そのまま、または軽微な修正で使える率）が20%台から70%台に上がったことがあります。時間的なインパクトは相当大きかった。
---
基本テクニック5選
1. 役割設定（Role Prompting）
AIに「あなたは〇〇です」と役割を与える方法です。
なぜ効くのか： LLMは役割を与えることで、その役割に関連したトークンの出現確率が高まり、その専門家らしい語彙・視点・知識の使い方をするようになります。
実例：
- 「あなたは10年以上の経験を持つ広島の中小企業診断士です」
- 「あなたはエラーに厳しいシニアバックエンドエンジニアです。コードレビューをして」
- 「あなたは読者が初心者であることを前提に説明するライターです」
役割設定は必ずプロンプトの冒頭に置くのがコツ。後から付け加えると効果が薄れることがあります。
2. Few-shot（例示）
「こういうパターンで答えてほしい」という例をいくつか見せてから本題を聞く方法。
実例：
以下のパターンで商品説明を生成してください。
例1）
商品：オーガニックハンドクリーム
説明：肌に優しい天然成分だけで作られた、乾燥知らずの手に。
例2）
商品：折りたたみ傘
説明：急な雨も怖くない。ポーチに入る軽さで、毎日のお守りに。
では、次の商品の説明を同じスタイルで：
商品：ノイズキャンセリングイヤホン
出力のトーン・文体・構成を統一したいときに非常に効きます。ブランドのトンマナを合わせるのに重宝しています。
3. Chain of Thought（思考の連鎖）
複雑な判断や分析を求めるときに「ステップを踏んで考えてください」と明示する方法。
実例： 「この施策のリスクを評価してください。まず考えられるリスクをすべて列挙し、次にそれぞれの発生確率と影響度を評価し、最後に総合判断を示してください。」
または単純に「ステップバイステップで考えてください」という一言を加えるだけでも効果があります。
これが特に効くのは、論理的推論が必要な場面。数学的な計算、法的・倫理的判断、複数の選択肢の比較などです。うちの場合、要件定義の抜け漏れチェックをするときによく使っています。
4. 制約条件の明示
出力の形式・分量・含めてほしい要素・避けてほしい表現などを明示します。
使えるフォーマット：
- 文字数：「500字以内」「800〜1000字程度」
- 形式：「箇条書きで」「番号付きリストで」「表形式で」
- 構成：「結論→理由→具体例の順で」
- 禁止事項：「専門用語は使わないで」「英語は使わないで」
- 対象読者：「IT知識がない40代の経営者に向けて」
制約を明示するほど出力がブレなくなります。「自由に書いて」は最も難しい指示のひとつ。
5. 段階的指示（Iterative Prompting）
最初から完璧なものを求めるのではなく、段階を踏んで精度を上げていく方法。
進め方：
一発で完璧を目指すより、対話しながら育てる感覚。実は人間のライターやデザイナーとの仕事の進め方と同じですよね。うちのチームではこれを「AIとの共同作業」と呼んでいます。
---
業務別プロンプト実例
議事録要約
プロンプト：
以下の会議メモを要約してください。
【形式】
- 決定事項（箇条書き）
- 宿題・アクションアイテム（担当者と期日付き）
- 次回確認事項
【注意】
- 曖昧な点は「要確認」と記載
- 発言者の名前は「Aさん」「Bさん」に匿名化
【会議メモ】
（ここにメモを貼り付ける）
これを使い始めてから、うちでは会議後の議事録作成が以前の3分の1の時間になりました。
メール作成
プロンプト：
以下の状況でビジネスメールを作成してください。
状況：先週の提案に対してまだ返答がない取引先への、柔らかいフォローアップ
関係性：3年以上の取引がある、比較的フレンドリーな関係
目的：進捗確認と、もし何か懸念があれば聞き出したい
トーン：押しつけがましくなく、相手の状況を気遣う雰囲気
文字数：200字前後
コードレビュー
プロンプト：
以下のコードをレビューしてください。
【レビューの観点】
1. バグ・潜在的なエラー
2. パフォーマンスの問題
3. セキュリティリスク
4. 可読性・保守性
5. ベストプラクティスへの準拠
【重要度】高/中/低で分類してください
【言語】TypeScript
【コンテキスト】本番環境で月間10万リクエストを処理するAPIエンドポイント
（コードをここに貼り付ける）
企画書のたたき台
プロンプト：
新サービス「〇〇」の企画書のたたき台を作成してください。
【サービス概要】（ここに説明を書く）
【盛り込んでほしい要素】
- エグゼクティブサマリー（A4半ページ程度）
- 市場・課題の整理
- 解決策とUSP（独自の強み）
- ターゲット顧客
- ビジネスモデル（収益構造）
- 想定リスクと対策
- ロードマップ（6ヶ月〜1年）
【読者】社内の役員会議（5名、経営寄りの視点が強い）
【トーン】論理的で数字・根拠を重視、冗長な表現は避ける
---
やりがちな失敗パターン
失敗1：「とにかく長く書けばいいと思う」
プロンプトは長ければいいわけではありません。長くても矛盾した指示や曖昧な表現が含まれていると、AIは混乱します。量より明確さ。
失敗2：「一度で完璧を求める」
最初の出力に失望して「AIは使えない」と判断するケースが多い。一発目はあくまでたたき台。フィードバックを与えて精度を上げるプロセスが前提です。
失敗3：「何でも任せようとする」
AIが苦手なこともあります。最新情報、自社特有の文脈、感情的なニュアンスの判断など。「どこまでAIに任せて、どこは人間がやるか」の切り分けができていないと時間を無駄にします。
失敗4：「毎回ゼロからプロンプトを書く」
同じ種類のタスクに毎回ゼロからプロンプトを書いているのは非効率です。一度うまくいったプロンプトはテンプレート化して再利用しましょう（後述します）。
失敗5：「出力をそのまま使う」
特にファクトを含む内容（数字、固有名詞、法的内容）はAIが「もっともらしいウソ」をつく可能性があります（ハルシネーション）。必ずファクトチェックを。これはプロンプトの問題ではなくLLMの性質上の問題ですが、忘れがちな落とし穴。
---
Claude vs ChatGPTでのプロンプトの違い
「ClaudeとChatGPT、どっちを使えばいいですか？」という質問をよく受けます。うちのチームでは両方使っていますが、プロンプトの書き方で気づいた違いをまとめます。
Claudeの特性
長文・複雑な文書処理が得意。コンテキストウィンドウが大きく、長い資料を丸ごと投げても処理できます。
指示への準拠度が高い。「〇〇を含めないで」「必ず〇〇の形式で」という制約条件を守る精度が高め。
文章の質・ニュアンスが繊細。日本語の微妙なトーン調整、ビジネス文書の品質が求めやすい。
Claudeに効くプロンプトの傾向：
- 詳細な制約条件を与えると素直に従う
- 「XMLタグ」での構造化（<task>, <context>, <format>など）が効く
- 「なぜそうするのか」の理由を添えると精度が上がることがある
ChatGPTの特性
プラグイン・ツール連携が豊富。Webブラウジング、DALL-Eによる画像生成、データ分析などのエコシステムが強い。
コード生成が直感的。プログラマーに近い文化で育っているためか、コードの説明・生成に慣れた感覚がある。
ChatGPTに効くプロンプトの傾向：
- システムプロンプト（APIを使う場合）を設定すると一貫性が上がる
- 「act as」形式の役割設定が効く
- ダイレクトな指示に強い傾向
使い分けの考え方（うちのチームの場合）
- 長文の資料読み込み・複雑な文書作成 → Claude
- コーディング支援・プロトタイプ作成 → ChatGPT（またはClaude Code）
- 画像生成を伴うコンテンツ → ChatGPT
- 微妙なニュアンスが必要な日本語ライティング → Claude
正直、どちらが「勝ち」とかはなくて、タスクによって使い分けるのが現実的です。
---
チームで活用するためのプロンプトテンプレート運用
個人がプロンプトを上手に使えるようになっても、組織全体では活用されていない——これがよくある「AI導入が進まない会社」のパターンです。
うちのチームでは、以下の方法でプロンプトを資産化しています。
テンプレートライブラリの構築
Notionに「プロンプトライブラリ」ページを作り、以下の形式で管理しています：
【テンプレート名】議事録要約テンプレートv3
【用途】会議後の議事録作成（60分以内の会議向け）
【最終更新】2026年2月
【プロンプト】（本文）
【使い方メモ】（注意点や改善履歴）
【効果】（使ってみた感想・改善率）
タスク種別（ライティング/分析/コード/画像/要約）でタグ分類して検索しやすくしています。
プロンプトのバージョン管理
プロンプトも一種のコードだと思って、改善したら更新履歴を残しています。「v1→v2で何が変わって、どう結果が良くなったか」を記録することで、組織内のプロンプト設計力が積み上がります。
使いどころの明文化
「このテンプレートはどういう状況で使うか」を具体的に書くことで、AIに慣れていないメンバーでも迷わず使えるようになります。抽象的な「文章作成に使えます」より「〇〇のような場面で、△△の目的で使うテンプレートです」の方が断然役に立ちます。
レビュー会議
月1回、チームでプロンプトのレビューをしています。「このテンプレート、最近イマイチになってきた気がする」「モデルが更新されてから挙動が変わった」という共有ができる場。プロンプトは一度作ったら終わりじゃなく、AIモデルのアップデートに合わせて定期的に見直す必要があります。
新人オンボーディングへの組み込み
うちでは入社直後のオンボーディングに「プロンプト基礎研修」を組み込んでいます。ライブラリの使い方、基本テクニック、NGパターンを最初に共有することで、全員が最低限のプロンプトスキルを持った状態でスタートできます。
---
まとめ
プロンプトエンジニアリングは、特別なスキルじゃなくて「AIとうまく対話するためのコミュニケーション術」です。
大事なポイントを整理すると：
- 役割・目的・制約・形式を明示することが基本
- 一発で完璧を求めない、対話しながら精度を上げる
- テンプレート化して資産にする、個人のノウハウで終わらせない
- Claude vs ChatGPTは用途で使い分ける
- ファクトチェックは必須、出力を鵜呑みにしない
プロンプトエンジニアリングを学ぶ最善の方法は、とにかくたくさん使ってみること。「なんか思った通りじゃないな」と感じたとき、その都度「なぜそうなったか」を考えながら修正する——その繰り返しで自然と上手になっていきます。
うちのチームでは、AIを「ツール」として使うのではなく「チームメンバー」として対話する感覚を大切にしています。指示の出し方を磨くことで、AIとの仕事はもっと楽しく、もっと生産的になる。プロンプトエンジニアリングは、その入口です。
広島でAI活用やDX推進を検討されている方は、ぜひお気軽にご相談ください。うちのチームの実践ノウハウを共有しながら、一緒に考えていきます。
Written by
Swaaab編集部
広島を拠点に、AI開発・DX支援・Web制作を手がけるSwaaab株式会社の編集チーム。現場で得た知見をもとに、実践的な情報を発信しています。