AI Overview時代の外部エンジニア選定｜5フェーズで使うプロンプト活用法

新規プロジェクトを任されて外部エンジニアを探し始めた瞬間、以前とは検索体験が変わっていることに気づいた方は多いのではないでしょうか。Google の検索結果には AI Overview（旧 SGE）による要約が挟まり、候補企業やスキルセットの概要はすでに冒頭で「まとめられて」出てきます。それ自体は便利ですが、要約を読んだだけで発注判断ができるわけではありません。むしろ「表層の情報は簡単に得られるのに、意思決定に必要な深い情報が見えづらくなった」という感覚を持ち始めている方もいるはずです。

一方で、外部エンジニアの単価は上昇しており、選定の失敗コストは年々大きくなっています。数百万円規模のプロジェクトでスキルミスマッチや進行トラブルが起きると、金銭的な損失だけでなく、社内の DX 推進体制そのものへの信頼が揺らぎます。「情報は多いのに、正しく比較できない」「面談で聞くべきことが整理しきれない」「提案書の妥当性を評価する軸がない」といった悩みは、担当者個人のスキル不足ではなく、選定プロセス全体が AI 時代の情報環境に追いついていないことに起因します。

こうした状況で有力な武器になるのが、生成 AI プロンプトを選定プロセスに組み込むアプローチです。ただし、汎用的なプロンプト集をコピペするだけでは自社要件と噛み合わず、期待した回答が返ってきません。求められるのは「単発のプロンプト」ではなく、要件言語化から意思決定まで一連の流れに沿ってプロンプトを配置する設計です。

本記事では、AI Overview 時代に外部エンジニア選定の精度を高めるための、5 つのフェーズに沿った生成 AI プロンプト活用法を解説します。要件の言語化・ペルソナ設計・面談質問リスト生成・提案書と見積書のレビュー・選定判断の書き起こしまで、コピペしてカスタマイズできる形でプロンプト例を掲載しました。発注者側の視点だけでなく、受注者側の視点も踏まえて「良い問いが良い回答を引き出す」双方向のダイナミクスにも触れます。読了後には、自社の選定プロセスに落とし込める「今日から使えるチェックリスト」が手元に残る構成です。

AI Overview（SGE）時代のエンジニア選定はなぜ難しくなったか

外部エンジニアの選定は、もともと難易度の高い意思決定でした。技術スキル・コミュニケーション相性・単価妥当性・稼働可能性・契約形態など、判断軸が多い上に、情報が非対称です。そこに AI Overview（SGE）による検索環境の変化が加わり、従来型の情報収集手法だけでは意思決定に必要な深さに届きにくくなっています。

AI Overview が変えた発注者の情報収集行動

AI Overview は Google 検索結果の上部に生成 AI による要約を表示する機能で、日本でも 2024 年 8 月以降、順次一般ユーザーに展開されています（Google Japan Blog: AI Overview（AI による概要）の提供を日本で開始）。検索クエリに対して複数の情報源をまとめた回答が冒頭に提示されるため、ユーザーは個別の記事を開かなくても概要を把握できるようになりました。

一方で、外部エンジニア選定のような複雑な意思決定では、要約された情報だけでは不十分です。要約は「一般論として何が正しいか」を示すのは得意ですが、「あなたの会社の状況では何が最適か」までは踏み込めません。以下のような情報は、AI Overview の要約では得にくい代表例です。

• 自社の業種・規模・既存システム構成に合わせた技術選定の妥当性
• 特定の言語・フレームワークの実運用上の落とし穴
• 候補エンジニアの過去実績と自社案件との適合度
• 見積書に記載された工数・単価が業界水準と乖離していないかの判断

つまり、AI Overview の登場によって「概要把握」のコストは下がったものの、その先の「自社要件へのフィット度を評価する」作業は依然として発注者側に残されています。むしろ、要約を読んで「わかった気になってしまう」リスクが高まったとも言えます。

エンジニア選定の失敗コストが上がっている背景

