案件のセキュリティ仕様書は、受ける側が一人で書き上げるものだと考えられがちです。もともとこの仕様書は、発注する側と受ける側が情報を出し合いながら作り上げるものです。IPAが公開した講演資料には、責任の所在があいまいなまま進んだ開発が、損害賠償請求の訴訟などのトラブルに発展したケースもあると記されています¹。何を参照し、どんな手順で決めていくのかを、順を追って整理します。

1. 責任の話は役割分担から始まる

案件を受けるとき、最初に整理されるのは機能や納期だけではありません。誰がどこまでの作業を担当するのか、役割分担も同時に固まっていきます。セキュリティに関する対応も、この役割分担のなかに位置づけられる項目のひとつです。

役割分担のなかにセキュリティが組み込まれる場面

要件を整理する打ち合わせの段階で、誰が何を確認し、誰が何を実装するのかが話題になります。ここでセキュリティに関する対応も合わせて取り上げられれば、責任の所在は早い段階で言葉になります。打ち合わせの議題に含まれるかどうかが、後の進めやすさを左右します。

逆に、機能や画面の話だけで打ち合わせが終わると、セキュリティに関する役割は誰の担当なのかが宙に浮いたまま開発が進むことになります。開発が進むほど、後から役割を整理し直す負担は大きくなっていきます。

分担があいまいなまま進んだときに起きること

IPAが公開した講演資料では、責任関係や作業分担などが明確でない場合、損害賠償請求の訴訟などのトラブルに発展するケースもあると記されています¹。ここで示されているのは、担当があいまいなまま進んだ開発が、後になって双方の言い分の食い違いを生むという構図です。

この構図は、発注する側と受ける側のどちらか一方に問題があるという話ではありません。役割分担を整理する段階で、セキュリティの扱いを言葉にしておいたかどうかが、分かれ目になります。

図の作成：Remogu編集部。役割分担とセキュリティの検討の関係を整理したもので、統計データではありません

次の章では、この役割分担のなかで、セキュリティ対策の責任がどのように扱われているのかを見ていきます。

2. 責任の明確化そのものが対象になっている

セキュリティに関する役割分担のなかでも、特に取り上げられているのが「責任の明確化」そのものです。誰が何に責任を持つのかを決める作業自体が、検討の対象として位置づけられています。

「責任の明確化」が検討項目に挙げられている

IPAが公開した講演資料では、責任関係のひとつとして、セキュリティ対策の責任の明確化が挙げられています²。これは、対策の内容を決める前段階として、まず「誰の責任か」を言葉にしておく作業が位置づけられていることを示しています。

責任の所在が先に言葉になっていれば、対策を決める打ち合わせも、誰が何を判断するのかがはっきりした状態で進められます。逆に、その順番が崩れると、決めた対策の意味づけがあとから不安定になります。

責任の明確化を早い段階で扱う考え方

責任の明確化は、開発が進んでから確認する話ではなく、役割分担を決める段階であわせて扱う話です。打ち合わせの議題に加えておくだけでも、責任の所在があいまいなまま進むことを防ぎやすくなります。

発注する側と受ける側のどちらかが主導するという話ではなく、双方が同じ議題として扱うことが、責任の明確化という検討項目の趣旨に沿います。

次の章では、責任を明確にしたうえで、仕様書がどのように作られていくのかを見ていきます。

3. 仕様書は協議して作ると書かれている

責任の所在を言葉にしたあとに続くのが、実際にどのセキュリティ対策を実装するのかを決める作業です。この決め方についても、講演資料のなかで手順が示されています。

情報を提供し合うところから始まる

IPAの講演資料では、必要な情報を提供し合い、セキュリティ基準等の公表情報を参照しながら、協議のうえで実装するセキュリティ対策を決め、その内容をセキュリティ仕様書として作成・合意することが挙げられています³。片方が仕様を用意して、もう片方がそれに従うという形ではありません。

情報を提供し合うという言葉には、発注する側が持つ前提条件と、受ける側が把握している技術的な制約の双方を、打ち合わせのテーブルに出し合う意味が含まれています。

合意の形にするところまでが仕様書づくり

