AIで内製は中小企業に本当に向くのか――情シスがいない会社の現実と外注の線引き

「最近うちの若手が、Claudeとかいうやつで何か作ってるらしいよ。これからはAIで内製でいいんじゃないの？外注なんかいらないでしょ」

ある経営会議で、社長がぽつりと口にする。総務を兼ねた情シス担当が苦笑いを浮かべ、若手は得意げに資料を見せる。よくある光景です。

確かに、生成AIで「動くもの」を作るコストは、ここ1〜2年でまるで別の景色になりました。プログラミングを職業にしていない人でも、日本語で頼めば、社内ツールの形にはなる。これは事実です。

ただ、弊社が業務システムの引き取り相談を受ける現場で見えてくるのは、もう少し別の景色です。「作る」のハードルが下がった一方で、「作ったあと、誰がそれを運用し続けるか」は、何も変わっていません。情シスがいない、あるいは総務が兼任している中小企業ほど、この線を引き間違えると、属人化の新しい形を呼び込みます。

ここでは、AI内製化のブームを一旦落ち着いて眺め、何を自社で持ち、何を外に任せるかの線引きを、経営判断の側から整理します。

なぜいま「中小企業もAIで内製」と言われるのか――2026年時点のブームの正体

「AIで内製しよう」という論調が強まっている背景には、生成AIコーディングが急速に一般化したことと、行政が中小企業のDX・内製化を後押ししていることの2つが重なっています。順に見ていきます。

生成AIコーディングが「動くものを作る」コストを下げた

ここ1〜2年で、Cursor、GitHub Copilot、Claude Codeといった生成AIによるコーディング支援ツールが、エンジニアの現場に一気に浸透しました。さらに、自然言語の指示だけで動くプロトタイプを組み立てる「Vibe Coding」と呼ばれる作り方も話題になっています。

これらに共通するのは、「動くもの」をとにかく早く形にできることです。社内向けの簡単な入力フォームや、Excelの転記を自動化するツール程度であれば、専門のエンジニアでなくても、何らかの形にはたどり着けるようになりました。

中小企業の現場でも、「うちの若手が、社内向けに何か作ってきた」という話を、以前より明らかに多く聞くようになっています。具体的な活用イメージは、中小企業のAI活用事例の記事でも整理しているので、合わせて参考にしてみてください。

「内製化推奨」の論調がここ1〜2年で強まった背景

行政側の動きもあります。経済産業省は2025年3月に「中堅・中小企業等向けDX推進の手引き2025」を公表し、中堅・中小企業のDXの進め方や成功のポイントを整理しています。IPAも2025年6月に「DX動向2025」を出し、日米独の比較から、日本企業の課題として人材不足や、外向き・全体最適への転換の遅れを指摘しています。

こうした流れの中で、「外注に丸投げするのではなく、自社の中にデジタル人材を育てて内製化していこう」というメッセージが、メディアや支援機関を経由して中小企業の経営者にも届くようになりました。生成AIの追い風が重なり、「うちもそろそろ内製でやれるのではないか」という機運が生まれているわけです。

出典: 経済産業省「中堅・中小企業等向けDX推進の手引き2025」（2025年3月）／ IPA「DX動向2025」（2025年6月26日公開）

一方で、中小企業の現場感はその論調と少しずれている

ただ、現場で経営者の方々とお話ししていると、「内製化を進めよう」という大きな話と、目の前の現実の間には、それなりの距離があると感じます。

情シス専任がいない、いてもひとり情シスで手一杯、若手が片手間で触っている――そんな体制で「内製化」と言われても、すぐにイメージが湧かない、というのが正直なところではないでしょうか。

問題は、「AIで作れるかどうか」ではなく、「作ったあとを誰が支えるか」です。次のセクションで、もう一段踏み込んで見ていきます。

情シスがいない会社で「AIで作る」は本当に成立するのか

AIで「動くもの」を作ること自体は、情シスがいなくても成立します。ただし、それを業務で使い続ける状態に持っていけるかは、別の話です。ここで言う「成立」を、作る側と運用する側の両面から分解します。

大企業の内製化と中小企業の内製化は別ゲーム

メディアで語られる「内製化の成功事例」の多くは、情シス部門が独立してあり、エンジニアを一定数抱えた中堅・大企業の話です。専任のエンジニアが、AIを道具として使いこなして開発スピードを上げる、というイメージです。

一方、従業員30〜100名規模の中小企業では、そもそも情シスが独立した部署として存在しないことが珍しくありません。総務部長がIT全般を見ている、経理担当が片手間で社内システムの面倒を見ている、社長が一番ITに詳しい、といった体制が普通です。

