プロンプトエンジニア業務委託の実務ガイド｜職種特性と発注時の見極め方

「プロンプトエンジニアを業務委託で確保してほしい」——経営層や事業部門からこう指示された発注担当者の多くが、最初にぶつかるのが「そもそもプロンプトエンジニアとは何ができる人なのか」「単価がなぜ月50万円から200万円まで幅広いのか」という壁ではないでしょうか。

求人媒体やフリーランスエージェントを開いても、「ChatGPTを日常的に使いこなせればOK」という案件と、「Python + LangChain + ベクトルDBの実装が必須」という案件が同じ「プロンプトエンジニア」という名称で並んでいます。社内の別の担当者からは「プロンプトくらい自分たちで書けるのでは？」という声も上がり、稟議書に発注理由や単価根拠をどう書けばよいか、材料が揃わないまま社内会議が停滞しがちです。

この状況の背景には、プロンプトエンジニアという職種そのものの新しさと、業務範囲が「自然言語での指示設計」から「LLMを組み込んだシステム実装」までを一括りにされている構造的な曖昧さがあります。適切に整理しないと、発注後に「思っていたのと違う」というミスマッチが起きやすい領域です。

本記事では、発注担当者が社内稟議を通し、実際に成果を出せる業務委託契約に至るまでの意思決定の流れを、以下の順で解説します。まず職種特性を3つの軸で整理し、次に業務委託で発注できる3タイプのパターンを提示します。そのうえで内製と業務委託の判断軸、タイプ別の単価相場、候補者面談での見極めポイント、契約時の実務、よくある失敗と回避策までを一気通貫でまとめました。

読み終えたときには、「自社の目的なら○○タイプのプロンプトエンジニアを月○○万円で業務委託し、成果物は○○として要件定義書に○○を明記する」という具体的な発注プランを描ける状態を目指します。

なぜ「プロンプトエンジニアの業務委託」は判断が難しいのか

プロンプトエンジニアの業務委託を検討する発注担当者が直面する困難は、単に「新しい職種で情報が少ない」という以上のものです。実際には、職種名は一つでも、その内側に業務範囲・スキル要件・単価が大きく異なる複数の職務が同居しているため、判断軸そのものが揃わない状態が生まれます。

単価が月50〜200万円と幅が広い理由

フリーランス案件の情報を集めると、プロンプトエンジニアの月額単価は概ね60万円台から200万円前後まで分布しています。継続案件では80〜150万円、専門特化した案件では120〜200万円というレンジが一般的な目安です（出典: プロンプターズ「プロンプトエンジニアの年収」、2026年）。

同じ職種名でこれほど幅がある理由は、実案件の中身が「ChatGPTを業務プロセスに組み込むためのプロンプト設計・改善」から、「LangChainやLlamaIndexを使ったRAG（検索拡張生成）システムの本番実装」まで、実質的に別の職務にまたがっているためです。前者は自然言語能力と業務ドメイン知識が主軸ですが、後者はPython・API連携・ベクトルDB・エージェント設計といったソフトウェアエンジニアリング全般のスキルが必要になります。

つまり「プロンプトエンジニア」という求人票を出しても、応募してくる人材のスキルセットは大きく分かれます。発注側が「どのレンジの人材が必要か」を明確にしないまま面談すると、優秀な候補者ほど「あなたたちが本当に欲しいのはコピーライターかシステム開発者か」を面談中に見極め、条件が合わないと判断されて逃してしまうケースが起きます。

「社内で書けるのでは？」という疑問

もう一つの壁が、社内から出る「プロンプトくらい自分たちで書けるのでは？」という反論です。ChatGPTのWeb UIで「〇〇について要約してください」と書けるならプロンプト作成は誰でもできる、という感覚は間違ってはいません。

しかし業務での本格活用では、次の3点が個人利用と決定的に異なります。第一に、複数の担当者が同じ品質でプロンプトを再利用できる「テンプレート化」が必要になります。第二に、モデルのバージョン更新や入力データの変動に対して出力が安定する「品質管理」が必要になります。第三に、社内システムや業務プロセスにプロンプトを組み込む場合、API連携・エラーハンドリング・費用管理といったソフトウェアエンジニアリングの視点が必要になります。

