ゼロトラストのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

ゼロトラストのシステム開発は、要件整理、製品・サービスの選定、設計開発、テスト、段階移行による稼働、定着の6段階で進めます。

各段階で納めるものと判断基準を決めておくと、業務を保ちながら必要なアクセス制御を整えられます。

▼全体ガイドの記事
・ゼロトラストのシステム開発の完全ガイド

ゼロトラストのシステム開発の全体像

認証、端末管理、アプリ接続、データ保護、ログ監視を積み重ねたゼロトラスト基盤の図。
一つの要素だけでなく、各層を組み合わせてアクセスを判断します。

ゼロトラストは特定の製品名ではなく、アクセスのたびに判断するセキュリティアーキテクチャです。社内ネットワークにいることや一度ログインしたことだけを理由に利用者を信頼せず、必要な範囲だけを許可します。

判断の材料には、利用者や端末の状態、アプリやデータがあります。場所や時刻、リスクも条件に含まれます。既存の業務を止めずに安全なアクセスへ移す視点を持つ必要があります。

ゼロトラストのシステムの定義

ゼロトラスト基盤は、複数の要素を連携させて、アクセスごとに信頼度を評価する仕組みです。その要素には、認証や端末管理、アプリ接続があります。データ保護やログ監視も含まれます。

  • 明示的に検証:利用者や端末などの状態の確認
  • 最小権限:必要な範囲に限ったアクセスの許可
  • 侵害を前提に設計:監視と対応を続ける仕組み

NISTのSP 800-207の考え方を具体化したSP 1800-35は、2025年6月の最終版で19の実装例を紹介しています。この文書の対象は、オンプレミスと複数クラウド、ハイブリッド勤務、外部パートナーです(出典:NIST SP 1800-35、2025年)。

それぞれの役割は、IDaaS・IAMがSSOや多要素認証を担い、MDM・UEMが端末を管理します。EDRは脅威を検知し、ZTNA・SASEはアプリ単位の接続を制御します。

ポリシーエンジンが条件を判定し、SIEM・SOCがログを監視します。さらに、業務システム側にもロール別の権限やAPI認証が必要で、操作ログとデータ分類も欠かせません。

多要素認証(MFA)を導入しても、端末の状態、過剰権限、異常操作は確認できません。そのため、認証の追加はゼロトラスト基盤の一部にとどまります。

VPNやMFAだけでは不十分な理由

VPNは遠隔地から社内ネットワークへ接続する手段です。既存のVPNを初日に廃止する必要はありません。まず、接続範囲と端末・運用条件を確認します。

  • VPNの範囲:接続後に広く到達できる構成では、認証情報が漏えいした際に被害が広がるおそれがあります。
  • アプリ単位の制御:誰が、どの端末から、何をするかの確認と、重要なSaaSや業務アプリのZTNAへの移行
  • 段階移行と追加対策:利用状況と障害対応を見てVPNを縮小し、MFAに端末暗号化、OS更新、権限制限、ログ、緊急手順を組み合わせる

国内でも、ネットワークだけを置き換えず、クラウドツールや端末、認証を組み合わせる事例があります。

たとえば、ユニアデックスの埼玉県朝霞市教育委員会の事例では、教職員588人の環境にゼロトラスト型の教育ネットワークを整えました。2024年9月から市内の小中学校で運用しています(出典:ユニアデックス「校務ネットワークのゼロトラストモデル化事例」、2025年公開)。

規模が大きくても、利用者の業務と運用開始後の利便性を見ながら移行する点は参考になります。

ポイント

ゼロトラストは、アクセスのたびに利用者や端末、データの条件で判断する仕組みです。MFAの追加だけではゼロトラスト全体にはならないため、既存VPNの扱いを含めて移行方針を決めておくと、判断がぶれにくくなります。

ゼロトラストのシステム開発の進め方6フェーズ

要件整理から定着までを6段階に分け、各段階で納めるものと判断基準を決めます。さらに、前の段階へ戻る条件も明記しておきます。

最初は20〜100ユーザー・1〜3アプリ程度のPoCから始め、問題がなければ対象を広げます。

デジタル庁の標準ガイドラインには、DS-210「ゼロトラストアーキテクチャ適用方針」があります。これは製品の手順にとどまらず、クラウド利用やサプライチェーンを含めて方式を検討する際の参考になります(出典:デジタル庁「デジタル社会推進標準ガイドライン」、2026年確認)。

民間企業に一律に適用される法律ではありません。ただし、委託先や外部利用者を含めたアクセス条件を整理する際には役立ちます。

