1. はじめに
こんにちは。株式会社レトリバでエンタープライズ案件や生成AI案件のプロジェクトマネージャーをしている野沢です。
このZennでは、私たちが日々の業務や検証の中で得た知見を（趣味も含め）発信していきます。技術的な実験からちょっとした工夫まで、気軽に読める記事を目指しています。
今回は、プロンプトを活用してエンジニア視点を広げる実践的な話を取り上げます。
「十分考えたつもりだったのに、
上司からは『このスケジュールで本当に間に合うの？』、経営層からは『で、利益にどうつながるの？』と、技術以外の角度から突っ込まれた経験はありませんか？」
私も一生懸命準備したのに、思わぬ観点で突っ返されて悔しい思いをしたことがあります。
でも、その“違う角度”こそが事業を動かす視点であり、私たちが強くなるために必要なものです。
ここで大事なのは、「AIにプロンプトを書かせる」ことそのものではありません。
自分でプロンプトを書くと、どうしても想定内の観点にとどまります。
けれども、実際に受けた指摘を素材としてAIに渡し、背景や意図を推定させると、思いがけない“想定外の視点”を取り込めるようになります。
ポイント：技術の正解と、経営の正解は必ずしも同じではない
本記事では、日々の実務に即してプロンプトを工夫し、AIを“壁打ちの相手”として強化する方法と、さらに一歩進めてAIにプロンプト自体を設計させる方法を紹介します。
2. AIに“上司役”をやらせる
普段はコードレビューや同僚レビューが壁打ちの中心。
でも、上司や経営層からの「別の観点でのツッコミ」を事前に想定できると、成果物の説得力は段違いに増します。
- 上司：「このスケジュールで本当に回る？運用リソースは足りる？」
- 経営層：「収益性やリスクは？競合と差が出る？」
- 顧客（間接的に）：「導入後も現実的に運用できるの？」
プロンプトで「上司なら？ 経営層なら？」と問い直すことで、自分の盲点を非同期・無制限にセルフレビューできます。
ポイント：「AIを“もう一人の上司役”にする」「仮想の経営層といつでも打ち合わせできる」
3. 体験談①：経営層レビューでの“利益の壁”
状況：技術的に美しいアーキテクチャーとPoC結果を揃えたのに、経営会議でひとこと──
「リスク分は、利益に織り込めてるの？」
数字の裏付けが弱く、議論が空転しました。
気づき：必要だったのは、「技術を利益に翻訳する力」。
ポイント：技術を利益に翻訳する力
効いたプロンプト例（CEO役）
あなたはCEOです。以下の提案について、
- 収益性：直接売上 / 間接LTV
- 費用：初期 / 運用 / 要員コスト / リスク対策
- ROI：回収期間と、前提条件を変えたときの振れ幅
これらの観点から弱点を洗い出し、
「経営層が突っ込みそうな3問」を出力してください。
実際の出力例（抜粋）
- 指摘：「ROIが示されているが、最悪ケースでの回収不能リスクが考慮されていない」
- 根拠：「想定コスト変動幅が狭すぎる」
- 改善：「リスクシナリオ別の損益分岐を追加」
→ レビュー前に弱点を把握でき、会議準備の時間が短縮できた。
※ROI＝投資回収率、LTV＝顧客生涯価値
4. 体験談②：顧客視点の“抜け落ち”問題
よくあるズレ
- 例：クラウド前提で見積 →顧客はオンプレ必須
- 例：新モデル採用 →社内セキュリティ審査に数ヶ月
- 例：「まずは小さく試したい」 →PoC設計が大きすぎる
気づき：技術のベストと、顧客のベストは違う。
もちろん、顧客事情をすべてエンジニアが把握するのは現実的ではありません。
営業や上司からのヒアリング不足、顧客からの要件伝達の遅れなど、原因は複合的です。
ただし、エンジニアの立場でも「これって大丈夫かな？」と感じた時に
一度立ち止まって確認できるかどうかで、提案の精度は大きく変わります。
効いたプロンプト例（顧客調整役）
あなたはエンタープライズ顧客のCIO補佐です。以下の提案をレビューしてください。
観点：
- セキュリティ審査
- インフラ制約（オンプレ/クラウド可否/ネットワーク分離）
- 顧客側の運用リソース
- 段階導入（PoC→本番）
さらに「聞き落としている可能性が高い顧客制約」があれば補足してください。
5. 実践例：AIに“プロンプトを書かせる”
ここからが本題です。
単に「チェック用プロンプトを自分で書く」だけでは、自分の想定内の観点しか出てきません。
そこで有効なのが、過去に突っ込まれた指摘を材料に、AI自身にプロンプトを書かせる方法です。
流れ
- これまでに上司や経営層から言われた指摘を列挙する
例：「スケジュール詰めすぎ」「運用リソースは誰がやるの？」「リスク分を利益に載せろ」 - それをAIに渡し、「レビューBot用のプロンプトを作って」と依頼する
- AIが「指摘の背景や意図」を推定し、それを観点化してくれる
ポイント：AIは「レビュー役」だけでなく、「レビュー観点そのものを設計してくれる」
入力例
これまで上司や経営層から言われたこと：
- スケジュール詰めすぎ
- 運用リソースを誰が担うか曖昧
- リスク分を利益に織り込めてない
- ベテランがミスなく作業した場合の工数を提示するのはリスク高い、見積はその2倍を目安に
- 会社のナレッジを活用しないスクラッチ提案はリスク高い
このような指摘に加え、エンタープライズ案件でありがちな制約も考慮して、
「レビューBot用のプロンプト」を生成してください。
良い点/悪い点/根拠/改善案を整理し、人が理解しやすい形にしてください。
AIが生成したプロンプト（出力イメージ）
あなたは上司です。以下の提案をレビューしてください。
観点：
- スケジュールの現実性（人員/工数/並行作業）
- 運用体制（顧客/自社の役割分担）
- リスク反映（利益/価格設定）
- インフラ制約（オンプレ/クラウド可否）
- セキュリティ（データ持ち出し禁止、認証連携）
- 工数見積（ベテラン見積もりの2倍を目安に、妥当性を確認）
- 自社の既存基盤/APIの再利用可否（スクラッチ提案によるリスク増加を避ける）
出力形式：
- 良い点
- 指摘事項
- 根拠
- 改善提案
→ ベテラン2倍ルールや自社基盤再利用など、現場っぽい観点も含まれ、レビュー観点が進化します。これで作りこむ前に対策ができて、手戻りが激減します。
※ここで挙げたルールは一例であり、自社固有のものではありません。
まとめ
- 技術の正解と、経営の正解は必ずしも同じではない
- 上司・経営層の視点をAIにシミュレーションさせると、盲点が浮き彫りになる
- さらに一歩進めて、“プロンプトをAIに考えさせる”ことで、過去の失敗を未来の武器に変えられる
おわりに
プロンプトエンジニアリングは、もはや珍しいスキルではありません。
けれども“経営や顧客の視点を持ち込む”使い方は、まだ取り入れている人は少ないでしょう。
次にレビューを受ける前に、一度AIに「上司ならどうツッコむ？」「顧客なら何を気にする？」と聞いてみてください。
さらに、過去の指摘を材料にAIにプロンプトを書かせることも試してみてください。
その小さな実践の積み重ねが、やがて事業変革に結びつく“種”になります。
株式会社レトリバでは、今後もエンジニアやプロジェクト現場の視点から技術記事を発信していきます。
よければフォローいただき、次回の記事もぜひご覧ください。
Discussion