CIO・情シス担当がNetSuiteを評価する技術的確認ポイントと、見落とされがちな「業務プロセス」【2026年版】

2028.2のリリースで、NetSuiteのSOAP連携は使えなくなる予定です。

いま動いている連携も、その時点で止まります（出典：Oracle NetSuiteヘルプ、2026年9月確認）。

評価の表で「API連携：○」と書く前に、知っておきたい事実です。

NetSuiteとは、Oracleが提供するクラウドERP（会社の業務とお金の流れを1つにまとめる仕組み）です。

世界220地域・44,000社以上で使われています（出典：Oracle NetSuite公式サイト、2026年9月時点）。

製品としての技術要件は、多くの中堅企業の要件を満たせる水準にあります。

評価で差がつくのは、次の2点です。

• 連携の方式とセキュリティを、2028年以降の前提で設計できているか
• 業務プロセスを全社で設計する役割が、社内に誰かいるか

では、技術の表がすべて○でも、導入後に「業務が回らない」と言われるのはなぜか。

答えは、2つ目の点にあります。

経営者の方で基礎から知りたい場合は、NetSuiteとは？クラウドERP入門もご覧ください。

この記事で分かること

• API連携・セキュリティ・運用負荷の技術の確認点（公式情報つき）
• SOAP連携の終了予定と、いま使っている会社の棚卸しの順番
• 情シスの体制で変わる、評価の重点と導入の期間
• 技術評価だけでは見落とす「業務プロセス」の評価軸
• よくある3つの失敗と、今日できる作業

技術評価の全体像｜5つの確認軸

CIO・情シスがNetSuiteを評価するとき、見る軸は次の5つです。

評価軸	見ること	この記事の章
API連携	連携の手段、認証の方式、今後の方針	第2章
セキュリティ	認証・権限・監査・外部の認証	第3章
運用負荷	年2回の更新と、カスタマイズの保守	第4章
拡張性	事業の拡大・海外展開への対応	第1章（下記）
パートナー	業務の設計まで伴走できるか	第6章・第9章

導入後の情シスの負担に直結するのは、API連携・セキュリティ・運用負荷の3つです。

そのうえで、技術の表では捉えきれない業務プロセスの評価軸があります。

拡張性は、比較的判断しやすい軸です。

NetSuiteは190通貨・27言語に対応し、海外拠点も同じ基盤で管理できます。

Oracleは「#1 AI Cloud ERP」を掲げ、AIの機能の強化も続けています。

海外の子会社を持つなら、複数の法人を1つの環境で扱うOneWorldが評価の対象です。

考え方はNetSuite OneWorldとはで扱っています。

データの量が多い会社は、NetSuiteの容量の上限もご覧ください。

API・外部連携｜SuiteCloudと、SOAPの終了予定

SuiteCloudは、NetSuiteをカスタマイズしたり、外部とつないだりする仕組みの総称です。

APIは、システムどうしがデータをやり取りする窓口のことです。

主な3つの手段

項目	SuiteScript	SuiteTalk（REST／SOAP）	RESTlet
中身	NetSuite内で動くJavaScriptのカスタマイズ	外部からレコードを読み書きするAPI	自社で作る独自のREST連携の窓口
主な用途	業務ロジック・画面・ワークフローの拡張	定期的なデータ連携、外部からの取り込み	業務ロジックを伴う軽い連携
情シスの確認点	属人化させない管理、コードの審査	認証の方式、データの整合性	認証・権限・トークンの管理
SOAPの削除の影響	対象外	新規はRESTで作る（SOAPは削除予定）	対象外

Oracleのヘルプでは、REST Web サービスを、SuiteTalkを拡張するRESTの連携の窓口と説明しています。

レコードの作成・読み取り・更新・削除や、クエリの実行ができます（出典：Oracle NetSuiteヘルプ、2026年9月確認）。

SuiteScriptの詳細はSuiteScriptとはで、ワークフロー拡張はNetSuiteのワークフロー・カスタマイズで扱っています。

SOAP連携は2028.2で使えなくなる予定

Oracleのヘルプには、次のように書かれています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。

