AI開発の外注費用｜工程ごとの内訳と、外注を続けるか内製へ戻すかの判断

外注で割高になるのは要件定義と運用改善

AI開発の外注費と内製の費用を比べるとき、見積書の合計額どうしを並べても判断はつきません。金額の差が出るのは実装の単価ではなく、その前後の工程だからです。工程で分けると、費用は次の3つに出ます。

1. 要件定義 … 何を作るかを決めるまで。業務の手順を言葉にし、対象範囲と例外の扱いを確定させる
2. 実装 … 決まった仕様を動く形にするまで。既存システムとの接続もここに含む
3. 運用改善 … 公開後に直し続ける費用。業務が変わるたびに、判定の基準や出力の形を修正する

外注が割高になりやすいのは1と3で、2は必ずしもそうではありません。1では社内にしかない判断の基準を外部へ渡すための往復が要り、3では直したい箇所が出るたびに契約上の手続きを一巡させることになります。実装の単価だけを並べると、この2つが比較から抜け落ちます。

外注と内製の比較が噛み合わなくなるのは、この3つをまとめて1つの金額として見ているためです。まず自社の直近1年の発注を、この3区分に割り振ってみると議論の前提が揃います。割り振った結果をどう読むかは、工程ごとの内訳を見たあとに扱います。

工程ごとに、費用がどこへ出るか

工程	外注のときに費用が乗る理由	内製へ移すと何が変わるか
要件定義	社内にしかない手順を外部へ伝える作業が必要。打ち合わせと差し戻しの回数が金額になる	業務を知っている人が直接書くため、伝える工程が消える
実装	作業量に応じた費用。専門性が高い部分ほど妥当な支出になる	対象を絞れば社内で作れるが、基盤に近い部分は割高になる
既存システムとの接続	相手側の制約が後から出るため、追加の見積が発生しやすい	社内の担当が権限とデータの所在を把握していれば短くなる
運用改善	改修1回ごとに見積・承認・着手待ちが挟まる。作業量が小さくても手続き分が乗る	直す判断と作業が同じ場所にあるため、手続き分が消える
保守・監視	契約に含まれる範囲が固定される。範囲外は都度の依頼になる	対応する人を決める必要があり、その分の人件費が発生する

表の下2行が、外注を続けたときに積み上がる部分です。1回あたりの金額は大きくないため見積書では目立ちませんが、業務が変わるたびに発生するため、年単位で見ると要件定義と並ぶ規模になることがあります。

一方で、実装と保守を内製に移せば費用が消えるわけではありません。社内の人が対応する時間に置き換わるだけです。比較するときは、外注費と社内の人件費を同じ表に並べて見ます。金額換算の手順は AI導入の効果測定と投資判断 で扱っています。

外注を続けるか、内製へ戻すかを分ける条件

3区分への割り振りが済んだら、次に見るのは総額ではなく次の5点です。1つで決めるのではなく、左の列に当てはまる数が多いほど外注のままが妥当になります。

見るところ	外注のまま続けるほうがよい状態	内製へ戻す検討に入る状態
直す頻度	公開後の修正が年に数回で収まっている	業務が変わるたびに直したい箇所が出ている
金額の寄り	基盤の構築と外部審査への対応が大半を占める	仕様を決める工程と公開後の修正に積み上がっている
対象業務の見通し	数か月後に業務そのものが変わる予定がある	手順が固まっており、当面は同じ形で続く
社内に書ける人がいるか	業務の手順を仕様の形で書ける人がいない	部門に数名、手順と例外を書き出せる人がいる
同じ領域からの要望	単発で終わり、近い依頼が続いていない	同じ業務領域から繰り返し依頼が出ている

5点は同じ重みではありません。「社内に書ける人がいるか」だけは前提条件で、ここが埋まっていない状態で他の4点が揃っても、内製へ移した先で同じ差し戻しが起きます。逆に、書ける人がいても直す頻度が年に数回なら、戻して減る手続きの分が体制づくりの手間に届きません。

判断を保留する場合でも、契約が続いているうちにやっておくことがあります。発注のたびに、仕様が固まるまでの打ち合わせ回数と、公開後の改修が反映されるまでの日数を社内側でも控えておくことです。この記録が無いと、次に比べるときも見積書の合計額しか材料がなく、同じ場所で判断が止まります。

