開発会社に確認したいセキュリティの項目：発注する前と公開する前

新しい業務システムや Web サービスを開発会社に頼むとき、セキュリティについてどこまで話しているでしょうか。

「セキュリティはプロにお任せしたい」と考えるのは自然なことです。発注する側の多くはエンジニアではありませんし、専門用語の並んだ説明を聞いても、何を判断すればよいのか分かりにくいものです。

ただ、セキュリティには、開発会社だけでは決められないことがたくさんあります。どの情報がいちばん大事か。誰にどこまで見せてよいか。対策にどれだけ費用をかけるか。こうしたことは、業務と事業を知っている発注する側にしか答えられません。そして、決めないまま開発が進むと、公開の直前になって「その対策は見積もりに入っていません」「今から入れると作り直しになります」ということが起きやすくなります。

この記事は、システム開発を頼もうとしている、あるいは頼んでいる最中の、企業の担当者に向けて書いています。エンジニアでなくても使えるように、専門用語はできるだけかみ砕きました。次のことを順にまとめます。

• なぜ、発注する側がセキュリティを決める必要があるのか
• 発注する前に、開発会社と確認する項目
• 確認したことを、契約と仕様に残す方法
• 公開する前に、開発会社と確認する項目
• そのまま使えるチェックリスト

結論：セキュリティは「お任せ」ではなく「一緒に決めて、書面に残す」もの

先に結論を書きます。発注する側が押さえておきたいのは、次の2つの時期です。

発注する前（開発を始める前）に決めること

1. 守る情報と、それが漏れたり止まったりしたときの影響
2. 参照するセキュリティの基準と、対策の範囲
3. 開発や保守の体制（誰がどこに入れるか、再委託するか、データをどう扱うか）
4. 事故が起きたときの連絡と役割

公開する前に確かめること

1. 脆弱性の確認（診断やレビュー）をしたか。見つかった指摘をどう扱ったか
2. 公開する環境の設定（初期のパスワード、管理画面、テスト用のデータ）
3. 運用への引き継ぎ（アカウントの一覧、部品の更新の担当、記録の保管）

どれも、開発会社に「やってください」と頼むのではなく、「一緒に決めて、決めた内容を書面に残す」ことがポイントです。以下で、その理由と具体的な確かめ方を書いていきます。

なぜ、発注する側がセキュリティを決める必要があるのか

開発会社の責任は「決めた仕様どおりに対策すること」まで

IPA が公開している「情報システム・モデル取引・契約書（第二版）」は、システム開発の契約のひな形として広く参照されています。このモデル契約には、セキュリティについての条文（第50条）があり、開発を始める前までに、発注する側と開発会社が協議してセキュリティの仕様を確定させ、書面で定めることになっています。

同じモデル契約の解説には、次のように書かれています。

ベンダが正当な理由なくセキュリティ仕様に従ったセキュリティ対策を講じなかった場合は、契約不適合責任等の法的責任を負うことになる。一方、ベンダの責任は、セキュリティ仕様への適合性にとどまり、セキュリティインシデントを完全に免れることを保証するものではない。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

つまり、開発会社が責任を持つのは、「決めたセキュリティの仕様どおりに作ること」です。どんな仕様にするかが決まっていなければ、何をもって十分とするかの基準もありません。発注する側がセキュリティを決めることは、開発会社を疑うためではなく、両者が同じ基準で仕事をするための準備です。

解説では、ソフトウェアを作り込んでしまってから対策を講じるのには限界があり、費用も大きくなりやすいので、開発に取りかかる前に、発注する側と開発会社がリスクについて話し合う必要がある、とも書かれています。デジタル庁の「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」も、企画の段階からセキュリティの方針を定めることで、致命的な対策の漏れによる手戻りを防ぎ、納期の確保やセキュリティの費用の削減につながる、としています。

委託先を狙った攻撃は、組織にとって2番目に大きな脅威

IPA が毎年まとめている「情報セキュリティ10大脅威 2026」の組織向けの順位では、1位が「ランサム攻撃による被害」、2位が「サプライチェーンや委託先を狙った攻撃」でした。2位の脅威は、2019年に初めて選ばれてから、8年続けて入っています。4位には「システムの脆弱性を悪用した攻撃」も入っています。

自社がどれだけ気をつけていても、システムを作る会社、保守する会社、データを扱う会社のどこかに隙があれば、そこから情報が漏れることがあります。