• SOAP Web サービスは、製品から段階的に削除される
• 2025.2のSOAPエンドポイント（接続先の版）が、最後の予定の版
• 2027.1のリリースからは、2025.2のエンドポイントだけがサポートされる
• 2028.2のリリースで、SOAPはNetSuiteで使えなくなり、既存のSOAP連携は止まる
• 新しく作る連携は、REST Web サービスとOAuth 2.0の認証を使う

OAuth 2.0は、パスワードを渡さずに、決まった範囲の操作だけを許す認証の方式です。

ヘルプでは、パートナーのSOAPのアプリを使っている場合、REST版を相談するよう案内しています。

これから選ぶ会社は、評価の段階で次の3点を見ておきます。

• 自社で作る連携を、最初からRESTとOAuth 2.0で設計しているか
• 使う予定の連携ツール・SuiteAppが、RESTに対応済みか、予定があるか
• 2要素認証を必須にするロールを、導入前に決めているか

いま使っている会社は、SOAPの棚卸しが最優先

すでにNetSuiteを使っている会社は、次の順で進めると漏れが減ります。

順番	やること	目安の成果
1	SOAPを使う連携と、連携ツール・SuiteAppを洗い出す	対象の一覧
2	提供元にRESTへの対応の予定を聞く	対応の予定表
3	自社で作った連携は、影響の大きい順に作り直す	移行の計画
4	認証をOAuth 2.0に切り替え、並行して動作を見る	切り替えの手順書

移行は、連携を作り直す良い機会でもあります。

使われていない連携や、手入力で済ませている連携も、この時に見直してください。

認証の移行の進め方は、NetSuiteの認証方式の移行で扱っています。

「手段」より先に「つなぐ業務」を決める

APIが充実していても、評価で問うべきは別のところにあります。

「つなぐ手段があるか」ではなく、つなぐべき業務プロセスが決まっているかです。

何を・いつ・どの細かさで連携するか。

これが決まらないまま実装すると、二重入力や手直しの元になります。

たとえば、ECの受注をNetSuiteに取り込むなら、次の点を先に決めます。

決めること	例	決めないと起きること
何を	受注の明細・送料・値引き	金額が会計と合わない
いつ	15分ごと、または日次	在庫の引当が遅れる
どの細かさ	明細の1行ごと、または1注文ごと	分析に使えない粒度になる
正はどちら	取引先と品目のマスタはNetSuiteが正	同じ顧客が何件もできる
失敗したら	エラーの通知先と、再送の手順	取り込み漏れに気づかない

連携は、NetSuiteの年2回の更新や、相手のシステムの変更にも追随し続けます。

保守の担当と手順まで含めて評価してください。

AIとつなぐ前提で見る

Oracleは、NetSuite AI Connector Serviceを提供しています。

MCP（AIと業務システムをつなぐための共通の約束事）に対応し、ClaudeやChatGPTなどのAIをNetSuiteにつなぐサービスです。

公式サイトでは、利用者とAIが、ロールで決めた範囲だけを見て操作できると説明しています（出典：Oracle NetSuite公式、2026年9月確認）。

情シスの立場で見ておきたいのは、次の3点です。

• AIに使わせるロールを、人のロールと同じ考え方で設計できるか
• AIに見せてよいデータと、見せないデータの線引きが決まっているか
• マスタ（取引先・品目など）が整い、AIが読んでも誤解しない状態か

経理の担当がAIに「今月の未入金の一覧」を聞く場面を考えます。

AIが答えられる範囲は、その担当のロールで見える範囲に限られるのが望ましい。

人とAIで権限の考え方をそろえておくと、AIを広げるときの審査も短くなります。

全体像は、NetSuiteの組み込みAIと外部AIの違いで扱っています。

セキュリティ｜製品の機能と、運用の設計を分ける

上場準備・監査・取引先の要件などで、中堅企業のセキュリティの要件は厳しくなっています。

公式に確認できる主な項目

