NetSuiteのワークフロー・カスタマイズ完全ガイド｜SuiteFlow・SuiteScriptの使い分けと判断軸【2026年版】

「ノーコードで作れるなら、ワークフローは現場で増やしていけばいい」

導入の後、よく聞く考え方です。

数年たつと、誰が何のために作ったか分からないワークフローが並ぶ。

その入り口は、たいていここにあります。

NetSuiteのワークフロー（SuiteFlow）とは、コードを書かずに承認や自動の処理などの業務の流れを組む仕組みです。

その上位の言葉がカスタマイズで、標準の機能に項目・業務の流れ・プログラムを足し、自社の業務に合わせることを指します。

手段はSuiteBuilder・SuiteFlow・SuiteScriptの3つ。

年2回の更新でもカスタマイズは引き継がれますが、更新前の点検は要ります。

自由度が高いぶん、線引きを誤るとカスタマイズは運用の負債に変わります。

では、どこまで標準で済ませ、どこから作るのか。

その物差しは、技術ではなく経営の側にあります。

この記事で分かること

• NetSuiteのカスタマイズの3つの階層
• SuiteBuilder・SuiteFlow・SuiteScriptの違いと使い分け
• 標準で済ませるか、開発するかの判断軸
• カスタマイズを運用の負債にしない進め方
• カスタマイズの費用が膨らむ要因と、実際の導入費用の例
• よくある失敗3つと、その避け方

NetSuiteの「カスタマイズ」が指す3つの階層

「カスタマイズ」という言葉は、幅の広い意味を持ちます。

階層	中身	誰が触れるか
設定の変更	項目の追加、ロールの権限、ダッシュボードの調整	業務の担当者でも可
拡張	ワークフローの構築、帳票の調整	業務の担当者〜パートナー
開発	コードでの独自の機能、外部システムとの連携	開発者・パートナー

設定の変更と拡張の一部は、業務の担当者でも扱えます。

開発になると、JavaScriptの知識を持つ技術者の支援が要ります。

クラウドのまま自社の業務に合わせられる

オンプレミス型のERPでは、作り込みのせいで新しい版に上げられなくなる問題がありました。

これをバージョンロックと呼びます。

NetSuiteの更新は年2回、通常は春と秋に行われます。

Oracle NetSuite公式のFAQでは、利用者のカスタマイズは更新時もそのまま保たれると説明しています。

新しいバージョンへ自動で引き継がれるとされています（2026年9月確認）。

作成したスクリプトも同じく引き継がれ、バージョンロックは要らないとされています。

「作り込んだら塩漬けになる」という、従来のERPの悩みを避けやすい仕組みです。

ただし、引き継がれることと、動きが変わらないことは別です。

更新前の確認は第9章で扱います。

全体像｜SuiteCloudと3つの基盤機能

NetSuiteのカスタマイズは、SuiteCloud（スイートクラウド）と呼ばれる基盤の上で行います。

業務の担当者が触れる道具から、開発者向けの環境までがそろっています。

中心になるのは、次の3つです。

• SuiteBuilder：画面と項目を調整する。独自の項目・独自のレコード・入力フォームなど
• SuiteFlow：コードを書かずに業務の流れを自動にする。承認・自動の処理・条件の分岐など
• SuiteScript：JavaScriptで開発する。複雑な業務の論理・外部との連携・大量の処理など

コードを書く範囲が増えるほど、人への依存・保守の負担・更新時の確認が増えます。

そのため、できるだけSuiteBuilderとSuiteFlowで済ませ、残りだけをSuiteScriptで補うのが基本です。

比較表①：SuiteBuilder・SuiteFlow・SuiteScript

観点	SuiteBuilder	SuiteFlow	SuiteScript
位置づけ	画面・項目の調整	ノーコードのワークフロー	コードでの開発
操作	画面の操作	画面の操作	JavaScriptを書く
要るスキル	NetSuiteの操作	操作＋業務の流れの設計	プログラミング
得意なこと	独自の項目・レコード・フォーム	承認・自動の処理・条件の分岐・メール	複雑な論理・外部連携・一括の処理
苦手なこと	業務の論理	複雑な計算・外部APIとの連携	簡単な画面の調整（費用が見合わない）
更新への追随	引き継がれる	引き継がれる	引き継がれる（動作の確認は要る）
誰が触るか	業務の担当者でも可	業務の担当者〜パートナー	パートナー・開発者
AIとの親和性	中。項目がそろうとAIが読めるデータが増える	中。AIの結果を承認の流れに乗せやすい	高。生成AIの機能やAI Connectorのツールを作れる

