こんにちは、大平です。
最近、クライアントや知り合いの経営者から「これもAIで内製化できますよね？」と聞かれることが増えました。
Cursor、Claude Code、その他さまざまなAIツールのおかげで、たしかにシステムは以前よりも圧倒的に速く作れるようになっています。「自社で作れるものは、なるべく自社で作ればよい」という空気が、特にスタートアップやスモールビジネス周辺で強くなっている。
ただ、経験上はっきり言うと、AI時代でも「自社で作らない方がいい領域」は確実にあります。
今日はその判断基準を整理して書いておきます。
なお、この記事では「自社で作らない」という選択肢を、受託開発に任せることと、SaaSを買うことの両方を含む意味で扱います。
実際の経営判断では、「作る」「買う」「任せる」の3つを分けて考える必要があります。ただ、AI時代に内製化の可否を考えるときは、まず「自社で持つべき領域かどうか」を決めることが出発点になります。
内製化したものの運用できない、という事故は少なくない
まず前提として、「作れる」と「運用できる」は別の話です。
最近よく見るパターンは、次のようなものです。
- AIで短期間に作った
- でも保守人員がいない
- セキュリティパッチが当たらず、ゼロデイ攻撃を食らう
- そもそもセキュリティのことを考慮せずに作ってしまっている
- 結局作り直しになって、外部に任せることになる
システムは、デジタルだから劣化しないと思われがちですが、経験上はかなり「生モノ」に近いです。
「人の住まない家は損耗が速い」という不動産の法則がありますが、人のメンテしないシステムも同様に老朽化が速いです。
なので、内製化を考えるときの第一関門は「作れるか」ではなく「作った後、誰がメンテし続けるのか」です。
ここから話を始めないと、ただ負債を量産することになります。
内製化すべき領域は、結局この3条件
その上で、内製化すべきものの条件を整理するとこうなります。
1. 自分の会社にとってのコアビジネスであること
これが一番大事。
伸びるビジネスには、結局なんらかの「参入障壁」と「独自の差別化要因」が必要です。
その差別化要因は、会社の中の人にしかわからない解像度で作り込まれています。
外注業者にも優秀な人はいるし、業界を横断的に見ている分、知識が広い人もいます。
でも、自社のコアビジネスに対する解像度は、中の人の方が高い。
ここを外注に出すと、たいていこうなります。
- ベンダーの解像度が低くて、思ったものが出てこない
- 書面で確定した仕様以外に対応してくれない
- 発注側が仕様変更を投げすぎて、仕様が固まらない
- 結果として、プロジェクトが不安定になる
「アジャイルにビジネスインサイトに合わせて変化させたい」と思った時点で、内製化以外の選択肢はかなり狭くなります。
2. 保守可能な人員を割り当てられること
先ほどの話とも重なりますが、作って終わりではありません。面倒を見続けられる人を確保できるかを先に決める必要があります。
これがなければ内製化は避けた方がいい。
機能開発をしない期間でも、最低限セキュリティパッチを当てたり、データの不整合があった時に直せる体制は要ります。
ここを軽く見ると、3年後に「動いているが誰も触れない」というシステムができあがります。
3. セキュリティリスクが限定的なこと（コアでなくても内製しやすい領域）
これはコアではなくてもよい話で、たとえば次のようなものです。
- 社内リサーチツール
- 日報管理
- 社内申請、有給申請
このあたりは、万一問題が起きても事業継続への影響が限定的なので、SaaSを買うほどでもないが自前で必要十分なものを作るという選択があります。
AIのおかげで、この領域はかなり広がってきていると思います。
それでも「買う／任せる」を選ぶべき領域
ここからが本題。
「AIで何でも作れるなら内製化すればよい」と考える人ほど、ここを軽く見がちです。
法令対応が厳密に決まっているもの
ERP、税務会計、給与計算。
このあたりは法令でルールが細かく決まっているので、独自性を出す余地が小さい領域です。
決められた通りに正確に処理することが価値で、独自性は出せない。
こういうものは内製化するより、freee、マネーフォワード、SAP などのSaaSプロダクトを使った方が、総コストを抑えやすいです。
厳しいセキュリティが求められるもの
代表例はクレジットカード決済。
これを内製化しようとすると、もはやそれは自社が決済代行会社に近い責任を負うという話になります。
- カード番号を自社で保存しない、サーバーを通さない設計にする
- PCI DSS の審査が必要
- ガバナンス体制もとんでもなく厳しい
Stripe などのペイメントサービスを使った方が、ほとんどの会社にとって合理的です。
「決済機能を内製化」という言葉だけだと簡単そうに聞こえますが、実態としては決済代行会社に近い運用責任を背負うことになります。ここは慎重に判断すべきです。
技術的に難しすぎるもの
メールサーバー管理が典型。
「メールを送るだけ」と見えやすい領域ですが、実際にはかなり奥が深いです。
SPF、DKIM、DMARC、各ISPの到達性ルール、スパム判定の世界。専門性が高く、片手間で扱うには重すぎる領域です。
これも体系化された知識がすでにあって、それを体現したSaaSが SendGrid や Resend など複数あります。非コア領域であれば、買った方がROIは高くなりやすいです。
「最初は外注、伸びたら内製化」戦略の落とし穴
ここまで読んで「ではコアビジネスでも、最初は外注やSaaSで安く立ち上げて、伸びたら内製化すればよい」と思った人もいるかもしれません。
その戦略はありですが注意点もあります。
仮説検証フェーズ・PoCフェーズなら、外注やSaaSで素早く検証するのは合理的です。
市場があるかどうかわからないうちから作り込んでも、開発コストの無駄になりやすい。
ただ、最初のプロダクトでは中長期的な競争優位（Moat）は取れないということは最初から理解しておくべきです。
外注やSaaSの組み合わせで作ったプロダクトは、極論すれば「同じ部品を使えば誰でも作れる」状態です。だから「市場があることが検証された」瞬間に、解像度の高い競合にすぐ追随される可能性があります。
なので、「外部リソースで立ち上げる → 検証できたら早急に内製化へ切り替える → 差別化要因を仕込む」というスケジュール感が重要になります。「いつか巻き取ろう」と思っているうちは、ずっと巻き取れないことが多いです。
結局、判断軸の本丸は「難しい × 非コア」
最後にひとつ、これだけは押さえてほしいです。
外部に任せるべきものの本丸は、「難しいもの」ではなく 「難しくて、かつ自社のコアドメインになり得ないもの」 です。
- 会計プロダクトを作っている会社が、会計領域の中核を外注する → 差別化要因を手放している
- 給与計算SaaSをやっている会社が、給与計算ロジックを外注する → 事業の中核を外部依存にしている
- 決済代行をやりたい会社が、決済処理を外注する → 提供価値の中心が曖昧になる
- メールサーバー管理SaaSを売っている会社が、メール周りの知識を外注に依存する → 競争優位を作りにくい
「難しいからSaaSを買うべき」というのは、それが自社のコアではない場合の話です。コアなら、難しくても内製化しないと、そもそも商売になりません。
そうしないと、「お客さんがあなたの会社を選ぶ理由はどこにあるのか」という話になります。
まとめ
AI時代でも、内製化と外注の境界線はちゃんと引くべきです。
判断の本丸は、「難しい × 非コア」なら買う／任せる、コアなら難しくても内製。これだけです。
- コアビジネスは、難しかろうが内製する：差別化要因は中の人の解像度でしか作れない。ここを外注すると「お客さんがあなたを選ぶ理由」が消える
- 非コア × 難しいは、買う／任せる：枯れた法令対応・厳しいセキュリティ・技術的に難しすぎる領域。自社で抱える意味が薄い
- 「難しいから外注」は半分間違い：難しくても、それがコアなら内製しないと商売にならない
- 内製化の前提は「保守人員」：作れるかより「誰がメンテし続けるか」。ここがなければ内製化はやらない
- PoCは外注／SaaSでOK、ただし巻き取りは早急に：モートは2発目のプロダクトから作る
AIでシステム開発のコストが下がったからといって、全部内製化すればよいわけでも、全部AIに任せればよいわけでもありません。
判断軸さえ持っていれば、AI時代はむしろ「内製化、SaaS、外部パートナーを組み合わせて、コアに集中する」ことがやりやすくなった時代だと思います。手を動かす前に、何を作り、何を買い、何を任せるかの設計を真面目にやりましょう、というお話でした。