項目	公式の記載（2026年9月確認）
外部の認証	SOC 1 Type 2・SOC 2 Type 2の外部監査。ISO 27001・ISO 27018・ISO 42001・PCI DSSに準拠
可用性	99.7%の可用性を約束（計画された保守の時間を除く）
データセンター	北米・欧州・アジア太平洋に、地理的に分かれたデータセンター
通信	認証情報とやり取りするデータは、業界標準の方式で暗号化
認証	多要素認証、IPアドレスによる制限。管理者と強い権限のロールは2要素認証が必須
権限	ロール（役割）単位で、参照・編集・承認の範囲を分けられる

出典はOracle NetSuite公式（運用のセキュリティ）・可用性・Oracle NetSuiteヘルプ（2要素認証のロール）です。

SOC 1／SOC 2は、委託先の内部統制を外部の監査人が評価した報告書です。

ISO 27001は、情報セキュリティの管理の仕組みの国際規格です。

2要素認証は、管理者などの必須のロールのほか、多くのロールにも必須を指定できます。

ロールの設計は、NetSuiteのロールと権限で扱っています。

公式サイトでは、SOC 1 Type 2とSOC 2 Type 2の監査が終わるたびに報告書を出すと説明しています。

監査法人や取引先から委託先の管理を問われたとき、この報告書が材料になります。

入手の方法は、契約の前にOracleかパートナーに聞いておきます。

「製品のセキュリティ」と「運用のセキュリティ」

製品の機能が充実していても、運用は会社ごとに設計が要ります。

• 各ロールに、誰が・どの権限を持つか
• 退職者・異動者の権限を、いつ・誰が見直すか
• 監査ログを、誰が・どの頻度で見るか
• カスタマイズのコード（SuiteScript）を、誰が審査するか

これらは製品の仕様ではなく、運用を回す体制の話です。

内部統制・監査で問われやすい点

上場準備や監査では、システムの機能そのものより「どう使っているか」が問われます。

問われやすい点	NetSuiteで使う仕組み	決めておくこと
職務分掌（担当を分けて不正を防ぐこと）	ロールごとの権限	入力と承認を同じ人にしないロールの組み方
変更の記録	誰が・いつ・何を操作したかの記録	記録を誰が・どの頻度で見るか
承認の手順	承認のワークフロー	金額や部門で、承認者をどう分けるか

承認の手順の作り方はNetSuiteの承認ワークフローで、上場準備の確認項目はIPO準備企業の内部統制チェックリストで扱っています。

基幹システム全般の考え方は、基幹システムのセキュリティ性とはをご覧ください。

運用負荷｜年2回の更新とカスタマイズ

更新はOracleが行い、事前に試せる

Oracleのヘルプでは、NetSuiteの大きなリリースは年2回です。

各社のアカウントは、数か月かけて段階的に更新されます（出典：Oracle NetSuiteヘルプ、2026年9月確認）。

更新の前には、Release Previewのアカウントを依頼できます。

自社のデータと業務の流れで、新しい版で問題なく動くかを試すための環境です。

サーバーの管理やOSのパッチの作業は、情シスの手を離れます。

Release Previewは、本番のアカウントが新しい版に更新された日に使えなくなると案内されています。

開発やテストを日常的に行う環境が要るなら、別にサンドボックスを検討します。

違いはNetSuiteのサンドボックスとはで扱っています。

古いスクリプトにも、書き換えの期限があります。

対象は、SuiteScript 1.0や2.0・2.xで書いたスクリプトです。

Oracleのヘルプは、2028.2のリリースまでに2.1へ更新するよう案内しています（出典：Oracle NetSuiteヘルプ、2026年9月確認）。

SOAPの棚卸しと同じ時期に、スクリプトの版の一覧も作っておくと二度手間が減ります。

更新の進め方はNetSuiteのバージョンアップで扱っています。

カスタマイズの量が、運用負荷を決める

ベンチャーネットが見てきた範囲では、差がつくのはカスタマイズの量です。

状態	更新のたびに起きること
カスタマイズが少ない	動作の確認はあるが、影響の範囲は小さい
カスタマイズが多い	毎回の回帰テスト（既存の機能の再確認）が要り、保守の工数が続く
特定の担当者に依存	その人の異動・退職で、運用が止まる

情シスが1〜2名の会社ほど、3つ目の状態に陥りやすくなります。

業務を標準の機能に合わせる考え方を、Fit to Standardと呼びます。

カスタマイズを最小限にするほど、更新のたびの負担は軽くなります。

