購買システムのアカウント管理——入社・異動・退職と取引先の担当者

アカウント管理は「誰が入れるか」の管理である

購買システムの導入を受け持つと、権限表の設計に目が向きやすい。だが権限表は「入った人が何をできるか」を決めるもので、その前に「誰が入れるか」を決める仕事がある。入社した人にいつアカウントを渡し、異動した人の権限をいつ直し、辞めた人をいつ止めるか。この手続が回っていないと、権限表をどれほど丁寧に作っても、辞めた人が発注画面に入れる状態が残る。役割ごとに何の権限を渡すかは購買システムの権限設計の記事で扱うので、ここではアカウントを作る・変える・止める手続だけを扱う。

クラウドで提供される受発注・購買のサービスを使う場合、この手続は事業者ではなく自社の仕事になる。総務省のガイドラインは、SaaS を利用する側はアプリケーション上で生成したデータの管理の権限と責任を持ち、アカウント管理などの限定的な管理権限を事業者から付与される場合があると書いている^[5]。事業者は仕組みを用意するが、誰を登録して誰を止めるかは利用する側でしか判断できない。人事の情報を持っているのは自社だからである。

購買システムには、取引先の担当者の氏名やメールアドレスが入る。これらを検索できる形で持つなら、個人データを取り扱う情報システムに当たりうる。個人情報保護委員会のガイドラインは、技術的安全管理措置の一つとして、個人データを取り扱う情報システムを使用する従業者が正当なアクセス権を有する者であることを、識別した結果に基づき認証しなければならないとしている^[4]。アカウントの手続は、社内の規程の問題であると同時に、法令上求められる安全管理の一部でもある。預ける側として何を確かめるかは取引先の情報をクラウドに預けるときの記事で扱う。

1 人 1 アカウントを原則にする

購買の現場では「購買課」「受付用」といった共有アカウントが作られやすい。人が少なく、交代で画面を見るからである。だが購買システムの記録は、誰が発注し、誰が承認し、誰が検収を登録したかを残すためにある。共有アカウントで操作すれば、記録には「購買課」としか残らない。

内閣官房 国家サイバー統括室が政府機関向けに示しているガイドラインは、情報システムを利用する主体ごとに識別コード（ユーザー ID のこと）を個別に付与することを求め、やむを得ず共用の ID を付与する場合には利用者を特定できる仕組みを設けたうえで実施手順を整備するよう求めている^[1]。理由として、共用の ID はその利用履歴だけでは利用者を特定できないため不正な利用の検知が難しく、事故が起きたときの真相究明の支障になる可能性があると説明している^[1]。政府機関向けの文書なので民間に義務がかかるものではないが、理由の部分はそのまま購買システムに当てはまる。情報処理推進機構（IPA）の中小企業向けガイドラインも、共有 ID はなるべく使わないようにし、やむを得ず使う場合は利用したユーザーを特定できる仕組みを整備するよう求めている^[2]。

購買で特に困るのは承認である。承認者のアカウントを借りて押せば、記録上は本人が承認したことになる。不在のときに承認をどう回すかは承認の段は何段にするかで代理の置き方として整理している。アカウントの貸し借りで埋めないことが前提になる。

共有のメール受信箱（購買課の代表アドレスなど）と、共有のログイン ID は別のものとして扱う。取引先からの見積や問い合わせを部署のアドレスで受けるのは差し支えない。困るのは、そのアドレスでシステムにログインし、操作の主体まで共有してしまうことである。受け口は共有してよく、操作する人は分ける。

出来事ごとに、誰が何を合図に動くか

アカウントの手続が漏れるのは、手続そのものより合図が届かないことによる。人事は退職の手続をしても、購買システムの管理者に連絡するとは限らない。そこで、出来事ごとに起点と期限を決めておく。次の表は、決めておく項目の例である。

期限は会社ごとに決めてよい。大事なのは期限を数字で書くことと、合図を出す人を部署ではなく役職で書くことである。「人事から連絡があれば対応」では、連絡が来なかった場合に誰も気づかない。IPA のガイドラインは、退職や任期満了のときに情報や機器・ID・鍵などを回収し、チェックリストや証跡で実行状況を可視化するよう求めている^[2]。購買システムのアカウントも、この回収のチェックリストに 1 行加えておく。

発行：許可を得た人だけに、本人に設定させて渡す

政府機関向けのガイドラインは、情報システムを利用する許可を得た主体に対してのみ ID と認証情報を付与すること、ある主体に付与した ID を別の主体に付与しないこと、を基本対策として挙げている^[1]。購買システムに置き換えると、申請と承認を経ずに管理者の判断だけでアカウントを作らないこと、辞めた人の ID を後任にそのまま回さないことになる。

