生成AIの開発は内製か外注か｜同じ開発範囲で3年費用と責任を比べる

生成AIを使った開発を内製するか外注するかは、「年に何本作るか」だけでは決まりません。差を決めるのは、社内で1本作るのに何人年かかるかと、作り終えたシステムの保守が年ごとに積み上がる量です。 この記事では、毎年作る本数・人員・過年度分の保守を全パターンで揃えて3年費用を試算し直し、その数字を自社の条件に置き換えるための式も示します。

もう一つの前提は、いまは社内のチームもChatGPT、Codex、Claude Codeなどを使って、調査・実装・テストまで自分たちで進められることです。そのため「企画は社内、実装は外注」という固定の分担では考えません。社内がAIで進める部分と、会社に頼んだ方が早い部分（既存環境の調査、レビュー、外部システムとの接続、変更と障害の責任）を、成果物と責任の単位で分けます。

最後に、当社（AI革命）の受託開発で依頼できる範囲と公開価格を示します。全部を外に出す必要はなく、内製を続けながら一部だけ頼む共同開発も選べます。

内製と外注の判断を間違えると、どこで損が出るか

最初に、判断を誤ったときに何が起きるかを見ておきます。損失が出るのは開発費そのものではなく、たいてい「作った後」です。

社内で作ったシステムや、外注先が作ったまま引き継がれていないシステムで起きやすい問題には、次のような型があります。

• 部署の判断で作った仕組みに認証が無く、社外からデータが見える状態になっていた
• 外部サービスとの連携部分が、作成者にしか分からない設定で動いていた
• 作成者が異動・退職した後、後任が改修できず、作り直しになった
• 作成者自身が「AIに作らせたが、仕組みは説明できない」状態で引き継がれた

最後の2つは、生成AIで内製のハードルが下がったからこそ起きやすくなった、新しい形の属人化です。従来の属人化は「作れる人が1人しかいない」でしたが、いまは「作った本人も中身を説明できない」という状態が生まれます。逆に言えば、AIに書かせたコードでも、試験・変更履歴・手順書が残っていれば後任が引き継げます。問題はAIを使うことではなく、確認と引継ぎの仕組みを作らないことです。

NTTデータ経営研究所も、生成AI業務アプリの内製化の成否を決めるのは開発力ではなく継続して運用する力だと指摘しています。作った人が異動すれば設定の意図が失われ、外部AIサービスの仕様変更と社内の制度改正の両方から品質が落ちていきます。作成者の異動後に修正や停止ができなくなる問題は、かつてRPAでも見られました。

RPAの保守が想定以上に膨らんだ経験がある場合は、RPAの保守コストが膨らむ理由も合わせて確認しておくと、同じ失敗を繰り返さずに済みます。

つまり内製と外注の判断は、「安く作れるのはどちらか」ではなく「3年間動かし続けられるのはどちらか」で決めるべきものです。

そもそも自社は内製できる状態か｜総務省データで確認する6項目

出典: 総務省 令和8年版 情報通信白書 公式サイト

内製を選べるかどうかは、意欲ではなく環境で決まります。総務省『令和8年版 情報通信白書』（2026年7月公表）は、生成AIによる業務変革に向けた環境整備の状況を国別に調べています。

※ 総務省「令和8年版 情報通信白書（概要）」2026年7月／日本 n=326、米国 n=276、中国 n=293

特に注目したいのは下から2行目で、内製の前提となる開発環境がある日本企業は15.3%、およそ7社に1社です。さらに、社内データが整っている企業は26.1%、生成AIに社内データを学習させたり参照させたりする仕組みまで作れている企業は24.5%にとどまります。

同じ白書では、生成AIを何らかの業務で使っている日本企業は86.4%に達している一方、生成AIによる業務変革について「組織的な取り組みはない」と答えた日本企業が27.0%（日本 n=497。米国は1.4%）と突出しています。個人が使ってはいるが、会社としての仕組みにはなっていないというのが、日本の平均的な状況です。