この前提が違うと、同じ「内製化」という言葉でも、起きていることはまるで違ってきます。大企業の文脈をそのまま輸入すると、「うちでもできるはず」という期待と、現場の実態との間に大きなギャップが生まれます。

「AIで作れる」が成り立つための隠れた前提条件

AIに頼めば社内ツールが作れる、という話には、実は3つの隠れた前提があります。

要件を言語化できる人が社内にいる：何を作りたいかをAIに伝えられないと、AIは正しい答えを返せません。業務の流れを整理し、必要な機能を言葉にできる人が必要です。
出てきたものの品質を判定できる人が社内にいる：AIが出力したコードや画面が、業務で使えるレベルなのかを判断できないと、危ういものが本番に出ます。
本番に出す責任を取れる人が社内にいる：トラブルが起きたとき、誰が止め、誰が直し、誰が顧客や取引先に説明するか。この責任の所在が曖昧なまま走ると、必ずどこかで詰まります。

このうち1番目は、業務側の話なので、現場のリーダー層がいれば何とかなります。むしろシステム化の前段として、業務そのものを整理する作業が大事です。詳しくはシステム導入前の業務標準化の進め方で扱っています。

問題は2番目と3番目です。これは技術側の役割で、情シスがいない・兼任の体制では空白になりがちです。AIが作ったものを、誰が「OK」と判定するか。動かなくなったときに、誰が責任を持って直すか。この空白を埋めずに「AIで内製」と進めると、次のセクションのつまずきに直結します。

兼任体制で実際に何が起きるか

弊社が見ている範囲でも、AIで作った社内ツールに関する相談は、ここ最近、少しずつ増えてきました。多いのは次のような状況です。

若手社員が業務改善のつもりで作った社内ツールが、いつの間にか部署全体で使われている
作った本人が異動・退職し、コードを読める人が誰もいない
何かおかしいと気づいたときには、すでに半年間、間違った数字で集計されていた

どれも、悪気があって起きるわけではありません。むしろ前向きな取り組みの副作用として起きます。だからこそ、止めにくいし、気づきにくい。これは、過去にも何度も繰り返されてきた社内SEが1人で抱え込んだ業務システムの構造と、本質的には同じ問題です。

「動くものができた」あとに何が起きるか――AI内製化のつまずき5パターン

ここからが本記事の中核です。AIで作った社内ツールが、業務に組み込まれたあとで何が起きるか。弊社が引き取り案件の現場で見てきた典型的なつまずきを、5つのパターンに整理します。

それぞれを表にまとめます。自社の社内ツールに当てはまるものがないか、確認するための地図として使ってください。

#	つまずきパターン	よくある兆候	実際に起きる被害
1	テストがない／壊れていることに気づかない	「動いてるからOK」で本番投入。テストコードがない	数か月後に集計値が間違っていることに気づく。過去データのやり直し
2	作った本人しか中身を説明できない	仕様書なし。コメントもなし。本人も「AIが書いた」としか言えない	新しい属人化。本人の異動・退職で誰も触れなくなる
3	データの整合性・権限管理が甘い	全員が同じ権限。個人情報がそのまま外部AIに流れる経路がある	情報漏えい、データ破損、コンプライアンス違反
4	ライブラリ／OSアップデートで動かなくなったとき直せない	動いている間は触らない方針。バージョン管理の意識がない	ある日突然動かなくなり、原因も対応者も分からない
5	作った当人が辞めた瞬間に止まる	知っているのは作った本人だけ。引き継ぎ資料なし	業務システムが事実上の停止。緊急で外注先を探す羽目に

以下、それぞれが「なぜ起きるか」を補足します。

パターン1・2: 品質と属人化はなぜ起きるか

パターン1の根っこは、開発工程の中で「品質を判定する役割」が抜け落ちることにあります。従来の開発であれば、設計レビューやテスト工程が役割として存在し、誰かが「業務の正解」と「コードの挙動」を突き合わせていました。AIに頼んだ瞬間、その役割を持つ人が社内にいないまま本番に出てしまう。判定する人がいない構造で動き始めるので、間違いに気づくのは決算や監査のタイミングまで遅れます。

パターン2の属人化は、構造そのものが従来型と違います。これまでの属人化は「あの人がコードを書いたから、あの人しか分からない」という、書いた人の知識に紐づくものでした。AI内製では、書いた本人もAIへの指示を出したに過ぎず、出力されたコードの細部までは把握していない、ということが起きます。引き継ぎ手順を整える前に、そもそも本人すら詳細を語れない、という構造です。社内SE退職時の引き継ぎチェックリストで扱った従来型の手順だけでは、この種の属人化は引き継げません。

パターン3: データ・セキュリティはなぜ甘くなるか