同時に、エンジニア選定の失敗コスト自体が上昇しています。経済産業省の「DX レポート 2.2」でも、DX 推進人材の不足が繰り返し指摘されており、外部エンジニアの需要と単価は上昇傾向にあります（経済産業省: DX レポート 2.2（概要））。

具体的には、以下のような要因が絡み合っています。

• 単価上昇: 上位クラスのフリーランスエンジニアの単価は月額 80〜120 万円が一般的で、AI や特定領域の専門人材ではさらに高額になる
• 契約期間の長期化: 短期契約でスキル不足が発覚しても、代替人材の確保に時間がかかり、プロジェクト全体が遅延する
• 内製化圧力: 外部依存を減らしたい経営層と、即戦力を必要とする現場の板挟みで、選定に対する期待値が上がっている
• フリーランス新法: 2024 年 11 月施行の「特定受託事業者に係る取引の適正化等に関する法律」により、契約書面の交付義務・報酬支払遅延の禁止など、発注者側の実務負担も増えている

こうした状況で「なんとなく良さそうだったから発注した」判断が通用しづらくなっており、選定プロセスの標準化・可視化が求められています。

「良い問いを立てられる発注者」が有利になる時代

情報環境が変わっても変わらないのは、「良い意思決定は良い問いから生まれる」という原則です。AI Overview はあくまで「問われた内容に対する要約」を返す仕組みであり、問いの質が悪ければ得られる回答も浅くなります。

生成 AI を選定業務に組み込む際も同じで、「良さそうなエンジニアを教えて」というプロンプトからは一般論しか返ってきません。しかし「自社の技術スタック・プロジェクト規模・社内チーム構成を踏まえて、面談で確認すべき技術質問を 10 個作って」と問えば、実務で使える情報が返ってきます。

つまり、AI 時代の外部エンジニア選定で有利になるのは、豊富な情報にアクセスできる発注者ではなく、自社の要件を言語化し、それを AI に対して構造的に伝えられる発注者です。次のセクションからは、この「良い問いの立て方」を選定プロセスの各フェーズに組み込む方法を解説していきます。

生成 AI プロンプトを選定に組み込む 3 つの視点

具体的なプロンプト例に入る前に、選定プロセス全体のどこで AI が効くのかを俯瞰しておきましょう。細かいプロンプトを覚えるより、「AI をどの視点で使うか」を先に押さえたほうが、自社に合わせたカスタマイズが効きます。ここでは 3 つの視点で整理します。

視点1「要件の言語化」— 自社の課題を明確化する

選定でつまずく最大の理由は、エンジニアのスキル評価ではなく、そもそも「自社が何を求めているか」の言語化不足です。プロジェクトの目的・技術要件・成功条件・体制の前提が曖昧なまま面談に入ると、候補者ごとに違う軸で会話が展開し、比較不能な情報だけが手元に残ります。

この段階で生成 AI を使う目的は、担当者一人では気づけない「暗黙の前提」や「見落としている論点」を洗い出すことです。AI に「壁打ち相手」として、要件の抜け漏れを指摘してもらったり、要件の記述を業界標準の粒度に整えてもらったりします。要件そのものを AI が決めるのではなく、担当者の頭の中を整理する補助として使うのがポイントです。

視点2「候補評価」— 面談・スキル判断を補強する

要件が固まったら、候補エンジニアの評価フェーズに進みます。ここでは「限られた面談時間で、どう実力を見極めるか」が中心課題です。技術書や資格の知識を問う一般的な質問だけでは、実務での判断力・チーム内でのコミュニケーション力・トラブル対応力までは測れません。

生成 AI は、要件と候補者の情報を踏まえて「その候補者に対して何を聞けば実力が浮かび上がるか」を構造化するのに向いています。面談質問リストの生成、想定される回答パターンごとの評価軸の整理、提案書に書かれた技術的アプローチの妥当性チェックなど、面談前後の情報整理を大幅に効率化できます。