フェーズ1:要件整理による資産・リスク・対象範囲の確定

最初に、資産を洗い出します。対象は、利用者や端末、SaaSやクラウド、オンプレミスアプリです。さらに、管理者アカウントや委託先、重要データ、VPN経路も含めます。

台帳には資産名だけでなく、所有者、利用者、認証方式を記録します。加えて、保存データ、外部接続、停止時の業務影響、ログの有無、廃止予定日も残します。

特に、退職者アカウントや共有アカウント、長期未使用の特権ID、インターネット公開システムは、優先して確かめます。

機能要件に加えて、MFAの方式、端末未準拠時の挙動、ログ保存期間、RPO・RTOを決めておきます。さらに、可用性や暗号化、鍵管理、API連携も定めます。障害が起きたときに備えて、代替認証と緊急アクセスの承認者も決めておきます。

個人情報保護委員会は、技術的安全管理措置として、アクセス制御や識別・認証、不正アクセス防止、漏えい防止を示しています(出典:個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年確認)。

要件整理では、守る対象、責任者、例外運用、PoC条件、対象外の5点を書き出しておきます。

  • 守る対象:データと業務の重要度順の整理
  • 責任者:利用者・端末・アプリの所有者の決定
  • 例外運用:現状で認めている例外の洗い出し
  • PoC条件:対象ユーザー・アプリ・成功条件の数値化
  • 対象外:除外する範囲と理由の記録

対象範囲があいまいなまま製品を選ぶと、後から範囲が広がり、費用と工期が膨らみます。

フェーズ2:運用条件で見る製品・サービスの選定

製品は、IDaaS、MDM・UEM、EDRの領域を中心に選びます。ZTNA・SASEやSIEM・SOCも含め、一製品でそろえるか、既存ライセンスと複数製品を連携させるかで比べます。

Microsoft 365利用企業は、Entra ID、Intune、Defenderを中心に検討できます。一方で、Google Workspaceや他のID基盤を使う企業は、既存契約とAPI、端末対応、ログ連携を確かめ、将来の乗り換えやすさも見ておきます。

製品名の多さより、現在の資産と運用体制に無理なく組み込めるかを重視します。また、RFPには比較条件を具体的に記載します。

  • 規模と環境:ユーザー・端末・OS・アプリ・拠点・同時接続数の条件
  • 運用条件:ログ保管日数、監視時間帯、ヘルプデスクの範囲、設定変更の単価
  • 契約条件:終了時のデータ返却と連携対象の明記

候補先には、古いオンプレミスアプリへの接続や、端末故障時の代替手段を質問します。MFAを使えない現場や委託先の扱いも聞いておきます。さらに、誤検知を誰が何時間で調整するかも確認します。

PoCの合格条件は、選定の前に決めておきます。計測するのは、アプリ接続成功率、認証時間、未管理端末の遮断率、権限付与・剥奪時間です。ログ検索、問い合わせ件数、障害復旧時間も計測します。

使いやすさを測らずに機能だけで決めると、現場が回避策を使い、制御が形だけのものになるおそれがあります。

フェーズ3:設計開発によるポリシーと連携の実装

設計開発では、業務の条件をポリシーに落とし込み、製品どうしの連携を組み上げます。例外時の対応も、この段階で具体化します。

  • アクセス条件:利用者・端末・場所・時刻、アプリ、データ分類、リスクをポリシーに反映する
  • 制御の例:管理端末は許可、未更新端末は追加認証、海外の特権操作は遮断、委託先は指定アプリのみ許可
  • 連携の実装:SSO・属性連携・端末証明書、MDM・EDR・ZTNA、SIEMログ、管理者操作記録の構築
  • 例外対応:正常系と例外系の手順の決定、緊急用アカウントの理由・承認・利用時間・ログ・事後確認の必須化

条件が複雑な場合は、許可、追加認証、読み取り専用、遮断のうち、重要なルールから設定します。そのうえで、ログを見ながら段階的に増やしていきます。

既製品の標準機能を優先し、独自開発は業務固有の申請フローやAPI連携に絞ります。認証や暗号、監査ログを自社で作り込むと、脆弱性への対応や仕様変更の負担が増すためです。

例外手順には、端末紛失やスマートフォン交換、認証サービス停止を含めます。通信障害や管理者退職、緊急の特権操作も対象に入れます。

フェーズ4:安全性と業務継続性を同時に確かめるテスト

