「いま使っている〇〇は、NetSuiteとつなぐのか。NetSuiteの中で作るのか。それとも、つなぐ製品を買ってくるのか」
NetSuiteの導入が決まると、ほぼ必ず出てくる問いです。
答えは、周辺業務を「再販」「連携」「内包」の3つに分けると決まります。
再販は既製の連携をそのまま使うこと、連携は専用SaaSを残してつなぐこと、内包はNetSuiteの中に作ることです。
請求書の発行、経費精算、電子契約、勤怠、EC、決済。
周辺の業務は数十種類あり、1つずつ悩んでいると導入が止まります。
では、どの業務をどれに振り分ければよいのか。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、3つの問いを順番に当てる方法をとっています。
API・CSV・iPaaS（連携基盤）といった手段の比較ではありません。
何を作り、何を買い、何をつなぐか。それを決める話です。
この記事で分かること
- 周辺業務を3分類する判断軸と、その順番
- 「共に成長するSaaS」と「小さなSaaS」の見分け方
- 3分類それぞれで、費用と手間がどこに発生するか
- 判断の前に決めておくべき「担い手」
3つの問いを、順番に当てる
周辺業務は、次の3つの問いで分けられます。
上から順に当てはめ、最初に「はい」になったところで止めます。
| 順 | 問い | はい → 分類 |
|---|---|---|
| 1 | 公式の連携コネクタや、実績ある既製の連携があるか | 再販：既製をそのまま使う |
| 2 | 相手側の商流・審査・エコシステムが価値の源泉か。日本の法制度に密着しているか | 連携：専用SaaSを残してつなぐ |
| 3 | 単機能で、データ構造が単純で、法規制の変化が遅いか | 内包：NetSuiteの中に作る |
どれにも当てはまらない業務は、まず「連携」に置いて様子を見ます。
内包は最後の選択肢です。
作ったものには、保守が要るからです。
3分類の中身
再販：既製の連携をそのまま使う
公式のコネクタや、多くの会社が使っている連携アプリがある業務です。
ECのShopify、決済のStripe、電子契約のDocuSign、CRMのSalesforceなどが代表です。
自社で開発する理由は、ほぼありません。
既製の連携なら、相手側の仕様変更にベンダーが追従します。
自社で作れば、その追従も自社の仕事になります。
注意点は1つです。
「既製がある」と「自社の要件に合う」は別の話です。
既製の連携が扱うデータの範囲と、自社が流したいデータの範囲を、導入前に照らし合わせます。
連携：共に成長するSaaSを残してつなぐ
相手側の商流や法制度が、価値の源泉になっている業務です。
- 商流が価値：EC・決済・取引先ネットワーク型の請求書。相手側にお客様や取引先がいる
- 法制度が価値：給与・社会保険・電子帳簿保存法の保存要件。制度改正のたびにSaaS側が対応する
- 審査が価値：銀行明細の取得、ECモールのAPI。相手側の審査や契約が前提になる
NetSuiteの中に作り直しても、この価値は再現できません。
専用SaaSは、相手側と一緒に成長し続けるからです。
SaaSを残し、必要なデータだけをNetSuiteに流す設計にします。
日本での補足もあります。
NetSuiteは日本の給与計算に対応していません。
給与・勤怠・労務は国内SaaSを残し、仕訳と従業員マスタを連携する形が前提です。
日本の銀行との直接接続も標準にはなく、明細取込や入金消込は連携サービスと組み合わせます。
内包：小さなSaaSはNetSuiteの中に作る
単機能で、データ構造が単純で、法規制の変化が遅い業務です。
汎用の承認（稟議）、休暇の申請、来客や設備の予約、社内アンケート、通知などが当てはまります。
機能が1つで画面も1〜2枚、データは自社の中で完結し、ルールは数年変わらない。こうした「小さなSaaS」です。
これらは、NetSuiteの標準機能（項目・カスタムレコード・ワークフロー）の組み合わせで作れます。
作った仕組みは、会計や在庫と同じデータベースの上で動きます。
承認された申請がそのまま発注になる、といったつながりも自然に作れます。
一方で、作ったものには保守が要ります。
ルールが変われば、直す人が必要です。
内包を選ぶなら、「誰が保守するか」を先に決めます。
3分類の比較表
| 観点 | 再販 | 連携 | 内包 |
|---|---|---|---|
| 初期の手間 | 小（設定中心） | 中（連携の設計・開発） | 中〜大（仕組みを作る） |
| 継続費用 | 連携アプリの利用料 | 専用SaaS利用料＋連携の保守 | 保守の工数（ライセンス追加は原則不要） |
| 相手側の仕様変更 | ベンダーが追従 | 自社または支援先が追従 | 相手がいないため発生しない |
| データのつながり | 連携アプリの範囲内 | 流すデータを設計した範囲 | 会計・在庫と同じ基盤で完結 |
| AIとの親和性 | 連携アプリの対応次第 | 専用SaaS側のAI機能を活かせる | NetSuiteのAI連携（MCP対応）でそのまま扱える |
| 向く業務 | EC・決済・電子契約・CRM | 給与・請求書受領・銀行・モール | 承認・休暇・予約・アンケート・通知 |
| 失敗しやすい点 | 既製の範囲と要件のずれ | 設計・保守の担い手不在 | 作りすぎ・保守放置 |
連携の開発は、導入費用をいちばん動かす
分類は、導入費用にもそのまま響きます。
NetSuiteの導入費用を決める要因は4つあります。
業務の範囲、開発の量（とくに外部システムとの連携開発）、社内の体制、ユーザー数です。
ベンチャーネットが支援したNetSuite導入の費用を見てみます。
他社SaaSや顧客独自システムとの連携開発があった事例は2億円程度で、うち約7割が開発でした。
連携開発も追加の開発もなかった事例は、150万円程度です。
4つの事例の詳しい内訳は、NetSuiteの料金・費用・価格にまとめています。
「連携」に置く業務が増えるほど、この開発の量が増えていきます。
見分け方の実例
ベンチャーネットがよく相談を受ける業務で、3分類を当てた例です。
判断は会社の要件で変わるため、検討の出発点としてご覧ください。
| 業務 | 分類 | 理由 |
|---|---|---|
| 請求書の発行 | 連携（または標準） | 日本向けの締め請求は標準で足りる。WEB配信や郵送代行が要るなら発行代行SaaSと連携 |
| 請求書の受領・電帳法保存 | 連携 | 保存要件の対応はSaaS側が担う。仕訳と支払はNetSuite |
| 経費精算 | 連携（または標準） | 量が少なければ標準。領収書が多く電帳法運用を任せるなら専用SaaS |
| 対外の電子契約 | 再販・連携 | DocuSignは既製。クラウドサインなど国内サービスは連携 |
| 社内の承認（稟議） | 内包 | 単機能・データ単純。発注や経費の承認は標準のワークフローにある |
| 給与・勤怠 | 連携 | 日本の法制度に密着。NetSuiteは日本の給与に非対応 |
| EC・モール | 再販・連携 | Shopifyは既製。楽天などは受注管理SaaS経由で連携 |
| 入金消込 | 連携＋開発 | 日本の銀行と直接つながらないため、明細取込と消込のSaaSを組み合わせ、複雑な消込は開発 |
| 通知（Slack・Chatwork） | 内包 | 通知だけならNetSuite側の仕組みで完結 |
| 予約・アンケート | 内包 | 単機能。回答を顧客や案件に紐づけられる利点がある |
入金消込の「開発」の部分は、入金消込は買うより作ったほうが合うで詳しく扱っています。
判断の前に決めること：担い手と順番
連携・内包は「入れたら終わり」ではない
再販以外の2つは、保守が続きます。
連携は相手SaaSの仕様変更に追従し、内包はルール変更に合わせて直します。
設計と保守の担い手を決めずに始めると、最初の設計のまま古びていきます。
社内に担い手がいなければ、伴走を頼む前提で予算を組みます。
連携の手段を選ぶより、前に決める話です。
順番は「再販→連携→内包」
導入の順番も、3分類に沿わせます。
まず既製の連携で動くものを動かす。
次に専用SaaSとの連携を設計し、最後に内包を作ります。
内包を先に作ると、既製の連携で代わりが利くと分かっても、作ったものを捨てる判断が難しくなります。
順番と、それぞれに続く保守を図にすると、次のとおりです。
AIの登場で変わったこと
2026年に入り、外部のAIをNetSuiteにつなぐ仕組みが整いました（MCP対応のAI Connector Service）。
入力の手間を、AIに渡せるようになったのです。
内包で作った仕組みは、AIからそのまま扱えます。
一方、専用SaaSが担う承認・証跡・保存の流れは、AIで入力を楽にしても残ります。
「AIが入力できるから専用SaaSは要らない」とはならない理由は、AIに入力を任せれば専用SaaSは不要になるのかで扱っています。
つまずきやすい3つのパターン
3つのパターンと避け方を図にすると、次のとおりです。
手段の比較から始める
現象：API連携かiPaaSかCSVかを先に比べ、ツールを選んでから業務を当てはめる。
原因：「何をつなぐか」より「どうつなぐか」のほうが調べやすい。比較記事も多く、判断した気になれる。
回避策：先に3分類で「作る・買う・つなぐ」を決める。手段は、分類が決まった後で業務ごとに選ぶ。手段の比較はNetSuiteの連携方法まとめに分けています。
内包を「無料」と考える
現象：追加ライセンスが要らないため、内包を費用ゼロと見積もる。作った後の保守が予算にない。
原因：内包の費用は、ライセンスではなく工数で発生する。工数は見積書に載りにくい。
回避策：内包の候補ごとに「年に何回ルールが変わるか」「誰が直すか」を書き出す。年1回以上変わるなら、内包ではなく連携を検討する。
連携の担い手を決めずに契約する
現象：専用SaaSとNetSuiteの両方を契約したのに、間をつなぐ設計を誰も担当していない。二重入力が始まる。
原因：SaaSの契約とNetSuiteの契約は別々に進む。連携は、その間に落ちる。
回避策：「連携」に置いた業務は、契約前に設計・開発・保守の担い手を決める。社内にいなければ、支援先の範囲に含める。
ベンチャーネットならこう見る
3分類は「標準に合わせる／開発する／残す」の言い換え
ベンチャーネットは、NetSuiteの標準で収まらない業務を、3つの選択肢で決めています。
標準に合わせる、開発する、残す。
周辺業務の3分類は、この3択をSaaSに当てはめたものです。
| 3つの選択 | 周辺業務では | 決め手 |
|---|---|---|
| 標準に合わせる | 再販（既製の連携）や、NetSuiteの標準機能で済ませる | 既製の範囲で要件が収まるか |
| 開発する | 内包（中に作る）、または連携の個別開発 | 保守する人が決まっているか |
| 残す | 連携（専用SaaSを残してつなぐ） | 相手側の商流・法制度が価値か |
どれを選ぶかは、業務の見える化の後に決めます。
いまの業務でSaaSが何をしているのかを描かないまま3択に入ると、6.1の「手段から始める」失敗と同じことが起きます。
仕事の多くは「間に落ちる部分」
ベンチャーネットの仕事は、ゼロからの導入より、他システムとの連携や、他社のあとの引き継ぎが多くを占めます。
6.3で見た「連携は契約の間に落ちる」は、まさにその領域です。
既存システムとの連携の設計・開発・保守まで引き受けるのは、そのためです。
国内SaaSとの連携は、楽楽精算・バクラク・SmartHR・クラウドサインなどで、既製コネクタの活用から個別開発まで対応します。
分類の結果が「連携で十分」「作らないほうがよい」であれば、そのようにお伝えします。
作る量を増やすことが目的ではありません。
よくある質問
3分類は、導入前に全部決める必要がありますか
いいえ。
最初は主要な10業務ほどを分類すれば足ります。
残りは運用が始まってから、契約更新の時期に合わせて1つずつ判断します。
「連携」と「内包」で迷ったら？
連携に置きます。
内包は、保守する人が決まり、ルールが数年変わらないと分かってから選びます。
後から内包に切り替えることはできます。逆は、作ったものを捨てることになります。
iPaaS（連携基盤）を入れれば、判断は不要になりますか
なりません。
iPaaSは「連携」の手段の1つです。
何をつなぎ、何を作るかの判断は変わりません。
iPaaSの比較はNetSuite対応のiPaaS比較をご覧ください。
内包で作ったものは、NetSuiteのバージョンアップで壊れませんか
NetSuiteは年2回のバージョンアップがあり、標準機能の組み合わせで作った仕組みは原則として引き継がれます。
ただし、外部との連携で使う認証方式は、2027年以降に旧方式が使えなくなる予定です。
詳しくはNetSuiteの認証2027年問題で扱っています。
まとめ：今日できること
- 周辺業務は「再販→連携→内包」の順に3つの問いを当てて分類する
- 共に成長するSaaS（商流・法制度・審査が価値）はつなぐ。小さなSaaS（単機能・単純・変化が遅い）は中に作る
- 内包は無料ではない。費用はライセンスではなく保守の工数で発生する
- 手段の比較より先に分類を決め、連携・内包の担い手を契約前に決める
冒頭の問いに戻ります。
つなぐか、作るか、買うか。答えは、業務ごとに3つの問いを当てれば出ます。
今日できること：いま使っているSaaSと、NetSuite導入後に必要になる周辺業務を、1枚に書き出してみてください。
各行に「再販・連携・内包」のどれかを仮で付けるだけで、導入の姿と、誰に何を頼むべきかが見えてきます。
もう少し詳しく知りたい方へ
書き出した分類の結果を持って、ご相談ください。作るもの、つなぐもの、買えば済むものを、一緒に確定します。
関連記事
コメント
コメント一覧 （1件）
[…] 判断の順番は、NetSuiteの連携を「内包・連携・再販」で切り分ける判断軸で扱っています。 […]