NetSuiteを使う人が増えると、「誰が何を見られるか」の管理が一気に複雑になります。
権限・ロールの設計は、単なるIT設定ではありません。職務分掌、つまり内部統制の土台そのものです。
ここでは、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが、権限・ロール設計の基本を整理します。最小権限の手順、職務分掌（SoD）と内部統制のつなげ方、そしてやりがちな失敗と回避策までをまとめました。
この記事で分かること
- NetSuiteのロール・権限・アクセス権の基本構造
- 標準ロールを活かした「最小権限」の設計手順
- 職務分掌（SoD）と内部統制・J-SOXのつなげ方
- 権限設計でやりがちな失敗と回避策
（読了目安：約8分）
NetSuiteのロール・権限とは？（基本構造）
まず、ロール・権限・アクセス権の関係を整理します。この3つが設計の土台になります。
ロールと権限の関係
NetSuiteでは、次のような関係になっています。
- ロール（役割）：ユーザーに割り当てるアクセス設定の束
- 権限：個々の操作（見る・作る・編集するなど）を許可する単位
- ユーザーにロールを割り当てると、そのロールが持つ権限の範囲で操作できる
1人のユーザーに複数のロールを割り当て、ログイン時に切り替えることもできます。
なお、ロールを作成・管理できるのは管理者（Administrator）だけです。
標準ロールとカスタムロール
NetSuiteには、最初から多数の「標準ロール」が用意されています。
標準ロールは、役割に応じて大きく3グループに分かれています。
- 経営層向け（executive）
- 管理職向け（managerial）
- 現場担当向け（operational）
標準ロールは、そのままでは編集できません。
そのため、近いものをコピーして「カスタムロール」を作り、権限を足し引きして使うのが基本です。
| 観点 | 標準ロール | カスタムロール |
|---|---|---|
| 編集 | できない（固定） | できる |
| 位置づけ | 設計の出発点 | 自社の実体 |
| 作り方 | — | 標準をコピーして調整 |
| 向く場面 | まず試す・参照する | 本番運用・最小権限の作り込み |
権限の「種類」と「レベル」を理解する
権限には「種類」と「レベル」の2つの軸があります。これを押さえると、設計がぶれません。
権限の種類
権限は、対象によっていくつかの種類に分かれます。
- 取引（Transactions）：見積・受注・請求などの伝票
- レポート（Reports）：各種レポート
- リスト（Lists）：顧客・仕入先などの一覧
- 設定（Setup）：システム設定
- カスタムレコード（Custom Records）：自社で独自に作った記録
権限のレベル
それぞれの権限には、「どこまで操作できるか」のレベルがあります。
| レベル | できること | 使いどころの目安 |
|---|---|---|
| なし | アクセス不可 | 業務に無関係な領域 |
| 閲覧 | 見るだけ | 参照だけ必要な役割 |
| 作成 | 新規作成 | 起票担当 |
| 編集 | 既存の編集 | 修正・更新担当 |
| フル | 作成・編集・削除すべて | 限られた管理者 |
「種類 × レベル」で考えると、誰に何をどこまで許すかを細かく設計できます。
職務分掌（SoD）と内部統制
権限設計は、職務分掌（SoD）と切り離せません。これは内部統制の土台です。
職務分掌（SoD：Segregation of Duties）とは、相反する仕事を別の人・別のロールに分け、1人で完結させない仕組みのことです。
なぜ重要なのでしょうか。
- 起票と承認を同じ人ができると、誤りや不正を誰も止められません
- 購買と支払を分けることで、相互にチェックが働きます
これは、情シスだけの設定作業ではありません。
誰に何を任せ、どこで牽制をかけるか。これは会社の統制の設計であり、経営の仕事です。
J-SOX（内部統制報告制度）や会計監査でも、職務分掌は必ず見られるポイントになります。
内部統制・監査の観点での詳しい考え方は、IPOで求められる内部統制とは、会計監査の重要性とNetSuiteを活用した効率化も参考にしてください。
権限・ロール設計のベストプラクティス手順
ここからは、実際の設計を6つのステップで整理します。
ステップ1：目的と職務を棚卸しする
誰が、どの業務で、何を操作する必要があるか。まずはこれを洗い出します。
ステップ2：標準ロールから出発する
ゼロから作らず、近い標準ロールをコピーして土台にします。
ステップ3：最小権限で組む
「迷ったら付ける」ではなく「迷ったら外す」。業務に必要な操作だけを残します。
ステップ4：職務分掌（SoD）で相互牽制を設計する
起票と承認、購買と支払など、相反する職務を別ロールに分けます。承認フローと権限を一致させるのが要点です。
ステップ5：監査証跡・ログを前提に組む
誰が何を変更したかを後から追える状態にします（詳しくは第6章）。
ステップ6：定期的に棚卸しする
入退社・異動・組織変更に合わせて、ロールを見直します。
最初から完璧を目指す必要はありません。標準ロールと最小権限から始め、運用しながら整えていけば十分です。
権限設計でやりがちな失敗と回避策
NetSuiteの権限設計は、つまずく場所がほぼ決まっています。ここでは現場で起きやすい4つの失敗と、その避け方を整理します。
これは製品を売り込むためではありません。「同じ失敗をしてほしくない」という思いから共有するものです。ベンチャーネットは、リスクを正直にお伝えし、一緒に乗り越える伴走者でありたいと考えています。
失敗①：管理者（Administrator）ロールを配りすぎる
ありがちな状況
- 迷ったら、とりあえず管理者権限を付けてしまう
- Administratorをコピーし、少しだけ権限を削って使う
- 管理者が何人もいる
なぜ失敗するか
Administratorは、すべての権限を持つロールです。これを基に作ると、削り切れなかった権限が「穴」として残ります。
結果として、本来触れないはずのデータに誰でもアクセスできてしまいます。これは内部統制上の重大なリスクです。
どう防ぐか
管理者ロールを削るのではなく、最小限のロールから足していく発想に切り替えます。
管理者は最小人数に限定します。日常業務は別の限定ロールで行い、必要なときだけ管理者ロールに切り替える運用が安全です。
失敗②：職務分掌（SoD）を考えずにロールを作る
ありがちな状況
- 1人が「起票」も「承認」もできる
- 「購買」と「支払」が同じロールに入っている
- 経理と、そのチェック役が分かれていない
なぜ失敗するか
相互牽制が効かないと、不正やミスを誰も検知できません。
このSoDの不備は、J-SOXや会計監査で、ほぼ確実に指摘されるポイントです。
どう防ぐか
相反する職務は、別々のロールに分離します。承認フローと権限設計を、セットで考えることが要点です。
失敗③：退職・異動者のロールを放置する
ありがちな状況
- 退職者のアカウントが、有効なまま残っている
- 異動した社員が、前の部署のロールを持ち続けている
- ロールを棚卸しする仕組みがない
なぜ失敗するか
不要なアクセス権の放置は、情報漏えいや不正アクセスの温床になります。
監査の場面でも、「使われていない権限」は必ず問題として挙がります。
どう防ぐか
入社・退社・異動に連動して、権限を見直す運用を組み込みます。
NetSuiteの「ログイン監査証跡」を使えば、長く使われていないロールを特定し、整理できます。
失敗④：カスタムロールを乱立させ、検索やスクリプトの権限を見落とす
ありがちな状況
- 似たようなカスタムロールが、どんどん増えていく
- 保存検索（保存した検索条件）で、想定外のデータが見えてしまう
- スクリプトが動かず、後から権限を付け足している
なぜ失敗するか
ロールが増えすぎると、全体像が管理できなくなり、抜け穴が生まれます。
加えて、見落としやすい権限があります。カスタムレコードは作成時に権限がゼロで、明示的に付けない限り誰も使えません。保存検索は、ロールの想定を超えてデータを見せてしまうことがあります。SuiteScript（NetSuiteの自動処理）にも、専用の権限が必要です。
どう防ぐか
ロールに命名規則を決め、定期的に棚卸しします。
カスタムレコード・保存検索・スクリプトの権限も、最初から「設計の対象」に含めておきます。
失敗の根っこ：権限設計は「ITプロジェクト」ではなく「経営プロジェクト」
ここまでの4つに共通するのは、ある認識のズレです。
それは、権限設計を「情シスの設定作業」として扱ってしまうことです。
職務分掌は、内部統制そのものです。誰に何を任せ、どこで牽制をかけるか。これは会社の統制の設計であり、経営の仕事です。
だからこそ、経営層の関与が欠かせません。
ベンチャーネットからの提案：「完璧より、まず回す」
最後に、ベンチャーネットが大切にしている考え方をお伝えします。
それは、「完璧を目指すより、まず回す。動かしながら磨いていく」という姿勢です。
最初から完璧を目指して権限設計をすると、いつまでも始められません。標準ロールと最小権限から始め、運用しながら整えていけば十分です。
権限と職務分掌は、法改正や組織変更のたびに見直しが必要な領域です。一度作って終わりにはなりません。
だからこそ、設計から運用まで一緒に考える伴走者の価値があります。「うちもこの失敗に当てはまるかも」と感じた方は、お気軽にご相談ください。御社にとって無理のない進め方を、一緒に整理させてください。
導入時に避けたい失敗の全体像は、ERP導入はなぜ失敗するのかもあわせてご覧ください。
監査証跡とログで運用を固める
設計したら、運用を「追える」状態にしておくことが大切です。
NetSuiteには、変更履歴を記録する仕組みがあります。
- System Notes：レコードへの変更を、日時・変更者・その人のロール・変更内容（旧→新）まで記録します
- ログイン監査証跡：ログイン状況を確認でき、長く使われていないロールの特定にも役立ちます
これらは、内部統制・監査対応の実務で力を発揮します。
「誰が・どのロールで・何を変えたか」を後から説明できること。それが、統制の信頼性につながります。
監査対応の効率化については、会計監査の重要性とNetSuiteを活用した効率化で詳しく解説しています。
最新動向：AIと権限設計（2026年）
2026年は、権限設計に関わる新しい動きがありました。情シス・開発者向けの話題として押さえておきましょう。
SuiteCloud Agent Skills「Permissions References Skill」
Oracle NetSuiteは2026年4月28日（SuiteConnect San Francisco）に、新しい開発支援の仕組みを発表しました。AIコーディングを支援する「SuiteCloud Agent Skills」です（出典：PR Newswire 2026年4月28日）。
そのひとつ「Permissions References Skill」は、684個の検証済み権限コードのカタログを提供します。AIに正確な権限情報を渡すことで、最小権限の設計を後押しするものです。
ただし、これは開発者向けの機能で、ドキュメントは英語が中心です。日本語での提供は現時点で限定的なため、主な対象は開発・情シス部門になります。
NetSuite 2026.1 の権限関連の変更
NetSuite 2026.1では、セキュリティ関連の更新がありました。
- 複数同時セッションは、管理者が明示的に有効化する方式へ（2要素認証が前提）
- ログイン時に、コンプライアンス通知を表示・確認させる設定が可能に
（出典：NetSuite公式ヘルプ／2026.1 Release Notes）
よくある質問（FAQ）
Q1. 標準ロールとカスタムロールはどう使い分ける？
標準ロールはそのまま使わず、コピーして自社用のカスタムロールを作るのが基本です。
NetSuiteの標準ロールは編集できません。そのため、近いものをコピーし、不要な権限を削り、必要な権限を足して使います。標準ロールは設計の「出発点」、カスタムロールが「自社の実体」と考えると整理しやすくなります。
Q2. 「最小権限」とは具体的に何をすればいい？
各ユーザーに、業務に必要な操作だけを与える考え方です。
迷ったら付与するのではなく、迷ったら外すのが原則です。職務ごとに「何を・どのレベル（閲覧／作成／編集／フル）まで触るか」を洗い出し、それ以外は付けません。権限の付けすぎは、内部統制上のリスクと管理コストの両方を増やします。
Q3. 職務分掌（SoD）はNetSuiteでどう実現する？
相反する職務を別のロールに分け、1人で完結できないようにします。
例えば「起票」と「承認」、「購買」と「支払」を同じロールに入れないことです。これは内部統制・J-SOX対応の土台でもあり、情シスだけでなく経営の関与が必要なテーマです。承認フローと権限設計をセットで考えるのが要点になります。
Q4. Administrator（管理者）ロールは誰に渡すべき？
必要最小限の人数に限定すべきです。
Administratorはすべての権限を持つため、日常業務用には別の限定ロールを使うのが安全です。管理者業務と日常業務でロールを分け、必要なときだけ管理者ロールに切り替える運用が現実的です。
まとめ：権限設計は「自社理解」が出発点
権限・ロール設計は、機能を知るだけでは完成しません。
「誰に何を任せ、どこで牽制をかけるか」は、自社の業務と組織を理解して初めて決められます。
そして、法改正や組織変更のたびに見直しが必要です。一度作って終わりにはなりません。
だからこそ、設計から運用まで一緒に考える伴走者の価値があります。
ベンチャーネットは、お客様との対等な関係を大切にする、NetSuite認定パートナー（Solution Provider）です。
「自社の職務分掌をどう落とし込めばいいか」——その段階のご相談こそ歓迎します。一緒に、御社にとって無理のない進め方を考えさせてください。