テストは機能、連携、権限、負荷、障害、利用者受入に分けて、安全性と業務継続性を確認します。

  • 機能・権限:SSO・MFA、退職・異動時の無効化、端末違反、未許可アプリへの接続の確認
  • 業務継続性:基盤の停止時に業務を続けられるかの検証と、代替回線の実使用
  • 受入基準:重要アプリの許可・遮断、高リスク操作の追加認証、ログ追跡(利用者・端末・時刻・操作)、通常ログインの負担、重大障害からの目標時間内復旧

権限テストでは、一般利用者、部門管理者、システム管理者、委託先ごとに閲覧データと操作を確かめます。

業務継続性では、IDaaS、ZTNA、ネットワーク、端末管理、ログ基盤のいずれかが止まった場合に、業務をどこまで続けられるかを検証します。そのうえで、代替回線や復旧用端末を用意し、問い合わせ窓口とエスカレーション先を実際に使います。

認証アプリを使えない夜間、共有端末、工場・店舗など通信が不安定な場所もテスト対象に含めます。未解決の例外は一覧にし、責任者と期限を決めてから稼働へ進みます。

フェーズ5:段階移行と利用者支援による稼働

稼働では、移行順、切替計画、利用者支援をそろえて進めます。

  • 移行順:IT部門などで試したあと、影響の小さいSaaSから停止できない基幹領域へ広げる
  • 切替計画:対象者、日時と準備、戻し方、窓口、責任者の決定、安定までのVPN併用
  • 利用者支援:確認が増える理由、利用端末、MFA紛失時の対応の周知、動画・手順書・FAQ・窓口の用意

初日は問い合わせが増える前提で、応援要員を置きます。あわせて、認証できない場合でも安全に行える代替業務を確保します。

フェーズ6:ログ・権限・ポリシーの継続改善による定着

稼働後も、環境の変化に合わせて権限・ポリシー・運用指標を見直し続けます。

  • 見直す契機:人事異動、端末更新、クラウドの追加、委託先の変更、脅威の変化
  • 定期確認:月次の退職者・異動者・休眠・特権ID・共有アカウントの点検と、四半期ごとの重要アプリ権限・例外期限の見直し
  • 端末・権限KPI:MFA適用率、管理対象端末率、未管理端末数、過剰権限数の推移
  • 対応KPI:異常検知から遮断までの時間、重大アラートの未対応件数、認証関連の問い合わせ件数の推移

KPIが悪化したときの担当者と対応を決めておき、監視を報告だけで終わらせないようにします。SOCを委託する場合は、一次切り分けや顧客連絡、遮断判断、復旧支援、月次報告のうち、どこまでを誰が受け持つかを決めます。

ポイント

迷ったときは、各段階で納品物、責任者、合格条件、次へ進まない条件を決めておくと、判断しやすくなります。PoCを小さく始め、結果を見てから広げる順序も目安になります。

ゼロトラストのシステム開発費用相場と内訳

小規模PoCから全社基盤まで、4つの規模別に初期費用の目安を並べた横棒図。
対象範囲が広がるにつれて、初期費用の目安も上がります。

ゼロトラストに一律の公定価格はありません。費用はユーザー数や端末数、アプリ数、拠点数で変わります。オンプレミス連携やログ保管、SOCの有無、移行対象の複雑さによっても変わります。

ここで示すのは、公開価格と一般的な業務システム開発の工数を組み合わせた、編集上の目安です。発注金額を保証するものではないため、初期費用、ライセンス、運用費を分けて比べます。

規模別の費用相場

小規模なPoCから全社基盤まで、規模ごとに初期費用と期間が大きく変わります。

  • 小規模PoC:20〜100ユーザー・SaaS 1〜3個。初期50万〜300万円、1〜2か月。
  • 複数サービス導入:100〜500ユーザーでID・端末管理・EDR・複数SaaS・運用設計を含み、初期300万〜1,000万円、2〜6か月。
  • ZTNA・SASE:拠点・リモート接続、オンプレミスアプリ、VPN移行を含み、初期1,000万〜3,000万円、4〜12か月。
  • 全社基盤:複数クラウド、マイクロセグメンテーション、SIEM・SOC、数千ユーザー、サプライチェーン連携を含む場合があります。
  • 全社基盤の目安:初期3,000万円〜1億円超、12〜24か月以上になる場合があります。

端末の洗い出しや利用者教育が多い場合には、複数サービス導入の費用が上振れします。

小規模PoCは、既存のID基盤を使い、SSO・MFA、条件付きアクセス、基本的なログ確認に絞る想定です。

全社基盤の金額は、調査メモに基づく推定です。要件や契約条件によって変わります。

