SaaS企業の経営者・PdMの方から最も多い反応が「うちは既存技術の組合せなので特許は無理」というものです。しかし、実際に登録されているSaaS特許を見ると、驚くほど「普通の機能」がクレームになっています。給与計算の進捗ステータスを操作画面に表示する構成（freeeの特許第7489351号）、会計データからサブスクリプション契約を検出して提示する画面制御（マネーフォワードの特許第7084373号）——いずれも近年登録された現役の権利です。本記事では、SaaSプロダクトを4つのレイヤーの機能マップに分解し、どこに出願ポイントが眠っているかを探す方法を弁理士が解説します。
この記事の要点
目次
SaaSの機能を特許の観点で棚卸しするときは、次の4レイヤーに分けると整理が進みます。
| レイヤー | 例 | 特許との相性 |
|---|---|---|
| ※相性の評価は、権利行使のしやすさ・侵害発見の容易さを踏まえた実務上の一般的な整理です。個別の技術内容によって変わります。 | ||
| ① UI・画面遷移 | ダッシュボード、ステータス表示、通知、入力補助 | ◎ 外から見える＝模倣されやすく、権利化価値が高い |
| ② API・外部連携 | 銀行API連携、他SaaS連携、データ取込み、認証連携 | ◎ システム間の境界処理は構成が具体化しやすい |
| ③ バックエンド処理 | 推定アルゴリズム、バッチ最適化、負荷分散 | △ 権利化は可能だが侵害立証が困難。秘匿との比較を |
| ④ 料金・ビジネスロジック | 課金モデル、マッチングルール、ポイント制度 | △ ルール自体は発明にならない。情報処理への翻訳が必須 |
「画面デザインは意匠、機能は特許」と思われがちですが、画面の表示制御・遷移そのものが特許のクレームに入ります。freeeの特許第7489351号（2024年5月登録）は、給与計算SaaSについて、給与計算の操作画面にステータス情報を表示し、従業員情報の変動時には対応処理の画面へ遷移するリンクを表示するという、画面表示と遷移リンクを発明特定事項とする構成で登録されています。マネーフォワードの特許第7084373号（2022年6月登録）も、会計情報からサブスクリプション型サービスを特定し、条件に該当するサービスを提示する画面の表示を制御する構成です（いずれも請求項の要旨）。
UIレイヤーの発明は「ユーザーの迷い・手戻り・見落としをどう減らすか」という課題に紐づけると発明の形になります。使えば分かる＝競合に模倣されやすいレイヤーだからこそ、権利化の価値が高いのです（守り方の考え方は特許か秘匿かの使い分け記事参照）。
マネーフォワードの特許第6366037号（アカウントアグリゲーション：電子証明書がなければログインできない金融機関サーバに、ユーザー端末とサーバが連携してログインし明細を自動取得する構成）のように、自社と外部システムの「境界」で起きる課題──認証、データ形式の変換、同期タイミング、失敗時のリトライ──は、装置間の協働として構成を書きやすく、権利化と相性の良い領域です。サーバー側だけでなくユーザー端末側の処理も権利化しておく設計論は、既存のSaaSの通信処理の特許戦略の記事で詳しく解説しています。
推定アルゴリズムやパラメータ調整などサーバー内部の処理は、特許を取っても他社の侵害を外から立証しにくいという構造的な弱点があります。出願すれば1年6か月で公開される（特許法64条）ため、「権利行使しにくい特許」と引き換えに手の内を見せる結果になりかねません。このレイヤーは営業秘密としての秘匿＋先使用権の証拠保全が第一候補で、出願するなら「出力・挙動・画面に現れる特徴」とセットでクレーム化して検知可能性を確保する工夫が要ります。
課金モデルやマッチングルールそれ自体は「人為的取決め」であり、特許法上の発明になりません。ただし、そのルールを実現するための判定処理・データ構造・画面制御として設計すれば出願対象になり得ます。境界線の詳細はビジネスモデル特許の境界線の記事を、フィンテック分野の登録実例は事例集をご覧ください。
当ブログでこれまで実ページ検証してきた日本の登録特許を、4レイヤーに配置し直した一覧です。自社の機能マップと見比べる「相場観」としてお使いください。
| レイヤー | 特許（権利者） | 何を権利化したか |
|---|---|---|
| ① UI・画面遷移 | 特許第7489351号（freee） | 給与計算の進捗ステータス表示と処理画面への遷移リンク |
| 特許第7084373号（マネーフォワード） | 会計情報からのサブスク検出と提示画面の制御 | |
| 特許第7153818号（ふくおかFG） | コンテンツ指定→目的別預金作成の画面遷移連鎖 | |
| ② API・外部連携 | 特許第6366037号（マネーフォワード） | 電子証明書ログインを要する外部サーバとの端末協働での明細取得 |
| 特許第7505101号（PayPay） | 決済情報＋商品識別子の端末からの取得と特典提供 | |
| ③ バックエンド処理 | 特許第6105799号（ウェルスナビ） | 銘柄別の数量・時価・目標比率を記憶しリバランス演算するサーバ装置 |
| 特許第6975011号（メルカリ） | 商品画像の特徴抽出→類似商品情報のマージ生成 | |
| ④ ビジネスロジック | 特許第6474089号（タイミー） | 勤務評価が条件を満たす求職者への給与前払い実行（マッチング×即時払いの情報処理化） |
③のバックエンド2件が示すとおり、内部処理でも「記憶するデータ項目と演算の構成」まで具体化すれば権利化は可能です。ただし侵害の検知しやすさでは①②に劣るため、③は出願と秘匿の比較検討（第4章）を経てからが定石です。各特許の詳細はフィンテック事例集・BM特許境界線の記事で解説しています。
SaaS同士の特許訴訟として知られるfreee対マネーフォワード事件（東京地判平成29年7月27日）では、freeeの自動仕訳特許のクレームが「キーワードと勘定科目の対応テーブルを参照する」構成に限定解釈され、機械学習ベースとされる被告製品には届きませんでした。SaaSの機能は実装方式が世代交代します。「いまの実装」だけでなく「競合が採りそうな別実装」までカバーする抽象度でクレーム階層を設計する──機能マップで出願ポイントを見つけた後は、この視点が権利の寿命を決めます（詳細は拒絶理由あるある5選の第6章）。
PdM＋エンジニア＋（可能なら）弁理士の1時間で、自社版の機能マップが作れます。
| ステップ | やること |
|---|---|
| ①機能の洗い出し（15分） | プロダクトの機能一覧（メニュー・料金表・リリースノート）から主要機能を20〜30個書き出す |
| ②4レイヤーへの仕分け（15分） | 各機能をUI／連携／バックエンド／ロジックに配置（複数レイヤーにまたがる機能はそれ自体が有望候補） |
| ③価値と露出の採点（20分） | 各機能に「事業価値（高/中/低）」と「外から見えるか（見える/見えない）」の2軸でラベル付け |
| ④優先候補の決定（10分） | 「価値・高×見える」→出願第一候補／「価値・高×見えない」→秘匿＋証拠保全の候補、として上位3つを選ぶ |
MVP期（PMF前）は、資金も工数も限られるうえ、プロダクトのピボットで発明自体が変わり得ます。この段階の定石は「①コア機能1件に絞った出願で優先日を確保し、②審査請求（3年以内）は事業の見極め後に判断する」という最小構成です。中小スタートアップ（設立10年未満等）なら審査請求料・特許料（1〜10年分）が1/3に軽減され、中小企業の区分で早期審査も利用できます（スーパー早期審査にはスタートアップの実施関連出願の要件もあります）（費用解説・流れ解説）。
グロース期（PMF後）は、模倣リスクと採用・調達の対外発信ニーズが高まる局面です。①機能マップを四半期ごとに更新して新機能をリリース前に出願候補へ、②競合の出願ウォッチを開始、③初期に出願した案件の審査請求・権利化を事業イベント（調達・大型商談）に合わせて実行──と、単発の出願からポートフォリオ運用に切り替えます。
A. 守る対象が違います。画面の見た目（GUIのデザイン）は意匠、画面遷移・表示制御の仕組みは特許です。同じ画面でも「このレイアウトの美感」を守るなら意匠、「この順で出す仕組み」を守るなら特許で、両方に価値があれば併用します。
A. 正しい懸念です。出願内容は原則1年6か月で公開されるため、「出す機能（見える側）」と「出さない技術（見えない側）」の仕分けが出願前の設計になります。仕分けの考え方は特許か秘匿かの使い分け記事で詳説しています。
A. 調べられます。J-PlatPat（特許庁の無料データベース）で出願人名から検索するのが第一歩です。ただし公開は出願から1年6か月後のため「直近1年半の出願は見えない」こと、クレームの読解には専門性が要ることから、重要な意思決定に関わる調査は専門家への依頼をおすすめします。
A. あります。機能が10個程度でも「価値が高く・外から見える」機能の特定はでき、守るべき1件を見極めるにはむしろ早い方が有利です（公開前に出願する選択肢が残っているため）。マップは四半期ごとに育てていくものと考えてください。
SaaSの機能マップ診断（初回相談）：プロダクトの機能一覧（またはサービスサイトのURL）をお送りいただければ、4レイヤーへの仕分けと出願候補の初期見解をご案内します。知財事務所エボリクスのお問い合わせフォームよりどうぞ。
この記事の監修
弁理士 杉浦健文（日本弁理士会 登録第19446号／知的財産事務所EVORIX）。IT・ソフトウェア・AI分野の特許出願を中心に扱い、AI関連発明の特許化をテーマとするセミナー講師の実績があります。記事中の特許はGoogle Patents等の実ページを確認のうえ記載しています。
【免責事項】本記事は2026年7月18日時点の公開情報（Google Patents掲載の登録特許・裁判所ウェブサイト掲載の判決等）に基づく一般的な解説であり、法的助言ではありません。記事中の特許は実ページで書誌事項を確認していますが、権利範囲の解釈を示すものではなく、掲載企業と当所の取引関係を示すものでもありません（2026年7月19日増補）。ワーク手順・優先順位の記載は実務上の一般的な整理であり、個別の判断に代わるものではありません。