「AIとの親和性」の行は、第4章の公式情報をもとにした見立てです。

付けたのは、NetSuite認定パートナー（Solution Provider）であるベンチャーネットです。

3つのほかに知っておきたい道具

SuiteCloudには、3つの基盤のほかにも、開発と連携のための道具があります。

• SuiteTalk：外部のシステムからNetSuiteのデータを扱うWebサービス（第5章）
• SuiteCloud Development Framework（SDF）：手元の開発環境でカスタマイズを作り、アカウントに配置する仕組み（第9章）
• SuiteApp：既製の拡張アプリ。日本向けのJapan Localization SuiteAppもその一つ（第7章）

経営者がすべてを覚える必要はありません。

ただ、開発したものを誰がどこで管理しているかは、経営として知っておくべきことです。

SuiteFlowとは｜ノーコードのワークフロー

SuiteFlowは、コードを書かずに業務の流れを自動にする、NetSuiteのワークフローの仕組みです。

Oracleのヘルプでは、次のように説明されています（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。

• ワークフローは、標準または独自のレコードについて、業務の流れを定める
• レコードが流れの中で進む状態（ステート）を持つ
• 状態ごとに、メールの送信やボタンの追加などのアクションを定める
• 条件に応じて、次の状態へ遷移する
• レコードの表示・作成・更新をきっかけに動く。スケジュールで動かすこともできる

ヘルプでは、取引の承認、見込み客の育成、レコードの管理が業務の例に挙げられています。

SuiteFlowでできること

• 承認の流れ：申請・承認・差し戻しを自動にする
• 自動の処理：条件を満たしたら、メールの送信や項目の更新をする
• 条件の分岐：レコードの値で、処理の道筋を切り替える
• 状態の管理：レコードのステータスの移り変わりを一か所で管理する

人の連携と、システムの連携

人の連携の代表は、申請と承認です。

• AND承認：同じ段に複数の承認者がいるとき、全員の承認で次に進む
• OR承認：誰か1人の承認で次に進む
• 差し戻し：承認待ちの申請を却下し、前の段に戻す

システムの連携では、在庫のアラートや回収の流れの自動化などに使えます。

たとえば、在庫が一定の水準を下回ったら担当者に知らせる、期日が近い請求を一覧にして督促の担当者に回す、といった使い方です。

承認の実装の手順は、NetSuiteの承認ワークフロー実装ガイドで扱っています。

「業務の担当者だけで作れる」とは限らない

画面の操作で作れるため、プログラミングの経験がなくても作成・編集できます。

ただし、ワークフローには設計が要ります。

設計なしに増やすと、運用が回らなくなります（第9章の失敗2）。

SuiteFlowで扱いにくいこと

SuiteFlowは万能ではありません。

次のような要件は、SuiteScriptと組み合わせるか、最初からSuiteScriptで作ります。

• 取引の明細行（サブリスト）の値を、1行ずつ見て処理する
• 複数のレコードをまたぐ複雑な計算をする
• 外部のシステムとデータをやり取りする
• 大量のレコードを一度に処理する

明細行の扱いは、第4章のWorkflow Actionスクリプトで補えます。

「SuiteFlowで組めるが、動きが重い」という場合も、作り方を見直す合図です。

SuiteScriptとは｜コードで開発する仕組み

SuiteScriptは、JavaScriptをもとにした、NetSuiteの開発の仕組みです。

NetSuiteのデータ（レコード・取引・独自のレコード）を操作し、業務の論理を自由に作れます。

スクリプトの種類

Oracleのヘルプでは、SuiteScript 2.1のスクリプトの種類として12種類が挙げられています。

（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）

よく使うものを、用途ごとに並べます。

種類	用途
Client	画面での入力の確認、項目の動きの制御
User Event	レコードの保存時・読み込み時の処理
Scheduled	決まった時刻に動く処理（月次の集計など）
Map/Reduce	大量のデータを分けて処理する
Suitelet	独自の画面を作る
RESTlet	外部のシステムとのAPI連携の窓口を作る
Workflow Action	ワークフローに独自のアクションを足す
Custom Tool	外部のAIから呼び出すツールを作る
Mass Update・Portlet など	一括の更新、ダッシュボードの部品など

コードの例と各種類の詳細は、SuiteScript（NetSuiteの開発言語）とは？で扱っています。