PwC Japanの『生成AIに関する実態調査2026 春』（2026年2月調査。日本の回答者は売上高500億円以上の企業の課長職以上932名）も同じ方向を示しています。日本企業の活用・推進度は87%まで上がっているのに、「期待を大きく上回る効果を創出している」企業の割合は9%で6カ国中最低、施策の実施から1年以内に効果が出ると想定する割合は41%（米国66%）でした。導入はしたものの、効果の実感は薄い状態です。作ることではなく、動かし続けることでつまずいているということです。

自己診断の目安

上の6項目は、何個当てはまれば内製できるという基準ではありません。ただ、次の2つが揃っていない場合は、内製でも外注でも稼働後に止まりやすくなります。

• 社内データが、部署をまたいで同じ定義で整理されている
• 出てきた答えが業務上正しいかどうかを判定できる担当者が、業務側にいる

この2つは外注しても代わりにはなりません。外に出せるのは「作ること」や「確かめ方の設計」であって、「何を正しいとするかを決めること」ではないからです。

AIで社内が進められること、会社に頼むと早いこと

内製か外注かを比べる前に、「内製」の中身が変わったことを押さえておきます。Claude Codeの公式ガイドは、テストやビルドなど実行できる確認方法を渡せば、AIが実装→確認→修正を確認が通るまで繰り返せると説明し、作業の証拠（テスト結果や実行したコマンド）を示させることを勧めています。OpenAIもCodexを使って、レビュー・修正・検証を分け、検証結果を次の修正に渡す反復の組み方を公開しています。

つまり、社内に専任エンジニアがいなくても、AIを使ってコードとテストを書き、直すところまでは社内で進められます。一方で、AIに渡す「確認の基準」そのものや、社外のシステム・本番環境に関わる判断は、会社ごとの事情で止まりやすい部分です。

右の列は「AIにはできない」という意味ではありません。その会社の既存環境・権限・データ・例外を知っていて、結果に責任を持つ人が要る作業です。社内にその人がいれば内製で進められますし、いなければその部分だけを外に頼む、という分け方ができます。

人件費で比較する｜内製1名を1年抱えるといくらか

出典: 独立行政法人 情報処理推進機構（IPA）『DX動向2025』公式サイト

内製の費用を「ツールの月額」で計算してしまうと、必ず見誤ります。実際にかかるのは人件費です。

AIエンジニアの年収の目安は、厚生労働省の職業情報提供サイト（job tag）などに掲載されています。ただし集計年度や地域・経験年数で値が変わるため、採用予算は最新の掲載値と、自社が出す求人の条件で確認してください。年収に社会保険料・間接費・採用費が加わる点も忘れないでください。

この記事の試算では、次の値を仮定として置きます（実際の金額は会社ごとに置き換えてください）。

そして、この採用は簡単ではありません。IPA『DX動向2025』では、DX推進人材の「量」が不足していると答えた日本企業が8割を超えています（米国は2割台）。経済産業省の『IT人材需給に関する調査』（2019年4月時点の推計）でも、2030年にはAI人材だけで約12.4万人の需給ギャップが生じるとされていました。2019年の推計であることは差し引く必要があります。

採用にかかる時間も費用です。 求人を出してから入社し、自社の業務とシステムを理解するまでの間、開発は進みません。この期間は会社と職種で大きく違うため、自社の直近の採用実績で見積もってください。後の試算では、この空白期間を含めていません（含めると内製のパターンは不利になります）。

一方、外注費は「1本あたりいくら」「保守が年いくら」という形で見えます。違いは払い続けるかどうかです。人件費は仕事がない月も発生し、外注費は使った分だけ発生します。

期間で比較する｜「作る時間」より「作る前の時間」が長い

期間の話は、開発期間だけに目が向きがちです。実際に稟議を書く立場からすると、見落としやすいのは作り始める前の社内プロセスです。

