「グローバルIPは固定にしますか」「VPN接続を前提にしてよいですか」——システム開発をベンダーに発注しようとすると、要件定義や見積もりの場でこうしたネットワーク・セキュリティ用語が次々と飛んできます。意味が分からないまま「お任せします」と答えてしまい、後になって想定外の費用が請求されたり、思っていたセキュリティ水準と違ったりしないか、不安を感じている方も多いのではないでしょうか。
社内に専任のインフラエンジニアやネットワーク担当がいなければ、これらの用語を独学で完璧に理解するのは現実的ではありません。かといってベンダーに丸投げすれば、責任の所在が曖昧になり、トラブルが起きたときに「言った・言わない」の押し問答に巻き込まれてしまいます。発注者にとって本当に困るのは、用語を知らないことそのものよりも、「仕様書に何を書けばいいか分からず手が止まる」「ベンダーの提案を承認していいか判断できない」という、意思決定が前に進まない状態です。
結論からお伝えすると、発注者がネットワークの仕組みを専門家レベルで理解する必要はありません。必要なのは、発注判断に直結する「最小限の知識」と、それを仕様書に落とし込み、ベンダーに確認するための「型」だけです。
本記事では、システム開発の発注者が押さえるべきIPアドレス・VPN・アクセス制御の基礎を、技術の仕組みの解説は最短にとどめ、「仕様書に何を書くか」「ベンダーに何を確認するか」「提案をどう承認判断するか」という発注実務に直結する形で整理します。読み終えたときには、ネットワーク要件を自分の言葉で1〜2行でも書け、確認ポイントを持って打ち合わせに臨める状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜ発注者がIPアドレス・VPNの基礎を知るべきか
最初にお伝えしておきたいのは、「あなたがネットワークの専門家になる必要はない」ということです。それでもなお基礎を知っておくべき理由は、ネットワーク要件を曖昧にしたまま発注すると、発注者側に思わぬ不利益が生じるからです。
ネットワーク要件を曖昧にしたまま発注するリスク
ネットワーク・セキュリティの要件をベンダーに丸投げすると、主に3つのリスクが発生します。
1つ目は、責任の所在（責任分界点）が曖昧になることです。たとえば「外部からの不正アクセスを防いでほしい」とだけ伝えた場合、どこまでをベンダーが担保し、どこからが自社の運用責任なのかが決まっていません。実際にインシデントが起きたとき、契約書や仕様書に明記がなければ「そこは依頼に含まれていない」と言われても反論が難しくなります。
2つ目は、想定外の追加コストです。たとえば「固定IPで運用したい」「拠点間をVPNでつなぎたい」といった要件は、開発の後工程で判明すると、設計のやり直しや回線契約の追加が必要になり、当初見積もりに上乗せされます。要件定義の段階で決めておけば見積もりに織り込めた費用が、追加請求という形で跳ね返ってくるのです。
3つ目は、セキュリティ水準のミスマッチです。発注者は「当然このくらい守られているだろう」と期待していても、要件として明示していなければベンダーは最低限の構成しか組まないことがあります。逆に、過剰なセキュリティ要件を曖昧なまま求めると、不要なコストを払うことにもなります。
これらはいずれも、要件定義の段階で「最小限の言葉」を書けていれば防げるものです。
発注者に求められるのは「仕組みの専門知識」ではなく「判断のための要点」
ここで強調したいのは、発注者に求められるのは技術の内部構造を理解することではない、という点です。IPアドレスがどんなビット構造を持つか、VPNがどんな暗号アルゴリズムでトンネルを作るか——こうした技術詳細は、実装を担うベンダーの領域です。
発注者が押さえるべきなのは、次の3つの「判断のための要点」だけです。
- その用語が何を意味し、自社の何に影響するのか（コスト・セキュリティ・運用）
- その要件を仕様書にどう書けばよいか
- ベンダーの提案をどう承認判断すればよいか
本記事は、この3点に絞ってIPアドレスとVPNを解説していきます。「全部を理解しなければ」と気負う必要はありません。判断に必要な土台だけを、これから順に埋めていきましょう。
IPアドレスとは何か｜発注者が押さえる3つのポイント
IPアドレスは、ひとことで言えば「ネットワーク上の住所」です。郵便物を届けるのに住所が必要なように、インターネットや社内ネットワークでデータをやり取りするには、機器を識別する番号が必要です。その番号がIPアドレスです。
発注者として押さえるべきは、住所の仕組みそのものではなく、発注判断に直結する次の3つのポイントです。
IPアドレスは「ネットワーク上の住所」｜グローバルIPとプライベートIP
IPアドレスには大きく2種類あります。
- グローバルIPアドレス: インターネット上で機器を識別するための住所。インターネット全体で重複しないように管理されています。外部に公開するWebサイトやサーバーには、このグローバルIPが必要です。
- プライベートIPアドレス: 社内LANや自宅など、特定のネットワーク内だけで使う住所。外部から直接アクセスされることはなく、組織内の機器を識別するために使われます（参考: グローバルIPアドレスとプライベートIPアドレスの違い（NURO Biz））。
発注の文脈では、「インターネットに公開するシステムか、社内ネットワークの中だけで使うシステムか」で、必要なIPアドレスの種類が変わると理解しておけば十分です。たとえば外部の取引先がアクセスするWebサービスならグローバルIPが前提になり、社内だけで使う業務システムなら社内ネットワーク内のプライベートIPで完結することもあります。
固定IPと変動IP｜どんなときに固定IPが必要か
グローバルIPアドレスには、さらに「固定IP」と「変動IP（動的IP）」の区別があります。
- 変動IP（動的IP）: 接続のたびに、あるいは一定期間ごとにアドレスが変わるタイプ。多くのインターネット回線は標準でこちらです。
- 固定IP: 常に同じアドレスが割り当てられるタイプ。回線契約で追加オプションとなることが多く、月額費用が上乗せされるのが一般的です（参考: 固定IPとは？動的IPとの違い（NTTPCコミュニケーションズ））。
固定IPが必要になる典型的な場面は次のようなケースです。
- 後述のIP制限（アクセス許可リスト）をかけたいとき。アクセス元のIPが固定されていなければ、許可リストで絞り込めません。
- 自社サーバーで外部公開するシステムを安定運用したいとき。
- 拠点間をVPNで接続したいとき（接続元・接続先のIPが固定されていると設定・運用が安定します）。
ベンダーから「固定IPにしますか」と聞かれたら、それは「IP制限をかけたいか」「外部公開や拠点間接続の予定があるか」という質問だと読み替えてください。これらの予定がなければ、変動IPで問題ないケースも多くあります。固定IPは便利な一方で月額コストが発生するため、必要性を判断するのは発注者の役割です。
IP制限（アクセス許可リスト）でできること・できないこと
「IP制限」または「アクセス許可リスト（ホワイトリスト）」は、システムのセキュリティを語るうえで発注者がよく耳にする用語です。
これは、あらかじめ許可したIPアドレスからのアクセスだけを通し、それ以外をすべて遮断する仕組みです。たとえば「社内のオフィスと特定の拠点からのアクセスだけを管理画面に許可する」といった使い方をします（参考: IPアドレス制限とは？仕組みとメリット（ロリポップ！VPNコラム））。
IP制限でできること・できないことを整理すると、次のようになります。
できること | できないこと |
|---|---|
許可していないIPからのアクセスを遮断する | 許可したIP内部からの不正操作は防げない |
管理画面など限られた人だけが使う機能を保護する | 不特定多数が使う一般公開Webサイトには適用しにくい |
社内・特定拠点からのみアクセスさせる運用を実現する | IPが変わる環境（自宅の変動IP等）では運用が煩雑になる |
IP制限は強力なアクセス制御ですが、「IP制限さえかければ完全に安全」というわけではありません。許可したIPの内側からの不正や、IDパスワードの漏えいまでは防げないためです。この点は後ほど「よくある発注者の誤解」でも改めて触れます。
VPNとは何か｜なぜシステム開発でVPNが必要になるのか
VPNは「Virtual Private Network（仮想専用線）」の略で、ひとことで言えば公衆のインターネット回線上に作る、暗号化された専用の通信トンネルです。本来は誰でも通れる公道（インターネット）の上に、中身が見えない専用の通路を作るイメージだと考えてください。
VPNは「暗号化された専用トンネル」｜何を守るのか
VPNが守るのは、主に通信の途中での盗聴・改ざんです。インターネットを流れるデータは、対策をしなければ経路の途中で第三者にのぞき見されたり、書き換えられたりするリスクがあります。VPNは通信を暗号化してトンネルの中を通すことで、たとえ経路上で誰かにデータを傍受されても、中身を読み取れないようにします。
つまりVPNは「アクセスを制限する技術」というより、「通信経路を保護する技術」です。先ほどのIP制限が「誰を通すか」を制御するものだとすれば、VPNは「通る道そのものを安全にする」ものだと整理すると分かりやすいでしょう。
システム開発でVPN要件が出てくる典型シーン
発注者として、どんな場面でVPNが要件になるのかを知っておくと、ベンダーの提案を判断しやすくなります。典型的なシーンは次の3つです。
- 拠点間接続: 本社と支社、あるいは自社とデータセンターなど、離れた拠点のネットワーク同士を安全につなぎたいとき。
- リモートからのサーバー・管理画面アクセス: 開発・運用担当者が社外から本番サーバーや管理画面に接続する必要があるとき。インターネット越しに直接つなぐのは危険なため、VPN経由に限定することがよくあります。
- テレワーク・在宅勤務: 従業員が自宅から社内システムへ安全にアクセスするとき（参考: VPNとは？仕組みや導入のメリット・デメリット（KDDI））。
ベンダーから「VPN接続を前提にしてよいですか」と聞かれたら、それは「外部から社内やサーバーにアクセスする経路を、暗号化されたトンネルに限定してよいか」という確認です。多くの場合、セキュリティ上はVPN前提のほうが望ましい一方で、VPN環境の構築・維持にはコストや運用負荷が伴うため、その費用感を含めて判断することになります。
インターネットVPNとIP-VPNの違いは「コスト対セキュリティ」で捉える
VPNには複数の種類がありますが、発注者が押さえておくべきなのは、代表的な2つを「コストとセキュリティのトレードオフ」という軸で捉えることです。技術的な仕組みの詳細まで覚える必要はありません。
種類 | 通信経路 | コスト感 | セキュリティ・品質 |
|---|---|---|---|
インターネットVPN | 既存のインターネット回線を利用 | 比較的安価（既存回線＋VPN機器が中心） | 標準的。回線品質はインターネットに依存 |
IP-VPN | 通信事業者の閉域網（クローズドな専用ネットワーク）を利用 | 高め（帯域・拠点数に応じた月額が発生） | 高い。閉域網のため信頼性・通信品質に優れる |
ざっくり言えば、コストを抑えたいならインターネットVPN、セキュリティと通信品質を重視するならIP-VPNという関係です。IP-VPNは通信事業者の閉域ネットワークを使うため、インターネットを経由しない分、信頼性とセキュリティに優れます。一方でランニングコストは高くなる傾向があります（参考: IP-VPNとインターネットVPNの比較（InfiniCore））。
発注者としては、まず「どの程度のセキュリティ・通信品質が必要な業務か」「そのためにどこまでのコストをかけられるか」という観点で、ベンダーに選択肢とおおよその費用感を提示してもらい、自社で判断するのが現実的です。製品やサービスの細かい選定はベンダーに委ねてよい領域ですが、「コストとセキュリティのどちらを優先するか」という方針は発注者が決めるべきポイントです。
ネットワーク要件を発注書・仕様書に書く方法
ここからが本記事の核心です。ここまでの基礎をふまえて、要件定義書やRFP（提案依頼書）のセキュリティ・ネットワーク欄に、実際に「何を・どの粒度で」書けばよいかを見ていきます。専門用語を完璧に使いこなす必要はありません。要点を押さえた一文が書ければ、それで発注者としては十分です。
仕様書に書くべきネットワーク要件4項目（記載例つき）
発注者がまず押さえておきたいネットワーク要件は、次の4項目です。それぞれに「そのまま使える記載例」を添えます。
1. アクセス元の制限（IP制限の有無）
誰がアクセスできる範囲なのかを示します。
記載例: 「管理画面へのアクセスは、当社が指定するIPアドレス（オフィス・拠点）からのみ許可すること。一般利用者向け機能はインターネットからのアクセスを許可する。」
2. 通信の暗号化（HTTPS/VPN前提か）
通信経路をどう保護するかを示します。
記載例: 「利用者とシステム間の通信はすべてHTTPS（暗号化通信）とすること。運用・保守担当者が外部からサーバーへ接続する場合はVPN経由に限定すること。」
3. 接続経路（拠点間接続・リモート保守の有無）
どんな接続を想定しているかを示します。
記載例: 「本社・支社間の拠点間接続を前提とする。保守作業のためのリモートアクセス経路の要否について、貴社の推奨構成を提案いただきたい。」
4. データの保管場所（国内／海外リージョン）
データをどこに置くかを示します。法令やセキュリティポリシー上、国内保管が求められるケースがあります。
記載例: 「システムおよびデータの保管・処理は日本国内のリージョンで行うこと。」
これらは1項目あたり1〜2行で構いません。完璧な技術仕様を書く必要はなく、「自社として譲れない方針」を明示することが目的です。詳細な実現方法はベンダーが設計します。
発注者が決めること／ベンダーに委ねることの線引き表
すべてを発注者が決める必要はありません。「方針は発注者が決め、実現手段はベンダーに委ねる」という線引きを押さえておくと、要件定義がスムーズに進みます。
項目 | 発注者が決めること | ベンダーに委ねてよいこと |
|---|---|---|
アクセス制限 | 誰に・どの機能を許可するかの方針 | IP制限の具体的な実装方法・機器 |
通信の暗号化 | 暗号化を必須とするかどうか | 暗号化の方式・証明書の種類 |
VPN | VPN利用の要否・優先する方針（コスト重視かセキュリティ重視か） | VPNの種類・製品・構成の詳細 |
データ保管場所 | 国内／海外の方針、対象データの範囲 | 利用するクラウド・データセンターの選定 |
障害対応 | 求める復旧時間の目安・連絡体制の希望 | 冗長化・バックアップの具体構成 |
「決めること」の列は発注者の判断が必要な部分、「委ねてよいこと」の列はベンダーの専門領域です。この線引きを意識するだけで、「全部を自分で決めなければ」というプレッシャーから解放されます。
「自社で決めきれない」場合の書き方｜ベンダーに提案を求める一文
ネットワーク要件には、発注者だけでは判断しきれないものもあります。その場合に「空欄のまま放置する」のは避けたいところです。空欄は「要件なし」と解釈され、後でトラブルの原因になります。
決めきれないときは、ベンダーに提案を求める一文を書くのが正解です。
記載例: 「ネットワーク・セキュリティ構成については、当社の業務内容（取り扱うデータ・想定利用者数）をふまえ、コストとセキュリティのバランスをとった構成を複数案ご提案いただきたい。各案のメリット・デメリットと概算費用を併記すること。」
このように書いておけば、判断材料をベンダーから引き出せます。「分からないから書かない」のではなく、「分からないから提案を求める」と書く——これが発注者にとって最も現実的で安全な書き方です。
ベンダーへのセキュリティ・ネットワーク確認ポイント5項目
要件を書いたら、次は打ち合わせや提案レビューの場でベンダーに確認する番です。ここでは、発注者が確認すべき質問を5つに絞ってチェックリスト形式で示します。各項目に「なぜ確認するか」と「望ましい回答の方向性」を添えますので、提案を承認していいかどうかの判断材料にしてください。
1. 利用者とシステム間の通信は暗号化されますか（HTTPS化されますか）
- なぜ確認するか: 暗号化されていない通信は、途中で情報を盗み見られるリスクがあります。今や暗号化は標準的な対策です。
- 望ましい回答の方向性: 「すべての通信をHTTPSで暗号化する」と明確に回答できること。
2. 管理画面や重要機能へのアクセス制限はどうなりますか
- なぜ確認するか: 不特定多数がアクセスできる管理画面は、攻撃の入り口になります。IP制限や認証の強化が必要です。
- 望ましい回答の方向性: IP制限・多要素認証など、複数の手段を組み合わせた回答が出てくること。「IDパスワードだけ」という回答は要注意です。
3. IPアドレスやドメインの取得・管理は、どちらがどこまで行いますか
- なぜ確認するか: 固定IPの契約やドメインの管理を「どちらが・誰名義で」行うかが曖昧だと、契約終了時に引き継ぎでトラブルになります。
- 望ましい回答の方向性: 取得・契約名義・更新管理の責任分担が明確に示されること。自社名義で取得・管理することを基本とし、ベンダー名義になる場合は理由と移管条件を確認しましょう。
4. 障害が起きたときの連絡経路と対応時間はどうなりますか
- なぜ確認するか: ネットワーク障害は必ず起こりうるものです。起きてから慌てないために、事前に体制を確認します。
- 望ましい回答の方向性: 連絡窓口・受付時間・想定復旧時間の目安が示されること。契約書や保守条件に明記される形が望ましいです。
5. 脆弱性（セキュリティ上の弱点）が見つかった場合の対応方針はどうなりますか
- なぜ確認するか: 公開後に新たな脆弱性が発見されることは珍しくありません。発見後に誰が・どう対応するかが決まっていないと、放置されるリスクがあります。
- 望ましい回答の方向性: 脆弱性が見つかった際の通知・修正対応の範囲（保守契約に含まれるか・別費用か）が明示されること。
この5項目に明確に答えられるベンダーは、ネットワーク・セキュリティへの理解と運用体制を備えていると考えてよいでしょう。逆に、回答が曖昧だったり「お任せください」で具体性に欠けたりする場合は、契約前にもう一段踏み込んで確認することをおすすめします。
よくある発注者の誤解と注意点
最後に、発注者が陥りやすい誤解を取り上げます。基礎を学んだ直後は「これで安心」と思いがちですが、浅い理解のまま発注すると、かえってリスクを見落とすことがあります。発注後のトラブルを防ぐために、3つの誤解を正しい理解に修正しておきましょう。
「VPNやIP制限を入れれば安全」という思い込み
VPNやIP制限は有効なセキュリティ対策ですが、それだけで「すべてが守られる」わけではありません。
- VPNは通信経路を守りますが、システム自体の脆弱性やIDパスワードの漏えいまでは防げません。
- IP制限は許可した範囲外からのアクセスを遮断しますが、許可した範囲の内側からの不正操作は防げません。
セキュリティは、暗号化・アクセス制限・認証の強化・脆弱性対策などを複数組み合わせる（多層防御）ことで初めて実効性を持ちます。「一つの対策を入れたから安全」ではなく、「複数の対策が重なって安全に近づく」と理解しておきましょう。
「ネットワークはベンダーに任せれば自社は無関係」という誤解
開発と初期構築はベンダーが担いますが、システムの運用が始まった後も、ネットワーク・セキュリティの責任の一部は自社に残ります。
たとえば、IP制限の許可リストに新しい拠点を追加する判断、社員の入退社にともなうアクセス権限の見直し、不審なアクセスがあった際の一次対応など、運用上の意思決定は発注者側が担うことになります。どこまでがベンダーの保守範囲で、どこからが自社の運用責任なのか——この責任分界点を契約時に確認しておくことが、後のトラブルを防ぎます。
「セキュリティ対策はコストをかけるほど良い」という誤解
一見すると正しそうですが、これも要注意です。過剰なセキュリティ要件は、不要なコストを生むだけでなく、運用を複雑にして現場の負担を増やします。
大切なのは、自社が扱うデータの重要度や想定されるリスクに見合った対策を選ぶことです。個人情報や決済情報を扱うシステムと、社内の情報共有ツールとでは、求められるセキュリティ水準は当然違います。「最高水準」を一律に求めるのではなく、業務の性質に応じて適切な水準を選ぶ——その判断のために、本記事で整理した「コストとセキュリティのトレードオフ」の視点が役立ちます。
まとめ｜発注者が押さえる最小知識のおさらい
ここまで、システム開発の発注者が押さえておくべきIPアドレス・VPN・ネットワークの基礎を、発注実務に直結する形で整理してきました。最後に、発注前に確認しておきたいポイントをチェックリストとしてまとめます。
- IPアドレスは「ネットワーク上の住所」。インターネット公開ならグローバルIP、社内利用ならプライベートIPで完結することもある
- 固定IPは、IP制限・外部公開・拠点間接続の予定があるときに必要。月額コストが伴うため必要性を判断する
- IP制限（許可リスト）は許可したIPだけを通す仕組み。ただし内部からの不正までは防げない
- VPNは通信経路を暗号化して守る技術。拠点間接続・リモート保守・テレワークで要件になる
- インターネットVPNとIP-VPNは「コスト対セキュリティ」のトレードオフで捉える。方針は発注者が決め、製品選定はベンダーに委ねてよい
- 仕様書には4項目（アクセス制限・通信の暗号化・接続経路・データ保管場所）を1〜2行ずつ書く。決めきれない項目は「提案を求める一文」を書く
- ベンダーには5項目（通信暗号化・アクセス制限・IP/ドメイン管理・障害時連絡経路・脆弱性対応）を確認する
- セキュリティは多層防御で考える。運用責任の一部は発注後も自社に残る
これらを押さえておけば、ベンダーとの打ち合わせで用語に臆することなく、ネットワーク要件を自分の言葉で仕様書に書き、提案を承認可否で判断できるようになります。「丸投げ」ではなく「要点を押さえた発注者」として、システム開発を主体的に進めていきましょう。
ネットワーク要件は、システム開発における要件定義全体の一部です。本記事で整理した土台を起点に、自社の業務に必要なセキュリティ要件の洗い出しへと進めていただければ、より精度の高い発注ができるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
