業法違反は「あとで直せばいい」では済まない
士業や医療職の方がサービスを外注する場面で、開発会社との打ち合わせが「機能」「デザイン」「納期」の話に終始し、業法の話が一切出ないまま契約に進むことがあります。開発会社はソフトウェアのプロであって、税理士法や医師法、薬機法のプロではありません。だから、業法に触れる設計になっていても、開発会社側から「これは大丈夫ですか」と聞いてくれるとは限らないのです。
ここが、通常のバグや仕様変更と決定的に違うところです。UIの色を変えたり、ボタンの位置を直したりするのは、公開後でも数時間で対応できます。しかし業法に抵触する設計は、コードの書き換えでは直りません。機能そのものを削る、提供方法を作り直す、場合によってはサービスの前提を根本から見直す必要が出てきます。開発が進めば進むほど、その手戻りのコストは大きくなります。
後回しにするとどうなるか
典型的なパターンは、次のような流れで起きます。
- アイデア段階では「専門知識をアプリで提供する」という発想だけがあり、業法の確認をしていない
- 開発会社に相談し、要件定義・設計・実装へと進む
- β版がほぼ完成した段階で、知人の同業者や顧問弁護士から「これは無資格者による〇〇業にあたるのでは」と指摘される
- 該当機能を削るか、提供方法を変えるしかなく、すでに投じた開発費の一部が無駄になる
特に危ういのは、AIを使った自動診断・自動アドバイス系の機能です。「AIが答えを出すだけだから、自分が直接助言しているわけではない」という理屈は、業法の世界では通用しないことがあります。診断・鑑定・アドバイスに類する行為を、資格のない主体が業として提供していると評価されれば、たとえ実行しているのがAIでも問題になり得ます。何がアウトで何がセーフかの詳しい境界線は、資格が必要な業務を、アプリ経由で提供してよいかの境界線 で扱っていますので、自分のサービス構想と照らし合わせて確認してください。
もう一つ見落とされがちなのが、業法だけでなく士業・医療職それぞれの根拠法（税理士法、弁護士法、医師法、薬機法など)が定める「業として行ってよい範囲」の解釈です。自分の専門分野なら詳しいはずだと思っていても、「対面の相談」を前提にした条文が「アプリ経由の非対面提供」にどう適用されるかは、想像以上に専門的な判断を要します。この整理は 士業・専門職がサービスを作る際に確認すべき業法上の制約 に譲りますが、少なくとも「自分は詳しいから大丈夫」という思い込みだけで進めないことが重要です。
確認すべきタイミング
業法の確認は、開発会社への相談前、遅くとも初回打ち合わせの場で済ませておくべきものです。目安は次の通りです。
| タイミング | やるべきこと |
|---|---|
| アイデアを3行メモにする段階 | 「このサービスは誰の何の資格が関わるか」を自分の言葉で書き出す |
| 開発会社に相談する前 | 顧問弁護士・所属団体（士業会、医師会等）に一度相談し、口頭でよいので見解をもらう |
| 初回打ち合わせ | 開発会社に「この機能は業法上グレーな可能性がある」と自分から伝える |
| 要件定義の確定前 | グレーな機能について、削る・変える・保留するの判断を確定させる |
ポイントは、判断そのものを開発会社に委ねないことです。開発会社は「作れるかどうか」は判断できても、「作ってよいかどうか」は判断できません。この線引きを曖昧にしたまま契約に進むと、契約書の段階で仕様変更や責任範囲の条項があいまいになりがちです。契約時に必ず押さえておきたい条項については 契約書で必ず確認したい条項（知的財産権・検収・保守） も合わせて確認しておくと、後々の認識のズレを防げます。
まとめ
業法の確認は、開発が進んでからでは手遅れになりやすい性質のものです。デザインや機能の微調整とは違い、「作り直す」ではなく「前提から見直す」規模の手戻りにつながります。だからこそ、アイデア段階から開発会社に相談するまでの間に、自分の専門分野の根拠法と業法の両方を一度洗い出しておくことが、300万円という限られた資金を無駄にしないための最初の関門になります。判断に迷う個別の論点は、それぞれのコラムで詳しく確認してください。