この期間は、内製でも外注でもかかります。むしろ内製の場合、「自社でやるのだから審査は軽くていい」と考えて手続きを飛ばし、後から情報システム部門に止められて振り出しに戻ることがあります。外注の場合は、契約や審査を開発の準備と並行して進められるかを、発注前に相手と確認してください。

開発そのものの期間は、要件の固まり具合、既存システムとの接続の数、データの整理状態で大きく変わります。「生成AIだから数週間」「どの案件も半年」といった一律の目安は当てはまりません。期間を見積もるときは、次の3つを分けて考えると、どこが延びそうかが見えます。

• 何を作るかを決める期間：業務側が合格の基準（どの出力ならOKか）を決めるまで
• 作って確かめる期間：実装と、業務データを使った試験。AIを使えば実装は速くなりますが、業務側の確認の回数は減りません
• 本番に出す期間：権限設定、データ移行、利用者への説明、戻し方の準備

維持コストで比較する｜生成AIには「経年劣化」がある

出典: 株式会社NTTデータ経営研究所 公式サイト

従来のシステム開発と生成AI開発の大きな違いは、作った後も品質が変わり続けることです。原因は2つあります。

1つ目は、AIモデルの世代交代です。 生成AIのモデルは新しい世代が出るたびに、古い世代の提供終了が予告されることがあります。モデルが変われば、同じ指示文を渡しても出力の傾向が変わります。これは不具合ではなく仕様なので、変わるたびに指示文の調整と再検証が必要になります。

2つ目は、業務側の変化です。 制度改正、商品マスタの更新、業務フローの見直しなどで、AIに読ませているデータや判断のルールが古くなれば、出力はそのまま古い前提で返ってきます。しかも、システムのようにエラーで止まってくれるわけではなく、もっともらしい間違いを返し続けるため、気づくのが遅れます。

この記事の試算では、保守を次のように仮定します。

内製の維持コストが厄介なのは、費用として計上されないことです。担当者が月20時間かけて指示文を直していても、その20時間はどこにも数字として出てきません。だから安く見えます。そして担当者が異動した時点で、その20時間分の知見も一緒に失われます。

外注の保守費が「高い」と感じる場合は、内製時に誰かが無償でやっている作業を金額に直して比べてみてください。例えば月20時間×時給3,000円なら月6万円、年72万円です。

3年間の総額シミュレーション｜同じ成果物を作る前提で比べる

ここまでの仮定を使って、3年間の費用を4パターンで比較します。以下はすべて仮定に基づく試算で、実案件の実績値ではありません。 金額は税別・万円です。

揃えた条件

• 毎年作る新規の成果物：年1本（基本ケース）。比較用に年2本も計算
• 1本の範囲：どのパターンも同じ（社内文書を検索して根拠付きで答える仕組みや、業務システムへのAI組み込みを1件）
• 外注で作る場合の費用：1本あたり1,100万円（PoC 300万円＋本開発800万円と仮定）
• 過年度分の保守：前の年までに作ったシステムは、翌年以降すべてのパターンで保守する。外注なら1本あたり年196万円（保守96万円＋改修100万円）、内製なら1本あたり年0.2人年
• 社内で1本作るのに必要な工数（a）：基本ケースは1.0人年。AIの活用度や社内の慣れで変わるため、0.5人年と1.5人年でも計算
• 社内の工数で足りない分：外注する。新規開発は残った割合だけ外注費がかかる（例：社内で6割作れたら、残り4割の440万円を外注）と仮定。保守も同様
• 全パターン共通の費用：生成AIツールとAI従量課金の年180万円（3年で540万円）と、業務側が出力を確認する工数。どのパターンでも同じ額なので、比較表からは除いています

4つのパターン

• ① 兼任で内製し、足りない分を外注：社員2名が月20時間ずつ（年480時間＝0.25人年、年144万円）
• ② 専任を必要な人数だけ採用して全部内製：3年間で最も工数が要る年に足りる人数を、1年目に採用
• ③ すべて外注：新規も保守も外注
• ④ 専任1名を採用し、足りない分を外注（共同開発）：社内の1名がまず保守を担い、残りの工数で新規開発を進め、足りない分を外部に頼む