契約の前には、次の3つを聞いておくと運用負荷を見積もりやすくなります。

• 更新のたびに、パートナーはどの範囲の確認を支援するか
• カスタマイズの一覧と設計書を、誰がどこで管理するか
• データを外に持ち出す方法（エクスポート）と、その頻度

最後の問いは、将来の乗り換えや障害への備えにも関わります。

考え方はNetSuiteのバックアップとデータエクスポートで扱っています。

情シスの体制で変わる、評価の重点と期間

同じNetSuiteでも、情シスの体制によって、評価で重く見る点が変わります。

情シスの体制	重く見る点	見落としやすい点
一人情シス・兼務	カスタマイズを増やさない設計、保守を頼める相手	本人の不在時に、誰が連携のエラーに気づくか
数名の情シス	権限の見直しと更新時の確認を、手順として回せるか	各部門の要望を、情シスが一人で調整してしまう
専任の開発チームあり	RESTでの連携の設計、コードの審査の仕組み	作れるがゆえに、カスタマイズが増えすぎる

体制は、導入の費用と期間にも表れます。

ベンチャーネットが支援したNetSuite導入の費用では、情シスのいない20名程度の事例が3,000万円程度・2年でした。

情シスと開発会社のいる30名程度の事例（2,000万円程度・1年）より、高く、長くなっています。

情シスが少ない分、ベンチャーネットのサポートを厚くしたためです。

ほかの事例と4つの要因は、NetSuiteの料金・費用で扱っています。

判断の物差し｜NetSuiteが合う会社・合わない会社

技術の要件を満たすことと、自社に合うことは別の話です。

NetSuiteが合いやすい会社

• 複数の法人・拠点があり、会計と販売・在庫を1つの基盤で見たい
• 海外拠点がある、または近く持つ予定がある
• 情シスが少人数で、サーバーの運用から手を離したい
• 連携を、REST中心で新しく設計し直せる
• 業務を標準の機能に合わせる方針に、経営層が合意できる

ほかの選択肢が合いやすい会社

状況	合いやすい選択肢	理由
国内1社で、業種特有の帳票・商習慣が多い	国産ERP	日本の業務に合わせた標準機能が厚い
費用を抑え、自社で手を入れながら育てたい	Odoo	オープンソースで、自社開発の余地が大きい
業務が独自で、パッケージに合わない部分が核	AIスクラッチ開発	自社の業務に合わせて作れる
業務の流れが決まっていない、担当が足りない	いまは入れない	先に業務の整理から始めるほうが確実

情シスの目で見ると、分かれ目は2つです。

業務の多くが自社独自のやり方でないと回らないか。

導入後に運用を担う人を、社内に1人も置けないか。

どちらかに当てはまるなら、NetSuiteを急がないほうがよいこともあります。

2つの分かれ目を図にすると、次のとおりです。

技術評価だけでは見落とす「業務プロセス」の評価軸

技術の評価をすべて通ったのに、導入後に「使いにくい」「業務が回らない」と言われる。

冒頭の問いの答えは、ここにあります。

原因は多くの場合、製品ではなく、評価の視点が技術に偏っていたことです。

観点	技術の評価軸	業務プロセスの評価軸
何を見るか	機能・性能・連携・セキュリティ	業務とシステムの合い方、運用の余力
主な担当	CIO・情シス・SIer	多くの会社で明確な担当がいない
代表的な項目	API・可用性・ロール・カスタマイズの言語	業務の見える化、標準への合わせ方、現場との合意
いつ評価するか	製品を選ぶ段階	選ぶ前から、導入後の運用まで
足りないと	機能はあるのに使いこなせない	今の業務を残すカスタマイズが膨らむ

「CIO機能」とは何か

ここでいうCIO機能は、役職のCIOではありません。

次の2つをつなぐ役割のことです。

• 業務プロセスを見える化する（今の業務がどう流れているか）
• 見える化した業務を、ERPの標準の機能にどう乗せるかを設計する

SIerは実装、情シスはインフラ、各部門は自部門の実務、経営層は経営判断の専門家です。

全社を横断して業務を設計する役割は、どの専門にも含まれていないことが多い。