AI生成のコードでデータ・セキュリティが甘くなりやすいのは、「動くこと」を最短で達成しようとすると、認証・権限管理・ログのような業務側から見えにくい部分が後回しになる構造があるからです。指示する側も、「画面が出る」「ボタンが動く」を優先しがちで、見えない裏側まで指示しないと、AIはそこを積極的には作りません。さらに、業務データを外部AIサービスへ渡す経路が、開発者本人にも見えにくい形で混ざりこむこともあります。社内向けだから安全、という発想では足りない理由はここにあります。

IPAが毎年公開している「情報セキュリティ10大脅威」でも、組織を狙った脅威は年々増えています。

出典: IPA「情報セキュリティ10大脅威 2025」

パターン4・5: 運用継続はなぜ詰まるか

パターン4が詰まる構造は、ソフトウェアが「何もしなくても古びる」性質を持つことに由来します。依存しているライブラリのバージョンが上がる、OSのサポートが切れる、連携先のAPI仕様が変わる――時間が経つだけで前提条件が崩れていきます。普段から手を入れていないシステムほど、いざ変化が来たときに、何が原因で何を直せばいいかを追える人が社内に残っていません。

パターン5は、人の出入りが構造に直結します。作った本人だけが指示の意図と動作の癖を理解している場合、その人が抜けた瞬間に維持に必要な情報がまるごと失われます。AIに頼んで作り直せばいいという発想もありますが、業務で蓄積されたデータと、現状の運用フローを引き継いだうえで作り直すのは、ゼロから作るよりむしろ難しくなる場面が多いのが現実です。

自社で持つべき範囲と、外注に切り出すべき範囲をどう決めるか

「全部内製」か「全部外注」かの二択は、中小企業の現実には合いません。AIで作れるところは作り、責任を持てない範囲は外に出す、という線引きの設計こそが、経営者が考えるべきポイントです。

「全部内製」か「全部外注」かの二択は中小企業には合わない

大企業の議論を真に受けて全部内製に振ると、情シスの空白に踏み込みます。逆に、全部外注に戻すと、AIの追い風を活かせず、使っていない月の固定費が積み上がり、投資対効果（ROI）の判定も難しくなります。中小企業にとっての現実解は、「どの業務領域なら自社で持てるか」を見極めて、残りは外に出す、という設計です。

これは、弊社の提案哲学とも重なります。フルスクラッチで全部作るのが必ず正解ではないし、SaaSで足りるならSaaSを勧めます。AIで内製できるならそうすればいい。大事なのは、その判断を「ブーム」ではなく自社の業務構造から決めることです。

自社で持つべき範囲を決める3つの判断軸

判断軸として、次の3つで切り分けるのが現実的です。

判断軸	自社で持つ（AI内製含む）が向く	外注／既製SaaSが向く
業務理解の深さ	自社の業務知識が前提で、他社では作れない部分	一般的な業務（会計、勤怠、給与など）
障害時の許容ダウンタイム	半日止まっても業務が続く社内ツール	止まると受注・出荷・請求が止まる基幹業務
データの機密性	一般的な社内データ、機密性が低いもの	個人情報、取引情報、未公開の経営数値

3つすべてが「自社で持つ」側に倒れる業務は、AI内製の有力候補です。逆に、3つのうち2つ以上が「外注／SaaS」側にあるなら、無理に内製しないほうが安全です。

外注は「丸投げ」ではなく「境界線の引き方」で決まる

ここで強調したいのは、外注＝丸投げではない、ということです。境界線を引いて、そのうえで外に出すのが本来の外注です。

弊社が引き取った塗装業（30名規模）の例で言えば、もともと業務システムは外部に依存しすぎていて、担当者が退職した瞬間に誰も触れなくなりました。引き取りにあたっては、「何を弊社が責任を持って維持するか」と「何を社内で運用判断するか」の線を最初に引き直しました。料金も月額固定の保守ではなく、稼働した月だけ請求する実働ベースに切り替えています。この線引きと料金モデルの切り替えによって、属人化は解消されました。

これはAI内製の話と地続きです。AIで作ったツールがあるなら、その「動くもの」を活かしつつ、保守と運用の線引きをどう設計するか。そこが経営判断のしどころです。

AIで作ったものが「数年後の引き取り案件」にならないために

AIで内製した社内ツールが、数年後に「動いてはいるが誰も触れない」状態になることを防ぐには、作った時点で最低限の備えを残しておくことが必要です。完璧なドキュメントはいりません。引き取れる状態にしておく、というだけで十分です。

弊社で増えている「AIで作ったものが動かなくなった」相談

