Delve論争：セキュリティ点検を任せる際に確認すべきこと

規制遵守を支援していた企業に提起された疑惑

Delveは、企業がSOC 2監査¹を準備し、HIPAA²やGDPR³といった規制を遵守するのに必要な業務を自動化する企業です。証拠資料の収集や文書作成にかかる時間をAIで削減すると謳っていました。2025年には企業価値3億ドルで3,200万ドルのシリーズA投資を受けました。

ところが2026年3月から、監査資料を杜撰に作成し、顧客企業のオープンソースコードを出典表示なしに使用したという疑惑が相次いで浮上しました。**4月4日には共同創業者のセリン・コカラーがYCとの決別を発表しました。**同社は、告発内容が歪曲されていると反論しました。監査資料が実際の点検を反映しているか、オープンソースをどのような条件で使用したのかが主な争点です。

創業から2026年4月のYCとの決別まで

会社の成長過程と疑惑が提起された経緯を時系列で見ると、以下の通りです。告発者が公開した資料に関する主張は、その出典を別途記載しました。

**2023年：**MITで出会ったカルン・カウシクとセリン・コカラーが創業しました。創業者たちは、医療分野のサービスを作る過程でHIPAA対応に多くの時間と資金を費やした経験が、コンプライアンス事業へ転換するきっかけになったと説明しています。

**2024年初め：**YC Winter 2024プログラムに参加しました。当時の公開紹介では、インフラ設定、ポリシー文書、モニタリングを通じてHIPAA対応を支援すると説明していました。

**2025年1月：**General Catalystなどが参加した330万ドルのシード投資調達が明らかになりました。

**2025年4月：**DeepDelverが公開した資料によると、Sim.aiがDelveの顧客となり、SOC 2とHIPAA対応サービスに1万5,000ドルを支払うことになりました。同じ頃、DelveがSim.aiの公開プロジェクトSimStudioを自社のPathwaysに適用し始めたというのが告発者の主張です。告発者は移植する構成要素を記載した社内計画文書も提示しました。

**2025年7月：**DelveはInsight Partners主導で3,200万ドルの投資を受けたと発表しました。この時提示された企業価値が3億ドルです。

投資調達とYC参加の経歴は、Delveが営業で打ち出せる信頼要素でした。ただし、こうした経歴だけでサービスの点検品質まで確認できるわけではありません。

**2025年末：**DeepDelverは、顧客報告書に連なるスプレッドシートの流出を知らせるメールを受け取った後、他の顧客とともに調査に乗り出したと明らかにしました。同じ時期、創業者たちはForbesの「30 Under 30」AI部門の2026年リストに名を連ねました。

2026年3月19日：匿名アカウントDeepDelverの最初の投稿が公開されました。告発者は、数百件のSOC 2報告書の草案に同じ文言と監査結論が繰り返されていると主張しました。例に挙げた特定の一文が494件中493件、約99.8%の報告書に存在したというものです。これは報告書全体の内容の類似度が99.8%だという分析とは異なります。

**2026年3月20日：**Delveは公式ブログで疑惑を否定しました。最終報告書と意見は独立した監査人が発行しており、顧客は監査人を選択できると説明しました。文書の雛形は顧客が実際の状況に合わせて検討し完成させるべき草案であり、標準に従う報告書の間で共通の文言が生じるのは自然なことだという立場でした。

**2026年3月23日：**Insight Partnersの投資紹介記事が一時的に削除されたと報じられました。当該ブログ記事はその後復元されました。記事が消えたという事実だけでは、投資撤回や疑惑に対する投資会社の最終判断を知ることはできません。

**2026年3月31日：**DeepDelverはSimStudioとPathwaysの関係を扱った続報を公開しました。Sim.ai側は、出典表示なしに自社製品名として提供することを許可する別途の契約は締結していないと答えました。告発者は、Pathwaysが企業顧客を相手に販売されていたと主張しました。

**2026年4月1日：**TechCrunchがSim.ai代表のエミル・カラベグに確認を取り、この論争を報じました。4月3日、Delveは公式反論文でApache 2.0プロジェクトを土台にコンプライアンス用途に合わせて大幅に修正したと明らかにしました。同時に、監査人ネットワークの再整備、稼働中の顧客を対象とした無料の再監査とペネトレーションテスト、監査業務に連動した自動化の停止などを発表しました。

**2026年4月4日：**コカラーがYCとの決別を発表し、YCの公開企業リストからもDelveが外れたと報じられました。この変化は、個別の疑惑の真偽や法的責任を確定するものではありません。