申請に書かせる項目は多くなくてよい。氏名、所属、メールアドレス、付ける役割、利用開始日、派遣や委託であれば契約の満了日の 6 つで足りる。満了日を最初に書かせておくと、あとで止め忘れを探すときの手がかりになる。

初回のパスワードの渡し方にも気をつける。同じガイドラインは、本人以外の者が認証情報を設定する場合は推測されにくいものにして安全な方法で配布すること、本人以外が設定した認証情報を本人に速やかに変更させることを挙げている^[1]。管理者が考えたパスワードをメールやチャットに書いて渡すと、その文面が残る。選定の段階で、招待メールのリンクから本人がパスワードを決める方式になっているかを確かめておくと、この手間が仕組みで片付く。

異動：権限を足すだけで終わらせない

異動の手続は、新しい業務に必要な権限を足すところで止まりやすい。足すのは本人も上長も困るのですぐ依頼が来るが、外すのは誰も困らないので依頼が来ない。結果として、異動を重ねた人ほど広い権限を持つことになる。IPA のガイドラインは、従業員の異動や退職等に伴う権限の変更・削除漏れや、特定の役職員への権限集中によるシステムの不正利用や権限濫用を防ぐために、アクセス権限を見直すルールを定めて権限の付与状況を管理するよう求めている^[2]。

購買で見落としやすいのは、権限そのものより承認の経路である。承認ルートに個人名を直接書いている場合、異動した人の名前が経路に残り、その人のところで申請が止まる。承認経路を役職や役割で組めるかどうかは、選定のときに確かめておきたい。経路の組み方は発注の承認ルールをどう設計するかで扱っている。

購買の中での異動（発注担当から検収担当へ、など）も同じである。前の役割の権限を残したまま新しい役割を足すと、発注と検収が一人に集まる。どの組み合わせを一人に持たせてはいけないかは職務分掌の記事に整理してある。アカウント管理の側でできるのは、付け替えるときに「足す」と「外す」を同じ申請の中で必ずセットにすることである。

退職：削除ではなく無効化し、同じ ID を回さない

退職者のアカウントは、削除するより無効化するほうがよい。購買システムには、その人が出した発注、押した承認、登録した検収の記録が残っている。アカウントを消すと、記録の「誰が」が辿れなくなる作りのシステムもある。政府機関向けのガイドラインは、主体が情報システムを利用する必要がなくなった場合の措置として、ID を無効にすること、無効化した ID を他の主体に新たに発行することを禁止すること、を例に挙げている^[1]。消すのではなく止め、止めた ID は使い回さない、という考え方である。記録をどれだけの期間残す必要があるかは発注の記録を 2 年どう残すかを参照してほしい。

無効化したあとに確かめることが 2 つある。1 つは、すでにログインしている画面からも締め出されるかどうかである。ログインの時点だけで判定する作りだと、無効化の前に開いていた画面はしばらく使えてしまう。止めてから実際に使えなくなるまでに何分かかるかを、選定の段階で事業者に聞いておく。もう 1 つは、パスワードの再設定である。再設定のメールが届く先が本人の個人アドレスになっていると、退職後も再設定を試みられる。会社のアドレスで登録し、退職時に会社のメールも止めるのが基本になる。

退職者が担当していた取引先、承認待ちの申請、途中の見積依頼は、アカウントを止める前に洗い出しておく。止めてから気づくと、その人のアカウントでしか見えなかったものを確認する手段がなくなる。担当業務そのものをどう渡すかは購買担当の引き継ぎで抜けるもので扱っている。

取引先の担当者は、相手の会社の人である

受発注のシステムには、取引先の担当者にアカウントを持たせる方式と、持たせずにメールのリンクなどで回答してもらう方式がある。どちらを選ぶかの考え方はサプライヤーポータルは要るかの記事に譲り、ここでは担当者が替わったときの扱いだけを書く。

取引先の担当者のアカウントで難しいのは、退職や異動を発注側が知る手段がないことである。社内の人なら人事から合図が来るが、取引先の人事は合図をくれない。取引先にアカウントを持たせる方式なら、次の 3 つを決めておく。第一に、担当者が替わったら連絡してもらうことを取引の開始時に頼んでおく。第二に、取引先の側で自社の担当者を追加・停止できる管理者を 1 人置いてもらえる作りかどうかを確かめる。第三に、一定期間ログインのない取引先のアカウントを、発注側から一覧で見つけられるかどうかを確かめる。