種類の選び方は、「いつ動かすか」で考えると分かりやすくなります。

• 人が画面で入力している最中 → Client
• レコードが保存された時 → User Event
• 決まった時刻 → Scheduled、件数が多ければMap/Reduce
• 外部のシステムから呼ばれた時 → RESTlet
• ワークフローの途中 → Workflow Action

この選び方を図にすると、次のとおりです。

SuiteFlowとSuiteScriptは「補い合う」関係

Workflow Actionスクリプトは、ワークフローの中に独自のアクションを作る種類です。

ヘルプでは、ワークフローの画面では扱えない明細行（サブリスト）の処理や、標準のアクションでは書けない論理に使うと説明されています。

全体の流れはSuiteFlowで組み、難しい一部だけをSuiteScriptで作る。

両者は競合ではなく、補い合う関係です。

AIとつなぐ開発

Custom Toolスクリプトは、外部のAIからAI Connector Service経由で呼び出せるツールを作る種類です。

自然な言葉での指示から、データの取得や処理の実行ができるとされています。

使える範囲は、ツールの権限と、利用者のNetSuiteのロールで制限されます。

また、SuiteScript 2.1のN/llmモジュール（生成AIを呼び出す部品）は、日本で使えると案内されています。

（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）

AIと組み合わせる開発は、今後広がる領域です。

AI Connector Serviceの仕組みはNetSuite AI Connector Service（MCP）とはで扱っています。

外部システムとの連携

外部との連携の主な手段は、次の2つです。

• RESTlet：NetSuite側に窓口を作り、外部のシステムからREST形式でデータを受け取る
• SuiteTalk：NetSuiteの標準のWebサービス。SOAPとRESTの2つがある

Oracleのヘルプには、SOAPからRESTへの移行ガイドがあります。

RESTでは、認証の方法としてOAuth 2.0が推奨されています（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。

これから新しく連携を作る場合は、RESTを前提に検討するのが自然です。

ECサイト・倉庫管理システム・物流システムなど、自社の周辺のシステムとつなげられます。

ただし外部との連携は、認証・エラーの処理・データの整合性など、考えることが多い領域です。

既製の連携の手段がないかを先に探し、それでも足りない部分だけを作ります。

日本のSaaSとの連携の全体像は、NetSuite×日系SaaS連携マップで扱っています。

連携の方式を選ぶ目安

方式	合う条件	気をつける点
既製のSuiteApp・コネクタ	よく使われるSaaSやECとつなぐ	自社の運用に合うかを試してから入れる
SuiteTalk（REST）	外部のシステムからNetSuiteの標準のデータを読み書きする	認証と、エラーの時の再送の設計
RESTlet	NetSuite側で独自の処理を挟んで受け取りたい	開発と保守が自社またはパートナーの責任になる
CSVの取込	頻度が低い、件数が少ない	手作業が残る。取込の前の形をそろえる

どの方式でも、どちらのシステムの値を正とするかを先に決めます。

これが決まっていないと、連携しても数字が合いません。

よくある実装の型

導入の現場でよく行われるカスタマイズは、次の4つの型に分かれます。

承認のワークフロー

最初に検討されることが多いのが、承認の流れです。

受注・発注・経費の申請など、業務の節目で承認が要ります。

SuiteFlowで、申請→承認→完了の流れを、コードを書かずに組めます。

承認の履歴が残るため、内部統制の強化にもつながります。

金額の帯・部門・案件の種類に応じて、承認の道筋を切り替える設計もできます。

最初から一番複雑な流れを作らないでください。

よく使う単純な流れから作り、運用しながら例外を足していくほうが定着します。

承認フローの骨子をAIに下書きさせる

初めて承認の流れを作る担当者は、どこから手を付けるかで迷います。

そこで、状態・遷移・条件の骨子を生成AIに聞く方法があります。

SuiteFlowは標準の機能なので、汎用のAIに聞くだけならいますぐ始められます。

（出典：NetSuite Professionals「write me a basic vendor bill workflow」、2026年9月確認）

仕入先請求書での例です。サンプルは架空です。

手順	中身
元データ	起票は購買担当。課長が承認し、却下なら起票者へ戻す。50万円以上は経理部長も承認
AIへの頼み方	ロールで承認する仕入先請求書のワークフローの作り方を、状態・遷移・条件に分けて教えてほしい
結果	起票済み→課長承認待ち→（50万円以上なら）経理部長承認待ち→承認済み。却下は起票済みへ戻す
人の確認	骨子をSandbox（試験環境）で作り、承認と却下の両方を実際に通す