計算式

各年の費用は、次の式で計算しています。

• 今年の社内の必要工数 ＝ a × 今年の新規本数 ＋ 0.2 × 稼働中の本数
• ③ すべて外注 ＝ 1,100 × 新規本数 ＋ 196 × 稼働中の本数
• ①④ ＝ 社内の人件費 ＋（社内で足りない保守の工数 ÷ 0.2）× 196 ＋（社内で作れなかった新規の割合）× 1,100
• ② ＝ 800 × 採用人数（1年目は採用費150 × 採用人数を加算）

基本ケース（年1本・社内で1本1.0人年）の3年費用

※仮定に基づく試算（万円・税別）。共通費の年180万円と業務側の確認工数は全パターン同額のため除外

内訳の例を2つ示します。

• ③の3年目：新規1本1,100 ＋ 稼働中2本の保守196×2＝392 → 1,492
• ④の2年目：社内の必要工数は 1.0＋0.2＝1.2人年。専任1名（1.0人年）が稼働中1本の保守（0.2）を担い、残り0.8人年で新規の8割を作る。残り2割を外注して220 → 800＋220＝1,020

②で専任が2名になるのは、3年目の必要工数が1.0＋0.2×2＝1.4人年となり、1名では足りないからです。1年目と2年目は工数が余りますが、人件費は発生します。

条件を変えると順位が入れ替わる

※a＝社内で新規1本を作るのに必要な工数（人年）。仮定に基づく試算

この表の読み方

• 「年に何本作るか」だけでは決まりません。 年1本でも、社内で1本を0.5人年で作れるなら、専任1名の内製（②④とも2,550万円）が最も安くなります。逆に年2本でも、1本に1.5人年かかるなら、専任だけで回すパターン（②）が最も高くなります
• 社内で作るか外に出すかの分かれ目は、この仮定では a＝約1.4人年です。 社内で1本作る費用は 800万円×a、外注は1,100万円なので、1,100÷800＝1.375人年より少ない工数で作れるなら社内の方が安く、多くかかるなら外注の方が安くなります（採用費と、余った工数の人件費は別）
• 全部外注は、作る本数が同じでも年々高くなります。 過年度分の保守が積み上がるためで、基本ケースでは3年目が1年目より392万円多くなります。1年目の見積だけで比べると、この差を見落とします
• 専任だけで回す形は、人数が段階的にしか増やせないため、工数が余る年の人件費が乗ります

ここから言えるのは、「年何本なら内製」という一律の境界ではなく、自社のaを知ることが判断の出発点だということです。aはAIの使い方、社内の業務知識、既存システムの複雑さで大きく変わり、一般的な相場からは決められません。最初の1本を小さく作り、社内でかかった時間を記録すれば、次の判断に使える自社の数字が手に入ります。

なお、この試算に含めていないものがあります。採用が決まるまでの空白期間、担当者が辞めたときの引継ぎ、作業を分割したときの調整の手間、作ったものの品質の差です。いずれも内製を選ぶほど影響が大きくなる項目なので、②④を選ぶ場合は特に、試験・変更履歴・手順書を残すことを開発の範囲に入れてください。

自動化や開発の投資対効果をどう測るかについては、自動化の効果測定の考え方も参考にしてください。

内製・部分依頼・共同開発・委託の比較｜成果物と責任で分ける

試算の④のように、内製と外注の間にはいくつかの形があります。違いは金額よりも、誰が何を作り、何に責任を持つかです。

どの形でも、何を合格とするかを決めて受け入れる責任は社内に残ります。外部に頼めるのは、作ること、確かめ方の設計、既存環境を調べて安全に変えることです。

外注しない方がよい条件

次に当てはまる場合は、外注を急がない方が結果的に安く済みます。