実際に公表された事例を2つ挙げます。

• NTT西日本グループの事例：コールセンターのシステムの運用・保守に携わっていた元派遣社員が、システムの管理者アカウントを悪用し、約10年にわたって顧客の情報（69のクライアントの928万件）を不正に持ち出していました。同社がまとめた課題には、保守用のアカウントを複数の人で共用していて個人を特定できないシステムがあったこと、不正を見つけるための記録（ログ）の点検が不十分だったことが挙がっています（NTT西日本の公表資料、2024年2月29日）。
• イセトーの事例：印刷などの業務を受託していた会社がランサムウェアの被害を受け、委託元の顧客の個人情報が流出しました。同社は原因として、VPN からの不正アクセスに加えて、その情報を扱ってはいけないサーバーに作業の効率のために保管していたこと、業務が終わったら消すべきデータを消せていなかったことを挙げています（イセトーのお知らせ、2024年10月4日）。

どちらも、高度な技術の問題というより、アカウントの持ち方、記録の点検、データの消し方といった、決めておけば確かめられることが原因の一部になっています。発注する前に確認する項目には、こうした点も入れておきたいところです。

個人情報を預けるなら、委託先を監督する義務がある

システムで個人情報を扱う場合、発注する側には法律上の義務もあります。個人情報保護法の第25条は、個人データの取扱いを委託するときは、委託先に対して「必要かつ適切な監督を行わなければならない」と定めています。

個人情報保護委員会のガイドライン（通則編）では、その中身として、適切な委託先を選ぶこと、委託の契約を結ぶこと、委託先での取扱いの状況を把握すること、の3つを挙げています。必要な安全管理の措置を委託先に指示しなかった結果、委託先が個人データを漏らした場合は、監督をしていない例として示されています。

IPA の「中小企業の情報セキュリティ対策ガイドライン」（第4.0版）も、業務の一部を外部に委託する場合は、委託先でも少なくとも自社と同等の対策が行われるようにする必要があり、そのために契約書に委託先の責任や実施すべき対策を明記して合意する必要がある、としています。委託先の不備が原因でも、委託元としての管理責任を問われる、とも書かれています。

発注する前に、開発会社と確認する項目

ここからは、発注する前に確認したい項目を具体的に書きます。項目の立て方は、IPA の「非機能要求グレード2018」のセキュリティの項目を参考にしました。非機能要求グレードは、機能以外の要件（性能、止まらなさ、セキュリティなど）について、発注する側と開発会社の認識をそろえるために IPA が公開している資料です。セキュリティについては、リスクの分析、診断、アクセスの制限、データの秘匿、不正の追跡・監視、事故への対応など、11の項目に分けています。

全部を細かく決める必要はありません。ただ、次の項目は、エンジニアでなくても答えられ、しかも発注する側にしか答えられないものです。

1. 守る情報と、影響の大きさ

最初に決めたいのは、そのシステムが扱う情報のうち、何がいちばん大事かです。

• 個人情報（氏名、住所、電話番号、メールアドレス）を扱うか。何人分くらいか
• クレジットカードや口座の情報を扱うか
• 取引先から預かった情報や、契約で外に出せない情報を扱うか
• システムが止まったら、業務はどのくらい困るか。何時間なら待てるか

この答えによって、必要な対策の強さが変わります。社内の数人だけが使う予定表と、何万人もの顧客の情報を扱う会員サイトでは、かけるべき対策も費用も違います。開発会社は、この答えを聞いて初めて、対策の重さを提案できます。

2. 参照するセキュリティの基準

次に、どの基準を参考にして作るかを決めます。モデル契約の第50条にも、参照するガイドラインの名称と版を仕様に入れる、という選択肢の条項があります。

Web のシステムでよく参照されるのは、次のような資料です。

発注する側が中身を理解する必要はありません。「どの基準を参考にして作り、どの基準で確かめますか」と聞き、答えを仕様書に書いてもらえば十分です。基準が決まっていれば、公開する前に確かめるときの物差しにもなります。

ちなみに、OWASP Top 10:2025 では、1位が「アクセス制御の不備」（見てはいけない人が見られる、操作できてはいけない人が操作できる）、2位が「セキュリティの設定の誤り」、3位が「ソフトウェアのサプライチェーンの不備」（使っている部品や、その入手の経路の問題）です。次の項目の多くは、これらに対応しています。