不在のまま進めると、次のことが起きます。

• 業務の要件が、各部門の主張のすり合わせで終わる
• 「今の業務を変えたくない」に応えるカスタマイズが膨らむ
• 費用と運用負荷が、当初の想定を大きく超える

個人の判断ミスではありません。役割が決まっていないという構造の問題です。

進め方は、業務フローの見える化で扱っています。

業務プロセスの評価で見る4つの項目

項目	見方	危ない兆候
業務の見える化	主要な業務の流れが、図や表で書かれているか	「担当者に聞かないと分からない」業務が多い
標準への合わせ方	デモで、標準の機能に乗る業務の割合を見る	「今と同じ画面にしてほしい」という要望が多い
現場との合意	変える業務を、部門の責任者が了承しているか	決定が情シスの判断だけで進んでいる
運用の余力	導入後に業務を回す人と時間があるか	稼働の直後に、繁忙期が重なっている

4つのうち2つ以上に危ない兆候があれば、製品を決める前に手当てを考えます。

4つの項目を、チェックの形にすると次のとおりです。

CIO機能を置く3つのやり方

やり方	中身	向く会社	注意点
社内で育てる	業務に詳しい管理職を専任にし、横断の権限を渡す	担当を専任にできる余力がある	立ち上がりに時間がかかる
外部のチームで補う	業務の設計に慣れた外部のチームと、社内の担当が組む	社内に専任を置けない	任せきりにせず、決める人は社内に置く
導入パートナーに任せる	実装を担うパートナーに、業務の設計も頼む	業務が比較的単純	実装の都合で設計が決まりやすい

どれを選んでも、最後に決める人は社内に置くことが前提です。

外部は、判断の材料と選択肢を出す役割にとどめます。

評価の進め方｜6つのステップ

技術の評価と業務の評価は、同じ順番の中で進めると手戻りが減ります。

ステップ	やること	できあがるもの
1. 目的	何を1つにしたいか、どの数字を早く見たいかを決める	目的の1枚
2. 業務の見える化	受注から入金、発注から支払などの流れを書き出す	業務フロー図
3. 連携の棚卸し	相手のシステム・方式・頻度・担当を一覧にする	連携の一覧
4. 標準との照合	デモで、標準の機能に乗る業務・乗らない業務を分ける	合う・合わないの表
5. 技術の確認	認証・権限・連携の方式・運用の体制を見る	技術の確認表
6. 運用の設計	更新のたびのテスト、権限の見直し、保守の担当を決める	運用の手順書

ステップ4で「乗らない業務」が多いなら、ここで立ち止まります。

業務を変えるのか、作り足すのか、ほかの製品を選ぶのか。この段階で決めます。

照合の考え方は、フィット＆ギャップ分析で扱っています。

技術の確認で聞く質問の例

ステップ5では、次の質問を提供元やパートナーに投げます。

答えの質で、相手を比べやすくなります。

軸	質問の例
連携	提案の連携は、RESTとOAuth 2.0で作りますか
連携	SOAPの連携が残る場合、2028.2までの移行の計画はありますか
セキュリティ	2要素認証を必須にするロールを、どう決めますか
セキュリティ	退職者・異動者の権限の見直しを、どう運用しますか
運用	年2回の更新のとき、どこまで確認を支援しますか
運用	カスタマイズの設計書は、誰が持ち、どう引き継ぎますか
AI	AIに使わせるロールと、見せるデータの範囲をどう決めますか
出口	データを外に持ち出す方法と、その頻度はどうしますか

答えが具体的な相手ほど、導入後の運用も任せやすくなります。

パートナーの選び方は、NetSuiteのパートナーの選び方で扱っています。

評価の結果をまとめる表

最後に、評価の結果を1枚にまとめます。右端の列は、自社で埋めてください。

評価軸	NetSuiteの標準の対応	評価で見る点	自社の判定
API連携	SuiteScript・REST Web サービス・RESTlet	新しい連携をRESTとOAuth 2.0で作れるか
セキュリティ	SOC 1／SOC 2 Type 2、ISO 27001、2要素認証	権限の見直しを回す体制があるか
運用負荷	年2回の更新、Release Preview	更新のたびの確認を誰がするか
拡張性	190通貨・27言語、OneWorld	3〜5年後の拠点・法人の数
パートナー	認定パートナーの制度	業務の設計まで伴走できるか
業務プロセス	標準の業務の型	業務を設計する担当がいるか