Cloudflareの公開料金では、50ユーザーまでのFreeプランと、7米ドル/ユーザー/月のPay-as-you-goがあります。一方で、フル機能のSASEやワークスペース保護を含むプランは個別見積もりです(出典:Cloudflare Zero Trustの料金ページ、2026年確認)。

1ドル150円と仮置きすると、7米ドルは約1,050円です。この額は為替、税、契約条件を含まない概算です。設計や移行、端末整備、教育、監視を含む総額は、別に考えます。

初期・月額・見落としやすい費用の内訳

費用は、初期、月額、導入後に見落としやすい項目に分けて確かめます。

  • 初期費用:診断や要件定義・基本設計、製品設定、連携と端末登録、ポリシー作成、データ移行とテスト、切替と教育。
  • 月額費用:ユーザー・端末・通信量に応じたライセンス、ログ保管、SOC・MSS、問い合わせ、設定変更、バックアップ。
  • 見落としやすい費用:端末交換やOS更新、回線やアプリ改修、証明書、ログ容量、休日支援や研修、ヘルプデスクや監査と契約更新。

見積書を「ゼロトラスト導入一式」とせず、ユーザー数、端末数、アプリ数、作業時間、試験数の内訳で出してもらいます。

NTTドコモソリューションズの資料は、導入支援、各種設定、SOC定期レポート、ユーザー単位のライセンスを分けた参考価格を載せています。個別見積ではありませんが、費用項目を分けて見るうえでの実例になります(出典:NTTドコモソリューションズ「ゼロトラスト型セキュリティサービス」資料、リサーチノート確認)。

初期費用だけでなく、3年間の総保有コストも試算します。試算には、ライセンスの値上げやユーザー増加、ログ容量の増加、SOCの監視時間、端末更新、運用担当者の工数を含めます。

Microsoft 365や端末管理契約に含まれる機能を二重に購入しないよう、既存契約と追加契約の境界も確かめます。

ポイント

費用は規模や対象範囲で変わるため、初期・月額・見落としやすい費用を分けて、3年間の総額を同じ条件で比べるのが目安です。

ゼロトラストのシステム開発で見積もりを取るポイント

見積もり前にそろえる環境と対象、運用条件、納品物、契約と対応の4項目をカードで示した図。
各社へ同じ条件を渡すと、提案の範囲を見比べやすくなります。

見積の適正さを判断するには、製品の価格表に加えて、自社業務や資産、例外、運用担当者のスキルをそろえます。同じ対象範囲で複数社から提案を受け、内容を並べて比べられます。

何を導入するかに加えて、どの状態まで責任を持って移行するかを、見積の中心に置きます。

見積前の仕様書への対象範囲と納品物の記載

依頼書には、対象範囲と条件、納品物を具体的に書きます。

  • 環境と対象:ユーザー・端末・拠点・OS、業務アプリとSaaS、認証、データ・ネットワーク、既存ライセンス
  • 運用条件:対象外システム、VPN併用期間、教育範囲、ログ保存期間、監視時間帯、障害時の目標復旧時間
  • 納品物:設計・運用手順書、台帳と権限表、ポリシー、連携設計、テスト結果、切替・復旧手順

納品物を「設定完了」だけにとどめず、利用者向け手順書、運用フロー、ログ確認方法、残課題一覧まで指定します。会社によって納品物の粒度が異なり、安く見える見積でも、発注後に別料金が生じる可能性があります。

体制と分界を含めた複数社の比較

複数社を比べるときは、同規模・同業種の実績、現状診断とPoCの範囲、マルチベンダー連携を確かめます。オンプレミス接続、運用設計、SOC・ヘルプデスク体制も見ておきます。

設計、移行、運用の責任者が打ち合わせに参加するかも、判断材料になります。質問と回答は口頭で済ませず、提案書や契約書に反映します。

  • PoCと代替手段:PoCのユーザー数とアプリ数、MFA失敗時の代替方法
  • 端末とログ:未準拠時に業務を止めるか読み取り専用にするか、ログの保存日数と分析担当者
  • 契約と対応:設定変更、チケット、SOC、休日対応が月額に含まれるか、契約終了時のポリシーとログの返却可否

「ゼロトラスト対応」とだけ書かれ、対象アプリ数や端末条件、監視範囲が示されていない提案には注意が必要です。

製品販売会社、導入SIer、SOC事業者、業務アプリ開発会社の役割を分け、障害やインシデント時の一次窓口と最終責任者を決めます。

費用と工期が膨らむリスクの事前管理