これらは個人利用の延長ではなく、明確な専門知識と実装経験が要求される領域です。稟議書で「なぜ業務委託が必要か」を説明する際は、この3点を根拠として整理すると社内合意が得やすくなります。

本記事で解消する3つの疑問

以降のセクションで、次の3つの疑問に順番に答えていきます。

• 何ができる人か: プロンプトエンジニアの職種特性を3つのスキル軸で分解し、レベル感を可視化します
• 何を発注できるか: 業務委託で成立する3タイプの発注パターンを、成果物・単価・稼働形態とセットで提示します
• どう見極めるか: 候補者面談で実力を測るための5つの確認項目と質問例を提供します

この順序は、実際の発注プロセス（職種理解 → 発注範囲確定 → 予算設計 → 候補者選定 → 契約締結）と一致するように構成しています。

プロンプトエンジニアの職種特性を3つの軸で理解する

プロンプトエンジニアという職種を「一つの定義」で捉えようとすると、必ず矛盾が生まれます。実務者が持つスキルは、次の3つの独立した軸の組み合わせで表現するのが実態に合っています。この3軸マトリクスで整理することで、自社が求める人材レンジを「どの軸のどのレベルが必要か」という形で言語化できるようになります。

軸1: 自然言語による指示設計スキル

第1の軸は、自然言語でLLMに指示を出す設計力です。この軸で高いレベルにいる人材は、次の4つの原則を状況に応じて使い分けます。

• ペルソナ設定: 「あなたは金融業界の法務専門家です」のように、LLMに役割を明示することで回答の一貫性を高める
• Few-shot（少数事例提示）: 期待する入出力例を2〜5個示すことで、複雑な指示を暗黙的に伝える
• Chain of Thought（思考の連鎖）: 「ステップバイステップで考えてください」と指示し、推論過程を明示させることで精度を向上させる
• 出力形式の指定: JSON・Markdown・箇条書きなど、後工程で使いやすい形式に整える

これらはOpenAIやAnthropicが公開するPrompt Engineering Guideなどのドキュメントでも体系化されている技法です。個人利用でも触れられる領域ですが、業務で複数プロンプトを組み合わせる場合や、業務担当者に配布するテンプレートを作る場合には、これらを設計思想として理解している人材が必要です。

軸2: AIモデルの挙動理解

第2の軸は、LLMそのものの挙動を理解する力です。LLMは万能ではなく、確率的に文字列を生成する仕組みのため、次のような固有の弱点があります。

• 幻覚（Hallucination）: 事実に基づかない情報を、もっともらしい文体で生成してしまう
• モデル間の得意分野の違い: GPT-4系は論理推論、Claude系は長文文書処理、Gemini系はマルチモーダル処理といった強みの違いがある
• 入力トークン数の制限とコスト: 入力が長くなるほどAPI費用が増え、応答速度も低下する
• バージョン更新による挙動変化: モデルのアップデートで、同じプロンプトでも出力傾向が変わることがある

この軸のレベルが高い人材は、「なぜこのプロンプトが期待通り動かないか」を仮説を立てて改善できます。逆にこの軸が弱いと、うまく動かないときに闇雲にプロンプトを書き換えるだけになり、改善が属人的な試行錯誤に留まります。

軸3: プログラミング・システム統合力

第3の軸は、LLMを既存システムや業務プロセスに組み込むソフトウェアエンジニアリング力です。この軸のレベル感は次のように分かれます。

• Level 1: ChatGPTなどのWeb UIを業務で使いこなせる（プログラミング不要）
• Level 2: OpenAI APIなどをPythonから呼び出し、簡単なスクリプトで自動化できる
• Level 3: LangChain・LlamaIndex等のフレームワークを使い、RAG（社内文書検索と連携した回答生成）やAIエージェントを本格実装できる

Level 3のスキルを持つ人材は、実質的にAIエンジニアやMLエンジニアと呼ばれる領域の実務者です。「プロンプトエンジニア」という肩書きで応募してくる人材の中にもLevel 3の人はいますが、単価は上位レンジ（月120〜200万円）に振れます。

3軸マトリクスによるスキルレベル判定

上記3軸を組み合わせると、発注担当者は候補者の実力を次のような形で把握できます。