一方で、AI が生成した質問リストをそのまま鵜呑みにしてはいけません。あくまで「自分では思いつかなかった観点を追加する」補助であり、最終的な質問セットは案件責任者が選び取ります。

視点3「意思決定の透明化」— 比較軸と社内説明責任を整える

複数候補から選定する段階では、「なぜこの候補を選んだのか」を社内に説明する責任が生まれます。役員会・稟議・社内チームなど説明する相手が多いほど、判断の根拠を客観的な形で残す必要があります。

ここで生成 AI が役に立つのは、比較表の作成・選定理由の書き起こし・想定される反対意見への回答準備です。担当者の頭の中にある「なんとなくの判断」を、複数の評価軸に沿った言語に翻訳する作業を AI が肩代わりします。

これらは記録として残すことで、後日「この選定は正しかったか」を振り返る材料にもなります。プロジェクト終了時に振り返りをすると、選定時に軽視した観点が実は失敗の原因だった、というパターンは少なくありません。AI を使って選定判断を書き起こすことは、次回以降の選定精度を上げる資産にもなります。

以上の 3 視点を踏まえたうえで、次はいよいよ具体的なフェーズ別のプロンプト例を見ていきます。

フェーズ別プロンプト活用法（実践編）

ここからは実践編です。選定プロセスを 5 つのフェーズに分け、各フェーズで使える生成 AI プロンプトの例を提示します。すべてコピペで使える形にしていますが、< > で囲んだ部分は自社の情報に置き換えてください。プロンプトの冒頭では役割指定・出力形式指定・例示のいずれかを含める形にしており、AI からの回答精度が安定するようにしています。

なお、以下のプロンプト例は ChatGPT（GPT-4 系）・Claude（Claude 3.5 Sonnet 以降）などの汎用 LLM を想定しています。社内で導入している AI 環境や、機密情報の扱いについては、のちほど別のセクションで解説します。

フェーズ1: プロジェクト要件の言語化プロンプト

面談前の一番大事な準備が要件の言語化です。以下のプロンプトは、担当者が持っている断片的な情報を、外部エンジニアに提示できるレベルの要件書へ整理する用途で使います。

あなたはシステム開発の要件定義を10年経験してきたテックリードです。

【現状のプロジェクト概要】
- 事業: <自社事業の1〜2行説明>
- 目的: <このプロジェクトで達成したいこと>
- 現状の課題: <なぜ外部エンジニアが必要か>
- 想定技術スタック: <既存システムのスタック / 使用予定の言語・FW>
- 想定期間: <開始時期と概算期間>
- 想定予算: <月額or総額>
- 社内体制: <PM・エンジニア・デザイナーの人数と役割>

上記の情報をもとに、外部エンジニアに提示する要件書のドラフトを作成してください。
以下の観点で、抜け漏れや曖昧な点を指摘し、必要な追加情報を質問形式で挙げてください。

1. 機能要件の粒度
2. 非機能要件（性能・セキュリティ・可用性）
3. 開発プロセス（アジャイル/ウォーターフォール、レビュー体制）
4. 成功条件（KPI、リリース基準）
5. リスクと制約（法規制、既存システムとの連携）

出力形式:
- 要件書ドラフト（Markdown）
- 抜け漏れ質問リスト（10項目以内）

このプロンプトのポイントは、AI に「要件書を書かせる」のではなく「抜け漏れを指摘させる」ことです。要件書のドラフトはあくまで叩き台で、真の価値は「10 項目以内の質問リスト」にあります。担当者は質問リストを見て、社内関係者に確認しながら要件を固めていきます。

カスタマイズのコツとしては、既存システムの構成図やスクリーンショットを一緒に貼り付けると、AI の指摘がより具体的になります。ただし機密情報の扱いには注意が必要で、社名・顧客名・システムの内部構造などが含まれる場合は、社内で承認された AI 環境（社内 ChatGPT や API 経由の閉域環境）で実行してください。