言葉で条件を伝えるとワークフローを設計するSuiteFlow Assistantも発表されています（出典：日本オラクル プレスリリース、2026年9月確認）。

これはNetSuite Next上の機能で、日本での提供時期は公式に示されていません。

どちらの道でも、AIは下書きまでです。

条件と承認者が職務権限規程に合っているかは、人が照らして確定します。

帳票の調整

日本の商慣習には、独自の帳票が多くあります。

代表が、取引先ごとに月単位で複数の取引をまとめる締めの請求書です。

インボイス制度の開始後は、適格請求書として要る項目を入れた様式も求められます。

帳票は、現場からの要望が強くなりやすい領域です。

「取引先と合意した様式」と「社内の慣例の様式」を分け、前者を優先して調整します。

すべての要望に応えると、様式ごとに保守の手間が増え続けるためです。

定型業務の自動化

• 在庫のアラート：在庫が一定の水準を下回ったら、発注の担当者に知らせる
• 期日の通知：契約の更新日や請求の発行日が近づいたら、タスクにする
• 集計：月次・週次の売上の集計を、決まった時刻に動かす
• 同期：他のシステムとのマスタの同期を、夜間にまとめて動かす

SuiteFlowで作れるものと、SuiteScript（特にScheduledやMap/Reduce）が要るものに分かれます。

目安は「決まった時刻に動くか、出来事をきっかけに動くか」「処理が簡単か、複雑か」です。

外部システムとの連携

第5章のとおり、既製の手段を先に探し、足りない部分だけを作ります。

連携はカスタマイズの中でも難しい領域のため、要件の段階から保守の体制まで決めておきます。

判断の物差し｜標準で済ませるか、開発するか

多くの担当者が悩むのは、どこまでを標準で済ませ、どこから開発するかの線引きです。

Fit to Standardとクリーンコア

• Fit to Standard：業務を製品の標準の機能に合わせる考え方
• クリーンコア：ERPの本体への作り込みを最小にする設計の考え方

標準の機能をできるだけそのまま使い、自社に固有の事情がある部分だけを最小のカスタマイズで補う。

これが、NetSuiteを長く健全に使うための基本です。

カスタマイズは運用の負債にもなりうる。

この感覚を、最初に持っておくことが大切です。

「うちは特殊だから」が出たときこそ立ち止まる

本当に特殊な業務もあります。

ただ多くの場合、「担当者が慣れたやり方が、たまたまそうだった」だけのこともあります。

まず標準に合わせてみる。合わせてみて本当に困ったら、その部分だけを作る。

この順番で、要らない開発を避けられます。

たとえば「うちの請求は特殊だ」という声があったとします。

中身を書き出すと、締めの日が取引先ごとに違うだけ、ということがあります。

それなら、日本向けの機能の設定で足りるかもしれません。

一方、取引先との契約で決まった独自の計算がある場合は、本当に固有の事情です。

書き出してから判断するだけで、作るものは大きく減ります。

比較表②：業務の領域別の目安

業務の領域	標準で済みやすいケース	開発が要りやすいケース	判断の目安
承認の流れ	申請→上長の承認→完了	部門・金額・案件の種類でルートが大きく変わる	SuiteFlowの標準の機能で組めるか
帳票	標準の見積書・請求書	日本の締めの請求書、取引先ごとの様式	取引先と合意した様式があるか
集計	保存検索・ダッシュボード	複数の機能をまたぐ複雑な集計、毎日の一括の処理	月1回以下なら標準で足りることが多い
外部連携	既製のSuiteApp・標準のコネクタ	自社独自のシステム・古いシステム	既製のSuiteAppが先にないか
業務の流れ	業界の標準の流れ	自社に固有の流れ	「なぜこの流れか」を説明できるか
画面	ロール別の標準のダッシュボード	役職別の特殊な表示、業務で変わるフォーム	業務の担当者から強い要望があるか

保存検索（Saved Search）は、条件を保存して何度でも使える、NetSuiteの検索の機能です。

使い方は簡単です。

各領域で「左の列で済むか」をまず問います。

済まないときに「中央の列のような固有の事情が本当にあるか」を問います。

両方を経て残ったものだけを作ります。

2つの問いを図にすると、次のとおりです。

帳票は、NetSuiteの帳票カスタマイズ完全ガイドで詳しく扱っています。

Fit&Gapの進め方はNetSuite導入のFit&Gap分析をご覧ください。

