個人でSaaSを運営するときの法規の壁

01なぜ調べたか

私たちは、海外のオープンソースを日本語で使えるようにして、マネージドサービス（SaaS）として提供する事業を検討していました。実際に4本のサービスのランディングページを公開し、需要を測っていました。

技術的な検討は進みました。止まったのは別のところです。「顧客の個人データを預かる」という一点で、適用される法規が一段跳ね上がることに、途中で気づきました。

そこで、一人法人がSaaSを運営する場合に何が適用されるのかを、条文とガイドラインの原文まで遡って洗い直しました。この記事はその記録です。結論を先に書くと、努力やコストで越える壁ではなく、適用される法律そのものが違うという話でした。

02壁①　「中小規模事業者」の定義から外れる

個人情報保護法は、事業者に安全管理措置（法第23条）を求めています。そして個人情報保護委員会のガイドライン（通則編）には、「中小規模事業者」という区分があり、小さい事業者向けに手当てがあります。

私たちは「従業員1人なのだから当然ここに入る」と考えていました。入れませんでした。定義そのものに除外規定があります。

（※2）「中小規模事業者」とは、従業員の数が 100 人以下の個人情報取扱事業者をいう。ただし、次に掲げる者を除く。
・その事業の用に供する個人情報データベース等を構成する個人情報によって識別される特定の個人の数の合計が過去 6 月以内のいずれかの日において 5,000 を超える者
・委託を受けて個人データを取り扱う者 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」10（別添）講ずべき安全管理措置の内容

2つ目の除外が効きます。顧客の個人データを預かって処理するSaaSは、まさに「委託を受けて個人データを取り扱う者」です。従業員が何人であっても関係ありません。

03誤解：緩和されるのは「義務」ではなく「手法の例示」

ここでもう1つ、私たちは勘違いをしていました。「中小規模事業者なら安全管理措置が軽くなる」という理解自体が誤りです。

中小規模事業者については、その他の個人情報取扱事業者と同様に、法第23条に定める安全管理措置を講じなければならないが、（中略）円滑にその義務を履行し得るような手法の例を示す 同ガイドライン 10（別添）

義務の水準は同じで、示されているのは「その義務をどうやって果たすか」の例だけです。免除でも軽減でもありません。ここを「緩和」と要約している解説は少なくありませんが、原文はそう書いていません。

04壁②　クラウド例外は、思っていたより狭い

ここで多くの人が思いつく逃げ道があります。「クラウド例外」です。事業者が個人データを取り扱わないと整理できれば、そもそも委託にも当たらない、という考え方です。

成立の条件は、大まかに①契約により事業者がサーバーに保存された個人データを取り扱わない旨が定められており ②適切にアクセス制御が行われていること。これ自体は公式のQ&Aに書かれています。

問題は、この「取り扱わない」を一人運営で本当に維持できるのかです。個人情報保護委員会は2024年3月25日に、クラウド例外が認められなかった事案の考慮要素を注意喚起として公表しています。これが実務に効きます。

ここを自分の事業に当てはめると、なかなか厳しいことになります。

大企業なら、運用担当と開発担当を分け、本番アクセスを申請制にし、ログを取ることで「アクセス制御が講じられている」を作れます。1人だと、そのすべてが同じ人です。組織を分けられないことが、そのまま法的な位置づけに跳ね返ります。

05壁③　チャットを1つ足すと電気通信事業になり得る

これは今回の調査で初めて気づいた論点です。正直に言うと、検討時にはまったく視野に入っていませんでした。

総務省の「電気通信事業参入マニュアル［追補版］」は、SaaSについてまず原則として届出は不要としています。

このサービスは、自己と他人（利用者）との間の通信を行っており、他人の通信を媒介していないことから、サービス提供者が電気通信回線設備を設置していない場合には、登録及び届出が不要な電気通信事業と判断される。 総務省「電気通信事業参入マニュアル［追補版］」（令和5年1月30日改定）「ソフトウェアのオンライン提供（SaaS、ASP）」

ところが、同じ資料に例外が書かれています。

サービスの一部としてメール、チャット、オンライン会議等の利用者間のメッセージの媒介を行う機能を提供している場合は、登録又は届出が必要な電気通信事業と判断される 総務省「電気通信事業参入マニュアル［追補版］」

これはオープンソースをSaaS化する事業にとって、他人事ではありません。プロジェクト管理、問い合わせ管理、グループウェア——この種のOSSは、ほぼ必ずユーザー間のコメント通知やダイレクトメッセージを持っています。機能を1つ有効にするかどうかの話が、事業者としての立場そのものを変え得ます。

