---
title: "大手企業のシステム内製化とセキュリティリスク | Sales Retriever"
url: "https://www.sales-retriever.jp/column/enterprise-system-insourcing-security-risk"
description: "大手企業のシステム内製化とセキュリティリスクを解説。自社側の開発・改修を確認できるSaaStr、Moltbook、Knight Capitalの3事例を図解し、日米の人材差と継続保守から導入条件を整理します。"
---

[コラム一覧](https://www.sales-retriever.jp/column) AI・セキュリティ

# 大手企業のシステム内製化とセキュリティリスク

![大手企業の社内システムを支える保守とセキュリティの基盤を描いた概念イラスト](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/cover.webp)

AI時代のメリットと日米の人材差から考える、リリース後の保守と脆弱性対応

AIを使えば、自社の業務に合うシステムを短期間で作れるようになりました。外注費やSaaSの利用料を抑え、現場の要望にすぐ応える。内製化を検討する大手企業にとって、魅力のある選択肢です。

しかし、顧客情報や人事・財務データを扱う社内システムでは、完成後も安全性を維持し続けなければなりません。開発費が下がっても、認証・権限管理、脆弱性対応、障害復旧の責任は残ります。

本記事の「内製」は、自社側で設計・開発・改修を担うことを指します。主に社内の業務システムを想定し、AIを使う開発も含めて考えます。海外事例には、自ら開発した公開サービスも含むため、各事例で用途を明記します。

**セキュリティを設計・検証できるエンジニアと、継続して保守する組織・予算がそろわない段階では、本番システムの内製化は一旦見送る。** 海外のAI開発に関する調査と日本の人材事情を踏まえると、これが慎重な経営判断になります。

配布用PDF： [図解で読む システム内製化とセキュリティリスク（13ページ・約560KB）](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/enterprise-system-insourcing-security-guide.pdf)

※アイキャッチはAIで制作した概念イラストです。実在の企業や被害を描いたものではありません。

## 内製化のメリットと必要な体制

内製化の利点は、**自社が必要とする機能に投資を集中できる**ことです。独自の承認フローやデータの持ち方に合わせて設計し、現場の声を改善に反映しやすくなります。既存のサービスでは十分に対応できない業務ほど、この価値は大きくなります。

AIは、画面の試作や定型的なコード作成を支援します。要件が限定されたツールであれば、**開発着手までの待ち時間や一部の外注費を抑えられる可能性**もあります。米CIOも、AIで社内ツールを作る企業への取材を通じて、柔軟性と開発の速さを利点として紹介しています。 [出典1](https://www.cio.com/article/4148288/vibe-coding-your-own-enterprise-apps-is-edgy-business.html)

また、開発と改善に関与することで、**業務知識や設計上の判断を社内に蓄積**できます。ただし、担当者個人に知識が閉じたままでは組織の資産になりません。設計書、レビュー、引き継ぎまで含めて初めて、外部依存の低減につながります。

費用面も条件付きです。Lucidの営業向け社内ツールの内製経験を扱う記事では、AIの利用費、コード品質、セキュリティ監査、継続保守が課題になっています。**試作が安く済んだことだけで、長期的にも割安だとは判断できません**。 [出典2](https://airfocus.com/blog/product-managers-building-internal-ai-tools/)

こうしたメリットを得るには、開発を担う人に加え、**安全性を検証する人、更新と障害復旧を担う人を確保する必要**があります。次に、日本と米国でその担い手の状況がどう異なるかを確認します。

## 日米で異なる、内製化を支える人材構造

海外の事例を読むときには、その企業がもともと持っている開発体制を見る必要があります。ここでは、比較できる公的統計のある米国を中心に、日本との違いを確認します。

### IT人材がどこに所属しているかが違う

IPAの「DX白書2023」に関連する日米比較では、情報処理・通信に携わる人材のうち、IT企業以外に所属する割合は**日本26.4％、米国64.9％**でした。日本はIT企業側に人材が集中し、米国はIT企業以外にも多くの人材がいる構造です。 [出典3](https://www.ipa.go.jp/archive/event/2022/hjuojm000000cfks-att/000109379.pdf)

 [![情報処理・通信人材の所属先を示す日米比較 日本はIT企業以外26.4パーセント 米国は64.9パーセント](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/workforce.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/workforce.svg)

※日本は2020年、米国は2021年の統計に基づく比較です。各国内の対象人材の所属先構成であり、各企業の社員に占めるエンジニア比率や、セキュリティ能力を示す数字ではありません。

この違いから、米国企業がAIを導入した事例を「専門家が少なくても内製できる証拠」と読むことはできません。AIが、既存の開発者やレビュー体制を補助している可能性も考慮すべきです。

### 日本では内製化を担う人材の確保が課題になる

IPA「DX動向2025」では、内製化を進めている、または必要な部分を内製化済みと答えた企業の合計は**日本39.0％、米国83.5％**でした。一方、日本で内製化を進めている企業334社の**82.3％が、人材の確保・育成の難しさ**を課題に挙げています。 [出典4](https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf)

同じ調査のDXに取り組む企業では、推進人材の「量」が不足しているとの回答は**日本85.1％、米国23.8％**でした。 [出典5](https://www.ipa.go.jp/digital/chousa/discussion-paper/j5u9nn000000abx5-att/dx2025_digital_talent_ai_era.pdf)

| 比較する指標 | 日本 | 米国 | 読み取れること |
| --- | --- | --- | --- |
| 内製化を推進中または必要部分を内製化済み | **39.0％** | **83.5％** | 内製化への取組状況に差がある |
| DX推進人材の量が不足 | **85.1％** | **23.8％** | 日本では必要な担い手の不足感が強い |

※「DX動向2025」の日米比較。内製化は日本1,500社・米国509社、人材不足はDXに取り組む企業が対象です。どちらも大手企業だけの集計ではなく、開発経験を直接測った設問でもありません。

さらに、国内調査「DX動向2026」でも、DXに取り組む企業の**85.5％**が推進人材の量の不足を回答しています。**従業員301人以上の企業では9割を超えます**。企業規模が大きいことだけを、人材が十分な根拠にはできません。 [出典6](https://www.ipa.go.jp/digital/chousa/dx-trend/rcu1hd0000017uk8-att/dx-trend-2026.pdf)

### 情報システム部門の業務と開発経験を確認する

これらの統計から、日本の情報システム担当者の能力や開発経験を一律に判断することはできません。確認すべきなのは、自社で実際に担っている仕事です。

端末管理、社内問い合わせ、アカウント運用、ベンダーとの調整を担う経験と、アプリケーションの設計・実装・セキュリティ検証を担う経験は異なります。委託管理を中心に組織を作ってきた企業が内製化するなら、開発と保守に必要な役割を新たに確保する必要があります。

AIによってコードを作れる人数が増えても、**そのコードを評価し、事故時に修復できる人数が同じように増えるとは限りません**。海外企業の成功例を採用する前に、自社の開発体制を確認すべき理由はここにあります。

## AIで作れても残る実装・権限管理のリスク

ここで扱うAI開発は、AIに自然言語で指示してコードを作らせる方法です。専門家が設計・レビューする開発と、生成結果を十分に理解せず本番に使う開発では、リスクの管理水準が異なります。

### 動作確認に合格しても安全性は保証されない

Veracodeの2026年レポートでは、4言語・4種類の脆弱性を対象とした80のコード補完課題において、**生成結果の約44％に既知の脆弱性が検出**されました。セキュリティを特に指示しない条件での検証です。 [出典7](https://view.ceros.com/veracode/genai-code-security-report2026)

これは**実際の社内システムの44％が危険という統計ではありません**。ただし、機能を実現できるAIでも、安全な実装を常に選ぶわけではないことを示しています。

Databricksのレッドチームも、AIで生成した正常に動くアプリに、任意のコードを実行され得る欠陥を確認しました。同社は、セキュリティを意識した指示やレビューで改善できることも報告しています。**AIが修正を支援できることと、検証を省いてよいことは別**です。 [出典8](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding)

### ログイン画面があっても権限管理には穴が残る

社内システムで重要なのは、**利用者を確認する「認証」**に加えて、その人がどの情報を**閲覧・変更できるかを制限する「認可」**です。

例えば、一般社員がURLの番号を変えると他部署の人事情報を読める、閲覧専用の利用者がデータを書き換えられる、といった状態は、ログイン機能だけでは防げません。こうした権限の抜けは、いつもの操作を試すだけの動作確認では見つけにくい問題です。

GMOサイバーセキュリティ byイエラエも、AI生成アプリの認証・認可の不備や過剰権限を挙げ、社内ツールでも連携部分と権限を検証する必要性を説明しています。 [出典9](https://gmo-cybersecurity.com/column/assessment/vibecoding/)

## 自社で開発・改修したシステムの海外事例

当事者や公表資料から、自社側での開発・改修を確認できる3事例を紹介します。SaaStrはコミュニティ向けアプリ、Moltbookは公開SNS、Knight Capitalは取引業務システムの事例です。

**内製システムで起きた事故であることと、内製化そのものが原因であることは別です。** 開発主体、発生した事象、原因として報告された内容を区別して記載します。

### 事例1：SaaStr――AIの開発作業が本番データを削除

**対象システム。** SaaStr創業者がReplitのAIエージェントを使って自ら開発していた、コミュニティ向けアプリです。社内専用システムではありませんが、自らアプリを開発した事例として扱います。 [出典10](https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/)

**何が起きたか。** 2025年7月、SaaStr創業者のJason Lemkin氏は、ReplitのAIエージェントでコミュニティ向けアプリを開発中、本番データベースが削除されたと公表しました。同氏によると、**経営幹部1,206件、企業プロフィール1,196件超**の記録が対象でした。 [出典10](https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/)

**どこに問題があったか。** 同氏の説明では、**開発と本番でデータベースが分かれておらず**、開発中のAIが本番を直接操作できました。「変更しないで」という指示も、権限を取り上げる仕組みにはなっていませんでした。AIは当初、復元できないと誤って説明しましたが、**最終的にデータは復旧した**と報告されています。 [出典10](https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/)

 [![SaaStrのデータ削除事例 開発中のAIが分離されていない本番データベースに到達し削除 最終的には復旧した流れ](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-saastr.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-saastr.svg)

※当事者の説明に基づく模式図です。実際の画面や、恒久的なデータ消失を示すものではありません。

### 事例2：Moltbook――画面の裏のデータベースに権限制限がなかった

**対象システム。** 創業者が技術構成を考え、AIを使って自ら制作した公開SNSです。Wizは、創業者がAIによる開発を公に説明していたことを紹介しています。社内向けではなく、サービス運営者側で開発したシステムの事例です。 [出典11](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

**何が確認されたか。** Wizは2026年2月、AIを使って制作された公開SNS「Moltbook」で、認証なしのデータ閲覧・書き換えが可能な設定不備を報告しました。**約150万件のAPI認証トークン、約3万5,000件のメールアドレス**、非公開メッセージが露出したとしています。 [出典11](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

**どこに問題があったか。** ブラウザーに配信されるコードから、データベースへの接続情報を確認できました。ここに含まれる公開用キー自体は、公開を想定したものです。問題は、データベース側で利用者ごとのアクセスを制限する**「行レベルセキュリティ（RLS）」が欠けていた**ことでした。 [出典11](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

 [![Moltbookの情報露出事例 利用画面の裏でデータベースへの直接要求が権限確認されず 閲覧と書き換えが可能だった構造](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-moltbook.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-moltbook.svg)

※研究者が確認したアクセス経路の模式図です。公開用キーを置くこと自体が危険という意味ではありません。

Wizは読み取り制限後にも投稿の書き換えが可能なことを確認し、複数回の修正を経てアクセス制限を検証しました。これは研究者による露出・操作可能性の確認であり、悪意ある第三者が全件を持ち出したと確認された事件とは区別します。 [出典11](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

### 事例3：Knight Capital――8台中1台の更新漏れが大量の誤発注に

**対象システム。** 同社の取引業務に用いる注文転送システム「SMARS」です。SECの行政命令は、同社によるコードの開発・配布と、同社技術者の更新作業を記載しています。 [出典12](https://www.sec.gov/litigation/admin/2013/34-70694.pdf)

**何が起きたか。** 米証券取引委員会（SEC）によると、Knight Capitalは2012年8月1日、**約45分間にわたり大量の誤った注文を市場へ送り、4億6,000万ドル超の損失**を被りました。これはAIや外部からの侵入ではなく、自社で改修・運用する取引システムの更新と統制の事故です。 [出典13](https://www.sec.gov/newsroom/press-releases/2013-222)

**事故までの流れ。** 新機能への切り替え時、**8台のサーバーのうち1台に新コードが配布されませんでした**。そのサーバーには、使わなくなった「Power Peg」という古い処理が残っていました。新機能の起動に古い処理と同じフラグを再利用したため、更新されていない1台だけで古い処理が動き、必要数量を超えて注文を送り続けました。 [出典12](https://www.sec.gov/litigation/admin/2013/34-70694.pdf)

 [![Knight Capitalの事故 7台は更新済みで1台が未更新 同じ起動信号で残存した古い処理が動き 大量の誤発注につながった流れ](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-knight.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/case-knight.svg)

※SECの公表資料に基づく模式図です。サイバー攻撃やAI生成コードの事故を示すものではありません。

**なぜ被害を止められなかったか。** SECは、配布作業を別の担当者が確認する手順や、異常な発注を抑える統制が不十分だったと指摘しています。市場が開く前には関連エラーを示す**自動メール97通**が届いていましたが、対応されませんでした。稼働後の約45分間に、わずか**212件の顧客注文**を処理する過程で**400万件超の注文**が市場に送られました。 [出典13](https://www.sec.gov/newsroom/press-releases/2013-222) [出典12](https://www.sec.gov/litigation/admin/2013/34-70694.pdf)

## 社内限定でも残る侵入・被害拡大のリスク

社内アクセスの制限、相手の本人確認、アプリの権限は、それぞれ別に確認する必要があります。大手企業では侵入口だけでなく、接続後にどのデータや業務まで影響するかも論点になります。

### VPN接続後にも認証・権限管理が必要

VPNやIPアドレスによるアクセス制限は、外部から到達できる範囲を狭める対策です。しかし、接続できた利用者がすべて正当であることや、接続した端末が感染していないことまでは保証しません。

NISTのゼロトラストの考え方でも、**社内ネットワークにいるという理由だけで利用者や端末を信頼せず**、認証と認可を確認することが前提になっています。 [出典14](https://csrc.nist.gov/pubs/sp/800/207/final)

実際にCiscoが2022年に公表した事件では、盗まれた従業員の認証情報と、MFA承認を促す電話などを使ってVPNへの接続が成立し、その後、攻撃者が管理者権限を獲得して複数のシステムにログインしました。Ciscoは、製品開発などの重要システムへのアクセスを示す証拠は確認していないと説明しています。 [出典15](https://blog.talosintelligence.com/recent-cyber-attack/)

 [![認証情報の窃取からVPN接続 社内アプリへの到達 権限不備による被害拡大までの概念図](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/access-path.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/access-path.svg)

※侵入と被害拡大の可能性を説明する概念図です。Cisco事件で内製アプリの脆弱性が悪用されたことを示す図ではありません。

内製システムを社内に置く場合も、アプリごとの認証、最小限の権限、通信先の制限、監視が必要です。入口のVPNが突破された場合に、何のデータまで触れられるのか。この視点で設計と検証を行わなければ、社内限定という条件を過信することになります。

### 企業名や担当者を調べる標的型攻撃

大手企業では、偶然見つかった弱点への攻撃だけでなく、**特定の企業を選び、企業名・担当者・業務の事情に合わせて侵入を狙う標的型攻撃**を想定する必要があります。会社の名前を知っている、実在する社員の名前を名乗る、といった事情だけで、相手を信頼することはできません。

FBI・CISAなどが2025年7月に更新した共同注意喚起は、犯罪グループ「Scattered Spider」が、**大企業とその委託先のITヘルプデスク**を標的にすると明記しています。社員になりすまし、パスワードの初期化やMFAの移し替えを求める手口が報告されています。 [出典16](https://www.fbi.gov/file-repository/cyber-alerts/scattered-spider-072925.pdf)

Microsoftも、関連する攻撃活動「Octo Tempest」について、組織や対象者を調べてなりすまし、サポート担当者にパスワードやMFAを再設定させる手口を説明しています。無差別なメールへの注意だけでは足りず、正規の窓口と手続きを悪用されることにも備えなければなりません。 [出典17](https://www.microsoft.com/en-us/security/blog/2023/10/25/octo-tempest-crosses-boundaries-to-facilitate-extortion-encryption-and-destruction/)

 [![特定の企業名や担当者を調べる標的型攻撃 公開情報からなりすまし IT窓口で認証を再設定させ 社内システムに到達し得る流れ](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/targeted-attack.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/targeted-attack.svg)

※FBI・CISAおよびMicrosoftの報告を参考に作成した概念図です。特定の上場企業や内製アプリで、この図の全段階が実際に起きたと示すものではありません。

上場企業が公開するIR資料、役員情報、採用情報や、社員が公開する職歴なども、攻撃者が参照できる情報です。公開情報を扱う必要性は残したまま、そこで分かる氏名・所属を知っていることと、本人であることを区別すべきです。これは上記の攻撃手法を踏まえた、本記事のリスク評価上の考察です。

なお、「上場企業は中小企業より一律に狙われやすい」「内製化の事故率が必ず高い」という結論は、今回の資料からは導けません。Verizonの2025年DBIRにも中小企業の被害が多数収録されていますが、収録件数は各企業の攻撃される確率を示すものではありません。企業規模・上場の有無と、個別の攻撃リスクを分けて評価します。 [出典18](https://www.verizon.com/business/resources/T850/reports/2025-dbir-data-breach-investigations-report.pdf)

### 小さな内製アプリでも接続先の権限で影響が広がる

大手企業で慎重に確認すべきなのは、**アプリの規模よりも接続先**です。画面が数枚のツールでも、顧客データベースの全件閲覧権限や、基幹システムを書き換える権限を持たせれば、事故時に広い範囲へ影響し得ます。

例えば、営業の集計ツールに顧客情報の大量取得を許可する、業務自動化に強い管理者権限を与える、人事と財務を一つの連携用アカウントで扱う。こうした設計では、用途が小さくても保護すべき範囲は小さくなりません。

ここでの論点は、大手企業の内製化事故率が高いという主張ではありません。多数の利用者、機密情報、他システムへの権限を持つアプリでは、欠陥が残った際の被害拡大を考慮する必要がある、という経営上の判断です。

部署ごとに内製ツールが増えるなら、何が稼働し、誰が責任を持ち、どの権限でどのデータに接続するのかを一覧で把握できることが前提になります。

## 内製・外注に共通するリリース後の費用と保守責任

内製化でも委託開発でも、システムの完成後に運用・更新・脆弱性対応が続きます。初期費用とリリース後の責任を合わせて比較します。

### 内製化の費用は運用・更新・人材まで含める

内製化の見積もりでは、画面や機能を作る工数に目が向きがちです。しかし、**費用を比較する期間は完成まででは足りません**。自社で安全に運用するための支出と、担当者が他の仕事に使えなくなる時間まで含めて評価します。

 [![内製化の費用として初期開発のほかにセキュリティ 運用 更新 人材継続が必要なことを示す図](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/ownership-cost.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/ownership-cost.svg)

※費用項目の概念図です。面積は費用の実測値や構成比を表していません。

| 費用と責任 | 内製化の予算に含めるもの |
| --- | --- |
| 設計と初期開発 | 要件整理、実装、権限設計、テスト、既存データの移行 |
| セキュリティ | コードレビュー、脆弱性診断、秘密情報管理、アクセス権の棚卸し |
| 継続運用 | ログ監視、バックアップ、復旧訓練、障害時の一次対応 |
| 更新と改修 | ライブラリ更新、API変更への対応、制度・業務変更への追随 |
| 人材の継続性 | 採用・育成、複数担当者、引き継ぎ、退職時の対応 |

「担当者の空き時間で保守する」「問題が起きたらAIに直してもらう」という前提では、対応時間も品質も約束できません。運用責任者が、リスクに応じて修正を判断し、再検証して反映する時間を確保する必要があります。

日々の状態把握と、脆弱性・変更情報の確認は継続して行います。更新は毎日機械的に行うという意味ではなく、深刻度、影響範囲、業務停止のリスクを見て、必要な時期に安全に適用できる状態を指します。

### 安価な開発委託にも継続保守の契約が必要

この問題は、内製化だけに限りません。以前から取引のあるパートナー企業や、初めて依頼する外部ベンダーに安く開発を委託できても、その価格にリリース後の監視・改修まで含まれているとは限りません。

納品時の検査で問題が見つからなくても、**半年後や1年後**に、使っているライブラリやOS、認証基盤の脆弱性が新たに公表されることがあります。保守契約がなく、誰も情報を確認・修正しなければ、動き続けているシステムに危険が残ります。安価な委託先ほど放置するという意味ではなく、**開発と継続保守は、契約上も実務上も別に確保する必要がある**ということです。

Veracodeの2026年の別の調査では、**分析対象組織の82％**が、**1年以上未修正の脆弱性**を意味する「セキュリティ負債」を抱えていると報告しています。これは安価な委託開発の事故率ではありませんが、脆弱性を発見しても修正が長期間残る問題を示しています。 [出典19](https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/)

NISTのセキュア開発の枠組みも、脆弱性の継続的な特定・確認と、優先順位を付けた対応を求めています。**納品時の一度きりの確認で、運用期間全体の安全性を保証することはできません**。 [出典20](https://csrc.nist.gov/pubs/sp/800/218/final)

外部に委託するなら、少なくとも次の点を開発費とは分けて確認します。

**保守の期間と担当者**：いつまで、誰が、脆弱性情報とシステムの状態を確認するのか。

**修正の対象と費用**：独自コード、外部ライブラリ、OS・クラウド設定のどこまで対応するのか。

**緊急時の対応**：悪用が確認された脆弱性の受付時間、優先順位、暫定対策、修正の目標時間をどう定めるか。

**更新後の確認**：修正による業務影響を試験し、安全に反映・切り戻しできるか。

**保守終了時の引き継ぎ**：ソースコード、依存ソフトの一覧、構成、運用手順、管理権限を引き継げるか。

開発時点の品質は出発点です。リリース後も新しい脆弱性や攻撃の動きに合わせて、監視・見直し・更新を続けられることを重視してください。**安く作れる相手より、安全に維持する責任と費用を明確にできる体制を選ぶ。** 内製と外注の両方に共通する判断基準です。

## 本番導入前に確認する体制と判断基準

内製化を判断する際は、優秀なエンジニアが一人いるかだけを確認しても不十分です。実装者が休んだ場合や退職した場合でも、組織として安全性を維持できる必要があります。

以下は、本番導入を判断するための確認項目です。自社のデータの機密性と業務への影響に応じて、必要な水準を定めてください。

**設計を担う人材**：認証・認可、データ保護、外部連携まで説明し、AIの実装を評価できる担当者がいる。

**独立した検証**：実装者任せにせず、別の担当者や専門家が権限の抜けと攻撃への耐性を検証する。

**保守する時間と予算**：通常業務と兼任でも、監視、更新、障害対応を担える工数が確保されている。

**事故時の対応**：停止判断、連絡先、アクセス遮断、復旧の手順を決め、実行できる。

**担当者の継続性**：コード、構成、権限、運用手順が共有され、代替担当者が対応できる。

**接続範囲の管理**：実データや本番への接続を承認し、権限を限定して定期的に見直せる。

 [![内製化の判断は独自開発の必要性 安全な開発体制 継続保守と復旧の順で確認し 未整備なら本番導入を保留するという流れ](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/decision.svg) 図解を拡大](https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/decision.svg)

未整備の項目が残る場合、**機密情報や基幹業務に接続する本番導入は一旦保留**し、既存サービスの利用、専門家の伴走、対象業務の縮小を先に検討することを勧めます。試作を続けるなら、本番と隔離し、ダミーデータで価値を確認する方法があります。

既存サービスや外部委託にもリスクはあります。選定時は、提供側と自社の責任分担、アクセス制御、更新方針、監査情報、障害時の支援、データの持ち出し方法を確認します。外部サービスを使うだけで安全になるわけではありませんが、自社で負う開発・保守の範囲を比較できます。

経済産業省の2025年のレガシーシステムに関するレポートは、ユーザー企業による可視化と内製化、上流人材の育成・確保を提言しています。内製化は、適切な体制のもとで企業の変革に役立つ手段です。 [出典21](https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html)

**安全性を検証する人がいない。更新を続ける時間がない。事故時の責任者が決まっていない。そうした状況なら、社内システムの内製化は今すぐ進めず、体制を整えるまで一旦見送る判断が合理的です。**

## 参考情報

参照日：2026年10月20日。調査時点・対象・設問が異なるため、各数値を一つの母集団の割合として合算することはできません。

[1\. CIO — Vibe coding your own enterprise apps is edgy business（2026年3月26日）。AIによる内製のメリットと運用責任を扱う取材記事。](https://www.cio.com/article/4148288/vibe-coding-your-own-enterprise-apps-is-edgy-business.html)

[2\. airfocus by Lucid — Build vs. buy in the age of AI（2026年8月18日）。営業向け社内ツールの内製経験。](https://airfocus.com/blog/product-managers-building-internal-ai-tools/)

[3\. IPA — DX白書2023 日米のIT人材比較 解説資料（2023年）。国勢調査と米国職業雇用統計に基づく所属先比較。日本2020年・米国2021年。](https://www.ipa.go.jp/archive/event/2022/hjuojm000000cfks-att/000109379.pdf)

[4\. IPA — DX動向2025 本文（2025年6月）。図表2-14・2-16、本文p.43・45。内製化の取組状況と人材確保・育成の課題。](https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-2025.pdf)

[5\. IPA — DX動向2025 AI時代のデジタル人材育成（2025年10月）。p.1の日米比較。DXに取り組む企業の人材不足の回答。執筆者見解によるディスカッション・ペーパー。](https://www.ipa.go.jp/digital/chousa/discussion-paper/j5u9nn000000abx5-att/dx2025_digital_talent_ai_era.pdf)

[6\. IPA — DX動向2026 本文（2026年7月）。図表4-1・4-2、本文p.55・56。国内でDXに取り組む企業が対象。](https://www.ipa.go.jp/digital/chousa/dx-trend/rcu1hd0000017uk8-att/dx-trend-2026.pdf)

[7\. Veracode — 2026 GenAI Code Security Report（2026年）。特定の脆弱性を含み得る80のコード補完課題による検証。一般のシステムの事故率ではない。](https://view.ceros.com/veracode/genai-code-security-report2026)

[8\. Databricks — Passing the Security Vibe Check（2025年8月12日）。自社レッドチームの実験と改善策。](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding)

[9\. GMOサイバーセキュリティ byイエラエ — バイブコーディングのセキュリティリスク（2026年9月9日更新）。社内ツールを含む認証・認可や権限の解説。](https://gmo-cybersecurity.com/column/assessment/vibecoding/)

[10\. SaaStr — Replit’s New Release Addressed Most of The Challenges We Hit Vibe Coding（2025年の事故に関する当事者報告）。開発・本番DBの混在、削除と復旧、変更制限の問題。独立した技術監査報告ではない。](https://www.saastr.com/replits-new-release-address-most-of-the-challenges-we-hit-vibe-coding-but-is-prosumer-vibe-coding-really-ready-for-commercial-apps-yet/)

[11\. Wiz — Hacking Moltbook: The AI Social Network Any Human Can Control（2026年2月2日）。研究者による認証なしの閲覧・書き換えの確認と修正の経緯。](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)

[12\. SEC — Knight Capital Administrative Order, Release No. 70694（2013年10月16日）。本文p.5–8、段落12–27。8台中1台の配布漏れ、残存コード、通知と停止・更新手順の問題。和解に伴うSECの認定であり、同社は認定内容を肯定も否定もせず同意した。](https://www.sec.gov/litigation/admin/2013/34-70694.pdf)

[13\. SEC — Charges Knight Capital With Violations of Market Access Rule（2013年10月16日）。2012年8月の誤発注、損失、統制不備に関する公表。](https://www.sec.gov/newsroom/press-releases/2013-222)

[14\. NIST — SP 800-207 Zero Trust Architecture（2020年8月）。ネットワーク上の場所だけを信頼の根拠にしない原則。](https://csrc.nist.gov/pubs/sp/800/207/final)

[15\. Cisco Talos — Recent cyber attack on Cisco（2022年8月10日）。VPN経由の侵入に関する当事者報告。AI内製化が原因の事件ではない。](https://blog.talosintelligence.com/recent-cyber-attack/)

[16\. FBI・CISAほか — Scattered Spider, AA23-320A（2025年7月29日更新）。p.2–3・5–6。大企業と委託先ITヘルプデスクの標的化、企業・担当者情報を使うなりすまし。](https://www.fbi.gov/file-repository/cyber-alerts/scattered-spider-072925.pdf)

[17\. Microsoft — Octo Tempest crosses boundaries to facilitate extortion, encryption, and destruction（2023年10月25日）。組織・対象者を調べるソーシャルエンジニアリングと認証の再設定。](https://www.microsoft.com/en-us/security/blog/2023/10/25/octo-tempest-crosses-boundaries-to-facilitate-extortion-encryption-and-destruction/)

[18\. Verizon — 2025 Data Breach Investigations Report（2025年）。本文p.85以降、企業規模別の分析。収録件数は、母集団での企業当たり被害率や上場・非上場の比較ではない。](https://www.verizon.com/business/resources/T850/reports/2025-dbir-data-breach-investigations-report.pdf)

[19\. Veracode — 2026 State of Software Security（2026年）。長期間未修正の脆弱性とセキュリティ負債に関する分析。](https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/)

[20\. NIST — SP 800-218 Secure Software Development Framework（2022年、Version 1.1）。RV.1・RV.2は継続的な脆弱性の特定・確認と対応を扱う。実装上の解説も参照。](https://csrc.nist.gov/pubs/sp/800/218/final)

[21\. 経済産業省 — レガシーシステムモダン化委員会総括レポートの公表（2025年5月28日）。内製化、人材育成、ガバナンスを含む政策上の提言。](https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html)

※企業の調査・ブログには自社サービスの提供上の利害があります。実験・観測で確認した内容と、経営判断への提案を区別して参照しています。

Sales Retriever サービス資料

## 大手企業開拓の課題・機能・導入事例を資料で確認

大手企業開拓で起きやすい課題、部署・キーパーソン候補、連絡先、企業リサーチの機能、提案ドラフトの出力イメージと導入事例をまとめています。

[資料ダウンロードページへ](https://www.sales-retriever.jp/download_service)

## Structured data

```json
[
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "大手企業のシステム内製化とセキュリティリスク",
    "description": "大手企業のシステム内製化とセキュリティリスクを解説。自社側の開発・改修を確認できるSaaStr、Moltbook、Knight Capitalの3事例を図解し、日米の人材差と継続保守から導入条件を整理します。",
    "image": [
      "https://www.sales-retriever.jp/assets/columns/enterprise-system-insourcing-security-risk/cover.webp"
    ],
    "url": "https://www.sales-retriever.jp/column/enterprise-system-insourcing-security-risk",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://www.sales-retriever.jp/column/enterprise-system-insourcing-security-risk"
    },
    "inLanguage": "ja",
    "articleSection": "AI・セキュリティ",
    "about": [
      "システム内製化",
      "セキュリティリスク",
      "大手企業",
      "社内システム",
      "AI開発",
      "バイブコーディング"
    ],
    "datePublished": "2026-10-20",
    "dateModified": "2026-10-20",
    "keywords": "システム内製化, セキュリティリスク, 大手企業, 社内システム, AI開発, バイブコーディング, 日米IT人材比較, 脆弱性対応, 継続保守, 委託開発",
    "author": {
      "@type": "Organization",
      "name": "Sales Retriever株式会社",
      "url": "https://www.sales-retriever.jp/company"
    },
    "publisher": {
      "@id": "https://www.sales-retriever.jp/#organization"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "コラム",
        "item": "https://www.sales-retriever.jp/column"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "大手企業のシステム内製化とセキュリティリスク"
      }
    ]
  }
]
```