---
title: "NetSuiteの権限とロール設計：子会社・部門の可視範囲とSDF・SuiteScriptでの実装手順"
url: "https://www.issoh.co.jp/tech/details/18953/"
published: 2026-10-26
updated: 2026-10-26
categories: ["業務システム"]
publisher: "株式会社一創"
---

# NetSuiteの権限とロール設計：子会社・部門の可視範囲とSDF・SuiteScriptでの実装手順

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」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section%5F3781107123.html)は、権限を「特定の記録の種類へのアクセスを与えるもの」、制限を「権限を与えたうえで、その種類のどのインスタンスにアクセスできるかを定めるもの」と定義しています。

### 権限レベルNone・View・Create・Edit・Fullの違いと付与の単位

権限は「請求書」「仕訳入力」「仕入先」のような記録の種類ごとに、レベルを選んで付けます。上の段階ほど扱える操作が増えます。

| レベル    | できること          | 付ける場面の例  |
| ------ | -------------- | -------- |
| None   | アクセスなし         | 担当外の記録   |
| View   | 参照と検索、印刷       | 監査・照会担当  |
| Create | 新規作成（既存の更新は不可） | 起票だけする担当 |
| Edit   | 作成と既存の更新       | 日常の入力担当  |
| Full   | 削除を含む全操作       | 例外扱いの管理者 |

