中小企業の業務システムで、ログイン・権限・操作ログを最初に設計しておく理由と、最低限の作り方

この記事の結論：中小企業の業務システムでも、ログイン・権限・操作ログは、画面や機能より先に設計しておくほうが安く、安全に済みます。後から足そうとすると、すべての画面と処理に権限の確認を入れ直すことになり、過去の操作は記録が残っていないので調べようがありません。最低限の作り方は、1人に1つのアカウントを発行して共有をやめること、役割ごとに「見る・直す・消す・出力する」を分けた権限表を作ること、退職や異動のときにアカウントを止める手順を決めること、そして誰がいつ何に何をしたかを記録する操作ログ（監査ログ）を残して定期的に見ることの4つです。

社内の顧客台帳や受注の管理、予約の管理といった業務システムを作るとき、最初の打ち合わせで話題になるのは、たいてい画面と帳票です。けれども、公開した後に「この操作を誰がしたのか分からない」と困らないためには、ログインと権限の話を、画面の話と同じ最初の段階で決めておく必要があります。以下では、システムを発注する会社の担当者と、作る側の開発者が最初にそろえておく範囲を、IPA（情報処理推進機構）が中小企業向けに出している指針と、個人情報保護委員会の通則編に沿って並べます。どこかの会社で起きた出来事を紹介するものではありません。

なぜ最初に設計するのか：後から足すと、作り直しと記録の空白が残る

ログイン・権限・操作ログを最初に決める理由は、後から足すと作り直しが広がり、足す前の期間の記録がどうしても残らないからです。特に顧客の個人情報を扱うシステムでは、法律のうえでも求められている内容です。

後から足すと何が起きるかを、表にしました。

個人情報保護委員会が定める通則編（個人情報保護法の解釈を示す指針）は、情報システムで個人データを扱う事業者が講じなければならない技術的な安全管理措置として、担当者と扱う範囲を限るアクセス制御と、使う人が正当な権限を持つかを識別したうえで認証することを挙げています。中小規模の事業者向けの手法の例でも、ユーザーIDに付ける権限によって、システムを使える従業者を限ることが示されています。

ログインは1人1アカウントにし、守りの強さは扱う情報で決める

ログインの設計で最初に決めるのは、アカウントを1人に1つ発行し、共有のアカウントを使わないことです。共有していると、操作ログに残るのが「事務所のアカウント」だけになり、誰の操作か分かりません。

IPAが中小企業向けにまとめた情報セキュリティの指針（2026年3月公開の第4.0版）も、ユーザーIDや管理者IDの発行から削除までの手続きを決めて必要最小限の割り当てにすること、共有のIDはなるべく使わず、やむを得ず使う場合は使った人を特定できる仕組みにすることを求めています。あわせて、扱う情報の重要さに応じて認証の強さを決め、複数の要素を組み合わせる多要素認証を使うこと、ログオンの試行回数を限ってアカウントをロックする運用をすることも挙げています。

業務システムの設計に置き換えたのが、次の表です。

権限は、役割ごとの権限表を先に作る

権限は、人ごとに決めるのではなく、役割ごとに「何ができるか」を表にして、その役割を人に割り当てる形にします。表を先に作っておくと、作る側は画面と処理ごとに確認する内容が決まり、発注する側は社内の誰にどの役割を渡すかを決めるだけで済みます。

顧客の情報を扱う業務システムなら、たとえば次のような表になります。

表を作るときの決まりは、次の4つです。

1. できることは必要な分だけにする。 迷ったら「できない」にしておき、必要になったら広げる
2. 削除と一括出力は、ふだんの登録・修正と分ける。 誤りや持ち出しが起きたときの影響が大きい操作だから
3. 管理者は少人数にし、1人にしない。 1人だと、その人が休んだり辞めたりしたときに誰も権限を変えられない
4. 外部の委託先には期限を付ける。 作業が終わったら止まるように、終了日を持たせる

作る側が気をつけたいのは、権限の確認を画面のボタンを隠すだけで済ませないことです。ボタンが見えなくても、処理の入口（サーバー側）で役割を確かめていなければ、URLやAPIを直接呼ばれると操作できてしまいます。確認は必ずサーバー側で行い、表の「担当範囲のみ」のような区切りは、データを取り出すときの条件として組み込みます。

退職・異動のときは、アカウントを消すより先に止める

退職や異動でアカウントを放置すると、使われていないアカウントが不正なログインの入口になります。手続きとしては、削除の前にまず「停止」できる作りにし、退職の手続きの中にシステムの停止を組み込みます。