要件定義が外注で割高になる理由

要件定義は、業務の手順を仕様として書き出す工程です。外注の場合、ここに「社内にある知識を外部へ移す」作業が加わります。

作業量を押し上げるのは、例外の扱いです。ふだんの手順は説明できても、月に数件しか起きない例外や、担当者が経験で判断している部分は言葉になっていません。この部分は、打ち合わせの場では出てきません。実装が進んで動くものを見た段階で「この場合はどうするのか」という形で出ます。そのたびに仕様が変わり、変更として費用が発生します。

内製へ移すと、この伝える工程がなくなります。業務を知っている人が仕様を書くため、例外は最初から前提に入ります。ただしこれは、業務を知っている人が仕様を書ける状態にあることが条件です。書ける人がいないうちに内製へ移すと、社内で同じ差し戻しが起きるだけで、費用が人件費へ移動します。

改修のたびに見積と待ち時間が発生する

運用改善が外注で割高になるのは、作業そのものより手続きに理由があります。1回の改修で何が発生するかを並べると、差がはっきりします。

ここで効いてくるのは金額よりも時間です。判定の基準を1つ変えたいだけでも、依頼から反映まで数週間かかる場合、その間は業務側が手作業で補うことになります。補う作業は外注費に表れないため、費用の比較からも抜け落ちます。

もう一つ、依頼する側が「この程度の修正で発注してよいか」を毎回考えることになります。結果として、小さな改善は依頼されないまま残ります。運用改善の費用が外注で割高というより、必要な改善が行われないまま止まる、という形で表れます。

改修の頻度が低い場合は、この構造は問題になりません。年に数回しか直さないものは、外注のままで足ります。判断の分かれ目は費用の絶対額ではなく、直す頻度です。

外注を残したほうがよい領域

すべてを内製へ戻す必要はありません。線引きは、頻度と専門性で決まります。

領域	見るところ	どちらに置くか
業務の手順を含む処理	業務が変わるたびに直すか	内製。直す頻度が高いほど効く
出力の判定基準・例外の扱い	現場でしか決められないか	内製。仕様が現場にしかない
基盤の構築（認証・ネットワーク・権限設計）	一度作ったあと触るか	外注。頻度が低く専門性が高い
セキュリティ要件が重い部分	外部審査や監査の対象か	外注。要件の解釈に責任が伴う
個人情報・機密データの取り扱い設計	法令や社内規程の判断を含むか	外注と社内の共同。設計は外部、運用ルールは社内
単発で終わる案件	同じ要望が再び出るか	外注。内製化しても腕が落ちる

基盤とセキュリティを外注に残す理由は、費用ではありません。年に何度も触らない領域は、社内に担当を置いても経験が蓄積しないためです。認証やネットワーク構成の変更は、判断を誤ったときの影響が業務側の改修とは桁が違います。

同時に、外注へ残す領域についても、社内に「何を依頼しているかを説明できる人」は必要です。全部を任せると、次に別の会社へ依頼するときに要件を書けなくなります。切り分けの考え方は AI内製化の進め方 でも扱っています。

内製が成立する前提

内製へ移すと決めても、作れる人がいなければ外注費が人件費に置き換わるだけです。成立の条件を、到達の目安と役割分担の2つで確認します。

非エンジニアがどこまで作れればよいか

エンジニアと同じ状態を目指す必要はありません。次の3つができれば、業務の手順を含む処理は社内で回ります。

• 業務の手順を指示として書ける … 手順、判断の基準、例外の扱いを、順番に並べて書けること
• 出力が誤ったときに、指示のどこを直すか特定できる … 誤りを見て、指示の不足なのか元データの問題なのかを切り分けられること
• 扱ってよいデータの範囲を判断できる … 社内規程に照らして、入れてよい情報かを自分で決められること

この3つを超える部分、たとえば基幹システムとの接続や権限の設計は、情報システム側が持ちます。全員がこの状態になる必要はなく、部門ごとに数名で足ります。判断の基準として社内ルールを整える手順は 生成AIの社内利用ルールをどう作るか を参照してください。

手前で決めておく役割分担

作れる人を育てる前に、次の3つを誰が持つかを決めておきます。決まっていないと、作ったものが動かなくなった時点で止まります。