3段で着地させる

標準で足りない要件は、次の3段で着地させます。

1. いま標準でできること：設定・SuiteFlow・既製のSuiteAppで解く
2. 開発で補えること：SuiteScriptで作る。ベンチャーネットは「NetSuiteリブート」として開発で補う支援をしています
3. 順次の提供を待つこと：提供元の更新で入る見込みがある機能は、無理に作らない

日本向けの機能は、Japan Localization SuiteAppで扱います。

Oracleのヘルプでは、新しく用意された日本版（Japan Edition）のアカウントには最初から入っているとされています。

（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）

自社で作る前に、この中で足りるかを先に見ます。

中身はJapan Localization SuiteAppとはで扱っています。

NetSuiteで作らない選択肢

すべてをNetSuiteの中で作る必要はありません。

選択肢	合う条件
NetSuiteの中で作る	会計・在庫など基幹のデータと強く結びつく処理
既製のSuiteAppや外部のSaaS	経費精算・電子契約など、専門の製品が既にある業務
AIスクラッチ開発で周辺に作る	基幹の外にある、自社独自の業務の画面や処理
いまは作らない	業務の見直しや運用のルールで解ける

AIでの開発とERPの考え方は、AIでスクラッチ開発とERP、どちらを選ぶべきかで扱っています。

経費精算など外部のSaaSとのつなぎ方は、NetSuiteと経費精算SaaSをどうつなぐかで扱っています。

費用と期間を左右する要素

カスタマイズの費用は、作る物の「大きさ」だけでは決まりません。

次の要素で、作る時の費用と、持ち続ける費用が変わります。

要素	費用が小さく済む場合	費用が膨らむ場合
手段	設定・SuiteFlowで済む	SuiteScriptでの開発、外部との連携
例外の数	例外が少なく、流れが一本道	部門・金額・取引先ごとに例外が多い
つながる機能	1つの機能の中で完結する	会計・在庫など複数の機能にまたがる
テスト	業務の筋書きが少ない	確かめる筋書きが多く、担当者も多い
保守	社内で直せる	書いた人しか直せない

作る時の見積もりだけでなく、更新のたびの点検と、直す時の費用まで含めて比べます。

5年・10年で見ると、持ち続ける費用のほうが大きくなることもあります。

作るほど費用が膨らむことは、実際の導入の費用にも表れます。

ベンチャーネットが支援したNetSuite導入の費用では、100名程度で外部システム連携とアドオン開発を含めた事例が2億円程度でした。

そのうち約7割が開発の費用です。

一方、3名程度・購買・販売だけで、アドオン開発のない事例は、1.5か月・150万円程度で稼働しています。

差を生んだ要因は、機能範囲・開発（特に外部システム連携）・社内の体制・ユーザー数の4つでした。

4事例の詳細は、NetSuiteの料金で扱っています。

判断は技術ではなく経営の問題

作るかどうかは、突き詰めると技術の問題ではありません。

「この業務の流れは、自社の競争力の源泉か」

「それとも、業界の標準に合わせて効率を上げるべき領域か」

この問いは、経営が答えるものです。

「現場が困っているから作る」ではなく、「経営として、ここにお金をかける価値があるか」で決めます。

導入の全体の進め方は、NetSuite導入の流れで扱っています。

読者の二つの立場

これからNetSuiteを入れる会社

1. 要件を「標準で済む」「開発が要る」「作らない」に分ける
2. 開発が要るものは、SuiteFlowで済むかを先に確かめる
3. SuiteScriptで作るものは、誰が保守するかまで決める
4. 開発の成果物（コードと説明の資料）を契約に書く

要件は、次の5つの項目で書くと、作るかどうかの判断がしやすくなります。

項目	書く内容	例
目的	経営にとって何が良くなるか	大口の受注の値引きを、部長が必ず確かめる
対象	どのレコード・どの業務か	受注の伝票
頻度	どのくらいの件数・回数か	月に約200件
例外	通常の流れから外れる場合	既存の取引先の定期の受注は除く
保守	誰が変更し、誰が確かめるか	情シスが変更し、営業部長が確かめる

（例の数字は架空です）

「目的」を経営の言葉で書けない要件は、作る前に一度立ち止まります。

作る時期を分ける

すべてを稼働の前に作る必要はありません。

1. 稼働の前：業務が止まるもの、法令や取引先との約束に関わるものだけを作る
2. 稼働から数か月：標準で使ってみて、本当に困った所を記録する
3. その後：記録をもとに、作るものを決める