対策を決めるだけでなく、その内容を仕様書として作成し、合意することまでが一連の作業です。口頭でのやり取りだけで終わらせず、決めた内容を残る形にしておくことが、この作業の到達点になります。

この合意のプロセスに、受ける側としてどれだけ関われるかは、案件によって幅があります。関わり方を打ち合わせの早い段階で確認しておくと、後になって話が食い違うことを防ぎやすくなります。

次の章では、この協議が最終的に何を目指しているのかを見ていきます。

4. 目指すのは適切な責任分界点

仕様書を作る協議は、単に対策の内容を決めるだけの作業ではありません。その先には、発注する側と受ける側の責任の境界をどこに置くかという、もう一段階大きな論点があります。

リスクとコストへの共通理解

IPAの講演資料では、ユーザとベンダがリスクとコストについての共通理解をしたうえで、適切な責任分界点を設定するためのプロセスや、契約条項上の手当をモデル契約で提案できないかが、論点として挙げられています⁴。

ここで示されているのは、責任の境界線を決める作業そのものが、まだ整理の途上にある論点だということです。だからこそ、決めた内容をそのつど言葉にして残しておく意味が大きくなります。

観点	内容
リスクとコストの共通理解	ユーザとベンダが同じ前提に立てているかを確かめる観点
契約条項上の手当	責任分界点を契約の内容として残せているかを確かめる観点

受ける側として押さえておきたい視点

受ける側の立場からは、対策を実装するかどうかだけでなく、その判断がどのような前提のもとで行われたのかを合わせて確認しておくと、後から振り返りやすくなります。

責任分界点は一度決めたら固定されるものではなく、開発が進むなかで見直される場合もあります。そのつど、何を根拠に決めたのかを残しておく姿勢が役立ちます。

次の章では、判断のもとになる情報がどこから来るのかを見ていきます。

5. 参照する情報はどこから来るのか

対策を決める協議のなかで欠かせないのが、何を根拠に判断するかという参照情報です。この参照先についても、講演資料のなかで整理されています。

参照情報の提供元

IPAの講演資料では、参照する情報は、公的機関や業界団体、セキュリティ関連企業などが提供するものが挙げられています⁵。特定の一社の基準だけを見るのではなく、複数の提供元から出ている公表情報を照らし合わせる形が想定されています。

参照先が複数の系統に分かれているからこそ、どれか一つだけを確認して終わりにせず、案件の性質に応じて必要な情報を照らし合わせる姿勢が求められます。

提供元の種類
公的機関
業界団体
セキュリティ関連企業等

参照した情報を残しておく意味

どの提供元の、どの情報を参照したのかを記録しておくと、対策を決めた根拠が後から分かる状態になります。参照先を明示すること自体が、責任の明確化にもつながります。

受ける側として、参照した情報の名称や発行元をメモしておくだけでも、打ち合わせのなかで説明がしやすくなります。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

次の章では、これらの情報を参照しながら、仕様書ができあがるまでの具体的な段階を見ていきます。

6. 手順は4つの段階で示されている

責任の所在を言葉にし、参照する情報を確認したあとは、実際に仕様書を仕上げていく段階に入ります。この作成の流れは、4つの段階として整理されています。

仕様書ができるまでの4つの段階

作成の手順は、最初に必要な情報を提示し合い、次に公表情報を参照して脅威を把握し、そのうえでリスクを評価し、最後に対策の実装有無を決定して仕様書に反映するという、4つの段階として整理されています。順番を入れ替えて対策だけを先に決めてしまうと、何を根拠にその対策を選んだのかが、後から説明しづらくなります。

段階	内容
1	必要な情報を相互に提示する
2	セキュリティ基準等公表情報を参照し、脅威を把握する
3	開発対象のシステムを踏まえ、脅威の影響についてリスクを評価する
4	対策の実装有無を決定・合意し、結果を仕様書に反映する

情報の提示から脅威の把握まで

作成の手順として、まず必要な情報を双方が提示し合うことが挙げられています⁶。そのうえで、セキュリティ基準等の公表情報を参照し、セキュリティの脅威を把握することが続きます⁷。

