採用 · July 21, 2026 · 約9分

職種別プロンプトエンジニアリング：「良い」とはどういうことか

プロンプトエンジニアリングはほぼすべての職種でコアスキルになりました。ただし「良い」の意味はエンジニア、アナリスト、サポート担当、SDR、PM、採用担当で異なります。職種別の実践ハブガイドです。

← 「採用の5つのピラー：アセスメントが測定するもの」の一部

1年前、プロンプトエンジニアリングはニッチな専門技能のように聞こえていました。今や、キーボードに触れるほぼすべての職種での基礎スキルとなり、採用マネジャーや人材責任者にとって最も精度の高い測定指標の一つです。AIのミスを届けるかそれを捕捉するかを予測するからです。しかし、多くの採用チームが見落としていることがあります。職種別のプロンプトエンジニアリングは仕事をまたいで同じ姿をしていないのです。優れたエンジニアを際立たせるものは、優れたサポート担当を際立たせるものとは異なります。これは職種別クラスターのハブとなる記事です——各席で「良い」とは実際にどのような姿をしているかを示す実践ガイドと、より深く探求したい職種へのリンクです。

プロンプトエンジニアリングは単一スキルではなく、職種で形が変わる

根底にある能力は普遍的です。ツールに明確なコンテキストと制約を与え、返ってきたものを検証して修正する——これはAI fluencyの一部であり、最も強いシグナルは常に同じです。AIが自信を持って間違っているときに気づくこと。しかし、課題と失敗のパターンは職種ごとに固有であり、だからこそ言い回しのテクニックは予測精度がほぼなく、現実的な職種に即した課題が非常に高い予測精度を持つのです。私たちが評価する6つの職種領域でそれがどのように現れるか、続いて各領域の詳細ガイドをご覧ください。

プロンプティングが採用シグナルになった理由

過去10年の大部分において、候補者が職場で使うツールはアセスメントから見えませんでした。アウトプットを測定してスキルを推測していました。AIツールはその明確な線を崩しました。自信に満ちた成果物は候補者自身の丁寧な作業かもしれないし、微妙に高コストで間違ったモデルからの未検討のコピーかもしれません。その2つの結果の間のギャップがまさにプロンプトエンジニアリングが測定するものです。もっともらしい答えを出せるかではなく、良い答えともっともらしい答えを区別できるかどうかです。

だからこそ、プロンプティングは静かに最も評価するレバレッジが高いものになりました。モデルを無批判に信頼する人を採用すれば、そのミスのチャンネルを採用したことになります。すべてのアウトプットを検証すべき下書きとして扱う人を採用すれば、乗数を採用したことになります。その違いは履歴書では見えず、AI活用方法についての会話でも見えにくいです。人は実際よりも自分が慎重だと語る方が多い。実際の課題に取り組む様子を見るときに表れます。これが直接評価すべき全論拠です。

普遍的スキル、そして職種固有のエッジ

優れたプロンプトはすべて同じ形をしています。候補者はモデルが推測できなかったコンテキストを提供し、重要な制約を述べ——そして決定的なこととして——結果を安堵ではなく疑念を持って読みます。職種が分岐するのは「間違い」がどのような姿で、見落とすコストがどれほどかについてです。エンジニアのミスはコンパイルされてバグを届けます。アナリストのミスは役員報告書の数字になります。サポート担当のミスはすでに不満を持っている顧客に届きます。検証の筋肉は普遍的ですが、候補者がそれを持っているかどうかは、実際の職種の失敗モードを捕捉させる課題を与えてはじめて確認できます。

ソフトウェアエンジニア

アシスタントにリトライロジック付きの非同期APIクライアントを書かせてみましょう。優れた候補者は制約を最初に明示し——モダンな非同期パターン、適切な例外に対する明示的なエラーハンドリング——生成されたコードを読み、微妙な問題を捕捉します。非推奨の呼び出し、誤ったエラーを握りつぶすリトライ、抜け落ちたエッジケース。そして修正してテストします。ここでの良いプロンプティングはコードレビューと切り離せません。ソフトウェアエンジニアのアセスメントで他に何をテストすべきかをご覧ください。

