監査の準備の打ち合わせで、「管理者の権限を持っているのは誰ですか」と聞かれる。
経理部長が、すぐには名前を挙げられない。
稼働から時間がたち、使う人が増えた会社でよく起きる場面です。
NetSuiteのロールとは、ユーザーに割り当てる権限の束です。
ユーザーは、割り当てられたロールの範囲でだけ操作できます。
ロールの設計は、IT部門の設定作業にとどまりません。
誰に何を任せ、どこで確認を入れるかを決める、職務分掌の設計です。
では、使う人が増えた後からでも、どこから手を付ければ統制は取り戻せるのか。
この記事で分かること
- ロール・権限・アクセス権の基本の関係
- 標準ロールから、最小権限のカスタムロールを作る手順
- 管理者ロールと2要素認証の扱い
- 職務分掌（SoD）と内部統制のつなげ方
- AIとつなぐ時代に、ロールの設計が持つ意味
言葉の整理：職務分掌（SoD：Segregation of Duties）は、相反する仕事を別の人に分け、1人で完結させない仕組みです。
最小権限は、業務に要る操作だけを許す考え方です。
ロールと権限の基本
3つの関係
- ロール：ユーザーに割り当てる、アクセスの設定の束
- 権限：見る・作る・直すなど、個々の操作を許す単位
- 1人に複数のロールを割り当て、ログインの後で切り替えることもできる
標準ロールとカスタムロール
NetSuiteには、最初から多くの標準ロールがあります。
標準ロールは編集できません。
そのため、近いものをコピーしてカスタムロールを作るのが基本です。
| 観点 | 標準ロール | カスタムロール |
|---|---|---|
| 編集 | できない | できる |
| 位置づけ | 設計の出発点 | 自社の実体 |
| 作り方 | ― | 標準をコピーして調整、または新しく作る |
| 注意 | ― | 標準ロールの更新が反映されない |
公式ヘルプには、標準ロールの更新はカスタムロールに反映されないとあります。
新しい機能を有効にしても、既存のカスタムロールに権限は自動で足されません（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
機能を足したらロールも見直す運用が欠かせません。
権限の種類とレベル
権限は、取引・レポート・リスト・設定・カスタムレコードなどの種類に分かれます。
それぞれに、どこまで操作できるかのレベルがあります。
| レベル | できること | 使いどころの目安 |
|---|---|---|
| なし | アクセスできない | 業務に関係ない領域 |
| 閲覧 | 見るだけ | 参照だけ要る役割 |
| 作成 | 新しく作る | 起票の担当 |
| 編集 | 既存を直す | 修正の担当 |
| フル | 作成・編集・削除すべて | 限られた管理者 |
「種類×レベル」で考えれば、誰に何をどこまで許すかを細かく決められます。
管理者ロールと2要素認証
管理者ロールは「少なくとも2人・カスタムで」
標準のAdministratorロールは、ほかの標準ロールと同じくカスタマイズできません。
公式ヘルプでは、カスタムの管理者ロールを作って使うよう案内しています。
休みや退職に備えて、管理者は少なくとも2人に与えるようにとも勧めています。
同時に、人選は慎重にとも書かれています（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
つまり「1人だけ」も「何人も」も避け、2人程度に絞るのが目安です。
管理者の操作は、System Notes（変更の記録）で追えます。
管理者ロールで確かめたいことを図にすると、次のとおりです。
2要素認証が必須のロール
Administratorと、特に強い権限を持つロールは、2要素認証が必須です。
管理者は、ほかのロールも2要素認証の必須に指定できます（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
2要素認証は、パスワードに加えて、別の確認の手段を求める仕組みです。
2026.1以降の同時のセッション
2026.1から、管理者は「Multiple Sessions for 2FA-protected Users」を有効にできるようになりました。
有効にすると、2要素認証で守られたロールの利用者が、最大3つのセッションを同時に使えます。
有効にしなければ、誰も2つ以上のセッションを使えません（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
ログイン時に通知を出す設定（Login Notification）もあります。
利用者は、確認のボタンを押してからログインします（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
社内の規程への同意を、ログインのたびに求めたい会社に向いています。
職務分掌（SoD）と内部統制
起票と承認を同じ人ができると、誤りや不正を誰も止められません。
購買と支払を分ければ、互いの確認が働きます。
J-SOX（内部統制報告制度）や会計監査でも、職務分掌は必ず見られる点です。
承認の流れとロールの権限を一致させる。
これが、NetSuiteで職務分掌を形にするときの軸になります。
承認の流れはNetSuiteの承認ワークフロー実装ガイドで扱っています。
監査の観点はIPOで求められる内部統制、会計監査の重要性とNetSuiteを活用した効率化も参考にしてください。
設計の6つの手順
- 職務を棚卸しする：誰が、どの業務で、何を操作するか
- 標準ロールから出発する：近い標準ロールをコピーして土台にする
- 最小権限で組む：迷ったら付けるのではなく、迷ったら外す
- 相反する職務を分ける：起票と承認、購買と支払を別のロールに
- 記録を前提に組む：誰が何を変えたかを後から追えるようにする
- 定期に棚卸しする：入退社・異動・機能の追加に合わせて見直す
冒頭の問いへの答えは、6から始めることです。
使う人が増えた後なら、まず棚卸しで現状を出し、1に戻って組み直します。
設計の進め方の比べ方
| 進め方 | 手間 | 統制の強さ | AIとの親和性 |
|---|---|---|---|
| 標準ロールをそのまま使う | 小 | 弱い。業務に合わない権限が残る | 低。AIに見せてよい範囲が決まらない |
| 管理者ロールを多く配る | 小 | 弱い。誰でも何でも変えられる | 低。AIの操作も広く許してしまう |
| 職務ごとのカスタムロール | 中 | 強い | 高。AIもロールの範囲で動くため、任せる範囲を決めやすい |
| 職務ごとのロール＋定期の棚卸し | 中〜大 | 強く、続く | 高。変更の記録がそろい、点検もしやすい |
AIとつなぐ時代のロール
NetSuite AI Connector Serviceは、ClaudeやChatGPTなどのAIをNetSuiteにつなぐ仕組みです。
公式サイトでは、ロールにもとづく権限の仕組みで動くと説明しています。
利用者もAIも、ロールで許された範囲だけを見ます（出典：Oracle NetSuite公式サイト、2026年9月確認）。
ロールの設計は、そのままAIに任せる範囲の設計になります。
詳しくはNetSuite AI Connector Service（MCP）とはをご覧ください。
開発の側では、2026年4月28日に「SuiteCloud Agent Skills」が発表されました。
その1つ「Permissions References Skill」は、684の権限コードのカタログです。
最小権限の設定を、開発の段階から支えます（出典：NetSuiteの発表〔PR Newswire〕、2026年4月28日）。
開発者向けで、資料は英語が中心です。
判断の物差し｜どこまで作り込むか
細かく分けるのが合う会社
- 上場の準備中、または監査を受けている
- 経理・購買・営業など、役割ごとに担当者がいる
- 子会社や拠点ごとに、見せてよい数字が違う
作り込みすぎないほうがよい会社
- 社員が少なく、1人が複数の職務を兼ねる
- 利用者が数人で、当面は増えない
少人数の会社では、職務を完全には分けられません。
その場合は、事後の確認で補うのが現実的です。
たとえば、上長が週に1回、System Notesで変更を見る運用です。
システムで分けきることより、確認の習慣が続くことを優先します。
判断の分かれ目を図にすると、次のとおりです。
これから導入する会社と、いま使っている会社
これから導入する会社
稼働の前に、職務と権限の表を作ります。
稼働の後に作ると、広い権限のまま運用が始まりやすいからです。
管理者を誰にするか、2人目を誰にするかも、このときに決めます。
いま使っていて、見直したい会社
次のサインがあれば、見直しの時期です。
- 管理者ロールを持つ人の数を、すぐに答えられない
- 退職者のアカウントが残っている
- 機能を追加したのに、ロールを見直していない
公式ヘルプでは、System Notesでロールと権限の割り当ての変更を検索できます。
従業員の記録には、ロールの変更の履歴が残ります。
ロールの間の権限の違いを比べる機能もあります（出典：Oracle NetSuite公式ヘルプ、2026年9月確認）。
まずは、いまのロールの一覧と、割り当ての一覧を出してください。
導入したパートナーに見直しを頼めない場合は、別のパートナーに相談する道もあります。
よくある3つの失敗
失敗1：管理者ロールを配りすぎる
起きること：本来は触れないはずのデータを、多くの人が見たり変えたりできる。
原因：迷ったら管理者を付けた。管理者をコピーして、少し削って使った。
避け方：管理者は2人程度に絞ります。
日常の業務は、最小権限のロールで行います。
失敗2：職務分掌を考えずにロールを作る
起きること：1人が起票も承認もできる。監査で指摘を受ける。
原因：部署単位でロールを作り、相反する職務を同じロールに入れた。
避け方：職務の組み合わせの表を先に作り、相反する職務を別のロールに分けます。
承認の流れと権限は、一緒に決めてください。
失敗3：作った後に見直さない
起きること：退職者や異動者の権限が残る。似たカスタムロールが増え、全体が分からない。
原因：入退社や機能の追加と、ロールの見直しが結び付いていなかった。
避け方：ロールに名前の付け方の決まりを作り、四半期ごとなど周期を決めて棚卸しします。
カスタムレコード・保存検索・スクリプトの権限も、棚卸しの対象に入れます。
保存検索は、条件を保存して繰り返し使う検索です。
詳しくはNetSuite保存検索の作り方をご覧ください。
ベンチャーネットならこう見る
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、権限の相談を2つの型で受けます。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
ベストプラクティスは、自社の環境で試してから入れる
Oracleは、NetSuiteの標準の使い方（ベストプラクティス）を示しています。
標準ロールも、その1つです。
ただ、それがそのまま自社の職務に合うとは限りません。
ベンチャーネットは、Oracleのベストプラクティスを、お客様の環境で試してから入れます。
ロールなら、標準ロールをコピーしたカスタムロールで、実際の担当者の業務を通します。
画面が出ない、承認に進めない。
そうした詰まりを、本番の前に洗い出します。
役割の分け方も、最初に共有します。
日本オラクルは、ライセンス・トレーニング・製品サポートを担います。
ベンチャーネットは、要件定義・設定・カスタマイズ・保守を担います。
ロールの設計と棚卸しは、この設定と保守の中で扱います。
守り→攻め→次へ｜ロールは「次へ」の土台になる
稼働の後は、3つの段階で考えます。
守りは、業務が回る段階です。
攻めは、データで打つ段階。生成AIでの集計もここに入ります。
次へは、経営が変わる段階で、KPI・管理会計・上場に向けた内部統制が並びます。
ロールの設計は、3つのどの段階にも効いてきます。
守りでは、誤った操作を防ぎます。
攻めでは、AIに見せてよい範囲を決めます。
そして次へ進むとき、監査で最初に問われるのが職務分掌です。
最初から全部を作り込む必要はありません。
ただし、管理者の人数と相反する職務だけは、稼働の前に決めるよう勧めています。
最初の打ち合わせで伺うのは、次の3つです。
- いま管理者は何人か：名前を挙げられるか
- 相反する職務を1人で完結できる場所はどこか：起票と承認、購買と支払
- 監査や上場の予定はあるか：どこまで細かく分けるかが変わる
今日できること｜職務の組み合わせの表を作る
担当者を行に並べ、担う職務を書き込んでください。
| 担当者 | 起票・承認 | 購買・支払 | マスタの変更・管理者 |
|---|---|---|---|
| （例）経理Aさん | 起票○・承認○ | 支払○ | ― |
1つのセルに「起票○・承認○」のような組み合わせが並べば、そこが最初に手を打つ場所です。
管理者の印が1人だけか、3人以上なら、人数も見直します。
この表が、冒頭の「管理者は誰か」への答えになります。
よくある質問
Q1. 標準ロールとカスタムロールはどう使い分けますか
標準ロールをコピーして自社用のカスタムロールを作るのが基本です。
標準ロールは編集できません。
標準ロールの更新はカスタムロールに反映されないため、機能を足したら見直します（第1章）。
Q2. 管理者ロールは何人に渡すべきですか
公式ヘルプは少なくとも2人を勧めています。
1人だと不在のときに困り、多すぎると統制が弱まります。
標準のAdministratorではなく、カスタムの管理者ロールを使います（第2章）。
Q3. 最小権限とは具体的に何をすればよいですか
職務ごとに要る操作だけを残し迷ったら外します。
職務ごとに、何を、どのレベルまで触るかを書き出します。
それ以外は付けません（第1章・第4章）。
Q4. 職務分掌はNetSuiteでどう実現しますか
相反する職務を別のロールに分けます。
起票と承認、購買と支払を同じロールに入れないことです。
承認の流れと権限を一緒に設計します（第3章）。
Q5. 社員が少なく職務を分けきれません
事後の確認で補う方法があります。
上長がSystem Notesで変更を定期に見る、などの運用です。
監査や上場の予定があれば、分け方を早めに相談します（第5章）。
Q6. AIとつなぐと権限はどうなりますか
AI Connector Serviceはロールで許された範囲で動きます。
AIに任せる範囲は、ロールの設計で決まります。
連携に使うロールも、最小権限で作ります（第4章）。
まとめ
- ロールは権限の束。標準ロールをコピーし、最小権限のカスタムロールを作る
- 標準ロールの更新はカスタムロールに反映されない。機能を足したら見直す
- 管理者は少なくとも2人。カスタムの管理者ロールを使い、2要素認証を前提にする
- 起票と承認、購買と支払は別のロールに
- AIもロールの範囲で動く。ロールの設計はAIに任せる範囲の設計になる
「管理者は誰か」に即答できない会社でも、統制は取り戻せます。
まずは職務の組み合わせの表を1枚作り、管理者の人数と相反する職務から見直してください。
もう少し詳しく知りたい方へ
職務分掌をNetSuiteのロールにどう落とし込むか。
いまのロールの棚卸しからご相談をお受けしています。
あわせて読みたい
コメント
コメント一覧 （2件）
[…] 権限の設計はNetSuiteの権限・ロール設計で、承認の流れはNetSuiteの承認ワークフロー実装ガイドで扱っています。 […]
[…] ロールの考え方は、NetSuiteの権限・ロール設計で扱っています。 […]