• 何を解決したいかが、まだ社内で一文にできない（先に業務の整理から始める）
• 既製のSaaSや、いま使っているツールの設定変更で目的を満たせる
• 社内でAIを使って試作し、実際の業務で使い続けられている。足りないのが外部接続や権限など一部だけなら、委託ではなくその部分だけを頼む
• 受入の判断をする担当者を社内で決められない（誰が頼んでも稼働後に止まる）

共同開発で先に決めること｜説明用の架空アプリで書く分担表

共同開発では、「社内は企画だけ、外注は実装だけ」という分担は成り立ちません。社内のチームもAIを使ってコードとテストを変更するため、同じリポジトリの中で、どこを誰が変えてよいかを先に決める必要があります。

以下は説明用の架空の例です。実案件ではなく、この例で実際に試験を行った結果でもありません。取り決めの書き方の記入例として見てください。

架空の前提：営業日報アプリ。社内チームがAIを使って入力画面と承認ルールを変更し、外部の開発会社が基幹システムとのデータ連携と本番反映の仕組みを担当する。

この表を作ったら、次の4つの場面でどう動くかを、事前に文章で決めておきます。

このように、取り決めの成果物はPR、試験の結果、業務側の確認記録、引渡し物の一覧として残ります。これが残っていれば、後から外部の会社を替える場合も、社内で全部を引き取る場合も、どこまで終わっているかを確かめられます。

工程で分けるという現実解｜企画・データ・作る・評価・運用

「全部内製か、全部外注か」の二択で考えると、たいてい判断を誤ります。生成AIのプロジェクトは5つの工程に分かれており、工程ごとに置き場所を決めるのが実務的です。

推奨は、企画と評価を先に自社へ寄せることです。理由は単純で、この2つは外注先が代わりにできないからです。

「この出力は業務上OKか」を判定できるのは、その業務を毎日やっている人だけです。ここを外注先に丸投げすると、発注側が良し悪しを判断できないまま納品を受け取ることになり、稼働後に「思っていたものと違う」という事態が起きます。作ること（実装）は外に出しやすい工程ですが、AIを使えば社内でも進められるため、前の節のように一部だけを頼む形も選べます。

なお、社内に情報システム部門がない場合の進め方については、エンジニアがいない会社の業務自動化で詳しく整理しています。

外注してもノウハウを社内に残す発注のしかた

「外注するとノウハウが残らない」とよく言われます。これは半分正しく、半分は誤解です。残らない原因は、残す設計をせずに発注していることにある場合が少なくありません。

納品物として必ず受け取るべき7点

契約前に、以下が納品物に含まれるかを確認してください。含まれていなければ、含めた場合の見積もりを別途出してもらいます。

1. 整えたデータ（AIに読ませるために加工した後のもの）
2. 構築したプログラム一式（試験コードと変更履歴を含むリポジトリ）
3. 精度を測るための検証用データと、測定の手順書
4. AIへの指示文と設定値（ここが実質的なノウハウの本体）
5. 環境の構築手順書
6. 失敗記録（試したがうまくいかなかった方法とその理由）
7. 成果物の権利の扱いを明記した書面

特に4番の指示文と設定値は、生成AIのプロジェクトにおける中核資産です。ここが納品されないと、外注先を替えた時点でゼロからやり直しになります。そして6番の失敗記録も見落とされがちですが、これがないと後任が同じ失敗を繰り返します。

契約で確認すべき4点

経済産業省の『AI・データの利用に関する契約ガイドライン』は、AI開発では生データ・学習用データセット・学習済みモデル・中間生成物と成果物が多層になるため、権利の帰属と利用条件を細かく設定する必要があると指摘しています（契約チェックリストは令和7年2月公表）。確認すべきは次の4点です。