自社の目的が「業務担当者がChatGPTを効率的に使えるようにテンプレートを整備する」であれば1行目、「社内文書を検索できるRAGシステムを構築する」であれば3行目、というように、求める人材像がマトリクス上に位置づけられます。この整理を持って求人媒体やエージェントに相談すると、ミスマッチが大幅に減ります。

業務委託で発注できる範囲：3タイプの発注パターン

前の章の3軸マトリクスは「どんな人材がいるか」を整理する枠組みでしたが、業務委託の発注書に書く「何を成果物として受け取るか」の観点では、実案件は次の3タイプに整理すると意思決定がしやすくなります。

タイプA: 純粋プロンプト設計型

• 成果物: 業務プロセスごとのプロンプトテンプレート集、プロンプト運用ガイドライン、出力サンプル
• 単価: 月50〜80万円（週2〜3日稼働）
• 稼働形態: スポット（1〜2ヶ月）または継続支援
• 向いているシーン: 自社の業務プロセス（議事録作成・営業メール草案・調査サマリー等）を効率化するプロンプトを整備し、担当者に配布したい場合

このタイプは、既存の業務にプロンプトを差し込むイメージです。プログラミング作業がほぼ発生せず、ChatGPTやClaudeのWeb UIまたは既存のNo-Codeツール（Zapier・Make等）で完結します。

注意点として、実務市場では「純粋にプロンプト設計だけ」の案件は数として少なく、LLM実装や運用支援とセットで発注されるケースが多いという実態があります（出典: BigData-Navi「プロンプトエンジニアの副業案件動向」）。このタイプ単独で発注する場合は、明確に業務プロセスの効率化に絞ったスコープにしないと、候補者側から「もう少し実装まで含めた案件のほうが単価的にも合う」と辞退されるリスクがあります。

タイプB: LLM実装込み型

• 成果物: LLMを組み込んだ社内ツール、RAGシステム、Slackボットなどの動くシステム一式（ソースコード・ドキュメント含む）
• 単価: 月100〜150万円（週3〜5日稼働）
• 稼働形態: 継続（3〜6ヶ月のプロジェクト単位）
• 向いているシーン: 社内文書を横断的に検索できるRAGを構築したい、営業支援ツールにLLMを組み込みたい、といった実装ありきの依頼

このタイプが実案件で最も多く、プロンプトエンジニアという肩書きの案件のボリュームゾーンです。Pythonでの開発、API連携、簡易的なフロントエンド実装まで含まれ、実質はAIアプリケーション開発者と重なります。

タイプC: AIコンサル型

• 成果物: AI活用戦略のロードマップ、社内AIポリシー、プロジェクト立ち上げ支援、社内勉強会
• 単価: 月120〜200万円（顧問型・週1〜2日）
• 稼働形態: 顧問契約（半年〜1年）
• 向いているシーン: 自社のAI活用全体戦略を立てたい、経営層への説明資料を作りたい、複数プロジェクトを横断的にレビューしてほしい場合

このタイプは、実装よりも意思決定支援と社内浸透に重心があります。金融・医療・製造業など業界特化の実装経験を持つ人材の場合、単価はさらに20〜35%程度のプレミアムがつくことがあります。

3タイプ比較表と発注シーン別の推奨タイプ

自社の発注目的が「既存業務を効率化する道具を配りたい」ならタイプA、「新しいシステムを作りたい」ならタイプB、「AI活用の方向性を経営層と揃えたい」ならタイプCが基本の対応です。複合的な目的の場合は、まずタイプCで戦略を立てた後にタイプBで実装、というフェーズ分けの発注も現実的です。

内製と業務委託の判断軸：本当に外注すべきかを見極める

社内で必ず出るのが「そもそも外注する必要があるのか」という問いです。稟議を通すには、この問いに正面から答え、内製で対応できる範囲と業務委託が有効になる境界を明示する必要があります。

プロンプト業務の3段階

プロンプト業務は、社内での成熟度に応じて次の3段階に整理できます。

• 段階1: 単発利用: 業務担当者が個別にChatGPT等で自然言語プロンプトを使う。品質は担当者依存
• 段階2: テンプレート化: 部門やチームで共有できるプロンプトテンプレートを整備し、品質を均一化する
• 段階3: システム組み込み: 社内システムやプロダクトにLLMを組み込み、業務プロセスに統合する

