「AIで誰でも作れる時代に、わざわざお金を払って外注する意味があるのか」——先日、ある会議でそう問われた、と相談に来られた IT 担当の方がいました。社長から「うちの若手が AppSheet と AI で在庫アプリを試しに作ったら一日で動いた。受託に何百万も払う案件、本当に必要なのか」と詰められ、返答に窮したのだそうです。一方で別の会社からは、まったく逆向きの相談も来ます。「数年前に社内のエンジニアが一人で作った受発注ツールが、その人の退職後、誰も中身を触れなくなった。直したいのに直せない」。AI で作る初速が上がったこの時代に、内製と外注、そして SaaS をどう使い分けるか。受託をなりわいにしている私たちが、ポジショントークを抜きにして整理します。
結論を先に言えば、いまの正解は「全部内製」でも「全部外注」でもありません。業務の性質ごとに、内製で十分なところ、外注したほうがいいところ、そもそも作らずに SaaS を買えばいいところを切り分ける——これが 2026 年の現実的な進め方です。問題は、その切り分けの軸を持たないまま「AI で作れるから」と勢いで内製に突っ込んでしまうことにあります。
AI で下がったのは「初速」だけ、という事実
まず、AI とノーコードで何が本当に変わったのかを正確に押さえます。変わったのは、ゼロから動くものができるまでの初速です。コーディングエージェントに要件を伝えれば画面が立ち上がり、AppSheet ならスプレッドシートを土台に半日で業務アプリの形になる。エンジニアを雇わずに最初の一歩を踏み出せる、というのは紛れもない進歩です。Gartner は、2027 年までにエージェント型コーディングを使うエンジニアチームの 65% 超が「IDE（統合開発環境）を必須としなくなる」と予測していて、作り方そのものが変わりつつあるのは間違いありません。
ただし、同じ Gartner が並べてもう一つの予測を出しています。2028 年までに、市民開発者（現場の非エンジニアが自分で作る形）による「プロンプトからアプリ」方式は、ソフトウェアの不具合を 2500% 増やし、品質と信頼性の危機を引き起こす、というものです。数字の大きさはともかく、ここで言われている構図は現場で何度も見てきたものと一致します。「動くものを作る」のハードルは劇的に下がったが、「現場で壊れず回り続ける／後から誰でも直せる」のハードルはほとんど下がっていない、ということです。
動くデモと、本番で回る業務システムの間には、データ設計・権限・セキュリティ・引き継ぎという、見た目に表れない壁があります。AI はこの壁を越える作業も手伝ってはくれますが、何を作るべきか・どこに穴があるかを判断するのは結局つくる側の人間です。AI で初速が上がったぶん、設計の甘いものが速く大量にできてしまう、という新しいリスクすら生まれている。だからこそ、内製に向く領域と向かない領域の見極めが、以前より重要になっています。
内製・外注・SaaS を分ける六つの軸
では、どの業務をどの手段で進めるか。判断の軸を整理します。一つの軸だけで決めず、複数を重ねて見るのが要点です。
一番大きな軸は、その業務が自社の競争力の源泉（コア業務）か、誰がやっても同じ周辺業務かです。同業他社と差がつく独自の業務フロー、自社ならではの値づけや工程管理——ここは外部の出来合いに合わせると強みが消えるので、内製か、自社に深く寄り添う受託で「自社専用に作る」価値が高い。逆に、会計・勤怠・経費精算・名刺管理のような、どの会社でもやり方が大きく変わらない周辺業務は、作る理由がほとんどありません。SaaS を買って終わりが、たいてい一番安く一番速い。
二つ目は、要件が固まっているかです。「何を作ればいいか」が自社でも言語化できていない段階のものを、いきなり外注の固定見積もりに乗せると、仕様変更のたびに追加費用でもめます。逆に要件がふわっとしている探索段階こそ、AI とノーコードで自分たちで試作し、現場で当てながら固めていくのが向く。要件が固まってから、必要なら外注で本番品質に作り直す、という順番もあります。
三つ目が、作った後を社内で保守できる人がいるか。これが内製の成否を最も大きく分けます。冒頭の「退職で誰も触れなくなった」案件がまさにこれで、作れる人が一人いることと、組織として保守し続けられることは別です。社内に育てられる体制がないなら、内製で作っても遅かれ早かれ属人化して止まります。
四つ目は、データの機密度と規制。個人情報・与信情報・医療や金融に関わるデータを扱うなら、ノーコードや AI で安易に作るとアクセス権の設計漏れがそのまま情報漏えいになります。ここは設計とセキュリティの専門知見が要る領域で、安さより堅さを優先すべきです。五つ目の変更頻度も効きます。業務ルールが毎月のように変わるものは、変えるたびに外注へ依頼すると費用も時間もかさむので、内製で自走できる形が向く。逆にほぼ変わらない定型業務は、SaaS の標準機能に業務を寄せたほうが楽です。
最後の軸が、初期費用だけでなく総保有コスト（TCO）で見ているか。内製は初期が安く見えても、保守・教育・属人化の解消まで含めると割高になることがある。SaaS は月額が安く見えても、日本の現場要件を満たすために有料アプリを足し続けると隠れコストが膨らむ。「いま払う額」ではなく「五年払い続ける額と手間」で比べるのが鉄則です。
| 軸 | 内製（自社・ノーコード・AI）が向く | 外注（受託開発）が向く | SaaSを買うのが向く |
|---|---|---|---|
| 業務の性質 | 競争力に直結するコア業務 | コア業務だが自社だけでは作りきれない | 会計・勤怠など差がつかない周辺業務 |
| 要件の固まり度 | ふわっとしていて試しながら固めたい | 固まっていて本番品質が要る | 一般的な業務で型が決まっている |
| 保守できる人 | 社内に育てる体制がある | 自社だけでは保守が不安 | 提供元が保守してくれる |
| データ機密・規制 | 機密度が低い社内データ | 高機密・規制ありで堅さが要る | 提供元が認証・対策を持つ |
「ここは内製で十分です」と外注をお断りした話
受託会社として、内製したほうがいい案件を内製のまま手放した例を一つ挙げます。ある従業員 30 名ほどの建材卸（社名は伏せます）から、「営業が外回り先で在庫を確認できる仕組みを作りたい。御社に開発をお願いしたい」とご相談をいただきました。話を伺うと、扱う商品はスプレッドシートで管理できる規模で、やりたいのは「外出先のスマホから在庫数を見て、引き当てを記録する」というシンプルな台帳業務。社内には、表計算が得意で改善提案を自分で回している若手の方が一人いらっしゃいました。
私たちがお出しした見立ては、「これは外注しないほうがいい案件です」でした。コア業務ではなく台帳系で、要件もほぼ固まっていて、何より社内に自分で育てられる人がいる。ここに受託の固定費を払うのは、TCO で見ても合いません。私たちがしたのは、開発の受注ではなく、その若手の方に AppSheet でのデータ設計の考え方——マスタとトランザクションを分け、ID で結ぶという最低限の構造——を半日で伝えることだけでした。設計の土台だけ渡せば、あとはご自分で作って育てられる方だったからです。ノーコードでの内製の進め方そのものは AppSheet で業務アプリ化する記事 で詳しく書いた領域で、まさにこのケースに当てはまりました。
逆に、同じ会社から数年後に「受発注のシステムが他社の基幹と連携する必要が出てきて、自社だけでは設計しきれない」というご相談が来たときは、迷わず受託でお引き受けしました。機密度が上がり、要件も連携先の都合で固く、内製の手に余る領域に入っていたからです。同じ会社でも、業務によって内製と外注の答えは変わる。これが現実です。
内製したものが壊れたとき、外注に求めるべきこと
もう一つ、よくある逆の局面にも触れておきます。AI やノーコードで内製したものが、属人化や設計の甘さで立ち行かなくなったときです。作った人が辞めて誰も触れない、データ構造が崩れて集計が合わない、権限設計が甘くて誰でも全データを見られる——こうなってから外注を頼る会社は少なくありません。
このとき外注に求めるべきは、「ゼロから作り直して納品して終わり」ではありません。なぜ壊れたのかを解きほぐし、データ構造を整え直し、そして今度は社内で保守できる形にして引き渡すことです。受託の良い形は、作って手を引くことではなく、内製化まで伴走することにあると私たちは考えています。古いツールやレガシーを抱え込んでしまったときの立て直しの考え方は AI を活用したレガシー移行の記事 で整理していますが、AI で速く作れる時代だからこそ、「速く作って速く壊れる」を繰り返さない設計と引き継ぎの価値が、むしろ上がっています。AI とノーコードで内製化が現実になった時代の前提については AI エージェント時代のノーコード／ローコード論 でも触れているので、合わせて読むと判断の解像度が上がるはずです。
自社のどれが内製で、どれが外注か
整理すると、判断は「AI で作れるかどうか」ではなく、「自社のこの業務はどの軸に当てはまるか」で決まります。コア業務で社内に育てる人がいるなら内製、機密度が高く要件が固いなら外注、差がつかない周辺業務なら SaaS。多くの会社では、この三つが混在しているのが普通で、全部を一つの手段に寄せようとするから無理が出ます。
次の一歩としては、自社で抱えている「作りたい／作ってしまった」仕組みを、コア業務か・社内に保守する人がいるか・データの機密度はどうか、の三つだけでも棚卸ししてみてください。それだけで「これは内製でいい」「これは外注すべき」の輪郭がかなり見えてきます。
自社のこの業務は内製で進めるべきか外注すべきか判断がつかない、AI で作ってみたものの現場に出せる形にならない、属人化して止まったツールを保守できる形に立て直したい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。まずは業務の棚卸しから一緒に行い、どこは内製で十分か、どこは外注したほうが結局安く済むか、どこは SaaS で足りるかを、受注ありきにせず率直にお見立てします。
Sources
- システム開発の内製化 vs 外注はどう決める？判断基準フレームワークと3つの開発モデル比較【2026年版】 － シースリーインデックス株式会社
- Build vs Buy vs Partner｜IT投資の意思決定フレームワーク【2026年版】 － 株式会社renue
- Gartner Identifies the Top Strategic Trends in Software Engineering for 2025 and Beyond － Gartner
- 中小企業のシステム保守｜内製vs外注の判断基準とコスト比較 － 株式会社FUNBREW
- AI内製ツールを作った中小零細の企業が踏む落とし穴をまとめてみた － note