3. 誰が、何を見られて、何ができるか

アクセスの制限は、発注する側が業務の言葉で決められる項目です。

• 利用者の種類（社員、取引先、一般の顧客、管理者など）
• それぞれが見てよい情報と、操作してよいこと
• 管理者の画面を、社外から使えるようにするか
• ログインに、パスワードに加えてスマートフォンでの確認など（多要素認証）を求めるか
• 退職した人や、取引の終わった相手のアカウントを、誰がいつ止めるか

「営業部の人は自分の担当の顧客だけ見られる」「経理だけが金額を直せる」のように、業務の言葉で書いた表を渡すと、開発会社はそれを権限の設計に落とし込めます。

4. 大事なデータの守り方

扱う情報が決まったら、そのデータの守り方を確認します。非機能要求グレードでは「データの秘匿」と呼ばれている項目です。

• 通信は暗号化するか（Web なら当然、HTTPS にします）
• 保存するデータのうち、暗号化するものはどれか（パスワード、カード情報、個人情報など）
• バックアップはどこに、どのくらいの期間置くか。バックアップも同じように守るか
• 使い終わったデータ、テストに使ったデータを、いつ、どう消すか

イセトーの事例のように、消すべきデータが残っていたことで被害が広がることがあります。データを消す時期と方法も、決めておく項目に入れてください。

5. 記録を残し、異常に気づく仕組み

誰がいつ何をしたかの記録（ログ）を残し、点検する仕組みです。

• ログインや、大事なデータの閲覧・変更の記録を残すか
• 記録をどのくらいの期間保管するか
• 誰が、どのくらいの頻度で記録を確かめるか
• おかしな動きがあったときに、誰に知らせるか

NTT西日本の事例では、記録の点検が十分でなかったことが課題に挙がっていました。記録を残すだけでなく、誰が見るかまで決めておくことが大事です。記録を確かめる作業は、公開したあとの運用の費用にもかかわるので、保守の契約と合わせて考えてください。

6. 開発と保守の体制

開発会社の側の体制についても、遠慮せずに確認してかまいません。

• 開発や保守で、本番の環境やデータに触れる人は誰か
• 管理者のアカウントを、人ごとに分けて発行するか（共用しないか）
• 開発の一部を、別の会社に再委託するか。する場合、どの会社にどの作業か
• 開発や保守の作業で、本番のデータを手元に持ち出すことがあるか。その場合の扱いと消し方
• 情報セキュリティの社内の決まりや、第三者の認証（ISMS など）があるか

個人情報保護委員会のガイドラインでも、再委託については、事前に報告を受ける、または承認する、定期的に確かめる、といったことが望ましいとされています。

これらは、開発会社を疑って聞くものではありません。きちんとした会社であれば、すでに社内で決まっていることが多く、すぐに答えてもらえるはずです。答えを書面でもらっておけば、社内で委託先を選んだ理由を説明するときにも使えます。

7. 使う部品と、その更新

今のシステムは、多くの部品（オープンソースのライブラリや、フレームワーク、クラウドのサービス）を組み合わせて作られています。部品に脆弱性が見つかれば、システムにも影響します。

• 主に使う言語、フレームワーク、クラウドのサービスは何か
• それぞれのサポートの期限はいつか
• 使っている部品の一覧を残すか
• 部品に脆弱性が見つかったとき、誰が気づき、誰が更新するか。その費用は保守の契約に入っているか

2026年10月の PHP の脆弱性のように、広く使われている部品に重大な問題が見つかると、多くのシステムで急ぎの対応が必要になります。そのとき何が起きたかは、PHPの重大な脆弱性で何が起きたかで書きました。部品の更新の担当を決めておくことは、公開したあとのシステムを守るうえで欠かせません。

8. 事故が起きたときの連絡と役割

最後に、それでも事故が起きたときの決めごとです。

• 開発会社や保守の会社が異常に気づいたとき、誰に、どのくらいの時間で連絡するか
• 発注する側の連絡先（夜間や休日を含む）
• システムを止める判断を、誰がするか
• 原因を調べる作業と、直す作業の費用の扱い

個人データの漏えいなどが起きた場合、個人情報保護委員会への報告や本人への通知が必要になることもあります。そのときに必要な情報を、開発会社からどう受け取るかも、決めておくと慌てずに済みます。