アカウントを持たせない方式では、問題がメールの宛先に移る。見積依頼や注文書が担当者個人のアドレスに届く設定なら、その人が辞めた後も宛先は残り、届いた文書は誰にも読まれない。交代の連絡を受けたら、システムに登録されている宛先を差し替える。取引先によっては部署の代表アドレスを宛先にしてもらうほうが安全である。

年に一度以上は、アカウントを棚卸しする

手続を決めても漏れは出る。だから定期的に一覧を見て、いまいるべき人だけが残っているかを確かめる。政府機関向けのガイドラインは、付与しても利用しない主体や、人事異動等でアクセスの必要がなくなった ID が残っている可能性を指摘し、不要な ID は定期的に確認して無効にするなどの対処を講ずる必要があるとしている^[1]。本人からの届出による場合のほか、定期的に不要な ID が存在しないことを確認することが望ましいとも書いている^[1]。

棚卸しでは、システムから出したアカウントの一覧と、人事の在籍者の一覧を突き合わせる。見るのは次の 4 点である。在籍していない人のアカウントが有効のまま残っていないか。長くログインのないアカウントはないか。管理者の権限を持つ人が想定より多くないか。派遣や委託の人で、契約満了日を過ぎたアカウントはないか。最後のログイン日時を一覧で出せるかどうかは、棚卸しの手間を大きく左右するので、選定の段階で確かめておくとよい。

棚卸しは費用の面でも効く。利用者の数で料金が決まるサービスでは、止め忘れたアカウントの分も払い続けることになる。デジタル庁の基本方針も、アカウント数に対して課金される SaaS では利用アカウント数の増大で運用等の経費が増えるため、利用アカウントの推移を想定する際に十分注意するよう求めている^[6]。政府情報システム向けの方針だが、利用者数で課金されるサービスを選ぶ民間にもそのまま当てはまる。

パスワードと多要素認証は、管理者から固める

パスワードの決め方については、IPA のガイドラインが具体的な目安を示している。10 文字以上で「できるだけ長く」、大文字・小文字・数字・記号を含めて「複雑に」し、名前や電話番号、誕生日など推測できるものを使わないこと、同じ ID とパスワードを複数のサービスで使い回さないこと、重要なシステムを利用する場合は可能な限り多段階認証、多要素認証、パスキーなどの認証強化機能を使うこと、である^[2]。IPA のクラウドサービス向けの手引きも、15 項目の確認ポイントの一つとして「利用者の認証を厳格に行う」を挙げ、ID とパスワードを共有しないこと、2 段階認証などの認証機能も利用することを例に示している^[3]。

多要素認証とは、パスワードのような知っている情報に、手元の端末に表示される確認コードのような持っているものを組み合わせて本人を確かめる方式である。政府機関向けのガイドラインは、インターネットから直接アクセスできるクラウドサービスの管理者権限を持つ主体など、厳格な認証が必要な場合には 2 つ以上の認証方式を組み合わせる多要素認証などの強固な認証技術を用いることを求めている^[1]。購買システムの管理者は、利用者を追加し、権限を変え、承認のルールを書き換えられる。管理者のアカウントが乗っ取られれば、権限表も承認のルールも意味を失う。全員に多要素認証を求めるのが難しくても、管理者だけは必須にする。

パスワードの定期的な変更については、同じガイドラインの解説が、利用者に定期的な変更を求めると安易なパスワードが設定されやすくなり、かえって安全性を下げるおそれがあるとして、実施しないことが望ましいとしている。何らかの理由で実施する場合は、その理由に応じた時機と方法で行うとしている^[1]。社内の規程が一律の定期変更を求めているなら、理由を見直す機会にしてよい。力を割くべきなのは、長いパスワードと多要素認証のほうである。

社内で使っている ID の仕組み（社員の ID を一元管理する認証基盤）と購買システムをつなぐシングルサインオンにも触れておく。つなげば、人事の異動や退職を認証基盤で処理するだけで購買システムにも反映される。政府機関向けのガイドラインも、クラウドサービスの ID を作成から廃棄まで管理する際の留意項目として、シングルサインオンを行う場合の連携方式、多要素認証などのより強力な認証方式、管理者権限を持つ ID の取扱いを挙げている^[1]。ただし、受発注・購買のサービスがすべて対応しているわけではない。対応していないなら、この記事の手続を人の手で回すことになるので、その分の運用を見込んでおく。

選ぶ前に事業者に聞いておくこと

ここまでの手続を回せるかどうかは、システムの作りに左右される。選定の場で確かめる項目を挙げておく。評価表への落とし方は購買部門の要望を要件に書き直す記事を、事業者の安全対策全般の確かめ方はクラウドサービスの安全性を選ぶ前に確かめる記事を参照してほしい。

