目次
社内でSalesforceの管理を任されていると、日々こんな依頼が飛んできます。
「営業部で新しく管理したい項目があるので、追加してもらえますか」
「この条件でレポートを作りたいんですが、やり方が分からなくて」
「Excelで管理していたこの表、Salesforceに載せられませんか」
一つひとつは10分の作業です。しかし積み上がると、システム担当者の業務時間の相当部分が「SaaSの運用」に消えていきます。しかもその作業は、社内に何かを残すわけでもありません。
さらに厳しいのは、依頼に応えれば応えるほどカスタム項目とカスタムオブジェクトが増え、画面と権限が複雑化し、あなたしか触れないSalesforceが出来上がっていくことです。属人化を避けたくてSaaSを選んだはずが、結果的に属人化している状態になっていないでしょうか。
そんな中で、AIコーディングエージェントの登場によって、システムの内製にかかる工数が、現実的な水準まで下がってきたのです。
株式会社Digeonでは、SFAをSalesforceから自社構築のシステムへ移行しました。さらに、AIエージェント機能を載せ、これまで営業担当者が手作業で行っていた業務を自動化しています。この記事では、その設計思想と手順を、自社で再現できる粒度で共有します。
批判から入る前に、SaaSの合理性を正しく確認しておきます。SaaSがこれだけ普及したのには、明確な理由がありました。
整理すると、SaaSが本当に売っていたのは機能ではなく「作らなくていい」という価値でした。スクラッチ開発と比較したときの決定的な優位性は、工数です。
一方で、SaaSを選ぶということは、次のトレードオフを受け入れることでもありました。
これらは長く、「工数を買っているのだから当然のコスト」として受け入れられてきました。
実際、その判断は合理的でした。
しかし、従来は初期費用を抑えられることがSaaSの強みでしたが、CodexやClaude CodeなどのAIコーディングツールの台頭により、そもそも初期費用の比較の時点で、スクラッチ開発の方がコストメリットで上回るというケースも少なからず目にするようになりました。
SaaS・パッケージ・スクラッチの比較は「SaaS・パッケージではなくスクラッチ開発を選ぶべき3つの条件」で紹介しています。
そして近年、この構造に新しい要素が加わりました。SaaS各社がAI機能を標準機能ではなくアドオンとして販売しており、既存のライセンス費に上乗せされるという点です。
Salesforceを例に取ると、こうなります。
ライセンス種別 | 費用 |
|---|---|
Enterprise | 21,000円/ユーザー |
Agentforce for Sales（アドオン） | 15,000円〜/ユーザー |
※2026年5月時点（セールスフォース・ジャパン公式サイト記載）
自動化の目的の一つがコスト削減だったはずなのに、近年は自動化すればするほど費用が積み上がる状態になりつつあります。
「工数を買っている」という当初のトレードオフは、AI時代に入って明らかに割高になりつつあります。
こうした流れの中で、SaaSというモデルそのものへの批判も出てきています。その代表が「SaaS is dead（SaaSは死んだ）」という言葉です。
2024年12月、BG2 Podcast（Brad Gerstner氏・Bill Gurley氏がホスト）に出演したMicrosoftのSatya Nadella CEOが、エージェント時代にはビジネスアプリケーションという概念自体が崩れていくと述べました。
その論拠は、業務アプリケーションとは突き詰めれば「CRUDデータベースに業務ロジックを乗せたもの」であり、その業務ロジックが「AIエージェント側へ移っていく」というものです。
この発言は「SaaS is dead」というフレーズで世界中に広まりました。
これまで業務ロジックは、SaaSの内部に置かれていました。承認フロー、チェック項目、ステージ遷移のルールも、すべてSaaSの設定画面の中にありました。
しかしAIエージェントが業務を実行する前提に立つと、ロジックはエージェント側へ移り、その下に残るのはデータストアだけになります。
これまでスクラッチ開発が難しかった大きな理由は工数でした。
要件は分かっている。データ構造も頭の中にある。しかし通常業務を回しながらCRUD画面を何十本も実装し、認証と権限を作り、テストを書く時間がない。これが実情だったはずです。
コーディングエージェントは、この工数を大きく削ります。
近年のコーディングエージェントは「コード補完ツール」から「設計を渡せば複数ファイルにまたがる実装を任せられるエージェント」へと質的に変わりました。定型的なCRUD、一覧・詳細画面、バリデーション、テストコードといった、量は多いが判断を要さない実装は、大部分を任せられます。
SaaSが提供していた価値 | 現在の状況 |
|---|---|
開発工数がゼロ | コーディングエージェントで大幅に削減できる |
すぐに使い始められる | スクラッチでも数ヶ月で最小構成が動く |
ベストプラクティスが実装済み | 依然としてSaaSの強み。ただし自社の型と合うかは別問題 |
保守・セキュリティがベンダー持ち | 依然としてSaaSの強み。 |
保守責任とセキュリティ責任がベンダー側にある点は、SaaSの揺るがない価値です。しかし、天秤の片側にあった「工数」という最大の重りが軽くなった以上、トレードオフの計算式そのものを考え直す必要があります。
株式会社Digeonは2026年に入ってから自社で構築したSFAを本番運用しています。運用して実感したメリットをご紹介します。
既製SFAでは、製品側に業務の型があり、そこへ自社の業務を寄せていきます。
例えば、「リード → 取引先 → 商談 → 受注」という標準の流れに、自社の業務フローが合っていれば、何の問題もありません。
既製SFAの型に当てはまっていない場合は、カスタム項目とカスタムオブジェクトを積み増すことになります。そして増えるほど画面と権限が複雑化し、設定を理解している人しか触れないシステムになっていきます。
スクラッチ開発の場合は、順序が逆になり、「自社はどんな流れで仕事をしていて、どこで何を判断しているのか」から出発して、画面とデータ構造を設計することが可能です。
営業の情報は、SFAの中だけにあるわけではありません。
見積は会計システムに、原価は基幹システムに、日々のやり取りはチャットとメールに、資料はストレージに散らばっています。既製SFAを使う場合、これらをつなぐには連携アドオンを買うか、iPaaSを挟むかで作り込むことになります。
そして、たいてい「ここまでは連携できるが、ここから先は手作業」という線がどこかに引かれます。
一方で、自社構築の場合、この線を自分で引くことができます。
そして、私たちが自社構築を選んだ最大の理由がここにあります。
前章で触れたとおり、SaaSに搭載されるAI機能は、そのSaaSの中で完結する範囲しか自動化できません。
商談メモの要約はしてくれる。次のアクションも提案してくれる。しかしそこから先の「見積を作り、稟議を通し、システムに登録し、顧客にメールを送る」という業務フロー全体には手が届きません。
営業担当者の実感としては、「一部は便利になったが、やることの総量は大して減っていない」となります。
スクラッチ構築であれば、データ構造も業務フローも連携先も自社の設計です。
Digeonの商談後のタスク実行までの流れは以下になります。
1~5までの流れで営業がやることは、AIが提示したアクションや登録した内容の確認のみになります。
内製したSFAが既製SaaSより優れている点を3つ挙げました。
自社の業務フローに合わせて機能設計ができること。
自社で使っているツール・システムとそのままつなげられること。
そしてAIエージェントで業務フロー全体を自動化できること。
かつて、SaaSかスクラッチかの判断は工数で決まっていました。作る余力がないからSaaSを選ぶ、という構図です。
コーディングエージェントによってその前提が変わった今、判断の分かれ目は「業務ロジックとデータの設計権を、自社が持つ必要があるかどうか」に移りつつあります。
ただし、すべての企業に内製が向くわけではありません。営業プロセスが一般的な型に収まっていて、連携したいシステムも少なく、社内に改修を継続できる体制がないのであれば、SaaSを使い続けるほうが合理的です。コーディングエージェントは開発工数を減らしますが、運用と責任は減らしません。
株式会社Digeonでは、自社で実践したこの移行の知見をもとに、業務システムの内製化をご支援しています。「自社の場合はどちらが合理的か」という判断からご相談いただけます。ご相談があれば、お気軽にお問い合わせください。
著者
松尾 庄馬
山﨑 祐太
山﨑 祐太
山﨑 祐太
山﨑 祐太
山﨑 祐太