最後の行が空欄のままなら、評価はまだ終わっていません。

よくある3つの失敗

失敗1：機能の○×表で選んでしまう

起きること：導入後に「うちの業務と合わない」と現場から声が上がり、追加のカスタマイズが膨らむ。

原因：「今の業務に要る機能があるか」だけを見て、業務をERPに合わせる視点が抜けていた。

避け方：○×表の前に、業務プロセスを見える化します。

標準機能のうち「使う・使わない・作り足す」を決めてから、技術の評価に入ります。

失敗2：「APIで何でもつながる」と考える

起きること：連携は動くのに、二重入力やデータの食い違いが残る。SOAPで作った連携の作り直しも後から発生する。

原因：何を・いつ・どの細かさでつなぐかを決めずに実装した。連携の方式の今後の方針も見ていなかった。

避け方：「どの業務の流れを1つにするか」を先に決めます。

そのうえで、新しい連携はRESTとOAuth 2.0で設計します。

失敗3：情シスにすべてを任せる

起きること：各部門の合意が取れず、プロジェクトが止まる。一人情シスが疲弊する。

原因：情シスはインフラとシステムの専門家で、全社の業務の設計は本来の担当ではない。

避け方：業務プロセスを設計する役割を、社内か外部に明確に置きます（6-3）。

情シスの体制の考え方は、情シスアウトソーシングの限界でも扱っています。

ベンチャーネットならこう見る

「うちは情シスが2人しかいない。NetSuiteの導入は無理だろうか」

評価の相談では、この声をよく伺います。

NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、情シスが少なくても進められる体制を前提に組み立てます。

型1：要件は導入コンサルタントが、業務の言葉で聞く

ベンチャーネットでは、要件を伺うのは営業ではなく導入コンサルタントです。

情シスの方に、社内の要件を翻訳して伝える役を背負わせないためです。

PM兼コンサルタントが、提案からカットオーバー（本番稼働）まで一貫して担当します。

週次の定例と課題管理表で、決めたことを文書に残しながら進めます。

仕事の中身にも特徴があります。

ゼロからの導入より、他社のあとの引き継ぎ・立て直しと、他システムとの連携が多くを占めます。

2-3のSOAPの棚卸しや、既存の連携の作り直しは、その延長にある仕事です。

パートナーの変更の考え方は、伴走型のNetSuite導入支援とはで扱っています。

型2：見える化→整理整頓→Fit&Gap

第6章の「CIO機能」の空白は、次の順番で埋めます。

いまの業務を現場に聞いて描き、やめる・まとめる・そろえる業務を決める。

残った業務を、NetSuiteの標準機能と照らし合わせる。

合わない業務は「標準に合わせる／開発する／残す」のどれかに決めます。

Oracleのベストプラクティスも、そのまま入れず、自社の環境で試してから入れます。

開発を選ぶ数が減れば、第4章の運用負荷もそのぶん軽くなります。

最初の打ち合わせで伺うのは、主に次の3つです。

1. 何を1つにしたいのか（会計・販売・在庫・案件のどこで、数字が分かれているか）
2. 誰が業務を設計するのか（社内に担当がいるか、外部で補うか）
3. いまの連携の一覧（相手のシステム・方式・頻度・担当）

2に答えが出なければ、製品の比較より先に業務の整理をお勧めすることもあります。

比べた結果、国産ERPやOdoo、「いまは入れない」が合うなら、そうお伝えします。

今日できること｜連携の一覧を1枚にする

1時間あれば、次の表を作れます。

相手のシステムと方向	方式（SOAP／REST／CSV／手入力）	頻度・担当	止まったときの影響
（例）EC：受注→ERP	CSV	毎日・営業事務	出荷が遅れる

書き出すと、次の2つが見えてきます。

• 手入力が残っている連携（業務の設計で減らせる候補）
• 担当が1人しかいない連携（属人化のリスク）

