「業務改善のためにシステムを作りたい」と開発会社に相談したら、返ってきた見積は 300〜1,500 万円。想定していた予算を大きく超え、稟議書の作成で手が止まっていませんか。
一方で、SaaS・パッケージ・ノーコード・スプレッドシート＋自動化といった「既製ツール」の存在は知っています。「本当に開発する必要があるのか」「もっと安く済む方法があるのでは」という直感はある。けれど、判断軸を持たないため経営層に説明できず、ベンダーの「作りましょう」に押し切られそうになっている、そんな状況ではないでしょうか。
システム化の意思決定は、本来「作るか作らないか」から始まるべきです。ところが多くの現場では、いきなり「どう作るか」の議論に入ってしまい、既製ツールで十分だった業務にまで開発予算をかけてしまうケースが少なくありません。
本記事では、「作らない」を最初に検討するための5段階チェックフロー、既製ツールで済ませられる7条件、逆に「作る」を選ぶべき7つのシグナル、失敗しないための注意点、そして稟議テンプレートまでを一気通貫で解説します。読了後には、自社の業務を「作らないで済む業務」と「作るべき業務」に切り分けでき、経営層に説明できる状態を目指します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
なぜ「作らない選択肢」を最初に検討すべきか
システム化の相談をベンダーにすると、多くの場合「開発ありき」で話が進みます。そこには構造的な理由があります。「作らない」を先に検討することは、単なるコスト削減ではなく、意思決定の主導権を発注側に取り戻す行為です。
「作りましょう」に流される3つの構造的バイアス
第一に、ベンダーの提案動機です。受託開発を主業とする会社は、既製ツールを勧めても売上になりません。当然「まずは要件を伺い、御社に最適なシステムを提案します」という受託前提の入口になります。悪意ではなく、事業構造上そうならざるを得ません。
第二に、業務要件の言語化不足です。現場からの改善要望は「今の入力が面倒」「Excel の管理が限界」といった漠然としたものが多く、要件として書き起こされていません。要件が固まらないまま議論を進めると、「では作りながら固めましょう」という開発前提の流れに乗りやすくなります。
第三に、既製ツールの選択肢を発注側が知らないことです。SaaS の名前はいくつか思いつくが、パッケージ・ノーコード・OSS・スプレッドシート＋自動化ツールまで含めた選択肢マップを持っている担当者は多くありません。選択肢を知らなければ、比較検討そのものが成り立ちません。
「作らない」判断が生む3つのメリット
「作らない」が成立すれば、3つのメリットが得られます。1つ目はコスト削減で、開発費 300〜1,500 万円が SaaS の月額数万円で済むケースがあります。中小企業庁の中小企業白書でも、中小企業の IT 投資は投資規模の制約が大きいことが繰り返し指摘されており、既製ツール活用は現実的な選択肢です。
2つ目は導入スピードで、開発 6〜12 ヶ月に対して SaaS は数週間で稼働できます。業務改善の効果を早く享受できる分、機会損失も小さくなります。
3つ目は保守負担の外部化です。自社開発したシステムは、バージョンアップ・セキュリティパッチ・障害対応を自社で抱えます。既製ツールならベンダー側が対応するため、社内に保守要員を置く必要がありません。
本記事のスコープ
以降の章では、「作らない」を成立させる7カテゴリの選択肢を俯瞰し、5段階のチェックフローで「作らないで済むか」を段階的に判定する手順を示します。あわせて、「作らない」で十分と判断できる業務の7条件と、「作る」を選ぶべき7シグナルを対称的に提示し、中立的な意思決定を支援します。最後に、社内稟議を通すためのテンプレートまで示します。
「作らない選択肢」の7カテゴリー全体像
「作らない」を成立させる既製ツールは、SaaS だけではありません。ここでは7つのカテゴリを俯瞰し、それぞれの得意領域と概算費用感を整理します。
カテゴリ1｜SaaS（クラウドサービス）
会計・勤怠・給与・CRM・SFA・ヘルプデスクなど、業界を問わず必要となる汎用業務を対象としたクラウドサービスです。ユーザー単位の月額課金（月額 1,000〜3,000 円／ユーザーが目安）が中心で、初期費用は無償〜数十万円に収まるケースが多くあります。バックオフィス業務・情報共有系の業務は、まず SaaS で足りるかを検討するのが定石です。詳細は 業務システムのSaaS型 vs 受託開発型を徹底比較 を参照してください。
カテゴリ2｜パッケージソフト
業界特化型（建設・運送・医療・卸売など）のパッケージソフトは、その業界の標準業務プロセスを前提として作り込まれています。オンプレ／ライセンス型が中心で、買い切りまたは年間保守契約となります。初期 100〜500 万円が目安です。業界標準に近い業務なら、SaaS よりもフィット率が高いケースがあります。詳細は パッケージ開発とは？メリット・デメリット、スクラッチ開発との違い を参照してください。
カテゴリ3｜ノーコード・ローコードプラットフォーム
kintone・Bubble・Airtable・Microsoft Power Apps などのプラットフォーム上で、コードを書かずに業務アプリを構築できます。SaaS では対応しきれない自社固有の業務フロー、けれど本格開発するほどではない領域に向きます。月額 数千〜数万円／ユーザーが目安です。
カテゴリ4｜OSS（オープンソース）
プリザンター・Redmine・Odoo など、オープンソースの業務システムを自社サーバー上で運用する選択肢です。ライセンス費用は無料ですが、サーバー運用・アップデート・カスタマイズには技術リソースが必要になります。社内に一定の IT 人員がいる場合の選択肢です。
カテゴリ5｜スプレッドシート＋自動化ツール
Excel・Google Sheets を業務データの器として使い、Zapier・Make・Power Automate で SaaS 間の連携やメール送信・通知を自動化する構成です。月額 数千〜数万円で構築でき、業務要件が固まりきっていない探索フェーズや、3〜6 ヶ月の暫定運用に向きます。
カテゴリ6｜AI・汎用ツール
ChatGPT・Notion AI・Zapier AI などの汎用 AI・生産性ツールで、文書要約・メール下書き・データ整形・カテゴリ分類などが代替できるケースが増えています。従来「情報整理のためのシステムを作りたい」と考えていた業務が、AI で十分になるケースもあります。
カテゴリ7｜既存業務システムの機能拡張
すでに導入済みの会計・販売管理・グループウェアなどが、実は使っていない機能を多く抱えていることは珍しくありません。オプションモジュールの追加や、標準機能の再活用によって、新規開発せずに要件を満たせるケースがあります。まず現状のライセンス範囲で何ができるかを棚卸しすることをおすすめします。
「作らない」を選ぶ5段階チェックフロー
7カテゴリを把握したら、次は業務要件に対して「作らない」で済むかを段階的にチェックします。上位ステップで解決すればそこで検討を止める、優先順位付きのウォーターフォールです。
ステップ1｜業務要件を「標準的か／固有か」で分類する
最初のステップは、対象業務が「他社と同じような標準業務」なのか「自社固有の独自プロセス」なのかを分類することです。会計・勤怠・給与・請求書発行といった法定業務、および CRM・SFA・タスク管理・グループウェアといった共通業務は、標準業務側に分類されます。この時点で標準業務に分類できれば、ステップ2の SaaS 検討に進みます。
自社固有の受注方式・独自の生産管理・複雑な承認フローなど「他社と同じにはできない」業務は、固有業務としてステップ3以降で検討します。
なお、すでに SaaS を導入したものの「使いこなせず形骸化している」状態の読者は、業務独自性のスコアリングから見直す 業務効率化ツールの選び方｜SaaSと受託開発を業務独自性で判断 の枠組みが有用です。
ステップ2｜SaaS で類似機能が提供されているか
標準業務に分類された場合、まず既存 SaaS を Fit&Gap の観点で調査します。具体的には「業務要件を10〜20項目のチェックリストに分解する→候補 SaaS 2〜3 製品を選ぶ→各項目の対応可否を『◯／△（設定で対応）／×』で評価する」の順で進めます。
判定の目安は、業務要件の80%以上が◯で、△部分が業務側の運用調整で吸収できるなら SaaS で十分です。残り20%のために開発を上乗せするより、業務側を SaaS の標準機能に寄せる方が、TCO（総保有コスト）は劇的に下がります。
ステップ3｜カスタマイズ可能なパッケージ／ハイブリッド SaaS で対応可能か
SaaS だけではフィット率が届かない場合、次に検討するのが「カスタマイズ可能なパッケージ」または「ハイブリッド SaaS（標準機能＋カスタマイズ枠）」です。業界特化型パッケージは、その業界の標準業務を作り込んでいるため、汎用 SaaS より初期フィット率が高いケースがあります。
ただし、この段階で「カスタマイズ費用が積み上がる」リスクが発生します。カスタマイズ見積が初期パッケージ費用の50%を超えたら、後述する失敗パターンが起きやすいシグナルと捉え、次のステップまたは開発検討に進む判断が必要です。
ステップ4｜ノーコード／OSS で組み上げられる範囲か
パッケージでも足りない、あるいは業務プロセスが自社固有の場合、ノーコード・ローコードプラットフォームまたは OSS の組み上げを検討します。ノーコードは業務担当者に近い人でも構築・改変ができる利点があります。OSS は柔軟性は高いが運用ノウハウが必要です。
判定の目安は、「1〜2 週間の PoC で主要機能が動くか」を確認できることです。動かないなら、そのカテゴリでは対応困難と判断します。
ステップ5｜スプレッドシート＋自動化ツールで暫定運用できるか
ここまでのすべてで対応が難しくても、すぐに開発検討へ進む前にもう一段の確認があります。それが「スプレッドシート＋自動化ツールで3〜6 ヶ月の暫定運用ができないか」です。
暫定運用の狙いは2つあります。1つは、その期間で本当の業務要件が固まる（実際に運用してみると当初の要件が変わる）ことです。もう1つは、暫定運用中に業務そのものが不要になったり、他部門との統合が発生したりして、開発対象が変わる可能性を織り込めることです。3〜6 ヶ月間の暫定運用のコストは、開発費用に比べて圧倒的に小さく、要件の精度を上げる投資として意味を持ちます。
5段階すべてで不適だった場合
5段階すべてで既製ツールが不適だと判断された場合、初めて開発検討へ移行します。この段階に来た時点で、「なぜ既製ツールで足りないのか」の根拠が5段階分蓄積されており、稟議書に説得力のある形で書き込めます。開発方式の選定（フルスクラッチ／ハイブリッド）は、業務システムのSaaS型 vs 受託開発型を徹底比較 や パッケージ開発とは？メリット・デメリット、スクラッチ開発との違い を参考にしてください。
「作らない」で十分な業務の7条件
5段階チェックフローがプロセス視点だとすれば、この章で示すのは業務特性視点のチェックリストです。以下の7条件のうち5つ以上に該当する業務は、「作らない」で十分と判断してよい目安になります。
条件1｜業務が業界標準に近い
会計・勤怠・給与・請求書発行・年末調整といった法定業務、および CRM・SFA・グループウェア・タスク管理といった共通業務は、業界標準に近い業務の典型です。標準業務は、SaaS ベンダーが最も投資している領域でもあり、機能・信頼性ともに自社開発を上回るケースが多くあります。
条件2｜例外処理が業務全体の 10% 未満
「基本パターンは決まっているが、時々イレギュラー処理が発生する」業務は、SaaS の標準機能＋業務側での手作業補完で十分回せます。例外処理を全て自動化しようとすると開発費が膨らみますが、10%未満なら人手で吸収する方が費用対効果は高くなります。
条件3｜業務ボリュームが SaaS 月額の損益分岐点を下回る
業務ボリュームが少ないほど、SaaS の従量課金は開発費に対して圧倒的に有利になります。例えば、1ユーザー月額 2,000 円の SaaS を10人で使う場合、年間 24 万円で済みます。開発費 500 万円との差は約 20 年分です。
条件4｜業務が競争優位の源泉ではない
バックオフィス業務・情報共有系業務・法定業務など、他社と差別化する必要がない領域は、標準化・外部化するほうが合理的です。差別化すべきは、顧客体験・独自の商品開発プロセスなど、自社の競争優位を生む業務です。
条件5｜業務ルールの変更頻度が年数回以下
業務ルールの変更頻度が高い業務は、SaaS の設定変更で追随できる範囲を超えるとメンテナンス負担が発生します。逆に、変更が年数回程度に収まる業務は、SaaS の標準機能・設定変更で十分吸収できます。
条件6｜3年以内に業務そのものが変わる可能性がある
M&A・組織改編・事業戦略の変更などで、3年以内に業務そのものが変わる可能性があるなら、開発投資はリスクが高くなります。SaaS の月額契約または暫定運用（スプレッドシート＋自動化ツール）で対応し、業務が定着してから本格投資を検討する順序が安全です。
条件7｜社内に開発・保守を担える人員がいない
システムは作って終わりではなく、5〜10 年の運用・保守が続きます。社内に開発・保守を担える人員がいない状態で自社開発すると、稼働後の維持がベンダー丸投げになり、保守費用が積み上がります。既製ツールならベンダー側が保守を担うため、この負担が発生しません。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
逆に「作る」を選ぶべき7つのシグナル
「作らない」が中立的な判断であることを担保するために、逆側のチェックリストも提示します。以下のシグナルが2つ以上該当する業務は、既製ツールで無理をせず開発検討を進めるべきです。
シグナル1｜業務プロセスが競争優位の源泉
独自の受注方式・独自の生産管理・独自の顧客体験など、業務プロセス自体が競争優位を生んでいる業務は、既製ツールに寄せるほど競争力を失います。この場合は、開発による作り込みが正当化されます。
シグナル2｜既製ツールでは対応不可能な業界規制
医療・金融・建設・製薬などの業界には、既製ツールでは対応しきれない固有の規制・帳票要件・監査要件があります。規制対応そのものが業務要件の中核なら、開発は避けられません。
シグナル3｜大量データ処理／高頻度リアルタイム要件
数百万件のトランザクションを秒単位で処理するような業務、あるいはリアルタイム性が業務の本質となる業務は、汎用 SaaS の性能・アーキテクチャの制約を超えるケースがあります。この場合、性能設計を含めた開発が必要です。
シグナル4｜既存システムとの複雑な連携
基幹システム・生産設備・IoT センサー・独自プロトコルの外部システムとの連携が業務の中核にある場合、SaaS の標準 API では対応しきれないケースがあります。連携部分だけでも開発が必要になります。
シグナル5｜業務ボリュームが SaaS 月額の損益分岐点を超える
条件3の逆側です。1ユーザー月額 1 万円の SaaS を100人で使うと、年間 1,200 万円。5年で 6,000 万円になります。この規模になれば、開発費 3,000〜5,000 万円と比較しても開発が優位になるケースがあります。
シグナル6｜長期運用（5年以上）が確定している
業務が長期にわたって安定的に続くと確定している場合、開発費を減価償却する期間が長くなり、投資回収が現実的になります。SaaS のランニングコストが5年で開発費を上回るかを試算するのが目安です。
シグナル7｜現場が SaaS 側の運用制約を許容できない
「この帳票レイアウトは絶対に変えられない」「この画面遷移でなければ現場が使えない」といった、既製ツールの UI・帳票の制約を許容できない現場事情がある場合、SaaS を導入しても定着せず形骸化します。この場合、開発した方が結果的にコストパフォーマンスが高くなります。
「作らない」失敗パターンと回避策
「作らない」判断そのものは正しくても、その後の運用で失敗するケースがあります。ここでは、既製ツールカテゴリ別に4つの失敗パターンを整理し、それぞれの回避策を示します。
失敗1｜SaaS 導入後に Excel 二重入力が残る
SaaS を導入したものの、現場が「使いにくい」と感じて Excel の並行管理を続け、結果として二重入力が発生するパターンです。原因は、SaaS 選定時に現場ユーザーを巻き込まず、機能比較だけで決めてしまうことにあります。
回避策は、選定段階で現場ユーザーを2〜3人巻き込み、実際の業務データで1〜2週間の PoC を実施することです。「使いにくい」の中身を PoC で洗い出し、設定・運用ルールで解決するか、別 SaaS に切り替える判断を早期に行います。
失敗2｜パッケージのカスタマイズ料金が積み上がりスクラッチ超え
「パッケージなら安い」と考えて導入したものの、業務に合わせたカスタマイズを重ねた結果、総費用がスクラッチ開発を超えるパターンです。原因は、カスタマイズの上限を事前に決めていないことです。
回避策は、契約時点で「カスタマイズ費用が初期パッケージ費用の50%を超えたら、開発方式を再検討する」というトリガーを設定することです。トリガーを超えた時点で、ハイブリッド SaaS またはスクラッチ開発への切り替えを冷静に判断できるようになります。
失敗3｜OSS 選定後に運用ノウハウがなく塩漬け化
コストゼロに惹かれて OSS を選定したものの、運用・アップデート・障害対応のノウハウが社内になく、バージョンが古いまま塩漬けになるパターンです。セキュリティリスクの温床になります。
回避策は、OSS を選定する時点で「運用保守を担う体制」（社内担当者または保守委託ベンダー）を明確にすることです。運用体制が確保できないなら、OSS 版ではなく商用サポート付きのエディションを選ぶ、または SaaS に戻す判断が必要です。
失敗4｜ノーコード内製で属人化・退職リスクが加速
ノーコードで業務担当者が自ら業務アプリを構築した結果、その担当者に運用が属人化し、退職時にブラックボックスになるパターンです。原因は、内製が個人プロジェクト化してしまうことです。
回避策は、ノーコード内製にも開発ドキュメント（構築者・目的・データ構造・改変履歴）を残すこと、そして「1人体制」ではなく「作った人＋レビュー担当」の2人体制を敷くことです。
「作らない」判断を社内で通す稟議テンプレート
ここまでの検討結果を、社内稟議として通すためのテンプレートを提示します。以下の4項目を稟議書に盛り込めば、経営層が判断に必要な情報が揃います。
検討した既製ツール一覧
5段階チェックフローの実施結果を、以下の表形式でまとめます。
ステップ | 検討カテゴリ | 検討した具体名 | 判定 | 判定理由 |
|---|---|---|---|---|
ステップ2 | SaaS | 製品A・B・C | 不適 | Fit率60%で不足機能◯◯が業務側で吸収困難 |
ステップ3 | パッケージ | 製品D | 不適 | カスタマイズ見積が初期費用の80%に達し費用対効果が悪化 |
ステップ4 | ノーコード | 製品E | 適 | PoCで主要機能◯◯・△△が動作、月額 20 万円で対応可能 |
ステップ5 | 暫定運用 | — | 未検討 | ステップ4で確定のため未検討 |
この表があると、経営層は「なぜその選択肢に至ったか」を1枚で理解できます。
「作らない」で得られるコスト削減試算
初期費用＋5年 TCO（総保有コスト）で、開発案と既製ツール案を比較します。
項目 | 開発案 | 既製ツール案 |
|---|---|---|
初期費用 | 800 万円 | 30 万円 |
年間ランニング（保守／ライセンス） | 120 万円 | 240 万円 |
5年 TCO | 1,400 万円 | 1,230 万円 |
導入期間 | 8 ヶ月 | 6 週間 |
TCO で若干の差でも、導入期間の6 週間 vs 8 ヶ月という時間軸の差は業務改善効果に直結します。この効果まで含めた判断が重要です。
「作らない」で残る運用課題と回避策
失敗パターンの章で示した4つのリスクのうち、選択した既製ツールに該当するリスクを列挙し、事前の回避策を明記します。
例:
- リスク: SaaS 導入後の Excel 二重入力
- 回避策: 現場ユーザー3名を巻き込んだ2週間 PoC を実施し、運用ルールを PoC 期間中に確定させる
これによって「作らない後のリスクは把握済みで、対策も準備している」と経営層に説明できます。
3年後の見直しトリガー設定
「作らない」判断は永続ではなく、業務ボリュームの拡大や業務要件の変化で「作る」に転換するタイミングが来ることがあります。稟議書には、あらかじめ見直しトリガーを明記しておきます。
例:
- 月間トランザクション件数が現在の3倍を超えた場合
- SaaS の年間費用が初期開発費用の30%を超えた場合
- 現場の運用制約（Excel 補完・手作業）が業務全体の20%を超えた場合
トリガーを明記しておくと、経営層は「今回の判断は暫定的で、事業成長に合わせて見直す仕組みがある」と理解でき、稟議が通りやすくなります。
まとめ｜「作らない」を先に考える意思決定文化を作る
システム化の意思決定は、「どう作るか」ではなく「そもそも作るか、作らないか」から始めるべきです。作らないで済ませられる業務にまで開発予算を投じるのは、コスト・スピード・保守負担のすべてで機会損失を生みます。
本記事で示した流れをまとめると、次の通りです。
- 「作らない選択肢」の7カテゴリ（SaaS／パッケージ／ノーコード／OSS／スプレッドシート＋自動化／AI・汎用ツール／既存システム拡張）で選択肢マップを持つ
- 5段階チェックフローで、上位ステップから順に「作らないで済むか」を判定する
- 「作らない」で十分な7条件と、「作る」を選ぶべき7シグナルを対称的に照らし合わせて中立的に判断する
- 選んだ既製ツールカテゴリに固有の失敗パターンを把握し、事前に回避策を仕込む
- 稟議テンプレートで、経営層に判断根拠と見直しトリガーを提示する
次のアクションとして、まずは自社の主要業務3つに対して、5段階チェックフローを適用してみてください。すべてのステップで「作らないで済む」と判定される業務が1つでも見つかれば、そこから稟議書の記述を始められます。「作る」しかないと判断された業務についても、5段階分の検討記録が残るため、開発予算を経営層に説明する根拠として活用できます。
「作らない」を先に検討する意思決定文化は、一度作れば今後のシステム化検討全般に適用できます。目の前の1件だけでなく、組織の意思決定プロセスそのものへの投資として、本記事の枠組みをご活用ください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 「作らない」で十分な7条件と「作る」を選ぶべき7シグナルの両方に当てはまる場合はどう判断すればいいですか？
その場合はシグナル側を優先してください。競争優位や業界規制など事業リスクに直結する要素は、コスト効率の良さだけでは覆せないため、シグナルに1つでも強く該当するなら開発検討に進むのが安全です。
- 「作らない」判断が社内稟議で却下された場合はどうすればいいですか？
却下理由が機能不足なら5段階チェックフローの記録をもとにFit&Gap資料を補強し、コスト懸念ならTCO試算と見直しトリガーを提示して再提出してください。それでも通らなければ開発検討に移行して問題ありません。
- すでにベンダーとの商談が進んでいる場合、途中から「作らない」に方向転換できますか？
契約前であれば方向転換は可能です。5段階チェックフローの結果をベンダーに共有し、既製ツールでは対応できなかった残り部分だけを開発範囲として再見積を依頼するのが実務的な進め方です。
- ノーコードで暫定構築した後、要件が膨らんで対応しきれなくなったらどうすればいいですか？
条件6（業務変化の可能性）と条件7（保守人員の有無）を再チェックし、いずれかに該当しなくなった時点が開発検討へ切り替えるサインです。ノーコードで蓄積した業務要件やデータ構造は、そのまま開発の要件定義に転用できます。
- SaaS選定時のFit&Gapチェックリストは誰が作成すればいいですか？
現場の実務担当者と情シス・経営企画担当者が共同で作成してください。現場だけでは網羅性が、企画側だけでは実運用の細部が抜けやすいため、両者ですり合わせてから候補SaaSに照合するのが確実です。