役割	持つ内容	決めていないと起きること
業務側の担当	何を作るか、判定の基準、直す優先順位	作ったものが誰のものでもなくなり、直されないまま放置される
情報システム側	アカウントと権限、接続先、データの取り扱い	都度の確認で待ちが発生し、内製でも着手待ちが生まれる
判断する人	対象業務の選定、外注に残す範囲、費用の承認	案件ごとに議論が最初からやり直しになる

外注のときは、この3つを発注者と受注者の契約が代わりに定義していました。内製へ移すと契約書がなくなるため、社内で明示的に決め直す必要があります。要件定義から保守までの工程ごとに、どこを社内の誰が持ち、どこに外部の支援を残すかの分け方は AIエージェントを社内で内製する で扱っています。

外注から社内へ移すときにかかる費用

作れる人が育っても、外注で作ったものがそのまま社内で直せるとは限りません。移すための作業が別に必要で、この費用は見積書にも社内の人件費にも表れないため、内製へ戻す判断の時点で抜けやすい部分です。

移すもの	契約が続いているうちに確認すること	移していないと起きること
動かす環境とアカウント	クラウドの契約者と請求先が自社か、管理者の権限を自社が持っているか	契約が切れた時点で止まる。作り直しの費用が別に発生する
成果物と保管場所	納品の範囲に指示文・設定・手順書が含まれ、自社の保管先へ置かれているか	動くものはあるが中身を読めず、直すたびに元の外注先へ戻ることになる
接続先の認証情報	連携しているシステムの鍵とアカウントを誰が持っているか	接続が切れた時点で社内では復旧できない
判定の基準と例外の扱い	現場が読んで分かる言葉で残っているか	直す判断ができず、社内へ移しても改修が止まる

上の2行は契約の書き方でほぼ決まります。着手前に納品の範囲へ含めておけば追加の費用は発生しませんが、契約が終わってから頼むと、資料を作る作業として別に見積が出ます。下の2行は運用の中で溜まるもので、依頼のたびに自社側でも記録を残していれば、移す作業そのものがほとんど要りません。

移す作業は一度で終わるため、費用としては切り替えの年に一度だけ乗る支出です。判断としては、この一度の支出を、内製へ移したあとに減る改修分で回収できるかという比較になります。改修が年に数回しかない領域では回収に届かないため、環境とアカウントの所在だけ確認して外注のまま続けるほうが妥当です。引き渡しの範囲を発注前にどう確認するかは AI内製化支援サービスの選び方 で扱っています。

いつ内製化の検討に入るか

案件の本数を数えるだけでは決まりません。見るのは、同じ業務領域から要望が繰り返し出ているかどうかです。

• 1本目 … 外注が合理的です。社内に判断材料がなく、何が難しいのかも分かっていません。ここで内製から始めると、作れるかどうかの検証に時間を使い切ります
• 2本目 … 発注の記録を工程ごとに残します。要件定義に何回の打ち合わせが必要だったか、公開後に何回の改修依頼を出し、それぞれ反映まで何日かかったかを控えます
• 3本目 … 同じ業務領域から出た場合、要件定義と改修に払っている分を内製へ戻せるか検討します。別々の領域から出た場合は、まだ外注のままで足ります

3本目という区切りに意味があるのは、そこで初めて「同じ説明を3回している」状態が見えるためです。同じ業務領域で3回続けて外部へ手順を伝えているなら、その説明を書ける人が社内にいるということでもあります。

逆に、前半の表で左の列に当てはまる項目のほうが多い場合は、内製の体制づくりに人を割く前に、外注の契約範囲を見直したほうが早く効きます。範囲外として都度見積になっている改修を契約に含める、依頼から着手までの日数を取り決めるといった調整のほうが、同じ手間で早く効くことがあります。見積を工程ごとに分けて比べる観点は AIエージェント開発の進め方 で扱っています。

まとめ：外注費のどこを内製へ戻せるか