確認したことを、契約と仕様に残す

ここまでの項目は、話し合っただけでは残りません。モデル契約の第50条にならって、次のように書面に残すことをおすすめします。

• 開発を始める前に、セキュリティの仕様を確定させる：仕様書の一部として、守る情報、参照する基準、対策の一覧を書く
• 発注する側が出す情報を決める：使う環境（ネットワーク、ほかのシステムとのつながりなど）の情報は、発注する側から開発会社に渡す必要がある
• 仕様を変えるときの手順を決める：途中で対策を足したり減らしたりするときは、費用と納期の影響を確かめてから変える
• 実装しない対策を記録する：費用や使い勝手との兼ね合いで、ある対策を入れないと決めたときは、その判断と理由を議事録などに残す

最後の点は、モデル契約の解説でも強調されています。すべての対策を入れるのが正解とは限りません。費用に見合わない対策を入れないと判断するのは、発注する側の正当な選択です。大事なのは、それを「知らないうちに抜けていた」のではなく、「分かったうえで選んだ」と後から説明できるようにしておくことです。

要件のまとめ方全体については、要件定義とは：開発会社に頼む前に、社内でまとめておくことで書きました。セキュリティは、そこで「非機能要件」と呼んでいるものの一つです。

公開する前に、開発会社と確認する項目

開発が進み、公開の日が近づいたら、次の項目を確かめます。

1. 脆弱性の確認をしたか

作ったシステムに、脆弱性が残っていないかを確かめる作業です。非機能要求グレードでも、ネットワーク、Web、データベースのそれぞれについて診断をするかどうかが、決める項目として並んでいます。Web の対策の項目には、実施した対策が有効かを確かめるために、専門家のレビューやソースコードの診断、ツールによるチェックも検討する必要がある、と書かれています。

確認の方法には、次のようなものがあります。

• 開発会社の中で、作った人とは別の人がコードを確かめる（レビュー）
• ツールを使って、既知の脆弱性がないかを調べる
• 専門の会社に、外から攻撃を試すように診断してもらう（脆弱性診断）

どこまでやるかは、1で決めた「守る情報と影響の大きさ」によります。外部の会社に診断を頼む場合、IPA は、経済産業省の基準に適合した事業者の「情報セキュリティサービス基準適合サービスリスト」を公開しています。脆弱性診断やペネトレーションテスト（侵入を試す検査）などの区分ごとに、事業者を探せます。

診断をするかどうか、誰がどの範囲でするかは、できれば発注する前の段階で決め、見積もりに入れておいてください。公開の直前になって追加すると、日程にも費用にも余裕がなくなります。

2. 見つかった指摘をどう扱ったか

診断やレビューで指摘が見つかるのは、珍しいことではありません。大事なのは、その扱いです。

• 見つかった指摘の一覧と、それぞれの深刻さ
• 公開までに直したもの
• 公開後に直すことにしたものと、その時期
• 直さないと判断したものと、その理由

直さないと判断したものは、発注する側も内容を理解したうえで了承し、記録に残します。発注する前に決めた「実装しない対策を記録する」と同じ考え方です。

3. 公開する環境の設定

作りに問題がなくても、設定の誤りで情報が漏れることがあります。OWASP Top 10:2025 でも、設定の誤りは2位に挙がっています。公開する前に、少なくとも次の点を確かめてもらってください。

• 初期のパスワードや、開発のときに使ったパスワードが残っていないか
• テスト用のアカウントや、テスト用のデータが残っていないか
• 管理者の画面が、必要な人以外から開けるようになっていないか
• エラーが起きたときに、内部の情報が画面に出ないか
• クラウドの保存場所（ストレージ）が、誰でも見られる設定になっていないか
• バックアップが取れていて、実際に戻せることを確かめたか

4. 運用への引き継ぎ

公開した日から、システムを守る主役は、日々の運用に移ります。開発会社と、保守を担う会社（同じ会社のことも多いです）の間で、次のものを引き継いでもらいます。

• 管理者のアカウントの一覧と、それぞれの持ち主
• 使っている部品とサービスの一覧、それぞれのサポートの期限
• 記録（ログ）の保管場所と、点検の担当
• 事故が起きたときの連絡の流れ
• ドメインやクラウドの契約の名義（発注する側の名義になっているか）