• 「成果物として引き渡す」のか「使用を許諾するだけ」なのか（同ガイドラインは両方の形を想定しています）
• 納品されたものを、自社で改変してよいか
• 別の業者に保守を引き継げるか
• 引き渡し期間（測定をやり直すのに1カ月程度は必要）と、その間の対応費用

そして最も実務的なコツは、見積もり段階で「引き渡しを含む場合」と「含まない場合」の金額を分けて提示してもらうことです。差額が明示されれば、ノウハウを残すのにいくら払っているのかが分かります。この一手間で、3年目に外注先を替えるという選択肢を残せます。

当社の受託開発でも、どこまでを引き取れる形で納めるか（コード・試験・手順書・指示文など）を、依頼範囲として相談の段階から一緒に決められます。将来の内製化を見据えたご相談も可能です。

複数社から見積もりを取る際の比べ方は、AI開発の見積もり比較のポイントにまとめています。

費用の目安と、どこから始めるか

出典: AI革命 受託開発サービス 公式サイト

外注費の見積もりは、データの整理状態、既存システムとの接続の数、利用者数と権限の複雑さで大きく変わります。一般的な相場の金額よりも、見積もりに何が含まれ、何が含まれていないかを比べてください。例えば社内文書検索の仕組みなら、ファイルサーバーに同じ資料の版違いが並んでいる状態から始めるのか、最新版が一元管理されているのかで、必要な工数が大きく変わります。見積もりが高いと感じたときは、値引きを求める前に自社のデータ状態を確認したほうが早く安くなります。

当社（AI革命）の価格

当社の受託開発は、次の価格で対応しています（すべて税別、クラウド利用料・外部APIの利用料・ソフトウェアライセンスなどの実費は別途）。

内製を続けながら一部だけを頼む場合も、これらの形のどれに当たるかを相談の中で整理します。例えば、社内でAIを使って作った試作の外部接続や権限だけを直すなら既存システムの改修、試作が業務で使えるかを確かめるならPoC、という具合です。既存のコードや仕様書の調査だけを依頼することもできます（調査は有償で、着手前に範囲と金額を示します）。いきなりPoCや本開発から入る必要はありません。まず小さく1本外に出して、進め方と相性を確かめてから本番の規模を決めるのが、失敗の少ない入り方です。

▶ 内製で続ける範囲と、依頼する範囲を相談する

初回相談は無料・30分（オンライン）で、要件が決まっていなくても大丈夫です。相談後に、自社で進める部分・依頼する部分の切り分けと費用の目安を、相談メモでお送りします。

費用の内訳をさらに細かく確認したい場合は、AI受託開発の費用相場とPoCにかかる費用も合わせてご覧ください。

そもそも作らずに済む業務もある

内製と外注を比べる前に、一度だけ確認しておくべきことがあります。その業務は、本当に新しく開発する必要があるのかです。

以下に当てはまる業務は、システムを一から開発するよりも、繰り返し作業をAIエージェントに任せる運用型のサービスの方が合うことがあります。

• 毎日・毎週・毎月、同じ手順で繰り返し発生している
• 入力も出力もデータ上で完結している（紙や対面が前提になっていない）
• 判断のルールが言葉で説明できる

逆に、次の場合は開発が必要です。

• 自社独自の業務フローに合わせた画面や帳票が要る
• 既存の基幹システムと深く連携させる必要がある
• 顧客に提供する新しいサービスそのものを作りたい

上の3条件に当てはまり、新しい画面やシステムを作る必要がない場合は、開発せずに既製のツールや運用型のサービスで足りることもあります。どちらに当たるか迷う場合や、画面・帳票・既存システムとの連携が必要な場合は、この記事の受託開発の相談をご利用ください。

判断がつかない場合の費用感については、AIエージェント導入の費用も参考にしてください。

公開している開発実績

当社が受託開発の実績として公開しているのは、次の2件です（守秘のため社名・詳しい数値は非公開です）。

どちらも、AIや自動処理が出した結果をそのまま使うのではなく、人が確認する工程と、誰が何を見られるかの権限を開発の範囲に含めた例です。内製で作ったものを本番で使い続けるときに、外部に頼む価値が出やすいのもこの部分です。

