SDF、ACP、SDN、Built for NetSuite、SuiteApp Control Center。
SuiteAppの開発を調べ始めると、似た言葉が9つも並びます。
「自社で作ったNetSuiteの機能を、ほかの会社にも使ってもらいたい」
カスタマイズを重ねてきた会社や、業務ソフトを作る会社で、こうした声が出ることがあります。
ところが、9つの言葉の前で手が止まる。
9つは、役割で分ければ3つに収まります。
そして最初の分かれ道は、1つだけです。
自社のアカウントだけで使うのか。それとも、他社へ配布するのか。
- 自社のアカウントだけで使うなら、SDNへの加盟は要りません
- 他社へ配布するなら、SDNへの加盟と、配布のための審査が前提になります
では、配布を選んだ会社は、公開した後に何を続ければよいのか。
答えは第4章の「確認の更新」にあります。
この記事で分かること
- SuiteApp開発に出てくる言葉の意味
- 自社用と配布用の分かれ道
- 他社へ配布するまでの流れと、公開後の更新
- SuiteBundlerからSDFへの移行の手順
- よくある3つの失敗と、作らない選択肢
言葉の整理：SuiteAppは、NetSuiteに機能を追加するアプリです。
NetSuiteの中で動くものもあれば、外部のサービスとNetSuiteをつなぐものもあります。
9つの言葉を、3つの役割に分ける
| 言葉 | 意味 |
|---|---|
| SuiteCloud | NetSuiteを拡張するための開発の基盤の総称 |
| SDF（SuiteCloud Development Framework） | カスタマイズやSuiteAppを、ファイルとして開発・管理する仕組み |
| SuiteBundler | 以前から使われてきた、カスタマイズをまとめて配る仕組み |
| ACP（アカウントカスタマイズプロジェクト） | SDFで、自社のアカウント向けのカスタマイズを作る単位 |
| SuiteAppプロジェクト | SDFで、配布用のSuiteAppを作る単位（SDN加盟者向け） |
| SDN（SuiteCloud Developer Network） | SuiteAppを開発する会社向けの、Oracleのパートナープログラム |
| Built for NetSuite（BFN） | SuiteAppの品質を確認する、NetSuiteの仕組み |
| SuiteApp Control Center | SuiteAppの配布を管理する場所 |
| SuiteApp Marketplace | NetSuiteの中で、SuiteAppを探して入れる場所 |
役割で分けると、次の3つです。
- 作る道具：SDF（と、以前のSuiteBundler）
- 作る単位：ACPとSuiteAppプロジェクト
- 配る仕組み：SDN・Built for NetSuite・SuiteApp Control Center・SuiteApp Marketplace
最初の分かれ道｜自社用か、配布用か
Oracleのヘルプでは、SDFのプロジェクトを2つに分けて説明しています。
- ACP：本番・開発・サンドボックスなど、自社が持つアカウントのカスタマイズ用
- SuiteAppプロジェクト：SDNの加盟者が、SuiteAppを開発して配るため
出典はOracle NetSuite ヘルプ（SDFのプロジェクトの種類）です（2026年9月23日確認）。
サンドボックスは、本番に影響を与えずに試せる、NetSuiteの検証用のアカウントです。
| 観点 | 自社用（ACP） | 配布用（SuiteAppプロジェクト） |
|---|---|---|
| 使う相手 | 自社のアカウントだけ | 他社のアカウント |
| SDNへの加盟 | 要らない | 前提 |
| 配布の審査 | なし | Marketplaceに載せるには審査がある |
| 更新の手間 | 自社の都合で進められる | 利用する会社への影響を考えて進める |
グループ会社の複数のアカウントで同じカスタマイズを使う場合も、自社が持つアカウントなら、まずACPで考えます。
SDNを検討する分かれ目は、「他社に配るか」です。
AIを使った開発と、SDFの相性
SDFでは、カスタマイズの中身をファイルとして持ちます。
ファイルで持てると、変更の履歴を残したり、生成AIにコードを読ませたりしやすくなります。
この点は、自社用でも配布用でも同じです。
ただ配布用では、AIが書いたコードも、審査の基準に沿って点検する手間が残ります。
NetSuiteの開発を手伝うAIの仕組みは、NetSuiteのAI開発支援で扱っています。
画面の操作だけで作ったカスタマイズは、AIに中身を渡しにくい点に注意が要ります。
自社用から始めて、配布用へ進む場合
自社用として作ったものを、後から他社にも配りたくなることがあります。
その場合は、次の3つを見直します。
- 自社だけの前提：自社の勘定科目や承認の流れを、そのまま組み込んでいないか
- 設定の置き場所：会社ごとに変えたい値を、コードの中に直接書いていないか
- 説明の資料：自社の担当者でなくても、使い方が分かる資料があるか
自社用のカスタマイズは、自社の業務に合わせて作り込まれていることが多いものです。
そのまま配ると、利用する会社ごとに手直しが要ります。
前提を取り除く手間が大きいなら、配布用として作り直すほうが早いこともあります。
他社へ配布するまでの流れ
配布用のSuiteAppは、公式情報によると次の順で進みます。
| 段階 | やること | 公式の根拠 |
|---|---|---|
| ① SDNに加盟する | プログラムの契約を結び、開発用のアカウントを受け取る | SDNの公式ページ |
| ② SDFで作る | SuiteAppプロジェクトとして開発する | SDFのヘルプ |
| ③ 配布の準備をする | SuiteApp Control Centerにプロジェクトを上げ、版を作る | SuiteApp Control Centerのヘルプ |
| ④ 審査を受ける | SDNによる掲載の承認と、Built for NetSuiteの確認を受ける | Marketplace掲載のヘルプ |
| ⑤ 公開する | SuiteApp Marketplaceに載せ、利用する会社が入れられるようにする | 同上 |
| ⑥ 更新し続ける | NetSuiteの更新に合わせて、動作と確認を更新する | Built for NetSuiteの公式ページ |
SDNに加盟する
SDNは、NetSuiteを拡張するアプリを作る開発者向けの、Oracleのパートナープログラムです。
公式ページでは、開発用のアカウント、ロードマップの共有、SuiteApp.comへの掲載などの特典が案内されています。
出典はSDNの公式ページです（2026年9月23日確認）。
加盟には年会費がかかります。
金額と条件は、公式ページで見てください。
なお、ベンチャーネットが認定を受けているSolution Providerは、NetSuiteの導入や販売を担うパートナーの枠組みです。
SuiteAppの開発者向けのSDNとは、別のプログラムです。
Marketplaceに載せるための3つの条件
Oracleのヘルプでは、SuiteApp Marketplaceに載せる条件として、次の3つを挙げています。
- 公開した版が、少なくとも1つあること
- SDNが、掲載を承認すること
- Built for NetSuiteの確認を受けること
出典はOracle NetSuite ヘルプ（Marketplaceへの掲載）です（2026年9月23日確認）。
審査にかかる期間や費用は、公式情報では分かりませんでした。
計画を立てる前に、SDNの窓口に問い合わせてください。
配布の後の更新
SuiteApp Control Centerは、SuiteAppの配布の手順をまとめて管理する場所です。
配布したSuiteAppには、利用する会社の側で自動で更新されるものと、手動で更新するものがあります。
出典はOracle NetSuiteのヘルプ（SuiteApp Control Center）です。
どちらで配るかで、利用する会社への案内の仕方が変わります。
配布の前に、更新の方針を決めておきます。
配布用で、作る前に決めておく4つのこと
| 決めること | 中身 | 決めないと起きること |
|---|---|---|
| 対象の業務の範囲 | どの業務の、どこまでを受け持つか | 利用する会社ごとの要望で、機能が広がり続ける |
| 設定で変えられる範囲 | 会社ごとの違いを、設定で吸収するか | 会社ごとに個別の改修が要る |
| 問い合わせの窓口 | 利用する会社からの質問を、誰が受けるか | 開発の担当者に問い合わせが集中する |
| 更新の方針 | 自動で更新するか、手動で更新するか | 利用する会社の業務を、更新で止めてしまう |
配布用ならではの論点は、2つ目の「設定で変えられる範囲」です。
自社用なら、自社の業務に合わせて作り込めます。
配布用では、会社ごとの違いを設定で受け止める設計が要ります。
Built for NetSuiteの確認
Built for NetSuiteは、SDNのパートナーのSuiteAppについて、NetSuiteが確認と助言を行う仕組みです。
対象は、セキュリティ・データの保護・全体の品質です。
公式ページでは、確認の手順として次の3つが挙げられています（Built for NetSuite公式ページ、2026年9月23日確認）。
- 要件を満たしていることを示す質問票を出す
- 顧客からの肯定的な評価（リファレンス）を示す
- NetSuiteのSDNチームに、製品を実演する
3つの型
確認には、SuiteAppのつくりによって3つの型があります。
| 型 | つくり | 確認の対象 |
|---|---|---|
| Native | すべてがNetSuiteの基盤の上にある | SuiteApp全体 |
| Integrated | 大半が外部にあり、NetSuiteとデータ連携する | 連携の部分 |
| Hybrid | NetSuiteの中と外の両方に部品がある | 中の部品と連携の部分 |
外部のサービスとNetSuiteをつなぐSuiteAppは、IntegratedやHybridに当たります。
連携の部分では、認証の方式も確認の対象です。
認証の今後の変更は、NetSuiteの認証方式の移行で扱っています。
公開後は、大きなリリースごとに確認を更新する
冒頭の問いの答えは、ここにあります。
公式ページには、Built for NetSuiteの認定の表示は、NetSuiteの大きなリリースごとに更新が要ると書かれています。
要件を満たさなくなった場合は、取り消されることもあります。
一度通れば終わり、ではありません。
公開した後は、次の段取りを毎回のリリースで回します。
- NetSuiteの大きな更新の前に、新しい版を先に試せる期間を使う
- その期間に、SuiteAppの動作を点検する
- 問題が見つかれば直し、Built for NetSuiteの要件も見直す
- 利用する会社に、更新の中身と時期を案内する
点検する担当者と、直す担当者は、あらかじめ分けて決めておきます。
利用する側の視点ですが、更新への備え方はNetSuiteのアップグレード準備も参考になります。
作る側も、同じ時期に同じ点検を行うと考えると、計画が立てやすくなります。
SuiteBundlerからSDFへ
以前から使われてきたSuiteBundlerについて、Oracleのヘルプは次のように案内しています。
- SuiteBundlerは、もう更新されていない
- 開発と配布での利用から、できるだけ早く移るべき
- SDF・SuiteApp Control Center・Copy to Accountの機能を活用できる
出典はOracle NetSuite ヘルプ（SuiteBundlerからの移行）です（2026年9月23日確認）。
既存のバンドル（SuiteBundlerでまとめたもの）は、SDFのACPに変換できると案内されています。
これから作るSuiteAppは、最初からSDFで作ります。
移行の手順
移行は、一度に全部を行う必要はありません。
次の順で進めると、業務への影響を小さくできます。
- SuiteBundlerで作ったものを、一覧にする
- それぞれ、今も使っているかを調べる
- 使っていないものは、移行せずに整理する
- 変更の予定があるものから、SDFへ移す
- 移したものは、サンドボックスで動作を見てから本番へ反映する
一覧にすると、使われていないカスタマイズが見つかることもあります。
移行は、カスタマイズを棚卸しする機会にもなります。
よくある3つの失敗
失敗1：自社用の機能を、最初から配布用として作る
起きること：自社のために作りたい機能だったのに、SDNへの加盟や審査の準備に時間を取られ、肝心の業務の改善が進まない。
原因：「いずれ他社にも配るかもしれない」と考え、配布用の流れで作り始めた。
避け方：まずACPで自社用として作り、業務で効果を見ます。
他社に配る価値が見えてから、配布用に作り直すかを決めます。
失敗2：SuiteBundlerで作り続ける
起きること：以前のやり方のまま、SuiteBundlerでカスタマイズを配っている。新しい配布の機能が使えず、移行の作業が後からまとめて発生する。
原因：動いているものを変えたくないという理由で、移行を先送りした。
避け方：新しく作るものはSDFで作ると決めます。
既存のものは、変更の予定がある順に移します。
失敗3：公開した後の更新の体制がない
起きること：SuiteAppを公開した後、NetSuiteの更新で動作が変わった。点検と修正の担当がおらず、利用する会社から問い合わせが続く。
原因：公開までを計画し、公開の後の更新を計画に入れていなかった。
避け方：NetSuiteのリリースごとに、動作を点検する担当と期間を決めます。
Built for NetSuiteの更新も、同じ計画に入れます。
ベンチャーネットならこう見る
SuiteAppを自社で作ることが、いつも最善とは限りません。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、作る前に2つの型で考えます。
型1：標準に合わせる／開発する／残す
作りたい機能を、まず3つのどれかに決めます。
| 決め方 | SuiteAppで言うと | 次の一手 |
|---|---|---|
| 標準に合わせる | 既存のSuiteAppや標準機能で足りる | SuiteApp.comで同じ目的のものを探す |
| 開発する | 自社用ならACP、配布するならSuiteAppプロジェクト | 第2章の分かれ道へ |
| 残す | 連携サービスや、いまの運用で済ませる | 連携を作るか買うかを比べる |
既存のSuiteAppの選び方はSuiteApp.comの選び方で、連携を作るか買うかは連携は作るか買うかで扱っています。
連携が目的なら、連携サービスを使うほうが保守の負担が軽いこともあります。
作りたいものから次の一手を引けるよう、図にまとめます。
型2：見える化→整理整頓（移行と棚卸し）
SuiteBundlerからの移行は、ベンチャーネットの進め方の前半2段と同じ形をしています。
まず、いまあるカスタマイズを一覧にして見える化する。
次に、使っていないものをやめ、残すものをそろえる。
SDFへ移すのは、その後です。
5-1の手順は、この順番をSuiteAppに当てはめたものです。
作る前に聞く問いは、1つに絞ります。
公開の後で誰が更新し続けるか。
配布用のSuiteAppは、作ることより、更新し続けることのほうが重い仕事です。
ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
特定の製品に誘導しない立場から、作るかどうかの判断も一緒に考えます。
今日できること｜作りたいものを1行で書く
次の表を、作りたい機能ごとに埋めてみてください。
| 作りたい機能 | 使う相手 | 既存のSuiteAppはあるか | 公開後の更新の担当 |
|---|---|---|---|
| （例）請求の締めの補助 | 自社のみ | 調べていない | 未定 |
「使う相手」が自社のみなら、ACPで進めます。
「公開後の更新の担当」が未定なら、配布用に進む前に決めておきます。
よくある質問
Q1. 自社のNetSuiteだけで使う機能を作るのに、SDNへの加盟は必要ですか
必要ありません。SDFのACPで作れます。
OracleのヘルプではACPを、自社が持つアカウントのカスタマイズ用と説明しています（第2章）。
Q2. SuiteApp Marketplaceに載せるには、何が必要ですか
公開した版・SDNの承認・Built for NetSuiteの確認の3つです。
Oracleのヘルプで、この3つが条件として挙げられています（3-2）。
Q3. Built for NetSuiteは、一度取れば終わりですか
いいえ。NetSuiteの大きなリリースごとに更新が要ります。
要件を満たさなくなった場合は、取り消されることもあります（4-2）。
Q4. SDNの年会費や、審査の期間はどのくらいですか
年会費はSDNの公式ページに載っています。
審査の期間や費用は、公式情報では分かりませんでした。
SDNの窓口に問い合わせてください（第3章）。
Q5. SuiteBundlerで作ったカスタマイズは、使えなくなりますか
Oracleは早めの移行を勧めています。
SuiteBundlerは、もう更新されていません。
既存のバンドルは、SDFのACPに変換できると案内されています（第5章）。
Q6. Solution ProviderとSDNは、同じプログラムですか
別のプログラムです。
Solution Providerは導入や販売を担うパートナー、SDNはSuiteAppを開発する会社向けのプログラムです（3-1）。
Q7. SuiteAppの開発に、生成AIは使えますか
SDFで作ると生成AIにコードを読ませやすくなります。
SDFでは、カスタマイズをファイルとして持つためです。
ただし、AIが書いたコードも、サンドボックスでの点検とBuilt for NetSuiteの基準での点検が要ります（2-1）。
まとめ：配るかどうかで、道が分かれる
- 最初の分かれ道は、自社用か、他社へ配布するか
- 自社用なら、SDFのACPで作る。SDNへの加盟は要らない
- 配布用なら、SDNへの加盟・SuiteAppプロジェクト・SuiteApp Control Centerの流れ
- Marketplaceに載せるには、SDNの承認とBuilt for NetSuiteの確認が要る
- Built for NetSuiteは、大きなリリースごとに更新する
- SuiteBundlerは更新されていない。これから作るものはSDFで
SuiteAppは、公開した日から保守が始まります。
まずは第8章の表で、「公開後の更新の担当」の欄を埋めてみてください。
そこが空欄のうちは、自社用のACPから始めるのが近道です。
もう少し詳しく知りたい方へ
「自社用で作るか、配布用で作るか」の判断から、ご相談をお受けしています。
既存のカスタマイズをSDFへ移す計画づくりも、一緒に考えます。
