業務システムのセキュリティ、最低限どこまでやるか ── 発注側が確認する6項目

「セキュリティは万全ですか」。提案を受けている開発会社に、そう聞いた方は多いと思います。返ってきたのは、たぶん「万全です」でした。

この質問には構造的な欠陥があります。答える側に「はい」以外の選択肢がありません。「いいえ」と言えば失注します。仮に正直な会社が「ここが弱いです」と答えたとして、それが弱点の全部かどうかは、聞いた側には確かめようがない。結局、判断材料が何も残りません。

代わりに聞くことは、もっと地味です。この記事では6項目を挙げます。それぞれ、どう聞くかと、どんな答えが返ってきたら不十分かを並べました。扱うのは作るものの中身の話です。会社の体制のほうは開発会社の選び方に別の5つとして書いてあるので、質問が重ならないように分けています。

聞き方を変えると、答えが具体的になる

先に6項目を並べます。専門用語なしで聞けるものだけにしました。

項目	こう聞く
1. 通信の暗号化	httpsは全ページですか。証明書の更新は自動ですか
2. パスワードの保存	パスワードは、どういう形で保存されますか
3. 本番データの閲覧	本番のデータを見られるのは、名前を挙げると誰ですか
4. バックアップと復元	いつの時点まで戻せますか。復元を一度見せてもらえますか
5. 操作のログ	誰が何をしたかは追えますか。何ヶ月分残りますか
6. 退職者の停止	担当者が辞めたとき、アカウントを止める手順はありますか

順番には意味があります。上の2つは入口の話、真ん中の2つは中で起きることの話、下の2つは何ヶ月か経ってから効いてくる話です。下に行くほど地味で、下に行くほど後回しにされます。

なぜ6つなのか、という点だけ先に。もっと細かい項目を並べた資料は世の中にいくらでもあります。ただ、20項目を渡されて全部を確認できた発注担当者を、私は見たことがありません。打ち合わせの中で自然に聞けて、答えの良し悪しが素人でも判断できる。その条件で削っていくと、このくらいの数になります。

もうひとつ。この6つは、あとから直すと高くつくものを優先して選びました。パスワードの保存方法を変えるには、全員にパスワードの再設定を依頼することになります。ログを後から足すと、足す前の期間は永久に追えません。リリース前に確認する意味があるのは、そういう性質のものです。

通信とパスワード ── 入口の2つ

まず通信です。ブラウザと、システムが動いているサーバーの間が暗号化されているか。アドレスバーのhttpsがそれです。新しく作るものでここが抜けていることはほぼありませんが、確認する価値は別のところにあります。

聞き方。 「httpsは全ページですか。証明書の更新は自動ですか。」

全ページ、というのが効きます。ログイン画面だけhttpsで、そのあとの一覧画面がhttpのまま、という作りは今でもたまに見ます。証明書の期限切れで画面が開かなくなる事故も、更新を手作業でやっていると起きます。

不十分な答え。 「SSLを入れています」。入れた、ではなく、切れたときにどうなるかまで答えられるかを見てください。

次にパスワードです。技術の話に聞こえますが、聞くのは簡単です。

聞き方。 「パスワードは、どういう形で保存されますか。」

返ってきてほしいのは「ハッシュ化して保存します。元には戻せません」という趣旨の答えです。ハッシュは、元のパスワードから計算した文字列だけを保存して、元の文字列は保存しない仕組みのことです。万一データが漏れても、そこからパスワードそのものは復元できません。

不十分な答え。 「暗号化しています」。暗号化は鍵があれば元に戻せます。パスワードは元に戻せてはいけないものなので、この言葉が出てきたらもう一段聞いてください。「鍵があれば戻せる形ですか、それとも戻せない形ですか」と。

ついでに、パスワードを忘れたときの再発行が、メールで文字列をそのまま送る形になっていないかも見ておくと安心です。再設定用のリンクを送る形が普通です。

本番のデータを、誰が見られるか

