01「開発会社に任せておけばいい」が危険な理由

業務システムを外注するとき、「セキュリティは技術的な話だから開発会社に任せておけばいい」と考える発注者は珍しくありません。しかし、セキュリティの設計で本当に重要な判断は、技術の知識より業務の知識が必要なものがほとんどです。

たとえば、「このシステムを使うのは誰か」「どの職種のスタッフがどのデータを見てよいか」「顧客の個人情報はどこに保存されるか」という問いは、業務を知っている発注者側でなければ答えられません。これらを整理せずに開発を進めると、完成したシステムが「全スタッフが全顧客データを見られる状態のまま動いている」「退職した元スタッフのアカウントが有効なまま残っている」といった状態になっていることがあります。

特に、顧客の氏名・電話番号・予約履歴・購買情報などの個人情報を扱う業務システムでは、情報の漏洩やデータの消失が事業の信頼に大きく関わります。「何かあってから対処する」では手遅れになることも多く、設計の段階から要件として伝えておくことが最も確実な対策です。

この記事では、業務システムを外注する際に発注者が確認しておくべきセキュリティの基本を5点に絞って解説します。「エンジニアでなくても、ここだけ押さえておけば大丈夫」という水準でまとめています。

POINT

「セキュリティは技術の話」という先入観を一度手放して、「自社の業務でどんなデータを扱い、誰がアクセスできる必要があるか」を整理するところから始めましょう。それが、発注者ができる最も大切なセキュリティ対策の第一歩です。

02チェックポイント①：権限管理——誰がどのデータを操作できるかを分ける

権限管理とは、「このアカウントはこの画面を操作できるが、あのデータは閲覧できない」というルールをシステムに組み込む仕組みです。業務システムを設計するとき最も見落とされやすく、かつ最も重要なポイントのひとつです。

よくある失敗パターン

権限管理をきちんと設計しないと、次のような問題が起きることがあります。

予約管理システムであれば「受付スタッフは予約の確認と変更だけ」「管理者は全顧客データと売上レポートも閲覧可能」、顧客管理ツールであれば「担当者は自分の担当顧客のみ閲覧」「マネージャーは全顧客を一覧表示」といった形で、役割ごとに画面・データのアクセス範囲を明確に設計することが基本です。

発注時に確認すべき3点

確認項目内容
ロール（役割）ごとのアクセス分離管理者・一般スタッフ・閲覧専用など、権限レベルを設計に含めているか
アカウントの無効化手順担当者が退職・異動したとき、アクセスをすぐ止める手順があるか
必要最小限の原則「業務に必要な範囲だけ」アクセスできる設計になっているか

要件定義の段階でこの表を埋めておくと、開発会社への指示がより具体的になります。発注前の整理の仕方については、発注者側の要件定義のやり方もあわせてご覧ください。

03チェックポイント②・③：パスワード設計と通信の保護

パスワード・認証の設計

業務システムへのログインは、スタッフが毎日使う入口です。ここの設計が甘いと、部外者にアクセスされるリスクが生まれます。発注時に確認しておきたいポイントを整理します。

初期パスワードの扱い：開発段階でテスト用に設定した初期パスワードが、そのまま本番環境で使われ続けているケースがあります。運用開始時に全アカウントのパスワードをリセットする手順を、開発会社と取り決めておきましょう。

パスワード強度のルール：「8文字以上・英数記号を含む」といったルールをシステム側で強制できる設計になっているかを確認します。推測されやすい単純なパスワードを登録できないようにする仕組みが望ましいです。

パスワードの保存方法：パスワードは「ハッシュ化」という処理をして保存するのが基本です。ハッシュ化とは、元の文字列を元に戻せない形に変換して保存する処理で、データベースが万が一流出してもパスワードそのものが読み取られにくくなります。「パスワードはどのように保存していますか？」と一言確認するだけで、開発会社のセキュリティへの意識がある程度分かります。

二段階認証（2FA）：管理者権限を持つアカウントについては、パスワードに加えてスマートフォンへの確認コードなどを組み合わせる二段階認証の導入を検討すると、不正ログインのリスクを下げやすくなります。対応可能かどうかを発注時に確認しておきましょう。

通信の保護（HTTPS）