• 優れた例：リクエストを制約し、アウトプットを読み、非推奨または安全でないコードを捕捉し、クイックテストで検証する。
• 弱い例：生成された関数をそのまま貼り付けて提出し、未処理のエッジケースをすべて残したまま。

データアナリスト

SQLクエリを求めてみましょう——たとえば、内部テストアカウントを除く月別純売上——または結果の解釈を求めます。優れた候補者は指標と除外条件をプロンプトで定義し、すでに知っている数字と照らし合わせて妥当性を確認し、自信に満ちているが誤解を招く集計値に疑問を呈してレポートに貼り付けません。プロンプティングスキルと分析的判断力は同じ筋肉です。詳細はデータアナリストのアセスメントで。

• 優れた例：指標と除外条件を明示し、アウトプットの妥当性を確認し、データが裏付けない数字を疑う。
• 弱い例：もっともらしいクエリを受け入れ、密かに辻褄の合わない数値を報告する。

カスタマーサポート

不満を持つ顧客への返信の下書きをAIに依頼します。優れた候補者は関連するポリシーと望むトーンを提供し、下書きの正確さを確認し、ロボット的または冷淡に見えるものを和らげ、モデルが勝手に追加した過剰な約束を削除します。サポートでは、プロンプトは仕事の半分にすぎません。編集こそが判断力を示す場面です。カスタマーサポートのアセスメントをご覧ください。

• 優れた例：ポリシーとトーンを提供し、正確さを検証し、真の共感に調整し、過剰な約束を削除する。
• 弱い例：ポリシーが誤っているかトーンがずれた、または両方の問題を持つ汎用AI返信を送信する。

営業開発（SDR）

特定のペルソナへのコールドメールを依頼します。優れた候補者は実際のコンテキストをツールに提供します——購買者が誰か、バリュープロポジション、明確な一つのアクション——結果をパーソナライズし、忙しいVPが実際に読むものに絞り込み、送信前に見込み客についての幻覚の「事実」を捕捉します。プロンプトが準備し、判断力が信頼性を保ちます。詳細は営業開発のアセスメントで。

• 優れた例：コンテキストを提供し、パーソナライズし、明確なアクションに絞り込み、でっち上げの詳細を捕捉する。
• 弱い例：汎用テンプレートのメールを送信する——時に架空の事実を含む。

プロダクトマネジャー

仕様書の初稿または優先順位付けを求めます。優れたPMは問題と制約を明確にフレーミングし、AIを使って素早いスタート地点を得た後、真のプロダクト判断力を適用します——欠陥のある前提を捕捉し、モデルが過剰に追加したスコープを削除し、そのまま提出するのではなくユーザーと指標に紐付けます。プロダクトマネジャーのアセスメントをご覧ください。

• 優れた例：問題をフレーミングし、AIを下書きに使い、判断力を適用する——悪い前提を捕捉し、実際の目標に紐付ける。
• 弱い例：プロダクト思考が一切乗っていないAI生成の仕様書を提出する。

採用担当

AIにアウトリーチメッセージやスクリーニングルーブリックの下書きを依頼します。優れた採用担当は職種のコンテキストと必須のシグナルを提供し、バイアス、汎用のフィラー、実際には当てはまらない職種についての主張がないかアウトプットを確認します——そして候補者が信頼できるものに書き直します。ここでうまくプロンプトすることは別の形での人材判断力です。良いものがどのようなものかをモデルが推測する前から知ること。採用担当のアセスメントについては採用担当の採用方法をご覧ください。

• 優れた例：職種のコンテキストとシグナルを提供し、バイアスとフィラーのアウトプットを確認し、すべての主張を真実に保つ。
• 弱い例：職種を誇張しスパムのように読めるAI作成の汎用メールを送信する。

詳細ガイドへ：各職種のフルガイド