使ってみると、要ると思っていた機能が要らなかった、ということはよくあります。

稼働の前に作る量を絞ると、最初の費用と、稼働の遅れの危険の両方を抑えられます。

いま運用していて、カスタマイズが重くなった会社

導入から年数がたつと、ワークフローやスクリプトが増え、更新のたびの確認が重くなります。

次の順で見直します。

1. 棚卸し：ワークフローとスクリプトを一覧にし、使われていないものを見つける
2. 置き換え：標準の機能や既製のSuiteAppで置き換えられるものを探す
3. まとめ：同じ論理のワークフローを1つにまとめる（第9章の失敗2）
4. 体制：コードと資料が手元にあるか、誰が直せるかを確かめる

棚卸しで見つけたものは、次の3つに分けます。

分け方	当てはまるもの	次の一手
残す	目的がはっきりし、今も使われ、直せる人がいる	資料を整え、版の管理に載せる
置き換える	標準の機能や既製のSuiteAppで同じことができる	置き換えの時期を決め、並行で試す
止める	使われていない、目的が分からない	関係者に確かめたうえで止める。すぐ消さず、一定期間は残す

「止める」は、いきなり削除しないことが大切です。

止めた後に困る人がいないかを、一定の期間見てから消します。

書いた人しか直せないスクリプトが残っている場合は、保守の体制から見直します。

今のパートナーで対応が難しい場合は、パートナーの変更も選択肢です。

考え方はERP導入失敗の原因はパートナーにあり？で扱っています。

よくある失敗3つ

ERP導入全体の失敗の型は、NetSuite導入でよく受ける質問33問と回答で扱っています。

ここでは、カスタマイズそのものから起きる失敗に絞ります。

失敗1：SuiteScriptが特定の人に依存する

起きること：「あのスクリプトは、書いた担当者しか触れない」。担当者の異動や退職で、運用が止まる。

説明の資料が残っておらず、引き継ぎができない状態になっている現場は少なくありません。

パートナーに頼んで作った場合でも、コードが手元になければ同じことが起きます。

原因：JavaScriptは自由度が高く、書き手の癖が出やすい。説明の不足、名前の付け方の不統一、テストの未整備が重なった。

避け方：

• 説明の書き方・名前の付け方・テストを決めた開発の標準を定める
• パートナーに頼む場合は、コードと説明の資料の納品を契約に書く
• 月に1回ほど、社内でコードを互いに読み合う場をつくる
• SuiteCloud Development Framework（SDF）を使い、コードと設定を自社の版の管理の仕組みで持つ

SDFは、手元の開発環境でカスタマイズを作り、開発・サンドボックス・本番のアカウントに配置できる仕組みです。

Oracleのヘルプでは、独自のオブジェクトをXMLのファイルとコードで持てると説明しています。

自社の版の管理の仕組みで、変更を追えます（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。

ベンチャーネットは、将来の内製化を目指す会社には、作業の録画・資料づくり・レクチャーで技術の引き継ぎをしています。

失敗2：SuiteFlowを作りすぎる

起きること：誰が何のために作ったか分からないワークフローが並び、更新のたびに確認が膨らむ。

重なったワークフロー、もう使われていないワークフロー、目的の分からないワークフローが入り混じります。

同じレコードに複数のワークフローが動き、思わぬ順番で項目が書き換わることもあります。

原因：「ノーコードで簡単だから」と、業務の担当者が自由に作った。

避け方：Oracleのヘルプでは、SuiteFlowのベストプラクティスとして次が挙げられています。

（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）

• 同じ論理と機能を持つ複数のワークフローは、1つにまとめる
• 実行の文脈とイベントの種類で、動く場面を絞る
• あまり変わらないデータに対するスケジュール型のワークフローは、イベント型に変える

あわせて、社内のルールを決めます。

• 名前の付け方と、作る前の申請の手順を決める
• 四半期に1回、使われていないワークフローを止める
• 「自由に作ってよいもの」ではなく「設計が要るもの」として扱う

失敗3：更新前・変更前の確認を省く

起きること：年2回の更新や、ちょっとした変更の後に、本番の業務が止まる。承認の流れの小さな修正が、会計の仕訳に響くこともある。

原因：「クラウドだから何もしなくていい」「ちょっとした変更だから」という油断。NetSuiteは全業務がつながっているため、1か所の変更が思わぬ所に響く。