06壁④　漏えいが起きた日から動き出す時計

個人データの漏えい等が起きた場合、個人情報保護委員会への報告義務があります。ここでも、私たちが持っていた数字が正確ではありませんでした。

よく見る「速報は3〜5日以内」は、法令の文言ではありません。条文が求めているのは「速やかに」で、3〜5日はガイドラインが示す目安です。

加えて、本人への通知義務もあります。1人で開発も運用もサポートもやっている状態で、インシデント対応を数日以内に走らせるのがどれだけ現実的か。これは法律の話であると同時に、体制の話です。

07壁⑤　買い手のチェックシートは自宅を想定していない

法令をクリアしても、次に買い手の審査があります。法人にSaaSを売ると、多くの場合セキュリティチェックシートが送られてきます。

ここに、一人法人にとって構造的に苦しい項目が入ります。物理的セキュリティ、とくに入退室管理です。IPAの「中小企業の情報セキュリティ対策ガイドライン」にも、こう書かれています。

サーバー等の設置エリアへの入退室を管理し、記録する IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」

クラウド専業（自社でサーバーを持たない）なら、「該当なし。基盤はAWS/さくら等で、その認証取得状況で代替する」と説明する余地があります。実際その説明は通ることがあります。ただしそれは、審査する側が理解してくれるかどうかに依存します。1人の会社であるという事実が、そこに影響しないとは言えません。

08お金：Pマークとサイバー保険

「じゃあ認証を取ればいい」となります。ここでも数字を確認し直したところ、2件とも書き方が間違っていました。

そしてサイバー保険。ここは私たちの書き方が明確に不適切でした。

とはいえ、保険料が業種によって大きく変わること自体は、各社の商品説明から読み取れます。言えるのはそこまでです。「◯倍」と書けるのは、条件を揃えた比較ができたときだけです。

092026年10月、買い手側の控除が一段下がる

ここは調べ直していちばん驚いたところです。当初この記事では「別途調査が必要」として触れないつもりでしたが、手元の理解が制度改正で古くなっていたことが分かったので、書きます。

免税事業者のままBtoBでSaaSを売る場合、買い手（課税事業者）は仕入税額の一定割合しか控除できません。これが経過措置です。私たちは「8割控除が2026年9月30日まで、その後2029年9月30日まで5割」と理解していました。前半は合っていて、後半が古い制度でした。

令和8年度税制改正で見直され、国税庁の資料は見出しからして「７・５・３割控除」に変わっています。

免税事業者など適格請求書発行事業者以外の者から行った課税仕入れにつき、その一定割合を控除できる経過措置について、適用期限を２年間延長した上で、以下のとおり控除可能割合が見直されました。 国税庁「令和８年度税制改正特集」

加えて、あまり紹介されていない改正がもう1つあります。控除限度額です。

一の適格請求書発行事業者以外の者からの課税仕入れの額の合計額がその年又はその事業年度で１億円（改正前：10億円）を超える場合には、その超えた部分の課税仕入れについて、本経過措置の適用を認めないこととされました。 同上（見直しは令和8年10月1日以後に開始する課税期間から適用）

10「賠償の相場」という誤解

漏えいを起こしたときの賠償額。ここにも、広く流通している誤解があります。

よく引かれるのが最高裁 平成29年10月23日判決（ベネッセの個人情報漏えい）です。「実害がなくてもプライバシー侵害が認められた判決」として紹介されます。前半は正しいのですが、これは賠償を命じた判決ではありません。

原判決を破棄する。本件を大阪高等裁判所に差し戻す。 最高裁判所 平成29年10月23日 判決 主文

差し戻された先の大阪高裁（令和元年11月20日）は、1人あたり1,000円を認容しています。ネットでよく見る「1人3,300〜35,000円」という相場観は、下限がこれよりずっと低いところにあります。

11この記事を書くまでに間違えていたこと

この記事を書くにあたって、手元の調査資料を一次ソースまで遡って検証しました。6件の誤りが出ました。すべて、記事にする前に見つかったものです。

12それでもやるなら、どう畳むか

ここまで壁ばかり書きましたが、「個人ではSaaSをやれない」と言いたいのではありません。実際、一人・二人の会社で成立している事業は日本にもあります（私たちはそれを全部調べました）。

整理すると、壁の高さは「何を預かるか」で決まります。

私たち自身の結論は、「月額でデータを預かるマネージドSaaS」を一人で始めるのは、法規の面で無理筋だったというものでした。技術的には作れます。作れることと、売れる形で運営できることは違いました。