費用と工期を抑えるには、開始前のリスク整理と変更管理が欠かせません。

  • 主なリスク:不完全な台帳、全社一括の切替、期限のない例外、共有端末や古いOSの除外、ログの担当者不在
  • 発注前の対策:資産の不明点の解消、PoCの対象と対象外の線引き、移行の段階ごとの撤退条件の整理

業務システム開発では、要件定義が不十分だと工数・費用が1.3〜1.5倍に膨らみやすいという一般的な注意点があります(出典:リサーチノート内の業務システム一般Q&A、2026年確認)。

ゼロトラストでも、例外の追加や端末交換、アプリ改修、ログ容量の増加が範囲の拡大につながります。そのため、変更の承認者と追加費用の算定方法を契約前に確かめておきます。

導入効果は、製品数や設定数ではなく、業務リスクの低下で測ります。未管理端末、過剰権限、休眠アカウント、外部公開経路、ログ未取得の重要アプリを、導入前後で比べます。

現場が業務を止めたり抜け道を使ったりしないよう、利用者体験と業務継続性も評価します。

ポイント

見積は、対象範囲や納品物、運用条件を各社にそろえて比べるのが目安です。そのうえで、体制と分界、契約終了時の扱いまで確かめます。

ゼロトラストのシステム開発に関するよくある質問

発注前によく問われるのは、導入範囲、既存環境との接続、利用者への影響、運用体制です。特に多い疑問に、順に答えます。

50〜300人程度の企業でもゼロトラストのシステムを導入できますか?

導入できます。既存のID基盤を使い、SSO・MFAと端末の基本管理から始め、1部門・1〜3アプリのPoCで効果と運用負担を確かめます。

情シスの人数が少ない場合は、設定変更、ログ監視、問い合わせ対応を、外部のマネージドサービスへ委託する方法もあります。

ゼロトラストへ移行すると既存VPNはすぐ廃止しますか?

すぐに廃止する必要はありません。重要アプリをアプリ単位の接続へ移し、接続成功率や障害時の復旧、運用担当者の対応を確かめながら、対象を減らしていきます。

すぐにZTNAへ移せない古い業務アプリや、工場・拠点の機器は、期限付きの例外として扱います。そのうえで、リスクと代替計画を管理します。

MFAを導入すればゼロトラストのシステムは完成しますか?

MFAを入れても、ゼロトラストのシステムが完成したとはいえません。端末管理やOSの状態、最小権限、許可アプリへの接続、異常操作の検知も組み合わせる必要があります。

認証、端末、アプリ、データ、ログを、一つのアクセス判断につなげます。

ゼロトラストのシステム開発費用を抑えるにはどうすればよいですか?

既存のID・端末管理ライセンスを確認し、重要度の高い部門とアプリに絞ってPoCを行うと、不要な購入と手戻りを減らせます。

標準機能を優先し、独自開発は業務固有の連携に限定します。ただし、監視、教育、端末整備、ログ保管を削りすぎると、運用が回らなくなります。初期費用だけでなく、3年間の総保有コストで判断します。

ポイント

導入範囲や既存VPNの扱いは一度に決めず、段階ごとに判断するのが目安です。小規模な企業では、PoCや外部委託を組み合わせる方法もあります。

まとめ:段階導入によるゼロトラストのシステムの定着

ゼロトラスト開発は、製品を一つ導入して終わるプロジェクトではありません。利用者、端末、アプリ、データ、通信を都度検証し、必要最小限のアクセスを許可します。

侵害を前提に監視と復旧を行う業務基盤です。VPNの置き換えやMFAの追加だけで終わらせず、既存業務と運用を含めて設計します。

6フェーズを納品物と判断基準でつなぐ流れ

要件整理で資産・リスク・対象範囲を明確にし、選定で製品と運用条件を比べます。そのうえで、設計開発でポリシーと連携を実装し、テストで安全性と業務継続性を確かめます。

稼働では段階的に移行し、定着後は権限・ログ・ポリシーを改善します。納品物、責任者、合格条件、次へ進まない条件を決めておくと、現場で使える仕組みになります。

最初の一歩は資産台帳と小さなPoC

着手から見積比較まで、順に進めます。

  1. ユーザー・端末・SaaS・業務アプリ、管理者権限、重要データ、VPN経路を一覧にし、対象と優先順位を決めます。
  2. 20〜100ユーザー・1〜3アプリでの、認証、端末条件、ログ、利用者体験、障害時の代替手段の検証。
  3. 初期費用、ライセンス、監視、教育、移行、端末整備を含む3年総額と、導入後にどこまでを誰が受け持つかを比較します。

▼全体ガイドの記事
・ゼロトラストのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。