クラウドの3層アーキテクチャ ― SalesforceをPaaSとして捉える

まず、基本的なことではありますが、クラウドサービスは、事業者がどこまでを提供し、利用者がどこからを担うかによって、3つの層に整理できます。IaaS（Infrastructure as a Service）は、サーバーやストレージ、ネットワークといったITインフラを提供するサービス。PaaS（Platform as a Service）は、インフラに加えて、アプリケーションを開発・実行するための基盤までを提供するサービス。SaaS（Software as a Service）は、完成したアプリケーションそのものを提供するサービスです。下の層ほど自由度が高く、利用者が担う範囲が広い。上の層ほど手間がかからず、事業者が担う範囲が広い。クラウドの選択とは、突き詰めれば「どの層から先を自分で担うか」という責任範囲の選択です。

定義だけでは無味乾燥なので、家に例えてみます。IaaSは「土地と電気・水道」です。AWSやMicrosoft Azure、Google Cloudが代表例で、土地は借りられますが、家は自分で建てなければなりません。PaaSは「基礎と骨組みまで済んだ家」。データベース、開発環境、実行基盤、セキュリティ機構があらかじめ用意されており、開発者は基礎工事に煩わされず、部屋の中身、つまり業務のロジックに集中できます。SaaSは「家具付きで今日から住める家」。Gmail、Slack、そして多くの人が思い浮かべる「Salesforce」も、この層のサービスとして認識されています。

そして重要なのは、この3層が上下に積み重なる関係にあることです。SaaSはPaaSの上に、PaaSはIaaSの上に成り立つ。つまり、どんなSaaSも、分解すれば必ず「何らかのインフラの上の、何らかの基盤の上に作られたアプリケーション」です。例外はありません。皆さんが日々使っているあのサービスも、あの業務ツールも、床下を覗けば必ず、開発基盤の層とインフラの層が現れます。普段は見えないだけで、そこには必ず「土台」があるのです。

ところが私たちは、SaaSを選ぶとき、この積み木の一番上しか見ていないことが多いのが実状です。機能比較表を作り、画面の使いやすさを確かめ、導入実績の数を数える。どれも大切な確認です。しかし家選びに例えるなら、それは家具や間取りばかりを比較して、基礎と立地を確かめていない状態に近い。入居した瞬間の満足を決めるのは家具かもしれませんが、10年住んだときの満足を決めるのは基礎です。業務システムも同じで、その寿命と発展性を決めるのは、アプリケーションの下にある土台です。では、この視点で、世界で最も使われている業務系SaaSを見直してみましょう。何が見えてくるでしょうか。

「SalesforceはCRMのSaaSである」。おそらく大半のビジネスパーソンが、この理解を持っているはずです。そしてこの理解は、間違いではありません。ただ、半分しか正しくない。残りの半分を知ると、この製品の見え方が、そしてSaaSというもの全体の見え方が変わります。

世界中の企業が使うSales CloudやService Cloud。商談管理やカスタマーサービスの代名詞となったこれらの製品は、実は、Salesforce社自身が「Salesforce Platform」というPaaSの上に構築した、SaaSアプリケーションです。Salesforce Platformは、業務アプリケーションの開発に特化したPaaSという意味で、aPaaS（application Platform as a Service）とも呼ばれます。つまりSalesforceという会社の内部には、最初から3層構造が存在しているのです。IaaS層には、AWSを中心とするインフラ基盤（Hyperforce）。PaaS層には、データモデル・開発環境・自動化・セキュリティといった開発の土台一式を備えたSalesforce Platform。そしてSaaS層に、Sales Cloud、Service Cloud、AIエージェントのAgentforceといったアプリケーション群が載っています。前章で立てた命題、「どんなSaaSも、何らかの基盤の上に作られたアプリケーションである」を、Salesforceは自社の中で体現しているわけです（製品としての全体像は「Salesforceとは」の記事をご覧ください）。