IPAのガイドラインは、異動や退職に伴う権限の変更や削除の漏れ、特定の人への権限の集中による不正利用を防ぐために、アクセス権限を見直すルールを決めて付与の状況を管理することを求めています。停止を先にする理由は、操作ログとの関係です。アカウントを消してしまうと、記録に残った利用者IDが誰のものだったか追えなくなることがあるので、ログインだけを止め、記録の持ち主は残しておきます。

退職・異動のときは、次の6つを退職の手続きの書類に載せておきます。

1. 人事の連絡を受ける。 退職日や異動日が決まったら、システムの管理者に知らせる流れを決めておく
2. アカウントを停止する。 退職日の終業後など、止める時刻も決める。異動なら役割を付け替える
3. ログイン中の状態も切る。 停止しても、開いたままの画面から操作できないよう、ログインの状態を無効にする
4. 担当の引き継ぎをする。 その人が担当していた顧客や案件を、別の担当者に付け替える
5. ほかのサービスも止める。 メールや共有のフォルダ、外部のサービスのアカウントも同じ日に止める
6. 記録を残す。 誰のアカウントを、いつ、誰が止めたかを残す

あわせて、決まった間隔で権限の棚卸しをします。利用者と役割の一覧を出し、使われていないアカウントや、異動の前の役割が残っている人がいないかを、責任者が確かめます。

操作ログ（監査ログ）は、誰が・いつ・何に・何をしたかを残す

操作ログは、何かが起きたときに「誰が、いつ、何に対して、何をしたか」を後から確かめるための記録です。すべてを残すと読めなくなるので、残す操作と項目を先に決めます。

委員会の通則編は、組織的な安全管理措置の手法の例として、情報システムで個人データを扱う場合の担当者の利用状況（ログイン実績、アクセスログなど）の記録を挙げています。IPAのガイドラインも、認証ログなどを取得・保管し、改ざんを防いだうえで定期的に見直すことを求めています。

残す操作は、次のものから始めます。

• ログインの成功と失敗、ロック
• 利用者の追加、停止、役割の変更
• 顧客の情報の削除と、一括の更新
• CSVなどでの一括出力
• システムの設定の変更

1件の記録に持たせる項目は、次のとおりです。

作る側として守りたいのは、操作ログに個人情報やパスワードを書き込まないことです。ログに氏名や連絡先を書くと、ログそのものが守るべき個人データになり、見られる人を限る必要が出てきます。記録は対象のIDまでにして、中身は本体のデータベースで確かめる形にします。

ログの保存先は、ふだんの業務データとは分け、追記だけができて書き換えや削除ができない形にします。ログを見られるのは管理者と責任者に限り、ログを見たこと自体も記録します。保存する期間は、IPAのガイドラインにあるとおり、組織として方針を決めて、その期間を過ぎたものだけが消えるようにします。

操作ログは、取るだけでなく、見る日を決める

操作ログは、見なければ、問題が起きた後に調べる材料にしかなりません。月に一度など見る日を決め、確かめる観点をあらかじめ決めておくと、短い時間で済みます。

すぐに知りたいもの（管理者の追加、大量の出力など）は、起きたときに責任者へ通知が届くようにしておくと、月に一度の確認を待たずに気づけます。

最低限の作り方を、発注の前に1枚にまとめる

ここまでの内容を、システムを作り始める前に決めておく順番にすると、次の6つになります。

1. 扱う情報を書き出す。 顧客の個人情報、取引の条件など、守る必要のある情報がどの画面に出るかを洗い出す
2. 役割ごとの権限表を作る。 「見る・直す・消す・出力する」と、利用者の管理、設定の変更を分ける
3. ログインの決まりを決める。 1人1アカウント、多要素認証を必須にする役割、ロックの条件
4. 退職・異動の手順を決める。 停止する人、時刻、引き継ぎ、記録
5. 操作ログの項目と保存の方針を決める。 残す操作、項目、保存先、期間、見られる人
6. 見る日と通知を決める。 月ごとに確かめる観点と、すぐ知らせる操作

株式会社bundlyzeでは、受託した業務システムを要件を決める段階から受け持ち、作った後の保守運用まで同じ担当で続けています。要件定義の時点でこの6つが決まっていれば、作る側は権限の確認とログの記録を最初から組み込めます。要件の決め方から保守運用までをどう進めるかは、業務システムの開発についてのページにまとめました。

参考にした公的な資料

どちらも2026年10月2日を確認日としています。改訂で項目の番号や名前が変わることがあるので、使う前に最新の版を見てください。

• IPA：中小企業向けの情報セキュリティ対策の指針（第4.0版）の公開ページ：本編の「攻撃等の防御」にあるIDとアクセスの管理、ログの取得と見直し、用語の「ログ管理」
• 個人情報保護委員会：通則編の公開ページ：10-3 組織的安全管理措置、10-6 技術的安全管理措置