内製で完結できるケース

段階1（単発利用）は、外部人材を入れる必要はほぼありません。社内勉強会や公開資料（Prompt Engineering Guide など）を活用すれば、担当者個人が自走できます。

段階2（テンプレート化）も、社内に自然言語処理やドキュメンテーションが得意な人材がいれば内製で進められます。ただし、次の条件を満たす必要があります。

• テンプレートの品質を評価・改善できる人がいる（出力の良し悪しを判定できる業務ドメイン知識）
• テンプレートの運用管理（バージョン管理・利用状況の把握）を担う人がいる
• モデルのバージョン更新に追随して継続的にメンテナンスできる体制がある

この条件を満たせない場合は、次に述べる業務委託の対象になります。

業務委託が有効になるケース

業務委託が有効になるのは主に次のシーンです。

• 段階3への移行時: システム組み込みには実装スキルが必要で、社内にPythonやLLMフレームワークの経験者がいない場合、外部人材の起用が現実的
• 段階2でも品質評価軸が定まっていない場合: 「良いプロンプトとは何か」の判断軸そのものを外部から持ち込みたい場合
• 短期集中で立ち上げたい場合: 3〜6ヶ月で成果を出したいが、社内人材の学習コストを許容できない場合

稟議書には、これらのうち自社に該当する項目を「発注理由」として明記すると説得力が上がります。

判断フロー

以下のフローで内製と業務委託を切り分けると意思決定が早まります。

1. 目的は段階1・2・3のどれか？
2. 段階1 → 内製で対応可能。外注不要
3. 段階2 → 社内に評価者・運用管理者がいるか？ いれば内製、いなければタイプA発注
4. 段階3 → 社内にPython・LLMフレームワーク経験者がいるか？ いれば内製と外注の混成、いなければタイプB発注

この判断結果を稟議書に「発注理由の背景」として添付すると、経営層や調達部門の合意形成がスムーズになります。

業務委託での単価相場と稼働形態

稟議書で最も詰まりやすいのが単価根拠の記載です。ここでは3タイプそれぞれの単価レンジと稼働形態を、予算計画に落とし込める粒度で整理します。

タイプ別・スキルレベル別の月額単価

これらのレンジは複数の求人媒体・エージェントの公表値を統合した目安です（出典: プロンプターズ「プロンプトエンジニアの年収」2026年、BigData-Navi「プロンプトエンジニアの副業案件動向」）。実際の単価は候補者の実装事例・稼働可能日数・業界経験によって上下します。

稼働形態別の使い分け

• スポット（1〜2ヶ月・週2〜3日）: 特定業務のテンプレート整備、PoC（Proof of Concept）の立ち上げ
• 継続（3〜6ヶ月・週3〜5日）: LLM組込システムの本格実装、運用移行までの伴走
• 顧問型（半年以上・週1〜2日）: 戦略立案、複数プロジェクトの横断レビュー、社内勉強会

初回発注の場合、いきなり週5日の長期契約ではなく、スポットで1〜2ヶ月試して成果を見てから継続契約を結ぶという段階的アプローチが、リスクを抑えて成果を出す実務的な進め方です。

単価プレミアム要因

同じタイプでも、次の要素があると単価は10〜35%程度上昇する傾向があります。

• 業界特化: 金融・医療・法務など、専門知識が必要な業界での実装経験
• 複数LLM対応: OpenAI・Anthropic・Google・オープンソースモデルの複数運用経験
• 本番運用実績: PoCではなく本番稼働システムの運用経験
• セキュリティ要件対応: プロンプトインジェクション対策・データ匿名化の実装経験

予算逆算で確保できる人材レンジ

社内稟議で年間予算が決まっている場合、逆算すると次のような組み合わせが可能です。

• 年間600万円（月50万円）: タイプA中級を週2日
• 年間1,200万円（月100万円）: タイプB中級を週3日、またはタイプC上級を週1日
• 年間1,800万円（月150万円）: タイプB上級を週4〜5日、またはタイプC業界特化を週1〜2日

この整理をベースに、「今回は年間○○万円の予算で、タイプ○の週○日契約」という具体的な発注プランを稟議書に記載できます。

発注時の見極めポイント：候補者面談で確認すべき5項目