1. 利用者の追加はどの役割の人ができるか。
誰でも利用者を足せる作りだと、申請と承認の手続が仕組みの外に出る。

2. 初回のパスワードは誰が決めるか。
本人が招待メールのリンクから決める方式なら、管理者がパスワードを知らずに済む。

3. 利用者を削除ではなく無効化でき、無効化した人の操作の記録は残るか。
止めた人の名前が過去の発注や承認の記録から消えないかを確かめる。

4. 無効化してから、ログイン中の画面が使えなくなるまでにどれだけかかるか。
即時か、数分後か、次にログインするときかで、退職日の運用が変わる。

5. 最後の管理者を止めてしまわない仕組みがあるか。
管理者が一人もいなくなると、利用者の追加も停止もできなくなる。

6. 多要素認証を使えるか、管理者が全員に必須にできるか。
本人が任意で有効にする作りだけなら、管理者アカウントには規程で必須にする。

7. 利用者の一覧と最後のログイン日時、ログインの記録を出せるか。
棚卸しの手間はここで決まる。操作の記録全般を何のために残すかは操作の記録（ログ）の記事で扱う。

8. 取引先の担当者のアカウントや宛先を、発注側からどこまで管理できるか。
停止できるのは誰か、ログインのない取引先を見つけられるかを確かめる。

よくある質問

購買担当が 2 人しかいません。それでも 1 人 1 アカウントにすべきですか

人数が少ないほど、1 人 1 アカウントの意味は大きくなります。2 人で共有すると、どちらが発注しどちらが承認したかが記録から分からず、分掌の代わりに置く事後の確認も成り立たなくなります。利用者の数で料金が決まるサービスでも、2 人分の差でこの記録を失うのは割に合いません。

退職者のアカウントは、いつまで無効化のまま残せばよいですか

その人の名前で残っている記録を保存しなければならない期間は残すのが基本です。アカウントを消すと記録の「誰が」が辿れなくなる作りもあるため、消す前に、消した後も記録に名前が残るかを事業者に確かめてください。

取引先から「担当が替わった」と連絡が来ないのですが、どうすればよいですか

取引の開始時に頼んでおくのが第一です。そのうえで、棚卸しのときに取引先の担当者の一覧も見て、長くログインや回答のない相手に確認の連絡を入れます。宛先を担当者個人ではなく部署のアドレスにしてもらうと、交代の影響を受けにくくなります。

派遣社員や業務委託先の人にもアカウントを渡してよいですか

渡すこと自体は差し支えありません。発行のときに契約の満了日を記録し、満了日に止めることを手続に入れてください。社員と違い人事の在籍者一覧に載らないことが多く、棚卸しで見落とされやすいので、別の一覧で管理します。

多要素認証は全員に必須にしなければいけませんか

法令で一律に決まっているわけではありません。まず管理者のアカウントを必須にし、次に承認や支払に関わる人へ広げる順で考えると、手間と効果の釣り合いが取りやすくなります。

まとめ

購買システムのアカウント管理は、人の出入りに合わせてアカウントを作る・変える・止める手続を、合図と期限つきで回すことである。クラウドのサービスでは、この部分は利用する側の仕事として残る。原則は 1 人 1 アカウントで共有しない。発行は申請と承認を経て、初回のパスワードは本人に決めさせる。異動では足すと外すを同じ申請にまとめ、承認経路に名前が残らないようにする。退職では削除せずに無効化し、同じ ID を回さず、ログイン中の画面からも締め出されるまでの時間を把握する。取引先の担当者は相手の会社の人なので、交代の連絡が届く仕組みと宛先の差し替えを先に決めておく。そして年に一度以上、在籍者の一覧と突き合わせて棚卸しし、管理者のアカウントには多要素認証を必須にする。

出典・参考資料

1. 政府機関等の対策基準策定のためのガイドライン（令和７年度版） 第３部～付録（内閣官房 国家サイバー統括室／令和 7 年 7 月 1 日・令和 8 年 10 月 1 日一部改定）
2. 中小企業の情報セキュリティ対策ガイドライン 第 4.0 版（独立行政法人情報処理推進機構／2026 年 3 月）
3. 中小企業のためのクラウドサービス安全利用の手引き（独立行政法人情報処理推進機構 セキュリティセンター／2026 年 6 月）
4. 個人情報の保護に関する法律についてのガイドライン（通則編）（個人情報保護委員会／平成 28 年 11 月・令和 8 年 6 月一部改正）
5. クラウドサービス提供における情報セキュリティ対策ガイドライン（第３版）（総務省／2021 年 9 月）
6. デジタル社会推進標準ガイドライン DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル社会推進会議幹事会決定／2025 年 5 月 27 日）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで