プロンプトエンジニアリングとは？発注者が知るべき工数と判断基準
AI開発の提案書や見積書を確認していると、「プロンプトエンジニアリング工数: 〇〇時間」という項目が記載されていることがあります。担当エンジニアに聞いても「AIへの指示文を最適化する作業です」と言われるだけで、なぜその工数が必要なのか、妥当な費用なのかを判断しにくいと感じる方も多いでしょう。
プロンプトエンジニアリングは、AIシステムの精度を決定づける重要な工程です。AIモデルを購入・導入するだけでは精度は出ず、「どのような指示を与えるか」を設計・改善する作業が必ず必要になります。この工程を正しく理解しておかないと、見積もりの評価を誤ったり、品質管理の議論で発注者側から適切な質問ができなくなります。
実際に「複数のベンダーから見積もりを取ったが、プロンプト設計の工数がそれぞれ大きく異なり、どれが妥当か判断できなかった」という声もよく聞かれます。同じ機能でも、プロンプトエンジニアリングの見積もりが10時間から100時間まで幅があるのはなぜか、この記事を読んだ後には説明できるようになります。
この記事では、発注者として把握すべきプロンプトエンジニアリングの基本概念、工数の中身、ファインチューニングやRAGとの違い、そして見積もり書を確認する際のチェックポイントを解説します。AIシステム開発の意思決定に直接役立てる内容です。この記事の構成として、まず概念の理解、次に工数の実態、そして比較・判断基準の順に進みます。
目次
社内で ChatGPT を使い始めるための実践ガイド――ルール策定・安全なプロンプト設計・部門展開テンプレート付き
この資料でわかること
こんな方におすすめです
プロンプトエンジニアリングとは？AIに「正確な指示」を与える技術
プロンプトとは何か（「AIへの指示文」の正体）
プロンプト（Prompt）とは、ChatGPTやClaude、GPT-4などのLLM（大規模言語モデル）に入力するテキストのことです。単純に言えば「AIへの指示文」ですが、この指示の質がAIの出力品質を大きく左右します。
たとえば、同じAIモデルに対して「契約書をチェックして」と指示するのか、「あなたは法務専門家です。以下の業務委託契約書を発注者の立場から確認し、不利な条項・リスクのある表現を箇条書きで指摘してください。背景：自社はシステム開発会社で、外部ベンダーへ業務委託する際のひな形として使う予定です」と指示するのかでは、出力の精度が大きく異なります。
前者の指示では汎用的なコメントしか得られませんが、後者の指示では発注者視点の具体的なリスク指摘が得られます。この違いを生み出すのがプロンプトの設計力です。
プロンプトエンジニアリングとは、LLMから期待通りの出力を得るために、入力文（プロンプト）を体系的に設計・改善する技術・プロセスを指します。「AIに適切な指示を出す技術」と言い換えることもできます。
なぜプロンプト設計が必要なのか（精度への影響を具体的に）
「高性能なAIモデルを使えば、指示の仕方は関係ないのでは」と思う方もいるかもしれません。しかし実際には、同じAIモデルを使っても、プロンプトの設計次第で精度が50%前後から90%以上まで変動することが珍しくありません。
AIシステム開発で精度が求められる場面（請求書の自動分類、問い合わせの自動回答、契約書のリスク抽出など）では、プロンプト設計なしに求める精度水準に到達することはほぼ不可能です。そのため、AIシステム開発プロジェクトでは、プロンプトエンジニアリングは必須の工程として位置付けられています。
プロンプトエンジニアリングの主な作業内容（工数の中身）
発注者として最も気になるのは「この工数で何をやっているのか」という点でしょう。プロンプトエンジニアリングの主な作業内容は以下の通りです。
システムプロンプト設計とは（AIの「役割と基本ルール」の定義）
システムプロンプトとは、AIの基本的な役割・振る舞いを定義する指示文です。「あなたは〇〇の専門家です」「以下のルールに従って回答してください」という形で、AIの動作の土台を設定します。
システムプロンプトの設計は、AIシステムの用途・目的を明確にし、それをAIが理解できる形式で記述する作業です。用途によって複雑さが異なりますが、一般的に以下の内容を含みます。
- 役割設定: AIにどのような専門家・担当者として動作させるか
- 制約条件: 回答すべきでないことの定義（個人情報の扱い・ハルシネーション対策など）
- 出力フォーマット: 回答の構造（箇条書き・表・文章形式など）
- 背景情報の提供: 業界・企業・用途のコンテキスト
精度検証と改善サイクル（なぜ反復が必要なのか）
プロンプトは「一度作れば終わり」ではありません。設計後には必ず精度検証が必要で、その結果をもとに改善を繰り返します。
典型的な作業サイクルは以下の通りです。
- テストデータの準備: 実際に処理させる想定のデータを収集・整理する（例：過去の問い合わせメール200件）
- プロンプトの初期設計: システムプロンプトとサンプル例示を作成する（初回: 5〜10時間が目安）
- 精度測定: テストデータに対してAIを動作させ、正解率・エラーパターンを分析する
- 原因分析と修正: 精度が出ない原因（指示の曖昧さ・例示不足・制約不足など）を特定し、プロンプトを修正する（1サイクルあたり: 5〜10時間）
- 再検証: 修正後のプロンプトで再度精度を測定する
このサイクルを目標精度に達するまで繰り返します。業務に使えるレベル（精度80〜95%程度）に達するまでに、通常3〜5回程度の反復が必要です。工数の大部分はこの「検証と改善の繰り返し」に費やされます。
プロンプトエンジニアリング vs ファインチューニング vs RAG（選択の判断基準）
3手法の違いをコスト・効果で整理する
AI開発の見積もりには、プロンプトエンジニアリング以外に「ファインチューニング」「RAG」という手法が登場することがあります。これらはどのような場面で選択されるのでしょうか。
手法 |
コスト |
追加データ |
適した場面 |
備考 |
|---|---|---|---|---|
プロンプトエンジニアリング |
低〜中（数万〜数十万円） |
不要 |
汎用タスク・スピード重視・少量データ |
まず最初に試みるべき手法 |
RAG（検索拡張生成） |
中（数十万〜数百万円） |
必要（社内ドキュメント等） |
社内知識の参照・最新情報への対応 |
ベクトルDB構築が必要 |
ファインチューニング |
高（数百万〜数千万円） |
必要（大量の例データ） |
特定専門ドメインへの深い特化 |
学習コストが高い |
選択の基本的な考え方としては、「まずプロンプトエンジニアリングで試み、それで達成できない場合にRAGやファインチューニングを検討する」という順序が実務上の定石です。プロンプトエンジニアリングで求める精度が出るなら、追加コストをかける必要はありません。
発注者が確認すべき「手法選定の根拠」
見積もりにRAGやファインチューニングが含まれている場合、発注者として以下を確認することをおすすめします。
RAGが提案されている場合
- 「プロンプトエンジニアリングでは対応できない理由は何か？」
- 「参照させる社内ドキュメントの整備は、プロジェクト費用に含まれているか？」
- 「RAGなしの場合と精度の差はどの程度か？」
ファインチューニングが提案されている場合
- 「ファインチューニング用の学習データは何件必要か？自社で準備できるか？」
- 「ファインチューニング後のモデルの保守費用は？」
- 「まずプロンプトエンジニアリングで試した結果を見せてもらえるか？」
見積もり書のチェックポイント（プロンプトエンジニアリング工数の妥当性判断）
プロンプト工数の相場感（タスク規模別）
プロンプトエンジニアリングの工数は、タスクの複雑さと必要な精度水準によって大きく変わります。以下は目安感です（実際のプロジェクトによって異なります）。
タスク規模 |
工数目安 |
具体例 |
|---|---|---|
シンプルな分類・判定 |
10〜30時間 |
問い合わせの「対応要否」を2択判定 |
中程度の抽出・要約 |
30〜80時間 |
契約書から特定条項を抽出・整理 |
複雑な生成・マルチステップ |
80〜200時間以上 |
複数ステップを経由した提案書自動生成 |
工数を左右する主な要因は以下の通りです。
- タスクの複雑さ: 単純な2択判定 vs 複数要素を考慮した判断
- 精度目標: 80%でよいのか 95%以上が必要なのか
- エッジケースの多さ: 例外パターンが多いほど改善サイクルが増える
- ドメイン専門性: 一般的な業務 vs 法律・医療・金融などの専門領域
発注者が使える「見積もり確認チェックリスト5項目」
見積もりにプロンプトエンジニアリング工数が含まれている場合、以下の5点を確認することで妥当性を判断できます。
1. タスクの定義が明確か 「何を入力して、何を出力させるのか」が具体的に定義されているか確認します。曖昧な定義のまま工数が積まれている場合は、まず仕様の明確化を求めましょう。
2. 精度目標が設定されているか 「精度〇〇%を目標とする」という数値目標があるか確認します。目標がなければ、どこで作業を終えるかの基準がなくなり、工数が際限なく増える可能性があります。
3. テストデータの準備者が明確か 精度検証に使うテストデータを誰が準備するか確認します。自社業務データが必要な場合、発注者側の準備工数が発生することがあります。
4. 改善サイクルの回数・期間が明示されているか 「〇回の反復改善を含む」という記載があるか確認します。改善回数が無制限の場合、スコープが膨らむリスクがあります。
5. 手法選定の根拠が説明されているか プロンプトエンジニアリングのみでなく、RAGやファインチューニングも比較検討した上でこの手法が選ばれているかを確認します。
まとめ｜「プロンプト設計」を発注者として正しく理解するために
この記事で解説した主なポイントを整理します。
- プロンプトエンジニアリングとは: LLMから期待通りの出力を得るために入力文を設計・改善する技術。AIシステムの精度を決定づける必須工程
- 工数の中身: システムプロンプト設計・テストデータ準備・精度検証・改善サイクルの繰り返し。工数の多くは「検証と改善」に費やされる
- 手法の選択: まずプロンプトエンジニアリングで試み、必要に応じてRAGやファインチューニングを検討する。コスト感の違いを把握した上で提案を評価する
- 見積もりの確認: タスク定義・精度目標・テストデータ準備者・改善サイクル数・手法選定根拠の5点を確認することで妥当性を判断できる
発注者として適切な仕様定義（精度目標・対象タスクの明確化・テストデータの準備）を行うことが、プロンプトエンジニアリング工数を適切にコントロールする上で最も重要です。
「AI開発の見積もりを受け取ったが、内容が妥当かどうか判断したい」「自社業務にAIを導入したいが、何から始めればよいかわからない」という場合は、秋霜堂株式会社にお気軽にご相談ください。AIシステム開発の初期段階からプロンプト設計・精度検証を一貫してサポートしています。無料相談も受け付けていますので、見積もり書をお持ちの方は内容を一緒に確認することも可能です。
関連する記事として以下もご参考ください。
社内で ChatGPT を使い始めるための実践ガイド――ルール策定・安全なプロンプト設計・部門展開テンプレート付き