ここがいちばん現実的なリスクです。外からの攻撃より、内側から普通に見られるほうがずっと起きやすい。

聞き方。 「本番のデータを見られるのは、名前を挙げると誰ですか。」

人数ではなく名前で聞くのがコツです。「必要最小限にしています」と返ってきたら、「それは何人で、役割で言うと誰ですか」と続けます。開発会社側で本番のデータベースに触れる人と、自社側で管理画面から全件を見られる人。両方を出してもらってください。

不十分な答え。 「権限管理をしています」。権限の仕組みがあることと、実際に誰が何を見られるかは別の話です。仕組みはあるが結局全員が管理者、という設定は珍しくありません。

私たちが自社で使っている業務システムでは、使う人が3人で全員が同じ業務をするため、担当者ごとの権限分けはあえて作りませんでした。その代わり、誰が何を変えたかは監査ログと案件ごとの履歴に全部残し、データベース側でも行ごとのアクセス制御を有効にしています。どこまでやって、どこをやらなかったかは研修事業の業務コンソールに書きました。

あわせて、開発中のテスト環境に本番のデータをそのまま入れていないかも聞いておきます。ここが抜け穴になりやすい。「テスト用には名前やメールアドレスを置き換えたデータを使います」と答えられる会社は、手順が固まっています。

自社側の設定も同じです。経理は金額を見る、現場は自分の担当分だけ見る。こういう線引きは、作る前に決めておくほうが安く済みます。誰が使うかの整理は開発会社に相談する前に、決めておくと話が早い3つのことの1つ目とつながっています。

バックアップは「ある」ではなく「戻せる」

バックアップは「取っています」で終わりがちです。ただ、取ることと戻せることは違います。

聞き方。 「いつの時点まで戻せますか。復元を一度、実際にやって見せてもらえますか。」

この「見せてください」が効きます。実演を頼むと、その会社が復元を一度でもやったことがあるかが分かります。やったことがなければ、その場では答えられません。それ自体は責める話ではなく、リリース前に一度やっておきましょう、という提案にできます。

戻せる時点の粒度も聞いておきます。1日1回のバックアップなら、最悪その日の入力がまるごと消えます。1日分をやり直せる業務なのか、それでは困るのか。ここは技術ではなく業務側の判断です。

不十分な答え。 「クラウドなので自動でバックアップされます」。自動で取られていても、戻す操作をするのは人です。誰が、どの画面から、どのくらいの時間で戻すのか。そこが決まっていないと、いざというときに動けません。

復元の手順を決めていなかったために、本来なら数時間で終わる復旧に丸一日かかる。こういう話は珍しくありません。差は、手順書が1枚あるかないかです。

ログと、辞めた人のアカウント

ログは平常時には誰も見ません。見るのは、何かが起きたあとです。

聞き方。 「誰がいつ何をしたかは、あとから追えますか。何ヶ月分残りますか。」

全部の操作を記録する必要はありません。お金に関わるもの、データを消すもの、権限を変えるもの。この3つが残っていれば、たいていの調査はできます。「請求書の金額が書き換わっている」と言われたときに、誰がいつ変えたかを出せるかどうか。

不十分な答え。 「サーバーのログは残っています」。サーバーのアクセスログと、業務上の操作履歴は別物です。前者で分かるのは「どのURLが呼ばれたか」までで、「誰が何の値をどう変えたか」は出てきません。

保存期間も確認します。1ヶ月しか残らないログは、四半期の棚卸しで発覚する種類の問題には間に合いません。

6つ目が、退職者のアカウントです。地味ですが、実際の事故はここから起きます。

聞き方。 「担当者が辞めたとき、アカウントを止める手順はどうなりますか。誰が実行しますか。」

止めるのは自社の担当者なのか、開発会社に連絡するのか。連絡する場合、何時間で止まるのか。退職は事前に分かっていることがほとんどなので、退職日にあわせて止める運用を決めておけば済みます。