発注担当者自身がAI領域に詳しくなくても、次の5項目を面談で確認すれば候補者の実力を相当程度見抜けます。各項目に「聞くべき質問例」と「良い回答・危険な回答」の目安を添えます。

過去実装事例の具体度

聞くべき質問: 「直近で担当された案件を、業務ドメイン・使用モデル・成果物の内容・運用期間まで具体的に教えてください」

• 良い回答: 「小売業のカスタマーサポート案件で、GPT-4oとClaude 3.5 Sonnetを比較検証した上でClaudeを採用しました。FAQ回答ボットをLangChainで実装し、6ヶ月運用中で回答精度は初期比+18%です」のように、業界・モデル選定・実装フレームワーク・数値効果まで具体的に語れる
• 危険な回答: 「いろいろなプロンプトを書いてきました」「PoCまでは複数やりました」など、業界・モデル・成果物・運用期間のどれかが曖昧なままの回答

特に注意すべきは、PoC（試作）と本番運用の区別が曖昧な候補者です。本番運用にはPoCとは別次元の課題（費用管理・エラーハンドリング・非機能要件）が発生するため、本番運用経験の有無は発注成否に直結します。

プロンプト改善プロセスの説明力

聞くべき質問: 「特定のプロンプトを改善した際、どのようなPDCAを回されましたか？ 具体的な改善事例を教えてください」

• 良い回答: 「初期プロンプトの出力を50件サンプリングし、業務担当者に3段階評価してもらいました。Few-shotの事例を差し替えたところ精度が15%改善し、その後は評価結果を月次で追跡しています」のように、評価指標・改善サイクル・継続的な追跡が語れる
• 危険な回答: 「試行錯誤で良い出力になるまで書き直しました」のように、評価軸のない属人的な改善しか語れない

モデル選定の判断根拠

聞くべき質問: 「案件でモデルを選定する際、GPT・Claude・Geminiをどう使い分けていますか？」

• 良い回答: 「長文文書処理（10万トークン以上）ではClaude、コード生成ではGPT-4系、画像を含むマルチモーダルではGeminiというように、ユースケースとコスト・精度のバランスで判断しています」のように、判断軸を持って使い分けている
• 危険な回答: 「ChatGPTを主に使っています」「案件で指定されたものを使います」のように、比較検討の視点がない

幻覚・プロンプトインジェクション対策の実践知

聞くべき質問: 「業務での利用時に幻覚やプロンプトインジェクションにどう対処されていますか？」

• 良い回答: 「幻覚対策としてRAGで社内文書に基づいた回答を強制し、出力後にファクトチェック用の別プロンプトで検証しています。プロンプトインジェクション対策としてはユーザー入力とシステム指示を明確に分離し、想定外の指示は拒否させる設計にしています」のように、具体的な対策手法が語れる
• 危険な回答: 「特に対策していません」「そういう問題は聞いたことがあるくらいです」

これらの対策は本番運用では避けて通れない実践知です。この質問に的確に答えられない候補者は、本番運用の経験が浅いと判断できます。

成果物の再現性・品質管理の仕組み

聞くべき質問: 「納品されるプロンプトの品質をどう保証されますか？ 引き継ぎ時にどんなドキュメントを残されますか？」

• 良い回答: 「プロンプト本体・想定入力サンプル・期待出力サンプル・評価スクリプト・変更履歴をセットで納品します。モデルのバージョン更新時に再評価できる仕組みも合わせて用意します」のように、引き継ぎと保守を意識した納品物構成が語れる
• 危険な回答: 「プロンプトのテキストをお渡しします」だけで、再現性や引き継ぎの仕組みへの言及がない

この5項目を面談チェックリスト化して持参すれば、AI領域に詳しくない発注担当者でも候補者比較の軸を持てます。

業務委託契約時の実務ポイントとフリーランス新法対応

プロンプトエンジニアの業務委託契約では、通常のシステム開発案件とは異なる論点が複数あります。契約書の作成前に確認すべき5つのポイントを整理します。

準委任と請負：プロンプト業務ではなぜ準委任が主流か

プロンプト業務では、成果物の完成基準を事前に厳密に定義することが難しい特性があります。「良いプロンプト」の基準は業務担当者の主観と使用状況に依存し、モデルのバージョン更新でも出力が変わり得ます。

