chot Inc.（ちょっと株式会社）

AI自作アプリとSaaS、どちらを選ぶか——追随性・責任性・汎用性で判断する

開発

AIでアプリを作れるようになった結果、「そのSaaSは解約して自作すればいいのでは」という議論が実際に起きています。判断の分かれ目は月額費用と開発工数の比較ではありません。変化に誰が追随し続けるのか（追随性）、事故が起きたとき誰が説明責任を負うのか（責任性）、その業務は自社固有か他社と同じか（汎用性）の3点です。結論を先に書くと、法令や記録の正しさが外部から問われる領域はSaaSに寄せ、自社の差別化や隙間の業務は自作に寄せ、その境界をAPI連携でつなぐ切り分けが現実的です。以下、その根拠を順に整理します。

「自作 vs SaaS」が再燃した背景と、見落とされている計算

この議論は感覚論ではなく、実例が出てきたことで加速しました。米医療保険会社Curativeの創業者は、年間60万ドルのSalesforce契約を解約し、社内でAIを使い2か月で構築した独自CRMに置き換えたとインタビューで語っています。ただし同氏も、CRMの保守には課題が残ると認めています。

一方で、金融側からは冷静な問い直しも出ています。RBCキャピタル・マーケッツのアナリストが公開したビルド／バイの比較ツールは、初期の開発費だけでなく、保守、セキュリティリスク、不具合対応、さらに「機能や信頼性で劣るツールを従業員が使い続けることによる損失」まで変数に入れて総コストを比較する設計になっています。

ここが重要な示唆です。比較すべきは「サブスク費用」対「作る時間」ではなく、「サブスク費用」対「作る時間＋数年分の維持・監視・引き継ぎ・事故対応」です。この総額を出さないまま解約すると、削ったコストが翌年から人件費と障害対応の形で戻ってきます。

追随性：作った後の「変更に追いつく仕事」を誰が持つか

業務システムは完成後も外部要因で変更を強制されます。税制改正、依存ライブラリの脆弱性、外部APIの仕様変更、ブラウザやランタイムの更新です。この追随作業をSaaSはベンダーが引き受け、自作では自社が引き受けます。

典型例が電子帳簿保存法です。JIIMA（日本文書情報マネジメント協会）は市販ソフトが法的要件を満たすかを確認する認証制度を運用し、国税庁も認証製品リストを案内しています。認証済み製品を使えば、要件を一つずつ自社で検証する必要が減るという「予見可能性」が得られます。自作システムにはこの仕組みがありません。要件適合の判断と、改正のたびの再検証は自社の責任として残ります。

ただし注意点もあります。国税庁は、認証ソフトを使っても、事務手続関係書類の備付けなど機能以外の要件は別途満たす必要があると明記しています。SaaSを選べば法令対応が終わるわけではなく、運用側の対応は必ず残ります。

逆方向のリスクも見ておくべきです。SaaSを使う側は、値上げ・機能廃止・UI変更・プラン統廃合といったベンダー側の変更に追随させられます。自作は変更のタイミングを自社で決められる利点があります。つまり追随性は「楽になるか」ではなく「変更の主導権を持つ代わりに作業を負うか、作業を委ねる代わりに主導権を渡すか」という交換条件です。

責任性：SaaSをやめても責任は減らない、形が変わるだけ

個人情報保護法では、クラウド利用が法27条の「提供」に該当しない場合でも、利用する事業者は自ら講ずべき安全管理措置を実施する必要があるとされています（ガイドラインQ&A 7-54）。委託に該当する場合は、法25条に基づく委託先の監督義務が加わります。

ここから読み取れる実務上の意味は明確です。SaaSを使っていても安全管理措置の一次責任は自社にあり、自作に切り替えるとその責任に加えて、これまでベンダーが担っていた技術的措置——認証・認可の設計、アクセス制御、ログ、バックアップ、脆弱性対応——がそのまま自社に移ります。委託先監督の手間は消えますが、責任の総量は増えます。

その責任を負う難しさは、データが示しています。Veracodeが100を超えるLLMに80のコーディングタスクを与えた調査では、生成コードの45%がOWASP Top 10に該当する脆弱性を含みました。2026年春の更新でも、構文の正確さが95%超まで伸びる一方、セキュリティの合格率は約55%で横ばいだと報告されています。モデルを新しくすれば解決する問題ではない、という点が重い事実です。