フェーズ2: 求めるエンジニア像（ペルソナ）設計プロンプト

要件がまとまったら、次はどんなエンジニアが必要かのペルソナ設計です。「シニアエンジニア」「フルスタック」といった曖昧な表現ではなく、業務経験・技術スタック・チーム内での役割まで具体化することで、応募マッチ度が大幅に上がります。

あなたはIT人材のリクルーティングを15年経験してきたエージェントです。

【プロジェクト要件（フェーズ1の成果物）】
<フェーズ1で作成した要件書を貼り付け>

【求めるエンジニア像の仮説】
- 職種: <フロントエンド / バックエンド / インフラ / フルスタック 等>
- 経験年数: <想定年数>
- 契約形態: <準委任 / 請負 / SES>
- 稼働率: <週N日、月N時間>

上記をもとに、以下を作成してください。

1. 求めるエンジニアのペルソナ（3パターン: 理想像・現実的な妥協ライン・最低ライン）
2. 各ペルソナに対して、必須スキルとあると望ましいスキルを区別してリスト化
3. 過去実績として確認したい具体例（例: 「AWS ECS+Fargate での本番運用経験」等）
4. 除外条件（このパターンには合わない特徴）

出力形式は表形式でお願いします。

このプロンプトの狙いは、「理想像」だけでなく「現実的な妥協ライン」「最低ライン」を並列で作らせることです。理想のエンジニアを 1 人だけ定義すると、市場にほとんど存在しないペルソナができあがりがちで、結局妥協して選ばざるを得ません。最初から 3 段階のペルソナを持っておけば、候補者評価の時点で「どのラインを満たしているか」で判断できます。

除外条件も重要な要素です。ペルソナに合わない特徴を先に言語化しておくと、面談の途中で「このタイプの人だから合わない」という直感を後付けの理由にすり替えるリスクを減らせます。

フェーズ3: 面談質問リスト生成プロンプト

面談は選定プロセスで最も情報密度が高いフェーズです。しかし 60〜90 分という限られた時間で、要件との適合度を見極めるのは簡単ではありません。生成 AI を使えば、案件固有の技術質問と行動特性質問を組み合わせたリストを事前に作れます。

あなたは外部エンジニアの面談を100人以上実施してきた採用マネージャーです。

【プロジェクト要件】
<フェーズ1の成果物>

【求めるペルソナ】
<フェーズ2の成果物>

【候補者の職務経歴書（もし公開情報として入手できる場合のみ貼り付け。機密情報は避ける）】
<職務経歴書の要約>

以下の面談質問リストを作成してください。

■ 技術質問（8問）
- 求めるスキルセットに直結する具体的な状況質問
- 「実際にやったこと」を引き出す質問形式
- 各質問に、期待する回答レベル（初級/中級/上級）を併記

■ 行動特性質問（5問）
- チーム内でのコミュニケーションスタイル
- 判断に迷ったときの意思決定パターン
- トラブル発生時の対応経験

■ 相互確認質問（3問）
- 候補者側からの逆質問を想定した回答準備が必要な項目
- 稼働可能性・契約条件・並行案件の有無

出力形式は質問番号つきの一覧で。

質問数を「8+5+3」と明示的に指定しているのがポイントです。指定しないと AI は 30 問以上生成することがあり、面談時間に収まらないリストができあがります。実務では「技術 30 分・行動特性 20 分・相互確認 10 分」といった時間配分を先に決めて、質問数を逆算するのが有効です。

このプロンプトを使う際の注意点として、候補者の職務経歴書を貼り付ける場合は、氏名・所属企業名などの個人情報を除去してから使ってください。個人が特定できる情報を汎用 AI に投入すると、プライバシー保護の観点でリスクが生じます。

フェーズ4: 提案書・見積書の観点別レビュープロンプト

候補企業から提案書や見積書が届いたら、それを AI にレビューさせるフェーズに入ります。ここでの目的は「AI に採否を決めさせる」ことではなく、「発注者が見落としがちな観点を追加する」ことです。