このため、成果物の完成責任を負う「請負契約」ではなく、業務遂行そのものを対価とする「準委任契約」を採用するのが実務上の主流です。準委任であれば、モデル変更等の外部要因による出力変動があっても契約履行の妥当性を保てます。

ただし、タイプB（LLM実装込み型）で動くシステムを納品する場合は、システム納品部分は請負・プロンプト設計と運用支援部分は準委任、という混合型で契約するケースもあります。契約形態の選択は自社の法務部門と相談の上で決定してください。

成果物の定義（プロンプト本体+出力サンプル+評価指標）

準委任であっても、実務上は「何を成果物として受け取るか」を明示しないと引き継ぎと品質評価ができません。プロンプトエンジニア案件では、次の3点をセットで納品物として定義するのが推奨です。

• プロンプト本体: 使用しているプロンプトのテキスト（変数・分岐条件込み）
• 想定入力・期待出力サンプル: プロンプトが機能する入出力例（最低10〜20件）
• 評価指標と評価結果: どの観点でプロンプトの品質を測ったか、そのスコア

この3点セットが揃っていれば、担当者交代やモデル更新時にも品質を検証しながら継続運用できます。要件定義書の書き方については、業務委託発注の要件定義書の書き方に、フリーランス新法対応の書面明示6項目も含めて詳しく整理しています。

知的財産権とAI生成物の取り扱い

プロンプトそのものの著作権帰属、そしてAIが生成した出力の著作権帰属を、契約書に明記します。一般的には次の2点を発注者に帰属させる契約が実務上のデファクトです。

• 業務委託で作成したプロンプトの著作権は発注者に帰属
• 当該プロンプトを使ってAIが生成した出力の著作権も発注者に帰属

ただし、AI生成物の著作権の扱いは各国で議論が続いています。日本の現行法（著作権法）では、AIが自律的に生成した出力は原則として著作物と認められない解釈が主流ですが、人間の創作的寄与があれば著作物性が認められる余地があります（出典: 文化庁「AIと著作権に関する考え方について」2024年）。契約書には「著作物性が認められる場合の帰属先」として発注者を指定しておくことで、後日のトラブルを回避できます。

モデルAPI費用の負担・秘密保持・入力データの管理

• API費用の負担: OpenAI・Anthropic等のAPI費用を発注者が負担するか、業務委託先が立て替えて後請求するかを明確にします。本番運用時はAPI費用が月数十万円に達するケースもあり、事前合意が不可欠です
• 秘密保持契約（NDA）: 業務データがLLMに入力されるため、発注者の機密情報を扱う際の取り扱いルール（学習用途への流用禁止・保存期間・削除タイミング）を契約書に含めます
• 入力データの管理: 個人情報や顧客データを含む場合、匿名化・仮名化の要否、データの海外移転可否（OpenAI APIは米国リージョン利用が基本）を確認します

フリーランス新法対応（書面明示6項目・30日前通知）

2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）により、業務委託契約時に発注者は次の6項目を書面またはメール等で明示することが義務化されました（出典: 公正取引委員会「フリーランス法特設ページ」）。

• 業務の内容
• 報酬の額
• 支払期日
• 発注者・受注者の氏名または名称
• 業務委託をした日
• 給付を受領する場所・給付を受領する期日

また、6ヶ月以上継続する業務委託契約を中途解除する場合は、原則として30日前までに予告することが求められます。プロンプトエンジニアの継続契約はこの要件に該当することが多く、契約書のドラフト時点で解除条件を整理しておく必要があります。

プロンプトエンジニア業務委託でよくある失敗と回避策

発注後によく起きる4つの失敗パターンを、兆候・原因・回避策の観点で整理します。事前に潰しておくことで、発注の成功確率が大きく上がります。

失敗1: 成果物の再現性がない

兆候: 納品されたプロンプトを別の担当者が実行すると、期待と異なる出力になる。同じプロンプトを1週間後に実行すると、モデル側の変更で挙動が変わっている

原因: プロンプトの動作条件（モデル名・バージョン・パラメータ・想定入力形式）が明文化されていない

回避策: 前の章で述べた「プロンプト本体+入出力サンプル+評価指標」の3点セット納品を契約時に明記します。加えて、モデルバージョン更新時の再評価責任を業務委託期間中は業務委託先に持たせる条項を入れます