業務システムのURLが「https://」で始まっていることを確認してください。これは、ブラウザとサーバーの間で送受信されるデータを暗号化する仕組みです。「http://」のままでは、ネットワーク上でデータが読み取られるリスクがあります。現在は標準的な対応ですが、発注時に明示しておくと安心です。

POINT

パスワードの管理は「開発会社に設定してもらうもの」ではなく、「担当者が交代するたびに自社で変更・管理できる仕組みを作ってもらうもの」という認識が大切です。運用ルールまで含めて相談しておくと、長く安心して使えます。

04チェックポイント④：バックアップと個人情報の取り扱い

バックアップの設計

「データが消えた場合、元に戻せますか？」——この質問を、発注時に開発会社に投げかけてみてください。バックアップの設計は運用品質を決定づける重要な要素ですが、明示的に要件として伝えないと、コスト節約の判断で後回しにされることがあります。

確認しておきたいポイントは次のとおりです。

特に顧客の予約情報・購買履歴・個人情報を扱うシステムでは、データが失われたときの影響が大きいため、バックアップの要件を設計の段階から明確にしておくことが重要です。

個人情報の取り扱い

顧客の氏名・電話番号・住所・メールアドレスなどの個人情報を扱う業務システムは、個人情報保護法の対象になります。外注開発の場合、発注者（委託元）と開発会社（委託先）の両方に責任が生じます。

確認項目内容
データの保存場所国内のサーバーか、海外のクラウドか。データが保存される国・地域を確認する
暗号化の有無データベース内の個人情報が暗号化されているか
再委託の管理開発会社がさらに別の会社に業務を委託する場合、その管理体制を確認する
データの削除方針不要になった個人情報（退会・期限切れ等）をどのように削除するか

「どこにデータが保存されているか分からない」という状態のまま運用を始めると、顧客や関係者から問い合わせを受けたときに答えられません。要件定義の段階で、データの保存・管理・削除の方針を確認しておきましょう。

個人情報の取り扱いは、システムの設計と業務の運用ルールが両輪になって機能します。技術的な対策だけでなく、「社内で誰がアクセス権を管理するか」「退職者のアカウントをどう処理するか」といった運用ルールも、開発会社と一緒に設計しておくことをおすすめします。

05チェックポイント⑤：ログ管理と発注時の確認の進め方

ログ管理とは

ログとは、「誰が・いつ・何をしたか」をシステムが自動的に記録した履歴データです。たとえば「管理者アカウントでログイン」「顧客データを閲覧」「レポートをエクスポート」といった操作の記録が残ります。

ログがあることで、次のようなことが可能になります。

業務システムに「ログイン履歴」「データ操作の記録」「エラーログ」が残る設計になっているかを確認してください。コスト削減のためにログ機能が省かれることもあるため、明示的に要件として伝えることが大切です。

発注時のセキュリティ確認チェックリスト

ここまでの5点をまとめたチェックリストです。要件定義の段階で開発会社に伝える際の参考にしてください。

#確認ポイント開発会社への質問例
①権限管理スタッフのロールごとに閲覧・操作できる範囲を分けられますか？アカウントの無効化手順はありますか？
②パスワード・認証設計パスワードはハッシュ化されますか？二段階認証は対応可能ですか？
③通信の保護HTTPSは標準対応ですか？
④バックアップと個人情報バックアップの頻度・保存期間・復元テストの内容を教えてください。個人情報はどこに・どう保存されますか？
⑤ログ管理ログイン履歴・データ操作記録・エラーログは残りますか？保存期間はどれくらいですか？

セキュリティは「後から足す」のが最も費用がかかり、品質も落ちやすいものです。初期の設計段階から要件として伝えることが、長く安心して使えるシステムを手に入れる最も確実な方法です。

公開後の保守フェーズでセキュリティに関連するコストが発生することもあります。その全体像についてはシステム保守費用の相場と内訳もあわせてご覧ください。また、生成AIのAPIを業務システムに組み込む場合はAPIキーの管理も重要なセキュリティ要件になります。生成AIのAPIを業務に組み込む前の注意点もご参照ください。

まとめ

業務システムのセキュリティは、技術の問題である前に業務の問題です。権限管理・パスワード設計・バックアップ・個人情報の取り扱い・ログ管理の5点を要件定義の段階から整理して伝えることで、完成後も安心して長く使えるシステムに近づきます。