不十分な答え。 「言っていただければ対応します」。対応の中身が決まっていない、という意味です。管理画面から自社で止められるのが一番早い。それができない作りなら、なぜできないのかを聞いてください。

開発会社側の担当が抜けたときの扱いも、同じタイミングで確認しておくと話が対等になります。リリース後に誰が何を見るのかは運用・保守の中身を項目ごとにに書きました。

個人情報を扱うなら、追加で3つ

ここまでの6つは、社内向けの業務システムでも共通です。扱うデータに個人情報が入る場合は、上に3つ足してください。

何のために集めるかを書いてあるか。 利用目的を決めて、本人に分かる形にしておく必要があります。画面のどこに何を書くかは、フォームを作る段階で決めます。あとから足すと、すでに登録した人への案内が別途要ります。

開発会社に預ける範囲が契約に書いてあるか。 個人データの取扱いを外部に委託する場合、委託した側に監督の責任が残ります。開発会社がどこまで触るのか、再委託はあるのか。契約書のどこを読むかはシステム開発の契約書で、発注側が読むべき5つの場所にまとめています。

漏れたときに誰がどこへ連絡するか。 個人情報の漏えいが起きた場合、個人情報保護委員会への報告と本人への通知が必要になるケースがあります。2026年9月時点での一般的な理解として書いています。誰が最初に気づき、誰が判断し、誰が連絡するか。この順番を1枚の紙にしておくだけで、当日の動きが変わります。

細かい要件は、業種と扱う情報によって変わります。医療、金融、教育あたりは個別のルールがあるので、該当しそうなら公式の資料か専門家に当たってください。開発会社の「大丈夫です」を根拠にしないほうがいい部分です。

社内10人のシステムに、認証取得は要らない

逆の話も書いておきます。セキュリティは、かけようと思えばいくらでもかけられます。ただ、かけた分だけ初期費用も月額も上がりますし、使う人の手間も増えます。

社内10人で使うだけの在庫管理システムに、SOC2やISMSといった第三者認証の取得は要りません。あれは、他社に売るサービスが取引先から提示を求められるときに意味を持つものです。自社で使うシステムのために取るものではありません。

多要素認証を全員に必須にするかどうかも、状況次第です。たとえば、現場の担当者が手袋をしたままタブレットを触る業務（架空の想定例です）で、毎回スマートフォンの認証コードを求めるとどうなるか。そのうち全員が同じ端末を使い回します。かえって危なくなる。

判断の目安は3つです。扱うデータが漏れたときに、誰がいくら損をするか。外部の取引先から要求されているか。監督官庁や業界のルールで決まっているか。どれにも当てはまらないなら、この記事の6項目で足ります。

線引きの目安として、よく相談される対策を並べておきます。自社の状況に当てはめてみてください。

対策	最初から入れる	求められてから足す
httpsとパスワードのハッシュ化	常に入れる	──
役割ごとの権限設定	使う人が2種類以上いるなら入れる	全員が同じ業務なら後回しでよい
主要な操作のログ	お金・削除・権限変更は入れる	閲覧履歴まで残すかは後で判断
多要素認証	社外から使う、金額を動かすなら入れる	社内限定・閲覧中心なら後でよい
IPアドレスによる接続制限	事務所からしか使わないなら入れやすい	外出先で使うなら合わない
第三者認証の取得、外部監査	──	取引先や業界ルールで求められたとき

表の右の列に入るものは、必要になった時点で足せます。足すときの費用は、最初から入れる場合と比べて大きくは変わりません。逆に左の列は、あとから入れると影響範囲が広がります。この差が、優先順位の理由です。

足りない分は、あとから足せます。最初から全部を積むと、動き始める前に予算が尽きる。これはセキュリティに限った話ではありません。

見積もりに「セキュリティ対策一式」とだけ書かれていたら、中身を分けてもらってください。この6項目のどれが入っていて、どれが別料金なのか。そこが分かれば、他社の見積もりと並べられます。含まれるものと含まれないものの分け方は料金のページに書いています。