NetSuiteの権限とロール設計は、「どの種類の記録を扱えるか」を決める権限と、「そのうちどの記録まで届くか」を決める制限の2層で組み立てます。本記事では、権限レベル5段階の違い、OneWorldの子会社制限と部門・クラス・場所の制限の設定手順、経理や購買で職務分掌を崩さないロールの切り方、SDFのcustomrole XMLでロールをコード管理する方法、SuiteScriptでログイン中ロールの権限を判定するコードまでを、2026年10月時点のOracle公式ヘルプに沿って整理します。アクセス権限の共有や、子会社をまたいで閲覧だけ許す設定も、この流れの中に含めました。
まとめ：NetSuiteの権限は権限レベルと制限の2層で決め、子会社の既定値を必ず確認する
ロールに付ける権限は、取引・一覧・レポート・設定などの種類ごとにView／Create／Edit／Fullの4段階（付けなければNone）で決めます。そのうえで、子会社・部門・クラス・場所の制限で、届く記録の範囲を絞る設計です。権限だけ整えて制限を空けたままにすると、他社や他部門の伝票まで見える状態で稼働します。
見落としやすいのは子会社制限の既定値です。画面で新しく作るロールはUser Subsidiary（自分の子会社だけ）で始まりますが、SDFのXMLでsubsidiaryoptionを書かずに配布すると既定値はALLです。コードで管理するなら、この要素は省略しません。
ロールは業務単位で切り、起票と支払・承認を同じロールに置かない設計表を先に作ります。連携やスクリプトの実行ロールにAdministratorを使わないことも、稼働前に決めておく項目です。
NetSuiteのロールと権限の仕組みを権限レベルと制限の2層で読み解く
最初に押さえるのは、権限と制限が別の設定だという点です。Oracleの公式ヘルプ「Permissions and Restrictions」は、権限を「特定の記録の種類へのアクセスを与えるもの」、制限を「権限を与えたうえで、その種類のどのインスタンスにアクセスできるかを定めるもの」と定義しています。
権限レベルNone・View・Create・Edit・Fullの違いと付与の単位
権限は「請求書」「仕訳入力」「仕入先」のような記録の種類ごとに、レベルを選んで付けます。上の段階ほど扱える操作が増えます。
| レベル | できること | 付ける場面の例 |
|---|---|---|
| None | アクセスなし | 担当外の記録 |
| View | 参照と検索、印刷 | 監査・照会担当 |
| Create | 新規作成（既存の更新は不可） | 起票だけする担当 |
| Edit | 作成と既存の更新 | 日常の入力担当 |
| Full | 削除を含む全操作 | 例外扱いの管理者 |
実務の基本はEditまでで止め、Fullは理由を書ける場合だけにします。Oracle公式のSuiteCloud SDKリポジトリの権限リファレンスも、用途を満たす最小のレベルを選び、Fullは例外として明示的に正当化するよう求めています。
制限は「どの記録まで」を決める層、作成できても見えない記録の条件
同じ公式ヘルプには、制限のかかった記録の種類にCreateやFullを持つユーザーは新しい記録を作って保存できても、作った記録を参照できないと書かれています。権限レベルが高くても、制限の外にある記録は見えません。
経理担当に仕訳のEditを渡し、部門制限を「自部門のみ」にした場合を考えます。他部門の部門コードで仕訳を起こすと保存は通り、保存直後から本人の一覧に出てきません。稼働後に「入力したのに消えた」ように見える現象は、この2層のずれで説明がつきます。
標準ロールはCustomizeで複製し、従業員に複数ロールを割り当てる
標準ロールは直接編集せず、Setup > Users/Roles > Manage Rolesで対象ロールの「Customize」を押して複製し、複製したカスタムロールを編集します。公式ヘルプ「Employee Users」によると、ロールは従業員レコードのAccessサブタブにあるRolesで割り当て、1人に複数のロールを付けられます。割り当ての変更を確認できるのはHistoryサブタブです。
Global Permissions機能を有効にすると、従業員ごとに直接権限を付けることもできます。ただし、ロールの権限と衝突した場合はこちらが優先され、Oracle自身が「推奨しない」と明記しています。個人単位の例外は監査で追いにくくなるため、例外用の小さなロールを作って割り当てるほうが管理しやすい設計です。
子会社・部門・クラス・場所の制限を設定してロールの可視範囲を絞る手順
部門や子会社をまたぐ会社で、権限設計の手間の大半はこの章の設定に集まります。設定はいずれもロールのRestrictionsサブタブで行います。
OneWorldの子会社制限4択の選定基準と所属・担当会社による可視範囲
複数の子会社を1つのアカウントで扱うOneWorldでは、ロールごとに届く子会社を決めます。公式ヘルプ「Restricting Role Access to Subsidiaries」が示す選択肢は4つで、既定値はUser Subsidiaryです。
| 選択肢 | 届く範囲 | 向くロール |
|---|---|---|
| All | 無効な子会社を含む全社 | 連結・監査 |
| Active | 有効な子会社のみ | 本社の経理統括 |
| User Subsidiary | 従業員レコードの所属子会社 | 各社の経理・営業 |
| Selected | 指定した子会社（複数可） | 地域統括・シェアード |
User Subsidiaryは従業員レコードに設定した子会社を見るため、出向や兼務で所属を変えると、そのまま見える範囲も変わります。グループ内の経理を1か所で処理するシェアードサービスでは、Selectedで担当会社を列挙するほうが、人事異動のたびに範囲が揺れません。
部門・クラス・場所の制限3種と「Allow Viewing」で閲覧だけ広げる設定
公式ヘルプ「To Set Role Restrictions」の手順は次のとおりです。
- Setup > Users/Roles > Manage Rolesで、標準ロールなら「Customize」、カスタムロールなら「Edit」を押す
- Restrictionsサブタブを開き、SegmentでClass・Department・Locationのいずれかを選ぶ
- Restrictionsで「none – default to own」「own, subordinate, and unassigned」「own and subordinates only」から選ぶ
- 閲覧だけ許すならAllow Viewing、品目にも制限をかけるならApply to Itemsにチェックを入れる
- OneWorldならSubsidiary Restrictionsを選び、必要に応じてAllow Cross-Subsidiary Record Viewingにチェックを入れて保存する
「none – default to own」は入力時に自分の部門が初期値として入るだけで、アクセスは絞りません。本当に絞るのは残りの2つで、部門未設定の記録まで見せるかどうかで選び分けます。Allow ViewingとAllow Cross-Subsidiary Record Viewingは「見せるが編集はさせない」ための設定で、権限を共有したいという要望の大半はこの2つで足ります。
制限の変更が効かない、給与が見えないときに確認する4つの仕様
設定したのに意図どおりに動かないとき、先に疑うのは不具合ではなく次の仕様です。
- 制限を変えたロールのユーザーは、いったんログアウトして入り直すまで変更が反映されない
- Allow ViewingとAllow Cross-Subsidiary Record Viewingを付けても、従業員の給与とコミッションのデータは見えない
- 勘定科目表で部門を割り当てていない勘定科目は、部門の制限の対象外になる
- ユーザーにBook Record Restrictionが有効だと、子会社をまたぐ閲覧の許可より優先される
1つ目は検証の手順に直結する仕様です。テスト用ユーザーでログインしたまま設定を直すと、変化が無いと見誤って正しい設定まで戻してしまいます。変更のたびに入り直す手順を、検証表に書いておきます。
職務分掌を崩さないロール設計表の作り方と経理・購買業務の権限例
ロールを人や役職で作ると、異動や兼務のたびに権限が足し算で膨らみます。業務の単位で切り、起票と支払・承認を分けるのが基本です。
業務単位でロールを切る設計表と、起票と支払を同じロールに置かない線引き
購買から支払までを例に、ロールと権限の対応を表にします。権限キーはOracle公式リポジトリが同梱する一覧で実在を確かめたものです。
| ロール | TRAN_PURCHORD | TRAN_VENDBILL | TRAN_VENDPYMT | LIST_VENDOR |
|---|---|---|---|---|
| 購買担当 | Edit | View | None | View |
| 買掛担当 | View | Edit | None | View |
| 支払担当 | None | View | Edit | View |
| 仕入先マスタ管理 | None | None | None | Edit |
線引きの基準は、1つのロールだけで「架空の仕入先を登録し、請求書を起こし、支払う」の3段階を通せないことです。仕入先マスタの編集を支払担当から外しているのはこのためです。承認の規程や不正防止の考え方は購買管理規程と内部統制、職務分掌の設計を解説した記事で扱っています。
連携用・スクリプト実行用ロールをAdministratorにしない理由と代わりの設計
外部システムとの連携やスクリプトの実行ロールは、つい管理者で動かしがちです。前出のOracle公式リファレンスは、スクリプトの実行ロールに本番でAdministratorを推奨してはならないと明記し、必要な権限だけを持つ専用ロールを勧めています。REST連携の専用ロールには、ADMI_RESTWEBSERVICESに加えて対象記録の権限が要るとされています。
専用ロールにすると、連携の資格情報が漏れたときに被害が届く範囲が、そのロールの権限と制限の内側に収まります。考え方はAWSの最小権限と同じで、AWS IAMのユーザー・ロール・ポリシーと権限設計を解説した記事の設計原則がそのまま当てはまります。認証やエラー処理を含む連携の組み方はREST・認証・エラー処理を扱うAPI連携の実装手順を参照してください。
SDFのcustomrole XMLでロールをコード管理し、環境差を無くす手順
サンドボックスで作ったロールを本番へ手作業で写すと、チェック1つの漏れで権限がずれます。SuiteCloud Development Framework（SDF）を使えば、ロールをXMLとして版管理し、同じ定義を配布できます。
customrole XMLの最小構成と権限キー・制限の書き方
公式ヘルプ「Custom Roles as XML Definitions」の例をもとに、前章の買掛担当を、日本子会社のみ・自部門のみ（閲覧は許可）で定義すると次のようになります。
<role scriptid="customrole_ap_clerk_jp">
<centertype>ACCOUNTCENTER</centertype>
<name>AP Clerk JP</name>
<subsidiaryoption>OWN</subsidiaryoption>
<subsidiaryviewingallowed>F</subsidiaryviewingallowed>
<restricttimeandexpenses>T</restricttimeandexpenses>
<permissions>
<permission>
<permkey>TRAN_VENDBILL</permkey>
<permlevel>EDIT</permlevel>
</permission>
<permission>
<permkey>TRAN_PURCHORD</permkey>
<permlevel>VIEW</permlevel>
</permission>
<permission>
<permkey>LIST_VENDOR</permkey>
<permlevel>VIEW</permlevel>
</permission>
</permissions>
<recordrestrictions>
<recordrestriction>
<segment>DEPARTMENT</segment>
<restriction>OWNONLY</restriction>
<viewingallowed>T</viewingallowed>
<itemsrestricted>F</itemsrestricted>
</recordrestriction>
</recordrestrictions>
</role>scriptidは40字までで、customroleで始めます。restrictionに書ける値はDEFAULTTOOWN・OWNONLY・UNASSIGNEDの3つで、画面の3択に対応する名前です。viewingallowedとitemsrestrictedは、restrictionがDEFAULTTOOWN以外のときだけ有効になります。なお公式ヘルプの例にはitemrestrictedと書かれた箇所があり、要素リファレンスのitemsrestrictedと表記が揺れているため、配布前にsuitecloud project:validateで検証を通します。
SDFで扱えない項目と、subsidiaryoptionの既定値ALLの落とし穴
同じ公式ヘルプによると、ロールのうちSubsidiaries欄（Selectedで選ぶ子会社の一覧）と、Forms・保存検索・Dashboardの各サブリストはSDFで定義できず、画面で設定します。子会社をSelectedで絞る設計なら、配布後に画面で子会社を選ぶ手順を移行手順書に残しておきます。
もう1つの落とし穴は既定値です。role要素のXMLリファレンスではsubsidiaryoptionの既定値がALLで、画面で新規作成したときのUser Subsidiaryとは逆です。XMLからこの行を削って配布すると、全子会社に届くロールができあがります。値はALL・ALLACTIVE・OWN・SELECTEDの4つで、使う場合はマニフェストでSUBSIDIARIES機能を参照します。
<manifest projecttype="ACCOUNTCUSTOMIZATION">
<projectname>erp-roles</projectname>
<frameworkversion>1.0</frameworkversion>
<dependencies>
<features>
<feature required="true">SUBSIDIARIES</feature>
</features>
</dependencies>
</manifest>権限の付与を受けるカスタムレコードなどのSDFオブジェクトとロールが互いを参照している場合、双方の権限と制限のレベルが一致しないとデプロイできません。ロールだけを先に直して配布が止まったら、相手側のXMLを確認します。
SuiteScriptでログイン中ロールの権限を判定し、処理を出し分ける実装
Suiteletやユーザーイベントスクリプトで、権限のないユーザーに処理を走らせないための判定も、ロール設計の一部です。画面で隠すだけでは、URLを直接開かれたときに防げません。
getPermission()でログイン中ロールの権限レベルを取得する実装例
公式リファレンス「User.getPermission(options)」によると、このメソッドは2015.2から使え、クライアントとサーバーの両方のスクリプトで動き、ガバナンスの消費はありません。引数には権限の内部ID（前章のTRAN_JOURNALなど）を渡します。仕訳のEdit以上を持つロールだけに処理を許すSuiteletは次のように書けます。
/**
* @NApiVersion 2.1
* @NScriptType Suitelet
*/
define(['N/runtime', 'N/error'], (runtime, error) => {
const P = runtime.Permission;
const ALLOWED = [P.EDIT, P.FULL];
const onRequest = (ctx) => {
const user = runtime.getCurrentUser();
const level = user.getPermission({ name: 'TRAN_JOURNAL' });
if (!ALLOWED.includes(level)) {
throw error.create({
name: 'NO_JOURNAL_PERMISSION',
message: 'role ' + user.roleId + ' has ' + level + ' on TRAN_JOURNAL'
});
}
ctx.response.write({ output: 'subsidiary=' + user.subsidiary + ' department=' + user.department });
};
return { onRequest };
});runtime.getCurrentUser()が返すUserオブジェクトからは、ロールのスクリプトID（roleId）や所属子会社・部門も取れるため、エラーの記録に含めておくと問い合わせの切り分けが速くなります。
権限レベルを大小比較せず、許可する値の配列で判定する理由と型の扱い
runtime.Permissionの値はFULL・EDIT・CREATE・VIEW・NONEの5つで、公式リファレンスは戻り値の型を文字列としています。一方、コミュニティには>=で大小を比べるサンプルも出回っています。型の扱いに依存しないよう、上のコードでは許可する値を配列に並べてincludesで判定しました。
判定はスクリプトを実行しているユーザーとロールの権限で行われます。デプロイの実行ロールを管理者にしたまま本番に出すと、判定が常に通る状態になりかねません。前章の専用ロールの考え方を、スクリプトのデプロイ設定にも当てはめてください。
NetSuiteのロール設計を自社で進める条件と、外部に任せる場面の判断
ここまでの設定は、すべて標準機能の範囲です。問題は量と整合で、子会社と業務の数が増えるほど、設計表なしでは管理できなくなります。
標準ロールの複製で足りる会社と、設計表から作り直すべき会社の境目
単一の法人で部門が数個、ロールが10本前後に収まるなら、標準ロールをCustomizeで複製し、部門制限を足すだけで十分に回ります。SDFでのコード管理はこの規模では過剰で、画面での設定と変更履歴の確認で足ります。
次のいずれかに当てはまるなら、標準ロールの複製をやめて設計表から作り直します。OneWorldで子会社が3社以上ある場合、上場準備で内部統制の評価を受ける場合、サンドボックスと本番でロールの差異が監査で指摘された場合です。製品全体の位置づけやIPO準備企業での使われ方はNetSuiteの機能・料金構造とIPO準備企業に選ばれる理由を解説した記事にまとめています。
権限設計を後回しにすると戻せないデータ移行の場面と、相談に向く段階
後回しにしてはいけないのは、稼働前のデータ移行です。全員を管理者に近いロールで動かしたまま移行と稼働を迎えると、本稼働後に制限をかけた時点で、前章の仕様どおり見えていた伝票が一斉に見えなくなり、業務を止めてロールを作り直す事態になりえます。画面の項目やダッシュボードの絞り込みはNetSuiteの使いにくさの正体と標準設定で解消できる範囲を解説した記事で扱った設定と組み合わせると効果が出ます。
子会社と部門をまたぐロール設計表の作成、SDFでのロール配布、連携ロールの最小権限化を導入プロジェクトに含めて進めたい場合は、Oracle NetSuite導入支援サービスで要件整理から相談を受け付けています。
よくある質問
NetSuiteの権限とロールについて、設定の現場でよく出る質問に答えます。
NetSuiteで他部門や他の子会社とデータを共有するにはどうすればよいですか？
編集までは許さず見せるだけでよいなら、ロールのRestrictionsサブタブでAllow Viewing（部門・クラス・場所）か、Allow Cross-Subsidiary Record Viewing（子会社）にチェックを入れるのが近道です。どちらも閲覧だけを広げ、編集は元の制限の内側に留まります。従業員の給与とコミッションのデータは、この設定でも共有されません。担当として編集まで必要な場合は、子会社制限をSelectedにして対象を追加します。
NetSuiteのアクセス権限はユーザーごとに個別に付けられますか？
Global Permissions機能を有効にすると、従業員レコードに直接権限を付けられます。ただしロールの権限と衝突したときはこちらが優先され、Oracleの公式ヘルプも利用を推奨していません。個人の例外が増えると、誰が何をできるのかをロールの一覧から追えなくなります。例外は小さな追加ロールとして作り、必要な人に重ねて割り当てるほうが監査で説明しやすくなります。
標準ロールの権限をそのまま書き換えることはできますか？
標準ロールは直接は編集せず、Manage Rolesで「Customize」を押して複製したカスタムロールを編集します。複製元の標準ロールはそのまま残るため、変更後のカスタムロールと比較する際の基準です。SDFで配布する場合も、標準ロールではなくカスタムロール（customroleで始まるスクリプトID）として定義します。名前に業務名と対象子会社を入れておくと、ロールが増えても選び間違いが減ります。
ロールの権限や制限を変えたのに反映されないのはなぜですか？
公式ヘルプのとおり、制限を変更したロールのユーザーは、ログアウトして入り直すまで変更後の状態になりません。検証では、設定を直すたびにテスト用ユーザーで入り直します。それでも変わらない場合は、Global Permissionsによる個人単位の上書き、Book Record Restriction、そもそも部門を割り当てていない勘定科目や記録が対象かどうか、の順に確かめると原因に早く当たります。
SDFでロールを配布するとき、子会社の設定はどう扱えばよいですか？
XMLのsubsidiaryoptionでALL・ALLACTIVE・OWN・SELECTEDのいずれかを必ず明記します。省略すると既定値のALLになり、画面で作るときの既定値User Subsidiaryとは逆に、全子会社へ届くロールになる仕様です。SELECTEDで選ぶ子会社の一覧はSDFでは定義できないため、配布後に画面で選択します。マニフェストではSUBSIDIARIES機能を参照しておきます。
関連記事
- NetSuiteとは？機能・料金構造とIPO準備企業に選ばれる理由を解説：製品の全体像と導入判断。本記事の前提になる記事です
- NetSuiteは無料で試せる？料金・プランの決まり方と見積の読み方、デモ評価の進め方：ユーザーライセンスの種別と席数の設計
- NetSuiteは使いにくいのか？不満の正体と標準設定で解消できる範囲：ロールごとのフォームとダッシュボードの絞り込み
- 購買管理規程と内部統制とは？承認権限・職務分掌の設計とシステムでの不正防止を解説：ロール設計表の背景になる職務分掌の考え方
- AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説：最小権限の設計原則の比較対象
