AIビジネス読了 6 分

『AIでSaaSが終わる』論の中、非エンジニアが内製したシステムが抱えた壁の正体

Shiritomo編集部 @shiritomoAI_jp 2026年8月15日更新

「採用管理システムを、エンジニアなしで作りました」。
そんな報告が、AIコーディングツール（指示文を書くだけでプログラムを組んでもらえるAIサービス）を使う経営者や現場担当者の間で増えています。

Claude Codeのようなツールに要望を伝えるだけで、業務にぴったり合った社内システムを数日で組み上げられる——。
プログラミング経験がなくても「作る側」に回れる時代が、静かに現実になりつつあるようです。
ただし、動くものを作れることと、それを安全に運用し続けられることは、どうやら別の話のようです。
この記事では、AIによる社内システムの内製が広がる実態と、そこで指摘されているリスクを調べました。

先に結論をまとめると：
– 非エンジニアでもAIツールで業務システムを内製できる時代になった一方、バグやUIの粗さ、セキュリティ対策の甘さが運用段階で表面化しやすいと指摘されています
– 基幹システムの丸ごと内製には警戒感を示す経営者もおり、情報漏洩などのリスクが議論されています
– 決済など根幹部分は実績あるSaaS（月額課金で使うクラウド型の業務ソフト）に任せ、周辺業務だけAIで内製する「ハイブリッド」型が現実的な落としどころとして語られています

内製システムの「バグとセキュリティ」がXで話題に

きっかけは、BtoB営業支援を手がける株式会社Emoooveの藤澤諒一CEOが発信したとされる体験談です。
Xで伝えられている内容によると、藤澤氏は採用管理システムを非エンジニアの手でAI内製したものの、運用に入るとバグが頻発し、画面のUI（見た目や操作性）の粗さも目立ち、セキュリティ面の対応に苦労したといいます。

似た文脈で語られているのが、オンライン商談システム「bellFace」を運営するベルフェイス株式会社の中島一明代表です。
SNS上では「AIでSaaSが終わる」という風潮が広がる中で、企業の性急な動きに警鐘を鳴らす発信者として知られています。
基幹システムの内製には情報漏洩のリスクが伴うという趣旨の指摘があったと伝えられています。
「作れること」と「安全に運用できること」は別問題だという点は、両者に共通する論点のようです。
ただ、この2つの体験談・発言そのものは一次情報での裏付けが取れていないため、あくまでXで語られている話として受け止めるのが妥当でしょう。
そこで、AI内製の実態そのものを一次情報で確かめてみました。

調べて分かったこと

なぜバグやセキュリティの穴が生まれやすいのか？

情報システム部門向けのメディアが公開している事例集によると、非エンジニアがAIツールで作った社内システムには、共通する落とし穴があるようです。
代表的なのが認証・認可の設計漏れで、URLさえ知っていれば誰でも社内データにアクセスできてしまう状態のまま本番運用されるケースが報告されています。
ある企業では、営業部門が独自に構築した顧客データベースが、3カ月後に「認証なしで全顧客情報が読める状態」だったと判明した事例も紹介されていました。

背景にあるのは、AIが提案するコードの安全性を、作った本人が判断できないという構造的な問題です。
作成者にセキュリティの専門知識がないため、動作確認はできても「守りが甘い」ことには気づけません。
加えて、AIが古いライブラリや非推奨の実装方法を提案してしまうこともあり、表面上は正しく動いていても内部に脆弱性を抱えたまま運用が続く、というパターンが指摘されています。

「SaaSが終わる」論はどこまで本当なのか？

一方で、SaaS業界そのものが揺さぶられているのも事実のようです。
DX支援を手がける企業のレポートによると、AIエージェント（人に代わって複数の作業を自律的にこなすAI）が複雑な業務を代行できるようになりました。
その結果、月額数万円のSaaSが月額数千円台の汎用AIツールに置き換えられる動きが起きていると分析されています。
利用者一人あたりで課金するSaaSの料金モデルは、企業が業務を効率化するほどSaaS側の売上が減るという逆説を抱えています。
この構図が「SaaS解約」の話題が広がる土台になっているようです。

同じレポートでは、AIエージェント時代に対応するには、見た目の使いやすさよりもAPIの豊富さやデータの構造化のしやすさを基準に、業務の記録を管理する基盤（SoR）を選び直す必要があると述べられています。

セキュリティ対策として何が現実的なのか？

企業向けにAI活用のセキュリティ指針を発信するメディアの解説では、情報漏洩の原因の多くは技術的な欠陥そのものより、組織的な要因が占めるとされています。
具体的には、利用ガイドラインや承認フローの未整備が挙げられています。
対策としては、入力してよいデータの範囲をあらかじめ3段階程度に分類しておくことや、法人向けプランに統一してデータの学習利用をオフにすることなどが挙げられていました。
「完璧を目指さず、まずは入力禁止リストだけ作る」という小さな一歩から始める考え方も紹介されており、内製そのものを禁じるのではなく、リスクを管理しながら付き合っていく発想が主流になりつつあるようです。

Shiritomo編集部の考察：明日からやることは「線引き」

編集部として気になったのは、内製の是非が「できる／できない」ではなく「何を作らないか」という選択の問題に移り変わっている点です。
決済や顧客情報のような、事故が起きたときの被害が大きい領域は、これまで通り実績あるSaaSに任せる。
一方で、社内の申請フローや簡易な管理画面のような、失敗しても被害が限定的な領域はAIで内製して素早く試す。
この線引きさえ意識すれば、内製のスピードとSaaSの安定性のいいとこ取りができるはずです。
逆に言えば、線引きを決めずに「作れるから作る」を続けている企業ほど、後になって痛い目を見るリスクが高いのではないでしょうか。
AIツールを日常的に使う読者ほど、自分が今触っているシステムがどちらの領域に属するかを、一度棚卸ししてみる価値がありそうです。

まとめ

AIコーディングツールの登場で、非エンジニアでも社内システムを自分の手で作れる時代になりました。
ただし、バグやセキュリティ対策までを個人の裁量に任せてしまうと、思わぬ事故につながりかねません。
決済や基幹業務は信頼できるSaaSに、周辺業務はAI内製にという線引きが、今のところ最も現実的な付き合い方のようです。