ベンダー審査シートの「提供元」欄で手が止まる。これがLovableの導入検討でほぼ必ず起きることです。日本語の会社概要ページが存在せず、検索しても出てくるのは製品の使い方の記事ばかりで、法人名・所在地・資本の裏づけといった審査に必要な情報がまとまっていません。

この記事では、Lovableの運営会社・創業者・資金調達・利用規模を一次情報で整理し、そのうえでベンダー審査シートのどの欄に何を書けばよいかまで落とします。株式会社100はLovableの日本初の公式パートナーとして稟議・審査の資料作成を支援しており、そこで実際に求められる項目に沿って構成しています。

Lovableの運営会社はどこか？

まず会社そのものの情報です。

「Incorporated」という表記から米国法人と誤解されることがありますが、本社機能と開発の中心はストックホルムにあります。シリーズCの公式発表では、採用の中心地としてストックホルムを挙げ、そこから4都市へ拠点を広げる計画が示されています。欧州発のプロダクトである点は、後述するデータの保存先の確認に関わってきます。

創業者は誰で、何を作ってきた人なのか？

審査で創業者の経歴が問われる場面は多くありませんが、Lovableの場合はプロダクトの成り立ちを説明するのに創業者の来歴が最短経路になります。「AIブームに乗って作られたツール」なのか「以前から積み上げてきた技術の商用化」なのかで、事業継続性の評価が変わるためです。

Anton Osika氏は2023年、大規模言語モデルを使ってソフトウェアを生成するオープンソースプロジェクト「GPT Engineer」を公開しました。このリポジトリは2023年4月29日に作成され、2026年9月2日時点で55,000を超えるスターを集めています（MITライセンス。現在はアーカイブ済みで、説明文に「Precursor to: lovable.dev」と明記されています）。Osika氏はFabian Hedin氏とともに商用版「GPT Engineer App」を開発し、これを一般向けに再構築したものが現在のLovableです。両氏は2025年に、スウェーデン王立工科大学のKTH Innovationによるアワードを受けています。

つまりLovableは新規に企画されたSaaSではなく、オープンソースとして検証された仕組みを製品化したものです。私たちが稟議資料で技術的な裏づけを書くとき、この経緯を1行入れています。「生成AIの流行に合わせて出てきたツール」という前提で審査されると、事業継続性の評価が実態より低く出るためです。

いつ創業され、どのようにいまの形になったのか？

時系列で見ると、製品としての歴史はまだ2年に届きません。この短さは審査上のリスク要因になりますが、同時に成長速度の根拠にもなります。両方を並べて出すのが実務的です。

注目すべきは、13か月で評価額が18億ドルから133億ドルへ、約7.4倍になっている点です。シリーズAの公式発表では「欧州で最大級のシリーズA投資のひとつ」と述べられており、この時点から調達規模が一段ずつ上がり続けています。私たちが稟議で成長率に触れるときは、評価額ではなく後述の利用規模を使っています。評価額は投資家の期待値であり、審査担当者に対する説明材料にはなりにくいためです。

資金調達はどこまで進んでいるのか？

ここが審査で最も重視される項目です。「来年サービスが止まらないか」という問いに答えるには、調達額と投資家の顔ぶれを具体的に示す必要があります。金額だけでなく、誰が出しているかを併記してください。事業会社の投資部門が入っているかどうかで、継続性の評価が変わります。

シリーズAでは上記に加えて複数のエンジェル投資家が参加していますが、個人名は公式発表では開示されていません。累計の調達額は9.3億ドルを超えます。TechCrunchによれば、シリーズCは12社以上の投資家が参加しています。

投資家の顔ぶれは、審査でどう使えるか？

Lovableの株主には、財務投資家に加えて事業会社の投資部門が並んでいます。シリーズBの公式発表およびシリーズCの公式発表に記載されている投資家のうち、SaaS・インフラ事業者は次のとおりです。

• HubSpot Ventures（HubSpotのコーポレートベンチャーキャピタル）
• Salesforce Ventures
• NVentures（NVIDIAのベンチャー投資部門）
• Databricks Ventures（Databricksのベンチャー投資部門）
• Atlassian Ventures
• Tencent、World Innovation Lab（シリーズCで参加）