相談から導入までの流れと期間

当社の受託開発は次の流れで進みます。

この期間とは別に、御社側の法務レビュー・セキュリティ審査・稟議に時間がかかることを前提に逆算してください。社内手続きを開始するタイミングを早めることが、実は最も効果の大きい期間短縮策です。

初回相談の前に、秘密情報・本番の認証情報・実際の顧客データを送っていただく必要はありません。

対応領域は、AIを使った業務システム、新規事業の実証実験・試作、社内業務システム、既存システムの改修、外部システム連携、他社が作ったシステムやAIで作った試作の調査・引継ぎ、データ分析や管理画面などです。

よくある質問

Q1. 生成AIの内製化を始めるには、何人必要ですか。

人数より先に、3つの役割を誰が持つかを決めてください。①作る人（AIを使って実装・試験を進める）、②業務側で出力の正しさを判定する人、③社内手続きと本番反映の判断をする人です。小さな会社では1人が複数を兼ねることもありますが、作る人だけがいて判定する人がいないと「動いているが正しいか分からない」状態になり、稼働に踏み切れません。①が足りない場合は、②③を社内に残したまま、作る部分の一部を外に頼む形が取れます。

Q2. 情報システム部門がない会社でも内製できますか。

できないわけではありませんが、セキュリティ審査と本番運用の責任を誰が持つかを先に決める必要があります。情報システム部門がない会社で起きやすいのは、現場が良かれと思って作ったものが認証なしで外部に露出しているケースです。部門がない場合は、社内でAIを使って作ったうえで、認証・権限・外部公開の部分だけを外部にレビューしてもらう、または改修を頼むといった分け方もできます。

Q3. PoC（実証実験）で作ったものは、そのまま本番で使えますか。

そのまま使えるとは限りません。PoCは「実現できるか」を確認するもので、同時にアクセスする人数への対応、エラー時の処理、権限管理、ログの記録などを省いて作ることがあります。本番化に必要な期間と費用は、省いた部分の量で変わります。PoCの見積もりを取る際は、評価結果のまとめに「本番化に何が足りないか」を含めてもらってください。

Q4. 途中から内製に切り替えることはできますか。

できます。ただし、切り替えられるかどうかは発注時点の契約と納品物で決まります。本記事で挙げた7点の納品物と改変権を確保していれば、社内に担当者を置いたタイミングで引き継ぎができます。逆に、使用許諾のみの契約で、指示文や設定値が納品対象に入っていない場合は、実質的に作り直しになります。切り替えを検討する可能性が少しでもあるなら、最初の見積もり依頼の時点でその旨を伝えてください。引き渡しの範囲は、後から追加するより最初に含めるほうが安く済みます。

Q5. 外注先が撤退・倒産したら、システムはどうなりますか。

プログラム一式と環境構築手順書が手元にあり、改変と第三者への保守委託が契約で認められていれば、別の会社に引き継げます。これが揃っていないと、動いている間は使えても、修正が必要になった時点で作り直しになります。契約書で「別業者への保守移管の可否」を確認しておくことが、この状況への備えになります。当社でも、他社が作ったシステムの調査（調査のみ、または調査＋改修）を受けています。最初に、ソースコード・仕様書・環境情報があるか、それを使う権利があるかを確認します。

Q6. 補助金は内製と外注のどちらでも使えますか。

制度によって扱いが異なります。外部への委託費は対象になる制度がある一方、自社の人件費や、稼働後の保守・運用費は対象外、または対象期間に上限がある制度があります。また補助金は原則として後払い（先に支払い、後から入金される）であるため、資金繰りの計画も必要です。公募要領は年度ごとに変わるため、必ず最新の要領で対象経費を確認してください。詳しくは補助金で保守費が対象外になる理由をご覧ください。

Q7. 見積もりを依頼するとき、最低限そろえておくべき資料は何ですか。