あなたはシステム開発の見積・提案評価を200案件以上実施してきたPMOです。

【プロジェクト要件】
<フェーズ1の成果物>

【受領した提案書】
<提案書の内容を貼り付け(機密情報は伏字)>

以下の観点でレビューしてください。

1. 技術的アプローチの妥当性
   - 提案されている技術選定が要件と整合しているか
   - 過大/過小な技術投資はないか

2. 工数見積の妥当性
   - 各タスクの工数が業界水準と乖離していないか
   - 見えない工数（レビュー・調整・ドキュメント）が計上されているか

3. リスクの言及
   - 提案書がリスクや前提条件に言及しているか
   - 「〜の場合は追加費用」の記載が具体的か

4. 営業スクリプト警戒
   - 具体性のない美辞麗句が多くないか
   - 過去実績の記述が抽象的すぎないか

5. 質問すべきポイント
   - 追加確認が必要な項目を10個以内で
   - 各質問の意図（何を確かめたいのか）も添える

出力は Markdown 形式で、観点ごとに小見出しを分けてください。

このプロンプトで特に効くのは「営業スクリプト警戒」の観点です。提案書には、どの案件にも当てはまるようなテンプレート文言が入っていることが少なくありません。「豊富な実績」「柔軟な対応」「品質重視の開発」といった抽象的な言葉が並んでいる場合、AI に「具体性のない美辞麗句」として抽出させると、実質的な情報が意外なほど少ないことに気づけます。

見積書についても、同様のプロンプトで「工数の妥当性」「隠れコスト」「前提条件の明示度」を確認できます。ただし、AI が示す「業界水準」は学習データに依存するため、実際の相場は複数の情報源（発注ナビの案件相場・IT 人材白書・自社の過去案件データ）と突き合わせて判断してください。

フェーズ5: 選定判断の理由書き起こしプロンプト

複数候補から最終選定するフェーズでは、判断の理由を明示的に言語化することが重要です。稟議や社内説明のために、また自分自身の判断の質を上げるためにも、書き起こしのプロセスは省略しないでください。

あなたはIT投資意思決定を専門とする経営コンサルタントです。

【プロジェクト要件】
<フェーズ1の成果物>

【比較対象の候補】
- 候補A: <企業/個人名(社内メモ用の匿名でも可)、主な強み、弱み、見積金額>
- 候補B: <同上>
- 候補C: <同上>

【現時点での担当者の印象】
<担当者の主観を率直に書く>

以下を実施してください。

1. 3候補を比較する評価軸を5〜7個提示する
2. 各軸に対して、各候補を3段階(◎/○/△)で評価する表を作成する
3. 総合評価と、推奨候補、推奨理由を200字程度でまとめる
4. 反対意見(この選定に対して社内から出そうな異論)を3つ想定し、それぞれへの回答も準備する
5. 選定リスク(この候補を選ぶことで顕在化しうるリスク)を3つ挙げる

出力は稟議書に添付できる形の Markdown で。

このプロンプトは「AI に選定させる」のではなく、「判断の思考プロセスを書き起こす」ことが目的です。最終判断は担当者・案件責任者が下しますが、その判断を稟議書・議事録・振り返り資料に残すための土台を AI が作ってくれます。

特に「反対意見の想定と回答準備」は、稟議通過率を上げるうえで有効です。役員会や上長からの想定質問に事前に答えを準備しておくと、意思決定のスピードが上がります。同時に、想定できない質問が出た場合は「選定時に見落としていた観点があった」ということでもあり、判断の質を振り返る材料になります。

プロンプト活用時の落とし穴と回避策

生成 AI は選定業務に大きな価値をもたらしますが、いくつかの落とし穴もあります。ここでは発注業務で特に注意すべき 3 つのリスクと、それぞれの回避策を解説します。

ハルシネーションを見抜く 3 つのチェック

