最終更新：2026年9月14日｜読了時間：約10分
NetSuiteを導入すると、必ず出てくる問いがあります。
「いま使っている〇〇は、NetSuiteとつなぐのか。NetSuiteの中で作るのか。それとも、つなぐ製品を買ってくるのか」
請求書の発行、経費精算、電子契約、勤怠、EC、決済。周辺の業務は数十種類あり、1つずつ判断していると導入が止まります。
この記事では、周辺業務を「再販」「連携」「内包」の3つに切り分ける判断軸を整理します。書き手は、NetSuite認定パートナー（Solution Provider）のベンチャーネットです。連携の手段（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を残し、必要なデータだけをNetSuiteに流す設計にします。
🌏 日本での補足：NetSuiteは日本の給与計算に対応していません。給与・勤怠・労務は国内SaaSを残し、仕訳と従業員マスタを連携する形が前提です。日本の銀行との直接接続も標準にはなく、明細取込や入金消込は連携サービスと組み合わせます。
内包：NetSuiteの中に作る
単機能で、データ構造が単純で、法規制の変化が遅い業務です。汎用の承認（稟議）、休暇の申請、来客や設備の予約、社内アンケート、通知などが該当します。
これらは、NetSuiteの標準機能（項目・カスタムレコード・ワークフロー）を組み合わせて作れます。作った仕組みは、会計や在庫と同じデータベースの上で動きます。承認された申請がそのまま発注になる、といったつながりが自然に作れます。
一方で、作ったものには保守が要ります。ルールが変われば直す人が必要です。内包を選ぶときは、「誰が保守するか」を先に決めます。
3分類の比較表
| 観点 | 再販 | 連携 | 内包 |
|---|---|---|---|
| 初期の手間 | 小（設定中心） | 中（連携の設計・開発） | 中〜大（仕組みを作る） |
| 継続費用 | 連携アプリの利用料 | 専用SaaS利用料＋連携の保守 | 保守の工数（ライセンス追加は原則不要） |
| 相手側の仕様変更 | ベンダーが追従 | 自社または支援先が追従 | 相手がいないため発生しない |
| データのつながり | 連携アプリの範囲内 | 流すデータを設計した範囲 | 会計・在庫と同じ基盤で完結 |
| AIとの親和性 | 連携アプリの対応次第 | 専用SaaS側のAI機能を活かせる | NetSuiteのAI連携（MCP対応）でそのまま扱える |
| 向く業務 | EC・決済・電子契約・CRM | 給与・請求書受領・銀行・モール | 承認・休暇・予約・アンケート・通知 |
| 失敗しやすい点 | 既製の範囲と要件のずれ | 設計・保守の担い手不在 | 作りすぎ・保守放置 |
見分け方の実例
ベンチャーネットが、よく相談を受ける業務で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に渡せるようになりました。これは3分類の判断に影響します。
内包で作った仕組みは、AIからそのまま扱えます。一方、専用SaaSが担う承認・証跡・保存の流れは、AIで入力を楽にしても残ります。「AIが入力できるから専用SaaSは要らない」とはならない点を、「AIに入力を任せれば専用SaaSは不要になるのか」で整理しています。
つまずきやすい3つのパターン
手段の比較から始める
現象：API連携かiPaaSかCSVかを先に比べ、ツールを選んでから業務を当てはめる。
構造的原因：「何をつなぐか」より「どうつなぐか」の方が調べやすい。ツールの比較記事は多く、判断した気になれる。
回避策：先に3分類で「作る・買う・つなぐ」を決める。手段は分類が決まった後で、業務ごとに選ぶ。手段の比較は「NetSuiteの連携方法まとめ」に分けています。
内包を「無料」と考える
現象：追加ライセンスが要らないため、内包を費用ゼロと見積もる。作った後の保守が予算にない。
構造的原因：内包の費用はライセンスではなく工数で発生する。工数は見積書に載りにくい。
回避策：内包の候補ごとに「年に何回ルールが変わるか」「誰が直すか」を書き出す。年1回以上変わるなら、内包ではなく連携を検討する。
連携の担い手を決めずに契約する
現象：専用SaaSとNetSuiteの両方を契約したが、間をつなぐ設計を誰も担当していない。二重入力が始まる。
構造的原因：SaaSの契約とNetSuiteの契約は別々に進む。連携は両方の間に落ちる。
回避策：3分類で「連携」に置いた業務は、契約前に連携の設計・開発・保守の担い手を決める。社内にいなければ支援先に含める。
ベンチャーネットの対応
3分類は、そのままベンチャーネットの支援メニューです。
- 分類の代行：周辺業務を書き出し、再販・連携・内包に振り分ける整理を、経理・営業・情報システムの担当者と一緒に行います
- 再販の選定と設定：公式コネクタや既製の連携アプリの範囲と、自社の要件を照合し、設定まで行います
- 連携の設計・開発：楽楽精算・バクラク・SmartHR・クラウドサインなど国内SaaSとNetSuiteの連携を、既製コネクタの活用から個別開発まで対応します。入金消込のように標準で足りない領域は、開発で埋めます
- 内包の設計・実装と保守：承認・休暇・予約・通知などをNetSuiteの中に作り、ルール変更時の保守まで伴走します
分類の結果が「連携で十分」「作らない方がよい」であれば、そのようにお伝えします。作る量を増やすことが目的ではありません。
よくある質問
3分類は、導入前に全部決める必要がありますか？
いいえ。最初は主要な10業務ほどを分類すれば足ります。残りは運用が始まってから、契約更新のタイミングに合わせて1つずつ判断します。
「連携」と「内包」で迷ったら？
連携に置きます。内包は、保守する人が決まり、ルールが数年変わらないと確認できてから選びます。後から内包に切り替えることは可能ですが、逆は作ったものを捨てることになります。
iPaaS（連携基盤）を入れれば、判断は不要になりますか？
なりません。iPaaSは「連携」の手段の1つです。何をつなぎ、何を作るかの判断は変わりません。iPaaSの比較は「NetSuite対応のiPaaS比較」をご覧ください。
内包で作ったものは、NetSuiteのバージョンアップで壊れませんか？
NetSuiteは年2回のバージョンアップがあり、標準機能の組み合わせで作った仕組みは原則として引き継がれます。ただし、外部との連携で使う認証方式は、2027年以降に旧方式が使えなくなる予定があります。詳しくは「NetSuiteの認証2027年問題」で整理しています。
まとめ：今日できること
- 周辺業務は「再販→連携→内包」の順に3つの問いを当てて分類する
- 共に成長するSaaS（商流・法制度・審査が価値）はつなぐ。小さなSaaS（単機能・単純・変化が遅い）は中に作る
- 内包は無料ではない。費用はライセンスではなく保守の工数で発生する
- 手段の比較より先に分類を決め、連携・内包の担い手を契約前に決める
今日できること：いま使っているSaaSと、NetSuite導入後に必要になる周辺業務を、1枚に書き出してみてください。各行に「再販・連携・内包」のどれかを仮で付けるだけで、導入の姿と、誰に何を頼むべきかが見えてきます。
分類の結果を持って、ベンチャーネットにご相談ください。作るべきもの、つなぐべきもの、買えば済むものを、一緒に確定します。
もう少し詳しく知りたい方へ
関連記事