失敗2: モデルAPI費用が想定を超過

兆候: PoC時は月数千円だったAPI費用が、本番運用開始後に月数十万円まで膨らむ

原因: 本番トラフィックを見込んだコスト設計がされていない。長いプロンプト・長い出力・高性能モデルを漫然と使っている

回避策: 契約時に「想定利用量（月間リクエスト数・平均トークン数）」と「上限アラート閾値」を合意します。プロンプトの短縮・軽量モデルへの切り替え・キャッシュ活用など、コスト最適化を成果物に含めます

失敗3: 担当者退任でプロンプトが継承されない

兆候: 業務委託先の担当者が変わった途端、プロンプトの改善速度が落ちる。社内担当者が異動しても引き継ぎが機能しない

原因: プロンプトの設計思想・改善履歴・評価基準が個人の頭の中にあり、ドキュメント化されていない

回避策: 契約時に「設計思想ドキュメント」「変更履歴（Git等）」「月次評価レポート」の納品を必須項目に含めます。可能であれば社内担当者を業務委託先の作業に並走させ、暗黙知を移転する体制を組みます

失敗4: 本番組み込み時に非機能要件が破綻

兆候: PoCでは動いていたLLMシステムが、本番組み込み後にレスポンス遅延・障害時の代替経路欠如・監視の欠如といった問題を露呈する

原因: プロンプト設計にフォーカスするあまり、システムとしての非機能要件（可用性・監視・障害対応）が設計されていない

回避策: タイプBの発注時は要件定義段階で「非機能要件（応答時間・可用性・監視・障害時の代替動作）」を必ず要件に含めます。プロンプトエンジニア単独では対応できない場合、AIエンジニアやSREとの並行発注を検討します。AI領域の人材確保全般については、AIエンジニア採用ガイドも併せて参考にできます

まとめ：プロンプトエンジニア業務委託を成功させる5ステップ

ここまでの内容を、実際の発注プロセスに沿った5ステップに整理します。稟議書やプロジェクト計画書の骨子として、そのまま流用できる形にしました。

• ステップ1: 目的の明確化: プロンプト業務の3段階（単発利用・テンプレート化・システム組み込み）のどこを目指すかを定義します。「業務担当者の生産性向上」「社内システムへのLLM組込」「AI活用戦略の全社浸透」のいずれかに絞り込み、稟議書の「発注目的」欄に記載します
• ステップ2: タイプ判定: 3タイプ（純粋プロンプト設計型・LLM実装込み型・AIコンサル型）のどれが該当するかを判定します。目的とタイプの対応表を稟議書に添付し、「なぜこのタイプか」の判断根拠を明記します
• ステップ3: 予算・単価の逆算: 想定予算からタイプ別の単価レンジと稼働形態を照合し、確保できる人材レンジを特定します。初回発注はスポット（1〜2ヶ月）で試し、成果を見てから継続契約に移行する段階的アプローチが実務的です
• ステップ4: 面談での見極め: 5項目（過去実装事例の具体度・改善プロセスの説明力・モデル選定の判断根拠・幻覚と脆弱性への対策・成果物の再現性）を面談チェックリスト化し、複数候補者を同じ基準で比較します
• ステップ5: 契約条件の詰め: 準委任か請負かの選択、成果物の3点セット定義（プロンプト本体・入出力サンプル・評価指標）、API費用負担、知的財産権、NDA、フリーランス新法対応（書面明示6項目・30日前通知）を契約書ドラフトに反映します

社内にAI人材がいない状態からでも、この5ステップに沿って進めれば、プロンプトエンジニアの業務委託を成果に結びつけることは十分に可能です。重要なのは「プロンプトエンジニア」という職種名の曖昧さに惑わされず、自社の目的をタイプに翻訳し、単価根拠を数字で語れる状態にすることです。

発注ルートとしては、フリーランス向けエージェント・クラウドソーシング・業界特化のマッチングサービスなど複数の選択肢があります。求める人材タイプが明確になっていれば、どの経路でもマッチング精度は大幅に向上します。本記事で整理した3軸マトリクスと5ステップを手元に、自社にとって最適な発注プランを設計してみてください。