次の4点があると、初回の相談で依頼範囲と費用の目安まで話を進めやすくなります。①対象業務の現在の手順（箇条書きで構いません）②扱うデータの種類と、どのシステムに入っているか ③その業務に関わっている人数と、月に何時間かかっているか ④社内のセキュリティ規程で、外部サービスにデータを出せるかどうか。特に④は、後から発覚すると設計を丸ごとやり直すことになる項目なので、早い段階で確認しておいてください。逆に、機能一覧や画面イメージは事前に用意する必要はありません。

Q8. 社内でAIを使って作り続けながら、一部だけを頼めますか。

頼めます。社内が画面や業務ルールを変え、外部が接続部分・認証・本番反映を担当する共同開発や、既存コードの調査・レビューだけを頼む形も選べます。その場合は、本記事の分担表のように、変えてよい範囲・承認する人・合格の条件・障害時の一次対応を先に決めてください。決めないまま始めると、同じファイルを両者が変えて衝突したり、試験が落ちたまま誰も直さなかったりします。

まとめ｜判断の順番

1. 内製できる状態かを確認する。社内データの整理と、出力の正しさを判定できる人。この2つがなければ、内製でも外注でも稼働後に止まりやすくなります（開発環境が整っている日本企業は15.3%）
2. そもそも作る必要があるかを確認する。繰り返しの定型業務なら、開発せず運用型のサービスで足りることがあります
3. 同じ成果物で比べる。毎年作る本数、人員、過年度分の保守を揃えないと、内製と外注の費用は比べられません
4. 自社で1本作る工数を知る。この記事の仮定では、社内で1本を約1.4人年より少なく作れるかどうかで、社内と外注の安さが入れ替わります。最初の1本を小さく作って、かかった時間を記録してください
5. 全部か無しかで決めない。AIで社内が進める部分と、接続・認証・本番反映・レビューなど会社に頼む部分を、成果物と責任で分けます
6. 引き取れる形で発注する。納品物7点と改変権を、見積もり段階で金額として明示させます

ご相談ください

「内製と外注のどちらにすべきか」「社内でAIを使って作り続けながら、どこを頼めばよいか」の段階からご相談いただけます。要件が決まっていなくても構いません。今の業務と、使っているシステム、手元にある試作やコードの有無を伺い、自社で進める部分・依頼する部分・そもそも作らずに済む部分を一緒に切り分けます。

• 既存システムの改修：100万円〜（画面の追加・修正、帳票やCSV出力の追加、他のシステムとのデータ連携）
• PoC（検証）：300万円〜（検証内容の整理、PoCの設計・開発、評価結果のまとめ）
• 本開発：個別見積
• ※すべて税別。クラウド利用料・外部APIの利用料・ライセンス費などの実費は別途かかります
• 公開実績：通信事業（請求情報の取込・集計・確認画面）、薬局（複数店舗の記録管理・権限・確認工程）

初回相談は無料・30分（オンライン）です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。

▶ 内製で続ける範囲と、依頼する範囲を相談する

参考にした主な資料

• 総務省「令和8年版 情報通信白書（概要）」2026年7月（PDF）
• IPA「DX動向2025」（リンク）
• 経済産業省「IT人材需給に関する調査（概要）」2019年4月（PDF）
• 経済産業省「AI・データの利用に関する契約ガイドライン」／「AIの利用・開発に関する契約チェックリスト」令和7年2月版
• 厚生労働省「職業情報提供サイト（job tag）」AIエンジニア
• PwC Japan「生成AIに関する実態調査2026 春」（リンク）
• NTTデータ経営研究所「生成AI業務アプリの内製化は『運用力』がカギ」（リンク）
• Anthropic「Best practices for Claude Code」（リンク）
• OpenAI「Build iterative repair loops with Codex」（リンク）
• 3年費用の試算は、本文に記載した仮定と式による当社の計算であり、実案件の実績値ではありません