オープンソース利用と顧客への説明は別々に見るべきです

公開されたコードをコピーして修正することをフォークと呼びます。⁴オープンソースライセンスが許容する範囲であれば、別途の有償契約なしに商業的に利用できます。したがって「対価を支払わなかった」という事実だけで、無断使用だと断定することはできません。

今回の件で言及されたApache 2.0ライセンスは、商業的な使用・修正・再配布を許容しています。修正した部分に別のライセンスを適用することも、定められた条件の範囲内で可能です。争点は、当該コードの使用・配布方式にどのような条件が適用され、Delveがその条件を守ったかどうかです。

Apache 2.0の第4条は、原本または派生物を再配布する際に、次の条件を求めています。

• 受け取る側にライセンスの写しを提供すること。
• 変更を加えたファイルには、変更した旨を明記すること。
• 配布する派生ソースには、該当部分に関わる著作権・特許・商標・出典表示を維持すること。
• 原本にNOTICEファイルがある場合は、該当する出典表示を定められた位置に含めること。

公開された疑惑の核心は、SimStudioを活用しながら顧客には最初から自社で独自開発した製品だと説明していた、という点です。コードの出所と顧客への説明を確認する必要があります。ただし、実際の配布物と表示をすべて照合しないまま、「ライセンス条件4つすべてに違反した」と断定することはできません。

顧客関係も重要です。Sim.aiはDelveに規制遵守業務を任せていた顧客でした。自社の公開コードをサービス提供者が活用する場合であっても、その用途や顧客への説明が不透明であれば、信頼の問題が生じ得ます。この件で顧客の非公開コードやセキュリティ情報を持ち出したと確認されたわけではないため、公開コード利用の疑惑と混同してはいけません。

私はここで、ライセンス条件を守ったかどうかと、取引相手に正確に説明したかどうかを、それぞれ確認すべきだと考えます。オープンソースを使ったからといって問題があるわけではなく、商業利用が許されているからといってあらゆる説明が正当化されるわけでもないからです。

告発内容が事実であれば、顧客に約束したサービスと実際に提供したサービスの間に差があったかを検証する必要があります。Delveはこれについて、告発資料が文脈から外れて使用され、資料が悪意を持って流出したものだと反論しています。この主張もまた、会社側の説明として読む必要があります。

確認すべき問いは、次の三つに整理できます。

• 監査文書は、顧客の実際のシステムと点検結果を反映していたか。
• 監査人は十分な証拠を確認したうえで独立して結論を下したか。
• Pathwaysに使用したコードと出典表示は、適用されるライセンス条件を満たしていたか。

同じネットワークにいるという信頼が点検の代わりになるとき

YC出身の企業同士は、互いの製品を購入し推薦し合います。見知らぬ供給業者よりも、背景をよく知る会社をまず検討するのは自然なことです。Sim.aiとDelveの取引にも、そうした関係がありました。

しかし、著名な投資家からの投資や創業プログラムへの参加は、個々の顧客のセキュリティ統制がきちんと機能している保証にはなりません。Delveは3月20日の反論文で、顧客が1,700社を超えると明らかにしました。顧客数が多いという説明だけでは、自社の監査が誠実に行われたかどうかはわかりません。

コミュニティでは、YCの対応理由をめぐって様々な解釈が出ました。私は、外部から確認しづらい除名理由を推測するよりも、購入者が有名な名前に頼ってどのような確認を省いたのかを見つめるほうが、より有用だと考えます。

同窓生間の推薦は、供給業者を探すコストを減らしてくれます。その次には、契約範囲、監査人の独立性、実際の成果物を自ら確認する必要があります。推薦は検討を始める理由にはなりますが、検討を終える根拠にはなりません。

Oswarldの視点

私はこの件を見ながら、Delveが打ち出していた処理速度の速さを事業的にどう評価すべきか考えました。

GTM戦略を策定してきた経験から見ると、数か月かかっていた業務を数日に短縮するという提案は、顧客を説得しやすいものです。ただし、何を短縮したのかを説明できなければなりません。資料収集や反復入力を自動化することは助けになりますが、実際に統制が機能したかを確認する証拠と、監査人による独立した判断は必要です。自動化と独立検証は両立可能であり、両立するように設計すべきです。

