セキュリティ問題とVC投資としてのSaaSの終焉
AnthropicのS-1が出たのでそちらについても書くことがあるのだろうが、とりあえずは昨今日本のインターネットを騒がせているセキュリティ問題について、一歩ひいた視点でコメントしたいと思う。
何が起きているのかをシンプルに説明すると、AIによるセキュリティ問題の発見が加速化する中、対応を怠ってきたサービスが順番に攻撃されており、その中には商売が上手すぎるうえにザルなセキュリティでもビジネスとして成功していて大口な顧客を持っているプレイヤーも一定数いるがゆえに、データ漏洩が起きた際の社会的関心ないしインパクトが大きいというのが現状だろう。Linuxカーネルやプログラミング言語の脆弱性に起因するゼロデイ攻撃みたいなものは仕方ないと腹をくくれるが、ホワイトハットからの警告をないがしろにしたり、そもそも理解に苦しむ設計を採用していたりと、あまり弁明の余地がないケースも多く見られる。しかしGlobal Moneymaking Opportunitiesなどと揶揄している場合ではない。遡ること20年以上前の話であるが、筆者がよく知るとある企業では、なぜかExchangeサーバだけVPNの外に置いてあり、かつ社員のうち半分くらいのメールアドレスがbaseball1だったので、理論上社内の殆どの機密情報がダウンロードし放題であった（当然ながらWAFのようなものはない）。今でもそのレベルのセキュリティで回っている会社はいくらでもあるはずで、企業は大小を問わず、明日は我が身くらいに思っておくべきである。
セキュリティの本質的な難しさは、企業の成長との両立にある。AIにしたってSaaSにしたってガチガチに縛る方が安全ではある。しかし一切LINEでもFacebook Messengerでも仕事の話をしない人間が営業として優秀だとも思えないし、クラウド型LLMに一切機密情報を渡さないという姿勢は顧客からしたら素晴らしいが、顧客DBをClaude CodeなりCodexに繋げて日々分析している会社の方が、PDCAは何十倍・何百倍も速く回るに違いない。仕事ができる感を醸し出すことと会社のセキュリティに留意することを天秤にかけるならば、100人中99人のサラリーマンが前者を選ぶだろう。AIに代替される恐怖が現実味を帯びてきたホワイトカラーの職場なら尚更である。
何よりセキュリティ問題はひとつの会社で完結する話ではない。Google Sheetひとつを共有するにしても、共有した瞬間そこに含まれる情報の安全性は、共有先の情報管理に委ねられる。この問題は再帰的であり、その最たる例がSaaSだ。SaaSに機密情報を置くということは、そのSaaSが再委託しているサービス、そしてその先で再々委託しているサービスたちを信頼することと同値である。
先月名刺管理サービスSansanの顧客データが一部漏洩して話題となったが、これもユーザーコミュニティ運営のために導入したCommuneがセキュリティ攻撃を受けたことが直接の原因である。Commune社の説明によると「非公開コミュニティの招待リンクを不正に取得して一般会員として登録」できてしまったことで、悪意のあるユーザーがプラットフォームに侵入、その後コミュニティ管理者になりすましたと報告されていることから、既存のシステム脆弱性とソーシャルエンジニアリング攻撃を組み合わせたものだと考えられる。もちろんSansan以外の被害報告もあがってきている。森永乳業、ヤマハ、スズキ、博報堂DY One、LINEヤフーなどが既にプレスリリースを出しており、これだけの大企業においてコミュニティ施策の重要性を訴求し、かつその実現手段として自社プラットフォームの導入を決めさせたCommuneの営業力を感じる。冒頭でも述べたように、営業が上手な会社ほど足元の技術を固めることが疎かになりがちで、セキュリティ文脈では悪循環を生みやすい。
SecuritizeしてたらUnsecureだった話
一方で、Communeのセキュリティ問題による被害がそれでも大きくなかったのは、言うてコミュニティ運営SaaSがそこまで普及していないからである。これが一般消費者向けサービスとなると話が変わってくる。その最たる例がSecuritize Japanの一件だろう。
Securitize Japanと言われてピンと来る読者は殆どいないのではないか。ではSTdirectServicesの提供元と言えばどうだろうか。それでも殆どの人には馴染みがないだろう。「楽天証券や野村證券が先月末公表したデータ漏洩の原因となった、NTTデータが運用・販売するデジタル特典付き社債サービス」といってようやく意味が通じるのではなかろうか。Securitize Japan社のやっつけ仕事感このうえないウェブサイトに載っているNTTデータ社事例から引用する（強調は筆者）。
社債を買う投資家層は長年、富裕層や一部の機関投資家に偏っていました。加えて低金利環境が続き、個人投資家にとって魅力が薄れていたのです。そこで注目したのがデジタル特典付き社債の特性です。テクノロジーの力によって小口化が可能になり、10万円単位での販売を実現しました。従来は100万円単位の販売でしたから、これは大きな変化です。また、デジタル基盤を通じて発行企業と投資家が直接つながり、継続的なエンゲージメントを生み出せる点も決め手でした。
特に「デジタル特典付き」という設計は画期的だったと思います。単なる利息（クーポン）だけでは投資家の関心を引きにくい状況でしたが、特典を組み合わせることで購買意欲が大きく高まりました。
JR西日本やカゴメの案件は、従来通りの振替債（ほふりを利用した社債）に、発行企業が直接投資家に特典を付与できるようにしたもので、セキュリティトークンを活用したものではありませんが、デジタル特典付き社債の成功事例です。実際、JR西日本やカゴメの最初の案件は、販売開始からわずかな時間で完売しています。
そうすると気になるのがこのSecuritize Japanという会社なのだが、その名前からもわかるとおり外資系企業の東京オフィスである。Securitize本体は米国NYSEでCantor Fitzgeraldが用意したSPACに載っかって上場したFintech企業で、その業績はお世辞にもよいとはいえない。直近四半期の売上は$14.4M（22億円）で対前年比で5％ダウン、GAAP経常利益もマイナス$21.7Mと2026年上半期のRule of 40は衝撃のマイナス20%を叩き出している。2025年の売上も一見良さそうに見えるが、ファンド管理系の事業買収によるところも大きい。
そんなSecuritizeがなぜここまで日本の金融インフラに入り込めたのだろうか。7月にSPAC上場した際に独立系VCグローバル・ブレインが公開したインタビューから引用する。
──出資後のSecuritizeとGBの関わり方について教えてください。
百合本：私たちは特にSecuritizeの日本市場進出に対して深く支援してきました。Securitizeの技術力やエグゼキューション力は圧倒的でしたが、彼らが単独で日本に進出して人材を採用したり、行政手続きを行ったりするのは至難の業です。日本の商習慣の複雑さも大きなハードルになります。
そこでGBでは、私たちの強みの1つである国内大企業との強固なネットワークや、事業開発のノウハウをもとにSecuritizeを支援していくことにしました。
──具体的にはどのようなアプローチを取られたのですか。
百合本：まずは国内大企業とGBが共同で設立した各CVCとの連携です。2019年には三井不動産と設立した31VENTURESファンドと、KDDIと設立したKOIF3号ファンドから出資を実施。さらに、2020年にはソニーフィナンシャルベンチャーズと設立したSFV・GBファンドからも追加で出資を行いました。Securitizeにとって日本市場は大きなマーケットでしたから、日本の大企業とのパートナーシップ強化は私たちが特に価値を発揮できる場と考え、積極的に支援した形です。
つまりGlobal Brainからの声掛けにより金融系CVCが積極的にSecuritizeに投資、その関係性を活かしてオンライン証券プラットフォームへの組み込みが早期に実現したようだ。その結果、被害規模こそ小さけれど、前述の楽天証券と野村證券に加え、SBI証券、三菱UFJモルガン・スタンレー証券、ソニー銀行などが影響を受けたと発表している。ちなみにNTTデータの名誉のために付け加えておくと、これは何もNTTデータを経由しているから発生した問題ではなさそうだ。Securitize Japanと直接契約している丸井グループとLIFULL不動産クラウドファンディングでもデータ漏洩が発生しているため、おそらくSecuritizeそのものが然程Secureではないのだろう。こちらの5年前の記事によると、Securitizeは2019年にGlobal Brainが共同創業したブロックチェーン議場支援会社BUIDLを買収しており、元BUIDLチームがその後Securitize全体の認証モジュールを手掛けたそうだ。もはや依存関係が複雑すぎてわからないが、とりあえずSecuritize Japanは金融庁から業務停止命令を喰らってもおかしくないレベルの過失を犯したようにみえる。
説明責任回避 as a ServiceとしてのSaaS
マクロな話をすると約束したのにだいぶミクロな話を書いてしまったので、またマクロに話を戻す。ここまでサプライチェーン攻撃が日常茶飯時になってくると、もはや完全に防御することは現実的ではない。ではどうしたらよいかというと①SaaSに関しては、データが漏洩しても許してもらえる業界標準を使うこと②効果の有無に関係なくセキュリティSaaSを導入することが最善の選択肢のように思える。
まず①に関してだが、内製化は非現実的である。そんな技術力があるならとっくに内製化しているだろう。なのでSaaSには頼り続けるしかないのだが、ご覧のようにSaaS企業とて穴だらけである。ゆえに「穴のあいてないSaaSを探す」のではなく、「正しい穴が空いたSaaSを使う」ことが正解となる。たとえばCRMならばHubSpotを使うよりSalesforceを使うほうがよい。なぜならSalesforceなら、大谷翔平選手がCMに出ていて安心だからである。当然Salesforceだってセキュリティ問題を抱えているだろうが、もしSalesforceからデータ漏洩することがあればありとあらゆる大企業が影響を受けてプレスリリースを出すのでもはや市場全体で「しょうがないよね」という共通認識が形成されやすい。これがHubSpotだと「なんだコーポレートカラーもオレンジでチャラいな、こんなものを使っているから攻撃されたんだ」となるだろう。個人的にはHubSpotに対して何の恨みもないが、それが市場の現実である。
この「正しい穴が空いたSaaSを使う」というルールは再帰的に適用しなくてはならない。つまり正しい穴が空いている条件として、そのSaaS企業が再委託しているSaaSにも、正しい穴が空いていることを求めることが必須となる。つまり「HubSpot的何かを直接使うことを回避する」だけでは十分ではなく、「HubSpot的何かをこの期に及んで使っているチャラいSaaSは念のため避ける」こととなる。なぜなら「HubSpot的何か」の穴が悪用され、それが原因でチャラいSaaSにも穴が空いた場合、そのチャラい穴は間違った穴として叩かれるからだ。先のデジタル証券プラットフォームやらかし事件にしても、NTTデータまでは「正しい穴」で、Securitize Japanは「チャラいHubSpot的何か」と整理することができる。その意味では、プレスリリースの中で「NTTデータとその委託先」までとしか言及しなかった各社IRの判断はきわめて適切だったと言えよう。
次に②に関してであるが、セキュリティSaaSは引き続き導入されていくだろう。これは決してセキュリティSaaSを使えば万全だからではない。セキュリティSaaS未導入でインシデントが発生した場合、導入していなかった説明責任を問われるからだ。もちろんセキュリティSaaSそのものが攻撃されることで、ユーザーデータ保護の観点からは導入しなかった方がよかったみたいな結果にもなるかもしれない。しかし大事なのはいずれ起きるセキュリティ問題に対して「正しい穴」を整備することであり、同じ穴でも「セキュリティSaaSも見逃した穴」と「なんとなく空いていた穴」では、説明責任という意味でゼロトラストとトラストゼロくらいの開きがある。前者は力不足で許されるかもしれないが、後者は努力不足を糾弾されるだろう。なので当ニュースレターも過去に触れたZScalerやCrowdStrikeといった会社は、今後もノールックで契約が更新されていくことが予想される。
しかしこうなってくると、もはや法人向けSaaSを新しく立ち上げることは無謀でしかない。大企業からしたら、これ以上ソフトウェアのサプライチェーンを複雑化することには消極的だろうし、ましてやその中にどこの馬の骨ともわからない新興サービスを組み込むことは、割にあわないリスクとなる。そして万が一ビジネスが立ち上がったとして、それ相応のビジネス規模に成長すれば、今回のCommuneのように狙い撃ちされる。成長途上にあるSaaS企業は往々にしてトップラインを優先し、バックオフィスやセキュリティといった守りの部分が弱くなりがちだ。ハッカーたちからしたら「美味しいデータを持ってるディフェンスザルなザコ標的」になり得るわけで、そのSASUKEもビックリ無理ゲーキャズムが予期されるビジネスに投資家のリスクマネーが集まるとは考えづらい。SaaSというカテゴリは生き残るかもしれないが、少なくとも法人向けのSaaSを一から育てるのは、以前にも増して茨の道となるのではなかろうか。ｺｯｶﾗSaaS！
すでに登録済みの方は こちら
読者限定の内容も逃しません。