更新では、APIの仕様の変更や、古い機能の廃止が起きることもあります。

確認をせずに本番の更新を迎えると、まれに業務が止まる危険が表に出ます。

避け方：確認のための環境を使い分けます。

• サンドボックス：本番と同じ設定・データ・カスタマイズを持ち、本番に影響せず試せる環境。本番から更新もできる
• Release Preview：新しい版への更新の前に、自社の業務の流れとカスタマイズが動くかを試す環境

どちらもOracleのヘルプで案内されています（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。

サンドボックスの取得は、アカウントの担当に問い合わせるよう案内されています。

確認は「システムが動くか」だけでなく、業務が回るかで行います。

実際の業務の担当者が、業務の筋書きに沿って確かめる受入テスト（UAT）を必ず通します。

サンドボックスはNetSuiteのサンドボックスとは？、更新への備えはNetSuiteのバージョンアップへの備え方で扱っています。

カスタマイズは「ITの作業」ではない

3つの失敗に共通する根本の原因は、カスタマイズをITの作業として扱うことです。

カスタマイズは、業務の流れを変える行為です。

「営業と経理のどちらの要件を優先するか」「どこまでお金をかけるか」。

こうした判断は、現場の担当者だけでは下せません。

経営層が「なぜこのカスタマイズが要るか」を語れる状態であること。

それが、長く健全にNetSuiteを使うための近道です。

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

ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。

カスタマイズの相談で最初に聞くのは、「その業務は、自社の競争力の源泉ですか」という問いです。

標準に合わせる／開発する／残す｜見える化の後に決める

作るかどうかは、要望の一覧からは決めません。

まず、いまの業務の流れを現場に聞いて描きます（見える化）。

次に、やめる業務・まとめる業務・そろえる業務を決めます（整理整頓）。

残った業務を、NetSuiteの標準機能と照らし合わせます（Fit&Gap）。

標準で収まらない業務は、3つから選びます。

• 標準に合わせる：業務のやり方を変える。競争力の源泉でない業務の基本
• 開発する：SuiteFlow、SuiteScriptの順に、軽い手段から当てる
• 残す：NetSuiteの中で作らない。既製のSaaS、周辺のAIスクラッチ開発、いまの運用のまま

第7章の「うちは特殊だから」の見分けも、この見える化の中で行います。

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

誰が何を担うかを、作る前に決める

担い手	担うこと
日本オラクル	ライセンス・トレーニング・製品サポート
ベンチャーネット	要件定義・設定・カスタマイズ・アドオン開発・保守・PM
自社	作るかどうかの判断、受入テスト、内製する範囲の運用

要件を聞くのは、営業ではなく導入コンサルタントです。

伝言を挟まないぶん、「この要件は標準で実現できます」と、その場で言えます。

契約は、請負契約に対応しています（準委任も相談可）。

稼働後は、頼みたい作業の量に合わせて形を選べます。

• 運用保守の契約（月額）：稼働後の継続的な伴走の基本の形
• 都度の見積もり：大きな追加の開発が出たとき
• チケット制：パートナーの変更を考える会社が、お試しとして必要な作業分だけ頼む形

技術の引き継ぎでは、作業の録画、手順の資料、操作のレクチャーで社内にノウハウを残します。

内製と外注の分け方の目安は、次のとおりです。

範囲	内製に向く	外注に向く
項目・フォーム・保存検索	業務に合わせて頻繁に変える	―
SuiteFlow	単純な承認や通知	例外が多い流れ、複数のワークフローが絡むもの
SuiteScript	社内に開発者がいて、標準が決まっている	開発者がいない、外部との連携
更新前の点検	業務の筋書きでの点検	スクリプトの動作の点検

最初に投げかける問いは、次の3つです。

• その業務は、競争力の源泉か
• 作るなら、誰が保守し、コードと資料をどこに置くか
• 更新のたびに、誰がどの環境で動きを見るか

今日できること｜カスタマイズの棚卸し表を作る

いま使っている、またはこれから作ろうとしているカスタマイズを、次の表に書き出してみてください。

名前	種類（項目・ワークフロー・スクリプト・連携）	目的	作った人・直せる人	最後に使われた時期
（例）受注承認	ワークフロー	100万円以上の受注を部長が承認	情シスのAさん	毎日

「直せる人」が1人だけの行と、「最後に使われた時期」が分からない行に印をつけます。

印の多い行が、運用の負債になりやすい所です。

これから作るものは、「目的」の欄を経営の言葉で書けるかを見てください。