そして、ここが決定的な点です。このPaaS層は、第三者に開放されています。Salesforce社が自社のCRM製品を作ったのとまったく同じ土台の上に、外部の企業が自分たちのアプリケーションを構築できる。これが何を意味するか。企業のシステム調達は長らく、「パッケージをそのまま使う」か「スクラッチでゼロから作る」かの二択で語られてきました。開放されたPaaSは、その中間に第三の道を開きます。実績ある基盤の部品と信頼性を土台として受け取りながら、その上に自社ならではの業務アプリケーションを構築する道です。調査会社ガートナーのローコード・アプリケーションプラットフォーム（LCAP）のMagic Quadrant評価（2025年版）において、Salesforceが「CRMベンダー」としてではなく「プラットフォームベンダー」としてリーダーに位置づけられているのは、この実態の反映です。（出典：Gartner「Magic Quadrant for Enterprise Low-Code Application Platforms」2025年7月28日公開・公式レポートページ。）

「SalesforceはCRMのSaaS」という通説は、氷山の水面から出た部分だけを見た理解です。水面下には、そのCRMを生み出した基盤そのものが沈み、支えている。そしてこの見方はSalesforceに固有の話ではありません。どんなクラウドサービスにも、水面下の層は必ずあります。3層アーキテクチャとは、あらゆるSaaSに適用できる観察の道具であり、本稿がSalesforceを取り上げるのは、その構造が最も鮮やかに表れている素材だからです。

Unisrv 電力CISは、電力小売事業者の料金計算・契約管理を担う基幹システムです。現在、30社を超える小売電気事業者に採用され、100万件を超える需要家のデータがこの上で日々処理されています。冒頭の疑問、「なぜCRMの上に基幹システムを？」への答えは、もうお分かりかと思います。私たちはCRMの上に作ったのではありません。Salesforce社が自社のCRMを作ったのと同じPaaSの上に、電力CISというアプリケーションを作ったのです。3層で言えば、IaaS層はAWS、PaaS層はSalesforce Platform、SaaS層がUnisrv 電力CIS。クラウドの教科書通りの、正規のスタックです。

この選択は、思想から生まれたものではなく、与件から生まれたものでした。電力小売という事業には、特有の条件があります。第一に、変化の速さ。電力自由化以降、市場の新設や託送制度の見直しといった制度変更が絶えず、システムはそのたびに正確な追従を求められます。第二に、信頼性の水準。電気は社会インフラであり、毎月の料金計算に「おおむね正しい」は許されません。第三に、顧客接点の密度。料金、契約、引越し、問い合わせと、需要家との接点が業務の隅々まで及びます。この与件に対して、どの土台の上に建てるのが最も合理的か。それが構築時の私たちの問いでした。10年近くこのシステムを提供し続けた今、答え合わせの結果を3つに整理できます。

第一に、非機能要件の「継承」です。可用性、セキュリティ、政府情報システムのセキュリティ評価制度（ISMAP）への対応、年数回の自動アップグレード。これらは私たちが単独で保証しているのではなく、世界最大級のエンタープライズ基盤に投じられ続ける巨額の投資を、土台ごと継承しています。スクラッチ開発で同じ水準を維持しようとすれば、そのコストはすべて個社の負担になります。

第二に、変化に追従する速度です。制度が変わるたびにシステムの土台から手を入れていては、事業のスピードに追いつけません。骨組みが用意された基盤の上では、変更の対象を業務ロジックに絞り込める。制度対応の速さは、電力業界では競争力そのものです。

第三に、これが本稿の主眼ですが、アプリケーションを「並べて」構築し、拡張していけることです。私たちは電力CISという基幹業務のアプリケーションから始めましたが、同じ基盤の上には、CRMやSFAといったアプリケーション群を並べて構築し、業務の広がりに合わせて増築していくことができます。土台は共通ですから、増築のたびに基礎工事をやり直す必要がなく、権限管理やセキュリティといった共通部品も作り直さずに済む。基幹業務の隣に顧客管理を、その隣に営業支援を、と事業の成長に合わせて建て増していける構造です。しかも、この世界は閉じていません。Salesforce Platformは標準的なAPIによる連携の仕組みを備えており、基盤の外にあるシステム、たとえば独自の顧客接点やWebサービス、他社のクラウドとも、疎結合でつながることができます。すべてをこの基盤の中に置く必要はないし、置くべきでもない。囲い込まれるのではなく、外と連携しながら拡張していける。業務アプリケーションの土台として私たちがこのPaaSを評価するのは、骨組みの充実と、この開かれた拡張性の両立です。

