AI時代に社内システムの内製はアリかナシか｜生成AIで業務システムを作る前に決めた、レガシー改修と新規開発の4つの基準
「内製」とは、ここでは「業務システムを自社の人間が作ること」の意味で使います。AIを自社で持つ「AI内製化」の話ではありません。
社内システムを内製する立場として
私は5つのグループ会社の社内SEを担当しています。業務システムはPHPとGoogle Apps Scriptで自分で作ることが多く、ここ1年はコーディング支援にAIも使っています。「前任者がおらずそのまま放置されているAccess」「仕様が変わるたびにコードが注ぎ足しされて複雑になったVBAやPHP」のように、リファクタリングに着手する前のコード解析でAIは大変重宝します。
AI時代に内製はアリかナシか。内製する側の私の答えは「部分的にアリ」です。どこまでがアリかを決めるために、私は4つの基準を置きました。この記事では、その基準を置くことになった出来事と、4つの基準をレガシー改修と新規開発に当てはめた結果を書きます。
外注なら必要な見積と納品待ちが、AIで内製する場合は要らなくなる
外注で業務システムを作ると、要件を伝えて、見積が出て、発注して、納品を待ちます。小さな修正でも同じ手順を踏みます。「ボタンを1つ足したい」で見積2週間、というやり取りを経験した人は多いと思います。
AIで内製すると、この手順がなくなります。要件を自分で書いて、コードをAIに書かせて、動かして、直す。修正依頼も同じで、自分で直せるものは当日に終わります。当然AIに頼まなくてよいケースがあるかもしれません。しかし大きな開発となると、人の手で1週間、1ヶ月かかっていたものがAIでは1日で出来てしまうことは経験上よくあります。
しかしその代償として何が起きるか。それが「部分的に」の理由です。
AIで内製したシステムは、作った直後からブラックボックスになる
以前、公開Webサイトの会員向けマイページの改修を頼まれたことがあります。残っていたのはソースコードと最低限の引き継ぎメモだけで、仕様書はありませんでした。中身はPHPの直書きとグローバル変数だらけで、画面表示・DB・ログイン処理が一体化していて、どこを直すとどこに影響するかが分かりませんでした。
最初にやったのは、コード全体を読んで処理の流れを手書きのフロー図にすることです。次に、自分が読み返して分かるレベルのクラス図・シーケンス図を描いて、何を直すべきか、どこを分離すべきかを見えるようにしました。直したあとは、仕様と改修履歴をMarkdownで社内wikiに残しました。
（外部サイトへ遷移します）
このマイページは、人が書いて、人がいなくなってブラックボックスになったものです。AIで内製すると、同じ状態が「作った直後」に始まります。依頼した本人がコードを読んでいないからです。
「作った人がもういない」VBAマクロが業務を止める話をブログに書きましたが、AIで作ったシステムは、作った時点で「作った人がいない」のと同じです。
（外部サイトへ遷移します）
基準1：AIが書いたコードを、自分で読んで何をしているか説明できる
説明できないコードは本番に置きません。先述したマイページのように、あとで自分が読むことになります。
基準2：動作を自分のテストで確かめてから使う
AIが「動きます」と言っても、動くかどうかは自分で確かめます。確かめる手段がない範囲は、AIに任せません。
脆弱性の修正版が届く前に、攻撃コードが揃う
ここまでは「AIを使う側」の話でした。ここからは「AIに攻撃される側」の話です。内製か外注かを決めるとき、この条件は2026年10月に変わりました。
Linuxカーネルの脆弱性CVE-2026-98432の時系列です。
10月5日：カーネル側で修正
10月15日：CVE公開
10月27日：Anthropicが、自社のAIモデルがこの脆弱性で遠隔root奪取の攻撃コードを書いたと公表（実証環境で、カーネルのメモリ配置の特定まで48分、コマンド実行まで追加5分）
10月30日時点：UbuntuとRed Hat Enterprise Linuxには修正版カーネルが未配信
公開から12日で、AIが書いた攻撃コードの実証が出ました。その時点で、主要なディストリビューションにはまだ修正が届いていません。攻撃コードそのものは公開されておらず、実際の攻撃も報告されていませんが、「修正が届く前に攻撃手段が揃う」という順番が現実に起きました。
私がやったことは、自社のUbuntuサーバーで、動いているカーネルの版、MPTCPの有無、外部に開いているポートの3点を確認して記録することでした。修正版が来るまでは、それ以上できることがありません。
（外部サイトへ遷移します）
内製したシステムは、この確認と適用を全部自分でやります。脆弱性情報を追い、該当するか確認し、修正版が出たら当てて、再起動する。この速さに人力で追いつけるかが、内製の条件になりました。
基準3：次に直す人が決まっている
自分でも構いません。決まっていないのがNGです。「AIに頼めば直る」は、次に直す人が決まっていることにはなりません。修正は待ってくれないからです。
SaaSに移しても、認証の管理は自分に残る
「それなら内製をやめてSaaSにすれば安全か」と聞かれます。答えは「修正については確実にマシ、認証については変わらない」です。
修正はベンダーが当てます。自分で脆弱性情報を追わなくていい。ここは確実にマシです。
一方で、2025年から2026年にかけて拡大したランサムウェアQilinの対応案件を横断したDFIR分析では、初期侵入の入口になったファイアウォールやVPN機器の多くが、攻撃時点でパッチ適用済みでした。それでも侵入されています。主因として挙げられていたのは、多要素認証（MFA）が設定されていない、アカウントロックアウトが機能していない、パスワードの使い回し、という認証面の不備です。
（外部サイトへ遷移します）
SaaSに移しても、ログインは自分の会社のアカウントで行います。MFAを設定するのも、パスワードの使い回しを止めるのも、自分の責任のままです。「マシ」になるのは、修正をベンダーに任せた分の時間を、認証の強化に回せたときだけです。基準3の「次に直す人」は、SaaSに移しても消えません。
本番データをAIのプロンプトに載せない
AIにコードを書かせるとき、「このデータを処理して」と、本番のデータをそのまま貼る人がいます。顧客名簿、認証情報、社内の設定ファイル。悪意はなく、手元にあるデータを貼ったほうが早いからです。
私が決めているのは、本番データをプロンプトに載せないことです。開発はダミーデータで行い、本番データは自分の手元でしか動かしません。これはAIの性能の話ではなく、人の手順の話です。
基準4：本番データを渡さずに作れる
ダミーデータで開発できる範囲だけAIに任せます。本番データを貼らないと作れないものは、AIには出しません。どうしても本番データが入っているファイルなどを見せないといけない場合は、機密情報の箇所だけマスキングするなどおこなっています。
4つの基準を、レガシー改修と新規開発に当てはめる
レガシーの改修も新規開発も、同じ4つで判断しています。
AIが書いたコードを、自分で読んで何をしているか説明できる
動作を自分のテストで確かめてから使う
次に直す人が決まっている
本番データを渡さずに作れる
この4つを当てはめると、レガシーの改修は「部分的にOK」になります。先述したマイページのように、まず自分で構造を把握してからであれば、個別の処理の書き換えをAIに任せても、基準1と2を満たせます。構造を把握しないまま「全部AIに直させる」は、基準1で止まります。
新規開発も同じです。使う人（自分を含む）が理解できて、手を加えられる範囲まではOK。それを超えたら、内製ではなく外注かSaaSを選びます。
まとめ
AI時代に内製はアリかナシか。私の答えは「作ったものを人が引き取れる範囲ならアリ」です。
AIの性能が上がっても、この線は動きません。コードを読めない人が増えるほど、引き取れる範囲は狭くなります。AIが攻撃コードを書く側に回った今、修正を引き取れないシステムを内製するのは、ナシです。
4つの基準のうち、1つでも満たせない部分があれば、そこはAIに任せない。それが、内製する側の人間として決めていることです。
お知らせ
技術的な内容や具体的な手順は、筆者のブログ「たまの社内SE実践ブログ」に書いています。Windowsの更新で起きた不具合、ネットワークやプリンターのトラブル、セキュリティ、Microsoft 365、AI活用など、会社のIT担当が現場で実際に対処した記録をまとめているブログです。
noteメンバーシップではご相談を受け付けております！
ITのことよくわからない！誰に相談したらわからない…ITにまつわる相談ごとお気軽にご相談下さい😊