• AI開発費を要件定義・実装・運用改善の3工程に割り振る。外注で割高になりやすいのは要件定義と運用改善で、実装は必ずしもそうではない
• 運用改善の費用は作業量より手続きに出る。改修1回ごとに見積・承認・着手待ちが挟まり、小さな改善が依頼されないまま残る
• 基盤・セキュリティ要件が重い部分・単発の案件は外注に残す。頻度が低い領域は社内に担当を置いても経験が蓄積しない
• 内製が成立する条件は、手順を指示として書ける人が部門に数名いることと、業務側・情報システム側・判断する人の役割分担が決まっていること
• 移すときの費用は見積書に出ない。環境とアカウントの所在、成果物の範囲、判定の基準が社内にあるかを、契約が続いているうちに確認しておく
• 続けるか戻すかは総額ではなく、直す頻度、金額がどの工程に寄っているか、対象業務の見通し、社内に書ける人がいるか、同じ領域から要望が続いているかで見る。書ける人がいるかだけは前提条件で、ここが埋まらないと他が揃っても戻せない
• 本数ではなく、同じ業務領域から3本目の要望が出たかで検討に入る。改修の頻度が年に数回なら外注のままでよい

Augueでは、外注していた業務の棚卸しから、非エンジニアの方がご自身の業務を任せるAIを作れるようになるまでの伴走支援を行っております。どこまでを内製へ戻せるかの切り分けから整理できますので、ご興味がある方は是非ご相談ください。

関連する記事

社内で作れる体制をつくる順序は AI内製化の進め方、工程ごとに社内の担当と外部の支援を分ける考え方は AIエージェントを社内で内製する、外注を続ける場合の見積の見方は AIエージェント開発の進め方、戻した効果を金額で説明する手順は AI導入の効果測定と投資判断 を参照してください。

よくある質問

AI開発を外注すると、費用はどの工程に多くかかりますか？

実装そのものより、業務を言葉にする工程と、公開後に直し続ける工程に寄ります。前者は社内にしかない手順を外部へ伝える作業で、打ち合わせと差し戻しの回数がそのまま金額になります。後者は改修1回ごとに見積と承認が挟まるため、作業量が小さくても手続きの分だけ費用が乗ります。実装費だけを比べると、この2つが見えません。

内製に切り替えると外注費はどれくらい下がりますか？

一律の数字は出せません。同じ「AI開発費」でも、基盤構築が大半を占める会社と、公開後の改修が積み上がっている会社では減る場所が違うためです。判断材料になるのは、直近1年の発注を工程ごとに割り振った結果です。要件定義と改修に金額が寄っているほど内製で戻せる幅が大きく、基盤とセキュリティ対応に寄っているほど外注のままが妥当になります。

どこまでを外注に残すべきですか？

頻度が低く専門性が高い領域は残します。認証やネットワーク構成を含む基盤、監査や外部審査への対応、法令やセキュリティ要件の解釈が必要な部分が該当します。これらは年に何度も触らないため、社内に人を置いても腕が落ちます。逆に、業務が変わるたびに直す部分は残すほど改修のたびに費用と待ち時間が発生します。

非エンジニアだけでAI開発を内製できますか？

対象を絞れば成立します。目安は、業務の手順を指示として書けること、出力が誤ったときに指示のどこを直すか特定できること、扱ってよいデータの範囲を判断できることの3つです。この範囲を超える連携や権限設計は情報システム側が持ちます。全員がこの状態になる必要はなく、部門ごとに数名で足ります。

見積が一式でまとまっていて工程ごとの金額が分からない場合、どう分解しますか？

金額を按分するのではなく、作業の回数で割り振ります。仕様が固まるまでの打ち合わせが何回あったか、公開後に何件の改修を依頼し、それぞれ反映まで何日かかったかを社内の記録から数えます。回数が要件定義と改修に寄っているなら、一式の金額の多くもそこに乗っています。次の発注からは工程ごとの内訳を出してもらう形にしておくと、この手間がなくなります。

保守の月額は、外注費のどこに数えればよいですか？

契約に含まれる範囲と、範囲外として都度見積になる部分を分けて数えます。監視と障害対応だけが月額に含まれ、業務の変更に伴う改修は範囲外という契約は珍しくありません。その場合の月額は運用改善の費用ではないため、月額に改修が含まれていると見なして内製と比べると、外注側を実際より小さく見積もることになります。

何本目の案件から内製化を検討すべきですか？

本数そのものより、同じ業務領域で3本目の要望が出たかどうかで見ます。1本目は社内に判断材料がないため外注が合理的です。2本目で発注の記録を工程ごとに残し、3本目が同じ領域から出た時点で、要件定義と改修に払っている分を内製へ戻せるか検討します。単発で終わる領域は本数が増えても内製に向きません。