審査シートで使えるのは「事業上の接点を持つSaaS事業者が複数、資本参加している」という事実です。とくにHubSpot Venturesが入っている点は、CRMとの連携を前提に導入を検討する企業にとって実務的な意味を持ちます。LovableとHubSpotの連携で具体的な接続方式を整理していますが、資本関係があることは連携の永続性を保証するものではありません。資本の話と技術仕様の話は、審査シートでは別欄に書いてください。混ぜて書くと、根拠のない安心材料として扱われます。

どれくらい使われているのか？

事業継続性を評価するとき、調達額と並んで見るのが利用規模です。資金は投資家の判断ですが、利用規模は市場の判断だからです。公式発表の数字を、時点とセットで整理します。

Fortune 500の約67%という数字の読み方には注意が必要です。これは全社導入の比率ではなく、社内の誰かがアカウントを作っている企業の比率です。私たちが日本企業を支援する場面で最初に直面するのも、まさにこの状態——情報システム部門が把握していない個人利用が先に始まっているという状況です。この数字は「大企業で使われている実績」としてよりも、「統制を設計しないと個人利用が先行する」という証拠として稟議に載せるほうが実態に合います。全社展開の設計で、この順序を前提とした進め方を整理しています。

なお従業員数について、公式には現在の人数が開示されていません。シリーズCの発表では「今年中に約450名」という採用目標が示されており、機械学習・プロダクト・インフラ・セキュリティを強化領域として挙げています。

事業継続性はどう評価すべきか？

創業から3年、製品としては2年に届かない企業です。調達額と成長率は極めて高い一方で、長期の実績はありません。この両面を踏まえたうえで、審査で実際に効く確認事項は次の3つに絞られます。

1つ目は、成果物を自社側に持ち出せるかどうかです。Lovableは生成したコードをGitHubへ同期できるため、サービスが停止しても手元にコードが残ります。事業継続性の懸念に対して、契約や財務ではなく成果物の可搬性で答えられるのは、この種のツールの利点です。ただし「コードがある」ことと「動く状態を引き継げる」ことは別なので、確認は実際にリポジトリを作って同期するところまで行ってください。

2つ目は、第三者認証の状況です。シリーズCの公式発表では、AIエージェント向けの業界標準として位置づけられている「AIUC-1」の認証取得が示されています。あわせてLovableのセキュリティページには「LovableはSOC 2およびGDPRの要件をサポートし、エンタープライズの審査向けにセキュリティドキュメントとデータ保護契約を提供する」と記載され、AIによるペネトレーションテスト機能の説明では「SOC 2、ISO 27001、投資家デューデリジェンス向けの監査対応レポートを取得できる」と書かれています。ここで注意すべきは「要件をサポートする」という書き方であり、認証を取得済みであると断定していない点です。審査で認証書の提出を求められる場合は、この文言のまま転記せず、データ保護契約とあわせて個別に確認してください。

3つ目は、データの保存先とリージョンです。欧州発のサービスであり、バックエンドの構成によって保存先が変わります。セキュリティページには「Lovable Cloudは EU・米国・アジア太平洋のリージョンでのデータホスティングに対応し、顧客データは選択したリージョンに留まり、既定ではリージョンをまたいで移動しない」と記載されています。この選択は後から変更しにくいため、最初のアプリを作る前に決めるべき項目です。個人データを扱う場合は個人情報保護法の越境移転規制の確認対象になり、同委員会の法令・ガイドラインのページで移転先国の確認義務の範囲を確認できます。

日本法人はあるのか？日本語のサポート窓口はどこか？

2026年9月時点で、Lovableの日本法人の存在は公開情報から確認できません。公式ドキュメントとサポートは英語が基本です。

この状態で日本企業が直面するのは、技術的な問題ではなく調達と定着の問題です。海外サービスとの直接契約はクレジットカード決済が前提になりやすく、日本円・請求書払い・年間契約を求める購買プロセスと噛み合いません。私たちが支援している案件で最も多く止まるのはここで、技術審査ではなく支払いの形が理由です。日本円・請求書払いでの契約方法で、実際の進め方を整理しています。