ハルシネーションとは、AI が実在しない情報を、あたかも事実のように出力してしまう現象のことです。エンジニア選定の文脈では、以下のようなハルシネーションが起こりえます。

• 存在しないライブラリ・フレームワーク名を提示する
• 実在しないバージョン番号を挙げる
• 業界標準として存在しない資格や認定を「有名な資格」として紹介する
• 単価相場や工数見積の数値を、根拠なしに具体的に提示する

回避のポイントは、以下の 3 つのチェックです。

1. 数値には必ず一次情報を求める: AI が具体的な単価や工数を提示した場合、その数字の出典を尋ねる。出典が不明瞭であれば信用しない
2. 技術名・製品名は公式ドキュメントで確認する: 提示された技術・ライブラリ名は必ず公式サイトで存在確認をする。特にマイナーな OSS や新しいツール名は要注意
3. 同じ質問を別のプロンプトで聞き直す: 表現を変えて 2〜3 回同じ内容を聞き、回答が一貫しているか確認する。回答がばらつく場合はハルシネーションの可能性が高い

技術要件の妥当性判断など、担当者一人では正誤判定が難しい領域では、社内の技術リーダーやセカンドオピニオンを併用してください。AI の回答を「疑わずに使う」姿勢が最大のリスクです。

機密情報を含む場合の運用ルール

外部エンジニア選定のプロセスには、多くの機密情報が絡みます。プロジェクトの詳細・顧客企業名・既存システム構成・営業戦略・人事情報などです。汎用 AI（無償版 ChatGPT・無償版 Claude 等）にこれらの情報をそのまま投入するのは、情報漏洩リスクの観点で避けるべきです。

以下のような運用ルールを、社内で明文化してから活用を始めることをおすすめします。

• 投入する情報の分類: 公開情報のみを使う場面と、機密情報を含む場面を分ける
• 利用する AI 環境の選定: 機密情報を含む場合は、API 経由の閉域環境や、契約上「入力データを学習に使わない」ことを明示している法人向けサービス（ChatGPT Enterprise、Claude for Work 等）を使う
• 情報の匿名化: 個人名・企業名・システム名は、プロンプト投入前に「A 社」「システム X」等に置換する
• ログ管理: プロンプトと回答をログとして残し、後日レビューできるようにする

社内で AI 活用のルールが整備されていない場合、まずは自社の情報セキュリティ担当者と相談し、選定業務に AI を組み込む前に運用ガイドラインを準備してください。ルールを飛ばして便利さだけを追いかけると、後から大きな問題になりかねません。

「AI に委ねすぎない」判断の残し方

3 つ目のリスクは、AI の回答に頼りすぎることによる判断力の低下です。プロンプトの回答をそのままコピペして稟議書に貼り付けたり、AI が推奨した候補をそのまま選定したりすると、担当者の判断筋肉が衰えます。

回避策として、以下の原則を持っておくと有効です。

• AI は「壁打ち相手」であり、意思決定者ではない: AI の出力はあくまで一つの意見として扱い、最終判断は担当者・案件責任者が下す
• AI の回答に「なぜ」を返す習慣: AI が出した結論に対して「なぜそう判断したのか」を追問する。理由が薄い場合は、その結論も薄い
• 人間だけで判断する時間を残す: 面談後の 30 分間は AI を使わず、担当者自身の感覚で候補者を評価する時間を残す
• 判断の記録を残す: AI に頼った判断と、自分で下した判断を区別してログに残す。後日振り返る際、どちらの精度が高かったか比較材料になる

AI は「思考の補助線を引く道具」であり、思考そのものを代替する道具ではありません。この距離感を保ちながら使うことが、長期的に選定精度を上げる鍵になります。

発注者と受注者、双方の視点から見た選定成功のポイント

このセクションでは、発注者側の視点だけでなく、受注者側の視点も踏まえた選定成功のポイントを解説します。「良い問いを立てられる発注者」に対して、受注者側もより真剣に、より具体的に回答するという双方向のダイナミクスを意識することで、選定の質は大きく変わります。