最後の名義の点は、保守の会社を変えるときにもかかわります。詳しくは、開発会社を途中で変えるときにまとめています。

そのまま使えるチェックリスト

ここまでの項目を、チェックリストにまとめます。開発会社との打ち合わせで、そのまま使ってください。

発注する前（開発を始める前）

• 扱う情報（個人情報、カード情報、取引先の情報など）と、その量を伝えた
• システムが止まったときの影響と、待てる時間を伝えた
• 参照するセキュリティの基準と版を、仕様書に書いてもらった
• 利用者の種類ごとに、見てよい情報とできる操作を表にした
• 管理者の画面を社外から使うか、多要素認証を使うかを決めた
• 暗号化するデータ、バックアップの置き場所と期間を決めた
• 使い終わったデータ、テスト用のデータの消し方を決めた
• 残す記録（ログ）、保管の期間、点検の担当を決めた
• 本番に触れる人、アカウントを人ごとに分けるか、再委託の有無を確かめた
• 使う部品とサービス、サポートの期限、更新の担当を確かめた
• 事故が起きたときの連絡先、連絡までの時間、止める判断をする人を決めた
• 公開する前の診断やレビューを、誰がどの範囲でするかを見積もりに入れた
• 実装しない対策があれば、その理由を記録した

公開する前

• 脆弱性の確認（レビュー、ツール、診断）の結果を受け取った
• 指摘ごとに、直した・あとで直す・直さないの扱いを確かめ、記録した
• 初期のパスワード、テスト用のアカウントとデータが残っていないことを確かめた
• 管理者の画面の公開範囲と、エラーの表示を確かめた
• バックアップから戻せることを確かめた
• アカウントの一覧、部品の一覧、記録の保管場所を引き継いだ
• ドメインやクラウドの契約の名義を確かめた
• 公開したあとの部品の更新と、事故の対応が、保守の契約のどこに入っているかを確かめた

全部に「はい」と答えられなくてもかまいません。答えられない項目は、開発会社に相談するきっかけになります。

開発会社と話すときのコツ

最後に、セキュリティの話し合いを進めやすくするためのコツを書いておきます。

「どう守るか」より「何を守りたいか」を伝える

発注する側が、暗号の方式や設定の名前まで指定する必要はありません。「この情報が漏れると、取引先との契約に響く」「この画面が半日止まると、出荷が止まる」のように、業務への影響を伝えてください。対策の方法を考えるのは、開発会社の仕事です。

費用と対策の釣り合いを、一緒に考える

セキュリティの対策には、費用がかかります。開発会社から「この対策を入れると、これだけ費用が増えます」という説明があったら、それを入れない場合のリスクも聞いたうえで判断してください。全部入れるか、何も入れないかではなく、守る情報の重さに合わせて選ぶものです。

答えは書面でもらう

打ち合わせで聞いたことは、議事録や仕様書に残してもらいます。担当者が変わっても、何を決めたかが分かるようにするためです。社内の監査や、取引先からの確認にも、そのまま使えます。

開発会社への最初の相談の前に何を用意すればよいかは、開発会社に初めて相談する前ににまとめています。この記事のチェックリストの「発注する前」の項目のうち、答えられるものを埋めて持っていくと、話が早く進みます。

クリーヴァに相談するとき

クリーヴァでは、新しいサービスや社内のシステムの開発を、要件の整理からお受けしています。セキュリティについても、守る情報と業務への影響をうかがったうえで、どこまでの対策が必要かを一緒に考え、決めた内容を仕様に残します。

この記事のチェックリストは、クリーヴァに相談いただくときにもそのまま使えます。全部が埋まっていなくても大丈夫です。分からない項目から、一緒に確かめていきます。

おわりに

システム開発のセキュリティは、開発会社だけで決められるものではありません。何を守るか、どこまで対策するかは、業務と事業を知っている発注する側が決めることです。開発会社は、その決めごとをもとに、仕様どおりの対策を作ります。

発注する前に一緒に決めて書面に残し、公開する前に決めたとおりになっているかを確かめる。この2つの時期を押さえるだけで、公開の直前の手戻りも、公開したあとの「誰がやるはずだったのか」という行き違いも、ずっと減らせます。

次に開発会社と打ち合わせるときは、この記事のチェックリストを手元に置いてみてください。