NetSuiteを使っている会社は、方式の列で「SOAP」の行に印をつけてください。

それが、2028.2までに移行が要る候補です。

時間が残れば、もう1つの作業を。

主な業務の流れ（受注から入金、発注から支払など）ごとに、「全体を説明できる人」の名前を書きます。

業務の流れ	全体を説明できる人	その人がいないと困ること
（例）受注から入金	営業管理の課長	値引きや返品の扱いが分からない

名前が書けない流れや、同じ人の名前が並ぶ流れがあれば、そこが「CIO機能」の空白です。

よくある質問

Q1. SuiteScript・SuiteTalk・RESTletはどう使い分けますか

内部の処理はSuiteScript、データの連携はREST、独自の窓口はRESTletが基本です。

SuiteTalkのうちSOAPは削除の予定のため、新しい連携はREST Web サービスで作ります（第2章）。

詳しくはSuiteScriptの解説記事をご覧ください。

Q2. SOAPで作った連携は、いつまで使えますか

2028.2のリリースで使えなくなる予定です（Oracleのヘルプの記載）。

2027.1からは、2025.2のエンドポイントだけがサポートされます。

連携ツールやSuiteAppは、提供元にRESTへの対応の予定を聞きます。

自社で作った連携は、影響の大きいものから順に作り直すのが現実的です（2-3）。

Q3. NetSuiteのセキュリティは中堅企業の要件を満たせますか

製品としては満たせる水準です。

SOC 1／SOC 2 Type 2の外部監査、ISO 27001などに対応しています。

ただし、ロールの設計や権限の見直しなど、運用の設計は自社で決める必要があります（第3章）。

Q4. 年2回の更新で、カスタマイズが動かなくなりませんか

更新前にRelease Previewで試せます。

ただし、カスタマイズが多いほど、毎回の確認の工数は増えます。

標準機能を中心に使うことが、長く運用する近道です（第4章）。

Q5. 一人情シスでも導入・運用できますか

運用はできます。ただし、導入は一人で抱えないほうが確実です。

サーバーの管理がないため、運用の負荷は小さくなります。

一方、全社の業務の設計は情シスの専門外になりやすく、担当を別に置くことを勧めます。

情シスが少ない会社では、パートナーのサポートを厚くする分、導入の期間も長くなりがちです（4-3）。

Q6. 業務プロセスの見える化は、なぜ導入の前に要るのですか

標準機能に何を合わせるかを決められないからです。

見える化をせずに進めると、今の業務を残すためのカスタマイズが膨らみます。

「何を残し、何を変え、何をやめるか」を決めることが、評価の前提になります（第6章・第9章）。

Q7. SIerと伴走型のパートナーは何が違いますか

業務の設計から一緒に考えるかどうかの違いです。

SIerは、決まった仕様を作ることを得意とします。

NetSuiteは標準機能に業務を合わせるのが基本です。

そのため、業務とシステムの両方を設計できるかを、選ぶときの物差しにします。

ほかの質問はNetSuite導入でよく受ける質問30問にまとめています。

まとめ

• NetSuiteの評価には、技術の評価軸と業務プロセスの評価軸の2つが要る
• 新しい連携は、RESTとOAuth 2.0で設計する。SOAPは2028.2で使えなくなる予定
• 使っている会社は、まずSOAPの連携とスクリプトの版の棚卸しから始める
• セキュリティは公式の認証を確認し、運用の設計は自社で決める
• 運用負荷はカスタマイズの量で、導入の期間は情シスの体制で変わる
• 業務を全社で設計する「CIO機能」を、社内か外部に置く

技術の表がすべて○でも、業務は回るとは限りません。

評価表が埋まったら、最後に1つだけ問いかけてください。

「この業務の流れを誰が設計するのか」。

その答えが出たとき、評価は終わります。

もう少し詳しく知りたい方へ

技術の評価と業務の設計を、同時に進めたい方へ。

業務の見える化から、NetSuiteへの反映まで、一緒に整理するご相談をお受けしています。

• NetSuite × 業務見える化伴走サービス
• NetSuiteアドオン開発サービス「NetSuiteリブート」（連携・カスタマイズの設計と開発）
• お問い合わせ