発注者の問いの質が受注者の回答質を決める

外部エンジニア（受注者）側は、日々多くの発注案件に接しています。その中で、発注者からの依頼内容には大きく 2 つのパターンがあります。

• A パターン: 「AWS が得意なエンジニアを探しています。単価は月 80 万円で」といった抽象的な依頼
• B パターン: 「既存の EC2 ベースのシステムを ECS+Fargate に移行するプロジェクトで、社内メンバー 2 名と協働できる方を探しています。稼働は週 3 日、期間 6 ヶ月。ドキュメント整備の経験もあると助かります」といった具体的な依頼

同じスキルセットを持つエンジニアでも、A パターンには「テンプレート回答」を返し、B パターンには「案件に合わせた具体提案」を返す傾向があります。理由は単純で、B パターンには「自社が本当に合うか」を判断する材料が揃っており、真剣に検討する動機が生まれるからです。

生成 AI プロンプトを使って要件を言語化することは、単に発注者側の意思決定を助けるだけでなく、受注者側の回答質を引き出す装置としても機能します。フェーズ 1 で作成した要件書を、そのまま候補企業への RFP（提案依頼書）として提示することを想定しておくと、要件言語化の質が一段上がります。

提案書レビューで営業スクリプトを見抜くプロンプト

受注者側の立場から見ると、初回の提案書は「営業スクリプト的なテンプレート」で対応することが少なくありません。これは受注者が手を抜いているわけではなく、発注者の要件が曖昧なままだと、具体的な提案を書きたくても書けない、というのが実態です。

とはいえ、発注者としては「営業スクリプト的な提案書」と「自社案件を真剣に検討した提案書」を見分ける必要があります。以下のプロンプトはその判定に使えます。

あなたは受託開発会社の提案書を年間100件以上見てきた、
発注者側の提案評価スペシャリストです。

【提案書全文】
<受領した提案書を貼り付け>

以下を判定してください。

1. 案件固有性スコア(0〜100点)
   - この提案書が、当社の案件に固有の内容をどの程度含むか
   - 逆に言えば、同業他社にもそのまま送れそうな汎用度

2. 汎用テンプレート文言の抽出
   - どの案件にも当てはまりそうな抽象的文言を最大10個抽出

3. 案件固有の記述の抽出
   - 当社案件の要件に触れた具体的記述を抽出

4. 追加質問すべき項目
   - 「これを聞くと本気度がわかる」質問を5つ

出力は Markdown で、各項目に見出しをつけてください。

このプロンプトを使うと、提案書の「見た目のボリューム」に惑わされずに、実質的な情報密度を評価できます。案件固有性スコアが低い場合、その候補に対しては「もう一度、要件を踏まえて再提案してほしい」と依頼するのが有効です。再提案の質が最初と大きく変わらない候補は、その時点で選定から外す判断ができます。

相互理解の質を上げる対話設計

最後に、面談中の対話そのものの設計についても触れます。面談は「発注者が候補者を評価する場」だけでなく、「候補者が発注者を評価する場」でもあります。優秀な候補者は、面談中の質問や説明を通じて、この発注者と組んで良いプロジェクトができるかを見極めています。

そのため、面談の質問リストを一方的に読み上げるだけの進行は、優秀な候補者ほど「この会社は要件が曖昧なまま採用しようとしている」という印象を与えかねません。生成 AI で質問リストを作った後は、以下の工夫で対話の質を上げることをおすすめします。

• 面談の冒頭で、プロジェクトの目的・背景・体制を候補者に簡潔に説明する時間を取る
• 質問リストを機械的に読み上げず、候補者の回答に応じて深掘り質問を追加する
• 面談時間の 20〜30% は候補者からの逆質問時間として確保する
• 候補者からの逆質問の質も、選定の判断材料として記録する

