生成AI案件のバックエンド開発、どこまで外注できる？
- 15 時間前
- 読了時間: 10分
顧客から生成AI機能を求められたとき、元請けのSIer・Web開発会社がすべてを自社で実装する必要はありません。
ただし、「AI APIを呼ぶ部分だけ」を外へ出すと、プロンプトの保守、API利用料、検収条件、更新系処理の責任が曖昧になりやすくなります。 生成AI案件では、AIそのものより先に、外注先へ渡す「業務上の1機能」と責任分界を決めることが重要です。
はじめに：生成AI案件で難しいのは、モデル選定より外注範囲
顧客から「既存システムに生成AIを追加したい」と相談されたとき、モデル選定やプロンプト設計から考え始めると、外注範囲が決まりにくくなります。
元請け側が先に決めたいのは、「その機能が何を受け取り、何を返し、どの業務データやAPIへアクセスし、どこまで動けば検収できるのか」です。
たとえば、「生成AI API連携一式」とだけ依頼すると、既存DBからデータを取る処理、プロンプトの初期作成、出力形式の検証、失敗時の再試行、利用料の負担まで、誰の責任なのかが残ります。
生成AI案件でも、バックエンド外注の基本は変わりません。技術要素ではなく、業務上の1機能として成果物を切ることが出発点です。
結論：「AI API連携」ではなく、検収できる業務機能で切り出す
悪い切り方と、切り出しやすい形を比べると分かりやすくなります。
切り方 | 例 | 問題 |
技術要素だけで切る | 「生成AI APIを呼び出す処理」 | 入出力、既存データ連携、エラー処理、品質責任が残る |
業務機能で切る | 「申請内容を受け取り、分類結果と要約を所定形式で返すAPI」 | API契約と検収条件を定義しやすい |
後者なら、外注先の成果物を、API仕様、モデル呼び出し、既存DB・API連携、出力検証、ログ、タイムアウト、テストまで含めて定義できます。
一般的なバックエンド外注の考え方は、バックエンド開発を外注するとき、どこまでを成果物として切り出せるのかで解説しています。生成AI案件では、そこへプロンプト・モデル・評価・利用料・実行権限という固有の責任分界が追加されます。
そして、成功条件を事前に定義できるなら請負で切り出しやすく、まだ「何をもって良い回答とするか」自体を探る段階なら、技術調査やPoCを準委任で先に切り出すほうが進めやすい場合があります。
生成AI案件では、5つの責任分界を先に決める
1. モデルAPIの契約・アカウント・利用料を誰が持つか
多くの生成AI APIでは、モデルを呼び出す利用量に応じて費用が発生します。さらに、モデルやツールの使い方によって消費量は変わります。
そのため発注時に、少なくとも次を決めておきます。
API契約を顧客・元請け・外注先の誰が持つか
APIキーを誰が管理するか
利用料を誰が負担するか
利用上限や予算アラートを誰が設定するか
利用モデルを変更できるのは誰か
入力データの保持・学習利用の条件や利用リージョンを誰が確認するか
運用開始後も使い続けるシステムなら、顧客または元請けが契約主体となり、外注先には必要な範囲の認証情報だけを渡す形が管理しやすいケースがあります。ただし、外注先がサービスとしてモデル利用まで含めて提供する形もあるため、どちらが正しいという話ではありません。
重要なのは、開発費とは別に発生するモデル利用料の責任者を曖昧にしないことです。
2. プロンプトと出力仕様を誰が保守するか
プロンプトは「一度作って納品したら終わり」とは限りません。
顧客の業務ルールが変わる、新しい入力パターンが増える、モデルを変更する、といった理由で調整が必要になることがあります。
そのため、初回納品物にどのプロンプトや設定を含めるかに加え、納品後の変更を誰が行うかも決めておきます。
また、生成AIの出力を後続処理で使う場合は、自由文のままではなく、JSON Schemaなどで形式を固定する方法があります。OpenAIのStructured Outputsなど、指定したスキーマへ出力形式を合わせる機能も提供されています。
ただし、形式が正しいことと、内容が業務上正しいことは別です。 スキーマ検証と、業務ルール・内容品質の検証は別の責任として扱います。
3. どのデータと業務操作をAIから使えるようにするか
生成AIが既存DBを参照したり、業務APIを呼び出したりする場合、モデルへ広い権限を持たせることは避けます。
Anthropicの「Tool use with Claude」やAmazon Bedrockのtool useの公式仕様でも、クライアント側のツール利用では、モデルがツール利用を要求し、実際の処理はアプリケーション側が実行する構成が示されています。
つまり、モデルが操作を提案しても、実際にDBや業務APIを動かす責任はバックエンド側に残せます。
利用可能なAPIを必要最小限にする
引数を通常コードで検証する
利用者の権限を下流システムでも再確認する
金銭・送信・削除など影響の大きい処理は人の承認を挟む
といった境界を、外注範囲に含めるか明示します。
4. 失敗・再試行・利用量をどこまで制御するか
生成AI APIも外部サービスなので、タイムアウトや一時的なエラーを前提にします。
一方で、通常のAPIと異なり、同じ処理を再試行しても、文章や判断結果が完全に同じになるとは限りません。また、再試行回数が増えれば利用量も増えます。
そのため、
タイムアウト
最大再試行回数
二重実行防止
利用量・処理時間のログ
異常時に人へ戻す条件
を決めます。
OWASPの「Top 10 for LLM Applications 2025」でも、Prompt Injection、Improper Output Handling、Excessive Agency、Unbounded Consumptionなどが主要リスクとして挙げられています。生成AIの結果を無条件に信用して処理を進めるのではなく、入力・出力・権限・実行回数をアプリケーション側で制御する設計が必要です。
5. 何をもって検収とするか
生成AI案件を請負で切り出すうえで、最も重要なのが検収条件です。
「自然で良い文章が出ること」のような条件だけでは、発注側と受注側で判定が分かれやすくなります。
そこで、たとえば次のように分けます。
API仕様どおりに応答する
必須項目が所定形式で返る
エラー時に決めた状態・コードを返す
合意した評価ケースで必要な要素を含む
含めてはいけない内容や、必ず人へ戻す条件を満たす
文章の完全一致ではなく、形式・必要要素・禁止要素・業務上許容できない失敗を検収条件へ落とします。
モデルやプロンプトを後から変更する場合に、誰が再評価を行うかも合わせて決めておくと、保守範囲を整理しやすくなります。
「請負向き」「条件付き」「準委任から」の3つに分ける
生成AI案件を外注するときは、AIが何をするかではなく、検収条件をどこまで固定できるかで契約の切り方を考えると整理しやすくなります。
請負で切り出しやすい
次のような状態です。
入力と出力が決まっている
参照するDB・APIが決まっている
出力形式が決まっている
評価ケースと合格条件を決められる
最終判断は人が行い、自動更新範囲が小さい
たとえば、既存システムから申請内容を受け取り、「分類」「要約」「要確認フラグ」を所定形式で返すAPIなどです。
この場合は、通常のバックエンドAPIと同じように、仕様・試験・成果物を定義しやすくなります。
条件を決めれば請負にしやすい
必要な機能は決まっているものの、生成品質に調整余地があるケースです。
初期プロンプトをどこまで納品範囲に含めるか
何回まで調整するか
どの評価データを検収に使うか
モデル変更を納品範囲に含めるか
を決めれば、請負範囲を作れる可能性があります。
「完成後も無制限に回答品質を上げ続けること」を請負条件にしないことが重要です。
準委任や技術調査から始めたほうがよい
次のような状態では、いきなり完成形を請負で固定するより、調査工程を先に分けるほうが現実的です。
AIに任せる業務自体がまだ決まっていない
良い回答の評価基準が決まっていない
どのデータを使えば精度が出るか分からない
複数モデルを比較する必要がある
RAGやツール実行を含め、方式選定から必要
この場合は、小さな技術調査・PoC・評価設計を準委任で行い、その結果をもとに、検収可能な部分だけを請負開発へ移す方法があります。
成果物単位で切り出す考え方は、システム開発を「人月」ではなく「機能・成果物単位」で外注するにはも参考になります。
具体例：元請けは画面と顧客調整を持ち、AIバックエンドだけ外注する
SIerが、顧客の申請管理システム改修を受注したケースを考えます。
顧客からは「申請内容をAIで読み、担当部署の候補と要約を表示したい」という要望が出ています。
元請け側は、顧客との要件調整、画面改修、既存システム全体の受入を担当します。
外注先へは、次のバックエンド機能を成果物として切り出します。
申請IDを受け取るAPI
既存APIから申請本文を取得する処理
モデルへ渡す入力の組み立て
生成AI APIの呼び出し
「担当部署候補」「要約」「要確認フラグ」の形式検証
タイムアウト・再試行・エラー処理
処理ログ
合意した評価ケースによる試験
この場合、「AI連携一式」と発注するのではなく、既存システムから呼べる1本のバックエンド機能として定義するのがポイントです。
さらに、APIアカウントは元請け側、初期プロンプトは外注範囲、納品後の業務ルール変更に伴うプロンプト改善は追加対応、といった保守境界まで個別契約や発注条件へ落とします。
バックエンド一般の責任分界については、バックエンド開発を外注するとき、責任分界はどう決めるべきかも参考になります。
更新系のAI機能では「モデルが決めたから実行する」にしない
生成AIが回答案を返すだけなら、失敗時の影響を人が止めやすい一方、更新系の業務APIまで実行させる場合は責任分界が変わります。
たとえば、外部から届いた問い合わせ本文や文書には、モデルの挙動を意図せず変える記述や、悪意のある指示が含まれる可能性があります。こうしたPrompt Injectionは、OWASPのLLM向け主要リスクにも挙げられています。
そのため、「入力をきれいにすれば安全」と考えるのではなく、外部入力を信頼しない前提で、
AIから利用できる操作を限定する
更新APIの権限を最小化する
引数と出力を通常コードで検証する
下流システム側でも認可する
影響の大きい処理は人が承認する
操作ログと利用量を残す
という設計にします。
すべての処理に人の承認が必要という意味ではありません。取り消し可能で影響が社内に閉じる処理は自動化しやすい一方、金銭、外部送信、削除、契約状態の変更など影響が大きい処理ほど、承認を残す判断が重要になります。
AIに判断候補を出させても、実行可否を保証するのは通常コード側と分けると、外注先の責任範囲も定義しやすくなります。
プレイリーソリューションズが担当しやすい範囲
当社が生成AI案件でまず担当領域として想定しているのは、AIモデルそのものの研究開発ではなく、生成AIを既存の業務システムの中で安全に動かすためのバックエンド領域です。
たとえば、
既存システムから生成AI機能を呼び出すためのAPI設計・実装
生成AIへ渡す業務データの取得・整形と、利用者の権限に応じた絞り込み
モデルAPIの呼び出しと、タイムアウト・再試行・レート制限・利用量の記録
構造化されたAI出力の検証と、既存システムで扱えるデータ形式への変換
AIがツール利用を要求したときの、業務APIの実行可否・引数・権限・承認の制御
どの入力・モデル・設定で結果が出たかを追跡できるログと、異常時に人へ戻す仕組み
といった範囲です。
これらは、Java / AWS、既存DB、外部API連携といった当社の既存のバックエンド技術を、生成AI機能の前後へ適用する領域です。
筆者は、決済を含む外部APIを既存の業務システムへ組み込む開発で、APIを呼び出せること自体より、その結果を既存の業務状態へどう反映し、失敗時にどう追跡・復旧できるかが運用を左右すると考えてきました。
生成AIでも、モデルの出力をそのまま業務処理へ流すのではなく、既存システムとの境界をバックエンド側で持つという考え方は共通します。
生成AI固有の評価方法や安全策については、案件要件と技術検証を踏まえて対応範囲を確定します。最初から「AI開発一式」と大きく切るのではなく、既存システムとの接続部分や調査工程から分ける進め方も可能です。
まとめ：外注先を探す前に「AI以外の責任分界」を決める
生成AI案件を外注するときは、「どのモデルを使うか」だけでは範囲を決められません。
先に決めるべきなのは、
何を1つの業務機能として納品するか
API契約・利用料を誰が持つか
プロンプトを誰が保守するか
AIが使えるデータ・操作をどこまでにするか
何をもって検収するか
未確定部分を請負にするか、準委任で先に調べるか
です。
これらを決めれば、生成AI機能も通常のバックエンド開発と同じように、外注範囲を成果物単位へ落としやすくなります。
SIer・Web開発会社・DX支援会社の方で、顧客から生成AI機能を求められ、「どこまでを自社で持ち、どこからバックエンド開発として切り出すか」を整理したい場合は、プレイリーソリューションズへご相談ください。AI固有部分を無理に一括で請けるのではなく、既存システムとのAPI境界や技術調査を含め、切り出せる範囲から整理します。