株式会社100は、Lovableの日本初の公式パートナーとして認定されています（2026年6月時点で日本唯一）。導入から社内定着までを日本語で支援し、調達面でも日本円・請求書払い・年間契約に対応しています。

ベンダー審査シートを埋めるための情報一覧

実際の審査シートで求められる項目に、ここまでの内容を対応させます。空欄になりやすい欄と、その埋め方を並べました。「不明」と書くよりも「公開情報から確認できず」と書くほうが、審査の差し戻しが減ります。確認したが情報がない、という事実自体が審査の材料になるためです。

最後の行は必ず記載してください。審査担当者は独自に検索します。こちらから出していない情報が後から出てくると、審査は最初からやり直しになります。詳細はセキュリティとRLS設定にまとめています。

急成長中の若い企業を選ぶことの、メリットとデメリット

公平に整理します。私たちはLovableの公式パートナーですが、企業属性の観点で見た場合に不利な点も実在します。

審査の結論を「企業属性」で出そうとすると、この表はどちらにも読めます。私たちが実務で採る順序は逆で、まず成果物の可搬性とデータ範囲の設計を固め、企業属性は「その設計が崩れたときに何が残るか」の確認に使います。この順序にすると、企業の若さは決定的な障害になりません。

よくある質問（FAQ）

Q. Lovableの読み方は「ラバブル」で合っていますか？
はい。英語の「lovable（愛すべき）」がそのまま社名・製品名です。日本語では「ラバブル」と表記されます。ただし国内には同じ読みの上場企業（ラバブルマーケティンググループ）があるため、社内文書では英語表記の併記を推奨します。。

Q. 日本法人がないと、契約や請求で問題は起きませんか？
契約自体は可能ですが、日本円・請求書払い・年間契約を求める場合は標準の申し込み画面では完結しません。公式パートナー経由での調達か、社内の購買プロセス側の例外処理が必要になります。

Q. データはどこの国に保存されますか？
Lovable Cloudを使う場合、公式のセキュリティページではEU・米国・アジア太平洋のリージョンが選択でき、既定ではリージョンをまたいで移動しないと記載されています。自社で用意したバックエンドを接続する場合は、その保存先に従います。いずれも後から変更しにくいため、最初のアプリを作る前に確定させてください。

Q. サービスが終了したら、作ったアプリはどうなりますか？
ソースコードをGitHubに同期していれば、コードは自社に残ります。ただし動作環境（データベース・認証・ホスティング）の再構築は自社の作業になります。「コードが残る」ことと「すぐ動く」ことは別なので、重要なアプリでは同期の実地確認を済ませておいてください。

Q. 「創業3年の会社は社内審査を通らない」と言われました。どう反論すればよいですか？
企業年数で反論しないほうが早く進みます。審査の実質的な懸念は「使えなくなったときに困る」ことなので、コードの可搬性・データの持ち出し可否・代替手段の3点で答えてください。企業年数を争点にすると、比較対象の企業年数の話に終始して結論が出ません。

まとめ：企業属性より先に、成果物の可搬性を確認する

Lovableの運営会社はLovable Labs Incorporated、本社はスウェーデン・ストックホルム、2023年創業の未上場企業です。2026年8月にシリーズCで4億ドルを調達し、評価額は133億ドル。株主にはHubSpot VenturesやSalesforce Venturesといった事業会社の投資部門が並びます。日本法人はなく、日本語での窓口は公式パートナー経由になります。

審査シートを埋めるうえで押さえるべきは、次の3点です。第一に、日本語の「ラバブル」検索で出てくる上場企業（9254）は別会社であり、混同するとIR資料を取り違えます。第二に、企業年数を争点にしても結論が出ないため、成果物の可搬性で継続性を評価します。第三に、CVE-2025-48757の存在は自分から開示しておくほうが審査は速く進みます。

株式会社100は、Lovableの日本初の公式パートナーとして、この審査シートの作成から導入・定着までを日本語で支援しています。審査で止まっている項目があれば、Lovable導入支援からご相談ください。あわせてLovableとは何かで製品そのものの全体像を、料金とクレジットの仕組みで費用の見積もり方を確認いただけます。