この2段階は、対策を決める前の土台づくりにあたります。何が起こりうるのかを先に共有しておくことで、次のリスク評価の段階に無理なくつながります。

リスク評価から仕様書への反映まで

続く段階では、開発対象のシステムを踏まえながら、脅威の影響についてリスクを評価することが挙げられています⁸。そのうえで、対策の実装有無を決定・合意し、その結果をセキュリティ仕様書に反映することが、最後の段階として示されています⁹。

4つの段階を順にたどると、対策を決める判断が、思いつきではなく積み上げられた手順のうえに成り立っていることが分かります。途中の段階を飛ばして結論だけを合わせようとすると、後になって根拠を説明しづらくなります。

出典：IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」（2025年4月）をもとに作成

次の章では、対策を実装しないという判断をした場合に、何を残しておくとよいかを見ていきます。

7. 実装しない場合の記録と、確かめる項目

ここまでの4つの段階を経ても、すべての対策を実装するとは限りません。実装しないという判断そのものも、講演資料のなかで扱われています。

実装しない場合にも記録が必要な理由

IPAの講演資料では、対策を実装しない場合にも、その旨を記録しておくことが重要だと挙げられています¹⁰。実装しないという判断自体が、後から振り返る対象になるという位置づけです。

記録が残っていれば、なぜその対策を見送ったのかを、後になって双方が確認できます。記録がないまま時間が経つと、判断の理由自体があいまいになってしまいます。

確かめておきたい項目

ここまでの内容を踏まえると、受ける側として確かめておきたい項目が見えてきます。責任の所在、参照した情報、決定した対策の内容、そして実装しない場合の記録です。

図の作成：Remogu編集部。本文で整理した内容をチェック形式にまとめたもので、統計データではありません

ここからは、この記事の内容に関して寄せられやすい疑問について、順に整理します。

初めて参画する案件でも、セキュリティ仕様書の作成に関わりますか

初めて参画する案件であっても、セキュリティ仕様書の作成はエンジニア一人の作業にはなりません。必要な情報を相互に提示し合うところから始まるため⁶、分からない点はその場で確認しながら進める形になります。

副業として稼働している場合も、同じ手順で進みますか

副業として稼働する場合も、役割分担や責任の扱いを整理する流れそのものは変わりません。稼働の形にかかわらず、必要な情報を提供し合い、公表情報を参照しながら対策を決めていく手順が基本になります³。

地方に住んでいてリモートで参加する場合、支障はありますか

地方に住んでリモートで参加する場合でも、情報のやり取りや打ち合わせはオンラインで行われるため、場所による支障は基本的にありません。Remoguでも、案件の90%以上がフルリモート可能です。気になる条件があれば、登録して自分に合う案件を確かめてみてください。

経験がまだ少ない場合、何を確認しておくとよいですか

経験がまだ少ない場合は、決定した対策の内容と、その理由を自分の言葉で説明できる状態にしておくと安心です。分からない点をそのままにせず、打ち合わせのなかで確認する姿勢が、責任の所在をはっきりさせることにつながります。

契約に定められた要件は、どこまで確認すればよいですか

契約に定められた要件については、どこまでの対策を実装するのかという合意の内容と、その結果が仕様書に反映されているかどうかを確認しておくとよいでしょう⁹。

週3日の稼働でも、この手順に変わりはありますか

週3日の稼働であっても、必要な情報を提示し合い、公表情報を参照しながら対策を決めていく流れに変わりはありません³。稼働日数よりも、責任の所在をどれだけ言葉にできているかが重要です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起点の問題（2025年4月・2026年9月確認）
＊2 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」責任の明確化（2025年4月・2026年9月確認）
＊3 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」仕様書の作り方（2025年4月・2026年9月確認）
＊4 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」分界点の設計（2025年4月・2026年9月確認）
＊5 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」参照先（2025年4月・2026年9月確認）
＊6 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」手順1（2025年4月・2026年9月確認）
＊7 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」手順2（2025年4月・2026年9月確認）
＊8 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」手順3（2025年4月・2026年9月確認）
＊9 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」手順4（2025年4月・2026年9月確認）
＊10 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」書かない記録（2025年4月・2026年9月確認）