弊社の本業の1つはシステムレスキュー、つまり「動いてはいるが、もう誰も中身を触れない」レガシーシステムの引き取りです。ここ最近、その相談の中に、AIで作った社内ツールが含まれるケースが少しずつ出てきました。

20年前の言語で書かれたシステムと、半年前にAIで作られた社内ツール。原因はまったく違うのに、現場で起きていることは驚くほど似ています。仕様書がない、作った人がいない、動いているがブラックボックス。

この「動いているが誰も触れない」という構造そのものは、技術が変わっても再生産されます。詳しくはレガシーシステム保守を後回しにできない理由でも整理しています。

最低限残すべき4点

AIで作る場合でも、次の4点を意識して残しておくと、将来の引き取り可能性が大きく変わります。

プロンプトや指示書を業務ドキュメントとして残す：「何を作りたかったか」が、AIに渡した指示の中に残っています。それを業務マニュアルの一部として保管しておきます。
生成されたコードの読みやすさを評価軸に入れる：AIに「読みやすく書いて」と頼むだけで、後で読める確率は上がります。動けばよし、で終わらせない。
最小限の自動テストを併設する：完璧なテストでなくていい。「主要な業務フローが壊れたらすぐ気づける」レベルのテストでも、パターン1のつまずきは防げます。
引き継ぎ時にAIと人の両方が読める形にしておく：READMEに「このツールは何で、誰が、何のために作ったか」を書く。次の担当者がAIに読ませれば、ある程度の解読は進みます。

仕様書が完全に失われた状態でも、ソースコードと動いているシステムがあれば、現状から読み解いて段階的に直す道は残ります。実際の進め方は仕様書のない業務システムを現状から直す手順で詳しく整理しています。

動いているものは無理に作り直さないという選択肢

最後にもう1つ。AIで作ったものが「危ない状態」になっていることに気づいたとき、必ずしも全面的に作り直す必要はありません。

動いているコア部分は活かしつつ、危ない箇所だけを修正する。テストとドキュメントを後から足す。保守の責任範囲を外部と分担する。こうした段階的な対応が、中小企業の実態には合っています。弊社のシステムレスキューは、まさに「全部刷新せず、必要な部分だけ延命する」立ち位置です。月額固定ではなく実働ベースなので、使わない月は費用が発生しません。料金モデルの考え方は使った分だけ払う業務システム保守の現実解で詳しく整理しています。

システムレスキュー｜誰も触れなくなった業務システムを引き取る

AIで作った社内ツールも含めて、保守困難になったシステムを引き取ります。月額固定ではなく実働ベース、初回は直らなければ全額返金の成果保証。

/service/system-rescue/

Webシステム開発｜境界線を引いた部分外注のご相談

全部内製でも全部外注でもなく、自社で持つ範囲と外に出す範囲を整理したうえで、必要な部分だけ受託開発で支えます。

/service/development/

まとめ

AIで内製するか、外注するか。この二択で考えてしまうと、中小企業の現実には合いません。

生成AIで「動くもの」を作るハードルは確かに下がりました。一方で、作ったあと誰がそれを支え続けるかは、何も変わっていません。情シスがいない・兼任の体制で内製を進めるなら、品質を判定する責任、運用を続ける責任、引き継ぐ責任の3つを、社内のどこに置くかを先に決めておく必要があります。

その線引きさえできれば、AIで作るところは大胆に作り、責任が重い部分は外に出すという、無理のない設計が見えてきます。AIブームに踏み出す前に、自社の業務構造から線を引き直す。中小企業のAI内製化は、その順番で進めるのが現実的です。

よくある質問

Q. 中小企業がAIで内製を始めるなら、最初の一歩は何が現実的ですか？

A. 業務システムの新規開発から入るのではなく、既存業務の中で「壊れても業務が止まらない」軽い社内ツールから始めるのが安全です。会議の議事録整形、データの転記、簡単な集計フォームなど、半日止まっても困らない範囲で経験を積むのが現実的です。

Q. 情シスがいない会社でも、AI内製は可能ですか？

A. 「作る」ことは可能ですが、「業務で使い続ける」状態に持っていくには、品質判定と運用責任の置きどころを先に決める必要があります。これが空白のまま進めると、属人化と保守不能の両方を抱え込むことになりやすいです。重要な業務に関わる部分は、最初から外部の開発会社と分担を設計するほうが安全です。

Q. AIで作った社内ツールが動かなくなったときの相談先は？

A. 仕様書がない・作った本人がいない状態でも、ソースコードと動いているシステムが残っていれば、現状から読み解いて引き取れる場合があります。弊社のシステムレスキューでも、そうした「AIで作ったが誰も触れない」状態のツールについて、ご相談を受ける機会が増えています。全面的に作り直す前に、まず状態を見立てるところから相談されるのが現実的です。