生成 AI プロンプトはあくまで準備を効率化するツールであり、面談の現場では担当者自身の判断と対話力が問われます。準備を AI で強化しつつ、現場では人間同士の対話に集中するというバランスが、選定成功の鍵になります。

まとめ｜AI Overview 時代の外部エンジニア選定チェックリスト

ここまでの内容を、明日から使えるチェックリスト形式で振り返ります。自社の選定プロセスに落とし込む際の実行ガイドとしてご活用ください。

5 フェーズ実行チェックリスト

以下は 5 フェーズごとに「AI プロンプトで整理する項目」と「人間だけで判断する項目」を分けたチェックリストです。

フェーズ 1: プロジェクト要件の言語化

• プロジェクト目的・現状課題・想定技術スタックを AI で構造化した
• 要件書ドラフトの抜け漏れ質問リストを 10 項目以内で作成した
• 抜け漏れ項目を社内関係者に確認し、要件を確定した
• 機密情報が含まれる場合は、社内承認済みの AI 環境で実施した

フェーズ 2: 求めるエンジニア像（ペルソナ）設計

• 理想像・現実的な妥協ライン・最低ラインの 3 段階でペルソナを作成した
• 必須スキルとあると望ましいスキルを区別してリスト化した
• 除外条件（このタイプは合わない特徴）を先に言語化した
• 過去実績として確認したい具体例を明文化した

フェーズ 3: 面談質問リスト生成

• 技術質問・行動特性質問・相互確認質問の数を面談時間から逆算した
• 各質問の期待回答レベル（初級/中級/上級）を明記した
• 候補者の職務経歴書を使う場合、個人情報を匿名化した
• 面談時間の 20〜30% を候補者からの逆質問時間に確保した

フェーズ 4: 提案書・見積書の観点別レビュー

• 技術的アプローチの妥当性を AI に確認させた
• 工数見積の妥当性を業界水準と突き合わせた
• 営業スクリプト警戒（汎用テンプレート文言の抽出）を実施した
• AI 提示の「業界水準」は複数情報源で裏取りした

フェーズ 5: 選定判断の理由書き起こし

• 3 候補比較の評価軸を 5〜7 個で作成した
• 各候補を 3 段階（◎/○/△）で評価する表を作成した
• 想定される社内反対意見と回答準備を用意した
• 選定リスクを 3 つ明示し、稟議書に添付した

明日から始める 3 ステップ

すべてのフェーズを最初から完璧に導入する必要はありません。以下の 3 ステップで段階的に始めることをおすすめします。

ステップ 1（1 日目）: 現在進行中または直近予定のエンジニア選定プロジェクトを 1 つ選び、フェーズ 1（要件言語化）のプロンプトを実行する。AI が指摘した抜け漏れ質問を社内関係者に共有し、要件を再確認する。

ステップ 2（1 週間以内）: 面談を実施予定であれば、フェーズ 3（面談質問リスト生成）を実行する。AI が生成した質問リストから、実際に使う 15 問前後を担当者が選び取る。面談後、AI が想定した回答レベルと、実際の回答レベルを比較して、AI 補助の有効性を検証する。

ステップ 3（1 ヶ月以内）: 提案書が届いたら、フェーズ 4（提案書レビュー）を実行する。案件固有性スコアが低い候補には再提案を依頼する。最終選定時にフェーズ 5（選定判断の書き起こし）を実行し、稟議書に添付する。

AI Overview（SGE）時代においても、外部エンジニア選定の意思決定を下すのは人間です。ただし、良い問いを立てられる発注者は、AI からより深い情報を引き出し、より質の高い選定判断ができるようになります。本記事で紹介したプロンプトはあくまで出発点であり、自社の事業・技術・体制に合わせてカスタマイズすることで真価を発揮します。

最終判断は人間が持ち、AI は判断の壁打ち相手として活用します。この距離感を保ちながら、選定プロセスに生成 AI を組み込んでいくことが、変化した情報環境の中で成果を出し続けるための現実的な戦略です。