表ができたら、印のついた行から1つだけ選び、次の3つを問います。

• 標準の機能で同じことができないか
• 同じことをしている別のワークフローやスクリプトがないか
• 止めた場合に、誰が困るか

1時間あれば、最初の1行の答えは出せます。

その答えが、見直しをどこから始めるかの手がかりになります。

よくある質問

Q1. SuiteFlowとSuiteScriptはどう使い分けますか

業務の担当者でも作れて保守できる範囲はSuiteFlowです。

コードでの開発が要る範囲はSuiteScriptです。

全体の流れはSuiteFlowで組み、一部のアクションをWorkflow Actionスクリプトで作る組み合わせもできます（第4章）。

Q2. カスタマイズは、更新のときにどうなりますか

新しいバージョンへ引き継がれます。

Oracle NetSuite公式のFAQに、その旨が書かれています。

ただし動きが変わることもあるため、サンドボックスやRelease Previewで確かめてから本番を迎えます（第9章）。

Q3. 社内に開発のスキルがなくてもカスタマイズできますか

SuiteBuilderとSuiteFlowの範囲なら扱えます。

業務の担当者でも、設定と簡単なワークフローは作れます。

SuiteScriptは開発のスキルが要るため、パートナーの支援が前提です。

段階的に内製化することもできます。

まず項目やフォームの調整から社内で担い、慣れたら単純なワークフローへ広げる順番が無理がありません。

Q4. カスタマイズの費用はどのくらいですか

内容と規模で大きく変わります。

SuiteFlowの構築・SuiteScriptの開発・帳票の調整・外部連携で、工数が違います。

NetSuite本体の費用は、ミニマム構成で月額20万円〜が出発点です。

構成で変わり、数百万円規模になることもあります。最終的な金額はOracleの営業が提示します。

ベンチャーネットの支援事例には、導入費用2億円程度のうち約7割が開発だった例があります（7-5）。

カスタマイズの支援は、月額の運用保守の契約のほか、都度の見積もりやチケット制で頼む形もあります（第10章）。

Q5. カスタマイズと標準の機能、どちらを優先しますか

標準の機能を優先するのが基本です。

作るほど、運用の負担と更新の確認と人への依存が増えます。

「うちは特殊だから」が出たときこそ、標準で見直す価値があります（第7章）。

Q6. SuiteAppとカスタマイズは何が違いますか

SuiteAppは既製の拡張アプリです。

カスタマイズは、自社に合わせた追加の開発です。

既製のSuiteAppで足りるなら、作る前にそちらを検討します。

既製のものは提供元が更新に合わせて直すため、自社で保守する負担が小さくなります。

選び方はNetSuite SuiteApp.comの選び方で扱っています。

Q7. AIを使ってNetSuiteを拡張できますか

できます。

Custom Toolスクリプトで外部のAIから呼べるツールを作れ、N/llmモジュールでスクリプトから生成AIを使えます（第4章）。

AIで開発を支援する道具は、NetSuite Developer Assistantとはで扱っています。

Q8. 承認のワークフローをAIに作ってもらえますか

骨子の下書きまでは頼めます

状態・遷移・条件の案をAIに出させ、Sandboxで承認と却下を通してから本番に入れます（第6章）。

まとめ

• カスタマイズは、設定の変更・拡張・開発の3つの階層に分かれる
• 手段はSuiteBuilder・SuiteFlow・SuiteScript。できるだけ前の2つで済ませる
• 更新でもカスタマイズは引き継がれる。確認はサンドボックスとRelease Previewで
• 失敗は「人への依存」「作りすぎ」「確認の省略」。SDFと運用のルールで防ぐ
• 運用中の会社は、棚卸しで「残す・置き換える・止める」に分けるところから始める
• 作るかどうかは、経営としてお金をかける価値があるかで決める

「ノーコードなら、現場で増やしていけばいい」。

そう考える前に、1つだけ自問してください。

技術的にできるかではなく、経営としてやるべきか。

その答えが、ワークフローを資産にするか負債にするかを分けます。

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

「ここは作るべきか、標準で済ませるべきか」と迷っている部分があれば、要件の整理からご相談をお受けしています。

• 標準で足りない部分を開発で補いたい方：NetSuiteリブート（アドオン開発サービス）
• 導入後の保守・帳票の調整・パートナーの変更を考えている方：NetSuite導入・伴走・保守サービス
• まず自社のケースで何ができるかを聞きたい方：お問い合わせ