各職種にはそれぞれの詳細ガイドがあります——ベストプラクティス、実際のプロンプト例、優れた点と弱い点のシグナル、評価方法：

• ソフトウェアエンジニアのプロンプトエンジニアリング — 逆向きのコードレビューとしてのプロンプティング。
• データアナリストのプロンプトエンジニアリング — 厳密な定義、そして数字を疑う。
• カスタマーサポートのプロンプトエンジニアリング — 下書きは簡単、編集こそが仕事。
• 営業開発のプロンプトエンジニアリング — コンテキストを入れ、信頼性を出す。
• プロダクトマネジャーのプロンプトエンジニアリング — AIが下書きし、判断力が決める。
• 採用担当のプロンプトエンジニアリング — モデルに適用された人材判断力。

チームがアセスメントで犯す2つの間違い

最初の間違いはプロンプトクイズです——候補者にリクエストをどのように作るかを説明させたり、プロンプティングのテクニックの知識で採点したりすることです。これは語彙を測定するものであり、判断力ではありません。そのテーマに関するスレッドを数本読んだことがある人なら誰でも簡単にゲームできます。2番目の間違いは逆の過修正です——不正を心配してアセスメントでAIを完全に禁止することです。これは2年前の仕事のやり方をテストするものであり、現在の姿ではありません。また、他の全員がすでに使っているツールを使えない候補者をフィルタリングします。

両方の間違いは共通の根本原因を持っています。プロンプティングを行うものではなく知るものとして扱うことです。その解決策は、AIについての知識をテストするのをやめて、実際の職種の失敗モードを持つ課題で、AIとのコラボレーションを観察し始めることです。その発想の転換はインテグリティの懸念も解決します。AI使用が期待されていて課題が職務ごとに生成されているなら、良い結果への最短ルートは真のスキルです——これはAI生成アセスメントの不正防止に対する私たちのアプローチと同じ論理です。

評価の方法

プロンプトについてのクイズではこれを測定できません。AIを禁止することでも確実に測定できません。AIツールが使える状態で現実的な職種に即した課題に候補者を置き、どのように作業するかを観察することで測定します——これがまさにAI Sandboxアセスメントの機能であり、AI fluencyがピラーとして測定される方法です。実際の仕事がどのように行われているかをテストする正直な方法です——AI採用のコアアイデア。また、より広い視野での位置付けもあります。プロンプティングは包括的な候補者評価における5つのピラーの一つであり、単独のギミックではありません。

AI Sandboxは職種に調整された課題での実際のコラボレーションを観察するため、採用する職種が何であれ、同じ根本的なシグナル——このモデルが自信を持って間違っているときに気づくかどうか——が浮かび上がります。プロンプティングが各職種でどのように位置付けられるかを確認するには職種調整アセスメントの作成を見るか、より広い枠組みが先に必要な場合はAI fluency採用ガイドから始めてください。

アセスメント構築のための実践的なメモ：課題を過度に足場組みする衝動を抑えてください。候補者が実行すべきすべての制約とチェックを明示すれば、あなたが彼らのプロンプティングを代行したことになり、何も学べません。シグナルは、ブリーフが現実的にゆるいときに何を追加するかと何を問うかにあります——まさに実際の仕事で直面するのと同じ曖昧さです。良いプロンプトエンジニアリングの課題はテストよりも火曜日の朝に似ています。本物の問題、実際に誰もが使うツール、そして彼らがツールを駆動するかツールに駆動されるかを明らかにするだけの余白。

このように評価することで、プロンプトエンジニアリングはバズワードではなくなり、業務上のアウトプットの最も正直な予測指標の一つになります。上記クラスターから採用している職種を選び、詳細ガイドを読めば、最初の候補者が着席する前に「良い」とはどういうことかを正確に把握できます。

プロンプトエンジニアリングは採用する言い回しのテクニックではありません。AIの自信満ちた間違いに対する判断力です——そしてそれはテーブルのすべての席で異なる姿をしています。