実害の追跡も始まっています。ジョージア工科大学のSSLabは4万3,000件超のセキュリティアドバイザリを走査し、AIコーディングツール由来と確認できた74件のうち、14件を critical、25件を high と分類しました。2025年後半の約7か月で約18件だった検出が、2026年1〜3月には56件、3月単月で35件に増えています。コマンドインジェクション、認証バイパス、SSRFといった類型で、研究者は「同じモデルを使う開発者が多いほど同じバグが各所に現れる」と指摘しています。攻撃側は一つのパターンを見つければ横展開できるという構造です。

依存関係にも固有のリスクがあります。生成コードの約2割が存在しないパッケージを参照するという研究があり、攻撃者がその名前を先に登録する「slopsquatting」が報告されています。自作を選ぶなら、これらを検知・遮断する体制まで含めて自社の責任範囲だと理解しておく必要があります。

汎用性：他社と同じ業務ほどSaaSが強く、固有業務ほど自作が強い

SaaSの価格には、多数の利用企業から集まったフィードバック、業界慣行への適合、外部サービスとの連携、監査や認証への対応が含まれています。請求、会計、勤怠、給与のように「正しさの基準が社外にある」業務では、この蓄積を自作で置き換えるのは費用対効果が悪くなります。

一方、自社固有のワークフロー、既存システム間の隙間を埋める処理、部門内だけで使う集計や下書き生成などは、SaaSの標準機能に合わせる方がコストになりがちです。ここは自作の適所です。

自作で最も見落とされる汎用性は、人の交代に耐えるかです。作った本人以外が仕様を説明でき、修復できる状態かどうか。AIが書いたコードを誰も読んでいない場合、担当者の異動や退職がそのまま業務停止リスクになります。ツール選定時には、生成物のコードを自社が所有・エクスポートでき、標準的な環境で動かせるかを必ず確認してください。特定サービス上でしか動かない形で作ると、SaaSから逃れたつもりで別のロックインを抱えます。

判断の手順：3問で切り分け、次に運用条件を決める

  1. このデータは、外部（税務・監査・取引先・本人）に正しさを説明する必要があるか。該当するならSaaSまたは実績あるパッケージを軸にする。
  2. この処理は他社と同じか、自社固有か。同じならSaaS、固有なら自作の候補。
  3. 止まったら誰が何時間で直すか、名前で答えられるか。答えられないなら自作しない。

自作すると決めた場合、最低限そろえるべきは次の5点です。第一に、生成コードのレビュー。SSLabの研究者も、本番に出すならジュニア開発者のプルリクエストと同じ厳しさで、特に入力処理と認証周りを見るよう勧めています。第二に、CIでの静的解析・依存脆弱性検査・シークレット検知の自動実行。第三に、個人データを扱うかどうかの事前判定と、扱う場合の暗号化・アクセス制御・ログ保全。第四に、依存更新とバックアップ復旧の定期実施。第五に、仕様と運用手順のドキュメント化、および使わなくなったアプリの棚卸しです。

現実的な折衷案として有効なのが、記録の保持や法令対応はSaaSに残し、その上にAIで作った薄い画面や自動化をAPI経由で載せる構成です。個人データや会計記録を自作側に複製しなければ、責任範囲を広げずに操作性だけを自社仕様にできます。「全面自作か全面SaaSか」を選ぶ必要はありません。

まとめと次の一歩

AIによる自作は選択肢を確実に広げました。ただし増えたのは「作る力」で、「運用し続ける力」と「説明する責任」は自動的には手に入りません。まずは現在契約中のSaaSを、上の3問で分類してみてください。分類が済めば、解約して自作すべきものと、絶対に残すもの、そして自作の薄い層を足すだけで済むものが分かれます。

chot Inc.では、Webサイト制作・フロントエンド開発とあわせて、AIアプリケーション開発を手がけています。AIで作った社内ツールを本番運用に載せる際のレビューや構成の見直し、SaaSと自作の切り分け設計についてご相談があれば、お問い合わせからお気軽にご連絡ください。

出典

この記事をシェア

最新の記事

開発

Vercelの固定料金CDN「Flat Rate CDN」──料金の仕組みと切り替え判断のポイント

AI最新情報

Meta、パーソナルAIエージェント「Muse」を米国で公開 ― できること・料金・セキュリティ設計の要点

AI最新情報

OpenAIが人型ロボットを開発すると明言──何が決まり、何が未確定なのか

コラム一覧