オープンソースで製品開発の時間を短縮するのも合理的な選択です。そうであるほど、どのコードを使い、どのような表示が必要かを記録しておくべきです。私は、迅速なリリースと規制遵守を互いに衝突する目標として扱うと、問題が生じた際に確認すべき資料からして不足してしまうと考えます。

顧客だと明かした匿名の投稿者や告発者たちが、この論争を公然と提起した点も目に留まりました。これを機に、顧客が監査資料に疑問を提起する通路や、監査人に直接確認する方法が十分にあるかを問うことができます。ただし、一つの事件だけをもって規制当局と業界の監視がまったく機能していなかったと結論づけるのは難しいでしょう。

著名投資家の投資、メディア紹介、受賞歴が重なると、会社がすでに十分な検証を受けているという印象を与えやすくなります。私自身も、事業を評価する際にそうした名前がまず目に入ってしまうことがあると思います。だからこそ、評判に関する資料と、製品が実際に機能しているという資料を別々に確認する手続きが必要です。Delveの疑惑を判断する際も、投資歴より実際の監査資料とコード利用履歴のほうが、より直接的な根拠です。

おわりに

オープンソースを商業的に利用する際は、該当ライセンスの条件を確認する必要があります。開発の出所を顧客に説明する方法も、実際の使用履歴と合っていなければなりません。

セキュリティ・規制遵守業務を任せる際には、まず供給業者と監査人がそれぞれ何を行っているのかを確認したいところです。報告書が対象とするシステムと期間、点検した項目と例外事項も併せて見るべきでしょう。SOC 2はこうした統制についての監査報告書であり、HIPAAやGDPRは適用対象が守るべき法的義務です。これらをすべて一つの「セキュリティ認証」としてまとめてしまうと、実際の責任範囲があいまいになります。

迅速な処理を提案する業者には、何の作業が短縮されたのかを具体的に尋ねることができます。資料収集の時間が減ったのか、人が検討する範囲まで減ったのかによって、その意味は変わってきます。

特にHIPAAに関しては、米保健福祉省が民間機関による「認証」を認定・保証していないと説明しています。外部業者を利用したとしても、適用対象企業の法的義務が消えるわけではありません。

私は、成長速度だけを評価し、検証に必要な時間と責任を明確にしない事業運営を懸念しています。Delveに提起された疑惑の最終的な判断とは別に、これは私たちがサービスを選び評価する際にすでに適用できる問いです。どれだけ速く終わったかとともに、何を確認し、誰が結論を下したのかを見ていきましょう。

参考資料と関連リンク

• DeepDelver、Delve – Fake Compliance as a Service – Part I、2026年3月19日。告発者の主張と文言頻度分析が収められています。
• DeepDelver、Part II – Day 2 of 5、2026年3月31日。Sim.aiとPathwaysに関する続報の主張、およびSim.ai側の回答を掲載しています。
• Delve、Response to Misleading Claims、2026年3月20日。監査、文書の雛形、自動化についての会社の反論です。
• Delve、Delve sets the record straight on anonymous attacks、2026年4月3日。オープンソース活用についての説明と、後続措置を発表しています。
• Julie Bort、The reputation of troubled YC startup Delve has gotten even worse、TechCrunch、2026年4月1日。
• Anthony Ha、Embattled startup Delve has ‘parted ways’ with Y Combinator、TechCrunch、2026年4月4日。
• Delve、シリーズA投資発表、2025年7月22日。創業者たちによる2024年のサービス紹介、Forbes人物紹介。
• Apache Software Foundation、Apache License, Version 2.0。使用許容範囲と再配布条件の原文です。
• AICPA、SOC 2の紹介。米国HHS、HIPAA Security Ruleと民間認証に関する案内。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

각주

1. SOC 2：サービス提供組織のセキュリティ・可用性・処理の完全性・機密性・プライバシー保護に関する統制を、独立した会計事務所が評価し報告する枠組みです。すべてのセキュリティ事故を防ぐという保証ではありません。 ↩

2. HIPAA：米国の医療情報保護等に関する法律です。適用対象となる医療機関・健康保険関連機関および業務受託者などの義務を定めています。健康情報を扱うすべてのサービスに一律に適用されるわけではありません。 ↩

3. GDPR：EUの個人情報保護規則です。事業者の所在地だけでなく、処理活動と適用範囲を確認する必要があります。 ↩

4. フォーク（Fork）：既存プロジェクトのコードをもとに、別途の開発を始めることを指します。公開コードであっても、使用・修正・配布する際には該当のライセンスに従う必要があります。 ↩