実務の基本はEditまでで止め、Fullは理由を書ける場合だけにします。Oracle公式の[SuiteCloud SDKリポジトリの権限リファレンス](https://github.com/oracle/netsuite-suitecloud-sdk/blob/master/packages/agent-skills/netsuite-sdf-roles-and-permissions/SKILL.md)も、用途を満たす最小のレベルを選び、Fullは例外として明示的に正当化するよう求めています。

### 制限は「どの記録まで」を決める層、作成できても見えない記録の条件

同じ公式ヘルプには、制限のかかった記録の種類にCreateやFullを持つユーザーは新しい記録を作って保存できても、作った記録を参照できないと書かれています。権限レベルが高くても、制限の外にある記録は見えません。

経理担当に仕訳のEditを渡し、部門制限を「自部門のみ」にした場合を考えます。他部門の部門コードで仕訳を起こすと保存は通り、保存直後から本人の一覧に出てきません。稼働後に「入力したのに消えた」ように見える現象は、この2層のずれで説明がつきます。

### 標準ロールはCustomizeで複製し、従業員に複数ロールを割り当てる

標準ロールは直接編集せず、Setup > Users/Roles > Manage Rolesで対象ロールの「Customize」を押して複製し、複製したカスタムロールを編集します。[公式ヘルプ「Employee Users」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section%5FN322041.html)によると、ロールは従業員レコードのAccessサブタブにあるRolesで割り当て、1人に複数のロールを付けられます。割り当ての変更を確認できるのはHistoryサブタブです。

Global Permissions機能を有効にすると、従業員ごとに直接権限を付けることもできます。ただし、ロールの権限と衝突した場合はこちらが優先され、Oracle自身が「推奨しない」と明記しています。個人単位の例外は監査で追いにくくなるため、例外用の小さなロールを作って割り当てるほうが管理しやすい設計です。

## 子会社・部門・クラス・場所の制限を設定してロールの可視範囲を絞る手順

部門や子会社をまたぐ会社で、権限設計の手間の大半はこの章の設定に集まります。設定はいずれもロールのRestrictionsサブタブで行います。

### OneWorldの子会社制限4択の選定基準と所属・担当会社による可視範囲

複数の子会社を1つのアカウントで扱うOneWorldでは、ロールごとに届く子会社を決めます。[公式ヘルプ「Restricting Role Access to Subsidiaries」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/bridgehead%5FN286421.html)が示す選択肢は4つで、既定値はUser Subsidiaryです。

| 選択肢             | 届く範囲          | 向くロール      |
| --------------- | ------------- | ---------- |
| All             | 無効な子会社を含む全社   | 連結・監査      |
| Active          | 有効な子会社のみ      | 本社の経理統括    |
| User Subsidiary | 従業員レコードの所属子会社 | 各社の経理・営業   |
| Selected        | 指定した子会社（複数可）  | 地域統括・シェアード |

User Subsidiaryは従業員レコードに設定した子会社を見るため、出向や兼務で所属を変えると、そのまま見える範囲も変わります。グループ内の経理を1か所で処理するシェアードサービスでは、Selectedで担当会社を列挙するほうが、人事異動のたびに範囲が揺れません。

### 部門・クラス・場所の制限3種と「Allow Viewing」で閲覧だけ広げる設定

[公式ヘルプ「To Set Role Restrictions」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/procedure%5FN291445.html)の手順は次のとおりです。

1. Setup > Users/Roles > Manage Rolesで、標準ロールなら「Customize」、カスタムロールなら「Edit」を押す
2. Restrictionsサブタブを開き、SegmentでClass・Department・Locationのいずれかを選ぶ
3. Restrictionsで「none – default to own」「own, subordinate, and unassigned」「own and subordinates only」から選ぶ
4. 閲覧だけ許すならAllow Viewing、品目にも制限をかけるならApply to Itemsにチェックを入れる
5. 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公式リポジトリ](https://github.com/oracle/netsuite-suitecloud-sdk/blob/master/packages/agent-skills/netsuite-sdf-roles-and-permissions/SKILL.md)が同梱する一覧で実在を確かめたものです。

| ロール      | 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段階を通せないことです。仕入先マスタの編集を支払担当から外しているのはこのためです。承認の規程や不正防止の考え方は[購買管理規程と内部統制、職務分掌の設計を解説した記事](https://www.issoh.co.jp/column/details/15541/)で扱っています。

### 連携用・スクリプト実行用ロールをAdministratorにしない理由と代わりの設計

外部システムとの連携やスクリプトの実行ロールは、つい管理者で動かしがちです。前出のOracle公式リファレンスは、スクリプトの実行ロールに本番でAdministratorを推奨してはならないと明記し、必要な権限だけを持つ専用ロールを勧めています。REST連携の専用ロールには、`ADMI_RESTWEBSERVICES`に加えて対象記録の権限が要るとされています。OAuth 2.0のクライアント資格情報フローでの接続手順は[NetSuiteの連携とAPI：SOAP廃止後のREST・RESTletの使い分けとOAuth 2.0・同時実行数の設計](https://www.issoh.co.jp/tech/details/18955/)で解説しています。

専用ロールにすると、連携の資格情報が漏れたときに被害が届く範囲が、そのロールの権限と制限の内側に収まります。考え方はAWSの最小権限と同じで、[AWS IAMのユーザー・ロール・ポリシーと権限設計を解説した記事](https://www.issoh.co.jp/tech/details/15427/)の設計原則がそのまま当てはまります。認証やエラー処理を含む連携の組み方は[REST・認証・エラー処理を扱うAPI連携の実装手順](https://www.issoh.co.jp/tech/details/15351/)を参照してください。

## SDFのcustomrole XMLでロールをコード管理し、環境差を無くす手順

サンドボックスで作ったロールを本番へ手作業で写すと、チェック1つの漏れで権限がずれます。SuiteCloud Development Framework（SDF）を使えば、ロールをXMLとして版管理し、同じ定義を配布できます。

### customrole XMLの最小構成と権限キー・制限の書き方

[公式ヘルプ「Custom Roles as XML Definitions」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section%5F4731154857.html)の例をもとに、前章の買掛担当を、日本子会社のみ・自部門のみ（閲覧は許可）で定義すると次のようになります。

```
<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リファレンス](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/SDFxml%5F2121043136.html)では`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)」](https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section%5F4296668393.html)によると、このメソッドは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準備企業に選ばれる理由を解説した記事](https://www.issoh.co.jp/column/details/15979/)にまとめています。

### 権限設計を後回しにすると戻せないデータ移行の場面と、相談に向く段階

後回しにしてはいけないのは、稼働前のデータ移行です。全員を管理者に近いロールで動かしたまま移行と稼働を迎えると、本稼働後に制限をかけた時点で、前章の仕様どおり見えていた伝票が一斉に見えなくなり、業務を止めてロールを作り直す事態になりえます。画面の項目やダッシュボードの絞り込みは[NetSuiteの使いにくさの正体と標準設定で解消できる範囲を解説した記事](https://www.issoh.co.jp/column/details/18088/)で扱った設定と組み合わせると効果が出ます。

子会社と部門をまたぐロール設計表の作成、SDFでのロール配布、連携ロールの最小権限化を導入プロジェクトに含めて進めたい場合は、[Oracle NetSuite導入支援サービス](https://www.issoh.co.jp/service/erp%5Fcrm/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準備企業に選ばれる理由を解説](https://www.issoh.co.jp/column/details/15979/)：製品の全体像と導入判断。本記事の前提になる記事です
- [NetSuiteは無料で試せる？料金・プランの決まり方と見積の読み方、デモ評価の進め方](https://www.issoh.co.jp/column/details/16603/)：ユーザーライセンスの種別と席数の設計
- [NetSuiteは使いにくいのか？不満の正体と標準設定で解消できる範囲](https://www.issoh.co.jp/column/details/18088/)：ロールごとのフォームとダッシュボードの絞り込み
- [購買管理規程と内部統制とは？承認権限・職務分掌の設計とシステムでの不正防止を解説](https://www.issoh.co.jp/column/details/15541/)：ロール設計表の背景になる職務分掌の考え方
- [AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)：最小権限の設計原則の比較対象

---

出典: [NetSuiteの権限とロール設計：子会社・部門の可視範囲とSDF・SuiteScriptでの実装手順](<https://www.issoh.co.jp/tech/details/18953/>)（株式会社一創）