そしてAIです。Episode 1の問い、「AIが働ける土台か」に対する本稿の答えは、こうなります。進化し続けるPaaSは、AIのような新しい技術も、土台ごと供給してくる。生成AIの登場後、Salesforce PlatformにはAIエージェントを構築・運用する機能が基盤の進化として組み込まれました（その上のアプリケーションの一例がAgentforceです）。つまり、この土台の上に建っているアプリケーションは、AIという新技術を個別に建て増しするのではなく、基盤のアップグレードとして受け取れる。考えてみれば、これは幸運な話です。私たちが電力CISを構築したとき、今日の生成AIの隆盛を予見していたわけではありません。当時の判断基準は、あくまで電力小売の与件に対する合理性でした。それでも今、AIへの道が土台側から開かれている。土台を選ぶという行為には、まだ見ぬ技術への保険という側面があるのです。予見できない未来に備える唯一の方法は、進化し続ける土台の上に立つこと。10年提供し続けて得た、私たちの実感です。

Episode 1で、WebサイトのAI対応は情報の構造化という基礎工事から始まる、と論じました。本稿で見てきた業務システムの話は、それと対をなします。Webの土台が情報の構造化なら、業務の土台は、3層アーキテクチャを見極める目。どちらも、表から見えるもの、つまりページのデザインや機能の一覧ではなく、その下にある構造が成否を決めるという点で、同じ形をしています。構造化データの実装がWebの床下工事だとすれば、PaaSの見極めは業務システムの地盤調査です。そしてAIは、床下と地盤の出来栄えを容赦なく映し出します。AI-Readyな企業の条件としてよく語られる「組織・データ・Web」に、私はもう一つ、「業務基盤」を加えたいと思います。AIが働けるWebと、AIが働ける業務システム。この2つが揃ってはじめて、企業はAI-Readyの入り口に立ちます。

だから、SaaSを選ぶときの問いを変えることをお勧めします。「どんな機能があるか」ではなく、「このSaaSは、どんな土台の上に建っているのか。その土台は、進化し続けるのか」。機能の比較表は、選定の場では興味の対象となりやすいとは思います。しかしアプリケーションの機能は、数年で他社に追いつかれます。選定時に差がついたあの機能が、3年後には業界標準になっている。そんな光景を、25年を超えるB2Bの現場で私は何度も見てきました。一方で、土台の良し悪しは簡単には覆りません。それは10年のシステム投資の回収を左右し、そして本稿で見てきたとおり、AIのような次の技術変化を土台ごと受け取れるかどうかを左右します。

その土台に、唯一の正解はありません。ハイパースケーラーの更地に自社で建てる道。複数の業務SaaSを連携基盤でつなぐ分散型の道。そして、業務アプリケーションに特化したPaaSの上に集約していく道。企業の与件、つまり業務の独自性、変化の速さ、開発体制、既存資産のありようによって、合理的な答えは変わります。いずれの道も、AIが働ける土台になりえます。重要なのは、どれを選ぶかの前に、土台を見る目を持って選ぶことです。なお、データをどこに置き、どう統合するかは、業務アプリケーションの土台選びとは別の、それ自体が重要な設計判断です。本稿ではあえて扱いませんでした。稿を改めて論じるべき、もう一つの大きなテーマです。

電力小売事業者向けの業務アプリケーションの土台として、私たちはSalesforce Platformを選びました。それはシステム全体を構成する一つの要素であり、唯一解ではありません。読者の皆さまの与件では、別の答えになるかもしれない。ただし、問いは同じです。

その土台は、進化し続け、拡張できるか。

家具や間取りの比較を、いったん脇に置いて。次にシステムを選ぶとき、まず床下を覗いてみてください。3層の地図を手にしたあなたには、もう土台が見えるはずです。