「生成AIがあるんだから、もう外注しなくても自分たちで作れるんじゃないか」
2026年に入ってから、この言葉を経営層から聞いたという相談が増えました。
結論から書きます。「AIを使えば開発が速くなる」という前提そのものが、実験研究では割れています。 フリーランス開発者に新規の小さな課題を解かせた実験では所要時間が55.8%短縮、一方、自分が長年関わる大規模コードベースで熟練開発者に実作業をさせた実験では19%遅くなりました。どちらも無作為化比較試験（RCT）です。
割れ方には規則があります。新しく、小さく、書き手がその領域に不慣れなほど速くなり、大きく、古く、書き手が熟知しているほど効かない。 この規則を内製化の判断に当てはめると、「AIで内製化が進む領域」と「進まない領域」がかなりはっきり線引きできます。
公的統計もこの線と整合しています。JUAS（日本情報システム・ユーザー協会）の『企業IT動向調査2026』では、完全内製化を方針とする企業は4.5%、7割は内製と外注の「混成」を目指しています。上場企業クラスでも、コード生成AIを「導入済み」は15.3%にとどまります。
この記事では、システム開発・AI開発を受注する側の立場から、次の4点を解説します。
- 「AI開発の内製化」という言葉の2つの意味
- 内製化の現在地を公的統計で確認する
- 生成AIで開発は何%速くなるのか（一次研究5本の効果量）
- AIで内製化が進む領域・進まない領域の線引きと、現実的な進め方
「AI開発の内製化」には2つの意味がある
最初に言葉を整理します。「AI開発の内製化」は、文脈によって別のことを指しています。
| 意味 | 内容 | 例 |
|---|---|---|
| ① AIを組み込んだシステムを自社で作る | 生成AIや機械学習を使う業務システム・チャットボット・需要予測などを、外注せず社内で開発・運用する | 社内規程を答えるRAGチャットボット、見積書の自動下書き |
| ② 生成AIを使って、開発そのものを自社に取り戻す | これまで外注していた（AIとは無関係の）システム開発を、コーディングAIの助けを借りて社内で行う | 販売管理の帳票追加、Excel業務のWebアプリ化 |
検索で上位に出る解説記事は①の意味で書かれています。ただ、2026年時点で①の実体は「LLMのAPIを呼ぶ、普通のソフトウェア開発」に近づいており、②の道具であるコーディングAI（GitHub Copilot、Claude Code、Codex など）を使って、同じ人・同じ体制で作られます。
つまり、どちらの意味であっても問いは同じです。「AIがあれば、自社の人員で開発を回せるのか」。 この記事は両方を扱います。
内製化の現在地｜完全内製化は4.5%、7割は「混成」
まず、日本企業が実際にどこまで内製しているかを、公的統計で確認します。
使うのは JUAS『企業IT動向調査2026』（2026年4月公開、2025年度調査、回収957社）です。注意点として、調査対象は東証上場企業とそれに準じる企業で、中小企業を代表する調査ではありません。「体力のある企業でもこの水準」という読み方をしてください。
方針：内製と外注の使い分けが7割
システム開発の内製／外部委託の方針を聞いた結果（図表7-2-1、n=953）です。
| 方針 | 割合 |
|---|---|
| 完全内製化 | 4.5% |
| 内製を増やす | 11.5% |
| 内製・外部委託の混成 | 44.0% |
| 外部委託を増やす | 14.7% |
| 完全外部委託 | 18.7% |
報告書の原文はこうです。
「内製・外部委託の混成」に「内製を増やす」「外部委託を増やす」を加えると 70．2％となり、内製と外部委託を使い分ける方針の企業が大半を占める。
「内製か外注か」の二択で考えている企業は少数派で、大半は「どこを内製し、どこを外に出すか」を設計している、というのが実態です。
工程別：上流は内製、設計・実装・テストは外注
では、どの工程を内製しているのか。工程別の内製／外部委託度合い（図表7-2-3）を見ると、はっきり分かれます。
| 工程 | 内製寄り（ほぼ内製＋内製が多い） | 外注寄り（外部委託が多い＋ほぼ外部委託） |
|---|---|---|
| システム企画（システム化構想策定） | 70.9% | 17.6% |
| 機能要件定義 | 46.1% | 31.5% |
| 非機能要件定義 | 37.6% | 41.2% |
| 設計・実装・テスト | 18.5% | 63.4% |
| システム運用・保守 | 42.4% | 38.3% |
企画・要件定義という上流はすでに内製が主流です。外注の主戦場は「設計・実装・テスト」、つまりコードを書く工程です。「完全外部委託」を方針とする企業でさえ、システム企画は45.4%が内製寄りでした。
ここが重要です。生成AIが直接速くするのは、コードを書く工程です。 つまりAIによる内製化とは、「63.4%が外注しているこの帯を、どこまで社内に引き取れるか」という問いになります。
期待はコスト削減へ、壁は人材
内製化に期待する効果（図表7-2-6、複数回答）では、25年度に「開発コスト削減」が41.3%で最多になりました。前年まで最多だった「社内へのナレッジ蓄積による開発能力向上」は43.9%から35.1%へ8.8ポイント低下しています。報告書は、ベンダーの価格高騰を受けて「目の前のコスト削減の優先度が急速に高まった」と推察しています。
一方、内製化を進めるうえでの課題（図表7-2-7）は3年連続で人材です。
- 開発人材の量の不足：52.7%
- 開発人材の質の不足：49.6%
- プロジェクトマネジメント人材の不足：44.4%
いずれも前年より増えています。ここで自然に出てくるのが、冒頭の問いです。「その人材の壁を、AIが下げてくれるのではないか」。
生成AIで開発は何%速くなるのか｜一次研究5本の効果量
この問いに答えるには、ベンダーの事例発表ではなく、統制された実験で測った数値が必要です。生成AIコーディングの生産性を測った代表的な一次研究を並べます。
| 研究 | デザイン | 対象 | 結果 | 効きやすい／効きにくい条件 |
|---|---|---|---|---|
| Peng ほか（2023） | RCT | フリーランス開発者95名。新規にHTTPサーバを実装する小課題 | 所要時間 −55.8%（95%信頼区間 21〜89%） | 経験が浅い開発者ほど効果大 |
| Cui ほか（2026、Management Science） | フィールド実験×3（Microsoft・Accenture・Fortune 100企業） | 企業内開発者4,867名 | 週の完了タスク +26.08%（標準誤差10.3%） | 若手・新規入社では有意、勤続の長いシニアでは有意でない |
| METR（2025） | RCT | 熟練OSS開発者16名、自分が平均5年関わるリポジトリの実issue 246件 | 所要時間 +19%（遅くなる） | 大規模（平均110万行超）・成熟・熟知したコードベース |
| METR（2026年2月 追跡） | RCT | 57名・800タスク超（エージェント型ツール含む） | 元参加者 −18%（区間 −38〜+9%）、新規参加者 −4%（区間 −15〜+9%） | どちらも区間が0をまたぐ。選択効果あり |
| DORA（2025） | サーベイ | 約5,000名 | スループット・製品性能とは正の関係、デリバリーの安定性とは負の関係 | 「AIはチームを直さない。すでにあるものを増幅する」 |
符号を分ける3つの条件
同じ「生成AIでコードを書く」実験で、−55.8%から+19%まで割れています。研究者自身が挙げている要因を整理すると、3つの条件に集約できます。
1. コードベースの規模と成熟度
METR の研究で遅くなった開発者は、平均10年・110万行超のリポジトリで作業していました。AIが生成したコードの採用率は44%未満で、多くの参加者が「大幅な手直しが必要だった」と報告しています。著者はこう注意しています。
私たちの結果は、小規模なグリーンフィールド（新規）プロジェクトや、不慣れなコードベースでの開発では、AI支援によって大幅な高速化が起きることと矛盾しない。
2. 開発者の習熟度
Peng の実験では経験の浅い開発者ほど効果が大きく、Cui の実験では若手・新規入社で有意な効果、勤続の長いシニアでは有意な効果が出ませんでした。AIは「知らないことを補う」局面で強く、「すでに知っている人」の手を速くする効果は限定的です。
3. 体感と実測のずれ
METR の参加者は、実験前に「AIで24%速くなる」と予測し、実際には19%遅くなったあとでも「20%速くなった」と体感していました。経済学とML（機械学習）の専門家の予測はそれぞれ−39%、−38%でした。「使ってみたら速い気がする」は、判断材料になりません。
速くなっても「安全」とは限らない
もう1つ、内製化の判断で落とせない研究があります。スタンフォード大学の Perry ほか（2023、ACM CCS）は、47名にセキュリティに関わる5つの課題を解かせ、AIアシスタントの有無で比較しました。
- 5課題中4課題で、AIを使った群のほうが安全でないコードを書いた
- SQL の課題では、SQLインジェクションに脆弱な解答が AI群36%、対照群7%
- AIを使った群は、自分のコードを「安全だ」と信じる傾向が強かった
2022年時点のモデルを使った小規模な実験なので、数値そのものより構造に注目してください。速くなることと、外に出せる品質になることは別の問題であり、しかも使っている本人はその差に気づきにくい。DORA 2025 が「スループットは上がるが安定性は下がる」と報告しているのと同じ構図です。
IPA『DX動向2026』（回収1,799社）でも、「プログラムコードやシステム開発支援」の用途は効果が出ている割合が高い一方、「効果が出ていない」も3割弱あると記されています。
線引き｜AIで内製化が進む領域・進まない領域
ここまでの研究の条件を、そのまま内製化の判断表にします。
| AIで内製化が進む領域 | AIでも内製化が進みにくい領域 | |
|---|---|---|
| 対象 | 新規・小規模・単機能の社内ツール（帳票、集計、申請フロー、社内FAQボット、RAGの検証） | 基幹系・大規模・長期運用のシステム（販売管理・生産管理・会計連携の本体） |
| コードベース | ゼロから、または数千行規模 | 既存の大規模コード、他システムとの連携が多い |
| 担当者 | 業務は詳しいが開発経験は浅い人でも成立しやすい | 熟練者でもAIの効果が出にくく、設計判断は人が担う |
| 失敗したとき | 作り直せる、止まっても業務が回る | 顧客データ・取引・会計に影響する |
| 対応する研究 | Peng 2023／Cui 2026 の条件 | METR 2025／2026 の条件、Perry 2023 のリスク |
進む領域は、JUAS の工程表で言えば「設計・実装・テスト」のうち、小さく切り出せる部分です。ここは実験研究が一貫して大きな効果を示しており、業務を知っている社内の人が作ることの価値も大きい。
進みにくい領域は、失敗のコストが高く、コードベースが大きく、セキュリティ要件が重い部分です。ここでAIを使うこと自体は問題ありませんが、「AIがあるから内製できる」の根拠にはなりません。 熟練者を対象にした最新の追跡研究でも、速くなった証拠は得られていない（信頼区間が0をまたぐ）ことを思い出してください。
もう1つ、表に入れていない工程があります。運用・保守です。JUAS の調査では内製と外注が拮抗（42.4% 対 38.3%）していました。AIで速く作った社内ツールも、作った瞬間から保守対象になります。担当者が異動した後に誰が直すのか。これは AIの性能ではなく体制の問題で、内製化で最も後から効いてくる部分です。
日本企業に足りないのは道具ではなく環境
「では、コーディングAIを契約すれば進むのか」というと、そう単純ではないことを総務省のデータが示しています。
総務省『令和8年版 情報通信白書』（2026年7月24日公表）の企業向け国際比較です。日本企業で生成AIを何らかの業務で使っている割合は86.4%まで上がりました。前年の55.2%からの急伸で、米国90.9%・ドイツ91.6%との差はほぼなくなっています。
差が残っているのは「環境整備」です。
| 環境整備の項目 | 日本 | 米国 | ドイツ | 中国 |
|---|---|---|---|---|
| 業務プロセスの見直しや生成AI活用検討に必要なスキルやノウハウを学ぶ環境がある | 39.9% | 62.7% | 60.4% | 71.7% |
| 生成AIに社内データを学習させたり、生成AIが参照可能なデータベースを構築したりしている | 24.5% | 57.2% | 54.4% | 73.0% |
| 社員が生成AIを活用したアプリやAIエージェントを開発可能な技術環境にある | 15.3% | 22.1% | 27.4% | 31.1% |
最後の行が、まさに「AI開発の内製化」の土台です。社員がAIアプリやエージェントを開発できる技術環境を持つ日本企業は15.3%。さらに、生成AIによる業務変革について「組織的な取り組みはない」と答えた日本企業は27.0%で、米国1.4%・ドイツ4.9%・中国2.6%と桁が違います。
つまり日本の現状は、個人はAIを使っているが、会社としてAIで何かを作れる環境を整えていない、という段階です。IPA の調査でも、AI導入・運用上の課題の1位は「専門人材が不足している」50.1%、DX推進人材の量が不足している企業は85.5%でした。
内製化とは、ツールの契約ではなく、この15.3%側に入るための環境整備です。
受注側から見た、現実的な進め方
最後に、開発を受注する側から見た進め方を書きます。
前提として、内製化は行政が2020年に方向として示した既定路線です。経済産業省『DXレポート2（中間取りまとめ）』は、競争領域のシステムについて「アジャイルな開発体制を社内に構築し、市場の変化をとらえながら小規模な開発を繰り返すべき」と述べ、同時にベンダーの役割をこう書いています。
ベンダー企業はこうした事業機会を顧客企業への客先常駐ビジネスとするのではなく、対等なパートナーシップを体現できる拠点において、ユーザー企業とアジャイルの考え方を共有しながらチームの能力を育て（共育）、内製開発を協力して実践する（共創）べきである。
受注側として、この方向に異論はありません。そのうえで、データに照らして現実的だと考える順番は次の3段階です。
ステップ1：上流は最初から自社で持つ
JUAS の調査で企画の70.9%がすでに内製されている通り、「何を作るか」「なぜ作るか」は外に出すものではありません。内製化の課題で「システム企画力不足（ビジネス要件をシステム仕様に落とせない）」が34.5%挙がっていますが、ここはAIで代替できる工程ではなく、社内で育てる部分です。
ステップ2：AIで「進む領域」の小さなツールから内製し、ガードレールを先に置く
実験研究が一貫して効果を示す条件、つまり新規・小規模・業務を知っている人が作る社内ツールから始めます。ただし Perry の研究と DORA の結果を踏まえて、作る前に3つを決めておきます。
- レビュー：AIが書いたコードを、書いた本人以外が見る手順（社内に見られる人がいなければ、この部分だけ外部に頼む）
- データの境界：顧客情報・個人情報を扱うツールは最初の対象にしない
- 保守の担当：作った人が異動したら誰が直すか。決まらないなら作らない
ステップ3：大規模・基幹はベンダーと「混成」で組み、スキル移転を契約に入れる
METR の条件に当たる領域は、無理に内製へ寄せず、ベンダーとの混成で進めるほうが結果が安定します。そのとき、単に丸投げするのではなく、社内の担当者が設計レビューや実装の一部に入り、スキルが社内に残る形を最初から契約と体制に組み込みます。DXレポート2 が「共育・共創」と呼んだのはこの形です。
JUAS の調査で「ナレッジ蓄積」への期待が8.8ポイント下がり「コスト削減」が最多になったことは、受注側から見ると少し心配な傾向です。コスト削減だけを目的にした内製化は、人材の壁（量52.7%・質49.6%）に当たったところで止まります。 ナレッジが社内に残る設計にしておくと、止まったときに戻れる場所ができます。
まとめ
現在地
- 完全内製化を方針とする企業は4.5%、7割は内製と外注の混成（JUAS 2026、上場企業クラス）
- 上流（企画70.9%）はすでに内製、設計・実装・テストは63.4%が外注。AIが直接効くのは後者
- コード生成AIを「導入済み」は上場企業クラスでも15.3%
AIで速くなるのか
- 新規・小規模・経験の浅い書き手では大きく速くなる（−55.8%、+26.08%）
- 大規模・成熟・熟知したコードベースの熟練者では速くならない（+19%、2026年追跡でも区間が0をまたぐ）
- 速くなっても安全とは限らず、本人は気づきにくい（Perry 2023、DORA 2025）
線引き
- 進む領域：新規・小規模・単機能の社内ツール
- 進みにくい領域：基幹・大規模・長期運用・高セキュリティ要件
- 運用・保守は作った瞬間から始まる。担当が決まらないものは作らない
進め方
- 上流は自社で持つ → 小さなツールをガードレール付きで内製 → 大規模はベンダーと混成し、スキル移転を契約に入れる
- 日本企業で社員がAIアプリを開発できる環境を持つのは15.3%。内製化はツール契約ではなく、この環境整備そのもの
「AIがあるから内製できる」ではなく、「AIが効く条件が揃っている部分から内製し、揃っていない部分は揃うまで混成で進める」。判断の出発点はツールの性能ではなく、自社のコードベースの大きさ・担当者の習熟・失敗したときのコストです。
出典
- 一般社団法人日本情報システム・ユーザー協会（JUAS）『企業IT動向調査報告書2026』（2026年4月、2025年度調査、回収957社）図表7-2-1〜7-2-7、8-1-1、8-3-1
- 独立行政法人情報処理推進機構（IPA）『DX動向2026』およびプレス発表「国内企業のDX動向・AI活用動向のポイントを公開」（2026年7月16日、回収1,799社）
- 総務省『令和8年版 情報通信白書』第Ⅰ部 第2章 第1節「企業におけるAI利用の現状」（2026年7月24日公表）
- 経済産業省 デジタルトランスフォーメーションの加速に向けた研究会『DXレポート2（中間取りまとめ）』（2020年12月28日）
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590
- Cui, Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science. doi:10.1287/mnsc.2025.00535
- Becker, J., Rush, N., Barnes, E., & Rein, D. (METR) (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089／METR (2026年2月24日) We are Changing our Developer Productivity Experiment Design
- Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023. arXiv:2211.03622
- Google Cloud DORA (2025). State of AI-assisted Software Development（2025年9月、回答者約5,000名）
社内のどこまでを内製し、どこをベンダーと組むか。線引きの段階からご相談いただければ、開発を受注する側の視点でお手伝いします。お問い合わせフォームからご連絡ください。
